分層監督

資料來源#

• From Agent Behaviour to Agent-Friendly Documentation
• When Does AI Augment Work? A Workflow-Level Framework for Human-Agent Collaboration
• When Review Alone No Longer Scales: Layered Supervision in AI-Assisted Software Engineering

摘要#

Stolze & Strässle（OST Eastern Switzerland University of Applied Sciences / smartive AG，arXiv 2608.26316，2026-08-26，獲 ESEM 2026 Software Engineering in Practice track 接受，case-study）訪談五位實務工作者，探討一個問題：當 AI 輔助生成的速度超越審查能力時，團隊實際上會怎麼做？他們報告的答案不是「更仔細審查」，也不是「減少審查」，而是監督功能不再集中於一處，而是分散至三個層次：

• 預防性護欄——將架構意圖與慣例外化為機器可解讀的形式（規格、steering files、架構計畫），讓它們能在任何產物出現、可供檢查之前，先塑造生成結果。
• 可執行護欄——重新運用 lint、測試、CI/CD 與架構驗證，從品質工具轉為可擴展的監督基礎設施，並以建置系統作為裁決者。
• 人類監督——重新界定範圍，從逐行檢查轉向架構推理、可解釋性與長期可維護性，並在時間上從事後移至並行進行。

最關鍵的主張是否定性的：沒有任何單一層次足以獨立發揮作用。「預防性護欄無法事先涵蓋所有架構權衡，可執行護欄無法評估情境是否合宜，而人類護欄無法擴展至 AI 生成的吞吐量。」論文對自身創新之處的界定刻意保持謙遜——lint、CI 強制執行、適配度函數、政策即程式碼，以及規格導向工作流程，在 LLM 出現前都有悠久歷史——因此「改變的不是這些機制是否存在，而是它們在實務中的角色、相對權重與配置。」

證據來自五次訪談，以及一項作者明確拒絕視為推論性證據的 50 人調查。本文沒有任何測量結果。請參閱這值得多大重視。

區分前兩個層次的關鍵#

論文最精闢的貢獻不是三層清單，而是區分預防性與可執行護欄的標準，因為兩者都在人類看見產出之前就開始作用。作者依照機制而非順序加以區分：

外化會產生預防性護欄——規格、steering files、架構計畫——它們會引導 AI 系統生成什麼，但本身不會受到自動檢查；其效果取決於生成流程是否確實查閱它們。相較之下，可執行護欄會自動對生成產出進行評估，不論該產出是如何生成的。

由此可得兩個結果，實務工作者採取行動的原因是第二個。

• 這些層次會並行運作，而非依序作為階段進行。編碼某項慣例的 steering file，通常會與強制執行同一慣例的 lint 規則並存，「以便在 steering artifact 過時、遭忽略，或未納入特定生成軌跡時，可執行檢查仍能抓出違規」。兩層之間的重複是設計本身，不是應清除的冗餘。
• 預防層的成效取決於一個本研究中沒有人測量的事件——生成器是否查閱該 artifact。維基其他地方為這個條件命名並提供數據（見下方Harness Activation and Adherence連結），這也解釋了為什麼下方的 P4 規則讀起來像一種防範措施，而不是偏好。

五位實務工作者各自實際做了哪些改變#

論文報告的是主題而非個案，因此必須根據歸因標籤拼湊各參與者的情況。拼湊後呈現出不平均的樣貌，值得記錄。

	角色／背景（表 1）	涉及層次	Artifact 或做法
