核心用法
Spec Workflow Guide 是一套面向中大型软件变更的结构化开发流程管理技能，核心目标是在编码前完成需求澄清、技术设计与任务拆解，避免"边做边改"的低效模式。
四阶段工作流
1. Requirements（需求）：创建 specs/<name>/requirements.md，重述问题与范围，编写用户故事，采用 EARS 格式（While/When/Shall）撰写可验收标准
2. Design（设计）：创建 specs/<name>/design.md，定义架构边界、技术选型权衡、数据模型/API/安全/测试策略，Mermaid 图表仅用于关键复杂度说明
3. Tasks（任务）：创建 specs/<name>/tasks.md，将设计拆分为可执行、可审查的具体任务，每项任务反向关联需求编号
4. Execution（执行）：用户确认任务计划后方可启动编码，保持任务状态同步，确保变更→任务→需求的完整可追溯性
触发条件判定
- 强制使用：新功能、跨模块集成、架构设计任务、验收标准模糊、多文件/多用户流程/数据库设计需分阶段确认
- 跳过流程：小型 bug 修复、单文件文档更新、直接配置变更、用户已给出精确实现指令的简单重构
协同技能
- 前端/视觉工作 → 联动
ui-design技能 - 数据模型设计 → 联动
data-model-creation技能
显著优点
- 需求质量提升：EARS 格式强制将模糊需求转化为可测试的验收标准，显著降低交付偏差
- 风险前置暴露：设计阶段即需确认技术方案，避免编码后期发现架构性缺陷
- 跨模块协调：通过显式的阶段边界和确认机制，解决多模块并行开发的同步问题
- 可追溯性：任务→需求的双向链接确保任何代码变更都有明确的业务动机文档
- 用户对齐：强制用户确认机制（Requirements→Design→Tasks 每阶段）防止理解偏差累积
潜在局限
- overhead 成本：小型变更强制走完整四阶段会产生不必要的文档负担，与"小步快跑"敏捷原则存在张力
- 灵活性受限：严格的分阶段确认可能延缓紧急需求的响应速度
- EARS 学习曲线：非技术背景用户可能难以直接编写或理解 EARS 格式验收标准，需要 AI 辅助转换
- 工具链依赖：文档分散在
specs/目录下，缺乏集中式的可视化看板，对大型项目可能需额外管理工具
适合人群
- 中大型团队协作场景，特别是前后端分离、多模块并行的技术栈
- 需求频繁变更或历史遗留系统改造等高风险项目
- 技术负责人/架构师需要把控整体技术方向时
- 验收标准模糊、利益相关方较多的复杂业务场景
常规风险
- 阶段跳跃：团队或用户压力可能导致跳过设计确认直接进入编码，侵蚀流程价值
- 文档腐烂：
tasks.md状态若不及时更新，将导致计划与实际执行脱节 - 过度设计：设计阶段可能陷入技术炫技，产出远超实际需求的复杂方案
- 确认疲劳：频繁的用户确认点可能造成决策疲劳，用户倾向于快速点击"确认"而非深度审查
- 版本冲突：多人同时编辑
specs/目录下的 Markdown 文件可能产生合并冲突，需配合版本控制最佳实践