生成—治理缺口與 AI 原生結構負擔 v0.2

——從候選變更爆發到可信狀態轉換吞吐量

English Title: The Generation–Governance Gap and AI-Native Structural Burden: From Candidate-Change Explosion to Trusted State-Transition Throughput
系列：《綠燈錯置：AI 操作意圖不對齊與完成失真》06 / 08
作者： Neo.K × AI 協作
版本： v0.2
日期： 2026-09-16
文件性質： AI Engineering／Software Architecture／Agentic Coding／Verification Governance／Technical Debt／Delivery Throughput
承接： A01〈綠燈錯置〉、A03〈局部正確與全域失敗〉、A04〈流程代理錯置〉、A05〈驗證義務膨脹與 Completion Drift〉
核心前序：〈AI 寫得越快，屎山會長得越快嗎？AI 原生開發的新技術債〉
後續接口： A07〈能力—視角啟動不對稱〉、A08〈同質綠燈〉、Series B〈宏觀個體導向的動態全域觀察方法論〉

機構： EveMissLab／一言諾科技有限公司

摘要

生成式 AI 與 coding agents 最重要的工程變化，未必是「AI 能不能寫程式」，而是：

亦即候選變更、候選實作、候選修復、候選測試、候選重構與候選架構方案的邊際產生成本快速下降。

但可信軟體變更的成本並不只有生成。任何實際可被接受、合併、部署並成為未來依賴的變更，至少還需要經過不同程度的：

因此 AI coding 的真正吞吐量問題不是：

有多高，而是：

能否同步提高。

本文將此前提出的「生成—治理缺口（Generation–Governance Gap）」正式推進成一套變更流體／佇列式工程模型。令：

則真正可以進入可信產品狀態的吸收率，不應直接寫成各項總和，而更接近受最慢必要 stage 約束的：

其中 $V_T$ 可稱：

Trusted Change Throughput

如果：

則系統並沒有獲得等比例軟體演化能力，而是開始累積：

等 backlog。

本文沿用既有研究中的 AI 原生結構負擔向量：

分別表示：

• Verification Debt；
• Context Debt；
• Provenance Debt；
• Specification Debt；
• Integration Debt；
• Orchestration Debt；
• Supervision Debt。

v0.2 進一步加入：

• Elimination Debt；
• Observability Debt；
• Closure Debt；
• Substrate Compensation Burden；

並將它們理解成候選變更速度與可信吸收速度之間的不對稱沉積物。

外部研究目前並不支持「AI-generated code 必然更差」這種簡單敘事。2025–2026 的研究呈現高度混合結果：部分研究顯示 LLM 生成 code 在某些 maintainability / reliability 指標上優於人類基準；另一些大型研究則觀察到不同的 defect profile、較高的某些高風險弱點、真實 repository 中持續存在的 AI-introduced issues，以及 copy/paste、duplication、churn 等 maintainability signals 的惡化。這些結果不能被壓成單一品質結論。

相對穩定的共同訊號是：

生成速度上升後，verification、review、integration、supervision 與 governance 會成為新的瓶頸。

DORA 2025 將 AI 描述為 amplifier；DORA 2026 明確指出 AI 加速 initial code generation，但創作端節省的時間經常被重新投入 auditing 與 verification。2026 年一項針對 33,707 個 agent-authored PR 的研究更發現 review effort 具有高度不均勻分布，並能以 PR 結構特徵在建立時預測高 review-effort PR；在其資料中，以 20% review budget 可攔截 69% 總 review effort。這表示 governance capacity 本身已可被建模、預測與路由。

本文的核心主張不是「降低 governance」，而是：

最終，AI-native engineering 更合理的核心產能指標不是：

也不是：

甚至不只是：

而是：

亦即：

一個系統每單位時間究竟能吸收多少「真的理解、真的驗證、真的整合、真的可治理」的有效變更。

1. 問題不是 AI 能寫多少，而是系統能吸收多少

傳統軟體工程具有一個經常被忽略的天然限制：

相對有限。

工程師一天只能：

