← Archive
lm-004718 · 2026-10

三圖一致性：意圖、實作與執行之間的全域程式驗證

zh-Hant · md Raw source ↗ Metadata ↗
下載 MD 檔 ⬇
📎 附件 · Companion files — 隨文交付的程式 / 證明 / 資料，可獨立下載重驗

三圖一致性：意圖、實作與執行之間的全域程式驗證

Tri-Graph Consistency: Global Program Verification Across Intent, Implementation, and Runtime Realization

系列： 程式底空間與本體反演系列（Program Base Space and Ontology Inversion, PBSOI）
篇次： Paper 08
版本： v0.1
作者： Neo.K
機構： EveMissLab
日期： 2026-09-14
狀態： 系列收束稿／全域一致性框架初稿

公司： 一言諾科技有限公司

摘要

前七篇 PBSOI 論文已分別建立程式底空間、程式碼誘導語義圖（CISG）、程式本體反演、共通程式底空間、可執行語義圖、結構缺陷計算，以及程式功能基元與計算 motif。這些工作共同處理了一個核心問題：程式碼是否只是程式本體的一種投影，以及我們能否從既存程式碼反向恢復其可觀測計算結構。

然而，僅恢復實作結構仍不足以回答最終的工程問題：程式實際做出的事情，是否符合原本要做的事情？ 一個程式可以在語法、型別、靜態結構與單元測試上全部合法，卻仍可能偏離需求；也可能靜態結構正確，但因 runtime dispatch、外部狀態、並行、配置或環境差異而產生不同實際行為。

本文提出「三圖一致性」（Tri-Graph Consistency, TGC）框架，正式區分：

GI=Intent / Design GraphG_I = \text{Intent / Design Graph} GC=Code-Induced Semantic GraphG_C = \text{Code-Induced Semantic Graph} GR=Runtime Realization GraphG_R = \text{Runtime Realization Graph}

並研究三種核心差異：

ΔIC=d(GI,GC)\Delta_{IC} = d(G_I,G_C) ΔCR=d(GC,GR)\Delta_{CR} = d(G_C,G_R) ΔIR=d(GI,GR)\Delta_{IR} = d(G_I,G_R)

其中 ΔIC\Delta_{IC} 表示意圖—實作偏差， ΔCR\Delta_{CR} 表示實作—執行偏差，而 ΔIR\Delta_{IR} 則表示最終意圖與實際世界行為之間的偏差。

本文進一步引入 Paper 07 的功能 motif 圖：

GMG_M

作為高階意圖與低階實作之間的中介層，形成：

GI↔GM↔GC↔GRG_I \leftrightarrow G_M \leftrightarrow G_C \leftrightarrow G_R

此四層表示並不改變三圖一致性的核心，而是提供一個可實作的多解析度對齊方法。本文提出跨層 correspondence、required relation、forbidden relation、runtime witness、missing implementation、hidden implementation、runtime drift、contract violation、effect deviation 與世界狀態差分等概念，並建立局部一致性、功能一致性、全域一致性與時間一致性四種驗證層級。

本文亦提出「閉環驗證」：

I→GI→GC→GR→ΔW→V→I′I \rightarrow G_I \rightarrow G_C \rightarrow G_R \rightarrow \Delta W \rightarrow V \rightarrow I'

其中 ΔW\Delta W 是程式對世界造成的狀態差分， VV 是驗證與回饋。此模型將舊有「從程式碼到意圖」的正向意圖鏈，與本系列的反向本體反演鏈閉合成同一個可觀測循環。

本文的核心命題是：

程式正確性不應只被理解為「程式碼本身沒有錯」，而應被理解為意圖、實作與真實執行之間，在明確語境與證據下保持足夠一致。

關鍵詞

三圖一致性、Tri-Graph Consistency、TGC、意圖圖、CISG、Runtime Graph、全域程式驗證、架構漂移、需求偏差、執行偏差、程式本體、世界狀態差分、功能 Motif、Program Verification

一、問題的提出

1.1 「程式沒有 Bug」仍然可能是錯的

假設一個程式：

  • 可以編譯；
  • 型別正確；
  • 沒有 import cycle；
  • 單元測試通過；
  • 沒有靜態分析警告。

仍然可能：

完全不是使用者要的東西。

因此：

Implementation Correctness⇏Intent Correctness\text{Implementation Correctness} \not\Rightarrow \text{Intent Correctness}

另一種情況是：

  • source 看起來正確；
  • static graph 也正確；
  • runtime 卻因 configuration 或 dynamic dispatch 走到不同路徑。

因此：

Static Correctness⇏Runtime Correctness\text{Static Correctness} \not\Rightarrow \text{Runtime Correctness}

1.2 正確性其實至少跨越三個世界

本文區分：

意圖世界

GIG_I

描述：

系統應該做什麼？

實作世界

GCG_C

描述：

