核心用法
Spec-Flow 是一套规格驱动开发（Spec-driven development）的结构化工作流，通过强制性的分阶段确认机制来管理复杂功能开发。用户通过触发词（如"写个方案""plan this feature"）激活后，AI 会按 Phase 0→5 逐步推进：初始化→提案→需求→设计→任务拆解→实施。每完成一个阶段即暂停等待用户确认（"继续"/"ok"/"next"），严禁预生成后续阶段文档。
显著优点
1. 防范围蔓延（Scope Creep）：通过显式的 Non-Goals 和强制确认节点，确保需求边界清晰
2. 可测试性保障：EARS 格式需求（The system shall...）+ 逐条可测试性自检
3. Living Documentation：生成的 .spec-flow/ 目录成为团队持续参考的技术资产
4. 多语言支持：所有输出文档强制使用中文，适配本土团队
5. 灵活执行模式：支持 --fast 快速生成、--skip-design 跳过设计阶段、Step/Batch/Phase 三种实施模式
潜在缺点与局限性
- 交互 overhead 高：标准模式下需 5+ 次人工确认，简单功能可能显得冗长
- 模板依赖：依赖
templates/和references/外部文件，环境缺失时行为不确定 - 归档依赖人工：Phase 5 完成后需手动或条件触发归档，无自动清理机制
- 无版本控制感知：目录结构建议与 git 工作流配合，但未内置分支/PR 集成
适合人群
- 中大型功能开发：需要跨会话、多人协作的复杂需求
- 技术方案评审场景：需要结构化输出提案文档供团队 review
- 新人 onboarding：通过标准化的任务拆解（1-2 tool calls/任务）降低认知负担
- 敏捷与瀑布混合团队：既要有文档严谨性，又要保持迭代灵活性
常规风险
| 风险类型 | 说明 | 缓释措施 |
|---------|------|---------|
| 确认疲劳 | 频繁中断可能降低用户体验 | 使用 `--fast` 模式或切换 Batch Mode |
| 文档腐化 | 实施阶段未同步更新 tasks.md 状态 | 每个任务执行后强制 `- [ ]` → `- [x]` 更新 |
| 模板漂移 | steering/ 文档与代码实际状态不一致 | 定期 review `.spec-flow/steering/` 时效性 |
| 过度设计 | Phase 3 可能产生不必要的架构复杂度 | 强制自检问题："有没有更简单的方案？" |