程式底空間：從原始碼表徵到計算關係的存在層

Program Base Space: From Source-Code Representation to the Ontological Layer of Computational Relations

系列： 程式底空間與本體反演系列（Program Base Space and Ontology Inversion, PBSOI）
篇次： Paper 01
版本： v0.1
作者： Neo.K
機構： EveMissLab
日期： 2026-09-14
狀態： 理論基礎稿／可擴充研究版本

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

摘要

傳統程式工程通常以原始碼、抽象語法樹、中介表示、控制流程圖、可執行碼與執行軌跡描述程式。然而，這些表示之間長期存在一個未被充分區分的問題：哪一個是程式本身，哪一些只是對程式的表徵、投影、執行載體或觀測結果？

既有多重投影程式論已指出，文字原始碼不必被預設為程式的唯一權威本體；不同文字、圖、張量算子網路、格子介面、自然語言與世界狀態視圖，可以是同一計算本體的不同投影。本文進一步提出「程式底空間」（Program Base Space, PBS）概念，主張任何可實作程式都可以被視為建立在某個比其表面語法更低階、但又不必等同於硬體指令的關係承載域之上。該底空間包含可辨識的計算實體、關係、狀態、控制、資料依賴、效果、邊界與合法轉換；具體程式語言則對此底空間施加語法、型別、記憶體模型、作用域與執行模型等約束，生成可供人類、編譯器或執行環境操作的表徵。

本文提出程式底空間的形式模型，區分「表徵層」、「實作結構層」、「底空間層」與「執行實現層」，並定義由程式本體到原始碼的投影映射，以及由既存原始碼反向恢復可觀測程式本體的反演映射。本文特別強調，反演所得結構不等於完整本體，而是受限於可觀測性、語言動態性、執行環境與分析能力的近似。最後，本文提出可證偽條件與後續研究綱領：若不同語言實現同一功能時無法在任何合理正規化下收斂到共享關係結構，或若程式底空間不能比傳統 AST／CFG／IR 提供額外且可驗證的分析能力，則本理論的強版本應被否定或縮限。

本文的核心命題不是「程式可以畫成圖」，而是：

程式碼可能只是某個更深層計算關係空間的表面投影；若此命題成立，則程式理解、跨語言轉換、Bug 分析、功能分類與本體反演應可以在這個底空間上被統一描述。

關鍵詞

程式底空間、Program Base Space、程式本體、程式語義、本體反演、程式碼誘導語義圖、CISG、多重投影、語義圖、靜態分析、跨語言正規化、程式理解、後文本程式系統

一、問題的提出

1.1 原始碼究竟是不是程式

在傳統軟體工程中，一個程式經常首先以原始碼檔案的形式存在：

source files
→ parser
→ AST
→ IR
→ executable
→ runtime behavior

因此，人們很自然地把「程式」與「原始碼」近似等同。

但這種等同其實混合了至少四個不同問題：

程式如何被人類表達；
程式如何被編譯器理解；
程式實際包含哪些計算關係；
程式在特定環境中如何被執行。

若將這四者混為一談，就容易形成：

\text{Program} = \text{Source Code}

然而，更保守的關係應該是：

\text{Source Code} = \text{Program 的一種表徵}

或者：

C_L = \pi_L(P^\ast)

其中：

$P^\ast$ 表示某個程式的權威或理想計算本體；
$L$ 表示程式語言；
$\pi_L$ 表示由計算本體投影到語言 $L$ 的映射；
$C_L$ 表示以語言 $L$ 表達的原始碼。

這個式子並不要求 $P^\ast$ 是神秘或超驗的存在。它只表示：

在具體程式碼文字之外，我們可以區分「程式實際成立的計算關係」與「描述這些關係的文字形式」。

1.2 「投影非本體」之後的下一個問題

既有多重投影程式論已經建立：

\text{Text} ,\; \text{Graph} ,\; \text{Tensor Network} ,\; \text{Grid} ,\; \text{Natural Language} ,\; \text{Runtime View}

可以是同一計算結構的不同投影。

但若只停在「多重投影」，仍然存在一個尚未解決的方向性問題。

正向方向是：

P^\ast \xrightarrow{\pi_L} C_L

也就是：

給定某個權威計算結構，如何產生文字、圖形或其他投影？

本文研究的是逆向問題：

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

也就是：

給定已經存在的程式碼，我們能否反向恢復出它所實現的計算本體之可觀測部分？