P1	軟體架構師／CTO，企業軟體，小型團隊（2–9 人），非正式的 AI 建議式治理	三層皆有	規格細化是主要活動（「三分之二的時間用於規格細化」）；三個規劃子代理程式提出方案，再由另一個代理程式排序，明確用來偵測「代理程式是否完全偏離方向」；擴充可執行檢查以涵蓋架構違規；逐步觀察並及早介入（「不採用放手不管」）
P2	Staff Engineering Manager，能源公用事業前端，大型團隊（10 人以上），有明確指引	可執行、人類	額外的建置失敗檢查；以建置系統作為裁決者。提供了診斷（撰寫「非常便宜」、「瓶頸顯然正在移向審查」）以及下文的失敗軌跡
P3	工程團隊主管，營建軟體，大型團隊（10 人以上），有明確指引	—	**只出現在一項發現中。**P3 僅在 F5 中被引用，作為治理立場的資料點（「明確、正式的 AI 工具指引與結構化審查程序」），也是唯一無法進行成員檢核的參與者。在 F1–F4 中，P3 沒有任何做法、artifact 或引述
P4	資深前端工程師，數位代理商，小型團隊（2–9 人），非正式安排——也是論文共同作者	三層皆有	先投入更多架構規劃、縮短編碼時間；交接規則「若某規則相關，就必須透過 linting 強制執行」；以建置流程作為裁決者；操作層面的可解釋性（見下文）；使用 AI 生成的視覺化概覽，在架構層次而非程式碼層次進行驗證。也指出自動化層次的限制
P5	資深 UI 工程師，工業科技，小型團隊（2–9 人），沒有明確規則	可執行、預防	他自己的 monorepo 中，刻意不放寬自動化慣例：「只要我能自動完成，就不會增加成本……我真的希望嚴格維持這項慣例」。他指出既有 artifact 彼此矛盾且獨立演變，導致權威指引模糊不清；舊有 repository 是最棘手的情況

表格呈現了主題本身未揭示的兩件事。P3 對實質發現毫無貢獻——三層模型的有效樣本數是四，而非五。幾乎所有具名模式都來自兩位參與者：CTO 與共同作者，而這正是論文自身利益衝突揭露的重點（§5.7：P4 為了 SEIP track 的實務工作者觀點而加入共同作者行列；作者透過獨立核實 P4 的引述，並在 P4 加入前定稿編碼方案來降低影響）。

表 1 已逐格對照 pdftotext -f 4 -layout 核對；匯入時的 table-weld 警告出現在「Staff Engineering Manager」，原因是該職稱換成兩行顯示，而非欄位合併。

F1：以審查為核心的護欄實際在哪些方面失效#

失敗不只是數量問題，而是虛假的正確性——作者用這個詞描述生成的 artifact「在語法上正確、局部上連貫，但在架構一致性、可解釋性或長期可維護性方面存在問題」。P2 表示，他無法修改系統的某些部分，因為已經追溯不到「它們為什麼會變成現在這樣」；P5 在訪談前的調查回答中，已用精簡的說法表達同一狀況：「功能正確，但沒有人知道為什麼」。

這改變了驗證目的：「從行為測試轉向推理架構意圖、情境一致性、可解釋性與長期可維護性。」測試套件通過，並不能證明不存在虛假的正確性，因為虛假的正確性是以測試無法涵蓋的特性來定義的。

與壓力有關的唯一數量來自 P1，且需要附帶限定：手動審查一個 AI 輔助的一次性實作，通常要花上生成本身**「三到四倍的時間」**。論文很謹慎地指出，這是 AI 輔助工作流程中審查與生成階段之間的比例，並非使用 AI 前後比較，因此無法說明審查的絕對時間是否變長。

F1 的後半部是重新詮釋，而非研究發現，也是更有力的部分。P1 的觀察是，上游規格工作並非新事物——成熟團隊向來都會投入這類工作——但其影響力已經改變：規格品質如今會直接傳遞至生成程式碼，「輸入薄弱就會產生薄弱輸出，而 LLM 不會像有經驗的工程師那樣提出異議」。缺少反饋正是其機制。上游工作變得更具影響力，而不只是數量更多。

F4：操作層面的可解釋性，以及背後的利害程度校準#

人類層次的重新界定，是為了取代團隊已無法滿足的要求。P4 提出操作層面的可解釋性，取代全面理解：要求生成系統在需要時仍能診斷與重建；透過抽象層、視覺化機制、日誌與更高層次的詮釋工具來支援，這些工具「使人類護欄即使不逐行閱讀也能有效運作」。