程式碼實際實現了什麼？

執行世界

GRG_R

描述：

在具體輸入與環境下，系統實際發生了什麼？

所以程式驗證不能只研究：

GCG_C

而應研究：

GI↔GC↔GR\boxed{ G_I \leftrightarrow G_C \leftrightarrow G_R }

二、三張圖的正式定義

2.1 意圖／設計圖

定義：

GI=(VI,EI,KI,PI,QI)G_I = ( V_I, E_I, K_I, P_I, Q_I )

其中：

  • VIV_I：需求、功能、模組、角色、狀態與邊界；
  • EIE_I：required / forbidden / depends / flows / owns 等關係；
  • KIK_I：契約與不變量；
  • PIP_I：優先級與政策；
  • QIQ_I：不確定性、來源與權威層級。

意圖圖不必完全由自然語言建立。

它可以來自：

  • requirements；
  • architecture spec；
  • formal contract；
  • API schema；
  • state machine；
  • user story；
  • human-approved AI plan。

2.2 程式碼誘導語義圖

Paper 02 已定義：

GC=(VC,EC,TC,AC,QC,ΓC)G_C = ( V_C, E_C, T_C, A_C, Q_C, \Gamma_C )

其權威來源是：

Implementation\text{Implementation}

而不是：

Design Claim\text{Design Claim}

2.3 Runtime Realization Graph

定義某次執行：

GR(τ)=(VR,ER,SR,FR,TR,ΓR)G_R^{(\tau)} = ( V_R, E_R, S_R, F_R, T_R, \Gamma_R )

其中：

  • VRV_R：實際出現的 runtime entity / operation；
  • ERE_R：實際 call、data、state、effect relation；
  • SRS_R：runtime state；
  • FRF_R：外部效果；
  • TRT_R：時間與 happens-before；
  • ΓR\Gamma_R：trace evidence。

多次執行形成：

GR={GR(τ1),…,GR(τn)}\mathcal G_R = \{ G_R^{(\tau_1)}, \ldots, G_R^{(\tau_n)} \}

三、為什麼需要 Motif 中介層

3.1 意圖粒度與實作粒度不一致

意圖可能只有：

使用者登入後檢查權限。

但實作可能包含：

10310^3

個低階 operation。

因此直接比較：

GIG_I

與：

GCG_C

容易產生：

Granularity Mismatch\text{Granularity Mismatch}

3.2 功能圖

Paper 07 定義 motif collapse：

HM:GC→GMH_M : G_C \rightarrow G_M

其中：

GMG_M

是由實作機械抽取出的功能結構圖。

因此可以比較：

GI↔GMG_I \leftrightarrow G_M

再往下：

GM↔GCG_M \leftrightarrow G_C

3.3 四層表示

因此工程上可以使用：

GI↔GM↔GC↔GR\boxed{ G_I \leftrightarrow G_M \leftrightarrow G_C \leftrightarrow G_R }

但理論核心仍然是：

GI,GC,GRG_I , G_C , G_R

三個本體層級的一致性。

四、跨圖對應關係

4.1 Correspondence

定義：

μAB:VA→P(VB)\mu_{AB} : V_A \rightarrow \mathcal P(V_B)

表示圖 AA 中一個節點可以對應到圖 BB 中一組節點。

這很重要，因為：

1:11:1

通常不成立。

4.2 One-to-Many

意圖節點：

vI=Authenticate Userv_I = \text{Authenticate User}

可能對應：

μIC(vI)={v1,v2,…,v37}\mu_{IC}(v_I) = \{ v_1,v_2,\ldots,v_{37} \}

4.3 Many-to-One

多個低階 runtime event 也可能 collapse 成一個：

vMv_M

4.4 Correspondence 必須有證據

不能只寫：

我覺得這 37 個函式就是 authentication。

應保存：

E(μ)E(\mu)

例如：

  • motif match；
  • design mapping；
  • test relation；
  • runtime trace；
  • author approval。

五、意圖—實作偏差

5.1 定義

ΔIC=dC(GI,GC)\Delta_{IC} = d_{\mathcal C} ( G_I, G_C )

其中：

C\mathcal C

是比較語境。

5.2 Missing Implementation

若：

vIv_I

是 required：

Required⁡(vI)\operatorname{Required}(v_I)

但：

μIC(vI)=∅\mu_{IC}(v_I) = \varnothing

則：

δmissing\delta_{\mathrm{missing}}

成立。

5.3 Hidden Implementation

若：

vCv_C

無任何對應意圖：

μCI(vC)=∅\mu_{CI}(v_C) = \varnothing

不能立刻稱 Bug。

它可能是：

  • infrastructure；
  • generated support；
  • undocumented feature；
  • technical debt；
  • malicious logic；
  • accidental coupling。

因此先標記：

UnmappedImplementation⁡\operatorname{UnmappedImplementation}

