# 程式碼誘導語義圖：由實作生成而非由設計繪製的程式節點圖

**Code-Induced Semantic Graph: A Program Graph Derived from Implementation Rather Than Design**

**系列：** 程式底空間與本體反演系列（Program Base Space and Ontology Inversion, PBSOI）  
**篇次：** Paper 02  
**版本：** v0.1  
**作者：** Neo.K  
**機構：** EveMissLab  
**日期：** 2026-09-14  
**狀態：** 理論與工程規格初稿

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

---

## 摘要

軟體工程長期使用架構圖、模組圖、控制流程圖、呼叫圖、資料流程圖與依賴圖描述程式結構。然而，這些圖多半具有單一目的，而且其中相當一部分來自設計者、維護者或工具對程式的局部描述。它們可以非常有用，卻不必然等於「目前程式實際上形成的全域結構」。

本文提出「程式碼誘導語義圖」（Code-Induced Semantic Graph, CISG），將其定義為：**直接由可驗證程式實作、靜態分析結果、必要時加上執行觀測所誘導出的具型別、多關係、可追溯程式圖。** CISG 不把 repository 的檔案樹、人工架構說明或自然語言文件視為其權威本體，而要求每一個節點與關係都具有明確的來源證據、解析狀態、語義類型與信心層級。

本文區分意圖／設計圖 $G_I$ 、程式碼誘導語義圖 $G_C$ 與執行實現圖 $G_R$，並主張 CISG 的主要功能不是提供另一張視覺化圖，而是將「目前程式實際實現了什麼」轉換成可供演算法直接操作的結構層。本文提出 CISG 的 typed graph 模型、證據契約、未知邊界原則、解析度模型、局部與全域一致性要求，以及從 repository 建構 CISG 的參考流程。本文亦說明 CISG 如何成為程式底空間反演、結構缺陷檢測、功能 motif、跨語言正規化、變更影響分析與三圖一致性研究的共同中介層。

本文的核心主張是：

> **架構圖描述「我們認為系統應如何組織」；CISG 描述「目前可由實際程式證據支持的系統結構」。**

---

## 關鍵詞

CISG、Code-Induced Semantic Graph、程式碼誘導語義圖、程式節點圖、程式底空間、靜態分析、程式本體反演、語義圖、程式理解、證據圖、全域程式分析、架構漂移、RepoLumen

---

# 一、問題的提出

## 1.1 軟體已有很多圖，為什麼還需要 CISG

現代軟體工程並不缺少圖。

常見表示包括：

- architecture diagram；
- module dependency graph；
- call graph；
- control-flow graph；
- data-flow graph；
- class diagram；
- package graph；
- state machine；
- deployment graph；
- execution trace。

因此，若 CISG 只是將以上內容重新畫在同一張圖上，它沒有足夠的新意。

CISG 的差異不在於「圖」本身，而在於**來源與權威性**。

傳統人工架構圖通常具有：

$$
G_{\mathrm{arch}}
=
f(\text{設計文件},\text{維護者理解},\text{抽象需求})
$$

而 CISG 要求：

$$
G_C
=
\rho(C)
$$

其中：

- $C$：實際存在的程式實作；
- $\rho$：可追溯分析與反演程序；
- $G_C$：由實作誘導出的語義圖。

因此：

$$
\boxed{
\text{CISG 不是先畫圖再對程式做解釋，而是先分析程式，再讓圖由程式證據生成。}
}
$$

---

## 1.2 設計真相與實作真相

在理想專案中：

$$
G_I
\approx
G_C
$$

其中：

- $G_I$：設計者或需求所宣稱的結構；
- $G_C$：實作實際形成的結構。

但大型專案長期演化後常出現：

$$
G_I
\neq
G_C
$$

例如：

- 文件宣稱 A 模組不依賴 B，實際上已經存在隱性呼叫；
- 設計宣稱某服務是 leaf，實際上它已形成新的 orchestration role；
- 原本只允許單向依賴，實作卻累積出 cycle；
- 某功能已被移除，但其 dead path 仍存在；
- 某邊界理論上應封閉，實作中卻有跨層 effect。

因此，若要分析：

$$
\Delta_{IC}
=
d(G_I,G_C)
$$

