我用 Codex 重写了同事维护三年的代码，他没说谢谢——而是找了领导

2026/7/3 6:49:16

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

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

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

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

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

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

我又花了大半个周末做了以下事情：

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

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

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

我当时愣了一下，赶紧解释说不是，是因为新需求加不进去才做的重构。但他的表情告诉我，解释是苍白的。

下午，领导把我叫去聊了一下。不是批评，但语气很明确：“重构是好事，但你事先应该和小张对齐一下。”

后来我才知道，小张跟领导说了几个点：

每一点都说得有道理。

冷静下来之后复盘，发现自己犯了三个错误：

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

重构后的代码确实更好：结构清晰、类型完善、可测试。但"代码更好"不等于"做这件事的方式正确"。在团队里，代码不只是技术产物，还是人的产物。每一行代码背后都有人的时间、精力和判断。你"优化"它的方式，暗示着你对这些时间和判断的评价。

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

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

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

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

重构这种影响范围大的事情，在动手之前至少应该做到：

这些都是基本的团队协作规范。我因为"AI 让重构太容易了"就全部跳过了。

这件事让我意识到一个更深层的问题：AI 正在改变团队协作中一个不成文的契约。

过去，重构的成本是人人平等的。花两周重构一个模块，意味着你确实投入了时间和精力，这本身就是一种"尊重"。别人看到你的 PR 会想：这个人花了两周认真做的，我也应该认真 Review。

但 AI 把重构的成本降到了接近零。当改变别人代码的成本趋近于零时，"要不要改"和"动手改"之间的那道心理门槛消失了。人们更容易冲动行事，更容易跳过沟通，更容易无意中伤害团队关系。

我总结了一份AI 时代团队协作备忘录：