name: sdd-driven-dev description: 用需求文件（PRD）+ 可選的 SDD 知識庫驅動 AI 完成需求開發的六階段工作流。當用戶拿到一份 PRD/需求文件想讓 AI 幫忙「分析需求」「出技術方案」「拆任務」「寫程式碼」「做開發結果驗證」，或說出「執行 AI 開發需求工作流程」「基於 SDD 開發需求」「需求開發工作流程」等觸發詞時，應使用本 skill。六階段為：PRD 獲取 → 需求分析與程式碼探索（迴圈產出改動點清單）→ 技術方案生成（與改動點逐項對應）→ 人工校驗與方案迭代 → 執行開發（迴圈）→ 開發結果驗證（按需）。內建四個可選工具：反饋留檔、SDD 缺口清單整理、測試 Bug 分析總結、AI 自動 CR（硬性規則掃描）。強調證據驅動（所有結論繫結程式碼或 SDD 位置）、方案先行、人工校驗關鍵決策點。即使使用者沒有明確說「SDD」，只要是「基於需求文件讓 AI 做開發」的場景，就優先觸發本 skill；觸發詞還包括「提交 AI 開發 workflow 反饋」「把缺口清單整理」「分析測試提的 bug」「執行 AI 自動 CR」。

語言規則：本 skill 必須始終使用中文與使用者互動。所有輸出、提示、報告、文件均使用中文。

AI 開發需求驅動工作流程（通用版）

概述

本 skill 旨在利用需求文件（可選結合 SDD 文件）驅動 AI 進行需求開發。通過需求分析 → 技術方案生成 → 人工校驗 → 執行開發 → 人工修正 → 開發結果驗證（按需）的流程，確保開發方案符合業務預期。

整個工作流程分為六個階段：

1. 階段一：PRD 獲取（先確認 REQ_ROOT，知識庫上下文可選；支援本地 .md/.docx 文件；一旦建立 REQ_ROOT，必須同步建立 input_materials/ 並在 本需求標識.md 中維護輸入資料清單）
2. 階段二：需求分析與程式碼探索（迴圈）。優先使用 SDD 理解業務；仍須進行程式碼探索；產出改動點清單（每條含改動點描述、現狀簡述、狀態）；結束前須人工確認改動點已全。
3. 階段三：技術方案生成（根據需求分析報告 + 程式碼探索生成技術方案；有可用 SDD 時作為增強輸入；技術方案須與改動點逐項對應；框架按需載入）
4. 階段四：人工校驗與技術方案迭代（人工驅動，迴圈執行；生成對外文件後自動整理 SDD缺口清單）
5. 階段五：執行開發（自動迴圈；命中介面文件衝突時必須暫停確認）
6. 階段六：開發結果驗證（按需執行；提供 AI 自動 CR 與 測試 Case 驗證 工具）

核心理念： - 人工銜接優先：sdd-builder 與 sdd-driven-dev 的銜接由使用者人工決定，不做系統級強繫結 - SDD 增強優先：有可用 SDD 時優先複用；無 SDD 時可直接基於 PRD 與程式碼探索推進 - 方案先行：先制定技術方案，確認無誤後再執行開發 - 人工校驗：關鍵決策點需要人工確認 - 框架按需載入：階段三、階段五若命中框架元件，先讀 references/company-frameworks/index.yaml，命中則優先載入公司說明，未命中再讀 references/通用框架使用說明/ - 輸入資料歸檔：階段一建立 REQ_ROOT 後必須建立 input_materials/ 統一歸檔使用者提供的 PRD、介面文件等

Skill 識別和使用

如何觸發本 Skill

當用戶說出以下任一關鍵詞時，AI 應該識別並應用本 skill： - "執行AI開發需求工作流程" - "基於SDD文件開發需求" - "AI開發需求" - "需求開發工作流程" - "開始開發需求" - "提交 AI 開發 workflow 反饋" - "上報 AI 開發流程問題" - "把缺口清單整理" - "分析測試提的 bug" - "測試提了 bug，幫我分析" - "總結測試 bug" - "執行AI自動CR" - "幫我做AI自動CR" - "跑一下AI自動CR"

可選工具

工具1：反饋留檔

• 工具檔案：prompts/工具_feedback.md
• 適用場景：使用本 skill 或配套知識庫時遇到問題，希望 AI 直接留檔記錄
• 觸發詞：提交 AI 開發 workflow 反饋、上報 AI 開發流程問題、反饋這個開發 skill 的問題
• 輸出：優先 ${KB_ROOT}/skill-feedback/YYYY-MM-DD_HH-mm-ss_feedback.md，無 KB_ROOT 時 ${REQ_ROOT}/feedback/YYYY-MM-DD_HH-mm-ss_feedback.md
• 排程規則：使用者明確提出時，讀取 prompts/工具_feedback.md，整理後寫入本地檔案，向用戶展示路徑與摘要