這裡的 $\rho_L$ 稱為程式本體反演映射（Program Ontology Inversion Mapping）。

而 $\widehat{P^\ast}$ 不應被宣稱為完整的 $P^\ast$ 。較嚴謹的表示是：

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

此一限制將貫穿本文。

二、程式底空間的定義

2.1 底空間不是機器碼

「程式底空間」不等同於：

CPU 指令；
機器碼；
組合語言；
bytecode；
某一個編譯器 IR。

原因是這些仍然是特定載體或執行模型下的具體表示。

例如同一個「比較後分支」可以在：

Python bytecode；
JVM bytecode；
LLVM IR；
WASM；
x86；
ARM；

中具有不同表徵。

因此，本文定義的底空間不是最低階指令集合，而是：

足以承載程式中可辨識計算實體、關係、狀態、控制、資料依賴、效果與合法轉換的背景關係域。

2.2 基本形式

定義程式底空間：

B_{\mathrm{prog}} = ( V, E, \Theta, S, C, D, F, I, \Gamma )

其中：

$V$ ：程式實體與操作節點集合；
$E$ ：節點之間的關係集合；
$\Theta$ ：型別、分類與語義標記；
$S$ ：狀態與狀態區域；
$C$ ：控制關係；
$D$ ：資料依賴關係；
$F$ ：效果與外部作用；
$I$ ：接口與系統邊界；
$\Gamma$ ：合法性、約束、來源與證據結構。

這不是要求所有程式分析器都必須完整恢復上述全部項目，而是定義一個理論上的承載框架。

具體分析器只能得到：

\widehat{B}_{\mathrm{prog}} \subseteq B_{\mathrm{prog}}

2.3 節點與邊

最小節點集合可以寫為：

V = V_{\mathrm{entity}} \cup V_{\mathrm{operation}} \cup V_{\mathrm{control}} \cup V_{\mathrm{state}} \cup V_{\mathrm{effect}} \cup V_{\mathrm{boundary}}

其中：

V_{\mathrm{entity}}

可包含：

module；
class；
function；
method；
object；
value；
region。

而：

V_{\mathrm{operation}}

可包含：

arithmetic；
comparison；
allocation；
serialization；
hashing；
transformation；
query；
mutation。

關係集合則可包含：

E = E_{\mathrm{contain}} \cup E_{\mathrm{call}} \cup E_{\mathrm{control}} \cup E_{\mathrm{data}} \cup E_{\mathrm{state}} \cup E_{\mathrm{effect}} \cup E_{\mathrm{dependency}}

重要的是：

節點圖的價值不在於有多少節點，而在於每一種節點與每一種關係都具有明確語義與來源。

三、四層程式模型

本文提出至少區分四層。

3.1 表徵層

R_L

例如：

Python source；
Rust source；
Java source；
visual blocks；
natural-language DSL。

此層主要回答：

程式以什麼形式被表達？

3.2 實作結構層

G_C

此層由具體程式碼誘導產生，包括：

symbol；
call；
branch；
state mutation；
data dependency；
effect；
external boundary。

後續系列將把此層正式定義為：

\operatorname{CISG}(C_L)

即 Code-Induced Semantic Graph。

此層回答：

目前這份實作實際形成了什麼結構？

3.3 程式底空間層

B_{\mathrm{prog}}

這不是單一 repository 的某張圖，而是「哪些計算關係可以被合法表達、組合與變換」的承載域。

對某一具體程式 $P$ ，其結構可以視為：

G_P \hookrightarrow B_{\mathrm{prog}}

也就是某個局部實作結構嵌入底空間。

此層回答：

這份程式所使用的計算關係存在於什麼共同結構空間中？

3.4 執行實現層

G_R(t)

它依賴：

實際輸入；
執行時；
作業系統；
外部服務；
執行緒排程；
動態 dispatch；
runtime-generated state。

因此同一份程式：

G_C

可能對應多個執行實現：

G_R^{(1)}, G_R^{(2)}, \ldots, G_R^{(n)}

這也是為什麼靜態分析不能被誤稱為完整 runtime truth。

四、原始碼作為召喚、約束與投影介面

4.1 「召喚」不是神秘概念

若一段程式碼：

z = x + y

真正執行時並不是文字 "+" 本身產生加法。

文字只是指定：

對兩個對象施行某種由語言與型別系統所解析的加法操作。

因此：

\texttt{x + y}