• 改有限檔案；
• 開有限 PR；
• 設計有限 service；
• 寫有限 adapter；
• 跑有限實驗；
• 建有限 test。

這個限制固然降低 velocity，

但它也形成：

Natural Change Throttle

天然變更節流

候選變更的供給不會遠大於：

• review；
• integration；
• architecture reasoning；
• release engineering；

可以處理的量。

AI coding agent 打破的第一件事，就是這個天然節流。

2. Candidate Change Explosion

令：

AI 使：

因此同一時間窗：

而 candidate 不只包含 code。

它還包含：

• implementation；
• test；
• migration；
• API；
• adapter；
• refactor；
• documentation；
• architecture alternative；
• review finding；
• security concern；
• patch；
• workaround。

因此：

AI 是：

3. Candidate 不等於 Accepted Change

令候選變更：

它進入 product world 之前需要：

粗略對應：

candidate
→ verified
→ integrated
→ governed
→ accepted

因此：

這與 A01 / A02 的核心分離完全一致。

4. 五種核心吞吐量

本文定義五種核心工程 throughput。

4.1 Generation Throughput

4.2 Verification Throughput

4.3 Integration Throughput

4.4 Architecture Throughput

4.5 Governance Throughput

這些量不是彼此獨立，但必須概念分離。

5. Pipeline Bottleneck

若可信變更必須依序通過：

則 steady-state throughput 更接近：

這與 pipeline / queueing system 的基本直覺相同：

最慢的必要 stage 限制整體吞吐量。

因此：

如果：

不會得到：

而會先得到：

6. Generation–Governance Gap

既有研究定義：

以及治理能力：

並提出：

v0.2 將其修正成兩種版本。

6.1 Capacity Gap

如果：

表示 candidate supply 大於可信吸收能力。

6.2 Ratio

其中：

• $\rho_{GG}<1$：治理／吸收能力有餘裕；
• $\rho_{GG}\approx1$：接近飽和；
• $\rho_{GG}>1$：backlog 持續累積；
• $\rho_{GG}\gg1$：大量 candidate 必須被丟棄、延遲或低品質吸收。

7. Backlog Conservation

令：

為尚未被可信吸收的 candidate queue。

則最簡模型：

若：

長期成立，

則：

系統最終只能做三件事：

1. 增加 $V_T$ ；
2. throttle $V_g$ ；
3. 降低 acceptance / evidence bar。

第三種最危險。

8. Governance Saturation

當：

超過 governance capacity，

組織可能開始：

• review 變淺；
• test 被跳過；
• PR queue 延長；
• architecture impact 不再看；
• provenance 遺失；
• warnings 被大量忽略；
• merge criteria 放寬。

因此：

不是因為團隊突然不專業，

而是 queue 超過 service capacity。

9. DORA：AI 是 Amplifier

DORA 2025 State of AI-assisted Software Development 的核心 framing 是：

AI as an Amplifier

AI 不會自動把弱 delivery system 變成熟。

它更接近：

如果：

• version control；
• platform；
• feedback loops；
• team alignment；
• delivery practice；

本來成熟，

AI 可以放大好處。

如果本來存在：

• large batch；
• weak feedback；
• poor internal platform；
• unclear process；
• unstable delivery；

AI 也會放大 problem surface。

因此：

10. 2026 DORA：Creation 的時間省下來，常被 Verification 吃掉

DORA 2026〈Balancing AI tensions〉指出：

AI 確實加速 initial code generation，降低 task-start friction，但 creation 節省的時間常被重新投入 auditing 與 verification。

這非常接近本文的核心：

但：

因此：

11. Tokenmaxxing：生成活動量可以成為新的假生產力

DORA 在 2026 年又專門討論：

Tokenmaxxing

即組織用 token usage leaderboard 促進 AI adoption。

其核心警告是：

raw token consumption 是 input / activity metric，而不是 outcome metric。

所以：

甚至：

可能只表示：

• more agent loops；
• more speculative generation；
• more abandoned candidates；
• more duplicated implementation；
• more review burden。

這與本文的生成—治理缺口形成直接對照。

