意圖驅動開發

意圖驅動開發 是做什麼的？

產出有用的驗收條件，而不讓規範變成儀式。首先檢查可用的上下文，暴露真正的歧義，並選擇適合工作及其風險的驗證方法。

何時啟動

• 使用者要求釐清功能、定義驗收條件，或在實作前降低風險
• 請求涉及安全性、驗證、持久性資料、遷移、外部 API 或合規
• 使用者想要為另一個代理或團隊準備交接工件
• 請求模糊到預期結果尚不可觀察或可測試的程度
• 使用者使用 /intent-driven-development 明確呼叫此技能

對於瑣碎的編輯、直接的一行修正、活躍的除錯階段、程式碼審查請求，或驗收條件已經很清楚的實作請求，請勿啟動。

運作方式

1. 先檢查上下文 — 在提出任何問題之前，先讀取儲存庫、文件、架構和測試基礎設施以取得技術事實，同時將產品/業務限制視為只有使用者或產品工件才能提供的事物
2. 選擇深度 — 根據風險輪廓選擇快速捕捉（3-7 個標準，低/中等風險）或完整驗收簡報（安全性、資料、遷移、跨系統變更）
3. 最少提問 — 僅詢問那些答案無法推斷且會顯著改變範圍或行為的問題
4. 撰寫可觀察的標準 — 每個 AC-NNN 描述起始條件、觸發動作、預期結果、禁止的副作用、驗證方法和優先級；不使用模糊詞彙如「正確地」或「安全地」而沒有證據
5. 繼續或交接 — 對於清楚且無阻斷風險的請求，記錄標準後繼續；對於高風險變更，呈現阻斷因素並等待確認
6. 處理修訂 — 如果某個 AC 在實作中因架構限制無法滿足，將其標記為 [revised]，更新範圍或驗證方法，遞增修訂編號，並僅重新呈現變更後的標準

範例

快速捕捉 — "為儀表板新增 CSV 匯出"

目標：已驗證使用者可以將儀表板資料下載為 CSV 檔案。
範圍內：匯出當前篩選的行；檔案名包含日期。
範圍外：排程匯出、電子郵件傳送、Excel 格式。
假設：最大行數少於 10k；匯出欄位中無 PII。

AC-001：匯出產生的檔案包含正確的標題
- 情境：已驗證使用者，至少能看到一行資料
- 動作：點擊「匯出 CSV」
- 預期：瀏覽器下載的檔案包含欄位 [id, name, created_at]
- 不得：暴露內部欄位或其他使用者的行
- 驗證：自動化整合測試 + 手動綱要抽查
- 優先級：必要

完整驗收簡報觸發 — "將使用者驗證遷移到 OAuth"

驗證變更 + 外部依賴 + 現有會話資料 → 完整簡報，包含風險審查表、關於會話失效策略的阻斷決策，以及明確的回滾 AC。

現有規格審查 — 使用者貼上 PRD

技能審查其中遺漏的範圍邊界、無法驗證的需求（「系統應快速」），以及隱含的假設，然後返回修正或補充的標準，而不重新開始探索。

操作規則

