提示与反馈循环

提示的难点不在措辞，而在验收：你得先说清「怎么算做完」，agent 才可能自己跑到做完。把它当实习生带——细活交给它，方向由你给，偶尔做错要纠正。

规格的粒度

课上的示例把三件事塞进了一句话：改成 CLI、用 argparse、通过类型检查。目标、手段、验收齐全，模型不需要猜你的偏好。

两种失败方向：

• 太细：你在替它写代码，只剩打字外包
• 太粗：它朝自己想象的方向跑偏，回来还得重来

验收最好能一条命令跑出来。功能正常、体验流畅 这类词无法判定，模型只能自行解释，最后你拿到的是它认为的「正常」。需求大就切成一步一问，每步看到结果再决定下一步。

弱提示	强提示
优化一下这个脚本	用 argparse 接收 URL，输出只保留绝对链接
修一下报错	跑 pytest tests/test_api.py，让它全绿
重构这个文件	拆出 parse() 与 render()，行为不变，测试不改
加个日志	在 main() 入口打一条结构化日志，字段含 run_id

只描述感受的提示同样难判定：这个函数太长了 没说清要拆文件、拆函数还是只改名，它会挑最省力的那种理解。

用反馈纠偏

Agent 支持多轮对话，也支持中途打断。发现它开始改无关文件、反复试同一个错误命令，立刻停下来说清楚方向，比等它跑完再回滚便宜。

反馈要给可验证的锚点：

• 报错原文，不要转述成「报错了」
• 文件和行号，方便它直接跳转
• 正确的命令形式，比如「mypy 就在 PATH 上，别用 python -m mypy」

课程里提到的典型错误是模型硬套习惯用法，调了一个不存在的入口。这类问题一句话就能纠正，前提是你知道正确形式。

贴日志时只留首尾和关键帧。完整的 CI 日志几千行，大部分是无关进度，真正的报错位置反而被稀释。给上下文做减法，和给需求做减法是同一件事。

把测试当契约

TDD 在这里格外有效：先写测试，人工审一遍确认测试表达的是你要的行为，再让 agent 实现到测试通过。测试要能独立跑，依赖网络和时序的用例会反复误报。

测试是唯一能自动判定的信号：没有测试时，「完成」只能是模型的自述。代价是测试本身可能错或太弱，审测试比审实现省力，但不能省这一步。写不出测试通常说明需求还没想清，此时先别让它动手。

一个可直接用的模板

目标：把 download.py 改成命令行程序
约束：只用标准库，参数解析用 argparse，加类型注解
验收：mypy 无报错；对示例 URL 运行输出链接列表
不许：改 tests/ 下已有文件；不要新增依赖
做完：贴出运行命令与实际输出

最后两行值得常备。「不许改测试」堵住最常见的作弊路径，「贴出输出」把自述变成证据。

模板不用长，四到六行就够。超过一屏时模型更容易漏掉后半段，把次要约束挪进 AGENTS.md，让模板只留本次任务专属的部分。

什么时候重开

三种情况该开新对话而不是继续追问：需求已变、上下文被错误结论污染、agent 在同一处绕了三轮。追加纠错会把旧的错误推理留在窗口里，继续影响后面的判断。

重开时给它一份自包含的现状摘要：改了哪些文件、当前报错、下一步目标。这比让它在旧对话里翻找更快，也更省 token。

• 跨天任务把结论写进 NOTES.md、issue 或提交信息，别依赖会话历史
• 重开不是失败，脏上下文里每一轮都在为错误付费
• 重开前先确认需求没变，否则新对话会重复踩同一个坑