1. 引子：一次「好心」的重构

事情发生在上个月。我接手了一个内部工具项目，发现其中一段核心模块的代码质量堪忧——函数动辄两三百行、命名混乱、重复逻辑遍地都是。出于「顺手优化」的心态，我打开 Codex，把这段代码喂了进去，让它基于现有逻辑做一次重构。

Codex 的表现出乎意料地好。它梳理了业务分支、提取了公共方法、补上了缺失的边界处理，甚至把几个隐藏的 bug 都标了出来。我花了大概一个下午做 review 和微调，然后把重构后的代码提交了上去。

第二天，同事没有说谢谢。他直接找了领导。

2. 我当时的心理活动

说实话，刚听到这个消息时，我第一反应是委屈：

• 我明明是在帮他提升代码质量；
• 我明明发现了几个潜在 bug；
• 我明明花了自己的时间做这件事。

为什么他不但不领情，还要去找领导？

但冷静下来之后，我开始意识到：问题可能不在他，而在我。

3. 站在同事的角度看问题

3.1 三年维护的「所有权」

同事维护这段代码三年了。三年意味着什么？意味着：

• 每一行代码背后都有他踩过的坑；
• 每一个看似冗余的分支，都可能对应一个线上事故；
• 他可能已经习惯了这套「不够优雅但稳定」的实现。

我带着 Codex 一夜之间把它重写了，本质上是在否定他三年的工作成果。哪怕我的本意是「帮忙」，他感受到的却是「我的能力被质疑了」。

3.2 重构带来的隐性风险

Codex 重构后的代码，从静态角度看确实更「干净」。但同事比我更清楚：

• 这段代码和哪些外部系统有隐式耦合；
• 哪些「看起来没用」的逻辑其实是历史遗留的兼容处理；
• 测试覆盖不到的地方，出了问题谁来背锅？

他找领导，不是告状，而是在风险发生之前，先把责任边界划清楚。

4. 我复盘出的三个核心教训

4.1 不要用 AI 重写别人「正在维护」的代码

如果一段代码是同事正在负责、正在迭代的模块，哪怕它再烂，也不应该绕过他直接重写。正确的做法是：

• 先和同事沟通，提出你发现的问题；
• 让他决定是否要重构、什么时候重构；
• 如果他要做，你可以提供 Codex 作为辅助工具。

4.2 重构前先建立「信任账户」

在动别人的代码之前，先问问自己：

• 我和这位同事的信任关系够不够？
• 他是否认可我的技术判断？
• 我有没有先在小事上和他建立过协作默契？

如果答案都是否，那这次重构大概率会变成一次「越界」。

4.3 AI 提效 ≠ 可以跳过沟通

Codex 让重构的成本从「几天」降到了「几小时」。但技术成本的下降，不代表人际成本的消失。恰恰因为 AI 让改动变得太容易，我们更需要主动控制改动的边界和节奏。

5. 我后来是怎么补救的

事情发生后，我主动找同事聊了一次。我没有辩解，而是先道歉，然后做了三件事：

1. 承认越界：明确告诉他，我不该未经沟通就重写他负责的模块；
2. 分享 Codex 的发现：把 Codex 标出的几个潜在 bug 整理成文档发给他，让他自己判断是否采纳；
3. 把决定权还给他：重构后的代码是否合入、何时合入，完全由他决定。

结果比我想象的好。他后来告诉我，他其实早就想重构这段代码，只是一直没腾出时间。我的「越界」让他不舒服的点，不是重构本身，而是我没有尊重他的节奏。

6. 给同样想用 AI 提效的你几点建议

如果你也打算用 Codex 或类似工具去优化同事的代码，请先记住这几条：

• 先沟通，再动手：哪怕只是「我帮你看看」也要先说一声；
• 区分「我的代码」和「别人的代码」：自己的代码随便折腾，别人的代码先问一句；
• 把 AI 当建议者，而不是执行者：让 Codex 产出分析报告，把决策权留给代码所有者；
• 接受「不领情」：不是所有善意都会被感激，尤其是在职场里。

7. 写在最后

这件事让我明白了一个道理：技术能力解决的是「怎么做」，而职场协作解决的是「能不能做」。 Codex 再强，也替代不了人与人之间的沟通和尊重。

如果你也遇到过类似的情况，不妨先停下来想一想：对方需要的，到底是你的「帮助」，还是你的「尊重」？

很多时候，后者比前者重要得多。