人類審查 AI 撰寫的程式碼仍是真正的控制措施，還是早已淪為橡皮圖章？

這些問題#

來自 ai-coding-practice 監督議題群的五個相關 #oq/now 項目，以下合併綜整回答：

1. AI as Primary Author — 當代理程式直接套用變更，而人類所謂的接受就是不回退變更時，「接受」究竟代表什麼？
2. Compute Allocator — 配置者的說法是否有監督疲勞／橡皮圖章的風險，也就是人類名義上做決定，實際上卻只是蓋章？
3. Verification as the New Bottleneck — 完全自動化審查應推進到什麼程度？
4. Telemetry vs. Survey Measurement — Faros–DORA 的「矛盾」是否部分源自類別錯誤，兩者在各自層面都成立？
5. The Three Loops of AI-Native Building — Ng 與 Faros 對 QA 負擔的分歧，真的是 0 到 1 與生產環境的差異，還是自陳資料中的樂觀偏誤？

回答 1：「接受」是三種構念共用一個數字#

Faros 的 60% 接受率，合併了證據權重截然不同的行為（AI as Primary Author）。依照誰採取行動、誰來檢視拆開來看：

• 明確採用 — 人類閱讀建議後加以套用（自動補全時代的意思）。接受是一項決定。
• 經審查後未回退 — 代理程式套用差異內容；另一位獨立的人類在合併前進行檢視。接受代表委派撰寫，再由第二雙眼睛檢查。
• 單純未回退 — 代理程式套用變更；沒有人獨立檢視；「接受」就是沒有介入。這屬於橡皮圖章類別，也是唯一值得對整體數字發出警訊的類別。

構念不穩定是有測量依據的，不是假設：在 GitHub 上，代理程式 PR 最常只有呼叫代理程式的開發者檢視（只有作者檢視的比例，代理程式 PR 為 40.1%，人類 PR 為 21.5%）；而將該開發者視為獨立審查者（代理程式為作者）或自行審查的作者（代理程式為工具），會讓同一批資料中的獨立審查趨勢正負反轉（Review as the Control Point）。只要調整指標、母體、時間軸和作者身分單位，Faros 與 CMU 對審查不足的「分歧」也會以同樣方式消失（The Under-Review Divergence: Faros's Widening Crisis vs. CMU's Convergence）——資料集從未互相矛盾，矛盾的是構念。兩者合起來對橡皮圖章類別的共同揭示是：它在企業快照中占比很高（Faros：31.3% 的 PR 未經審查便合併——Acceleration Whiplash），在開源環境中則屬短暫現象（CMU：未經審查即合併的代理程式 PR，從 2025 年年中超過 50%，到 2026 年初降至約 14%，接近人類 PR 的基準）。企業是否也會跟上開源社群的趨同，是目前真正待驗證的經驗問題，光靠任一資料集都無法回答。

**實務規則：**停止報告「接受率」；改報三種行為的比例，只把單純未回退當成監督弱化訊號。第二類占比上升，代表委派運作順利；第三類占比上升，代表控制措施失效。

回答 2：是——配置者最核心的失效模式，已有三層證據記錄#

Compute Allocator 的說法預設稀缺的人類投入是判斷品質，但它所推崇的行為——99% 的一次性腳手架、數百個並行代理程式——恰恰會最大化損害判斷力的工作量。橡皮圖章風險並非臆測；知識庫有三個彼此獨立的證據層：

• **受控／實驗證據：**監督疲勞使輕微錯誤增加 11%、重大錯誤增加 39%；員工式框架則把疲勞換成投入不足（錯誤發現率下降 18%）——兩種失效面向，沒有哪種框架能免費避開問題（AI Brain Fry）。自陳資料也看不出損害：大量委派者自稱沒有學習缺損（The Automation–Optimism Link），但隨機測量顯示，移除 AI 後，自動化模式帶來的進步便消失（Experimental Learning Impact of Generative AI）。
• **遙測資料：**31.3% 的 PR 未經審查便合併，審查時間增加約 5 倍，每位開發者每日處理的 PR 情境增加 67.4%（Acceleration Whiplash）。
• 實務者論述及其機制對應：負荷會降低審查深度和動機（P1–P3：「略讀，而非細讀」）；而且表面可信度會卸下審查者的戒心（P4：潤飾過的外觀讓人放下警戒——「資深工程師會替看似符合慣例、實則藏有微妙錯誤的程式碼蓋章」），即使審查看起來深入，理解債務仍會隨之累積（P10/P11：「我們不是在審查食譜，而是在品嘗成品」）（Review as the Control Point）。

