SDD — 规格驱动开发方法论技能

触发条件

当用户出现以下场景时激活本技能：

1. 提到"SDD""规格驱动""文档链""SDD 方法论"等关键词
2. 需要编写 P1~P9 任一阶段的规格文档
3. 需要按规格驱动方式推进项目开发
4. 需要对 AI 编程工具进行执行约束或防幻觉检查
5. 需要建立项目的文档体系或目录结构
6. 需要进行里程碑验收或完整性检查

核心工作流

工作流 A：全新项目启动

当用户需要从零开始按 SDD 方法论推进项目时：

1. 确认输入材料 — 确认用户已有的原始需求规格说明书或资料包的路径
2. 确定项目阶段范围 — 必须使用 ask_followup_question 工具让用户确认，问题如下：
   问题: 请选择本项目要进行的 SDD 阶段（可多选，可跳过不需要的阶段，也可自定义）： 选项（多选）: - P1 产品需求分析 - P2 产品概要与技术架构设计 - P3 产品功能设计 - P4 产品原型设计 - P5 产品详细开发设计 - P6 产品开发与实施计划 - P7 产品典型案例与验证方案 - P8 产品测试方案 - P9 产品部署与运维指南 - 快捷：SDD-Min（P1+P2+P5）小团队快速推进 - 快捷：SDD-Std（P1+P2+P3+P5+P6+P7）一般产品开发 - 快捷：SDD-Full（P1~P9）正式产品长期迭代 - 自定义：我来说明需要哪些阶段
   不允许跳过此确认步骤。 必须等用户选择后才能继续。如果用户选择"自定义"，需进一步确认其自定义的阶段列表。
3. 初始化目录结构 — 在用户项目工作区内创建 docs/ 目录结构（见"推荐目录结构"章节），仅创建所选阶段对应的目录
4. 按序推进所选阶段 — 严格按依赖顺序推进（P1→P2→P3→P4→P5→P6→P7→P8→P9），跳过用户未选的阶段，每个阶段遵循"准入→编写→准出检查"流程。注意：跳过某阶段时，需提醒用户该阶段的下游文档可能缺少上游约束，后续编写时需自行补充
5. 建立追踪矩阵 — 维护需求→设计→实现→验证→证据的追踪关系

工作流 B：编写指定阶段文档

当用户需要编写某个特定阶段（如 P2 架构设计）的文档时：

1. 检查准入条件 — 确认上游文档是否已准出。如果上游文档不存在，提醒用户：该上游阶段被跳过或未完成，当前文档可能缺少上游约束，需自行补充
2. 加载上游文档 — 读取并理解已有的上游文档的核心约束（跳过的阶段无文档可加载）
3. 确认项目阶段范围 — 如果尚未确认项目阶段范围，必须先使用 ask_followup_question 让用户确认（同工作流 A 步骤2）
4. 读取阶段内容指引 — 必须使用 read_file 读取 assets/stage-content-guide.md，获取当前阶段的详细内容规范、章节深度描述、内容格式示例和常见遗漏提醒，严格按指引编写
5. 按章节模板编写 — 遵循内容指引中定义的必含章节和深度要求。编写文档时：
   - 文档头部使用 assets/doc-header-template.md 格式（用 read_file 读取）
   - 修正记录使用 assets/correction-record-template.md 格式（用 read_file 读取）
   - 将生成的文档写入用户项目的工作区目录，而不是技能目录
   - ⚠️ 特殊：编写 P4（产品原型设计）文档前，必须先让用户确认原型设计选项（详见 P4 阶段的"关键深度要求"中的交互选择项），包括：是否同时生成设计文档、视觉风格偏好、场景特征、色调模式、原型输出格式、是否使用 ui-ux-pro-max 专业设计技能等
6. 执行准出检查 — 用 assets/completeness-checklist.md 中对应阶段的检查项逐项验证
7. 建立交叉引用 — 确保引用上游文档的具体章节

工作流 C：AI 执行约束与防幻觉

当用户需要驱动 AI 编程工具进行开发实现时：

1. 确定当前任务所属阶段和模块
2. 按文档输入策略加载必要文档 — 参考下方"文档输入策略"章节
3. 生成 AI 执行约束 — 读取 assets/sdd-execution-constraint.md 模板，填写后输出
4. 组装任务输入包 — 读取 assets/sdd-task-package.md 模板，填写后输出
5. 验证 AI 输出 — 按验证策略对照规格文档检查