首先必須有一個不依賴 $G_I$ 的實作圖。

CISG 即服務於此目的。

---

# 二、CISG 的基本定義

## 2.1 定義

定義一個 CISG：

$$
G_C
=
(
V,
E,
T_V,
T_E,
A,
Q,
\Gamma
)
$$

其中：

- $V$：節點集合；
- $E$：關係集合；
- $T_V$：節點型別系統；
- $T_E$：邊型別系統；
- $A$：節點與邊的屬性；
- $Q$：解析狀態、信心與不確定性；
- $\Gamma$：來源、證據與版本追溯結構。

CISG 不要求：

$$
G_C
$$

是一張簡單有向圖。

更合理的實作可能是：

$$
\text{typed directed multigraph}
$$

甚至：

$$
\text{hypergraph}
$$

因為一個語義關係可能同時涉及：

- 多個輸入；
- 一個狀態區域；
- 一個 effect boundary；
- 一個控制條件；
- 一組輸出。

---

## 2.2 CISG 的最小條件

一個圖若要被稱為 CISG，至少應滿足：

### 條件一：實作誘導

節點與邊必須由實際程式實作、編譯產物或可驗證執行觀測產生。

### 條件二：來源可追溯

每一個 substantive node／edge 應可以追溯至：

$$
\text{repository}
+
\text{revision}
+
\text{path}
+
\text{location}
$$

或其他等價證據。

### 條件三：類型顯式

不可只表示：

$$
v_i
\rightarrow
v_j
$$

還應說明關係是：

- calls；
- imports；
- controls；
- reads；
- writes；
- contains；
- aliases；
- effects；
- transitions；
- depends-on。

### 條件四：未知顯式

未知關係不得被補成假確定邊。

### 條件五：分析與敘事分離

自然語言解釋可以依 CISG 產生，但自然語言本身不得反向偷偷成為 verified graph fact。

---

# 三、節點系統

## 3.1 結構節點

定義：

$$
V_{\mathrm{struct}}
$$

可包括：

- repository；
- package；
- module；
- namespace；
- class；
- function；
- method；
- lexical block。

這些節點主要表示程式的結構分區。

---

## 3.2 計算節點

定義：

$$
V_{\mathrm{op}}
$$

包括可被抽象為運算的單元，例如：

- arithmetic；
- comparison；
- conversion；
- allocation；
- hash；
- parse；
- serialize；
- deserialize；
- query；
- transform；
- validate。

若某個語言表面寫成：

```text
hashlib.sha256(x).hexdigest()
```

CISG 可以選擇將其正規化成：

$$
\operatorname{SHA256}
\rightarrow
\operatorname{HEX}
$$

從而降低對特定語法拼寫的依賴。

---

## 3.3 控制節點

定義：

$$
V_{\mathrm{ctrl}}
$$

例如：

- branch；
- loop；
- exception handler；
- early return；
- match；
- retry；
- synchronization barrier。

傳統 CFG 通常已可表達大量控制關係，CISG 的工作不是取代 CFG，而是將其納入更高層 typed graph。

---

## 3.4 狀態節點

定義：

$$
V_{\mathrm{state}}
$$

包括：

- object state；
- field；
- cache；
- database state；
- configuration；
- session；
- queue；
- file state；
- shared mutable region。

程式不只是函式互相呼叫，也是不斷對狀態進行：

$$
S_t
\rightarrow
S_{t+1}
$$

的轉換。

如果 CISG 完全沒有 state representation，它通常只能得到程式結構的一個表面近似。

---

## 3.5 效果與邊界節點

定義：

$$
V_{\mathrm{effect}}
$$

與：

$$
V_{\mathrm{boundary}}
$$

例如：

- network；
- filesystem；
- database；
- subprocess；
- clock；
- random source；
- OS；
- user input；
- external API。

CISG 應明確區分：

$$
\text{local resolved target}
$$

與：

$$
\text{external / unresolved boundary}
$$

因為：

$$
\text{不知道目標}
\neq
\text{沒有目標}
$$

---

# 四、邊型別系統

## 4.1 結構邊

例如：

$$
\operatorname{contains}(A,B)
$$

表示 $B$ 位於 $A$ 的結構範圍內。

另可有：

$$
\operatorname{inherits}
$$

