title: 理論不只用來判真：從 Capability Extraction 到 Artifact 與 Observed Behavior 的操作化鏈
english_title: Theory Is Not Only for Truth Assessment: From Capability Extraction to Artifacts and Observed Behavior
series: AI 原生研究物迭代與可驗證升版方法論系列
series_en: AI-Native Research Object Revision and Verifiable Evolution Series
paper: 05
author: Neo.K
institution: EveMissLab／一言諾科技有限公司
research_assistance: AI-assisted theoretical development
version: v0.1
date: 2026-09-16
language: zh-TW
status: Canonical UTF-8 Source / Working Paper
research_class: METHODOLOGY / OPERATIONALIZATION / SCHOLARLY INFRASTRUCTURE
claim_state: THEORETICAL FRAMEWORK / CAPABILITY EXTRACTION MODEL
evidence_state: CONCEPTUAL / PRACTICE-DERIVED

理論不只用來判真：從 Capability Extraction 到 Artifact 與 Observed Behavior 的操作化鏈

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

摘要

傳統研究評估容易把核心問題集中在：

這個理論是真的嗎？
它有多少證據？
是否被驗證？
是否被同行接受？

這些問題重要，但不足以完整描述一個研究物的價值。大量理論、方法論、形式系統、工程架構與哲學框架，即使尚未被證明為「世界的最終真相」，也可能已經能生成可重複的演算法、軟體架構、資料格式、Agent 規則、治理機制、設計 invariant、診斷工具、研究方法或產品能力。

本文提出「Capability Extraction」框架，將研究物評估從單一認識論軸擴展為：

\boxed{ \text{Epistemic Validity} \times \text{Operational Utility}. }

並建立：

\boxed{ \text{Theory} \rightarrow \text{Capability} \rightarrow \text{Artifact} \rightarrow \text{Observed Behavior}. }

本文主張：

\boxed{ \text{Truth Confidence} \neq \text{Operational Utility}, }

以及：

\boxed{ \text{Academic Legitimacy} \neq \text{Engineering Usefulness}. }

一個研究物可以在經驗確定性仍低的情況下具有高架構價值；也可能在事實上高度可靠，卻沒有直接操作效用。未來研究物升版因此不應只補引用與數據，還需要建立 Operational Role、Implemented As、Known Use Cases、Derived Products、Observed Behavior、Failure Domains 與 Unimplemented Capabilities 等欄位。

本文最後提出一套 Capability Graph 與 Theory-to-Artifact Trace，使研究平台能回答另一個過去經常被忽略的問題：

\boxed{ \text{What transformation does this theory enable?} }

關鍵詞： Capability Extraction、Operational Utility、Artifact、Observed Behavior、Theory-to-Artifact、研究操作化、AI 原生學術、研究物治理

0. 問題起點：如果一個理論還不是「世界真理」，它能不能先有用？

研究評估常被壓成：

\text{True} \quad\text{or}\quad \text{False}.

但實際研究世界遠比這個二分更複雜。

一個架構命題可能尚未被證明為宇宙的一般規律，卻能穩定改善軟體系統。

一個認識論框架可能沒有「物理實驗」，卻能直接生成：

審查規則；
決策流程；
資料 schema；
Agent guardrail；
研究治理機制。

一個形式表示法可能沒有證明它是「最佳語言」，卻可以：

降低 token；
減少結構錯誤；
提高 deterministic parsing；
改善跨語言轉譯。

因此本文的第一個命題是：

\boxed{ \text{A theory can be operationally useful before being ontologically final.} }

1. Truth Confidence 與 Utility 必須分離

令：

E_V(P) = \text{Epistemic Validity of research object }P,

以及：

O_U(P) = \text{Operational Utility of research object }P.

則：

\boxed{ E_V(P) \neq O_U(P). }

一個理論可能：

E_V\approx0.4, \qquad O_U\approx0.9.

