多重投影程式系統技術架構白皮書：權威 IR、可驗證回寫與 AI 原生治理

版本： v1.0
文件類型： 技術架構白皮書
狀態： MVP 前置規格
適用範圍： EML、NOVA、格子語言、Skill、動態顯影與世界狀態程式系統

摘要

本白皮書將「程式語言設計風格理論系列」的六篇地基論文轉換為可實作技術架構。系統的核心假設是：未來程式不應再被預設為某一份線性原始碼，而應被表示為一個具有穩定識別、型別、效果、權限、歷史與驗證資訊的權威程式本體。文字、自然語言、張量算子圖、格子空間、Agent 工作流、權限面板與執行動畫，皆為此權威本體的不同投影。

本文提出一套以 Canonical Authoritative Intermediate Representation，簡稱 CAIR，為核心的多重投影程式系統。系統由意圖輸入層、EML 語義轉譯層、CAIR 權威本體層、NOVA 張量—算子層、格子與圖形投影層、控制治理層、適應執行層及驗證版本層構成。所有投影修改皆不得直接覆寫權威程式，而須先生成候選語義差異，經型別、效果、權限、不變量與風險驗證後，才可提交為新版本。

本白皮書同時定義節點、邊、區域、端口、治理契約、修改提案、投影證書與驗證證書的資料模型；提出生成—執行分離、最小必要權限、最小必要自主性、語義差異優先、投影有損性顯式化與安全退化原則；並規劃第一版 MVP 的技術範圍、API、儲存模型、測試策略、里程碑與風險控制。

本系統的目標不是一次取代所有既有程式語言，而是先建立一個可被文字、圖、格子與 AI 共同操作的權威程式核心，驗證「多重投影、可驗證回寫與局部治理」是否能成為 AI 原生程式系統的新地基。

關鍵詞： 權威 IR、多重投影、AI 原生程式、可驗證回寫、語義差異、格子語言、NOVA、EML、治理契約

第一部分　系統定位

一、系統目標

本系統的主要目標是建立：

\text{權威程式本體} + \text{多重投影} + \text{可驗證回寫} + \text{AI 候選生成} + \text{局部治理}

具體而言，系統應能：

以結構化權威 IR 保存程式的節點、關係、型別、效果、權限、來源與歷史。
將同一權威程式投影為文字、圖、格子、自然語言、張量圖與治理視圖。
允許使用者或 AI 從不同投影提出修改。
將修改轉換為語義層候選差異，而非直接修改檔案。
驗證修改是否符合型別、權限、效果、不變量與治理契約。
顯示修改造成的結構、語義與治理影響。
保存完整版本、來源、內容指紋、證書與回滾點。
將 AI 的生成權與實際執行權分離。
支援區域、邊界、端口、耦合與局部權限。
為 EML、NOVA、格子語言與 Skill 提供共同技術底座。

二、非目標

第一版系統不以以下事項為必要目標：

取代 C、Python、Rust、JavaScript 等所有既有語言。
直接編譯任意自然語言為高風險可執行操作。
完成通用 AGI Agent 自主規劃平台。
支援所有硬體與所有分散式後端。
為所有程式轉換提供完整形式證明。
建立完整虛擬世界或數位孿生運行時。
實作所有 EML、NOVA 與格子語言的最終語法。
在 MVP 階段允許 AI 無限制呼叫外部工具。
以視覺化取代文字編輯器。
以單一模型輸出作為權威語義來源。

三、核心系統命題

本系統建立在下列關係上：

P^{\ast} \neq P_{\text{text}}

其中：

$P^{\ast}$ 是權威程式本體；
$P_{\text{text}}$ 是文字投影。

更完整地說：

\mathfrak{P} = \left( P^{\ast}, \Pi, \Delta, \mathcal{V}, \mathcal{G}, H \right)

其中：

$\Pi$ ：投影器集合；
$\Delta$ ：回寫與差異系統；
$\mathcal{V}$ ：驗證器集合；
$\mathcal{G}$ ：治理系統；
$H$ ：版本與歷史。

第二部分　總體架構

四、八層架構

系統分為八個主要層級：

\mathcal{S} = (L_I,L_E,L_C,L_N,L_P,L_G,L_X,L_V)

其中：

