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

——從軟體表觀完好到 Agent 完成失真

English Title: Observable Success Is Not Effective Completion
系列：《綠燈錯置：AI 操作意圖不對齊與完成失真》02 / 08
作者： Neo.K × AI 協作
版本： v0.1
日期： 2026-09

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

摘要

軟體可以啟動、主要功能可用、測試大致通過，卻仍具有嚴重的結構侵蝕、責任錯位與隱性依賴。這一「表觀完好」命題在 Agent 時代出現更一般化的版本：一個任務可以被標記為 DONE、測試可以為綠、review 可以通過、artifact 可以成功產生，但實際完成狀態仍與原始意圖、有效環境或真實產品狀態不一致。

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

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

其中 $I_o^{task}$ 表示任務在可觀察表面上的成功， $I_e^{task}$ 表示任務在有效系統中的實質完成。本文進一步區分 Declared Success、Observed Success、Inferred Success、Verified Success 與 Effective Completion，並指出「DONE」不是一個單一布林值，而應是一組帶有 authority、evidence、scope 與 validity interval 的狀態聲明。

1. 從「功能正常」到「任務成功」

早期的軟體表觀完好命題研究：

I_o \nRightarrow I_s,

亦即外部功能正常不能充分推出內部結構完整。

Agent 時代需要把問題再推一步。對一個由 AI 執行的任務，表面成功可能來自：

tool 回傳 success；
test suite 全綠；
CI pipeline 綠燈；
reviewer 說 LGTM；
Agent 自己回報 done；
artifact 已存在；
acceptance script 沒有報錯。

但這些只證明某些 observation channel 沒有偵測到失敗。

因此：

\boxed{ \text{Observed Success} \neq \text{Effective Completion} }

2. 五種完成狀態不應混成一個 DONE

令任務 $T$ 的完成狀態至少分為：

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

其中：

$S_d$ ：Declared Success，Agent／人／manifest 宣告成功；
$S_o$ ：Observed Success，工具或 runtime 直接觀察到成功訊號；
$S_i$ ：Inferred Success，由模型或分析器根據 evidence 推論成功；
$S_v$ ：Verified Success，某一指定 verifier 已通過；
$S_e$ ：Effective Completion，任務在目標系統與原始意圖下實質完成。

一般不存在：

S_d=1 \Rightarrow S_e=1.

也不存在：

S_v=1 \Rightarrow S_e=1.

這不是否定 declaration 或 verification 的價值，而是拒絕把不同 authority class 壓成同一個布林值。

3. 表觀成功的四種來源

3.1 真成功

最理想狀態：

S_o=S_v=S_e=1.

3.2 補償性成功

系統本身仍有缺口，但由 workaround、人工作業、fallback、compatibility shim 或外部平台補償：

S_o=1, \qquad S_{native}<1.

這與「補償性完好」一致。

3.3 代理指標成功

驗證器量到的是 proxy：

M_{proxy}=1,

但：

M_{mission}<1.

例如 screenshot pixel diff 通過，但 interaction flow 壞掉。

3.4 自我封閉成功

Agent 建立自己的 expected state，再用同一來源的 state 驗證自己：

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

若中間沒有獨立 world evidence，這是循環自證。

4. Completion State 必須帶 Scope

「完成」不是脫離範圍的永久屬性。

例如：

Windows tests: PASS
Linux tests: PASS
Production deployment: NOT MEASURED
Real-user interaction: NOT MEASURED
Security review: OUT OF SCOPE

此時最誠實的表示不是：

DONE

而是：

\text{Completion}(T,S,E,t),

其中：

$S$ ：scope；
$E$ ：evidence set；
$t$ ：validity time。

因此：

\boxed{ \text{Completion Is Scoped Evidence-Bearing State} }

而不是無條件的全域標籤。

5. 為什麼 AI 時代這個問題會放大

傳統工程中，人類通常知道自己只驗了什麼。

AI Agent 則可能同時：

產生 artifact；
產生 tests；
選擇 validator；
執行 validator；
解釋結果；
宣告完成。

也就是同一認知系統同時控制：

\text{Generator} + \text{Verifier} + \text{Interpreter} + \text{CompletionReporter}.

若缺乏權責分離與獨立 evidence，系統容易形成：

\boxed{ \text{Self-Consistent Completion} \neq \text{World-Consistent Completion} }

6. 與綠燈錯置的關係

綠燈錯置是本命題的一個重要子類：

G=1, \qquad A<1.

本文更一般地指出，甚至不必有一個正式 verifier，任何可被 Agent 誤當作 completion carrier 的 proxy 都可能造成表觀成功：

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

7. 工程規則：不要問「是不是 DONE」，要問「哪一層 DONE」

最小 completion report 應至少包含：

completion:
  requested_scope: ...
  built: ...
  verified: ...
  observed: ...
  not_measured: ...
  blocked_external: ...
  deferred_by_scope: ...
  remaining_actionable_obligations: ...

若：

\text{RemainingActionableObligations}=\varnothing

且必要 evidence 足夠，才可在該 scope 內聲明完成。

8. 核心命題

本文壓縮成五條：

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

\boxed{ \textbf{P2: DONE is an assertion with scope, authority, evidence, and time.} }

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

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

\boxed{ \textbf{P5: Completion should be represented as a structured state, not a single label.} }

9. 結論

AI 時代需要從「是否成功」轉向「成功的是什麼、在哪個 scope、由誰判定、根據什麼 evidence、有效到什麼時間」。

真正危險的不是 Agent 說「我失敗了」，而是：

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

這也為下一篇「局部正確與全域失敗」建立了狀態語義基礎。