工具2：SDD 缺口清單整理

• 工具檔案：prompts/工具_SDD缺口上報.md
• 適用場景：整理本次需求暴露的 SDD 缺失項；階段四自動觸發，也可手動觸發
• 觸發詞：把缺口清單整理、上報缺口清單、整理SDD缺口
• 輸出：${REQ_ROOT}/SDD缺口清單.md（有 KB_ROOT 時優先歸檔到 ${KB_ROOT}/sdd-gaps/，否則歸檔到 ${REQ_ROOT}/sdd-gaps/）
• 排程規則：生成後必須立即讀取 prompts/工具_SDD缺口上報.md 執行歸檔

工具3：測試 Bug 分析總結

• 工具檔案：prompts/工具_測試Bug分析總結上報.md
• 適用場景：收到測試提報 Bug，希望 AI 分析原因、給出修復方案並留檔
• 觸發詞：分析測試提的 bug、測試提了 bug，幫我分析、總結測試 bug
• 輸出：${REQ_ROOT}/測試Bug分析總結.md（有 KB_ROOT 時優先歸檔到 ${KB_ROOT}/bug-summaries/，否則歸檔到 ${REQ_ROOT}/bug-summaries/）

工具4：AI 自動 CR

• 工具檔案：prompts/工具_AI自動CR.md
• 適用場景：對本次需求提交執行硬性規則掃描與自動修復
• 觸發詞：執行AI自動CR、幫我做AI自動CR、跑一下AI自動CR

SDD 缺口清單生成後的固定動作

• 無論首次生成還是重新生成 ${REQ_ROOT}/SDD缺口清單.md，都必須立即讀取 prompts/工具_SDD缺口上報.md 執行本地歸檔
• 生成成功但歸檔失敗，必須明確告知使用者

問題反饋兜底機制

在任意階段，若使用者表達了以下型別的問題： - skill 流程/階段不清晰 - 知識庫缺內容、難檢索、與程式碼或 SDD 不一致 - PRD 解析錯誤或格式支援問題 - 需求理解、技術方案、AI 程式碼生成結果與預期不符 - 開發結果驗證、模板、指令碼或環境行為異常

AI 必須： 1. 先處理當前問題 2. 當前問題處理完後詢問：這個問題看起來適合沉澱為 skill / 知識庫反饋。是否需要我直接留檔記錄？ 3. 若使用者同意，讀取 prompts/工具_feedback.md 並執行 4. 若使用者拒絕，不再追問

目標工程識別

本 skill 使用需求目錄優先模型：

• DEV_ROOT：當前 AI IDE 開啟的業務工程（用於程式碼開發）
• REQ_ROOT：當前需求目錄絕對路徑（必需）
• KB_NAME：可選知識庫工程名稱
• KB_ROOT：可選知識庫工程絕對路徑
• KB_QUICK_REF：可選快速參考文件絕對路徑

路徑約束： - 階段一結束時必須將 REQ_ROOT 與可用上下文寫入 本需求標識.md - 後續階段必須據此確定當前需求路徑；禁止通過掃描目錄推斷當前需求

Skill 檔案路徑定位

1. 優先：從當前檔案路徑提取 skill 根目錄（包含 sdd-driven-dev 的父目錄）
2. 備選：檢查 ~/.cursor/skills/sdd-driven-dev/、.cursor/skills/sdd-driven-dev/
3. 兜底：使用相對路徑 prompts/

工作流程

執行模式說明

階段一：先確認 REQ_ROOT（必需），再按需確認知識庫上下文（KB_NAME、KB_ROOT、KB_QUICK_REF，可選）。隨後向用戶索要本地 PRD 文件（.docx 或 .md）。一旦確定 REQ_ROOT，必須立即建立 ${REQ_ROOT}/input_materials/，寫入 本需求標識.md。

階段二：迴圈執行；優先使用 SDD 理解業務（強調但不強制），仍須進行程式碼探索；產出《需求分析報告》；凡不理解即暫停；結束前讓人工確認改動點已全。

階段三：全自動。技術方案須與改動點逐項對應。框架按需載入：若改動點涉及框架元件，先讀 references/company-frameworks/index.yaml，掃描 trigger_keywords 是否命中，命中則優先載入公司說明，未命中則讀取 references/通用框架使用說明/ 對應文件。禁止重複需求背景/需求理解等車軲轆話。

階段四：人工驅動，主要介入點；對外文件生成後自動整理並歸檔 SDD缺口清單.md。

