← Archive
lm-004776 · 2026-10

局部正確與全域失敗 v0.2

zh-Hant · md Raw source ↗ Metadata ↗
下載 MD 檔 ⬇

局部正確與全域失敗 v0.2

——投影閉合、跨邊界錯位與宏觀完成缺口

English Title: Local Correctness, Global Failure: Projection Closure, Boundary Failure, and the Gap to Macro Completion
系列：《綠燈錯置：AI 操作意圖不對齊與完成失真》03 / 08
作者： Neo.K × AI 協作
版本： v0.2
日期： 2026-09-16
文件性質： AI 工程／軟體工程／系統工程／Agent 系統／跨邊界驗證／宏觀完成語義
承接： A01〈綠燈錯置〉、A02〈表觀成功與實質完成的分離〉
後續接口： A04〈流程代理錯置〉、A07〈能力—視角啟動不對稱〉、Series B〈宏觀個體導向的動態全域觀察方法論〉

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

摘要

大型軟體、遊戲、Agent 系統與一般複雜產品，幾乎從來不是由單一表示、單一專業或單一驗證器完整描述。前端、後端、資料、基礎設施、安全、UX、程式、美術、企劃、玩家、營運與外部環境，都只能觀察或承擔整體系統的一部分。這些局部視角可以各自建立高品質規格、測試、型別、schema、CI、review、benchmark 與形式化驗證；然而，即使所有局部角色都能合理地宣稱「自己的部分是正確的」，整體產品仍然可能失敗。

本文將此現象正式表述為投影閉合不推出宏觀閉合（Projection Closure Does Not Imply Macro Closure）。令宏觀對象為 XX，不同角色、工具、模態與工程層形成觀察或責任投影：

Oi:X→Yi.O_i:X\rightarrow Y_i.

若每一個局部驗證器只在自己的投影上工作：

Vi(Oi(X))=1,V_i(O_i(X))=1,

則一般不存在：

∀i,  Vi(Oi(X))=1⇒VG(X,I)=1.\forall i,\;V_i(O_i(X))=1 \Rightarrow V_G(X,I)=1.

原因在於宏觀對象不只由元件組成，也由元件間的關係、邊界、時序、共享狀態、權限、環境耦合與跨角色語義共同構成。局部 verifier 可以正確驗證 vertex，卻完全沒有驗證 edge；可以驗證 declared contract，卻沒有驗證 effective interaction；可以驗證 source-level correctness，卻沒有驗證 runtime、human、visual、operational 或 external-world consequence。

本文提出四層完成結構：

Cmacro=Clocal∧Cboundary∧Ccross-perspective∧Cintent\boxed{ C_{\mathrm{macro}} = C_{\mathrm{local}} \land C_{\mathrm{boundary}} \land C_{\mathrm{cross\text{-}perspective}} \land C_{\mathrm{intent}} }

並進一步加入 environment / runtime 條件，建立局部閉合、邊界閉合、跨視角閉合與宏觀意圖閉合之間的區分。本文同時提出 Projection Closure Fallacy、Boundary Blindness、Relation Failure、Cross-Perspective Contradiction、Homogeneous Green、Productive Friction 等概念，將遊戲開發中的程式／企劃／美術、軟體中的前端／後端／X 端，以及 AI Agent 中同模型多角色 review 統一到同一個架構。

本文與既有 systems engineering、product integration、interface management、end-to-end V&V、component composition、contract-based design 與 emergent behavior 研究相容。NASA Systems Engineering Handbook 明確將 product integration、interface management、complete-system integration 與 end-to-end validation 視為不同於單一 end-item verification 的必要工程活動；軟體工程中的 emergent behavior 研究也指出，系統級錯誤可能來自多個正確元件之間的互動，而非單一元件本身。

本文的新命題不在於重新發明 integration testing，而是將問題推進到 AI-native engineering：當 AI 能快速生成大量局部正確的 artifact，而且同一模型可以同時扮演 implementer、reviewer、tester 與 architect 時，最危險的失敗不一定是「沒有驗證」，而可能是「所有驗證都停留在同一投影」。

1. 問題：每一個人都對，產品還是錯

複雜系統中存在一種很常見、但在 AI 自動化時代會被放大的狀態：

Frontend: PASS
Backend: PASS
Database migration: PASS
Schema: PASS
CI: PASS
Security scan: PASS
Deployment: PASS

最後：

User clicks checkout
→ spinner never ends
→ payment already captured
→ UI still shows "processing"

這時不能簡單地說：

前端測試是假測試。

也不能直接說：

後端一定錯。

完全可能出現：

CF=1,C_F=1, CB=1,C_B=1, CD=1,C_D=1,

而：

CF↔B=0C_{F\leftrightarrow B}=0

或：

CB↔Payment=0.C_{B\leftrightarrow \mathrm{Payment}}=0.

最後：

Cproduct=0.\boxed{ C_{\mathrm{product}}=0. }

這表示錯誤的所在不是某一個單獨 component，而是：

Relation.\boxed{ \text{Relation}. }

A01 已指出「局部正確不推出全域意圖對齊」。A02 進一步指出 PASS / DONE / SUCCESS 只是一種帶 scope 的成功聲明。本文則把問題往中間補完整：

局部與宏觀之間不是一個空白，而是一組必須被獨立驗證的關係結構。

2. 宏觀產品不是局部 artifact 的集合

令系統中的構件集合為：

V={v1,v2,…,vn}.V=\{v_1,v_2,\ldots,v_n\}.

如果只把產品寫成：

X=V,X=V,

則系統會被錯誤地理解成「一堆東西的集合」。

但真實產品至少包含：

Xt=(V,E,St,Γt,Et).\boxed{ X_t=(V,E,S_t,\Gamma_t,\mathcal E_t). }

其中：

  • VV：元件、模組、服務、資產、角色、文件、模型；
  • EE：依賴、呼叫、資料流、時序、控制、契約、handoff、語義關係；
  • StS_t：時間 tt 的有效狀態；
  • Γt\Gamma_t：權限、責任、治理與可執行 action 邊界；
  • Et\mathcal E_t：部署環境、使用者、外部服務、網路、設備與其他有效環境條件。

因此產品不是：

Components.\text{Components}.

而是：

Components+Relations+State+Authority+Environment.\boxed{ \text{Components} + \text{Relations} + \text{State} + \text{Authority} + \text{Environment}. }

這一點與既有 systems engineering 的 integration 觀完全一致。NASA 將 product integration 描述為對 subsystem interaction 以及 subsystem 與 system environment interaction 的工程活動，並特別要求檢查整合後是否產生 adverse emergent behaviors。也就是說，低階產品被組裝成高階產品後，新的驗證對象已經出現。

所以：

∀vi∈V,V(vi)=1\forall v_i\in V,\quad V(v_i)=1

仍不能推出：

V(Xt)=1.V(X_t)=1.

因為：

E,  St,  Γt,  EtE,\;S_t,\;\Gamma_t,\;\mathcal E_t

