规格驱动开发

在编写任何代码之前，先写一份结构化的规格说明。没有规格的代码就是在猜。

使用场景

• 开始一个新项目或新功能
• 需求含糊不清或不完整
• 该变更涉及多个文件或模块
• 你即将做出一个架构决策
• 该任务的实现需要超过 30 分钟

带门禁的工作流

SPECIFY ──→ PLAN ──→ TASKS ──→ IMPLEMENT
   │          │        │          │
   ▼          ▼        ▼          ▼
 Human      Human    Human      Human
 reviews    reviews  reviews    reviews

阶段 1：明确规格（Specify）

从一个高层次的愿景开始。不断提出澄清性问题，直到需求变得具体。

立即浮现假设：

ASSUMPTIONS I'M MAKING:
1. This is a web application (not native mobile)
2. Authentication uses session-based cookies (not JWT)
3. The database is PostgreSQL (based on existing Prisma schema)
4. We're targeting modern browsers only (no IE11)
→ Correct me now or I'll proceed with these.

规格模板：

# Spec: [Project/Feature Name]

## Objective
[What we're building and why. User stories or acceptance criteria.]

## Tech Stack
[Framework, language, key dependencies with versions]

## Commands
[Build, test, lint, dev — full commands]

## Project Structure
[Directory layout with descriptions]

## Code Style
[Example snippet + key conventions]

## Testing Strategy
[Framework, test locations, coverage requirements]

## Boundaries
- Always: [...]
- Ask first: [...]
- Never: [...]

## Success Criteria
[Specific, testable conditions]

## Open Questions
[Anything unresolved that needs human input]

阶段 2：规划（Plan）

基于经过验证的规格，生成一份技术实现计划：

1. 识别主要组件及其依赖关系
2. 确定实现顺序
3. 记录风险与缓解策略
4. 识别可并行化的机会
5. 定义验证检查点

阶段 3：任务（Tasks）

将计划拆分为离散的、可实现的任务：

- [ ] Task: [Description]
  - Acceptance: [What must be true when done]
  - Verify: [How to confirm — test command, build, manual check]
  - Files: [Which files will be touched]

阶段 4：实现（Implement）

遵循增量实现和测试驱动开发，一次执行一个任务。

让规格保持鲜活

规格是一份活的文档：

• 当决策改变时更新它
• 当范围改变时更新它
• 将规格与代码一起提交
• 在 PR 中引用规格

验证

在进入实现阶段之前：

• 规格涵盖了全部六个核心领域
• 人类已审查并批准了规格
• 成功标准具体且可测试
• 边界（始终做 / 先询问 / 绝不做）已定义
• 规格已保存为仓库中的一个文件