可以被分解成：

\operatorname{Resolve}(+,\Theta_x,\Theta_y) \rightarrow \operatorname{Apply}(O_{+},x,y)

這表示程式碼具有一種「指定／召喚」性。

它指定某個操作：

O_{+}

在某個合法語義域中被實現。

因此，本文所稱「召喚」不是超自然意義，而是：

\boxed{ \text{Surface Symbol} \rightarrow \text{Resolved Computational Relation} }

4.2 意圖域與程式碼域

人類可能先有：

I

代表意圖。

之後經由設計、語言與工具轉換為：

I \rightarrow P^\ast \rightarrow C_L

而程式碼執行又產生：

C_L \rightarrow G_R \rightarrow \Delta W

因此更完整的鏈是：

I \rightarrow P^\ast \xrightarrow{\pi_L} C_L \rightarrow G_R \rightarrow \Delta W

其中：

\Delta W

表示世界狀態差分。

這裡可以看出：

程式碼既不是最初意圖，也不是最終世界變化，而是介於兩者之間的一種可執行約束介面。

五、程式本體反演

5.1 反演映射

定義：

\rho_L : C_L \rightarrow \widehat{G}_P

其中：

\widehat{G}_P

表示由程式碼反向恢復出的實作語義結構。

更完整可寫為：

\rho_L = \rho_{\mathrm{syntax}} \circ \rho_{\mathrm{name}} \circ \rho_{\mathrm{control}} \circ \rho_{\mathrm{data}} \circ \rho_{\mathrm{state}} \circ \rho_{\mathrm{effect}}

實際系統中不必真的按此順序實作，但這種分解有助於區分資訊來源。

5.2 反演不是還原作者心中的意圖

必須嚴格區分：

\text{Implemented Semantics} \neq \text{Author Intent}

例如：

if user.is_admin:
    ...

靜態分析可以觀察：

某個條件存在；
條件讀取 is_admin；
某一分支受此條件控制。

但它不能僅憑程式碼證明：

作者當初加入這段是因為某個具體資安事件。

因此反演的對象首先是：

P_{\mathrm{implemented}}

而不是：

P_{\mathrm{intended}}

此區分是整個理論可信度的必要條件。

5.3 可觀測性邊界

若程式包含：

reflection；
runtime code generation；
monkey patch；
dynamic import；
external configuration；
network response；
concurrency race；
native extension；
hidden state；

那麼：

\rho_L(C_L)

通常只能恢復部分結構。

因此定義反演完備度：

\kappa_{\rho} \in [0,1]

其中 $\kappa_{\rho}$ 並不必然可以精確量化，但概念上表示：

目前分析結果覆蓋了多少可被合理視為程式有效結構的資訊。

六、程式底空間與既有 AST、CFG、SSA、IR 的差異

6.1 不是取代既有表示

本文並不主張：

AST、CFG、SSA、IR 都不需要了。

相反地，這些是建構：

\widehat{B}_{\mathrm{prog}}

的重要觀測工具。

例如：

\text{AST} \rightarrow \text{語法與作用域結構}

\text{CFG} \rightarrow \text{控制可達關係}

\text{SSA} \rightarrow \text{資料版本與定義使用關係}

\text{Call Graph} \rightarrow \text{函式依賴}

\text{Effect Analysis} \rightarrow \text{外部作用與副作用}

程式底空間試圖做的是：

\boxed{ \text{將這些不同觀測放入同一個可比較的關係承載框架} }

6.2 IR 與底空間

IR 通常為編譯、最佳化或執行服務。

而程式底空間的用途更廣，包括：

程式理解；
跨語言對齊；
Bug 分析；
功能分類；
設計—實作偏差；
runtime 對照；
軟體知識記憶；
AI Agent 操作。

因此：

\text{IR} \subseteq \text{Program Representation}

但：

B_{\mathrm{prog}}

是一個更高層的理論承載域，不預設單一 compiler pipeline。

七、程式底空間的最小不變量

若要使不同表徵仍可被視為「同一程式」的不同投影，需要至少討論某些不變量。

本文提出候選集合：

\mathcal I_P = \{ I_{\mathrm{reach}}, I_{\mathrm{dependency}}, I_{\mathrm{state}}, I_{\mathrm{effect}}, I_{\mathrm{boundary}}, I_{\mathrm{contract}} \}

其中可能包括：

可達關係；
必要資料依賴；
核心狀態轉換；
必要效果；
系統邊界；
輸入輸出契約。