限定條件比術語本身更重要。P1 指出，組織依使用案例而有截然不同的容忍度：**短期 UX 原型可能完全不需要開發者理解每一行程式碼；但資料庫遷移，或是具嚴格復原時間要求的系統功能，則要求精確理解每一個陳述式。**因此，操作層面的可解釋性「不是單一門檻，而是依系統關鍵性與壽命校準的情境依賴能力」——維基在合併關卡記錄的同一套分級邏輯，只是應用於理解，而非核准。

人類層次的另一半是時間安排。P1 的團隊不再等到完成後才審查，而是「逐步觀察……及早介入」，在生成偏離時採取行動。論文以狹義而實用的方式定義介入：當護欄——自動化偏移偵測器或觀察中的開發者——揭露問題時，所觸發的監督行動。這讓人類成為自動化層次輸出的第二位使用者，而非在它們之後另行進行的一輪審查。

相較於 LLM 出現前治理的三項轉變#

論文對「究竟有什麼新意」的回答，也是最容易轉用的部分：

1. 護欄移往上游——steering files、結構化提示詞與規格細化充當預防性護欄，對照業界傳統依賴檢查完成程式碼的偵測性護欄。
2. 可執行護欄提升優先順序——任何足夠相關的規則都可考慮自動強制執行，讓人類層次專注於無法編碼的事項。
3. 人類監督在時間上重新分配——從事後檢查轉為並行監督。

三者都不是新機制，改變的是權重與位置。

F5：配置各異，且拒絕使用「成熟度」一詞#

五位參與者沿著三個具名維度，以不同方式組合這些層次：治理立場（組織 AI 工具指引的有無與正式程度）；系統關鍵性與同質性（程式碼庫在 AI 輔助修改下的壽命與一致性）；以及團隊組成（資深與較缺乏經驗的開發者分布，以及由此產生的監督能力）。

作者明確拒絕使用成熟度一詞，「因為它暗示線性進展，而我們的資料並不支持這種說法。」這直接否定了階梯式框架，但在只有五個觀察點的情況下，這屬於設計選擇，而非測量結果。

這些維度中的兩項發現值得保留：

• **這些機制取決於程式碼庫，來源明確如此指出。**P1 將團隊做法描述為有條件：其程式碼庫現代化、舊程式碼少且高度符合規範；他明確表示這些做法「可能無法轉用到逐漸累積成形的舊系統」。P5 說明舊 repository 最棘手，因為不一致的模式與未記錄的假設會加劇模糊性。三層模型是在程式碼庫分布中相對容易的一端提出的。
• 下限有明確說法。「廣泛採用 AI 工具，卻沒有相稱的資深監督能力，可能會累積團隊內部看不見的風險。」P2 與 P5 都觀察到，架構專業能力較強的團隊會更廣泛使用可執行限制——因此，最能擴展的層次，正是最需要依賴稀缺專業能力來建置的層次。

這些層次要應對的失敗軌跡#

P2 提供了論文中唯一具體的失敗案例，也是最清楚說明為何這是組織問題而非技術問題的陳述。在一個 AI 生成的變更累積數月、卻沒有相稱審查能力的專案中，一項重要功能在架構問題浮現後，不得不捨棄並從頭重新實作。P2 的看法是：

「如果當時沒有使用 AI 系統，我們就不會生成這麼多程式碼……也許會更早發現問題」

作者謹慎看待這項推論——這是一種失敗模式，而非固有特性——並提出實務教訓：生產力提升與驗證基礎設施必須同步擴展，這是「組織選擇，而非純粹的技術最佳化」。若三個層次都缺乏足夠護欄，收益「常常會被更多審查工作、累積的虛假正確性，以及延遲發現缺陷所抵銷」。

作者將生產力方面的一項推論標明為自己的判斷，而非參與者所言：若收益微不足道，組織就不會投入如此程度的關注。他們坦言，這是根據觀察到的時間與心力投入得出的，而非參與者說過的話。

四種模式，作為模式提出，而非建議#

