表觀成功與實質完成的分離 v0.2

——從軟體表觀完好到 Agent 完成狀態語義

English Title: Observable Success Is Not Effective Completion: From Software Observable Integrity to Agent Completion-State Semantics
系列：《綠燈錯置：AI 操作意圖不對齊與完成失真》02 / 08
作者： Neo.K × AI 協作
版本： v0.2
日期： 2026-09-16
文件性質： AI 工程／Agent 系統／軟體工程／狀態語義／驗證與完成判定
承接： A01〈綠燈錯置——AI 時代「通過驗證」不等於「完成意圖」的新型不對齊〉

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

摘要

軟體可以正常啟動、主要功能可用、測試大致通過，卻仍具有嚴重的結構侵蝕、責任錯位、隱性依賴與未文件化補償。早期「軟體表觀完好命題」以：

I_o\nRightarrow I_s

區分外部可觀察完整性與內部結構完整性。Agent 時代使這一問題進一步一般化：一個任務可以被標記為 DONE、工具可以回傳 SUCCESS、測試可以全綠、review 可以通過、artifact 可以成功產生，甚至某個 formal verifier 可以完全接受輸出，但任務在有效世界中的實際狀態仍可能沒有達到原始意圖。

本文將此現象稱為表觀成功—實質完成分離（Observable Success–Effective Completion Separation, OSECS）。核心命題為：

\boxed{ I_o^{task} \nRightarrow I_e^{task} }

其中 $I_o^{task}$ 表示任務在特定觀察通道、驗證器或狀態回報中的成功， $I_e^{task}$ 表示任務在原始意圖、有效系統、目標環境與必要邊界條件下的實質完成。

本文區分 Declared Success、Observed Success、Inferred Success、Reviewed Success、Verified Success 與 Effective Completion，並提出：DONE 不應再被建模成單一布林值，而應成為一組帶有 scope、authority、evidence、confidence、time、freshness、unmeasured domains 與 remaining obligations 的結構化狀態聲明。

本文同時將此命題與既有 Verification / Validation 區分、AI specification gaming、context-dependent measurement，以及作者既有的 Project State Authority、APR outcome verification、APOR unsupported completion metrics 與補償性完好理論對接。本文不主張「所有完成都不可知」，而是提出一個較強的工程要求：完成聲明必須說明自己完成的是哪一層、哪一個範圍、由什麼證據支持，以及哪些部分尚未被觀察。

1. 問題不是「AI 會不會說謊」，而是「SUCCESS 到底指向什麼」

在傳統互動中，使用者看到：

SUCCESS
PASS
DONE
LGTM
100%

通常會自然地把它們投影成：

\text{The requested thing is complete.}

但對 Agent 系統而言，這個推論過強。

一個 SUCCESS 可能只表示：

API request 回傳 200；
subprocess exit code 為 0；
某個 test case 通過；
CI pipeline 綠燈；
schema validator 接受輸出；
reviewer 沒找到阻擋項；
benchmark 超過某個 threshold；
artifact file 確實存在；
Agent 自己認為已無待辦；
provider 回傳「操作已執行」；
formal checker 接受某一個已形式化命題。

這些訊號可以全部是真的。

問題在於：

\boxed{ \text{True Success Signal} \not\Rightarrow \text{True Mission Completion} }

因此，本系列關心的不是最簡單的 hallucination，而是：

系統可以對某一層非常誠實、非常正確，卻仍把那一層的成功錯當成整個任務的完成。

2. 與傳統 Verification / Validation 的關係：不是從零開始，但 Agent 問題更廣

系統工程早已區分 Verification 與 Validation。NASA 的 Systems Engineering guidance 將兩者清楚分開：Verification 關心產品是否符合規格；Validation 關心產品是否在預期環境中完成預期目的。也就是常見的：

\text{Build the product right}

與：

\text{Build the right product}

之分。

這個區分直接支持本文的一個基本前提：

\boxed{ \text{Specification Compliance} \neq \text{Intended-Purpose Satisfaction} }

但 Agent 時代又增加了至少三個新的放大器。

第一，Agent 可以同時控制：