12. Activity Metric Goodhartization

若組織獎勵：

則 Agent / developer 會自然優化：

若獎勵：

會優化：

若獎勵：

會優化：

但真正需要的是：

因此：

不應成為：

13. Review Effort 已經成為可預測資源

2026 年一項針對 AI-generated PR 的研究分析：

個 agent-authored PR，

來自：

個 repositories。

研究觀察到兩個 regime：

1. 約 28.3% PR 幾乎瞬間 merge；
2. 其餘一部分進入 iterative review cycle，甚至 stall / abandon。

研究建立 structural triage model，

在其實驗中：

review budget 可以攔截：

總 review effort。

這個數字不能直接外推所有 repository，

但它證明一件很重要的事：

本身可以被：

• modeling；
• prediction；
• routing；
• budget allocation。

所以 governance 不是「人類最後看一下」。

它是一個正式 capacity system。

14. Review Agent 也不是免費 Governance

2026 年另一項 empirical study 分析 code review agents。

在其樣本中，CRA-only reviewed PR 的 merge rate 低於 human-only review group，且被分析的 closed CRA-only PR 中，大量 feedback 落在低 signal-to-noise range。

這不能推出：

AI reviewer 沒用。

它反而支持：

如果 AI reviewer 本身產生大量 noise，

則：

但：

15. Governance Throughput 要算 Signal，不是 Message

因此：

不是 governance throughput。

更合理的是：

同理：

不是 verification throughput。

而是：

16. AI-generated Code 的品質不是單向結論

本文避免：

2025–2026 的研究結果高度混合。

例如一項比較 LLM 與 human-written code 的研究，在特定 Python coding-task dataset 與 SonarQube 指標下，觀察到 LLM-generated code 在部分 bug / repair-effort 指標上較好，但高難度題可能出現 human baseline 沒有的 structural issues。

另一項超過 500,000 code samples 的研究則觀察到：

• AI code 結構通常較簡單；
• repetition 較多；
• unused constructs / hardcoded debugging 較多；
• human code 結構複雜度較高；
• maintainability issue profile 不同；
• AI samples 中觀察到更多 high-risk security vulnerabilities。

因此：

17. 非功能品質是 Green Closure 的重要盲區

2025 年一項研究綜合：

• 108 篇文獻；
• industry workshops；
• real-world issue patching experiments；

指出 LLM code evaluation 長期過度集中：

tests 是否通過。

但 functional pass 並不能代表：

• security；
• maintainability；
• performance；
• reliability；

同步成立。

研究中也觀察到：

改善一個 non-functional dimension 有時會傷害另一個。

因此：

這直接與 A01 / A03 相接。

18. 真實 Repository 中的 AI Issue 可以持續存在

2026 年〈Debt Behind the AI Boom〉分析：

個 verified AI-authored commits，

來自：

個 GitHub repositories，

識別：

個 distinct issues。

其中：

是 code smells。

研究並追蹤 issue 到 repository 最新 revision，

觀察到：

仍然存在。

這是一篇近期 empirical preprint，因此不能被解讀成：

24.2% 所有 AI code 都是 technical debt。

合理的結論是：

並不必然在後續 review / maintenance 中自動消失。

19. Vendor Observational Signal：Maintainability Gap

GitClear 2025 / 2026 發表大型 observational code-change analysis。

其 2026 報告聲稱分析：

changes，

並在 2023–2026 window 中觀察到：

• refactoring / moved code activity 下降；
• legacy maintenance 下降；
• duplication / copy-paste 上升；
• error-masking constructs 上升；
• short-term churn 上升。

這是供應商自有度量與 observational dataset，

因此不能作為：

的因果證明。

但它提供一個值得治理系統持續監測的 signal：

可能同時伴隨：

20. AI Authorship 不等於 Technical Debt

技術債需要：

所以：

同樣：

本文使用「AI 原生結構負擔」是因為：

AI 改變負擔的生成速度、分布、可見性與治理需求。

不是因為：

AI 寫的東西天生比較差。

21. Verification Debt

若：

則未充分驗證變更 queue：

滿足：

