技能審計員 — 代理能力折舊與契合度評估
概述
技能是一項持續折舊的資產。 模型版本每隔幾個月就會更新。一個上個季度通過的技能可能會悄然退化——輸出格式錯誤、工具呼叫中斷、觸發條件失效——而且沒有人告訴使用者他們的代理變笨了。
此技能是一種評估方法論。它回答三個問題：
- 技能是否在退化？ — 跨模型版本的能力衰退。
- 新技能真的有用嗎？ — 效益與成本的比較。
- 這個技能適合這個使用者嗎？ — 觸發準確度、環境與風格。
它提供了五個可執行的入口點：
scripts/console.py— 常駐主控台（資料層）：維護每個主機的registry.<host>.json，檢測模型版本變化（bump/check），並輸出推薦/淘汰面板。完整的指令集請參閱USAGE.md。scripts/regress.py— 根據金標準回放結果，計算通過率矩陣，標記退化（門檻值與方向），並在資產被編輯時標記FINGERPRINT-DRIFT。scripts/baseline.py— 建立回放檢查清單，然後將記錄的判定結果合併到baseline-results.json（按資產；--replace用於完整覆蓋）。草稿測試案例會跳過，除非使用--allow-draft。scripts/fingerprint.py— 獨立的報告 CLI；是scan所使用的相同雜湊程式碼的薄封裝。它只寫入fingerprint-report.*；不會寫入註冊表。scripts/install.py— 將此技能安裝到機器上的每個代理主機（~/.workbuddy-ai/skills、~/.claude/skills、~/.agents/skills、~/.dsh/skills、~/.codex/skills）。安裝後會驗證；絕不遺留空目錄；絕不複製個人資料。
核心原則：沒有基線就沒有測量。退化 = 在指紋未改變的情況下，通過率顯著下降——絕不僅憑「感覺變笨了」。
多主機架構（技能 vs 插件）
一個核心引擎，每個主機搭配適配器。相同的指紋/基線/迴歸/推薦/需求建議邏輯在所有地方執行；適配器只需要知道資產存放位置和如何讀取其清單。
| 主機 | 類型 | 預設根目錄 | 清單 |
|---|---|---|---|
| workbuddy | skill | 包含此技能的 skills 根目錄 | SKILL.md |
| claude-code | skill | ~/.claude/skills | SKILL.md |
| deepseek | 插件 | ~/.dsh/profiles/desktop (讀取 package.json deps) | package.json / plugin.json |
| generic | asset | 傳遞 --root | plugin.json / manifest.json / SKILL.md / package.json |
- 每個主機維護自己的註冊表：
registry.<host>.json— 不會跨主機覆寫。 - 基線結果 + 金標準集合是共享的，以資產名稱作為鍵值。
- 使用
--host <name> --root <path>執行；可在hosts.json中新增自訂主機。 console.py hosts顯示每個設定檔、解析後的根目錄以及檢測到的資產數量。
因此，在 WorkBuddy 中你評估的是技能；在 DeepSeek 測試平台中你評估的是插件——相同的指令，不同的適配器。新增一個新主機只需在 hosts.json 中新增一個項目（類型 + 根目錄 + 清單檔名），無需修改程式碼。
何時使用
- 在部署新技能或插件之前（「做個 skill，按評測流程走」）。
- 在模型版本升級之後，檢查現有技能是否退化。
- 當技能「感覺不對勁」時——用數據確認，而非靠感覺。
- 在決定保留/重寫/淘汰某個技能時。
- 在向使用者推薦技能或插件時（契合度 + 證據）。
何時不使用： 一次性任務且無可重複使用的技能；純敘述性文件。
核心概念：版本指紋
指紋是折舊矩陣的行。
fingerprint = hash(能力面文件內容 + 相對路徑) # 口徑 v2-ability-surface
什麼算是「能力面」（其變更會實際改變行為的檔案）：
- 包含：
SKILL.md、scripts/*、lib/*、dist/*、package.json、plugin.json、cordis.patch.yml、範本 - 排除：
README*、CHANGELOG*、LICENSE*、圖片/音訊/字型、*.map、鎖定檔、node_modules/、test*/、docs/
為什麼排除：編輯 README 不會改變能力，但對其進行雜湊會導致指紋移動，並在沒有任何功能變更時產生虛假的 FINGERPRINT-DRIFT（「資產被編輯了」）。插件讓這個問題更嚴重——一個已安裝的插件可能攜帶 16 MB 的捆綁輸出以及 57 KB 的 README。
規則：
- 指紋未改變 ⇒ 該行持續存在；通過率下降是模型衰退。
- 指紋已改變 ⇒ 變更是技能自身的責任，而非模型的。 新舊行並存，因此技能編輯永遠不會被錯誤歸因於模型漂移。
執行 python scripts/console.py scan 來計算指紋並將其儲存在註冊表中。fingerprint.py 是一個獨立的報告包裝器；它不會觸及註冊表。
能力面（為什麼插件需要第二個軸）
指紋說明「檔案是否已更改」。它無法說明「是否仍提供相同的功能」。
因此，scan 還會為每個資產記錄一個能力面，並將其與上一次掃描進行比對：
| 資產類型 | 能力面記錄的內容 |
|---|---|
| 插件 | patch (dsh.bundle.patch)、main/module、bin、exports、deps、skills、mcp、hooks、insert (cordis rows)、scripts |
| 技能 | tools (允許的工具數量)、scripts |
當它變更時，scan 會明確列印出來：
[caps] 1 個資產的能力面有變化（這是「它對外提供的東西變了」，與通過率無關）：
plug-a +bin
為什麼這對插件很重要： 插件退化的方式是未註冊其工具 / 路由回傳 404 / 未執行其鉤子——而不是「回答得比較差」。金標準的提示集無法正確衡量插件。能力面差異則可以捕捉到「v1.1.0 丟失了一個入口點」，而無需啟動主機。
已知邊界（不要粉飾它）： 能力面是宣告的能力，而非觀察到的能力。對於一個清單不實（宣告了一個無法載入的修補程式）的插件，這無法捕捉到。
運行時證據（第三個軸，以及它做不到的事）
有兩種截然不同的東西被稱為「運行時探測」。不要把它們混為一談：
| 主動探針 (active probe) | 被動證據 (passive evidence) — 已實作 | |
|---|---|---|
| 功能 | 啟動主機，詢問「你實際註冊了哪些工具」 | 讀取主機已經寫入的日誌 |
| 成本 | DSH desktop 設定檔僅限 Electron——dsh --profile desktop --dump-config 會被拒絕；無無頭模式入口 → 需要逆向工程 IPC 或驅動 UI | 一次檔案讀取，約 10 毫秒 |
| 捕捉範圍 | 所有情況，包括清單不實的插件 | 插件記錄過的任何內容 |
| 狀態 | 未建置 | console.py probe / skill_audit_probe |
probe 讀取 ~/.dsh/logs/*.log（可透過 hosts.json 中的 "logs" 為每個主機設定），解析 <iso> [level] [source] message，將 source 等於已安裝資產名稱的行歸屬，並標記匹配失敗詞彙的行（fail|error|ENOENT|unavailable|timeout|…）。
在本機上實際捕捉到的例子：
@wxg-prc-cpg/browser-skill-dsh-plugin 2 條故障跡象
bsk probe failed (spawn bsk ENOENT); browser tools will report install guidance…
檔案存在，清單有效，caps=4——所有靜態檢查都通過。該插件已載入且其工具已註冊，但無法運作：它所用的 bsk CLI 不在 PATH 上。再多的檔案雜湊也無法發現這個問題。
盲點（清楚說明，絕不隱藏）： 不記錄任何內容的插件是看不見的；日誌輪替會抹去舊的故障；沒有人使用過的插件沒有證據；info 等級的故障是透過關鍵字匹配來捕捉的，因此可能遺漏也可能誤報。沒有證據並不等於健康——probe 會自己印出這句話，而不是打個綠色勾。
已實作 vs 僅為方法論（不要模糊這條界線）
以下的方法論範圍比程式碼更廣。使用者應該知道他們拿到的是哪一半：
| 領域 | 狀態 |
|---|---|
能力面的指紋、scan/status、能力差異 | 已實作 |
| 金標準建立 + 基線整合（按資產合併，草稿防護） | 已實作 (baseline.py) |
通過率矩陣、≥20pp 門檻 + 方向、FINGERPRINT-DRIFT | 已實作 (regress.py) |
模型變更檢測 (bump/check)、每個主機的時間戳 | 已實作 — 但事件源是手動的；排程的 check 會保持綠燈，直到有人執行 bump |
| 推薦/淘汰面板、需求建議、歷史挖掘的草稿 | 已實作 (啟發式；建議並非證據) |
| 來自主機日誌的運行時證據 | 已實作 (被動；僅記錄插件記錄的內容) |
| 消融測試、影子模式採用率、淨值 / Token 遙測 | 僅為方法論 — 無程式碼 |
| 觸發精準度/召回率、環境比對、風格基線 | 僅為方法論 — 無程式碼 |
| K≥3 回放、LLM 評判交叉驗證 | 未實作；目前判定為 K=1 自我評估 |
risk 欄位 | 維護面代理指標 — 非價值 |
如果此文件中的某項主張無法追溯到標記為「已實作」的項目，則應將其視為對執行審計的人類的建議，而非工具會為他們做的事情。
判斷 1 — 能力退化
四個步驟：
- 從歷史記錄中建立金標準，而非手動建立。 挖掘過往對話：使用者無異議採用 → 正面回放；使用者提出異議/要求重寫 → 負面。回放即是迴歸。使用者自己的使用歷史就是語料庫——無需發明測試集。
- 在同一個金標準集上執行兩個模型，K≥3（LLM 評分案例：K≥5，因為評判者本身有雜訊）。記錄每個（指紋，模型版本）的通過率。
- 判定規則： 下降 ≥20pp 且方向一致 → 報告退化；低於門檻 → 「波動觀察」。這將「這個輸出很奇怪」轉變為可重現的標準。
- 歸因，而不只是標記。 檢查中間產物：
- 工具呼叫錯誤/格式變更 → 修正工具描述。
- 輸出結構正確，內容錯誤 → 重寫指示。
- 應該觸發但未觸發 → 修正觸發描述。
- 所有中間產物都正確，僅最終結果錯誤 → 模型內部退化；將技能標記為「單模型依賴」，等待模型修正。
「7 個退化，2 個建議重寫」這一行是步驟 4 輸出的可歸因子集——這正是使報告可操作的原因。
判斷 2 — 新技能是否良好？
分為兩個可衡量的軸向：效益（更好的結果）和經濟性（更低的成本）。
- 部署前消融測試。 相同的任務批次，兩個分支：A 不使用技能，B 使用技能。記錄成功率、人工修正次數、Token 成本。
淨效益 = 成功率提升 × 任務頻率 − 邊際成本一個將成功率提升 30% 但每年只觸發 3 次且每次消耗 50k Token 的技能是負債，而非資產。 - 部署後影子模式。 新技能靜默執行：產生建議但不自動執行；記錄「原本會發生什麼事」。觀察採用率（接受 vs 覆蓋）。採用率是「好」的最終評判標準，比任何離線指標都更誠實。邊界：寫入操作技能（刪除檔案、發送郵件）在影子模式下只能模擬/註解，從不真正執行。
- 淨值卡片。 每個技能一個儀表板：呼叫次數、成功率、採用率、平均 Token、累積淨效益。90 天淨負值 → 建議重寫或淘汰。這是折舊表的用戶端。
判斷 3 — 它適合這個使用者嗎？
「適合你」= 觸發準確 + 假設成立 + 風格匹配。全部可自動化：
- 觸發精準度（對感受影響最大，也最常被跳過）。取樣歷史記錄中的正向案例（應該觸發）和負向案例（長得像但不應該觸發——「修正這個 bug」 vs 「解釋什麼是 bug」）。回放 → 精準率/召回率。低精準率 = 煩人（過度觸發）；低召回率 = 浪費安裝空間。首先手動標記 10–20 個，然後半自動化，零 LLM 成本。
- 環境比對（已安裝 ≠ 可執行）。技能元資料宣告依賴項：哪些工具 / MCP / 權限 / 路徑習慣 / 語言，以及隱含的模型能力假設（長上下文、程式碼執行、多模態）。與使用者的實際環境進行比對；缺少的內容 → 紅燈。「假設為 macOS」、「輸出日文」、「需要 200k 上下文」——看不見的假設是技能未被使用的第一大原因。這也會回饋到判斷 1：能力假設失敗 = 靜默退化。
- 風格基線（權重最低）。以使用者的歷史輸出 + USER.md 作為參考；LLM 評判比較格式、語言、詳細程度。僅用於在評分相等的技能之間進行抉擇。
內嵌工作流程（用於「製作一個新技能」）
當使用者要求建立一個技能時，在交付之前內嵌執行此協議：
- 環境比對 — 使用者的環境是否滿足技能宣告的依賴項 + 能力假設？
- 觸發回放 — 回放 10–20 個取樣案例；報告精準率/召回率。
- 消融測試 — 在一個小型任務批次上，衡量提升與成本。
- 進入監控 — 通過後，註冊指紋 + 金標準；常駐主控台在每次模型升級時重新執行。
基於需求的建議（當沒有技能匹配時）
這是「空貨架」行為：使用者（尤其是那些沒有任何技能/插件的使用者）要求某個已安裝技能無法涵蓋的功能。不要只說「我做不到」——應揭露這個缺口並提供補救方案。
- 從對話中檢測需求：任務類型 + 領域（例如「季度財務報告」→ 金融/分析；「移除 AI 語氣」→ 人性化工具；「建立一個儀表板」→ 前端/圖表）。
- 首先檢查註冊表 —
python scripts/console.py suggest --need "<need>"。它會返回以下其中一種結果：✓ 你已有可用的 skill/插件：<name>→ 使用它，無需安裝任何東西；或💡 建議新增：[install:<slug>] <title>→ 沒有涵蓋，建議該類別。
- 如果未被涵蓋，搜尋市集尋找真實的候選項目（技能/插件/專家），並提供帶有證據的卡片：功能、為何適合此需求、來源。絕不自動安裝——由使用者選擇。
- 在安裝時 — 如果技能/插件需要設定，詢問並引導，而非默默失敗。最後將指紋提交到主機的註冊表。
- 如果缺口是真實的 —「‘無覆蓋’是產品缺口，不是使用者錯誤」——提出建立一個。
技能審計指令
（此技能回應的觸發詞/指令）
| 觸發模式 | 解釋 | 執行 |
|---|---|---|
| 做個 skill / 創建 skill | 內嵌工作流程 | conversation.start_audit(create=true) |
| 評測這個 skill / 評測這個插件 | 打開指定資產的審計面板 | console.py audit --asset <name> |
| 模型升級後 skill 還靈不靈 | 模型變更 => 回放金標準 + 退化報告 | scripts/regress.py（如果存在基線） |
| 這個 skill 適合我嗎 / 新 skill 好不好用 | 判斷 2 + 3（效益 + 契合度） | 對話式分析 |
| deepseek 插件好不好用 | 觸發 DeepSeek 適配器路徑 | --host deepseek |
| 跨 agent 評估能力 | 所有主機的全局掃描 | console.py scan && console.py status |
| 做個 skill 並按評測流程走 | 建立 + 內嵌 | 建立，然後立即進入審計 |
資源
- 來源： 此技能可以在 GitHub 找到
- 需求： 需要 Python 3.10+，安裝方式為
python scripts/install.py或手動安裝到 skills/plugins 目錄 - 設定： 可選的
HOSTS_CONFIG環境變數指向自訂的hosts.json，以支援非標準主機 - 輸出示例：
=== 能力退化報告: [email-buddy] ===
測試案例: 12 | 通過: 7 | 通過率: 58.3%
基線通過率: 91.7% | 下降: -33.3pp
方向: 一致 | 判定: 退化
建議行動:
- 預期輸出結構遺失 (3/5 案例)：輸出格式已變更。建議更新格式設定。
=== 推薦/淘汰面板 ===
┌──────────┬──────────┬──────────┬──────────┬──────────┐
│ Skill │ 通過率 │ 趨勢 │ 成本 │ 判定 │
├──────────┼──────────┼──────────┼──────────┼──────────┤
│ repo-lint│ 95% │ 穩定 │ 低 │ 保留 │
│ email-bd │ 58% │ ↓33pp │ 中 │ 建議重寫 │
│ code-gen │ 82% │ 波動 │ 高 │ 監控 │
│ trans-ai │ 100% │ 新 │ 低 │ 觀察 │
└──────────┴──────────┴──────────┴──────────┴──────────┘