Development
规格驱动开发
在编码之前先创建规格。当开始一个新项目、新功能或重大变更，且尚不存在规格说明时使用。
在编写任何代码之前，先写一份结构化的规格说明。没有规格的代码就是在猜。
SPECIFY ──→ PLAN ──→ TASKS ──→ IMPLEMENT
│ │ │ │
▼ ▼ ▼ ▼
Human Human Human Human
reviews reviews reviews reviews
从一个高层次的愿景开始。不断提出澄清性问题，直到需求变得具体。
立即浮现假设：
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]
基于经过验证的规格，生成一份技术实现计划：
将计划拆分为离散的、可实现的任务：
- [ ] Task: [Description]
- Acceptance: [What must be true when done]
- Verify: [How to confirm — test command, build, manual check]
- Files: [Which files will be touched]
遵循增量实现和测试驱动开发，一次执行一个任务。
规格是一份活的文档：
在进入实现阶段之前：