仍可能失敗。

3. 投影：每一個角色看到的都是真的，但都不是全部

令完整宏觀對象為 XX。

不同專業、工具與感知模式建立：

Oi:X→Yi.O_i:X\rightarrow Y_i.

OiO_i 可以是：

  • frontend projection；
  • backend projection；
  • database projection；
  • security projection；
  • performance projection；
  • visual projection；
  • UX projection；
  • game-design projection；
  • art projection；
  • player projection；
  • runtime trace projection；
  • source-code projection；
  • infrastructure projection；
  • organizational projection。

重要的是：

Oi(X)≠X.\boxed{ O_i(X)\neq X. }

這不代表投影是錯誤。

相反地，一個好的專業視角通常正是因為它主動忽略大量與目前責任無關的資訊，才能提高局部解析度。

例如後端工程師可能忽略：

  • 字體；
  • 動畫節奏；
  • UI 對比；
  • 玩家是否直覺理解技能效果。

這並不表示後端工程師失職。

同樣，美術工作也不需要在每一張角色立繪上重新推導資料庫 isolation level。

問題只在於：

局部投影何時被錯誤地冒充成宏觀對象本身？

4. 投影閉合謬誤

本文將以下推論稱為：

Projection Closure Fallacy

投影閉合謬誤

若：

∀i,Vi(Oi(X))=1,\forall i,\quad V_i(O_i(X))=1,

就推論：

VG(X)=1.V_G(X)=1.

這個推論一般不成立。

原因至少有五類。

第一，projection 可能不完備：

⋃iOi\bigcup_i O_i

沒有覆蓋某些有效世界狀態。

第二，projection 間可能存在未驗證關係。

第三，不同 projection 的語義可能互相矛盾。

第四，所有 projection 可能共享同一個 blind spot。

第五，宏觀層可能產生任何單一 projection 中都不存在的 emergent behavior。

所以：

Projection Completeness\boxed{ \text{Projection Completeness} }

與：

Projection Consistency\boxed{ \text{Projection Consistency} }

都必須被獨立處理。

5. Relation Failure：錯誤可以只存在於「之間」

最容易被局部驗證遺漏的，不是 node，而是 edge。

令：

eij∈Ee_{ij}\in E

表示：

vi→vjv_i\rightarrow v_j

之間的一個有效關係。

例如：

  • API contract；
  • event sequencing；
  • schema mapping；
  • file format；
  • transaction boundary；
  • cache invalidation；
  • animation-event timing；
  • authority transfer；
  • model-tool protocol；
  • human handoff；
  • retry semantics；
  • deployment dependency。

若：

V(vi)=1,V(vj)=1,V(v_i)=1, \qquad V(v_j)=1,

但：

V(eij)=0,V(e_{ij})=0,

則：

Correct Components+Incorrect Relation=Incorrect System Path.\boxed{ \text{Correct Components} + \text{Incorrect Relation} = \text{Incorrect System Path}. }

這就是 relation failure。

既有 component-based software 研究早已指出：即使 components 對 domain interface specification 分別正確，runtime binding 之後的 system correctness 仍不自動成立。contract-based design 也因此需要 assumptions / guarantees 與 composite refinement，而不是只證明每個 component 自己成立。

6. Static Interface 正確，不代表 Behavioral Interaction 正確

跨邊界錯誤不能只理解成：

field name mismatch

或：

wrong API version

因為 interface 可以在 static schema 層完全一致，但 behavioral assumptions 不一致。

例如：

Frontend assumption:
POST /checkout 回傳 200
→ payment 已完成且 UI 可立即顯示成功

Backend guarantee:
POST /checkout 回傳 200
→ payment job 已被接受，最終狀態稍後由 event 決定

兩邊 schema 都合法。

HTTP status 也合法。

甚至各自 unit test 全綠。

但：

SemanticsF≠SemanticsB.\mathrm{Semantics}_F \neq \mathrm{Semantics}_B.

因此：

Syntactic Compatibility≠Behavioral Compatibility.\boxed{ \text{Syntactic Compatibility} \neq \text{Behavioral Compatibility}. }

再例如：

Service A:
retry is safe

Service B:
operation is not idempotent

單獨看：

A=correct,B=correct.A=\mathrm{correct}, \qquad B=\mathrm{correct}.

組合後：

A∘BA\circ B

可能造成重複扣款。

所以真正需要驗證的是：

Assumptioni⊆Guaranteej\boxed{ \mathrm{Assumption}_i \subseteq \mathrm{Guarantee}_j }

是否成立。

7. 時序本身是一種邊界

許多局部正確／全域失敗不是 value mismatch，而是 time mismatch。

例如：

Backend state:
updated

Cache:
old

Client:
old

Event:
delayed

UI:
renders stale snapshot

每一個 subsystem 都可能在自己的 consistency model 下合法。

但使用者看到：

付款成功
+
訂單仍顯示未付款

此時 failure domain 不是：

Value.\text{Value}.

而是：

Temporal Relation.\boxed{ \text{Temporal Relation}. }

可以定義某一 boundary 的時序契約：

Bijtime=(tmin⁡,tmax⁡,ordering,freshness,retry,timeout).B_{ij}^{\text{time}} = ( t_{\min}, t_{\max}, \text{ordering}, \text{freshness}, \text{retry}, \text{timeout} ).

若兩端對：

  • ordering；
  • freshness；
  • timeout；
  • eventual consistency；
  • retry window；

的理解不同，則 component-level pass 不足以保證產品行為。

8. Shared State：兩個正確模組可以讀到不同的世界

令兩個 subsystem 的世界模型為：

Wi(t),Wj(t).W_i(t), \qquad W_j(t).

若：

Wi(t)≠Wj(t),W_i(t)\neq W_j(t),

並不必然表示其中一個壞掉。

它可能只是：

  • replication lag；
  • cache；
  • snapshot；
  • eventual consistency；
  • stale browser state；
  • delayed event；
  • local optimistic update。

真正問題是：

當 action 需要跨模組一致判斷時，這個差異是否仍被允許？\boxed{ \text{當 action 需要跨模組一致判斷時，這個差異是否仍被允許？} }

所以 boundary contract 不應只有 schema，也需要：

State Synchronization Semantics.\text{State Synchronization Semantics}.

這一點在 Agent 系統尤其重要。

兩個 agents 可能：

  • 使用不同 memory snapshot；
  • 讀到不同 artifact version；
  • 使用不同 authority state；
  • 一個讀到新 intent，另一個仍沿用舊 intent。

兩邊都可以對自己的 context 推理得完全正確。

最後仍然：

Globally Wrong.\boxed{ \text{Globally Wrong}. }

9. 權限也是跨邊界語義

工程系統常把 authorization 當 security 的獨立議題。

但在 Agentic runtime 中，authority 本身會直接影響「全域完成是否成立」。

例如：

Planner:
正確產生 deploy plan

