程式功能基元與結構型分類：從功能命名到計算 Motif

Program Functional Primitives and Structural Classification: From Functional Naming to Computational Motifs

系列： 程式底空間與本體反演系列（Program Base Space and Ontology Inversion, PBSOI）
篇次： Paper 07
版本： v0.1
作者： Neo.K
機構： EveMissLab
日期： 2026-09-14
狀態： 功能結構理論初稿／Motif Classification Framework

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

摘要

前述 PBSOI 系列已建立程式底空間、程式碼誘導語義圖（CISG）、程式本體反演、共通程式底空間、可執行語義圖與結構缺陷計算。這些工作使程式可以被表示為具有型別、關係、狀態、效果、邊界、證據與不確定性的可計算結構。當不合法結構可以形成缺陷模式後，另一個自然問題是：合法且反覆出現的程式結構，是否也可以被辨識為功能基元？

本文提出「程式功能基元」（Program Functional Primitive, PFP）與「計算 Motif」（Computational Motif）概念，主張常見程式功能不應首先由檔名、函式名或自然語言註解決定，而應優先由其在程式語義圖中的結構、資料流、狀態轉換、效果、契約與邊界模式決定。自然語言名稱可以描述 motif，但不應成為 motif identity 的唯一來源。

本文將 motif 定義為程式語義圖中的可重現子結構：

M = ( V_M, E_M, K_M, B_M, Q_M )

其中 $V_M$ 與 $E_M$ 分別為節點與關係， $K_M$ 為必要約束， $B_M$ 為邊界接口， $Q_M$ 為不確定性與證據條件。本文提出 exact motif、parameterized motif、approximate motif 與 emergent motif 四種類型，並區分功能 motif、協調 motif、資源 motif、驗證 motif、錯誤處理 motif 與狀態 motif。

本文進一步建立 motif extraction、canonicalization、matching、clustering、naming 與 validation 的完整流程，並定義 motif identity 與自然語言 label 的分離原則：

\operatorname{Identity}(M) \neq \operatorname{Name}(M)

此原則使跨語言、跨專案與跨 framework 的功能分類可以建立在共享結構上，而不必依賴文字相似度。

本文亦提出「程式功能基元庫」（Program Functional Primitive Library, PFPL），用於累積經多專案驗證的 motif family。例如 parse-validate-transform、lookup-cache-fallback、authenticate-authorize、acquire-use-release、retry-backoff-fail、read-modify-write 等結構，可作為候選高階功能基元。這些 motif 可以成為程式理解、跨語言對齊、變更影響分析、程式搜尋、AI Agent 導航與自動重構的中介結構。

本文同時強調：高頻率不等於功能基元，相似形狀不等於相同語義，功能標籤也不能反向污染圖證據。若 motif 只能靠 LLM 讀命名猜測，或無法跨 repository 重現，則它只是一種自然語言分類，不足以形成結構型程式知識。

本文的核心命題是：

功能可以被視為程式語義圖中反覆出現、具有穩定邊界與關係不變量的結構形狀；名稱只是人類對這些形狀的投影，而不是形狀本身。

關鍵詞

程式功能基元、Program Functional Primitive、PFP、Computational Motif、程式功能分類、CISG、子圖模式、跨語言語義、程式搜尋、程式理解、功能圖譜、Motif Library、結構分類

一、問題的提出

1.1 功能名稱與功能本體不是同一件事

程式工程中常見以下函式：

authenticate_user
validate_token
verify_access
authorize_request

它們的名稱可能不同，但都可能實現近似功能。

反過來，兩個函式都叫：

validate

卻可能分別驗證：

schema；
password；
state transition；
cryptographic signature；
business rule。

因此：

\text{Name Similarity} \not\Rightarrow \text{Functional Similarity}

同樣：

\text{Name Difference} \not\Rightarrow \text{Functional Difference}

如果程式功能分類完全依賴文字：

\text{Function Name} + \text{Comments} + \text{README}

那麼分類本質上仍然停留在表面投影。

1.2 若程式已經成為圖，功能可以重新定義

假設：

G_C = (V,E,\ldots)

是一個 CISG。

則一個功能不再只能描述為：

這個函式叫什麼？

而可以問：

哪些節點、關係、狀態、效果與邊界共同形成某個重複出現的結構？

因此定義：

M \subseteq G_C

作為某個候選 motif。

若多個不同 repository 中：