配置者角色還有兩項特有的惡化因素：配置品質沒有回饋迴圈（該頁自己提出的待解問題——沒有任何訊息告訴配置者，他們是錯誤地花掉算力，而不只是花了很多算力）；而規劃／執行分工（Planning / Execution Division of Labor）意味著人類保留的 70% 比重是規劃決策——正是那些品質會悄然下降的決策，因為在逐字紀錄中，蓋章通過的計畫核准，和經過慎重考量的核准毫無差別（該頁自己也提到橡皮圖章測量上的限制）。

**但失效模式有其門檻，並非命中注定——證據中也有對策。**面對腦力疲勞造成的工作量問題，有效的是重新設計審查，而不是增加審查力道：以抽樣深度取代逐一審查所有輸出，聚焦高風險決策點（AI Brain Fry）；要求通過測驗、展現理解才能合併，而非只要簽名（測驗關卡——Unknowns as the Agentic Bottleneck）；採用依風險分級的治理，只把關重大變更（P17）；並在適當時間、透過適當管道參與，而非增加參與次數——HAS-Bench 發現人類投入的效果取決於設定條件，而且不是愈多愈好；過度介入甚至會讓原本已解決的任務失敗（Configurable Human Participation）。因此答案是：是，配置者的說法帶有橡皮圖章風險，這正是其核心失效模式；只有在合併條件要求理解、以抽樣方式深入審查，而非只看人是否到場、再把注意力稀釋開來時，監督才仍是真正的控制措施。

回答 3：「自動化到什麼程度」是分工，而不是刻度#

Fung 的問題假設有一條單一的自動化界線，可以一路推進。證據顯示，應該把它拆開來看（Verification as the New Bottleneck、Review as the Control Point）：

• **完全自動化：機械式驗證。**風格、lint、明顯錯誤、對照簽入的規格檢查規格偏移、測試——只要驗證器是確定性或接近確定性的，自動化就只有好處，而且已是 Claude Code 團隊的既有做法。
• **有爭議且未經測量：自動化的品質／安全性判斷。**P9 確實存在爭議——一派引用約 82% 的預置錯誤攔截率，另一派則指出「能抓到風格問題，卻漏掉負載下的競爭狀況這類問題」，還會製造錯誤信心。供應商自己宣稱 Opus 5 審查的精確率／召回率，但那是未經測量的一手宣傳，無法解決爭議。完全自動化確實能穩定提升吞吐量、降低延遲（P8）；但沒有人證明它能提升品質。
• **目前證據顯示永遠無法完全自動化：審查除了找出缺陷之外的功能。**人類深入審查，是審查者培養技能的方式（P12/P13：「你還不會建構的東西，要怎麼審查？」）、也是形成共同責任歸屬和知識傳遞的方式（P14：「如果沒有人類深入審查邏輯，就沒有人真正負責它」），還能讓理解債務逐步償還，而非不斷累積（P15）。即使自動審查者抓出了每一個錯誤，這些功能仍會因自動化而弱化——決定「自動化到什麼程度」的真正限制不是缺陷偵測，而是責任歸屬和技能傳承。

因此答案有明確形式：**把機械式檢查全部自動化；人類則對依風險分級、經過抽樣的一部分深入審查，以維持理解和技能，而不是重新檢查機器。**界線位置取決於理論中的調節因素（自動審查者能力、流程校準），也因此不存在固定值，調節因素的門檻仍是待測量的問題。

回答 4：部分屬於類別錯誤，但並非全然如此#

是，Faros–DORA 衝突中比較明確的部分屬於類別錯誤。調查衡量的是主觀生產力（真實情況：個人任務完成量確實增加，因此感受並沒有錯）；遙測衡量的是系統結果（佇列、事故、審查延遲），這些尚未反映在主觀感受中。在快速轉變期間，兩個層面的結果確實可能分歧；這就是 Faros 所說的「感受落後於現實」機制，若對稱地理解，而不是拿來判定誰勝出（Telemetry vs. Survey Measurement）。AEI 將每個人的遙測資料與調查結果連結的設計，已經把兩者視為互補資訊；CMU 研究則指出為何兩種工具都不能「勝出」：即使不是供應商提供的遙測資料，在沒有審查目的之因果模型時，方向也不穩定（Review as the Control Point——Pearl 說「資料非常愚鈍」）。兩種工具、兩個層面，兩者都成立——大部分「矛盾」因此消失。

剩下的部分不屬於類別錯誤：**成熟度保護論。**DORA 說扎實的基礎能提供保護；Faros 則說它的遙測資料顯示並非如此。這是針對同一層面（系統結果）的同一命題，實質爭議仍然存在——Faros 的說法符合其供應商利益；CMU 的調節因素理論主張方向由團隊決定（較接近 DORA），但沒有測量成熟度的效果。釐清類別錯誤能整理辯論的框架，卻不能解決其中唯一真正的歧見。

回答 5：兩者兼具——範圍差異確實存在，樂觀偏誤也無法排除#

