【2026 最新】Compile by Training 是什麼？把自然語言規格編譯成本機神經函式

如果一個客服分類器每天要跑十萬次，你可以每次把文字送到大模型 API，也可以先花一次成本，把「怎麼分類」編譯成一個小型神經函式，之後留在本機反覆執行。Compile by Training 想做的正是後者：不是把自然語言翻成可讀程式碼，而是用 Teacher 模型合成訓練資料，再把任務能力寫進一組 LoRA 權重。

這篇給第一次接觸 Program-as-Weights、但願意碰終端機的讀者。我們會用一個不含敏感資料的三分類函式，走完規格、編譯命令、同分布、邊界、OOD 與規格改版四組驗收，最後算出損益平衡與回滾條件。AlphaLab 本次在作者程式碼的固定 commit 上完成語法、CLI 與預設設定的靜態檢查；由於目前公開預設配方約需 40 GB accelerator memory，而且環境沒有 Teacher API 金鑰，下文不會把來源導讀冒充完整訓練結果。

先說結論：把 prompt 變成 weights，仍要先過四道閘門

• 任務閘門：只選狹窄、重複、允許機率誤差的文字函式；精確計算、權限與不可逆動作繼續用 deterministic code。
• 品質閘門：Teacher 合成資料不是答案本身。上線前必須用完全未參與訓練的 holdout，分開量 ID、edge case、OOD 與 spec drift。
• 資料閘門：後續輸入可以本機執行，但現行編譯流程會把規格送到 PAW 與 Teacher API；「本機 runtime」不等於「全流程私有」。
• 成本閘門：先要求 compiled function 達到相同品質，再把 Teacher、GPU、人工標註、驗收與未來重編一起放進 break-even。

Compile by Training＝自然語言規格＋Teacher 合成範例＋任務專屬 LoRA＋共享本機 Interpreter。

最好記的操作口訣是：規格寫一次、編譯一次、本機跑很多次；但發布前先用未見資料證明它值得跑。這也是它和一般 prompt、傳統規則函式最根本的差別。

Compile by Training 是什麼？它不是傳統編譯器

傳統編譯器把明確語法轉成另一種可執行表示，通常能追查每條規則；Compile by Training 接收的卻是自然語言 specification，輸出也是機率式模型產物。依原始論文，它先用較快的 Program-as-Weights compiler 產生 warm start 與 prompt scaffold，再讓 GPT-5.4-mini、GPT-5.5 這類 Teacher 生成任務專屬的輸入／輸出配對，最後只微調共享 Qwen3-0.6B Interpreter 上的 LoRA adapter。

完成後的 .paw 包含原規格、pseudo-program、prompt template、adapter 與 runtime metadata；共享的 0.6B 基礎模型不會重複塞進每個函式。新輸入交給 Python runtime 後，不必再呼叫 Teacher。這種設計比較像「為一份規格訓練一個很小的文字處理器」，不是把規格變成可形式驗證的 Python 函式。

如果你還不熟悉「大模型其實在預測下一個 token」這件事，先讀LLM 下一個 Token 預測器；若想知道為何把能力蒸餾到小模型，則可接著看模型蒸餾教學。Compile by Training 借用了類似的 Teacher–Student 直覺，但產物綁定的是一份函式規格。

83.6% 到底代表什麼？先把 benchmark 放回邊界

論文最吸睛的數字，是在特別挑出的 FuzzyBench-Hard 子集上，Compile by Training 的平均 LLM Exact Match（LEM）為 83.6%，較 fast PAW compiler 的 22.4% 高 61.2 個百分點。這個子集的挑選條件，本來就是 fast compiler 沒有任何「字串完全相同」輸出的規格，所以它是一場針對 baseline 弱點的壓力測試，不是完整 FuzzyBench，也不是一般產品流量。

名稱裡雖有 Exact Match，實際 LEM 是由 GPT-5.5 判斷輸出在語意上是否正確；GPT-5.5 同時也是其中一個 Teacher。作者用 128 個人工標註判斷驗證這個 judge，報告 97.7% accuracy 與 0.946 Cohen’s kappa，但沒有因此證明你的長尾輸入也會得到 83.6%。更重要的是，論文 v1 公開的 Evaluation 與 Appendix 沒有提供 runtime OOD、時間漂移或「改一條規格後其他行為是否跟著漂移」的結果。

因此，正確讀法是：作者證明「在一個選定的困難合成集合上，額外 Teacher supervision＋LoRA training 能大幅救回 fast compiler」；你仍要自己證明「對我的資料、風險與改版頻率，這個 artifact 可以上線」。需要先補 Eval 基礎，可看AI Evals 完整教學。

動手前先看三個現實條件

1. 公開 repo 的預設配方很重

