程式本體反演：從可執行投影重建可觀測程式本體

Program Ontology Inversion: Reconstructing Observable Program Ontology from Executable Projections

系列： 程式底空間與本體反演系列（Program Base Space and Ontology Inversion, PBSOI）
篇次： Paper 03
版本： v0.1
作者： Neo.K
機構： EveMissLab
日期： 2026-09-14
狀態： 理論方法論初稿／反演框架定義

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

摘要

前兩篇分別提出「程式底空間」（Program Base Space, PBS）與「程式碼誘導語義圖」（Code-Induced Semantic Graph, CISG），建立了兩個前提：第一，原始碼不必等同於完整程式本體；第二，實際程式碼可以被轉換為具有型別、證據與不確定性標記的程式關係圖。本文進一步處理整個系列的核心逆問題：若程式碼是一種投影，我們究竟能從投影反向恢復多少程式本體？

本文正式提出「程式本體反演」（Program Ontology Inversion, POI），定義反演映射：

\rho_L : C_L \rightarrow \widehat{P^\ast}

其中 $C_L$ 是語言 $L$ 下的程式碼， $P^\ast$ 是理想或權威程式本體， $\widehat{P^\ast}$ 則是由分析器在有限觀測條件下重建出的本體近似。本文主張，程式本體反演不是反編譯、程式摘要或自然語言解說，而是一個受可觀測性、證據來源、分析模型與語言動態性限制的結構重建問題。

本文建立四類觀測來源：靜態觀測、動態觀測、歷史觀測與外部契約觀測；提出多通道反演模型、可觀測本體、不可識別等價類、反演覆蓋向量、反演誤差向量與證據格。本文指出：單一程式碼表面通常不能唯一決定完整程式本體，因此程式本體反演在一般情況下不是單值逆函數，而是一個受證據約束的候選本體收斂過程。

本文最後提出一個保守原則：反演系統的價值不在於「猜得像」，而在於能明確區分何者已觀測、何者被強推論、何者僅弱推論、何者仍不可判定。只有在此條件下，CISG、程式底空間、跨語言正規化、結構缺陷檢測、功能 motif 與三圖一致性分析才可能共享同一個可信的程式知識層。

本文的核心命題是：

程式本體反演不是把程式碼重新說明一次，而是把可觀測程式事實從特定語言表徵中解耦，重建成可驗證、可比較且保留未知性的結構。

關鍵詞

程式本體反演、Program Ontology Inversion、POI、程式底空間、CISG、可觀測性、不可識別性、靜態分析、動態分析、語義重建、反演誤差、證據融合、程式知識圖、程式理解

一、問題的提出

1.1 從正向投影到逆向問題

假設存在某個程式本體：

P^\ast

而一種程式語言 $L$ 提供投影：

\pi_L : P^\ast \rightarrow C_L

則程式碼 $C_L$ 可以被視為：

C_L = \pi_L(P^\ast)

前述模型首先帶來一個直接的逆問題：

\boxed{ \text{已知 } C_L,\text{ 能否恢復 } P^\ast? }

最直觀的寫法是：

\pi_L^{-1}(C_L)

但這個表示在一般情況下過強。

因為 $\pi_L$ 通常不是雙射。

不同的本體狀態可能投影成相同或近似相同的程式碼表面；同一份程式碼在不同 runtime、configuration、dependency version 與外部環境下，也可能形成不同實際行為。

因此本文不假設：

\rho_L = \pi_L^{-1}

而定義一個更保守的反演映射：

\rho_L : C_L \rightarrow \widehat{P^\ast}

其中：

\widehat{P^\ast}

只代表在目前觀測條件下可支持的本體近似。

1.2 反演問題的核心不是「能不能理解程式碼」

程式碼理解早已有：

parser；
compiler；
decompiler；
static analyzer；
debugger；
profiler；
symbolic execution；
abstract interpretation；
program slicing；
model checker；
reverse engineering。

因此，本文若只說「程式可以被分析」，沒有新的理論價值。

真正的問題是：

能否把這些彼此分散的分析結果重新視為對同一個潛在程式本體的不同觀測，並建立一個明確的反演框架？

因此，本文把問題改寫為：

\mathcal O = \{ O_s, O_d, O_h, O_c \}

其中：

