93% 的工程師都在用 AI，生產力卻只多了 10%——歡迎來到 2026 年的 AI 矛盾現場

這禮拜在各家 CTO 的 Slack 群組裡被瘋傳的三個數字，怎麼擺都擺不到一起。第一：92.6% 的工程師至少每月用一次 AI 程式助手、82% 每天或每週用、全球已有 41% 的程式碼出自 AI 之手。第二：然而平均自評的生產力提升只停在 10% 左右，METR 一份控制良好的研究甚至顯示，資深開源工程師用 AI 比不用慢了 19%。第三：AI 協作產出的程式碼，安全漏洞密度比人類手寫的高出 23.7%。

如果你管著一個工程組織，這三個數字組成一個矛盾：最高的採用率、平庸的整體增益、上升中的下游風險。直覺是宣布「AI 寫程式被過度行銷」。錯了。正確的結論是：價值是真的，但它從三個明確的洞漏掉，而這三個洞，這一季都補得起來。

一、一段話交代數字

84% 的工程師在用 AI 工具，41% 的全球程式碼是 AI 生成，26.9% 的 production 程式碼出自 AI（上一季是 22%）。自評生產力提升：10–30%（看你信哪份研究）。控制實驗下的資深開發者生產力：在某些任務 −19%，在多數任務接近 0%，變異大。同時 66% 的工程師說 AI 最大的問題是「結果看起來對但其實不完全對」，AI 程式碼的漏洞密度上升 23.7%。

二、為什麼「打字變快」沒有變成「交付變快」

代理人寫 diff 快，但不代表把工作做完得快。「工作」包含：讀懂票、設計變更、過 code review、過 CI、修 staging regression、過資安掃描、上線又沒收到客訴。AI 把這條管線中的「打字」這一段壓縮了大概一半。其他段落沒變、甚至更糟。如果原本「打字」只佔總週期時間的 20%，你頂多賺到 10%。這正是新聞標題那個數字。算術一直都會落在這裡，我們只是不肯算。

三、隱形的稅：23.7% 的漏洞密度上升

安全的那部分是這個矛盾裡最被低估的角度。同一個能寫出乾淨 controller 方法的模型，也會自信地吐出字串拼接 SQL、漏掉 CSRF token、密碼規則寬鬆、依賴一個昨天才被剛註冊的 npm 帳號發布的套件——這禮拜 SAP npm「Mini Shai-Hulud」事件就是活生生的例子（本期第三篇就在講這件事）。AI 程式碼沒比較不安全，不是因為模型有惡意，而是因為它的訓練資料平均水準，本來就比你們團隊代碼審查過的版本低。平均水準的程式碼變成新地板。

四、真正撬動生產力的四件事

那些拿到超過 10% 提升的團隊，都在做這四件事：第一，給代理人一份 CLAUDE.md 或同等的專案上下文。第二，把代理人「分層」——測試代理人只寫測試，migration 代理人只動 SQL migration——而不是讓一個代理人什麼都做。第三，安全 linter 跑在「代理人 diff 進入分支之前」，不是 code review 後。第四，量「端到端週期時間」，不要量「人均每日程式碼行數」——後者是最容易讓 AI 看起來很厲害、但實際上交付變慢的指標。

我的看法

「AI 讓大家變慢」的敘事是錯的，「AI 把我團隊變十倍」的敘事也是錯的。誠實讀完 2026 年 5 月的資料：AI 是一個 10–15% 的生產力提升、24% 的安全退步，以及一個 100% 改寫「資淺工程師如何學習」的方式。整體淨值是：短期 ROI 真實但溫和；中期會累積真實而漸大的安全債；長期人才養成的影響，根本沒有人在定價。十八個月後看起來最聰明的公司，會是那些現在就投資「AI-aware code review」、強制 CLAUDE.md 上下文、與審慎設計學徒制度的公司——後者用來防止資淺工程師把核心能力外包給模型。只想多買幾個 Copilot 席次然後祈禱的公司，付了一份永遠收不到的生產力錢。