# 多重投影程式系統技術架構白皮書：權威 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{局部治理} $$ 具體而言，系統應能： 1. 以結構化權威 IR 保存程式的節點、關係、型別、效果、權限、來源與歷史。 2. 將同一權威程式投影為文字、圖、格子、自然語言、張量圖與治理視圖。 3. 允許使用者或 AI 從不同投影提出修改。 4. 將修改轉換為語義層候選差異，而非直接修改檔案。 5. 驗證修改是否符合型別、權限、效果、不變量與治理契約。 6. 顯示修改造成的結構、語義與治理影響。 7. 保存完整版本、來源、內容指紋、證書與回滾點。 8. 將 AI 的生成權與實際執行權分離。 9. 支援區域、邊界、端口、耦合與局部權限。 10. 為 EML、NOVA、格子語言與 Skill 提供共同技術底座。 --- ## 二、非目標 第一版系統不以以下事項為必要目標： 1. 取代 C、Python、Rust、JavaScript 等所有既有語言。 2. 直接編譯任意自然語言為高風險可執行操作。 3. 完成通用 AGI Agent 自主規劃平台。 4. 支援所有硬體與所有分散式後端。 5. 為所有程式轉換提供完整形式證明。 6. 建立完整虛擬世界或數位孿生運行時。 7. 實作所有 EML、NOVA 與格子語言的最終語法。 8. 在 MVP 階段允許 AI 無限制呼叫外部工具。 9. 以視覺化取代文字編輯器。 10. 以單一模型輸出作為權威語義來源。 --- ## 三、核心系統命題 本系統建立在下列關係上： $$ 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` 範例： ```json { "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 補全內容必須在來源中標記： ```json { "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{可執行後端} $$ --- # 第六部分　多重投影層 ## 二十二、投影器介面 每個投影器應實作： ```typescript 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，例如： ```text 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 生成？ --- # 第七部分　回寫與語義差異 ## 二十八、回寫器介面 ```typescript 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) $$ 例如： ```json { "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}} \} $$ 執行順序可為： 1. Schema 驗證； 2. 識別碼與引用完整性； 3. 型別； 4. 形狀； 5. 效果； 6. 權限； 7. 區域邊界； 8. 不變量； 9. 測試； 10. 風險。 --- ## 四十三、驗證結果 驗證結果表示為： $$ 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： ```text 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 ``` --- ## 五十、投影插件 投影插件必須聲明： - 插件名稱； - 支援版本； - 投影類型； - 有損性； - 是否可回寫； - 所需權限； - 覆蓋性； - 依賴； - 驗證器。 --- ## 五十一、驗證插件 驗證器介面： ```typescript interface Validator { id: string; version: string; validate( base: CAIRProgram, proposal: ChangeProposal, context: ValidationContext ): ValidationResult; } ``` --- ## 五十二、Skill 插件 Skill 插件應包含： ```typescript 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 驗證 前端包含四個主要面板： 1. 文字投影； 2. 圖／格子投影； 3. 語義差異預覽； 4. 驗證與版本面板。 --- ## 五十四、後端 建議： - Python - FastAPI - Pydantic - SQLAlchemy - SQLite - NetworkX - 可選 NumPy／PyTorch - pytest Python 適合第一版，因為： - 語義處理與 AI 整合成本低； - 張量計算生態完整； - 圖分析方便； - MVP 開發速度快。 --- ## 五十五、模型接入 模型層應抽象為： ```python class CandidateGenerator: def propose(self, intent, context, schema) -> ChangeProposal: ... ``` 模型供應商不應滲透到權威資料模型。 第一版甚至可以先使用： - 規則式候選生成； - 本地簡單模型； - 手動輸入候選提案； 再接入外部大型模型。 --- ## 五十六、執行後端 MVP 可支援： 1. 純函數算術節點； 2. NumPy 張量節點； 3. 沙盒式 Python 生成； 4. 禁止外部網路； 5. 禁止未授權檔案存取； 6. 執行時間限制； 7. 記憶體限制； 8. 輸出捕獲。 執行層必須與權威編輯層隔離。 --- # 第十四部分　MVP 使用案例 ## 五十七、案例一：文字與圖的往返 使用者在文字投影輸入： ```text 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 $$ 在可逆操作範圍內成立。 --- ## 六十三、整合測試 完整流程： 1. 建立權威程式； 2. 生成文字投影； 3. 解析回權威結構； 4. 生成圖投影； 5. 提交圖形修改； 6. 驗證； 7. 生成新版本； 8. 更新文字投影； 9. 執行； 10. 回滾。 --- ## 六十四、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、工具與執行環境，能以各自最適合的表達方式，共同維護同一個可驗證、可治理並可持續演化的程式本體。