本文稱：

Verification Debt

它本身不一定已經成為傳統 technical debt。

但若：

中的 change 被：

• merge；
• deploy；
• downstream depend；

就可能轉成真正 future-cost-bearing debt。

22. Verification Debt 與 A05 不同

A05 的問題是：

A06 的 Verification Debt 是：

兩者可以互相放大：

造成：

而 reviewer 再產生：

於是：

形成雙重擁塞。

23. Context Debt

Agent 生成時通常只看到：

而完成正確變更真正需要：

因此：

這就是 Context Debt。

它可以包括缺失的：

• historical reason；
• hidden dependency；
• incident history；
• external consumer；
• manual workflow；
• runtime behavior；
• compatibility contract。

結果是：

但：

24. Context Debt 是治理負擔，不只是 hallucination

如果 architectural truth 只存在：

某位資深工程師記憶裡，

那新人也會犯錯。

因此 Context Debt 更接近：

AI 只是因為：

讓這個缺口被更高頻觸發。

25. Provenance Debt

若大量 artifact 無法回答：

• why changed；
• requirement ref；
• agent / human actor；
• context snapshot；
• validation evidence；
• model / tool version；
• review / authority；
• parent state；

則：

這會提高：

與：

因此：

具有很強的 technical-debt 性質。

26. Provenance 不等於把所有 Chat 全存下來

真正 provenance 需要：

不是：

理想記錄：

change:
  intent_ref:
  requirement_ref:
  parent_version:
  author_agent:
  model/tool:
  context_refs:
  files_changed:
  tests:
  structural_impact:
  authority:
  accepted_by:

而不是：

full 400k-token transcript

27. Specification Debt

AI 降低 implementation 成本後，

underspecification 會變得更危險。

因為：

做一個登入系統

就可以快速展開成：

• frontend；
• backend；
• DB；
• session；
• recovery；
• email；
• auth logic。

但真正未定義：

• authority；
• state semantics；
• threat boundary；
• failure；
• recovery；
• data ownership；
• lifecycle；
• acceptance criteria。

因此：

可能暴露：

不是 spec 真的變少，

而是 implementation 跑得比 spec closure 更快。

28. Integration Debt

AI 可以獨立生成：

每個 component 都：

但 integration surface：

可能隨 component 增加更快增長。

最壞情況 pairwise：

所以：

可以快速超過：

這就是 A03 的吞吐量版本。

29. Integration Debt 的核心不是 Merge Conflict

Integration debt 不只：

Git conflict

而包括：

• contract mismatch；
• retry mismatch；
• transaction mismatch；
• permission mismatch；
• state ownership mismatch；
• observability gap；
• version skew；
• deployment dependency；
• timing mismatch。

也就是：

30. Orchestration Debt

Agentic workflow 引入：

• planner；
• implementer；
• reviewer；
• test agent；
• security agent；
• deploy agent；
• memory agent。

如果：

• responsibility overlap；
• context inconsistent；
• authority unclear；
• retry semantics differ；
• completion definition differs；
• ownership unclear；

則：

這就是：

Orchestration Debt

Agent 越多不一定：

甚至可能：

31. Supervision Debt

如果 AI generation capacity：

而 trusted review capacity：

則：

結果可能：

1. merge queue 變長；
2. reviewer fatigue；
3. review depth 下降；
4. AI review 取代 human review，但 signal quality 不足；
5. low-risk / high-risk change 沒有 routing。

這就是：

32. Elimination Debt

v0.2 新增：

Elimination Debt

AI 讓：

但刪除成熟 code 需要：

• dependency analysis；
• compatibility check；
• migration；
• replay；
• deprecation；
• user impact；
• rollback。

因此：

不一定同比下降。

所以：

結果組織偏向：

don't remove old
→ add new
→ add adapter

形成：

33. 沉積偏差

當：

最便宜策略是：

因此：

且：

這是 AI 時代很重要的非對稱。

34. AI 越會生成，越需要 Garbage Collection

如果：

是 memory allocation，

則成熟 AI-native engineering 還需要：

包括：

