DemandSpec 需求规格化

要解决什么问题

业务侧常把需求留在聊天、纪要或半成品 PRD 里：范围含糊、假设混在「已确认」里、验收口径缺失，研发与设计只能反复口头对齐。更糟的是，模型只在对话里给建议或吐出空模板，没有可落盘、可评审、可追踪的资产。

DemandSpec 面向的是：从一句话想法、会议纪要、口述、已有 PRD、截图到 AI 场景设想，把材料写入工作区里的需求包，并用稳定 ID（如 CRM-VISIT-001）串起规格、验收与任务。

技能如何工作

执行上是一条有检查点的流水线，而不是「一次性生成全套文档」：

• 检查现状：先扫 demandspec/、demands/、changes/ 及现有 PRD、纪要、原型与接口文档，优先复用真实材料。
• 判断入口：评估成熟度 L0–L6、需求类型（普通 / AI / UI / 跨系统 / 高风险），区分新需求、PRD 修订或 OpenSpec 风格变更包。
• 分离信息：已确认事实、当前假设（含验证方式）、阻塞项分开写，避免把未确认内容伪装成规格。
• 按成熟度落盘：只读本次需要的模板；L0–L2 不伪造完整 PRD，先产出需求卡片、澄清问题与范围边界。
• 可验收写法：功能用「系统 MUST/SHALL + 可观察行为」；验收用 GIVEN/WHEN/THEN；AI 场景要写低置信度处理与人工兜底；UI 要写页面状态与权限态。
• 验证与报告：对变更包做结构/追踪校验；最终列出写入文件、未决问题与验证结果，不把「文档已生成」当成「需求已确认」。

快捷路径示例：一句话想法走 Intake → Clarify → Scope；已有 PRD 走 Inspect → Review → Repair → Validate；AI 场景需补 AI Fit、数据规则与 AI 验收。

适用边界与注意点

• 模板是检查清单，不是成品；禁止无解释空标题、通用占位语或只复制模板。
• 只写理想主流程、漏掉空数据/重复提交/接口失败/权限不足，或验收与任务不带需求 ID，都会让后续无法证明「已实现、已测试」。
• 除非用户明确只要建议，否则应写文件到工作区；验证未通过时应列失败项继续修，或标明阻塞原因。