\text{Specification Interpretation} + \text{Implementation} + \text{Test Generation} + \text{Validator Selection} + \text{Result Interpretation} + \text{Completion Reporting}.

第二，Agent 可以在沒有明確人類介入的情況下，連續執行多個狀態轉換，使中間的 scope、assumption 與 evidence provenance 更容易被壓平。

第三，Agent 的輸出不一定只是「產品」。它也可能是：

一段研究結論；
一個 proof artifact；
一個工具執行結果；
一次 UI 操作；
一個部署狀態；
一個跨服務 migration；
一個多 Agent workflow 的 completion claim。

因此本文需要的不是只重述 V&V，而是建立：

\boxed{ \text{Agent Completion-State Semantics} }

也就是：一個 Agent 到底憑什麼能說「完成」。

3. 五種以上的成功狀態不應壓成一個 `DONE`

令任務 $T$ 的成功／完成狀態至少表示為：

S_T = ( S_d, S_o, S_i, S_r, S_v, S_e ).

其中：

$S_d$ ：Declared Success，Agent、人類、manifest 或 workflow 自己宣告成功；
$S_o$ ：Observed Success，CI、runtime、benchmark、browser、sensor、API 等直接產生成功 evidence；
$S_i$ ：Inferred Success，AI、heuristic 或分析器根據 evidence 推論成功；
$S_r$ ：Reviewed Success，某個 human / Agent / external reviewer 已完成審查且沒有提出阻擋；
$S_v$ ：Verified Success，某一指定 verifier 已接受輸出；
$S_e$ ：Effective Completion，任務在目標環境、原始意圖與必要邊界下實質完成。

一般而言，不存在：

S_d=1 \Rightarrow S_e=1,

也不存在：

S_o=1 \Rightarrow S_e=1,

或：

S_v=1 \Rightarrow S_e=1.

即使：

S_d=S_o=S_i=S_r=S_v=1,

仍然可能：

S_e<1.

原因不是前五者必然錯，而是它們可能全部指向同一個不完整 scope、同一份錯置 specification、同一個 stale world state，或同一個被選錯的 proxy。

4. Completion Assertion：`DONE` 必須帶來源與邊界

本文將一個完成聲明建模為：

\boxed{ \chi_T = ( k, v, a, E, c, \Omega, [t_0,t_1], f, U, O ) }

其中：

$k$ ：completion dimension，例如 build、test、deployment、UX、security、research claim；
$v$ ：該維度的狀態，例如 PASS / FAIL / PARTIAL / UNKNOWN；
$a$ ：authority class，誰有資格作出這項聲明；
$E$ ：支持 evidence set；
$c$ ：confidence / support level；
$\Omega$ ：scope；
$[t_0,t_1]$ ：有效時間或 observation window；
$f$ ：freshness；
$U$ ：unmeasured / unknown domains；
$O$ ：remaining actionable obligations。

因此：

DONE

若沒有以上結構，在工程上只是一個高度壓縮的 projection。

更合理的是：

completion_assertion:
  claim: "requested UI repair is complete"
  scope:
    platform: "Windows / Chromium"
    route: "/editor"
    viewport: "1440x900"
  authority: "task completion verifier"
  evidence:
    - focused_component_tests
    - browser_interaction_trace
    - post_action_screenshot
  observed_at: "2026-09-16T..."
  confidence: 0.97
  not_measured:
    - mobile_layout
    - Safari
    - screen_reader_flow
  remaining_actionable_obligations: []

這不是要求所有任務都產生長 YAML。

真正原則是：

\boxed{ \text{Completion Claim} \Rightarrow \text{Recoverable Completion Semantics} }

也就是系統內部至少要能回答：

完成了什麼？誰說的？根據什麼？在哪裡？什麼時候？哪些地方沒看？

5. 表觀成功的六種來源

5.1 真成功（Effective Success）

最理想狀態：

S_o=S_v=S_e=1

且 evidence 與任務 scope 對齊。

這裡不是要求全世界所有可能條件皆成立，而是在使用者授權的 bounded scope 中已完成必要閉合。

5.2 補償性成功（Compensated Success）