截至 2026 年 9 月 7 日，官方 repo commit 0401a7e要求 Python 3.10+、uv、可用的 Teacher API key 與編譯期網路。README 把預設本機配方定位在約 40 GB 可用 accelerator memory；較小裝置可降低 --micro-batch-size 或開 --gradient-checkpointing，代價通常是更慢。先讀本機 LLM VRAM 指南，不要只看 0.6B 就認為訓練一定適合 16 GB 電腦。

2. 論文配方與現行 script 不能混成一組數字

論文 Appendix A 寫的是 2,400 組合成配對擴成 6,400 個 training examples；現行 compile.py 預設則要求 2,400 組 GPT-5.4-mini 加 1,200 組 GPT-5.5 配對，並建立 100 steps × batch 48，也就是 4,800 筆訓練排程。repo 沒有 lockfile，公開 script 也會先完成全部合成、才開始訓練，和論文所述的託管式平行管線不同。換句話說，README quickstart 可以教你走流程，不能單憑一句「defaults reproduce」就宣稱復刻論文的時間或分數。

3. 產物可固定，不代表重編行為必然相同

一個完成的 .paw 可以雜湊、封存並回滾；但 Teacher 在 temperature 1.0 生成資料，供應商模型與相依套件也可能更新。即使程式碼設了 seed，論文仍沒有同一規格多次 cold compile 的一致性分布。生產環境要保存 artifact hash，而不是假設下個月重打一遍 prompt 就會得到同一個函式。

7 步編譯一個無敏感資料的三分類函式

第 1 步：先把輸出空間寫死

我們把虛構產品回饋分成 bug、feature、other。規格只描述公開、低風險的語意，不含客戶姓名、真實 ticket、內部政策或金鑰：

Classify fictional product feedback into exactly one lowercase label:
bug, feature, or other.

bug: an existing behavior is broken, wrong, or fails.
feature: the user requests a new behavior or capability.
other: praise, a question, or unrelated text.

If bug and feature both apply, return bug.
Return the label only. Never add punctuation or explanation.

「只能回傳三個 label」和「雙意圖時 bug 優先」都能直接驗收。若你的需求無法寫出允許輸出、衝突優先序與失敗策略，先別進到訓練。

第 2 步：固定程式碼，再看配置

git clone https://github.com/programasweights/compile-by-training.git
cd compile-by-training
git checkout 0401a7e28ff81d5c65e72ffc515c180f5633c4e7

mkdir -p specs artifacts/v1
uv run compile.py --help
uv run compile.py --print-config > artifacts/v1/recipe.json
uv tree --script compile.py --format json \
  > artifacts/v1/dependencies.json

先保存 --print-config 輸出與 resolved environment；這兩個命令不會提交編譯工作。AlphaLab 已在該 commit 驗證 py_compile、--help 與 --print-config 可通過，但截至 2026 年 9 月 7 日未呼叫 PAW、OpenAI、下載訓練模型、產生 adapter，也未驗證一次未快取端到端編譯當日能完成。所以下一段是固定來源的操作入口，不是服務可用性跑分。

第 3 步：把 spec、Teacher 資料與 adapter 都保存

把上一段存成 specs/feedback-v1.txt，以你的秘密管理方式設定 OPENAI_API_KEY，再於符合資源條件的隔離環境執行：

uv run compile.py \
  --spec-file specs/feedback-v1.txt \
  --save-examples artifacts/v1/teacher-examples.json \
  --keep-adapter artifacts/v1/adapter \
  --json \
  -o artifacts/v1/feedback.paw

shasum -a 256 artifacts/v1/teacher-examples.json \
  > artifacts/v1/teacher-examples.sha256

最後一行是 macOS 的 SHA-256 指令；Linux 通常改用 sha256sum artifacts/v1/teacher-examples.json。雜湊值不能證明資料「正確」，但能證明日後審查與回滾時看的仍是同一份 Teacher 樣本。

現行 script 在預設值下會以每批 8 筆，要求 3,600 組 Teacher 配對，名義上是 450 次成功的初始 API request；重試與補件還可能增加。它只檢查 JSON 結構與筆數，不會替你判定 label 是否合理或資料是否重複，所以 teacher-examples.json 必須另做抽樣與類別覆蓋檢查。

第 4 步：安裝 runtime，先連網準備資產

pip install "programasweights==0.4.4" \
  --extra-index-url https://pypi.programasweights.com/simple/

import programasweights as paw

classifier = paw.function("<compiler 印出的 program-id>")
print(classifier("The export button crashes every time."))

