一个负责找方向，一个盯产品，一个审代码，再找一个专门挑错。这样一来，我不用在一个超长对话里反复切换上下文，每个任务也能有自己的责任人。

后来有一天，我看着 Codex 侧边栏，发现里面已经有了 COO、产品负责人、技术负责人、发布验证工程师和内容秘书。再往下翻，还有一批临时研究员、接任者和组长。

我干脆给这套东西起了个名字：Aimake / 爱创，一家虚拟 AI 公司。

这是缩编之后的团队。截图是我真实使用的 Codex 项目列表，不是为了文章补画的组织图。

听起来有点像角色扮演，但真正做起来以后，它更接近一次小型的组织实验：我既是投资人，也是 CEO；AI COO 负责派单和收口；下面的人各自做产品、技术、验证、研究和内容。

实验做了一阵，我得出的第一个结论并不浪漫：启动 Agent 很容易，管理 Agent 很难。

我为什么要把任务变成“岗位”

只开一两个 Codex 任务时，管理基本不是问题。我自己记得每个窗口在干什么，也知道哪段结论值得信。

一旦任务变多，情况就变了。

每个 Agent 都能写计划、搜资料、跑测试，也都很擅长交出一份看起来很完整的报告。但报告多，并不代表事情更清楚。我开始反复遇到三个问题：

1. 大家研究的是不是同一件事？
2. 它说“完成了”，到底完成到哪一层？
3. 哪些动作可以自己做，哪些必须停下来等我？

所以我没有继续靠聊天记忆维持秩序，而是给任务加上了岗位、汇报线和验收人。

每次派单尽量写成一张很短的合同：

1
2
3
4
5
6
7

目标：这次只解决什么？
交付：结束时必须留下什么？
事实源：以哪些代码、文档或运行结果为准？
完成门：满足什么才算完成？
停止门：出现什么情况立刻 Hold？
接收人：谁来复核和采用？
外部权限：哪些动作必须等我批准？

这比“认真调研一下，给我一个完整方案”有用得多。后者很容易得到一篇漂亮长文，前者才有机会得到一个能被下一位接住的结果。

然后我还是扩编过头了

这次集中冲刺里，我想同时看清产品方向、用户证据、技术架构、开源交付、安全风险和内容增长，于是短时间拉起了数十个任务。

一开始感觉非常好。屏幕上到处都在动，每隔几分钟就有新发现。不同角色从不同角度挑问题，很多盲点确实比我一个人顺序做更早暴露。

但热闹持续了一会儿，代价就出来了。

有人在重复研究同一个问题；同一款产品收到几份彼此冲突的优先级建议；上一份报告还没写完，接任它的任务已经开始；自动测试通过、真实环境可用和用户愿意复用，被几份汇报写成了差不多的“完成”。

最尴尬的是，每个 Agent 都能证明自己做了很多，却没人能证明公司应该因此改变哪个决定。

峰值时，我设置了五个临时组长，让他们吸收大约二十五个成员任务。等真正开始汇总，完整交付并被采用的只是一小部分。其余内容有的重复，有的只是阶段记录，有的结论已经被后来的验证推翻。

那一刻我才承认：我扩大的不是产能，至少不全是。很大一部分只是管理复杂度。

收工不是一句“停”，而是一场交接

我没有马上把所有任务关掉，也没有让旧岗位突然消失。

先冻结新增范围，让每个人把眼前能够安全收口的工作做完；再留下有效事实、失败记录、未知项、恢复路径和下一道门槛；接收人能够复述并独立继续之后，旧任务才归档。

最后一共归档了三十一个临时或已经被替代的任务，团队缩回八个岗位：一名 COO，四个产品与战略岗位，两个技术、安全与交付岗位，再加一个 COO 办公室岗位。

这个过程让我改掉了一个说法。我现在不太说“开除 Agent”，更愿意说“归档岗位”。AI 会话当然可以重新打开，但组织里的事实不能靠某一段聊天记录碰运气。

如果一个旧任务里有唯一的测试、尚未转交的代码或一条没人复述过的风险，它就还没到能关的时候。

我开始对“完成”分级

这次最有用的改动，是给证据分层：

这样一来，很多争论会自然消失。

代码写完不等于产品可用；测试通过不等于已经发布；页面返回 200 不等于业务正确；Star、访问量和版本号也不能替代用户价值。

员工只提交事实、推断和待验证项。组长负责处理冲突。最后由 COO 给出 Continue、Hold 或 Stop。任何人都不能把下一层证据提前“脑补”出来。

Agent 不需要为了显得忙而制造工作

我以前只限制产品主线，没有限制围绕主线出现的调研、复核和支援任务。于是看板上好像只有几件大事，背后却同时跑着几十个小任务。

现在的规则简单很多：最多一条 P0 保护面、两条 P1 增长线；临时研究限制并发；同一个问题通常只设一个 Owner、一个反方和一个 Reviewer。

模型也不再全员长期拉满。边界清楚的盘点、清单和重复验证用中档推理；真正需要跨产品取舍、证据冲突裁决和最终验收时，再把高推理档留给负责人。

高算力应该放在决策瓶颈，而不是平均撒在每一件小事上。这和真实公司用人其实很像：不是每封邮件都需要管理层开会。

还有一条边界我刻意保留给自己。发帖、联系用户、推送、合并、生产部署、Release、付费、域名和仓库可见性变化，都不能因为某个 Agent 写了“建议执行”就自动发生。

“准备好了”不等于“已经获准”。沉默也不等于批准。

这次我做对了什么，也做错了什么

我做对的，是在事情变重以后停了下来；没有因为已经花了很多时间和算力，就继续保留重复岗位；也没有在清理临时环境前，随手删掉可能还装着唯一代码证据的目录。

做错的也很清楚：先扩编，后设计组织；太早把最高推理档当成动员方式；组长出现得太晚；第一次复盘写得太轻，没有立刻说清每个人究竟交付了什么，哪些被采用，哪些其实没有完成。

如果再来一次，我会先冻结一个目标、一道完成门和一条外部边界。第一波最多四个临时角色。十五分钟做一次中检，发现重复就停。汇总前再专门做一次证据降级审计。

最重要的是，不会再为了让侧边栏看起来“全员开工”，凭空制造岗位。

这次经历让我真正理解了一件事：管理一支 AI 团队的核心，不是让更多 Agent 同时说话，而是减少未经验证的“完成”。

组织图可以很漂亮，名字也可以起得很有文化。但最后真正有用的，还是几个朴素的问题：谁负责？证据在哪？谁来验收？出了问题能不能退回来？

如果你也同时开着很多 Codex 任务，可以先别急着再招一个 Agent。看看侧边栏，然后问一句：

今天，究竟谁有权宣布这件事真的完成了？