核心定位与用法
Spec Workflow Guide 是一套面向软件开发团队的结构化需求到实现工作流工具，核心目标是通过强制分阶段交付（需求→设计→任务→执行）来提升中大型变更的质量可控性。
核心用法
四阶段强制流转：
1. Requirements 阶段：创建 specs/<name>/requirements.md，使用 EARS 模式（While...When...Shall）撰写可测试的验收标准，明确业务规则与非目标边界
2. Design 阶段：创建 specs/<name>/design.md，阐述架构边界、技术选型 trade-off、数据模型/API/安全/测试策略
3. Tasks 阶段：创建 specs/<name>/tasks.md，将设计拆解为可执行、可评审的具体任务，并建立与需求的追溯链接
4. Execution 阶段：仅在用户确认任务计划后方可进入编码，保持变更→任务→需求的完整可追溯性
关键协作规则：
- 用户确认节点：需求→设计→任务 三阶段必须逐次获得用户确认
- 早期引入 UI Design Skill：凡涉及终端用户页面或视觉决策，需提前联动 UI 设计技能
- 追问机制：需求不明确时主动提问，禁止猜测核心产品行为
显著优点
- 强制验收标准显性化：EARS 模式将模糊的"做得好"转化为可测试的客观标准
- 跨模块协调机制：明确为需要多文件、多用户流、数据库设计、UI 设计的复杂场景而生
- 可追溯性保障：任务→需求的双向链接确保变更动机始终可查
- 决策边界清晰：提供明确的"使用/不使用"判断规则，避免流程僵化
潜在缺点与局限
- 轻量任务 overhead：小 Bug 修复、单文件文档更新、明确配置变更等场景强制走流程反而降低效率
- 用户配合依赖：三阶段确认机制要求用户深度参与，异步协作或需求方响应慢时周期拉长
- Mermaid 图表可选：设计阶段未强制要求可视化，复杂架构的沟通成本可能未完全消除
- 验收标准质量参差：EARS 模式本身不保证写出好的验收标准，依赖执行者能力
适合人群
- 中大型产品团队：有专职产品经理、架构师、开发分工的协作场景
- 质量敏感型项目：金融、医疗、政务等对验收标准有合规要求的领域
- 远程/异步协作团队：需要文档化共识替代面对面沟通的场景
- 技术债务治理期：需要结构化梳理现有系统边界的重构项目
常规风险
- 形式主义风险：团队机械执行模板但内容空洞，沦为"文档工厂"
- 阶段跳跃诱惑：开发者或业务方压力下的"先写代码后补文档"破窗效应
- 确认节点阻塞：用户方决策延迟导致项目挂起，需建立升级机制
- 技能联动缺失：未早期识别 UI/数据模型需求，导致设计返工