也可能：

E_V\approx0.95, \qquad O_U\approx0.1.

這裡的數字只作概念示意，不主張建立普遍單一分數。

核心只是：

\boxed{ \text{Knowing whether something is true} \neq \text{Knowing what it can do}. }

2. Academic Legitimacy 也不是 Utility 的代理

研究物可能具有：

peer review；
high citation count；
famous venue；
institutional recognition；

卻未必能產生任何直接可操作結構。

反過來，一個剛提出、尚未廣泛引用的框架，可能已經能：

編譯成演算法；
限制 runtime 行為；
生成資料結構；
修復流程；
提供安全不變量。

因此：

\boxed{ \text{Academic Legitimacy} \neq \text{Operational Utility}. }

這與前一篇提出的 Authority Substitution 問題直接相連。

3. Capability Extraction

本文定義：

\boxed{ \mathcal X(P) = \text{Capability Extraction from research object }P. }

它回答：

如果不先問這個理論是不是「最終真理」，而先把它當成一個可操作結構，它能讓什麼變得可能？

Capability 可以包括：

DESCRIPTIVE
EXPLANATORY
GENERATIVE
PREDICTIVE
PRESCRIPTIVE
ARCHITECTURAL
ALGORITHMIC
GOVERNANCE
REPRESENTATIONAL
DIAGNOSTIC
HEURISTIC
TRANSLATIONAL
VALIDATIONAL
COORDINATIVE

這些不是互斥類別。

同一理論可能具有多個 Operational Role。

4. Operational Role

本文定義：

\boxed{ R_O(P) = \{r_1,r_2,\ldots,r_k\}. }

例如：

operational_role:
  - architectural
  - governance
  - representational

它表示：

這個研究物目前已知可以被用來做什麼類型的轉換？

Operational Role 不等於 paper type。

一篇 THEORY 可以具有：

ARCHITECTURAL

角色。

一篇 METHODOLOGY 可以具有：

ALGORITHMIC

角色。

因此：

\boxed{ \text{Research Class} \neq \text{Operational Role}. }

5. 從 Theory 到 Capability

本文提出第一條操作鏈：

\boxed{ P \xrightarrow{\mathcal X} K, }

其中：

K = \text{Extracted Capability}.

例如，一個理論提出：

\text{Observer} \neq \text{Controller}.

在哲學層，它可能是認識與權限的區分。

但 Capability Extraction 可以得到：

K_1= \text{Separate observation permission from action permission}.

進一步：

K_1

可以轉成 Agent runtime invariant。

因此：

\boxed{ \text{Conceptual Distinction} \rightarrow \text{System Constraint}. }

6. Capability 不等於 Artifact

能力被抽取出來後，還不代表已經實作。

所以：

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

一個理論可能明確指出：

系統應將 Observe、Validate、Authorize、Act 分離。

這代表：

K

已存在。

但如果尚未有：

code；
schema；
runtime；
protocol；
benchmark；

則：

A=0.

因此研究物需要同時記：

capability:
  state: identified

implementation:
  state: not_implemented

7. Artifact Layer

本文定義：

\boxed{ A_k = \text{Artifact implementing capability }K. }

Artifact 可以是：

CODE
PROTOCOL
SCHEMA
RUNTIME
COMPILER
DATASET
BENCHMARK
CERTIFICATE
MODEL
SIMULATOR
UI
WORKFLOW
AGENT
API
PRODUCT

因此：

\boxed{ K \rightarrow A_k }

是操作化的重要一步。

8. Artifact 存在仍然不代表 Capability 成立

這裡必須避免另一個跳躍：

\text{Artifact Exists} \rightarrow \text{Capability Works}.

不能直接成立。

所以：

\boxed{ \text{Implementation} \neq \text{Observed Capability}. }

一個 repo 存在，只表示有人寫了實作。

它是否真的產生預期能力，仍然需要觀察。