若兩份程式：

P_1,P_2

在某個分析語境 $\mathcal C$ 下滿足：

\mathcal I_P(P_1) = \mathcal I_P(P_2)

則可以定義：

P_1 \sim_{\mathcal C} P_2

但這不是宣稱兩者在所有語境下完全等價。

八、共通域底空間

8.1 問題

若 Python 與 Rust 實現同一個功能：

C_{\mathrm{py}}

與：

C_{\mathrm{rs}}

則可能有：

\rho_{\mathrm{py}}(C_{\mathrm{py}}) = G_{\mathrm{py}}

\rho_{\mathrm{rs}}(C_{\mathrm{rs}}) = G_{\mathrm{rs}}

如果存在某種 normalization：

N

使：

N(G_{\mathrm{py}}) \approx N(G_{\mathrm{rs}})

那麼可以推測存在某種共享結構域：

B_{\mathrm{common}}

8.2 共通不等於完全一致

不同語言仍然可能具有本質差異：

ownership；
lifetime；
garbage collection；
exception；
async model；
memory safety；
undefined behavior；
type system。

因此：

B_{\mathrm{common}}

不應被理解為：

所有語言最後都完全一樣。

而是：

B_{\mathrm{common}} = B_{\mathrm{shared}} + B_{\mathrm{language-specific}}

更準確地說：

B_L = B_{\mathrm{common}} \oplus B_L^{\mathrm{specific}}

其中：

B_L^{\mathrm{specific}}

保留語言自身不可消除的語義。

九、由底空間導出的分析能力

9.1 結構 Bug

若程式被轉換為：

G_C

則可以直接計算：

D(G_C)

來尋找：

unreachable node；
orphan dependency；
cycle；
impossible transition；
unresolved call；
contradictory state constraint；
missing boundary；
unsafe effect propagation。

這些分析不要求一般智能。

9.2 功能分類

若某些子圖：

G[S_i]

在多個專案中重複出現相似結構，可以定義功能 motif：

M_k

並比較：

G[S_i] \sim M_k

這為後續建立「程式功能基元庫」提供基礎。

9.3 專案全域分析

傳統 repository 管理首先顯示：

folders
files
classes
functions

程式底空間方法則可能首先顯示：

state regions
control regions
data flow
effects
dependencies
functional motifs
boundaries
execution paths

也就是將：

\text{File Tree}

改為：

\text{Program Relation Space}

作為第一視圖。

十、與空間狀態論的關係

空間狀態論可寫為：

\Sigma = ( B, X, x, \Theta, \Lambda, \mathcal H, \mathcal A, \mathcal I, \mathcal P )

在程式域中，可以建立對應：

B \rightarrow B_{\mathrm{prog}}

X \rightarrow \text{可行程式狀態域}

x \rightarrow \text{當前具體程式狀態}

\Theta \rightarrow \text{型別與語義分類}

\mathcal H \rightarrow \text{module/class/function/block 嵌套}

\mathcal A \rightarrow \text{合法程式操作}

\mathcal I \rightarrow \text{API / I/O / system boundary}

\mathcal P \rightarrow \text{source / graph / runtime projection}

因此程式底空間可以被視為空間狀態論在程式理解與程式本體上的一個具體專門化。

但本文不要求讀者接受整個空間狀態論，程式底空間模型仍可以獨立使用。

十一、初步實證：RepoLumen CISG PoC

本系列研究已完成一個初步實驗。

對 RepoLumen 的一組 Git blob SHA 驗證過的核心 Python 原始碼進行分析後，系統建立：

182

個 typed nodes，以及：

334

條 typed edges。

節點與關係包含：

module；
class；
function；
method；
control；
calls；
imports；
state writes；
effects；
contains。

此 PoC 的目的不是證明：

182

或：

334

具有普遍理論意義，而是證明：

一個 repository 可以不依賴人工架構描述，而直接由實際實作生成具有來源證據的關係圖。

此外，初步 mutation test 人工注入四種基本結構錯誤：

mutable default；
unreachable statement；
bare exception；
import cycle。

第一版 detector 對四類注入錯誤皆成功觸發。

因此至少支持一個弱命題：

\boxed{ \text{由程式碼抽取的結構圖，可以直接承載部分非智能化缺陷檢測} }

十二、核心命題

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

命題 1：表徵非本體命題

C_L \neq P^\ast

