你等 AI 生成、AI 等你确认、你等 AI 修改。单线程的协作,CPU 有 50% 在发呆。
9:00 — 你:帮我写一个用户注册接口
9:03 — AI:这是代码 150 行
9:04 — 你:review,发现少了邮箱验证
9:05 — AI:已补充 30 行
9:06 — 你:review,发现密码没加密
9:07 — AI:已修复 10 行
9:08 — 你:review,确认没问题。下一个:登录接口
9:11 — AI:这是代码 120 行
...
这是一个单线程流水线:你做一步,等 AI;AI 做一步,等你。 中间有大量时间双方都在等待对方。
几个月下来,我总结了一套"批处理"模式,把单线程流水线变成了多任务并行。效率提升不是一个数量级,但体验完全不同。
# ❌ 单件流:一次一件,来回切换
for task in tasks:
ai.generate(task)
you.review()
ai.fix()
you.review()
# 每轮都要等
# ✅ 批处理:把同类操作合并,一次发一批
batch = tasks[:5] # 1. 攒一批
results = ai.generate_batch(batch) # 2. 一次性生成
issues = you.review_batch(results) # 3. 一次性审阅
ai.fix_batch(issues) # 4. 一次性修复关键不在"更快",在"减少上下文切换"。 你从 5 次 review 变成 1 次 review,AI 从 5 次上下文切换变成 1 次连续工作。
适用场景: 同一类型的多个独立任务——加 5 个 API 端点、改 10 个文件的导入路径、给 8 个函数加类型注解。
# ❌ 单件流
你:加一个获取用户列表的端点
AI:[代码]
你:加一个获取用户详情的端点
AI:[代码]
你:加一个更新用户的端点
AI:[代码]
# ✅ 批量
你:加这三个端点:获取用户列表、获取用户详情、更新用户
要求:统一用 Flask 3.x 装饰器注册,统一返回 JSON 格式
[业务规则:列表需要分页、详情需要 404 处理、更新需要权限校验]
AI:[一次性给出三个端点,接口风格统一]关键技巧:一次描述清楚公共约束和个性需求。
# 批量派发的模板
任务清单:
1. [任务 A] - [个性要求]
2. [任务 B] - [个性要求]
3. [任务 C] - [个性要求]
公共约束:
- 所有代码放在 src/api/ 下
- 统一错误处理模式:装饰器 @handle_errors
- 统一返回格式:{"code": 0, "data": ...}不是每个都要单件流。 当任务之间没有依赖关系时,批量派发收益最大。
适用场景: 输出量大的任务——生成 10 首歌的歌词、写 5 个模块的文档、做 8 张表的数据分析。
# ❌ 全过程单件流
for task in tasks:
ai.generate(task) # 生成
you.review() # 验证
ai.fix() # 修复
you.approve() # 确认
# ✅ 分阶段:生成阶段批量,验证阶段批量
# 阶段一:全部生成
all_results = []
for task in tasks:
all_results.append(ai.generate(task))
# 阶段二:全部验证
issues = review_all(all_results)
# 阶段三:批量修复
fixed = ai.fix_all(issues)核心洞察:生成和验证的解耦。 AI 在生成阶段不需要你的 feedback,你在验证阶段不需要等 AI。两个阶段各自独立推进,只在交接点汇总。
实际经历:以前 10 个同类任务要来回 30 轮对话。改成这种模式后,3 轮(生成→反馈→修复)搞定,而且风格一致性比单件流好得多——因为 AI 在生成阶段是连续工作的,不会被你中途的反馈打断它的连贯性。
适用场景: 有关联但不完全串行的任务——前后端同时开发、多个子模块独立开发后集成。
# 依赖图分析
tasks = {
"DB_schema": {"depends": []},
"API_interface": {"depends": ["DB_schema"]},
"frontend_form": {"depends": ["API_interface"]},
"unit_tests": {"depends": ["API_interface"]},
"documentation": {"depends": []} # 可以立刻开始!
}
# 拓扑排序 → 找到可以并行的任务
wave_1 = ["DB_schema", "documentation"] # 无依赖,并行
wave_2 = ["API_interface"] # 等 wave_1 完成
wave_3 = ["frontend_form", "unit_tests"] # 并行很多时候你有一些零依赖的任务可以立刻开始,但你让它们在后面排队。 文档、测试、配置——这些经常不依赖"核心功能先写好"。把它们提前到第一波并行。
批处理不是万能药。三种情况不适合:
# ❌ 不适合批处理
你:帮我设计这个系统的架构
# 你不知道自己要微服务还是单体,不知道选哪个消息队列
# 批量派发 5 个架构方案 = 5 个基于模糊需求的猜测
# ✅ 适合单件流探索
你:这个系统核心是订单处理,给我几个方向性方案
AI:[方案 1-3]
你:方案 2 更合适,展开这个方向探索型任务需要每一步的反馈来修正方向。批处理会放大"方向偏差"。
# ❌ 不适合批处理
你:把项目中所有字符串拼接改成 f-string
# 如果 AI 改错一处,你要从 50 个文件中找出哪处错了
# ✅ 适合分批小批量
你:先把 src/utils/ 改完,我验证,再继续高风险的批量操作要拆小。每批验证通过后再下一批。
# ❌ 不适合批处理
你:实现用户认证系统
# 选 JWT 还是 Session?选哪个密码哈希算法?这些决策影响后续所有代码
# 在核心决策确定之前,批处理是在错误的方向上狂奔
# ✅ 适合先对齐再批量
你:认证方案有几个选择 [列出来],你的建议?
AI:建议 JWT + bcrypt,因为...
你:好,按这个方向实现完整系统先对齐关键决策,再批量执行。 决策错一次,后面全部返工。
接到任务时,先过三问:
def should_batch(task_list):
# 1. 任务之间独立吗?
independent = all(t1.id != t2.depends_on for t1, t2 in pairs)
# 2. 任务类型相同吗?
same_type = len(set(t.task_type for t in task_list)) == 1
# 3. 公共约束明确吗?
constraints_clear = has_explicit_constraints()
if independent and same_type and constraints_clear:
return "批量派发"
elif not independent:
return "分析依赖图,按波次派发"
else:
return "单件流探索,确认方向后转批量"不是技术问题,是工作习惯问题。几个月的协作中,我发现自己最容易回到单件流模式的时候是:
对抗方式很简单:
本文所有示例均已脱敏处理。你是单件流还是批处理派?欢迎评论区聊你的模式。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。