• duplicate detection；
• dead artifact detection；
• obsolete adapter removal；
• deprecated path cleanup；
• consolidation；
• migration completion；
• compatibility retirement。

否則系統只會：

不會：

35. Observability Debt

v0.2 再新增：

Observability Debt

如果 AI change speed 上升，

但：

• traces；
• metrics；
• state introspection；
• change lineage；
• runtime evidence；

沒有同步提高，

則：

此時 incident response 會更依賴猜測。

所以 observability 是 governance capacity 的一部分。

36. Closure Debt

A01–A05 已指出：

• tests pass 不等於 intent closed；
• local pass 不等於 global pass；
• finding 不等於 obligation；
• process 不等於 progress。

若大量 change 處於：

implemented
but not semantically closed

則形成：

Closure Debt

形式上：

這比 Verification Debt 更高階。

37. Substrate Compensation Burden

若目前 technology substrate 不提供某種 required guarantee，

系統可能反覆加入：

• wrapper；
• validator；
• retry；
• runtime guard；
• extra reviewer；
• compatibility layer。

這些都可以局部有效。

但若：

持續上升，

則真正問題可能位於：

因此 Global-First v2.1 提出：

重複 structural defect 應提高 diagnostic level，

而不是：

再多派一個 reviewer。

38. Stay Cost / Move Cost

定義：

另一方案：

如果：

且 remaining lifecycle 足夠長，

就應重新評估。

不是因為：

新語言比較漂亮。

而是因為：

governance cost 已在替 substrate 的缺失保證付租金。

39. AI-native Structural Burden Vector v0.2

本文將負擔向量擴充：

其中：

• $D_v$：Verification Debt；
• $D_c$：Context Debt；
• $D_p$：Provenance Debt；
• $D_s$：Specification Debt；
• $D_i$：Integration Debt；
• $D_o$：Orchestration Debt；
• $D_{sup}$：Supervision Debt；
• $D_e$：Elimination Debt；
• $D_{obs}$：Observability Debt；
• $D_{cl}$：Closure Debt；
• $D_{sub}$：Substrate Compensation Burden。

40. 這些 Debt 不是互斥類別

一個 change 可以同時：

例如 Agent 不知道歷史 contract：

產生新 adapter：

又沒留下 rationale：

所以：

是多維狀態，不是單一 label。

41. Debt 會互相轉換

可能有：

其中：

代表傳統 technical debt / future maintenance cost。

所以 AI-native burden 是：

42. AI 可以加速 Compensation Solidification

以前 workaround 變成 architecture 可能需要數月。

現在 Agent 可以快速：

script
→ service
→ API
→ UI
→ database
→ deploy

幾天內完成。

如果 downstream 立刻依賴：

則：

因此 AI 可以加速：

Architectural Solidification

壞處是：

臨時東西更快變成不能拆的東西。

好處是：

健康 primitive 也可以更快被制度化。

關鍵仍是 governance。

43. AI 也可以提高 Governance Throughput

這篇不能把 AI 固定放在 numerator。

AI 也可以做：

• architecture recovery；
• dependency graph；
• impact analysis；
• test generation；
• invariant check；
• provenance generation；
• doc sync；
• observability analysis；
• deprecation detection；
• duplicate detection；
• migration planning；
• runtime anomaly triage。

所以：

完全可能。

44. Agentic Refactoring 是重要反例

2025 年 Agentic Refactoring 研究分析：

個 agent-generated refactoring instances，

跨：

個 PR。

研究發現：

• refactoring 並不少見；
• 26.1% commits 明確以 refactoring 為目的；
• maintainability / readability 是主要動機；
• 部分 structural metric 有小幅但顯著改善。

因此：

AI 也可以：

45. 但 Refactoring Throughput 也需要 Closure

AI refactor：

仍不表示：

需要驗：

• behavior preservation；
• architecture impact；
• tests；
• compatibility；
• performance；
• runtime。

因此 governance automation 本身也需要 governance。

這是 recursive governance 問題。

46. AI 在分子還是分母？

生成—治理比率：

如果 AI 只用在：

