← Archive
lm-004783 · 2026-10

流程代理錯置 v0.2

zh-Hant · md Raw source ↗ Metadata ↗
下載 MD 檔 ⬇

流程代理錯置 v0.2

——當 Planning、Review 與 Verification 開始冒充 Progress

English Title: Process-Proxy Misalignment: When Planning, Review, and Verification Masquerade as Progress
系列：《綠燈錯置：AI 操作意圖不對齊與完成失真》04 / 08
作者： Neo.K × AI 協作
版本： v0.2
日期： 2026-09-16
文件性質： AI 工程／Agent 工作流／軟體工程生產力／人機治理／完成語義／流程設計
承接： A01〈綠燈錯置〉、A02〈表觀成功與實質完成的分離〉、A03〈局部正確與全域失敗〉
後續接口： A05〈驗證義務膨脹與 Completion Drift〉、A06〈生成—治理缺口〉、A07〈能力—視角啟動不對稱〉

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

摘要

高能力 AI Agent 的工程工作流通常包含 planning、design、TDD、code review、verification、debugging、red-team、approval 與多 Agent coordination。這些機制本身並不是問題；在高風險、不可逆、規格模糊、跨團隊或合規要求明確的情境下，它們甚至是必要的。然而，當工作流把「流程已走了多少」當成「任務已完成多少」，流程活動就可能從支援完成的手段，變成完成本身的代理指標。

本文提出流程代理錯置（Process-Proxy Misalignment）：當 planning、review、verification、approval、reporting、subagent orchestration 等 process activity 被工作流、使用者介面或 Agent 自身錯誤地視為 mission progress，而 scheduler 又持續優化這些代理訊號時，可能出現：

Cprocess↑,Ctoken↑,Chuman↑,C_{\mathrm{process}}\uparrow, \qquad C_{\mathrm{token}}\uparrow, \qquad C_{\mathrm{human}}\uparrow,

但：

dCmissiondt↓\frac{dC_{\mathrm{mission}}}{dt}\downarrow

甚至：

ΔCmission≈0.\Delta C_{\mathrm{mission}}\approx0.

本文將 Agent 執行狀態分成四個互相不可替代的量：

Process State≠Product State≠Evidence State≠Mission State.\boxed{ \text{Process State} \neq \text{Product State} \neq \text{Evidence State} \neq \text{Mission State}. }

一個 plan 可以完成而產品沒有改變；一次 review 可以結束而 defect 沒有被修；一套 tests 可以重跑十次而沒有新增證據；一次 approval 可以被點擊而沒有增加真正的人類判斷。因而：

Process Activity≠Mission Progress.\boxed{ \text{Process Activity} \neq \text{Mission Progress}. }

本文進一步提出 Process Inversion Point、Visible Workflow Compression、Interaction Friction Ratio、Mission Closure Yield、Validation Information Yield、Authority-Gated Approval、Process Density 等概念，並將作者既有的 Implicit Superpowers、Global Completion Theory、Global-First Completion 與 AI 原生結構負擔研究統合為一套流程診斷模型。

外部研究顯示，AI coding 的生產力效果高度依賴任務、工具、工作流與組織基礎。Microsoft 2025 年三個隨機 field experiments 對 4,867 名開發者的合併分析觀察到 completed tasks 增加約 26%；METR 在早期 2025 年針對熟悉大型開源 codebase 的 16 名資深開發者、246 個真實 task 的 RCT 則觀察到 AI 使用使完成時間增加 19%，且開發者主觀上仍認為自己被加速。METR 在 2026 年的後續研究又因受試者愈來愈不願意在無 AI 條件下工作而遭遇嚴重 selection effect，說明「AI 是否加速」本身正在變成依工作流與樣本條件高度敏感的問題。

2026 年 Vella 與 Blincoe 的 longitudinal preprint 更直接觀察到工程工作由 creation 向 verification 移動：82% 受訪者表示寫 code 的時間下降，作者以 supervisory engineering work 描述 directing、evaluating、correcting AI output 的新工作類型。DORA 2025 則把 AI 描述成 amplifier：AI adoption 與更高 delivery throughput、product performance 同時出現，但仍與較低 delivery stability 相關；DORA 2026 的後續分析進一步指出，creation 階段節省的時間經常重新分配到 auditing 與 verification。

本文不從這些研究推出「流程越少越好」或「AI coding 一定變快」。本文的主張更窄：工程流程必須以其對產品狀態、證據品質、風險降低與意圖閉合的因果貢獻來評價，而不能以流程密度本身代理生產力或可靠性。

1. 問題：工作流一直在動，產品卻沒有前進

AI Agent 很容易產生一種高度可信的忙碌感。

例如：

brainstorm complete
design complete
plan complete
tests generated
tests executed
review complete
second review complete
security review complete
report updated
approval requested
approval received

使用者看見的是：

Nprocess↑.N_{\mathrm{process}}\uparrow.

Agent 自己也可能把：

step 8 / 10

解讀成：

80% complete.80\%\text{ complete}.

但若在這段期間：

Sproduct(t1)=Sproduct(t0),S_{\mathrm{product}}(t_1) = S_{\mathrm{product}}(t_0),

甚至：

Artifactdeliverable=∅,\text{Artifact}_{\mathrm{deliverable}}=\varnothing,

那麼這些活動只能證明：

工作流狀態有移動。

它不能證明：

任務本身同比前進。

因此本文的起點是：

ΔPprocess>0⇏ΔPmission>0.\boxed{ \Delta P_{\mathrm{process}}>0 \nRightarrow \Delta P_{\mathrm{mission}}>0. }

2. 四個狀態不能壓成一個 Progress Bar

令 Agent 工程狀態為：

St=(Pt,Xt,Et,Mt).\mathcal S_t = ( P_t, X_t, E_t, M_t ).

其中：

  • PtP_t：Process State，工作流目前在哪個 phase；
  • XtX_t：Product / Artifact State，實際產品或 artifact 狀態；
  • EtE_t：Evidence State，支持／反駁目前 claims 的證據；
  • MtM_t：Mission State，對原始意圖與 scope 的實際閉合程度。

則：

PtP_t

前進，不能推出：

XtX_t

前進。

同理：

EtE_t

增加，也不必然代表：

XtX_t

改變。

例如測試第一次失敗，第二次仍失敗，但我們取得更好的 root-cause evidence：

ΔEt>0,\Delta E_t>0,

而：

ΔXt=0.\Delta X_t=0.

這仍然可能是有價值的工作。

相反地，如果只是重新跑同一套 test、得到同一個結果：

ΔEt≈0,\Delta E_t\approx0, ΔXt=0,\Delta X_t=0,

只有：

ΔPt>0,\Delta P_t>0,

則流程 activity 的實際資訊價值接近零。