M_1 \sim M_2 \sim \cdots \sim M_n

並共享穩定不變量，則可以形成一個功能 motif family。

二、程式功能基元的定義

2.1 功能基元不是最小指令

本文所稱：

\text{Program Functional Primitive}

不是 machine instruction。

它也不必是語言層級的最小運算。

例如：

\operatorname{ADD}

是 operation primitive。

而：

\operatorname{Authenticate}

可能是由多個 operation、state、effect 與 boundary 組成的高階功能基元。

因此：

\text{Operation Primitive} \neq \text{Functional Primitive}

2.2 Motif 形式

定義 motif：

M = ( V_M, E_M, K_M, B_M, Q_M )

其中：

$V_M$ ：motif 節點；
$E_M$ ：motif 關係；
$K_M$ ：必要語義約束；
$B_M$ ：輸入、輸出、狀態與效果邊界；
$Q_M$ ：證據與不確定性條件。

2.3 Functional Primitive

若 motif：

M

滿足：

跨多個實作重現；
邊界相對穩定；
結構具有可描述功能；
可與其他 motif 組合；
不依賴單一程式語言表面；

則可將其提升為：

PFP(M)

即程式功能基元。

三、Motif Identity 與名稱分離

3.1 結構先於標籤

定義：

\operatorname{ID}(M)

應由 canonical structure 產生。

例如：

\operatorname{ID}(M) = H( N(M) )

其中：

N

表示 motif normalization。

3.2 名稱只是投影

自然語言名稱：

\operatorname{Name}(M)

可以是：

authentication
cache lookup
retry loop
resource guard

但：

\boxed{ \operatorname{ID}(M) \neq \operatorname{Name}(M) }

3.3 多名稱與多語言

同一 motif 可以具有：

\{ \text{authenticate}, \text{身份驗證}, \text{認証}, \text{auth check} \}

多個 label。

因此 motif ontology 不應依賴單一語言文字。

四、六類 Motif

4.1 功能 Motif

描述某個可辨認業務或程式功能。

例如：

\text{parse} \rightarrow \text{validate} \rightarrow \text{transform}

4.2 協調 Motif

描述 control / orchestration。

例如：

\text{fan-out} \rightarrow \text{parallel work} \rightarrow \text{join}

4.3 資源 Motif

例如：

\operatorname{Acquire} \rightarrow \operatorname{Use} \rightarrow \operatorname{Release}

4.4 驗證 Motif

例如：

\operatorname{Input} \rightarrow \operatorname{Check} \rightarrow \operatorname{Accept/Reject}

4.5 錯誤處理 Motif

例如：

\operatorname{Try} \rightarrow \operatorname{Fail} \rightarrow \operatorname{Retry} \rightarrow \operatorname{Fallback}

4.6 狀態 Motif

例如：

\operatorname{Read} \rightarrow \operatorname{Modify} \rightarrow \operatorname{Write}

五、Motif 的四個層級

5.1 Exact Motif

若：

M_1 \cong M_2

即 typed graph isomorphism 成立，則為 exact motif。

5.2 Parameterized Motif

若結構相同，但：

node count；
constant；
branch count；
retry count；

可變，則：

M(\theta)

稱 parameterized motif。

例如：

\operatorname{Retry}(n)

5.3 Approximate Motif

若：

d(M_1,M_2) < \epsilon

但不完全同構，仍可能屬於同一 motif family。

5.4 Emergent Motif

某些 motif 並非預先定義，而是從大量程式圖中 clustering 得到。

若：

\mathcal C_k = \{M_1,\ldots,M_n\}

具有穩定共同結構，則可以形成候選 emergent motif。

但：

\text{Cluster} \not\Rightarrow \text{Functional Primitive}

仍需要驗證。

六、Motif Extraction

6.1 Subgraph Candidate

對：

G

取候選子圖：

S_i \subseteq G

候選來源可以包括：

function boundary；
state region；
effect boundary；
call community；
strongly connected component；
execution path segment；
repeated code region。

6.2 邊界抽取

定義 motif boundary：

B_M = ( I_M, O_M, S_M, F_M )

其中：

$I_M$ ：輸入；
$O_M$ ：輸出；
$S_M$ ：共享狀態接口；
$F_M$ ：外部效果。

6.3 內部／外部區分

對：

M

若一條 edge：

e=(u,v)

且：

u\in M,\quad v\notin M

則：

e

是 motif boundary edge。

