# 表觀成功與實質完成的分離 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 到底指向什麼」 在傳統互動中，使用者看到： ```text 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。 因此： ```text DONE ``` 若沒有以上結構，在工程上只是一個高度壓縮的 projection。 更合理的是： ```yaml 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 說： ```text dialog.visible = false ``` provider 回傳： ```text CONFIRMED ``` 如果系統直接將： ```text 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. $$ 例如： ```text 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。 真實專案可能同時具有： ```text core stability: stable Windows installer: failing Linux tests: pass security review: not measured release package: built production deployment: not authorized user journey: partially verified ``` 如果系統將這些壓成： ```text 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 證據是否來自不同來源？ 例如： ```text 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 傳統工程組織裡，很多狀態天然分散在不同角色： ```text 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. $$ 例如： ```text 1000 unit tests PASS ``` 若都沒有覆蓋： ```text 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 ```text pixel snapshot: PASS component render: PASS build: PASS ``` 但： ```text 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 回： ```text 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，但遊戲還沒成為那個遊戲 程式說： ```text mechanic implemented ``` 美術說： ```text assets complete ``` 企劃說： ```text rules finalized ``` 但如果三者在實際 play loop 中沒有閉合： $$ C_{code}=1, \quad C_{art}=1, \quad C_{design}=1, $$ 仍可能： $$ C_{game}<1. $$ 這也是下一篇「局部正確與全域失敗」的入口。 --- # 14. Completion 不應被同一個 Agent 無條件自動提升 一個 Agent 可以有權： ```text IMPLEMENT TEST REPORT ``` 但不代表它必然具有： ```text 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 為： ```text 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 ```yaml 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 的新增點在於： 1. 觀察者可以是 Agent； 2. verifier 可以由 Agent 自己建立； 3. completion claim 可以成為 autonomous workflow 的控制訊號； 4. 錯誤 completion 不只是「理解錯」，還會驅動後續 commit、promotion、deployment 與停止決策； 5. 因此 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 明確回報： ```text 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. 外部既有研究／工程背景 1. 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/ 2. NASA, *Product Validation*. https://www.nasa.gov/reference/5-4-product-validation/ 3. NASA, *Technical Requirements Definition*. https://www.nasa.gov/reference/4-2-technical-requirements-definition/ 4. NIST, *AI Measurement and Evaluation*. https://www.nist.gov/ai-measurement-and-evaluation 5. 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 6. 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 既有內部理論／工程文件 1. 〈功能正常，不代表結構正常：軟體表觀完好命題〉。 2. 〈補償性完好：為什麼不完整的軟體仍然可以正常運作〉。 3. 〈今天的 Workaround，明天的 Architecture：補償凝固命題〉。 4. *PSA-02 Project Object and Four Topology Separation*。 5. *EML APOR 06 — From Multi-Agent Role Simulation to AI-Native Product Organizations*。 6. 〈從持續機器觀察到受權限代理行動的跨結構感知記憶織體〉。 7. *Adaptive Perceptual Reading / Agentic Perception Runtime* 系列。 8. 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 核心命題與系列定位保持不變。