让AI写代码不再翻车
Claude Code工作流实战指南
本文是对他人博客文章的深度分析与解读，内容基于原作者九个月的实践经验整理而成。（页尾提供原文链接）
最近有一篇关于如何使用 Claude Code（Anthropic的AI编程助手）的文章在开发者圈子里传开了。作者是一位已经重度使用Claude Code九个月的开发者，他分享了一套与AI协作的独特工作流。
这套方法的核心非常简单：在你审核并批准书面计划之前，绝不要让Claude写代码。
但背后的思考却极其深刻，几乎颠覆了我们以往对AI编程助手的认知。
这篇文章虽然面向的是Claude用户，但其中的思想完全可以迁移到任何AI编程工具（GitHub Copilot、Cursor、通义灵码等）。今天，我就用普通开发者都能听懂的大白话，深度剖析这套工作流的每个环节，并告诉你为什么它有效，以及如何在自己的项目中落地。
01 为什么需要一套新流程？
AI的"聪明"和"愚蠢"只有一线之隔
先来聊聊痛点。很多人用AI写代码时都有过这种经历：你给AI一个任务，它很快生成了一大段代码，看起来逻辑清晰、注释到位。你满心欢喜地把它集成到项目里，结果发现——
- 它忽略了你缓存层的存在，自己又实现了一套缓存
- 它修改了一个公共函数的签名，导致其他十几个模块全部报错
- 它不知道你项目的潜规则、历史包袱、业务优先级
AI不是故意的，它只是"无知"——它看到的只是你给它的那几个文件，然后根据训练数据里的"常见做法"给出一个看似合理的答案。可现实是，一个在真空中完美的实现，放到现有系统里可能就是一场灾难。
文章作者敏锐地抓住了这个矛盾，并设计了一套流程，把AI的"快速生成能力"和人类的"深度判断能力"有机结合起来。下面我们就一步步拆解这套流程。
02 第一步：研究（Research）
让AI先"读书"，再"说话"
传统做法
打开聊天框 → 输入"帮我写个用户登录功能" → AI开始输出代码
正确做法
给AI任务 → 深入阅读代码库 → 写详细研究报告
"深入阅读这个文件夹，深入了解它的工作原理、功能以及所有具体细节。完成后，写一份详细的学习和发现报告，research.md"
注意里面的关键词："深入""细节极其详尽""复杂细节""逐一审视"。这些不是空话，而是让AI进入深度理解模式的开关。
为什么要写成书面报告？
对AI来说：写报告的过程强迫它组织语言，把理解固化成结构化的文本
对开发者来说：这份报告是你检查AI理解是否正确的唯一窗口
很多AI生成代码的问题，根源都在于AI对现有系统理解不够。研究阶段就是要把这些隐患扼杀在摇篮里。
03 第二步：规划（Plan）
让AI拿出施工图纸
研究完成后，作者会要求AI基于研究写一份详细的实施计划。注意，这里仍然不允许写代码，只允许写计划。
"列表端点应支持基于光标的分页，而非偏移。写一份详细的 plan.md 来实现这一点。建议修改前先阅读源文件，计划基于实际代码库"
这份计划应该包含：修改哪些文件、每个文件怎么改、代码片段示例、需要考虑的边界情况、潜在权衡等。它就像一份施工图纸，把最终要实现的样子画得清清楚楚。
实用技巧：如果在开源项目里看到好的实现，直接把那段代码贴给Claude，说"这是别人实现可排序ID的方法，写个计划说明我们如何采用类似方法"。这相当于给AI一个参考标杆。
04 第三步：注释循环（Annotation Loop）
这是整个流程的灵魂！
计划写好后，作者会在本地编辑器中打开plan.md，直接往里面添加内联笔记：
"这个参数应该是非可选的"
"不要用缓存，我们不需要"
"队列消费者已经处理重试，所以你的重试逻辑是多余的"
"可见性字段应该在列表本身，而不是单个项目上"
"暂时不实施" 这句话至关重要！作者坚持要经过 1到6次 这样的注释循环，直到计划完全符合预期。
注释循环的本质是把人类的经验注入到AI的解决方案中。AI知道怎么写代码，但它不知道你的产品优先级、技术偏好、未来扩展方向。这些隐性知识只能由你来补充。
05 第四步：待办清单（Todo List）
把计划拆成可执行的任务
当计划最终定稿后，作者会让Claude把计划拆解成一个细致的待办清单：
这个清单有两个作用：一是让你随时看到进度；二是强迫AI把大的改动拆分成小的步骤，避免遗漏。
06 第五步：实施（Implementation）
让AI当一个"无聊的执行者"
现在，终于可以写代码了：
"全部实施。完成某个任务或阶段后，在计划文件中标记为已完成。直到所有任务和阶段完成，不要停止。不要添加不必要的注释或 jsdocs，也不要使用 any 或未知类型的。持续运行 typecheck，确保没有引入新问题。"
"全部实施"
按计划做，不要自己加戏
"标记为已完成"
计划就是进度看板
"直到完成不要停止"
不要中途停下来问我
"不要用any"
保持类型安全
作者希望实施过程"无聊"。因为所有创造性的决策已经在注释循环中完成了。当实施变得无聊，意味着风险已经提前消除。
07 第六步：反馈与迭代
用简短指令微调
当Claude开始实施后，角色从"建筑师"变成了"监工"。用非常简短的指令修正方向：
"你没实现 deduplicateByTitle 功能。"
"你在主应用里建了设置页面，应该在管理员应用里，移过去。"
对于前端样式问题，甚至可能直接截个图说"这里再宽一点"
如果发现方向完全错了，直接 git 回退，然后缩小范围重新开始："我把一切都恢复了。现在我只想让列表视图更简洁——别无他意。"
✨ 核心原则总结
计划与执行分离
就像盖房子，必须先有图纸，再动工，而不是一边砌墙一边改图纸。
文档即共享状态
Markdown文件是持久的、可编辑的。你和AI可以轮流在同一个文档上修改。
人类主导，AI执行
AI可以是个优秀的执行者，但绝不是一个好的决策者。
把隐性知识显性化
通过注释循环，把项目中的"潜规则"一条一条写在计划文档里。
🚀 如何开始应用？
从小任务开始练习
选一个功能点，尝试按这套流程走一遍，体验"先计划后执行"的节奏。
把提示词模板化
把提示词保存成模板，每次使用时稍微修改即可。
拥抱Markdown
用普通的Markdown文件，可以git提交，成为项目的一部分。
练习"注释思维"
直接在文档里写下修正，逼自己把模糊的感觉转化为清晰的文字。
别怕返工
注释循环可能需要好几轮，每轮循环都是一次风险排除。
📝 写在最后
❌ 对话驱动
我问一句，AI答一句。适合解决小问题，但对于稍大的功能，很容易陷入循环。
✅ 文档驱动
所有重要信息都沉淀在Markdown文件里。当文档定稿后，实施就是水到渠成的事。
AI是工具，而我们是主人。工具越强大，主人就越需要清晰的思考和明确的指令。
下次当你打开AI编程助手时，不妨试试先让它写一份研究计划和设计文档，你来批注修改，再让它实施。相信我，你会惊讶于最终代码的质量，以及整个过程的顺畅。
参考资料
本文是对原作者博客文章的深度分析与解读，内容基于原作者九个月的Claude Code实践经验整理而成。
这篇文章对你有帮助吗？