Executor:
正確執行 local build

Verifier:
正確驗證 artifact

Deployment:
沒有 production authority

則：

Cplan=1,C_{plan}=1, Cbuild=1,C_{build}=1, Cverify=1,C_{verify}=1,

但：

Cmission=0C_{mission}=0

如果原始任務明確是：

deploy to production。

反過來，若 Agent 沒有 authority 卻自行 promotion，也不是「更完整」，而是：

Authority Boundary Violation.\boxed{ \text{Authority Boundary Violation}. }

因此宏觀 closure 必須包含：

CΓ.C_{\Gamma}.

也就是：

該完成路徑是否在正確 authority chain 內成立？

10. 遊戲：程式、企劃、美術為什麼必然互相吐槽

遊戲提供一個非常直觀的例子。

令完整遊戲為：

G.G.

程式的工作投影：

OP(G)=State+Logic+Runtime+Performance+Architecture.O_P(G) = \text{State} + \text{Logic} + \text{Runtime} + \text{Performance} + \text{Architecture}.

企劃投影：

OD(G)=Rules+Balance+Progression+PlayerExperience+ContentLogic.O_D(G) = \text{Rules} + \text{Balance} + \text{Progression} + \text{PlayerExperience} + \text{ContentLogic}.

美術投影：

OA(G)=VisualForm+Readability+Animation+Style+AssetCost.O_A(G) = \text{VisualForm} + \text{Readability} + \text{Animation} + \text{Style} + \text{AssetCost}.

玩家投影：

OU(G)=Interaction+Perception+Feedback+Difficulty+Meaning.O_U(G) = \text{Interaction} + \text{Perception} + \text{Feedback} + \text{Difficulty} + \text{Meaning}.

如果：

VP(OP(G))=1,V_P(O_P(G))=1, VD(OD(G))=1,V_D(O_D(G))=1, VA(OA(G))=1,V_A(O_A(G))=1,

仍然不能推出：

VG(G)=1.V_G(G)=1.

例如：

程式：
技能狀態機正確。

企劃：
技能數值合理。

美術：
動畫品質很好。

玩家：
根本看不出何時能閃避。

這不是：

美術錯。

也不一定是：

程式錯。

更可能是：

AnimationTiming↔GameplayWindow↔PlayerPerception\boxed{ \text{AnimationTiming} \leftrightarrow \text{GameplayWindow} \leftrightarrow \text{PlayerPerception} }

這個 cross-projection relation 沒閉合。

所以傳統遊戲團隊中大量「互相吐槽」其實具有兩種性質：

Fh=Ccoordination+Vcross-projection.F_h = C_{\mathrm{coordination}} + V_{\mathrm{cross\text{-}projection}}.

一部分是協作摩擦。

另一部分卻是重要的異質驗證。

11. 軟體：前端、後端與 X 端只是不同投影

同理，「前端」「後端」「資料端」「Infra」「Security」「ML」「Mobile」「DevOps」不是完整軟體本體的自然分割線。

它們更接近：

Responsibility Projection.\boxed{ \text{Responsibility Projection}. }

前端常關心：

OF(S)=Interaction+Presentation+ClientState+PerceivedLatency.O_F(S) = \text{Interaction} + \text{Presentation} + \text{ClientState} + \text{PerceivedLatency}.

後端：

OB(S)=BusinessLogic+Persistence+Concurrency+ServiceReliability.O_B(S) = \text{BusinessLogic} + \text{Persistence} + \text{Concurrency} + \text{ServiceReliability}.

Infra：

OI(S)=Deployment+Capacity+Networking+RuntimeHealth.O_I(S) = \text{Deployment} + \text{Capacity} + \text{Networking} + \text{RuntimeHealth}.

Security：

OS(S)=TrustBoundary+Authority+AttackSurface+DataExposure.O_S(S) = \text{TrustBoundary} + \text{Authority} + \text{AttackSurface} + \text{DataExposure}.

Data：

OD(S)=Schema+Lineage+Consistency+Quality+Transformation.O_D(S) = \text{Schema} + \text{Lineage} + \text{Consistency} + \text{Quality} + \text{Transformation}.

每一個都是：

Oi(S).O_i(S).

但：

Oi(S)≠S.\boxed{ O_i(S)\neq S. }

因此「某一端已完成」是局部狀態。

產品完成必須穿過：

OF↔OB↔OI↔OD↔OS↔⋯O_F \leftrightarrow O_B \leftrightarrow O_I \leftrightarrow O_D \leftrightarrow O_S \leftrightarrow\cdots

的有效關係。

12. Full-stack 不等於 Global-stack

Full-stack engineer 或 full-stack Agent 的重要價值之一，是降低：

Boundary Translation Cost.\text{Boundary Translation Cost}.

因為同一 observer 可以看到：

Frontend↔Backend.\text{Frontend} \leftrightarrow \text{Backend}.

但這不能推出：

FullStack=GlobalStack.\boxed{ \text{FullStack} = \text{GlobalStack}. }

至少有四個原因。

第一，front/back 只是整體中的兩類 projection。

第二，同一 observer 同時負責兩側，可能提高 coherence，也可能降低異質反證。

第三，full-stack knowledge 並不自動包含：

  • production operations；
  • security；
  • UX；
  • visual perception；
  • data governance；
  • performance；
  • legal / compliance；
  • organizational workflow；
  • external service behavior。

第四，宏觀問題不只需要「知道更多 layer」，也需要：

知道自己目前沒有看見什麼。\boxed{ \text{知道自己目前沒有看見什麼。} }

所以：

Broad Knowledge≠Global Observational Closure.\text{Broad Knowledge} \neq \text{Global Observational Closure}.

13. Productive Friction：不是所有摩擦都該消失

工程自動化常有一個直覺：

Coordination Friction↓⇒Productivity↑.\text{Coordination Friction}\downarrow \Rightarrow \text{Productivity}\uparrow.

很多時候成立。

但若某種 friction 同時承擔：

Cross-Perspective Challenge,\text{Cross-Perspective Challenge},

則把它全部消除可能同時降低：

Error Detection Diversity.\text{Error Detection Diversity}.

因此本文定義：

Epistemically Productive Friction

認知上有生產力的摩擦

它指：

因角色、表示、責任、觀測模態或失敗模型不同，而迫使系統重新檢查原先未被看見的假設。

例如：

企劃問：

這個功能真的好玩嗎？

程式問：

這個組合狀態空間真的能維持嗎？

美術問：

玩家真的看得懂嗎？

Security 問：

這個 trust boundary 真的成立嗎？

SRE 問：

production failure 時怎麼恢復？

這些問題不是重複 verifier。

它們改變的是：

Oi.O_i.

因此理想方向不是：

Fh→0.F_h\rightarrow0.

而是：

RedundantFriction↓,EpistemicallyProductiveFriction↑.\boxed{ \text{RedundantFriction}\downarrow, \qquad \text{EpistemicallyProductiveFriction}\uparrow. }