1. **將反覆出現的審查發現升級為 lint 規則。**把每一項反覆出現在人工審查中的疑慮，都視為升級為可執行檢查的候選項，讓人工審查能聚焦在真正依賴情境判斷的問題上。
2. **把規格與架構規劃提前。**原本投入實作的心力移往上游；應為這種重新分配預留資源，不要把規劃壓縮成額外負擔。
3. **以子代理程式進行並行監督與獨立審查。**P1 的三個規劃子代理程式提出方案，再由另一個代理程式排序，並明確以偏移偵測為目的——「將架構符合性檢查與事後審查分離，並使前者在生成時並行進行」。注意：標題承諾兩種互補機制，但段落只交代第一種；「獨立審查」部分在已發表文本中缺失，對照參考解析後確認，因此這是論文本身的缺陷，不是解析造成的。
4. **將驗證轉向更高層次的抽象。**使用架構計畫、視覺化系統概覽、循序圖與其他中介表示；其一般化結論是回報：「能讓架構狀態與實作軌跡一目了然的工具，似乎比單純加速生成的工具帶來更大回報。」

作者指出，以上四項的有效應用，都仰賴參與者認為供應不足的架構與情境專業能力。

調查如何使用，以及它的價值#

這項調查是背景資訊，而非證據，作者也這麼說。調查於 2025 年 11 至 12 月，在第一作者所屬機構的電腦科學校友網絡中進行；約 100 位校友收到個別邀請，50 人完成調查；問卷由第一作者與一位同事共同設計，一位外部實務工作者協助檢視清晰度，且未經正式試測。「由於調查採用便利抽樣，且問卷未經試測，我們不將彙總回答解讀為推論性證據。」

有兩項結構性事實會限制以下所有數字。五位受訪者是從調查答卷者中選出，因此訪談樣本是便利樣本中的子樣本，無法獨立驗證該調查。答卷者多為資深人員，且小型團隊占比高：26/50 是技術主管或架構師，16/50 是資深軟體工程師，34/50 在 2–9 人的團隊中。請將每項數字都理解為「瑞士／中歐小型團隊中的資深實務工作者」。

調查項目	數字
最常選取的風險	程式碼品質 43/50；長期可維護性 40/50
使用 steering files（.cursor/config、claude.md）	13/50
使用結構化提示詞工作流程（需求 → 設計 → 任務）	6/50
希望獲得 AI 生成程式碼審查標準方面的支援	23/50
希望獲得監控與追蹤工具	15/50
AI 工具使用受到明確組織指引治理	24/50
非正式安排，或完全沒有監控	23/50
表示 AI 輔助程式碼的責任歸屬變得更分散	8/50

值得保留的是 steering files 為 13/50，而將程式碼品質列為首要風險者為 43/50 這組數字：在這個樣本中，預防層是採用率最低的層次，儘管論文主張它正往上游移動。作者也以相同方式解讀外化數字——「已開始出現，但尚未廣泛普及」。

這值得多大重視#

不高，而且論文沒有過度推銷自己。具體而言，應打哪些折扣：

• **沒有任何測量。**沒有審查時間、缺陷率、逃逸率、前後比較或對照組。發現中的唯一數量，是 P1 自我回報的兩個比例（審查時間為生成時間的 3–4 倍；三分之二的時間用於規格細化），以及上方的調查數字。三層模型描述的是回報的做法；作者也明確指出：「本研究記錄的是回報的做法與看法，而非直接的縱向觀察。」
• 樣本數 = 5，實際上是 4（P3 只參與一個主題），且來自單一便利抽樣調查，瑞士與中歐情境占比過高。
• **由單一編碼者分析，沒有評分者間信度。**透過反覆修訂、書面追問，以及 2026 年 3 月下旬與五位參與者中的四位進行成員檢核來降低影響——值得一提的是，研究發現中的數個例子與重新詮釋，是在此時提出，而非來自原始訪談。
• **已揭露 AI 輔助分析。**使用 ChatGPT 翻譯德文摘錄、統整措辭及初步擬定主題；為準備定稿，使用 Claude 重新對照逐字稿核驗引述——這「修正了該流程所辨識出的數個參與者歸因錯誤」。一項以 AI 監督為主題的研究，在自身分析流程中使用 AI，並因此發現歸因錯誤；這兩方面都值得注意。
• 一位參與者是共同作者（P4），而且 P4 是研究發現中被引用最多的參與者。§5.7 中有揭露此事，並列出兩項降低影響的措施。
• 逐字稿無法分享（保密要求）；編碼手冊、調查問卷與匿名化證據表已上傳至 Zenodo（10.5281/zenodo.21611622）。