1. 在詢問可在本地發現的技術事實之前，先檢查可用的儲存庫、文件、議題、設計和測試上下文。
2. 不從程式碼推斷產品或業務限制。業務規則、合規和法規義務、合約 SLA、定價、資料保留政策、優先順序和目標使用者無法從儲存庫讀取。將其視為未知，直到使用者提供或權威產品工件（PRD、合約、政策文件）陳述它們。將它們記錄為標記為確認的假設，從不作爲發現的事實。儲存庫告訴你系統今天如何運作，而不是業務要求它做什麼。
3. 僅詢問那些答案必要且無法安全推斷的問題。在必要時將簡短、相關的問題分組，以節省不必要的往返。
4. 預設情況下不阻止實作。當使用者要求實作足夠明確的變更時，簡短記錄關鍵假設和驗收標準，然後繼續或將其交給實作工作流程。
5. 僅在未解決的決策可能造成重大的安全暴露、資料遺失、不可逆的遷移、合約/API 破壞、有意義的成本或破壞性外部動作時，才需要明確的使用者確認才能繼續。
6. 除非使用者要求或活躍的儲存庫工作流程明確要求，否則不將驗收文件寫入儲存庫、不修改專案檔案、不建立分支、不提交、不呼叫其他技能。
7. 將自動化測試視為證據，而非真理。在可靠且合比例時偏好自動化；在自動化無法確定結果時，允許手動 UX、可訪問性、安全、法律或操作驗證。
8. 絕不在驗收標準、測試夾具、範例或儲存的工件中包含真實的秘密、憑證、令牌、私鑰、個人資料或敏感的生產負載。使用遮罩或合成值。
9. 未經明確授權並識別出安全的環境，不得對生產/即時資料執行破壞性測試、遷移、安全探測、負載測試、付費的外部呼叫或操作。
10. 當驗收標準因實作中發現的架構、平台或外部限制而無法滿足時，不要默默地丟棄或繞過它。更新受影響的標準（將其標記為 [revised]，說明限制，並調整範圍或驗證方法），遞增修訂編號，並僅在繼續之前向使用者重新呈現變更後的標準。僅在修訂更改了阻斷決策或顯著降低安全性或正確性保證時，才需要明確確認。

選擇深度

使用最小但有用的輸出。

快速捕捉

用於明確但非瑣碎且風險低或中等的變更。產出：

• 目標
• 範圍內 / 範圍外
• 假設
• 3-7 個驗收標準及驗證方法
• 阻斷性問題（如有）

除非存在操作規則中的阻斷風險，或使用者特別要求先進行規格說明，否則不延遲實作以等待核准。

完整驗收簡報

用於模糊、跨系統、安全敏感、資料變更、遷移、合規或高成本變更，或當使用者要求交接工件時。產出下方的完整範本，並在風險實作前請求確認未解決的阻斷決策。

現有規格審查

當使用者已提供 PRD、議題、計畫或驗收標準時：

1. 審查它們，而不是重新開始探索。
2. 識別遺漏的範圍邊界、不安全的假設、矛盾和無法驗證的需求。
3. 返回修正或補充的標準。

工作流程

1. 確立目標與風險

提取或詢問：

• 使用者或系統的可觀察結果。
• 受影響的行為者。
• 主要的失敗後果。
• 實際適用的風險維度：安全/隱私、持久性資料、相容性/API、遷移、外部依賴、成本、並行、效能、可用性/可訪問性。

避免詢問與無關風險的一般性問題。

2. 探索上下文

當本地或連接的工件可用時，僅檢查所需的內容：

• 現有行為和直接相關的檔案或介面。
• 儲存庫慣例、產品文件、API 合約、資料綱要或遷移歷史。
• 現有的驗證基礎設施和實際命令。
• 外部依賴以及它們是否可以隔離測試。

將發現的事實與使用者提供的假設分開記錄。如果無法檢查上下文，則說明哪些是未知的，並提出有針對性的問題。

儲存庫揭示技術事實——系統今天如何運作、其慣例和合約。它不揭示產品或業務限制：業務規則、合規和法規義務、合約 SLA、定價、資料保留政策、優先順序和目標使用者。絕不從程式碼或命名中重建這些。僅從使用者或權威產品工件捕獲它們，並將其列為待確認的假設。

3. 定義範圍

說明：

• 目標：一句話描述預期結果。
• 範圍內：此變更必須提供的行為。
• 範圍外：明確排除的誘人相鄰工作。
• 假設：尚未證實的主張。
• 阻斷決策：會顯著影響安全性或行為的未解決選擇。

4. 撰寫驗收標準

使用 AC-001、AC-002 等。每個標準必須描述可觀察的行為和適當的驗證方法；標準和測試不要求一一對應。

對於每個適用的標準，包括：

• 情境或起始條件。
• 動作或觸發。
• 預期的可觀察行為。
• 有意義時禁止的副作用。
• 驗證方法：自動化測試、整合檢查、手動 UX 審查、可訪問性檢查、安全審查、操作檢查或利害關係人驗收。
• 當驗證可能影響資料、服務、成本或秘密時的環境/安全限制。
• 優先級：必要、重要或可選。

不要使用「正確地」、「安全地」、「快速」、「直觀」或「穩健」等詞彙，除非定義了可觀察的證據或將其記錄為人工審查判斷。

