AI Agent Skill 工程化 02：從“憑感覺優化”到"Eval 驅動”
整理版優先睇
Agent Skill優化要靠Eval驅動，建立可復現案例、評分同迴歸門禁。
呢篇文章係講緊AI Agent Skill嘅工程化方法，作者係一班寫Agent Skill嘅開發者，成日遇到Skill越改越亂嘅問題：改完之後唔知有冇變好，改一處就影響其他地方。佢哋想解決嘅問題係點樣將Skill優化從「憑感覺」變成有數據支持嘅科學過程。
文章嘅整體結論係：Skill優化要靠可復現案例、評分同迴歸門禁，即係Eval驅動。佢哋提出一個標準SOP七步閉環：問題池 → 測試用例 → 基線評分 → 小步改動 → 迴歸驗證 → 版本發佈 → 持續監控。呢個流程可以將Skill當成工程資產咁管理，有版本、有評測、有門禁。
另外，文章仲提供六種升級方案，由人工覆盤到自動優化，適合唔同成熟度嘅團隊。重點係要先補測試集、跑基線，先好改Skill，避免盲目改動。最後有一個7日最小落地計劃，畀讀者可以即刻開始實踐。
- 標準SOP七步：問題池→測試用例→基線評分→小步改動→迴歸驗證→版本發佈→持續監控，係Eval驅動嘅核心流程。
- 問題池要嚟自真實任務，記錄用戶糾偏、追問、輸出缺失等五類信號，唔係靠腦暴。
- Eval鐵律：值得改嘅問題一定要先變成eval case，通過規則檢查、結構檢查、軌跡檢查等先改。
- 升級方案A-F都套同一條SOP，只係喺唔同環節加厚，比如方案B係Eval驅動，方案C係自動優化。
- 建議先補測試集同跑基線，而唔係將SKILL.md寫得更長，避免越改越亂。
frontend-team-marketplace
參考倉庫，包含相關技能
從「憑感覺」到「Eval驅動」
好多人而家做緊「人工反饋閉環」，即係用Skill跑真實任務，記錄問題，同AI對話分析，再用create-skill改寫。呢套做法早期有用，但有兩個硬傷：問題難復現，同埋冇迴歸測試。
「人工反饋閉環」
「兩個硬傷：問題難復現、冇迴歸測試」
更規範嘅做法係將Skill當成可測試、可迴歸、可發佈嘅工程資產——同寫代碼一樣，有版本、有評測、有門禁。
七步閉環：主幹流程
下面係推薦主流程，後文嘅方案A～F都係喺呢條線上「加厚」某一環，唔係另起爐灶。
- 1 問題池：記錄真實使用中嘅跑偏，存為skill-issues.jsonl
- 2 測試用例：將高頻失敗寫成eval，存為test-prompts.json
- 3 基線評分：改之前先測當前版，記錄results.tsv / score
- 4 小步改動：一輪只改一個假設，單點diff + hypothesis
- 5 迴歸驗證：spot → targeted → regression，對比pass/fail
- 6 版本發佈：通過先發版，更新CHANGELOG.md
- 7 持續監控：生產問題反哺測試集，每週Skill Review
「口訣：先記問題，再寫eval；先跑基線，再改一句」
問題池同Eval：數據驅動嘅基礎
問題池唔係開會腦暴出嚟，而係從真實任務裏面長出嚟。下面係五類高價值信號來源。
- 用戶糾偏：Agent邊一步錯咗，例如「只跑階段A，別寫OpenSpec」
- 用戶追問：點解要反覆問，例如「API文檔喺邊？」
- 輸出缺失：少咗邊一節，例如收尾冇「仍為TBD」
- 工作流偏航：跳步或者漏閘門，例如閘門未過就寫四文件
- 契約文件漂移：多改或者漏改，例如只刷field-matrix，tasks未同步
Eval方面，鐵律係：值得改Skill嘅問題，必須先變成eval case。Eval類型包括規則檢查、結構檢查、軌跡檢查、LLM Judge同人工複核。
「值得改Skill嘅問題，必須先變成eval case」
「規則檢查、結構檢查、軌跡檢查、LLM Judge、人工複核」
升級方案同成熟度自測
方案A～F唔係六套唔同流程，而係同一條SOP上唔同成熟度嘅「加厚層」。
- 方案A：人工覆盤，適合啱啱寫Skill，強化問題池、小步改
- 方案B：Eval驅動，推薦主形態，強化測試、基線、迴歸
- 方案C：Darwin自動優化，有rubric後自動試錯、保留/回滾
- 方案D：CI門禁，團隊共用，強化迴歸、發佈
- 方案E：生產監控，日常高頻使用，強化持續監控、問題池
- 方案F：分層重構，Skill太長時強化可維護性、測試落地
「先用方案B跑通七步；團隊化再加D；穩定後再考慮C/E」
成熟度自測可以睇自己喺L0到L6邊一級。L0只靠對話，L1有SKILL.md，L2記錄問題，L3有test prompts，L4每次改動必跑eval，L5自動hill-climbing，L6生產持續反哺。
7日最小落地同總結
如果你哋而家大概喺L2～L3，下一步唔係將SKILL.md寫得更長，而係補測試集、跑基線、加發布門禁。呢個7日計劃可以直接照抄。
- 1 Day 1：跑new-skill.sh或建Skill卡，彙總10條真實問題
- 2 Day 2：核心Skill各補8～12條test prompt
- 3 Day 3：跑baseline，唔改Skill
- 4 Day 4：每個Skill只改1個最高風險點
- 5 Day 5：做spot + targeted + regression
- 6 Day 6：寫CHANGELOG，標版本
- 7 Day 7：對比baseline，新問題入問題池
「改前測 vs 改後測」
前言
你有冇都試過覺得Skill越改越亂，出現以下呢種情況？
•Skill用耐咗，越改越長，模型反而更加容易漏讀
•遇到問題就記低筆記，改完Skill之後講唔清到底有冇變好
•編排技能、子技能、契約技能疊埋一齊，改一處、影響成片
如果你係用緊 Cursor / Claude Code 做相關Skill技能，呢類流水線更新優化迭代嘅，呢篇文章俾你一套可以直接落地嘅升級方法。
適用讀者：寫Agent Skill嘅開發者、前端/全棧同學、小團隊技術負責
典型場景：使用change-spec-workflow技能進行AI編程，因為咁樣可以產生大量嘅技能使用數據。
參考倉庫地址：
https://github.com/yangmeishux/frontend-team-marketplace/tree/main/plugins/frontend-team-toolkit/skills
一句講曬總結
一句話：Skill優化唔好靠體感，要靠 可復現案例 + 評分 + 回歸門禁。
標準SOP七步（主幹流程，所有方案都套呢條線）：
問題池 → 測試用例 → 基線評分 → 小步改動 → 迴歸驗證 → 版本發佈 → 持續監控
口訣：先記低問題，再寫eval；先跑基線，再改一句。
開頭：你而家嘅做法，有效但係唔完整
好多人已經喺度做「人工反饋閉環」：
1.使用Skill跑真實任務
2.記錄問題同疑問
3.同AI對話分析
4.用 create-skill 改寫Skill
呢套做法適合早期探索，可以快速捉住真實痛點。
但係佢有兩個硬傷：
更規範嘅做法，係將Skill當成可測試、可回歸、可發佈嘅工程資產——同寫code一樣，有版本、有評測、有門禁。
1）標準SOP：七步閉環（建議全文記住）
下面呢條線係推薦主流程。之後嘅方案A～F，都係喺呢條線上「加厚」某一環，唔係另起爐灶。
skill-issues.jsonl | ||
test-prompts.json | ||
results.tsv | ||
CHANGELOG.md | ||
決策規則（棘輪）：
•分數或通過率嚴格變好 → 保留
•退步 → 回滾，唔好堆改動
2）問題池：數據從邊度嚟？（你最關心嘅）
問題池唔係開會腦暴出嚟嘅，而係從真實任務入面生出來嘅。
下面例子描述係使用change-spec-workflow產生嘅。
2.1 五類高價值信號
2.2 三級採集（由易到難）
第一級：當場記低一行JSONL
{"date":"2026-05-28","skill":"change-spec-workflow","symptom":"局部刷新未列漂移風險","severity":"high","status":"open"}
第二級：任務結束叫Agent自己報告
喺使用Skill時追加：
任務結束時請輸出「Skill 使用觀察」，有問題則給出可寫入 skill-issues.jsonl 的 JSONL 行。
第三級：每週覆盤
睇三類材料：最近對話、失敗eval、git diff 文檔漂移。
3）Eval：先寫測試，再改Skill
鐵律：值得改Skill嘅問題，必須先變成eval case。
評分優先級（慳錢又穩定）：
1.規則檢查（章節、禁用詞、路徑）
2.結構檢查（步驟順序、閘門）
3.軌跡檢查（係咪Read子技能）
4.LLM Judge（語義質量）
5.人工複核（高風險場景）
3.1 你嘅流水線，優先測呢6條
•缺PM MD / 規格根目錄 → 淨係出待補充清單，禁止作嘢
•編排技能 → 一定要先Read兩個子技能
•階段A閘門未過 → 唔可以進入階段B
•淨係刷新單文件 → 一定要輸出未同步清單 + 漂移風險
•Reconcile → 唔可以有舊版本字段殘留
•任務結束 → 路徑 / TBD / 建議下一步，三節齊全
4）六種升級方案：都套同一條SOP
好多人問：方案A～F係咪六套唔同流程？
不是。 標準SOP係主幹；方案只係成熟度唔同嘅「加厚層」。
| 推薦主形態 | ||
落地建議：先用 方案B 跑通七步；團隊化再加D；穩定咗之後再考慮C / E。
5）成熟嘅Skill係點樣？
一個可以長期迭代嘅Skill目錄，至少應該有：
SKILL.md | |
reference.md | |
test-prompts.json | |
results.tsv | |
CHANGELOG.md |
反模式（中咗一定出事）：
•將所有失敗都塞曬入 SKILL.md → 越長越漏讀
•一次改十處 → 歸因唔到
•淨係改規則唔加eval → 問題一定會翻發
•容許改評分器 → 等於作弊
6）7日最小落地（照跟就得）
new-skill.sh 或者整Skill卡 + 匯總10條真實問題 | |
evals-minimal.json） | |
真實閉環參考：上篇文章測試經驗 wechat-article-review 首評8.4 → 改稿9.2；可以睇下之前嘅腳手架搭建藍圖篇
如果你哋而家大概喺L2～L3：會記錄問題，但eval資產仲未齊。
下一步唔係將 SKILL.md 寫得更長，而係補測試集 + 跑基線 + 加發布門禁。
7）成熟度自測：你喺邊一級？
SKILL.md，可以觸發 | |
工程化理念
升級前：
我覺得這個 Skill 需要改
升級後：
case 7/9/12 失敗；改局部刷新護欄後 regression 12/12，capability 8/10，token 成本未明顯上升。
這就是 Eval驅動嘅Skill工程化。
總結
寫Skill就好似寫code咁，冇測試嘅優化就係盲改。
呢篇文章我哋拆解咗點樣用 Eval驅動 取代「憑感覺優化」。核心唔在於你寫咗幾複雜嘅Prompt，而在於你有冇建立咗一套可復現、可量化、可回滾嘅反饋閉環。
•從0到1：建立 skill-issues.jsonl，等問題有據可查。
•從1到N：編寫 evals，等基線評分變成版本發佈嘅唯一門票。
•長期主義：堅持回歸測試，確保新能力嘅獲得唔會犧牲舊能力。
工程化唔係一步到位嘅。
你唔需要一開始就起好完美嘅CI流水線，就算只係手動跑通一次「改前測 vs 改後測」，你已經從「寫Prompt嘅人」進化成「構建Agent資產嘅工程師」。"
前言
你是不是也遇到過感覺Skill 越改越亂，出現以下這種情況：
•Skill 用久了，越改越長，模型反而更容易漏讀
•遇到問題就記筆記，改完 Skill 後說不清到底有沒有變好
•編排技能、子技能、契約技能疊在一起，改一處、漂一片
如果你正在用 Cursor / Claude Code 做相關Skill技能, 這類流水線更新優化迭代的，這篇文章給你一套能直接落地的升級方法。
適用讀者：寫 Agent Skill 的開發者、前端/全棧同學、小團隊技術負責
典型場景：使用change-spec-workflow技能進行AI編程，因為這樣可以產生大量的技能使用數據。
參考倉庫地址：
https://github.com/yangmeishux/frontend-team-marketplace/tree/main/plugins/frontend-team-toolkit/skills
一句話總結
一句話：Skill 優化不要靠體感，要靠 可復現案例 + 評分 + 迴歸門禁。
標準 SOP 七步（主幹流程，所有方案都套這條線）：
問題池 → 測試用例 → 基線評分 → 小步改動 → 迴歸驗證 → 版本發佈 → 持續監控
口訣：先記問題，再寫 eval；先跑基線，再改一句。
開篇：你現在的做法，有效但不完整
很多人已經在做「人工反饋閉環」：
1.使用 Skill 跑真實任務
2.記錄問題和疑問
3.和 AI 對話分析
4.用 create-skill 改寫 Skill
這套做法適合早期探索，能快速抓住真實痛點。
但它有兩個硬傷：
更規範的做法，是把 Skill 當成可測試、可迴歸、可發佈的工程資產——和寫代碼一樣，有版本、有評測、有門禁。
1）標準 SOP：七步閉環（建議全文記住）
下面這條線是推薦主流程。後文的方案 A～F，都是在這條線上「加厚」某一環，不是另起爐灶。
skill-issues.jsonl | ||
test-prompts.json | ||
results.tsv | ||
CHANGELOG.md | ||
決策規則（棘輪）：
•分數或通過率嚴格變好 → 保留
•退步 → 回滾，不堆改動
2）問題池：數據從哪裏來？（你最關心的）
問題池不是開會腦暴出來的，而是從真實任務里長出來的。
下面例子描述是使用 change-spec-workflow 產生的。
2.1 五類高價值信號
2.2 三檔採集（從易到難）
第一檔：當場記一行 JSONL
{"date":"2026-05-28","skill":"change-spec-workflow","symptom":"局部刷新未列漂移風險","severity":"high","status":"open"}
第二檔：任務結束讓 Agent 自報
在使用 Skill 時追加：
任務結束時請輸出「Skill 使用觀察」，有問題則給出可寫入 skill-issues.jsonl 的 JSONL 行。
第三檔：每週覆盤
看三類材料：最近對話、失敗 eval、git diff 文檔漂移。
3）Eval：先寫測試，再改 Skill
鐵律：值得改 Skill 的問題，必須先變成 eval case。
評分優先級（省錢又穩）：
1.規則檢查（章節、禁用詞、路徑）
2.結構檢查（步驟順序、閘門）
3.軌跡檢查（是否 Read 子技能）
4.LLM Judge（語義質量）
5.人工複核（高風險場景）
3.1 你的流水線，優先測這 6 條
•缺 PM MD / 規格根目錄 → 只出待補充清單，禁止編造
•編排技能 → 必須先 Read 兩個子技能
•階段 A 閘門未過 → 不得進入階段 B
•只刷新單文件 → 必須輸出未同步清單 + 漂移風險
•Reconcile → 不得殘留舊版本字段
•任務結束 → 路徑 / TBD / 建議下一步，三節齊全
4）六種升級方案：都套同一條 SOP
很多人問：方案 A～F 是不是六套不同流程？
不是。 標準 SOP 是主幹；方案只是成熟度不同的「加厚層」。
| 推薦主形態 | ||
落地建議：先用 方案 B 跑通七步；團隊化再加 D；穩定後再考慮 C / E。
5）成熟 Skill 長什麼樣？
一個能長期迭代的 Skill 目錄，至少應有：
SKILL.md | |
reference.md | |
test-prompts.json | |
results.tsv | |
CHANGELOG.md |
反模式（踩了必翻車）：
•把所有失敗都塞進 SKILL.md → 越長越漏讀
•一次改十處 → 無法歸因
•只改規則不加 eval → 問題必復發
•允許改評分器 → 等於作弊
6）7 天最小落地（照抄即可）
new-skill.sh 或建 Skill 卡 + 彙總 10 條真實問題 | |
evals-minimal.json） | |
真實閉環參考：上篇文章測試經 wechat-article-review 首評 8.4 → 改稿 9.2；可以看看之前的腳手架搭建藍圖篇
如果你們現在大概在 L2～L3：會記錄問題，但 eval 資產還沒齊。
下一步不是把 SKILL.md 寫更長，而是補測試集 + 跑基線 + 加發布門禁。
7）成熟度自測：你在哪一檔？
SKILL.md，能觸發 | |
工程化理念
升級前：
我覺得這個 Skill 需要改
升級後：
case 7/9/12 失敗；改局部刷新護欄後 regression 12/12，capability 8/10，token 成本未明顯上升。
這就是 Eval 驅動的 Skill 工程化。
總結
寫 Skill 就像寫代碼，沒有測試的優化就是盲改。
這篇文章我們拆解了如何用 Eval 驅動 替代“憑感覺優化”。核心不在於你寫了多麼複雜的 Prompt，而在於你是否建立了一套可復現、可量化、可回滾的反饋閉環。
•從 0 到 1：建立 skill-issues.jsonl，讓問題有據可查。
•從 1 到 N：編寫 evals，讓基線評分成為版本發佈的唯一門票。
•長期主義：堅持迴歸測試，確保新能力的獲得不以犧牲舊能力為代價。
工程化不是一蹴而就的。
你不需要一開始就搭建完美的 CI 流水線，哪怕只是手動跑通一次“改前測 vs 改後測”，你都已經從“寫 Prompt 的人”進化成了“構建 Agent 資產的工程師”。