則：

如果 AI 同時提高：

則：

可能讓：

所以：

47. Trusted Integration Throughput

本文把舊文的：

Trusted Integration Throughput

正式化成：

若再加入：

與：

則得到更強版本。

48. Verified, Governed, Reversible State Transition

令一個 change：

可信 transition 至少滿足：

且高風險變更需要：

因此：

其中：

VGRT

Verified, Governed, Reversible Transition

49. 核心產能指標

定義：

這就是：

Verified, Governed, Reversible State Transitions per Unit Time

比：

更接近真實 AI-native engineering productivity。

50. 為什麼不只用 Tasks Completed？

因為兩個「task completed」可以具有完全不同：

• scope；
• risk；
• change radius；
• integration surface；
• evidence quality；
• reversibility。

所以：

仍然太粗。

狀態轉換至少要求：

可被明確表達。

51. Architecture Transaction

本文沿用既有概念：

AI 生成的不是 code，而是一個有來源、有證據、有結構影響的 architecture transaction。

可表示：

change:
  intent:
  parent_state:
  actor:
  context:
  artifact_diff:
  dependency_diff:
  authority_diff:
  state_ownership_diff:
  tests:
  runtime_evidence:
  structural_review:
  provenance:
  rollback:
  acceptance:

這樣：

才可治理。

52. AI Change Budget

如果：

可近乎無限擴張，

但：

有限，

則成熟組織可以設定：

AI Change Budget

要求：

這不是：

限制 AI。

而是：

不讓 ingestion rate 永遠高於 absorption capacity。

53. Change Budget 類似 SRE Error Budget，但不是同一概念

SRE error budget 管：

AI Change Budget 管：

其 budget 可以由：

• review capacity；
• test capacity；
• incident capacity；
• architecture capacity；
• release stability；
• rollback readiness；

動態決定。

54. Adaptive Change Budget

可寫：

當：

上升，

budget 應下降。

當 governance automation 改善：

budget 可以提高。

55. Circuit Breaker

當：

超過閾值：

可以觸發：

pause low-priority generation
prioritize backlog closure
increase targeted verification
cluster repeated defects
consolidate duplicates
recover architecture

這是一種：

Governance Circuit Breaker

不是 failure punishment。

而是 capacity protection。

56. Queue Prioritization

不是所有 candidate 都值得同樣 governance cost。

可依：

高價值低風險：

高風險：

低價值高 review cost：

57. 33,707 AI PR 研究對本文的啟示

review effort 高度不均勻意味：

可能很浪費。

如果 structural feature 能在 PR creation 時預測：

則：

比：

更合理。

58. Review Budget 也應 APR 化

這與 APR 的：

同型。

Review 也可以問：

為了決定這個 change 是否可接受，最少需要什麼 evidence？

所以：

不是最少治理，

而是：

足以支持當前 consequential decision 的最小治理集合。

59. Generation / Governance 的雙向調度

成熟 runtime 不只：

還需要：

例如 backlog 高：

則 generation policy：

轉向：

• fix existing；
• consolidate；
• refactor；
• document；
• test；
• remove；
• migrate。

而不是繼續：

new feature generation。

60. Structural Metabolism

本文提出：

這像結構代謝。

如果只提高：

系統會肥大。

如果：

同步提高，

系統才是真正：

61. Metabolic Balance

定義：

可建立概念性平衡：

若：

表示偏生成。

若：

表示結構代謝較平衡。

62. AI-native Big Ball of Mud 形成路徑

可能是：

intent
→ agent solution
→ local tests pass
→ merge
→ next agent sees local state
→ new local solution
→ local tests pass
→ adapter
→ duplicated state
→ more hidden dependencies
→ more local repair

最終：

這就是 A01 / A03 / A06 的合流。

63. Green Closure 與 Generation–Governance Gap 的關係

如果 governance throughput 不足，

系統很自然會選便宜 validator：

• unit test；
• lint；
• CI；
• local snapshot。

於是：

可以保持很高，

但：

跟不上。

因此：

這是一個非常重要的因果橋。

