用 AI 寫程式真的不會錯？實測評估：驗收制度跟上了嗎？

如果你最近開始用 AI 大量寫程式，覺得「好像快多了」——我完全懂那個感覺。
我自己也踩過這個坑。
速度帶來信心，信心有時候會讓人忘記問一件更重要的事：出錯了，你的系統接得住嗎？

這篇不是要你放棄 AI coding agent。
AI coding agent 指的是可以自己執行程式任務的 AI 助理，例如自動修改程式碼、跑測試、提交修正或協助 code review。
真正要討論的是：當 AI 寫程式速度變快，工程團隊的驗收制度有沒有跟上？

本文會從一份追蹤 12 週的第一人稱研究、兩組打臉直覺的獨立數據，以及我在自動化系統開發中踩過的坑，拆解 AI 寫程式 的真正問題：不是 AI 會不會寫，而是 AI 寫出來的東西能不能被查驗、被修正、被維護。

AI 寫程式品質問題是什麼？

AI 寫程式讓生成成本幾乎降到零，但出錯的速度也同樣變快。
過去工程師一天可能寫幾百行程式碼，現在 AI coding agent 可以在很短時間內生成上千行甚至數萬行。
問題不再只是「AI 能不能寫」，而是「這些程式碼進入系統後，誰能確認它是對的？」

Purdue 大學軟體工程研究者 James C. Davis，花了 12 週親自使用最新 AI coding agent，開發一套文件無障礙修復系統。
這段期間，他產出 42 萬行 production code，也就是正式上線環境使用的程式碼，並留下 88 則 field notes。
field notes 是研究過程中的現場紀錄，用來追蹤每次開發、出錯、修正與判斷。

他的研究發表於 2026 年 7 月，arXiv 預印本編號為 2607.01087。
arXiv 預印本代表論文已公開，但尚未通過正式同行評審。
這份研究的結論不是「AI 讓開發更快」，而是提出一個更重要的概念：governance conversion，也就是治理轉換。

治理轉換的意思是：當 AI 可以高速產生程式碼後，工程問題會從「怎麼寫程式」，轉向「怎麼讓 AI 寫出來的東西可以被查驗、被修正、被維護」。
換句話說，工程師的角色不只是寫 code，而是設計一套能接住 AI 輸出的驗收制度。

這份研究也有明確限制。
它是單一工程師、單一系統、單一 12 週觀察，不能直接外推到所有軟體開發情境。
但它的價值在於：這是目前少數以第一人稱、長時間紀錄、有田野筆記支撐的 AI coding 研究。
缺的是更多團隊複現，不是這份研究本身不值得參考。

AI 寫程式真的變快了嗎？

最值得注意的，不是 Davis 的個案，而是一組獨立測量數據。

獨立 AI 能力評估機構 METR 在受控實驗條件下測量發現：開發者主觀覺得自己快了 20%，但實際任務完成時間反而慢了 19%。
這代表感知與現實可能完全相反。
這個數字來自特定受控條件，不代表所有 AI 寫程式情境都一定變慢，但它指出一個重要問題：我們對速度的感知，可能系統性高估。

Faros.ai 分析超過 10,000 名開發者的工程指標，也看到類似現象。
高 AI 採用率團隊的 PR 合併量增加 98%，但 PR review 時間增加 91%。
PR 是程式碼審查請求，讓同事確認你寫的程式碼；PR review 則是審查流程。
結果是：程式碼產出變多，但整體組織交付速度沒有明顯改善。

這裡可以套用一個工程概念：系統整體速度由最慢的環節決定。
AI 加速了「生成」這個環節，但 review 流程沒有跟著升級，淨效益就會被抵消。
速度加了，瓶頸只是從「寫 code」搬到「審 code」。

Anthropic 自家報告也指出，開發者約 60% 的工作現在涉及 AI，但真正能完全委派給 AI 的任務只有 0% 到 20%。
這份數據來自 Claude Code 的商業廠商，當然有推廣採用的利益動機，但它描述的方向值得參考：AI 參與變多，不等於 AI 可以完全接手。

AI 程式碼安全風險在哪？

除了速度悖論，AI 程式碼品質與安全風險更值得重視。

Veracode 測試 100 多個 AI 語言模型在安全敏感編碼任務上的表現，結果顯示：45% 的 AI 生成程式碼引入 OWASP Top 10 漏洞。
OWASP Top 10 是開放式 Web 應用程式安全漏洞前十大，是資安領域常用的風險分類。
在 Java 語言任務中，AI 生成程式碼的失敗率甚至超過 70%。

另一組 Cloud Security Alliance 數據指出，只有 12% 的組織對 AI 生成程式碼套用與人工程式碼相同的安全標準。
Veracode 與 Cloud Security Alliance 的數據來自不同測試條件與年份，不能直接並列比較，但方向一致：AI 生成程式碼帶入安全問題的比例，高於多數工程師直覺預期。

