我以为我在帮忙，他以为我在"打脸"。AI 让重构变得太容易了，但它解决不了的，恰恰是最难的那个部分——人。

---

事情是这样开始的

我们组有一个内部管理后台，核心模块是一个表单引擎。这个模块是同事小张三年前搭的，从简单表单慢慢迭代到支持上百个字段、动态联动、多级嵌套的复杂系统。

三年下来，这个模块膨胀到了大几千行——一个文件。没有拆分，没有类型定义，变量命名从 data1 到 tempArr2 应有尽有。

我不是在黑小张。三年前的代码放到三年后看，谁的都一样。问题是，最近产品要加新的联动规则，我负责这个需求，改了两天——每次改完一个地方，另一个地方就莫名其妙地坏掉。

一个周末，我"手贱"了

周五下班前有点烦躁，打开 Codex，把这个文件丢了进去："帮我重构一下，拆成合理的模块结构，加上 TypeScript 类型。"

大约二十分钟，Codex 给出了完整的重构方案：一个大文件拆成 6 个模块，职责清晰，类型完善，连测试框架都搭好了。

我花了大半个周末逐行审查、补边界情况、跑通测试，然后在新结构上实现了产品要的联动规则——比原来轻松太多。

周一早上，信心满满地提了一个大 PR。

小张的反应出乎意料

我以为他会说"这下好维护多了"。

他看完 PR 沉默了大概十分钟，然后走到我工位旁边："你是不是觉得我写的代码很烂？"

我赶紧解释是因为新需求加不进去。但他的表情告诉我，解释是苍白的。

下午领导找我聊了一下，语气很明确："重构是好事，但你事先应该和小张对齐。"

小张跟领导说了三个点：

• 没有提前沟通：周一早上突然收到一个改了几千行的 PR
• 感觉被否定：三年的工作被 AI 用二十分钟"替换"了
• 维护成本转嫁：重构后的代码他没参与设计，但以后还是他维护

每一点都有道理。

我犯了三个错误

第一，把"技术上正确"等同于"做法正确"。

重构后的代码确实更好。但在团队里，代码不只是技术产物，还是人的产物。每一行背后都有人的时间和判断。你"优化"它的方式，暗示着你对这些投入的评价。

第二，低估了 AI 带来的"效率暴力"。

手动重构需要两周，同事不会觉得被"替代"——因为你付出了对等的时间。但 AI 让这件事变成了一个周末，这个速度本身就带着隐含的否定："你三年写的东西，AI 二十分钟就能写得更好。"

即使我没有这个意思，观感就是这样。

第三，跳过了最重要的步骤——达成共识。

重构这种大范围改动，动手前至少应该：和原作者讨论方案、让他参与设计、分阶段提交。我因为"AI 让重构太容易了"就全部跳过了。

AI 时代的协作陷阱

这件事揭示了一个深层问题：AI 改变了团队协作中一个不成文的契约。

过去，重构成本是人人平等的。花两周改别人的模块，这份投入本身就是"尊重"。但 AI 把成本降到接近零。当改变别人代码的成本趋近于零，"要不要改"和"动手改"之间的心理门槛就消失了。

我总结了一份协作备忘录：

场景	正确做法	常见错误
重构别人的模块	先讨论方案	AI 改完直接提 PR
AI 生成大量改动	拆成小 PR 逐步合入	一次性巨型 PR
发现别人代码问题	Review 中指出	自己 fork 用 AI 重写
AI 方案和同事冲突	作为另一种思路讨论	拿 AI 方案否定同事

后来怎么样了

我找小张单独聊了一次，承认做法不对。他也说模块确实该重构了，只是"被 AI 二十分钟替掉三年代码"需要消化一下。

最后方案：关掉大 PR，重新开几个小 PR，每个只改一个模块，小张全程参与 Review。整个过程花了一周多——比 AI 二十分钟慢了很多，但团队关系没受损。

有时候，慢一点才是真的快。

写在最后

AI 让写代码、重构、测试都变容易了。但它解决不了最难的部分——沟通、共识、尊重、信任。

技术能力再强，搞不定"人"的部分，在团队里就是定时炸弹。AI 放大了个体的执行力，也放大了不沟通的后果。

你有没有遇到过类似情况——好心办了"坏事"？欢迎留言聊聊。