title: 有效能力不是模型能力：任務、使用者、上下文、算力與驗證的條件化
english_title: Effective Capability Is Not Model Capability: Task-, User-, Context-, Compute-, and Verification-Conditioned AI Performance
series: AI 動態能力本體論：潛能、激發、內生性與耦合
series_english: Dynamic Capability Ontology of AI: Potential, Activation, Endogeneity, and Coupling
paper: 02 / 09
author: Neo.K / EveMissLab
ai_collaboration: Aletheia / GPT-5.6 Sol
date: 2026-09-12
version: v0.1
document_type: 系列論文／有效能力條件化／人機耦合與計算轉化架構
status: Canonical Series Draft
encoding: UTF-8
depends_on: DCAO_Paper00_AI_Capability_Ontology_Master_Framework_v0.1_zh-TW.md · DCAO_Paper01_Potential_Is_Not_Activation_v0.1_zh-TW.md
predecessor_theories: MPD 的人機耦合狀態 · 智能計算轉化與分配定律 · 脈衝式智能發展與現實耦合閾值 · 表徵閘門猜想 · Distributed Cognitive Runtime

有效能力不是模型能力

——任務、使用者、上下文、算力與驗證的條件化

Effective Capability Is Not Model Capability

Task-, User-, Context-, Compute-, and Verification-Conditioned AI Performance

作者： Neo.K / EveMissLab
機構： EveMissLab／一言諾科技有限公司
日期： 2026-09-12
版本： v0.1

摘要

當代 AI 評估最常見的抽象，是把一個模型表示成一組近似固定的能力值：數學能力、程式能力、推理能力、搜尋能力、寫作能力、規劃能力。然而，只要模型被放進真實產品、Agent Runtime、工具系統、人機協作流程或長期任務中，這種抽象便快速失效。相同底層模型，在不同任務定義、不同使用者、不同上下文、不同計算資源、不同工具、不同記憶、不同驗證器與不同權限條件下，可以形成截然不同的實際可完成任務域。

本文提出：

\boxed{ \text{Nominal Model Capability} \neq \text{Effective AI Capability} }

並將有效能力定義為條件化能力函數：

\boxed{ \mathcal C_{\mathrm{eff}} = F( \mathcal C_{\mathrm{nom}}, Q, U, X, M, T, K, R, V, P, L, W, S ) }

其中：

$\mathcal C_{\mathrm{nom}}$ ：模型／系統名義能力；
$Q$ ：任務與問題規格；
$U$ ：使用者／上游智能體耦合；
$X$ ：工作上下文與表徵；
$M$ ：持續記憶；
$T$ ：工具與可執行環境；
$K$ ：實際分配計算；
$R$ ：routing / orchestration；
$V$ ：驗證與反證；
$P$ ：權限與政策；
$L$ ：延遲與時限；
$W$ ：外部世界狀態；
$S$ ：長程狀態連續性。

本文承接 Paper 01 的八層能力狀態：

P \rightarrow E \rightarrow R \rightarrow L \rightarrow A \rightarrow C \rightarrow X \rightarrow V

並提出：上述能力鏈本身並不足以決定實際表現。即使某能力已達 Validated Effective 層，只要任務規格不完整、使用者無法提供必要領域約束、上下文被污染、算力不足、工具失效、權限受限或世界狀態改變，該能力在當下仍可能不可實現。

本文因此建立三個層級：

\boxed{ \mathcal C_{\mathrm{latent}} \supseteq \mathcal C_{\mathrm{available}} \supseteq \mathcal C_{\mathrm{effective}} }

並進一步區分：

模型名義能力；
系統可用能力；
任務條件有效能力；
使用者—AI 聯合有效能力；
經驗證可承諾能力。

本文還提出「能力條件向量」「條件化能力曲面」「任務適配係數」「人機耦合係數」「上下文品質係數」「計算配置係數」「狀態連續係數」「驗證增益／驗證稅」「權限切面」「延遲可行域」等概念，以將 Same Model ≠ Same Effective Capability 從直覺轉化為可測研究框架。

最後，本文提出：

\boxed{ \text{Effective Capability} = \text{Nominal Capability} \times \text{Conditioning Quality} - \text{Dissipation} }

作為零階直覺式，並指出真正成熟的 AI benchmark 必須從只測「模型」轉向同時測量 model、runtime、user coupling、tooling、memory、verification 與 world-grounding。

關鍵詞

Effective Capability；Nominal Capability；Human–AI Coupling；Task Fit；Context Quality；Compute Allocation；Verification；Memory；Tool Use；Runtime；State Continuity；Capability Conditioning；AI Benchmark；Capability Surface；Capability Dissipation

0. 問題：同一模型為什麼不像同一個工具？

假設兩個人都使用同一模型：

A.

且：

模型版本相同；
參數相同；
推理引擎相同。

若 AI 是一台固定函數計算器，則可以近似：

A_{u_1} = A_{u_2}.

但現代 AI 並不是只接受固定格式輸入。

它會依賴：

使用者提供的資訊；
任務規格；
context；
tools；
memory；
inference budget；
feedback；
validation；
authority；
environment。

因此實際系統更像：

A_{\mathrm{eff}} = A \mid \Omega,

其中：

\Omega

為條件集合。

所以：

\boxed{ \text{Same Model} \neq \text{Same Effective System} }

1. 名義能力

定義：

\mathcal C_{\mathrm{nom}}(A)

表示模型／系統在標準測試或理想條件下可表現出的能力域。

它可能來自：

benchmark；
provider documentation；
internal eval；
controlled test。

名義能力有用。

但它不是當下實際能力。

2. 可用能力

定義：

\mathcal C_{\mathrm{avail}}(A,t)

為時間 $t$ 下，系統技術上可調用的能力。

例如：

tool online；
memory mounted；
model available；
quota sufficient；
permission present。

所以：