14. Cross-Perspective Contradiction：多個真局部可以互相衝突

令兩個 projection 對同一宏觀狀態產生局部 assertion：

ai∈Oi(X),a_i\in O_i(X), aj∈Oj(X).a_j\in O_j(X).

兩者可以各自在局部證據下成立：

Support⁡i(ai)≥τi,\operatorname{Support}_i(a_i)\ge\tau_i, Support⁡j(aj)≥τj,\operatorname{Support}_j(a_j)\ge\tau_j,

但在 joint model 中：

ai∧aja_i\land a_j

可能不可同時成立。

例如：

Backend:
order finalized

Frontend:
order still editable

或者：

Security:
session revoked

Client:
token still treated as active

因此需要定義：

Kij=Consistency⁡(Oi,Oj).\boxed{ K_{ij} = \operatorname{Consistency}(O_i,O_j). }

並且：

Kij=0K_{ij}=0

時，不能用：

兩邊測試都通過。

來結案。

15. Projection Coverage：有多少重要視角根本沒被啟動

如果系統有潛在觀察算子集合：

O={O1,O2,…,On},\mathcal O = \{O_1,O_2,\ldots,O_n\},

當前任務實際啟動：

Otactive⊆O.\mathcal O_t^{active} \subseteq \mathcal O.

可以定義概念性的 projection coverage：

PCt=∑Oi∈Otactivewi∑Oi∈Otrelevantwi.PC_t = \frac{ \sum_{O_i\in\mathcal O_t^{active}}w_i }{ \sum_{O_i\in\mathcal O_t^{relevant}}w_i }.

其中：

Otrelevant\mathcal O_t^{relevant}

不是所有可能 modality，而是對當前宏觀任務真正具有因果或驗證價值的視角。

這個限制很重要。

本文不主張：

Otactive=O\mathcal O_t^{active} = \mathcal O

永遠成立。

因為那會造成：

TokenCost+ToolCost+Latency+CoordinationCost→excessive.\text{TokenCost} + \text{ToolCost} + \text{Latency} + \text{CoordinationCost} \rightarrow \text{excessive}.

真正需要的是：

Sufficient Relevant Projection Coverage.\boxed{ \text{Sufficient Relevant Projection Coverage}. }

這一點將在 Series B 與 APR-driven dynamic observation 中進一步展開。

16. Boundary Coverage：測了多少關係，而不是只測多少元件

令重要邊界集合：

B={b1,b2,…,bm}.\mathcal B = \{b_1,b_2,\ldots,b_m\}.

每一 boundary 具有重要度：

w(bk).w(b_k).

定義：

BC=∑bk∈Bverifiedw(bk)∑bk∈Brequiredw(bk).BC = \frac{ \sum_{b_k\in \mathcal B_{\mathrm{verified}}}w(b_k) }{ \sum_{b_k\in \mathcal B_{\mathrm{required}}}w(b_k) }.

這比單純：

Test Count\text{Test Count}

更接近 integration completeness。

因為 1000 個 unit tests 可能都集中在一個 component。

而一條沒有驗證的高權重 boundary：

payment → ledger

就足以讓：

Cmacro=0.C_{\mathrm{macro}}=0.

所以：

Test Volume≠Boundary Coverage.\boxed{ \text{Test Volume} \neq \text{Boundary Coverage}. }

17. Boundary 不只存在於程式模組之間

本文將 boundary 擴張成至少九類。

17.1 Structural Boundary

module A ↔ module B

17.2 Data Boundary

schema A ↔ schema B

17.3 Temporal Boundary

producer time ↔ consumer time

17.4 Authority Boundary

proposal ↔ allowed action

17.5 Representation Boundary

internal state ↔ UI

17.6 Human Boundary

system ↔ operator

17.7 External-System Boundary

product ↔ payment provider

17.8 Modality Boundary

code state ↔ visual state

17.9 Intent Boundary

implemented behavior ↔ requested outcome

因此 integration testing 只是 cross-boundary closure 的一個子域。

AI-native system 需要更大的 boundary model。

18. Effective Dependency：真正的邊界可能不在 import graph

作者既有「宣告架構／有效架構」系列提出：

De⊇Dstatic.D_e \supseteq D_{\mathrm{static}}.

也就是 effective dependency 可以來自：

  • API；
  • DB；
  • event；
  • config；
  • schedule；
  • human；
  • external service；
  • compatibility behavior；
  • recovery procedure。

因此若 AI 只從 source dependency graph 建 boundary map：

Bsource,B_{\mathrm{source}},

就可能漏掉：

Beffective.B_{\mathrm{effective}}.

例如：

nightly reconciliation job
+
finance operator
+
Excel correction

可能沒有出現在主要 service architecture 中，卻是真正維持產品承諾的有效結構。

所以：

Declared Boundary Map≠Effective Boundary Map.\boxed{ \text{Declared Boundary Map} \neq \text{Effective Boundary Map}. }

19. Emergent Behavior：宏觀錯誤不一定能向下歸因成單一壞元件

軟體工程對 emergent behavior 的研究指出，某些 behavior 不能歸因到單一 subsystem，而是來自多個 component 或 system 的 interplay。

這意味著：

Failure(X)\text{Failure}(X)

不必然存在：

∃vi:Failure(vi)=1.\exists v_i: \text{Failure}(v_i)=1.

完全可能：

∀i,Failure(vi)=0,\forall i,\quad \text{Failure}(v_i)=0,

但：

Failure(X)=1.\text{Failure}(X)=1.

其來源是：

InteractionTopology+State+Environment.\boxed{ \text{InteractionTopology} + \text{State} + \text{Environment}. }

這與本文的 relation-first view 完全一致。

因此「找到哪個檔案錯」不是所有 failure analysis 的合法問題。

有些問題真正需要問：

哪一個關係組合使宏觀狀態進入失敗域？

20. NASA Integration 對本文的工程支持

NASA Systems Engineering Handbook 將：

  • product implementation；
  • product integration；
  • product verification；
  • product validation；

明確分成不同技術流程。

其中 product integration 的核心不是把檔案放在一起，而是：

將 lower-level products 組裝成 higher-level product，工程化 subsystem interaction 以及 subsystem 與 environment 的 interaction，並檢查 integrated product 是否正常、是否產生 adverse emergent behavior。

其 V&V plan 也從：

end item
→ end-item integration
→ complete system integration
→ external interfaces
→ end-to-end integration

逐層提高。

這提供一個非常重要的既有工程對照：

Element Verification≠Integrated-System Verification.\boxed{ \text{Element Verification} \neq \text{Integrated-System Verification}. }

本文只是將這個原理推廣到 AI Agent 與多視角工程：

Projection Verification≠Macro-Object Verification.\boxed{ \text{Projection Verification} \neq \text{Macro-Object Verification}. }

21. Contract-Based Design：局部保證必須帶著假設

在 contract-based design 中，component 不只具有：

Guarantee,\text{Guarantee},