第一次載入可能仍需下載共享 Interpreter。確認 program 與 base assets 都進入 cache 後，再依官方 local inference 文件用 PAW_OFFLINE=1 啟動，並在 OS 或容器層封鎖 egress；若推理仍成功，可確認執行不依賴外網。若還要確認程式沒有發出連線嘗試，再查網路事件或系統呼叫。

第 5 步：訓練前封存四組 holdout

不要從 Teacher 結果切一塊當測試集。你要在合成與訓練前，自己寫好並封存：

• ID：與預期日常流量相同語言、長度與類別比例。
• Edge：否定句、雙意圖、空字串、格式噪音、拼字錯誤與超長輸入。
• OOD：新語言、新產品、新使用者群、時間漂移或訓練模板沒涵蓋的表達。
• Spec revision：刻意設計只有 v2 應改變的案例，以及 v1、v2 都應保持不變的 invariant cases。

為了測規格改版，假設 v2 只改一條：同一則輸入若同時包含 bug 與 feature，從原本的 bug 優先改為 feature 優先。測例可以長這樣：

{"slice":"id","input":"The search page stays blank","gold":"bug"}
{"slice":"edge","input":"Not broken; please add dark mode","gold":"feature"}
{"slice":"ood","input":"La app se cierra al abrir ajustes","gold":"bug"}
{"slice":"spec_revision_expected_change","input":"Export crashes; add CSV","gold_v1":"bug","gold_v2":"feature"}
{"slice":"spec_revision_invariant","input":"Are you open on weekends?","gold_v1":"other","gold_v2":"other"}

第 6 步：用 slice accuracy 與 drift 決定能不能上線

每個 slice 分開算 correct / total，再列出 confusion matrix；不要讓大量容易的 other 把少數但高風險的 bug 錯誤沖淡。對 v2，至少同時報告兩個數字：

• expected change rate：規格明確要求改變的案例，有多少真的從 v1 轉成正確 v2 輸出。
• unintended drift rate：應保持不變的 invariant cases，有多少在 v2 無故換答案。

由於 fresh compile 的一致性尚未被論文量化，正式導入時應用不同冷 cache 重編多次，把 build-to-build disagreement 也列入報告。通過門檻要在看結果前訂好，例如「bug slice 不低於 98%、OOD 不低於 90%、非預期 drift 低於 0.5%」；真正數值要按錯誤成本決定，不能照抄別人的門檻。

第 7 步：把神經函式放進 deterministic 外殼

runtime 的回傳值仍是字串。應先 strip().lower()，只接受 {bug, feature, other} allowlist；超時、空值、額外文字或未知 label 一律進 fallback。真正的權限、計費、刪除與通知邏輯，由一般程式碼決定。這就是deterministic core、probabilistic edge：讓模型做模糊判斷，讓規則保護不可逆邊界。

版本化與回滾：不要只保存最後一個 .paw

feedback-classifier/
├── specs/feedback-v1.txt
└── artifacts/v1/
    ├── recipe.json
    ├── dependencies.json
    ├── teacher-examples.json
    ├── teacher-examples.sha256
    ├── adapter/
    ├── feedback.paw
    ├── holdout.jsonl
    └── report.json

report.json 至少記錄 source commit、resolved dependencies、Teacher 名稱、compiler snapshot、artifact SHA-256、四組分數、build disagreement、編譯開始／完成時間與核准人。v2 通過 shadow traffic 前，v1 artifact、runtime base hash 與啟動方式都不能刪。回滾是重新載入已驗證的舊 artifact，不是臨時把舊 prompt 貼回去再重編。

若你想把這些 receipt、狀態與 stop condition 納入完整執行層，可沿用AI Agent Harness 實作教學；若想把 repo 變成團隊可重跑的作業流程，則可參考Repo 轉 Skill 的驗收思路。

Break-even 怎麼算？品質先行，成本第二

把每次都呼叫遠端模型的總成本記為 N × C_remote；compiled function 則是一次性的編譯與 QA，加上每次本機執行與預期重編：

N_break-even = ceil((C_compile + C_QA + C_recompile) / (C_remote − C_local))

C_compile 要包含 Teacher token、GPU 時間與工程工時；C_QA 包含 holdout 標註、失敗分析與核准；C_recompile 則是同一比較期間內的預期重編次數，乘上每次完整重編與回歸驗收成本。若 C_remote ≤ C_local，分母不為正，就沒有成本損益點；若 compiled function 沒過同一品質門檻，更不用進入這條公式。

在試算表中，令 B2＝遠端單次成本、B3＝本機單次成本、B4＝編譯成本、B5＝QA 成本、B6＝同一期間的預期重編總成本：

=IF(B2<=B3,
    "無損益點",
    ROUNDUP((B4+B5+B6)/(B2-B3),0))

隱私決策：哪些資料會離開本機？