$O_s$ ：static observation；
$O_d$ ：dynamic observation；
$O_h$ ：historical observation；
$O_c$ ：contract / environment observation。

反演不再只依賴單一 source：

\rho_L(C_L)

而可以寫為：

\rho ( O_s, O_d, O_h, O_c ) \rightarrow \widehat{P^\ast}

這使「程式理解」從單次解析問題，變成多觀測源的本體重建問題。

二、反演對象：到底要恢復什麼

2.1 三種不同的「程式」

本文首先區分：

P_{\mathrm{intended}}

P_{\mathrm{implemented}}

P_{\mathrm{realized}}

其中：

意圖程式

P_{\mathrm{intended}}

表示作者、團隊、需求或規格希望程式成為什麼。

實作程式

P_{\mathrm{implemented}}

表示現有 source／binary 所編碼出的結構。

實現程式

P_{\mathrm{realized}}

表示程式在具體環境與輸入下真正發生的行為。

一般而言：

P_{\mathrm{intended}} \neq P_{\mathrm{implemented}} \neq P_{\mathrm{realized}}

並不罕見。

因此，僅從 source code 進行反演時，合理目標首先是：

\widehat{P}_{\mathrm{implemented}}

而不是：

\widehat{P}_{\mathrm{intended}}

2.2 程式本體的工作定義

本文將一個工作性程式本體表示為：

P = ( V, R, S, T, F, B, K, H )

其中：

$V$ ：實體與操作；
$R$ ：關係；
$S$ ：狀態；
$T$ ：轉換規則；
$F$ ：效果；
$B$ ：內外部邊界；
$K$ ：約束與契約；
$H$ ：版本與歷史關係。

這不是宣稱所有程式哲學上都必須服從此八元組，而是提供一個可供反演系統操作的最小統一容器。

三、程式本體反演不是什麼

3.1 不是反編譯

反編譯常處理：

\text{Binary} \rightarrow \text{Higher-Level Code}

其目標通常是生成可讀或近似原始的程式表示。

POI 則是：

\text{Any Executable Projection} \rightarrow \text{Ontology Approximation}

因此：

\text{Decompiler Output}

可以成為 POI 的一種輸入，但不是最終目標。

3.2 不是程式摘要

摘要通常為：

C \rightarrow N

其中 $N$ 是自然語言。

POI 則要求：

C \rightarrow G

其中 $G$ 必須是：

可計算；
可追溯；
可比較；
保留未知；
可由其他投影再次使用。

自然語言可以由 $G$ 生成：

G \rightarrow N

但不應反過來以 $N$ 取代 $G$ 。

3.3 不是猜作者意圖

任何從程式碼直接推斷：

作者是為了效能才這樣寫。

若缺乏 commit、issue、spec 或其他證據，都不能被標記為 implementation fact。

因此：

\operatorname{IntentInference} \neq \operatorname{OntologyObservation}

四、四種觀測來源

4.1 靜態觀測

定義：

O_s(C)

可包含：

AST；
symbol table；
type relation；
CFG；
call graph；
data flow；
SSA；
alias / points-to；
effect hints；
dependency；
exception structure。

靜態觀測的優勢是：

可重現；
可批次；
不需要執行不可信程式；
可覆蓋未被測試走到的分支。

但它不能保證：

O_s = P_{\mathrm{realized}}

4.2 動態觀測

定義某次執行軌跡：

\tau_i = (e_1,e_2,\ldots,e_n)

多次執行得到：

O_d = \{\tau_1,\tau_2,\ldots,\tau_m\}

可以觀察：

真正發生的 call；
真正 branch；
concrete type；
allocation；
lock；
I/O；
latency；
exception；
runtime dispatch；
external boundary。

動態觀測的限制是：

\text{not observed} \not\Rightarrow \text{impossible}

也就是：

沒跑到，不等於不存在。

4.3 歷史觀測

定義 revision sequence：

H = (P_{r_1},P_{r_2},\ldots,P_{r_n})

歷史資訊可以補充：

某關係何時出現；
某節點是否穩定；
某功能是否被拆分；
某 boundary 是否逐步形成；
某 relation 是否只是短期過渡。

因此：

O_h

不是用 commit message 猜真相，而是比較：

G_C^{(r_i)} \rightarrow G_C^{(r_{i+1})}