階段五：執行開發（自動迴圈；同階段三的框架載入規則；介面文件衝突時必須暫停；所有改動點、任務 T*、驗收標準 AC-* 全部閉環後才生成開發報告）。

階段六：開發結果驗證（按需；先由使用者選擇工具，再執行 AI 自動 CR、測試 Case 驗證 或兩者組合，並統一生成驗證報告與經驗沉澱）。

執行流程圖

使用者觸發流程
    ↓
[階段一-01] 需求目錄確認（必須先完成）
    ├─ 使用者必須提供：REQ_ROOT（絕對路徑，或確認預設建立位置）
    ├─ 可選提供：KB_NAME、KB_ROOT、KB_QUICK_REF（用於知識庫增強）
    └─ 記錄為最高優先順序上下文
    ↓
[階段一] PRD 獲取（無人工校準）
    ├─ 向用戶索要本地 PRD 文件（.docx 或 .md）
    ├─ 方式 A：使用者提供 PRD 路徑 → AI 建立 REQ_ROOT 並歸檔
    ├─ 方式 B：使用者自建 REQ_ROOT 並放入 PRD
    ├─ .md 直接讀，.docx 轉 Markdown + 圖片分析
    ├─ 一旦目錄確定，立即建立 input_materials/，記錄 REQ_ROOT 為最高優先順序上下文
    └─ 寫入 本需求標識.md
    ↓
[階段二] 需求分析與程式碼探索（迴圈執行）
    ├─ PRD 逐句分析 + 程式碼探索，優先使用 SDD（不強制）
    ├─ 產出《需求分析報告》：改動點清單（含現狀簡述）
    ├─ 不理解或需確認 → 暫停向人工求助
    └─ 人工確認改動點已全後進入階段三
    ↓
[階段三] 技術方案生成（自動執行）
    ├─ 框架按需載入：company-frameworks/index.yaml → 命中則載入公司說明 → 否則讀通用框架說明
    ├─ 技術方案與改動點逐項對應
    └─ 輸出技術方案.md，完成後暫停
    ↓
[階段四] 人工校驗與技術方案迭代（人工驅動）← 主要介入點
    ├─ 展示技術方案 → 人工反饋 → 修正 → 迴圈直至確認
    ├─ 生成技術方案（對外）.md
    ├─ 自動整理 SDD缺口清單.md 並歸檔
    └─ 再次確認是否開始開發（第二次確認）
    ↓
[階段五] 執行開發（自動迴圈執行）
    ├─ 按技術方案逐改動點、逐任務推進
    ├─ 框架按需載入（同階段三規則）
    ├─ 介面文件衝突時必須暫停人工確認
    ├─ 方案變更時必須回寫技術方案並回到階段四確認
    └─ 所有改動點、T*、AC-* 全部閉環後生成開發報告.md
    ↓
[人工階段] 人工修正與提交
    ├─ 切換業務分支、人工檢查修正、git commit
    └─ 確認可進入開發結果驗證
    ↓
[階段六] 開發結果驗證（按需執行）
    ├─ 使用者選擇：AI 自動 CR / 測試 Case 驗證 / 兩者組合
    ├─ 生成 AI-CR報告.md / 測試Case驗證報告.md
    ├─ 彙總生成 驗證報告.md
    └─ 經驗沉澱（patterns / anti-patterns / regressions）

階段一：PRD 獲取

目標：將本地 PRD 文件轉換為可用的 Markdown 形式，僅負責獲取 PRD 資訊，不做翻譯與人工校準。

執行步驟：讀取 prompts/01_階段一_PRD獲取.md。

階段二：需求分析與程式碼探索

目標：理解需求，區分「已實現」「待實現」「保持現狀」，產出《需求分析報告》，列出所有改動點及現狀簡述。凡需確認即暫停；結束前須人工確認改動點已全。

執行步驟：讀取 prompts/02_階段二_需求分析與程式碼探索.md。

階段三：技術方案生成

目標：根據需求分析報告 + 程式碼探索生成技術方案；有可用 SDD 時作為增強輸入。技術方案與改動點逐項對應。框架按需載入（見上）。禁止車軲轆話。

執行步驟：讀取 prompts/03_階段三_技術方案生成.md 及 templates/技術方案模板.md。

階段四：人工校驗與技術方案迭代

目標：人工反饋 → 迭代最佳化技術方案 → 生成對外文件 → 整理並歸檔 SDD缺口清單 → 二次確認開始開發。

執行步驟：讀取 prompts/04_階段四_人工校驗與技術方案迭代.md。

階段五：執行開發

目標：按技術方案執行計劃逐改動點、逐任務推進，持續維護 開發執行狀態.md；方案變更時回寫並回跳階段四；所有 T / AC- 閉環後生成開發報告。