依 2026 年 9 月 7 日檢查的固定版本程式碼，初始 mapper request 會把完整 spec 送到 ProgramAsWeights，並帶上 public: true、ephemeral: false；之後 Teacher prompt 也包含同一份 spec。官方隱私政策說明，編譯規格會送到伺服器，編譯後的本機推理則不收集資料；政策也允許把服務資料用於改善模型、研究與資料集，並可能長期保存 compiled programs。

服務條款另對提交的 specification、input 與 output 取得廣泛授權，並把編譯出的 .paw 與 adapter weights 視為衍生作品，而非 user IP。這些條款會直接改變「可不可以把內部商業邏輯拿去編譯」的答案：若 spec 不能公開、不能由服務留存或不能授予該權利，現行預設 CLI 就不適合這份規格。

Teacher 端也要分開判斷。OpenAI 在API 資料控制文件說明，API 輸入與輸出預設不會用於訓練，除非組織主動 opt in；部分 abuse-monitoring logs 預設最多保留 30 天，核准的 Zero Data Retention／Modified Abuse Monitoring 另有條件。這不會覆蓋 ProgramAsWeights 自己的政策。最安全的第一個練習，就是本文這種完全虛構、可公開、沒有 PII 與機密規則的分類器。

什麼任務適合？什麼任務不要用？

• 適合候選：高頻、輸入短、輸出空間窄、容許 fallback 的分類、抽取、正規化、路由與小型 DSL。
• 暫不適合：低呼叫量、需求常改、長 context、多輪狀態、精確算術、授權判斷、金流或不可逆控制。
• 必要保護：schema parser、allowlist、timeout、拒絕路徑、shadow traffic、人工抽查與舊 artifact 回滾。

判斷的核心不是「小模型很酷」，而是這份規格是否穩定到值得編譯，錯誤是否能被外殼攔住，以及日後呼叫量是否足以攤平 build 與驗收成本。

Compile by Training 常見問題 FAQ

1. Compile by Training 會把自然語言變成 Python 程式碼嗎？

不會。它把規格轉成 prompt scaffold 與神經網路 adapter，交給共享 Interpreter 生成文字輸出。產物不是可逐條閱讀、形式驗證的規則程式。

2. 編譯和執行都能完全離線嗎？

照本文固定的官方 repo 流程，編譯不能離線。它會把 spec 送到 PAW 與 Teacher API；程式與共享 runtime assets 備妥後，SDK 執行才可用 offline=True 或 PAW_OFFLINE=1 禁止網路。

3. 16 GB 記憶體可以照預設值編譯嗎？

不符合 README 描述的預設目標。公開配方約以 40 GB 可用 accelerator memory 為目標；降低 micro-batch 或 gradient checkpointing 可能減少峰值，但仍需在自己的裝置量時間與穩定性。

4. 論文的 83.6% 可以當成我的預期 accuracy 嗎？

不可以。它是 GPT-5.5 在選定 FuzzyBench-Hard 合成子集上的 LEM，回答的是該實驗，不是你的資料、OOD 或 production error rate。

5. 為什麼不能直接用 Teacher 合成資料做測試？

因為那主要測量模型在 Teacher／合成資料分布上的表現。它不能取代獨立撰寫案例與真實流量驗收；驗收集要在訓練前封存，才有機會抓到 Teacher 錯標、模板偏差與真實長尾。

6. 改一行 spec 後，可以直接覆蓋舊 artifact 嗎？

不應直接覆蓋。把它當 v2 重新編譯，同跑 expected-change 與 invariant holdout，通過 shadow traffic 後再切換；v1 要保留到回滾窗口結束。

7. 呼叫越多，就一定比遠端 API 便宜嗎？

不一定。若本機單次成本不低於遠端，或頻繁改版讓編譯與 QA 一再發生，就沒有可用的 break-even；品質未達標時也不能只談便宜。

8. 它可以取代 deterministic code 嗎？

不適合全面取代。讓 neural function 處理模糊語意，再由 deterministic code 驗證格式、限制動作、處理錯誤並執行真正副作用，才是更穩健的組合。

給第一次導入者的完成清單

• 選一個低風險、短輸入、窄輸出、高頻且規格穩定的文字任務。
• 固定 repo commit、dependency resolution、Teacher、recipe 與 runtime base hash。
• 確認 spec 可以公開且符合 PAW、Teacher 的資料與智慧財產條款。
• 在合成前封存 ID、edge、OOD、spec-revision 四組測例。
• 分 slice 報告 accuracy、build disagreement、expected change 與 unintended drift。
• 品質、隱私與回滾都通過後，才計算 break-even 並開 shadow traffic。

想有系統地補齊 AI 工具、Agent 與部署能力，可前往 AlphaLab 的線上課程與AI 專區。