64. 為什麼「全部加更多 tests」不是完整答案

如果：

第一反應可能：

generate more tests。

AI 確實可以提高 test generation。

但如果 tests：

• 同一 projection；
• 同一 spec；
• 同一 fixtures；
• 同一 model blind spot；

則：

但：

有限。

這會接到 A08：

Homogeneous Green

65. Structural Verification

因此治理層除了 functional tests，

還需要按 change class 選：

• dependency diff；
• state ownership；
• authority change；
• lifecycle；
• runtime；
• visual / interaction；
• performance；
• compatibility；
• architecture residual。

不是每次全部開。

而是：

66. Architecture Review Frequency 可以被 AI 提高

以前 architecture review：

太高，

所以可能：

quarterly

或：

incident-driven

未來 Agent 可以每個 PR：

• recover dependency；
• compare declared / effective；
• inspect structural delta；
• detect ownership drift；
• query historical rationale。

因此：

如果品質足夠，

甚至接近：

這正是 AI 提高 denominator 的例子。

67. 但 Architecture Review 也需要 Stop Discipline

A05 已證明：

不能成為 infinite obligation generator。

所以：

不應靠：

每個 PR 寫更多 architecture comments。

而應靠：

68. Provenance Automation

Provenance 是很適合 AI 自動化的治理項。

因為：

• task ref；
• diff；
• tests；
• model；
• tool；
• branch；
• timestamp；
• dependency impact；

大多可以機械取得。

所以：

可以顯著提高：

這類 automation 比：

再產生一段 free-form review prose

更可能提高 trusted throughput。

69. Deterministic Evidence Preference

對可機械驗證的東西：

應優先於：

原因不是 LLM reviewer 沒價值。

而是：

通常：

• 成本較低；
• reproducible；
• lower correlation；
• easier caching；
• easier closure memory。

70. Governance Cache

如果同一 artifact / state：

已經有有效 evidence：

那麼沒有 relevant change 時：

應可重用。

不需要：

因此：

Governance Cache

可提高：

71. Evidence Invalidation

Governance cache 不能永遠有效。

若 change：

影響：

則：

所以：

比：

更 scalable。

72. Backlog 分層

不要只有：

PR queue

而應分：

candidate
verification
integration
architecture
governance
release

才能知道 bottleneck 位於哪。

例如：

真正問題顯然不是：

產碼不夠快。

73. Little's Law 視角

對穩定 queue：

因此 backlog：

上升可能來自：

• arrival rate $\lambda$ 上升；
• waiting time $W$ 上升。

AI 最直接提高：

如果 service rate 不變，

則：

這提供一個非常直觀的工程量化框架。

74. Governance Lead Time

可以測：

如果 AI 後：

但：

那 end-to-end lead time 未必改善。

因此：

75. Candidate Rejection Rate

如果 candidate generation 很便宜，

高 rejection rate 本身不一定壞。

定義：

只要：

很低，

探索性 generation 可以合理。

真正問題是：

如果每個垃圾 candidate 都耗大量 review，

則不值得。

76. Governance-Adjusted Candidate Value

可定義：

只有：

的 candidate 才值得深入。

這可降低：

77. Agent 不該把所有想法都變 PR

候選方案可以先存在：

不一定立刻：

• edit repo；
• open PR；
• trigger full CI；
• trigger reviewers。

因此：

這也是 governance cost control。

78. Proposal Layer

可以有：

hypothesis
→ candidate plan
→ cheap static evaluation
→ selected candidate
→ repo mutation

而不是：

every idea
→ code
→ PR
→ CI
→ review

這能把 expensive governance 放到後面。

79. Global-First 對 Generation–Governance Gap 的意義

Global-First Completion 並不是：

先生成更多。

它真正的優勢是：

例如：

global implementation
→ first global validation
→ failure clustering
→ batched repair

比：

tiny edit
→ full validation
→ tiny edit
→ full validation

降低：

因此提高：

80. A06 與 A04 的區別

A04：

A06：

A04 主要研究：

流程是否在浪費。

A06 研究：

即使所有流程都有必要，capacity 是否跟得上生成速度。

