中文編程語言作為 AI 形式化語料基礎設施

從人類可用性爭論到機器學習資料價值的重新評估

作者：Neo.K、Aletheia（GPT）
版本：v0.1
日期：2026-07-24
文件類型：理論命題論文／研究綱領

摘要

過去對中文編程語言的討論，多集中於「是否有助於中文使用者學習程式設計」、「是否能降低英文門檻」以及「能否取代既有英文編程語言」等問題。若僅從這些角度觀察，中文編程語言往往顯得效益有限：它難以取代成熟的國際工具鏈，容易造成生態分裂，也可能只是將 if、else、print 等關鍵字機械翻譯為中文，而未真正改變計算模型。

然而，在大規模人工智慧、自然語言程式生成、形式化推理與智能體系統快速發展之後，中文編程語言的價值需要被重新評估。其核心價值可能不在於直接成為主流執行語言，而在於建立大規模、高品質、可驗證的「中文語義—形式結構—可執行結果」對齊語料。此類語料不只可以提升模型的中文能力，也能強化模型的意圖分解、約束保持、程序生成、執行驗證、錯誤定位與自我修正能力。

本文提出：中文編程語言應被重新理解為一種中文形式化語料基礎設施。其功能不是單純替換英文關鍵字，而是將中文自然語言、受控中文、形式中介表示、程式碼、測試案例、執行軌跡與修正紀錄連接為可訓練、可驗證、可持續擴張的資料系統。本文進一步提出語料價值模型、資料單元結構、生成流程、品質控制、評估框架與分階段建設路線，並討論其對中文 AI、形式化文明、跨語言模型與智能體系統的長期意義。

關鍵詞

中文編程語言、人工智慧訓練語料、形式化語言、自然語言程式設計、語義對齊、可執行語料、程序生成、智能體、形式化文明、受控自然語言

一、問題的重新提出

1.1 傳統問題設定

過去中文編程語言通常面臨以下質疑：

程式設計中的主要障礙不只是英文，而是抽象思維、資料結構與演算法。
主流函式庫、文件、社群與工具鏈多以英文為中心。
將英文關鍵字翻譯為中文，並不會自動改善程式設計能力。
中英文混用、術語不一致與輸入法切換，可能反而增加負擔。
中文語法若缺乏穩定形式規則，容易引入歧義。
新語言若沒有生態系，往往只能停留在教學或展示階段。

因此，傳統討論往往將問題表示為：

Q_{\text{old}} = \text{中文編程語言是否比英文編程語言更適合人類使用？}

在此問題設定下，答案通常不具決定性。中文編程語言或許能降低部分入門門檻，但很難取代 Python、JavaScript、C、Rust 或其他成熟語言。

1.2 AI 時代的新問題

當人工智慧開始大量學習自然語言、程式碼、形式化證明、工具操作與執行軌跡後，問題已經發生改變。真正重要的問題不再只是人類是否需要使用中文關鍵字，而是：

Q_{\text{new}} = \text{中文是否擁有足夠規模的形式化、可執行與可驗證語料？}

這個轉向十分重要。因為對 AI 而言，程式語言不只是工具，也是高密度的形式化訓練資料。程式碼包含明確語法、結構化控制流、型別關係、輸入輸出、錯誤訊息與可驗證結果。相較於一般自然語言，程式語料更接近可檢驗的因果與操作結構。

因此，中文編程語言的價值可從「人類介面」重新定位為「AI 訓練基礎設施」。

二、從文字語料到可執行語料

2.1 一般自然語言語料的限制

傳統自然語言模型主要從下列結構中學習：

\text{文字上下文} \rightarrow \text{下一段文字}

此類資料能讓模型學會語法、文體、概念關聯與常見推論，但未必能提供穩定的外部驗證。模型可能生成語意流暢的答案，卻不能保證其操作結果正確。

一般文字語料中的真實性、因果性與可操作性，往往需要額外判斷。即使一句話在語言上合理，也不代表它在形式系統中有效。

2.2 程式語料的特殊結構

程式語料則具有不同的資料鏈：

\text{需求} \rightarrow \text{程式} \rightarrow \text{執行} \rightarrow \text{結果}

若再加入測試與修正，則形成：

