各角色操作手册

日常操作流程

Step 1: 在 Claude Code 中运行 /speckit.specify
Step 2: 用自然语言描述功能需求
Step 3: 检查生成的 spec.md：
        - 用户场景是否完整？
        - 优先级分层（P1/P2/P3）是否合理？
        - 验收标准是否可测试？
        - 边界条件是否覆盖？
Step 4: 对 [NEEDS CLARIFICATION] 标记的点做出决策
Step 5: 运行 /speckit.clarify 解决剩余模糊点
Step 6: 将 spec.md 交给开发和测试审阅

写好 Spec 的要诀

• 用“作为 XX，我想 XX，以便 XX”的格式写用户故事。
• 验收标准尽量使用 Given / When / Then，方便测试直接转用例。
• 写清楚“做什么”，也写清楚“不做什么”，避免范围蔓延。
• 遇到拿不准的点，不要自己猜，显式标记 [NEEDS CLARIFICATION]。

产品经理最容易踩的坑

• 把需求写成实现方案，过早指定技术细节。
• 只有功能描述，没有边界条件和异常场景。
• 验收标准写得太抽象，导致后面很难验证完成与否。

日常操作流程

Step 1: 审阅产品提交的 spec.md
        - 检查需求是否有歧义
        - 评估技术可行性
        - 提出修改建议

Step 2: 运行 /speckit.plan
        - 检查数据模型设计是否合理
        - 检查接口设计是否符合宪法
        - 确认复杂度评估

Step 3: 运行 /speckit.tasks
        - 检查任务拆分粒度
        - 确认依赖关系正确
        - 检查并行标记是否合理

Step 4: 运行 /speckit.implement
        - AI 按任务清单逐步生成代码
        - 你负责 Review 每一步的输出
        - 对不满意的地方要求 AI 修正

Step 5: 运行 /speckit.analyze
        - 确认规格、计划、任务、代码四者对齐
        - 修复任何 CRITICAL 或 HIGH 级别的问题

Step 6: 提 MR，走正常的 Code Review 流程

开发同学的关键注意事项

• 宪法文件是你的依据：如果需求违反技术约束，应回到宪法讨论。
• Plan 阶段要补充产品视角看不到的技术细节，例如缓存、并发、异常策略。
• Implement 阶段 AI 生成的代码必须逐文件 Review，不能盲目信任。
• Analyze 阶段不是可有可无，它是发现“文档和代码脱节”的关键环节。

开发最容易踩的坑

• 跳过 Plan，直接让 AI 写代码，导致实现与规格脱节。
• 任务拆分过粗，后续很难跟踪进度和回写完成状态。
• 把 AI 当成自动驾驶，不做代码审查和修正。

日常操作流程

Step 1: 在 Specify 阶段参与 spec.md 审阅
        - 验收标准是否可测试？
        - 边界条件是否覆盖充分？
        - 异常场景是否有考虑？

Step 2: 安装并使用 V-Model 扩展
        specify extension add v-model

Step 3: 运行 /speckit.v-model.requirements
        - 为每条需求分配 REQ-NNN 编号
        - 确保所有需求可追溯

Step 4: 运行 /speckit.v-model.acceptance
        - 生成三层验收测试计划
        - 包含 BDD 场景和测试数据
        - 验证 100% 需求覆盖

Step 5: 在开发完成后运行 /speckit.v-model.trace
        - 生成追溯矩阵
        - 检查是否有需求缺失测试
        - 检查是否有测试缺失需求

Step 6: 使用追溯矩阵作为测试报告的依据

V-Model 扩展给测试的价值

• 在写需求阶段就能定义怎么测，而不是等开发完成后被动补测。
• 追溯矩阵自动生成，减少手工维护覆盖表的负担。
• 测试方案与设计方案一一对应，确保覆盖不漏项。
• 输出符合 IEEE / ISO 标准，更适合审计和正式交付场景。

测试最容易踩的坑

• 只在实现后介入，错过需求阶段定义验收标准的最佳时机。
• 只关注正常路径，没有把边界条件和异常场景提前写进规格。
• 有测试执行记录，但没有回到具体需求，导致追溯断裂。