Claude Academy
載入中

擷取為 intent.md

第 2 課4 分鐘

啟動軟體開發流程的 intent.md，可以透過不同的途徑產生。可能是某人有了一個想法、提出了一張工單，或是透過警示發現了一個事件（參見第 6 階段：維護）。

當某人有了一個想法時，他們會與 Claude 一起進行腦力激盪，並產出一份 Markdown 格式的初步規格草案。在傳統的 SDLC 中，同一個人接下來必須說服產品團隊的成員與他們一起撰寫，或代表他們撰寫這個想法。

由 Claude 產生的初步規格草案具有人類可讀性、受版本控制，並可立即供下一階段使用。這份初步規格草案會以 intent.md 的形式儲存。

無論意圖是源自於事件觸發還是源自於某個人，所適用的步驟都相同：產品負責人會在提交之前，審查並修正由代理程式撰寫的 intent.md。

有何改變

傳統方式AI 原生方式
一個想法在任何人能夠對其採取行動之前，必須經過待辦事項清單、使用者故事、故事點數以及細化會議。每次交接時所有權都會轉移，因此最終到達工程團隊手中的內容，已經與發起人最初的意思相差了好幾個步驟。發起人與 Claude 一起進行腦力激盪，並將結果以發起人自己的用語寫成 intent.md，這是一份初步規格草案。此產出物包含了想要什麼、為什麼想要，以及在什麼限制條件下。重複性的流程則透過技能（skills）來編碼。

開始使用

  • 先決條件：無。
  • 基礎設施：讓非工程師人員也能使用 Claude（claude.ai 或 Cowork）；一份已達成共識的 intent.md 範本；一個共享、受版本控制的意圖存放處，供產品負責人關注。對於單一產品而言，最簡單的存放處是產品儲存庫中的一個 intent/ 資料夾。這樣的設定可讓產出物鏈與由其衍生的程式碼保持在一起。只有當意圖跨越多個儲存庫時，才值得為此建立一個專用的意圖儲存庫；而在單一儲存庫（monorepo）中，它就只是一個目錄。第 3 階段：建置中的舊系統章節，說明了這個存放處與已經保存記錄的 Jira 或需求工具之間的關係。

建立這套設定是平台或工程團隊的一次性任務。需要有一位技術團隊成員來建立意圖存放處，並決定誰可以寫入其中，因為許多貢獻者將來自組織內的各個部門。

一旦儲存庫建立完成，沒有 Git 經驗的貢獻者就不需要直接使用 Git。取而代之的是，一個連接到版本控制系統（例如 GitHub）的連接器，可讓 Claude 代表他們從 claude.ai 或 Cowork 提交 Markdown 檔案。

如何執行

  1. 發起人用自己的話向 Claude 描述問題。發起人可以描述他們目前做不到的事、這個想法會影響到誰、更好的結果是什麼樣子，或是哪些內容不在範圍之內。不需要使用正式的語言。
  2. 持續進行腦力激盪，直到這個想法變得具體為止。Claude 會提出分析師會問的問題：範圍、使用者、限制條件，以及成功的樣貌是什麼。
  3. 請 Claude 使用組織的範本，將結果寫成 intent.md，這個範本可以編碼為一套技能，由技術團隊成員建立並由主管簽核。這可以涵蓋問題、提議的結果、受影響的使用者與系統、限制條件，以及尚待解決的問題。
  4. 發起人修正 Claude 誤解的任何內容。
  5. 將 intent.md 提交到共享的存放處。作者與時間戳記會加入記錄，產品負責人便可從那裡接手這個想法。

實際樣貌

intent.md：

markdown
# Intent: claims status self-service
Author: J. Ortiz (claims operations). Status: draft.
## Problem
Customers phone the contact center to ask where their claim is.
Handlers spend roughly a third of call time on status-only queries.
## Proposed outcome
Customers see claim status, next step and expected date in the portal.
## Affected users and systems
Claims handlers, portal team, claims-core API.
## Constraints
No new PII in the portal session. Existing authentication only.
## Open questions
Do third-party loss adjusters need access too?

治理考量

證據就是已提交的 intent.md，其中列出了作者、時間戳記，以及完整的修訂歷史。這會記錄在意圖存放處的 Git 歷史中。產品負責人進行核准，而將意圖送入第 2 階段：設計的接受或拒絕決定，會以合併（merge）或結案審查的形式記錄下來。

如何衡量

  • 領先指標：從第一次對話到提交 intent.md 所經過的時間，從意圖存放處的 Git 歷史中讀取，該歷史記錄了作者與時間戳記。預期這段時間會從原本需要數週的需求蒐集與細化循環，縮短為數小時。
  • 落後指標：存活率，也就是產品負責人接受進入第 2 階段：設計、而非關閉的 intent.md 檔案所占的比例。接受或拒絕的決定會以產出物的合併或結案審查的形式記錄下來。此外，也要計算在同一項變更的第一次 spec.md 提交之後，對 intent.md 所做的變更次數。