\text{自然語言意圖} \rightarrow \text{形式化表示} \rightarrow \text{程式碼} \rightarrow \text{測試案例} \rightarrow \text{執行結果} \rightarrow \text{錯誤分析} \rightarrow \text{修正版本}

這類資料不只是描述「某句話可能接續什麼」，而是在訓練模型理解：

某段自然語言對應何種操作；
某個操作是否滿足指定條件；
哪一項約束被遺漏；
錯誤出現在語法、語義、資料還是執行環境；
如何從失敗結果回推原始理解的偏差。

因此，可執行語料本質上是一種帶有外部回饋的形式學習資料。

三、中文編程語料的核心價值

3.1 建立中文到形式世界的直接映射

目前大量高品質的程式碼、API 文件、技術規格、形式化證明與錯誤訊息主要以英文表達。中文使用者與中文模型常需經過一層隱性轉換：

\text{中文} \rightarrow \text{英文概念代理} \rightarrow \text{形式結構}

這種路徑並非必然錯誤，但它意味著中文與形式世界之間缺乏足夠直接的資料連接。

若建立大規模中文編程語料，則可能形成：

\text{中文} \rightarrow \text{形式語義} \rightarrow \text{可執行結構}

此時，模型不再只是把中文翻譯成英文後再寫程式，而是能直接學習中文中的條件、時序、主體、權限、集合、例外、因果與約束如何映射到形式結構。

3.2 中文語義結構的形式化訓練

中文具有大量依賴語境、省略主詞、彈性詞序與隱含關係的表達方式。例如：

將尚未付款但已出貨的訂單找出來，排除已進入退款流程者，依照出貨時間由早到晚排列。

這段話至少包含：

訂單集合；
付款狀態條件；
出貨狀態條件；
排除條件；
排序鍵；
排序方向；
狀態互斥或重疊關係；
潛在的缺失資料處理。

其形式化可以表示為：

R = \operatorname{Sort}_{\text{ship\_time}\uparrow} \left( \left\{ x \in O \mid \neg \operatorname{Paid}(x) \land \operatorname{Shipped}(x) \land \neg \operatorname{Refunding}(x) \right\} \right)

若此類中文描述與形式結構、程式實作、資料樣例和測試結果大量對齊，模型將能更精確地學習中文語義中的結構性資訊。

3.3 不只是中文能力，而是一般推理能力

中文編程語料的作用不應被限縮為語言在地化。其真正訓練目標包含：

\text{意圖理解} + \text{任務分解} + \text{約束追蹤} + \text{程序生成} + \text{工具使用} + \text{結果驗證} + \text{錯誤修正}

若模型能從中文需求生成可執行程序，並透過測試確認結果，它所獲得的能力將超出單純的中文生成。

因此，中文編程語料的價值可表示為：

V_{\text{corpus}} = V_{\text{language}} + V_{\text{formalization}} + V_{\text{execution}} + V_{\text{verification}} + V_{\text{repair}} + V_{\text{transfer}}

其中：

$V_{\text{language}}$ ：中文理解能力；
$V_{\text{formalization}}$ ：將自然語言轉換為結構化規則的能力；
$V_{\text{execution}}$ ：生成可運行程序的能力；
$V_{\text{verification}}$ ：依據測試與結果判斷正確性的能力；
$V_{\text{repair}}$ ：根據失敗訊息修正程序的能力；
$V_{\text{transfer}}$ ：將形式能力遷移到其他語言、領域與工具的能力。

四、中文編程語言不應只是關鍵字翻譯

4.1 低價值模式

最簡單的中文編程語言通常採用關鍵字替換：

如果 條件：
    顯示「成立」
否則：
    顯示「不成立」

其底層可能只等價於：

if condition:
    print("成立")
else:
    print("不成立")

此類設計具有一定教學價值，但對 AI 語料建設而言，資訊增益有限。因為它主要提供：

\text{中文詞彙} \leftrightarrow \text{英文關鍵字}

而不是：

\text{中文意圖} \leftrightarrow \text{形式語義} \leftrightarrow \text{執行行為}

4.2 高價值模式

高價值的中文編程系統應包含至少四個層次：

L_{\text{natural}} \rightarrow L_{\text{controlled}} \rightarrow L_{\text{IR}} \rightarrow L_{\text{executable}}

其中：