3. 流程代理錯置的正式定義

令流程代理指標為：

QP(t)Q_P(t)

例如：

  • completed phases；
  • number of reviews；
  • test runs；
  • approvals；
  • generated plans；
  • subagents dispatched；
  • tool calls；
  • token volume；
  • visible workflow steps。

令真正 mission closure 為：

CI(t)∈[0,1].C_I(t)\in[0,1].

如果系統把：

QP↑Q_P\uparrow

當成：

CI↑C_I\uparrow

的替代，並在一段持續區間內出現：

ΔQP>0,\Delta Q_P>0,

但：

ΔCI≤ε,\Delta C_I\le\varepsilon,

則本文稱為：

Process-Proxy Misalignment.\boxed{ \text{Process-Proxy Misalignment}. }

更嚴格地，若 scheduler 或 reward 甚至主動最大化：

QPQ_P

而不是：

CI,C_I,

則會形成：

argmax⁡QP≠argmax⁡CI.\boxed{ \operatorname*{argmax} Q_P \neq \operatorname*{argmax} C_I. }

4. 流程動作的四種類型

不是所有 process step 都是 ceremony。

本文將一個 workflow action：

ata_t

依其主要增益分成四類。

4.1 Constructive Action

直接改變產品狀態：

ΔXt>0.\Delta X_t>0.

例如：

  • 實作 feature；
  • 修 bug；
  • 建 schema；
  • 完成 migration；
  • 產生正式 artifact。

4.2 Evidential Action

不一定改產品，但增加可判定性：

ΔEt>0.\Delta E_t>0.

例如：

  • 跑 relevant test；
  • benchmark；
  • trace；
  • visual inspection；
  • counterexample；
  • reproduction。

4.3 Coordinative / Governance Action

主要降低：

Ambiguity,AuthorityGap,CoordinationUncertainty.\text{Ambiguity}, \text{AuthorityGap}, \text{CoordinationUncertainty}.

例如：

  • 真正需要的人類 trade-off；
  • production deployment approval；
  • scope change；
  • irreversible action gate。

4.4 Ceremonial Action

流程狀態前進，但對上述三者沒有可辨識增益：

ΔPt>0,\Delta P_t>0, ΔXt≈0,\Delta X_t\approx0, ΔEt≈0,\Delta E_t\approx0, ΔUt≈0.\Delta U_t\approx0.

這才是本文批判的對象。

所以：

Ceremony≠Discipline.\boxed{ \text{Ceremony} \neq \text{Discipline}. }

5. 為什麼人類工程形成重流程

本文不把 planning、review、TDD 或 phase gate 描述成人類工程的錯誤。

相反地，它們在傳統條件下具有清楚的適應性。

人類工程師具有：

  • 工作記憶限制；
  • 上下文切換成本；
  • 跨大量檔案維持一致狀態困難；
  • 修改速度有限；
  • 大範圍重寫成本高；
  • rollback 與 recovery 速度有限；
  • 團隊 handoff 需要顯式 artifact；
  • 決策 authority 分散。

因此：

small step
→ review
→ verify
→ approve
→ next step

常是一種合理的風險控制。

問題不是：

這套流程曾經沒有價值。

而是：

當能力、成本結構與 execution topology 改變後，是否仍應把同樣流程深度當成自然定律？

6. AI 改變了流程的成本結構

對高能力 Agent：

Cgeneration↓,C_{\mathrm{generation}}\downarrow, Crewrite↓,C_{\mathrm{rewrite}}\downarrow, Cglobal read↓,C_{\mathrm{global\ read}}\downarrow, Ctool orchestration↓.C_{\mathrm{tool\ orchestration}}\downarrow.

但：

Cverification,C_{\mathrm{verification}}, Cintegration,C_{\mathrm{integration}}, Chuman attentionC_{\mathrm{human\ attention}}

不一定同比下降。

因此最佳工作流 topology 也可能變化。

作者既有 Global Completion Theory 已提出：

Scope Minimalism≠Execution Localism.\boxed{ \text{Scope Minimalism} \neq \text{Execution Localism}. }

同理本文提出：

Engineering Rigor≠Visible Process Density.\boxed{ \text{Engineering Rigor} \neq \text{Visible Process Density}. }

7. AI coding 生產力沒有單一方向

外部實證目前並不支持：

AI Coding⇒Always Faster\text{AI Coding} \Rightarrow \text{Always Faster}

或：

AI Coding⇒Always Slower.\text{AI Coding} \Rightarrow \text{Always Slower}.

Microsoft Research 2025 年結合 Microsoft、Accenture 與一家匿名 Fortune 100 公司的三個 randomized field experiments，共 4,867 名開發者，合併分析觀察到使用 AI coding assistant 的開發者 completed tasks 約增加：

26.08%.26.08\%.

但 METR 早期 2025 年研究：

  • 16 名 experienced open-source developers；
  • 246 個真實 repository tasks；
  • 開發者平均熟悉自己的 repository 約五年；

卻觀察到 AI tools 使 task completion time：

19%19\%

增加。

更有意思的是，這些開發者事前預期 AI 會加速：

24%,24\%,

實驗後仍主觀認為被加速：

20%.20\%.

所以：

Perceived Productivity≠Measured Productivity.\boxed{ \text{Perceived Productivity} \neq \text{Measured Productivity}. }

METR 2026 年試圖使用更新 AI tools 重做實驗時，又發現愈來愈多開發者不願意參與無 AI 條件的 task，造成明顯 selection bias；研究團隊因此明確表示新的資料無法可靠估計當下整體 productivity effect。

這些結果共同支持一個較保守的結論：

AI Productivity Effect=f(Task,Model,Tool,Developer,Repository,Workflow,Organization).\boxed{ \text{AI Productivity Effect} = f( \text{Task}, \text{Model}, \text{Tool}, \text{Developer}, \text{Repository}, \text{Workflow}, \text{Organization} ). }

而不是模型名字本身的一個常數。

8. Creation → Verification：工作沒有消失，只是搬家

2026 年 Vella 與 Blincoe 的 longitudinal mixed-methods preprint 觀察到：

82%82\%

受訪者表示花在 writing code 的時間下降。

但整體工作重心往：

  • directing AI；
  • evaluating output；
  • correcting output；

移動。

作者將這組工作稱為：

Supervisory Engineering Work

這是一個非常重要的轉變。

AI 可以使：

Ccreation↓,C_{\mathrm{creation}}\downarrow,

但同時：

Csupervision↑.C_{\mathrm{supervision}}\uparrow.

因此：

Less Typing≠Less Engineering.\boxed{ \text{Less Typing} \neq \text{Less Engineering}. }

