给 AI 编程助手立三条规矩：先读代码，再改代码

背景

把改代码交给 AI 编程助手后，最常见的翻车不是它写不出代码，而是它在没读懂上下文的情况下动手：改了 A 处，断了 B 处的隐含约定；补了一个函数，却与项目里已有的工具函数重复。问题不在模型能力，而在任务下达方式——人默认助手已经理解了项目，助手默认人的指令就是全部上下文。

我现在的做法是：每次开任务前，先给助手立三条规矩，写进任务描述里，而不是事后返工时再补。

规矩一：先读，再改

明确要求助手在动手前先读三类东西：要改的文件本身、直接调用它的上下游、以及相关的测试或配置。读完后用一两句话复述它理解的现状，再开始改。

这一步的价值不在“读”本身，而在对齐：如果它对现状的复述是错的，人在动手前就能纠正，成本是一句话；如果等它改完才发现理解错了，成本是一次返工加一次回归验证。

规矩二：改动范围写死

指令里写明“只改这一个文件 / 只动这个函数 / 不许顺手重构无关代码”。没有这条约束，助手很容易把一次小修扩成一次大扫除：顺手统一命名、顺手升级依赖、顺手删掉它认为无用的代码——而每一次“顺手”都是一次未经评审的风险。

范围写死还有一个好处：diff 变小，评审变快。改动越小，出了问题越容易定位和回滚。

规矩三：改完要自证

要求助手在交付时同时给出三样东西：改了什么（文件与行级摘要）、为什么这样改（对应哪个需求或故障）、以及怎么验证（跑了哪条命令、结果是什么，有没有回归影响）。

“自证”不是不信任，而是把验证成本前移。助手自己跑一遍测试、贴出结果，人只需要复核结果而不是从头验证一遍。如果它说“没法验证”，那本身就是一个信号：说明这次改动缺少可验证的抓手，应该先补测试或复现步骤，而不是直接合并。

取舍与总结

这三条规矩会让单次任务变慢一点：多一次现状复述，多一次验证输出。但它换来的是返工率的下降和 diff 的可控——对需要长期维护的代码来说，这笔账是划算的。

反过来，如果只是一次性脚本、写完即扔的探索代码，就没必要上全套规矩：规矩的强度应该跟着代码的寿命走。寿命越长，约束越严；寿命越短，越可以放手让助手快跑。

一句话总结：把 AI 助手当成一位能力很强但刚入职的新同事——先让它读懂现状、划清边界、交出验证，你省下的返工时间，远多于立规矩花掉的时间。