我用 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 做了一件自以为是"好事"的事，结果引发了意想不到的反应？