$L_I$ ：意圖輸入層；
$L_E$ ：EML 語義轉譯層；
$L_C$ ：CAIR 權威本體層；
$L_N$ ：NOVA 張量—算子層；
$L_P$ ：多重投影層；
$L_G$ ：控制治理層；
$L_X$ ：適應執行層；
$L_V$ ：驗證、版本與證書層。

五、完整資料流

系統的主要資料流為：

I_t \xrightarrow{\rho} S_t \xrightarrow{\kappa} P_t^{\ast} \xrightarrow{\pi_i} P_{i,t}

使用者或 AI 在投影上提出修改：

\Delta P_{i,t} \xrightarrow{\delta_i} \Delta P_{t,c}^{\ast}

候選差異經驗證：

\Delta P_{t,c}^{\ast} \xrightarrow{\nu} \begin{cases} \Delta P_t^{\ast}, & \text{接受}\\ \Delta P_{t,r}^{\ast}, & \text{修正}\\ \varnothing, & \text{拒絕} \end{cases}

提交後形成新版本：

P_{t+1}^{\ast} = P_t^{\ast} \oplus \Delta P_t^{\ast}

再重新生成所有受影響投影：

P_{i,t+1} = \pi_i(P_{t+1}^{\ast})

六、權威資料與派生資料

系統必須嚴格區分權威資料與派生資料。

6.1 權威資料

包括：

節點；
邊；
型別；
效果；
權限；
不變量；
區域；
端口；
治理契約；
版本；
來源；
驗證證書。

6.2 派生資料

包括：

文字格式；
圖形布局；
格子位置；
自然語言說明；
執行動畫；
統計摘要；
AI 生成解釋；
快取與索引。

原則為：

\text{Derived Data} \rightarrow \text{可重建}

若一項資料無法由權威結構重建，則它可能不應被視為純派生資料。

第三部分　CAIR 權威中介表示

七、CAIR 定義

CAIR 是：

Canonical Authoritative Intermediate Representation，規範權威中介表示。

其目標不是成為人類直接編寫的最佳語法，而是成為所有投影、驗證、版本與治理共享的穩定結構。

CAIR 的完整狀態表示為：

P^{\ast} = (N,E,R,P,C,V,H,M)

其中：

$N$ ：節點集合；
$E$ ：邊集合；
$R$ ：區域集合；
$P$ ：投影與端口描述；
$C$ ：約束、型別與效果；
$V$ ：驗證與證書；
$H$ ：歷史與版本；
$M$ ：中繼資料與來源。

八、節點模型

節點定義為：

n = (id,k,t,d,e,p,s,a)

其中：

$id$ ：穩定識別碼；
$k$ ：節點種類；
$t$ ：型別；
$d$ ：資料；
$e$ ：效果；
$p$ ：權限；
$s$ ：來源；
$a$ ：屬性集合。

第一版節點種類包括：

value
operator
function
tensor
agent
skill
event
state
constraint
validator
resource
projection
region

範例：

{
  "id": "node:sum-01",
  "kind": "operator",
  "type": "number[] -> number",
  "data": {
    "operator": "sum"
  },
  "effects": [],
  "permissions": {
    "read": ["project:default"],
    "write": ["role:developer"]
  },
  "source": {
    "kind": "human",
    "projection": "text:main"
  },
  "attributes": {
    "deterministic": true
  }
}

九、邊模型

邊定義為：

e = (id,u,v,k,t,c,p)

其中：

$id$ ：穩定識別碼；
$u$ ：來源節點；
$v$ ：目標節點；
$k$ ：關係種類；
$t$ ：邊型別；
$c$ ：約束；
$p$ ：權限。

第一版關係種類包括：

data
control
event
capability
permission
causal
temporal
validation
containment
projection

邊不是畫面中的線，而是權威語義結構。

十、端口模型

端口定義為：

p = (id,o,\tau,m,d,c,g)

其中：

$id$ ：端口識別碼；
$o$ ：所屬節點或區域；
$\tau$ ：資料或能力型別；
$m$ ：傳輸模式；
$d$ ：方向；
$c$ ：約束；
$g$ ：治理規則。

端口方向包括：

input
output
bidirectional

傳輸模式包括：

value
stream
event
capability
state
reference

兩端口只有在下列條件成立時才能耦合：

\operatorname{Compatible}(p_o,p_i) = \text{true}