\mathcal C_{\mathrm{avail}} \subseteq \mathcal C_{\mathrm{nom}}^{\mathrm{system}}

通常成立。

3. 有效能力

定義：

對任務 $q$ ，在指定時間、資源、狀態、權限、上下文與驗證條件下，系統真正能穩定完成的能力。

形式上：

\boxed{ \mathcal C_{\mathrm{eff}}(q,t) = \operatorname{Realize} ( \mathcal C_{\mathrm{avail}}, \Omega_{q,t} ) }

其中：

\Omega_{q,t}

為條件狀態。

4. 能力條件向量

本文定義：

\boxed{ \boldsymbol\omega_{q,t} = ( \phi_Q, \phi_U, \phi_X, \phi_M, \phi_T, \phi_K, \phi_R, \phi_V, \phi_P, \phi_L, \phi_W, \phi_S ) }

每個 $\phi_i$ 表示一個條件維度。

5. 任務適配係數

定義：

\phi_Q = \operatorname{Fit}(A,q).

它描述：

模型／系統結構與任務本身是否相容。

例如：

一個擅長 coding 的模型對法律證據分析未必同樣強；
一個視覺模型對純符號證明未必適合。

因此：

\boxed{ \text{General Capability} \neq \text{Uniform Domain Capability} }

6. Task Specification Quality

任務本身也可能規格不足。

定義：

Q_{\mathrm{spec}}.

若：

Q_{\mathrm{spec}}\downarrow,

則：

ambiguity 上升；
branch explosion 上升；
validation 變難；
output selection 變差。

因此：

\phi_Q = F( \text{domain fit}, Q_{\mathrm{spec}} ).

7. 任務模糊度

定義：

H_Q = \text{Task Ambiguity}.

通常：

H_Q\uparrow \Rightarrow C_{\mathrm{coord}}\uparrow.

如果 AI 必須先猜使用者到底想做什麼，更多計算會消耗在 intent recovery。

8. 任務分解品質

對大型任務：

q \rightarrow \{q_1,\dots,q_n\}.

若分解不良：

子任務互相衝突；
遺漏依賴；
重複工作；
驗收無法閉合。

所以：

\boxed{ \text{Task Decomposition} \text{ is a capability conditioner.} }

9. 使用者耦合係數

定義：

\phi_U = C_{\mathrm{HA}}(u,d,t).

它不代表親密度。

而是：

使用者與 AI 在領域 $d$ 、時間 $t$ 下形成有效協作的能力。

10. Same Model ≠ Same Effective Tool

即使：

A_{u_1} = A_{u_2},

仍可能：

\phi_U(u_1) \neq \phi_U(u_2).

所以：

\mathcal C_{\mathrm{eff}}(u_1) \neq \mathcal C_{\mathrm{eff}}(u_2).

11. 使用者提供的是額外狀態，不只是 prompt

使用者可能提供：

domain knowledge；
constraints；
acceptance criteria；
counterexamples；
history；
taste；
risk judgment。

因此：

U

不是外部噪聲。

它可能是 system cognition 的輸入層。

12. 專業使用者的槓桿

專業使用者不只自己更強。

他可能讓 AI：

少猜；
少走錯路；
更快修正；
使用正確術語；
設定更好測試。

所以：

\boxed{ \Delta H \text{ can induce } \Delta A_{\mathrm{effective}}. }

13. 新手也可能獲得巨大增益

但：

\phi_U

高不等於只有專家能用 AI。

AI 可以大幅降低：

entry barrier；
syntax barrier；
procedural barrier。

所以新手也可能從：

P\approx0

提升到：

P>0.

14. 相對增益與絕對增益

定義：

G_{\mathrm{abs}} = P(H+A)-P(H).

以及：

G_{\mathrm{rel}} = \frac{ P(H+A)-P(H) }{ P(H)+\varepsilon }.

新手可能：

G_{\mathrm{rel}}

更高。

專家可能：

G_{\mathrm{abs}}

更高。

兩者不矛盾。

15. 使用者校正能力

定義：

C_{\mathrm{corr}}(u).

若使用者能快速判斷：

hallucination；
wrong scope；
bad architecture；
hidden assumption；

則 system error persistence 降低。

16. 驗收條件能力

一個重要人類能力是：

C_{\mathrm{accept}}(u).

也就是：

能否定義「什麼才算完成」。

這會直接影響 Agent 是否無限漂移。

17. 上下文品質

定義：

\phi_X = Q_{\mathrm{context}}.

Context 不是越多越好。

18. Context Completeness

若必要條件缺失：

Q_{\mathrm{context}}\downarrow.

但完整不等於把所有歷史都塞進去。

19. Context Relevance

定義：

R_X = \frac{ \text{Relevant Information} }{ \text{Total Context} }.

如果：

R_X\downarrow,

模型可能：

分心；
誤取舊狀態；
被不相關模式干擾。

20. Context Contradiction

Context 中若同時存在：

x

與：

\neg x,

而沒有 version / temporal semantics，

則能力可能下降。

因此：

\boxed{ \text{More Context} \neq \text{Better Context}. }

21. Context Freshness

對動態世界資訊：

F_X(t).

一條舊資訊可能曾經正確，但現在錯。

所以 context quality 必須包含 freshness。

22. Context Provenance

相同句子：

server is healthy

若來源不同，其可靠度不同。

Context 應帶：

source；
time；
authority；
status。

23. Context Compilation

Persistent memory 不應整包送入模型。

應：

M \rightarrow \operatorname{CompileContext}(q) \rightarrow X_q.

所以：

\boxed{ \text{Context Quality} \text{ depends on compilation.} }

24. Memory 條件

定義：

\phi_M = Q_M.

Memory 可以提升：

continuity；
retrieval；
learned workflow；
user alignment。

25. Memory 也可能傷害能力

如果 memory：

stale；
wrong；
overgeneralized；
unauthorized；
duplicated；