經過所有折扣後，留下來的是一套詞彙與結構性主張，而不是研究結果：預防／可執行／人類三層劃分、區分前兩層的機制而非順序標準、「虛假的正確性」，以及「操作層面的可解釋性」。這些是維基其他內容可採用的部分，而每一項都是可以用語料庫中經測量的來源檢驗的假說。

治理框架指出人類層次缺少的投入：CIVIC-AI，2026 年 9 月#

本文的第三層以立場界定——監督從逐行閱讀重新界定為並行監督，加上操作層面的可解釋性——但來源未說明它需要什麼投入。When Does AI Augment Work? A Workflow-Level Framework for Human-Agent Collaboration（CIVIC-AI 2026 workshop 白皮書，practitioner-opinion，沒有測量；框架收錄於Human-AI Accountability Redesign）提出兩項適用於這個缺口的內容，來自軟體工程以外的領域，證據力不比本文來源更強。

以三項任務特性劃定委派邊界。本文將人類層次的位置留給配置決定；該白皮書則提出一條規則——可驗證性（「具備資格的人能否檢查產出並辨識失敗？」）、可逆性（「嚴重傷害發生前，能否修正錯誤或行動？」）以及利害程度。產出越容易檢查、錯誤越能挽回、利害越有限，委派程度就越高。這是 P1 的理解分級（關鍵性 × 壽命）與Risk-Tiered Auto-Approval的影響範圍關卡，用一組三項條件來表述；對本文而言，其重要之處是讓可執行層次成為人類層次的決定因素：可驗證性不是工作本身固定不變的特質，而是部分由現有的機械檢查所形成。因此，每當一項規則從預防層升級至可執行層，都會移動委派邊界，而不只是強制執行規則。

人類層次所需、卻沒有人測量的投入。「唯有審查者具備理解、質疑並推翻演進中系統所需的能力、時間、資訊與權限，人類監督才有實質意義。這種能力不會自動維持。組織必須刻意安排足夠的實質審查工作，也讓工作者充分接觸 AI 失敗案例，才能保持驗證技能與時俱進。」對照本文的五位實務工作者來看，他們描述的重新界定恰好移除了該條款所說用來維持技能的實質審查工作——逐行閱讀正是被移除的部分，取而代之的是監督一個預期應由可執行層先攔截失敗的流程。白皮書將此情況的失敗模式稱為「人類核准淪為形式」；本文 F1 的發現則指出，以審查為核心的護欄，已無法處理人類層次原本要負責的事項。兩個來源都沒有測量重新界定工作後的審查者是否仍有能力審查；可反駁的研究形式與本文第一個開放問題相近：依層次歸屬已捕捉的缺陷，並且追蹤人類層次所分擔的實質審查工作減少時，其捕捉率是否下降。從職業層面探討同類折舊，請參閱The Tragedy of the Cognitive Commons。

預防層的定義特性，透過軌跡測量：Gao & Chen，2026 年 8 月#

上文的預防／可執行區分，是以定義形式提出，並以五次訪談為依據。Gao & Chen（Peking University，arXiv 2608.20195，2026-08-20，empirical）對其背後行為進行測量，涵蓋557 次真實代理程式編碼工作階段、94,813 個事件與 3,033 次文件互動；測量結果以比本文作者主張更強的形式支持了這項定義。

「本身不會受到自動檢查」原本描述的是工具。軌跡記錄讓它成為對生成器的描述：3,033 次文件互動中，沒有觀察到任何以文件作為比對程式碼基準的情況。候選循環中的 Validate 階段有零個事件，Verify 互動類型（依文件檢查程式碼）無從查證，而代理程式查閱文件後的三個事件內，執行測試的比率為工作階段基準率的 0.23 倍，執行建置的比率為 0.15 倍（校正後 OR 分別為 0.39 [0.25, 0.60] 和 0.25 [0.14, 0.44]）。steering artifact 不只是未受工具鏈檢查；在觀察到的軌跡中，也沒有任何機制會依據它進行檢查。

