（3703期）Spec Flow – 结构化需求开发，五阶分步确认

结构化需求开发，五阶分步确认 结构化需求驱动开发工作流，五阶段分步确认从提案到实施，生成living documentation作为团队参考，防止scope creep 使用说明 核心用法 Spec-Flow 是一套规格驱动开发（Spec-driven development）的结构化工作流，通过强制性的分阶段确认机制来管理复杂功能开发。用户通过触发词（如"写个方案""plan this feature"）激活后，AI 会按 Phase 0→5 逐步推进：初始化→提案→需求→设计→任务拆解→实施。每完成一个阶段即暂停等待用户确认（"继续"/"ok"/"next"），严禁预生成后续阶段文档。 显著优点 防范围蔓延（Scope Creep）：通过显式的 Non-Goals 和强制确认节点，确保需求边界清晰 可测试性保障：EARS 格式需求（The system shall...）+ 逐条可测试性自检 Living Documentation：生成的 .spec-flow/ 目录成为团队持续参考的技术资产 多语言支持：所有输出文档强制使用中文，适配本土团队 灵活执行模式：支持 --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 可能产生不必要的架构复杂度 | 强制自检问题："有没有更简单的方案？" | 原始说明 Spec-driven development workflow. Interactive phase-by-phase confirmation from proposal to implementation. Trigger: 'spec-flow', 'spec mode', 'need a plan',...