Ng 與 Faros 的分歧（The Three Loops of AI-Native Building 與 Acceleration Whiplash）不必二擇一：

• **範圍差異解釋了大部分現象。**在個人從 0 到 1 的建構中，錯誤建構的外部成本近乎零，代理程式的自我測試足以充當驗證器，也沒有審查佇列、事故預算，或必須在一年後理解差異內容的維護者。讓生產環境審查成本高昂的功能（回答 3 所述的責任歸屬／理解功能）幾乎不存在，因此 QA 負擔確實可能下降。Ng 所說的「不再負責 QA」，對他的工作情境而言是合理的。
• **樂觀偏誤也有記錄，而且正好適用於這類主張。**Ng 的證據是自陳的主觀負擔——這類工具會落後於系統現況，如回答 4 所述；自陳沒有學習缺損，但隨機測量發現進步已消失（The Automation–Optimism Link、Experimental Learning Impact of Generative AI）；也可能在人們感覺更有生產力的同時，錯誤率卻在攀升（AI Brain Fry）。自陳中所謂「大幅減少」，只是帶有已知樂觀偏差的主觀感受，不是測量結果。

因此，非此即彼的問題可以化解：範圍差異解釋了為何 Ng 的負擔可能真的比較低；偏誤研究則說明他的報告無法量化負擔。現有的裁決原則不變——就組織情境而言，Faros 的遙測資料優於兩方的實務者意見；CMU 的趨同發現則補上組織面唯一較正向的資料：團隊會學會審查代理程式產生的程式碼，因此負擔趨勢並非註定一路惡化。仍缺少能解決問題的證據：從 0 到 1 的建構者 QA 時間序列，目前沒有任何來源提供測量結果。

補充說明（2026-07-29）：第四層證據，並且關乎回答 2 和 3#

本綜整完成後才彙整的 Security Debt of Agent-Generated Code（Sakib 等人，arXiv 2607.12428，empirical），對兩個答案略有補充——並非推翻它們，而是提供原本論證缺少的結果層級證據。

• 回答 2 增添第四層。前面引用的三層證據分別是實驗（錯誤率）、遙測資料（未審查筆數）、論述（作用機制）。三者衡量的都是橡皮圖章出現的條件。這份研究則測量特定產出上的後果：在 4,022 個代理程式 PR 中發現的 74 組真實有效憑證，有 81.1% 未收到任何機器人或人類審查者的留言便進入整合；而且其中 67.6% 是由人類而非代理程式提交。橡皮圖章風險不再只能透過工作負荷和錯誤率等替代指標推斷。（構念限制：論文以「審查者曾留言」判定審查者是否發現；未留言的機密資訊中仍有 60 組遭到移除。可站得住腳的說法是「整合前沒有留言」，而不是「未被發現」。）
• 回答 3 的分工仍然成立，但第一個子句從現況描述降為行動建議。「將 100% 的機械式檢查自動化」聽起來像是已經做到的事。硬編碼憑證是最容易以機械方式偵測的問題類別，樣本中也出現七種不同的商業偵測器，但它們加起來只對 18.9% 的有效憑證留言。機械式驗證是可以自動化的部分，不是已經自動化的部分。
• **回答 1 對趨同的樂觀預期需要加上限定。**三類接受方式將「經審查後未回退」（第二類）視為委派順利運作。這個來源顯示，第二類可能包含實質上未受審查的 PR：涵蓋率趨同不等於成效趨同；即使 PR 有審查者掛名，仍有五分之四的情況會帶著有效憑證合併。

補充說明（2026-07-29）：回答 3 的部署校準，以及對回答 1 更精確的解讀#

Risk-Tiered Auto-Approval（PostHog 的 StampHog，case-study）是知識庫中第一個實際部署的案例，採用回答 3 所建議的分工方式；不過它的具體做法和原先建議略有差異。

• 回答 3 的界線取決於檢查種類，而非檢查品質。這種分工把「機械式驗證」與「品質／安全性判斷」分開——區分的是檢查內容。StampHog 的分工則看負責檢查的是什麼：三個確定性關卡（PR 狀態、阻止清單中的爆炸半徑關鍵字、<500 行／<20 個檔案的上限）負責決策，最後才由 LLM 執行，而且只允許它收緊條件。這條界線比回答 3 提出的更嚴格，但對同一批證據而言，是站得住腳的回應——回答 3 標示為有爭議的判斷層，正是這個設計不讓它主導決策的層面。
• 回答 1 增加第四類，讓統計更完整。三類接受方式沒有納入明確、公開條件、有記錄的免審查。StampHog 取代的是 Slack 上的蓋章往返流程，其中未參與工作的工程師會核准「幾乎完全不了解背景的變更」——這其實早已是披著簽名外衣的單純未回退。將它自動化之後，未審查的部分變得可列舉，判定條件也可稽核；統計方式嚴謹得多，但監督並未因此改善。由此可推知，解讀相關數字時要小心：「代理程式核准了三分之一的已合併 PR」不代表「三分之一的審查工作已自動化」，因為其中很大一部分原本只是儀式。
• **這個案例研究無法提供的內容。**沒有誤核准率，也沒有漏網缺陷筆數。回答 3 的爭議區域（P9）仍然存在爭議；這個案例增加的是部署證據的規模，而不是測量資料。可供檢驗的對照，存在 PostHog 自己的歷史紀錄中——自動核准的 PR，對照該頻道過去產生的人類蓋章基準。