工作流 D：完整性检查与验收

当用户需要进行阶段验收或整体检查时：

1. 确定检查范围 — 哪些阶段需要检查
2. 执行完整性检查清单 — 读取 assets/completeness-checklist.md，逐项检查
3. 检查三条完整性链 — 规格链、执行链、证据链是否完整
4. 输出检查报告 — 列出通过项、缺失项和风险项

SDD 九阶段详细内容指引

> 编写任何阶段文档前，必须先读取 assets/stage-content-guide.md 获取完整的内容深度规范。 以下为各阶段的概要速查。

P1 — 产品需求分析

• 输入：原始需求规格说明书、业务资料
• 输出：产品需求分析文档 → 写入 docs/requirements/ 目录
• 核心任务：将模糊的原始需求转化为结构化、可追溯、有优先级的产品需求定义，包含业务场景深度分析、功能模块逐项详述、跨模块交互链路梳理
• 必含章节：产品定位与核心价值、需求总览（来源/层次/优先级）、业务场景详细分析（场景概览+逐场景详述+场景-模块映射）、功能边界分析（系统边界图+系统内/外功能+边界约束）、功能模块详细分析（每个模块：定位+功能清单+逐功能详述+模块内部交互）、跨模块交互分析（依赖关系图+关键交互链路表）、非功能性需求（性能/安全/适应性/通信/运行环境/设计约束）、术语表、风险与关注点（风险点+待确认项+原始需求问题）
• 关键深度要求：
• 产品定位必须一句话说清"是什么、为谁、解决什么问题"，不允许空泛描述
• 业务场景必须逐个详细分析：每个场景包含触发条件、业务流程（逐步骤编号）、业务规则；必须有场景与模块的映射矩阵
• 功能模块必须逐个详述：每个模块包含模块定位、功能清单（含功能标识）、每个功能的详述（业务目的/核心处理/输入/输出/前置后置条件/关键约束）、模块内部交互
• 功能边界必须画出系统边界图，分列系统内功能与系统外功能（含外部系统交互方式与独立性说明），列出边界约束
• 跨模块交互必须画出模块间依赖关系图，列出关键交互链路（交互内容、触发时机、是否为推断性交互）
• 非功能性需求必须给出量化指标（如"响应时间 < 500ms"而非"响应快"），覆盖性能、安全保密、适应性、通信、运行环境、设计实现约束等维度
• 每条需求标注来源段落，确保可回溯
• 常见遗漏：业务场景只有概览没有逐步骤详述；功能模块只有名称和概述没有逐功能详述；缺少跨模块交互链路分析；功能边界只有文字没有系统边界图；非功能需求只有笼统描述无量化值；缺少"不做什么"清单和边界约束；术语表只列名词不定义；缺少待确认项和原始需求问题清单
• 防幻觉：每条需求标注来源段落；推断性交互和推断性需求必须明确标注
• 准出：边界明确（含边界图）、场景详述完整、功能模块逐项详述、交互链路清晰、优先级排序、非目标确认、待确认项已列出

P2 — 产品概要与技术架构设计

