先別問它有多少功能。先問你自己一件事：你叫 AI 幫你寫一個登入功能的時候，它有沒有先問你規格、先寫測試、寫完自己跑一次安全檢查？

答案幾乎都是沒有。它直接開始敲 code。因為對一個 coding agent 來說，「把功能生出來」就是任務達成，中間那些寫 spec、補測試、審安全的動作，在它眼裡都是繞路。你不主動要求，它一步都不會做。

Addy Osmani——就是 Google Chrome 那位效能工程師——開源的 agent-skills，整件事就是衝著這個來的。它把 20 個資深工程師的工作流程（怎麼寫 spec、怎麼跑 TDD、怎麼做安全審查、怎麼記 ADR）封裝成一疊結構化的 Markdown，塞給 Claude Code、Cursor 這類 agent，讓工程紀律變成它的預設行為，而不是每次都要你在旁邊碎念。GitHub 上 22k+ 顆星，這個數字在開發者工具裡算是相當能打了。連結在文末。

所以問題就變成：這套值不值得你裝？以及更重要的——什麼時候它反而是個壞選擇？

它真正解掉的，是「你懶得每次都講一遍」

拿帶新人來比。一個很聰明但很急的新人，技術沒問題，可是你不盯著，他就跳過寫測試、跳過 code review，直接把東西推上去。於是你每天重複講一樣的話：先寫規格、記得補測試、上線前掃一次。講到你自己都煩。

agent-skills 做的事，就是把這些「你每次都要講的話」寫成一份新人手冊，讓 agent 每次開工自己翻。它的核心不是教 agent 新技術，而是幫你省掉「重複要求」這個動作。

它的架構分三層，但你真正會天天碰到的是最上面那層 Slash Commands。.claude/commands/ 底下放的是你直接下的指令，中間 agents/ 是幾個專職角色（persona），最底下 skills/ 才是那 20 個核心技能。平常你只要記 /spec、/plan、/build 這幾個命令就夠了，底下那兩層會自己被叫起來。有些技能甚至會自動觸發——你一開始設計 API，它就自己把 api-and-interface-design 這條規則掛上，不用你喊。

七個 Slash Commands 裡，我覺得最能看出這套東西用心的是 /ship。它不是叫 agent 自己看一遍就說「可以上」，而是同時派出三個專職 agent——一個 code reviewer、一個 security auditor、一個 test engineer——各查各的，最後匯總成一個 GO 或 NO-GO 的結論，還附一份 rollback plan。而且只要安全審查裡出現任何一條 Critical，預設直接 NO-GO，不跟你囉嗦。這裡有個技術細節要注意：這種並行的 fan-out 必須在同一個 turn 一次發出去，才會真的平行跑，不然就退化成一個接一個排隊，慢很多。

最有洞察的一招：它防的是 agent 找藉口

如果只看功能列表，你會覺得這不過是一堆 workflow 樣板。真正讓我停下來多看兩眼的，是每個 SKILL.md 裡固定有一段叫 Common Rationalizations——中文大概可以叫「防藉口對照表」。

這東西是幹嘛的？AI agent 在被要求做麻煩事的時候，會很自然地產生「合理化」的說法來跳過。比方它會告訴你「這功能很簡單，不用寫測試吧」。聽起來還挺有道理，很多工程師自己也這樣騙自己。agent-skills 就預先把這句藉口寫進對照表，右邊擺上標準回應：「你當下的信心不算數，測試保護的是未來的你和你的隊友。」

這招之所以聰明，是因為它治的不是技術問題，是心態問題。你去翻它引用的東西就懂了——大量出自 Google 那本《Software Engineering at Google》，Hyrum’s Law、Beyoncé Rule、Chesterton’s Fence、trunk-based development 全都在裡面。這些不是語法規則，是那種工作十年才會內化的判斷。把它們寫成 agent 每次都得對照的清單，等於是逼一個急性子的新人，在想抄捷徑的那一刻先看一眼老鳥會怎麼吐槽他。

