我用 Claude Code 的 9 个月：规划先行、标注驱动的工作流

大家好，我把 Claude Code 当成主力开发工具已经快 9 个月了。我最终磨合出的这套工作流，跟大多数人用 AI 编码工具的习惯完全不一样。

普通开发者通常的做法是：扔个 prompt，有时候开个计划模式，修修报错，再循环往复。那些深度玩家则把 ralph loops、mcps、gas towns（这些你还记得吗？）之类的工具拼起来用。结果呢？不管哪种方式，稍微复杂一点的任务就彻底崩盘，一团乱麻。

而我这套流程，只有一个铁律：绝不让 Claude 在我审阅并批准书面计划之前写一行代码。把「规划」和「执行」彻底分开，是我做过的最重要的一件事。它能大幅减少浪费，让我牢牢掌握架构决策，用极少的 token 就能得到远超直接跳码的效果。

整个流程大致循环 1–6 次：

研究 → 规划 → 标注迭代 → Todo 清单 → 实现 → 反馈迭代

第一阶段：深度研究

任何有意义的任务，都从「深度阅读指令」开始。我会让 Claude 先彻底搞懂代码库的相关部分，再做其他事。而且，我一定要求它把所有发现写进一个持久的 Markdown 文件，而不是只在聊天里随便说说。

典型提示示例：

read this folder in depth, understand how it works deeply, what it does and all its specificities. when that’s done, write a detailed report of your learnings and findings in research.md

study the notification system in great details, understand the intricacies of it and write a detailed research.md document with everything there is to know about how notifications work

go through the task scheduling flow, understand it deeply and look for potential bugs… keep researching the flow until you find all the bugs… when you’re done, write a detailed report of your findings in research.md

注意这些关键词：「deeply」「in great details」「intricacies」「go through everything」。这些不是废话。没有它们，Claude 就会浅尝辄止，只看函数签名就觉得自己懂了。你必须明确告诉它：表面阅读绝对不行。

写出来的 research.md 是整个流程的关键。它不是给 Claude 留作业，而是给我自己的「审查界面」。我可以仔细读一遍，确认它真的理解了系统，在开始规划前就把误解纠正掉。如果研究阶段错了，后面的计划和实现全都会错——这就是典型的「垃圾进垃圾出」。

AI 辅助编程里最贵的失败，往往不是语法错或简单逻辑 bug，而是写出了「局部能跑、整体会炸」的代码：比如忽略了已有的缓存层、迁移没遵循 ORM 规范、API 端点重复了别处的逻辑……研究阶段能把这些隐患全部扼杀在摇篮里。

第二阶段：制定详细计划

审阅完 research.md 后，我会要求生成一份独立的 plan.md 详细实现计划。

示例提示：

I want to build a new feature that extends the system to perform . write a detailed plan.md document outlining how to implement this. include code snippets

the list endpoint should support cursor-based pagination instead of offset. write a detailed plan.md for how to achieve this. read source files before suggesting changes, base the plan on the actual codebase

计划文档通常会包含：详细方案说明、关键改动的代码片段、涉及的文件路径、各种考虑和权衡取舍。

我不用 Claude 自带的计划模式（体验一般），而是坚持用自己的 Markdown 文件。这样我能在编辑器里随意编辑、加注释，它还能永久留在项目里，成为真实文档。

一个小技巧：对于有优秀开源参考的特性，我会把参考代码一起发给 Claude。比如我想加 sortable IDs，就会贴一段做得特别好的开源实现，然后说：“这是别人实现 sortable IDs 的方式，请参考这个写一份 plan.md，说明我们如何采用类似方案。” 有具体参考时，Claude 的规划质量会高出一个档次。

标注迭代循环（我贡献价值最多的环节）

这是我工作流里最独特、也最有价值的部分。

流程大概是：

Claude 输出 plan.md → 我在编辑器里审阅 → 直接加行内笔记 → 发回给 Claude 更新文档 → 重复 1–6 次 → 满意后要 Todo 清单

计划出来后，我打开编辑器，直接在文档里加注释。这些注释可以纠正假设、否决方案、增加约束，或者注入 Claude 不知道的领域知识。

真实笔记举例：

• “use drizzle:generate for migrations, not raw SQL” —— 领域知识，Claude 不知道
• “no — this should be a PATCH, not a PUT” —— 纠正错误假设
• “remove this section entirely, we don’t need caching here” —— 直接否决方案
• “the queue consumer already handles retries, so this retry logic is redundant. remove it” —— 解释为什么删掉
• “this is wrong, the visibility field needs to be on the list itself… restructure the schema section” —— 整个章节重构

加完笔记后，发回给 Claude：

I added a few notes to the document, address all the notes and update the document accordingly. don’t implement yet

