同时开 3 个 AI Agent 后，我开始重新安排自己的工作
type
status
date
slug
summary
tags
category
icon
password
wechat_gate
10 月的一段时间，我经常同时开两三个 AI Agent，让它们分别处理不同项目。
这里的 Agent，可以简单理解为能读材料、调用工具、执行任务的 AI 助手。在我的使用场景里，主要是 Codex、Claude Code 里的独立工作会话。
这种做法带来的感受很直接：我检查一个项目时，另一个项目仍在推进。原来串着做的部分工作，可以同时发生。
当时我甚至在日记里写过“一天像干了三天的活”。现在回看，这是一种兴奋时的主观感受。我没有做严格计时，也没有统计返工，不能把它当成三倍效率的测量结果。
真正值得留下的经验，是我开始重新安排自己的角色：哪些任务可以交出去，什么时候需要我做决定，怎样确认交回来的结果真的可用。
并行的前提：任务能各自推进
我试得比较顺的一种情况，是不同 Agent 分别处理不同项目。它们各自有材料、有目标，也不需要同时修改同一份文件。
如果两个任务存在先后关系，硬拆开通常会增加等待。例如，产品需求还没确定，就让另一个会话开始实现，后面很可能要重做。
所以，在打开更多窗口前，我准备先判断三件事：
- 这个任务需要的输入是否已经齐全？
- 它能不能在不等另一个任务的情况下推进？
- 交付以后，我有没有明确办法检查它？
三项都说得清，再考虑并行。
同一个代码项目还需要处理文件冲突。不同聊天窗口，并不自动意味着不同工作目录。可以使用独立的代码工作副本；需要合并时，再检查各自改了什么。Git worktree 就是一种创建独立工作目录的方式，具体使用时还要准备依赖和环境配置。
Claude Code 的官方实践也建议，并行会话使用各自的工作副本，并给任务提供能执行的检查。这两点分别解决“改动互相碰撞”和“做完以后无法判断对错”的问题。参考：Claude Code Best Practices
我能同时照看的任务，也有上限
10 月 11 日，我原本想跑三个项目。但其中的 Computer Use，也就是 AI 操作电脑界面的任务，会占用屏幕，结果只开了两个。
还有一天晚上，我因为环境和精力，把三个并行任务减成了两个。
这些经历提醒我，窗口数量本身没有价值。多个任务一起结束时，我需要读结果、做决定、验证行为。如果这一环节来不及处理，工作就只是堆到了我面前。
人的注意力也需要切换。美国心理学会介绍的任务切换研究表明，切换会带来时间成本，复杂或不熟悉的任务尤其如此。这个结论不能直接换算成我的开发效率，但足以提醒我：AI 可以并行执行，我仍需要安排连续的检查时间。延伸阅读：Multitasking: Switching Costs
我接下来更愿意观察的是：一天有多少结果通过了检查，有多少结果需要返工，以及自己是否还清楚每个项目的状态。
把任务写到能够验收
“帮我优化一下”容易开始，也容易没有终点。下面是一份我根据这段经历整理的任务说明，适合在启动会话前补齐：
目标：这次具体改善哪一个用户问题。范围：允许修改哪些部分；哪些内容需要另行讨论。输入：相关文件、现有行为、设计稿或问题记录。交付：修改结果，以及检查时需要看的材料。验收：运行哪些检查；由谁复查真实使用流程。停止条件：出现哪些不确定性时，先报告，再继续。
例如，让 AI 优化订阅页，就需要说明用户应当看懂哪些权益和价格，哪些购买逻辑不能擅自调整，完成后怎样核对不同语言和显示模式。
这种写法会多花一点交代任务的时间，但能减少它朝错误方向跑很远的机会。对于没有现成自动检查的视觉工作，也要留下前后截图或明确的人工复核路径。
“已生成”“检查通过”“人工验收”“已上线”，应该分别记录。 一句“完成了”，装不下这些差别。
夜间任务也要留下边界
我还尝试过让 AI 在夜间继续处理项目。它确实给了我一种新的时间安排可能：白天被家务和照顾孩子打断，部分准备工作仍能推进。
但这也容易让人过度乐观。第二天打开电脑，如果只看到大量改动，却不知道依据、验证和未完成项，就很难放心接手。
因此，我准备优先把资料整理、方案草拟、独立分支里的初步实现等可复核任务放到夜间。涉及生产环境、付费操作和数据删除的动作，需要单独授权和检查；拿不准的地方应当停下来记录。
夜间结束时，也要留一份简短交接：做了什么、检查了什么、哪里没通过、需要我决定什么。
我对 AI 并行协作仍然很有期待。只是衡量它的标准，应该落在可用的交付上。额度花了多少、窗口开了几个，都只能说明投入，不能替代结果。
参考资料
关注沐风，不定期更新，全是干货。
2026.11.04 23:40
沪 · 赵巷