兼容性至少檢查：

型別；
方向；
效果；
權限；
時間模式；
資源預算；
區域邊界。

十一、區域模型

區域定義為：

z = (id,N_z,E_z,\partial z,I_z,O_z,G_z,L_z)

其中：

$N_z$ ：區域內節點；
$E_z$ ：區域內邊；
$\partial z$ ：邊界；
$I_z$ ：輸入端口；
$O_z$ ：輸出端口；
$G_z$ ：治理策略；
$L_z$ ：布局與投影資訊。

區域可以是：

固定模組；
動態選域；
Agent 工作區；
Skill 執行區；
沙盒；
正式部署區；
高風險隔離區；
只讀分析區。

區域是治理與局部性的一級單位。

十二、型別與效果系統

CAIR 的合法性不只依賴資料型別，也依賴效果。

型別可表示為：

\tau = (\tau_v,\tau_s,\tau_r)

其中：

$\tau_v$ ：值型別；
$\tau_s$ ：形狀或結構型別；
$\tau_r$ ：資源型別。

效果集合表示為：

\epsilon \subseteq \{ read, write, network, filesystem, execute, state, external, nondeterministic \}

函數或算子型別可寫為：

f: A \xrightarrow{\epsilon} B

例如：

f: \text{FilePath} \xrightarrow{\{filesystem,read\}} \text{Text}

效果系統將成為 Agent 控制與 Skill 權限驗證的基礎。

十三、約束與不變量

約束表示為：

c = (id,scope,predicate,severity,source)

其中：

scope：適用節點、區域或整體程式；
predicate：可執行或可檢查條件；
severity：錯誤、警告或提示；
source：人類、AI、語言核心或治理規則。

不變量可分為：

型別不變量；
形狀不變量；
權限不變量；
狀態不變量；
資源不變量；
世界狀態不變量；
治理不變量。

第四部分　EML 語義輸入層

十四、EML 的技術角色

EML 在本系統中不是單一固定語法，而是：

\text{EML} = \text{多表面語義輸入} + \text{規格生成} + \text{CAIR 轉譯}

EML 輸入可以是：

自然語言；
結構化表單；
高密度符號；
領域 DSL；
範例；
對話；
圖像標註；
既有程式碼。

十五、意圖模型

意圖表示為：

I = (G,C,R,V,U)

其中：

$G$ ：目標；
$C$ ：約束；
$R$ ：可用資源；
$V$ ：驗證標準；
$U$ ：未決定項目。

EML 必須區分：

使用者明確指定；
系統推定；
AI 補全；
預設值；
尚未解決的歧義。

任何 AI 補全內容必須在來源中標記：

{
  "origin": "ai_inferred",
  "confidence": 0.78,
  "requires_review": true
}

十六、語義正規化

EML 轉譯流程為：

I \xrightarrow{\rho} S \xrightarrow{\kappa} P_c^{\ast}

其中：

$I$ ：原始意圖；
$S$ ：規範化規格；
$P_c^{\ast}$ ：候選 CAIR。

正規化至少生成：

目標；
前置條件；
後置條件；
不變量；
資源；
權限；
風險；
驗證；
未決問題。

十七、自然語言候選修改

自然語言修改不得直接提交。

流程為：

\Delta_{\text{NL}} \rightarrow \Delta P_c^{\ast} \rightarrow \operatorname{Preview} \rightarrow \operatorname{Validate} \rightarrow \operatorname{Commit}

預覽必須顯示：

新增節點；
刪除節點；
新增或刪除連線；
型別變化；
效果變化；
權限變化；
不變量變化；
受影響區域；
是否可回滾。

第五部分　NOVA 張量—算子層

十八、NOVA 權威結構

NOVA 子圖表示為：

P_{\text{NOVA}}^{\ast} = (T,O,S,D,E,C)

其中：

$T$ ：張量；
$O$ ：算子；
$S$ ：形狀；
$D$ ：裝置與分布；
$E$ ：效果；
$C$ ：約束與證書。

NOVA 節點屬於 CAIR 節點的特化，而非另一套獨立權威資料庫。

十九、張量型別

張量型別表示為：

T: \operatorname{Tensor} [ dtype, shape, device, layout ]

例如：