5.4 Forbidden Implementation

若：

GIG_I

明確包含：

A↛BA \not\rightarrow B

但：

GCG_C

存在：

A→BA \rightarrow B

則可形成 verified architecture violation。

六、實作—執行偏差

6.1 定義

ΔCR=dC(GC,GR)\Delta_{CR} = d_{\mathcal C} ( G_C, G_R )

6.2 Static Edge 未被觀測

若：

e∈GCe\in G_C

但：

e∉GRe\notin G_R

不能推出：

ee

不存在。

只能說：

NotObserved⁡(e)\operatorname{NotObserved}(e)

6.3 Runtime Unexpected Edge

若：

eRe_R

出現在 runtime：

eR∈GRe_R\in G_R

但：

eR∉GCe_R\notin G_C

則可能代表：

  • dynamic dispatch；
  • reflection；
  • generated code；
  • native extension；
  • instrumentation gap；
  • static-analysis miss。

6.4 Runtime Drift

若原本：

GR(t1)G_R^{(t_1)}

與：

GR(t2)G_R^{(t_2)}

在相同主要輸入條件下顯著不同：

d(GR(t1),GR(t2))>ϵd( G_R^{(t_1)}, G_R^{(t_2)} ) > \epsilon

可以形成 runtime drift candidate。

七、意圖—執行偏差

7.1 最終重要差異

ΔIR=dC(GI,GR)\Delta_{IR} = d_{\mathcal C} ( G_I, G_R )

這個差異其實比：

ΔIC\Delta_{IC}

更接近使用者真正關心的問題：

最後世界發生的事情是不是我要的？

7.2 Source 正確但 Runtime 錯

即使：

ΔIC≈0\Delta_{IC} \approx0

仍可能：

ΔIR≫0\Delta_{IR}\gg0

例如：

  • database config 錯誤；
  • external API 回傳不同；
  • permission environment 不同；
  • race condition；
  • stale cache。

7.3 Intent 正確但 Implementation 不完整

也可能：

ΔIC≫0\Delta_{IC}\gg0

但某些測試場景：

ΔIR≈0\Delta_{IR}\approx0

因為 runtime 尚未觸發缺失路徑。

因此只看 test pass 不足以證明完整意圖已實現。

八、三種差異的組合

定義：

Δ=(ΔIC,ΔCR,ΔIR)\Delta = ( \Delta_{IC}, \Delta_{CR}, \Delta_{IR} )

這比單一：

Correct / Incorrect\text{Correct / Incorrect}

更有資訊量。

8.1 Case A

ΔIC≈0\Delta_{IC}\approx0 ΔCR≈0\Delta_{CR}\approx0 ΔIR≈0\Delta_{IR}\approx0

代表在目前語境下高度一致。

8.2 Case B

ΔIC≫0\Delta_{IC}\gg0

但：

ΔCR≈0\Delta_{CR}\approx0

表示實作忠實執行了自己，但偏離設計。

8.3 Case C

ΔIC≈0\Delta_{IC}\approx0

但：

ΔCR≫0\Delta_{CR}\gg0

表示設計與 source 對齊，但 runtime 偏離 source model。

8.4 Case D

ΔIR≫0\Delta_{IR}\gg0

表示最終結果偏離意圖，不論中間哪一層造成。

九、局部一致性

9.1 Local Region

對子圖：

S⊆GS \subseteq G

可以做：

Consistency⁡(SI,SC,SR)\operatorname{Consistency}(S_I,S_C,S_R)

9.2 局部先於全域

大型專案不應一開始要求：

GI≅GC≅GRG_I \cong G_C \cong G_R

因為三張圖粒度本來不同。

更合理的是先建立：

μ\mu

再比較對應區域。

十、功能一致性

10.1 Motif-Level Alignment

若：

MIM_I

代表設計功能：

cache fallback

而實作抽取：

MCM_C

則比較：

MI↔MCM_I \leftrightarrow M_C

比比較所有 low-level nodes 更合理。

10.2 Runtime Motif

也可以從：

GRG_R

抽：

MRM_R

形成：

MI↔MC↔MRM_I \leftrightarrow M_C \leftrightarrow M_R

十一、全域一致性

11.1 Composition

如果 project 由：

M1,…,MnM_1,\ldots,M_n

組成，可以研究：

GM=M1∘M2∘⋯∘MnG_M = M_1 \circ M_2 \circ \cdots \circ M_n

11.2 Global Constraints

例如：

∀Mauth,Mauth≺Mprotected−resource\forall M_{\mathrm{auth}} , \quad M_{\mathrm{auth}} \prec M_{\mathrm{protected-resource}}

表示任何 protected resource 前都必須經 auth。

11.3 全域不是所有細節一次展開

全域分析可以使用：

coarse graph+selective refinement\text{coarse graph} + \text{selective refinement}

而不是把百萬節點一次載入。