還具有：

Assumption.\text{Assumption}.

可表示為：

Ci=(Ai,Gi).C_i=(A_i,G_i).

當 component 被組合時，需要檢查：

AiA_i

是否真的被其他 component / environment 的：

GjG_j

滿足。

因此：

Gi=1G_i=1

不是充分條件。

因為：

Ai=0A_i=0

時，component 的「正確」可能只是在不存在的前提下成立。

這與 AI coding 有直接關係。

AI 常能生成：

function correct under expected input

卻沒有檢查：

does real upstream actually guarantee expected input?

所以：

Implementation Correctness≠Assumption Satisfaction.\boxed{ \text{Implementation Correctness} \neq \text{Assumption Satisfaction}. }

22. Cross-Boundary Closure

本文將 boundary closure 定義為：

對所有 required boundary：

bij∈Brequired,b_{ij}\in\mathcal B_{\mathrm{required}},

存在足夠 evidence：

EijE_{ij}

使：

Vij(Oi(X),Oj(X),Eij)=1.V_{ij} ( O_i(X), O_j(X), E_{ij} )=1.

因此：

CB=⋀bij∈BrequiredVij.\boxed{ C_B = \bigwedge_{b_{ij}\in\mathcal B_{\mathrm{required}}} V_{ij}. }

但工程上不需要對宇宙中所有 pair 做：

O(n2)O(n^2)

驗證。

只需要對：

Bcausal/relevant\mathcal B_{\mathrm{causal/relevant}}

進行 risk-weighted closure。

因此：

Boundary Closure≠All-Pairs Testing.\boxed{ \text{Boundary Closure} \neq \text{All-Pairs Testing}. }

這與 Global-First / APR 的 resource governance 一致。

23. Cross-Perspective Closure

Boundary closure 側重：

interaction.\text{interaction}.

Cross-perspective closure 則處理：

interpretation.\text{interpretation}.

例如同一個 feature：

Backend:
correct

UX:
misleading

Security:
unsafe

Legal:
not allowed

Player:
unreadable

因此需對 relevant projections 建立：

Kij.K_{ij}.

並在存在重大 contradiction 時 reopen。

定義：

CP=1[all material cross-perspective contradictions resolved or explicitly bounded].C_P = \mathbf 1[ \text{all material cross-perspective contradictions resolved or explicitly bounded} ].

這裡的 resolved 不要求所有角色喜歡同一方案。

而是要求：

  • contradiction 被看見；
  • trade-off 被承認；
  • authority owner 做出決定；
  • 結果被寫回 canonical intent / specification；
  • verifier 不再拿舊假設驗新產品。

24. 宏觀完成的五層模型

A03 v0.1 提出四層 closure。v0.2 將它細化為五層：

Cmacro=CL∧CB∧CP∧CE∧CI.\boxed{ C_{\mathrm{macro}} = C_L \land C_B \land C_P \land C_E \land C_I. }

其中：

24.1 Local Closure

CLC_L

必要局部 component 是否達到自己的 required correctness。

24.2 Boundary Closure

CBC_B

重要 interaction / relation 是否成立。

24.3 Cross-Perspective Closure

CPC_P

不同觀察／責任投影的重大矛盾是否被處理。

24.4 Environment Closure

CEC_E

在真正目標環境、runtime、external system、human operation 下是否仍成立。

24.5 Intent Closure

CIC_I

整體是否完成原始任務意圖。

因此：

CL=1C_L=1

只代表第一層。

25. Partial Closure Vector

在真實工程中，不一定所有 closure 都是純布林值。

因此可以使用：

C=(cL,cB,cP,cE,cI),\mathbf C = ( c_L, c_B, c_P, c_E, c_I ),

其中：

ck∈[0,1].c_k\in[0,1].

例如：

C=(1.0,0.92,0.55,0.80,0.60).\mathbf C = ( 1.0, 0.92, 0.55, 0.80, 0.60 ).

這比單一：

92% complete

更有意義。

因為同樣的：

0.920.92

可能代表：

  • 局部 code 幾乎都完成；
  • 但 cross-role / environment 根本沒有 closure。

因此：

Scalar Completion Percentage\boxed{ \text{Scalar Completion Percentage} }

很容易隱藏 topology。

26. Minimum Macro Completion Certificate

本文提出一個概念性的 Macro Completion Certificate：

macro_completion:
  intent:
    id: checkout-v3
    status: aligned

  local:
    required_components: 12
    verified_components: 12

  boundaries:
    required_weighted: 9
    verified_weighted: 9
    unresolved: []

  perspectives:
    activated:
      - frontend
      - backend
      - ux
      - payment
      - operations
    material_conflicts: []

  environment:
    target: production-like
    runtime_replay: PASS
    external_dependencies: PASS

  remaining_obligations:
    blocking: []
    deferred:
      - optional animation polish

  claim:
    status: COMPLETE

它不是要求所有產品都使用 YAML。

而是說：

COMPLETE 應該有 topology-aware evidence，而不是只有一個字串。

27. AI 時代第一個放大器：局部 artifact 生成速度暴增

傳統工程中，局部施工本身很慢。

這形成天然節流：

Vlocal productionV_{\mathrm{local\ production}}

有限。

AI coding agent 讓：

Vlocal production↑↑.V_{\mathrm{local\ production}}\uparrow\uparrow.

因此一個 agent 很容易短時間產生：

  • frontend；
  • backend；
  • tests；
  • schema；
  • docs；
  • deployment；
  • migration。

表面上：

CLC_L

快速上升。

但若：

Vboundary verificationV_{\mathrm{boundary\ verification}}

沒有同步提高，會出現：

CL↑whileCB remains low.\boxed{ C_L\uparrow \quad\text{while}\quad C_B \text{ remains low}. }

這就是 AI-native integration debt 的一個來源。

28. AI 時代第二個放大器：同一模型可以扮演所有角色

傳統團隊中：

programmer
designer
artist
QA
security
operations

通常具有不同：

  • training；
  • responsibility；
  • tools；
  • incentives；
  • representations；
  • failure priors。

AI 時代可能變成：

same model
→ programmer persona
→ reviewer persona
→ QA persona
→ architect persona

表面上形成：

Nroles>1.N_{\mathrm{roles}}>1.

但 epistemic diversity 未必增加。

若：

O1≈O2≈⋯≈On,O_1\approx O_2\approx\cdots\approx O_n,

那麼：

Many Roles≠Many Perspectives.\boxed{ \text{Many Roles} \neq \text{Many Perspectives}. }

甚至可能出現：

∀i,Vi=1\forall i,\quad V_i=1

只是因為所有 verifier 共用：

  • 同一誤解；
  • 同一 specification；
  • 同一 context；
  • 同一 test fixture；
  • 同一 completion definition。

這將在 A08〈同質綠燈〉完整展開。

29. AI 時代第三個放大器：多模態能力存在，但沒有被呼叫

