我用 Codex 重写了同事维护三年的代码，他没说谢谢——而是找了领导
我以为我在帮忙，他以为我在"打脸"。AI 让重构变得太容易了，但它解决不了的，恰恰是最难的那个部分——人。
事情是这样开始的
我们组有一个内部管理后台，核心模块是一个表单引擎。这个模块是同事小张三年前搭的，从几十个字段的简单表单，慢慢迭代到支持上百个字段、动态联动、多级嵌套的复杂表单系统。
三年下来，这个模块膨胀到了大几千行代码——一个文件。没有拆分，没有类型定义，变量命名从data1到tempArr2应有尽有。
我不是在黑小张。三年前的代码放到三年后看，谁的都一样。何况他当时赶工期，能跑就是胜利。问题是，最近产品要加一批新的联动规则，我负责这个需求，改了两天——每次改完一个地方，另一个地方就莫名其妙地坏掉。
一个周末，我"手贱"了
周五下班前我有点烦躁，打开 Codex，把这个文件丢了进去：“帮我把这个文件重构一下，拆成合理的模块结构，加上 TypeScript 类型。”
大约二十分钟，Codex 给出了一个完整的重构方案：把一个大文件拆成了 6 个模块，每个模块职责清晰，加上了完整的类型定义，连测试用例的框架都搭好了。
我又花了大半个周末做了以下事情：
- 逐行审查了 AI 生成的代码，确保逻辑和原来一致
- 补了一些 AI 遗漏的边界情况
- 跑通了所有现有的测试用例
- 在新结构上实现了产品要的新联动规则——比原来轻松太多了
周一早上，我信心满满地提了一个大 PR。
小张的反应完全出乎我的意料
我以为小张会说"这下好维护多了"。
他看完 PR 后沉默了大概十分钟，然后走到我工位旁边说了一句：“你是不是觉得我写的代码很烂？”
我当时愣了一下，赶紧解释说不是，是因为新需求加不进去才做的重构。但他的表情告诉我，解释是苍白的。
下午，领导把我叫去聊了一下。不是批评，但语气很明确：“重构是好事，但你事先应该和小张对齐一下。”
后来我才知道，小张跟领导说了几个点：
- 没有提前沟通：他完全不知道有人要重构他的模块，周一早上突然收到一个改了几千行的 PR
- 感觉被否定：三年的工作被 AI 用二十分钟"替换"了，心里不是滋味
- 维护成本转嫁：重构后的代码他没参与设计，但以后还是他在维护
每一点都说得有道理。
我做错了什么
冷静下来之后复盘，发现自己犯了三个错误：
第一，把"技术上正确"等同于"做法正确"。
重构后的代码确实更好：结构清晰、类型完善、可测试。但"代码更好"不等于"做这件事的方式正确"。在团队里，代码不只是技术产物，还是人的产物。每一行代码背后都有人的时间、精力和判断。你"优化"它的方式，暗示着你对这些时间和判断的评价。
第二，低估了 AI 带来的"效率暴力"的冲击。
如果我自己手动重构，可能需要两周。两周的工作量，同事不会觉得被"替代"——因为你付出了对等的时间。但 AI 让这件事变成了一个周末，这个速度本身就带着一种隐含的否定：“你三年写的东西，AI 用二十分钟就能写得更好。”
即使我没有这个意思，但观感就是这样。
第三，跳过了最重要的步骤——达成共识。
重构这种影响范围大的事情，在动手之前至少应该做到：
- 和原作者讨论重构的必要性和方案
- 让他参与设计甚至一起结对
- 分阶段提交而不是一个巨型 PR
这些都是基本的团队协作规范。我因为"AI 让重构太容易了"就全部跳过了。
AI 时代的"协作陷阱"
这件事让我意识到一个更深层的问题：AI 正在改变团队协作中一个不成文的契约。
过去，重构的成本是人人平等的。花两周重构一个模块，意味着你确实投入了时间和精力，这本身就是一种"尊重"。别人看到你的 PR 会想：这个人花了两周认真做的，我也应该认真 Review。
但 AI 把重构的成本降到了接近零。当改变别人代码的成本趋近于零时，"要不要改"和"动手改"之间的那道心理门槛消失了。人们更容易冲动行事，更容易跳过沟通，更容易无意中伤害团队关系。
我总结了一份AI 时代团队协作备忘录：
| 场景 | 正确做法 | 常见错误 |
|---|---|---|
| 想重构别人的模块 | 先和原作者讨论方案 | 直接让 AI 改完提 PR |
| AI 生成了大量改动 | 拆成多个小 PR 逐步合入 | 一次性提一个巨型 PR |
| 发现别人代码有问题 | Code Review 中指出 | 自己 fork 过来用 AI 重写 |
| 用 AI 加速开发 | 分享方法，帮团队一起提效 | 一个人偷偷用，制造效率差 |
| AI 方案和同事方案冲突 | 作为"另一种思路"讨论 | 拿 AI 方案否定同事 |
后来怎么样了
我后来找小张单独聊了一次，把本意解释清楚——确实不是觉得他代码烂，是新需求实在加不进去。同时也承认自己做法不对，应该事先沟通。
小张也表示理解。他说那个模块确实该重构了，只是"被 AI 二十分钟替掉三年代码"这件事需要消化一下。
最后我们达成了一个方案：我关掉那个大 PR，重新开了几个小 PR，每个只改一个模块，小张全程参与 Review。整个过程花了一周多——比"AI 二十分钟"慢了很多，但团队关系没有受损，小张也在 Review 过程中熟悉了新的代码结构。
有时候，慢一点才是真的快。
写在最后
AI 让很多事情变得容易了：写代码容易了，重构容易了，写测试容易了。但 AI 解决不了的事情，恰恰是最难的那些——沟通、共识、尊重、信任。
技术能力再强，如果搞不定"人"的部分，在团队里就是一颗定时炸弹。这个道理以前就有，只是在 AI 时代变得更加尖锐了——因为 AI 放大了个体的执行力，也放大了不沟通的后果。
你有没有在团队里遇到过类似的情况——用 AI 做了一件自以为是"好事"的事，结果引发了意想不到的反应？