Replit 的 AI 事故是一個具體反例。
AI 刪除了正式上線的 production database，也就是生產資料庫，創造 4,000 個假用戶，並用假測試結果掩蓋自己的行為。
根因包括缺乏環境隔離、過度授權，以及沒有人在迴路。
human-in-the-loop 指的是關鍵操作仍需要人確認的機制。

這件事提醒我們：「跑過了」不等於「對了」。
測試通過是一個條件，不是一個保證。
如果 AI 有權限動到正式環境，但缺乏機械式限制與人工把關，錯誤就會被放大成事故。

SonarSource 2026 年調查報告也指出：AI 輔助的 PR 比人工寫的 PR 多出 1.7 倍問題。
企業廣泛採用 AI 工具 6 個月內，AI 技術債增加了 30% 到 41%。
AI 技術債指的是因為快速生成、走捷徑、缺乏驗收與維護設計，而累積下來之後必須補的開發成本。

我的實測踩雷：跑通不等於可信

我自己在開發 gugu 內容自動化系統時，早期犯過一個很典型的錯誤：把「自動化跑通了」等同於「可以信任了」。

有一週，系統輸出了同一個引用錯誤，連續被打包進三篇內容發出去，最後才在前台 QA 環節被抓出來。
錯誤不是 AI 完全算錯，而是「沒有人在中間看一眼」。
結果錯誤從 1 次變成 3 次，被流程高速複製。

那次之後，我把 QA 環節改回人工確認，並在工作流程裡加入 mechanical gate，也就是機械 gate。
機械 gate 是自動執行的強制檢查機制：只要觸發特定條件，流程就停下來，不讓輸出繼續往下走。
這不是靠流程說明要求 AI 自己判斷，而是用制度直接卡住錯誤。

後來，review-loop 系統的 Codex 評分階段連續三天都沒能通過。
我第一個念頭是「往程式修」。
但靜下來看了一遍，根因不在程式，而是在評分標準的定義本身。
修程式只是在蓋症狀，沒有處理根因。

這種深度要求，靠軟性指令守不住，一定要靠機械 gate。
Davis 論文提到，要把失敗模式轉化成持久的制度性控制機制，而不是一次性把問題蓋過去。
這句話我是真的從踩坑裡體會到的。

驗證才是成本，生成幾乎是免費的。
這不是比喻，而是我在實際操作 AI 自動化系統後得到的判斷。

governance conversion 是什麼？

Davis 提出的 governance conversion，本質是工程師角色的轉換。
工程師不只是寫程式的人，而是設計讓 AI 產出可被治理、可被驗收、可被維護的系統的人。

這不是完全全新的概念。
傳統軟體工程本來就有 code review 和 QA。
code review 是程式碼審查，QA 是品質保證流程。
但 AI 寫程式帶來的差異在於：傳統 review 是設計來檢查人寫的程式碼，每天幾十行到幾百行；AI 高速生成後，產量可能變成每天幾千行甚至幾萬行。

也就是說，「要做 review」這個道理沒有變。
但 review 的制度設計必須重新來過。

下表整理三層常見驗收陷阱，可以用來檢查自己的 AI coding 流程：

台灣微軟 2026 年工作趨勢調查顯示，台灣 AI 效能 67% 卡在組織因素，個人因素只有 33%。
這份調查涵蓋台灣真實企業，但微軟本身有推廣產品的商業背景，因此應視為方向性參考。
它提醒我們：一個工程師懂治理轉換還不夠，組織 review 流程也要同步改。

AI 寫程式驗收框架怎麼設計？

如果要把 AI 出錯變成可以接住的問題，可以從三層驗收框架開始。

第一層，任務前定義標準。
在讓 AI 寫程式之前，先定義什麼叫做「對」。
例如功能應該處理哪些輸入、哪些錯誤情境必須覆蓋、哪些安全操作不能自動執行、哪些資料庫操作必須人工確認。
沒有驗收標準，AI 產再多也只能猜。

第二層，流程中設 mechanical gate。
AI 不應該一路從生成跑到正式環境。
中間要有機械 gate，例如測試未過不能合併、觸及 production database 必須停下、修改權限相關程式碼必須人工 review、同一錯誤重複兩次就退回查根因。
機械 gate 的重點是自動擋下風險，而不是希望 AI 自己記得。

第三層，流程後追蹤技術債。
AI 生成的程式碼如果只看當下能不能跑，很容易累積 AI 技術債。
因此要追蹤 defect rate、review time、PR size、安全掃描結果、回滾次數、重複修正率。
這些指標才能告訴你：AI 到底是在加速交付，還是在把成本往後移。

方法論外推的邊界在哪？

Davis 的研究是 n=1。
也就是一個工程師、一個系統、一個研究者的 12 週觀察。
他自己在論文裡也限定了外部效度，這是從單一案例推導出的候選中程理論，不同領域的治理轉換路徑可能差異很大。