5. 僅涵蓋相關邊界

考慮以下類別，但僅包括適用的類別：

類別	何時包含	典型證據
快樂路徑	新的或變更的使用者可見行為	成功的工作流程或狀態轉換
驗證	變更接受輸入	拒絕格式錯誤或邊界值而不改變狀態
授權/隱私	資料或動作有存取邊界	拒絕存取且無敏感揭露
持久性/遷移	儲存的資料或綱要變更	向後讀取、遷移、回滾或備份行為
相容性	公開 API、檔案、事件或用戶端可能中斷	現有合約或測試夾具仍然有效
失敗恢復	存在網路、服務或非同步失敗	無部分狀態或明確的重試/降級行為
冪等性/並行	重複或同時寫入是合理的	無重複副作用或無效的最終狀態
效能	存在使用者或服務門檻	定義的測量條件和門檻
UX/可訪問性	有人與結果互動	鍵盤、回饋、錯誤恢復、視覺/手動審查

6. 呈現並繼續

• 對於釐清/規格請求，呈現簡報並僅針對列出的阻斷因素要求決策。
• 對於沒有阻斷因素的實作請求，以緊湊的標準摘要作為工作的一部分呈現，並繼續實作。
• 對於轉交給另一個代理或團隊，包含足夠的上下文和驗證細節，使他們能夠在不發明需求的情況下行動。
• 僅在要求時將簡報儲存到檔案。使用儲存庫核准的路徑（如果存在）；否則在寫入之前詢問或說明選擇的目的地。

輸出範本

將此範本用於完整驗收簡報。對於快速捕捉，省略不相關的部分。

# 驗收簡報：<變更名稱>

**狀態：** 草稿 | 已核准 | 已實作 | 已驗證
**修訂：** <編號>
**為以下對象準備：** <使用者/團隊/代理，如果知道>
**風險工作前需要核准：** 是 | 否 - <原因>

## 修訂記錄

| 修訂 | 日期 | 變更的標準 | 原因 |
| --- | --- | --- | --- |
| 1 | <日期> | — | 初始草稿 |

## 目標

<一句可觀察結果的描述。>

## 範圍

**範圍內**
- <包含的行為>

**範圍外**
- <排除的相鄰工作>

## 上下文

**發現的事實**（技術性，從儲存庫或工件驗證）
- <系統今天如何運作、慣例、合約>

**產品/業務限制**（由使用者或產品工件提供，絕不從程式碼推斷）
- <業務規則、合規/SLA 義務、保留政策、優先順序、目標使用者 — 或「尚未提供」>

**假設**
- <未經證實的主張，待確認或驗證>

**依賴和限制**
- <外部服務、本地慣例、相容性義務、環境限制>

## 風險審查

| 風險領域 | 適用？ | 必要處理 |
| --- | --- | --- |
| 安全性/隱私 | 是/否 | <遮罩、授權、審查等> |
| 持久性資料/遷移 | 是/否 | <相容性、備份、回滾等> |
| 外部影響/成本 | 是/否 | <沙箱/測試環境/授權> |
| 相容性/API | 是/否 | <要保留或版本化的合約> |
| UX/可訪問性 | 是/否 | <手動或自動化證據> |

## 驗收標準

### AC-001：<可觀察行為>
- **情境：** <起始條件>
- **動作：** <單一觸發>
- **預期：** <可觀察結果>
- **不得：** <禁止的副作用，如果適用>
- **驗證：** <方法和預期證據>
- **環境/安全：** <限制，如果適用>
- **優先級：** 必要 | 重要 | 可選

## 阻斷決策

- [ ] <僅指能防止安全或正確進展的決策>

## 驗證計畫

| 標準 | 驗證證據 | 狀態 |
| --- | --- | --- |
| AC-001 | <測試/檢查/審查命令或證據類型> | 待處理 |

通過/失敗範例

使用這些來判斷技能是否真正產出了可驗證的簡報，而不是規劃文章。

失敗的驗收標準

AC-001：匯出功能正常運作且安全。

失敗 — 「正常運作」和「安全」不可觀察，沒有情境、觸發、預期...