这个「don’t implement yet」非常关键。没有它，Claude 一觉得计划差不多就会直接跳去写代码。而我必须亲自说「可以了」才行。

为什么这么有效？因为 Markdown 文件成了我和 Claude 共享的可变状态。我可以按自己的节奏思考，在精确的位置写下意见，而不用在聊天里长篇大论解释。整个计划是一个结构完整的规格说明，我能整体审阅。相比之下，聊天记录要翻半天才能理清思路，plan.md 完胜。

三轮标注迭代，就能把一份泛泛的计划变成完美贴合现有系统的方案。Claude 很擅长理解代码、提出方案、写实现，但它不知道我的产品优先级、用户痛点、以及我愿意接受的工程权衡。标注循环就是我注入个人判断的通道。

Todo 清单环节

开始实现前，我一定会要求加一份细粒度的任务拆分：

add a detailed todo list to the plan, with all the phases and individual tasks necessary to complete the plan - don’t implement yet

这份清单成了实施过程中的进度追踪器。Claude 每完成一项就打勾，我随时打开 plan.md 就能一眼看出进度，尤其适合长达几小时的会话。

第三阶段：机械执行

计划彻底 OK 后，我发出标准的实现指令（我几乎每次都复用这段话）：

implement it all. when you’re done with a task or phase, mark it as completed in the plan document. do not stop until all tasks and phases are completed. do not add unnecessary comments or jsdocs, do not use any or unknown types. continuously run typecheck to make sure you’re not introducing new issues.

这句提示把所有关键点都封装好了：

• 全部实现，不挑三拣四
• 在 plan.md 里打钩作为进度真源
• 不中途停下来等确认
• 保持代码干净、不加多余注释
• 严格类型 + 持续 typecheck

到我说「implement it all」的时候，所有决策都已经定好、验证过。实现阶段就变成纯机械工作——这正是我想要的。创造性工作已经在标注循环里完成了，执行就应该无聊且可靠。

实现过程中的反馈

Claude 开始执行后，我的角色从架构师变成监工，提示也变得极简。

通常就是一句：

• “You didn’t implement the deduplicateByTitle function.”
• “You built the settings page in the main app when it should be in the admin app, move it.”

前端部分迭代最频繁，我会在浏览器里测，然后快速反馈：

• “wider”
• “still cropped”
• “there’s a 2px gap”

视觉问题我还会直接附截图——一张错位的表格截图，比描述一千字都管用。

我还经常引用现有代码：

“this table should look exactly like the users table, same header, same pagination, same row density.”

这比从零描述设计要精准得多。成熟代码库里的大多数新功能，都是现有模式的变种，指向参考文件就能把隐含要求全部传达到位。

如果方向跑偏了，我不会一点点 patch，而是直接 git revert，然后重新收窄范围：

“I reverted everything. Now all I want is to make the list view more minimal — nothing else.”

保持在驾驶座上

虽然执行交给 Claude，但我从不给它完全的自主权。大部分关键决策都在 plan.md 里由我主导完成。

Claude 有时会提出技术上正确、但对项目不合适的方案：过度工程化、改动公共 API、选了复杂方案而简单方案就够……我有整个系统的上下文、产品方向、工程文化，它没有。所以我会在以下场景主动干预：

• 逐条 cherry-pick：“第一个用 Promise.all 就行，别搞复杂；第三个提取成函数；第四、第五个忽略，太复杂不值得”
• 砍范围：“把下载功能从计划里删掉，现在不做”
• 保护接口：“这三个函数的签名不能变，让调用方适配”
• 技术偏好：“用这个库的内置方法，别自己写”

Claude 负责机械执行，我负责所有判断。计划负责大决策，实现中再做小调整。

单次长会话运行

我喜欢把研究、规划、实现全部放在一次长会话里完成：先深度读文件夹，三轮标注迭代，然后一口气实现到底。

很多人说上下文窗口到 50% 后性能会衰退，但我完全没遇到。因为到「implement it all」时，Claude 已经在整个会话里不断加深理解：研究阶段读文件、标注循环完善心智模型、吸收我的领域知识。上下文满的时候，自动压缩也能保留足够信息，而 plan.md 这个核心 artifact 会完整保留，我随时可以指向它。

一句话总结我的工作流

深度阅读 → 写计划 → 反复标注直到完美 → 让 Claude 一口气执行到底，边写边 typecheck。

没有花哨的系统提示，没有复杂的 hack，只有一条纪律分明的流水线：研究防止无知修改，计划防止错误修改，标注循环注入我的判断，实现命令让它不被打断。

试试这套工作流吧。你会惊讶地发现：没有一份经过标注的 plan.md 坐在你和代码之间，你以前是怎么用 coding agent 把东西做出来的。欢迎评论区分享你的经验～

（完）