如果你維護開源專案、內部平台或 SDK repo，GitHub issue 和 PR 通知很容易從協作訊號變成背景噪音：新問題一直進來，真正需要立刻處理的項目反而被淹沒。
Hugging Face 2026 年 6 月 22 日發布的 OpenClaw 案例，提供了一個可參考的解法：用 Gemma、Qwen 等本機開放權重模型，搭配 localpager 管線與只讀 repo shell，先把 GitHub issues/PRs 分成標籤、負責區域、通知政策與人工審核佇列。
讀完這篇，你可以判斷三件事：你的 repo 是否適合先試本機 triage、第一版權限要限制在哪裡、如何用 7 天 dry run 檢查誤報與漏報。這條路線適合先處理通知分流，不適合一開始就讓 AI 自動改 code 或對外回覆。
先看通知負載是否值得自動分流
本機模型 triage 最有價值的場景，是人類已經被重複通知與分類工作拖慢。若你的 repo issue 量還不高，通常先整理 GitHub templates、labels、code owners 與 reviewer 規則，就能先降低不少噪音。
| 情境 | 是否適合先試 | 判斷重點 |
|---|---|---|
| 大型開源專案，每天大量 issue/PR | 適合 | 標籤、負責區域與通知政策要先定義清楚。 |
| 內部平台 repo，需求來自多個產品線 | 適合 | 先把輸出限制在 routing 與 priority，不要讓模型直接派工。 |
| 小型產品 repo，每週只有少量 issue | 不急 | GitHub 原生 labels、templates 與 reviewer 規則可能已足夠。 |
| 資安漏洞、合規或客戶事故入口 | 慎用 | 本機模型可做輔助標記，但必須有人類審核與明確升級規則。 |
最好的第一個任務通常是縮小通知範圍：只通知維護者負責的幾個 topic，其他保持安靜。這讓成功標準很清楚：誤報少一點、漏報可追蹤、維護者能更快看到該看的項目。
如果你現在想讓 AI 自動改 code、回覆外部使用者或判斷資安優先級，這個案例還不足以支撐那種權限。它比較適合當第一步：先把大量 GitHub 訊號整理成標籤、負責區域、通知政策與人工審核佇列。
OpenClaw 案例的重點：分流架構比「免費 AI」更重要
Hugging Face 原文標題強調 free，但文中也說明前提是已經有硬體，仍要計算電力與維運成本。團隊評估時要把注意力放在三種成本：雲端模型額度、通知延遲，以及維護者被無關 issue 打斷的時間。
案例的起點是 OpenClaw repo 每天有大量 issues 與 PRs，需要被分類、優先排序並路由給維護者。作者用 localpager 監看 GitHub 物件，將新項目寫入本機 SQLite，worker 再把 issue/PR 標題、body、標籤、作者、狀態、留言、變更檔案與截斷 diff 整理成分類任務。模型只在受控上下文中輸出結構化標籤，不取得自由行動權。
這種設計很適合用在「大量、重複、可回放」的工程訊號。你可以保存每次輸入、模型輸出、通知結果與人工修正，之後用同一批資料比較不同模型、提示與標籤定義。
OpenClaw 案例的資料流怎麼跑
Hugging Face 的管線可以拆成四層。
第一層是 GitHub 物件同步。localpager 把 issues、PRs 與必要的上下文標準化，寫入本機資料庫。這避免模型每次都直接上 GitHub 查資料，也讓後續評估可以回放。
第二層是 受控提示與 schema。每個項目會被渲染成 prompt，模型需要輸出符合 schema 的分類結果。這裡的分類包含 local models、self-hosted inference、agent runtime、Codex、UI/TUI 等 topic；自由文字心得不進入正式輸出。
第三層是 只讀 repo 工具。模型可以透過 reposhell 看 repo 中必要的檔案，例如列目錄、查檔名、讀 package metadata；不能任意執行 curl、寫檔或呼叫外部服務。這讓模型在需要更多上下文時可以查證，但工具面仍維持窄而可審計。
第四層是 確定性通知政策。模型只負責分類；是否通知某位維護者，由 localpager 依照使用者設定的 topic policy 決定。這個分工很重要，因為通知本身不應每次都交給模型重新判斷。
模型結果怎麼讀：先看誤報/漏報，不要只看誰分數最高
原文用 330 筆 GitHub issues 與 PRs 建立評估集。每筆資料由 GPT-5.5 與 Opus 4.8 多次標註，模型需要達成一致才被接受；之後再拿 Gemma、Qwen 與 DeepSeek-V4-Flash 參考結果比較。這是任務型評估，不能直接推論成所有 coding agent 場景的通用排名。
比較值得帶走的是 trade-off。Gemma 在該設定下 recall 較高、每列耗時較低，代表比較不容易漏掉應該通知的項目；Qwen precision、exact match 與誤報控制較好，代表比較不容易把無關項目丟進維護者通知流。若你的痛點是漏掉 P0 issue，偏好會不同；若你的痛點是通知噪音，偏好也會不同。
原文列出的部分數字如下，請把它視為 Hugging Face 在該硬體、提示、資料與優化下的案例結果：
| 指標 | gemma-4-26b-a4b | qwen3.6-35b-a3b | DeepSeek-V4-Flash 參考 |
|---|---|---|---|
| Precision | 0.716 ± 0.010 | 0.831 ± 0.007 | 0.938 |
| Recall | 0.905 ± 0.004 | 0.818 ± 0.006 | 0.714 |
| Exact match | 0.410 ± 0.014 | 0.540 ± 0.014 | 0.509 |
| False positives | 227.0 ± 10.5 | 105.7 ± 6.4 | 30 |
| Wall seconds / row | 1.41 ± 0.04 | 13.51 ± 0.79 | 144.14 |
對實務導入來說，這張表不該拿來問「哪個模型最強」。比較好的問題是：你的通知流更怕誤報還是漏報？你的硬體可以承受多少延遲？你的標籤是否定義到讓模型能穩定輸出？
安全重點在工具邊界，不在「模型在本機」
本機推論不代表自動安全。GitHub issue 和 PR body 本身可能包含 prompt injection，惡意內容可以要求模型讀秘密、執行命令或偏離分類任務。Hugging Face 案例把 reposhell 做成只讀、有限命令集合，這比「模型放在本機」更值得複製。
對工程團隊來說，第一版 triage agent 至少要有四個邊界。模型只能讀任務需要的 GitHub 上下文；repo shell 只能允許查詢型命令；輸出必須符合固定 schema；通知、升級與寫入動作由 deterministic policy 處理。這樣就算模型被 issue 內容帶偏，也比較難跨出分類工作。
還有一個容易忽略的點：不要把所有上下文都丟給模型。PR diff 可以截斷，敏感設定檔可以排除，comments 可以分批加入。分流任務需要的是足夠判斷 topic 的資訊，不是整個 repo 的完整讀取權。
什麼時候不要急著導入
如果你的標籤本來就混亂，模型只會把混亂放大。先整理 labels、components、owners、severity 與通知規則，再談本機 agent。
如果你的任務需要直接改變外部狀態，例如自動關閉 issue、自動要求客戶補資料、自動合併 PR，請先停在建議層。分類與通知是低風險入口；寫入、關閉、派工與合併需要更嚴格的權限、審核與稽核。
如果你沒有基準資料，也很難知道模型是否進步。至少抽 100 到 300 筆過去的 issues/PRs，標出期望標籤與通知對象，再讓不同模型跑同一批資料。沒有回放集，就只能用感覺判斷通知是不是變乾淨。
7 天試跑流程
第一週不要追求完整平台，先證明本機 triage 能不能讓維護者少看噪音，同時不漏掉重要項目。
- 第 1 天：定義標籤與通知政策。挑 5 到 15 個真正會影響 routing 的 topic，刪掉只是好看的標籤。
- 第 2 天：整理基準資料。抽取近期 100 到 300 筆 issues/PRs，請熟悉 repo 的人標出期望分類與通知對象。
- 第 3 天：建立只讀上下文。決定模型可看到 title、body、labels、comments、changed files、截斷 diff 與哪些 repo 查詢命令。
- 第 4 天：跑第一個本機模型。先要求固定 JSON schema，保存輸入、輸出、耗時、失敗案例與人工修正。
- 第 5 天：比較另一個模型或提示。用同一批資料比較 precision、recall、false positives、false negatives 與每筆耗時。
- 第 6 天：接通知 dry run。先不要真的打擾維護者，把預計通知寫到 Slack/Discord 測試頻道或報表。
- 第 7 天：決定上線範圍。只把信心最高、風險最低的 topic 開到真實通知，其餘留在觀察模式。
這個流程可以接上站內的 LLM 評估指南 與 AI 安全工程：模型分數、工具權限、資料保存與人類覆核要一起設計，不能只看 demo 是否跑通。
和 GitHub 原生 triage 工具有什麼關係？
GitHub 也在強化 issue duplicate detection、semantic issue search 與 MCP issue fields。這些功能適合做 repository 內的結構化整理；本機模型 triage 則適合放在「自訂 topic、維護者通知、跨工具報表」那一層。
實務上可以並用。GitHub 原生功能負責減少重複 issue、維持欄位一致；本機模型負責把新項目映射到你的內部 topic 與通知政策。若你已經在用 GitHub Issues AI triage，這篇案例可以當作下一步：把 repo 外的通知、評估與本機模型成本也納入設計。
參考來源
- Hugging Face Blog：We got local models to triage the OpenClaw repo for FREE!*
- Mason AI Lab：GitHub Issues AI triage：重複偵測、語意搜尋與 MCP 欄位怎麼用
- Mason AI Lab：Interpreter Skills 是什麼？把 AI Agent 的固定流程變成可測試的 skill code
下一步
如果你現在每天只處理幾個 issue，先把 GitHub templates、labels 與 owner 規則整理好就夠。若你的 repo 已經有大量 issue/PR 噪音，先選一個維護者最痛的 topic，建立 100 到 300 筆回放資料，用本機模型做一週 dry run。
評估時不要只看模型回答是否漂亮。請看三件事：誤報是否少到維護者願意開通知、漏報是否有定期檢查機制，以及工具邊界是否足夠窄。這三件事過關，本機模型 triage 才值得進入正式維護流程。