一个人,30个AI员工:岗位、工位、验收标准,全给你拆好了

👋各位好啊，我是AI领航员小陆。最近，OpenClaw 作者 Peter Steinberger 发了一张 Codex 截图。

列表里有三十多个任务，同时在运行。

有的删废弃代码，有的修测试，有的整理依赖，还有的在优化网页。Peter 说，这些任务被分配到了大约五台机器上，截图只是性能最强的一台。

以前一个人写代码，快慢取决于自己一双手。现在几十个任务可以同时往前跑，个人产能的上限变了。

新的问题也跟着来了。

几十个代码任务怎么拆开，同时推进？每个 Agent 长期负责什么，怎样形成稳定分工？两个 Codex 同时改一份代码怎么办？谁检查结果？同一个错误怎么避免反复出现？

如果这五个问题没有答案，Agent 开得越多，人越忙。原本想用 AI 节省时间，最后却成了专门给 AI 收作业的人。

三十多个任务能够同时跑起来，是因为它们背后有一套管理系统。

AI 编程正在把一个人的产能瓶颈，从写代码的速度，推向管理并行任务的能力。

这套系统要解决五件事：长期岗位怎么分，眼前的任务怎么拆，资料放在哪里，几个人怎样避免撞车，谁来检查结果。

Peter 的截图展示的是结果。要让几十个 Agent 同时开工，管理和工程两层都得补上。

管理层解决的是长期协作。谁负责找资料，谁写代码，谁检查；它们去哪里读取背景，犯过的错误又记在哪里。

工程层解决的是这一次怎么开工。一个需求拆成哪些代码任务，每项任务在哪个分支和目录里完成，最后怎样测试和合并。

两层合起来，才是一个人管理几十个 Agent 的完整方法。

团队是什么

先把「AI 团队」说清楚。

多开几个聊天窗口，不算团队。

拿公众号写作举例。

你让第一个 Agent 找资料，让第二个 Agent 写稿，让第三个 Agent 检查。看起来已经有三个人了。

但第一个 Agent 找了什么，第二个不知道。第二个写稿时缺资料，又重新搜索一遍。第三个只收到一篇文章，不知道哪些事实来自哪里，只能泛泛地说「结构清晰、内容完整」。

最后，你仍然要在三个窗口之间复制资料、补背景、检查事实。

人还在中间搬东西。

下面这张图把单个助手和团队的区别画得很清楚。

左边，一个助手什么都做。每次交付都回到人这里检查，产出多少取决于人有多少精力。

右边，每个 Agent 有固定工作。它们在同一个地方看任务、交结果。写完以后先由另一个 Agent 检查，人只处理已经整理好的结果。

一支 AI 团队至少要有四样东西：

少了其中任何一项，团队都会重新退化成几个独立窗口。

怎么分工

分工有两层。

第一层是长期岗位。一名 Agent 不要今天找客户、明天写文章、后天又去对账。工作越混，它越难积累稳定的规则和记忆。

可以把一家小公司的工作分成五类：找客户、做内容、跟进销售、交付服务、整理财务。每类工作安排一个 Agent。

这张图信息很多，我用一个最简单的方式解释。

June 找客户。每天早上扫描指定网站，找出可能合适的客户，写清推荐理由，再起草一封联系邮件。它不能发送邮件，只能交草稿。

Cole 做内容。读取资料，整理选题，起草文章和提案。每个重要事实都要带来源，缺少证据时直接标出来。

Etta 跟进销售。定时检查有没有新回复。没有变化就不说话，有新消息才提醒下一步。涉及报价、合同和法律问题时，交给人处理。

Ray 负责交付。按照客户要求检查交付物。范围、格式、测试结果没有通过，文件就不能往外发。

Penn 整理财务。汇总发票、成本和回款，标记异常。它可以做报告，不能操作付款。

这五个名字不重要。重要的是每个 Agent 长期守住一类工作。

你要抄的是每个岗位后面的四件事：

例如「做内容」太模糊，Agent 不知道做到什么程度才算完成。改成下面这样就清楚了。

每周一读取选题库和资料库。起草本周文章。重要事实附原始链接。不允许编造使用体验。交付文章、图片位置和待确认事实。发布前必须交给审查 Agent。