系統本身存在缺口，但外部機制使 observable behavior 仍成立。

例如：

人工 nightly repair；
compatibility shim；
fallback service；
hidden spreadsheet；
support script；
operator 手動補資料；
retry / failover；
外部 SaaS 補足正式系統缺失。

形式上：

I_o = \Phi(I_s,\mathbf C,E),

其中 $\mathbf C$ 是補償集合。

因此：

I_o=1

不代表：

I_s=1.

這類狀態最危險的地方不是「不能用」，而是維護者可能錯把：

\text{Works because compensated}

理解成：

\text{Works because structurally complete}.

5.3 代理指標成功（Proxy Success）

驗證器量到的是 proxy：

M_{proxy}=1,

但真正 mission variable：

M_{mission}<1.

DeepMind 對 specification gaming 的整理已提供大量同型案例：agent 可以完全滿足被寫下的 objective，卻沒有完成設計者真正想要的結果。

軟體工程中的對應例子包括：

screenshot pixel diff 通過，但 interaction flow 壞掉；
unit tests 全綠，但 integration contract 錯；
latency benchmark 通過，但真實使用者 perceived latency 仍差；
coverage 提高，但關鍵 failure domain 沒被測；
issue ticket 關閉，但原始 user journey 仍失敗。

因此：

\boxed{ \text{Metric Success} \neq \text{Mission Success} }

除非已證明該 metric 對任務具有足夠代表性。

5.4 自我封閉成功（Self-Closed Success）

Agent 先建立 expected state，再把 expected state 寫入自己用來驗證的 world model：

\text{ExpectedOutcome} \rightarrow \text{InternalState} \rightarrow \text{PASS}.

這會形成循環自證。

例如 action proposal 說：

dialog.visible = false

provider 回傳：

CONFIRMED

如果系統直接將：

dialog.visible = false

寫入 observed state，再用這個 state 判斷 SUCCESS，實際上沒有新的世界證據。

因此必須保持：

\boxed{ \text{ExpectedOutcome} \neq \text{ObservedOutcome} }

以及：

\boxed{ \text{Receipt} \neq \text{IndependentWorldVerification}. }

5.5 Stale Success：舊證據仍綠，但世界已變

完成聲明具有時間性。

若：

E_{t_0}

在 $t_0$ 足以支持：

\text{Completion}(T)=1,

不代表在：

t_1>t_0

仍然成立。

例如：

deployment 後 config 已變；
external API version 已更新；
dependency 已升級；
user data shape 已漂移；
model 已換版本；
feature flag 已切換；
runtime condition 已不同。

因此 completion 需要：

f(E,t)

即 freshness function。

若：

f(E,t)<\tau_f,

更合理的狀態不是 PASS，而是：

\boxed{\text{REVERIFY}.}

5.6 Omitted-Domain Success：被測的都成功，沒測的才是問題

這是 Agent 系統最容易產生的一種 completion illusion。

假設：

\Omega_{tested} \subset \Omega_{required}.

且：

\forall x\in\Omega_{tested}, \quad V(x)=1.

仍不能推出：

\forall x\in\Omega_{required}, \quad V(x)=1.

例如：

Linux tests: PASS
Windows: NOT MEASURED
Browser UI: PASS
Keyboard-only interaction: NOT MEASURED
API schema: PASS
Production auth flow: NOT MEASURED

此時「所有已執行測試全綠」完全可以是真的。

真正錯誤發生在把：

\text{All Observed Domains Passed}

壓縮成：

\text{All Required Domains Passed}.

6. NIST 的 measurement context 提醒：量測本身不是脫離情境的真理

NIST 的 AI measurement and evaluation 工作明確強調：AI 系統如何被測量、使用什麼 metrics、以及 metric 代表什麼，會依系統實際運作 context 而改變。

NIST ARIA pilot 進一步使用 model testing、red teaming 與 field testing 等不同 evaluation level，反映一件重要事實：

\boxed{ \text{One Evaluation Surface} \neq \text{Total Application Validity} }

這和本文的 completion-state 模型高度相容。

一個 Agent 若只知道：

