Codex

最开始，我只是想把几个并行任务分开。 一个负责找方向，一个盯产品，一个审代码，再找一个专门挑错。这样一来，我不用在一个超长对话里反复切换上下文，每个任务也能有自己的责任人。 后来有一天，我看着 Codex 侧边栏，发现里面已经有了 COO、产品负责人、技术负责人、发布验证工程师和内容秘书。再往下翻，还有一批临时研究员、接任者和组长。 我干脆给这套东西起了个名字：Aimake / 爱创，一家虚拟 AI 公司。 这是缩编之后的团队。截图是我真实使用的 Codex 项目列表，不是为了文章补画的组织图。 听起来有点像角色扮演，但真正做起来以后，它更接近一次小型的组织实验：我既是投资人，也是 CEO；AI COO 负责派单和收口；下面的人各自做产品、技术、验证、研究和内容。 实验做了一阵，我得出的第一个结论并不浪漫：启动 Agent 很容易，管理 Agent 很难。 我为什么要把任务变成“岗位” 只开一两个 Codex 任务时，管理基本不是问题。我自己记得每个窗口在干什么，也知道哪段结论值得信。 一旦任务变多，情况就变了。 每个 Agent 都能写计划、搜资料、跑测试，也都很擅长交出一份看起来很完整的报告。但报告多，并不代表事情更清楚。我开始反复遇到三个问题： 大家研究的是不是同一件事？ 它说“完成了”，到底完成到哪一层？ 哪些动作可以自己做，哪些必须停下来等我？ 所以我没有继续靠聊天记忆维持秩序，而是给任务加上了岗位、汇报线和验收人。 每次派单尽量写成一张很短的合同： 1 2 3 4 5 6 7 目标：这次只解决什么？ 交付：结束时必须留下什么？ 事实源：以哪些代码、文档或运行结果为准？ 完成门：满足什么才算完成？ 停止门：出现什么情况立刻 Hold？ 接收人：谁来复核和采用？ 外部权限：哪些动作必须等我批准？ 这比“认真调研一下，给我一个完整方案”有用得多。后者很容易得到一篇漂亮长文，前者才有机会得到一个能被下一位接住的结果。 然后我还是扩编过头了 这次集中冲刺里，我想同时看清产品方向、用户证据、技术架构、开源交付、安全风险和内容增长，于是短时间拉起了数十个任务。 一开始感觉非常好。屏幕上到处都在动，每隔几分钟就有新发现。不同角色从不同角度挑问题，很多盲点确实比我一个人顺序做更早暴露。 但热闹持续了一会儿，代价就出来了。 有人在重复研究同一个问题；同一款产品收到几份彼此冲突的优先级建议；上一份报告还没写完，接任它的任务已经开始；自动测试通过、真实环境可用和用户愿意复用，被几份汇报写成了差不多的“完成”。 最尴尬的是，每个 Agent 都能证明自己做了很多，却没人能证明公司应该因此改变哪个决定。 峰值时，我设置了五个临时组长，让他们吸收大约二十五个成员任务。等真正开始汇总，完整交付并被采用的只是一小部分。其余内容有的重复，有的只是阶段记录，有的结论已经被后来的验证推翻。 那一刻我才承认：我扩大的不是产能，至少不全是。很大一部分只是管理复杂度。 收工不是一句“停”，而是一场交接 我没有马上把所有任务关掉，也没有让旧岗位突然消失。 先冻结新增范围，让每个人把眼前能够安全收口的工作做完；再留下有效事实、失败记录、未知项、恢复路径和下一道门槛；接收人能够复述并独立继续之后，旧任务才归档。 ...