十二、時間一致性

12.1 三圖都會變

對 revision / time：

GI(t)G_I(t) GC(t)G_C(t) GR(t)G_R(t)

都可能演化。

12.2 Design Lag

可能：

GC(t+1)G_C(t+1)

已改變，但：

GI(t)G_I(t)

尚未更新。

12.3 Runtime Lag

deploy 後可能：

GR(t)G_R(t)

仍執行舊版本。

因此：

VersionAlignment⁡\operatorname{VersionAlignment}

本身就是一致性前置條件。

十三、版本身份

比較前必須確認：

rI,rC,rRr_I, r_C, r_R

的版本關係。

若 runtime 執行：

rC1r_{C1}

卻拿：

rC2r_{C2}

的 CISG 比較，則：

ΔCR\Delta_{CR}

沒有意義。

13.1 Deployment Identity

可保存：

DR=(commit,artifact hash,config hash,dependency lock,runtime version)D_R = ( \text{commit}, \text{artifact hash}, \text{config hash}, \text{dependency lock}, \text{runtime version} )

十四、契約作為跨圖錨點

14.1 Contract

定義：

K=(P,Q,F,E)K = ( P, Q, F, E )

其中：

  • PP：precondition；
  • QQ：postcondition；
  • FF：allowed effects；
  • EE：error semantics。

14.2 Intent Contract

KIK_I

描述希望行為。

14.3 Implementation Contract

KCK_C

由型別、code、schema 等恢復。

14.4 Runtime Contract Observation

KRK_R

由 trace / assertion / monitor 觀測。

14.5 Contract Consistency

研究：

KI↔KC↔KRK_I \leftrightarrow K_C \leftrightarrow K_R

是三圖一致性的高價值子問題。

十五、效果一致性

程式最終會對外界產生：

FF

因此需要比較：

FIF_I FCF_C FRF_R

15.1 Forbidden Effect

若意圖禁止：

NetworkWrite⁡\operatorname{NetworkWrite}

而 runtime 出現：

FR∋NetworkWrite⁡F_R \ni \operatorname{NetworkWrite}

則是強 violation。

15.2 Missing Effect

若意圖要求：

Persist⁡\operatorname{Persist}

但 runtime 未發生：

FR∌Persist⁡F_R \not\ni \operatorname{Persist}

在足夠 coverage 下可形成缺陷。

十六、世界狀態差分

16.1 最終程式作用

程式的最終結果可以表示為：

Wt→Wt+1W_t \rightarrow W_{t+1}

因此：

ΔW=Wt+1−Wt\Delta W = W_{t+1} - W_t

16.2 Intent World Delta

定義：

ΔWI\Delta W_I

表示期望世界變化。

16.3 Runtime World Delta

ΔWR\Delta W_R

表示實際變化。

16.4 最終一致性

dW(ΔWI,ΔWR)d_W ( \Delta W_I, \Delta W_R )

其實是：

ΔIR\Delta_{IR}

的一種世界狀態表示。

十七、閉環程式模型

前述舊理論可寫為：

I→K→R→A→V→ΔW→FI \rightarrow K \rightarrow R \rightarrow A \rightarrow V \rightarrow \Delta W \rightarrow F

本文將本體反演插入，形成：