則：

Q_M<0

的效果可能出現。

因此：

\boxed{ \text{Persistent Memory} \neq \text{Persistent Improvement}. }

26. Memory Retrieval

真正影響能力的是：

M \rightarrow R_M(q).

而不是 memory 容量。

所以：

\boxed{ \text{Memory Size} \neq \text{Memory Utility}. }

27. 工具條件

定義：

\phi_T = Q_T.

工具可以：

擴張 action space；
增加 precision；
提供 external state；
執行 verification。

28. Tool Presence vs Tool Utility

工具存在：

T\in \mathrm{Registry}

不代表：

Q_T>0.

如果：

API unstable；
schema unclear；
latency high；
output unreliable；

工具反而可能降低有效能力。

29. Tool Selection

工具越多，routing 問題越難。

因此：

|T|\uparrow

可能使：

D_{\mathrm{routing}}\uparrow.

30. Tool Composition

複雜任務通常需要：

T_1\rightarrow T_2\rightarrow T_3.

因此：

Q_T

也取決於 tool composition。

31. 計算配置

定義：

\phi_K = Q_K.

同一模型可用：

shallow inference；
extended reasoning；
multi-sample；
search；
self-consistency；
verifier loop。

32. 可見 Token 不是計算量

輸出：

N_{\mathrm{out}}

不能穩定代表：

C_{\mathrm{compute}}.

因為系統可能使用大量 hidden compute。

33. 計算分配

定義：

K_{\mathrm{alloc}} = K_{\mathrm{base}} + K_{\mathrm{reason}} + K_{\mathrm{branch}} + K_{\mathrm{tool}} + K_{\mathrm{verify}} + K_{\mathrm{memory}} + K_{\mathrm{route}}.

34. 更多算力不必然更好

若：

\eta_K

低，

則：

K\uparrow

只會增加成本。

因此：

\boxed{ \text{More Compute} \neq \text{More Effective Capability}. }

35. 推理時計算適配

某些任務受益於：

K_{\mathrm{reason}}\uparrow.

某些簡單任務則可能沒有明顯增益。

所以 compute allocation 需要 task-conditioned routing。

36. 計算轉化效率

定義：

\eta_{\mathrm{comp}} = \frac{ \Delta P_{\mathrm{useful}} }{ K_{\mathrm{alloc}} }.

37. 系統級計算效率

進一步：

\eta_{\mathrm{sys}} = F( \eta_{\mathrm{model}}, \eta_{\mathrm{route}}, \eta_{\mathrm{memory}}, \eta_{\mathrm{tool}}, \eta_{\mathrm{verify}} ).

38. Routing 條件

定義：

\phi_R = Q_R.

Routing 包括：

model selection；
tool selection；
memory route；
agent selection；
verifier selection。

39. Routing 是 Meta-Capability

如果 routing 弱：

\mathcal C_{\mathrm{available}}

很大，

仍可能：

\mathcal C_{\mathrm{effective}}

很小。

40. Routing Error

定義：

E_R = P( \text{wrong capability path selected} ).

降低 $E_R$ 可以不修改模型權重卻顯著提高有效能力。

41. Verification 條件

定義：

\phi_V = Q_V.

Verifier 可以：

reject；
repair；
reroute；
request evidence；
stop。

42. 驗證增益

若：

P_{\mathrm{raw}}

為原始成功率，

P_{\mathrm{verified}}

為驗證後成功率，

則：

G_V = P_{\mathrm{verified}} - P_{\mathrm{raw}}.

43. 驗證稅

驗證也有成本：

T_V = C_{\mathrm{compute}} + C_{\mathrm{latency}} + C_{\mathrm{coord}}.

因此：

\boxed{ \text{Verification Gain} \neq \text{Free Gain}. }

44. 過度驗證

若低風險任務使用高強度 verifier：

T_V \gg G_V.

則系統變慢。

所以 verification policy 也需要 task fit。

45. Validator Quality

錯誤 verifier 會形成：

\text{False Confidence}.

所以：

\boxed{ \text{Having a Verifier} \neq \text{Having Reliable Verification}. }

46. 權限條件

定義：

\phi_P = Q_P.

AI 可能知道怎麼做，卻沒有權限。

所以：

\mathcal C_{\mathrm{authorized}} \subseteq \mathcal C_{\mathrm{executable}}.

47. Capability vs Authority

再固定：

\boxed{ \text{Capability} \neq \text{Authority}. }

48. 權限切面

能力圖在給定 principal 下：

\mathbb G^{\mathrm{cap}}

會被投影成：

\mathbb G^{\mathrm{cap}}_P.

也就是 authority-conditioned capability graph。

49. Authority Revocation

若權限撤銷：

P_t(c)=0,

有效能力立即下降，即使底層技術能力未變。

50. Latency 條件

定義：

\phi_L.

很多能力在理論上可做，但如果：

T_{\mathrm{response}} > T_{\mathrm{deadline}},

則對任務而言等效失效。

51. Latency Feasible Set

定義：

\mathcal C_L = \{ c: T_c \le T_{\mathrm{deadline}} \}.

所以 realtime system 的能力域不同於 offline research system。

52. 世界條件

定義：

\phi_W = Q_W.

能力是否有效也取決於外界。

例如：

market open；
robot sensor healthy；
website accessible；
game state permits action。

53. World Availability

外部服務關閉：

W_t

改變。

能力可能失效，即使模型完全沒變。

54. State Continuity

定義：

\phi_S = Q_S.

長期 Agent 若每次都忘記：

S_{t-1},

就會重做工作。

55. State Dissipation

定義：

D_S.

包含：

context loss；
stale summary；
memory mismatch；
branch confusion；
identity discontinuity。

56. State Continuity Gain

若 persistent runtime 保存：

task state；
world state；
decisions；
failures；

則：

D_S\downarrow.