X: \operatorname{Tensor} [ float32, (batch,features), GPU, rowmajor ]

形狀約束可寫為：

X.shape_1 = W.shape_0

MVP 可先支援：

固定維度；
命名維度；
未知維度；
簡單廣播；
矩陣乘法；
逐元素算子；
歸約算子。

二十、算子模型

算子定義為：

O = (id,signature,shapeRule,effectRule,gradRule,lowering)

其中：

signature：輸入輸出型別；
shapeRule：形狀推導；
effectRule：效果；
gradRule：微分規則；
lowering：後端映射。

第一版可包含：

add
multiply
matmul
sum
mean
reshape
transpose
relu

二十一、硬體適應

權威 NOVA 圖經適應器生成後端程式：

A_H(P_{\text{NOVA}}^{\ast}) = P_H

MVP 階段可先支援：

Python／NumPy 後端；
可選 PyTorch 後端；
CPU 執行；
基本算子融合提示；
執行成本估計。

第一版的核心不是追求最高性能，而是驗證：

\text{權威算子圖} \rightarrow \text{多投影} \rightarrow \text{可執行後端}

第六部分　多重投影層

二十二、投影器介面

每個投影器應實作：

interface Projector {
  id: string;
  kind: string;
  lossiness: "lossless" | "conditional" | "lossy" | "generative";
  canWrite: boolean;

  project(program: CAIRProgram, context: ProjectionContext): ProjectionResult;
  explainCoverage(program: CAIRProgram): CoverageReport;
}

投影器必須聲明：

投影類型；
是否可回寫；
可表示子集；
省略資訊；
需要權限；
版本；
內容指紋。

二十三、文字投影

文字投影是 CAIR 的可讀結構化表示。

MVP 可採用 YAML 或自訂簡化 DSL，例如：

region main {
  value x: Number = 1
  value y: Number = 2
  operator add(x, y) -> sum
}

文字投影需要滿足：

\rho_{\text{text}} \left( \pi_{\text{text}}(P^{\ast}) \right) = P^{\ast}

至少在 MVP 支援子集內保持往返性。

二十四、圖投影

圖投影顯示：

節點；
型別化端口；
資料邊；
控制邊；
驗證邊；
區域；
權限標記。

布局資訊應獨立保存：

L_{\text{graph}} \not\subset P_{\text{semantic}}

除非使用者明確切換到「語義空間模式」。

二十五、格子投影

格子投影提供：

自由選域；
區域折疊；
邊界；
端口；
Agent 與 Skill 區域；
沙盒與正式區域；
局部治理；
多尺度顯影。

格子操作分為兩種模式：

25.1 布局模式

只修改：

\Delta_{\text{layout}}

不改變權威語義。

25.2 語義模式

可修改：

區域包含；
邊界；
端口；
權限；
耦合；
執行域。

任何語義模式操作都必須進入候選差異流程。

二十六、自然語言投影

自然語言投影屬於有損或生成式投影。

其輸出必須附帶：

權威版本；
內容指紋；
模型版本；
適用範圍；
省略項目；
可展開來源節點。

自然語言投影不可默認具有直接回寫權。

二十七、投影證書

投影證書定義為：

C_{\pi} = (id,root,version,projector,lossiness,coverage,hash,time)

證書用於回答：

這個投影來自哪個權威版本？
是否完整？
是否可回寫？
是否仍與最新版本同步？
使用哪個投影器生成？
是否經過 AI 生成？

第七部分　回寫與語義差異

二十八、回寫器介面

interface WritebackAdapter {
  id: string;
  projectionKind: string;

  propose(
    baseProgram: CAIRProgram,
    projection: ProjectionState,
    userChange: ProjectionChange
  ): ChangeProposal;
}

回寫器只產生候選修改，不直接提交。

二十九、修改提案模型

修改提案定義為：

\Delta = (id,b,a,s,o,r,e,v)

其中：

$b$ ：基底版本；
$a$ ：作者；
$s$ ：來源投影；
$o$ ：操作集合；
$r$ ：修改理由；
$e$ ：證據；
$v$ ：驗證狀態。

第一版操作種類包括：

add_node
remove_node
update_node
add_edge
remove_edge
update_edge
create_region
move_to_region
update_policy
add_constraint
remove_constraint

三十、語義差異

語義差異表示為：