现在，岗位有了边界，任务也有开始条件和结束条件。

第二层是一次项目里的任务拆分。

例如一名编程 Agent 长期负责产品开发，这是岗位；「修登录」「接支付」「补测试」是这一次要并行执行的三个任务。岗位分工解决谁来做，任务拆分解决这次具体做哪一块。

后面讲 Worktree，处理的就是第二层。

资料放哪

几个 Agent 一起工作，需要看到同一份资料。

可以用 Raft，也可以用 GitHub Issues、项目看板、Slack，甚至一个整理清楚的文件夹。工具叫什么并不重要。重要的是下面这些信息不能只留在聊天记录里：

Raft 的做法很直观。它像一个给人和 Agent 共用的聊天软件。每个任务都有自己的频道，Agent 在本地电脑运行，结果回到同一个频道。

比如，你在频道里写：

每天 9 点检查最近发布的 AI 论文。只汇报昨天没有出现的新内容。先交给 Critic 检查，再把最终简报发回这个频道。

之后不需要每天重新发一次命令。时间到了，Agent 自己运行。没有新内容，它就保持安静。

这类定时任务在很多 Agent 系统里叫「心跳」。名字听着复杂，实际就是闹钟。到了指定时间，Agent 醒来，看一眼任务，做完以后把结果放回原处。

Agent 还需要记住以前定下的规则。每次启动时，让它读取一组固定文件。这组文件不用复杂，三份就够。

岗位说明。写清负责什么、禁止什么、交付什么。

长期记忆。记录反复有效的经验。例如哪些网站可信、哪些写法总被退回、哪些文件不能修改。

当前任务。只放这一次工作需要的资料和进度。任务结束后归档，不要一直塞进长期记忆。

下面是一份可以直接改的岗位说明。

# June，客户线索负责从指定网站寻找潜在客户，给出筛选理由，起草联系邮件。每天交付客户名单、来源链接、推荐理由、邮件草稿。禁止不能发送邮件。不能编造客户信息。不能决定报价。遇到这些情况找人客户已经回复。涉及价格、合同或法律问题。来源过期或无法确认。完成标准每位客户都有来源、理由和草稿。

长期记忆也不要一直变长。文件太长，Agent 每次都要花时间重新阅读，旧规则还可能和新规则冲突。经验超过一页，就压缩一次。已经失效的内容直接删除。AI 的记忆不是仓库，更像一本随时要翻的工作手册。

代码怎么分

前面的长期分工和共享资料，解决了谁负责什么、去哪里取资料。到了具体项目，还要把一个需求拆成可以同时执行的代码任务。拆完以后，几个 Agent 也不能挤在同一个目录里干活。

假设 Agent A 正在重构登录模块，改到一半还没提交。Agent B 又在同一个目录切换到支付分支。Git 会要求先处理 A 留下的改动，B 可能选择暂存，也可能误删，两个任务从这一刻就缠在了一起。

人类程序员串行工作时，经常靠  git stash  、切分支、再恢复现场。一个人慢慢切还能应付，几个 Agent 同时开工，这套做法就不够用了。

Worktree 的作用，是把同一个 Git 仓库铺成几个独立目录。分支记录的是一条代码路线，Worktree 提供的是一个可以真实打开、编辑、运行测试的目录。登录任务在  app-fix-login  ，支付任务在  app-payment  ，补测试在  app-tests  。三个目录共享同一个仓库的提交历史，不需要把整个项目重新克隆三遍；各自没有提交的文件改动，也不会跑到别人的目录里。

对多 Agent 来说，这相当于给每个任务发了一张门禁卡。它只能进入自己的目录，看到自己的改动，运行自己的测试。

最稳妥的分法是：

一个任务，一个分支，一个 Worktree，一个验收标准。

假设现在要同时修登录、接支付、补测试，先从  main  建三个现场：

git worktree add -b fix-login ../app-fix-login maingit worktree add -b feature-payment ../app-payment maingit worktree add -b test-hardening ../app-tests main

命令执行后，原项目旁边会多出三个目录。每个目录已经检出自己的分支，可以分别交给三个 Agent。

app-fix-login 只修登录app-payment 只接支付app-tests 只补测试

