The AI-Native SDLC Playbook：以 AI agent 為中心重畫開發流程

這是什麼

Anthropic 官方寫的長篇指南，講企業怎麼把整套軟體開發流程改成以 AI agent 為中心。開場主張是一句話：「Code is no longer the bottleneck」——程式碼不再是瓶頸。

對象寫得很明確：受監管產業（金融、醫療、政府）的工程組織。但它提出的檔案結構，個人或小團隊也用得上。

核心概念怎麼運作

傳統開發流程的設計前提是「寫程式最慢」，所以整套制度都在管控寫程式這件事。現在 AI 寫得飛快，瓶頸就移到人做的那些階段——規劃、審查、部署。

它的解法是把流程排成一個圈而不是直線，六個階段走完會回到開頭。而每一階段結束時，交出一份下一階段讀得懂的檔案，commit 進 git。三份主要檔案分別回答：想做什麼、規格是什麼、怎麼實作。因為都進了版本控制，commit 歷史本身就成了稽核軌跡。

規範不靠開會傳達，而是做成 skill 在需要時自動載入；品質關卡做成 hook，符合條件的動作攔下來要人批准。人的判斷則留在整個迴圈之上。

解決什麼問題

導入 AI 之後速度上去了，但治理跟不上——出事要追是誰批准的、依據什麼規範，全部說不清楚。這套做法把每個決策點都變成一份可追的檔案。

用到哪些東西

三份 markdown 檔案、一份記錄團隊內規的 CLAUDE.md、Skills、Hooks、持續進行的評測。成效指標分兩類：速度看流程跑多快，品質看返工幾次、缺陷在哪一關被抓到。

設計師可以怎麼用

這篇是寫給工程組織的，但有三件事對設計工作直接有用，由淺到深。

一、把你的設計規範變成檔案，不要停在文件。

命名規則、顏色階、字體規定，如果只活在 Figma 註解或某份沒人打開的 PDF 裡，做事的當下不會有人去翻它。做成 skill，它在產出的當下就自動生效。

從你最常被違反的那一條開始做，不要一次搬整套。 一條規則做成檔案、實際生效一次，比整理五十頁規範有用。

二、讓設計稿變成驗收條件，而不是參考資料。

文中那份實作計畫有一個「證明」欄位，裡面跟單元測試並列的是「截圖與批准的設計稿一致」。

你可以在自己的交付流程裡加同一句話。這改變的不是設計品質，是設計的地位——從「之後可以參考也可以忽略的東西」，變成「沒做到就是沒做完」。

三、先寫「想做什麼」，再開 Figma。

最前面那份檔案只回答四件事：問題是什麼、想要的結果、有什麼限制、還沒解決的問題。不需要任何工具，記事本就能寫。

它真正的價值不是產出文件，是把「還沒想清楚就開始畫」這件事擋在前面。

要注意的：這套是為多團隊、有合規稽核需求的組織設計的。你一個人接案不需要六個階段跟三份檔案。抽出對你有用的那一兩件，其餘不要照抄——照抄會變成儀式，而儀式會被放棄。