依風險分級的自動核准

資料來源#

• Deploying AI from pilot to production: A practical blueprint for CIOs and technical leaders
• Not All Agents Are Equal: Code Quality and Post-Merge Maintenance Across Five Autonomous Coding Agents in the Wild
• State of AI in the SOC 2026: 8 Key Takeaways
• Stop being the code review bottleneck
• The Speed Trap: 8 takeaways from our latest AI engineering research
• The State of AI Impact in Engineering: Q2 2026

摘要#

依風險分級的自動核准是一種合併閘門，會根據差異的低成本結構屬性，而非對其正確性的判斷，決定這個 PR 是否真的需要人類查看。PostHog 的實作 StampHog 由 Jina Yoon 在 PostHog 電子報中於 2026 年 7 月介紹，是此知識庫首個有紀錄、且大規模投入正式環境的案例：一季之內，它對 PostHog 主儲存庫約三分之一的合併 PR 給予最終核准，並在單月處理了 1.6K 個 PR。

這是 CMU 的審查理論在 P17 中所命名構想的實際部署形式：只對重大變更設閘的風險分級治理政策，能降低審查延遲；對所有項目一律設閘的政策則會提高延遲。該頁指出這個調節器確實存在；這份來源則展示其中一種校準方式如何在真實合併佇列中運作。

證據說明。 case-study——團隊為推廣這種做法而撰寫、介紹自家工具的第一方敘述。處理數量（三分之一、每月 1.6K）是團隊能可靠統計的數字，且看不出有明顯灌水誘因。但這份敘述從未提供安全性最關鍵的數字：**沒有誤核准率、沒有逃逸缺陷數，也沒有事故歸因。**機制有文件可查，成效則尚未測量。

閘門堆疊：先確定性檢查，模型最後出場#

工程師新增 stamphog 標籤，讓 PR 進入自動核准流程。接著執行四項檢查：

1. PR 狀態——沒有合併衝突，沒有尚未處理的要求變更審查。
2. 爆炸半徑——關鍵字封鎖清單（驗證、機密、計費、公開 API，等等）。命中任何一項就交由人類處理。
3. 差異大小——少於 500 行、20 個檔案。
4. 簡單的 LLM 檢查——「用來找出基本的重大問題」。

順序就是設計所在。四道閘門中有三道，是差異與儲存庫的確定性屬性；模型則最後才檢查已確認規模不大、且未觸及敏感清單內容的變更。這和 AI 程式碼審查的預設架構相反：通常模型是偵測器，它的判斷是差異能否合併的最後關卡——而 P9指出，這種安排對品質的影響確實仍有爭議。在這裡，模型是對已縮小範圍的集合行使否決權，而不是負責縮小範圍。這與安全領域的「預防，不要偵測」採取相同的結構性做法，只是從提升吞吐量的角度獨立推導而來。

兩種結果都刻意保持簡潔：核准時只給出沒有行內註解的 GitHub 核准（明確表示這不冒充審查）；拒絕時則提供一到兩句理由、風險等級評定及後續步驟。

三項不變條件#

PostHog 自己的移植提示詞，明確寫出希望原樣保留的安全契約：「失敗時封閉，不得要求變更或合併，LLM 可以收緊閘門，但不能放寬。」

• 失敗時封閉——有歧義時交由人類處理，因此閘門故障的結果是延遲增加，而不是未經審查便合併。
• 絕不合併，也不要求變更——代理程式的權限被限制為一種動作：核准。它不能提交程式碼，也不能用要求變更的審查阻擋人類的 PR。可對照 Claude Code Auto Mode：其中分類器的權限同樣只有單一方向（可以封鎖工具呼叫，不能解除禁用工具的限制）。
• 模型可以收緊閘門，但不能放寬——這種不對稱設計可避免容易受說服的元件變成攻擊面。若 LLM 只能將決策推向更多人類介入，就無法被差異中的內容哄騙而核准；一般情況下，差異是攻擊者可控制的內容（Agentic Prompt Injection）。

升級處理是路由，而非封鎖#

拒絕不會把 PR 丟回佇列，而是轉交給領域專家；對象依據「CODEOWNERS-soft 和 git-blame 熟悉度」選出。因此，閘門真正提供的是注意力分配決策，而非核准——它將合併流程分為「沒有人需要查看」與「應由這位特定人士查看」兩類。這是將監督疲勞的緩解方式（「將審查集中在高風險決策點，而非每個輸出」）落實到合併關卡的做法，也說明了吞吐量提升不只是單純減少工作：工程師原本花在 1.6K 個低脈絡印章上的注意力，現在可以用在升級處理的其他 PR 上。

它取代了什麼，會影響我們如何解讀#

StampHog 推出以前，PostHog 使用 Slack 頻道（#dev-stamp-exchange，附有排行榜）：工程師貼上 PR，等人核准。Yoon 對其成本的描述是：「每蓋一個章，就要另一位工程師中斷手上的工作，去核准一項他幾乎毫無脈絡的變更。」

這讓自動化取代的對象有了不同的面貌。被交給機器的不是實質審查，而是早已幾乎不含資訊、且由當下可用人選中最不了解情況的人執行的核准儀式。在 Is Human Review of AI-Authored Code Still a Real Control, or Already Rubber-Stamping?的三分式接受結果分類中，蓋章交換早已接近於披著簽名外衣的僅未撤銷。

因此，最公允的解讀是：StampHog **把隱性的橡皮圖章，轉成明確記錄、經閘門檢查的橡皮圖章。**這確實改善了可追溯性——現在能列出自動核准的項目、標準有明確記載，封鎖清單也是可供檢視的產物——但這並不表示自動核准能取代原本有實質作用的審查。把「三分之一的 PR 由代理程式核准」解讀為「三分之一的審查已自動化」是過度推論；其中很大一部分原本只是儀式。

