从想法到作品 / 章节 04
第四章｜改坏了、走偏了，怎样继续
读完这一章，你可以
用复现、调查和回归检查处理故障，保存可用版本。
前面我们在贪吃蛇里加入了速度档，并沿着暂停需求完成了学习与修改。现在假设你发现：第一次开始正常，暂停后恢复也正常，但重新开始几次之后，蛇的移动变得异常。
这时候，继续加新功能会让问题更难理解。我们先围绕这一处故障，把信息收集、排查、恢复和交接连起来，学会让项目保持可继续修改的状态。
先把“有时候不对”变成一段操作
你可以从打开页面开始，固定一条最短流程：选择轻松档，开始，暂停，继续，重开三次。记录每一步之后看到的变化。
再分别比较：不经过暂停，重开是否仍异常？只暂停继续，不重开是否正常？标准档是否也出现？这些对比帮助我们缩小条件，而不是让每次尝试都变成另一种情况。
整理后可以发给 Agent：
轻松档首次开始正常。
暂停并继续后仍正常；连续重开三次后移动明显变快。
不操作暂停、直接连续重开，也会出现。
预期每次重开都按当前档位重新启动。
请先调查重开与移动循环的关系，提出有依据的原因和检查方式。读到这段，Agent 已经知道问题不只与暂停有关。你提供的是观察结果，节省了它重新猜情境的时间。
重复计时 → 越跑越快
先调查，再决定改哪里
调查可以包括阅读相关函数、搜索循环的创建与停止位置、查看浏览器错误，必要时增加少量诊断输出。请它把发现与假设分开说明：实际代码怎样写，哪种情况可能造成异常，还需要什么验证。
这会让下一步更明确。如果它只说“可能很多原因，建议重写”，可以要求先从当前复现路径检查。一次排查最好能减少未知，而不是不断扩大改动。
你也可以问：“怎样用一个小实验区分这两种解释？”比如检查每次重开是否清理旧计时器，或临时记录一次更新来自哪个循环。实验结束后再移除不需要的诊断内容。
报错和日志该怎样提供
报错通常包含类型、说明、文件位置或调用路径。尽量复制相关完整文本，再附触发步骤。只发最后一个词，可能丢掉最重要的位置线索。
日志则记录程序走到了哪里。某项操作出现了几次、收到什么输入、返回什么结果，都可能帮助判断。先明确想确认什么，再请 Agent 选择记录位置，避免加满整页无用输出。
如果是工具本身连接模型失败，就先处理账号、网络或额度；如果是页面运行后的错误，就提供页面和复现步骤。两类问题属于不同环节，修改方向也不同。
这也是第一章分开确认模型、目录和运行的好处：现在你已经有一张定位问题的地图。
修好目标，再回头看看原有功能
假设原因已经定位，Agent 改好了重开逻辑。先按原来的三次重开复现步骤检查，再试一次速度切换、暂停恢复、撞墙结束和计分。
这些检查各有目的：原步骤确认目标故障消失，其他操作确认这次修改没有破坏相关行为。它们常被称为回归检查。
可以把结果记成一张小表：操作、预期、实际、下一步。第一次做项目时，手动试玩就能产生有效反馈。遇到经常重复的检查，下一章我们再把它整理成 Skill。
如果 Agent 能运行浏览器或测试脚本，也让它提供结果；自己再体验关键操作，尤其是速度、按钮反馈等与感受有关的部分。
怎样保存一个可用版本
一开始复制整个项目文件夹很直观。随着修改增多，可以使用 Git：它记录一组文件在某个时刻的状态，方便比较和恢复。
先掌握几个动作即可：查看当前状态，查看差异，提交一个已经检查过的版本。工具里通常也有图形界面。喜欢用终端时，可以从以下命令认识对应关系：
git status
git diffstatus 看哪些文件有变化，diff 看尚未暂存的具体改动。首次建立仓库可以用 git init；准备保存时，选择本次相关文件加入暂存区（也叫索引），再提交。例如单文件项目：
git add index.html
git diff --staged
git commit -m "Add pause and speed selection"暂存可以理解为选好“这次准备记录哪些变化”。提交信息写清这次做了什么，隔几天再回来也容易认出来。第一次提交若提示缺少姓名和邮箱，按 Git 提示为当前项目设置自己的身份后再继续。
每次保存，都能回看
- 01初始版
- 02速度版
- 03暂停版
恢复时先弄清楚要放弃什么
发现改坏之后，可以先查看差异和历史，找到最近一个可用版本。让 Agent 说明准备恢复哪些文件、会放弃哪些未保存改动，再选择恢复方式。
对于尚未提交、准备放弃的单个文件，git restore index.html 可以还原到索引中的版本；该文件尚未暂存的修改会被覆盖，所以先看差异，想保留的部分先备份。若改动已经提交，则要结合历史选择撤销方式。
刚开始不熟悉时，使用工具的历史和恢复界面也可以。关键是知道自己要回到哪个状态，而不是随机试一串命令。版本记录让你有空间尝试，也让错误更容易收拾。
对话太长时，给项目做一次交接
一轮轮修改后，聊天里可能同时出现旧需求、试过的方案和已经失效的错误。继续让 Agent 从头梳理，会增加负担。
先请它整理一份当前状态：
项目目标：做一个可调整难度的贪吃蛇。
当前能力：基础玩法、速度选择、暂停恢复。
运行方式：浏览器打开 index.html。
当前决定：开局选择档位；重开保留档位并重置本局。
已处理问题：重开后重复移动。
下一步：检查食物生成是否会与蛇身重合。
相关文件与位置：请依据当前代码补充。把这份说明保存到项目中。新会话先读它，再读需要修改的文件。你也可以使用工具提供的上下文管理功能，保留目标、决定和当前进度，减少无关历史。
这里值得区分：项目文件保留在磁盘里，不代表新会话自动知道此前讨论。交接说明把稳定信息重新送到任务中，相关代码则提供当前事实。
哪些信息值得长期留下
运行方法、常用检查、重要约定和容易误解的地方，可以放在项目说明或工具支持的项目指令文件中。例如 AGENTS.md 等文件，需要按所用工具的规则放置。
我建议先写少量真正影响行动的信息：入口在哪里，怎样运行，当前范围，完成改动后要检查哪些场景。已经能直接从代码看出来的细节，可以让 Agent 按需要读取。
项目约定帮助每次任务从相近的起点开始。完整的检查流程则可以再独立整理，供需要的时候使用。两者的区别，会在下一章变得更清楚。
留下一次可复用的排错经历
用几句话记录：怎样发现问题，最短复现是什么，真正原因是什么，怎样确认修好。下一次遇到类似症状，先查这份记录。
如果几轮之后仍没有缩小问题，就先暂停修改，请 Agent 总结已确认事实、仍在猜测的原因和试过的方法。回到可用版本，或者把故障单独缩成一个小例子，再继续讨论。
这一轮结束，我们得到的除了一个可用游戏，还有一套经常会重复的工作：读取规则、安排试玩、记录现象、整理问题。接下来就把这套方法留下来。
停一下，检查自己的理解
RECALL / 一分钟回忆
先凭自己的理解选一项，再看解释。