$L_{\text{natural}}$ ：自然中文需求；
$L_{\text{controlled}}$ ：受控中文或可消歧中文；
$L_{\text{IR}}$ ：形式化中介表示；
$L_{\text{executable}}$ ：Python、SQL、Rust、Shell、JavaScript 或其他可執行語言。

例如，自然中文：

每天凌晨整理前一天的錯誤紀錄；相同錯誤合併計數；若某類錯誤超過一百次，通知維運人員，但測試環境不通知。

可轉換為受控中文：

排程：每日 00:00 執行。
資料範圍：前一自然日。
分組欄位：錯誤類型。
聚合方法：計數。
通知條件：計數 > 100。
排除條件：環境 = 測試。
通知對象：維運人員。

再映射為中介表示：

trigger:
  type: cron
  value: "0 0 * * *"

source:
  dataset: error_logs
  time_range: previous_calendar_day

transform:
  group_by:
    - error_type
  aggregate:
    count: true

filter:
  - count > 100
  - environment != "test"

action:
  type: notify
  target: operations_team

最後才生成實際程式。

這種多層結構能保留自然語言、形式化與執行之間的對齊關係，因而具有更高的訓練價值。

五、語料單元的最小結構

本文提出，理想的中文編程語料單元不應只有「中文—程式碼」兩欄，而應至少包含：

D = (I,C,F,P,T,X,E,R,M)

其中：

$I$ ：原始中文意圖；
$C$ ：消歧後的受控中文；
$F$ ：形式語義或中介表示；
$P$ ：可執行程式；
$T$ ：測試案例；
$X$ ：實際執行軌跡；
$E$ ：錯誤、例外或失敗結果；
$R$ ：修正紀錄；
$M$ ：來源、授權、版本、領域與品質等中繼資料。

5.1 原始中文意圖

應保留真實使用者可能輸入的自然中文，包括：

口語；
書面語；
簡略指令；
不完整描述；
多義敘述；
地區性用語；
繁體與簡體；
專業術語；
中英混合表達。

這一層可讓模型學習真實世界中的語言分布。

5.2 受控中文

受控中文負責顯性化原始需求中的隱含條件。它不必取代自然中文，而是作為可檢查的語義橋梁。

例如：

最近三個月收入下降的產品。

可能需要進一步澄清：

最近三個完整自然月，或最近九十日；
以總收入、平均收入或月末收入判斷；
「下降」是連續下降，還是期初高於期末；
缺少月份資料時如何處理。

受控中文應明確記錄這些決策。

5.3 形式語義與中介表示

形式語義負責將需求轉換為穩定結構。它可以採用：

抽象語法樹；
JSON；
YAML；
邏輯規則；
關係代數；
狀態機；
工作流圖；
型別化操作節點；
領域特定語言；
矩陣式或圖式中介表示。

此層是自然語言與執行語言之間最重要的對齊核心。

5.4 測試、錯誤與修正

語料中必須保留失敗樣本。若只保留正確程式，模型只能學習成功結果，卻無法充分學習：

哪些理解是錯的；
哪一條中文約束被遺漏；
哪一種錯誤來自歧義；
如何根據測試結果定位問題；
如何進行最小修正。

因此，完整資料鏈應包含：

I \rightarrow P_0 \rightarrow E_0 \rightarrow A_0 \rightarrow P_1 \rightarrow E_1 \rightarrow \cdots \rightarrow P_n

其中 $P_0$ 為初始程式， $E_i$ 為第 $i$ 次錯誤或測試結果， $A_i$ 為錯誤分析， $P_n$ 為最終通過驗證的版本。

六、失敗語料的高價值性

6.1 程式錯誤不只是一種錯誤

在中文程式生成中，錯誤至少可分為：

E = E_{\text{syntax}} \cup E_{\text{semantic}} \cup E_{\text{constraint}} \cup E_{\text{data}} \cup E_{\text{runtime}} \cup E_{\text{environment}}

其中：

$E_{\text{syntax}}$ ：語法錯誤；
$E_{\text{semantic}}$ ：語意映射錯誤；
$E_{\text{constraint}}$ ：遺漏或違反需求約束；
$E_{\text{data}}$ ：資料格式、缺值或邊界條件錯誤；
$E_{\text{runtime}}$ ：執行期間錯誤；
$E_{\text{environment}}$ ：權限、版本、依賴或平台錯誤。

傳統程式資料常重視語法與執行錯誤，但中文形式化語料還必須特別保存語意與約束錯誤。

