AI Ready 规格撰写

要解决的具体问题

输入需求常常带着空白：谁有权限、字段能取哪些值、状态怎么流转、失败后返回什么。开发 Agent 读到“支持”“正常”“合理”这类词时，只能替人猜业务规则；测试 Agent 面对不确定的 SC/AC，也形不成稳定断言。本技能把目标、事实、缺口和冲突收敛成一份规范性 Spec，让 Spec 描述“必须实现什么”，而不是记录需求分析过程。

核心能力

• 按模板收敛输入：以 assets/spec-template.md 为骨架，只保留对当前范围有实际内容的章节，删除不适用提示。
• FR 统一组织：每个 FR 按功能目标、功能行为、业务规则、不满足条件时的结果、验收标准、核心场景展开。
• 稳定引用：共享规则使用 BR-[模块]-[序号]，全局权限使用 BR-AUTH-[序号]；禁止用“按第 X 节”“见上表”定位。
• 验收标准取舍：SC 提炼关键独立结果，通常 3～8 条；AC 只覆盖真实存在的高风险路径，不为越权或接口篡改虚构 UI。
• 缺口处理：按优先级采用来源规则、相互印证结论或影响最小方案；未确认事项用三列清单列出。

关键步骤

1. 读取用户描述、原型和约束，提取目标、用户和已明确事实。
2. 检查范围、权限、字段、状态、计算、关联和完成判定等缺口。
3. 先闭合共享规则并分配 BR ID，再拆分 FR、编写 SC/AC。
4. 引用时写出稳定 ID 与最小实现结论，不整表复制大型字典。
5. 质量校验后交付 Markdown 文件和简短摘要。

适用边界

• 只规定业务行为、字段规则、状态和可观察结果，不规定接口、数据库、缓存、日志、代码组织和测试实现。
• 待人工确认事项不作为默认交付门禁；确认前 FR、SC 和必要 AC 必须先写成可开发、可验收的唯一行为。
• 流程图和交互依据只辅助理解已有需求，不能替代字段、权限、决策或状态规则。
• 详细测试数据、等价类、选择器或自动化步骤不写入 Spec。
• 审查模式默认只报告问题；更新模式保留用户已有修改，不回退无关内容。