補充說明（2026-09-02）：第五種驗證類型，來自審查對象是判定結果的領域#

Autonomous Defense 的母體來源 （Prophet Security's State of AI in the SOC 2026， vendor-claim、由供應商委託的調查，n=250 名安全領導者與實務者，由 ViB 執行調查，所有數字皆為自陳）提出了一個本綜整一直缺少資料的問題：不是「輸出是否經過審查？」而是**「團隊如何確認模型本身是對的？」**對AI 使用者進行複選後，調查結果形成五類分布：

驗證做法	AI 使用者占比
人類在結案前審查每個判定結果	57%
資深分析師抽樣抽查	40%
以已標註資料集或紅隊演練進行基準測試	32%
依賴供應商回報的準確率指標	19%
沒有正式流程	5%

這帶來三項改變，依照重要程度排列。

**回答 1 需要第五類，而且它根本不在審查軸線上。**三類分工（明確採用／經審查後未回退／單純未回退），以及 StampHog 補充說明新增的第四類（明確、公開條件、有記錄的免審查），都描述了審查者如何處理特定輸出。19% 描述的則是另一回事：**把驗證委託給賣方。**組織對系統準確性的信心，來自受驗證方所提供、屬於 vendor-claim 等級的數字，且它完全沒有對應到任何特定輸出。這不是比較不嚴格的審查，而是以另一種做法取代審查；這也是第一個關於它有多普遍的母體估計——約五分之一。

**回答 3 的分工找到一個已有多數採用其建議做法的領域，但效果仍未測量。**建議是「將 100% 的機械式檢查自動化；人類則對依風險分級、經過抽樣的一部分深入審查。」SOC 中有 40% 採用資深分析師抽樣抽查，正是已部署的這種做法；32% 以已標註資料集進行基準測試，則是資料集裡最接近缺漏之成效測量工具的做法。但請留意最常見的答案：57% 仍然審查每個判定結果，這就是 P17 所預測、會拉長延遲的全面政策——然而在這個領域，自己的數據顯示約 28% 的警示根本沒人查看。在 100% 審查自動判定結果的同時，佇列中卻有 28% 未經調查，這是本綜整中最鮮明的例子，呈現審查力氣如何依照儀式而非風險分配。

**回答 2 對橡皮圖章的診斷，首次出現在利害關係完全顛倒的領域。**在程式碼審查中，橡皮圖章式失效會造成缺陷隨程式碼一起上線。在這裡，失效則會產生一張已結案工單；即使 AI 完全沒有介入，這份調查也提供了該失效的基準發生率：60% 的受訪者表示，自己忽略或從未調查的警示後來被證實具有重大影響；34% 表示十二個月內發生過三次以上。因此，SOC 中「人類名義上做決定，實際上只是蓋章」的情況有自動化前的測量基準，而程式碼領域的議題群從未有過。但它仍然缺少和本頁其他地方相同的資料：57% 的效能數字——調查只報告審查有沒有發生，從未說審查抓到了什麼。

以上四種解讀都必須連同證據等級來看。這是賣方針對其銷售市場進行的調查，所有資料均為自陳，且調查方法藏在名單開發表單後方；它能證明的是團隊自稱如何行事。對於實務問題，這是合適的工具；對於效果問題，則不合適。

綜合結論#

五個問題呈現同一套三步模式，可用來化解這場辯論：(1) 拆分構念（將接受拆成三種行為；將審查拆成抓出缺陷與責任／技能傳承；將「矛盾」拆成不同層面；將非此即彼拆成作用機制與程度），(2) 依照工具能看見的內容衡量證據權重（自陳能看見感受，遙測能看見行為；兩者都無法在欠缺因果模型時看見原因），(3) 重新定位控制措施：只有在人類監督經過重新設計時，對 AI 撰寫程式碼的監督才仍是真正的控制措施——採用三類接受方式的統計、以理解為關卡的合併條件、針對依風險分級之抽樣部分深入審查，並將所有機械式檢查交由自動化負責。若將審查力氣平均分散到代理程式規模的工作量上，那只是戴著審查徽章的橡皮圖章。