6.2 約束遺漏是關鍵訓練訊號

假設需求為：

找出所有尚未付款且已出貨的訂單，但排除測試帳號建立的資料。

模型生成的程式若只包含前兩項條件，程式仍可能正常執行，甚至通過部分測試，但它在語意上是不完整的。

因此，語料系統應能標記：

missing_constraint:
  source_text: "排除測試帳號建立的資料"
  expected_field: creator_account_type
  expected_operator: "!="
  expected_value: test

這類資料能訓練 AI 從「可運行」提升到「符合意圖」。

七、語料建設流程

7.1 基本流程

中文形式化語料的生成流程可表示為：

G = S \rightarrow N \rightarrow A \rightarrow F \rightarrow P \rightarrow T \rightarrow V \rightarrow R \rightarrow Q

其中：

$S$ ：蒐集原始需求；
$N$ ：正規化與語言標註；
$A$ ：歧義分析；
$F$ ：形式化；
$P$ ：程式生成；
$T$ ：測試生成；
$V$ ：執行驗證；
$R$ ：錯誤修正；
$Q$ ：品質評分。

7.2 資料來源

可用資料來源包括：

真實工作流程需求；
教學題目；
軟體規格；
API 使用案例；
資料庫查詢需求；
自動化任務；
系統管理腳本；
數學與邏輯問題；
法律與政策規則；
工業控制流程；
遊戲規則；
模擬器與狀態機；
公開程式專案的 issue 與需求描述；
人機協作過程中的修改紀錄；
AI 自動生成並經驗證的合成樣本。

7.3 AI 生成與人類驗證

由於語料規模可能非常龐大，完全依賴人工作業並不實際。可採用：

\text{AI 生成} + \text{自動執行} + \text{測試驗證} + \text{抽樣人工審核}

但必須避免將模型自身錯誤無限制回灌。可建立多模型交叉審查、規則檢查、形式驗證與測試覆蓋率控制。

八、品質控制與可信度

8.1 語料品質不是單一分數

每個資料單元可具有多維品質向量：

Q(D) = (q_l,q_f,q_p,q_t,q_e,q_r,q_s)

其中：

$q_l$ ：中文表達品質；
$q_f$ ：形式化正確性；
$q_p$ ：程式正確性；
$q_t$ ：測試充分性；
$q_e$ ：執行可重現性；
$q_r$ ：修正紀錄完整性；
$q_s$ ：安全與授權合規性。

8.2 可重現性

每個樣本應記錄：

執行環境；
語言版本；
套件版本；
作業系統；
隨機種子；
輸入資料；
預期輸出；
實際輸出；
超時與資源限制。

只有可重現的可執行語料，才具有長期訓練與評測價值。

8.3 語義一致性

中文意圖與程式結果之間應建立雙向檢查：

\operatorname{Compile}(I)=P

以及：

\operatorname{Explain}(P)\approx I

也就是不只要能從中文生成程式，也要能從程式反向生成中文解釋，並檢查二者是否保持同一組核心約束。

九、評估框架

中文編程語料建設完成後，不應只以程式是否可執行作為評估標準。

9.1 基本指標

一、語義保持率

S_{\text{retain}} = \frac{\text{被正確保留的需求約束數}} {\text{原始需求約束總數}}

二、可執行率

R_{\text{exec}} = \frac{\text{成功執行樣本數}} {\text{生成樣本總數}}

三、測試通過率

R_{\text{test}} = \frac{\text{通過全部測試的樣本數}} {\text{可執行樣本數}}

四、修正成功率

R_{\text{repair}} = \frac{\text{經錯誤回饋後成功修正的樣本數}} {\text{初次失敗樣本數}}

五、歧義偵測率

R_{\text{ambiguity}} = \frac{\text{被正確標記的實質歧義數}} {\text{全部實質歧義數}}

六、跨語言遷移率

觀察模型在中文形式語料訓練後，是否提升英文、日文或其他語言的程序生成與約束保持能力。

9.2 高階評估

更高階的評估應測試模型是否能：

主動指出需求缺失；
產生反例；
生成邊界測試；
解釋程式與需求間的偏差；
對高風險指令要求確認；
在多輪修改中保持未變更的約束；
將中文需求編譯為不同後端語言；
將同一形式語義重新表達為不同自然語言。