這直接支持 P4 的規則——「若某規則相關，就必須透過 linting 強制執行」——以及重複而非二擇一的立場。這也進一步釐清本文的第二個開放問題，而非解答它：用來衡量預防層剩餘貢獻的消融實驗仍未進行，但其背後前提已不再只是根據缺乏工具支援所作的推論。論文 §6.2 明確得出結論，並指出可驗證性——「文件應撰寫成讓代理程式可以依據文件驗證自身工作」——是其資料不支持的一項推論，因為它「並未描述任何已觀察到的行為」。完整討論見Agent Documentation Behavior。

同一份語料也提供另一種不那麼令人安心的預防層解讀：代理程式自行發起查閱這些 artifact（占互動的 70.2%），而非在發生問題時才查閱（占 7.5%）；它們所查閱的文件絕大多數是面向代理程式的——指示檔案與代理程式自己的工作筆記占互動的 60.5%，API 參考資料則占 1.3%。無論預防層發揮什麼作用，都是在日常進展中進行，而且主要依賴為代理程式撰寫或由代理程式撰寫的 artifact，而非護欄一詞所暗示的面向人類文件。

延伸閱讀#

• Agent Documentation Behavior — 以測量而非定義方式呈現預防層的定義特性：557 次真實工作階段的 3,033 次文件互動中，零個事件以文件作為比對基準；Verify 並未出現為互動類型，查閱文件後測試與建置活動都受到抑制（增幅 0.23 / 0.15）。這為 P4 的升級為 lint 規則提供行為證據，也指出「可驗證性」是資料不支持的推論
• Review as the Control Point — **直接的結構性分歧；仔細看後會發現，兩者討論的範圍不同，而非互相矛盾。**該頁（empirical，3,100 份編碼文件、250 多萬個 PR）將編碼代理程式對軟體的影響定位在審查，並以審查深度及審查者技能作為因果核心；本文的核心論點則是審查只是三層之一，另外兩層在審查存在之前就已作用。兩者的研究層次並不相近——一套以大型語料建立的 26 構面理論，對照五次訪談——因此在證據重疊處應以該頁為準。但兩者大多沒有爭辯同一主張：該頁的三項調節因素（審查者專業能力、處置方式、流程調整）是審查層次的特性，本文的 F5 維度則是其周遭配置的特性。兩者確實衝突之處，是 P4 主張任何相關規則都應轉為 lint 規則，這等於主張縮小審查控制點的範圍；而該頁則主張審查控制點決定一切
• Verification as the New Bottleneck — 本文提出分布式解答的核心文章。P2 以實務工作者的說法闡述論點（「程式碼撰寫變得非常便宜，瓶頸顯然正移向審查」）；本文報告的回應既不是「更仔細審查」，也不是「減少審查」，而是「將監督功能移出審查步驟」，同時朝兩個方向移動：上游與建置流程內
• Agent Context Files — 從 artifact 角度命名的預防層。本文為該頁增添的是定義，而非檔案格式：context file 是一種沒有任何機制會檢查的護欄，其效果取決於生成器是否查閱它；並提供業界使用情況數字：50 位資深實務工作者中有 13 位使用 steering files
• Harness Activation and Adherence — 對本文用文字描述之條件的測量。「其效果取決於生成流程是否確實查閱它們」就是啟動關卡；P4 主張任何相關規則也必須轉為 lint 規則，是未經測量得出的實務緩解方式
• Deterministic Engineering for Agent Code Review — 從實驗室角度論述的可執行層。該文將確定性優於自主性視為設計哲學；本文則呈現實務立場（「若某規則相關，就必須透過 linting 強制執行」）與組織立場（以建置系統作為裁決者，因此違規會讓建置失敗，而不會流到審查者手上）
• Reviving Impractical Quality Tools — 模式 1 的供給面。該頁說明為什麼如今能負擔關卡堆疊（改變的是人力成本，而非工具）；本文則提供決定哪些項目納入其中的升級規則，以及 P5 表示絕不放寬已自動化關卡的原因
• Acceleration Whiplash — 本文回應的壓力，並附上質性案例：P2 的功能在數月累積 AI 變更、卻沒有相稱審查能力後遭到捨棄並重新實作。本文也從第三個方向對該頁的成熟度框架提出疑問——請見該頁的開放問題
• Psychological Costs of AI Adoption — 經過成本衡量的人類層次。本文指出監督工作轉向架構推理；該頁則測量這種重新分配對工作者的代價（驗證稅、責任焦慮），並發現影響最深的是工程師，架構師則完全不受影響——這與本文 F5 下限所指方向一致：最能擴展的層次最需要稀缺的專業能力
• Pilot-to-Production Gap — 從操作人員轉為監督者，在不同層次上探討的同一轉變。該頁的藍圖讓執行人力在 artifact 層級轉為監督人力；本文則指出監督轉而上移至架構層次，這是同一轉變的另一個目的地
• Standardize the Infrastructure, Not the Tools — 低一層堆疊中相同的原則。Shopify 將閘道標準化，同時保留工具選擇自由；這些團隊將護欄（慣例、lint、CI）標準化，但在五個案例中有三個 AI 工具治理仍屬非正式安排，調查中也有 50 人中的 23 人如此。這是非供應商來源的佐證，顯示實際標準化發生在限制層，而非工具層
• Loop Engineering — 本文與之呼應的研究論述，論文本身也如此指出。該文直接引用 Osmani，將自身定位於高一層：loop engineering 設計能自行觸發的代理程式循環，減少人類逐刻介入；本文的人類監督層則回應由此產生的協調問題。P1 逐步觀察並及早介入，是同一停止檢查方式的非自動化版本
• Agent Harness Engineering — 本文與之匯合的論述，論文也提到這一點。論文指出 Galster 等人的配置研究後來更名為 Harness Engineering for Agentic AI Coding Tools，並指出 Böckeler 的說法——harness 試圖「將人類開發者經驗帶來的內容外化並明確呈現」——「與我們對外化的用法十分相似」。實證軟體工程領域獨立提出相同概念
• Human-AI Accountability Redesign — 同一問題在組織圖層級的呈現，也收錄了六項條件的稽核測試：本文的三層是第 1 層（「工作流程完整性」）安排；而會失效的條件是本文未測量的縱向條件
• The Tragedy of the Cognitive Commons — 說明人類層次的投入如何在職涯尺度而非單季尺度折舊：該層預設的審查能力，仰賴前兩層吸收的執行工作來重新培養
• Risk-Tiered Auto-Approval — 相同校準邏輯，套用於不同對象。該頁依影響範圍與可逆性區分核准層級；P1 則依關鍵性與壽命區分理解層級（UX 原型不需理解每一行，資料庫遷移則每一個陳述式都得懂）。兩者都指出監督資源應依變更可能造成的破壞決定，而非依變更規模決定
• Human-Governed Skill Maintenance — 經測量的預防性護欄維護：254 次實質 SKILL.md 編輯，每一次都由具名人類合併，62% 為 AI 共同撰寫；一項具備足夠檢定力的移轉測試發現，維護版本並不優於最早版本——這是本文所稱「沒有人檢查」之層次唯一的縱向證據