這些 boundary 是 motif identity 的重要部分。

七、Canonicalization

7.1 去除無關名稱

例如：

user_id
uid
account_identifier

若只在 motif 結構中扮演同一 input role，可以 canonicalize 為：

\operatorname{Input}_0

7.2 去除局部 ID

若：

v_{173}

與：

v_{829}

只因不同 repository 而 ID 不同，不應影響 motif matching。

7.3 保留語義型別

但：

\operatorname{Validate}

不能與：

\operatorname{WriteDB}

因為名稱被移除就視為相同。

因此 normalization 必須保持：

T_V

與：

T_E

7.4 Canonical Motif

定義：

N_M : M \rightarrow \widetilde{M}

並要求：

\widetilde{M}

對同一 motif family 具有穩定 serialization。

八、Motif Matching

8.1 Exact Matching

可用：

\operatorname{Iso} ( \widetilde{M}_1, \widetilde{M}_2 )

8.2 Typed Graph Edit Distance

對 approximate motif：

d_G(M_1,M_2)

可考慮：

node insertion；
node deletion；
edge insertion；
edge deletion；
type substitution；
boundary substitution。

8.3 Semantic Weighted Distance

不同差異的成本不應相同。

例如：

w( \text{rename} ) < w( \text{effect change} )

以及：

w( \text{local branch} ) < w( \text{security boundary removal} )

因此：

d_{\mathrm{sem}} = \sum_i w_i \Delta_i

九、功能相似不等於實作相似

兩個 authentication implementation 可能：

一個 JWT；
一個 session cookie；
一個 certificate；
一個 hardware key。

其內部 operation 不同。

但在較高解析度下，可能共享：

\operatorname{CredentialInput} \rightarrow \operatorname{Verification} \rightarrow \operatorname{IdentityResolution} \rightarrow \operatorname{Decision}

因此 motif 必須支援多解析度：

M^{(R_0)} , M^{(R_1)} , \ldots, M^{(R_n)}

十、功能基元庫

10.1 定義

建立：

\mathcal M = \{ M_1, M_2, \ldots, M_n \}

稱為：

\boxed{ \text{Program Functional Primitive Library} }

簡稱：

PFPL

10.2 每個基元應包含

對：

M_k

保存：

canonical graph；
accepted variants；
semantic constraints；
input/output boundary；
state contract；
effect contract；
language examples；
counterexamples；
provenance；
confidence；
version。

10.3 Motif Promotion

候選 motif：

M^\ast

不應一次就進 authoritative library。

應經：

\text{discover} \rightarrow \text{cluster} \rightarrow \text{validate} \rightarrow \text{counterexample} \rightarrow \text{promote}

十一、候選功能基元

11.1 Parse–Validate–Transform

\operatorname{Input} \rightarrow \operatorname{Parse} \rightarrow \operatorname{Validate} \rightarrow \operatorname{Transform}

11.2 Lookup–Cache–Fallback

\operatorname{LookupCache} \rightarrow \operatorname{Hit/Miss}

若 miss：

\operatorname{FetchSource} \rightarrow \operatorname{StoreCache}

11.3 Authenticate–Authorize

\operatorname{Credential} \rightarrow \operatorname{VerifyIdentity} \rightarrow \operatorname{ResolvePrincipal} \rightarrow \operatorname{CheckPermission}

11.4 Acquire–Use–Release

\operatorname{Acquire} \rightarrow \operatorname{Use} \rightarrow \operatorname{Release}

11.5 Retry–Backoff–Fail

\operatorname{Attempt} \rightarrow \operatorname{Failure} \rightarrow \operatorname{Backoff} \rightarrow \operatorname{Retry}

最後：

\operatorname{Success} \lor \operatorname{TerminalFailure}

11.6 Read–Modify–Write