十、風險與限制

10.1 歧義固化

若受控中文或形式化過程錯誤，語料可能將錯誤解釋固化為標準答案。這會造成：

\text{自然語言歧義} \rightarrow \text{錯誤形式化} \rightarrow \text{大規模訓練偏差}

因此，資料中應保留歧義候選與決策理由，而非只保留單一結果。

10.2 中文術語標準化問題

不同地區、產業與社群對同一技術概念可能使用不同譯名。系統不應過早強制單一術語，而應建立：

\text{多表達} \rightarrow \text{同一概念節點}

例如「執行緒」、「線程」可映射至同一形式概念，但保留地區與語境標記。

10.3 合成資料退化

大量使用 AI 生成資料可能造成樣本風格單一、錯誤重複與資訊退化。因此需要：

真實資料與合成資料混合；
多模型生成；
多語言交叉映射；
執行驗證；
人類抽樣；
失敗樣本保留；
分布多樣性監測。

10.4 安全問題

自然語言到程式碼的系統具有直接執行風險。訓練與部署環境應採取：

沙盒；
權限分層；
資源限制；
網路隔離；
危險操作攔截；
敏感資料遮罩；
執行前計畫顯示；
高風險操作人工確認。

十一、分階段建設路線

11.1 第一階段：中文受控編程資料集

先選擇低風險、易驗證領域：

資料轉換；
表格處理；
SQL 查詢；
檔案整理；
基礎演算法；
教學題目；
純函式計算。

目標是建立：

\text{中文需求} \leftrightarrow \text{受控中文} \leftrightarrow \text{中介表示} \leftrightarrow \text{測試}

11.2 第二階段：多後端編譯

讓同一中文形式語義可編譯到：

Python；
JavaScript；
SQL；
Shell；
Rust；
工作流系統；
自動化平台。

此階段可測試語義與實作語言之間是否真正解耦。

11.3 第三階段：修正與執行軌跡資料

大量保存：

首次生成；
編譯錯誤；
測試失敗；
錯誤分析；
修正補丁；
最終版本；
需求變更歷史。

這將形成 AI 自我修正訓練的高價值資料。

11.4 第四階段：跨領域形式化

擴張到：

法規；
公共政策；
財務規則；
合約條件；
工業流程；
醫療行政流程；
科研工作流；
遊戲世界規則；
多智能體權限系統。

此階段的重點不再只是編程，而是中文形式化能力。

11.5 第五階段：多語言形式語義網路

最終目標不是建立封閉的中文系統，而是：

\text{中文} \leftrightarrow \text{共享形式語義} \leftrightarrow \text{其他自然語言}

中文可成為其中一個高複雜度語言節點，並與英文、日文、西班牙文、阿拉伯文及其他語言共同形成多語言可執行語義網路。

十二、理論命題

命題一：直接映射命題

當中文與形式結構之間存在足夠大規模且高品質的直接對齊資料時，模型不必完全依賴英文中介，即可形成中文到形式推理的穩定映射。

形式表示為：

\lim_{|D_{\text{zh-formal}}|\to\infty} \operatorname{Dependence} \left( \text{中文推理}, \text{英文中介} \right) \downarrow

此處並不主張英文中介將完全消失，而是其必要性可能下降。

命題二：形式語料增益命題

中文形式化語料的價值不只體現在中文任務上，也可能遷移至一般程序推理能力。

\Delta C_{\text{general}} = f \left( D_{\text{zh-formal}}, D_{\text{execution}}, D_{\text{repair}} \right) > 0

其中 $C_{\text{general}}$ 表示一般計算與推理能力。

命題三：失敗資料優勢命題

在相同規模下，包含錯誤、測試與修正軌跡的資料集，對程序修正能力的訓練價值高於只有最終正確答案的資料集。

V(D_{\text{trajectory}}) > V(D_{\text{final-only}})

命題四：語義基礎設施命題

中文編程語言的長期價值，主要不取決於其是否成為主流執行語言，而取決於它是否能成為中文自然語言與形式系統之間的穩定接口。

V_{\text{long-term}} \not\approx \text{市場占有率}

而更接近：

V_{\text{long-term}} \approx \text{形式語料規模} \times \text{語義品質} \times \text{可驗證性} \times \text{跨域遷移性}

十三、從中文編程到中文形式化文明