$$
\operatorname{implements}
$$

$$
\operatorname{declares}
$$

---

## 4.2 呼叫與依賴邊

定義：

$$
\operatorname{calls}(u,v)
$$

表示存在可支持的靜態或動態呼叫關係。

但：

$$
\operatorname{imports}(u,v)
$$

不得自動被視為：

$$
\operatorname{calls}(u,v)
$$

因為 import 表示結構可見性或依賴，不等同於實際執行。

因此：

$$
E_{\mathrm{dependency}}
\neq
E_{\mathrm{execution}}
$$

是 CISG 的重要原則。

---

## 4.3 控制邊

例如：

$$
\operatorname{controls}(b,x)
$$

表示控制節點 $b$ 決定 $x$ 是否可達。

可進一步區分：

$$
\operatorname{true\_branch}
$$

$$
\operatorname{false\_branch}
$$

$$
\operatorname{exception\_branch}
$$

$$
\operatorname{loop\_back}
$$

---

## 4.4 資料邊

例如：

$$
\operatorname{defines}(a,x)
$$

$$
\operatorname{uses}(b,x)
$$

$$
\operatorname{flows}(x,y)
$$

若引入 SSA，可進一步將：

$$
x
$$

分成：

$$
x_1,x_2,\ldots,x_n
$$

以表示資料版本。

---

## 4.5 狀態與效果邊

例如：

$$
\operatorname{reads}(f,S)
$$

$$
\operatorname{writes}(f,S)
$$

$$
\operatorname{mutates}(f,S)
$$

$$
\operatorname{emits}(f,E)
$$

這些邊使 CISG 可以處理單純 call graph 無法描述的問題：

> 兩個函式即使沒有互相呼叫，也可能因共享狀態而高度耦合。

---

# 五、證據契約

## 5.1 圖不可以失去來源

CISG 中的每一個 verified object 應附帶 provenance。

最低可表示為：

$$
\Gamma(x)
=
(
r,
p,
l_s,
l_e,
m,
h
)
$$

其中：

- $r$：revision；
- $p$：path；
- $l_s$：start line；
- $l_e$：end line；
- $m$：analysis method；
- $h$：source hash 或其他完整性資訊。

因此，一條邊不只是：

$$
u\rightarrow v
$$

而是：

$$
(u,v,\tau,\Gamma)
$$

---

## 5.2 來源完整性閘門

若分析來源本身不能被確認，就不能把後續結果標成 verified。

因此 CISG 建構流程應允許：

$$
\operatorname{VerifySource}(C,r)
\rightarrow
\{\text{valid},\text{invalid},\text{unknown}\}
$$

例如可使用：

- Git blob hash；
- commit hash；
- signed artifact；
- content fingerprint。

這不是附帶功能，而是 graph authority 的前置條件。

---

## 5.3 證據與解釋分離

定義 graph fact：

$$
g
$$

與 explanation：

$$
e
$$

應滿足：

$$
e
\xrightarrow{\operatorname{grounded\_by}}
g
$$

而不是：

$$
e
\Rightarrow
g
$$

也就是：

> 解釋可以引用結構，但解釋本身不能自動製造結構。

---

# 六、解析狀態與不確定性

## 6.1 四種最小狀態

本文建議至少區分：

$$
Q
=
\{
\text{observed},
\text{strongly inferred},
\text{weakly inferred},
\text{unresolved}
\}
$$

另可加入：

$$
\text{author claimed}
$$

以保存文件敘述，但不得與 implementation evidence 混同。

---

## 6.2 未解析不是失敗

若存在：

```text
dynamic_call(x)
```

而靜態分析無法唯一決定 target，CISG 應建立：

$$
v
\xrightarrow{\mathrm{calls?}}
B_{\mathrm{unresolved}}
$$

而不是任意選一個候選。

因此：

$$
\boxed{
\text{Unknown edge is first-class information.}
}
$$

---

## 6.3 信心不是機率真理

可以為每個 node／edge 設：

$$
q\in[0,1]
$$

但這個值表示：

> 在指定分析方法與證據條件下的可信度。

它不應被解釋為：

> 此語義在宇宙中為真的客觀概率。

---

# 七、CISG 與 Architecture Graph 的根本差異

## 7.1 Architecture Graph

