ClearForge
重點：AI 導入失敗的根因不是工具，是工程師習慣難改、判斷力沒建立、抗拒沒被處理。技術主管把文件做到極致也救不了。
Agentic coding 導入失敗，大多數時候不是工具選錯——是你低估了要改變一群工程師寫 code 習慣這件事有多難。
在社群不時會看到有人大推 Claude Code，有的人則認為 Codex 更好，但這種軍火庫的比較是比不完的。真正把工具導入團隊之後，你會發現工具選哪個根本不是重點。 重點是——你的同事願不願意改變他們已經用了好幾年的開發方式。
一次 SaaS 團隊的 AI 導入健診
最近幫一個 SaaS 團隊做了一次 AI 導入健診，有幾個發現我覺得值得拿出來分享。這絕對不會是個案，相反的，我認為這會是不少公司會遇到的典型狀況。
不是因為這個團隊特別糟。恰恰相反——他們的技術推動者非常認真，做了大多數團隊根本沒做的事：自己先跑完整輪 Agentic Coding，驗證可行，再開始推。
他給團隊的東西有多完整？
用 AI 吃完 PM 需求，產出 SA/SD 文件、API endpoint、DB schema、C4 圖、循序圖，再切成一張一張有情境、SBE、API、DB 的 task 給 RD 開發。
我看完那份文件的第一個念頭是：「這如果是我，一天就交卷了。」
結果團隊花了整整一週，Daily 每天都是「還在研究中」。
問題不在文件，在起手式
文件那麼完整，團隊還是卡了一週。不是因為 task 寫不清楚。是因為工程師不知道怎麼用 AI 來消化這些文件。
每個人拿到 task 的第一動作，還是自己打開 IDE 開始寫。卡住了才去問 AI。
沒有人示範過「AI-first」的工作流長什麼樣——讓 AI 讀 context、讓 AI 跑測試、讓 AI 持續操作檔案。
全公司真正進入 agentic 工作模式的人，推動者估計不超過 5%。
其他人以為 AI 就是比較聰明的 Google：你問，它答，然後你繼續自己做。
這不是工具問題，是工作流的起手式從來沒被重新設計過。
「還是人比較可靠」這句話，背後藏著什麼
推動者告訴我，團隊裡大約有一半的人持這個態度。
我一開始以為是保守，但他繼續描述的細節讓我想了很久：他們分不清「AI 寫的程式碼有問題」跟「我不會判斷 AI 寫的程式碼有問題」的差別。
因為沒有一套共用的品質判斷框架，面對 AI 的產出，只有兩個選項：全信，或全不信。結果當然是全不信。這其實是理性決策。
信任不是靠鼓勵產生的。當一個工程師能精準指出 AI 生成的 code 哪裡有問題、哪裡可以用，他才會真的把 AI 跟自己習慣的工作流進行融合——因為他知道出問題時他能處理。
判斷力先於信任。沒有判斷力，你給再多鼓勵都是在加速焦慮。
AI 是放大鏡，不是遮羞布
這是這次健診最讓我印象深刻的觀察，來自推動者自己說的：
「AI 真的是放大鏡，基本功跟軟體工程還是重要。你可以 vibe 出一個系統，不代表可以一直迭代加新功能。」
推動者觀察到，Senior 跟 Junior 的抗拒程度差不多。
照理說，Senior 有更多能力判斷 AI 的產出，應該更容易接受才對。但他們沒有。
一個可能的解釋是：AI 會放大你的強項，也會放大你的弱項。你不熟的地方，AI 會讓它更明顯。對某些 Senior 來說，靠自己累積的直覺和經驗工作了十幾年，突然要在一個放大鏡底下操作，不舒服是真實的。
抗拒 AI 的人，不一定是懶，也不一定是笨。有時候是因為用了之後，自己不想看見的東西會被看見。
RD 和 QA，抗拒的根源不一樣
這個團隊另一個值得單獨拿出來說的現象是 QA 的反應。
推動者告訴我，QA 堅持手動產生測試案例，抗拒程度比 RD 還高。
- RD 的抗拒，核心是信任問題——不確定 AI 寫的 code 能不能用，本質上是判斷力還沒建起來
- QA 的抗拒，我認為不只是 mindset 的問題。測試案例的撰寫，是 QA 最核心的職能之一，也是 AI 目前最容易直接替代的工作內容之一
抗拒的背後，很可能是一個更根本的問題：我的角色還有什麼是不可被取代的？
同樣叫做「抗拒」，根源完全不同。如果用同一套方法處理，註定解決不了其中一個。
帶領者沒走過，要怎麼帶別人走
推動者原本規劃了讓大家一起做的 workshop。但組織的決定是：這是 Team Lead 的事。
問題是 Team Lead 自己還沒完整走過 agentic coding 的工作流。
這不是 Team Lead 的問題，是設計問題。角色分工本身沒錯，但「教練式陪跑」這件事，沒有被納入任何人的分工架構。
等於叫一個才剛在泳池邊練習水中吐氣的人去當救生員。
知識透過文件可以傳遞，但工作流的 mindset 不行。這個東西需要有人走在前面、示範、接住問題、再走一次。
很多團隊的 AI 導入卡在同一個地方：提供工具、鼓勵使用、然後放養。放養長不出習慣。
寫 code 已久的工程師，第一反應不是興奮，是防衛
確定一件事——嘗試導入 agentic coding tools，本質是在推動變革。 而變革的成功與失敗，工具的選擇是影響最小的因子，最大的挑戰會來自你想變革的組織文化。
大部分技術主管想到「導入 AI 工具」，腦海裡浮現的是 setup guide、best practice、prompt 技巧。但一個寫了十幾年 code 的資深工程師，被暗示他的工作方式需要改變的時候，他的第一反應不是興奮，是防衛。
少林足球裡有一幕——周星馳蹲在地上跟吳孟達說：「球，不是這麼踢滴。」曾經是球星的吳孟達覺得他在胡說八道，大概就是這種感覺。
而且壓力不只來自下面。你的主管可能同時在問你「什麼時候全面導入」，但他不一定理解現場的阻力長什麼樣。你夾在中間，上面要速度，下面要安全感。
整條交付流程都會被衝擊，不是只有寫 code 那一段
就算有人開始用了，你的開發交付流程有沒有跟著變？
AI 能幫你把開發速度拉快兩三倍，聽起來很美好。但產出變多，review 的量暴增，你的 tech lead 本來一天 review 三個 PR，現在變八個，每個還比以前長。開發產能不是瓶頸了，review 產能才是。
跟一位好朋友在交流 AI 導入的問題時，他跟我提了一個更實際的問題：當交付速度整個拉上去，原本的 Scrum 儀式——Daily、Planning、Refinement、Demo——哪一個的節奏還跟得上？
一個問題留給你
你現在的團隊裡，對 AI 輔助開發最抗拒的那個人——你知道他在擔心什麼嗎？
還是其實你自己就很擔心？