57. 零階能力式

本文先給直覺式：

\boxed{ C_{\mathrm{eff}} = C_{\mathrm{nom}} \cdot Q_{\mathrm{cond}} - D }

其中：

Q_{\mathrm{cond}}

為條件品質。

58. 條件品質

可寫：

Q_{\mathrm{cond}} = \Phi( \phi_Q, \phi_U, \phi_X, \phi_M, \phi_T, \phi_K, \phi_R, \phi_V, \phi_P, \phi_L, \phi_W, \phi_S ).

不預設是簡單乘法。

59. 為什麼不能直接相乘

如果：

\phi_P=0,

某些 action capability 直接失效。

這是 gate。

而：

\phi_U

可能只是增益。

不同條件的數學角色不同。

60. Gate / Gain / Cost

因此條件至少分三類。

Gate

不成立就不可用。

Gain

提高成功率。

Cost

消耗資源。

所以：

\Omega = ( \text{Gates}, \text{Gains}, \text{Costs} ).

61. Hard Gate

例如：

\text{Permission}=0.

則：

C_{\mathrm{exec}}=0.

62. Soft Gain

例如：

Q_{\mathrm{context}}\uparrow

可能只是提高成功率。

63. Cost Constraint

如果：

\text{Cost}(c)>\text{Budget},

即使能力存在也不可調用。

64. Effective Capability Surface

對兩個主要變數：

x,y,

可以畫：

P_c = f(x,y).

例如：

P_c = f( K_{\mathrm{compute}}, Q_{\mathrm{context}} ).

這是一個 capability surface。

65. 高維能力流形

真正系統則是：

P_c = F( \boldsymbol\omega ).

所以有效能力是一個高維條件流形上的函數。

66. Capability Ridge

某些區域：

P_c

會快速上升。

這代表 capability threshold。

67. Capability Cliff

某些條件稍降：

P_c \rightarrow0.

例如：

tool unavailable；
permission revoked；
missing dependency。

這是 capability cliff。

68. Robust Capability

真正 robust capability 要求：

P_c

在合理條件擾動下仍穩定。

69. Fragile Capability

若：

\left| \nabla_{\omega} P_c \right|

很大，

能力對條件極敏感。

70. Capability Elasticity

定義：

\epsilon_i^c = \frac{ \partial \ln P_c }{ \partial \ln \phi_i }.

表示能力對某條件的敏感度。

71. 找真正瓶頸

若：

\epsilon_K^c\approx0

但：

\epsilon_X^c\gg0,

那增加算力沒用。

應改 context。

72. 能力診斷

因此 system optimization 不是：

永遠換更大模型。

而是：

\operatorname{Diagnose} ( \arg\max_i |\epsilon_i^c| ).

73. 同一模型的多種 effective regimes

同一模型可形成：

Regime A

Model-only.

Regime B

Model + context.

Regime C

Model + tools.

Regime D

Model + memory + verifier.

Regime E

Persistent agent runtime.

這些是不同有效能力系統。

74. Model Capability Benchmark 的局限

只測：

B(A)

會混淆：

model；
prompt；
runtime；
tools；
evaluator。

75. System Benchmark

本文主張增加：

B(A,R,\Omega).

其中：

R

是 runtime。

76. Benchmark Profile

評估報告應標示：

Model
Inference Mode
Context
Tools
Memory
Verifier
Compute Budget
Human Intervention
Authority
World Access

77. 沒有 profile 的 benchmark 不完整

如果兩個 benchmark 條件不同：

B_1

與：

B_2,

直接比較「模型能力」可能誤導。

78. Human-in-the-Loop

若人類提供：

plan；
correction；
selection；
final validation；

則結果是：

C_{\mathrm{HA}}

而不是純：

C_A.

79. Human-Out-of-the-Loop

若 AI 獨立：

plan；
execute；
verify；
stop；

則測量的是另一種能力域。

不能混用。

80. AI-in-the-Loop

人類也可能是主要 agent，AI 只是：

critic；
search；
checker。

這也是另一個系統。

81. 有效能力的主體邊界

因此任何能力聲明都必須指定：

X.

例如：

X=A

或：

X=H+A

或：

X=A+\text{Runtime}.

82. 這不只是 Benchmark 問題

它也是本體問題：

到底是在評估模型、Agent、團隊，還是整個生產系統？

83. 能力轉化

從 nominal 到 effective：

\mathcal C_{\mathrm{nom}} \rightarrow \mathcal C_{\mathrm{eff}}

需要 conversion process。

84. Capability Conversion Efficiency

定義：

\eta_C = \frac{ |\mathcal C_{\mathrm{effective}}| }{ |\mathcal C_{\mathrm{available}}| }

這是粗略集合版。

85. 加權版

若不同能力價值不同：

\eta_C^{w} = \frac{ \sum_c w_c P_c^{\mathrm{eff}} }{ \sum_c w_c P_c^{\mathrm{avail}} }.

86. 低轉化效率

系統可能：

名義能力很強；
工具很多；
memory 很大；

但：

\eta_C\ll1.

這是典型「看起來很強，實際不好用」。

87. 高轉化效率

較小模型配好 runtime 可能：

\eta_C\uparrow.

因此小模型可能在特定任務打贏大模型。

88. Model Scale vs System Efficiency

N_{\mathrm{params}}\uparrow

不推出：

\eta_C\uparrow.

89. Capability Dissipation

定義：

D = D_Q+ D_U+ D_X+ D_M+ D_T+ D_K+ D_R+ D_V+ D_P+ D_L+ D_W+ D_S.

這是概念分解，不要求線性。

90. Coordination Dissipation

多 Agent / 多工具常見：

D_{\mathrm{coord}}.

如果過高：

C_{\mathrm{team}} < C_{\mathrm{single}}.

91. Verification Dissipation

驗證不良會：

重複檢查；
false reject；
false accept；
endless loop。

