SDD规范驱动开发助手

要解决的问题

AI 编程工具接入项目后，最常见的失败不是模型“不会写代码”，而是规格缺位导致的自由发挥：需求还停在聊天记录里，接口没有契约，验收靠肉眼比对。代码看起来能跑，回到业务目标上却对不上。

SDD（Specification-Driven Development）把软件交付拆成九个可独立检查的阶段：从 P1 产品需求到 P9 部署运维。每个阶段都有输入、输出、必含章节、深度要求和准出条件，让“规格”先于实现稳定下来。

技能如何工作

规范先行，逐阶段准出。 新增项目时，技能会确认已选阶段范围，在工作区创建 docs/ 目录，并按依赖顺序推进。任一阶段都走“准入 → 编写 → 准出检查”流程，准出前用 completeness-checklist.md 逐项验证。

• 模板内置，先读后写。 编写任何阶段文档前，必须先读取 assets/stage-content-guide.md 获取深度规范；文档头部和修正记录分别使用 doc-header-template.md、correction-record-template.md。文档写入用户工作区，不污染技能目录。
• 跳过阶段有显式风险提示。 用户可以只选 P1 + P2 + P5（SDD-Min）等档位；当上游被跳过时，技能会提示下游文档可能缺少约束，需要自行补充。
• AI 执行有约束和任务包。 调用 AI 编码前，技能生成 sdd-execution-constraint.md 和 sdd-task-package.md，按文档输入策略只加载当前任务所需规格，而不是整套项目文档。
• 三道门禁与三条完整性链。 设计门禁管编码前、实现门禁管合并前、上线门禁管部署前；同时检查规格链、执行链、证据链是否完整，避免局部完成但整体不可交付。
• 验收有量化基线。 P6 要求完成标准可执行、可检查或可留证；P7 走端到端业务场景，P8 覆盖负面路径；P4 原型编写前还需确认视觉风格、色调模式和输出格式。

适用边界与注意点

• 适合产品型软件项目，尤其是需要多人协作、长期迭代、依赖 AI 生成代码的场景；不适合一次性脚本或需求几小时内必变的探索原型。
• P1、P2 强烈建议不要跳过，它们是文档链的根基。
• 技能本身不自动写代码，而是把需求、设计、计划、验证和运维规格结构化；产出质量仍取决于输入材料的完整度。