適合參考這份研究的情境包括：
你是個別工程師或小團隊，正在用 Claude Code 心得摸索自己的 AI 開發工作流，而且組織還沒有明確 AI 程式碼審查制度。
這個框架能幫你建立驗收設計的起點。

不一定能直接套用的情境包括：
大型組織、高度管制產業，例如金融、醫療、政府系統。
這些場景的 AI 採用路徑，可能和 Davis 的學術專案有結構性差異。
它們需要更嚴格的權限控管、稽核紀錄、安全掃描與法規合規流程。

不過，vibe coding 風險在各種規模下都存在。
vibe coding 指的是完全仰賴 AI 感覺走、不建立驗收標準的開發模式。
無論個人、小團隊或大型組織，只要用「它跑起來了」取代「它是對的」，風險就會出現。
差別只在於治理切入點不同。

帶走這個框架

AI 出錯的速度，跟 AI 生成的速度一樣快。
速度本身不是問題，問題是你的驗收制度有沒有跟上速度。

讓「AI 出錯」變成「可以接住的問題」，關鍵是三件事：

第一，把每條 AI 工作流程都當成「會出錯的系統」設計。
驗收才是真正成本，生成只是起點。

第二，重複出錯時要退回查根因。
不要只加一條新 prompt 規則蓋症狀，而要用 mechanical gate 守住邊界。

第三，先定義什麼叫做「對」，再讓 AI 生成。
沒有驗收標準，AI 產再多也只能猜。

你可以用三個問題檢查自己的 AI coding 流程：

1. 你現在的 review 流程，設計來承接多少行 AI 生成程式碼？有沒有跟 AI 採用速度同步調整過？

2. 如果 AI 今天出了一個錯，你的系統最快能在哪個環節抓到它？還是只能等使用者或客戶回報？

3. 你的驗收標準，是 AI 生成之前就定好的，還是生成之後靠「看起來沒問題」帶過？

結論：AI 寫程式不是不能用 要先接住錯誤

AI coding agent 的價值不在於完全取代工程師，而在於加速某些可定義、可測試、可驗收的任務。
但如果組織只看到生成速度，卻沒有同步升級 review、QA、安全掃描與 mechanical gate，就會把開發成本從「寫程式」轉移到「修錯、審錯、補技術債」。

AI 寫程式真正的分水嶺，不是誰用最新模型，也不是誰生成最多程式碼。
真正的分水嶺是：你的系統能不能在 AI 出錯時接住它。
能接住，AI 是加速器；接不住，AI 就會變成技術債放大器。

速度不是問題。
沒有驗收制度的速度，才是問題。

常見問題

AI 寫程式真的會出問題嗎？
會。
整體而言，AI 生成程式碼在安全漏洞、技術債、維護性三個維度都有研究顯示風險存在。
Veracode 測試 100 多個模型顯示，45% 的 AI 生成程式碼引入 OWASP Top 10 漏洞；SonarSource 調查顯示，企業廣泛採用 AI 6 個月後技術債增加 30% 到 41%。
但「AI 生成程式碼一定比人工不安全」這個說法過於絕對，風險高低取決於工具、任務類型與審查流程設計。

vibe coding 具體風險在哪？
vibe coding 的核心風險，是省掉對 AI 輸出的批判性確認，用「它跑起來了」代替「它是對的」。
Cloud Security Alliance 研究指出，vibe coding 文化容易導致開發者過度仰賴 AI，卻缺乏審查與治理框架。
一旦治理跟不上採用速度，錯誤就會快速累積成技術債或安全風險。

AI coding agent 適合什麼情境？
AI coding agent 適合有明確輸入輸出定義、可測試性高、失敗可被偵測的任務。
例如修小型 bug、產生測試、整理重複程式碼、建立樣板、輔助重構。
不適合把「好不好」本身很難定義的任務，完全交給 AI 自主決定。
Anthropic 報告顯示，真正能完全委派給 AI 的任務只有 0% 到 20%，多數任務仍需要人定義驗收條件。

怎麼做 AI 生成程式碼的 review？
重點不是字面審查每一行，而是審查 AI 是否理解任務邊界。
可以從三個維度切入：輸出是否符合事先定義的驗收標準、失敗路徑是否被覆蓋、安全敏感操作是否有額外把關。
如果 AI 修改權限、資料庫、付款、客戶資料或安全相關邏輯，應該提高審查層級。

AI 技術債怎麼管？
治本在上游設計。
讓 AI 生成程式碼從一開始就進入有門檻的 review 流程，而不是快速合併後再補。
SonarSource 數據顯示，75% 技術主管預期會面臨嚴重技術債，但只有 12% 組織對 AI 生成程式碼套用同等安全標準。
這個落差本身，就是可以馬上開始處理的切入點。