的實際結構差分。

4.4 契約與環境觀測

定義：

O_c

可包括：

type contract；
API schema；
test assertion；
formal specification；
database schema；
protocol；
permission policy；
configuration constraints。

這些資訊有時比 source code 更直接描述：

K

即程式約束。

但契約同樣不能自動等同於實作事實。

因此：

O_c \neq O_s

而應保持為不同證據通道。

五、多通道反演模型

5.1 基本形式

定義：

\mathcal O(P) = ( O_s(P), O_d(P), O_h(P), O_c(P) )

反演系統：

\rho : \mathcal O(P) \rightarrow \widehat{P}

5.2 證據融合

對候選結構 $x$ ，定義證據集合：

E(x) = \{ e_s, e_d, e_h, e_c \}

其中可能有些為空。

例如：

e_s \neq \varnothing

但：

e_d = \varnothing

表示某 static edge 已被觀測，但目前沒有 runtime trace 支持或反駁。

因此不應寫成：

e_d=\varnothing \Rightarrow x=\text{false}

5.3 證據格

本文提出一個簡化的證據偏序：

\text{unresolved} \prec \text{weakly inferred} \prec \text{strongly inferred} \prec \text{observed}

但不同來源之間不是簡單線性排序。

例如：

\text{static observed}

與：

\text{dynamic observed}

支持的是不同命題。

更合理的是保存向量：

q(x) = ( q_s, q_d, q_h, q_c )

而不是壓成單一分數。

六、不可識別性

6.1 一般情況下反演不唯一

假設：

\pi_L(P_1) = \pi_L(P_2) = C

但：

P_1 \neq P_2

則由 $C$ 無法唯一判斷原始本體。

因此定義：

[P]_C = \{ P_i \mid \pi_L(P_i)=C \}

這是一個與觀測 $C$ 相容的本體候選等價類。

所以一般情況下：

\rho(C)

更合理的數學型態可能是：

\rho(C) \rightarrow \mathcal P(P)

也就是候選集合，而不是單一結果。

6.2 工程上為何仍可得到單一圖

實作系統仍然可以輸出：

\widehat{P}

但它應同時保存：

U

表示 unresolved / ambiguous structure。

所以：

\rho(C) = (\widehat{P},U)

而不是假裝：

U=\varnothing

6.3 不可識別不等於不可分析

這一點很重要。

即使：

P_1 \neq P_2

無法區分，仍可能存在共同部分：

I(P_1)=I(P_2)

因此反演的合理目標不是永遠恢復全部：

P^\ast

而是恢復所有候選都共同支持的：

P_{\mathrm{stable}}

可寫成：

P_{\mathrm{stable}} = \bigcap_{P_i\in[P]_C} I(P_i)

這提供一種保守本體重建方式。

七、反演完備度

7.1 單一百分比不足

若只給：

\kappa_\rho=0.82

其實很難知道到底缺什麼。

因此本文提出反演覆蓋向量：

K_\rho = ( k_V, k_R, k_S, k_T, k_F, k_B, k_K, k_H )

對應：

節點；
關係；
狀態；
轉換；
效果；
邊界；
契約；
歷史。

7.2 相對覆蓋率

若存在外部驗證集：

P_{\mathrm{ref}}

則可以定義：

k_R = \frac{ |R_{\mathrm{reconstructed}}\cap R_{\mathrm{ref}}| }{ |R_{\mathrm{ref}}| }

但現實中完整 $P_{\mathrm{ref}}$ 通常不存在。

因此實際工程更常只能計算：

supported coverage；
parser coverage；
trace coverage；
test coverage；
resolved-target ratio；
evidence-backed ratio。

也就是代理指標。

7.3 可觀測覆蓋與本體覆蓋必須分開

定義：

K_{\mathrm{obs}}

表示目前觀測工具能碰到的範圍。

而：

K_{\mathrm{ont}}

表示整個程式本體的真實覆蓋。

通常：

K_{\mathrm{obs}} \geq K_{\mathrm{ont}}

不能由已觀測部分直接推定整體本體已被完整覆蓋。

八、反演誤差

8.1 錯誤不只一種

定義反演誤差向量：

