AI 编程工作流：上下文、任务拆分与代码审查

AI 编程不是"把需求丢进去，代码自己就写好了"。真实项目里，你需要管理上下文、拆分任务、审查代码、控制变更范围。这篇文章把我在项目中总结的 AI 编程工作流整理出来。

完整工作流

需求分析 → 任务拆分 → 上下文准备 → AI 实现 → 代码审查 → 测试验证 → 提交上线

每个环节都很重要，跳过任何一步都可能出问题。

第一步：需求分析

在让 AI 写代码之前，先自己想清楚：

问自己三个问题

1. 要做什么：功能的边界是什么？
2. 怎么做：技术方案是什么？
3. 不能做什么：有哪些约束和限制？

# 让 Claude 帮你梳理需求
claude "我要给用户列表加分页功能，帮我梳理一下需求：
1. 需要考虑哪些场景？
2. 前后端分别需要改什么？
3. 有什么边界情况需要处理？"

第二步：任务拆分

大任务拆成小任务，每个小任务独立可验证。

拆分原则

原则	说明
独立性	每个任务独立完成，不依赖其他未完成的任务
可验证	每个任务完成后都能验证是否正确
小粒度	每个任务改 1-3 个文件，不超过 100 行代码

拆分示例

需求：用户列表加分页

任务 1：后端接口支持分页参数
  - 修改 UserMapper.xml 的查询语句
  - 修改 UserService 的分页逻辑
  - 修改 UserController 的参数接收

任务 2：前端分页组件
  - 创建 Pagination 组件
  - 在用户列表页引入组件

任务 3：前后端联调
  - 调用接口测试分页
  - 处理异常情况

任务 4：测试和优化
  - 添加单元测试
  - 优化加载速度

第三步：上下文准备

给 AI 提供必要的上下文，让它理解任务背景。

上下文清单

✅ 相关代码文件（当前要改的 + 相关的）
✅ 接口文档（如果有）
✅ 数据库表结构（如果涉及数据库）
✅ 相关的工具函数（如果要复用）
✅ 错误信息（如果有报错）
❌ 不相关的代码
❌ 敏感信息（密码、密钥）
❌ 过多的历史对话

实际操作

# 不好的做法：把所有文件都给 Claude
cat src/**/*.js | claude "加分页"

# 好的做法：只给相关的
claude "给用户列表加分页，相关文件：
- src/views/user/list.vue（列表页）
- src/api/user.js（API 请求）
- src/components/Pagination.vue（分页组件，已有）

接口返回格式：
{
  code: 200,
  data: {
    list: [...],
    total: 100,
    page: 1,
    size: 20
  }
}"

第四步：AI 实现

让 AI 先说再做

# 不好的做法：直接让 AI 改代码
claude "修改用户列表页，加上分页"

# 好的做法：先让 AI 说方案
claude "用户列表页要加后端分页，先说说你打算怎么改？确认后再动手"

控制变更范围

# 明确告诉 AI 只改哪些文件
claude "只修改以下文件：
1. src/views/user/list.vue - 添加分页组件和请求逻辑
2. src/api/user.js - 修改 getList 方法添加分页参数

不要修改其他文件"

分步验证

# 每完成一步就验证
claude "先修改 src/api/user.js 的 getList 方法，添加 page 和 size 参数"

# 验证无误后继续
claude "再修改 src/views/user/list.vue，引入分页组件"

第五步：代码审查

AI 写的代码必须过审，不能盲目信任。

审查清单

功能正确性

• [ ] 代码是否实现了需求？
• [ ] 边界情况是否处理？（空值、空列表、超长输入）
• [ ] 异常情况是否处理？（网络错误、权限不足）

安全性

• [ ] 用户输入是否校验？
• [ ] SQL 注入风险？
• [ ] XSS 风险？
• [ ] 敏感信息是否泄露？

性能

• [ ] 有没有不必要的循环？
• [ ] 有没有重复查询？
• [ ] 大数据量是否分页？

可维护性

• [ ] 命名是否清晰？
• [ ] 逻辑是否易懂？
• [ ] 有没有重复代码？

使用 Claude 辅助审查

# 审查当前改动
git diff | claude "审查这些改动，重点关注：
1. 安全性：有没有注入风险？
2. 性能：有没有可以优化的地方？
3. 边界情况：空值处理是否完善？"

# 审查特定文件
cat src/api/user.js | claude "审查这个文件的错误处理是否完善"

第六步：测试验证

单元测试

# 让 AI 生成测试
claude "为 src/utils/pagination.js 生成单元测试，覆盖以下场景：
1. 正常分页
2. 页码为 0 或负数
3. 每页条数为 0
4. 总数为 0"

手动测试

✅ 正常流程：能分页、能切换页码
✅ 边界情况：第一页点上一页、最后一页点下一页
✅ 异常情况：网络断开、接口报错
✅ 性能：大数据量是否流畅

第七步：提交上线

提交规范

# 小步提交，每个 commit 都是独立可回滚的
git add src/api/user.js
git commit -m "feat(user): 添加用户列表分页参数"

git add src/views/user/list.vue
git commit -m "feat(user): 用户列表添加分页组件"

git add src/components/Pagination.vue src/utils/pagination.js
git commit -m "feat(pagination): 新增分页组件和工具函数"

提交信息格式

类型(范围): 简短描述

类型：
- feat: 新功能
- fix: 修复 bug
- refactor: 重构
- test: 测试
- docs: 文档

回滚策略

Git 回滚

# 回滚最近一次提交
git reset --hard HEAD~1

# 回滚到指定提交
git reset --hard <commit-hash>

# 回滚已推送的提交（谨慎使用）
git revert <commit-hash>
git push

分支策略

# 功能开发在分支上
git checkout -b feat/user-pagination

# 完成后合并到主分支
git checkout main
git merge feat/user-pagination

# 出问题时回滚合并
git revert -m 1 <merge-commit-hash>

常见问题

AI 改动太大

claude "只修改 src/api/user.js 这一个文件，不要动其他文件。如果需要改其他文件，先告诉我，我确认后再改"

AI 理解错了需求

# 先让 AI 说方案
claude "先描述一下你打算怎么改，包括会修改哪些文件、每个文件改什么。我确认后再动手"

AI 生成的代码有 bug

# 提供错误信息
cat error.log | claude "这段代码报错了，错误信息如下：xxx。帮我定位问题并修复"

上下文不够

# 补充上下文
claude "补充一下背景：这个项目的用户表结构是 xxx，之前已经有一个不分页的查询接口"

效率对比

场景	纯手写	AI 辅助	效率提升
写 CRUD	2小时	30分钟	4x
写测试	1小时	15分钟	4x
代码审查	30分钟	10分钟	3x
排查 bug	1小时	20分钟	3x
重构	3小时	1小时	3x

注意：这是建立在正确使用 AI 的前提下。如果上下文管理不好、任务拆分不合理，效率可能反而下降。

小结

• AI 编程是一个完整的工作流，不是一步到位
• 上下文管理是关键：只给相关的，不给多余的
• 大任务拆成小任务，每步都验证
• AI 写的代码必须过审，不能盲目信任
• Git 是安全网，小步提交，方便回滚