AI 指令：写代码前先做 Spec（Spec 驱动开发）

本页面向 AI 提供「Spec 驱动开发」的固定流程，综合 Kiro 与 Qoder 的规范驱动方法论。核心原则：先出文档、再写代码，文档就是契约，改需求先改文档。AI 通过 URL 访问本页后，在动手写代码之前按下列流程执行。

总原则

每完成一个步骤，必须停下来等用户审查，确认通过后才能进入下一步。不要在未经审查的情况下连续推进。

第一步：摸底（Steering）

正式开发前，先分析现有代码库，产出三份基线文档，作为后续 Spec 的依据：

  • structure.md — 代码架构、关键组件、目录组织。
  • tech.md — 技术栈、已用模式、技术约束。
  • product.md — 业务上下文、现有功能、用户流程。
第一步审查节点：把三份文档交给用户确认，内容是否准确、是否符合项目现状。

第二步：三阶段 Spec

把需求转成三份文档，依次产出：

2.1 需求（requirements）

  • 用户故事：表达价值与目的。
  • 验收标准：用 EARS 句式（WHEN…THEN…）定义可测试条件。
  • 边界情况与约束。

2.2 设计（design）

  • 技术方案研究与架构决策。
  • 数据模型与接口定义。
  • 错误处理与测试策略。

2.3 任务（tasks）

  • 把设计拆成有序、可执行的编码任务。
  • 每个任务有明确目标与验收标准，并对应到需求以保证可追溯。
第二步审查节点：用户确认需求、设计、任务拆解都无误，才可进入下一步。

第三步：执行（按 tasks 实现）

  • 严格按 tasks 的顺序实现，代码与 spec 保持一致。
  • 实现中以 requirements 的验收标准为完成依据。
  • 中途用户新增需求：先回改 spec 文档，再继续实现，不要直接改代码绕过 spec。
第三步审查节点：核对实现是否符合 spec，验收标准是否全部达成。

范围与例外

  • 适合：复杂功能、高风险项目、团队协作、知识交接、AI 辅助开发。
  • 可跳过：简单 bug 修复、实验性原型、紧急热修、已成熟的固定模式。跳过时需说明原因。