让AI写代码更靠谱的秘诀:先规划,后记录,再验证

用 Claude Code 或者 Cursor 开发功能时，很多人的体验是这样的：起手式很帅，几行自然语言生成一个雏形；但两轮对话之后，代码开始“鬼打墙”，新开一个 Session（会话）还得费劲巴拉从头解释业务逻辑。最后，你花在修 Bug 和解释上下文的时间，比自己手写还长。

痛点在哪？在于你把 AI 当成了“自动贩卖机”——投币（Prompt），出货（代码）。

但 Drew Wilson 最近分享的一套工作流直接指出了真相：要把 AI 当作一个需要做交接（Handover）的初级工程师来管理。

这套方法论不搞虚的，主打一个“防呆设计”和“长期记忆”。简单说，就是通过三个核心步骤，让你的 AI 队友不再“失忆”，也不再乱写。

1. 第一步：按住它的手，先别急着敲代码

很多时候 AI 写出 500 行废代码，是因为它把你的“大概意思”脑补成了“错误方案”。

Drew 的建议非常反直觉但有效：强制 AI 先写 Plan（计划），再动手。

别小看这一步。当你要求它：“在写代码之前，先列出你的实现计划”时，你其实是在做一次低成本的“需求对齐”。如果它的计划里出现了逻辑漏洞，你用两句话就能纠正；但如果它直接把错误逻辑写成了几百行代码，你要改的成本就是指数级上升。

• •话术示例：“阅读当前代码库，针对这个需求，先给我一个详细的 Implementation Plan，不要写代码。”

2. 第二步：文档即记忆，拒绝“阅后即焚”

这是这套工作流的灵魂。

代码写完了，还没完。必须要求 AI 更新一份命名清晰的文档。

这就好比人类团队里的“技术文档”或“交接文档”。没有这份文档，你下次新开一个 Session，AI 面对的就是一个陌生的代码仓库，它得重新扫描、重新猜测。但有了文档，它就是项目的长期记忆（Long-term Memory）。

甚至，你可以把这个动作标准化。每当 Agent 完成任务，最后的指令永远是：“根据刚才的变动，更新相关文档。”

3. 第三步：双向校验，防止“精神分裂”

AI 有时候会偷懒，代码改了，文档没改；或者文档写得天花乱坠，代码完全没动。

所以，最后一步是一致性校验。让它自己检查：“现在的代码实现，和文档里的描述一致吗？”

这看似繁琐，实则是为了下一次迭代铺路。文档如果不准，下一个 Session 的 AI 就会被误导，产生新的 Bug，最后变成无限套娃。

4. 高阶玩法：如何优雅地管理上下文？

有人担心：“文档写这么多，Context Window（上下文窗口）爆了怎么办？”

其实大可不必。你不需要让每个新 Agent 读完《红楼梦》一样的全量文档。你只需要告诉它：“读取与你当前工作相关的文档”。现在的模型足够聪明，知道去哪里找答案。

社区里还有几个“黑话”级别的补充技巧，建议直接抄作业：

• •文件头“作弊条”：在核心代码文件的开头，用注释写 100 行左右的“架构说明”或“注意事项”。Agent 读取文件时，顺带就吃透了上下文，省去了你额外解释的 Token。
• •CHANGELOG 必须有：维护一个变更日志，记录“改了什么”和“为什么改”。这不仅仅是给 AI 看的，更是给你自己看的。后续会话扫一眼，就能接上断点。
• •Claude.md 索引：建一个简单的索引文件，列出文件名和对应的功能简介。这相当于给 AI 一张“地图”，帮它在新会话里精准拉取需要的文档。
• •主动暴露无知：在 Prompt 里加一条规则——“动手前先问清楚所有不确定的问题，严禁自作主张做强假设（Strong Assumption）”。这一条能帮你省下 50% 的返工时间。

5. 写在最后

这套方法的本质，其实是工程管理能力的下放。

代码是会过期的（Version Rot），但良好的文档结构能让知识在不同的 Agent Session 之间持续流转。对我们人类来说，Review 一个有良好文档的系统，也比去啃生肉代码要轻松得多。

别再觉得写文档是“额外步骤”了。在 AI 编程时代，文档就是你的 Prompt 库，就是你的护城河。