AI编程诀窍003:没想好就敢让AI改代码?等着返工

谋定而后动。

一句话结论：先让 AI 助手进入只读模式，把想清楚的方案摆上桌，再允许它碰你的代码。

常见错误

你把报错堆栈直接贴给 AI，别的什么也没说。

它立刻开始改多个源文件，改到一半才发现根本不懂你的整体架构。

结果，旧问题没修好，反倒多了几个新问题。接下来一小时，你都在手动回滚它那一团糟的改动。

解决的问题

AI 会动那些本来不需要动的代码。

它还没读完相关函数，就急着开始敲代码。

它连 package.json都没看，就假设某个库已经装好了，然后一本正经地胡说八道。

改动太大，看 diff 的时候你看得头皮发麻。

具体怎么做

如果你的工具有「计划模式/询问模式」，直接打开它。

没有的话，就在提示词开头加一句元指令：

先读完这些，等我下一步指示，现在不要改任何文件。

让 AI 去读具体的文件，并把它理解的逻辑讲给你听。

然后，让它给出一个分步骤的执行计划，等你点头再动手。

你觉得方案没问题了，再告诉它：「现在执行第一步。」

这样做的好处

准确率更高：AI 只负责想「为什么」的时候，推理反而更稳。

主动权在你手里：逻辑错误还没进代码库，就被你拦下来了。

省 token：少了「写错—回滚—再写」的试错循环，花的钱和流量都更少。

你自己也更清楚：你不仅知道怎么修，还知道为什么要这么修。

为什么有效：AI 也手比脑子快

模型天生爱「动手」多过「动脑」，因为做点什么是它最有用的感觉。这其实就是冲动式编程。

你强行给它加一个只读阶段，等于让 AI 先扮演顾问，再扮演开发者。资深工程师遇到复杂问题，也是这么干的：先看、再想、最后才改。

这种模式也叫只读式提示（Read-Only Prompting），或者叫顾问模式。叫法不重要，关键是顺序：先当军师，再当苦力。

提示词范例

反面提示词

用这个堆栈信息，把 Kessler Syndrome Monitor 组件里的概率预测器修好。

推荐提示词

先读 @Dashboard.tsx 和 @api.ts，不要写代码。分析这个堆栈信息，找到问题后先给我讲清楚。然后写一份 Markdown 修复计划，范围只限 REST API。[激活代码模式]写一个能复现这个错误的失败测试。应用修复，并持续跑测试，直到全部通过。

注意事项

简单任务用不着这么大张旗鼓。

AI 给出的计划，你必须自己认真看。

它照样可能在计划里胡说八道，所以方案也得验。

局限

这招适合重构和复杂需求。

改个 CSS 间距、修个拼写错误，用它就显得慢了。

有些 AI 又过于谨慎，改什么都得先问你。耐心点，习惯了就好。

相关诀窍

小步提交，每次只做一个最小改动。

结论

想清楚了再让 AI 动手，反而省时间。

你得先逼它做你的架构师，再允许它做你的施工队。这个简单的顺序，能帮你少加好几个小时的班。

古人云：「工欲善其事，必先利其器。」真正称手的「利器」，是你按下暂停键的那一下；插件再花哨，也替不了这一步。

适用说明：这条做法属于「半自动」实践，难度定位进阶——它帮你把 AI 的冲动按住，但最后那一下决定，永远得你自己拍板。