我有一个团队，但只有一个是人

现在做自己的产品，实际已经有了一支很小的“团队”。

ChatGPT 和 Claude 更多负责思考：一起讨论产品、研究问题、拆方案、帮我做判断。

Codex 是目前开发的主力，大部分 repo 内的实现由它完成。

Claude Design 负责设计；Claude Code 最近更多负责把 Claude Design 的结果还原进产品。选它做这部分也很实际：两者在同一个 Claude 生态里，设计交接相对顺。

只有我是人。

我的工作也因此发生了一些变化。我越来越少亲自处理具体实现，更多是在决定：这件事交给谁，哪些任务可以一起推进，哪里需要第二个 Agent review，出现冲突时到底该保留哪个版本。

多用几个 AI 很容易。让它们真的像一支团队一样工作，麻烦得多。

Agent 默认不知道其他 Agent 在做什么

人类团队里，即使协作很差，至少大家知道隔壁还有同事。

Agent 不是这样。

Codex 不会天然知道 Claude Code 在另一个工作区里改了什么；Claude Design 读取代码仓库时，也不一定看到电脑上还没有同步进去的变化。

因此，两个 Agent 对同一个问题给出不同答案，不一定是谁能力差。

它们可能根本没有在看同一个版本。

我碰到过最明显的一次，是设计还原过程中，同一套设计规则在不同工作线上继续变化。最后，同一个组件在两份 handoff 文档里留下了两个相反的结论。

这种问题再换一个更聪明的模型也解决不了。

它本质上已经是团队协作问题：版本、分工、依赖和交接。

设计任务比看起来更难并行

这件事在设计工作里尤其明显。

表面上，我可能同时在处理三个完全不同的页面。按产品功能看，它们彼此独立，很适合并行。

但设计的边界并不跟页面边界重合。

三个页面都有可能同时碰到 Button、Select、Dialog、Typography、Spacing、Responsive rules、Design tokens，甚至 global CSS。

所以一个很普通的页面调整，最后可能改变的是一个全局组件。

设计任务的边界，经常和页面边界不是一回事。

这也意味着，判断两个 Agent 能不能同时开工，不能只看“是不是两个不同需求”。

还要看它们是不是在碰同一个共享层。

如果一个 Agent 正在改全局 Button，另一个 Agent 正在重做一个大量使用 Button 的页面，这两个任务从产品结构上看毫无关系，从实现上却高度相关。

这种情况下，硬并行很可能只是把冲突推迟到后面解决。

多开 Chat 不是主要问题，多个“最终版本”才是

同一个需求拆几个 Chat，本身没有什么问题。

我可以在一个 Chat 讨论产品结构，在另一个 Chat 看设计，在第三个地方做代码 review。很多人读取同一份资料，也不会自动制造冲突。

真正需要小心的是：几个地方同时开始维护同一个“最终答案”。

例如，一个 Chat 产出一版 Design Rules，另一个 Chat 又基于旧版本继续修改同一份规则，最后两份内容分别进入代码仓库。

这时候问题已经不是 Chat 数量。

而是同一份共享内容有了多个互不知情的 writer。

所以我现在更在意角色有没有说清楚：

谁负责思考和提出方案，谁真正负责实现，谁负责 review，最后谁来收口。

意见可以很多，最终写入最好不要有很多条互相独立的线。

“唯一的人”现在主要管理三件事

第一件，是 ownership。

一个任务可以经过很多 Agent，但最好有一个明确的 owner，把它从开始带到结束。

现在大部分开发任务最终由 Codex 收口；Claude Design 产出的设计，则更多交给 Claude Code 还原。

第二件，是 shared surface。

两个任务能不能并行，我会看它们有没有同时碰全局组件、设计规则、基础样式或者其他共享层。

页面不同，不代表工作彼此独立。

第三件，是 dependency。

如果任务 B 的判断依赖任务 A 还没完成的修改，那就不应该假装它们是两条互不相干的工作线。

要么等 A 完成，要么明确让 B 基于 A 的结果继续。

这些东西都很像真正团队里的项目管理，只不过对象换成了 Agent。

哪些事情不用管那么细

我不打算因为开始管理多个 Agent，就把 Git 的每一个操作都自己接回来。

branch 怎么同步，worktree 怎么创建，rebase 怎么处理，机械性的 merge conflict 怎么解，Coding Agent 比我熟。

我需要管的是更上一层：

这个任务为什么做；由谁负责；能不能并行；它依赖什么；现在什么算产品事实；出现两个合理答案时谁来做决定。

AI 确实让我一个人可以推进更多事情，但协调工作并没有消失。

只是以前协调的是人，现在协调的对象大部分变成了 Agent。

我现在准备同时开多个 Agent 时，会先确认三个问题：

它们会不会修改同一个共享层？其中一个是否依赖另一个还没完成的结果？每个任务最后到底由谁负责收口？

如果这三件事说不清楚，再多开一个 Agent，未必是在增加产能。