92. Context Dissipation

長上下文若混入大量無關歷史：

D_X\uparrow.

這和 Paper 08 直接相連。

93. State Dissipation

若每次 restart 都：

\tau_{\mathrm{restore}}\gg0,

長期能力下降。

94. 世界摩擦

即使 AI 決策很快，世界可能慢。

例如：

build；
compile；
robot move；
manufacturing；
legal approval。

所以：

C_{\mathrm{digital}}

不直接等於：

C_{\mathrm{world}}.

95. 脈衝式能力釋放

若瓶頸：

b

突然解除：

\phi_b: 0\rightarrow1,

可能導致：

C_{\mathrm{eff}}

跳升。

96. Capability Backlog

如果：

C_{\mathrm{nom}} \gg C_{\mathrm{eff}},

則可定義：

B_C = C_{\mathrm{nom}} - C_{\mathrm{eff}}

作為能力積壓。

97. 能力積壓的來源

包括：

weak tools；
no memory；
bad UI；
low authority；
poor verifier；
insufficient compute；
slow world。

98. 解除瓶頸比訓練新模型更重要的情況

若：

\frac{ \partial C_{\mathrm{eff}} }{ \partial \phi_i } > \frac{ \partial C_{\mathrm{eff}} }{ \partial C_{\mathrm{nom}} },

短期改善條件比換模型更划算。

99. Capability ROI

定義：

ROI_i = \frac{ \Delta C_{\mathrm{eff}} }{ \Delta \text{Cost}_i }.

用來決定：

upgrade model；
add memory；
improve tool；
improve validator。

100. 使用者也是能力投資方向

改善：

C_{\mathrm{HA}}

可能比升級模型更便宜。

例如：

better specification；
reusable templates；
domain ontology；
acceptance tests。

101. 組織吸收能力

企業即使買了最強 AI：

A^*,

若：

Q_{\mathrm{org}}\ll1,

有效能力仍低。

102. AI Adoption ≠ AI Absorption

因此：

\boxed{ \text{AI Access} \neq \text{AI Absorption}. }

103. 組織的 effective capability

可寫：

C_{\mathrm{org,eff}} = F( A, H, \text{Process}, \text{Data}, \text{Authority}, \text{Integration}, \text{Validation} ).

104. 長期共同歷史

使用者與 AI 的共同歷史可能提高：

\phi_U, \phi_X, \phi_M.

因此 coupling 本身可形成資本。

105. 但共同歷史也可能形成鎖定

如果：

舊假設；
舊偏見；
錯誤 memory；

持續累積，

則：

D_M\uparrow.

106. Dynamic Coupling

所以：

C_{\mathrm{HA}}(u,d,t)

不是固定。

可以：

C_{\mathrm{HA}}(t+1) = F( C_{\mathrm{HA}}(t), \text{Feedback}_t, \text{History}_t ).

107. Effective Capability 也是歷時的

C_{\mathrm{eff}}(t)

會改變，即使模型版本不變。

108. 為什麼產品體感會變

同一模型可能因：

server load；
inference policy；
tool availability；
memory changes；
UI changes；

讓使用者感覺「變笨」或「變強」。

109. Model Regression vs System Regression

若：

C_{\mathrm{eff}}\downarrow,

不必然：

C_{\mathrm{nom}}\downarrow.

可能只是：

\phi_i\downarrow.

110. Regression Diagnosis

因此 regression test 應分：

model；
context；
tool；
memory；
routing；
verifier；
latency；
permission。

111. Capability Attribution

成功結果：

y

不應全部歸因於模型。

應建立：

\operatorname{Attrib}(y) = ( A,U,X,M,T,K,R,V,\dots ).

112. Attribution 不是責任判決

這只是 causal contribution。

不直接等於：

legal responsibility；
authorship；
ownership。

113. Product Design Implication

如果有效能力高度條件化，產品設計重點不應只有：

expose the model.

而應是：

construct the right capability conditions.

114. AI-Native Interface

AI-native 產品應管理：

context；
tools；
memory；
permissions；
verification；
recovery。

而不是只放聊天框。

115. Capability UX

好的 UX 可以提高：

\phi_U, \phi_X, \phi_T.

所以 UX 本身可以改變 effective capability。

116. Voice / Semantic UI

自然語言介面可以降低：

K_{\mathrm{interaction}}.

讓同樣底層能力更可達。

117. Accessibility

若無障礙設計提高：

\phi_U,

則有效能力對更多使用者上升。

118. Capability Equality

同一模型對不同群體不一定提供相同：

C_{\mathrm{eff}}.

因此公平性研究也應關注：

interface；
language；
domain familiarity；
accessibility。

119. Language Effect

若使用者以不同語言互動：

Q_{\mathrm{context}}

與：

Q_{\mathrm{elicitation}}

可能不同。

120. Cross-Language Capability

所以：

C_{\mathrm{eff}}^{zh} \neq C_{\mathrm{eff}}^{en}

可能存在。

這不一定是模型「偏見」，也可能是 representation coverage 差異。

121. Capability Conditioning Matrix

可建立：

M_{ci} = \frac{ \partial P_c }{ \partial \phi_i }.

每列是能力，每欄是條件。

122. Condition Dominance

如果某能力主要依賴：

\phi_T,

則 tool-heavy。

若主要依賴：

\phi_U,

則 user-coupling-heavy。

123. Capability Architecture Classification

可以按主導條件分：

model-dominant；
memory-dominant；
tool-dominant；
world-dominant；
user-coupled；
verifier-dependent。

124. 這將接到 Paper 03

Paper 03 的核心問題將是：

如果一項能力主要來自 runtime、memory、tools 或 world，那它到底算不算 AI 自己的能力？

本文故意不回答。

125. Conditional Capability Envelope

定義：

\mathcal E_c = \{ \boldsymbol\omega: P_c(\boldsymbol\omega) \ge \theta \}.

