資深工程師的工作大多是那些不會出現在差異比較中的部分：規格、測試、審查、範圍管理，以及拒絕交付無法驗證的成果。AI 編碼代理預設會跳過這些部分。Agent Skills 是我嘗試讓這些流程成為必須的方案。

任何 AI 編碼代理的預設行為都是走最短路徑完成任務。你要求一個功能，它就寫出功能，卻不會詢問是否有規格、是否先寫測試、是否考慮變更是否跨越信任邊界，或檢查拉取請求對審查者的呈現。它產生代碼，宣告勝利，然後繼續下一個任務。

這正是每位資深工程師職涯中努力避免的失敗模式。資深工程師執行的任務包含許多不會出現在差異比較中的工作：揭露假設、撰寫規格、將工作拆分成可審查的部分、選擇枯燥的設計、留下結果正確的證據、將變更大小控制在人類可審查的範圍。這些步驟是區分能夠大規模交付可靠軟體的工程師與推送破壞性代碼者的關鍵。

代理跳過這些步驟的原因與初級工程師相同：這些步驟是隱形的。獎勵信號指向「任務完成」，而非「任務完成且設計文件存在」。因此，我們必須重新為代理加上資深工程師的支架。

Agent Skills 是我對這支架的嘗試。它已獲得超過 27,000 顆星，顯示並非只有我想要這樣的功能。本文將說明 README 未詳述的部分：每個設計選擇的原因、如何對應標準軟體開發生命週期（SDLC）與 Google 公開的工程實踐，以及即使你不安裝任何技能，也能從專案中借鑑的內容。

「技能」一詞在 Claude Code / Anthropic 詞彙中承擔重要角色，需精確定義。技能是一個帶有前置資料的 Markdown 文件，當情境需要時注入代理的上下文。它介於系統提示片段與操作手冊之間。

技能不是參考文件，不是「你應該知道的所有測試知識」。它是一個工作流程：代理遵循的一連串步驟，包含產生證據的檢查點，並以明確的結束標準收尾。

這個區別是關鍵。如果你把一篇 2,000 字的測試最佳實踐文章放入代理上下文，代理會閱讀並生成看似合理的文字，但跳過實際測試。若你放入工作流程（先寫失敗測試、執行並觀察失敗、寫最少代碼讓測試通過、重構），代理就有具體行動，你也有可驗證的結果。

流程勝於文字，工作流程勝於參考資料，有結束標準的步驟勝於無結束標準的文章。這一點區分了有用的技能與漂亮的 Markdown 文件，也解釋了為何許多「AI 規則」倉庫在實務中無效，因為它們只是文章。

倉庫中的二十個技能圍繞六個生命週期階段組織，並有七個斜線命令。Define (/spec) 決定你要建造什麼。Plan (/plan) 將工作拆解。Build (/build) 以垂直切片實作。Verify (/test) 證明功能正常。Review (/review) 捕捉遺漏。Ship (/ship) 安全交付給用戶。/code-simplify 貫穿整個流程底層。

這並非巧合，這是每個正常運作的工程組織都在執行的 SDLC，只是用不同詞彙表達。Google 稱之為設計文件 → 審查 → 實作 → 可讀性審查 → 上線清單。亞馬遜稱為倒推工作備忘錄與標準提升者。每個健康團隊都有這樣的循環。

AI 編碼代理的新問題是，大多數代理預設跳過這些階段。你要求功能，它直接給你實作，規格、計畫、測試、審查與上線清單全都不見。技能讓代理經歷資深工程師強迫自己經歷的階段，因為跳過這些階段會導致事故。

複雜功能可能連續啟動十一個技能，小錯誤修正可能用三個。路由器（using-agent-skills）決定哪些技能適用。重點是工作流程會依實際範圍調整，而非假設範圍。

專案中五個設計決策是支撐整體架構的關鍵，其他系統皆從這些決策衍生。

首先，工作流程必須可由代理執行；文章則不行。人類團隊亦然。若團隊手冊有 200 頁，沒有人會在時間壓力下閱讀。若是有檢查點的小型工作流程，大家會實際執行。

這是專案中最具特色的設計決策，也是我最希望其他團隊借鑑的。

每個技能包含一張表，列出代理（或疲憊工程師）可能用來跳過流程的常見藉口，並附上反駁文字。例如：

這之所以有效，是因為大型語言模型擅長合理化。它們會產生看似合理的段落，解釋為何某任務不需要規格，或為何某變更可不經審查合併。反合理化表是預寫的反駁，針對代理尚未說出的謊言。

這對人類團隊同樣適用。大多數工程品質下降不是有人故意做壞事，而是人們接受了看似合理的藉口，跳過不想做的部分。寫下反合理化的團隊，會減少這種情況。

每個技能以具體證據結束。測試通過、建置輸出乾淨、執行追蹤符合預期、審查者簽字。僅憑「看起來沒問題」永遠不夠。

這與 Anthropic 的失敗恢復機制、Cursor 的規劃者/工作者/裁判分工能捕捉錯誤，以及任何長時間運行代理可恢復性原理相同。代理是生成器，你需要獨立信號證明工作完成。技能將此信號內建於每個工作流程。

不要在會話開始時載入全部二十個技能。根據階段啟動它們。一個小型元技能（using-agent-skills）作為路由器，決定當前任務適用哪個技能。

這是將駕馭工程教訓應用於技能粒度。每個載入上下文的字元都會在某處降低效能，因此只載入相關部分，其他留在磁碟。漸進式揭露讓你能在 5,000 字元的上下文中使用二十個技能庫，避免污染上下文。