• 输入：P1
• 输出：产品概要与技术架构设计文档 → 写入 docs/architecture/ 目录
• 核心任务：确定整体技术方案，定义系统分层、核心选型、全局规范和关键架构决策。本阶段文档是技术层面的"宪法"，下游所有技术文档不得违反此文档定义的约束
• 必含章节：系统定位与核心概念、理论基础（如适用）、技术选型与理由、系统分层架构、核心对象与边界、模块划分与核心模块架构、核心接口契约、核心业务流程、安全架构概要、全局编码规范、第三方集成规范、禁止事项清单、部署与运维方式、应用场景、术语表
• 关键深度要求：
• 系统定位必须一句话说清"是什么、不是什么"，列出核心概念模型（每个概念的名称、定义、职责）和系统边界（外部系统关系表）
• 理论基础（如适用）必须列出支撑系统设计的领域理论/方法论/标准/协议，每个说明"对系统设计的约束是什么"
• 技术选型必须写明：技术名 + 版本 + 用途 + 选型理由 + 不选替代方案的理由；辅助工具链单独列出；国产化/特殊环境适配说明（如适用）；地图组件优先选用 Cesium（3D地球与场景仿真的行业最佳实践，已验证的可编译级方案），如仅需2D轻量地图可选Leaflet
• 分层架构必须画架构图（ASCII或图表），每层写明职责边界和层间调用规则；前端架构须独立分层描述；后端项目结构须精确到关键文件级别
• 模块划分必须画出模块架构图，每个核心模块包含：技术原理、组件图、外部交互说明
• 核心接口契约必须包含：HTTP REST 接口规范（URL规范/方法语义/统一响应格式/分页响应格式）、错误码体系（编码规则+模块范围表）、WebSocket 消息契约（如适用：消息格式+消息类型列表）
• 核心业务流程必须用流程图画出主流程和关键子流程（训练全流程/状态流转/审批流程等），每个流程标注触发条件、处理步骤、结果
• 部署与运维方式必须包含：部署架构图（集中部署/分布式部署）、容器化方案（容器服务清单）、运维方案（日志/备份/监控/升级）
• 全局编码规范至少覆盖：命名规范（按语言/范围分类）、时间处理规范、注释约束、中文编码要求、Git提交规范
• 禁止事项清单必须显式列出，按架构层面/编码层面/数据层面/部署层面分类，每条写明禁止行为、原因、替代方案
• 术语表必须列出系统特有的术语/缩略语，每项包含全称和说明
• 常见遗漏：缺少系统定位与核心概念定义；缺少理论基础说明；选型只有"用了什么"没有"为什么选它"；分层图没有层间依赖规则；缺少模块架构图和核心模块技术原理；核心业务流程只有文字没有流程图；缺少错误码体系和WebSocket消息契约；部署架构缺少架构图；禁止事项清单缺失或过于笼统；缺少术语表
• 防幻觉：必须有禁止事项清单；推断性架构决策必须标注
• 准出：定位明确、选型确定、分层定义、模块架构清晰、核心流程可走通、核心约束成文、禁止事项明确

P3 — 产品功能设计

• 输入：P1、P2
• 输出：产品功能设计文档 → 写入 docs/design/ 目录
• 核心任务：将产品能力拆解为可设计、可开发的功能单元，精确到操作级别定义行为细节、界面元素、交互流转和业务逻辑。本阶段是 P4 原型设计的直接输入，细化程度直接决定原型的清晰度
• 必含章节：功能模块详细设计、功能点操作规格、界面功能与草图设计、页面流转与跳转设计、核心业务流程与时序、状态机与生命周期、权限与角色设计、用户体验约束与界面风格要求、数据模型概要
• 关键深度要求：
• 功能模块必须按模块独立编写，每个模块包含：模块定位、核心能力清单、依赖关系、边界声明
• 功能点不能只有名称，必须定义到操作级别：每个操作包含触发方式、操作步骤、输入字段（含校验规则）、输出结果、前置/后置条件、业务规则、异常处理、不做什么
• 每个核心页面必须包含：页面概述（编号/名称/职责/访问条件）、ASCII 线框草图、表单元素详述（字段/类型/校验/交互）、区域元素说明、交互逻辑流程图、跳转规则
• 页面流转必须画出全局页面流转图和各模块内部流转路径
• 核心业务流程必须用流程图和时序图描述（参与者+消息+触发条件+处理逻辑）
• 状态机必须画出状态流转图，标明触发条件、守卫条件、转换动作、禁止的流转
• 用户体验约束必须包含：界面风格与配色要求、中英文切换方式、色调切换（亮/暗模式）、登录方式、操作习惯约束、关键场景使用约束
• 权限设计必须用矩阵形式：角色 × 操作 → 允许/禁止，包含页面可见性矩阵
• 每个功能点必须补充"不做什么"
• 常见遗漏：功能点只有名称没有操作细节和业务规则；缺少界面草图和字段定义；缺少页面间跳转规则；状态机只画正常流遗漏异常态；权限设计只有角色没有矩阵；缺少核心业务时序图；缺少用户体验约束（风格/配色/切换/登录方式）；数据模型缺少实体间关联关系
• 防幻觉：每个功能点补充"不做什么"；界面草图须与 P2 技术选型对齐
• 准出：功能树与边界清晰、每个功能点操作规格完整、界面草图覆盖核心页面、页面流转完整、核心业务流程与时序已定义、关键状态已定义、用户体验约束已明确、权限矩阵完成

