为什么需要工作流
很多人使用 AI 编程助手的方式是：直接输入需求，然后接受或拒绝 AI 的修改。这种方式对于简单任务没问题，但面对复杂需求时，往往会遇到：
- AI 理解偏差，修改方向错误
- 一次性修改太多文件，难以审查
- 发现问题后难以回退
- 缺乏上下文，AI 做出不合适的假设
Plan-Build-Review 工作流通过分阶段协作，解决这些问题。
三阶段工作流
阶段一：Plan（规划）
在 Plan 模式下，AI 只分析和规划，不实际修改文件。使用 Shift+Tab 切换到 Plan 模式：
> 我需要给这个 API 添加分页功能
[Plan 模式]
好的，我来分析一下：
1. 当前状态：
- 发现 src/api/users.ts 中有 getUsers 函数
- 当前返回所有用户，没有分页
2. 建议方案：
- 修改 getUsers 接受 page 和 pageSize 参数
- 使用 SQL OFFSET/LIMIT 实现分页
- 返回 { data, total, page, pageSize } 格式
3. 需要修改的文件：
- src/api/users.ts
- src/types/api.ts（添加分页类型）
是否继续？在这个阶段，你可以：
- 审查 AI 的理解是否正确
- 讨论方案的优劣
- 补充遗漏的上下文
- 迭代调整方案
阶段二：Build（构建）
确认方案后，切换回 Build 模式（Shift+Tab），让 AI 执行修改：
> 方案没问题，开始实施
[Build 模式]
正在修改文件...
✓ src/types/api.ts - 添加 PaginationResult 类型
✓ src/api/users.ts - 实现分页逻辑
修改完成。共修改 2 个文件。阶段三：Review（审查）
审查 AI 的修改：
- 使用
git diff查看变更 - 运行测试确认功能正常
- 检查代码质量
如果发现问题，使用 /undo 回退：
> /undo
已撤销上一次修改。然后回到 Plan 模式重新讨论方案。
实用操作技巧
@ 引用文件
使用 @ 可以引用特定文件，帮助 AI 理解上下文：
> @src/database/schema.ts 帮我写一个查询，获取这个表中的活跃用户! 执行命令
使用 ! 前缀可以直接执行命令：
> !npm test
运行测试...
✓ 15 tests passed多轮迭代
不要期望一次就完美。通过多轮对话迭代改进：
> 这个函数的错误处理不够完善
[AI 改进错误处理]
> 还需要添加日志
[AI 添加日志]
> 很好，现在帮我写单元测试
[AI 编写测试]最佳实践
- 小步快跑：每次只处理一个小任务，避免一次性修改太多
- 明确上下文：提供足够的背景信息，减少 AI 的猜测
- 及时审查：每次修改后立即审查，不要积累太多变更
- 善用回退：发现问题立即
/undo，不要硬着头皮继续 - 保持对话：在一个会话中完成相关任务，保持上下文连贯
工作流示例
以下是一个完整的工作流示例：
# 1. 进入项目
cd my-project
opencode
# 2. Plan 模式：分析需求
[Shift+Tab 切换到 Plan]
> 我需要给这个 Express 应用添加 JWT 认证
# 3. 讨论方案
> 我倾向于使用 express-jwt 中间件
> 数据库用 PostgreSQL
# 4. Build 模式：执行修改
[Shift+Tab 切换回 Build]
> 方案确认，开始实施
# 5. Review：审查修改
!git diff
!npm test
# 6. 如有问题，回退重来
> /undo
> 我们换个方案...总结
Plan-Build-Review 工作流的核心是：先理解，再行动，后验证。通过这种方式，你可以更好地控制 AI 的行为，获得更高质量的代码。