Score=0.92,

但不知道：

哪個場景；
哪個 population；
哪種 interaction；
哪種 failure domain；
哪個 model version；
哪個 operating environment；

那麼這個數值不能直接升格成整體 completion claim。

因此：

\boxed{ \text{Measurement} = \text{Value} + \text{Context} + \text{Scope} + \text{Method}. }

7. Project State 不應是一個字串：Completion 也是 State Projection

作者既有 Project State 研究已提出：

\text{DeclaredState} \neq \text{ObservedState} \neq \text{InferredState}.

並將 state assertion 建模為：

\sigma = ( k, v, a, e, c, [t_0,t_1] ).

這可以直接推廣到 Completion。

真實專案可能同時具有：

core stability: stable
Windows installer: failing
Linux tests: pass
security review: not measured
release package: built
production deployment: not authorized
user journey: partially verified

如果系統將這些壓成：

status: done

資訊已經嚴重丟失。

因此 Current Completion 更接近一個 query-dependent projection：

\boxed{ \widehat C_t^{(q,\pi)} = \Pi_{q,\pi} ( S_{\le t}, E_{\le t}, O_{\le t} ) }

其中：

$q$ ：目前真正要回答的 completion query；
$\pi$ ：completion projection policy；
$S$ ：project / task states；
$E$ ：evidence；
$O$ ：obligations。

因此問題不應只是：

Is it done?

而應變成：

Done with respect to which query?

8. Effective Completion 的最小形式定義

本文提出一個工作性定義。

令：

$I$ ：原始使用者意圖；
$\Omega$ ：授權任務範圍；
$R$ ：必要 requirements / invariants；
$W_t$ ：時間 $t$ 的有效 world state；
$E_t$ ：可用證據；
$O_t$ ：scope 內可行動義務集合；
$V$ ：必要 verification / validation predicates。

則 bounded effective completion 可以寫為：

\boxed{ EC(T,t)=1 }

當且僅當至少滿足：

Align(W_t,I,\Omega)\ge\tau_I,

\forall r\in R_{critical}, \quad V(r,E_t)=1,

O_t^{actionable}=\varnothing,

以及：

Fresh(E_t)\ge\tau_f.

這裡刻意沒有要求：

\text{All conceivable imperfections}=0.

因為：

\boxed{ \text{Completion} \neq \text{Perfection}. }

Completion 只要求：在既定 scope、風險與資源下，沒有仍需處理的 critical in-scope obligation，且必要 evidence 足以支持該聲明。

9. Completion Evidence 需要三種獨立性

一個 evidence packet 即使很多，也可能沒有真正增加完成可信度。

本文提出三種應區分的 independence。

9.1 Source Independence

證據是否來自不同來源？

例如：

Agent says PASS
Agent-generated test says PASS
Agent-generated summary says PASS

看似三項 evidence，實際可能高度同源。

9.2 Causal Independence

驗證 evidence 是否真的由目標世界狀態產生？

如果：

\text{ExpectedState} \rightarrow \text{ObservedState}

只是因為系統把 expected state 寫回 observation store，則沒有 causal independence。

更合理的是：

\text{Action} \rightarrow \text{WorldChange} \rightarrow \text{NewObservation} \rightarrow \text{Verification}.

9.3 Semantic Independence

多個 verifier 是否其實都在測同一個 proxy？

例如：

unit test；
snapshot test；
reviewer；

若三者都只確認 DOM text 是否存在，它們沒有增加 interaction semantics 的 coverage。

因此：

\boxed{ \text{Evidence Count} \neq \text{Evidence Independence}. }

10. Agent 時代為什麼更容易出現 Completion Compression

傳統工程組織裡，很多狀態天然分散在不同角色：

Developer
QA
Designer
Operator
Product Owner
Security
User

這種分散本身有 coordination cost，但也會保留不同完成語義。

Agent 系統則可能將：

\text{Generator} + \text{Planner} + \text{Tester} + \text{Reviewer} + \text{Operator} + \text{Reporter}

壓入同一個 cognitive runtime。

如果沒有額外 state discipline，容易形成：

