从想法到作品 / 章节 02
第二章｜让 Agent 沿着你的想法做
读完这一章，你可以
把一个模糊愿望，推进成具体规则、可试玩的改动与有效反馈。
上一章，大家已经得到了一份能玩的贪吃蛇。现在试玩几局，你觉得速度太快，想让第一次玩的人也容易上手。
我想用这一次修改，带大家看清楚一轮轮对话怎样推进。每轮都做一件具体的事：找到现有实现，明确要改什么，讨论方案，动手修改，再根据试玩结果继续调整。上下文、计划模式等词放在章末的 PS 中，大家先跟着对话往下走。
从一句“帮我优化一下”开始
我们很容易这样发消息：
这个游戏太难玩了，帮我优化一下，让它更适合新手。这句话说出了愿望，但还留着很多选择：难在哪里？是移动太快、转向不灵，还是按钮不好找？“优化”以后，什么表现才算改好了？
我把这种只说希望得到什么、把关键选择都留给 Agent 的表达，叫作“许愿式编程”。它适合刚开始找灵感；已经有了具体问题时，就继续把愿望讲成能执行的修改。
接下来，我们把同一句话一步步改清楚。
第 1 轮 · 定位
先不要修改代码。请找到贪吃蛇的运行入口、移动速度与开始和重开逻辑分别在哪里，说明每次开局怎样设置速度，并列出相关文件。
先让 AI 建立代码上下文。你需要知道它准备修改哪里，以及判断依据是什么。
第一轮：先让它找到这次要改的地方
先在工具里打开上一章的 snake-lab 项目，再发送：
本次继续修改当前打开的 snake-lab 项目。
请先查看项目，告诉我：
1. 怎样打开和运行这个游戏？
2. 当前控制蛇移动速度的代码在哪里？
3. 开始新一局、重新开始时，速度分别怎样设置？
我觉得当前速度太快，想增加一个慢速档。
这一轮先阅读和说明，暂时不要修改文件。这轮的目的很明确：先找到当前实现，再谈怎样改。 我们没有要求 Agent 凭“贪吃蛇”三个字重新做一份，而是让它接着已有项目工作。
看回答时，先对照它提到的文件是否真的存在。它指出位置之后，可以在编辑器里打开看一眼；暂时看不懂代码，也先知道这次修改落在哪里。
假如项目中只有 index.html，它可能既是网页入口，也包含移动逻辑；以后文件多起来，入口与速度控制代码可能分别在不同文件中。这里让 Agent 查看实际项目，就能得到这次任务需要的位置。
第二轮：把“慢一点”变成具体玩法
找到位置后，先发一条讨论要求：
我想保留现在的速度，作为“标准”档，再增加一个更慢的“轻松”档。
请先问清会影响实现的选择，比如什么时候切换档位、
重新开始时用哪个档位。先不加入其他功能。假如它问：“运行中也能切换吗？重新开始要保留档位吗？”我们就把决定说下来：
先按下面的方式做：
- 默认选择轻松档。
- 开始前可以选档位，运行中不切换。
- 每次开始或重新开始，都使用当时选中的档位。
- 重开时，分数和游戏局面重新开始，但保留档位选择。
- 这次先调整速度和相关控件，计分、碰撞规则保持原样。
请把这些规则整理成一份简短修改说明。这一轮结束，“适合新手”已经变成了一组可以检查的行为。你能判断它是否默认轻松，是否保留标准档，重开是否使用当前选择。暂时没想清楚的细节，也可以先比较两种方案，再作决定。
对比开头的许愿，这里多出来的是你对作品的选择。Agent 可以帮忙提出问题，但最终要做成怎样，由你逐步确定。
第三轮：先看它准备怎样改
接着发送：
请按刚才确认的规则，先列出这次修改的步骤。
说明需要改哪些位置，每一步完成后，我可以怎样运行和检查。
如果某一步会影响计分或碰撞，请单独指出。
这一轮先给方案，暂时不要修改文件。读这份方案时，对照第二轮的规则：轻松与标准两个档位有没有，默认值有没有，重开有没有。再看是否多出了排行榜、登录或大规模改造。这些都可以在执行前调整。
比如发现它漏掉重开，可以继续发：
方案里补上重开的处理。重点检查旧一局怎样结束，
新一局怎样读取当前档位。其他部分先按这次的范围推进。这里是在用计划帮助我们看清改动，而不是要求它提前写出每一行代码。需要认识计划模式时，可以看章末 PS 3。
第四轮：先做出一个可以试玩的改动
方案对齐之后，开始执行：
先完成第一步：增加轻松、标准两个档位，并让开始新一局时使用所选档位。
现有速度保留为标准档，轻松档采用更慢的速度。
完成后告诉我两个档位当前怎样设置，以及我该怎样比较。
先停在这一步，等我试玩后再继续处理重开的完整流程。完成后打开页面，分别选两个档位开始一局，看看区别。这里先把“新一局按档位运行”做出来，得到一次及时反馈。
如果轻松档仍然太快，可以继续说：
轻松档已经比标准慢了，但我试玩时仍觉得开局太急。
请先说明当前两档的速度设置，我想在理解这个设置后再决定改多少。到这里，已经出现了一个很好的学习入口：为了作出更精确的修改，你开始需要理解“速度怎样设置”。下一章会沿着这个目的展开。
确认这一步的体验后，再发送：
两个档位的首次开局已经可以区分。现在继续处理重开：
结束后切换档位，再重新开始，新一局应使用新的选择。
保留刚才已经做好的档位控件和首次开局行为。每个步骤都能单独运行和判断，下一步也接着上一步已经做到的结果继续。这就是分步推进的实际用法。
第五轮：用操作和结果反馈问题
假设你试玩后发现：轻松档开始正常，结束后改成标准档，再点重开，速度却仍然很慢。
此时一句“还是不对，再优化一下”，又会把任务交回猜测。把它换成：
我按下面的顺序操作：
1. 选轻松档，开始一局，直到结束。
2. 把选择改成标准档。
3. 点击重新开始。
实际：新一局仍然按轻松档的速度运行。
预期：新一局使用刚选中的标准档。
请先查看相关代码，说明可能原因与依据，再修复这一处。
本轮保持其他玩法不变。这段反馈给出了复现步骤、实际结果和预期结果。你还不懂内部代码，也已经能提供有效信息。
如果知道某个相关位置，可以补充给它；还不知道时，就让它先查。准确描述自己看到的现象，比先猜一个技术原因更重要。更深入的排错和恢复，我们放到第四章继续讲。
让反馈可以复现
第六轮：检查这一轮修改，留下下一次的起点
问题处理后，可以发送：
请对照第二轮确认的规则，整理本轮改动：
- 改了哪些文件和位置？
- 我应怎样检查两个档位、重开，以及原有计分和碰撞？
把最终采用的规则和运行方式补到项目记录中。然后自己按清单试玩，看一下工具的变更视图，保存一个可用版本。重开正确、两档清楚、原有玩法仍正常，这一轮就有了可以留下来的结果。
再记下一项最想继续改的地方。例如：“想增加暂停，但还没确定结束后能否继续。”下一章就带着这项需求往下走。
这六轮对话做了什么
回看开头，你只有一句“让它更适合新手”。现在我们已经有了具体规则、对应代码、一份方案、可以试玩的改动，以及明确反馈问题的方式。
不必每次都完整发送六轮。很小的修改可以合并，没想清楚的地方可以多讨论一轮。重要的是知道当前这条消息要推进什么，以及拿到结果后怎样接下一步。
想练习的话，可以把“慢速档”换成自己的一个需求，先写出最初那句愿望，再写下一轮准备发给 Agent 的话。看看你补充了哪些决定，哪些信息仍需要它帮助调查。
PS｜这几个词分别指什么
PS 1：工作目录与入口文件。 在这个练习中，
snake-lab是项目文件夹，也是选给 Agent 的工作目录；index.html是浏览器打开游戏的入口。前者回答“这次在哪个项目里工作”，后者回答“从哪里运行作品”。真正需要修改的位置，要按当前实现查找。
PS 2：上下文。 上下文是模型当前实际拿到、能用来处理任务的信息，比如这轮要求、对话内容、已经读取的代码和工具返回结果。选中项目文件夹，表示 Agent 有了定位和读取文件的起点；模型实际收到的文件内容，才属于本轮可用的信息；文件路径只是帮助定位的线索。第一轮让它查看项目，第二轮补充玩法决定，都是在给当前任务补上需要的信息。
从路径，到真正读懂
PS 3：先讨论与计划模式。 “先给方案、暂时不改文件”是一条对话要求。有些工具还提供专门的计划模式，可以先在该模式中调查和讨论，再切换到执行。具体模式能做什么，按工具本身的说明理解。
PS 4：分步推进与变更。 一步最好对应一个能运行、能检查的小结果。变更视图里的 diff 展示本次文件差异；第二章先用它了解改动范围，第四章再讲版本与恢复。
需要时回看项目位置、入口与上下文；具体界面操作可以查 ZCode 的文件查看与引用说明。
停一下，检查自己的理解
RECALL / 一分钟回忆
先凭自己的理解选一项，再看解释。