依本地情況校準，否則封鎖清單只是裝飾#

PostHog 的移植提示詞拒絕直接提供門檻：「他們的封鎖清單和門檻是依自己的程式碼庫校準的——請為我重新推導：從我的 git 歷史中找出高爆炸半徑的封鎖候選項目，並依我已合併的 PR 校準大小／級別上限。」

這是影響最大的實務注意事項。兩道有區別力的閘門都依賴單一儲存庫的經驗事實：哪些識別字代表危險，以及在該程式碼庫已合併 PR 的分布中，「小」代表什麼。把某個儲存庫的封鎖清單複製到另一個儲存庫，就會比對錯誤字串；把 500 行上限套用到 PR 中位數只有 40 行的儲存庫，則幾乎什麼都擋不住。可移植的成果是推導程序（從歷史中找出爆炸半徑候選項目，依已合併 PR 的分布設定上限），而不是設定值本身。

還要重新校準：上限所依據的分布正在變動#

移植提示詞要求依已合併 PR 校準大小上限，但沒有說要重新校準，而且周遭的分布並未停滯。DX 的 2026 年第二季調查（vendor-claim，500 多個組織）指出，PR 大小中位數在 2026 年第一季至第二季之間幾乎翻倍；這也從曆時變化而非採用程度的橫斷面，印證了 Faros 的 +51.3%。

分布上升時，固定上限會在不知不覺中失去涵蓋率。沒人修改設定，也不會出錯，只是能通過 500 行、20 個檔案門檻的合併流程占比逐漸縮小——因此，**「約三分之一的 PR」描述的是某一季的測量結果，不是這套設計的固定屬性。**由此產生兩個方向相反的結果：

• **涵蓋率下降是安全的。**失敗時封閉的閘門涵蓋率縮小，造成的是延遲，而非未經審查的合併。這個不變條件證明，即使面對設計者未曾提及的威脅，仍能發揮作用。
• **這讓堆疊式 PR 實務成為不可或缺的支柱，而非選配。**只有在作者端積極把差異規模往下壓，大小閘門才會持續有用；否則分布會逐漸超出上限，閘門也會悄悄失去作用。拆解工作才能讓適合自動核准的範圍維持開放。

實務上，應將上限表示為該儲存庫近期已合併 PR 分布中的百分位數，並定期重算，而非設為固定值——這也能讓上限與16.2% 至 53.6% 的異味梯度保持一致，因為該梯度是絕對差異大小的事實，不會因中位數改變而移動。不過，移植時仍要注意：DX 衡量的是跨產業調查樣本的中位數，而非 PostHog 的儲存庫，也沒有來源測量任何特定儲存庫的分布是否改變。

第三項測量，而且差距正在加速擴大（2026-09-22）。Faros 的 The Speed Trap（The Speed Trap: 8 takeaways from our latest AI engineering research，vendor-claim，22,000 名開發者／4,000 個團隊）指出，在兩個已高度採用 AI 的時期之間，PR 平均大小增加 +71.8%；這比先前報告衡量採用深度時的 +51.3% 更快。開發者「觸及更多檔案和更廣泛的程式碼庫範圍」，而且報告認為 AI 輔助變更的規模如今已永久超出人類速度下的基準。現在，三種不同對照方式（採用程度橫斷面、曆時調查、期間對期間）都指向相同方向，因此上述悄然衰減的問題是預期情況，而非偶發風險。使用這項結果時有兩項限制：它衡量的是平均值的成長率，沒有公布絕對中位數，因此無法換算成任何儲存庫的涵蓋率；同一來源還指出，同一期間每次變更的事故成長率正在減速，所以規模分布上升本身並不能證明閘門所隱含的假設（大差異風險較高）確實成立。實務結論並未改變，現在得到更有力的支持：上限應設為百分位數，並讓工作拆解成為不可或缺的做法。

另有一點值得個別記錄，因為 Faros 以供應商身分提出了本頁的設計：Faros 對未經審查合併的補救建議——這項指標期間對期間成長 +76.3%，前次為 +31.3%，應解讀為成長率而非占比——是不要讓臨時跳過審查逐漸僵化成預設做法，而要設定明確、依風險與範圍決定的審查要求；這正是本頁用文字描述的閘門。其第 8 項結論將代理式審查列為首個值得期待的對策（高度採用團隊的首次審查較快、變更失敗率較低），但兩項主張都沒有百分比，且明確標示為相關性，並承認即使代理式審查採用程度高，未經審查的合併仍持續增加。這是處方，而非部署：沒有涵蓋率數字，沒有逃逸缺陷率，也沒有回答本頁第一個開放問題所需的資料。

大小上限成了供應商篩選器，只是當初沒人這麼打算#

Kraishan（arXiv 2609.17598）首次提供大型代理式語料中，各產品 PR 大小的分布，而偏斜程度足以改變大小閘門的意義。跨 2,807 個公開儲存庫的 37,623 個 PR，其變更行數中位數為：人類 52、Devin 61、Codex 63、Copilot 76、Cursor 96——Claude Code 495。

套用 500 行／20 個檔案上限，這不是分級篩選器。它會放行四種代理程式以及人類的 PR 中位數，並擋下第五種代理程式幾乎所有 PR。在此分布下，依差異校準的閘門實際上就是依供應商設定的閘門——而且會悄悄如此，因為設定中根本沒寫入供應商。這會影響本頁的兩種解讀：