開放問題#

• 結構性主張是沒有任何層次足以獨立發揮作用，而論文測量的是三個層次都沒有攔截的事項。對已經運行三層護欄的團隊而言，要提出可反駁的測試並不難：將一季內發現的每項缺陷歸屬至攔截它的層次——預防性（從未生成）、可執行（建置失敗）、人類（在監督或審查中發現），或逃逸至正式環境——並回報四者占比。在這些數據出現以前，「分層監督」只描述了心力分配到哪裡，沒有證據顯示這種分配優於它所取代的審查中心式安排。
• 本文將預防性護欄定義為沒有任何機制會檢查、且效果取決於生成器是否查閱的護欄；實務工作者的做法是將每條相關規則複製到可執行檢查中。**那麼 steering artifact 還有什麼貢獻？**能區分兩者的消融實驗需使用同一 repository，設置三組：規則只放在 steering file、只放在 lint 規則，以及兩者皆放；並在第一次生成時而非合併時，根據違規率評分。如果兩者皆放組與只有 lint 組的結果相同，預防層帶來的就是軌跡品質，而非符合性，應以此作為論據。
• 作者拒絕用「成熟度」描述由三個維度構成的配置空間——治理立場、系統關鍵性與同質性、團隊組成——因為五個觀察點看不出線性進展。**這個空間本來就沒有順序，還是拒絕使用此詞只是樣本數 = 5 的結果？**產生其中三個維度裡兩項的調查問卷已存在，並公開於 Zenodo；若以足以支持排序的規模施測，並測試護欄層次採用率是否隨三個維度任一項單調變化，就能區分真實發現與樣本數造成的假象。