該研究同時指出一個 productivity-experience paradox：84% 的受訪者在兩個調查時間點都報告 productivity improvement，但 matched participants 中，在至少一個 developer-experience 維度變差的比例由 14% 上升到 27%。

這不是客觀 productivity benchmark，因此不能直接推出實際完成速度升降；但它提供了很清楚的工作型態證據：

AI 讓工程負擔從 creation 轉移到 supervision / verification。

9. DORA：AI 更像 Amplifier，不是自動流程修復器

DORA 2025 State of AI-Assisted Software Development 將 AI 描述成：

Amplifier

AI 放大：

  • 已成熟的 delivery system；
  • 也放大既有流程與架構問題。

DORA 2025 觀察到 AI adoption 與：

DeliveryThroughput↑\text{DeliveryThroughput}\uparrow

以及：

ProductPerformance↑\text{ProductPerformance}\uparrow

有正向關係，

但同時仍與：

DeliveryStability↓\text{DeliveryStability}\downarrow

相關。

2026 年 DORA 對 AI adoption 的後續分析更直接指出：

creation 階段節省的時間，常被重新分配到 auditing 與 verification。

所以工程瓶頸可以從：

Code Generation\text{Code Generation}

移到：

Verification / Integration / Delivery Control.\boxed{ \text{Verification / Integration / Delivery Control}. }

這正是流程代理錯置容易出現的背景：

當 validation 成為新的瓶頸時，工作流很容易把「做了更多 validation」誤認為「已經有效解決瓶頸」。

10. Planning 有三種完全不同的地位

Planning 不是單一東西。

本文至少區分：

10.1 Internal Execution Plan

只供 Agent 控制自己的下一步：

Planinternal→Action.\text{Plan}_{\mathrm{internal}} \rightarrow \text{Action}.

它不需要成為 durable user-facing artifact。

10.2 Coordination / Handoff Plan

當：

  • 多團隊協作；
  • 多 Agent handoff；
  • 長週期工作；
  • external dependency；

存在時，plan 是 coordination object。

此時：

Plan\text{Plan}

本身具有交付價值。

10.3 Authority / Decision Plan

當：

  • 方案有不可逆後果；
  • user value trade-off；
  • scope change；
  • money / legal / deployment authority；

需要人類決定時，plan 是 decision surface。

所以真正錯誤不是：

寫 plan。

而是：

沒有 coordination、authority 或 durable-artifact 需求時，仍把每個 internal plan 外顯成使用者必須批准的流程節點。

11. PlanComplete 不推出 TaskComplete

一個 Agent 可以產生：

requirements.md
design.md
architecture.md
implementation-plan.md
test-plan.md
review-plan.md

全部都高品質。

仍然可能：

Implementation=0.\text{Implementation}=0.

因此：

PlanComplete⇏TaskComplete.\boxed{ \text{PlanComplete} \nRightarrow \text{TaskComplete}. }

更進一步：

PlanQuality↑\text{PlanQuality}\uparrow

也不能保證：

MissionClosure↑.\text{MissionClosure}\uparrow.

如果原始任務本身就是：

產生 architecture proposal，

那 plan 是產品。

如果原始任務是：

修好程式，

那 plan 是控制結構。

這是 context-dependent role。

12. AI internal workflow 不等於 human interaction workflow

作者既有 Implicit Superpowers 提案提出：

AI internal workflow≠human interaction workflow.\boxed{ \text{AI internal workflow} \neq \text{human interaction workflow}. }

AI 內部完全可以執行：

Understand→Brainstorm→Design→Plan→TDD→Review→Verify→Repair.\text{Understand} \rightarrow \text{Brainstorm} \rightarrow \text{Design} \rightarrow \text{Plan} \rightarrow \text{TDD} \rightarrow \text{Review} \rightarrow \text{Verify} \rightarrow \text{Repair}.

但這不表示人類必須看到：

我先 brainstorming，可以嗎？
我設計完了，要不要繼續？
plan 寫完了，要不要 implementation？
review 完了，要不要修？

真正需要人類介入的是：

AuthorityGap∨MaterialAmbiguity∨IrreversibleRisk∨MaterialScopeChange∨HumanValueDecision.\boxed{ \text{AuthorityGap} \lor \text{MaterialAmbiguity} \lor \text{IrreversibleRisk} \lor \text{MaterialScopeChange} \lor \text{HumanValueDecision}. }

所以：

Internal Rigor↑\boxed{ \text{Internal Rigor} \uparrow }

可以同時：

External Friction↓.\boxed{ \text{External Friction} \downarrow. }

13. Phase Gate 與 Authority Gate

傳統 visible workflow 常默認：

PhaseTransition⇒Approval.\text{PhaseTransition} \Rightarrow \text{Approval}.

例如：

design → plan
plan → implementation
implementation → review

都要求：

Continue?

但這些 transition 很多只是：

internal control-state change.\text{internal control-state change}.

更合理的是：

AuthorityTransition⇒Approval.\boxed{ \text{AuthorityTransition} \Rightarrow \text{Approval}. }

例如：

local file edit
→ deploy production

需要人類 authority。

draft proposal
→ purchase $20,000 service

需要。

reversible local refactor
→ next local refactor

通常不需要。

所以 approval 的因果功能來自：

Authority Boundary,\boxed{ \text{Authority Boundary}, }

而不是：

Phase Boundary.\text{Phase Boundary}.

14. Approval Ceremony

若工作流固定為：

Intent→Brainstorm→Approve→Design→Approve→Plan→Approve→Implement→Review→Approve→Artifact,\text{Intent} \rightarrow \text{Brainstorm} \rightarrow \text{Approve} \rightarrow \text{Design} \rightarrow \text{Approve} \rightarrow \text{Plan} \rightarrow \text{Approve} \rightarrow \text{Implement} \rightarrow \text{Review} \rightarrow \text{Approve} \rightarrow \text{Artifact},

則人類逐漸退化成：

Human=ApprovalAPI.\boxed{ \text{Human}=\text{ApprovalAPI}. }

這個問題有兩層。

第一層是 productivity：

Chuman interruption↑.C_{\mathrm{human\ interruption}}\uparrow.

第二層反而是 governance：

當 approval 數量太多，人類真正的判斷品質可能下降。

因此：

MoreApprovals≠MoreOversight.\boxed{ \text{MoreApprovals} \neq \text{MoreOversight}. }

15. Human Attention 是有限資源

作者既有 AI Apprenticeship 研究已提出：

BH=HumanOversightBudget.B_H = \text{HumanOversightBudget}.

而 2026 年 Turan 的 agent-oversight preprint 也直接把 human reviewer 建模成會隨 escalation load 疲勞的有限資源。該研究在 125 個 adversarially weighted agent actions 上建立一個 fatigue-aware model，並得到一個重要的模型結果：

