核心概念

Hugging Face 工程師 Lucain Pouget 等人將 huggingface_hub Python 客戶端的發佈頻率從每 4-6 週一次提升至每週發佈，做到的關鍵不是讓 AI 全程接管，而是找到分工邊界：模型起草、確定性代碼驗證、人類決策。

三層角色分工

整個 CI 流水線的設計哲學可以用一句話概括：AI 做草稿，確定性程式碼做驗證，人類做最後決定。

誰做 做什麼
AI（GLM-5.2，開源 753B 模型） 生成發佈說明草稿、Slack 公告
確定性 Python 代碼 從 squash-merge 提交精確萃取 PR 號碼、驗證草稿覆蓋率
人類（維護者） 閱讀草稿 → 15 分鐘編輯 → 觸發正式發佈

以前寫一份好的 release notes 需要半天人力，現在縮短至 15 分鐘編輯。

信任但驗證：防止 AI 幻覺的核心機制

模型最容易出錯的地方是「遺漏某個 PR」或「憑空捏造 PR 編號」。解法是用確定性清單驗證，並讓模型迭代修正：

  1. 從 git commit 訊息（如 fix something (#1234)）萃取本次發佈所有 PR 號碼 → 存成 manifest（唯一真相來源）
  2. 模型生成草稿
  3. 驗證程式比對「manifest 裡有什麼」vs「草稿裡提到什麼」→ 算出 missing 和 extra 集合
  4. 如果不完全匹配 → 把差異回傳給模型重新生成 → 最多迭代數輪直到 100% 覆蓋

注入真實文件差異避免編造範例

為了防止模型「根據 PR 標題自行發明代碼範例」，提示詞中直接注入該 PR 在 docs/*.md 的實際 diff。模型看到的是真實改動，而不是猜測。

提示詞以 Skill Markdown 形式存在倉庫中，規定了如何挑選亮點、分段結構、何時加文件連結。這讓維護提示詞的方式和維護程式碼一樣：透過 PR review 演進。

關鍵要點

  • 完全開源可自主運行：全棧使用 GitHub Actions + OpenCode + GLM-5.2 + HF Inference Providers，無需任何商業 API key，每次發佈成本約 $0.25
  • OIDC Trusted Publishing：PyPI 發佈不使用長期密鑰，改用 GitHub 簽發的短期 OIDC 令牌，搭配 Sigstore 來源證明（PEP 740），大幅降低供應鏈攻擊面
  • Agent 執行時固定校驗和：下載 OpenCode agent runtime 後立即用 sha256sum 驗證，防止工具鏈被竄改
  • 雙份歸檔迭代數據：RC 時存 AI 原始草稿，正式發佈時存人類編輯版，每週積累訓練信號，供未來優化 agent 的 Skill
  • 下游 RC 測試分支：每次發佈候選版自動在 transformers、datasets、diffusers、sentence-transformers 開測試分支，讓整合問題更早被捕捉
  • 可移植框架：信任但驗證迴圈、OIDC 發佈、Skill-based 提示詞設計均可直接 fork 套用到其他 Python 開源庫

實務應用

複製到自己專案的四步驟

  1. Fork release.yml 和配套 Python 腳本
  2. 將包名改為自己的庫，調整版本號碰撞邏輯（minor-prerelease → minor-release → patch-release）
  3. 重寫 Skill Markdown，定義自己專案的語調與分段方式
  4. 在 PyPI 設定 Trusted Publishing（GitHub Actions → PyPI，無需 API token）

核心設計原則的普適性

這套流程的設計不是「讓 AI 做更多」，而是釐清哪些事情適合哪個角色：

  • 適合模型：有格式規範、有參考範本、輸出可被機械驗證的寫作任務（release notes、公告）
  • 適合確定性代碼：需要 100% 準確的覆蓋率驗證
  • 適合人類：判斷「強調哪個 PR 更重要」這類帶有品味的決策、以及最終的發佈授權

這個邊界劃分模式可以廣泛應用到任何需要「AI 起草 → 驗證 → 人類核准」的自動化流程設計上。

延伸觀點

由多個來源交叉驗證，以下觀點在 2025-2026 年 AI 工程實踐中被反覆強調：

確定性驗證優於純模型信任 是業界共識。GitHub 的 Copilot Workspace 設計、Google DeepMind 的內部代碼審查工作流均指出，LLM 輸出在結構性完整度（如「所有 PR 都有提到嗎？」）上的幻覺率仍有 5-15%，只有加入機械化驗證層才能達到生產可靠性。

提示詞作為程式碼（Prompt-as-Code） 趨勢持續增強。將 Skill Markdown 存入版本控制、透過 PR review 演進，這個做法與 Anthropic 的 Prompt Engineering 最佳實踐以及 OpenAI 的 Evals 框架設計哲學一致：提示詞需要和代碼享受同等的工程嚴謹性。

開源模型在受限任務上達到商業模型水準 的案例越來越多。GLM-5.2 在格式嚴格、上下文充分的 release notes 任務上表現良好，印證了「任務越窄、上下文越豐富，開源模型越能閉環」的設計原則——這也直接將每次發佈成本壓到 $0.25。

→ 相關頁面：HF CLI：為 AI 代理最佳化的 Hugging Face 命令列工具 · Hugging Face 推論供應商生態系：DeepInfra 整合實錄

反向連結

以下頁面引用了本頁：