\varepsilon_\rho = ( \varepsilon_{\mathrm{miss}}, \varepsilon_{\mathrm{false}}, \varepsilon_{\mathrm{type}}, \varepsilon_{\mathrm{resolution}}, \varepsilon_{\mathrm{semantic}}, \varepsilon_{\mathrm{provenance}} )

分別表示：

漏掉真實節點／邊；
產生不存在的節點／邊；
型別錯誤；
target resolution 錯誤；
語義分類錯誤；
provenance 錯誤。

8.2 最危險的不是漏掉，而是捏造

對保守反演系統而言：

\varepsilon_{\mathrm{false}}

通常應比：

\varepsilon_{\mathrm{miss}}

受到更嚴格控制。

原因是：

漏掉一條邊會降低完備度；捏造一條邊則會污染後續所有依賴它的推理。

因此可以採用：

\lambda_{\mathrm{false}} > \lambda_{\mathrm{miss}}

的損失權重。

8.3 本體反演損失

概念上可定義：

\mathcal L_\rho = \lambda_1\varepsilon_{\mathrm{miss}} + \lambda_2\varepsilon_{\mathrm{false}} + \lambda_3\varepsilon_{\mathrm{resolution}} + \lambda_4\varepsilon_{\mathrm{semantic}} + \lambda_5\varepsilon_{\mathrm{provenance}}

此式目前是方法論形式，不主張已有統一最佳權重。

九、靜態—動態閉合

9.1 靜態圖

定義：

G_s = \rho_s(C)

由 static analysis 得到。

9.2 動態圖

對 trace：

\tau

建立：

G_d(\tau)

表示實際發生的執行關係。

9.3 疊合

可定義：

G_{sd} = G_s \oplus G_d

其中：

\oplus

不是簡單 union，而是帶來源標記的證據疊合。

例如某 static call edge：

e

在 runtime 被觀測：

q(e) = (\text{observed-static},\text{observed-dynamic})

另一條 static edge 尚未走到：