它表示：

能力 $c$ 可以可靠存在的條件域。

126. Narrow Envelope

若：

|\mathcal E_c|

很小，

能力脆弱。

127. Wide Envelope

若：

|\mathcal E_c|

很大，

能力 robust。

128. Capability Portability

若模型換 runtime 後：

\mathcal E_c

大致保留，

則 capability portability 高。

129. Runtime Portability

如果能力只能在特定：

provider；
tool；
memory；

運作，則 portability 低。

130. Effective Capability Is Relational

本文因此提出：

\boxed{ C_{\mathrm{eff}} \text{ is relational.} }

它存在於：

\text{Model} \leftrightarrow \text{Task} \leftrightarrow \text{User} \leftrightarrow \text{Runtime} \leftrightarrow \text{World}.

131. Relational 不等於虛假

能力受條件影響，不表示能力「不存在」。

就像：

飛機需要空氣動力條件；
程式需要 runtime；
人需要工具與環境。

條件性不取消真實性。

132. Effective Capability Is Not Arbitrary

條件化也不是隨便解釋。

必須：

列條件；
可測；
可重現；
可消融。

133. 實驗一：Same Model, Different User

固定：

model；
task；
tools。

改變 user expertise / specification。

測：

\Delta C_{\mathrm{eff}}.

134. 實驗二：Same Model, Different Context

固定 user、task。

改變：

context length；
relevance；
freshness；
contradiction。

測：

P_c.

135. 實驗三：Same Model, Different Compute

比較：

instant；
medium reasoning；
high reasoning；
multi-sample。

測：

\frac{ \Delta P_c }{ \Delta K }.

136. 實驗四：Tool Ablation

依序移除：

browser；
code runner；
database；
theorem prover。

建立：

\Delta C^{-T_i}.

137. 實驗五：Verifier Ablation

比較：

Generate Only
Generate + Self-Check
Generate + External Verifier
Generate + External Verifier + Repair

138. 實驗六：Memory Ablation

比較：

No Memory
Summary Memory
Structured Memory
Graph Memory
Canonical State + Retrieval

139. 實驗七：State Reset

測：

session reset；
runtime restart；
model swap。

觀察：

C_{\mathrm{eff}}

恢復率。

140. 實驗八：Authority Cut

撤銷：

read；
write；
execute。

測 capability graph 如何收縮。

141. 實驗九：Latency Budget

設定：

T_{\max}

逐步下降。

測：

\mathcal C_{\mathrm{eff}}(T_{\max}).

142. 實驗十：World Perturbation

改變 environment：

API offline；
schema change；
game state change；
sensor noise。

測 robustness。

143. Minimal Effective Capability Record

capability_id:
model:
task_scope:
user_coupling:
context_quality:
memory_state:
tools:
compute_budget:
routing:
validator:
authority:
latency_budget:
world_dependencies:
state_continuity:
observed_success:
transfer_success:
restart_success:
cost:

144. Capability Condition Receipt

每次高價值 execution 可以產生：

condition_receipt:
  capability_id:
  runtime_version:
  model_version:
  state_head:
  tool_versions:
  validator_version:
  authority_scope:
  compute_budget:
  context_digest:
  result:

這有利於 debug。

145. 能力不可重現的常見原因

如果某次成功無法再現，可能是：

context 不同；
model version；
tool version；
random seed；
hidden compute；
memory；
environment。

沒有 receipt 很難知道。

146. Capability Reproducibility

定義：

Rep(c) = P( \text{same relevant conditions} \Rightarrow \text{same capability class outcome} ).

147. 可重現不要求完全相同輸出

語言模型輸出可以不同。

重點是：

\text{Outcome Class}

一致。

148. Effective Capability Contract

產品對外可宣告：

\mathcal K_c = ( \text{Scope}, \text{Conditions}, \text{SLA}, \text{FailureModes} ).

149. Capability SLA

例如：

在 repo < 100k LOC、完整測試可執行、權限為 read/write、15 分鐘 budget 下，完成某類 bug fix。

這比：

AI can code.

精確很多。

150. 高階能力最需要條件化

越複雜任務：

n_{\mathrm{dependencies}}\uparrow.

因此：

\frac{ C_{\mathrm{eff}} }{ C_{\mathrm{nom}} }

可能更敏感。

151. 簡單任務更接近模型能力

例如：

翻譯一句話。

所需條件少。

所以：

C_{\mathrm{eff}} \approx C_{\mathrm{nom}}.

152. 長程 Agent 差距更大

對：

完成一個大型軟體專案。

需要：

persistent state；
tools；
tests；
planning；
authority；
recovery。

所以：

C_{\mathrm{eff}}

高度 runtime-conditioned。

153. 世界模型差距更極端

短片生成可能主要依賴模型。

長期世界則依賴：

persistent state；
causal engine；
memory；
multi-agent；
world controller。

154. AI 原生系統的真正競爭

未來競爭不只：

\Theta_1 \text{ vs } \Theta_2.

而是：

\boxed{ (\Theta,R)_1 \text{ vs } (\Theta,R)_2. }

155. 模型商品化後 Runtime 更重要

若模型差距下降：

\Delta C_{\mathrm{nom}}\downarrow,

則：

\Delta R

對產品差異的重要性可能上升。

156. 但 Runtime 不能救所有弱模型

如果：

C_{\mathrm{nom}}\approx0

對核心任務，

再好的 runtime 也可能無法補。

所以：

\boxed{ \text{Runtime Multiplies Capability} \neq \text{Runtime Creates Anything from Nothing}. }

157. Capability Floor

存在：

C_{\mathrm{floor}}(q).

模型低於此門檻，某些 tool / workflow 無法有效利用。

158. Capability Ceiling

同樣存在：

C_{\mathrm{ceiling}}(R).

若 runtime 太差，再強模型也被壓住。

