规格先行¶
先固定问题，再讨论实现。
规格先行（Spec First）是 Vibe Coding 最重要的习惯。在让 AI 写任何代码之前，先用自然语言把问题边界写清楚。这一步通常只需要 5 分钟，却能避免 80% 的跑偏和返工。
为什么需要规格¶
AI 模型非常擅长"完成任务"，但它不知道你真正想要什么——除非你告诉它。
没有规格时，AI 会做出合理但错误的假设：
- 你说"加个搜索功能"，它可能实现了全文搜索，但你只需要按名称过滤
- 你说"优化这个函数"，它可能重写了整个模块，但你只想改一个算法
- 你说"修复这个 Bug"，它可能改了症状，但没有修复根因
规格的作用是提前约束改动边界，让 AI 的"合理假设"和你的预期对齐。
一个可执行规格应包含¶
| 字段 | 说明 | 示例 |
|---|---|---|
| 目标行为 | 完成后系统应该做什么 | 用户点击"用 GitHub 登录"后跳转到 OAuth 授权页 |
| 不做什么 | 明确排除的内容 | 不新增后端接口，不修改现有用户表结构 |
| 输入和输出 | 数据流的起点和终点 | 输入：GitHub OAuth token；输出：session cookie |
| 影响范围 | 可以修改哪些文件 | 只改 src/auth/ 和登录页组件 |
| 验证方式 | 怎么确认完成了 | 运行 pnpm test auth 和手动走一遍登录流程 |
| 已知风险 | 可能出问题的地方 | GitHub OAuth 回调 URL 需要在开发环境配置 |
不是每个规格都需要填满所有字段。简单任务可以只写前三项；复杂任务或安全敏感改动需要全部填写。
示例对比¶
模糊请求（容易跑偏）：
可执行规格（边界清晰）：
目标：为登录页增加 GitHub 登录按钮，点击后走 OAuth 流程，成功后写入 session。
范围：只改 src/auth/providers.ts 和 src/pages/login.tsx，不新增后端接口。
约束：沿用现有按钮样式（Button 组件）和 loading 状态逻辑。
验证：运行类型检查和登录页组件测试，手动验证 OAuth 回调正常。
风险：本地开发需要在 .env.local 配置 GITHUB_CLIENT_ID。
第二个版本让 AI 知道：改哪里、不改哪里、用什么风格、怎么验证。
规格的粒度¶
规格不需要写成需求文档。一段话就够，关键是覆盖边界。
- 太粗：没有约束，AI 自由发挥
- 刚好：覆盖目标、范围、验证，AI 有足够信息做决策
- 太细：变成伪代码，失去 AI 的价值
判断标准：读完规格后，你能预测 AI 会改哪些文件吗？如果能，规格就够了。
规格先行的时机¶
不是所有任务都需要完整规格。以下情况必须先写规格：
- 改动涉及多个文件或模块
- 任务有明确的"不做什么"
- 安全、权限、数据库相关改动
- 团队协作时需要对齐理解
以下情况可以简化：
- 单文件的小改动（修个拼写、调个样式）
- 探索性的原型（先跑起来再说）