「該不該推 team 用 AI coding tools」這個問題，市面上的標準答案通常是「it depends」、「要看公司文化」、「漸進式 rollout」。
我寫不出那種文章。
因為我親自走過一個 team adoption 完全失敗的案例——AI 在那個團隊不是 productivity tool，是讓既有結構性問題崩潰得更快的放大器。最後我選的不是 best practice，是離開。
這篇是「what went wrong」紀錄。不是 listicle、不是 framework，是讓你看完知道什麼時候你該意識到該離開了。
場景：規模不大，但人力結構已經失衡
類 EC 的專案，規模沒有很大，但人力超級缺乏。
這個案例的痛點，從一開始就不在工具層、不在 stack 選型、不在 sprint cadence——這些都是表象。真正的痛點是團隊的責任邊界結構：
- 每個人只想顧好自己範圍的東西
- 邊界外的事情都被預設成「給能補的人」
- 那個能補的人是我
我那段時間補的範圍：
前端、後端、DBA、infra、PM、MIS、人資。
不是我自願擴大 scope，是邊界外沒人接，東西就會卡住，最後只能我補。久了大家會習慣這個分工——但這個分工不是健康的「合作」，是一種寄生關係的常態化。
這是 AI 進場之前的基線。先把這個基線記住，後面才看得懂為什麼 AI 是壓垮駱駝的最後一根稻草。
AI 進場：不是救星，是放大器
接著上頭下令「AI 至上」，全員導入 coding tools。
崩盤不是漸進的，是斷崖式的。
原本對 AI 抱持懷疑的 RD（典型「我寫得比 AI 好不需要它」的工程師），在被推著用之後沒有變懂 AI——而是翻轉成「AI 寫的我不用看就 commit」。一天 40 個 commit，commit 內容裡 middleware 是幹嘛的都不知道。我 review 的速度跟不上 garbage in garbage out 的速度。
這個現象的本質不是 commit 數量。爛 ratio 不變、量變大才是問題核心。AI 在不健康的結構上的作用，就是讓爛東西的生產速度變快。
而且是真的講不聽。不是溝通技巧的問題——是個人的認知不會因為主管 push 就改。原本就抗拒 AI 的人被強推之後，會變成「無腦用 AI 但拒絕學」的版本，這比抗拒 AI 還差。
「請你去改變所有人的認知」
某天主管找我談話，原話大致是：
「你要告訴我用 AI 以後省了多少時間。資訊部門應該是最靠近 AI 的，所以你們都要用 AI、要統一用法。」
我聽到當下整個人是問號。
幾個層次同時冒出來。
第一個問題：工具採用本來就是 pull-driven 不是 push-driven。如果一個工程師覺得這個工具好用，他早就主動用了——根本不用我去教。「強制統一用法」會有效果的話，每一個團隊老闆隨便講一句大家就照辦了。實際上工程師花十年養成的工作習慣，不是被 push 推得動的東西。
第二個問題：「改變所有人的認知」這個 ask 本身就有結構性問題。
講了有用的話，每個人都嘛台大、建中、北一女了。
這話聽起來像玩笑，但邏輯是真的——如果說服別人改變認知這件事這麼簡單，這個世界上不會有那麼多教育階級的差異。要嘛我們這個團隊在做直銷（強制信仰一套方法論），要嘛我是邪教教主（用一套說辭讓所有人放棄原本的判斷），不然「改變所有人認知」這個 KPI 根本是不可達成的。
第三個問題：這個 ask 反映的不是員工教育問題，而是 leadership 的責任分配問題。
「找個強的把弱的拉起來」不是 leadership，是把 leadership 的責任往下委派。
把 team culture 的塑造責任丟給最強的 IC，等於主管把自己最重要的工作 outsource 出去。IC 接了不會變成英雄，會變成那段寄生關係能繼續運轉的關鍵零件。
我那時候不懂這個，硬撐了一陣子才看清。寫這篇就是希望看到的人不要重複我的弧線。
領悟：團隊的短版就是團隊的上限
這是那段時間後我帶走的最重要判斷依據：
不管你個人多強，你的天花板會被團隊的地板拉低。
如果團隊的地板是「commit 內容沒讀過、middleware 沒概念、AI 出什麼貼什麼」——
- 你 review 的時候，不只在 review code，還在 review 一個你補不完的洞
- 你寫再多 best practice 文件，沒人讀
- 你提 architecture 改善，會被 deprioritize 因為大家正在「快速 ship」
- 你 raise 的問題沒人聽得進去，因為他們的認知層級還沒到能聽懂
AI 不會修這個結構。AI 加速的是「生產速度」，不是「認知層級」。一個無法理解 middleware 的工程師，不會因為用了 Claude Code / Copilot / Cursor 就變得理解 middleware——他只會用更快的速度產出他不理解的 code。
三條件警報
如果你在的團隊三個訊號都齊：
1. 上頭 AI 至上 不問實際 ROI、把 AI 當不可質疑的方向、覺得導入就是進步、把「教育同事接受 AI」當成 IC 該做的事。
2. 同事只顧自己範圍 + 你補全部空缺 你做的不是「你的工作」，是「沒人接的所有工作」。前端、後端、DBA、infra、PM——你的 scope 跟團隊缺口同義。
3. 講不聽 不是溝通能力的問題。是團隊整體的認知層級還沒到能聽懂你 raise 的問題。AI 進場後這個現象變得更嚴重——因為他們有「AI 幫我寫了所以我懂」的錯覺。
三個齊了，這個團隊大概率救不了。不是你不夠努力，是這個結構的上限就到這裡。
我那時候最後悔的是「我以為再撐一下就能改變什麼」。事後看，那個假設本身就是錯的。
反思一句話
那段經歷之後我給自己定了一條規則：
只要團隊裡面的 key man 整天產不出實際東西，就保全自己快逃。
key man 不只是 staff engineer 那種「key」，是「整個 team 走下去靠他補的人」。如果你是這個 key man，你補了三個月、半年、一年下來都還在補——那不是工作，是在維繫一個寄生結構的運轉。
寄生關係裡，被吸的那一方就是你。AI 進場之後寄生效率更高——同事用 AI 拉爛 PR 的速度更快，你被 review 吸走的時間更多。
離開是 self-preservation，不是 quitter mindset。
那真正的 AI Coding Tools team adoption 該怎麼做
把上面的反例反過來看就是答案：
- 上頭懂——能分辨「AI 加成」跟「AI 替代學習」的差別，知道 AI 不會修人的認知層級
- 團隊懂——AI 出的 code，每個人都會 review、會挑錯、會 push back
- 你不必補全——你的 scope 是合理的、邊界清楚的，邊界外有別人
三個條件任何一條缺，就先別 push 導入。先處理結構問題，AI 的事等等再說。
如果三條件你的環境齊了，後面才有 rollout 策略 / hold-out 處理 / productivity 評估這些 best practice 可講。但那些 best practice 都建立在「團隊本身能用 AI 變好」的前提上。
團隊本身結構失能的話，導入 AI 等於給火上加油。
你不是團隊的救星
最後給看到這篇的你——
你不是耶穌、不是諸葛亮、不是團隊的救星。你是個工程師。
工程師的責任是：產出好東西、把事情做好、把判斷講清楚。「教育所有同事接受新工具」這個責任不在 IC，是主管的、HR 的、team culture 的。
主管把這個責任丟給你，是把不屬於 IC 的擔子交出來。你接了不會變成英雄，會變成那段寄生關係能繼續運轉的關鍵零件。
意識到這點之後，下一步只有一個。
延伸閱讀
這篇講的是「結構失能到 reach 點時的離開判斷」。在還沒到那個點時 IC 該怎麼維護邊界、怎麼 push back 不合理的 ask、健康 R&R 該長什麼樣——見 20-roles-responsibilities。