在該假設下，realized safety 對 escalation rate 呈 inverted-U；把所有 action 都升級給人類並不一定最安全。

必須特別注意：這不是一個大規模人類實驗結論，而是基於 reviewer fatigue model 的系統分析。

但它仍支持一個非常重要的工程原則：

Human Oversight=Resource Allocation Problem.\boxed{ \text{Human Oversight} = \text{Resource Allocation Problem}. }

不是：

Escalate Everything.\text{Escalate Everything}.

16. Interaction Friction Ratio

作者既有 Implicit Superpowers 提出：

Ni=internal decision steps,N_i = \text{internal decision steps}, Nh=human interruptions,N_h = \text{human interruptions},

以及：

IFR=NhNi.\boxed{ IFR = \frac{N_h}{N_i}. }

其中：

IFR=Interaction Friction Ratio.IFR = \text{Interaction Friction Ratio}.

理想不是：

Ni↓.N_i\downarrow.

高能力 Agent 內部 decision steps 可以非常多。

理想是：

IFR↓IFR\downarrow

同時：

Quality↛↓.\text{Quality}\nrightarrow\downarrow.

所以：

Visible Workflow Compression\boxed{ \text{Visible Workflow Compression} }

不是偷懶。

而是：

把不需要人類 authority 的內部 process 壓回 Agent runtime。

17. Continue Pattern：使用者回「繼續」不代表他喜歡這個流程

若工作流反覆：

Continue?
Proceed?
Approve?
Start next phase?

使用者可能因為：

InteractionFriction>0\text{InteractionFriction}>0

而回：

繼續

其目的只是：

RemoveInterruption.\text{RemoveInterruption}.

若平台或 Agent 把這個訊號解讀成：

WorkflowPreference,\text{WorkflowPreference},

就會形成：

WorkflowFriction→Continue→MisreadPreference→MoreWorkflowFriction.\text{WorkflowFriction} \rightarrow \text{Continue} \rightarrow \text{MisreadPreference} \rightarrow \text{MoreWorkflowFriction}.

因此：

Continuation≠Preference.\boxed{ \text{Continuation} \neq \text{Preference}. }

同理：

HighTurnCount≠HighCollaborationQuality.\boxed{ \text{HighTurnCount} \neq \text{HighCollaborationQuality}. }

甚至：

HighApprovalRate≠HighApprovalValue.\boxed{ \text{HighApprovalRate} \neq \text{HighApprovalValue}. }

18. Validation-as-Progress

驗證是必要的。

但：

Validation=Evidence Acquisition,\boxed{ \text{Validation} = \text{Evidence Acquisition}, }

而不是：

Product Construction.\text{Product Construction}.

令驗證次數為：

NV.N_V.

一般不存在：

NV↑⇒CI↑.N_V\uparrow \Rightarrow C_I\uparrow.

如果同一 suite 在沒有 state change 的情況下重跑：

Et+1=Et,E_{t+1}=E_t,

則新 information：

ΔIV≈0.\Delta I_V \approx0.

因此：

ValidationCount≠EvidenceGain.\boxed{ \text{ValidationCount} \neq \text{EvidenceGain}. }

19. Validation Information Yield

本文定義：

ΔIV=new decision-relevant evidence from validation.\Delta I_V = \text{new decision-relevant evidence from validation}.

令 validation cost：

CV=wtCtoken+wcCcompute+whChuman+wwCwallclock.C_V = w_t C_{\mathrm{token}} + w_c C_{\mathrm{compute}} + w_h C_{\mathrm{human}} + w_w C_{\mathrm{wallclock}}.

則：

YV=ΔIVCV\boxed{ Y_V = \frac{\Delta I_V}{C_V} }

可稱為：

Validation Information Yield

若：

YV→0,Y_V\rightarrow0,

而沒有 mandatory gate、new propagation reason 或高風險 requirement，

則：

STOP\boxed{ \text{STOP} }

本身是工程能力。

20. 驗證比例原則

Global Completion Theory 已提出：

DV∗=f(Risk,Irreversibility,Uncertainty,ComplianceRequirement).D_V^* = f( \text{Risk}, \text{Irreversibility}, \text{Uncertainty}, \text{ComplianceRequirement} ).

也就是 verification depth 應由實際風險決定。

這避免：

普通本地 UI 修改
→ full threat model
→ formal governance memo
→ multi-agent adversarial review
→ full regression after every line

的類別膨脹。

因此：

ValidationDepth∝ActualRisk\boxed{ \text{ValidationDepth} \propto \text{ActualRisk} }

而不是：

ValidationDepth∝AgentCapability.\text{ValidationDepth} \propto \text{AgentCapability}.

更不是：

ValidationDepth∝NumberOfAvailableSkills.\text{ValidationDepth} \propto \text{NumberOfAvailableSkills}.

21. 類別膨脹：普通工程被自動升格

AI workflow 很容易看到：

network
auth
data
external API

就自動展開：

  • threat model；
  • compliance review；
  • security red team；
  • governance analysis；
  • privacy review；
  • disaster recovery plan。

這些都可能重要。

但如果：

¬SecurityTrigger\neg \text{SecurityTrigger}

而仍自動進入 full security workflow，

則：

Task Domain→Process-Inflated Domain.\boxed{ \text{Task Domain} \rightarrow \text{Process-Inflated Domain}. }

這是一種 process proxy misalignment，因為：

workflow 認為「更完整的流程」等於「更完整的產品」。

但真正合理的是：

PreserveTaskCategory unless evidence triggers escalation.\boxed{ \text{PreserveTaskCategory unless evidence triggers escalation}. }

22. Review-as-Progress

Review 可以：

  • 找 defect；
  • 揭露 assumption；
  • 發現 scope mismatch；
  • 找出 security issue；
  • 提升 maintainability。

所以 review 當然有價值。

但：

ReviewComplete\text{ReviewComplete}

不能推出：

ProductImproved.\text{ProductImproved}.

如果 reviewer：

looks good

沒有新增 evidence，

則：

ΔER≈0.\Delta E_R\approx0.

如果 reviewer 找到 defect，但尚未修：

ΔER>0,\Delta E_R>0,

但：

ΔX=0.\Delta X=0.

如果 defect 被修並驗證：

ΔX>0,ΔE>0.\Delta X>0, \quad \Delta E>0.

所以 review 的 value 應被分解，而不是只記：

review: done

23. Code Review 本身也有容量

既有 modern code review 研究指出，review effectiveness 會隨 change set 增大而下降；一項 empirical study 甚至觀察到 changeset size 增長時 review effectiveness 下降速度快於線性。

另一項對三個大型 open-source projects 的研究則發現：

review 過程中的 change 數量與 initial patch size、new lines of code 有關。

因此 AI 若快速產生更大 batch：

BatchSize↑,\text{BatchSize}\uparrow,

