skill 沒有 evals 就別上線

012Philipp Schmid（Google DeepMind）21:452026-07-14 上架

Don't Ship Skills Without Evals — Philipp Schmid, Google DeepMind

Philipp Schmid 指出人人都在用 skills，卻幾乎沒人替它寫 evals。這場整理出寫 skill 的八個要點，並用 Gemini Interactions API 的案例，示範怎麼用便宜的 regex 檢查把 skill 測起來。

這場講了什麼

• 人人用 skills，沒人有 evals：Philipp 請現場舉手，用 coding agent 與 skills 的人很多，有 evals 的很少。SkillsBench 索引了 50,000 多個 GitHub 上的 skills，幾乎都沒有 evals，多數還是 AI 寫的。
• skill 分兩種，命運不同：capability skills 補的是模型目前做不穩的事，模型變強就可能用不到；preference skills 記的是團隊自己的流程與風格，比較長久，要靠 evals 守住。
• description 是成本也是關鍵：model-invoked 的 skill 靠兩句 description 讓模型判斷要不要用，每次模型呼叫都要付這筆 token。Philipp 要求寫成明確的指令，說清楚為什麼用、怎麼用、什麼時候用，也要寫什麼時候不用。
• 固定流程寫成腳本，不要寫成 skill：流程每次都一樣，就別花模型與 token 去走；skill 該講的是目標與限制。Philipp 也引了 Matt 的發現：AI 生成的 skill 常夾帶 no-ops，也就是對 agent 行為沒有影響的句子。
• eval 可以很土：Gemini Interactions API 的 skill 用 117 個測試案例、一份 JSON 加一支 Python 腳本，多半只靠 regex 檢查，成本低到每換一次模型都能重跑，有效程式碼的比例最後接近 90%。
• 用有無 skill 的對照決定退役：每次都跑開啟與關閉 skill 兩種版本，模型不靠 skill 也能達標，就可以退掉它，但 eval 要留著。

影片從哪一段開始看16 段

1. 00:12舉手調查與 SkillsBench現場幾乎人人用 skills，有 evals 的只有少數。SkillsBench 索引 50,000 多個 skills，幾乎都沒有 evals、多半是 AI 寫的；agent 不確定性高，失敗時分不清是 skill 不好還是任務太難。
2. 01:33自用與給客戶的 agent自己用 coding agent 時，skill 沒觸發馬上看得出來；替客戶做的 agent，使用者根本不知道有 skill 這回事。
3. 02:22skill 是什麼skill 是一個資料夾，裡面有 skill.md 檔與輔助檔案，靠漸進式揭露分成 description、本文、參考檔三層。
4. 03:11兩種 skillcapability skills 是暫時的，模型變強就能移除；preference skills 比較持久，要用 evals 保護。
5. 04:08skills 有沒有用SkillsBench 1.1 顯示 skills 平均提升約 15% 表現。Philipp 自己的觀察是人寫的 skill 最好，AI 生成的可能拖累表現，skill.md 應在 500 行以內。
6. 05:29兩種觸發方式模型觸發靠 description，使用者觸發則被低估；固定的開發流程多半適合做成使用者觸發，替客戶做的 agent 只剩模型觸發。
7. 06:31寫 skill 要點：descriptiondescription 要交代為什麼、怎麼用、何時用，寫成指令而不是論述，例如「做聊天應用就用 Interactions API」。
8. 07:56保持精簡、分層description 每次模型呼叫都要付 100 到 200 個 token；多雲部署這類細節放進各自的參考檔，不塞進 skill 本文。
9. 09:01自由度與負面案例步驟固定就寫腳本，skill 只給目標與限制；description 寫得太寬（如 web development）會過度觸發，要限縮到 React 元件或 Tailwind CSS。
10. 10:27提早測試新 skill 先備 10 到 20 個 prompt：五個該觸發、五個不該觸發，有真實客戶資料就一併納入。
11. 10:59砍掉 no-ops 與退役時機Matt 發現 AI 生成的 skill 常有 no-ops；模型不靠 skill 也達標時就退役，省 token 也省維護。
12. 12:21案例：Gemini Interactions APIInteractions API 在 Gemini 最近一次訓練之後才發布。團隊從真實使用者資料、合成案例與回饋整理出 117 個測試案例，把產生有效 Interactions API 程式碼的比例推到近 90%。
13. 13:29兩個檔案的 eval harness一份 JSON 存 prompt、語言（TypeScript 與 Python）、該不該觸發與預期檢查；一支 Python 腳本跑 Gemini CLI 收輸出。多數檢查是 regex，便宜到每換模型都能重跑，複雜情況才用 LLM as a judge。
14. 15:51Google DeepMind 的做法每個 skill 旁邊都放 evals，在乾淨工作區跑，用腳本驗證器與 LLM as a judge 檢查；每次改動都跑一遍，沒讓測試變好就不能合併。
15. 17:16十個最佳實務description 最關鍵，他們看到 50% 的失敗來自 skill 沒被正確觸發；其餘是寫指令、負面測試、先小量起步、測結果不測路徑、隔離執行、每個案例跑三到六次、跨 harness 測試，以及 skill 退役後 eval 照樣留著。
16. 20:12回去的作業挑最常用的 skill 寫五個測試 prompt，清掉 no-ops，並一律跑有 skill 與沒 skill 兩種版本。

值得記的話5 句

• Everyone uses skills. No one has evals.大家都在用 skills，沒有人有 evals00:44

• human-written skills are the best we can provide. AI-generated skills can impact performance negatively.人寫的 skill 是我們能給的最好版本，AI 生成的 skill 可能拉低表現。這是 Philipp 自己的觀察05:13

• We should write directives instead of essays.我們應該寫指令，而不是寫論述。講的是 skill 的 description07:21

• definitely create outcomes, not paths.一定要以結果為準，不是路徑18:06

• Only that way you will know when you can retire a skill or if a skill is really helpful for your performance.只有這樣，才知道什麼時候能退役一個 skill，或它是不是真的有幫助21:16

名詞與人物10 個

SkillsBench

公開的 skills 評測，約 100 個涵蓋程式與生產力的任務，有排行榜，並開放社群貢獻

capability skills

教模型目前做不穩的事，屬暫時性質，模型變強後可退役

preference skills

記錄團隊專屬的流程、風格或語言偏好，較持久，要用 evals 保護

progressive disclosure

skill 分層載入：先放 description，需要時才讀本文與參考檔

model-invoked / user-invoked skills

前者由模型依 description 判斷是否使用，後者由使用者用指令主動觸發

no-ops

對 agent 行為沒有影響的指令，AI 生成的 skill 常夾帶，只會多花 token

ablation tests

同一批 evals 分別在有 skill 與沒有 skill 時各跑一次，用差異判斷 skill 有沒有用

Gemini Interactions API

Google 與 Gemini 模型和 agent 互動的新介面，發布時間晚於 Gemini 最近一次訓練

Gemini CLI

這個案例裡由 Python 腳本驅動、用來跑 skill 評測的 coding agent

LLM as a judge

讓另一個模型對輸出判定通過或失敗，用在 regex 不夠用的複雜 skill

提到但沒有展開

• Philipp 建議用 coding agent 回看自己的對話軌跡，找出最常用的 skills，再從中挑一個起手寫 evals。
• 要隔離執行，是因為 coding agent 很會作弊：在既有環境裡跑，它可能翻出之前的對話或執行紀錄，不用 skill 也拿到 skill 的內容。

Agent評估開發工具Google

在 YouTube 看原片 ↗