\operatorname{Read}(S) \rightarrow \operatorname{Transform} \rightarrow \operatorname{Write}(S')

十二、功能分類

12.1 傳統分類

傳統分類可能是：

\operatorname{Classify} ( \text{name}, \text{comments}, \text{README} )

12.2 結構分類

本文提出：

\operatorname{Classify}_{M} ( G[S] ) \rightarrow M_k

12.3 混合分類

實際系統可使用：

\operatorname{Score} = \alpha S_{\mathrm{struct}} + \beta S_{\mathrm{boundary}} + \gamma S_{\mathrm{effect}} + \delta S_{\mathrm{contract}} + \eta S_{\mathrm{text}}

但應滿足：

\alpha+\beta+\gamma+\delta > \eta

在 structure-first 模式下，文字只是輔助證據。

十三、跨語言 Motif

13.1 Python 與 Rust

若：

G_{\mathrm{py}}[S]

與：

G_{\mathrm{rs}}[T]

經 Paper 04 的 normalization：

N_{\mathrm{py}}

與：

N_{\mathrm{rs}}

後滿足：

d( N_{\mathrm{py}}(S), N_{\mathrm{rs}}(T) ) < \epsilon

則可以被分類到同一跨語言 motif。

13.2 Language Residual

但語言特定：

R_L

仍保留。

例如：

M_{\mathrm{resource}}

在 Rust 中可能帶：

\operatorname{OwnershipResidual}

在 C 中帶：

\operatorname{ManualLifetimeResidual}

十四、Motif 與 Defect Pattern 的對偶

Paper 06 定義：

F_k

作為 forbidden pattern。

本文定義：

M_k

作為 functional motif。

因此：

\boxed{ \text{Program Pattern Space} = \text{Functional Motifs} \cup \text{Defect Motifs} \cup \text{Unknown Motifs} }

14.1 正向結構

功能 motif 表示：

\text{應該如何組成某類功能}

14.2 負向結構

defect motif 表示：

\text{不應存在的結構}

14.3 未知結構

大量尚未命名 subgraph：

U_M

可以進入 discovery pool。

十五、Motif 與程式搜尋

15.1 Text Search 的限制

搜尋：

authentication

只能找到具有類似文字的 code。

15.2 Structure Search

可以查詢：

Q_M

表示：

找出所有具有 credential → verify → permission decision 結構的子圖。

15.3 跨語言搜尋

因此 query：

Q_M

可以同時找到：

Python；
Rust；
Go；
Java；
C#；

中的功能等價候選。

十六、Motif 與程式理解

16.1 從細節到功能區域

大型 CISG：

G

若有數十萬節點，人類與 AI 都不應每次讀完整圖。

可以先壓縮：

G \rightarrow G_M

其中：

G_M

是 motif-level graph。

16.2 Motif Collapse

若：

M \subseteq G

可以定義：

H_M : M \rightarrow v_M

將整個 motif 壓成：

v_M

但保存：

B_M

作為邊界。

16.3 多解析度展開

因此：

v_M \rightarrow M \rightarrow \text{source evidence}

可以逐層展開。

十七、Motif 與變更影響

若某修改：

\Delta v

位於 motif：

M

內，可以分析：

\operatorname{Impact}_{\mathrm{local}}(M)

以及：

\operatorname{Impact}_{\mathrm{boundary}}(B_M)

這比只看 function caller/callee 更接近功能層。

十八、Motif 與重構

18.1 Equivalent Motif Replacement

若：

M_1 \equiv_{\mathcal C} M_2

可以研究：

G[M_1] \rightarrow G[M_2]

18.2 Pattern-Level Refactoring

例如：

\operatorname{ManualRetryLoop}

可被重構為：

\operatorname{StandardRetryPrimitive}

只要：

K_{M_1} \equiv K_{M_2}

在指定語境成立。

十九、Motif 與 AI Agent

19.1 Agent 不必從檔案樹開始

傳統 Agent：

\text{Repo} \rightarrow \text{File Search} \rightarrow \text{Read Code}

19.2 Motif-First Agent

可以：

\text{Intent} \rightarrow \text{Relevant Motif} \rightarrow \text{Affected Subgraph} \rightarrow \text{Source Evidence}

19.3 Example

若任務：

修改 authentication retry policy。

Agent 可以直接導航到：

M_{\mathrm{auth}}

與：

M_{\mathrm{retry}}

的交界，而不是搜尋所有含 "auth" 與 "retry" 的文字。

二十、Motif Discovery

20.1 無監督候選

對大量：

\{G_1,\ldots,G_n\}

抽取 subgraphs：

\mathcal S

再執行 clustering：

\operatorname{Cluster}(\mathcal S)

20.2 頻率

可定義：

f(M)

表示 motif 出現頻率。

但：

f(M)\gg 1

不代表：

M

具有功能重要性。

20.3 Stability

更重要的是跨 repository 穩定度：

s(M)

以及跨語言穩定度：

s_L(M)

20.4 Boundary Stability

如果 motif 內部結構可變，但：

B_M

高度穩定，仍可能是一個強功能基元。

二十一、Motif 驗證

21.1 Positive Examples

需要：

P_M = \{M_1^+,\ldots,M_n^+\}

21.2 Negative Examples

更重要的是：

N_M = \{M_1^-,\ldots,M_m^-\}

避免：

所有有 if + lookup 的東西都被叫 authentication。

21.3 Counterexample Search

若 motif 定義：

K_M

太寬，應尋找：

M^- \models K_M

但功能實際不同。

若找到，必須修正 motif。

二十二、Motif Confusion

22.1 相同形狀，不同功能

例如：

\text{parse} \rightarrow \text{check} \rightarrow \text{decision}

可能是：

auth；
config validation；
spam filter；
compiler type check。

因此只看 topology 不夠。

22.2 需要語義型別與邊界

真正 motif 應包含：

T_V + T_E + B_M + K_M

而不是純 graph shape。

二十三、Motif Versioning

23.1 Motif 會演化

定義：

M^{(1)} \rightarrow M^{(2)} \rightarrow \cdots

23.2 Family

可以建立：

\mathcal F_M = \{ M^{(1)},M^{(2)},\ldots \}

表示同一功能 motif family。

23.3 Deprecation

若某 motif 被證明：

過度寬鬆；
誤分類過高；
語義錯誤；

應標記：

\operatorname{Deprecated}(M)

而不是靜默替換。

二十四、Motif Graph

當一個大型 project 被 motif collapse 後，可形成：

G_{\mathrm{motif}} = ( V_M, E_M )

其中節點不再是 function，而是：

authentication；
cache；
persistence；
retry；
validation；
orchestration。

此圖可以成為比普通 architecture diagram 更接近實作的高階功能圖。

二十五、Motif 與 Architecture Graph 的關係

人工設計圖：

G_I

可以寫：

Authentication Service

CISG：

G_C

則有大量低階實作節點。

Motif abstraction：

H(G_C) = G_M

可以建立：

G_I \leftrightarrow G_M \leftrightarrow G_C

使 design 與 implementation 之間多出一個可機械生成的功能中介層。

二十六、功能基元的組合

若：

M_A

與：

M_B

存在相容 boundary：

O_A \cong I_B

則：

M_A \circ M_B

可形成更高階 motif。

因此：

\mathcal M

不只是 motif dictionary，也可以形成 composition algebra。

二十七、功能層級

可建立：

M^{(0)} \rightarrow M^{(1)} \rightarrow M^{(2)}

例如：

\operatorname{Compare}

是 operation。

上層：

\operatorname{Validate}

再上層：

\operatorname{Authenticate}

更上層：

\operatorname{AccessControl}

因此功能不是單層標籤，而是 hierarchy。

二十八、與共通程式底空間的關係

Paper 04 定義：

B_{\mathrm{common}}

若 motif 可以跨語言存在，則：

M \subseteq B_{\mathrm{common}}

或更準確：

N_L(M_L) \rightarrow M_{\mathrm{common}}

因此 motif 是 CPBS 中最具工程價值的一類中高階共享結構。

二十九、可證偽條件

29.1 只靠名稱才能分類

若移除：

function name；
comments；
README；

後 motif classifier 幾乎失效，則它不是 structure-first system。

29.2 無法跨 Repository 重現

若候選 motif：

M

只在單一 repository 出現，不能穩定匹配其他實作，則它只能算 local pattern。

29.3 高 False Positive

若：

M

大量匹配功能不同的子圖，則 motif 定義過寬。

29.4 過度具體

若 motif 只匹配完全相同 source structure，無法容許合理 implementation variation，則它只是 clone detection。

29.5 過度粗粒

若所有：

\text{input} \rightarrow \text{check} \rightarrow \text{output}

都被歸成同一功能，則 motif 沒有辨識力。

三十、核心命題

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

命題 1：功能形狀命題

部分程式功能可以由穩定的語義子圖結構表徵：

M\subseteq G_C

命題 2：標籤非本體命題

\operatorname{Name}(M) \neq \operatorname{Identity}(M)

命題 3：跨語言 Motif 命題

經正規化後：

N_{L_1}(M_1) \sim N_{L_2}(M_2)

可以構成跨語言功能 family。

命題 4：邊界重要命題

B_M

是 motif identity 的核心部分，而非附註。

命題 5：多解析度命題

功能 motif 可以存在於不同：

R_k

解析度。

命題 6：功能與缺陷對偶命題

\text{Functional Motif}

與：

\text{Defect Motif}

是同一 pattern space 中不同語義類型。

命題 7：功能基元庫命題

經驗證 motif 可累積成：

PFPL

形成可重用程式功能知識庫。

命題 8：功能壓縮命題

大型程式圖可經：

H_M

壓縮成 motif-level graph，而保留回到證據的能力。

命題 9：AI 後置命名命題

AI 可以：

M \rightarrow \operatorname{Name}(M)

但不能用名稱反向製造：

M

的 verified identity。

命題 10：組合性命題

若 boundary compatible，則：

M_A \circ M_B

可以形成更高階功能 motif。

三十一、後續工程路線

第一階段建立：

PFPL_0

只收錄少量可明確定義 motif：

parse-validate-transform；
acquire-use-release；
retry-backoff；
read-modify-write；
cache-hit-miss-fallback；
authenticate-authorize。

第二階段進行：

Python；
Rust；
C；
JavaScript；

跨語言驗證。

第三階段才允許：

\operatorname{DiscoverMotif}

從大型 repository corpus 自主發現新 motif。

所有新 motif 都必須經：

\text{Positive} + \text{Negative} + \text{Counterexample} + \text{Cross-Repo Validation}

後才能升格。

三十二、與下一篇的關係

Paper 08 將完成整個系列，研究：

G_I \leftrightarrow G_C \leftrightarrow G_R

的三圖一致性。

其中：

$G_I$ ：意圖／設計；
$G_C$ ：實作；
$G_R$ ：runtime realization。

Paper 07 建立的：

G_M

則可以作為 $G_I$ 與 $G_C$ 之間的功能抽象層。

因此完整關係可以進一步寫成：

G_I \leftrightarrow G_M \leftrightarrow G_C \leftrightarrow G_R

三十三、結論

本文提出「程式功能基元」與「計算 Motif」，主張程式功能可以在語義圖中被重新理解為具有穩定關係、邊界與約束的反覆結構。

其核心定義為：

M = ( V_M, E_M, K_M, B_M, Q_M )

而：

\boxed{ \operatorname{Identity}(M) \neq \operatorname{Name}(M) }

這表示：

authentication、cache、retry、validation 等名稱只是人類對某些程式結構的命名；真正可以跨 repository、跨語言與跨 framework 被比較的，是其底下的結構、資料、狀態、效果與邊界。

因此，程式功能分類可以由：

\text{Text Classification}

逐步提升為：

\boxed{ \text{Semantic Structural Classification} }

而大型 repository 也可以由：

\text{File Tree}

壓縮成：

\text{Motif Graph}

使人類與 AI 首先看到：

這個專案有哪些功能形狀、它們如何連接、哪些形狀正在變動、哪些形狀出現異常。

到此，PBSOI 已經同時具備兩種 pattern：

\text{Forbidden Pattern} \rightarrow \text{Defect}

與：

\text{Stable Recurrent Pattern} \rightarrow \text{Functional Motif}

也就是：

\boxed{ \text{程式結構不只可以被執行與驗證，也可以形成自身的功能語彙。} }

這為最後一篇的三圖一致性提供一個新的中介層：意圖不必直接與數十萬低階節點比較，而可以先與由實作反演出的功能 motif graph 進行對齊。

參考與前置理論

Neo.K，《程式底空間：從原始碼表徵到計算關係的存在層》，PBSOI Paper 01。
Neo.K，《程式碼誘導語義圖：由實作生成而非由設計繪製的程式節點圖》，PBSOI Paper 02。
Neo.K，《程式本體反演：從可執行投影重建可觀測程式本體》，PBSOI Paper 03。
Neo.K，《共通程式底空間：跨語言語義正規化與表徵收斂》，PBSOI Paper 04。
Neo.K，《可執行語義圖：脫離原始碼後的程式重建與再執行》，PBSOI Paper 05。
Neo.K，《結構缺陷計算：以程式語義圖進行非智能化 Bug 與異常偵測》，PBSOI Paper 06。
Neo.K，《多重投影程式論：原始碼不再是程式本體》。
Neo.K，《從程式碼到意圖：程式概念的歷史轉換與後文本時代》。
EveMissLab，CISG RepoLumen PoC v0.1。
EveMissLab，Semantic Graph PoC v0.1。