让 AI 改我的旧代码之前，我先立了三条规矩

我有一个写了两年、没人review、注释全靠心情的旧项目。上个月决定用 AI 编程工具把它重构一遍。第一次尝试以惨败告终——AI 非常高效地把我手写的存储适配层判定为「冗余封装」，大刀阔斧地内联掉了。它没错，从代码本身看那层封装确实薄；但它不知道那是我故意留的迁移出口。

痛定思痛，第二次开工前我立了三条规矩。这次顺利多了。

规矩一：先讲历史，再谈改动

现在每次开新会话，我第一件事不是提需求，而是花五分钟把项目的「考古笔记」喂给它：哪些模块是故意绕的弯，哪个函数看着废但不能删，哪段注释是血泪教训。这些信息代码里没有，AI 又恰恰最擅长把「看不懂」重构成「看不懂但更短」。

规矩二：小步提交，人先看后跑

第一次失败还有个原因：我让它一口气改完一整个模块再一起看。改动量一大，review 就变成走马观花。现在规矩是每次只改一个函数级别的单元，我看懂了 diff 才允许跑测试，测试过了立刻提交。慢了三倍，但再也没有「惊喜」。

规矩三：让它写「为什么」，不只是「做了什么」

AI 写的 commit message 一直很好，但好得空洞：「Refactor storage layer for clarity」。现在我要求每个改动附一句「为什么这么改、不改会怎样」。神奇的是，逼它写理由的过程经常让它自己发现方案有问题——有一次它写着写着改口说「其实原实现更稳妥，建议保留」。AI 给自己 code review，居然是成立的。

一点感受

用 AI 改代码，最大的风险从来不是它写错，而是它把「能跑」和「对」混为一谈，而你在它流畅的输出面前放弃了追问。三条规矩说到底就一件事：别把方向盘完全交出去，你可以让它开，但路线得你批。

旧项目重构还在进行中，等全部完成我再写一篇复盘，对比一下前后的代码量——我猜会变多，因为规矩一逼着我把考古笔记全写进注释了。这不一定是坏事。