Scrum 与敏捷开发：怎么管理一个 AI 帮你做的项目
完成时间：约 20 分钟。读完后你能用 Sprint 的方式管理你的 Vibe Coding 项目，不会”一口气让 AI 把整个系统写完”。
为什么需要 Scrum
Section titled “为什么需要 Scrum”新手最常犯的错误：
❌ 一次性给 AI 一整套需求 → AI 生成一大坨代码 → 你看不懂 → 出了 bug 找不到在哪正确的方式：
✅ 把项目拆成小块 → 每次只让 AI 做一小块 → 验证通过再做下一块Scrum 就是帮你做这件事的框架——把大项目拆成小迭代，每轮迭代（Sprint）只做一小部分，做完就验证。
类比：装修房子不会一次性把水电、墙面、家具全做了。你会先做水电 → 验收 → 再做墙面 → 验收 → 再买家具。Scrum 就是这个节奏。
核心概念速览
Section titled “核心概念速览”| 概念 | 一句话解释 | 类比 |
|---|---|---|
| Sprint | 一个固定时间的迭代周期（通常 1-2 周） | 一轮装修工期 |
| Product Backlog | 所有要做的事的总清单，按优先级排列 | 装修的完整计划书 |
| Sprint Backlog | 本轮 Sprint 要完成的任务子集 | 这周要做的事 |
| User Story | 从用户视角描述一个需求 | ”作为业主，我想要厨房能做饭” |
| Done | 什么算”完成”（不只是 AI 写完代码，还要验证通过） | 验收标准 |
User Story：需求的最小单位
Section titled “User Story：需求的最小单位”User Story 是描述需求的标准格式：
作为 [角色]，我想要 [功能]，以便 [价值]示例（记账系统）
Section titled “示例（记账系统）”✅ 好的 User Story：
作为普通用户，我想要按月筛选费用记录，以便查看某个月的支出情况。
验收标准：- [ ] 页面有月份选择器- [ ] 选择月份后只显示该月记录- [ ] 月度总额随筛选更新- [ ] 默认显示当月❌ 差的 User Story：
做一个费用管理系统。
（太大了，不知道从哪开始，不知道什么算完成）User Story 拆分技巧
Section titled “User Story 拆分技巧”大需求 → 拆成多个小 Story：
❌ 太大："做一个完整的用户系统"
✅ 拆开：Story 1：作为用户，我想要注册账号（邮箱+密码）Story 2：作为用户，我想要登录并获得 tokenStory 3：作为用户，我想要查看自己的个人信息Story 4：作为管理员，我想要查看所有用户列表拆分原则：每个 Story 应该能在 1-2 天内完成（让 AI 做可能只需要 1-2 小时），并且做完后能独立验证。
Sprint：项目的节奏
Section titled “Sprint：项目的节奏”一个 Sprint 的完整流程
Section titled “一个 Sprint 的完整流程”graph TD Start["Sprint 开始"] --> Plan["Sprint 计划<br/>(30 分钟)<br/>从 Backlog 挑选本轮 Story"] Plan --> Work["每天工作 (1-2 周)<br/>给 AI Prompt → 生成 → 验证 → 下一个<br/><br/>每天问自己：<br/>昨天做了什么？今天做什么？卡在哪？"] Work --> Review["Sprint 回顾 (15 分钟)<br/>做完了哪些？还剩什么？<br/>什么做得好？什么要改？"] Review --> Next["下一个 Sprint"] Next --> PlanVibe Coding 的 Sprint 示例
Section titled “Vibe Coding 的 Sprint 示例”Sprint 1（第 1 周）：MVP — 能用就行
| Story | 给 AI 的任务 | 验证标准 |
|---|---|---|
| 费用 CRUD | 帮我做增删改查接口 | 能用 curl 创建和查询费用 |
| 费用列表页 | 帮我做一个费用列表页面 | 浏览器能看到数据 |
| 按月筛选 | 加一个月份筛选功能 | 选择月份后列表正确过滤 |
Sprint 2（第 2 周）：用户系统
| Story | 给 AI 的任务 | 验证标准 |
|---|---|---|
| 用户注册 | 帮我加注册接口，bcrypt 加密 | 注册成功，密码在数据库里是哈希 |
| 用户登录 | 帮我加登录接口，返回 JWT | 登录返回 token |
| 数据隔离 | 每个用户只能看自己的费用 | 用户 A 看不到用户 B 的数据 |
Sprint 3（第 3 周）：管理员功能
| Story | 给 AI 的任务 | 验证标准 |
|---|---|---|
| 管理员视图 | 管理员能看到所有费用 | admin 登录后能看全部数据 |
| 审批流程 | 管理员能批准/驳回费用 | 状态能从 pending 变成 approved |
| 仪表盘 | 加一个总支出和分类汇总 | 数据正确，和明细一致 |
注意：每个 Sprint 结束时你都有一个能跑的系统——不是 Sprint 3 才能用，Sprint 1 结束就已经能记账了。
看板：可视化你的进度
Section titled “看板：可视化你的进度”用一个简单的看板跟踪每个 Story 的状态：
┌──────────────┬──────────────┬──────────────┬──────────────┐│ 待做 │ 进行中 │ 验证中 │ 完成 ✅ ││ To Do │ In Progress │ Verifying │ Done │├──────────────┼──────────────┼──────────────┼──────────────┤│ 管理员视图 │ 数据隔离 │ 用户登录 │ 费用 CRUD ││ 审批流程 │ │ │ 费用列表页 ││ 仪表盘 │ │ │ 按月筛选 ││ │ │ │ 用户注册 │└──────────────┴──────────────┴──────────────┴──────────────┘Vibe Coding 的看板多了一列”验证中”——AI 写完代码后，你还需要验证才算真正完成。
| 工具 | 适合 | 费用 |
|---|---|---|
| GitHub Projects | 代码在 GitHub 上的项目 | 免费 |
| Notion | 个人/小团队，灵活 | 免费版够用 |
| Linear | 专业开发团队 | 免费版够用 |
| 纸笔/白板 | 最简单，学习阶段够了 | 免费 |
学习阶段用纸笔或 Notion 就够了，不需要复杂工具。
估算：这个 Story 要多久
Section titled “估算：这个 Story 要多久”Story Points（故事点数）
Section titled “Story Points（故事点数）”用相对大小估算工作量，不是精确到小时：
| 点数 | 含义 | Vibe Coding 实际耗时 |
|---|---|---|
| 1 | 非常简单，一个 Prompt 搞定 | 10-30 分钟 |
| 2 | 简单，可能需要 2-3 轮对话 | 30 分钟 - 1 小时 |
| 3 | 中等，涉及 2-3 个文件 | 1-2 小时 |
| 5 | 较复杂，需要仔细验证 | 半天 |
| 8 | 复杂，可能需要拆分 | 一天 |
| 13 | 太大了，必须拆分 | 拆成多个小 Story |
费用 CRUD 接口 → 2 点（AI 一次性生成，简单验证）JWT 登录系统 → 5 点（涉及多个文件，要仔细测权限）审批流程 + 状态机 → 5 点（业务逻辑需要仔细验证）仪表盘（聚合统计） → 3 点（查询逻辑 + 前端展示）WebSocket 实时通知 → 8 点（新技术，需要调试）超过 8 就该拆。如果一个 Story 你都不知道该给多少点，说明需求还没想清楚——回去用思考框架再分析一遍。
Vibe Coding 项目的 Sprint 模板
Section titled “Vibe Coding 项目的 Sprint 模板”每次开始一个新项目，用这个模板规划你的前 3 个 Sprint：
Sprint 0：准备（半天）
Section titled “Sprint 0：准备（半天）”- 用 6 层思考框架分析系统
- 写出所有 User Story
- 用 Story Points 估算
- 按优先级排列成 Product Backlog
- 创建 CLAUDE.md
- 搭建开发环境（Docker + 项目初始化）
Sprint 1：MVP（1 周）
Section titled “Sprint 1：MVP（1 周）”- 挑出最核心的 3-5 个 Story
- 目标：做出一个能跑的最简版本
- 不考虑登录、权限、性能——先让核心功能能用
Sprint 2：完善（1 周）
Section titled “Sprint 2：完善（1 周）”- 加用户系统 + 权限
- 修 Sprint 1 遗留的 bug
- 补充输入校验
Sprint 3+：根据实际需要
Section titled “Sprint 3+：根据实际需要”- 性能优化？安全加固？新功能？
- 看你的 Backlog 里什么优先级最高
| 误区 | 正确做法 |
|---|---|
| ”先把需求全部想好再动手” | 先做 MVP，在使用中发现新需求 |
| ”Sprint 里的 Story 必须全部做完” | 做不完就移到下一个 Sprint，不要赶工 |
| ”AI 写代码很快，不需要 Sprint” | AI 快但你的验证需要时间，Sprint 帮你控制节奏 |
| ”估算必须很准” | 估算是为了发现”这个太大了需要拆”，不是为了精确到小时 |
| ”一个人做项目不需要 Scrum” | 一个人更需要——没人监督时，Scrum 帮你保持节奏和方向 |
用记账系统作为例子，完成以下任务：
- 写 5 个 User Story，每个都包含验收标准
- 给每个 Story 估 Story Points
- 分配到 Sprint 1 和 Sprint 2（Sprint 1 只放最核心的）
- 在纸上画一个看板，把 5 个 Story 放到”待做”列
参考答案：
Sprint 1（MVP）： - 费用 CRUD（2 点） - 费用列表 + 月度筛选（3 点） - 月度汇总统计（2 点） 共 7 点
Sprint 2（用户系统）： - 用户注册/登录（5 点） - 数据隔离（3 点） 共 8 点| 概念 | 你需要记住的 |
|---|---|
| Sprint | 1-2 周一轮，每轮结束有可用的产品 |
| User Story | ”作为X，我想要Y，以便Z” + 验收标准 |
| 看板 | 待做 → 进行中 → 验证中 → 完成 |
| Story Points | 相对估算，超过 8 就拆 |
| 核心节奏 | 计划 → 执行(AI写+你验) → 回顾 → 下一轮 |
一句话总结：Scrum 不是给大公司用的复杂流程，而是帮你把大象吃掉的方法——一口一口来。
下一步：回到主线，开始 Step 1：思考框架。