P4 — 产品原型设计

• 输入：P2（技术架构）、P3（功能设计）
• 输出：产品原型设计文档 + 可运行原型 → 写入 docs/prototypes/ 目录
• 核心任务：将界面功能设计可视化，定义视觉风格系统与交互规范，输出可直接体验的高保真原型
• 必含章节：视觉风格定义、设计令牌体系、导航与布局规范、核心页面设计、交互流转与状态规范、响应式与多端适配、原型交付物规范
• 关键深度要求：
• 推荐集成专业 UI 设计技能：编写 P4 或生成原型时，强烈推荐使用 ui-ux-pro-max 技能生成设计系统，确保视觉质量达到专业水准。具体集成方式：
  • 步骤一：生成设计系统 — 使用 ui-ux-pro-max 的 --design-system 功能，根据产品类型和行业关键词自动生成完整的设计系统推荐（风格、配色、字体、效果、反模式），命令格式：python3 [ui-ux-pro-max技能路径]/scripts/search.py "<产品类型> <行业> <风格关键词>" --design-system -p "<项目名称>"
  • 步骤二：补充搜索 — 根据需要用 --domain 搜索具体领域的专业建议：--domain style（更多风格选项）、--domain typography（字体搭配）、--domain color（配色方案）、--domain ux（交互最佳实践）、--domain chart（图表类型推荐）
  • 步骤三：获取技术栈指南 — 用 --stack 获取原型技术栈的实现最佳实践：--stack html-tailwind（HTML原型默认）、--stack vue（Vue原型）
  • 步骤四：质量交付检查 — 交付前参考 ui-ux-pro-max 的 Pre-Delivery Checklist：禁止用 emoji 做图标（用 SVG）、所有可点击元素加 cursor-pointer、hover 有视觉反馈、亮暗模式对比度合规、响应式覆盖 375px/768px/1024px/1440px
  • 如果 ui-ux-pro-max 技能未安装，则按本技能内置的风格流派参考进行设计
• 视觉风格必须明确：风格流派（含推荐风格库）、配色方案（亮色/暗色/双模式切换）、字体方案、图标风格、间距与圆角体系
• 设计令牌体系必须定义：色彩令牌（主色/功能色/中性色/语义色）、排版令牌（字体族/字号/行高/字重）、间距令牌、圆角令牌、阴影令牌、动画令牌
• 原型交付格式必须明确：HTML原型（单文件/多文件）、Vue组件原型（SFC结构）、或Figma/Sketch设计稿，并标注关键技术选型（地图组件优先选用 Cesium——3D场景与军事仿真的最佳实践验证；如仅需2D轻量场景可选 Leaflet；图表用ECharts等）
• 开始编写 P4 文档前，必须使用 ask_followup_question 工具让用户确认以下选项：
  • 是否同时生成原型设计文档（默认：是）——仅生成原型界面则跳过文档
  • 视觉风格偏好（深空指挥 / 商务精锐 / 极简北欧 / 科技未来 / 暖系亲和 / 工业硬朗 / 自定义）
  • 场景特征（指挥监控 / 企业管理 / 数据分析 / 协作工具 / 其他自定义）
  • 色调模式（仅亮色 / 仅暗色 / 亮暗双模式切换）
  • 原型输出格式（HTML单文件 / HTML多文件 / Vue SFC组件 / 设计工具源文件）
  • 是否使用 ui-ux-pro-max 技能生成专业设计系统（默认：是，如已安装）
  • 如用户选择"自定义"风格或场景，需进一步询问其具体描述
