我用 Codex 重寫了同事維護三年的程式碼，他沒說謝謝——而是去找了主管
我以為我在幫忙，他以為我在「打臉」。AI 讓重構變得太容易了，但它解決不了的，恰恰是最難的那個部分——人。
事情是這樣開始的
我們組有一個內部管理後台，核心模組是一個表單引擎。這個模組是同事小張三年前搭的，從幾十個欄位的簡單表單，慢慢迭代到支援上百個欄位、動態聯動、多層巢狀的複雜表單系統。
三年下來，這個模組膨脹到了大幾千行程式碼——一個檔案。沒有拆分，沒有型別定義，變數命名從 data1 到 tempArr2 應有盡有。
我不是在黑小張。三年前的程式碼放到三年後看，誰的都一樣。何況他當時趕時程，能跑就是勝利。問題是，最近產品要加一批新的聯動規則，我負責這個需求，改了兩天——每次改完一個地方，另一個地方就莫名其妙地壞掉。
一個週末，我「手癢」了
週五下班前我有點煩躁，打開 Codex，把這個檔案丟了進去：「幫我把這個檔案重構一下，拆成合理的模組結構，加上 TypeScript 型別。」
大約二十分鐘，Codex 給出了一個完整的重構方案：把一個大檔案拆成了 6 個模組，每個模組職責清晰，加上了完整的型別定義，連測試案例的框架都搭好了。
我又花了大半個週末做了以下事情：
- 逐行審查了 AI 生成的程式碼，確保邏輯和原來一致
- 補了一些 AI 遺漏的邊界情況
- 跑通了所有現有的測試案例
- 在新結構上實作了產品要的新聯動規則——比原來輕鬆太多了
週一早上，我信心滿滿地提了一個大 PR。
小張的反應完全出乎我的意料
我以為小張會說「這下好維護多了」。
他看完 PR 後沉默了大概十分鐘，然後走到我座位旁邊說了一句：「你是不是覺得我寫的程式碼很爛？」
我當時愣了一下，趕緊解釋說不是，是因為新需求加不進去才做的重構。但他的表情告訴我，解釋是蒼白的。
下午，主管把我叫去聊了一下。不是批評，但語氣很明確：「重構是好事，但你事先應該和小張對齊一下。」
後來我才知道，小張跟主管說了幾個點：
- 沒有提前溝通：他完全不知道有人要重構他的模組，週一早上突然收到一個改了幾千行的 PR
- 感覺被否定：三年的工作被 AI 用二十分鐘「取代」了，心裡不是滋味
- 維護成本轉嫁：重構後的程式碼他沒參與設計，但以後還是他在維護
每一點都說得有道理。
我做錯了什麼
冷靜下來之後復盤，發現自己犯了三個錯誤：
第一，把「技術上正確」等同於「做法正確」。
重構後的程式碼確實更好：結構清楚、型別完善、可測試。但「程式碼更好」不等於「做這件事的方式正確」。在團隊裡，程式碼不只是技術產物，還是人的產物。每一行程式碼背後都有人的時間、精力和判斷。你「優化」它的方式，暗示著你對這些時間和判斷的評價。
第二，低估了 AI 帶來的「效率暴力」的衝擊。
如果我自己手動重構，可能需要兩週。兩週的工作量，同事不會覺得被「取代」——因為你付出了對等的時間。但 AI 讓這件事變成了一個週末，這個速度本身就帶著一種隱含的否定：「你三年寫的東西，AI 用二十分鐘就能寫得更好。」
即使我沒有這個意思，但觀感就是這樣。
第三，跳過了最重要的步驟——達成共識。
重構這種影響範圍大的事情，在動手之前至少應該做到：
- 和原作者討論重構的必要性和方案
- 讓他參與設計甚至一起 pair programming
- 分階段提交而不是一個巨型 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 做了一件自以為是「好事」的事，結果引發了意想不到的反應？
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