典型來源：

$$
G_I
=
f(
\text{requirements},
\text{design},
\text{documents},
\text{human abstraction}
)
$$

它主要回答：

> 系統應該如何被理解或組織？

---

## 7.2 CISG

來源：

$$
G_C
=
\rho(C)
$$

它主要回答：

> 現在的實作可被證據支持地還原成什麼結構？

---

## 7.3 二者都必要

本文不主張：

$$
G_C
>
G_I
$$

因為 $G_I$ 包含程式碼中可能無法恢復的意圖與設計規則。

更合理的是：

$$
G_I
\leftrightarrow
G_C
$$

並研究：

$$
\Delta_{IC}
=
d(G_I,G_C)
$$

這個差異本身可能揭示：

- architecture drift；
- missing implementation；
- undocumented coupling；
- dead design；
- hidden dependency。

---

# 八、多解析度 CISG

## 8.1 為什麼不能永遠顯示所有節點

若 repository 有：

$$
10^6
$$

個低階節點，直接顯示整張圖沒有實用價值。

因此 CISG 必須支援 coarse-graining。

定義：

$$
\pi_k
:
G_C
\rightarrow
G_C^{(k)}
$$

其中 $k$ 表示解析度。

---

## 8.2 建議解析度

### $R_0$：功能域

例如：

- authentication；
- history；
- cache；
- storage；
- orchestration。

### $R_1$：模組域

顯示 module／package 與主要 dependency。

### $R_2$：symbol 域

顯示 function／class／method。

### $R_3$：control／state 域

顯示 branch、state、data dependency、effect。

### $R_4$：source evidence

回到實際 code span。

因此：

$$
R_0
\leftarrow
R_1
\leftarrow
R_2
\leftarrow
R_3
\leftarrow
R_4
$$

但各層不應以「上一層摘要」作為唯一來源。

每一層都應能回到共同 evidence base。

---

# 九、CISG 建構流程

本文提出第一版參考流程：

$$
C
\rightarrow
V_0
\rightarrow
E_0
\rightarrow
N
\rightarrow
R
\rightarrow
G_C
$$

其中：

- $V_0$：原始節點抽取；
- $E_0$：原始關係抽取；
- $N$：語義正規化；
- $R$：target resolution；
- $G_C$：最終 typed graph。

具體步驟如下。

## 9.1 Source verification

確認：

- revision；
- hash；
- path；
- encoding。

## 9.2 Parse

建立：

- AST；
- scope；
- symbol table。

## 9.3 Structural extraction

取得：

- module；
- class；
- function；
- lexical block。

## 9.4 Relation extraction

取得：

- import；
- call；
- control；
- read/write；
- effects。

## 9.5 Resolution

將可能的 target 分成：

$$
\text{local resolved}
$$

$$
\text{external resolved}
$$

$$
\text{ambiguous}
$$

$$
\text{unresolved}
$$

## 9.6 Normalization

將語言表面的不同形式映射到 canonical relation。

## 9.7 Evidence attachment

每個 node／edge 綁定 provenance。

## 9.8 Graph validation

檢查：

- dangling node；
- invalid target；
- evidence loss；
- duplicate identity；
- illegal type pair。

---

# 十、CISG 的形式約束

## 10.1 邊的型別合法性

定義合法關係：

$$
\mathcal R
\subseteq
T_V
\times
T_E
\times
T_V
$$

例如：

$$
(\text{function},\text{calls},\text{function})
\in
\mathcal R
$$

但：

$$
(\text{constant},\text{imports},\text{branch})
\notin
\mathcal R
$$

除非模型明確允許該語義。

---

## 10.2 證據完整性

對 verified node $v$：

$$
Q(v)=\text{observed}
$$

則必須有：

$$
\Gamma(v)\neq\varnothing
$$

對 verified edge $e$：

$$
Q(e)=\text{observed}
$$

同樣要求：

$$
\Gamma(e)\neq\varnothing
$$

---

## 10.3 不確定性保留

若 target resolution 為 ambiguous：

$$
|\operatorname{Candidates}(e)|>1
$$

則：

$$
Q(e)\neq\text{observed-resolved}
$$

除非存在額外證據消除歧義。

---

# 十一、第一個工程實驗：RepoLumen