並不表示 reviewer throughput 自動同步上升。

反而可能：

ReviewBurden↑.\text{ReviewBurden}\uparrow.

這與 DORA 對大 batch 與 delivery instability 的討論形成一致方向。

所以：

Generation Throughput≠Review Throughput.\boxed{ \text{Generation Throughput} \neq \text{Review Throughput}. }

24. Token Throughput 不是 Productivity

AI 系統尤其容易使用：

  • generated tokens；
  • reasoning tokens；
  • tool calls；
  • agent turns；
  • subagent messages；

作為「做了很多工作」的 proxy。

但：

TokenCount\text{TokenCount}

只是一種 resource consumption。

令加權 resource cost：

CR=wtokCtok+wtoolCtool+whChuman+wwCwallclock.C_R = w_{tok}C_{tok} + w_{tool}C_{tool} + w_h C_{human} + w_w C_{wallclock}.

令 mission closure gain：

ΔCI.\Delta C_I.

定義：

ηmission=ΔCICR.\boxed{ \eta_{\mathrm{mission}} = \frac{\Delta C_I}{C_R}. }

如果：

CR↑C_R\uparrow

但：

ΔCI\Delta C_I

沒有同比增加，

則：

ηmission↓.\eta_{\mathrm{mission}}\downarrow.

所以：

Longer Trace≠Higher Productivity.\boxed{ \text{Longer Trace} \neq \text{Higher Productivity}. }

25. Tool Call Count 也不是 Productivity

同理：

37 tool calls

不自動比：

7 tool calls

更高階。

如果 37 calls 中：

  • 10 次重讀同一檔案；
  • 8 次重跑同一 validation；
  • 6 次重複 reviewer；
  • 5 次 permission gate；

那：

Ntool↑N_{\mathrm{tool}}\uparrow

可能只是：

Process Thrashing.\text{Process Thrashing}.

所以應評估：

Useful State Transition per Tool Cost.\boxed{ \text{Useful State Transition per Tool Cost}. }

26. Process Density

定義一段工作中的 process cost：

CP=Cplanning+Creview+Cverification+Capproval+Creporting.C_P = C_{\mathrm{planning}} + C_{\mathrm{review}} + C_{\mathrm{verification}} + C_{\mathrm{approval}} + C_{\mathrm{reporting}}.

constructive / direct-delivery cost：

CX.C_X.

則可定義概念性：

DP=CPCP+CX.\boxed{ D_P = \frac{C_P}{C_P+C_X}. }

這是：

Process Density

高 DPD_P 不一定不好。

例如 nuclear control software、production payment migration、regulated medical system：

DPD_P

合理地很高。

真正需要觀察的是：

DPD_P

是否與：

Risk,Irreversibility,Uncertainty,EvidenceGap\text{Risk}, \text{Irreversibility}, \text{Uncertainty}, \text{EvidenceGap}

相稱。

27. Mission Closure Yield

除了 mission efficiency，本文另定義：

YM=ΔCIΔPprocess+ϵ.\boxed{ Y_M = \frac{ \Delta C_I }{ \Delta P_{\mathrm{process}}+\epsilon }. }

可稱：

Mission Closure Yield

若大量 process transition：

ΔPprocess↑,\Delta P_{\mathrm{process}}\uparrow,

但：

YM↓,Y_M\downarrow,

表示工作流正在：

消耗流程，而不是閉合任務。

這對 Agent workflow 很適合作為 diagnostic metric。

28. Process Inversion Point

令 visible process intensity：

IP.I_P.

其邊際收益：

MBP(IP)MB_P(I_P)

主要來自：

  • defect prevention；
  • coordination clarity；
  • authority safety；
  • evidence quality；
  • rollback readiness。

邊際成本：

MCP(IP)MC_P(I_P)

來自：

  • token；
  • wall clock；
  • context fragmentation；
  • human interruptions；
  • duplicated review；
  • delayed implementation；
  • approval fatigue；
  • lost flow。

存在某個：

I∗I^\ast

使：

IP>I∗I_P>I^\ast

時：

MCP(IP)>MBP(IP).\boxed{ MC_P(I_P) > MB_P(I_P). }

此後 process 由：

SafetyMechanism\text{SafetyMechanism}

反轉成：

ProductivityBottleneck.\text{ProductivityBottleneck}.

這就是：

Process Inversion Point

29. 高能力模型的反直覺：能力上升，Visible Process 不一定應上升

一種常見直覺是：

模型越高階，應該越嚴謹，所以流程越多。

但這混淆：

InternalDepth\text{InternalDepth}

與：

VisibleProcessDepth.\text{VisibleProcessDepth}.

高能力模型可以：

InternalPlanningDepth↑,\text{InternalPlanningDepth}\uparrow, InternalVerificationDepth↑,\text{InternalVerificationDepth}\uparrow,

同時：

VisibleProcessDepth↓.\text{VisibleProcessDepth}\downarrow.

因為更多中間 transition 可以被 Agent 自己可靠處理。

因此作者既有提案定義：

ProcessDepth=f(ModelCompetence,TaskRisk,Ambiguity,Irreversibility,EvidenceGap).\boxed{ \text{ProcessDepth} = f( \text{ModelCompetence}, \text{TaskRisk}, \text{Ambiguity}, \text{Irreversibility}, \text{EvidenceGap} ). }

在其他條件固定時：

ModelCompetence↑\text{ModelCompetence}\uparrow

可以導致：

OptimalVisibleProcessDepth↓.Optimal\text{VisibleProcessDepth}\downarrow.

這不是降低 rigor。

而是：

InternalRigor↑,ExternalFriction↓.\boxed{ \text{InternalRigor}\uparrow, \qquad \text{ExternalFriction}\downarrow. }

30. Adaptive Process Depth

本文將合理的 visible process depth 寫成：

DP∗=f(M,R,A,I,E,H),D_P^\ast = f( M, R, A, I, E, H ),

其中：

  • MM：Model competence；
  • RR：Task risk；
  • AA：Ambiguity；
  • II：Irreversibility；
  • EE：Evidence gap；
  • HH：Human coordination requirement。

這意味著同一 Agent：

低風險本地修改

silent / balanced

高風險 production migration

explicit plan
+ authority gate
+ staged validation

教學

interactive

使用者要求共同設計

interactive / collaborative

所以：

One Fixed Process\boxed{ \text{One Fixed Process} }

不是成熟 Agent runtime 的理想形態。

31. State First, Phase Second

流程驅動系統會問：

現在是哪個 phase？

狀態驅動系統會問：

現在缺什麼？

因此 Implicit Superpowers 提出：

State first, phase second.\boxed{ \text{State first, phase second.} }

例如目前已經：

  • intent clear；
  • architecture obvious；
  • low risk；
  • same known pattern；