目录隔开了，任务边界也要跟着隔开。给支付 Agent 的指令可以这样写：

在 app-payment 目录接入支付。禁止修改登录模块。完成后运行测试。返回改动文件、测试结果和仍未解决的问题。

这里的「禁止修改登录模块」很重要。Worktree 隔开的是文件现场，隔不开代码之间的依赖。支付任务和登录任务都去改同一个公共配置，最后合并时仍然可能冲突。真正适合并行的任务，要么修改范围不同，要么接口已经约定清楚。

每个 Agent 做完后，先在自己的目录运行测试，再提交代码，并返回三样东西：改了哪些文件、测试是否通过、还有哪些问题没有解决。人或审查 Agent 看完 diff，确认后再合并到主分支。

任务结束，现场也可以清掉：

git worktree listgit worktree remove ../app-fix-logingit worktree prune

有一个坑需要单独说。Git 默认不允许同一个分支同时被多个 Worktree 检出。因此，不能直接把同一条分支同时挂到五个目录。即使使用  --force  绕过保护，几个 Agent 的提交和文件状态也很难追踪。

更省心的做法，是给每个并行子任务建立独立分支。例如五个 Agent 同时接五家支付渠道，就建立五条 provider 分支，各配一个 Worktree，完成后再合并进支付功能的集成分支。

Worktree 也不是开得越多越好。改一句文案、修一个拼写错误，直接在当前目录完成就行。一个大任务只能串行推进，单独开分支也够用。只有当几项工作可以同时进行，而且修改范围能够分开时，Worktree 才能把等待时间真正省下来。

它解决的只是「别在同一个现场互相踩文件」。代码有没有写对，几个分支合起来能不能运行，还需要下一道检查。

谁来检查

不要让写作者检查自己的工作。这个规则适用于代码，也适用于文章。

一个 Agent 刚写完文章，你再问它「这篇文章有没有 AI 味」，它很容易沿着自己的写作思路，证明文章没有问题。检查工作应该交给另一个 Agent，而且任务要具体。

例如，June 交了一批客户名单，可以这样检查：

检查 June 提交的客户名单。逐条确认客户是否符合目标范围推荐理由是否具体来源链接是否有效邮件里是否包含没有依据的判断发现问题，写明原因并退回。全部通过，只回复批准和数量。

审查 Agent 找到问题以后，退回原因要保存下来。如果连续两次出现「来源过期」，就在 June 的岗位说明里加一条：抓取后必须检查发布日期。如果连续两次出现「邮件理由太空」，就把一封通过审查的邮件放进示例。

这样跑一段时间以后，Agent 会越来越符合你的要求。所谓「自我改进」，没有那么神秘。就是每次犯错都留下原因，再把反复出现的原因写进规则。

但邮件发送、付款、代码上线、客户交付，仍然由人确认。Agent 可以准备结果，不能替你承担后果。

普通人怎么开始

最后给一套最小启动方法。不要第一天就创建五个 Agent。先选一件每周都会做、结果容易检查的工作。例如整理线索、生成周报、补测试、核对账单。

第 1 天创建一个执行 Agent，写好岗位说明、禁止事项和完成标准。

第 2 天创建一个审查 Agent，只检查最容易出错的三四项。

第 3 到 7 天每天运行一次。记录哪里出错、为什么出错、需要增加哪条规则。

第 2 周第一项工作已经能稳定交付，再增加第二个岗位。

刚开始可能比自己做更慢。原因很简单。很多判断以前只在你的脑子里，现在必须写成 Agent 能读懂的规则。

等这些规则逐渐稳定，你收到的就不再是一份未经检查的原始结果。它已经被执行过、检查过，问题和证据也被整理好了。

回到 Peter 那张截图。三十多个 Codex 之所以能够同时工作，是因为每个任务都有分工、有资料、有独立目录，也有人负责检查。数量当然重要。能把数量变成有效产出，才是 Peter 这张截图真正厉害的地方。

先把一个执行 Agent 和一个审查 Agent 跑通。这比第一天打开三十个窗口有用得多。

如果现在只选一件工作交给 Agent，你会选什么？

⭐️有用就点个赞吧～也别忘了转给你那个想招AI员工却不知道怎么开始的朋友～