本系列已完成一個早期 CISG PoC。

在 Git source hash 驗證後，對 RepoLumen 的一組核心 Python 檔案進行：

- AST extraction；
- symbol extraction；
- call extraction；
- control extraction；
- state-write hint；
- effect-boundary hint；
- local target resolution。

得到：

$$
|V|=182
$$

以及：

$$
|E|=334
$$

此數字本身不具有理論特殊性；重要的是圖不是從 README 或人工 architecture design 建立，而是由實際程式來源生成。

初步圖已能顯示：

- function 到 function 的 local resolved calls；
- module dependency；
- lexical containment；
- control nodes；
- state mutation hints；
- external／unresolved boundaries。

這使：

$$
\text{Repository}
\rightarrow
\text{Evidence-Grounded Program Graph}
$$

在有限範圍內得到工程驗證。

---

# 十二、CISG 作為演算法輸入

CISG 的真正價值不是顯示，而是計算。

## 12.1 結構缺陷

定義 detector：

$$
D
:
G_C
\rightarrow
\Delta
$$

其中 $\Delta$ 可以包含：

- cycle；
- unreachable；
- orphan；
- illegal dependency；
- unresolved boundary；
- state conflict；
- effect leak。

---

## 12.2 Change impact

對變更節點：

$$
v
$$

可以研究：

$$
\operatorname{Reach}^{+}(v)
$$

與：

$$
\operatorname{Reach}^{-}(v)
$$

分別表示 outbound 與 inbound 影響域。

---

## 12.3 功能 motif

定義：

$$
M_k
\subseteq
G_C
$$

若多個 repository 出現結構相似的子圖：

$$
G_1[S_1]
\sim
G_2[S_2]
$$

則可以將其作為候選功能基元。

---

## 12.4 Architecture conformance

若已有：

$$
G_I
$$

則可以計算：

$$
\Delta_{IC}
=
d(G_I,G_C)
$$

形成機械化 architecture drift detection。

---

# 十三、CISG 與程式底空間

Paper 01 定義：

$$
B_{\mathrm{prog}}
$$

作為程式關係的底空間。

本文中的：

$$
G_C
$$

則是一個具體實作在該底空間中的可觀測局部結構。

因此：

$$
G_C
\hookrightarrow
\widehat{B}_{\mathrm{prog}}
$$

而：

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

CISG 不是整個程式底空間，而是：

> **由具體程式實作所誘導出的、可被目前分析器觀測到的局部結構。**

這個區分避免把「一張圖」誤稱為「完整本體」。

---

# 十四、與傳統靜態分析的關係

CISG 的大量底層能力並非憑空創造。

它依賴既有方法：

- AST；
- symbol resolution；
- control-flow analysis；
- data-flow analysis；
- SSA；
- alias analysis；
- points-to analysis；
- call graph；
- effect analysis；
- program slicing。

因此 CISG 的新主張不是：

> 以前沒有程式分析。

而是：

> **將多種分析結果整合成一個具共同 identity、共同 provenance、共同 uncertainty contract 的全域 typed semantic graph，並將其提升為後續程式理解與本體反演的 canonical intermediate knowledge layer。**

---

# 十五、限制

目前 CISG 至少存在以下限制。

## 15.1 動態語言

reflection、monkey patch、dynamic dispatch 會降低 target resolution。

## 15.2 Runtime-generated behavior

執行時生成程式碼可能不在靜態 CISG 中。

## 15.3 外部世界

database、network、OS、hardware 等只能以 boundary 表示，除非有額外觀測。

## 15.4 Graph explosion

若把每個 expression 都展開為 node，圖規模可能快速膨脹。

## 15.5 語義正規化

不同語言與 framework 如何映射到共同 operation set，仍未解決。

## 15.6 作者意圖

CISG 只能描述實作結構，不自動等於作者意圖。

---

# 十六、可證偽條件

## 16.1 不可重現

若同一 revision 在同一 analyzer configuration 下無法穩定生成同一核心圖結構，CISG 不適合作為可信中介層。

## 16.2 provenance 不足

若大量 substantive edges 不能回指程式證據，那麼圖可能只是另一種推測式 architecture generation。

## 16.3 不確定性被抹除