就不需要為了「流程規定」再完整 brainstorm 一次。

反之，即使 nominal phase 已到 implementation，

若突然出現：

MaterialAmbiguity,\text{MaterialAmbiguity},

就應返回 decision。

所以 runtime 應：

CurrentState→CurrentNeed→SelectSkill→Execute→Observe.\text{CurrentState} \rightarrow \text{CurrentNeed} \rightarrow \text{SelectSkill} \rightarrow \text{Execute} \rightarrow \text{Observe}.

而不是：

Phase1→Phase2→Phase3\text{Phase}_1 \rightarrow \text{Phase}_2 \rightarrow \text{Phase}_3

固定前進。

32. Skill 是能力庫，不是儀式序列

若系統有：

  • brainstorming；
  • architecture；
  • TDD；
  • debugging；
  • review；
  • verification；
  • red-team；

成熟架構應把它們理解成：

Capability Library.\boxed{ \text{Capability Library}. }

由：

CurrentNeed\text{CurrentNeed}

路由。

而不是：

有 skill
→ 一定 invoke
→ 一定 announce
→ 一定產生 artifact
→ 一定要求 approval

所以：

Skill Availability≠Mandatory Visible Invocation.\boxed{ \text{Skill Availability} \neq \text{Mandatory Visible Invocation}. }

這是 AI-native workflow 與傳統 checklist workflow 的重要差別。

33. Workflow Contamination

如果某一種 Skill / workflow 被設為：

DefaultPrior,\text{DefaultPrior},

它可能逐漸把所有任務重新解讀成：

適合該 workflow 的任務.\text{適合該 workflow 的任務}.

例如所有問題都被轉成：

brainstorm
→ design
→ plan
→ \text{TDD}
→ reviewer
→ reviewer of reviewer

即使原始 task 只是：

改一行 config。

此時問題不只是 cost。

而是：

Workflow Prior→Task Representation.\boxed{ \text{Workflow Prior} \rightarrow \text{Task Representation}. }

Agent 不再先問：

這個任務需要什麼？

而是先問：

我的 workflow 下一步是什麼？

本文將此視為 Process-Proxy Misalignment 的上游來源之一。

34. Process Thrashing

若 workflow 在多個 phase 間反覆：

Plan→Review→RevisePlan→Review→Replan→⋯\text{Plan} \rightarrow \text{Review} \rightarrow \text{RevisePlan} \rightarrow \text{Review} \rightarrow \text{Replan} \rightarrow\cdots

但沒有：

ΔX>0\Delta X>0

或顯著：

ΔE>0,\Delta E>0,

則可定義：

Process Thrashing

其特徵是：

StateTransitionCount↑\text{StateTransitionCount}\uparrow

但：

MissionDistanceReduction≈0.\text{MissionDistanceReduction}\approx0.

它與 distributed systems 的 livelock 類似：

系統一直活動，但沒有有效前進。

35. 流程不是越少越好

本文必須防止被解讀成：

少規劃、少測試、少 review 就比較 AI-native。

這是錯誤的。

對高風險工作：

Risk↑\text{Risk}\uparrow

合理地要求：

ValidationDepth↑,\text{ValidationDepth}\uparrow, AuthorityControl↑.\text{AuthorityControl}\uparrow.

例如：

  • production credentials；
  • irreversible deletion；
  • financial transfer；
  • schema migration；
  • security boundary；
  • regulated data；
  • public release；
  • safety-critical control。

所以本文真正主張的是：

Process Depth Should Be Causally Justified.\boxed{ \text{Process Depth Should Be Causally Justified}. }

而不是：

Process Depth Should Be Minimal at Any Cost.\text{Process Depth Should Be Minimal at Any Cost}.

36. Explicit Process 的合法場景

外顯 process 在下列情境中具有明確價值：

36.1 Material Ambiguity

兩個合理解釋會導致不同產品。

36.2 High Irreversibility

錯誤難 rollback。

36.3 High External Consequence

會影響第三方、財務、production、public release。

36.4 Multi-Team / Durable Handoff

plan 是共享 contract。

36.5 Teaching / Auditability

過程本身就是產品的一部分。

36.6 User Explicitly Requests Co-Design

使用者本來就要參與思考過程。

因此：

ExplicitProcess\boxed{ \text{ExplicitProcess} }

是一種：

Contextual Tool,\boxed{ \text{Contextual Tool}, }

不是：

Universal Default.\boxed{ \text{Universal Default}. }

37. Visible Ceremony Share

定義：

CvisibleC_{\mathrm{visible}}

為使用者必須直接參與或閱讀的 workflow cost。

總 process cost：

Cprocess.C_{\mathrm{process}}.

則：

VCS=CvisibleCprocess.\boxed{ VCS = \frac{C_{\mathrm{visible}}}{C_{\mathrm{process}}}. }

稱為：

Visible Ceremony Share

對 mature high-capability agent，普通低風險工作理想上：

VCS↓.VCS\downarrow.

對 audit / teaching / co-design：

VCSVCS

可以合理上升。

所以 VCS 不是品質指標，而是：

interaction topology metric.\text{interaction topology metric}.

38. 不要用單一 productivity 指標評估 workflow

A04 不建議只測：

TaskSuccess.\text{TaskSuccess}.

也不只測：

TokenCost.\text{TokenCost}.

應建立多維向量：

Q=(TaskSuccess,DefectRate,Rework,TokenCost,WallClock,HumanInterruptions,EvidenceGain,MissionClosure,InteractionFriction).\mathbf Q = ( \text{TaskSuccess}, \text{DefectRate}, \text{Rework}, \text{TokenCost}, \text{WallClock}, \text{HumanInterruptions}, \text{EvidenceGain}, \text{MissionClosure}, \text{InteractionFriction} ).

作者既有 Implicit Superpowers 已提出對照實驗：

Control

Original explicit workflow.

Treatment

Implicit / internalized workflow.

比較：

Ninterrupt,N_{\mathrm{interrupt}}, TokenCost,\text{TokenCost}, WallClock,\text{WallClock}, TaskSuccess,\text{TaskSuccess}, DefectRate,\text{DefectRate}, Rework.\text{Rework}.

這是一個非常適合進一步實證化的基礎。

39. 主要可驗證假說

H1 — Visible Workflow Compression

Ninterrupt,treatment<Ninterrupt,control.N_{\mathrm{interrupt,treatment}} < N_{\mathrm{interrupt,control}}.

同時：

TaskSuccesstreatment≥TaskSuccesscontrol−ϵ.\text{TaskSuccess}_{\mathrm{treatment}} \ge \text{TaskSuccess}_{\mathrm{control}} -\epsilon.

H2 — Cost Dominance

若：