\operatorname{diff}_{\ast} (P_a^{\ast},P_b^{\ast}) = ( \Delta N, \Delta E, \Delta R, \Delta T, \Delta F, \Delta G, \Delta C )

其中：

$\Delta N$ ：節點；
$\Delta E$ ：邊；
$\Delta R$ ：區域；
$\Delta T$ ：型別；
$\Delta F$ ：效果；
$\Delta G$ ：治理；
$\Delta C$ ：約束。

使用者介面應優先呈現語義差異，而非只呈現文字行差異。

三十一、影響分析

每一修改提案都應計算影響閉包：

\operatorname{Impact}(\Delta) = \operatorname{Reachable} ( \Delta, E_{\text{dependency}} )

影響分析包括：

直接受影響節點；
下游資料依賴；
上游型別依賴；
區域邊界；
權限；
驗證器；
執行後端；
投影失效範圍。

三十二、結構化合併

三方合併表示為：

P_m^{\ast} = \operatorname{Merge} ( P_0^{\ast}, \Delta_a, \Delta_b )

衝突類型包括：

同一欄位不同值；
刪除與修改；
型別不兼容；
端口失效；
區域邊界衝突；
權限衝突；
合併後不變量失效；
投影不可表示。

MVP 可先採用：

結構識別碼對齊；
操作序列合併；
衝突標記；
人工解決；
合併後重新驗證。

第八部分　控制治理層

三十三、治理契約模型

治理契約定義為：

C_g = (I,S,P,A,V,L,Q,R)

其中：

$I$ ：意圖；
$S$ ：規格；
$P$ ：權限；
$A$ ：允許操作；
$V$ ：驗證；
$L$ ：日誌；
$Q$ ：中止與升級；
$R$ ：回滾。

三十四、控制權模型

控制主體集合為：

\mathcal{A} = \{H,C,R,A,E\}

控制面包括：

意圖；
規格；
生成；
調度；
執行；
驗證；
治理；
撤回。

控制矩陣為：

K=[k_{ij}]

MVP 不必實作完整數值矩陣，可先以角色與能力集合表示。

三十五、能力模型

能力表示為：

cap = (resource,action,scope,constraint)

例如：

{
  "resource": "region:analysis",
  "action": "write",
  "scope": "local",
  "constraint": {
    "risk_level_max": 1
  }
}

三十六、最小必要權限

Agent 或 Skill 的權限集合應為：

P_A^{\ast} = \min \left\{ P \mid P\text{ 足以完成任務} \right\}

MVP 可採預先定義權限模板：

read_only
propose_changes
edit_sandbox
execute_sandbox
commit_low_risk
admin

三十七、最小必要自主性

自主性分為：

目標分解；
計畫生成；
工具選擇；
操作執行；
結果接受。

MVP 中 AI 僅擁有：

\text{候選生成權} + \text{說明權}

不預設擁有：

\text{提交權} + \text{外部執行權}

三十八、風險分級

風險函數為：

R(a) = \alpha I(a) + \beta U(a) + \gamma S(a) + \delta X(a)

其中：

$I$ ：影響範圍；
$U$ ：不可逆性；
$S$ ：敏感性；
$X$ ：外部性。

MVP 風險級別：

$L_0$ ：純閱讀；
$L_1$ ：本地可回滾修改；
$L_2$ ：跨區域寫入；
$L_3$ ：外部執行；
$L_4$ ：不可逆或物理世界操作。

第一版只自動允許 $L_0$ 與部分 $L_1$ 。

第九部分　AI 候選生成

三十九、AI 在系統中的角色

AI 可以：

解釋權威結構；
產生自然語言投影；
將意圖轉為候選規格；
產生候選節點與連線；
建議區域切分；
建議型別與驗證器；
產生測試；
解釋差異；
建議修復。

AI 不應直接：

修改權威版本；
提交高風險操作；
自行擴大權限；
隱藏驗證失敗；
修改意圖來源；
靜默改變治理契約。

四十、AI 生成流程

I \rightarrow Context \rightarrow Candidate \rightarrow Normalize \rightarrow Validate \rightarrow Preview

AI 生成結果必須包含：

候選操作；
理由；
信心；
未確定項目；
使用的來源；
預期影響；
建議驗證。

四十一、模型非權威

AI 輸出只是一個候選函數：

