Claude Academy
載入中

需求與設計

第 3 課5 分鐘

一旦產品負責人核准了 intent.md，Claude 就會接手並產出一份需求與設計規格。這個過程會依循組織在品牌、安全、合規與 UX 方面的技能來引導。

產品負責人會審查該規格，但不會親自撰寫。這個流程的目標是建立一份工程團隊可以據以規劃的規格，並標示出需要關注的疑慮點。

前端工作是最清楚的例子。一旦 intent.md 被接受，產品負責人就會根據 intent.md 在 Claude Design 中製作設計模型，反覆調整該模型，然後將其匯出到 Claude Code 進行建置。

有何改變

傳統方式AI 原生方式
需求與設計是由不同團隊分別執行的獨立階段。分析師將構想正式化為需求，然後設計師再將這些需求解析回設計。這種分工是為了課責，但速度慢且容易流失資訊。兩個階段在單一提示工作階段中完成。Claude 接收 intent.md，並在組織技能的約束下產出需求與設計規格，同時標示出需要關注的疑慮點。

開始使用

  • 先決條件：撰寫一份 intent.md 檔案，其中品牌、安全、合規與 UX 政策皆以技能的形式撰寫。
  • 基礎設施：一位擁有 Claude 存取權限的產品負責人。不需要工程技能。

如何執行

  1. 產品負責人開啟一個工作階段，該工作階段可使用組織的技能，並附上 intent.md。
  2. 產品負責人的提示會指向該意圖、點名各項限制條件，並要求標示出疑慮點。一開始先手動執行，之後再將其編寫成組織層級的斜線指令。接著，將 intent.md 在意圖主目錄中被接受作為觸發條件，設定一個非互動式工作，在合併時觸發，載入組織的技能執行該流程，並將 spec.md 以拉取請求（pull request）的形式提交（第 5 階段：部署中的 CI/CD 做法涵蓋了相關的管線設定）。從那時起，產品負責人首次介入就是進行審查。
  3. 同一位產品負責人會將規格對照構想進行審查。這份規格是否解決了所陳述的問題？intent.md 中的未決問題是否已獲得解答或被延續下去？
  4. 優先處理被標示出的疑慮點，因為這些正是分析師原本會上報的重點。產品負責人會在工程團隊看到規格之前，與各項政策的負責人一起解決每一個疑慮點。
  5. 將 spec.md 與 intent.md 一併提交。這組檔案記錄了當初的需求以及最終的決定。
  6. 產品負責人決定規格與意圖是否進入建置階段，對於組織歸類為較高風險的項目，會諮詢技術主管。這項決定永遠由真人團隊成員做出，而接受該規格正是啟動第 3 階段：建置中規劃模式（plan mode）流程的時刻。

實際樣貌

提示：

請閱讀附上的 intent.md，並為將其整合進我們現有程式碼庫產出一份需求與設計規格。請套用您可使用的技能，使此計畫符合我們的品牌指南、安全政策與 UX 標準。請將規格完整記錄為 spec.md，以便交付給工程團隊。請清楚描述任何需要關注的疑慮點，特別是在您無法同時滿足相互矛盾的政策時。

這個範例背後的 intent.md 來自一家保險公司，該公司希望客戶能在其入口網站中查看理賠案件的狀態。在此情境中，claims-api 是該入口網站的後端，而 claims-core 則是保存理賠資料的較舊內部系統。上述提示將其轉化為以下這份 spec.md：

markdown
# Spec: claims status self-service
From: intent.md (J. Ortiz, claims operations). Status: ready for product owner review.
Skills applied: secure-api-review, brand-voice, portal-ux.

## Requirements
- R1. A signed-in customer sees status, next step and expected date for each open claim.
- R2. Status is one of four states: received, in review, approved, paid.
- R3. The response carries those three fields and nothing else.
- R4. What the customer sees is at most 60 seconds old.

## Design
- New endpoint GET /claims/{id}/status in claims-api, behind the gateway JWT.
- claims-api reads the claim from claims-core. The portal never calls claims-core.
- New StatusPanel on the portal claims page. It caches each answer for 60 seconds.

## How each constraint in the intent is met
| Constraint | Met by |
| :---- | :---- |
| No new PII in the portal session | R3. None of the three fields is tagged pii in the schema. |
| Existing authentication only | The gateway JWT. No new login, token or role. |

## Open questions from the intent
- Do third-party loss adjusters need access too? Not answered. Carried forward as concern 1.

## Areas of concern
1. Loss adjusters have no portal account. Giving them access breaks "existing
   authentication only", so they are left out of this spec. Owner: security.
2. The portal-ux skill says every status shows a date. The brand-voice skill says
   never to state a payment date as a commitment. I cannot satisfy both as written.
   Proposed label: "Estimated date". Owner: compliance.
3. claims-core allows 50 requests a second. The 60-second cache should keep the
   portal under that, but nobody has load tested it. Owner: claims-core team.

這些需求都經過編號，以便計畫與審查可以引用它們。疑慮點 2 讓兩項技能彼此產生衝突，這正是該提示要求 Claude 標示出來的那種衝突。

治理考量

政策衝突不再是在數週後的審查中才被發現，而是在撰寫規格的當下就讀取並套用現行政策。組織的技能被套用為規格的限制條件。規格本身、產生該規格的提示，以及當時生效的技能版本，全都記錄在版本控制中。產品負責人會在規格上簽核，並將被標示出的疑慮點轉交給指定的政策負責人。

如何衡量成效

  • 領先指標：同一項變更中，intent.md 提交與 spec.md 提交之間經過的時間（兩個 Git 時間戳記之差），並與舊有的需求加設計週期相比較。
  • 落後指標：建置開始後的需求返工情況。計算在同一項變更的第一筆 plan.md 提交之後所提交的 spec.md 提交次數。Git 日誌可以直接提供這項資訊。