语言规则：本 skill 必须始终使用中文与用户交互。所有输出、提示、报告、文档均使用中文。
AI 开发需求驱动工作流程（通用版）
概述
本 skill 旨在利用需求文档（可选结合 SDD 文档）驱动 AI 进行需求开发。通过需求分析 → 技术方案生成 → 人工校验 → 执行开发 → 人工修正 → 开发结果验证（按需）的流程，确保开发方案符合业务预期。
整个工作流程分为六个阶段：
- 阶段一：PRD 获取（先确认
REQ_ROOT，知识库上下文可选；支持本地.md/.docx文档；一旦创建REQ_ROOT，必须同步创建input_materials/并在本需求标识.md中维护输入资料清单） - 阶段二：需求分析与代码探索（循环）。优先使用 SDD 理解业务；仍须进行代码探索；产出改动点清单（每条含改动点描述、现状简述、状态）；结束前须人工确认改动点已全。
- 阶段三：技术方案生成（根据需求分析报告 + 代码探索生成技术方案；有可用 SDD 时作为增强输入；技术方案须与改动点逐项对应；框架按需加载）
- 阶段四：人工校验与技术方案迭代（人工驱动，循环执行；生成对外文档后自动整理 SDD缺口清单）
- 阶段五：执行开发（自动循环；命中接口文档冲突时必须暂停确认）
- 阶段六：开发结果验证（按需执行；提供
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 文件路径定位
- 优先：从当前文件路径提取 skill 根目录（包含
sdd-driven-dev的父目录） - 备选：检查
~/.cursor/skills/sdd-driven-dev/、.cursor/skills/sdd-driven-dev/ - 兜底：使用相对路径
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）
- 所有结论必须绑定证据编号：
E-001、E-002... - 证据类型仅允许三类：
CODE（代码路径+行号+结论）、SDD（文档路径+章节+结论）、CMD（命令+输出摘要+结论） - 无证据结论必须标注：
【推测】
2. 任务图执行（DAG）
- 任务字段：任务 ID（T1/T2...）、依赖任务（Deps）、输出物、完成判据、回滚点
- 阶段五必须按依赖执行
- 可并行任务标注并行组
3. 验收先行（Spec → Tests → Code）
- 阶段四必须先产出验收标准
AC-xxx，再进入开发任务拆分 - 每个开发任务至少映射一个验收标准 ID
4. 变更影响分析（Impact Analyzer）
阶段三和阶段四必须输出影响分析矩阵：调用链上下游、数据库与缓存、对外接口与调用方、配置项与开关、监控指标与告警、兼容性。
5. 风险分级与发布护栏（Risk Guardrail）
- 每个需求必须评估风险等级：低/中/高
- 高风险需求必须包含：灰度策略、回滚步骤、监控阈值、告警项、人工确认点
6. 闭环学习（Project Memory）
- 阶段六有
KB_QUICK_REF时沉淀到其指定路径；无则沉淀到${REQ_ROOT}/经验沉淀/ - 阶段二开始前，先读取历史
patterns.md、anti-patterns.md、regressions.md（若相关路径可用）
7. 运行产物落盘边界（必须）
- skill 目录仅用于存放提示词和模板
- 运行期产物落到
${REQ_ROOT}/，经验沉淀优先从快速参考文档获取路径，未提供时落到${REQ_ROOT}/经验沉淀/
8. AI 自动 CR 硬性规则（执行时必须）
try/catch规则：每个catch必须有error级别日志和监控上报- 日志级别规则：仅允许
info、error；禁止warn/worn/warning - RPC 字段规则（Dubbo/gRPC/Thrift 均适用）：
- 禁止删除或修改已存在的 RPC 接口字段（field number/field id）
- 新增字段只能追加到末尾，field number/id 必须取当前最大值 + 1，禁止复用
- 存量字段语义变更时必须新增字段表达，不改老字段语义 - RPC 版本联动规则：若修改 RPC 接口定义（proto/IDL/Thrift），必须同步升级版本号，并更新所有引用方的依赖版本
9. 接口契约外部对齐（执行时必须）
- 阶段三若涉及 HTTP 接口（Controller）或被外部调用的 RPC 接口契约变化，必须单独输出"接口契约改动及外部对齐"块
- 若某 RPC 改动仅供内部链路使用，必须明确标注"内部链路使用，无需外部对齐"
- 技术方案文档结尾必须汇总接口契约改动与外部对齐清单
相关文档
- 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