若 unresolved／ambiguous targets 被強行解析，則 CISG 失去 epistemic reliability。

## 16.4 無跨分析整合價值

若將 AST、CFG、call graph 等合併後，完全不能產生新的可計算能力，則 CISG 只能被視為視覺整合格式，而非新的 program knowledge layer。

---

# 十七、工程規格草案

CISG v0.1 的最小 schema 可概念表示為：

```json
{
  "graph_version": "cisg-0.1",
  "repository": {
    "source": "...",
    "revision": "...",
    "source_integrity": "verified"
  },
  "nodes": [
    {
      "id": "...",
      "type": "function",
      "semantic_role": null,
      "confidence": 1.0,
      "status": "observed",
      "evidence_ids": ["..."]
    }
  ],
  "edges": [
    {
      "id": "...",
      "type": "calls",
      "source": "...",
      "target": "...",
      "resolution": "local",
      "confidence": 0.98,
      "status": "observed",
      "evidence_ids": ["..."]
    }
  ],
  "evidence": [
    {
      "id": "...",
      "path": "...",
      "start_line": 1,
      "end_line": 5,
      "revision": "...",
      "source_hash": "..."
    }
  ],
  "uncertainty": []
}
```

實際 schema 可比此更複雜，但最低要求是：

$$
\text{Graph}
+
\text{Evidence}
+
\text{Uncertainty}
$$

必須同時存在。

---

# 十八、研究路線

Paper 03 將進一步研究：

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

本身的性質。

核心問題包括：

- 哪些結構可反演；
- 哪些結構只能推論；
- 如何估計反演覆蓋率；
- 如何區分 implementation truth 與 author intent；
- 如何加入 runtime observation；
- 如何定義 ontology reconstruction error。

因此 Paper 02 建立的是：

$$
\boxed{
\text{反演結果的共同結構容器}
}
$$

而 Paper 03 才研究：

$$
\boxed{
\text{反演本身}
}
$$

---

# 十九、核心命題

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

## 命題 1：實作誘導命題

$$
G_C
=
\rho(C)
$$

CISG 的權威來源是實際實作，而非人工架構描述。

## 命題 2：證據依附命題

對 substantive graph object $x$：

$$
Q(x)=\text{observed}
\Rightarrow
\Gamma(x)\neq\varnothing
$$

## 命題 3：關係型別命題

程式關係不可退化成單一 generic edge。

$$
T_E
$$

是 CISG 的必要部分。

## 命題 4：未知顯式命題

$$
\text{unresolved}
\neq
\text{absent}
$$

未知本身必須被保存。

## 命題 5：多解析度命題

同一 CISG 應允許：

$$
\pi_k(G_C)
$$

形成不同解析度，而不丟失回到共同證據的能力。

## 命題 6：分析優先於視覺命題

CISG 首先是：

$$
\text{machine-operable structure}
$$

其次才是視覺化介面。

## 命題 7：圖非本體命題

$$
G_C
\neq
P^\ast
$$

CISG 是程式本體的可觀測實作近似，而不是完整本體本身。

---

# 二十、結論

本文提出「程式碼誘導語義圖」CISG，作為由實際程式實作直接誘導出的 typed、evidence-grounded、uncertainty-aware program graph。

它與人工架構圖最大的差異不是畫法，而是權威來源：

$$
G_I
=
f(\text{Design})
$$

而：

$$
G_C
=
\rho(\text{Implementation})
$$

因此，CISG 可以成為：

- 程式底空間反演的結構容器；
- repository 全域分析層；
- Bug 與 anomaly detector 的輸入；
- 功能 motif 抽取基礎；
- architecture drift 的實作側錨點；
- 跨語言 normalization 的比較對象；
- runtime graph 對照的靜態基線。

最終，本系列希望將 repository 的主要視圖由：

$$
\boxed{
\text{Files}
\rightarrow
\text{Code}
}
$$

逐步提升為：

$$
\boxed{
\text{Program Relations}
\rightarrow
\text{Evidence}
\rightarrow
\text{Executable / Verifiable Structure}
}
$$

若此路線成立，那麼「程式節點圖」就不再只是方便人類觀看的圖形介面，而會成為程式本身的一個可計算、可追溯、可驗證的知識層。

---

# 參考與前置理論

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