--- 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 可以包括： ```text 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\}. } $$ 例如： ```yaml operational_role: - architectural - governance - representational ``` 它表示： > 這個研究物目前已知可以被用來做什麼類型的轉換？ Operational Role 不等於 paper type。 一篇 `THEORY` 可以具有： ```text ARCHITECTURAL ``` 角色。 一篇 `METHODOLOGY` 可以具有： ```text 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. $$ 因此研究物需要同時記： ```yaml capability: state: identified implementation: state: not_implemented ``` --- # 7. Artifact Layer 本文定義： $$ \boxed{ A_k = \text{Artifact implementing capability }K. } $$ Artifact 可以是： ```text 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 都有狀態： ```text CONCEPTUAL SPECIFIED PROTOTYPED IMPLEMENTED TESTED REPRODUCED DEPLOYED DEPRECATED FAILED ``` 因此： ```yaml capability: id: K3 role: architectural state: tested ``` 比只寫： ```yaml useful: true ``` 更有意義。 --- # 14. Implemented As 研究物應明確記錄： ```yaml implemented_as: - type: repo ref: ... - type: protocol ref: ... - type: runtime ref: ... ``` 這使： $$ \text{Paper} \leftrightarrow \text{Artifact} $$ 可以被機器解析。 否則網站與 repo 會長期分裂。 --- # 15. Derived Products 有些理論會直接導出產品。 因此可以建立： ```yaml derived_products: - name: ... capability_source: - K1 - K4 ``` 這不代表論文等於產品。 而是： $$ \boxed{ \text{Research Object} \rightarrow \text{Product Lineage}. } $$ 這對未來研究商業化與技術轉移非常重要。 --- # 16. Known Use Cases Capability 不應只寫成抽象標籤。 還應記： ```yaml 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. } $$ 例如： ```yaml failure_domains: - very_large_context - non_deterministic_external_api - incomplete_metadata ``` 這與 Evidence Graph 中保存 counterevidence 的原則一致。 --- # 18. Unimplemented Capability 有些理論已經明確推出某種能力，但尚未實作。 這不應被丟失。 因此： ```yaml 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} $$ 可以生成： ```text 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 可以表示： ```yaml 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 本文建議未來研究物升版至少加入： ```yaml 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}. } $$ 如果一個理論只能： > 提供思考角度， 就應標： ```text HEURISTIC ``` 而不是： ```text ARCHITECTURAL ``` 如果尚未實作，就不能寫： ```text DEPLOYED ``` 因此 Operational Utility 與 Epistemic Validity 一樣需要校準。 --- # 35. Capability Debt 若理論已明確提出可操作能力，但尚未被測試，可記： $$ \boxed{ D_K = \text{Capability Debt}. } $$ 例如： ```yaml 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 就是： ```text EXPLANATORY ``` 或： ```text 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}. } $$ 這條循環使理論不再只是靜態文本。 它開始成為可以被實作、觀察、修正與持續演化的研究物。