前沿 AI 可能同時具備：

  • code reasoning；
  • image understanding；
  • UI inspection；
  • document understanding；
  • logs / traces；
  • natural-language requirements reasoning。

但 coding workflow 可能只啟動：

Ocode+Otest.O_{\mathrm{code}} + O_{\mathrm{test}}.

所以：

Multimodal Capability Available≠Multimodal Evidence Acquired.\boxed{ \text{Multimodal Capability Available} \neq \text{Multimodal Evidence Acquired}. }

結果就是：

模型理論上看得懂 UI，實際工作流卻從頭到尾沒讓它看 UI。

此時「低級 UI 錯誤」未必表示：

Capabilityvision=0.Capability_{\mathrm{vision}}=0.

更可能：

Activationvision=0.Activation_{\mathrm{vision}}=0.

這將在 A07 與 Series B 的 resolution / APR routing 中完整形式化。

30. Homogeneous Green

本文先引入一個後續會獨立展開的概念：

Homogeneous Green

同質綠燈

若多個 verifier：

V1,V2,…,VnV_1,V_2,\ldots,V_n

實際共享高度相似的：

Projection,Specification,Evidence,ModelPrior,FailureModel,\text{Projection}, \text{Specification}, \text{Evidence}, \text{ModelPrior}, \text{FailureModel},

則：

V1=⋯=Vn=1V_1=\cdots=V_n=1

提供的獨立資訊量可能遠低於 verifier 數量。

概念上：

Ngreen≠Nindependent evidence.\boxed{ N_{\mathrm{green}} \neq N_{\mathrm{independent\ evidence}}. }

因此「三個 Agent 都同意」本身不是強證據。

31. Cross-Boundary Replay

對高重要度 path，本文建議不要只做 component test，而做：

Cross-Boundary Replay.\boxed{ \text{Cross-Boundary Replay}. }

例如：

User intent
→ UI action
→ client state
→ API
→ service
→ database
→ external provider
→ event
→ backend state
→ API refresh
→ UI visible outcome

並取得：

E0,E1,…,En.E_0,E_1,\ldots,E_n.

這與 APR 的 post-action independent observation 具有相同精神：

不要把「預期結果」直接寫成「已觀察結果」。

而是重新取得 machine / world evidence。

32. Boundary Witness

每一個高權重 boundary 最好存在至少一個正 witness：

wij+w^+_{ij}

證明：

合法交互確實能成功。

以及在適當情況下存在負 witness：

wij−w^-_{ij}

證明：

不合法交互會被拒絕或被發現。

因此：

BoundaryEvidence=PositiveWitness+NegativeWitness\boxed{ \text{BoundaryEvidence} = \text{PositiveWitness} + \text{NegativeWitness} }

可以比單純：

request returned 200

更能證明 semantic boundary。

33. Relation-Centric Failure Clustering

若 integration validation 發現大量錯誤，不應立刻逐 ticket 修。

先將 failure 依 relation class 聚類：

F→{Fschema,Ftiming,Fstate,Fauthority,Frepresentation,Fenvironment,Fsemantic}.F \rightarrow \{ F_{schema}, F_{timing}, F_{state}, F_{authority}, F_{representation}, F_{environment}, F_{semantic} \}.

若多個 symptom 指向同一 boundary：

b∗,b^\ast,

則優先修：

b∗b^\ast

而不是：

every downstream symptom.\text{every downstream symptom}.

這與作者既有的：

Maximum Local Precision+Minimum Global Disturbance\text{Maximum Local Precision} + \text{Minimum Global Disturbance}

以及 responsibility-layer diagnosis 相容。

34. 全域不是「所有東西都一起看」

本文必須避免一個反向錯誤。

既然：

Local≠Global,\text{Local}\neq\text{Global},

不代表：

Global=ReadEverything.\text{Global} = \text{ReadEverything}.

也不代表：

Global=AlwaysUseAllAgents.\text{Global} = \text{AlwaysUseAllAgents}.

更不代表：

Global=RunEveryTest.\text{Global} = \text{RunEveryTest}.

真正的全域是：

知道宏觀對象的必要結構、重要邊界、可用視角與當前未知。\boxed{ \text{知道宏觀對象的必要結構、重要邊界、可用視角與當前未知。} }

然後：

按風險與不確定性提高局部解析度.\text{按風險與不確定性提高局部解析度}.

所以：

GlobalAwareness+TargetedObservation\boxed{ \text{GlobalAwareness} + \text{TargetedObservation} }

優於：

UniformMaximumObservation.\text{UniformMaximumObservation}.

這就是本文與第二系列的橋。

35. Global-First 與本文的關係

Global-First Completion 已提出：

Global implementation
→ Global/integration validation
→ Root-cause clustering
→ Batched repair
→ Affected-area validation
→ Final relevant global validation

本文為這個方法補上一個更精確的理由。

全域第一版的價值不只在於：

Coverage↑.\text{Coverage}\uparrow.

更在於：

只有當足夠多的節點同時存在，真正的邊界與 relation failure 才會開始顯現。

若一直：

component A
→ polish
→ verify
→ polish
→ verify

在 component B 尚未存在時，很多：

eABe_{AB}

根本無法被觀察。

所以：

Global Instantiation\boxed{ \text{Global Instantiation} }

也是：

Boundary Discovery Mechanism.\boxed{ \text{Boundary Discovery Mechanism}. }

36. 宏觀個體與有效架構

作者既有的 Effective Architecture 理論主張：

Aeffective(t)=Ψ(Acode,Aruntime,Adata,Aops,Ahuman,Aexternal,Acompat)t.A_{\mathrm{effective}}(t) = \Psi( A_{\mathrm{code}}, A_{\mathrm{runtime}}, A_{\mathrm{data}}, A_{\mathrm{ops}}, A_{\mathrm{human}}, A_{\mathrm{external}}, A_{\mathrm{compat}} )_t.

這正好說明：

軟體的宏觀個體不是 source tree。

Source code 是：

Ocode(X).O_{\mathrm{code}}(X).

UI 是：

Ovisual(X).O_{\mathrm{visual}}(X).

runtime 是：

Oruntime(X).O_{\mathrm{runtime}}(X).

operation 是：

Oops(X).O_{\mathrm{ops}}(X).

真正的系統是：

X.X.

因此 A03 的 failure theory 與 Series B 的 macro-object methodology 形成直接接口：

A03: projection closure can fail globally\boxed{ \text{A03: projection closure can fail globally} } ⇓\Downarrow Series B: dynamically reconstruct sufficient macro-object resolution\boxed{ \text{Series B: dynamically reconstruct sufficient macro-object resolution} }

37. 反例：不是所有跨角色 disagreement 都值得保留

Productive Friction 不代表：

人越多越好。

也不代表：

每一個 role 都要否決一次。

如果兩個角色：

Oi≈OjO_i\approx O_j

且沒有新的：

  • evidence；
  • failure model；
  • authority；
  • observation modality；

則額外 review 可能只是：