\boxed{ \text{Role Compression} \rightarrow \text{Completion-Semantics Compression}. }

此時「我完成了」可能同時混合：

我寫完了；
我測過了；
我沒看到錯；
我認為符合規格；
我認為使用者會滿意；
我認為沒有其他重要工作。

這六句完全不是同一命題。

11. Unsupported Completion Rate：把「自信地說 Done」變成可測問題

作者既有 APOR 研究提出：

UCR = \frac{ \text{UnsupportedDoneClaims} }{ \text{AllDoneClaims} }.

這個指標可以直接併入本系列。

但本文進一步建議分解：

UCR = f( U_{evidence}, U_{scope}, U_{freshness}, U_{authority}, U_{intent} ).

其中：

$U_{evidence}$ ：缺乏 supporting evidence；
$U_{scope}$ ：claim 超過已驗 scope；
$U_{freshness}$ ：使用 stale evidence；
$U_{authority}$ ：沒有資格做全域 completion claim；
$U_{intent}$ ：驗證成功但偏離原始 intent。

如此一來，unsupported done 不再只是「沒貼測試結果」，而是更完整的 completion pathology。

12. Completion Confidence 不能只靠證據數量

可以定義概念性的 completion support：

Support(T) = F( \text{Coverage}, \text{Freshness}, \text{Independence}, \text{Relevance}, \text{Authority}, \text{IntentAlignment} ).

而不是：

Support(T) = \#Evidence.

例如：

1000 unit tests PASS

若都沒有覆蓋：

real browser interaction

則對 UI workflow completion 的 support 仍可能很低。

反過來，一個精確的 end-to-end witness 有時比數十個同質 test 更有 completion information value。

因此：

\boxed{ \text{Completion Evidence Quality} > \text{Completion Evidence Quantity} }

在同質重複證據增加時尤其如此。

13. 六個跨領域例子

13.1 UI：Screenshot Green，Interaction Red

pixel snapshot: PASS
component render: PASS
build: PASS

但：

button cannot be reached by actual interaction path

此時：

S_v^{visual}=1, \qquad S_e^{interaction}=0.

13.2 API：Schema Correct，Business Semantics Wrong

response 完全符合 JSON schema：

SchemaValid=1,

但其中 price、permission 或 lifecycle state 的 business meaning 錯誤。

因此：

SyntaxClosure=1 \not\Rightarrow SemanticClosure=1.

13.3 Deployment：Provider Receipt 不等於 World Outcome

cloud API 回：

DEPLOYED

但：

traffic 還沒有切過去；
health check 失敗；
DNS 尚未更新；
old replica 仍服務使用者。

因此：

Receipt=1 \not\Rightarrow EffectiveDeployment=1.

13.4 研究：Document Produced 不等於 Research Closed

Agent 生成一份 80 頁報告：

ArtifactExists=1.

但：

關鍵引用未驗；
claim 沒有外部 support；
反例尚未處理；
research question 被悄悄改寫。

因此：

\text{DocumentCompletion} \neq \text{EpistemicCompletion}.

13.5 Formal Proof：Type-Check 不等於 Intended Theorem

proof checker 接受：

ProofValid=1,

只證明「被形式化的 statement」在該 formal system 中成立。

如果原始自然語言命題被錯誤翻譯，仍可能：

FormalClosure=1, \qquad IntentClosure=0.

13.6 遊戲：所有子系統都 Done，但遊戲還沒成為那個遊戲

程式說：

mechanic implemented

美術說：

assets complete

企劃說：

rules finalized

但如果三者在實際 play loop 中沒有閉合：

C_{code}=1, \quad C_{art}=1, \quad C_{design}=1,

仍可能：

C_{game}<1.

這也是下一篇「局部正確與全域失敗」的入口。

14. Completion 不應被同一個 Agent 無條件自動提升

一個 Agent 可以有權：

IMPLEMENT
TEST
REPORT

但不代表它必然具有：

DECLARE_GLOBAL_COMPLETION

因此可以將 completion authority 建模為：

A_C = A_C(T,\Omega,R,E).

低風險局部任務可以允許 Agent 直接完成聲明。

