夜雨聆风你有没有遇到过这种情况：你只是想让 AI 修一个小 bug，结果它代码写得飞快，解释也很认真，最后一看，问题没修干净，旁边还多改了一堆你没让它碰的东西。
你让它优化首页，它顺手改了全局样式；你让它补一个按钮，它顺手重排了半个页面；你让它改一个接口字段，它顺手调整了数据结构。最气人的是，它还会很自信地告诉你：“已经完成。”
我以前真的被这种“已经完成”坑过很多次。后来我才意识到，AI 写代码最容易出问题的地方，不是它不会写，而是它太早开始写。
我给它的其实只是一句模糊愿望：“帮我优化一下”“帮我修一下”“帮我加个功能”。这些话人听了都要追问半天，AI 却经常直接开干。这就是问题。
我现在最怕的不是 AI 慢，而是它太快
以前我也迷信过“AI 写代码很快”。一两分钟给你一大段代码，看起来确实爽。但后来我发现，快有两种。一种是真的快，还有一种是它很快把你带到错误方向上。
第二种更麻烦。因为你后面要花时间看它改了什么、为什么改、有没有破坏旧功能、哪些地方需要回滚。最后算下来，不一定省时间，甚至更累。
我现在判断一个 AI 编程流程靠不靠谱，不再只看它生成代码有多快。我更看三件事：它开工前有没有问清楚，它有没有明确边界，它最后有没有真实验证。这三件事没有，代码写得越快，我越紧张。
为什么我现在让 AI 先采访我
这不是为了搞仪式感，也不是为了把简单事情复杂化。恰恰相反，是为了降低人的负担。
很多人一听 AGENTS.md、CLAUDE.md、CHECKLIST.md、handoff.md，就头大。我也一样。我找 AI 是为了省事，不是为了先写一堆文档给它上课。
但后来我看 Claude Code、Copilot、Cursor、Codex 这些工具的发展，发现大家最后都在绕回同一个问题：AI 写代码不是只缺能力，它更缺上下文。
项目是干什么的？哪些文件不能动？这次任务到底做到哪里？什么情况算完成？失败了怎么办？这些东西你不说，它就会自己猜。而 AI 最大的问题就是，它猜得很自信。
所以我现在不再要求自己先写一堆正式文档。我换了一种更省脑子的方式：让 AI 先当 10 分钟产品经理。它先问我，我回答，它整理，我确认，然后它再当程序员。
这比一上来就写代码稳很多。
这里面有一个很简单的用户心理
人不怕确认，人怕从空白页开始写。
你让我写一份项目说明，我大概率拖着不想写。但你问我“这个项目是做什么的”“哪些文件不能碰”“这次什么算完成”，我通常能答出来。
所以关键不是让人写文档，而是把“写文档”变成“回答问题”。这个动作轻很多，而且 AI 问问题的时候，我自己也会被迫想清楚。
比如我说“优化首页”。AI 反问我：“你说的优化，是视觉、转化率、加载速度，还是信息结构？”我一下就卡住了。但这个卡住是好事。因为它如果不问，可能就直接去改 CSS 了。
我现在会让 AI 先问这 10 个问题
如果你也经常被 AI 写代码返工，可以先不要学一堆复杂方法。就从这 10 个问题开始。我现在经常直接把这段发给 AI：
先不要写代码。 请你先采访我，帮我把这个任务整理清楚。 你需要问清楚： 1. 这个项目是做什么的？ 2. 我这次真正想解决什么问题？ 3. 这次只做哪些事情？ 4. 哪些事情明确不做？ 5. 哪些文件、功能、配置不要碰？ 6. 你需要参考哪些材料？ 7. 最后要交付什么？ 8. 什么情况算完成？ 9. 需要跑哪些验证？ 10. 哪些地方必须停下来问我？ 每次只问 2-3 个问题。 不要一次性把问题全抛给我。 问完以后，先帮我整理成一份任务说明。 我确认后，你再开始写代码。这段话的价值不在于它多高级。它的价值是把 AI 从“马上写代码”，拉回“先搞清楚任务”。只要这一步发生，后面的返工就会少很多。
我一定会补一句：不要擅自扩大范围
这个很重要。因为 AI 特别容易热心过头。你让它修一个问题，它可能觉得旁边代码也不优雅，顺手一起改了；你让它补一个功能，它可能觉得结构不好，顺手重构了。
如果你没提前说，它会以为这是“更好的完成”。但对我来说，这叫越界。
所以我现在一定会加一段禁止事项：
本次任务的禁止事项： 1. 不要做额外重构 2. 不要改动无关页面 3. 不要改生产配置 4. 不要删除历史逻辑 5. 不要顺手优化我没有要求的地方 6. 如果你发现必须扩大范围，先停下来问我这段话看起来很普通，但非常救命。它能防止 AI 把一个小任务做成一个大工程。
验收清单一定要提前写
还有一个坑，我现在非常警惕：AI 做完以后再写验收，很容易变成“为结果找理由”。它已经改完了，再让它总结怎么验证，它当然会倾向于证明自己完成了。
所以我现在要求验收清单必须在开工前出现：
在你开始写代码前，请先生成一份验收清单。 这份清单要包括： 1. 功能验收项 2. 不能破坏的旧功能 3. 需要跑的命令 4. 需要人工确认的地方 5. 如果验证失败，你应该怎么处理 生成后先给我确认。 确认后你再开始执行。 执行结束时，请逐条说明哪些已完成、哪些没完成。这一步防的是“假完成”。AI 说完成不重要，它能证明完成，才重要。我现在宁愿它慢一点，也要它把验证跑出来。如果它跑不了，也要老老实实告诉我为什么跑不了，不要用一句“理论上可以”糊弄过去。
长任务一定要让 AI 写交接
如果一个任务今天做不完，或者你准备换一个对话继续，一定要让 AI 写交接。不然第二天你回来，大概率又要从头解释。
我现在会这样要求：
每一轮工作结束前，请你生成一份交接说明。 里面包括： 1. 本轮完成了什么 2. 修改了哪些文件 3. 每个文件为什么改 4. 已经跑过哪些验证 5. 哪些地方没有完成 6. 当前风险是什么 7. 下一轮应该从哪里继续 如果没有写交接说明，不要声明任务完成。这不是形式主义。这是给下一轮的 AI 留路，也是给我自己留路。我不想每天重新当一遍项目经理，把昨天讲过的话再讲一遍。
我真正想省下来的，是判断成本
很多人用 AI 写代码，只盯着“生成速度”。但我现在更在意“判断成本”。代码生成得快，不代表我轻松。如果我每次都要重新判断它有没有理解错、有没有改多、有没有验证、有没有留下坑，那我其实还是很累。
所以这套流程真正想解决的，不是“怎么让 AI 更能写”，而是怎么让我更容易判断它有没有做对。
项目说明，让我知道它有没有理解背景；任务说明，让我知道它有没有理解目标；禁止事项，让我知道它有没有越界；验收清单，让我知道它有没有完成；交接说明，让我知道下一步从哪继续。
这些东西如果让人自己写，很烦。但让 AI 通过提问生成，就轻很多。
无题
不要让 AI 从写代码开始，让它从提问开始。
这句话听起来简单，但我现在觉得非常值钱。因为它改变的是整个使用顺序。
以前是：我提需求，AI 写代码，我检查返工。
现在是：AI 先提问，我确认任务，AI 再执行，最后按清单验收。
顺序一变，返工就少很多。
最后的最后
我不太相信“一句神 prompt 让 AI 完美干活”。越是复杂的任务，越不应该一句话开工。但这也不代表人要先苦哈哈写一堆文档。
更合理的方式是：让 AI 先问，让 AI 整理，让人确认，再让 AI 执行。
我现在用 AI 写代码前，不是先自己写 AGENTS.md、GOALS.md、CHECKLIST.md。我会先对 AI 说：你别急着写代码，先问我。把我脑子里的东西问出来，整理成你能执行的说明书，然后我们再开工。
这不是为了显得专业，是为了少返工。
— E N D —
