🌏 Read this article in English
上週，一位帶 80 人團隊的工程主管約我喝咖啡。
他沒提 AI 多先進。 他只丟了一句： 「我們花了一大筆錢買算力，結果團隊每天花在『修補 AI 生成的 code』的時間，比寫新功能的時間還多。」
他苦笑了一下：「我們以為請了個超級工程師。 結果請了個 24 小時不眠不休、但完全不懂我們業務邏輯的實習生。」
這很正常。
Gartner 在 2024 年 7 月預測，到 2025 年底，至少 30% 的 GenAI 專案會在 PoC 階段後被放棄。 （來源：Gartner Newsroom, “Top Technology Trends 2024″）
但問題是：這不是技術不夠強。 而是當 AI 從「玩具」變成「工具」，它觸發的組織摩擦，遠大於效率增益。
我們常誤以為 AI 導入是技術問題。 其實，它是人性與流程的壓力測試。
幻滅的起點：PoC 的倖存者偏差
大多數公司導入 AI 的起手式，都是「PoC（概念驗證）」。
選一個痛點，找兩個熱心的工程師，給他們最高的 API Key 權限。 然後，奇蹟發生了。
Junior 用 AI 在 10 分鐘內寫完了原本要寫一天的 CRUD。 Senior 用 AI 在 5 分鐘內重構了一段 4,127 行的 Legacy Code。
報告寫給老闆：「效率提升 300%。」
老闆點頭，預算通過，全公司推廣。
然後，現實來敲門。
⸻
PoC 選的是新功能，沒有歷史包袱。 生產環境不一樣——那裡有 2019 年留下來的欄位，沒有人寫過文件。
在那裡，沒有人有時間問「這個欄位是什麼」。 AI 會根據訓練分布、提示內容與可用上下文，推測出一個看起來合理、但完全錯誤的答案。 還附帶一個完美的註解。
沒人會逐筆對。對到第 50 筆，所有人都累了。
我們高估了 AI 在「已知領域」的能力，卻低估了它在「未知領域」的破壞力。
當 AI 開始介入核心業務邏輯，錯誤的成本不再是「重寫一段 code」，而是「誤導客戶決策」或「資料外洩」。 特別是涉及 PII、權限或外部輸出的情境，這種成本是不可逆的。
看不見的冰山：維護成本的結構性轉移
很多主管在評估 AI ROI 時，只算了一筆帳：「節省了多少開發時間？」
但他們忘了算另一筆帳：「維護這些 AI 生成內容的成本增加了多少？」
⸻
這不是技術債。 是信任債。
⸻
Senior 的皺眉，不是因為 code 爛。 是因為現有規格不足以確認這段邏輯是否涵蓋所有業務規則。
想像一個場景： Senior 看到 AI 寫了一段付款邏輯，語法完美，測試通過。
但他不敢 merge。
他不是不信 AI。 他是不知道這段邏輯背後的業務規則，AI 到底懂了多少，還是只是湊巧湊出來的。
1. 程式碼的可讀性崩解
在缺少 repo context、規範與 review 的情況下，AI 生成的程式碼往往很長、很聰明，但沒人看得懂。
它喜歡用複雜的巢狀結構、隱藏的邏輯判斷，以及充滿魔法數字的變數名。
前陣子，我翻到一段 AI 生成的代碼： 7 層巢狀的 if-else，變數名是 MAGIC_RATE。
當你的團隊開始大量使用 AI，你的 Codebase 會迅速充滿這種「聰明但難懂」的代碼。 AI 帶來的效率增益，通常被「理解成本」的上升所抵消。
2. 依賴鏈的爆炸
在缺少依賴政策與 prompt 約束時，AI 很喜歡引入新的 Library。
每引入一個新的依賴，就增加了一個潛在的衝突點。 半年後你打開 package.json，會發現多了一堆你沒批准過的依賴。
這就是「隱形維護成本」。 lockfile 沒更新、license 不合規、CVE 漏洞漏掃——這些都是 AI 幫你埋的雷。
⸻
這正是典型的「AI 債」：開發變快了，但系統的透明度與可維護性卻下降了。
組織摩擦：當 AI 撞上舊流程
部分技術問題有明確工程解法。 更難的是，責任與流程如何同步重設。
1. 責任歸屬的真空
傳統開發：寫 code 的人，對 code 負責。 AI 輔助開發：誰負責？
是寫 Prompt 的人？ 是審核 Code 的 Senior？ 還是提供 API 的廠商？
前陣子聽一個在製造業做 IT 的朋友說： 他們導入 AI 生成報表。結果 AI 把「營收」算成了「毛利」。
IT 主管說：「是 AI 算錯的。」 業務主管說：「是你們沒審好。」
兩邊都不是壞人——IT 沒被告知這份報表是要報董事會的，業務以為 IT 會審。 問題是流程沒有覆蓋這個情境。
然後就沒有然後了。 報表照樣每週出，錯誤照樣沒人認。
PM 問：「這個 bug 誰負責？」 你：「呃…AI 寫的？」 PM：「…」
AI 導入的最大阻礙，往往不是技術不夠強。 是責任歸屬的真空。
2. 知識傳承的風險
資深工程師的價值，在於他們腦中的「隱性知識」。 AI 沒有這些記憶。
如果團隊過度依賴 AI，Junior 可能失去「在混亂中建立秩序」的機會。 他們學會的不是「如何解決問題」，而是「如何向 AI 描述問題」。
特別是在缺少 review、pairing 或事後講解時，這種脈絡練習就斷了。
取捨：什麼時候不該讓 AI 直接生成？
AI 不是萬靈丹。 在某些情境下，不讓 AI 直接生成並進入核心邏輯，反而是更聰明的選擇。
高穩定性、錯誤不可逆的系統
比如：銀行的核心帳務系統、航空器的飛控軟體。 這些系統的特點是錯誤成本極高、需求變更極少、法規審查嚴格。
對於這類系統，在風險調整後，嚴格審查流程可能更有效率。
高度客製化、業務邏輯複雜的內部工具
比如：一家連鎖超市的庫存調撥系統。
前陣子，團隊裡發生了一件事。 有個 Junior 用 AI 寫了一個庫存調撥功能。
大概 500 行，花了兩小時。效率很高，他自己也很滿意。
我們的 Senior 花了十分鐘 review，然後皺著眉頭說： 「這邊邏輯有問題。2021 年客戶 A 的特殊稅率 1.05，這裡沒處理。」
Junior：「AI 沒提到這個耶。」 Senior：「AI 沒讀過那份 2021 年的合約。」
AI 適合「模式清晰、重複性高」的任務。 對於「規則模糊、高度客製化」的業務，ROI 容易被驗證、整合與返工成本吃掉。
決策框架：如何評估你的 AI 導入策略？
如果你正在考慮導入 AI，不要問「我們能不能用？」。 要問「我們該用在哪裡？」。
| 維度 | 高 ROI 情境 | 低 ROI 情境 |
|---|---|---|
| 任務性質 | 重複性高、模式清晰 | 難驗證、規則模糊 |
| 錯誤容忍度 | 高（可快速修復） | 低（不可逆、高成本） |
| 依賴成熟度 | 標準化 Library 充足 | 需要大量客製化 |
| 團隊能力 | 有足夠的 Senior 進行 Review | 團隊主要由 Junior 組成 |
| 可量測指標 | Review pass rate > 80% 返工率 < 10% |
Review pass rate < 50% 依賴新增數 > 5/月 |
但表格只是起點。 這些數字只是示例門檻，實際基準需依團隊現況校準。
真正的問題是：你團隊裡有幾個人，能在 review 時看出 AI 寫錯了？
就像童軍規則：離開營地時，讓它比你來的時候乾淨一點。 但前提是，你得知道「乾淨」的標準是什麼。
執行指南：建立 AI Code Review 標準
為了對抗「AI 債」，企業不該禁用 AI，而是建立標準化流程。
我會這樣跟主管講：
「我建議我們先在測試與文件上開放 AI，付款邏輯先不碰。三個月後我給你 review pass rate 的數據。」
再跟團隊講清楚三件事：
第一，定義「AI 介入範圍」。 明確哪些模組（如單元測試、文件）允許 AI 生成，哪些核心模組（如付款邏輯、權限控制）必須嚴格禁止 AI 直接生成。
第二，強制性「邏輯溯源」審查。 在 Code Review 時，審核者必須要求開發者解釋 AI 生成代碼中的關鍵判斷邏輯，而非僅僅檢查語法正確性。
第三，依賴清單自動化稽核。 建立 CI/CD 檢查點，當 PR 新增第三方依賴時，觸發自動化的安全與合規性掃描。 （若要追蹤 AI 來源，需額外加入 provenance 標記。）
差距不在會不會用 AI
很多公司失敗的原因，是他們把 AI 當作「更快的鍵盤」。
但生成式模型會產生高機率輸出，正確性仍需靠規格、測試與人類審核驗證。
真正的差距，不是「會不會用 AI」，是「能不能看出 AI 寫錯了」。
工具是放大器。放大的是你本來就有的能力。
所以，明天該做什麼？
Agent 一年後會走到哪一步，市場訊號尚未明朗，需要等 1-2 年回頭看才知道。
但我知道一件事： 誰一開始就把責任講清楚，誰就更容易把 ROI、責任與風險放在同一張表上管理。
如果你明天就要向老闆報告 AI 導入的進度，報告可以不只呈現數據，也呈現審查與責任機制。
AI 不會自動帶來 ROI。 它只會放大你現有的優勢，或暴露你現有的弱點。
這段 code，如果出問題，你知道要找誰嗎？