核心用法
Feature Specification 是一种元技能（Meta-Skill），核心任务是将 PERSONA.md 中定义的用户画像、痛点和用户旅程，转化为可供开发团队执行的功能规格文档。使用时需遵循以下流程：
1. 前置条件：确保已存在 persona 文档，明确目标用户及其核心诉求
2. 文档生成：在 docs/specs/ 或 docs/features/ 目录下创建功能规格书，使用标准模板结构
3. 需求转化：将画像中的痛点转化为具体的问题陈述（Problem Statement），再推导解决方案描述
4. 用户故事编写：严格遵循 INVEST 原则（Independent, Negotiable, Valuable, Estimable, Small, Testable），采用 "As a [persona], I want [action], so that [benefit]" 格式
5. 验收标准制定：使用 Given/When/Then 语法覆盖 happy path、边界条件、错误处理、状态转换和安全场景
6. 优先级排序：应用 MoSCoW 框架（Must/Should/Could/Won't），以 persona 影响而非技术兴趣为锚点
7. 范围界定：明确列出依赖项和明确排除项（Out of Scope），防止范围蔓延
显著优点
- 结构化输出：提供完整的模板体系，涵盖元数据、问题陈述、用户故事、验收标准、边缘案例、非功能需求等维度，确保规格书无遗漏
- 开发者友好：验收标准采用行为驱动开发（BDD）风格，可直接转化为自动化测试用例，QA 团队可直接引用
- 需求追溯性强：每个功能必须映射回具体 persona 和痛点，避免"为技术而技术"的功能堆砌
- 防范围蔓延机制：通过 Out of Scope 清单和依赖项显式声明，在项目早期锁定边界
- 质量门禁设计：明确禁止跳过验收标准、禁止模糊词汇（如"fast""user-friendly"）、禁止单规格多功能，从源头提升需求质量
潜在缺点与局限性
- 前置依赖较重：必须已有成熟的 persona 文档，若画像本身质量差或缺失，规格书将失去根基
- 文档开销显著：完整的规格书包含大量结构化字段，对于小型团队或快速迭代场景可能显得笨重
- 模板僵化风险：严格遵循模板可能导致过度文档化，在探索性、实验性项目中可能抑制灵活性
- 验收标准撰写门槛高：编写高质量的 Given/When/Then 需要训练，团队缺乏 BDD 经验时易产生形式化但无价值的描述
- 非功能需求易流于形式：性能、安全、可访问性等要求若无量化指标，易成为模板中的占位符
适合人群
- 产品经理/业务分析师：需要将用户研究转化为开发输入的中枢角色
- 技术负责人/架构师：需在编码前明确技术依赖和非功能需求边界
- 敏捷教练/Scrum Master：希望引入 BDD 实践，提升团队需求澄清效率
- 中大规模研发团队：多人协作、多角色参与，需统一的需求交付标准
- 外包/跨团队协作场景：需通过文档而非口头沟通传递需求的复杂项目
常规风险
- 规格书与实现脱节：开发过程中需求变更但未同步更新规格书，导致文档沦为"考古资料"
- 过度设计早期规格：在不确定性高的阶段投入过多细节规格，后期因方向调整造成浪费
- 验收标准覆盖不足：团队仅关注 happy path，忽略并发、异常、安全等场景，上线后暴露缺陷
- MoSCoW 误用：将技术团队的兴趣项标记为 Must，而真正影响用户的核心功能被降级
- 工具链假设风险：技能文档提及
npx clawhub@latest等特定安装方式，实际可用性取决于特定生态（OpenClaw/Moltbot/Clawbot）的成熟度，存在 vendor lock-in 隐患