• 涵蓋率數字會隨工具組合而變。「約三分之一的已合併 PR」是某一季的測量結果，也取決於 PostHog 工程師當季使用哪些代理程式。如果團隊改用預設 PR 大小高出一個數量級的產品，自動核准占比就會在設定完全不變的情況下崩跌；這與上文中位數上升問題造成的悄然衰減相同，只是從另一個方向發生。
• **這樣做是否妥當，仍沒有定論。**就安全性而言，Claude Code 的 PR 最值得封鎖（9.5% 至少含有一項異味，人類為 4.6%）；但就維護而言，它的 PR 最不值得封鎖（任何群組中合併後每行變動率最低，δ = −.33，每 100 行變更的後續提交中位數為 0.5，人類為 5.3；90 天回復率為 10.5%，與人類無法區分）。大小閘門隱含的假設是大差異有較高風險；在唯一能區分大小與結果的產品上，兩種結果軸對這項假設是否成立給出了相反答案。

同一篇論文依大小分層的檢查也有相同結果。所有代理程式與人類合併計算的安全異味密度優勢，完全出現在 XL PR 區間（Cliff's δ = −.08，p =.025），較小的四個區間則沒有差異——因此，就這項指標而言，代理程式最大的 PR 相較人類表現最好，與通常用來支持大小上限的16.2%→53.6% 出現率梯度方向相反。出現率和密度是不同數量，兩者在形式上並不衝突；然而，以「差異越大越糟」為由設閘，如今得倚賴其中一項，卻被另一項反駁。

以上都有論文本身特別指出的混淆因子：供應商與任務組合交纏在一起，因為儲存庫與使用者會自行選擇要用哪個代理程式、處理什麼任務。Claude Code 的 495 行中位數，可能更多反映人們交辦給它的工作，而非它實際寫出的內容。

上游配套：縮小差異以符合閘門#

來源中的第四種模式把大小閘門變成設計限制，而非篩選器。Daniel Visca 的原則是觀察優於推理：「代理程式很會解釋程式碼為何能運作。這種解釋往往很有說服力……卻也是錯的。」因此，能觀察行為時就不要只接受論證。要觀察 3,000 行的 PR 並不可行，所以代理程式會被指示把工作拆成一連串小型、單一用途的 PR（目標 <400 行變更，透過 Graphite 堆疊），每個 PR 都能獨立執行，並附上「執行的指令和預期輸出」，由下而上合併，讓每一層都只建構在已觀察過的行為之上。

這兩種模式可以搭配使用，來源也明確這麼說：拆解工作「讓 StampHog 能像第 3 節所述，自動核准小而聚焦的 PR。」結果是兩種不同類型的檢查——代理程式推理程式碼，人類觀察程式碼執行——而非用相同方式檢查兩次。這是合併佇列中代理程式對自身解釋是最弱可用證據的實例，也是對大小閘門明顯異議（「大多數真實工作都超過 500 行」）的實務解答：改變工作單位，而不是提高上限。

與已測得的偵測下限存在張力#

Agent-Generated Code 的安全債務（Sakib 等人，arXiv 2607.12428，empirical）測量了這套設計所要把關的表面，而且結果正反兩面都有。兩者有重疊之處時，實證來源的證據力高於本案例研究——前者是對 4,022 個 PR 進行編碼分析，後者是沒有成效測量的第一方敘述——所以下列兩種解讀都是將論文結果套用到 PostHog 設計上。

**它大力支持大小閘門。**代理式 PR 中安全異味的盛行率隨變更規模單調上升，從 1 至 9 行 PR 的 16.2% 上升到 1000 行以上 PR 的 53.6%。500 行／20 個檔案的上限將自動核准限制在低盛行率區間，而堆疊式 PR 則刻意把工作沿著該曲線往下推。這是獨立於供應商、且來自實證研究的支持，證明堆疊中看起來最武斷的閘門有根據——也正是 Faros要求、卻無法提供的依大小分層證據。

它強烈削弱封鎖清單的正當性。封鎖清單依業務風險主題整理（驗證、機密、計費、公開 API）。實際測得的異味主要出現在別處：82.3% 屬於供應鏈完整性問題——可變動的動作標籤、未固定版本的安裝；而所有異味中有 87.6% 位於 GitHub Actions 工作流程和 Dockerfile，這些檔案看起來像樣板，也不會命中任何業務風險關鍵字。在一個 30 行的工作流程差異中，未固定版本的 actions/checkout@main 可以通過 PR 狀態檢查、通過封鎖清單、通過大小閘門，最後只剩 LLM 的重大問題檢查作為防線——然而，在最容易以機械方式偵測的異味類別（存在七種不同的商用偵測器）中，對真正有效的憑證，該檢查的實測表現只是留下評論的比例為 18.9%。以應用程式風險直覺建立的封鎖清單，正好看不見建置與部署管線；而實際債務正是在那裡累積。

因此，具體建議是：.github/workflows/、Dockerfile 和 IaC 路徑都應以路徑形式加入封鎖清單，不依賴關鍵字。PostHog 自己要求從 git 歷史中挖掘封鎖候選項目，很可能會找到這些路徑；直接複製一份業務風險關鍵字清單則永遠不會。

另一種判定條件：「測試涵蓋了這項變更」#

封鎖清單是爆炸半徑的替代指標，而顯而易見的第三種替代指標——現有測試套件已經測到這個差異——是這個領域唯一根據變更本身的事實，而非對變更的猜測的閘門。Dipongkor 等人（arXiv 2607.18057，empirical）以 4,882 個代理式 PR 衡量其代價，發現代價很低：現有測試會執行 Java 中代理程式變更可執行行數的 61.5%，以及 Python 中的 27.0%；而 64.8% 的 Python PR 沒有任何變更行被任何既有測試執行。作者給實務工作者的建議正是這項發現的否定形式：「使用代理式 PR 的團隊不應假設測試通過，就代表變更已受測。」

這對閘門堆疊有兩種相反的意義。

