让 AI 改代码之前，先让它读懂代码

引言

写代码的人大概都有过这种时刻：一段逻辑越看越别扭，想重构成更清晰的样子，但一想到"牵一发而动全身"，手就停在半空。

我把这种活儿交给 CodeArts 的代码智能体有一段时间了。坦白说，它确实能大幅缓解这种犹豫——但前提是，你得用对方式。用得不对，它会把本来能跑的代码改成一个看起来更"高级"、实际上处处是坑的版本。

这篇就聊聊我在"AI 辅助代码审查与重构"这件事上的一点心得。

一、先读，再改

让 AI 改代码，最常见的错误是直接丢一句"帮我优化这个文件"。它确实会改，但改的是它"以为"的意图，而不是你真正想要的。

我的做法是分两步：先让它读懂，再让它动手。

具体来说，我会先让它通读相关模块，回答几个问题：

• 这个模块对外暴露了什么？（函数签名、返回值、副作用）
• 谁在调用它？依赖关系是怎样的？
• 哪些地方看起来可疑（重复逻辑、隐藏的耦合、边界没处理）？

这相当于让它先建立一份"地图"。等它对结构有了把握，再谈改动，方向就不容易跑偏。很多时候，光是这一步，它就能指出我自己没注意到的重复代码或失效分支。

二、审查：一位不会疲倦的第二双眼睛

重构的第一步其实是"看懂哪里值得改"。这时候 AI 特别适合扮演审查者。

它不会因为"这是我自己写的"而护短，也不会因为深夜犯困而走神。我通常会让它从几个角度过一遍：

• 一致性：命名风格、错误处理方式是否统一？
• 健壮性：空值、异常、并发、边界输入有没有漏？
• 可维护性：有没有过长的函数、过深的嵌套、被复制粘贴的代码？

重要的是，让它给出理由和位置，而不是只给结论。比如"这个函数同时做了校验和持久化两件事，职责不单一，建议拆分"——这种带定位、带依据的意见，我才会认真考虑。

三、重构：小步走，每一步都能回头

审查之后是真正危险的部分——动手改。我的原则只有一条：小步走，每步可回退。

我不会让它一次性重写整个模块。更稳的节奏是：

1. 先做纯机械、零风险的改动，比如重命名、提取常量、拆函数；
2. 每完成一步就确认行为没变；
3. 再做需要判断的改动，比如调整结构、引入抽象。

同时我会给它划死红线，明确写进指令里：

• 对外接口和返回值不能变；
• 现有行为（包括那些看起来"多余"的分支）不能删，除非我确认可以；
• 保持改动粒度小，方便我用版本控制随时回退。

有了版本控制这层安全网，我就敢让它多试几种改法——大不了退回上一个提交重来。

四、几条我踩出来的协作原则

几个具体的技巧，供参考：

• 一次只做一件事。 "同时重构结构、改命名、加日志"往往改出问题也没法定位。拆开做，每次只解决一个目标。
• 让它解释自己的改动。 改完后，让它逐条说明"为什么这样改"。解释不清或不合理的地方，正是风险所在。
• 警惕过度设计。 AI 有时会引入不必要的抽象层、设计模式，把简单问题复杂化。简单能跑，胜过高大上。
• 保留人的判断权。 它擅长扫描和机械劳动，但"这段代码该不该改、改到什么程度"是人的决定。

五、它不该替你决定的事

AI 重构有一个隐蔽的风险：它会"顺手"抹掉那些没写进注释、只存在于团队默契里的约定。

比如某个"看起来多余"的判断，可能是因为上游数据真的会脏；某个不规范的命名，可能被外部脚本依赖着。它不知道这些，就会"好心"删掉。

所以，凡是涉及业务语义、外部契约、历史包袱的改动，我都会亲自过一遍。把 AI 当作高效的执行者和审查者，但最后的守门人仍是我自己。

结语

用 AI 做代码审查和重构，最大的价值不是"写得快"，而是"想得全"——它能不厌其烦地把角角落落看一遍，帮你把藏在深处的坏味道翻出来。

但它终究是一把很好用的工具。真正决定一次重构成不成、值不值得的，还是坐在屏幕前的那个人对代码的理解和判断。把它用成得力的副手，而不是替你拍板的老板，大概就是最好的姿势。