「Skill 將死，方法論永生」這句話值得保留，但不該照字面執行。會被淘汰的，是反覆解釋模型早已能處理的通用知識；不會被淘汰的，是把任務範圍、可接受證據與副作用邊界留在模型外的工作契約。

原貼文把第一性原理、對抗式審查、消融實驗、奧卡姆剃刀、不確定性、獨立思考、批判性思維與高內聚低耦合，整理成八個可放進 Agent 工作流的檢查角度。它的價值不在於湊出八句更厲害的 Prompt，而在於換一個問題：這段 Skill 是在提供模型缺少的情境，還是在重複描述一個沒有驗收的流程？

更強的模型需要更少指揮，不是更少約束

模型能力提升後，確實不必再用數百行文字交代「先讀檔、再思考、最後檢查」這類通用動作。Anthropic 對 context engineering 的建議也相近：保留高訊號脈絡，避免脆弱、過度指定的提示；但「minimal」不等於單純縮短，而是用最少的內容保留完成任務所需的狀態與判斷。Effective context engineering

所以不該把 1,000 行 Skill 壓成兩行口號。先拆掉其中沒有改變結果的重複說明，再保留模型無法自行得知的事：專案慣例、資料範圍、允許的工具、外部副作用的核准條件，以及什麼輸出才算通過。

留在 Skill 或 task contract交給模型的通用能力
repository 的測試命令與通過條件閱讀、摘要、提出實作選項
可讀與可寫的資料或路徑將需求拆成可執行步驟
部署、發信、付款等副作用的核准門檻依回饋修正草稿或程式
團隊術語、介面契約與例外處理對既有程式提出理解與假設

這也補足了「Skill 只是文字」的誤解。Skill 可以是可攜的程序與資源包，但宿主仍須負責 discovery、工具權限與驗收；詳細差別可參考本站的 25 個 AI Skills 真的能跨 Claude、ChatGPT 與 Gemini 使用嗎？。

用四個欄位取代一段泛用長指令

任何需要動手的 Agent 任務，先寫成下列最小契約。它比「請仔細完成並自行檢查」短，但每個欄位都能改變行為。

goal: 修正重複付款的 checkout bug
method:
  - 先以既有測試或紀錄確認問題可重現
  - 找到所有共用寫入路徑，再選最小根因修正
evidence:
  - 回歸測試在修正前失敗、修正後通過
  - 列出未覆蓋的付款情境
stop_when: 不可重現，或缺少可安全驗證的測試環境

「方法」不是逐鍵盤操作的劇本。它要求 Agent 做第一性原理的問題確認、先選最小可行解，再明確列出不自信的地方。這也是原貼文中奧卡姆剃刀與不確定性聲明可落地的版本。

對抗式審查與消融，只在能改變決策時使用

獨立 reviewer 的任務不該是重述實作者的結論，而是找出反例、遺漏與失敗場景，並附上證據。這在高風險變更、有多條可行路徑，或結果需要高信心時有價值；一行 CSS 改動不值得為此開一個 agent team。

同樣地，消融不是每次都要做正式實驗。當團隊不確定某條規則、某個工具或某段 Prompt 是否真的貢獻結果，才在其餘條件盡量相同時移除它並比較。若品質、成本或失敗率沒有可量測差異，就刪除它。這是讓 Skill 不再無限膨脹的唯一可靠理由。

Anthropic 公開的費馬最後定理形式化案例也說明了另一面：多 agent 成功依賴的不是長篇角色指令，而是可保存的 theorem 描述、DAG 狀態與協作 harness；早期嘗試曾因專案狀態遺失而受阻。Formalizing Fermat’s Last Theorem 這不證明每個任務都該多 agent 化，反而證明需要留下的是能接手與驗證的外部狀態。

先刪一段，再觀察結果

下一次要新增或修改 Skill 時，先挑一段最通用的規則，暫時移除後跑同一個真實任務。若結果、風險與驗證都沒有變差，就永久刪掉；若變差，將它改寫成能指出資料範圍、證據或停止條件的一句契約。Skill 不必死亡，但它應停止扮演模型訓練資料的影印機。