元技能編碼了一條不可妥協的原則，我若能會釘在每個代理上：「只觸碰被要求觸碰的部分」。不要重構相鄰系統。不要移除不完全理解的代碼。不要碰到 TODO 就決定重寫整個檔案。

這聽起來理所當然，直到你看到代理認為修一個錯誤需要現代化三個不相關檔案。範圍管理是決定代理拉取請求是否可合併或必須回退的最大因素。這也是最符合 Google 代碼審查規範的原則，審查者會阻擋一次做多件事的拉取請求。

這些技能充滿了 Google 軟體工程與公開工程文化的實踐。這是刻意為之。大部分讓 Google 規模軟體運作的關鍵已公開，卻是代理最可能跳過的部分。

部分技能與實踐對應：

這些都不是新概念，重點是代理預設不會執行它們。前沿模型可能在訓練資料中讀過「Hyrum’s Law」一詞，但不會在凌晨三點設計你的 API 時應用它。技能確保代理會遵守。

有三種模式，承諾程度逐漸增加。

模式一：透過市集安裝。若你使用 Claude Code：

你會得到斜線命令（/spec、/plan、/build、/test、/review、/ship、/code-simplify），代理會根據上下文自動啟動相關技能。這是我推薦大多數人開始的路徑。

模式二：將 Markdown 檔放入你選擇的工具。技能是帶前置資料的純 Markdown。Cursor 用戶放在 .cursor/rules/。Gemini CLI 有自己的安裝路徑。Codex、Aider、Windsurf、OpenCode 或任何接受系統提示的工具都能讀取。工具重要性不及底層工作流程。

模式三：將技能當作規格閱讀。即使你不安裝任何東西，技能也是 AI 代理良好工程實踐的文件描述。閱讀 code-review-and-quality.md，將五軸框架應用於團隊審查流程。閱讀 test-driven-development.md，用它解決與初級工程師的「是否先寫測試」爭論。閱讀元技能，偷取五項不可妥協原則，放入自己的 AGENTS.md。

我會從第三種模式開始。挑選四五個最貼近你痛點的技能，決定要強制執行哪些工作流程，然後安裝執行環境或自行實作強制機制。

無論是否使用 AI 編碼代理，我都會借鑑專案中的幾個模式。

反合理化作為團隊實踐。寫下團隊自我欺騙的謊言：「我們會在上線後修測試」、「這變更太小不需要設計文件」、「沒關係，我們有監控」。並配上反駁。放入 AGENTS.md 或工程維基。它能避免爭論，也能阻止下次疲憊的週五下午捷徑。

內部文件重流程輕文字。若你寫了 2,000 字的「我們如何處理 X」文件，那是參考資料。將它轉成帶檢查點的工作流程，文件縮短到 400 字，且人們會執行。這適用於入職指南、操作手冊及代理技能。

驗證作為嚴格結束標準。讓「產生證據」成為每項任務的結束步驟。對代理、工程師、你自己皆然。證據是證明工作完成的任何東西：綠燈測試、截圖、日誌、審查通過。沒有證據，任務未完成。「看起來沒問題」永遠不算完成。

規則書採漸進式揭露。不要寫 50 頁手冊。寫一個小型路由器，指向適合情境的小章節。這適用於 AGENTS.md、操作手冊、事故應變手冊，及任何在時間壓力下會被閱讀的文件。

元技能中五項不可妥協原則，我明天就會放入任何 AGENTS.md：

這五行文字即是一種值得推崇的工程文化，且不需安裝任何東西即可採用。

從更廣泛角度看，技能是代理駕馭工程的一層。駕馭包含模型與你圍繞它建構的一切；技能是可重用的工作流程片段，漸進式揭露進系統提示。它們與 AGENTS.md（滾動規則書）、掛鉤（確定性執行層）、工具（代理可採取的行動）及會話日誌（持久記憶）並列。每層有特定職責。技能負責資深工程師流程。

技能對長時間運行代理比對聊天型代理更重要，因為長時間運行會放大每個捷徑。10 分鐘會話跳過測試會產生一個錯誤；30 小時會話跳過測試會產生一個調試考古專案，沒人記得原意。運行時間越長，資深工程師支架越必須強制執行，而非建議。

技能格式的可攜性也很重要。相同的 SKILL.md 檔可用於 Claude Code、Cursor（搭配規則）、Gemini CLI、Codex 及任何接受系統提示內容的駕馭。寫一次工作流程，執行環境負責強制。這是 Markdown 加前置資料格式帶來的優勢，非定制提示工程可比。

我最希望大家從專案中帶走的，不只是技能本身，而是思維框架。

AI 編碼代理是非常有能力的初級工程師，卻沒有對差異比較外工作的直覺。資深工程師工作（揭露假設、控制變更範圍、撰寫規格、留下證據、拒絕合併無法審查的代碼）正是代理會跳過的，除非你讓它無法逃避。這份工作，越來越多，是將這種紀律編碼成代理無法自我辯解的規則。

技能是其中一種形式。反合理化表、漸進式揭露、流程勝於文字、驗證作為關鍵結束標準、已驗證有效的 Google 實踐，且具可攜性。

你可以安裝我的版本，也可以自行實作。無論如何，教訓是：資深工程師的工作不再是選項，即使工程師是模型。

專案位於 github.com/addyosmani/agent-skills（MIT 授權）。欲了解更廣泛的駕馭架構，請參考 Agent Harness Engineering 與 Long-running Agents。

我在 O'Reilly 出版的 AI 輔助與代理工程書籍涵蓋規格、駕馭、評估、上下文與使用 AI 發佈生產級軟體。

免責聲明：本網站所表達的觀點與意見為作者個人觀點，不代表 Google 或其任何關係企業的立場或策略。