Redundant Friction.\text{Redundant Friction}.

因此可定義概念性的 marginal perspective value：

MPV(Oj)=ΔU−+ΔFailureDetectionCost(Oj).MPV(O_j) = \frac{ \Delta U^{-} + \Delta FailureDetection }{ Cost(O_j) }.

其中：

ΔU−\Delta U^{-}

表示 uncertainty reduction。

如果：

MPV(Oj)≈0,MPV(O_j)\approx0,

則沒有理由只為「多一個角色」而多一輪 ceremony。

38. 反例：不是每一個局部缺陷都阻止宏觀完成

同樣：

LocalImperfection>0LocalImperfection>0

不代表：

Cmacro=0.C_{\mathrm{macro}}=0.

例如：

  • 非必要動畫可再 polish；
  • 文件 typo；
  • 不影響目標平台的 low-priority warning；
  • out-of-scope enhancement。

所以本文不主張：

CL=1C_L=1

必須意味：

zero defect.\text{zero defect}.

而是：

all critical in-scope local obligations closed.\boxed{ \text{all critical in-scope local obligations closed}. }

也就是 closure 仍需與：

Scope+Risk+Intent\text{Scope} + \text{Risk} + \text{Intent}

綁定。

39. 反例：跨邊界 closure 也不能自動證明意圖正確

即使：

CL=1,C_L=1, CB=1,C_B=1, CP=1,C_P=1, CE=1,C_E=1,

仍可能：

CI=0.C_I=0.

例如整個系統完美地實作：

password login。

但使用者真正要的是：

OAuth-only login。

因此 A03 不是 A01 的替代。

它只解決：

局部如何組成宏觀。

而最終仍需：

IntentClosure.\boxed{ \text{IntentClosure}. }

40. 典型 Failure Taxonomy

本文暫定將「局部正確與全域失敗」分成十類。

F1 — Interface Contract Failure

資料格式、欄位、version、ABI 不一致。

F2 — Behavioral Assumption Failure

schema 一致，但對行為的前提不同。

F3 — Temporal Boundary Failure

ordering、freshness、timeout、retry、eventual consistency 不一致。

F4 — Shared-State Divergence

各 subsystem 使用不同世界狀態。

F5 — Authority Boundary Failure

誰可以 proposal / execute / promote / commit 不一致。

F6 — Representation Failure

內部狀態正確，但外部呈現錯誤或不可理解。

F7 — Environment Failure

local / test 環境成立，目標環境不成立。

F8 — Human / Operational Boundary Failure

軟體流程與人類操作、SOP、support、handoff 不閉合。

F9 — Emergent Interaction Failure

單一 component 均正確，但 interaction topology 產生未預期結果。

F10 — Intent Boundary Failure

整合系統工作正常，但不是原始需求所要的宏觀行為。

41. 一個更完整的驗證拓撲

對 AI-native engineering，本文建議將驗證拓撲從：

unit tests
→ done

改成：

Local Closure
↓
Boundary Closure
↓
Cross-Perspective Contradiction Check
↓
Target-Environment Replay
↓
Intent Closure
↓
Completion

形式上：

CL→CB→CP→CE→CI.C_L \rightarrow C_B \rightarrow C_P \rightarrow C_E \rightarrow C_I.

注意這不是要求所有任務都用五個昂貴 pipeline。

低風險、小範圍任務可以將某些層：

trivially satisfied\text{trivially satisfied}

或：

not applicable.\text{not applicable}.

核心要求只是：

不能把未檢查的層偷偷壓成 PASS。

42. Verification Routing

令 failure hypothesis 為：

Hf.H_f.

系統應根據：

Domain(Hf)Domain(H_f)

路由 verifier。

例如：

code correctness
→ compiler / unit test

API integration
→ contract / integration test

visual layout
→ visual observation

interaction
→ UI replay

performance
→ profiler / benchmark

security
→ security validation

runtime consistency
→ trace / telemetry

user experience
→ human/user-oriented evaluation

因此：

One Universal Verifier\boxed{ \text{One Universal Verifier} }

不是理想。

而是：

Verifier chosen by failure domain.\boxed{ \text{Verifier chosen by failure domain}. }

43. 宏觀完成的停止條件

本文的目的不是製造無限驗證。

停止條件可以表示為：

Stop=CL∧CB∧CP∧CE∧CI∧¬Oblocking.\text{Stop} = C_L \land C_B \land C_P \land C_E \land C_I \land \neg O_{\mathrm{blocking}}.

其中：

OblockingO_{\mathrm{blocking}}

是尚未閉合的、可行動且在 scope 內的 blocking obligations。

如果：

  • critical boundaries 已閉合；
  • required perspectives 已覆蓋；
  • environment evidence 足夠；
  • intent 已對齊；
  • 其餘 findings 已被分類為 deferred / out-of-scope / nonblocking；

則應：

Stop.\boxed{ \text{Stop}. }

而不是：

再找一個 reviewer
→ 再找一個 hypothetical issue
→ 再增加一個 requirement

這將直接接入 A04 / A05。

44. 本文的核心命題

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

P1 — Projection Non-Identity

Oi(X)≠X.\boxed{ O_i(X)\neq X. }

角色、工具、模態看到的是宏觀個體的投影，不是完整宏觀個體。

P2 — Projection Closure Non-Implication

∀i,  Vi(Oi(X))=1⇏VG(X)=1.\boxed{ \forall i,\;V_i(O_i(X))=1 \nRightarrow V_G(X)=1. }

P3 — Relation-First Failure

V(vi)=V(vj)=1⇏V(eij)=1.\boxed{ V(v_i)=V(v_j)=1 \nRightarrow V(e_{ij})=1. }

P4 — Composition Requires Assumption Closure

Guaranteei=1⇏Assumptioni is satisfied.\boxed{ Guarantee_i=1 \nRightarrow Assumption_i\text{ is satisfied}. }

P5 — Boundary Is Multi-Domain

Boundary≠APIOnly.\boxed{ \text{Boundary} \neq \text{APIOnly}. }

它可以是 state、time、authority、representation、human、environment 或 intent。

P6 — Full-Stack Non-Globality

FullStack≠GlobalStack.\boxed{ \text{FullStack} \neq \text{GlobalStack}. }

P7 — Productive Friction

RedundantFriction↓∧EpistemicallyProductiveFriction↑\boxed{ RedundantFriction\downarrow \quad\land\quad EpistemicallyProductiveFriction\uparrow }

是比「所有摩擦都消失」更合理的目標。

P8 — Test Volume Non-Coverage

TestCount≠BoundaryCoverage.\boxed{ \text{TestCount} \neq \text{BoundaryCoverage}. }

P9 — Multi-Role Non-Diversity

ManyRoles≠ManyIndependentPerspectives.\boxed{ \text{ManyRoles} \neq \text{ManyIndependentPerspectives}. }

P10 — Available Modality Non-Activation