• 每个核心页面必须展示：布局结构、内容区块、操作入口、数据展示方式、亮色/暗色两种模式效果
• 关键流转必须覆盖从入口到完成的完整用户旅程
• 必须展示：空态、常态、异常态、加载态、权限受限态
• 管理操作必须覆盖：搜索、筛选、批量操作、确认与回退机制
• 响应式适配必须说明：Web端/移动端布局差异、关键断点、触控适配
• 国际化支持必须说明：是否支持中英文切换、文案管理方式
• 常见遗漏：只有正常态没有异常态和空态；只画页面不画流转；遗漏管理类操作；没有视觉风格定义直接跳入页面；缺少设计令牌体系；原型只有静态图没有可运行交付物；未定义亮色/暗色模式；未说明原型输出格式与技术选型；未考虑响应式与移动端；原型视觉质量不专业（emoji图标、无hover反馈、对比度不足）
• 防幻觉：原型问题必须回溯修正 P3；视觉风格须与 P2 技术选型对齐（如P2选了Element Plus则风格基于其设计体系）
• 准出：视觉风格定义完成、设计令牌成文、关键页面可视化（亮/暗双模式）、旅程走通、异常态展示、原型交付物格式与技术明确、原型视觉质量达到专业水准

P5 — 产品详细开发设计

• 输入：P2、P3、P4
• 输出：编号化专题详细设计文档系列 → 写入 docs/design/ 目录
• 核心任务：将架构设计和功能设计细化到可直接编码的实现级别，输出精度应达到"AI 读后可直接写出可编译代码"
• 编号规则：01_项目总览与开发规范 → 02_系统架构设计 → 03_数据模型与存储设计 → 04_配置与接口契约规范 → 05~NN_各模块详细设计 → API接口设计 → 认证鉴权设计 → 前端架构与组件设计 → 可观测性设计 → 部署与运维设计 → 页面功能与流转设计 → 典型案例与验证方案 → 测试资产与阶段验收矩阵
• 总览文档（01号）必含：技术栈总览表（技术+版本+用途）、全局编码规范（含代码示例）、项目目录结构（精确到文件级别）、关键设计决策索引表（编号+决策项+决策结果+详见文档）
• 架构文档（02号）必含：分层架构图（ASCII或图表）、请求流转全链路（逐步骤）、核心接口定义（代码级别）、配置管理（含配置文件结构和校验逻辑）、架构决策记录（ADR：决策+理由+替代方案否决理由）
• 数据模型文档（03号）必含：每个集合/表的完整 Schema 示例（JSON/SQL）、索引设计（直接对应 API 查询场景）、并发问题修正方案（含事务代码）、大文本溢出处理策略、数据同步机制（多存储引擎间的一致性保证）
• 各模块详细设计文档必含：元数据、职责定义与核心能力列表、输入输出契约（含请求/响应示例）、核心算法/流程（伪代码或实现代码）、数据结构（含字段名+类型+约束+默认值+索引策略）、错误处理策略（重试/降级/阻断/回滚/超时）、依赖关系（依赖谁+被谁依赖+具体接口名）、安全要求、验收标准、修正记录
• 关键深度要求：
• 输入输出契约必须包含：完整的请求/响应 JSON 示例、状态码映射表、边界条件处理
• 核心算法必须用伪代码或实现代码描述，不允许只写文字；复杂调度/排序/解析算法须给出算法名称和核心步骤
• 数据结构必须包含：字段名、类型、约束、默认值、索引策略；须给出 JSON/代码 Schema 示例
• 错误处理必须覆盖：重试策略（次数+退避方式）、降级方案（触发条件+降级值）、阻断条件、回滚机制（事务范围+补偿操作）、超时处理（阈值+超时后行为）
• 依赖关系必须写明：依赖谁、被谁依赖、层间调用规则、具体调用的接口名和方法签名
• 架构决策（ADR）必须记录：决策项、决策结果、选型理由、不选替代方案的理由
• 修正记录必须保留：旧方案描述 → 新方案描述 → 修正理由 → 影响范围
• 常见遗漏：总览文档缺少项目目录结构和技术栈版本表；架构文档没有请求流转全链路；接口只有定义没有请求/响应示例；核心逻辑只有文字没有伪代码；错误处理只有"统一异常处理"没有具体策略；数据模型只有表结构没有索引策略和并发修正方案；缺少架构决策记录（ADR）
• 防幻觉：接口必须有请求/响应示例；核心算法须有伪代码或实现代码；修正须留痕；推断性设计决策必须标注
• 准出：总览文档含技术栈表和目录结构；架构文档含分层图和请求全链路；关键模块有独立专题；核心算法有伪代码或实现代码约束；数据模型有索引策略；架构决策有记录

P6 — 产品开发与实施计划

