AI写代码总返工？先出方案再动手，返工率直降

为什么AI写代码总在返工？

你让AI“加个分类统计”，它立刻改了七八个地方，连布局都换了——可这不是你要的，想退都不知道从哪退。这是很多人用AI编程时的真实写照：AI理解偏差加上直接输出代码，导致大范围返工。问题不在于AI不够强，而在于跳过了“对齐方案”这一步。

据B站UP主“AI进化论-花生”的分享，一个简单原则能显著减少返工：大一点的改动，先让AI出方案，再让它写代码。

计划模式：让AI先看图纸再动工

装修之前，师傅会先给你看图纸。图纸上改一笔几乎不花钱；墙砌好了再改，就得砸了重来。AI编程同理——代码写出来再推倒重来，代价远高于在方案阶段调整。

主流AI编程工具已经内置了“计划模式”：

• Claude Code：按 Shift+Tab 切到计划模式，或在指令前加 /plan。它会读文件、了解现状，产出一份方案，但不改你的代码。方案写好，它会问你是否照做——你可以批准，也可以让它接着改。
• Codex：输入 /plan，同样先给出执行计划，你看过没问题再让它动手。

不想切换模式也行，一句话就能实现：

先别写代码，先告诉我你打算怎么做。

计划模式（Plan Mode） 是近年来 AI 编程工具引入的一种交互范式：模型在只读状态下遍历项目文件、理解现有代码结构与依赖关系，输出一份结构化执行方案（通常包含改动目标、涉及文件、执行步骤、验证方式），在此期间不产生任何写操作。用户审阅、修订并批准该方案后，模型才进入执行阶段。其技术意义在于把“意图对齐”和“代码生成”两个环节解耦——生成方案的成本远低于生成代码，因此把纠错前置可以显著降低无效 token 消耗与回滚成本。对多文件、跨模块的改动，计划模式还能让模型先建立全局视图，避免边写边改导致的局部最优与风格漂移。

拿到方案，重点看三样

AI给出的方案往往很“丰满”，但你要盯住三件事：

1. 要改哪些文件、分几步——范围是否超出你的预期？AI要改的地方常常比你想的多得多。
2. 每一步做完怎么检查——有没有验证环节，避免改完不知道对错。
3. 有没有它拿不准、需要问你的地方——AI主动提问是好事，说明它在对齐需求。

看到方案里有看不懂的词，别客气，直接问；觉得范围太大，先问一句“为什么”。

验证环节（Verification Step） 指的是方案中为每一步改动配套的可执行检查手段，例如运行单元测试、执行 lint 与类型检查、启动本地服务手动验证页面，或对比改动前后的输出差异。AI 生成的代码往往“看起来对”，但可能引入未使用的依赖、破坏既有接口或遗漏边界条件；如果没有明确的验证点，错误会一路累积到最终运行阶段才暴露，届时定位成本成倍上升。审方案时确认每一步都有对应的检查方式，本质上是在为后续的“逐步汇报”提供判断依据——每步做完能立刻知道对错，而不是等到全部完成才发现方向错了。

范围蔓延（Scope Creep） 是 AI 编程返工的高发原因：模型为了“把事做好”，常顺带重构相邻模块、替换工具库、调整布局或统一代码风格，导致实际改动远超用户预期。由于这些改动往往彼此耦合，用户想撤销其中一部分时很难干净回退，只能整体丢弃或手工挑选。审方案时第一件事就是核对“要改哪些文件、分几步”，把改动边界显式写进方案；一旦发现范围超出预期，应在方案阶段追问理由并要求收窄，而不是等代码落地后再做减法。

怎么改方案，代价最小

方案越早改，代价越小。改方案的正确姿势：

• 直接改：别不好意思，比如“第二步先补做颜色，别动，不要引入新的工具库”。
• 对不确定的地方追问：方案里每个模糊点，都在这里解决，而不是等代码写完。
• 小改动不必出方案：改个文字、换个颜色这种小事，直接说就行，避免流程过重。

批准之后，怎么推进不跑偏

批准方案时，建议加上一句：

就按这个方案做，每做完一步停下来，告诉我结果。

这样AI会按步骤执行，每完成一步汇报一次。中途发现方向不对，就退回去重新对方案，而不是在代码里硬改。

可以直接照抄的两句话：

出方案时：先别写代码，读一下现在的项目，告诉我你打算改哪些文件、分几步、每一步怎么检查，有拿不准的地方先问我。

批准时：就按这个方案做，每做完一步停下来，告诉我结果。

一句话总结

大一点的改动，先看图纸再开工。方案里改一句话，比代码里返工省得多。

下一集预告：同样的规矩每次都要重新交代？可以给项目写一本“说明书”——把约定固化下来，让AI每次开工前先读。