完整流程很省心，也真的很慢
一開始使用 Superpowers 時，我真的覺得很省事。
它會先幫你釐清需求、討論設計、產生實作計畫，再依照計畫寫程式、跑測試、做 code review。很多以前需要自己提醒 AI 的事情，它都已經包進一套完整流程裡。
對剛開始使用 Coding Agent 的人來說，這種體驗很有安全感。你不用一直想下一步該下什麼指令，也比較不容易遇到 AI 沒搞懂需求，就直接開始亂改程式的情況。
用了一段時間後，另一個問題浮現了：整套流程真的很慢。慢的不是模型產生文字或程式碼的速度，而是需求確認、設計、規格、任務拆解和多輪 review 全部疊在一起。對大型任務來說，這些步驟各有作用；放到幾分鐘能完成的小修改上，流程成本反而可能超過實作本身。
有些修改其實非常明確，可能只是調整一個條件、補一段 error handling、修改一個 SQL 欄位，或修正幾行程式碼。正常情況下，Agent 找到位置、完成修改、跑過相關測試，幾分鐘就能結束。
套用完整工作流後，Agent 可能會先重新確認需求，再討論設計、產生規格、拆成好幾個 implementation tasks，接著逐項執行、驗證，最後再做多輪 review。每個步驟單獨看都合理，疊在小任務上卻顯得太重。
這讓我開始思考：
AI Coding 工作流的目標，究竟是讓每一個任務都走完一套完整流程，還是讓 Agent 根據任務的大小與風險，選擇剛剛好的流程？
流程成本要跟任務風險相稱
Superpowers 將自己定位為一套完整的軟體開發方法，包含需求討論、設計、規劃、TDD、分工執行、review 與分支收尾。面對架構修改、跨服務變更或長時間自主執行，這套流程能提早暴露錯誤方向。
例如：
- 開發一個全新的功能
- 修改系統架構
- 涉及多個服務
- 進行資料 migration
- Agent 需要自主執行很長一段時間
這些情況下，先討論清楚、再規劃、分階段驗證，可以避免 Agent 做到一半才發現方向錯了。
小任務只需要快速理解、精準修改與必要驗證；方向清楚但牽涉數個模組時，可以加一份簡短計畫；需求模糊、範圍廣或風險高，才值得啟動完整流程。
Matt Pocock 的 Skill，價值不只在比較短
後來我開始閱讀 Matt Pocock 公開的 Skills。
Matt Pocock 將自己的 Skills 描述為小型、容易調整，而且可以互相組合。提問、除錯、TDD 和 code review 分別由不同 Skill 處理，不必塞進同一份工作流。
例如，需求還不清楚時，可以使用負責提問和釐清的 Skill；遇到難解的錯誤時，使用 diagnosing-bugs；需要測試驅動開發時，使用 tdd；準備檢查程式碼時，再使用 code-review。
這些工程紀律都還在，只是可以按照任務選擇，不必每次同時出現。
從這種設計延伸到我的使用方式，就是先判斷任務，再決定要加入哪些工程紀律。幾分鐘的小修改可以直接修改並驗證；任務變複雜後，再逐步加入研究、規劃、TDD 和 review。
Skill 拆小後，才知道該改哪裡
當一個 Skill 同時負責需求分析、設計、實作、測試、review 和交付時，行為出了問題，很難確認該修改哪個部分。
- 除錯流程有問題，就改
diagnosing-bugs - 測試方式有問題，就改
tdd - code review 太冗長，就調整
code-review - 需求尚未釐清，再啟動訪談或規格流程
能力拆小後，問題比較容易定位，使用者也能依照任務情況，決定要把流程開到什麼程度。
Skill 寫得短，不代表內容比較隨便
Skill 可以保持精簡，是因為資訊不必全部擠在同一個地方。
在 Matt 現行的分類裡，model-invoked Skill 需要留下可供模型判斷的 description，因此會增加每輪的 context load；user-invoked Skill 則以 disable-model-invocation: true 關閉自動觸發。
同一份文件也使用 progressive disclosure：每次執行都需要的步驟留在 Skill 裡，只有特定分支才需要的規則放進參考文件，等真的用到時再讀取。
其他 Agent 產品的實作可能不同，但設計問題相同：哪些資訊真的需要一直留在模型眼前？不是所有重要內容都要常駐，規則寫得更多，也不保證 Agent 更可靠。
每一段提示詞，都應該證明自己為什麼需要在現在被模型看到。
模型升級後，舊規則要重新驗證
LLM 的能力一直在變。新模型發布後，理解程式碼、搜尋專案、規劃修改、呼叫工具與驗證結果的能力，都可能比上一代更好。
過去必須寫進 AGENTS.md 或 Skill 的提醒，到了新模型上，可能已經成為它原本就會做的事。例如：
- 先閱讀相關程式碼
- 修改前先理解現有架構
- 找出根因，不只修表面問題
- 完成後執行測試
- 回報修改了哪些檔案
- 資訊不足時先搜尋專案
這些指令在舊模型上可能有幫助。新模型如果原本就會做，繼續保留不一定能提升品質，反而可能把幾分鐘能完成的任務推進完整的分析、規劃和回報流程。
我的判斷是，模型升級會讓一部分舊規則失去作用。Skill 仍然有用，只是某些通用能力可能已被模型吸收；是否真的能刪，仍要用實際任務比較。
Prompt 也會累積技術債
每次 Agent 犯錯時，我們很自然會多加一條規則。
上次忘記跑測試，就規定每次都跑完整測試；上次沒搞懂需求，就要求所有修改都先進行訪談；上次改壞架構，就要求每次都先產生設計文件；上次漏掉問題，就再加一輪 review。
每一條規則都有合理的來歷，但我們通常只會增加，很少回頭刪除。
Matt 把這種只加不刪的陳舊規則稱為 sediment：舊指令一層層沉積，最後留下重複、過時，甚至互相衝突的要求。Prompt 和程式碼一樣會累積技術債，也需要定期重構。
用移除測試找出 no-op
很多提示詞看起來都很正確：
- 請仔細思考
- 請遵循最佳實踐
- 請確保程式碼品質
- 請完整分析問題
- 完成後請確認沒有遺漏
維護 Skill 時，我會直接做一個測試：拿掉這句話，模型的行為有沒有變差？
Matt 將不會改變模型預設行為的指令稱為 no-op。像「請仔細思考」或「請確保程式碼品質」這類句子，如果移除後結果沒有差別，留下來只會增加 context 和維護成本。
真正有價值的規則通常更具體：
- 修改後必須執行哪一條測試指令
- 哪些模組不能修改
- 哪些 API 必須維持相容
- 哪些 edge cases 一定要覆蓋
- 必須提供哪些驗證結果
- 什麼情況下才可以把任務標成完成
「請做好」只是期待。「必須通過這三項測試」才是可以驗證的要求。
哪些內容不容易被新模型取代？
模型越來越強後，我認為還是有三類資訊值得長期保留。
第一類：模型不可能自己知道的專案資訊
例如：
- 專案真正的測試與部署指令
- 公司內部的業務名詞
- 哪份文件才是正確來源
- 各個模組實際負責什麼
- 程式碼裡看不出來的環境限制
模型無法從公開資訊或程式碼自行推知公司內部規則，這些內容仍然需要由團隊明確提供。
第二類：不能讓模型自己決定的邊界
例如：
- 不得修改公開 API
- 必須維持 backward compatibility
- 不可以新增 dependency
- 只能修改指定的服務
- Production 資料不能拿來本機測試
這些是團隊的決策。模型再強，也沒有權力替團隊改變限制。
第三類：可以明確驗證的完成條件
例如：
- 哪些測試一定要通過
- 哪些情境必須驗證
- 要提供哪些 evidence
- 哪些既有行為不能改變
- 什麼結果才算真正完成
這類規則通常比冗長的流程更有效。它不需要規定 Agent 每一步怎麼走，但會清楚告訴它最後必須交出什麼結果。
為上一代模型準備的護欄，可能成為下一代模型的限制
有些 Skill 的內容，是在修補特定模型的弱點。
假設舊模型不擅長找測試檔案，我們可能會寫下一套非常詳細的搜尋步驟。換成新模型後，它已經可以自己找到更適合的測試位置，舊流程卻仍然強迫它照固定步驟搜尋。這時原本的護欄就可能變成限制。
所以每次更換主要模型後，都應該重新檢查原本的 Prompt 和 Skills：
- 先不載入額外規則，觀察新模型自然會怎麼做
- 再加入原本的
AGENTS.md和 Skills - 比較結果是否真的變好
- 找出哪些規則只是在重複模型原本的能力
- 刪除沒有改善結果，卻增加流程的內容
- 把低頻資訊改成需要時才載入
- 保留專案事實、工程邊界與完成條件
這就像軟體升級後重新檢查以前的 workaround。底層問題已經不存在時，補丁不該永遠留著。
Agent 規劃太多，問題未必出在 Skill
同一份 Skill 放進不同模型、Agent 產品或版本，可能出現完全不同的結果。觸發方式、context 載入、壓縮機制和工具權限都會影響行為。
一個 Coding Agent 的行為，通常同時受到幾個層次影響：
- 模型本身
- Agent 產品內建的系統指令
- 專案中的
AGENTS.md - Skill 的描述與內容
plugin或hook自動注入的流程- Agent 可以使用的工具
- context 壓縮方式
subagent收到的任務資訊
因此，看到 Agent 對小修改產生龐大計畫時，先確認是哪一層下了這個要求。可能是模型偏好先規劃、系統指令要求列計畫、AGENTS.md 規定先寫規格、Skill 的觸發範圍太廣，也可能是 plugin 在 session 開始時自動注入完整流程。
表面上都是「Agent 規劃太多」，修正方式卻完全不同。
讀源碼時，只追一條行為路徑
讀源碼時，我只先追一條路徑：從輸入任務，到 Agent 載入 Skill、選擇工具並執行，中間經過哪些判斷？接著確認：
- Agent 會去哪裡找 Skill？
- 哪些內容會一直放在 context 裡？
- Skill 是手動啟動，還是模型自動選擇？
- 同名 Skill 發生衝突時，哪一個優先？
- 對話被壓縮後，哪些規則還會留下？
subagent拿到的是完整任務，還是摘要後的版本？- Skill 要求的工具，在目前環境中是否真的存在？
知道這些之後，Agent 做錯事時，才知道應該修改哪一層。否則我們很容易一直改 Prompt，實際問題卻是 Skill 沒有被載入，或者工具沒有相關權限。
把控制放在適合的層
Agent 的行為由多個層次共同決定。專案資訊可以放在 AGENTS.md，特定流程放進 Skill，危險操作交給權限限制，結果則由測試、lint、CI 和完成條件驗證。
例如：
- 用
AGENTS.md保存每次都需要的專案資訊 - 用 Skill 封裝特定任務才需要的流程
- 用 Skill description 控制觸發時機
- 用 reference 保存低頻細節
- 用權限限制危險操作
- 用測試和 lint 驗證結果
- 用完成條件決定任務能不能結束
- 用
hook處理每次都必須自動執行的動作
如果只是怕 Agent 忘記跑測試，直接提供一個清楚的驗證指令，甚至把檢查放進 CI，通常比三段提醒可靠。擔心 Agent 修改不該碰的地方，也可以用權限、模組邊界或 review gate 處理。
Prompt 只是其中一層。
從 Prompt Engineering 走向 Agent Engineering
現在的 Coding Agent 由模型、context、tools、Skills、plugins、hooks、subagents 和外部系統共同組成。使用者需要決定哪些資訊每次都要提供、哪些能力按需載入、哪些邊界交由系統限制，以及哪些結果必須透過工具驗證。
我會把這種工作稱為 Agent Engineering：把整套 Agent 視為可觀察、測試、調整與除錯的系統。
我會如何重新整理自己的 Skills
接下來，我會用五個問題整理自己的 AGENTS.md 和 Skills：
- 這個任務真的需要完整流程嗎？
- 這段資訊是否每一輪都必須出現在 context？
- 這個 Skill 是否只處理一個清楚的問題？
- 完成條件能否由測試、lint 或其他工具驗證？
- 換模型後，舊規則仍然會改善結果嗎？
完整流程和可組合 Skills 各有適用情境。現在我會在每次任務前再問三個問題：
這個任務需要多少流程？
這個模型還需要多少提醒？
這條規則，現在是否仍然值得存在？
好的 Skill，應該讓 Agent 在正確的時候做剛剛好的事。