資料來源#

• From Agent Behaviour to Agent-Friendly Documentation — Gao & Chen（Peking University），arXiv 2608.20195，2026-08-20，empirical。本文引用 §4.1.3 與 §5 + 表 10（Validate 為 0 個事件，Verify／Compare／Follow-reference 無從查證）、§4.2.2 + 表 3（測試增幅 0.23 / OR 0.39，建置 0.15 / 0.25）、§4.2.1 + 表 2（70.2% 自行發起 vs 7.5% 失敗後發起）、§4.1.2 + 表 1（60.5% 面向代理程式），以及 §6.2（可驗證性是不受支持的推論）。所有十張表都已對照 pdftotext -layout 核對；零是依照操作型定義模式所得的零，作者強調這不代表任何形式的驗證都未發生。完整討論見Agent Documentation Behavior
• When Review Alone No Longer Scales: Layered Supervision in AI-Assisted Software Engineering — Markus Stolze（OST Eastern Switzerland University of Applied Sciences, Rapperswil）與 Mirco Strässle（smartive AG, St. Gallen），When Review Alone No Longer Scales: Layered Supervision in AI-Assisted Software Engineering，arXiv 2608.26316，2026-08-26，13 頁，ESEM 2026 Software Engineering in Practice track（DOI 10.4230/LIPIcs.ESEM.2026.89），case-study。本文引用 §4.1–4.5（F1–F5）、§5.1–5.6（層次區分、三項轉變、四種模式）、表 1、§3.3（調查背景）及 §5.7（限制與共同作者利益衝突）。**解析判定：乾淨。**唯一一項匯入時 table-weld 軟性警告出現在表 1 的「Staff Engineering Manager」，這是有文件記載的換行標籤誤報——表 1 已逐列對照 pdftotext -f 4 -layout 核對，也是論文唯一的表格。canary-recall 通過 7/7。五個圖像素材都是 LIPIcs 的版面素材（CC-BY 徽章、Dagstuhl 人字形標誌、三個章節編號方塊），依圖像兩階段規則檢視後確認不含內容；docling 也把作者旁的電子郵件圖示轉成字面詞語「envelope」。**這是論文本身的缺陷，不是解析造成的：**模式 3 的標題承諾「並行監督與獨立審查」，段落也宣稱有「兩種互補機制」，卻只描述第一種；對照第 10 頁 pdftotext -layout 參考解析，確認第二種缺失。利益衝突：已揭露且具實質關聯——訪談參與者 P4 是共同作者（SEIP 實務工作者觀點），第二作者的所屬機構（smartive AG）是研究族群中的一家軟體代理商。限制：來自單一便利抽樣校友調查的五次訪談，受訪者集中於瑞士／中歐，單一編碼者且無評分者間信度，內容是回報的做法而非觀察所得，也完全沒有任何結果測量
• When Does AI Augment Work? A Workflow-Level Framework for Human-Agent Collaboration — Wu、Ziems 等人（22 位作者；NUS、Stanford、A*STAR、NTU、Singapore Ministry of Manpower），CIVIC-AI 2026 workshop 白皮書，arXiv 2609.12482，2026-09-11，8 頁，practitioner-opinion，本身沒有測量。本文引用 §4（可驗證性／可逆性／利害程度作為委派邊界；相依條款）以及 §3（能力維持要求與「形式化核准」失敗模式）。這不是支持本文任何主張的證據，而是另一套未經測量的框架；它的用處在於為本文未指出的投入命名