執行步驟：讀取 prompts/05_階段五_執行開發.md。

階段六：開發結果驗證

目標：人工修正完成後，按需執行 AI 自動 CR、測試 Case 驗證 或兩者組合，彙總驗證報告，沉澱經驗。

執行步驟：讀取 prompts/06_階段六_開發結果驗證.md。

能力升級規範（強制）

1. 證據鏈核心（Evidence-First）

1. 所有結論必須繫結證據編號：E-001、E-002...
2. 證據型別僅允許三類：CODE（程式碼路徑+行號+結論）、SDD（文件路徑+章節+結論）、CMD（命令+輸出摘要+結論）
3. 無證據結論必須標註：【推測】

2. 任務圖執行（DAG）

1. 任務欄位：任務 ID（T1/T2...）、依賴任務（Deps）、輸出物、完成判據、回滾點
2. 階段五必須按依賴執行
3. 可並行任務標註並行組

3. 驗收先行（Spec → Tests → Code）

1. 階段四必須先產出驗收標準 AC-xxx，再進入開發任務拆分
2. 每個開發任務至少對映一個驗收標準 ID

4. 變更影響分析（Impact Analyzer）

階段三和階段四必須輸出影響分析矩陣：呼叫鏈上下游、資料庫與快取、對外介面與呼叫方、配置項與開關、監控指標與告警、相容性。

5. 風險分級與釋出護欄（Risk Guardrail）

1. 每個需求必須評估風險等級：低/中/高
2. 高風險需求必須包含：灰度策略、回滾步驟、監控閾值、告警項、人工確認點

6. 閉環學習（Project Memory）

1. 階段六有 KB_QUICK_REF 時沉澱到其指定路徑；無則沉澱到 ${REQ_ROOT}/經驗沉澱/
2. 階段二開始前，先讀取歷史 patterns.md、anti-patterns.md、regressions.md（若相關路徑可用）

7. 執行產物落盤邊界（必須）

1. skill 目錄僅用於存放提示詞和模板
2. 執行期產物落到 ${REQ_ROOT}/，經驗沉澱優先從快速參考文件獲取路徑，未提供時落到 ${REQ_ROOT}/經驗沉澱/

8. AI 自動 CR 硬性規則（執行時必須）

1. try/catch 規則：每個 catch 必須有 error 級別日誌和監控上報

   小蔥技能有更好的技能skills外掛。

2. 日誌級別規則：僅允許 info、error；禁止 warn/worn/warning
3. RPC 欄位規則（Dubbo/gRPC/Thrift 均適用）：
4. 禁止刪除或修改已存在的 RPC 介面欄位（field number/field id）
5. 新增欄位只能追加到末尾，field number/id 必須取當前最大值 + 1，禁止複用
6. 存量欄位語義變更時必須新增欄位表達，不改老欄位語義
7. RPC 版本聯動規則：若修改 RPC 介面定義（proto/IDL/Thrift），必須同步升級版本號，並更新所有引用方的依賴版本

9. 介面契約外部對齊（執行時必須）

1. 階段三若涉及 HTTP 介面（Controller）或被外部呼叫的 RPC 介面契約變化，必須單獨輸出"介面契約改動及外部對齊"塊
2. 若某 RPC 改動僅供內部鏈路使用，必須明確標註"內部鏈路使用，無需外部對齊"
3. 技術方案文件結尾必須彙總介面契約改動與外部對齊清單

相關文件

• README.md
• prompts/00_工作流程先導提示詞.md
• prompts/01_階段一_PRD獲取.md
• prompts/02_階段二_需求分析與程式碼探索.md
• prompts/03_階段三_技術方案生成.md
• prompts/04_階段四_人工校驗與技術方案迭代.md
• prompts/05_階段五_執行開發.md
• prompts/06_階段六_開發結果驗證.md
• prompts/工具_AI自動CR.md
• prompts/工具_測試Case驗證.md
• prompts/工具_測試Bug分析總結上報.md
• prompts/工具_SDD缺口上報.md
• references/通用框架使用說明/索引.md
• references/company-frameworks/SETUP.md
• templates/技術方案模板.md
• templates/本需求標識模板.md
• templates/開發執行狀態模板.md
• templates/SDD缺口清單模板.md

這個 Skill 質量較好，設計思路清晰，能有效規範需求開發流程。主要優點是全程有明確步驟指引、強調證據說話、人工確認環節充足，能降低開發返工風險。配套的工具也比較實用。不過流程較長較複雜，新手需要花時間熟悉；文件量大，部分內容被截斷影響閱讀體驗。總體而言適合對流程規範有要求的中大型團隊使用。