q(e') = (\text{observed-static},\text{not-yet-observed-dynamic})

不能將後者刪除。

十、歷史閉合

10.1 程式不是只有當前快照

若：

G_C^{(t)}

只是當前版本，則許多結構意義無法判斷。

例如一個孤立函式可能是：

剛加入尚未接線；
已廢棄但未刪除；
plugin entrypoint；
test-only utility。

歷史可以提供：

G_C^{(t-2)} \rightarrow G_C^{(t-1)} \rightarrow G_C^{(t)}

的變化脈絡。

10.2 時間型本體

因此程式本體可以進一步寫成：

P(t)

而歷史反演為：

\rho_H : \{C_{r_1},\ldots,C_{r_n}\} \rightarrow \widehat{P}(t)

此時「程式是什麼」不再只是某一 commit 的圖，而是：

\text{state} + \text{transition} + \text{history}

十一、來源權威與反演可信度

11.1 Source integrity

若來源本身不是已確認版本：

C?

則：

\rho(C?)

不能被標為 fully verified。

因此應先執行：

\operatorname{VerifySource} ( C, r, h )

其中：

$r$ ：revision；
$h$ ：hash。

11.2 Analyzer identity

相同 source 在不同 analyzer version 下可能得到：

G_1 \neq G_2

因此反演結果必須保存：

A_{\mathrm{id}} = ( \text{analyzer}, \text{version}, \text{config} )

這是可重現性的必要部分。

11.3 Graph identity

可以定義：

\operatorname{ID}(G) = H( r, A_{\mathrm{id}}, N(G) )

其中：

N(G)

表示 canonical serialization。

此機制可支援：

cache；
diff；
history；
reproducibility。

十二、CISG 在反演中的角色

Paper 02 定義：

G_C

作為程式碼誘導語義圖。

在本文中，CISG 不等於反演過程本身，而是：

\boxed{ \text{反演輸出的 canonical structural container} }

因此：

\rho(C) \rightarrow G_C

以及：

G_C \hookrightarrow \widehat{P^\ast}

兩者可以同時成立。

CISG 主要保存：

程式結構；
關係；
provenance；
uncertainty。

而更完整的本體近似還可能包括：

runtime statistics；
contracts；
historical persistence；
architecture intent；
environmental constraints。

十三、由反演導出的新問題

13.1 反演後能不能再投影

若：

C_L \xrightarrow{\rho_L} G

則可以研究：

G \xrightarrow{\pi_M} C_M

其中：

M

是另一種程式語言。

形成：

C_L \rightarrow G \rightarrow C_M

這將在後續跨語言論文處理。

13.2 反演後能不能直接執行

若 $G$ 已經保存足夠控制、資料與效果語義，則可以研究：

E(G)

而不必回到原始 source。

第一輪小型 PoC 已證實，在受限語義子集中：

C \rightarrow G \rightarrow \cancel{C} \rightarrow E(G)

可以成立。

13.3 反演後能不能找 Bug

若某些 Bug 對應：

\mathcal F \subseteq \operatorname{Subgraph}(G)

則可以建立：

D(G) \rightarrow \Delta

而不依賴自然語言理解。

十四、RepoLumen PoC 對反演問題的初步支持

前一輪 CISG PoC 對 RepoLumen 的 Git hash 驗證程式來源進行分析，得到：

182

個節點與：

334

條關係。

此實驗並未證明完整程式本體已被恢復。

它只支持：

\boxed{ \text{實際 repository 可被自動轉換為具有來源證據的結構近似。} }

此外，mutation test 對四類注入錯誤成功觸發 detector，支持：

\boxed{ \text{反演所得結構具有可直接計算的工程價值。} }

這兩點構成 POI 的最低工程基礎，但尚不足以證明跨語言本體收斂。

十五、最小反演管線

本文提出第一版 POI pipeline：

C \rightarrow V \rightarrow S \rightarrow R \rightarrow N \rightarrow G \rightarrow U

其中：

$V$ ：source verification；
$S$ ：syntax / symbol extraction；
$R$ ：relation reconstruction；
$N$ ：semantic normalization；
$G$ ：CISG construction；
$U$ ：uncertainty registration。

若加入 runtime：

G + O_d \rightarrow G'

若加入歷史：

G' + O_h \rightarrow G''

因此反演不是一次完成，而是可以持續收斂：

\widehat{P}^{(0)} \rightarrow \widehat{P}^{(1)} \rightarrow \cdots \rightarrow \widehat{P}^{(n)}

十六、反演單調性

一個理想反演系統加入新證據時，不應任意破壞舊的 verified fact。

定義證據集合：

E_1 \subseteq E_2

若：

x

已在 $E_1$ 下被 verified，且 $E_2$ 沒有反證，則期望：

x\in\rho(E_1) \Rightarrow x\in\rho(E_2)

這可以稱為證據單調性。

但若新證據產生矛盾：

e_{\mathrm{new}} \bot x

則系統應：

降級 confidence；
標記 conflict；
重新解析；

而不是靜默覆寫。

十七、反演與衝突

17.1 靜態與動態衝突

例如 static analysis 推出：

A\rightarrow B

但大量 runtime trace 顯示該 target 永遠被其他 dispatch 取代。

此時不應簡單刪掉 static edge。

應保存：

\operatorname{Conflict} ( e_s, e_d )

17.2 文件與實作衝突

若 README 宣稱：

A\nrightarrow B

但 source 顯示：

A\rightarrow B

則：

\text{AuthorClaim} \neq \text{ImplementationObservation}

兩者都應保存，但優先權不能混同。

十八、反演的 epistemic contract

本文建議 POI 系統至少輸出：

\mathcal K_{\rho} = ( F, I, U, C )

其中：

$F$ ：verified facts；
$I$ ：inferences；
$U$ ：unresolved；
$C$ ：conflicts。

所以一個成熟反演器不是只回答：

這個程式是什麼？

而應回答：

我能證明它具有什麼結構、我強烈推論什麼、我仍不知道什麼、哪些證據互相衝突。

十九、可證偽條件

19.1 無法區分 observed 與 inferred

若系統不能可靠區分：

F

與：

I

則其反演結果不適合作為權威程式知識層。

19.2 新證據無法改善結果

若加入：

runtime trace；
history；
contracts；

後：

\widehat{P}^{(n+1)}

無法比：

\widehat{P}^{(n)}

增加解析能力或降低不確定性，則多通道反演模型缺乏實證價值。

19.3 跨工具結果無法對齊

若不同 analyzer 對同一 source 產生的結果無法映射到共同 typed relation space，則 POI 作為統一層的可行性會受到重大限制。

19.4 反演只等價於既有單一 IR

若完整 POI 最終沒有超出某一現有 IR 的能力範圍，也無法額外整合 evidence、history、runtime 與 uncertainty，則「本體反演」不需要作為獨立工程概念存在。

二十、核心命題

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

命題 1：反演非逆函數命題

一般情況下：

\rho_L \neq \pi_L^{-1}

因為程式投影通常不可唯一逆。

命題 2：部分反演命題

合理目標是：

\rho_L(C_L) = \widehat{P^\ast}

其中：

\widehat{P^\ast} \subseteq \operatorname{Observable}(P^\ast)

命題 3：多觀測源命題

更完整反演應使用：

\rho ( O_s, O_d, O_h, O_c )

而非只依賴 source syntax。

命題 4：不可識別命題

存在：

P_1\neq P_2

但：

\pi_L(P_1)=\pi_L(P_2)

因此反演必須保留候選與未知。

命題 5：保守錯誤命題

對可信反演系統：

\varepsilon_{\mathrm{false}}

通常比：

\varepsilon_{\mathrm{miss}}

更危險。

命題 6：證據分層命題

\text{Observed} \neq \text{Inferred} \neq \text{Claimed} \neq \text{Unresolved}

必須在資料模型層顯式存在。

命題 7：持續收斂命題

反演可以隨證據增加形成：

\widehat{P}^{(0)} \rightarrow \widehat{P}^{(1)} \rightarrow \cdots \rightarrow \widehat{P}^{(n)}

而不是一次性輸出。

命題 8：可再投影命題

若反演結果保存足夠語義，則理論上可以研究：

C_L \rightarrow \widehat{P} \rightarrow C_M

使反演結構成為跨語言轉換與新型程式編譯的中介基礎。

二十一、研究路線

Paper 04 將處理：

B_{\mathrm{common}}

與跨語言語義正規化。

核心問題是：

Python、Rust、C、Java、WASM 或其他表示經反演後，哪些結構可以收斂到共同底空間，哪些差異必須保留為 language-specific semantics？

因此：

\rho_L

在 Paper 03 被建立後，下一步自然是研究不同：

\rho_{L_1}, \rho_{L_2}, \ldots, \rho_{L_n}

是否能共同落入：

B_{\mathrm{common}}

二十二、結論

本文正式提出「程式本體反演」作為一個獨立研究問題。

它不是：

\text{Code} \rightarrow \text{Explanation}

而是：

\boxed{ \text{Executable Projection} \rightarrow \text{Evidence-Grounded Observable Ontology} }

其核心關係為：

P^\ast \xrightarrow{\pi_L} C_L \xrightarrow{\rho_L} \widehat{P^\ast}

但：

\rho_L \neq \pi_L^{-1}

而：

\widehat{P^\ast} \neq P^\ast

在一般情況下都必須被明確承認。

程式本體反演真正追求的不是「完全猜中」，而是：

\boxed{ \text{最大化可驗證恢復} + \text{最小化虛構關係} + \text{顯式保存未知} }

因此，反演器的核心品質不應只以輸出多少資訊評估，而應以：

可追溯性；
可重現性；
誤差；
覆蓋；
不確定性誠實度；
跨來源一致性；

共同評估。

在此基礎上，程式碼才真正可以從「唯一主要工件」轉化為「可被觀測、反演與重新投影的計算表面」。

而程式理解則進一步轉化為：

\boxed{ \text{對程式存在結構本身的測量問題} }

參考與前置理論

Neo.K，《程式底空間：從原始碼表徵到計算關係的存在層》，PBSOI Paper 01。
Neo.K，《程式碼誘導語義圖：由實作生成而非由設計繪製的程式節點圖》，PBSOI Paper 02。
Neo.K，《從程式碼到意圖：程式概念的歷史轉換與後文本時代》。
Neo.K，《多重投影程式論：原始碼不再是程式本體》。
Neo.K，《程式語言設計風格的多軸形態空間》。
Neo.K，《基本計算單位的歷史轉換：從指令、函數到張量、意圖與世界狀態》。
Neo.K，《空間狀態論：異質底空間、嵌套尺度與空間改寫算子的統一方法論》。
EveMissLab，RepoLumen / Repo Semantic Teaching Layer v0.10。
EveMissLab，CISG RepoLumen PoC v0.1。