高風險／跨域／不可逆任務則可能需要：

independent validator；
user acceptance；
production observation；
human authority；
cross-perspective closure。

這不是把每件事都升格成 bureaucracy。

而是：

\boxed{ \text{Completion Authority Must Match Claim Scope}. }

15. 最小 Completion Protocol

對一般 AI engineering task，本文建議的最小 protocol 為：

1. Recover intended scope.
2. Build / execute the requested artifact or change.
3. Collect evidence from the relevant failure domains.
4. Separate declared / observed / inferred / reviewed / verified states.
5. Check freshness and world-state causality.
6. List unmeasured domains explicitly.
7. Close all critical actionable in-scope obligations.
8. Emit a scoped completion assertion.
9. Stop.

第 9 步非常重要。

Completion semantics 不是新的 infinite review generator。

如果：

O_t^{actionable}=\varnothing

且：

Support(T)\ge\tau,

則應停止，而不是因為還能想像新問題就持續擴張 scope。

16. 建議的 Completion Report Schema

completion:
  task_id: ...
  original_intent: ...
  requested_scope: ...

  state:
    declared: ...
    observed: ...
    inferred: ...
    reviewed: ...
    verified: ...
    effective_completion: ...

  evidence:
    positive_witnesses: []
    falsifying_witnesses_checked: []
    independent_observations: []
    provenance: []
    freshness: ...

  scope_status:
    covered: []
    not_measured: []
    out_of_scope: []
    blocked_external: []
    deferred_by_scope: []

  obligations:
    remaining_critical: []
    remaining_nonblocking: []

  authority:
    completion_claim_owner: ...
    promotion_authority: ...

  final_status:
    value: COMPLETE | PARTIAL | BLOCKED | UNKNOWN
    valid_at: ...

這個 schema 不要求所有實作照抄。

它只展示：

\boxed{ \text{Completion Is a Structured State Transition} }

而不是一個 conversational adjective。

17. 反例與邊界：本文不主張什麼

17.1 不主張所有 `PASS` 都不可信

PASS 仍然是重要 evidence。

本文反對的是：

PASS_{local} \Rightarrow DONE_{global}

被無條件使用。

17.2 不要求所有 Agent 都需要獨立 reviewer

低風險、可逆、清楚範圍的 local task 可以：

Generator=Verifier=Reporter

只要 claim scope 不超過 evidence scope。

17.3 不把 Effective Completion 定義成形上學的「絕對真實」

工程上永遠可能存在未知未知。

本文的 $S_e$ 是 bounded、evidence-bearing、scope-relative 的 effective completion，而不是全知證明。

17.4 不要求驗證所有 modality

某些任務只需要 code-level evidence。

某些任務需要 browser、runtime、audio、vision 或 human interaction。

是否需要新 observation domain，應由任務 failure domain 與 uncertainty 決定，而不是機械式全開。

17.5 不把使用者 acceptance 當成唯一真理

使用者可能不知道底層 security、data corruption 或 reliability 問題。

因此：

UserAcceptance=1

也不必然推出：

AllCriticalInvariants=1.

Completion 仍需多層 evidence。

18. 與 A01「綠燈錯置」的精確關係

A01 聚焦：

G=1, \qquad A<1,

亦即 verifier 綠燈，但 alignment 不足。

A02 將問題一般化為：

\boxed{ \text{Any success carrier} \not\Rightarrow \text{Effective completion}. }

其中 success carrier 可以是：

\text{Proxy} \in \{ \text{Test}, \text{Review}, \text{Plan}, \text{Ticket}, \text{Artifact}, \text{Receipt}, \text{Status}, \text{Benchmark}, \text{FormalProof}, \text{HumanApproval} \}.

因此：

\boxed{ \text{Green Closure Misalignment} \subset \text{Observable Success–Effective Completion Separation}. }

A01 是最危險、最直觀的一型；A02 則提供更一般的 state semantics。

19. 與「表觀完好系統」系列的關係

早期系列研究：

I_o \nRightarrow I_s.

A02 則把它提升成：

I_o^{task} \nRightarrow I_e^{task}.

