「把大象放进冰箱需要几步？三步。把大项目交给AI也需要：拆分、逐步执行、验证整合。」
开场：为什么"一步到位"在Vibe Coding里行不通
小维的同事小张，刚接触 Vibe Coding，想用它做一个完整的用户管理系统。
他的提示词：
帮我做一个完整的用户管理系统，包括：注册、登录、个人信息管理、
修改密码、忘记密码、账号注销、管理员查看用户列表、管理员修改用户权限、
管理员封禁用户、用户操作日志……
AI 生成了大量代码，但：
- 各模块之间的接口不一致
- 有些功能实现了一半
- 有些功能逻辑有漏洞
- 整体结构混乱，难以维护
小张花了三天时间修改这堆代码，最终放弃，从头重写。
问题的根源不是 AI 不够强，而是任务粒度太粗。
全局视角：迭代式开发在工作流中的位置
graph LR
A["理解需求"] --> B["任务拆解\n(本讲重点)"]
B --> C["逐步执行\n每步一个提示词"]
C --> D["验证结果"]
D --> E{符合预期?}
E -->|是| F["下一步"]
E -->|否| C
F --> G["完成集成"]
核心知识点一：任务拆解的黄金标准
一个好的任务拆解，让每个子任务满足以下条件：
标准一：独立性（Independence）
每个子任务可以独立完成，不依赖其他子任务的输出（或者依赖关系是明确的）。
反例：
任务A：实现用户注册
任务B：实现登录，依赖任务A的用户表结构
（如果任务A的用户表结构还没确定，任务B根本没法开始）
正例：
任务0：定义数据库 Schema（用户表、会话表）
任务A：实现用户注册（依赖任务0的 Schema）
任务B：实现用户登录（依赖任务0的 Schema）
（任务0的输出是明确的，A和B都依赖它，但A和B之间互相独立）
标准二：可验证性（Verifiability）
每个子任务完成后，你能立刻验证它是否正确。
不易验证：实现整个认证系统
易验证：
- 实现 hashPassword 函数，输入密码，验证输出不是明文，相同密码每次输出不同
- 实现 verifyPassword 函数，输入密码和哈希值，验证匹配返回 true，不匹配返回 false
标准三：原子性（Atomicity）
每个子任务是最小可独立单元，不能继续拆分为更小的独立单元。
太大：实现用户认证模块（包含多个独立逻辑）
恰好：
- 实现密码哈希工具函数
- 实现 JWT 生成函数
- 实现 JWT 验证函数
- 实现登录接口（组合上面三个）
标准四：清晰边界（Clear Boundary）
每个子任务有明确的输入和输出定义。
模糊边界：实现数据库查询层
清晰边界：
findUserByEmail(email: string): Promise<User | null>createUser(data: CreateUserDto): Promise<User>updateUser(id: string, data: UpdateUserDto): Promise<User>
核心知识点二：三种常用的任务拆解方式
方式一：垂直切片（Vertical Slice）
按功能模块垂直切割，每个切片包含一个功能的完整实现（从数据库到API接口）。
适合场景：功能相对独立的项目
graph LR
A["用户模块\n完整功能"] --> A1["数据库\nSchema"]
A --> A2["Service\n层"]
A --> A3["API\n接口"]
B["商品模块\n完整功能"] --> B1["数据库\nSchema"]
B --> B2["Service\n层"]
B --> B3["API\n接口"]
开发顺序：先完成用户模块的全部（A1→A2→A3），再做商品模块
方式二：水平切片（Horizontal Slice）
按技术层次水平切割，先完成整个系统的某一层，再做下一层。
适合场景：层次关系清晰的项目
graph TD
A["第一阶段：数据库层\n所有 Schema + Migration"] --> B["第二阶段：Service 层\n所有业务逻辑"]
B --> C["第三阶段：API 层\n所有接口"]
C --> D["第四阶段：集成测试"]
方式三：核心优先（Core First）
先做核心路径，再扩展边缘功能。
适合场景：有明确核心业务流程的项目
第一轮：实现最核心的用户注册→登录→查看资料（Happy Path）
第二轮：添加错误处理（错误密码、重复邮箱……）
第三轮：添加高级功能（双因素认证、头像上传……）
第四轮：性能优化和安全加固
深度拆解：迭代式对话的节奏控制
掌握了任务拆解，还需要掌握迭代节奏。
节奏一：先规划，再执行
在正式开始写代码之前，先让 AI 给出完整的实施计划：
在开始写任何代码之前，先告诉我你的实施计划：
- 需要创建哪些文件？
- 每个文件的主要内容是什么？
- 各部分之间的依赖关系是什么？
- 哪些部分可能有风险，需要我特别注意？
确认计划后再开始执行。
为什么这样做：计划阶段发现问题比实现阶段便宜得多。
节奏二：每步验证再继续
第一步：先实现数据库 Schema
（AI 生成 Schema）
（你验证 Schema 是否正确）
确认 Schema 正确后继续第二步...
不要：让 AI 一次性生成所有代码，然后统一调试。
要：每完成一步，验证这步正确了，再告诉 AI 继续。
节奏三：出错时的处理模式
出错时，不要直接说"修一下"，而是提供诊断信息：
第二步的实现有问题：
实际错误：[粘贴错误信息]
我期望的行为：[描述]
实际发生的：[描述]
注意：只修改第二步，不要改变第一步已经完成的 Schema。
节奏四：集成验证
所有步骤完成后，做一次整体验证：
各个模块都已单独实现完毕，现在帮我验证整体集成是否正确：
1. 检查各模块之间的接口是否兼容
2. 检查是否有循环依赖
3. 给我一个端到端的测试步骤，验证完整的功能流程
案例解析：用迭代式提示词构建一个真实功能
任务：为一个博客系统添加文章标签功能
不好的做法（一次性提示词）：
添加文章标签功能，包括：创建标签、删除标签、给文章打标签、
删除文章的标签、按标签搜索文章、标签云显示……
好的做法（迭代式提示词）：
第一轮：数据模型
首先设计标签功能的数据库 Schema：
- 标签表 tags（id, name, slug, createdAt）
- 文章-标签关联表 article_tags（articleId, tagId）
约束：
- 标签名唯一
- slug 自动从 name 生成（如"前端开发"→"qian-duan-kai-fa"）
- 删除文章时级联删除关联关系（但不删除标签本身）
用 Prisma 格式写 Schema，我确认后再继续。
（验证 Schema 正确后）
第二轮：标签基础操作
基于已确认的 Schema，实现标签的基础操作：
- createTag(name: string): Promise<Tag>
- getTagBySlug(slug: string): Promise<Tag | null>
- getAllTags(): Promise<Tag[]>
- deleteTag(id: string): Promise<void>（级联删除关联关系）
把这些实现在 src/services/tag.service.ts
（测试单元后）
第三轮：文章-标签关联
在已有的标签 Service 基础上，添加文章-标签关联的操作：
- addTagsToArticle(articleId: string, tagIds: string[]): Promise<void>
- removeTagsFromArticle(articleId: string, tagIds: string[]): Promise<void>
- getArticleTags(articleId: string): Promise<Tag[]>
- getArticlesByTag(slug: string, page: number): Promise<{articles: Article[], total: number}>
已有的文章 Service 在 src/services/article.service.ts，
不要修改它，只在 tag.service.ts 里添加新方法。
（验证后）
第四轮：API 接口
基于已完成的 Service，实现 REST API：
GET /api/tags - 获取所有标签
POST /api/tags - 创建标签（管理员权限）
DELETE /api/tags/:id - 删除标签（管理员权限）
POST /api/articles/:id/tags - 给文章添加标签
DELETE /api/articles/:id/tags/:tagId - 删除文章的某个标签
GET /api/tags/:slug/articles - 按标签获取文章列表（支持分页）
认证中间件已在 src/middleware/auth.ts，管理员权限用 requireAdmin 中间件
结果对比：迭代式方法完成的代码质量远高于一次性方法，而且每一步都是可验证的。
实操指南：任务拆解工作表
在开始一个新功能之前，填写这个工作表：
## 功能：[功能名称]
### 前置条件
- [ ] 已有什么：[列出已有的相关代码/接口]
- [ ] 需要确认什么：[需要做决策的地方]
### 任务分解
| 步骤 | 任务描述 | 输入 | 输出 | 验证方式 |
|------|---------|------|------|---------|
| 1 | [任务1] | [输入] | [输出] | [如何验证] |
| 2 | [任务2] | [输入] | [输出] | [如何验证] |
| ... | | | | |
### 依赖关系
- 步骤2依赖步骤1的：[具体依赖]
- 步骤3依赖步骤1和2的：[具体依赖]
本讲小结
mindmap
root((迭代式开发))
任务拆解标准
独立性
可验证性
原子性
清晰边界
三种拆解方式
垂直切片-按功能
水平切片-按层次
核心优先-先核心后扩展
迭代节奏
先规划再执行
每步验证再继续
出错提供诊断信息
最后集成验证
关键原则
小步快跑
步步验证
出错不慌-有诊断流程
思考题
-
在你最近的项目中，找一个"一次性提示词失败"的案例。用这一讲的任务拆解方法重新规划，应该分成哪几步？
-
"垂直切片"和"水平切片"各有什么优缺点？在什么情况下你会选择垂直切片，什么情况下选水平切片？
-
迭代式开发有一个代价：每一步都需要验证，时间投入更多。什么情况下值得花这个代价，什么情况下一次性完成更好？
下一讲预告
我们已经掌握了单次提示词的写法和迭代开发的节奏。
还有一个更强大的工具：系统提示词（System Prompt）——给 AI 设定一个在整个项目中始终保持的"工作人格"，让它始终按照你的规范工作。
下一讲，我们来讲如何设计高效的系统提示词。