**對目前的堆疊不利：**綠燈 CI 執行結果目前在「PR 狀態」檢查中默默發揮作用，也存在於每位審查者的先入判斷中；但對 Python 代理式 PR 來說，它幾乎無法說明差異是否受測。四道閘門留下的任何「至少測試通過了吧」信心，依這項測量來看，大多沒有根據。

**支持擴充堆疊：**與關鍵字封鎖清單不同，差異涵蓋率是直接從差異計算出來的。它無須依程式碼庫的詞彙校準，不會因變更看起來乾淨而被解除，也會產生數字而非判斷——因此屬於和大小上限並列的確定性層級，而非置於 LLM 否決權之後。最直接的做法是設最低標準（只有每一行新增的可執行程式碼都由某項測試執行過，才自動核准），而且它與大小閘門互補，不會重複：PR 大小預測風險有多大，涵蓋率預測是否有任何測試在監看。代價是論文無法估計的部分——涵蓋率門檻可能會大幅縮小適合自動核准的範圍，比路徑封鎖清單縮小得更多，因為超過半數的 Python 代理式 PR 都會直接不合格。

請注意，這項研究測量的是與安全研究相同的開源代理式 PR 母體，也有同一項缺失（沒有人工撰寫 PR 的基準組），而且沒有按 PR 大小區分涵蓋率——因此無法判斷 StampHog 實際自動核准的小型差異，其測試涵蓋率比語料平均高或低。

不依差異分級，而依異常分級：控制區間（Anthropic，2026 年 8 月）#

以上每道閘門都依據變更的屬性分級。Anthropic 的 Applied AI AI-Native SDLC playbook（vendor-claim，2026-08-21）提出相同階梯，但依據正式環境的屬性設定，適用於代理程式發起而非人類交辦的工作。受版本控制的 bands.yaml 會針對一項分布穩定的指標，依其移動基準設定回應級別（CI 測試失敗率、部署後 5xx 比率、PR 週期）：

• 1σ——只記錄。
• 2σ——以 唯讀 模式呼叫 Claude 進行診斷，工具清單明確列於設定檔（Read,Grep,Bash(gh run view *)）。
• 3σ——Claude 可以採取行動，但只能透過兩條預先核准的途徑：向現有審查閘門提交 PR，或觸發事先核准的操作手冊。

有三項設計選擇值得帶到合併閘門中，三者都只是重述本頁自己的原則：

• 偵測器不是模型。「偵測全程採用確定性方法，不涉及模型」——一個經過單元測試、受版本控制的指令碼，使用移動平均值／標準差搭配 Western Electric-style 規則，同時偵測漂移與突升。閘門會呼叫模型，但模型本身不是閘門。這和此處將 LLM 降為最後一道否決權完全相同，也與工具邊界的確定性優先順序一致。
• **級別決定可採取的行動範圍，而非信心門檻。**嚴重程度越高，代理程式獲准使用的途徑越多，而不是在同一途徑內獲得更多自主權；即使升到 3σ，輸出仍是由程式碼負責人核准的 PR。這與否決權相同，都是單向授權：升級處理是路由，而非解除阻擋。
• **駁回結果會調整控制區間。**分類結果會回饋到門檻設定，這正是此處封鎖清單欠缺的校準紀律。

它與 StampHog 一樣面臨證據缺口，情況甚至更糟：手冊完全沒有報告任何部署，因此級別邊界沒有觀察到的誤判率、沒有雜訊預算，也沒有說明 2σ 診斷是否值得花費相應 token。以 σ 分級也引入封鎖清單沒有的假設——指標基準是固定的——而本頁自身談到的分布變動問題（環境中的 PR 大小增加，導致大小上限逐漸失效）就是直接類比：30 天移動基準會吸收緩慢退化，而非因此觸發；這正是加入 Western Electric 規則要捕捉的漂移，也是最難調校的部分。

**案例研究報告的是處理量，不是安全性。**三分之一和 1.6K 都是吞吐量數字。P8/P9正好呈現這種區分——自動化審查可靠地提升吞吐量、降低延遲，但對品質與安全的影響仍有爭議；StampHog 是大規模部署、卻沒有任何測量結果佐證的爭議案例。要解決這個問題，所需的資料既便宜又欠缺：自動核准 PR 的逃逸缺陷或事故率，與該 Slack 頻道過去產生的人工蓋章基準相比如何。

第三種分級依據：回應的可逆性（安全營運，2026-09-02）#

本頁已經有兩種分級依據——變更的屬性（StampHog 的大小上限和爆炸半徑封鎖清單），以及正式環境的屬性（Anthropic 的 σ 控制區間）。安全營運提供第三種依據，也首次呈現團隊實際採用的分級方式及其母體分布。

Prophet Security 的 State of AI in the SOC 2026（vendor-claim，由供應商委託的調查，ViB 訪問 n=250 位安全主管與實務工作者，所有數字皆為自陳）詢問使用 AI 的 SOC，會賦予分類模型多少自主權。答案總和為 100，因此這是一個單選階梯：

賦予的最高自主程度	AI 使用者占比
僅讀取分類結果	13%
建議操作，由人類執行	44%
自動執行低風險操作	30%
自動執行中風險操作	13%
完全無監督的自主運作	0%

分級依據是操作有多難復原——隔離、撤銷憑證、終止工作階段、變更存取控制——而非輸入規模有多大或有多敏感。這與本頁前兩種依據不同，而且可以從工具呼叫本身計算，而不是從產物推測：操作的級別是所呼叫 API 的固定屬性，無須依程式碼庫詞彙校準，也不會隨基準漂移。它與差異涵蓋率同屬確定性級別，且不像關鍵字封鎖清單，無法被看起來乾淨的內容解除。