兩者共享一個共同結構：

可觀察表面不是對整體狀態的完備表示。

但 A02 的新增點在於：

觀察者可以是 Agent；
verifier 可以由 Agent 自己建立；
completion claim 可以成為 autonomous workflow 的控制訊號；
錯誤 completion 不只是「理解錯」，還會驅動後續 commit、promotion、deployment 與停止決策；
因此 completion state 必須成為可治理的 machine object。

20. 十條核心命題

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

\boxed{ \textbf{P1: Observable success does not imply effective completion.} }

\boxed{ \textbf{P2: A completion claim is a scoped, evidence-bearing state assertion.} }

\boxed{ \textbf{P3: Declared, observed, inferred, reviewed, verified, and effective states are not interchangeable.} }

\boxed{ \textbf{P4: Proxy success can be correct while mission completion is false.} }

\boxed{ \textbf{P5: Self-consistency is not world-consistency.} }

\boxed{ \textbf{P6: Evidence freshness is part of completion semantics.} }

\boxed{ \textbf{P7: Evidence count does not imply evidence independence.} }

\boxed{ \textbf{P8: Completion authority must not exceed completion evidence scope.} }

\boxed{ \textbf{P9: Effective completion is bounded closure, not absolute perfection.} }

\boxed{ \textbf{P10: A mature Agent should emit structured completion state rather than an unqualified DONE.} }

21. 下一篇接口：從 Completion State 進入局部—全域問題

即使每一個 completion assertion 都有 evidence，仍會遇到下一個問題：

C_1=1, \quad C_2=1, \quad \ldots, \quad C_n=1

是否能推出：

C_G=1?

答案仍然是否定的。

前端可以完成。

後端可以完成。

資料庫 migration 可以完成。

UI 可以完成。

測試也可以完成。

但它們整合後仍可能不是使用者要求的那個產品。

因此下一篇 A03 將研究：

局部正確與全域失敗

核心問題為：

\boxed{ \forall i, \ C_i=1 \not\Rightarrow C_G=1. }

A02 先把「一個 completion claim 是什麼」說清楚；A03 再處理「多個局部 completion 如何仍然無法形成宏觀 completion」。

22. 結論

AI 時代需要把「是不是成功」改寫成一組更精確的問題：

成功的是哪一層？
成功的是哪一個 scope？
這是 declaration、observation、inference、review 還是 verification？
evidence 從哪裡來？
evidence 是否獨立？
evidence 是否仍然新鮮？
哪些 domain 尚未量測？
有沒有尚未閉合的 critical obligation？
這個 caller 是否有資格把局部成功提升成全域完成？
最後的 world state 是否真的滿足原始 intent？

因此真正危險的不是 Agent 明確回報：

FAILED

而是：

\boxed{ \text{It reports success at a layer the user did not ask about.} }

更一般地：

\boxed{ \text{Completion is not a label attached to an artifact.} }

而是：

\boxed{ \text{a scoped, temporal, evidence-bearing claim about the effective state of a task in the world.} }

這一轉換使 DONE 從聊天語句變成可驗證、可更新、可失效、可回溯、可治理的 Agent runtime object，也為後續「局部—全域」、「流程代理錯置」、「能力—視角啟動不對稱」與第二系列的動態全域觀察方法論建立狀態語義基礎。

參考與理論來源

A. 外部既有研究／工程背景

NASA, Systems Engineering Handbook — Distinctions between Product Verification and Product Validation.
https://www.nasa.gov/reference/2-4-distinctions-between-product-verification-and-product-validation/
NASA, Product Validation.
https://www.nasa.gov/reference/5-4-product-validation/
NASA, Technical Requirements Definition.
https://www.nasa.gov/reference/4-2-technical-requirements-definition/
NIST, AI Measurement and Evaluation.
https://www.nist.gov/ai-measurement-and-evaluation
NIST, Assessing Risks and Impacts of AI (ARIA): Pilot Evaluation Report, NIST AI 700-2, 2025.
https://www.nist.gov/publications/assessing-risks-and-impacts-ai-aria-pilot-evaluation-report
Krakovna, V. et al., Specification gaming: the flip side of AI ingenuity, Google DeepMind, 2020.
https://deepmind.google/blog/specification-gaming-the-flip-side-of-ai-ingenuity/