• 输入：P5
• 输出：产品开发与实施计划文档 → 写入 docs/plans/ 目录
• 核心任务：将详细开发设计转化为可执行的任务序列，定义里程碑、依赖关系和阶段验收标准
• 必含章节：里程碑总览（含依赖关系图）、各里程碑详细任务、依赖排序、验收标准、风险登记、文档索引
• 关键深度要求：
• 里程碑总览必须用图展示依赖关系链（M0→M1→...），每个里程碑包含：编号、名称、目标、关键交付物
• 各里程碑详细任务必须用表格列出：任务编号、任务描述、产出、完成标准（量化），每个里程碑必须单独注明前置条件和独立完成标准
• 验收标准必须量化，不允许"基本可用""大致完成"等模糊表述；完成标准必须是可执行命令、可检查状态或可截图留证的动作
• 依赖排序必须画出或用文字描述任务间的先后关系和可并行关系
• 风险登记必须列出：风险描述、影响范围、缓解措施
• 文档索引必须列出：编号、文档名称、主题，便于查找关联设计文档
• 常见遗漏：里程碑总览没有依赖关系图；里程碑只有名字没有交付物和前置条件；任务表格缺少"产出"列和量化完成标准；验证动作是笼统的"检查功能"而非具体命令；风险登记缺失；文档索引缺失
• 防幻觉：完成标准必须量化，不可写"基本可用"
• 准出：里程碑与依赖关系图合理、任务表包含量化完成标准、每阶段有验证动作、风险已登记

P7 — 产品应用场景验证方案

• 输入：P1（业务场景）、P3（功能设计）、P5、P6
• 输出：产品应用场景验证方案文档 → 写入 docs/examples/ 目录
• 核心任务：基于 P1 定义的各类业务场景，设计端到端的应用场景验证案例，证明系统在真实业务场景下的行为符合预期。P7 聚焦于"业务场景是否走通"，而非"功能是否正确"——功能测试属于 P8 范畴
• 必含章节：场景验证总览、业务场景验证案例、场景数据与前置条件、场景执行路径与观察点、跨场景交互验证、场景验收矩阵
• 关键深度要求：
• 场景验证总览必须包含：P1 业务场景与验证案例的覆盖矩阵（每个场景至少一个验证案例）、验证范围说明（P7 验证什么、P8 负责什么）
• 每个业务场景验证案例必须包含：场景编号、场景名称（对应 P1 业务场景）、业务背景与触发条件、参与角色、端到端执行路径（从用户操作到业务结果）、场景数据集（真实业务数据，非功能测试数据）、预期业务结果（非接口返回值，而是业务效果）、场景观察点（业务节点而非技术节点）、通过标准（量化业务指标）
• 场景数据必须贴近真实业务数据，而非功能测试的边界值/异常值；边界值和异常输入测试归 P8
• 场景执行路径必须覆盖完整业务链路：触发→处理→结果→后续影响，而不是单接口调用
• 跨场景交互验证必须包含：场景间数据传递、场景间状态依赖、并发场景冲突（如同时操作同一资源）
• 验收矩阵必须与 P6 里程碑挂钩，标注每个里程碑必须通过的场景验证
• 常见遗漏：案例是功能测试而非场景验证（如"测试创建计划接口"而非"验证训练计划全生命周期"）；缺少 P1 场景覆盖矩阵；数据是测试边界值而非真实业务数据；只验证单功能不验证端到端业务链路；缺少跨场景交互验证；与 P8 职责边界不清
• 防幻觉：每个案例必须追溯至 P1 业务场景；通过标准必须是业务指标而非接口返回码
• 准出：P1 每类业务场景有对应验证案例、案例是端到端业务链路而非单功能测试、与 P8 职责边界清晰、验收矩阵与里程碑挂钩

P8 — 产品测试方案

