SOP：项目搭建
从需求到交付的完整 Vibe Coding 项目搭建流程。
适用场景
- 从零开始搭建新项目
- 为已有项目添加新模块
- 任何需要从 spec 开始的任务
前置条件
- 已安装 Claude Code 并完成认证
- 有一个 git 仓库（空目录或有初始代码）
- 准备好写 spec（你可以用下面的模板）
流程步骤
步骤 1：写 spec.md
用自然语言描述你要做什么。spec 是你与 AI 的契约——写得越具体，AI 越精确。
直接复制下面的模板开始填写：
markdown
# Spec：[项目名称]
## 概述
[一句话描述项目目标]
## 需求
- [需求 1：做什么]
- [需求 2：做什么]
- [需求 3：做什么]
## 约束
- 技术栈：[具体技术栈，如 Node.js + Express + SQLite]
- 语言：[TypeScript / Python / 等]
- 不使用：[明确排除的技术，如"不使用 MongoDB"、"不使用微服务"]
- 代码风格：[命名导出、async/await 等]
- 无外部依赖：[或列出允许的依赖]
## 成功标准
- [标准 1：如"所有 API 端点有对应测试"]
- [标准 2：如"npm run lint 无错误"]
- [标准 3：如"手动测试 CRUD 流程无误"]
## 不做的事
- [明确排除：如"不做用户权限管理"、"不做部署配置"]spec 写作要点
- 需求用动词开头："添加"、"支持"、"实现"——不要写"要有 XX"
- 约束写否定句："不使用 XX"、"不改测试文件"——AI 会遵守否定约束
- 成功标准可测试——写能用命令验证的标准（"npm test 通过"），而不是模糊标准（"代码质量好")
- "不做的事"很重要——明确边界防止 AI 越界
步骤 2：让 AI 生成 plan.md
启动会话，让 Claude 基于 spec 生成实施计划：
读取 spec.md，生成 plan.md 实施计划。计划包含：
- 文件结构和目录布局
- 数据模型设计
- 模块边界和接口定义
- 实现顺序（哪些先做哪些后做）
- 每个步骤的预期产出
不要直接修改任何代码。审查 plan.md： 重点检查：
- 技术栈是否与 spec 约束一致？（AI 可能自行换技术栈）
- 实现顺序是否合理？（先做数据模型 → 再做 API → 再做前端）
- 是否有 spec 中"不做的事"出现在计划里？
步骤 3：审查 plan.md（推荐新会话）
重新开一个会话，让 Claude 以审查者视角检查 plan：
读取 spec.md 和 plan.md。审查 plan 是否：
1. 遵守了 spec 中所有约束
2. 没有遗漏 spec 中任何需求
3. 实现顺序合理（依赖关系正确）
4. 没有过度工程化
列出发现的风险和遗漏。不要修改任何文件。新会话没有"原作者的思维惯性"——审查更客观。
步骤 4：让 AI 生成 tasks.md
审查通过后，让 Claude 把计划拆解为可逐条执行的清单：
读取 plan.md，生成 tasks.md 任务清单。每条任务：
- 一行描述，动词开头
- 带状态标记 [ ] / [x]
- 按实现顺序排列
- 每条任务可以独立完成和验证
每 2-3 条任务应能在一个会话内完成。步骤 5：逐条执行
每个会话只做几条任务，完成后标记 [x]，提交 checkpoint：
开始执行 tasks.md 中的任务 1-3：[具体任务描述]
完成后运行测试确认没有引入新错误。每做完一批任务：
- 审查变更
- 运行测试
git add + git commit（checkpoint）- 更新 tasks.md 中的
[ ]→[x]
步骤 6：验证交付
所有任务完成后：
运行完整测试套件和 lint 检查。确认所有 spec.md 中的成功标准都满足。可复用模板
spec.md 模板
markdown
# Spec：[项目名称]
## 概述
[一句话描述]
## 需求
- [需求列表]
## 约束
- 技术栈：[具体]
- 不使用：[排除]
- [其他约束]
## 成功标准
- [可测试的标准列表]
## 不做的事
- [排除列表]plan.md 模板
markdown
# Plan：[项目名称]
## 文件结构
[目录布局和文件列表]
## 数据模型
[核心数据模型定义]
## 模块边界
[模块职责划分和接口]
## 实现顺序
1. [步骤 1]
2. [步骤 2]
3. [步骤 3]
## 风险
- [风险 1] → 对策：[对策]
- [风险 2] → 对策：[对策]tasks.md 模板
markdown
# Tasks：[项目名称]
- [ ] 1. [任务 1]
- [ ] 2. [任务 2]
- [ ] 3. [任务 3]
- [ ] 4. [任务 4]
- [ ] 5. [任务 5]
- [ ] 6. [任务 6]
- [ ] 7. [任务 7]常见问题
Q：spec 写多细合适？ A：足够让 AI 不做你没要求的决策，但不用写 API 参数签名这种细节。目标是"AI 在每个决策点都有明确的指引"。
Q：plan 审查后发现重大问题怎么办？ A：修改 spec.md（调整约束），让 AI 重新生成 plan。不要在 plan 上手动修改——重新生成更干净。
Q：执行中发现 spec 需要调整？ A：停下来，更新 spec.md，让 AI 重新生成受影响的 plan 和 tasks 部分。不要在执行中随意偏离 spec——那会让 tasks.md 失去追踪价值。
与其他 SOP 的关系
- 前置 SOP： 无（这是起点）
- 后续 SOP： SOP：调试排障（执行中遇到 bug）、SOP：审查发布（完成后准备发布）
- 配合工具： spec → plan → tasks 工作流、多会话协作策略