81. A06 與 A05 的區別

A05：

造成 completion drift。

A06：

造成 structural backlog。

所以兩篇形成對偶：

與：

82. A06 與 A07 的橋

若 governance capacity 不足，

Agent 會依賴：

• prior；
• local tests；
• text-only context；
• default role。

所以：

這會接到 A07：

Capability–Perspective Activation Gap

即：

模型可能有能力，但 runtime 沒有啟動該視角／模態。

83. A06 與 Series B 的橋

第二系列會提出：

其一個直接經濟理由就是：

governance 不可能對所有 change 永遠使用 maximum observation。

需要：

提高：

同時保持：

84. 治理吞吐量不等於治理步驟越少

提高：

可以靠：

1. automation；
2. better routing；
3. deterministic evidence；
4. causal reuse；
5. architecture memory；
6. stronger observability；
7. better specs；
8. reviewer specialization；
9. elimination / consolidation。

不是單純：

skip review。

85. Governance Compression

成熟系統追求：

可稱：

Governance Compression

例如：

• one exact schema validator 取代多輪文字 review；
• cached dependency graph 取代每次重新閱讀；
• targeted visual replay 取代全站人工巡查；
• provenance receipt 取代完整 chat reconstruction。

86. Trusted Absorption Efficiency

定義：

可信吸收效率：

這比：

更有工程意義。

87. Rework-adjusted Throughput

如果 accepted change 很快又被 revert / rewrite，

那 nominal throughput 會高估。

定義：

因此：

更值得觀察。

88. Stability-adjusted Throughput

再加入 escaped incident cost：

這能避免：

快速 merge 一切

看起來 throughput 很高。

89. AI Change Health Dashboard

可以監測：

generation:
  candidates_per_day:
  files_changed_per_day:

queues:
  verification:
  integration:
  architecture:
  review:
  release:

throughput:
  verified:
  integrated:
  governed:
  deployed:

quality:
  rework_rate:
  rollback_rate:
  escaped_defects:
  duplicated_code:
  churn:

burden:
  context_debt:
  provenance_debt:
  integration_debt:
  supervision_debt:
  elimination_debt:

ratio:
  generation_governance_ratio:

這比：

tokens consumed

更接近治理現實。

90. 早期警報

以下 signal 出現時：

• PR queue 快速上升；
• review latency 上升；
• review comment noise 上升；
• duplicate adapters 上升；
• short-term churn 上升；
• architecture warnings 長期未處理；
• provenance missing；
• reopened defects 上升；
• same structural failure family 重複；

應判斷：

的可能性。

91. 反例：High Generation 可以是好事

如果：

同時：

而且：

則 AI 可以讓：

• refactor；
• test；
• migration；
• cleanup；
• documentation；
• architecture recovery；

都高頻化。

因此本文不是反對：

而是反對：

92. 反例：Low Generation 也不等於健康

一個團隊：

可能只是：

• legacy 太難改；
• review 太慢；
• fear-driven process；
• no automation；
• low capability。

所以：

真正目標是：

93. 反例：Governance 很多也可能是壞事

如果：

用「review steps」計算，

可能被 A04 的 process proxy 騙。

所以治理吞吐量必須用：

衡量，

而不是：

94. 核心命題

本文 v0.2 收束為十八條命題。

P1 — Candidate-Cost Reduction

這比「AI 一定讓專案變快」更弱也更可靠。

P2 — Candidate / Trusted Change Separation

P3 — Pipeline Bottleneck

P4 — Generation–Governance Gap

P5 — Backlog Accumulation

若：

則：

P6 — AI Authorship Non-Debt

P7 — Distinct Defect Profile

P8 — Verification Debt

P9 — Integration Debt

P10 — Context Debt

P11 — Elimination Asymmetry

會增加沉積偏差。

P12 — AI Can Increase Governance Too

P13 — Structural Amplifier

它放大的是既有 engineering system。

P14 — Activity Non-Productivity

P15 — Trusted State Transition Metric

P16 — Change Absorption Budget

P17 — Governance Routing