9. Observed Behavior

本文定義：

\boxed{ B(A_k,C) = \text{Observed Behavior of artifact }A_k\text{ under condition }C. }

完整操作鏈因此成為：

\boxed{ \text{Theory} \rightarrow \text{Capability} \rightarrow \text{Artifact} \rightarrow \text{Observed Behavior}. }

Observed Behavior 可以包括：

正確輸出；
錯誤率下降；
latency 改變；
token 使用下降；
failure mode 改變；
安全邊界改善；
deterministic behavior；
retrieval quality 改善；
human task completion 改善。

10. Observed Behavior 不等於 Theory Truth

即使 artifact 表現很好，也不能直接推出：

T(P)=1.

因為一個理論可能：

作為近似模型有效；
作為設計 heuristic 有效；
在特定 domain 有效；
在工程上可用；

但仍不是世界的完整描述。

所以：

\boxed{ \text{Artifact Success} \neq \text{Ontological Truth}. }

這個區分非常重要。

11. 反向鏈也成立

操作化不只是一條向前鏈。

Observed Behavior 也能反過來改變 Theory。

即：

\boxed{ P \rightarrow K \rightarrow A \rightarrow B \rightarrow P'. }

其中：

P'

可能是：

修正版；
縮域版；
強化版；
分叉版；
被反例修正的版本。

這形成：

\boxed{ \text{Operational Feedback Loop}. }

12. Capability Evidence

Capability 本身也需要 evidence。

例如 claim：

這套方法能降低 Agent 修復次數。

那麼 operational evidence 應該是：

\text{Repair Count}_{new} < \text{Repair Count}_{baseline}.

而不是只提供：

架構圖；
理論描述；
引用。

因此：

\boxed{ \text{Capability Claim} \rightarrow \text{Capability-Specific Evidence}. }

這把第 03、04 篇的 Evidence–Claim Matching 延伸到操作化層。

13. Capability State

本文建議每個 Capability 都有狀態：

CONCEPTUAL
SPECIFIED
PROTOTYPED
IMPLEMENTED
TESTED
REPRODUCED
DEPLOYED
DEPRECATED
FAILED

因此：

capability:
  id: K3
  role: architectural
  state: tested

比只寫：

useful: true

更有意義。

14. Implemented As

研究物應明確記錄：

implemented_as:
  - type: repo
    ref: ...
  - type: protocol
    ref: ...
  - type: runtime
    ref: ...

這使：

\text{Paper} \leftrightarrow \text{Artifact}

可以被機器解析。

否則網站與 repo 會長期分裂。

15. Derived Products

有些理論會直接導出產品。

因此可以建立：

derived_products:
  - name: ...
    capability_source:
      - K1
      - K4

這不代表論文等於產品。

而是：

\boxed{ \text{Research Object} \rightarrow \text{Product Lineage}. }

這對未來研究商業化與技術轉移非常重要。

16. Known Use Cases

Capability 不應只寫成抽象標籤。

還應記：

known_use_cases:
  - ...
  - ...

Use Case 回答：

在什麼情境下，這個理論已知能被實際使用？

因此：

\boxed{ \text{Capability} \neq \text{Use Case}. }

Capability 是一般能力。

Use Case 是能力在特定情境中的投影。

17. Failure Domain

只保存成功案例會產生操作化偏誤。

所以應明確記：

\boxed{ F_D(K) = \text{Failure Domain of capability }K. }

例如：

failure_domains:
  - very_large_context
  - non_deterministic_external_api
  - incomplete_metadata

這與 Evidence Graph 中保存 counterevidence 的原則一致。

18. Unimplemented Capability

有些理論已經明確推出某種能力，但尚未實作。

這不應被丟失。

因此：

unimplemented_capabilities:
  - id: K9
    description: ...
    blocker: ...

這能使研究平台直接生成：

future work；
engineering tasks；
prototype backlog。

所以：

\boxed{ \text{Theory Corpus} \rightarrow \text{Capability Backlog}. }

19. Operational Utility 不應被壓成單一分數

本文反對：

O_U(P)=87/100

作為唯一輸出。

更合理的是：

\boxed{ \mathbf U(P) = ( u_a, u_g, u_r, u_d, u_p, u_t ), }

其中例如：

$u_a$ ：architectural utility；
$u_g$ ：governance utility；
$u_r$ ：representational utility；
$u_d$ ：diagnostic utility；
$u_p$ ：product utility；
$u_t$ ：transferability。

不同研究物可以具有不同 profile。

20. Epistemic Validity × Operational Utility

本文正式建立雙軸：

\boxed{ \mathcal R(P) = ( E_V(P), \mathbf U(P) ). }

這表示研究物不能只被問：

它有多真？

也不能只問：

它有多有用？

而應同時保留兩者。

例如：

類型 A

E_V\text{ high}, \quad U\text{ high}.

既有強證據，也有強操作價值。

類型 B

E_V\text{ high}, \quad U\text{ low}.

高度可靠但目前用途有限。

類型 C

E_V\text{ low/medium}, \quad U\text{ high}.

尚未作為世界真理被充分證成，但作為架構或 heuristic 非常有效。

類型 D

E_V\text{ low}, \quad U\text{ low}.

目前仍主要是探索性思想。

這四種都可能具有研究價值。

21. 類型 C 為什麼不能被低估？

很多新架構會先出現在類型 C。

例如：

尚未證明是認知真理的 Agent 分層模型；
尚未證明是最佳表示法的 IR；
尚未證明是普遍法則的研究工作流；
尚未有大規模外部驗證的治理規則。

如果它們已經：

降低錯誤；
提高可重現性；
改善架構；
產生可執行工具；

就具有高 Operational Utility。

因此：

\boxed{ \text{Low Ontological Certainty} \not\Rightarrow \text{Low Engineering Value}. }

22. 形式系統的典型操作化

假設某研究提出一個表示協議：

L.

它不必先證明：

$L$ 是宇宙中最優語言。

更實際的 Capability Claim 可以是：

\text{ParseError}(L) < \text{ParseError}(Baseline).

或：

\text{RoundTrip}(L)=1.

或：

\text{TokenCost}(L) < \text{TokenCost}(Baseline).

這些都是可以測的 operational claims。

23. 哲學理論也可以操作化

一個哲學命題：

\text{Observe} \neq \text{Authorize}

可以生成：

Observation Layer
↓
Proposal Layer
↓
Validation Layer
↓
Authority Gate
↓
Execution Layer

這時哲學區分轉成：

\boxed{ \text{Architectural Invariant}. }

因此哲學研究不必靠偽造 empirical dataset 才顯得「有用」。

它可以透過：

\text{Concept} \rightarrow \text{Constraint} \rightarrow \text{System Behavior}

獲得操作性。

24. 方法論也可以操作化

研究方法本身可以產生：

workflow；
evaluator；
benchmark；
validator；
repair protocol；
task router。

因此方法論研究的 Operational Role 常是：

\boxed{ \text{Method} \rightarrow \text{Procedure}. }

這使它能被測試：

\text{TaskOutcome}_{method} \quad\text{vs}\quad \text{TaskOutcome}_{baseline}.

25. Capability Extraction Protocol

本文提出最小流程。

Step 1 — 找核心區分

這篇理論真正建立了什麼：

定義；
不等式；
類型；
算子；
invariant；
transformation？

Step 2 — 問轉換能力

\boxed{ \text{What transformation does this enable?} }

Step 3 — 建 Capability

把理論命題轉成可操作能力。

Step 4 — 尋找 Artifact

是否已有：

code；
protocol；
schema；
runtime；
product？

Step 5 — 找 Observed Behavior

是否真的有行為結果？

Step 6 — 找 Failure Domain

在哪裡失敗？

Step 7 — 回寫研究物

建立：

P\leftrightarrow K\leftrightarrow A\leftrightarrow B.

26. Capability Graph

可以表示：

capabilities:
  - id: K1
    role: architectural
    derived_from_claims:
      - C3
      - C7
    state: tested

artifacts:
  - id: A4
    type: runtime
    implements:
      - K1

observations:
  - id: B2
    artifact: A4
    condition: ...
    result: ...

圖上形成：

C_3,C_7 \rightarrow K_1 \rightarrow A_4 \rightarrow B_2.

27. Theory-to-Artifact Trace

本文定義：

\boxed{ \tau_{TA} = \text{Theory-to-Artifact Trace}. }

它回答：

這個 artifact 到底來自哪個理論命題？

這對大型研究庫很重要。

因為未來可能有：

幾千篇研究物；
幾百個 repo；
幾十個 runtime；
多個產品。

如果沒有 trace，產品與理論會脫節。

28. Artifact-to-Theory Trace

反向也需要：

\boxed{ \tau_{AT} = \text{Artifact-to-Theory Trace}. }

它回答：

這個 repo 或產品正在實作哪些理論？

如此一來，程式改動可以觸發：

\text{Research Reassessment}.

而研究升版也可以觸發：

\text{Implementation Review}.

29. Observed Behavior 也需要 Scope

若 artifact 在：

C_0

條件下成功，不應推出：

\forall C.

因此：

\boxed{ B(A,C_0) \neq B(A,\forall C). }

Observed Behavior 仍然必須遵守第 04 篇的 Scope Binding。

30. Operational Claim 也可能被反駁

例如原 claim：

這個方法能降低錯誤率。

若新實驗發現：

\text{Error}_{new} > \text{Error}_{baseline},

則 capability claim 必須：

降級；
縮域；
重新設計；
或標為 failed。

因此：

\boxed{ \text{Operational Utility} \text{ is revisable}. }

它不是宣傳欄位。

31. Derived Product 不等於 Validation

一個理論做成產品，不代表它的世界觀正確。

因此：

\boxed{ \text{Commercialization} \neq \text{Validation}. }

同樣：

\boxed{ \text{User Adoption} \neq \text{Truth}. }

產品成功只能支持特定 operational claims。

32. 市場也不是唯一 Utility

Operational Utility 不等於：

\text{Revenue}.

研究物可能對：

研究效率；
認知清晰；
安全；
可重現性；
教育；
知識保存；
Agent coordination；

具有價值，即使沒有直接商業收入。

因此：

\boxed{ \text{Operational Utility} \neq \text{Commercial Utility Only}. }

33. 升版時新增 Capability Section

本文建議未來研究物升版至少加入：

operational:
  roles:
    - architectural
    - governance

  capabilities:
    - id: K1
      state: tested
      derived_from:
        - C3

  implemented_as:
    - artifact: A1
      type: runtime

  known_use_cases:
    - ...

  observed_behavior:
    - ...

  failure_domains:
    - ...

  unimplemented_capabilities:
    - ...

這使「這篇能幹嘛」成為一級 metadata。

34. Capability 不應被誇大

Capability Extraction 不是把所有哲學命題都硬說成產品。

因此需要：

\boxed{ \text{Capability Inflation Guard}. }

如果一個理論只能：

提供思考角度，

就應標：

HEURISTIC

而不是：

ARCHITECTURAL

如果尚未實作，就不能寫：

DEPLOYED

因此 Operational Utility 與 Epistemic Validity 一樣需要校準。

35. Capability Debt

若理論已明確提出可操作能力，但尚未被測試，可記：

\boxed{ D_K = \text{Capability Debt}. }

例如：

capability_debt:
  - capability: K4
    missing:
      - prototype
      - benchmark

這使 future work 不再只是泛泛而談。

36. Artifact Debt

若已經有產品或程式，但沒有回鏈到理論：

\boxed{ D_A = \text{Artifact Linkage Debt}. }

這正是第 01 篇 Hidden Integration Debt 的一部分。

37. Operational Evidence 與 Academic Evidence 可以不同

某些工程能力最重要的 evidence 可能是：

test log；
trace；
benchmark；
failure distribution；
conformance report。

這些不一定是傳統期刊引用。

因此：

\boxed{ \text{Evidence Form} \text{ should follow } \text{Operational Claim Type}. }

這與前文「Evidence must match the claim's operation」完全一致。

38. 理論改版的兩條軸

因此未來升版至少有兩條獨立問題：

Axis A — Epistemic Upgrade

補證據；
補形式化；
補反例；
修 scope；
修 inference。

Axis B — Operational Upgrade

抽 capability；
建 artifact；
補 benchmark；
加 use case；
加 failure domain；
回鏈產品。

因此：

\boxed{ \text{Revision} = \text{Epistemic Upgrade} + \text{Operational Upgrade}. }

兩者不必每次同時發生。

39. 不是每篇都要產品化

本文特別聲明：

\boxed{ \text{Operationalization} \neq \text{Mandatory Productization}. }

有些研究的 Operational Role 就是：

EXPLANATORY

或：

HEURISTIC

這已經足夠。

Capability Extraction 的目的不是商業化所有知識。

而是不要因為某研究不是 empirical product paper，就看不見它能生成的結構。

40. 與前四篇的接口

第 01 篇：

\text{Generation} + \text{Stewardship} + \text{Global Closure}.

第 02 篇：

\text{Identity} \neq \text{Version} \neq \text{Edition} \neq \text{Lineage}.

第 03 篇：

\text{Claim} \neq \text{Evidence} \neq \text{Validation} \neq \text{Truth}.

第 04 篇：

\text{Presence} \neq \text{Relevance} \neq \text{Support} \neq \text{Sufficiency}.

本文新增：

\boxed{ \text{Theory} \rightarrow \text{Capability} \rightarrow \text{Artifact} \rightarrow \text{Observed Behavior}. }

並建立：

\boxed{ \text{Epistemic Validity} \times \text{Operational Utility}. }

41. 下一步：時間與來源

當研究物可以同時表示：

身份；
版本；
claim；
evidence；
capability；
artifact；

下一個問題就是：

這些東西何時形成？

以及：

我們現在對它的理解到底來自哪一條觀察與推論路徑？

因此下一篇將處理：

\boxed{ \text{Temporal Provenance} }

與：

\boxed{ \text{Publication Time} \neq \text{Creation Time}. }

再下一篇則處理 Epistemic Provenance。

結論

一個研究物不應只被問：

它是不是真的？

還應被問：

\boxed{ \text{What transformation does this theory enable?} }

這不是放棄真理。

而是承認研究價值至少具有兩個彼此不可化約的維度：

\boxed{ \text{Epistemic Validity} \times \text{Operational Utility}. }

因此：

\boxed{ \text{Truth Confidence} \neq \text{Operational Utility}. }

\boxed{ \text{Academic Legitimacy} \neq \text{Engineering Usefulness}. }

\boxed{ \text{Artifact Success} \neq \text{Ontological Truth}. }

完整的 AI 原生研究物不只需要保存：

它聲稱什麼；
它有什麼證據；

還應保存：

它能生成什麼能力；
哪些能力已被實作；
實作後觀察到什麼；
在哪裡失敗；
還有哪些能力尚未完成。

因此：

\boxed{ \text{Theory} \rightarrow \text{Capability} \rightarrow \text{Artifact} \rightarrow \text{Observed Behavior} \rightarrow \text{Theory Revision}. }

這條循環使理論不再只是靜態文本。

它開始成為可以被實作、觀察、修正與持續演化的研究物。