intent.md 是什麼？Claude Code 團隊公開的「AI 原生開發流程」，把你的意圖也變成一份檔案
半小時做完的事，為什麼專案還是卡住
深夜十一點，你盯著終端機。Agent 剛剛把一個功能的程式碼寫完、測試也一併跑完，訊息跳出來的時候你看了一眼時間戳記——半小時。同一件事，上禮拜你的團隊排了整整三天。
你正想關電腦收工，手機卻跳出一則通知：待整理的需求清單裡還躺著八張沒人碰過的單子，昨天那個 Pull Request 也還沒有人看。你突然意識到一件事——變快的只有「寫程式」這一段，其他每一段都還是老樣子。
這正是 Claude Code 創造者 Boris Cherny 與 Anthropic 團隊，最近公開一份「AI 原生軟體開發生命週期（SDLC）playbook」時，想直接點名的問題。YouTuber Rob Shocks 在他的頻道上把這份文件拆解了一遍，核心的一句話是：程式碼已經不是瓶頸了，你的流程才是。
「兩倍速」是真的，但只發生在一個地方
傳統的軟體開發生命週期，長得像這樣：規劃、設計、建置、測試、部署上線、維運，做完一輪再回到起點迎接下一個功能、下一個 bug、下一次發版。
在 Agent 出現之前，「建置」這一段幾乎永遠是耗時最長、也最貴的一段。Agent 出現之後，這一段被大幅壓縮——按 Rob Shocks 的說法，等於快了兩倍。問題是，規劃、設計、測試、審查、維運，沒有一個跟著一起變快。 Anthropic 這份文件想回答的，正是這個問題：Agent 幫我們把「建置」壓縮了，那其他每一個階段，要怎麼一起用 Agent 重新設計？
從「開會蒐集需求」到「跟 Agent 吵到彼此都同意」
先看規劃階段。傳統做法是坐下來開會、蒐集需求、寫 PRD、辦工作坊、跟利害關係人一輪一輪對焦。
在 Anthropic 描述的新流程裡，第一步反過來了：先讓 Agent 反覆訪問你，把你要做的功能、要修的 bug、或整個產品的樣貌問清楚，藉此建立起完整的上下文。Rob Shocks 提到他自己用的是一套叫「Switch Dimension Discovery」的探索式 skill，也提到市面上還有 Matt Pocock 做的「Realm」、或是 Cursor 內建的「Requirements Discovery」——工具可以不同，但目的一致：讓 Agent 一路追問，直到它真正搞懂你要的是什麼為止。你要做的，是把自己的經驗、對這個領域的理解、還有各種背景脈絡，盡量倒進這場對話裡。
Agent 接著把這些對話裡萃取出來的痛點整理、彙整，寫成一份檔案——intent.md。這份檔案的特別之處在於：人看得懂，機器也能直接拿去動作（human-readable and machine-actionable）。
傳統 SDLC 裡，一個想法會先變成待辦清單裡的一則使用者故事、算上故事點數、經過幾次交接才輪到人動手。而在 Anthropic 描述的世界裡，任何一個提出議題的人——不管是回報 bug 的客戶、有新功能想法的產品經理，還是想記錄流程優化點子的工程師——都可以直接跟 Claude 腦力激盪，把結果寫成一份 intent.md。實際做法很單純：專案裡開一個叫 `intent` 的資料夾，每一份 intent.md 就存在裡面。
這份檔案寫完後，工作還沒結束。提出這個意圖的人（Anthropic 稱之為 originator）需要回頭檢查 Agent 寫下的內容，確認彼此的理解一致——originator 不必是團隊裡的專家，任何人都可以扮演這個角色。之後，這些散落的 intent.md 會被匯集成類似待辦清單的東西，可能是一份份 markdown 檔，也可能整理進 Notion 或 Linear，由產品負責人來排序，甚至也可以交給 Agent 做初步分類——標上前端／後端、任務大小、功能類型、優先層級這類標籤。
intent.md 只是第一步：一條叫「artifact chain」的生產線
一旦 intent.md 拍板，流程就往下一站走——spec（規格）。Anthropic 建議，intent 一旦確認，就用一個 hook 或固定流程自動觸發 spec 的產生，並給出一個範例提示詞：讀取附上的 intent.md，產出一份需求與設計規格，套用你手上可用的 skill 去規劃並符合品牌規範，完整寫進 spec.md。這裡沒有標準答案——你可以直接用 Cursor、Claude Code 或 Codex 內建的 plan mode，也可以自己動手做一個專屬於團隊風格的 spec 產生 skill。
再往下走一步是 plan：工程師把 intent 與 spec 一起餵給 Agent 進入 plan mode，產出一份 plan.md。Anthropic 建議在這一步反過來質問這份計畫——問它「哪些改動可能會出錯」。目標是讓 plan.md 完整到一個地步：就算把它單獨交給另一位工程師，對方不用回頭看 intent 或 spec，也能直接照著執行。這一點特別重要，因為 Rob Shocks 特別提醒：這整條流程從來不是靠同一個 Agent 從頭做到尾——不同階段會由不同的 Agent、甚至不同的對話串（context window）接手，所以你要把 intent、spec、plan 這些「產物」當成正式的交接文件，讓下一個 Agent 能夠不帶著前面的對話記憶，直接從文件本身重新開始。
plan.md 本身也有固定寫法：列出需要改動的檔案、工作順序或待辦清單、風險與限制，以及「證明」——某種可驗證的成功標準，可能是 lint 檢查、可能是測試通過與否。Anthropic 也建議把 intent、spec、plan 每個版本、每次由誰異動都存下來，這是很多企業覺得最難落地、卻對追蹤成效（例如 DORA 指標）最關鍵的一塊。
進入 build（建置）之後，Anthropic 建議用「auto mode」加速——但 Rob Shocks 提醒這高度取決於你的組織：先在權限收緊的環境裡跑一陣子，逐步放寬，等你摸清楚哪些工具、哪些外部套件、哪些網路來源是可以放行的「合理使用範圍」，再把這套權限鎖進 Cursor 或 Claude 的設定裡，Agent 才能在你不必時刻盯著的情況下加速前進，同時把「炸裂半徑」控制住。團隊也建議搭配 worktree，讓多個 Agent 同時處理不同任務；而串起這一切、讓流程保持在軌道上的，是 hook——例如在建置完成後自動更新 plan、擋住 Agent 碰某些資料夾、或阻止它安裝一個還沒核准的 npm 套件。好一點的 Agent 執行環境還能把 plan 拆成多個獨立任務，交給多個 sub-agent 平行處理。
到了 test（測試）階段，Anthropic 的原則是：讓 Agent 在人類工程師或 QA 出手前，盡可能把測試做完——寫測試、跑 lint、跑建置確認沒有錯誤；如果團隊用到 Playwright 這類工具，甚至能讓 Agent 實際跑起服務、截圖、錄下操作過程再交回來。Anthropic 也建議每次 skill 更動或換模型時都跑一輪 evals：先收集個二十來個曾經處理過的真實案例與預期結果，每次有新模型、新規模、或工作方式有根本性改變時，就拿這組案例回測，確認整條 SDLC 有沒有退步。
進入 deploy（部署），Agent 依照人類已經完成的審查結果，開出一個 Pull Request；Anthropic 建議讓另一個 Claude 實例依照團隊的政策與安全規範，非同步地審查這個 PR——如果它不同意，還會有另一個 Claude 實例專門處理這些審查意見的往返。治理層面，你可以設計 hook，讓部署非得經過特定人核准、或滿足某個發版關卡才會放行；PR 通過後，還會有另一個 Agent 跑一輪安全與 CI 檢查，可能是決定性的 lint 與門檻檢查，也可能是像 Cursor Bugbot 或 Claude 的安全審查這類 Agent 幫你再抓一次錯。
最後是 maintenance（維運）——Rob Shocks 直言，這是整份文件裡「最有野心」的一段。傳統維運是被動的：你在吃午餐、你在待命、也可能是凌晨三點收到伺服器掛掉的警報，一張工單躺在堆積如山的待辦清單裡被徹底忽略。而在 AI 原生 SDLC 裡，一次資安事件、一張新工單、Slack 上的一則訊息，或是排程本身，都可以在完全沒有人參與的情況下喚醒 Claude，讓它非同步地去診斷、處理——而且它會依照發現的日誌或收到的訊息，自己生出一份 intent.md。實際運作上，你可能會先設好一些要守住的指標，一旦頁面掛掉或 API 流量突然衝高，就觸發 Agent 去診斷、寫出 intent、提出建議方案——全部發生在你還沒碰到電腦之前。
轉折：真正被考驗的不是 Agent 聰不聰明，是你有沒有把治理做好
看到這裡，很容易把這份 playbook 讀成「只要每個階段都塞進 Agent，流程就會自動變快」。但整理下來，真正撐起這條 artifact chain 的，其實是一堆不那麼性感的東西：把 intent、spec、plan 每個版本都存下來、標清楚誰動過；先在收緊的權限裡試跑再逐步放寬；用 hook 擋住不該碰的資料夾與套件；每次換模型都跑一輪回歸評估；PR 要有獨立的審查與安全門檻。少了任何一塊，「讓 Agent 接管整條 SDLC」很容易變成「讓 Agent 用更快的速度，把混亂複製到更多階段」。
Rob Shocks 自己也坦言，他在頻道上教的工作流跟 Anthropic 這份文件不完全一樣，市面上還有 Superpowers、BMAD 這類不同流派的做法——沒有一體適用的標準答案，重點是團隊要選定一套，並且盡量不要三天兩頭換。
從今天起，你要先寫的不是程式碼，是一份 intent.md
如果只能從這整套流程裡帶走一個習慣改變，大概是這個：下一次要做一個功能或修一個 bug 之前，先讓 Agent 反覆問你、把你腦子裡的上下文倒出來，寫成一份 intent.md，再往下走。
這也是為什麼這套流程對我們在意的另一件事特別有意思：一旦一個功能要經過 intent、spec、plan、build、test、deploy、maintain 七道關卡，每一道都可能是不同的 Agent、不同的模型在跑，跑的次數也遠比「一個 Agent 從頭寫到尾」多得多。流程標準化之後，用量會變得可預測，但也會變得更分散——這正是 AI Token King 想幫團隊解決的事：不管背後串了幾個 Agent、切了幾個模型，每一次呼叫用了哪個模型、花掉多少 Token、實際扣了多少錢，都能一次查清楚。
常見問題（FAQ）
Q1：intent.md 到底是什麼？
根據 Rob Shocks 轉述 Anthropic 團隊的做法，intent.md 是一份由「originator（提出議題的人）」跟 Claude 腦力激盪、整理出來的意圖文件，特色是「人看得懂、機器也能直接拿去動作」。它取代傳統待辦清單裡零散的使用者故事，成為後續 spec、plan 等產物的起點。
Q2：誰可以寫 intent.md？
任何人。可以是回報 bug 的客戶、想加功能的產品經理、或想記錄流程改善點子的工程師——不需要是團隊裡的專家。寫完之後，Anthropic 建議由提出議題的本人回頭檢查 Agent 整理的內容，確認雙方理解一致。
Q3：intent.md 跟 spec.md、plan.md 是什麼關係？
三者組成 Rob Shocks 所說的「artifact chain（產物鏈）」：intent.md 先確立要解決的問題與脈絡；一旦 intent 拍板，用 hook 或固定流程觸發產生 spec.md（需求與設計規格）；再由工程師把 intent 與 spec 一起餵給 Agent 進入 plan mode，產出 plan.md（具體改動的檔案、順序、風險與驗證標準）。
Q4：這是不是代表整條流程都可以無人值守？
不是。逐字稿裡多次強調人要留在關鍵審查點上：originator 要核對 intent、工程師要確認 plan 才能執行、部署前需要人核准或滿足發版關卡。Anthropic 談的是減少每一階段花掉的人力時間，而不是完全移除人的判斷。
Q5：這套流程一定要照抄 Anthropic 的版本嗎？
不用。Rob Shocks 自己在影片裡就說，他實際教學的工作流跟 Anthropic 這份文件並不完全一樣，市面上也有 Superpowers、BMAD 等不同流派。重點是團隊要選定一套並盡量標準化，而不是每個專案都換一套玩法。
資料來源聲明
本文內容整理自 YouTube 頻道 Rob Shocks 於 2026 年 9 月發布的影片《Claude Codes New INTENT.MD, What is It?》，內容為該頻道對 Anthropic（Claude Code 創作者 Boris Cherny 所在團隊）公開之「AI 原生軟體開發生命週期 playbook」的口語拆解與轉述，並非本文作者直接查閱 Anthropic 官方原始文件逐字引用；文中流程步驟、工具名稱（如 Switch Dimension Discovery、Realm、Cursor Requirements Discovery）均忠實反映影片內容，非逐字翻譯，為重新組織與論述後的整理。若你的團隊要正式導入類似流程，建議自行查閱 Anthropic 官方發布的原始文件以核對細節。
延伸閱讀
立即行動
當一個功能要跑過 intent、spec、plan、build、test、deploy、maintain 七道關卡，背後可能是好幾個 Agent、好幾個模型輪番上陣，Token 帳單也會跟著散落在一次次呼叫裡。免費試用 AI Token King，把每一次呼叫花掉的 Token、用的模型、實際扣的費用一次攤開來看，不管你的 AI 原生 SDLC 串了多少個 Agent 與模型，都能看得懂錢花去哪。
留言