還有一個我很吃這套的設計：每個技能的退出標準（Verification）寫得很硬。它明講「感覺對了」不算完成，你要交得出具體證據——測試輸出、build 結果。這一條看似小，其實是整套東西的骨氣所在。一個會自我宣稱「應該沒問題」的 agent 跟一個必須貼出測試綠燈才能收工的 agent，交出來的東西是兩個世界。

裝起來有多快，以及會卡在哪

Claude Code 的話兩行指令：

1
2
3
4
# 先把 marketplace 加進來
/plugin marketplace add addyosmani/agent-skills
# 再裝這個 plugin
/plugin install agent-skills@addy-agent-skills

大概唯一會踩到的坑是 SSH。如果你的 git 預設走 SSH，加 marketplace 的時候可能會噴權限錯誤。解法是叫 git 把這個來源改走 HTTPS：

1
git config --global url.https://github.com/.insteadOf git@github.com:

不是 Claude Code 也能用，只是要多動手。Cursor 就把 SKILL.md 複製到 .cursor/rules/；Gemini CLI 有 gemini skills install；再不然你連工具都不挑，直接把那些 Markdown 當 system prompt 貼進去也行——因為它本質上就是純文字的指導，沒有什麼執行檔在背後跑。

什麼情況它反而幫倒忙

講完好話，來講它不適合你的時候，這才是你該不該裝的關鍵。

第一種，也是最容易被忽略的：你的 agent 太弱。這套東西是靠自然語言「指導」agent，它沒有任何強制力。Claude Sonnet 這種夠強的模型會乖乖照著走，但換成一個能力弱一點的 agent，你會看到它讀了規則，然後只遵守一半——寫了 spec 卻還是跳過測試，或者審查跑到一半就自己說可以了。指導和強制之間的落差，全看你底下那顆模型撐不撐得住。指望用一份 Markdown 把弱 agent 調教成守紀律的老鳥，是會失望的。

第二種：你根本不常跑這套流程。這裡的判準很直白——你一天到底認真走幾次完整的開發流程？如果你多數時間只是叫 agent 改個字串、查個 log、寫個一次性的小腳本，那 /spec 到 /ship 這整套 gated 流程對你就是純負擔。每次都被要求寫規格、補測試、跑三個審查，你只想改一行字，這時候紀律不是保護你，是擋你的路。

還有個容易忽略的性質：這些 skill 是無狀態的。它不會記得你上次做過什麼，每個新 session 都重新觸發一次。所以你別期待它幫你維護跨天的專案脈絡，它管的是「這一次任務內」的紀律，不是專案記憶。另外 /ship 的並行前面提過，你要是把三個審查拆成三個 turn 慢慢發，那份「三人同時把關」的效果就沒了。非 Claude Code 工具還得手動複製 SKILL.md，每次它更新你都得再同步一次，這也是持續的小成本。

所以到底裝不裝

如果你的日常是用 Claude Code（或同等級的強 agent）在做有一定規模、要上正式環境的東西，而且你早就受夠了每次都得提醒它寫測試、掃安全——裝，而且現在就裝。它把你腦子裡那套「老鳥的自我要求」外化成 agent 每次都會翻的清單，這件事光是省下你的碎念力氣就值回票價，更別說那個 Critical 就 NO-GO 的 /ship 幫你擋掉的意外。

但如果你手上是弱模型，或你根本只拿 agent 做零碎雜事，那就別裝——你會被一堆你不需要的流程綁住，最後乾脆繞過它，那還不如一開始就不裝。工程紀律是給要走完整條路的人用的；只想抄近路的人，硬套一套紀律只會兩邊都不舒服。

專案連結在這：https://github.com/addyosmani/agent-skills（22k+ stars，作者 Addy Osmani，@addyosmani）。與其自己從零寫一份 agent 的規矩，不如先看看一個 Google 效能工程師是怎麼把老鳥的判斷寫成清單的——就算你最後不裝，那 20 個技能的目錄本身，就是一份不錯的「資深工程師到底在乎什麼」的檢查表。