原始碼可以是高品質權威投影，但不應在理論上自動等同於完整程式本體。

命題 2：底空間承載命題

存在某種關係承載域：

B_{\mathrm{prog}}

使具體程式的可觀測計算結構可以嵌入其中。

命題 3：可部分反演命題

對大量非完全動態程式，存在：

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

使程式碼中的部分實作語義可以被系統性恢復。

命題 4：跨表徵不變量命題

不同表徵若實現同一計算功能，應存在至少部分可比較的不變結構：

\mathcal I_P

命題 5：結構分析命題

若：

G_C = \rho_L(C_L)

則部分 Bug、異常、依賴與功能模式可以直接轉化為：

\text{graph / constraint / state analysis}

問題。

命題 6：底空間非完備命題

任何有限反演器都不應被假設可以恢復完整程式本體：

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

除非另有形式證明。

十三、可證偽條件

本文不把程式底空間當成不可反駁的哲學命題。

至少存在以下可證偽方向。

13.1 跨語言不收斂

若大量功能等價的跨語言程式：

P_1,P_2,\ldots,P_n

在任何合理 normalization 下都無法找到可穩定比較的共同結構，則：

B_{\mathrm{common}}

的強版本需要被否定。

13.2 無新增分析價值

若程式底空間表示最終只是在重新包裝：

AST；
CFG；
SSA；
Call Graph；

卻不能提供：

更佳跨語言比較；
更佳全域理解；
新的 Bug 分析；
新的功能分類；
新的 project-level reasoning；

則本理論的工程必要性應被降低。

13.3 反演誤差不可控

若：

\rho_L

無法可靠區分：

\text{Observed}

與：

\text{Inferred}

甚至大量將推測誤當程式事實，則此方法不應被用作權威結構。

13.4 圖規模不可控制

若：

|V|+|E|

隨 repository 規模增長而產生不可接受的爆炸，且無法透過：

coarse-graining；
motif compression；
boundary summarization；
multi-resolution graph；

降低複雜度，則其實用性將受重大限制。

十四、後續研究路線

本系列接下來將研究：

Paper 02

建立：

\operatorname{CISG}

的正式 typed graph 模型與 provenance contract。

Paper 03

研究：

\rho_L

的本體反演方法、完備度、誤差與可觀測性。

Paper 04

研究：

B_{\mathrm{common}}

與跨語言正規化。

Paper 05

研究：

G \rightarrow \text{execution}

即脫離原始碼後的語義圖執行。

Paper 06

研究：

D(G_C)

的結構缺陷計算。

Paper 07

研究程式功能 motif 與程式功能基元庫。

Paper 08

研究：

G_I \leftrightarrow G_C \leftrightarrow G_R

的三圖一致性。

十五、結論

本文提出「程式底空間」概念，試圖在原始碼、程式結構、計算本體與執行實現之間建立一個更清楚的分層。

本文的主要主張可以濃縮為：

\boxed{ \text{Source Code} \neq \text{Program Ontology} }

以及：

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

前半段描述本體如何被投影為程式碼。

後半段描述如何從既存程式碼反向恢復其可觀測本體近似。

因此，程式研究可以從：

如何閱讀、編譯與執行程式碼？

進一步轉向：

程式碼背後究竟實現了什麼關係空間，而這個關係空間可以被恢復、比較、執行、驗證與重新投影到什麼程度？

若這個問題成立，則程式碼將不再只是開發工件，也會成為一種可以被反演的計算投影；程式理解則不再只是在文字上做解釋，而是對計算結構本身進行測量。

這正是本系列所稱的：

\boxed{ \text{Program Base Space and Ontology Inversion} }

亦即：

\boxed{ \text{程式底空間與本體反演} }

參考與前置理論

Neo.K，《從程式碼到意圖：程式概念的歷史轉換與後文本時代》。
Neo.K，《多重投影程式論：原始碼不再是程式本體》。
Neo.K，《程式語言設計風格的多軸形態空間》。
Neo.K，《基本計算單位的歷史轉換：從指令、函數到張量、意圖與世界狀態》。
Neo.K，《穩定核心與動態表面：自適應程式語言的分層設計》。
Neo.K，《空間狀態論：異質底空間、嵌套尺度與空間改寫算子的統一方法論》。
EveMissLab，RepoLumen / Repo Semantic Teaching Layer v0.10。
EveMissLab，CISG RepoLumen PoC v0.1。