A: (I,Ctx,\theta) \rightarrow \mathcal{P}(\Delta)

權威性來自：

\text{CAIR} + \text{驗證} + \text{版本提交}

而非模型本身。

第十部分　驗證與證書

四十二、驗證管線

驗證器集合為：

\mathcal{V} = \{ V_{\text{schema}}, V_{\text{type}}, V_{\text{effect}}, V_{\text{permission}}, V_{\text{constraint}}, V_{\text{test}}, V_{\text{risk}} \}

執行順序可為：

Schema 驗證；
識別碼與引用完整性；
型別；
形狀；
效果；
權限；
區域邊界；
不變量；
測試；
風險。

四十三、驗證結果

驗證結果表示為：

V = (status,errors,warnings,evidence,certificate)

其中：

status：accepted、rejected、needs_review；
errors：阻斷錯誤；
warnings：警告；
evidence：測試、證明或分析；
certificate：內容指紋與驗證器版本。

四十四、等價性證書

當系統進行最佳化或投影往返時，可產生：

C_{eq} = (P,P',Q,V,h)

MVP 可先支援：

結構等價；
型別保持；
簡單輸出測試；
內容指紋；
投影往返測試。

四十五、內容指紋

權威版本指紋為：

h_t = H( \operatorname{CanonicalSerialize}(P_t^{\ast}) )

內容指紋應排除純布局資料，避免移動畫面造成權威版本變化。

布局可使用獨立指紋：

h_t^{layout}

第十一部分　儲存與版本

四十六、事件溯源模型

系統可採事件溯源：

P_t^{\ast} = P_0^{\ast} \oplus \Delta_1 \oplus \Delta_2 \oplus \cdots \oplus \Delta_t

每個事件保存：

基底版本；
作者；
來源投影；
操作；
時間；
理由；
驗證證書；
內容指紋。

四十七、快照

為避免每次重播全部事件，定期保存：

Snapshot_k = (P_k^{\ast},h_k)

回滾可使用：

P_t^{\ast} \xrightarrow{rollback(k)} P_k^{\ast}

四十八、第一版儲存方案

MVP 建議：

SQLite：權威資料、版本、提案、證書；
JSON：交換與匯出；
檔案系統：投影快取、執行輸出；
Git：文件、範例與外層專案版本；
可選內容尋址儲存：後續版本。

SQLite 適合第一版，因為：

單機；
交易；
易備份；
易檢查；
無需額外服務；
可逐步遷移到 PostgreSQL。

第十二部分　API 與插件

四十九、核心 API

第一版核心 API：

GET    /programs/:id
POST   /programs
GET    /programs/:id/versions
POST   /programs/:id/proposals
POST   /proposals/:id/validate
POST   /proposals/:id/commit
POST   /proposals/:id/reject
GET    /programs/:id/projections/:kind
POST   /programs/:id/projections/:kind/writeback
POST   /programs/:id/rollback
GET    /programs/:id/diff

五十、投影插件

投影插件必須聲明：

插件名稱；
支援版本；
投影類型；
有損性；
是否可回寫；
所需權限；
覆蓋性；
依賴；
驗證器。

五十一、驗證插件

驗證器介面：

interface Validator {
  id: string;
  version: string;
  validate(
    base: CAIRProgram,
    proposal: ChangeProposal,
    context: ValidationContext
  ): ValidationResult;
}

五十二、Skill 插件

Skill 插件應包含：

interface SkillDefinition {
  id: string;
  domain: string[];
  inputSchema: object;
  outputSchema: object;
  capabilities: Capability[];
  permissions: Permission[];
  validators: string[];
  failurePolicy: FailurePolicy;
}

Skill 不是直接執行任意程式，而是受治理的能力封裝。

第十三部分　MVP 技術棧

五十三、前端

建議：

React
TypeScript
Vite
React Flow 或等價節點圖框架
CodeMirror 6
Zustand 或輕量狀態管理
Zod 做前端 schema 驗證

前端包含四個主要面板：

文字投影；
圖／格子投影；
語義差異預覽；
驗證與版本面板。

五十四、後端

建議：

Python
FastAPI
Pydantic
SQLAlchemy
SQLite
NetworkX
可選 NumPy／PyTorch
pytest

Python 適合第一版，因為：

語義處理與 AI 整合成本低；
張量計算生態完整；
圖分析方便；
MVP 開發速度快。

五十五、模型接入

模型層應抽象為：

class CandidateGenerator:
    def propose(self, intent, context, schema) -> ChangeProposal:
        ...

模型供應商不應滲透到權威資料模型。

第一版甚至可以先使用：

規則式候選生成；
本地簡單模型；
手動輸入候選提案；

再接入外部大型模型。

五十六、執行後端

MVP 可支援：

純函數算術節點；
NumPy 張量節點；
沙盒式 Python 生成；
禁止外部網路；
禁止未授權檔案存取；
執行時間限制；
記憶體限制；
輸出捕獲。

執行層必須與權威編輯層隔離。

第十四部分　MVP 使用案例

五十七、案例一：文字與圖的往返

使用者在文字投影輸入：

value x: Number = 1
value y: Number = 2
operator add(x, y) -> total

系統生成 CAIR：

x \rightarrow add \leftarrow y

圖投影顯示兩個值節點與一個算子節點。

使用者在圖上新增 multiply 節點，系統生成候選差異，再更新文字投影。

五十八、案例二：自然語言候選修改

使用者輸入：

把 total 再乘以 10，輸出 result。

AI 或規則器生成：

新增常數節點 10；
新增算子 multiply；
連接 total 與 10；
新增輸出 result。

系統顯示語義差異後，使用者提交。

五十九、案例三：格子區域

使用者選取數個節點，建立區域：

Z_{\text{calculation}}

系統自動計算跨邊界邊，轉為輸入與輸出端口。

區域可設為：

可編輯；
只讀；
AI 建議；
沙盒執行。

六十、案例四：NOVA 張量圖

建立：

Y = \operatorname{ReLU}(XW+b)

系統顯示：

張量形狀；
算子圖；
形狀錯誤；
NumPy 執行；
文字投影；
格子區域。

第十五部分　測試策略

六十一、單元測試

至少包括：

節點 schema；
邊 schema；
端口兼容；
區域邊界；
型別推導；
內容指紋；
投影往返；
修改提案；
權限檢查；
回滾。

六十二、性質測試

重要性質包括：

62.1 投影往返

\rho_i(\pi_i(P^{\ast})) = P^{\ast}

62.2 無修改不變性

\delta_i(\varnothing) = \varnothing

62.3 布局非語義性

\Delta_{\text{layout}} \Rightarrow h(P^{\ast})\text{ 不變}

62.4 提案隔離

未提交提案不得改變權威程式。

62.5 回滾正確性

rollback(commit(P,\Delta)) = P

在可逆操作範圍內成立。

六十三、整合測試

完整流程：

建立權威程式；
生成文字投影；
解析回權威結構；
生成圖投影；
提交圖形修改；
驗證；
生成新版本；
更新文字投影；
執行；
回滾。

六十四、AI 測試

AI 候選生成需測試：

不直接提交；
不擴大權限；
未確定項目標記；
來源記錄；
結構合法性；
失敗時安全退化；
模型更換不影響權威資料格式。

第十六部分　里程碑

六十五、M0：資料模型

完成：

CAIR schema；
節點；
邊；
端口；
區域；
修改提案；
驗證結果；
版本模型。

六十六、M1：文字投影

完成：

CAIR JSON；
結構化文字 DSL；
解析；
往返測試；
內容指紋。

六十七、M2：圖與格子投影

完成：

節點圖；
型別端口；
區域；
布局與語義模式分離；
投影同步。

六十八、M3：語義差異與版本

完成：

修改提案；
語義 diff；
驗證；
提交；
回滾；
版本瀏覽。

六十九、M4：AI 候選生成

完成：

自然語言候選修改；
結構化輸出；
差異預覽；
來源與信心標記；
人工批准。

七十、M5：NOVA 最小張量層

完成：

張量節點；
形狀；
基本算子；
NumPy 執行；
張量圖投影；
形狀驗證。

七十一、M6：Skill 與局部治理

完成：

Skill schema；
能力；
權限模板；
區域治理；
沙盒執行；
驗證器插件。

第十七部分　風險與降級

七十二、權威 IR 過度複雜

風險：

資料模型過早膨脹；
所有概念都想放入核心；
MVP 無法完成。

策略：

核心只保留節點、邊、區域、型別、效果、權限、版本；
其他結構以擴展欄位與插件加入；
保持 schema 可演化。

七十三、投影債務

風險：

投影太多；
映射互相衝突；
同步成本過高。

策略：

MVP 只支援文字、圖／格子與自然語言說明三類；
每個投影必須聲明有損性；
不允許投影維護獨立權威副本。

七十四、AI 語義漂移

風險：

相同意圖生成不同結構；
模型版本改變語義；
AI 靜默補全重要條件。

策略：

AI 僅生成候選；
規範化輸出；
記錄模型版本；
標記推定項；
需要差異預覽與驗證。

七十五、圖形規模爆炸

風險：

大型程式節點與連線過多；
視覺化失去可讀性。

策略：

區域折疊；
自動選域；
類型篩選；
依賴高亮；
動態顯影；
多尺度視圖。

七十六、治理複雜度

風險：

權限系統過於複雜；
使用者無法理解。

策略：

MVP 使用少量權限模板；
高階規則延後；
任何外部執行默認禁止；
用區域顏色以外的明確文字與圖標標示治理狀態。

七十七、執行安全

風險：

生成程式存取檔案、網路或系統；
無限執行；
資源耗盡。

策略：

沙盒；
逾時；
記憶體限制；
禁止網路；
能力白名單；
執行與主服務隔離；
輸入輸出 schema。

七十八、安全退化

任何層失敗時，系統應有穩定退路：

\text{AI 失敗} \rightarrow \text{手動結構化輸入}

\text{圖投影失敗} \rightarrow \text{文字投影}

\text{硬體適應失敗} \rightarrow \text{CPU 基準執行}

\text{投影回寫失敗} \rightarrow \text{保留候選、不提交}

\text{驗證失敗} \rightarrow \text{拒絕並保留錯誤證據}

第十八部分　後續擴展

七十九、投影代數

後續可研究：

\pi_j\circ\pi_i

投影組合、限制、信息損失與可逆條件。

八十、語義差異代數

建立：

節點差異；
關係差異；
型別差異；
效果差異；
治理差異；
世界狀態差異。

八十一、控制型別

未來可將權限寫入型別：

Agent[ Generate, \neg Execute, ReviewRequired ]

或：

Skill: Input \xrightarrow{ \{read:file,\neg network\} } Output

八十二、世界狀態程式

CAIR 可擴展為：

W_t = (X_t,R_t,\Phi_t,H_t,G_t)

使程式不只描述靜態圖，也描述：

事件；
時間；
世界線；
分支；
回滾；
反事實；
場。

八十三、動態顯影

未來投影層可根據：

A(x,t) = f( task, risk, role, anomaly, dependency )

動態決定顯示細節。

第十九部分　總結

本白皮書提出一套以 CAIR 為核心的多重投影程式系統架構。

其核心結構為：

\boxed{ \text{CAIR 權威本體} + \text{EML 語義轉譯} + \text{NOVA 張量算子} + \text{格子與圖投影} + \text{可驗證回寫} + \text{局部治理} + \text{版本與證書} }

此架構的關鍵不在於製作一個新的視覺化編輯器，也不在於讓 AI 直接取代程式設計者，而在於建立一個共同的權威計算結構，使人類、AI、編譯器與運行時可以透過不同投影共同操作，同時保持：

程式同一性；
語義可追溯；
修改可預覽；
執行可驗證；
權限可控制；
失敗可回退；
版本可回滾；
模型可替換。

第一版 MVP 的最小成功標準不是完成一種通用新語言，而是證明以下閉環可以穩定成立：

\text{權威 IR} \rightarrow \text{文字與圖投影} \rightarrow \text{候選修改} \rightarrow \text{語義差異} \rightarrow \text{驗證提交} \rightarrow \text{多投影同步}

一旦此閉環成立，EML、NOVA、格子語言、Skill、動態顯影與世界狀態系統便可逐步接入，而不必各自建立互不兼容的權威核心。

最終，本系統試圖實現的不是「讓所有人使用同一種程式語法」，而是：

讓不同人類、AI、工具與執行環境，能以各自最適合的表達方式，共同維護同一個可驗證、可治理並可持續演化的程式本體。

多重投影程式系統技術架構白皮書_v1.0