哪些部分能移植，哪些不能。整體形式完全可以移植——一開始就採用確定性分級、限制模型只能使用部分核准途徑、以路由升級而非直接封鎖。但分級程度無法照搬，原因也正是依據不同：合併自動核准位在 CI 和一條指令即可回復的操作之後；自動執行的圍堵操作會直接影響客戶，而且通常不可逆。若將「SOC 中有 0% 完全自主」與「StampHog 核准三分之一已合併 PR」解讀成膽量差異，就弄反了；兩者是同一調節器對應兩種設定，因為操作的復原成本截然不同，而這正是以可逆性為依據的分級要處理的問題。

這份調查還提供了一個本頁一直缺少的數字，但來自錯誤領域。在 AI 使用者中，19% 以供應商回報的準確度指標作為驗證方式（相比之下，57% 要求每項判定在結案前由人類審查、40% 會由資深人員抽查、32% 會與標註資料集或紅隊演練結果比對、5% 沒有正式流程——此題可複選）。本頁一再指出 StampHog 報告了處理量，卻從不報告成效；在 SOC 中，約五分之一的團隊透過接受銷售方提供的準確度數字，代替自行測量來填補相同缺口。這不是控制措施，而是以 vendor-claim 取代應有的測量；若沒有人進行前後比較，下面所列「沒有逃逸缺陷率」的疑問就可能走向這種結果。

第四種分級依據：輸出造成的後果（Anthropic × Accenture，2026-09-11）#