Qualityimplicit≈Qualityexplicit\text{Quality}_{\mathrm{implicit}} \approx \text{Quality}_{\mathrm{explicit}}

但：

Costimplicit<Costexplicit,\text{Cost}_{\mathrm{implicit}} < \text{Cost}_{\mathrm{explicit}},

則支持：

visible workflow ceremony is no longer paying for itself.\boxed{ \text{visible workflow ceremony is no longer paying for itself}. }

H3 — Process Inversion

存在：

DP∗D_P^\ast

使超過後：

dMissionClosuredProcessCost\frac{d\text{MissionClosure}}{d\text{ProcessCost}}

顯著下降。

H4 — Authority Gate Advantage

將 approval 從 phase transition 改為 authority transition，可降低：

HumanInterruptions\text{HumanInterruptions}

而不增加 consequential unauthorized actions。

H5 — Validation Yield

以 marginal evidence gain 路由 validation，可降低重複 validation cost，而不提高 escaped defect rate。

40. 如何找出「真正有因果價值的流程」

不要直接刪 phase。

應做 process ablation。

例如：

Baseline:
brainstorm + design + plan + \text{TDD} + reviewer + verifier

Ablation A:
remove user-visible brainstorming approval

Ablation B:
remove second reviewer

Ablation C:
batch validation

Ablation D:
replace phase gate with authority gate

測：

ΔQuality,\Delta \text{Quality}, ΔDefect,\Delta \text{Defect}, ΔCost,\Delta \text{Cost}, ΔCompletionTime.\Delta \text{CompletionTime}.

如果移除某 gate：

Quality↓↓,\text{Quality}\downarrow\downarrow,

它就有因果價值。

如果：

Quality≈constant\text{Quality}\approx \text{constant}

而：

Cost↓,\text{Cost}\downarrow,

則該 visible gate 可能主要是 ceremony。

所以本文不是：

憑感覺刪流程。

而是：

Empirical Process Causal Audit.\boxed{ \text{Empirical Process Causal Audit}. }

41. Process Audit Checklist

對任何 Agent Skill / workflow，可以問：

  1. 這一步改變了 product state 嗎？
  2. 若沒有，是否產生新 decision-relevant evidence？
  3. 若沒有，是否解決真實 coordination / authority ambiguity？
  4. 這一步是否只是因為 phase 結束？
  5. 同一 evidence 是否已取得？
  6. 是否存在新的 propagation reason？
  7. 是否真的需要 human authority？
  8. 是否可由 Agent internalize？
  9. 移除後 quality 是否實際下降？
  10. 它是否讓 mission closure 更快？
  11. 它是否只是讓 workflow 看起來更完整？
  12. 停止條件是否存在？

若：

1=0,2=0,3=01=0, 2=0, 3=0

且：

4=1,4=1,

則該步高度可能屬於：

CeremonialProcess.\boxed{ \text{CeremonialProcess}. }

42. 一個 AI-Native 的基本節律

對普通、可逆、scope 清楚的 substantial engineering task，本文建議的基本節律不是：

tiny edit
→ full validation
→ approval
→ tiny edit
→ full validation
→ reviewer
→ new approval
→ repeat

而是：

Intent
→ Scope
→ Global understanding
→ Internal plan
→ Global implementation
→ Relevant validation
→ Root-cause clustering
→ Batched repair
→ Affected validation
→ Final relevant global validation
→ Obligation closure
→ STOP

人類只在：

authority transition
material ambiguity
scope change
irreversible risk
value decision

介入。

這不是：

NoProcess.\text{NoProcess}.

而是：

Process Internalization+Exception-Based Governance.\boxed{ \text{Process Internalization} + \text{Exception-Based Governance}. }

43. A04 與 A05 的邊界

A04 討論：

process activity 何時被錯誤地當成 progress。

A05 將討論：

review / validation 找到的東西，何時被錯誤地升格成新的 mandatory obligation。

所以：

A04=Process Proxy Problem.A04 = \text{Process Proxy Problem}. A05=Obligation Expansion Problem.A05 = \text{Obligation Expansion Problem}.

兩者會形成：

ProcessDensity↑\text{ProcessDensity}\uparrow

加上：

CompletionFrontier↑\text{CompletionFrontier}\uparrow

的雙重拖延。

44. 與 A06 的關係

A06 會處理：

Vgeneration>Vverification/governance.V_{\mathrm{generation}} > V_{\mathrm{verification/governance}}.

A04 提供它的微觀機制：

當 creation 變快後，verification 成為 bottleneck。

如果工作流對此的反應只是：

More Review+More Validation+More Approval,\text{More Review} + \text{More Validation} + \text{More Approval},

則：

VerificationCapacity\text{VerificationCapacity}

未必真正提高。

甚至：

Verification Activity↑whileVerification Throughput↑̸.\boxed{ \text{Verification Activity} \uparrow \quad\text{while}\quad \text{Verification Throughput} \not\uparrow. }

所以 A06 需要的不只是更多 verification，而是：

higher verification yield per unit resource.\boxed{ \text{higher verification yield per unit resource}. }

45. 核心命題

本文將 v0.2 壓縮為十四條核心命題。

P1 — Process / Mission Separation

Process Activity≠Mission Progress.\boxed{ \text{Process Activity} \neq \text{Mission Progress}. }

P2 — Four-State Separation

ProcessState≠ProductState≠EvidenceState≠MissionState.\boxed{ \text{ProcessState} \neq \text{ProductState} \neq \text{EvidenceState} \neq \text{MissionState}. }

P3 — Plan Non-Completion

PlanComplete⇏TaskComplete.\boxed{ \text{PlanComplete} \nRightarrow \text{TaskComplete}. }

P4 — Validation Non-Completion

Validation=EvidenceForCompletion≠Completion.\boxed{ \text{Validation} = \text{EvidenceForCompletion} \neq \text{Completion}. }

P5 — Review Non-Improvement

ReviewComplete⇏ProductImproved.\boxed{ \text{ReviewComplete} \nRightarrow \text{ProductImproved}. }

P6 — Token Non-Productivity

TokenThroughput≠MissionProductivity.\boxed{ \text{TokenThroughput} \neq \text{MissionProductivity}. }

P7 — Tool-Count Non-Productivity

ToolCalls≠UsefulStateTransitions.\boxed{ \text{ToolCalls} \neq \text{UsefulStateTransitions}. }

P8 — Continuation Non-Preference

Continue≠WorkflowPreference.\boxed{ \text{Continue} \neq \text{WorkflowPreference}. }

P9 — Approval Non-Oversight

MoreHumanClicks≠MoreHumanOversight.\boxed{ \text{MoreHumanClicks} \neq \text{MoreHumanOversight}. }

P10 — Authority-Gate Principle