• 输入：P7、P5
• 输出：产品测试方案文档 → 写入 docs/test/ 目录
• 核心任务：定义系统化的测试策略、测试层级、测试矩阵与质量门禁
• 必含章节：测试策略、单元测试、集成测试、安全测试、性能测试、环境要求、用例矩阵
• 关键深度要求：
• 测试策略必须定义各层级的优先级和范围边界
• 单元测试方案必须包含：模块测试重点、Mock 策略、覆盖率要求（量化目标）
• 集成测试方案必须包含：端到端 API 测试、模块联动、环境依赖与数据准备
• 安全测试必须包含：静态扫描、漏洞检查、恶意输入、越权场景
• 性能测试必须包含：基线指标、压力场景、性能退化检测
• 用例矩阵必须包含：用例编号、阶段、类型、预期结果、证据要求
• 常见遗漏：只有功能测试没有安全/性能测试；覆盖率目标缺失；负面路径覆盖不足；测试矩阵未与 P7 案例打通
• 防幻觉：必须覆盖负面路径
• 准出：层级齐全、覆盖率目标明确、测试矩阵与 P7 打通

P9 — 产品部署与运维指南

• 输入：P2（可与 P3-P8 并行）
• 输出：产品部署与运维指南文档 → 写入 docs/ops/ 目录
• 核心任务：定义系统的部署架构、环境配置、运维流程、回滚策略和应急响应方案
• 必含章节：部署架构、环境要求、环境变量与配置、部署步骤（含回滚）、健康检查、日常运维、监控告警、应急响应
• 关键深度要求：
• 部署架构必须包含：拓扑图、组件关系、端口规划、网络策略
• 环境变量与配置必须包含：配置项名、默认值、安全约束、敏感参数说明
• 部署步骤必须包含：首次部署、升级部署、回滚操作、灰度策略
• 健康检查必须列出各组件检查方式和部署后验证清单
• 监控告警必须包含：指标名、阈值、告警渠道、处置流程
• 应急响应必须包含：常见故障列表、排查顺序、应急处理流程
• 常见遗漏：部署步骤只有首次安装没有升级/回滚；环境变量缺少默认值和安全说明；应急手册只有框架没有具体操作
• 防幻觉：必须有部署后验证清单
• 准出：验证清单可执行、回滚路径明确、应急手册可执行

文档输入策略

AI 编程工具的上下文窗口有限，不应一次性输入全部文档，而应按任务阶段加载：

推荐原则：

1. AI 永远先读"总览与规范"，再读当前专题
2. 输入尽量围绕当前任务，而不是整套项目
3. 当前任务所需的禁止事项和关键修正必须单独摘出

推荐目录结构

docs/
├── requirements/      # P1 原始需求、需求分析
├── architecture/      # P2 产品概要与架构总纲
├── design/            # P5 编号化专题详细设计
├── prototypes/        # P3/P4 功能设计、原型图
├── plans/             # P6 实施计划、实施总结
├── examples/          # P7 典型案例、测试资产
├── test/              # P8 测试方案、测试报告
├── ops/               # P9 部署与运维指南
├── reviews/           # 评审、复核、研究
└── reports/           # 阶段总结、发布报告

核心原则：按角色与职责组织，不按文件名习惯组织。

三道门禁

三条完整性链

1. 规格链：需求 → 架构 → 功能 → 原型 → 详细设计
2. 执行链：详细设计 → 实施计划 → 开发实现 → 实施总结
3. 证据链：典型案例 → 测试方案 → 测试报告 → 部署验证 → 上线证据

缺任何一条链，实现就容易变成"局部完成、整体不可交付"。

阶段选择与文档集档位

SDD 允许用户灵活选择需要进行的阶段：可跳过不需要的阶段，也可自定义过程。以下为三种快捷档位推荐，用户也可自由组合：

跳过阶段的风险提示：

> 原则：SDD 不强制所有阶段，但 P1 和 P2 强烈建议不要跳过——它们是整个文档链的根基。

模板资产使用方式

本技能在 assets/ 目录下提供了以下模板文件。使用时必须先用 read_file 读取模板内容，然后按模板格式编写文档，将文档写入用户项目的工作区目录（而非技能目录）：

> 重要：[技能目录] 指本技能的安装路径（如 C:\Users\Admin\.workbuddy\skills\sdd-methodology）。在读取模板时使用绝对路径。

完整方法论参考

如需查看方法论完整论述（含理论背景、各阶段详细章节要求、防幻觉机制矩阵等），用 read_file 读取 [技能目录]/references/sdd-methodology-full.md。

SDD 方法论与具体项目、技术栈和文件命名无关，可作为任何产品型软件项目的通用规格驱动开发框架。