本頁已有三種依據——變更的屬性、正式環境的屬性，以及操作的可逆性。[Claude × Accenture 的 Deploying AI from pilot to production]( [[raw/claude-accenture-pilot-to-production|Deploying AI from pilot to production]]（Anthropic × Accenture，vendor-claim）補上第四種依據：輸出進入流程後會造成什麼影響。這也是本頁第一個為非程式碼企業工作流程設計，而非為合併佇列或 SOC 設計的分級方式。

級別	監督方式	使用案例	審查週期
1. 自動化	無人工審查；輸出直接進入工作流程	摘要會議逐字稿；在系統間重新格式化資料；產生程式碼文件	每季稽核輸出品質
2. 抽樣	按固定週期隨機抽取部分項目審查	從發票擷取結構化資料；分類客服案件；依通話逐字稿填入 CRM 欄位	每週審查一部分；初期抽查較多，待錯誤模式穩定後再調整
3. 審核	每項輸出都由人類核准後才交付受眾	撰寫客戶溝通內容；供外部使用的財務分析；依範本撰寫合約條款；行銷內容	每項輸出發布前都須審查；每月稽核審查流程的錯誤捕捉率與成本
4. 建議	AI 提供分析，由人類做決策並產出結果	信用與貸款建議；候選人篩選；供醫師審閱的臨床發現；準備法規申報資料	每項決策都須留下稽核軌跡；每季進行合規審查

此處的判定依據既不是產物大小，也不是操作的復原成本，而是輸出會觸及誰，以及接收者會如何使用——因此「產生程式碼文件」屬於第一級，「撰寫客戶溝通內容」屬於第三級，儘管兩者都是文字生成。值得注意的是第四級：它不是更嚴格的審查，而是不同的架構——輸出由人類產生，因此根本沒有 AI 輸出可供審查；閘門被移到產物上游，而非放在產物之前。

**週期欄補上了本頁原本欠缺的部分。**本頁先前提到的每種依據都規定了哪些項目需要審查，卻沒有一種說明多久重新檢視一次分級本身。這裡每個級別都有自己的稽核週期，而且明確表示級別可以變動：「如果某個流程長期維持低錯誤率，例如六個月或一年，就可能適合升到第二級。」把級別做成只會收緊的棘輪，正是下一節要指出的問題。

結構性阻力與檢查點稽核#

文件對監督為何會不斷增加的解釋，是其中最精闢之處：

「審查檢查點會不斷累積，因為增加比移除容易，而且移除檢查點的風險看得見，保留它的成本卻看不見。」

這種不對稱存在於清晰可見的風險與不易察覺的成本之間，也因此無論任何人的意圖如何，變化都只會朝單一方向發展。文件建議定期對每一道人工審查步驟進行三個問題的稽核，以作為對策：

1. 它實際能抓到什麼？
2. 審查者有多常改變輸出？
3. 每次審查的成本是多少？有什麼理由值得付出這筆成本？

捕捉率低、成本高，代表檢查點應該自動化、改為抽樣，或直接移除。第 2 個問題是關鍵，也是 Is Human Review of AI-Authored Code Still a Real Control, or Already Rubber-Stamping?用來區分真正控制措施與儀式的同一種測量——審查者從不改變輸出，就不算審查；這是語料中第一個將此寫成常態營運指標、而非批評觀點的來源。依文件自己的說法，這也是診斷 StampHog 前身問題的機制：一個從來沒有人測量捕捉率的核准儀式。

級別說明。以上全是沒有實際部署案例的供應商指引——文件沒有報告任何組織正在使用此分級階梯，也沒有級別分布或依其稽核方式測得的捕捉率。應將它視為有理據的分類法，而非證據。同一來源還提出另一個相關主張：有正式分攤成本責任的組織，會將 AI token 支出中的每一美元 32 美分歸因於量化的業務成果，是沒有成本分攤制度者的六倍。這是文件中最接近經測量的治理成果的主張，但測量的是成本歸因，而非監督成效。

相關連結#

• 分層監督——**第五種分級依據，分的是理解程度而非核准權。**P1 指出，組織對理解程度的容忍度會因使用案例而大幅不同：短期 UX 原型可能完全不需要開發者逐行理解；資料庫遷移或有嚴格復原時間要求的功能，則需要「精確理解每一個陳述」。其邏輯和本頁各種分級依據相同——監督資源依變更可能造成的損害決定，而非依變更大小——只是這裡分級的是人類必須理解多少，而非哪些變更可以無人看管地合併。五次訪談、自陳，沒有涵蓋率數字

• 自主防禦——安全營運中相同的分級階梯，以回應的可逆性為依據（見上節）：僅讀取 13%／僅建議 44%／自動執行低風險操作 30%／中風險操作 13%／完全自主 0%；由使用 AI 的 SOC 自陳，來自一份由供應商委託、訪問 250 位安全主管的調查。這是整個語料中第一個風險分級閘門的母體分布——本頁有一項部署，卻沒有分布——而且它是透過政策設定，而非閘門堆疊實現，因此級別以操作而非產物表述

• 正式環境中的代理程式流量錯位——本頁閘門所依賴的知情同意邊界，明確寫成判斷標準。明確命名的繞過方式（「提交時使用 --no-verify」）或代理程式指出閘門後使用者給出的簡短核准，都構成授權；「提交這個」、「趕快搞定」、「別問我問題」及一般性的自主權授予都不構成授權——*「使用者若根本不知道閘門或繞過方式，出於反射動作給予的核准就不代表知情意圖，不管聽起來多麼廣泛。」*專案文件若指示特定繞過方式，則算數；代理程式自行從含糊文件推斷則不算

• Same-Model Review Blindness——**免費且尚未採用的最後一道閘門強化方式。**四道檢查中有三道具確定性，第四道是最後才執行、用來找重大問題的 LLM 檢查，對象是程式碼代理程式產生的差異；設計中沒有任何條件限制使用哪個模型。Greptile 的配對資料集（case-study）指出，此選擇會讓重大問題召回率差 6 至 12 個百分點——每個前沿模型在自家模型家族產生的程式碼中抓到的錯誤較少——因此，讓否決權交由與作者代理程式不同家族的模型執行，比任何提示詞調整都有效，完全不花成本，也不需要像封鎖清單那樣依程式碼庫校準。同一來源為審查者面板提出的獨立性規格（「不同審查者使用不同模型與供應商」），也能以最低成本套用到閘門。要注意順序上的限制：否決權刻意排在三道閘門之後，因此這只會提升最弱的一層，不會改變傳送到該層的內容

• Agent Review Comment Resolution——為此設計兩項最少論述選擇提供獨立實證支持。分析 54,713 則代理程式審查意見後發現，行內程式碼建議是處理完成的最強預測因子（OR 1.62，75.5% 對 64.6%）；而評論長度會降低處理率，影響集中在功能回饋（OR 0.855）——這印證了 StampHog 的最簡輸出規則（只給不含行內註解的核准；拒絕時提供一到兩句理由、風險等級和後續步驟），不只是口頭宣稱。這也驗證了把模型降為否決權的做法：否決不會留下評論，因此沒有處理率可以損失，也避開了該研究拒絕案例中最常見的失敗——代理程式把團隊刻意如此設計的結果指稱為缺陷（有論證的案例中占 23.8%）。但它沒有提供本頁第一個開放問題所要求的逃逸缺陷數字；此處的採用率也不等於正確率

• 驗證成為新瓶頸——對該頁「全自動審查應該推進到什麼程度？」的部分式部署回答：只推進到低成本、結構性檢查能做到的程度，並將模型降為位於其後的否決權；不延伸到依模型判斷程式碼正確與否。該頁的 CircleCI 資料（vendor-claim）則把相同的先做低成本檢查原則提前一個階段：在內層迴圈執行 lint、單元測試與建置，讓失敗在幾秒內浮現；CircleCI 估計，50 人團隊交付成本中每年約有 ~$700K 可用這種方式省回來。兩者都是順序安排的論證——先做快速且確定的檢查，再做緩慢或機率性的檢查——差別只在低成本層所在位置（開發者迴圈或合併閘門）；兩者直觀的組合方式是：先通過內層迴圈的差異會以更乾淨的狀態進入 StampHog

• 審查作為控制點——P17（只對重大變更進行風險分級設閘）的實際部署案例，也是規模龐大、但未經控制的P9爭議案例：此處報告吞吐量（三分之一、每月 1.6K），卻未測量任何品質結果

• 代理程式供應商間的異質性——各供應商 PR 大小分布如何使差異上限變成供應商篩選器，以及篩選器的正當性為何如今受到質疑：最大的代理程式 PR 在安全異味密度方面勝過人類，而本頁引用的異味出現率梯度卻指向相反結論。它也提出可能的第五種分級依據——產生程式碼的產品本身；就此資料而言，相較於一組人類基準，該產品能預測 90 天回復機率，範圍從 0.50 到 1.31，差距大於任何差異結構屬性。不過，這反映的是代理程式本身，還是人們交給它的任務，仍是論文中未解的混淆因子

• 代理程式產生程式碼的安全債務——用於檢驗閘門堆疊的實證研究，結果正反兩面都有：16.2%→53.6% 的大小梯度支持差異大小上限；87.6% 的異味位於未命中任何業務風險關鍵字的 CI／容器檔案，揭露封鎖清單盲點；而 18.9% 的憑證評論率，則是 LLM 重大問題檢查若要涵蓋此盲點，所面臨的實測下限

• 代理程式產生測試的品質——經實測的另一種閘門判定條件（見上節）：現有測試會執行 Java 中代理程式變更行數的 61.5%、Python 的 27.0%，而 64.8% 的 Python PR 完全沒有測到任何變更行——因此「測試通過」並不能提供閘門堆疊隱含依賴的安心感。這也是唯一一種能從差異直接計算的候選判定條件，因此有資格進入確定性層；關鍵字封鎖清單只是猜測，LLM 檢查則是判斷

• 確定性執行前閘門——工具呼叫邊界也採用相同的確定性優先順序，並補足本頁的證據缺口。兩項差異決定它們如何組合。StampHog 閘門是替代指標——以關鍵字封鎖清單和行數來代替「這裡出錯會不會很昂貴」——而政策閘門直接判斷它設計來處理的問題，因此能稽核閘門精確率（一道閘門 161 次觸發中為 100%，另一道為 5%），本頁的封鎖清單涵蓋率則無從稽核。兩者的報告情況也互為鏡像：本案例研究測量處理量、不測量成效；該論文測量成效（+12.4pp，以不重疊的 seeds 重複驗證），卻沒有部署案例。兩者共同支持的可移植原則是順序，而非任何一方的設定值

• Claude Code Auto Mode——低一層的同一種分類器閘控自主權架構（以工具呼叫而非合併為單位），權限方向也相同：模型可以封鎖，不能解除封鎖。差異在於承載決策的是什麼——Auto Mode 的分類器就是閘門；此處則由三項確定性檢查設閘，模型只行使否決權

• 已提交產物鏈——此閘門會置於其中的流程，也是上述控制區間變體的來源。該手冊指出三道閘門都需要分級（接受規格、接受計畫、合併 PR），卻未對任何一道具體說明；它只說「組織判定為高風險的事項」應交由技術主管處理。因此 StampHog 是該手冊留作練習的把手之校準實例。這條產物鏈也提供本頁欠缺的一項判定條件：有已提交的 plan.md，就能計算「差異是否仍符合核准內容」，這與差異涵蓋率同屬關於變更的事實

• 加速反噬——對抗審查時間暴增（PR 審查時間中位數 +441.5%）的手段，也是審查涵蓋率可能上升、人工審查時數卻下降的機制；但 Faros 認為解法應從撰寫端著手，而合併閘門位於下游

• AI 腦力耗竭——中斷工作的面向：閘門減少了工程師因核准「自己幾乎毫無脈絡」的變更而產生的 1.6K 次情境切換；搭配路由升級處理，就是把審查「集中在高風險決策點」的緩解方式落實

• 最佳化器與評估器解耦——同一來源提出的審查者面板模式，也透過明確的獨立性規格套用此原則：撰寫程式碼的代理程式不能審查自己的程式碼；不同審查者應使用不同的指示、模型和供應商

• Loop Engineering——自動蓋章器和 PR 照護迴圈都是處理審查相關繁瑣工作的迴圈工程產品；PostHog 的 Paul D'Ambra 為這種做法估算成本：「我的 token 支出大概有 60% 都花在自動化處理 CI 和審查的繁瑣工作上。」

• 爆炸半徑（代理式）——知識庫中的第三種用法：此處既不是安全遭入侵的範圍，也不是程式碼變更的足跡，而是合併閘門的判定條件——以關鍵字封鎖清單代替「這裡出錯會不會很昂貴」，因此其替代指標涵蓋率可以檢查；依安全研究的結果，它並不完整

• 無效的自我驗證——「以觀察驗證，而非依賴推理」是審查者一方的說法，用來指出代理程式對自己工作的描述是最弱的可用證據；將工作拆解到每個差異都能執行，就是解方

• Polish No Longer Signals Readiness——確定性閘門要避開的正是這種問題：大小與路徑檢查不會被表面看起來乾淨的差異解除，這是模型優先閘門會承接的特定審查者失誤（P4）

• Write-Then-Trusted——封鎖清單批評的第二個案例，向下一層延伸：Pillar Security 對預設允許沙箱設定檔的判斷是：「這不是沙箱，而是一份有人記得要封鎖的項目清單，永遠少一項。」這是作業系統政策版的本頁實測缺口：爆炸半徑關鍵字封鎖清單會漏掉承載已測得安全債務87.6% 的 CI／容器檔案。兩種獨立的「列出不良項目」控制措施，都在其作者無法預見的方向上有所不足；下方的開放問題（「延伸封鎖清單能否恢復涵蓋率？」）在兩者中都有相同的結構

• 代理程式程式碼審查的確定性工程——較小接合點也採用相同的先確定性、後模型順序。OpenCodeReview 的評論錨定步驟，會先嘗試兩種低成本確定性比對（引用片段是否符合差異的新側區塊，再比對整份檔案），只有在都失敗時才呼叫 LLM 重新定位；這與本頁閘門堆疊及重大問題否決權共享相同的「便宜檢查失敗後才用模型」架構，只是套用在評論要附在哪裡，而非 PR 是否合併

• 從試行到正式環境的落差——**本頁分級在企業部署生命週期中的位置。**該藍圖的考量事項 06，就是上文第四種分級依據；它補充的觀點是，監督設計是正式環境中要決定的事項，且試行前必須指定負責人（「風險與監控負責人」）——因此在工程問題之前，閘門校準首先是組織架構問題。它也說明了結構性阻力如何讓本頁每一道閘門逐漸累積出超過其合理程度的審查

• AI-Assisted Error Analysis——將相同的後果分級邏輯套用於評估資源投入，而非合併自主權：錯誤在於對每項 AI 功能都設相同準確度門檻；應先推演最壞情況下使用者會遭遇什麼結果（由助理列舉，交由人類判斷），再從結果倒推要建立哪些評估和護欄

衍生內容#

• Is Human Review of AI-Authored Code Still a Real Control, or Already Rubber-Stamping?——本頁涉及的監督綜合分析：其 Answer 3 分類的實際校準案例，也是自動化層取代原本已淪為橡皮圖章的核准儀式的案例——因此，它改變的是合併流程的可追溯性，而非其安全性

開放問題#

• 案例研究報告處理量，卻從不報告成效。自動核准 PR 的逃逸缺陷或事故率，與 Slack 頻道先前產生的人工蓋章基準相比如何？PostHog 在自己的歷史資料中同時有這兩組資料，因此這是可檢查的前後比較，而非要求新增監測工具。同一份歷史資料還能免費回答第二個問題（2026-08-12 新增）：逐季繪出能通過 500 行／20 個檔案上限的已合併 PR 占比，就能標出閘門涵蓋率隨環境 PR 大小分布上升而衰減的速度。

• 關鍵字封鎖清單是爆炸半徑的替代指標，而代理程式產生程式碼的安全債務指出，替代指標會漏掉實際債務集中的位置（CI／容器管線，87.6%）。把 CI／IaC 路徑加入封鎖清單，能恢復涵蓋率嗎？還是會大幅縮小適合自動核准的範圍，讓閘門不再划算？第三種候選判定條件已經測量，但尚未測試（2026-08-12）：Dipongkor 等人（empirical）指出，「現有測試套件涵蓋此差異」可以計算、具確定性，卻很少成立——Python 中只有 27.0% 的變更行受測，而 64.8% 的 PR 完全沒有測到任何變更行。這使本項問題變成兩種延伸方式間的選擇，且兩者有相同的失敗模式，而不再是單一開放問題：路徑封鎖清單與涵蓋率門檻都能縮小適合自動核准的範圍來提升精確率，但兩者所犧牲的處理量都尚未測量。PostHog 現有的同一份前後比較資料就能同時回答兩者。

• 如果大小上限變成設計目標——指示代理程式產生低於 400 行的堆疊——整體風險會下降嗎？還是只是把風險重新分配到更多個低於上限的 PR，讓整合風險轉移到彼此接合處？安全研究測量的是單一 PR 的大小梯度，無法區分這兩種情況。

• 本頁現在列出三種分級依據——變更（大小上限、封鎖清單）、正式環境（σ 控制區間），以及操作的可逆性（SOC 分級階梯）。只有第一種有附帶涵蓋率數字的部署案例。**在逃逸缺陷率相同的前提下，依可逆性分級能否比依大小分級，讓更多項目自動核准？**可用第一個問題所述的同一份 PostHog 歷史資料檢查：依變更可復原的容易程度（只能回復，對比資料遷移、設定或已發布產物）來區分已合併 PR，而非依行數區分，再比較各區間適合自動核准的占比及事故歸因。SOC 分級階梯的預測是，可逆性比大小更能主導結果，因為所有以復原成本分級的閘門，都恰好在無法復原時停止放行。

資料來源#

• The State of AI Impact in Engineering: Q2 2026 — Justin Reock，The State of AI Impact in Engineering: Q2 2026（DX，Engineering Enablement 電子報，2026-07-22）；在彙編時將等級從 empirical 更正為 vendor-claim（理由見 Sources）。僅引用發現 2——500 多個客戶組織的 PR 大小中位數在 2026 年第一季至第二季之間幾乎翻倍——用來說明固定上限下變動中的分布。數字沒有附上方法說明；報告受存取限制

• The Speed Trap: 8 takeaways from our latest AI engineering research — The Speed Trap，Faros Research，2026-09-18，vendor-claim。僅引用結論 4、5 和 8——PR 平均大小 +71.8%（固定上限下變動中的分布；以平均值成長率表示，未公布絕對中位數）、明確依風險／範圍設定審查要求的建議，以及沒有數字的相關性代理式審查對策。這是兩個已高度採用 AI 時期之間的期間對期間比較，沒有控制組，研究方法記載於需填表才能取得的報告中；未經審查合併的數字按成長率而非占比解讀。完整概念分析見加速反噬

• Not All Agents Are Equal: Code Quality and Post-Merge Maintenance Across Five Autonomous Coding Agents in the Wild — Obada Kraishan（Texas Tech），arXiv 2609.17598，2026-09-12，empirical，唯一作者，尚無發表場域。表 1（各群組變更行數中位數——上限依據的分布）、§4.1（XL 區間依大小分層的敏感度檢查）、§4.3 與表 2（依供應商區分的逐行變更率及 90 天回復率）、§6（代理程式會自行選擇任務，因此供應商與任務組合彼此交纏）。已使用 pdftotext -layout 逐格驗證表 1 和表 2。完整分析見代理程式供應商間的異質性

• Stop being the code review bottleneck — Jina Yoon，〈Stop being the code review bottleneck〉，PostHog 電子報（2026-07-09），case-study。§3（StampHog：標籤觸發、四項閘門、移植提示詞中的不變條件、升級處理路由、三分之一與 1.6K 數字、前身 #dev-stamp-exchange）；§4（觀察優於推理、透過 Graphite 堆疊不超過 400 行的 PR、與 §3 的明確組合）；§1（審查者面板、跨模型與供應商的獨立性、60% token 支出的引言）

• State of AI in the SOC 2026: 8 Key Takeaways — Ajmal Kohgadai（Prophet Security），State of AI in the SOC 2026: 8 Key Takeaways，2026-08-03，vendor-claim（由供應商委託的調查，n=250，由 ViB 訪問，自陳，方法須透過名單徵求表取得；Prophet 銷售代理式 AI SOC 平台）。本頁僅引用 §7——單選自主權階梯及可複選的驗證方式。完整分析見自主防禦；級別推理見 Sources

• Deploying AI from pilot to production: A practical blueprint for CIOs and technical leaders — Deploying AI from pilot to production，Anthropic × Accenture，2026-09-11，38pp，vendor-claim。僅引用考量事項 06——包含審查週期的四級監督階梯、結構性阻力分析，以及三個問題的檢查點稽核。全篇皆屬指引：沒有部署、沒有級別分布，也沒有捕捉率。完整分析見從試行到正式環境的落差