CapabilityAvailable≠ObservationActivated.\boxed{ \text{CapabilityAvailable} \neq \text{ObservationActivated}. }

P11 — Macro Completion Vector

Cmacro=CL∧CB∧CP∧CE∧CI.\boxed{ C_{\mathrm{macro}} = C_L \land C_B \land C_P \land C_E \land C_I. }

P12 — Globality Is Structured Awareness, Not Maximum Observation

Global=MacroAwareness+BoundaryAwareness+PerspectiveAwareness+TargetedResolution.\boxed{ \text{Global} = \text{MacroAwareness} + \text{BoundaryAwareness} + \text{PerspectiveAwareness} + \text{TargetedResolution}. }

而不是：

ReadEverything.\text{ReadEverything}.

45. 與 A01、A02、A04 的位置關係

A01 問：

為什麼 verifier 全綠，意圖仍可能沒有完成？

A02 問：

為什麼 SUCCESS / DONE 只能是一個帶 scope 的狀態聲明？

A03 問：

為什麼所有局部都可以正確，而組合後的宏觀產品仍然錯？

下一篇 A04 將問：

當 AI workflow 不斷 planning、review、verification 時，這些活動何時開始取代真正的任務進展？

因此前四篇形成：

Green Misalignment\text{Green Misalignment} ⇓\Downarrow Observable Success Separation\text{Observable Success Separation} ⇓\Downarrow Local Correctness / Global Failure\text{Local Correctness / Global Failure} ⇓\Downarrow Process Proxy Misalignment.\text{Process Proxy Misalignment}.

46. 與第二系列的橋

A03 是第一系列中最直接通往第二系列的一篇。

第一系列到此得出：

局部投影的完整成功，不能保證宏觀個體成功。\boxed{ \text{局部投影的完整成功，不能保證宏觀個體成功。} }

第二系列將反過來研究：

那麼 Agent 如何在有限 token、有限工具、有限感知成本下，維持對宏觀個體的足夠解析度？

因此：

Failure Theory→Observation Methodology.\boxed{ \text{Failure Theory} \rightarrow \text{Observation Methodology}. }

A03 給出：

Oi(X)≠X.O_i(X)\neq X.

Series B 將研究：

{Oi}→dynamic reconstruction of sufficient macro-object state.\boxed{ \{O_i\} \rightarrow \text{dynamic reconstruction of sufficient macro-object state}. }

這也是 APR、多模態、角色觀察算子與動態全域視角真正開始匯合的位置。

47. 結論

複雜產品最危險的工程幻覺之一，是：

每一個局部都過了，所以整體應該也過了。

這個推論在簡單、完全可組合的系統中可能成立；但在具有 state、timing、authority、external dependency、human interaction、multimodal representation 與 emergent behavior 的系統中，它通常需要額外條件。

因此：

Local Correctness≠Boundary Correctness≠Macro Correctness.\boxed{ \text{Local Correctness} \neq \text{Boundary Correctness} \neq \text{Macro Correctness}. }

真正的完成不能只問：

哪些 component 是綠的？

還必須問：

哪些重要 boundary 已經閉合？

哪些 perspective 仍可能看到不同的世界？

真正 target environment 是否已重放？

宏觀對象是否完成了原始意圖？

在 AI 時代，這個問題更加重要，因為 AI 可以極快地產生大量局部正確 artifact，也可以用同一模型快速模擬多個工程角色。若工作流只是增加 role label、review 次數與局部 verifier，而沒有真正擴張觀察投影與 boundary evidence，就可能產生大量：

Homogeneous Green.\boxed{ \text{Homogeneous Green}. }

因此本文留下的最終工程原則是：

Do not ask only whether every part is correct. Ask whether the relations that make the parts one product are correct.\boxed{ \textbf{Do not ask only whether every part is correct. Ask whether the relations that make the parts one product are correct.} }

中文即：

不要只問每個部分是否正確；要問那些使所有部分真正成為同一個產品的關係是否正確。

參考文獻

A. 外部研究與工程資料

  1. NASA. NASA Systems Engineering Handbook. 特別參見 Product Integration、Interface Management、Product Verification、Product Validation、Verification and Validation Plan、End-to-End Integration 等章節。
    https://www.nasa.gov/reference/system-engineering-handbook-appendix/
    https://www.nasa.gov/reference/5-2-product-integration/

  2. NASA. NPR 7123.1B — NASA Systems Engineering Processes and Requirements. Interface management、integration、verification / validation requirements.
    https://nodis3.gsfc.nasa.gov/displayAll.cfm?Internal_ID=N_PR_7123_001B_&page_name=ALL

  3. Binder, C., et al. (2020). A systematic map on verification and validation of emergent behavior in software engineering research. Future Generation Computer Systems, 112, 1010–1037.
    https://doi.org/10.1016/j.future.2020.06.049

  4. Mogul, J. C. (2006). Emergent (Mis)behavior vs. Complex Software Systems. ACM SIGOPS Operating Systems Review / EuroSys 2006.

  5. Fiadeiro, J. L., Maibaum, T. S. E. (1995). On the correctness of modular systems. Theoretical Computer Science, 140(1), 139–177.

  6. Cimatti, A., Demasi, R., & Tonetta, S. (2018). Tightening the contract refinements of a system architecture. Formal Methods in System Design, 52, 88–116.
    https://doi.org/10.1007/s10703-017-0312-9

  7. Inverardi, P., Wolf, A. L., & Yankelevich, D. (1995/1997 proceedings lineage). Checking assumptions in component dynamics at the architectural level. Coordination Languages and Models.

  8. Dong, J., Alencar, P., & Cowan, D. D. (2000). Ensuring structure and behavior correctness in design composition. Proceedings of the IEEE Conference and Workshop on Engineering of Computer-Based Systems.

B. Neo.K / EveMissLab 既有研究

  1. Neo.K. 〈綠燈錯置——AI 時代「通過驗證」不等於「完成意圖」的新型不對齊〉，2026.

  2. Neo.K. 〈表觀成功與實質完成的分離——從軟體表觀完好到 Agent 完成狀態語義〉，v0.2, 2026.

  3. Neo.K. 〈真正的系統在哪裡？宣告架構與有效架構的分離〉，《表觀完好系統》系列，2026.

  4. Neo.K. 〈從靜態 MSSP 到動態 MSSP：讓架構角色成為可觀察狀態〉，2026.

  5. Neo.K. Global Completion Theory: From Local-First Execution to Global-First Instantiation in the AI Era, 2026.

  6. Neo.K. Global-First Completion Skill v2.x, 2026.

  7. Neo.K. APR / Agentic Perception Runtime 系列與統一技術白皮書，2026.

  8. Neo.K. AI-Native Game Runtime Series 08 — MSSP × TDD × APR for Autonomous Game Agents, 2026.

  9. Neo.K. 〈MSSP 的對偶：全域擾動、局部責任與結構化失敗投影〉，GACEI-02, 2026.

End of A03 v0.2