主循环：探索 → 计划 → 实现 → 验证 → 提交

6.1 即兴发挥是最贵的用法

前面五章都是零件，这一章把它们装成一条可以每天重复的流水线。

新手的典型用法是”想到哪说到哪”：先让它改一点，看效果不对再说一句，再改一点。这条路径的问题不是慢，而是没有任何一个点可以判断”做完了”——于是任务会一直拖到你累了为止。

官方最佳实践页给出的循环是：探索 → 计划 → 实现 → 提交。结合前面几章，这里把”验证”显式拆出来，因为它是最容易被跳过、也最不该被跳过的一环。

目标是让它建立对问题的认识，而不是急着动手。

不要改任何代码。先搞清楚：用户切换账号后还能看到上一个账号的订单，
这个数据是从哪一层带过来的？把涉及的文件和调用链列出来。

关键词是”不要改任何代码”。如果任务涉及大量文件，按第 5 章的做法交给子代理去读。

按 Shift + Tab 切到计划模式，或者启动时指定：

claude --permission-mode plan

在这个模式下它只读不写，产出一份方案。然后你做三件事：

什么时候可以跳过计划？ 官方文档说得很直白：计划模式本身有开销，如果你能用一句话描述这个 diff，就跳过它。改一个常量、加一行日志，不需要走这一步。

方案确认后，把自动化档位调到 acceptEdits 或 auto，让它执行。这一段的纪律是第 3 章那条：一次只推进一步，每一步都要有可判断的产出。

如果计划里有五步，逐步放行，而不是说一句”按计划全做完”。

要求证据，而不是结论。三种表述的效果依次递增：

❌ 做完了吗？
⚠️ 确认一下测试通过了
✅ 跑 npm test，把完整输出贴出来。如果有失败，先不要修，告诉我失败的是哪几个用例

官方文档给出了一条从轻到重的”验证阶梯”，你可以按任务重要性选一档：

第 4 档还有一个变体很好用：开一个新会话去 review 上一个会话的 diff。官方给的理由很有说服力——新会话不会偏袒它自己刚写的代码。

不过官方也给了配套的警告：如果你让一个审查者”去找问题”，它一定能找出一些。要限定它只报正确性问题和需求缺口，否则你会收获一堆过度工程的建议。

把这次改动提交，commit message 说明修的是什么问题和为什么这样修。
然后开一个 PR，描述里包含复现步骤和测试结果。

一个建议：频繁地小提交。每个提交都是一个存档点，出问题时你回退的粒度就是提交的粒度。这也是多位实践者共同强调的一点——把版本控制当作和 AI 协作的基础设施，而不是收尾工作。

假设任务是”修复切换账号后订单串号的问题”：

注意”先让测试失败，再让它通过”这个顺序。它的价值不是形式，而是证明这个测试真的在测你以为的东西——一个从来没红过的测试，可能只是恒真。

官方文档列出了一组失败模式，配上对策就是一张排错表：

你现在的成果：你有了一条可以每天重复的流水线。到这里，日常使用的核心内容已经完整了；接下来的章节是把它从”你会用”变成”你的团队会用”。