中文在文學、歷史、行政、哲學與日常溝通中累積了龐大語料，但在可執行規則、形式證明、標準化程序與機器可驗證結構方面，仍有很大的發展空間。

中文編程語料的建設，可能只是更大轉變的起點：

\text{中文敘述} \rightarrow \text{中文規則} \rightarrow \text{中文形式化} \rightarrow \text{中文可執行知識}

這種轉變並不意味著要消滅模糊性、文學性或語言彈性。相反地，它是在自然中文之外，增加一條通往形式世界的穩定通道。

未來的中文知識系統可同時保留：

原始文本；
語義圖；
形式規則；
可執行模型；
驗證紀錄；
版本演化；
多語言映射。

因此，中文編程語言的意義最終可能超越「用中文寫程式」，成為中文知識可計算化、可驗證化與可傳遞化的一部分。

十四、結論

過去認為中文編程語言意義有限，是建立在「它是否能取代英文編程語言」與「它是否能讓人類更容易學會程式設計」的問題框架上。在這個框架中，中文化關鍵字確實很難產生根本性價值。

但在 AI 時代，程式語言本身也是訓練資料，形式化規則也是認知結構，而執行與測試則提供可驗證回饋。因此，中文編程語言的真正價值可能不是作為一套孤立的程式語法，而是作為：

中文到形式語義的映射層；
中文可執行語料的生成系統；
AI 程序推理與修正能力的訓練來源；
中文知識形式化的基礎設施；
多語言共享形式語義網路中的重要節點。

最值得重視的命題是：

中文編程語言對人類直接使用的價值可能有限，但它作為 AI 形式化語料基礎設施的價值，可能遠高於過去的估計。

因此，未來值得建設的並不是單純把英文關鍵字翻譯成中文的語言，而是一個能持續生產下列資料鏈的系統：

\text{中文意圖} \rightarrow \text{受控中文} \rightarrow \text{形式語義} \rightarrow \text{程式} \rightarrow \text{測試} \rightarrow \text{執行} \rightarrow \text{錯誤} \rightarrow \text{修正}

當這條資料鏈達到足夠規模時，中文將不再只是 AI 的自然語言輸入之一，也將成為 AI 學習形式推理、程序生成與可驗證行動的重要語料來源。

附錄 A：建議資料格式範例

id: zhformal-000001
language:
  primary: zh-Hant
  variants:
    - zh-Hans

intent:
  raw: >
    找出所有尚未付款且已出貨的訂單，
    排除測試帳號建立的資料，
    並依出貨時間由早到晚排列。

controlled_chinese:
  dataset: 訂單
  include_conditions:
    - 付款狀態 != 已付款
    - 出貨狀態 = 已出貨
  exclude_conditions:
    - 建立者帳號類型 = 測試
  sort:
    field: 出貨時間
    order: 升冪

formal_ir:
  operation: filter_sort
  source: orders
  filters:
    - field: payment_status
      operator: "!="
      value: paid
    - field: shipping_status
      operator: "="
      value: shipped
    - field: creator_account_type
      operator: "!="
      value: test
  sort:
    field: shipping_time
    direction: ascending

targets:
  - language: sql
    code: |
      SELECT *
      FROM orders
      WHERE payment_status <> 'paid'
        AND shipping_status = 'shipped'
        AND creator_account_type <> 'test'
      ORDER BY shipping_time ASC;

tests:
  - name: 排除已付款訂單
  - name: 排除未出貨訂單
  - name: 排除測試帳號資料
  - name: 驗證排序方向
  - name: 驗證空集合

execution:
  status: passed
  environment:
    database: sqlite
    version: "3.x"

revision_history:
  - version: 0
    issue: 遺漏測試帳號排除條件
  - version: 1
    status: passed

metadata:
  license: CC-BY-4.0
  domain: database_query
  difficulty: basic
  verified: true

附錄 B：後續研究方向

中文受控編程語法設計；
中文語義中介表示標準；
繁體、簡體與地區術語映射；
中文程式語料品質評分模型；
中文需求歧義自動偵測；
中文需求到測試案例的生成；
錯誤軌跡與修正資料標準；
中文形式語料對一般推理能力的實證研究；
中文、英文與其他語言的形式語義共享；
中文編程語料開源治理、授權與安全框架。

中文編程語言作為AI形式化語料基礎設施_v0.1