Spec Workflow Guide 是一套面向中大型软件变更的结构化开发流程，强调在编码前完成需求澄清、技术设计和任务拆解。其核心分为四个阶段：
Phase 1: Requirements（需求）
要求产出 requirements.md，包含问题重述、用户故事、业务规则及采用 EARS 模式（When... the system shall...）编写的验收标准。该模式强制明确触发条件与系统响应，避免模糊描述。
Phase 2: Design（设计）
产出 design.md，涵盖架构边界、技术选型权衡、数据模型、API 设计、安全与测试策略。仅在图表能实质提升清晰度时使用 Mermaid，避免过度文档化。
Phase 3: Tasks（任务）
产出 tasks.md，将设计拆分为可执行、可review的具体任务，每个任务需反向链接到对应需求编号，确保可追溯性。
Phase 4: Execution（执行）
必须待用户确认任务计划后方可编码，执行中保持任务状态更新，按有意义单元推进。
显著优点：强制验收标准前置，降低返工风险；EARS模式提升需求可测试性；跨模块变更通过文档化协作减少沟通损耗；任务-需求双向追溯保障变更可控。
潜在局限：对于小型修复或单文件改动，完整流程显得笨重，可能拖慢迭代速度；团队需接受EARS培训，初期有学习成本；过度坚持阶段 gate 可能在探索性场景中降低灵活性。
适用人群：技术团队负责人、架构师、产品经理及需处理多模块集成的开发者，尤其适合对需求质量有硬性要求的企业级开发场景。
常规风险：用户可能在压力下跳过确认环节直接编码，导致后期返工；任务拆解过细可能陷入微观管理；若设计阶段过度推测技术细节，可能在执行时发现前期假设不成立。建议保留"小型变更可直接执行"的逃逸通道，避免流程僵化。