AuthorityTransition⇒Approval\boxed{ \text{AuthorityTransition} \Rightarrow \text{Approval} }

優於固定：

PhaseTransition⇒Approval.\text{PhaseTransition} \Rightarrow \text{Approval}.

P11 — Adaptive Process Depth

DP∗=f(ModelCompetence,Risk,Ambiguity,Irreversibility,EvidenceGap,HumanCoordination).\boxed{ D_P^\ast = f( \text{ModelCompetence}, \text{Risk}, \text{Ambiguity}, \text{Irreversibility}, \text{EvidenceGap}, \text{HumanCoordination} ). }

P12 — Process Inversion

存在：

I∗I^\ast

使：

I>I∗⇒MarginalCost(Process)>MarginalBenefit(Process).I>I^\ast \Rightarrow \text{MarginalCost}(\text{Process}) > \text{MarginalBenefit}(\text{Process}).

P13 — Internal Rigor / External Simplicity

InternalRigor↑∧ExternalFriction↓\boxed{ \text{InternalRigor}\uparrow \quad\land\quad \text{ExternalFriction}\downarrow }

可以同時成立。

P14 — Mission-Yield Principle

真正值得優化的是：

Intent / Mission Closure GainToken + Tool + Human + Wallclock Cost\boxed{ \frac{ \text{Intent / Mission Closure Gain} }{ \text{Token + Tool + Human + Wallclock Cost} } }

而不是：

Process Density.\text{Process Density}.

46. 結論

AI 工程進入高能力 Agent 階段後，一個非常容易被忽略的問題是：

流程本身可以變得比產品更容易被生成。

AI 很容易生成：

  • plan；
  • design note；
  • review；
  • test；
  • checklist；
  • governance memo；
  • status update；
  • second opinion。

這些 artifact 都可以合理、完整、甚至高品質。

但如果：

ΔCmission≈0,\Delta C_{\mathrm{mission}}\approx0,

那麼：

busy≠progress.\boxed{ \text{busy} \neq \text{progress}. }

成熟 AI workflow 的目標不是刪掉 planning、review、verification。

它應該保留：

Discipline\text{Discipline}

同時移除：

UnnecessaryCeremony.\text{UnnecessaryCeremony}.

也就是：

Keep the discipline; remove the ceremony.\boxed{ \text{Keep the discipline; remove the ceremony.} }

高能力 Agent 應該能把：

Understand→Plan→Execute→Verify→Repair\text{Understand} \rightarrow \text{Plan} \rightarrow \text{Execute} \rightarrow \text{Verify} \rightarrow \text{Repair}

大量內隱化，

只在真正存在：

AuthorityGap,\text{AuthorityGap}, MaterialAmbiguity,\text{MaterialAmbiguity}, IrreversibleRisk,\text{IrreversibleRisk}, ScopeChange,\text{ScopeChange}, HumanValueDecision\text{HumanValueDecision}

時把人類叫回來。

因此本文留下的最終工程原則是：

 Do not measure intelligence by how much process it displays. Measure the causal contribution of process to justified completion. \boxed{ \textbf{ Do not measure intelligence by how much process it displays. Measure the causal contribution of process to justified completion. } }

中文即：

不要用 AI 展示了多少流程來衡量它有多高階；要看這些流程到底為完成、證據與風險控制提供了多少因果價值。

參考文獻

A. 外部研究與實證

  1. Cui, Z. (K.), Demirer, M., Jaffe, S., Musolff, L., Peng, S., & Salz, T. (2025). The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers. Microsoft Research.
    合併三個 randomized field experiments、4,867 名開發者，觀察 AI coding assistant 使用者 completed tasks 增加 26.08%。

  2. Becker, J., Rush, N., Barnes, B., & Rein, D. (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. METR / arXiv.
    16 名資深 open-source developers、246 個真實 tasks；AI-assisted 條件完成時間增加 19%。

  3. Becker, J., Rush, N., Cunningham, T., Rein, D., & Mahamud, K. (2026). We are Changing our Developer Productivity Experiment Design. METR, 2026-02-24.
    說明 late-2025 / early-2026 follow-up experiment 因無 AI 條件 participation selection effects 與 multi-agent time measurement 問題而難以可靠估計 uplift。

  4. Vella, A., & Blincoe, K. (2026). The Impact of AI Coding Assistants on Software Engineering: A Longitudinal Study. arXiv:2605.23135.
    Longitudinal mixed-methods preprint；提出 supervisory engineering work，並觀察 creation → verification 的工作重心轉移。本文將其視為近期 preprint，而非已確立的跨產業普遍定律。

  5. DORA / Google Cloud. (2025). State of AI-Assisted Software Development 2025.
    將 AI 描述為 amplifier；AI adoption 與 throughput / product performance 的正向關係同時伴隨 delivery stability 的負向關係，並強調底層 delivery system、platform、workflow 與 team alignment 的重要性。

  6. DORA. (2026). Balancing AI tensions: Moving from AI adoption to effective SDLC use.
    指出 code creation 節省的時間常重新分配到 auditing 與 verification。

  7. Turan, E. (2026). Oversight Has a Capacity: Calibrating Agent Guards to a Subjective, Fatiguing Human. arXiv:2606.08919.
    將 agent oversight 建模為有限 human-attention resource allocation；文中的 fatigue / inverted-U 結果屬模型與 125-action testbed 分析，不能直接當成大規模人類行為實證。

  8. Jureczko, M. (2020). Code review effectiveness: an empirical study on selected factors influence. IET Software.
    研究觀察 changeset size 增長與 review effectiveness 下降的關係。

  9. Pascarella, L., et al. (2022). The evolution of the code during review: an investigation on review changes. Empirical Software Engineering.
    研究指出 review changes 數量與 initial patch size、new lines of code 存在關係。

B. Neo.K / EveMissLab 既有研究

  1. Neo.K. 〈綠燈錯置——AI 時代「通過驗證」不等於「完成意圖」的新型不對齊〉，2026.

  2. Neo.K. 〈表觀成功與實質完成的分離〉，A02 v0.2，2026.

  3. Neo.K. 〈局部正確與全域失敗〉，A03 v0.2，2026.

  4. Neo.K. Implicit Superpowers — 將外顯流程改造成內隱 Agent Governance 的改造提案, v0.1, 2026.

  5. Neo.K. Global Completion Theory: From Local-First Execution to Global-First Instantiation in the AI Era, v1.0, 2026.

  6. Neo.K. Global-First Completion, v2 / v2.1, 2026.

  7. Neo.K. 〈AI 寫得越快，屎山會長得越快嗎？AI 原生開發的新技術債〉，《表觀完好系統》Series 10, 2026.

  8. Neo.K. AI Apprenticeship / Risk-Routed Oversight 相關研究，2026.

End of A04 v0.2