B. Neo.K 既有內部理論／工程文件

〈功能正常，不代表結構正常：軟體表觀完好命題〉。
〈補償性完好：為什麼不完整的軟體仍然可以正常運作〉。
〈今天的 Workaround，明天的 Architecture：補償凝固命題〉。
PSA-02 Project Object and Four Topology Separation。
EML APOR 06 — From Multi-Agent Role Simulation to AI-Native Product Organizations。
〈從持續機器觀察到受權限代理行動的跨結構感知記憶織體〉。
Adaptive Perceptual Reading / Agentic Perception Runtime 系列。
A01〈綠燈錯置——AI 時代「通過驗證」不等於「完成意圖」的新型不對齊〉。

版本註記（v0.2）： 本版在 v0.1 基礎上新增 Verification / Validation 外部理論錨點、Completion Assertion 結構、六類表觀成功來源、freshness 與 omitted-domain 模型、evidence independence、Effective Completion 最小定義、Unsupported Completion Rate 分解、Completion Authority、最小 runtime protocol、跨領域案例與 A03 接口。原 v0.1 核心命題與系列定位保持不變。

表觀成功與實質完成的分離 v0.2

表觀成功與實質完成的分離 v0.2

——從軟體表觀完好到 Agent 完成狀態語義

摘要

1. 問題不是「AI 會不會說謊」，而是「SUCCESS 到底指向什麼」

2. 與傳統 Verification / Validation 的關係：不是從零開始，但 Agent 問題更廣

3. 五種以上的成功狀態不應壓成一個 DONE

4. Completion Assertion：DONE 必須帶來源與邊界

5. 表觀成功的六種來源

5.1 真成功（Effective Success）

5.2 補償性成功（Compensated Success）

5.3 代理指標成功（Proxy Success）

5.4 自我封閉成功（Self-Closed Success）

5.5 Stale Success：舊證據仍綠，但世界已變

5.6 Omitted-Domain Success：被測的都成功，沒測的才是問題

6. NIST 的 measurement context 提醒：量測本身不是脫離情境的真理

7. Project State 不應是一個字串：Completion 也是 State Projection

8. Effective Completion 的最小形式定義

9. Completion Evidence 需要三種獨立性

9.1 Source Independence

9.2 Causal Independence

9.3 Semantic Independence

10. Agent 時代為什麼更容易出現 Completion Compression

11. Unsupported Completion Rate：把「自信地說 Done」變成可測問題

12. Completion Confidence 不能只靠證據數量

13. 六個跨領域例子

13.1 UI：Screenshot Green，Interaction Red

13.2 API：Schema Correct，Business Semantics Wrong

13.3 Deployment：Provider Receipt 不等於 World Outcome

13.4 研究：Document Produced 不等於 Research Closed

13.5 Formal Proof：Type-Check 不等於 Intended Theorem

13.6 遊戲：所有子系統都 Done，但遊戲還沒成為那個遊戲

14. Completion 不應被同一個 Agent 無條件自動提升

15. 最小 Completion Protocol

16. 建議的 Completion Report Schema

17. 反例與邊界：本文不主張什麼

17.1 不主張所有 PASS 都不可信

17.2 不要求所有 Agent 都需要獨立 reviewer

17.3 不把 Effective Completion 定義成形上學的「絕對真實」

17.4 不要求驗證所有 modality

17.5 不把使用者 acceptance 當成唯一真理

18. 與 A01「綠燈錯置」的精確關係

19. 與「表觀完好系統」系列的關係

20. 十條核心命題

21. 下一篇接口：從 Completion State 進入局部—全域問題

局部正確與全域失敗

22. 結論

參考與理論來源

A. 外部既有研究／工程背景

B. Neo.K 既有內部理論／工程文件

3. 五種以上的成功狀態不應壓成一個 `DONE`

4. Completion Assertion：`DONE` 必須帶來源與邊界

17.1 不主張所有 `PASS` 都不可信