159. Model–Runtime Matching

最佳系統不是：

\max \Theta

而可能是：

\arg\max_{\Theta,R} \frac{ C_{\mathrm{eff}}(\Theta,R) }{ Cost(\Theta,R) }.

160. CP 值

這接到本系列的重要現實問題：

更長 context、更大模型、更多 agent 是否真的划算？

真正應比較：

\frac{ \Delta C_{\mathrm{eff}} }{ \Delta Cost }.

161. Capability Marginal Return

定義：

MR_i = \frac{ \partial C_{\mathrm{eff}} }{ \partial \text{Cost}_i }.

162. Context 的邊際回報

若：

MR_{\mathrm{context}}\downarrow,

繼續增加 linear context CP 值下降。

這預告 Paper 08。

163. Compute 的邊際回報

推理時計算也可能：

MR_K\downarrow.

所以需要 adaptive allocation。

164. Human Attention 的成本

人類校正也不是免費。

定義：

Cost_H.

如果需要人類一直 babysit：

C_{\mathrm{eff}}

可能高，但 autonomy 低。

165. Human Attention Efficiency

定義：

\eta_H = \frac{ \Delta C_{\mathrm{eff}} }{ Cost_H }.

166. Human–AI Coupling 的成熟目標

不是最大化人類操作量。

而是：

用最少必要人類高價值判斷，換最大有效能力。

167. Agent 的成熟目標

也不是完全無人。

而是：

\boxed{ \text{Right Human at Right Decision Boundary}. }

168. Effective Capability 與自主性

高有效能力不等於高 autonomy。

系統可能：

C_{\mathrm{eff}}\gg0

但完全依賴 human approval。

169. Autonomy Axis

因此 autonomy 是另一軸：

A_{\mathrm{auto}}.

不能和 capability 合併。

170. Capability–Autonomy Plane

可以建立：

low capability / low autonomy；
high capability / low autonomy；
low capability / high autonomy；
high capability / high autonomy。

171. 高自主低能力很危險

如果：

A_{\mathrm{auto}}\uparrow

但：

V\downarrow,

可能產生大量錯誤 action。

172. 高能力低自主也有價值

例如：

expert advisor；
proof assistant；
medical literature search。

173. Capability–Authority Plane

能力和權限也應分離。

高能力：

\neq

高權限。

174. Capability–Trust Plane

Trust 應來自：

\text{Evidence}

而不是 model brand。

175. Trust Calibration

定義：

T_c \approx P_{\mathrm{validated}}(c).

過度信任：

T_c>P_{\mathrm{real}}.

低估：

T_c<P_{\mathrm{real}}.

176. 使用者對 AI 的校準也是條件

如果使用者：

過度信任；
過度不信任；

都會降低：

C_{\mathrm{HA,eff}}.

177. Dual Calibration

需要：

Calib_A

與：

Calib_U.

AI 要估自己，也要估使用者。

178. Calibration Error

若 AI 錯估使用者 expertise：

解釋過淺；
過度依賴 user correction；
過度迎合。

179. 使用者域條件

Expertise 不是全域值。

應寫：

E(u,d,t).

180. 同一使用者在不同領域不同

所以：

E(u,d_1) \not\Rightarrow E(u,d_2).

181. AI 對 user model 也必須局部化

不能因：

user 在 distributed systems 很強

就推出：

user 在稅法也強。

182. Capability Conditioning 的安全含義

高耦合讓能力變強。

也可能讓錯誤更快傳播。

183. Negative Coupling

若 user correction 是錯的：

C_{\mathrm{HA}}

可能負向。

因此：

\boxed{ \text{Coupling} \neq \text{Improvement}. }

184. Positive Coupling

若雙方能：

challenge；
verify；
correct；

則：

C_{\mathrm{HA}}>0.

185. Effective Capability Is Co-Produced

在人機系統中：

C_{\mathrm{eff}}

往往是共同生產。

186. Co-Production 不等於 Joint Identity

即使能力由：

H+A

共同形成，

也不推出：

H=A.

187. Co-Production 不等於平均責任

責任仍取決於：

control；
authority；
foreseeability；
role。

188. Ability vs Result

一個好結果：

y

不必然證明高能力。

可能是：

luck；
memorization；
easy instance。

所以需要 task distribution。

189. Capability Distribution

對能力 $c$ ：

P_c = P( \text{success} \mid q\sim D_c ).

190. Distribution Shift

若：

D_{\mathrm{test}} \neq D_{\mathrm{real}},

benchmark 會失真。

191. Real-World Effective Capability

所以真正部署要測：

D_{\mathrm{real}}.

192. Capability Drift

隨：

model update；
tool update；
world change；

P_c(t)

會漂移。

193. Continuous Evaluation

因此高價值 capability 需要：

\operatorname{Eval}_t.

194. Capability Decay

若外部依賴變動：

P_c(t+\Delta t) < P_c(t).

能力可能衰退。

195. Capability Refresh

重新：

train；
update workflow；
update memory；
update verifier；

可恢復。

196. 能力不是一次取得永久有效

這再次說明：

\boxed{ \text{Capability} \text{ is temporally maintained.} }

197. Paper 02 的核心母公式

本文最終採：

\boxed{ \mathcal C_{\mathrm{eff}}(q,u,t) = F( \mathcal C_{\mathrm{nom}}, \boldsymbol\omega_{q,u,t} ) }

其中：

\boldsymbol\omega_{q,u,t} = ( Q,U,X,M,T,K,R,V,P,L,W,S ).

198. 零階增益—耗散式

為直覺化：

\boxed{ C_{\mathrm{eff}} = C_{\mathrm{nom}} \cdot G_{\mathrm{cond}} - D_{\mathrm{cond}} }

其中：

$G_{\mathrm{cond}}$ ：條件增益；
$D_{\mathrm{cond}}$ ：條件耗散。