I→GI→C→GC→GR→ΔW→V→I′\boxed{ I \rightarrow G_I \rightarrow C \rightarrow G_C \rightarrow G_R \rightarrow \Delta W \rightarrow V \rightarrow I' }

17.1 驗證回饋

若：

ΔWR≠ΔWI\Delta W_R \neq \Delta W_I

則：

VV

產生偏差資訊。

17.2 意圖更新

有時不是 code 錯，而是原本意圖需要修正。

因此：

I→I′I \rightarrow I'

也是合法結果。

十八、一致性不是完全相等

三圖不可能要求：

GI=GC=GRG_I = G_C = G_R

因為：

  • 粒度不同；
  • 來源不同；
  • 時間尺度不同；
  • 目的不同。

因此更合理的是：

GI≡CGCG_I \equiv_{\mathcal C} G_C

以及：

GC≡CGRG_C \equiv_{\mathcal C} G_R

18.1 Equivalence Contract

語境：

C\mathcal C

必須聲明：

  • 保留什麼；
  • 忽略什麼；
  • tolerance；
  • time window；
  • effect scope。

十九、一致性向量

不建議輸出單一：

S=0.93S=0.93

本文定義：

S=(Sfunction,Scontrol,Sdata,Sstate,Seffect,Scontract,Sboundary,Stemporal)\mathbf S = ( S_{\mathrm{function}}, S_{\mathrm{control}}, S_{\mathrm{data}}, S_{\mathrm{state}}, S_{\mathrm{effect}}, S_{\mathrm{contract}}, S_{\mathrm{boundary}}, S_{\mathrm{temporal}} )

19.1 功能一致性

SfunctionS_{\mathrm{function}}

衡量 required motif 的對齊。

19.2 狀態一致性

SstateS_{\mathrm{state}}

衡量 state transition。

19.3 效果一致性

SeffectS_{\mathrm{effect}}

衡量 world-facing effects。

二十、Hard Constraint 與 Soft Constraint

20.1 Hard

例如：

Never send plaintext password\text{Never send plaintext password}

應表示：

KHK_H

不可違反。

20.2 Soft

例如：

優先低 latency。

表示：

KSK_S

可用 objective / preference 表示。

20.3 不可混同

Soft deviation：

⇏Bug\not\Rightarrow \text{Bug}

Hard violation 才可能直接形成 defect。

二十一、三圖一致性與 SDC

Paper 06：

D(GC,K)→ΔD(G_C,K) \rightarrow \Delta

本文擴展為：

D(GI,GC,GR,K)→ΔglobalD( G_I, G_C, G_R, K ) \rightarrow \Delta_{\mathrm{global}}

21.1 新缺陷型別

包括：

  • missing implementation；
  • hidden implementation；
  • runtime-only behavior；
  • intent-unrealized；
  • effect drift；
  • contract drift；
  • deployment mismatch。

二十二、三圖一致性與 PFPL

Paper 07 的：

PFPLPFPL

可以提供跨層語義錨點。

例如意圖：

有 cache fallback。

可以映射：

vI→Mcache−fallbackv_I \rightarrow M_{\mathrm{cache-fallback}}

再匹配：

GCG_C

與：

GRG_R

中的對應 motif。

二十三、設計圖如何建立

23.1 不要求全部人工

GIG_I

可以由：

  • human design；
  • natural language；
  • formal spec；
  • existing docs；
  • AI extraction；

共同建立。

23.2 Author Claim 不等於 Verified Intent

若 README 說：

系統沒有外部網路。

應標：

author-claimed\text{author-claimed}

除非經權威設計契約確認。

23.3 Intent Provenance

每個：

vIv_I

與：

eIe_I

也應具有：

ΓI\Gamma_I

二十四、Runtime Graph 的抽樣問題

24.1 Trace 不完備

即使：

10001000

次執行都沒走某 edge，也不能證明 edge 不可能。

24.2 Coverage

定義：

CRC_R

表示 runtime observation coverage。

24.3 Negative Evidence

只有在：

  • exhaustive state space；
  • bounded proof；
  • formal model checking；

等條件下，absence 才可能升格為強 negative evidence。

二十五、Counterfactual Consistency

25.1 不只驗證已發生

可以問：

若輸入不同，意圖與實作是否仍一致？

25.2 Counterfactual

定義：

do⁡(X=x′)\operatorname{do}(X=x')

並比較：

GIdo⁡(x′)G_I^{\operatorname{do}(x')}

與：

GCdo(x′)G_C^{do(x')}

或 ESG simulation：

GEdo(x′)G_E^{do(x')}

25.3 Pre-Deployment Verification

這使三圖一致性不必等 runtime 真出事後才檢查。

二十六、局部閉合與全域閉合

26.1 Local Closure

對某功能 motif：

MM

要求：

MI↔MC↔MRM_I \leftrightarrow M_C \leftrightarrow M_R

26.2 Boundary Closure

再檢查：

BMB_M

與外界接口。

26.3 Global Closure

當所有 critical motif 與 boundary 都閉合後，才宣稱：

GlobalConsistency⁡\operatorname{GlobalConsistency}

達到指定 threshold。

二十七、一致性證書

27.1 Certificate

可以生成：

Cert⁡C=(r,S,Δ,E,U)\operatorname{Cert}_{\mathcal C} = ( r, \mathbf S, \Delta, E, U )

其中：

  • rr：版本；
  • S\mathbf S：一致性向量；
  • Δ\Delta：已知偏差；
  • EE：證據；
  • UU：未知。

27.2 證書不是絕對正確證明

除非使用完整形式證明，否則應寫：

在語境 C\mathcal C 、版本 rr 、coverage cc 下的一致性證書。

二十八、持續一致性監測

28.1 每次 Commit

對：

GC(r)→GC(r+1)G_C^{(r)} \rightarrow G_C^{(r+1)}

重新計算局部：

ΔIC\Delta_{IC}

28.2 每次 Deploy

對：

GR(d)G_R^{(d)}

計算：

ΔCR\Delta_{CR}

28.3 只重算受影響區域

利用 change impact：

Impact⁡(ΔG)\operatorname{Impact}(\Delta G)

不必每次全域重算。

二十九、三圖 Diff

可以定義：

Diff⁡IC\operatorname{Diff}_{IC} Diff⁡CR\operatorname{Diff}_{CR} Diff⁡IR\operatorname{Diff}_{IR}

29.1 Diff Object

每個差異保存：

δ=(type,source,target,severity,evidence,status)\delta = ( \text{type}, \text{source}, \text{target}, \text{severity}, \text{evidence}, \text{status} )

三十、優先級

不是所有：

Δ\Delta

都同等重要。

可定義：

R(δ)=f(hardness,impact,reachability,effect,confidence)R(\delta) = f( \text{hardness}, \text{impact}, \text{reachability}, \text{effect}, \text{confidence} )

但：

R(δ)R(\delta)

是修復優先級，不是 truth score。

三十一、AI 在三圖一致性中的位置

31.1 AI 適合做對應候選

例如：

vI→{vC1,vC2,vC3}v_I \rightarrow \{v_{C1},v_{C2},v_{C3}\}

AI 可以提出候選。

31.2 但不能偷升格

候選：

μ∗\mu^\ast

必須經：

  • motif；
  • evidence；
  • tests；
  • human approval；
  • formal rule；

才能升格。

31.3 AI 適合做差異解釋

對：

δIC\delta_{IC}

AI 可翻譯：

設計要求權限檢查發生在資料讀取前，但實作圖顯示某一路徑可以先讀取再檢查。

這比讓 AI 從頭猜 Bug 更可靠。

三十二、自動修復閉環

建立：

δ→R→GC′→D→Reverify⁡\delta \rightarrow R \rightarrow G_C' \rightarrow D \rightarrow \operatorname{Reverify}

其中：

RR

是 repair operator。

32.1 Minimal Disturbance

修復應最小化：

Disturbance⁡(GC,GC′)\operatorname{Disturbance} ( G_C, G_C' )

subject to：

δ∉Δ(GC′)\delta \notin \Delta(G_C')

32.2 Intent Preservation

還需：

GC′≡CGIG_C' \equiv_{\mathcal C} G_I

避免只修掉 local bug 卻破壞意圖。

三十三、三圖一致性與 Agentic Development

未來 AI Agent 可以不再只接收：

幫我改這個檔案。

而接收：

I′I'

然後：

I′→ΔGII' \rightarrow \Delta G_I

再推導：

ΔGC\Delta G_C

並預測：

ΔGR\Delta G_R

33.1 Change Before Code

此時變更的第一級工件可以變成：

ΔG\Delta G

而程式碼是：

πL(ΔG)\pi_L(\Delta G)

的一種輸出。

三十四、三圖一致性與多重投影程式論

舊多重投影程式論建立：

P∗→{π1,π2,…,πn}P^\ast \rightarrow \{ \pi_1, \pi_2,\ldots,\pi_n \}

PBSOI 則建立：

CL→ρLP∗^C_L \xrightarrow{\rho_L} \widehat{P^\ast}

本文再建立：

P∗^↔Pintended↔Prealized\widehat{P^\ast} \leftrightarrow P_{\mathrm{intended}} \leftrightarrow P_{\mathrm{realized}}

因此形成完整對偶：

Projection+Inversion+Consistency\boxed{ \text{Projection} + \text{Inversion} + \text{Consistency} }

三十五、與空間狀態論的閉合

若：

Σt=(B,X,x,Θ,Λ,H,A,I,P)\Sigma_t = ( B, X, x, \Theta, \Lambda, \mathcal H, \mathcal A, \mathcal I, \mathcal P )

則程式：

GCG_C

可以被理解為對允許轉換：

A\mathcal A

與結構：

H\mathcal H

的可觀測實作。

而：

GRG_R

則是真正發生的：

Φ:Σt→Σt+1\Phi: \Sigma_t \rightarrow \Sigma_{t+1}

所以三圖一致性的最終問題可以寫成：

意圖允許的空間轉換≈?實作編碼的空間轉換≈?實際發生的空間轉換\boxed{ \text{意圖允許的空間轉換} \stackrel{?}{\approx} \text{實作編碼的空間轉換} \stackrel{?}{\approx} \text{實際發生的空間轉換} }

三十六、可證偽條件

36.1 無法建立穩定跨圖 Correspondence

若：

μIC\mu_{IC}

與：

μCR\mu_{CR}

只能依賴自由文字猜測，無法以 motif、contract 或 evidence 穩定建立，則 TGC 的工程可行性會大幅降低。

36.2 三圖粒度無法合理對齊

若意圖與實作永遠只能在過度粗粒化下比較，則：

ΔIC\Delta_{IC}

資訊價值有限。

36.3 Runtime Graph 不可可信觀測

若 tracing 本身嚴重改變 runtime、coverage 太低或 artifact identity 不可靠，則：

ΔCR\Delta_{CR}

不可作強結論。

36.4 一致性分數無法預測真實偏差

若：

S\mathbf S

很高但實際 intent failures 仍大量出現，則一致性指標需要重新設計。

36.5 只產生更多文件

若 TGC 最後只是自動生成：

  • 架構摘要；
  • 差異報告；
  • 彩色圖；

卻不能支持：

  • deterministic violation；
  • targeted testing；
  • change impact；
  • runtime verification；
  • repair closure；

則它不應被宣稱為新的 verification layer。

三十七、核心命題

本文提出以下十二個核心命題。

命題 1：三圖分離命題

GI≠GC≠GRG_I \neq G_C \neq G_R

三者是不同證據來源與本體層。

命題 2：一致性非相等命題

Consistency≠Graph Equality\text{Consistency} \neq \text{Graph Equality}

而是語境化等價與約束保持。

命題 3：三差異命題

核心偏差為：

ΔIC,ΔCR,ΔIR\Delta_{IC}, \Delta_{CR}, \Delta_{IR}

命題 4：功能中介命題

GMG_M

可以作為：

GIG_I

與：

GCG_C

之間的可機械抽象層。

命題 5：Intent Correctness 命題

Code Correct⇏Intent Correct\text{Code Correct} \not\Rightarrow \text{Intent Correct}

命題 6：Runtime Correctness 命題

Static Correct⇏Runtime Correct\text{Static Correct} \not\Rightarrow \text{Runtime Correct}

命題 7：世界差分命題

最終一致性可投影為：

ΔWI↔ΔWR\Delta W_I \leftrightarrow \Delta W_R

命題 8：版本對齊命題

沒有：

VersionAlignment⁡\operatorname{VersionAlignment}

就沒有可信的跨圖比較。

命題 9：Unknown Preservation 命題

未觀測 runtime path、未解析 implementation 或模糊 intent 都必須保留為 unknown，而不是被補成一致。

命題 10：持續驗證命題

一致性不是 release 前一次檢查，而可以隨：

commit,deploy,runtime\text{commit} , \text{deploy} , \text{runtime}

持續更新。

命題 11：修復閉環命題

有效修復應同時滿足：

FixDefect⁡\operatorname{FixDefect}

與：

PreserveIntent⁡\operatorname{PreserveIntent}

命題 12：全域程式驗證命題

程式驗證可以從：

Code-Local Verification\text{Code-Local Verification}

擴展為：

Intent↔Implementation↔Runtime↔World State\boxed{ \text{Intent} \leftrightarrow \text{Implementation} \leftrightarrow \text{Runtime} \leftrightarrow \text{World State} }

的全域一致性問題。

三十八、PBSOI 系列總結

至此，八篇論文形成完整鏈。

Paper 01：程式底空間

BprogB_{\mathrm{prog}}

回答：

程式碼底下是否存在可共同描述的計算關係承載域？

Paper 02：CISG

C→GCC \rightarrow G_C

回答：

如何從實際程式碼生成真正由實作誘導的節點圖？

Paper 03：程式本體反演

CL→ρLP∗^C_L \xrightarrow{\rho_L} \widehat{P^\ast}

回答：

從投影可以恢復多少本體？

Paper 04：共通程式底空間

GL→NLBcommon⊕BLspecificG_L \xrightarrow{N_L} B_{\mathrm{common}} \oplus B_L^{\mathrm{specific}}

回答：

不同程式語言共享多少共同語義？

Paper 05：可執行語義圖

C→GE→C→E(GE)C \rightarrow G_E \rightarrow \cancel C \rightarrow E(G_E)

回答：

反演結構能不能脫離 source 直接執行？

Paper 06：結構缺陷計算

GC→DΔG_C \xrightarrow{D} \Delta

回答：

哪些 Bug 可以轉成圖與約束問題？

Paper 07：功能 Motif

GC→HMGMG_C \xrightarrow{H_M} G_M

回答：

哪些合法結構可以形成程式功能語彙？

Paper 08：三圖一致性

GI↔GC↔GRG_I \leftrightarrow G_C \leftrightarrow G_R

回答：

程式最後是否真的做了它原本應該做的事？

三十九、系列總體模型

八篇合併後，可以寫成：

I→GI→P∗→πLCL→ρLGC→NLG∗I \rightarrow G_I \rightarrow P^\ast \xrightarrow{\pi_L} C_L \xrightarrow{\rho_L} G_C \xrightarrow{N_L} G^\ast

再：

G∗→{GM,GE,Δ}G^\ast \rightarrow \{ G_M, G_E, \Delta \}

並執行：

GE→GR→ΔWG_E \rightarrow G_R \rightarrow \Delta W

最後驗證：

GI↔GM↔GC↔GR↔ΔWG_I \leftrightarrow G_M \leftrightarrow G_C \leftrightarrow G_R \leftrightarrow \Delta W

形成閉環。

四十、從程式碼中心到程式本體中心

傳統工程經常是：

Code→Compile→Run\boxed{ \text{Code} \rightarrow \text{Compile} \rightarrow \text{Run} }

PBSOI 提出的研究方向則是：

Intent→Ontology→Projection→Inversion→Verification→Execution→World Feedback\boxed{ \text{Intent} \rightarrow \text{Ontology} \rightarrow \text{Projection} \rightarrow \text{Inversion} \rightarrow \text{Verification} \rightarrow \text{Execution} \rightarrow \text{World Feedback} }

這不是否定程式碼。

而是把程式碼從：

中心本體\text{中心本體}

重新定位為：

可執行、可編輯、可交換，但可被反演的程式投影\boxed{ \text{可執行、可編輯、可交換，但可被反演的程式投影} }

四十一、未來研究綱領

PBSOI 完成理論第一輪後，後續至少包含：

  1. CISG v1 typed schema；
  2. SSA / data-flow / state-region 擴充；
  3. cross-language CPBS benchmark；
  4. ESG stateful runtime；
  5. deterministic detector library；
  6. PFPL motif corpus；
  7. intent graph schema；
  8. runtime trace overlay；
  9. tri-graph consistency engine；
  10. source ↔ graph ↔ source reprojection；
  11. formal equivalence subset；
  12. repository-scale coarse-graining。

四十二、結論

本文以「三圖一致性」收束 PBSOI 系列。

整個系列最初由一個簡單問題出發：

分析程式的程式，能不能把現有程式真正拆成節點圖？

但這個問題進一步展開後，形成：

Source Code→Semantic Structure→Program Base Space\text{Source Code} \rightarrow \text{Semantic Structure} \rightarrow \text{Program Base Space}

再進一步形成：

Ontology Inversion,Cross-Language Convergence,Executable Graph,Defect Computation,Functional Motifs\text{Ontology Inversion} , \text{Cross-Language Convergence} , \text{Executable Graph} , \text{Defect Computation} , \text{Functional Motifs}

最終回到真正的工程核心：

程式實際做的事情，是否符合原本想讓它做的事情？\boxed{ \text{程式實際做的事情，是否符合原本想讓它做的事情？} }

這個問題不能只由：

GCG_C

回答。

必須同時觀察：

GIG_I

與：

GRG_R

因此本文的最終模型是：

GI↔GC↔GR\boxed{ G_I \leftrightarrow G_C \leftrightarrow G_R }

工程上再加入功能中介：

GI↔GM↔GC↔GR\boxed{ G_I \leftrightarrow G_M \leftrightarrow G_C \leftrightarrow G_R }

最終再連接世界：

GR→ΔWG_R \rightarrow \Delta W

於是程式驗證不再只是：

這段程式碼是否正確？

而變成：

意圖、實作、執行與世界狀態變化是否在明確語境、版本、證據與不確定性條件下保持一致？

這使 PBSOI 最終形成一個完整閉環：

Projection→Inversion→Normalization→Execution→Verification→Reprojection\boxed{ \text{Projection} \rightarrow \text{Inversion} \rightarrow \text{Normalization} \rightarrow \text{Execution} \rightarrow \text{Verification} \rightarrow \text{Reprojection} }

程式碼仍然存在，但它不再是唯一能代表程式的東西。

真正被逐步推到中心的，是：

可被觀測、反演、比較、驗證、執行與重新投影的程式本體結構\boxed{ \text{可被觀測、反演、比較、驗證、執行與重新投影的程式本體結構} }

參考與前置理論

  1. Neo.K，《程式底空間：從原始碼表徵到計算關係的存在層》，PBSOI Paper 01。
  2. Neo.K，《程式碼誘導語義圖：由實作生成而非由設計繪製的程式節點圖》，PBSOI Paper 02。
  3. Neo.K，《程式本體反演：從可執行投影重建可觀測程式本體》，PBSOI Paper 03。
  4. Neo.K，《共通程式底空間：跨語言語義正規化與表徵收斂》，PBSOI Paper 04。
  5. Neo.K，《可執行語義圖：脫離原始碼後的程式重建與再執行》，PBSOI Paper 05。
  6. Neo.K，《結構缺陷計算：以程式語義圖進行非智能化 Bug 與異常偵測》，PBSOI Paper 06。
  7. Neo.K，《程式功能基元與結構型分類：從功能命名到計算 Motif》，PBSOI Paper 07。
  8. Neo.K，《多重投影程式論：原始碼不再是程式本體》。
  9. Neo.K，《從程式碼到意圖：程式概念的歷史轉換與後文本時代》。
  10. Neo.K，《程式語言設計風格的多軸形態空間》。
  11. Neo.K，《基本計算單位的歷史轉換：從指令、函數到張量、意圖與世界狀態》。
  12. Neo.K，《空間狀態論：異質底空間、嵌套尺度與空間改寫算子的統一方法論》。
  13. EveMissLab，RepoLumen / Repo Semantic Teaching Layer v0.10。
  14. EveMissLab，Semantic Graph PoC v0.1。
  15. EveMissLab，CISG RepoLumen PoC v0.1。