199. 更嚴格的集合式

令：

\mathcal C_{\mathrm{avail}}

為可用能力。

則：

\boxed{ \mathcal C_{\mathrm{eff}} = \{ c\in \mathcal C_{\mathrm{avail}} : \operatorname{Feasible}(c,\Omega)=1 \land P_c(\Omega)\ge\theta_c \} }

200. Feasible 條件

至少包括：

\operatorname{Feasible} = Gate_Q \land Gate_T \land Gate_P \land Gate_L \land Gate_W.

201. Quality 條件

再由：

Gain_U, Gain_X, Gain_M, Gain_K, Gain_R, Gain_V, Gain_S

決定成功率與品質。

202. Canonical Invariants

本文固定：

Nominal Capability != Effective Capability.
Same Model != Same Effective Tool.
Capability Is Task-Conditioned.
Capability Is User-Coupling-Conditioned.
More Context != Better Context.
Memory Size != Memory Utility.
Tool Presence != Tool Utility.
More Compute != More Effective Capability.
Routing Is a Meta-Capability.
Having a Verifier != Reliable Verification.
Capability != Authority.
Theoretical Reachability != Deadline Feasibility.
Digital Capability != World Capability.
State Continuity Conditions Long-Horizon Capability.
Model Regression != System Regression.
AI Access != AI Absorption.
Coupling != Improvement.
Expertise Is Domain-Conditioned.
Human–AI Effective Capability Can Be Co-Produced.
Co-Production != Identity Merger.
Benchmark Result != Real-World Effective Capability.
Capability Is Temporally Maintained.
Runtime Can Amplify Capability but Cannot Guarantee Capability from Nothing.
Model Scale != Capability Conversion Efficiency.
Effective Capability Is Relational but Not Arbitrary.

203. 可證偽條件

F1

若在大量真實任務中，使用者、context、memory、tools、compute、verification 等條件對表現只產生極小影響，則本文的強條件化主張被削弱。

F2

若同一模型在固定 benchmark 與真實部署間高度穩定，且 runtime 差異幾乎不影響結果，則 model-centric capability model 已足夠。

F3

若使用者專業、task specification 與 correction quality 對 AI 產出沒有穩定可測影響，則 Human–AI Coupling 係數的重要性下降。

F4

若增加 memory、tools、verifier 等只能改變速度，不能擴大可完成任務域，則 system-level effective capability 應被重新縮窄。

F5

若本文高維條件模型無法比簡單 model-score 模型更好預測實際成功率、成本與 failure mode，則應簡化。

204. 最小工程 MVP

建立一個固定任務集。

對同一模型執行：

A. Model Only
B. + Structured Context
C. + Persistent Memory
D. + Tools
E. + Verifier
F. + High Compute
G. + Expert User Constraints
H. Full Runtime

比較：

success；
cost；
latency；
transfer；
restart；
robustness。

205. 最重要的工程問題

不要只問：

要不要換更強模型？

而應問：

現在真正限制有效能力的是哪一個條件？

206. Capability Optimization

因此：

\boxed{ \operatorname{Improve} = \arg\max_i \frac{ \Delta C_{\mathrm{eff}} }{ \Delta \text{Cost}_i } }

這才是系統工程的合理方向。

207. 與 Paper 01 的關係

Paper 01 問：

一項能力目前在哪個狀態？

Paper 02 問：

即使能力狀態固定，外部條件如何決定它現在能不能有效實現？

所以：

\boxed{ \text{Capability State} + \text{Conditioning} = \text{Effective Capability}. }

208. 與 Paper 03 的關係

Paper 03 將進一步問：

如果有效能力高度依賴 memory、tools、runtime、user、world，哪些算 AI 的內生能力，哪些只是外包或耦合？

所以本文故意只回答：

\text{How capability becomes effective}

不回答：

\text{Who owns capability ontologically}.

209. 與 Paper 05 的關係

快速再耦合準內生化需要先知道：

C_{\mathrm{eff}}

在 restore 前後是否保留。

因此本文的 condition receipt / restart test 將成為 Paper 05 的測量基礎。

210. 與 Paper 08 的關係

Paper 08 將處理：

為什麼 linear context 的 CP 值下降。

本文已提供一個入口：

MR_{\mathrm{context}} = \frac{ \Delta C_{\mathrm{eff}} }{ \Delta Cost_{\mathrm{context}} }.

211. 一句話定義

有效 AI 能力不是模型參數所標示的一個固定能力值，而是名義能力在特定任務、使用者、上下文、記憶、工具、算力、路由、驗證、權限、延遲、世界與狀態連續性條件下，被真正實現出的可用能力。

212. 結論

當 AI 還只是：

\text{Input} \rightarrow \text{Model} \rightarrow \text{Output},

把「模型能力」近似成「AI 能力」尚可接受。

但當系統變成：

\boxed{ \text{User} + \text{Task} + \text{Model} + \text{Context} + \text{Memory} + \text{Tools} + \text{Compute} + \text{Routing} + \text{Verification} + \text{Authority} + \text{World} + \text{Persistent State} }

後，

真正可觀測的是：

\mathcal C_{\mathrm{eff}},

而不是裸：

\mathcal C_{\mathrm{nom}}.

因此：

\boxed{ \text{Same Model} \neq \text{Same Effective Capability}. }

一個模型可以在不同 runtime 裡像不同等級的系統。

同一個 AI 對不同使用者可以是不同生產工具。

同一個 capability 在不同 context、compute、tool、verification 與 authority 條件下，可以從幾乎不可用跨越到高度可靠。

這不是說模型本身不重要。

而是說：

模型只是有效能力生成方程中的一個核心變數，而不是整個方程。

下一篇因此將進入更難的問題：

\boxed{ \text{當能力由模型、memory、tools、runtime 與外部世界共同形成時，到底哪些才算 AI「自己」的能力？} }