别管 AI 能不能写代码了,你管理任务的方式才是问题

OpenAI 发了一篇博客，叫 Symphony。看完之后，我有一个感觉：我们一直在问错问题。

过去两年，大家聊 AI 编程，核心问题总是：AI 到底能不能写出好代码？能写多少？能不能替代我？OpenAI 这篇博客给了一个完全不同的视角——他们早就过了「AI 能不能写代码」这个阶段了。他们的瓶颈变成了另一件事：一个人最多同时盯 3 到 5 个 AI 编程会话，再多脑子就转不过来了。

想想这个画面：你开着一堆终端窗口，每个里面跑着一个 AI agent，你跳来跳去，看这个做完了没，那个卡住了没，还要时不时提醒一下方向对不对。

这不就是你带了五个实习生，然后自己被他们累死了吗。

当每个 AI agent 都需要你亲自盯着的时候，人就变成了自己的瓶颈

他们做了一件反直觉的事

OpenAI 内部有个团队，半年前做了一个决定：一个项目，一行人写的代码都不要。全让 Codex 生成。

这事本身不新鲜了。新鲜的是接下来——他们发现 agent 写得够快了，人跟不过来了。

然后他们做了一个关键的转身。

他们意识到，自己一直在优化错误的东西。整个系统围绕着「coding session」和「merged PR」在转——但这两个东西只是手段，不是目的。软件工程真正围绕的是 deliverables：issue、task、ticket。

所以他们问了自己一个问题：如果我不再直接监督 agent，而是让 agent 自己从任务看板里领活干呢？

这就是 Symphony。不是一个新的 AI 工具，而是一个调度器。它把 Linear（一个项目管理工具）变成了 AI agent 的控制平面。每个 open issue 自动分配一个 agent，agent 跑着，人在旁边 review 结果就行。

结果是什么？有些团队的 PR 数量增长了 500%。

从「人盯着 AI 干活」到「AI 自动从任务板领活」的转变

真正值得注意的不是 500%

500% 很扎眼。但我觉得这不是这篇文章最重要的信息。

重要的是他们描述的一个行为变化：当工程师不再需要盯着 agent 干活的时候，他们对每一次代码改动的「心理成本」彻底变了。

以前，让 AI 改一个功能，你得开 session、描述需求、中途纠正、review 结果——一套下来半小时。所以你会犹豫：这事值不值得现在做？

现在，往 Linear 里丢一个 issue，agent 自动领走，你该干嘛干嘛。做出来你看一眼，好就合，不好就关。心理成本从半小时降到一分钟。

这个变化带来的结果不是「产出变多」，而是「探索变多」。

他们开始做以前不会做的事：抛一个想法让 agent 先试试水、做一个重构看看效果、验证一个假设。做了不满意就扔掉，成本几乎为零。

这不是效率提升。这是工作方式变了。

更深的层：我们还没有学会「派活」

看到这里我有一个直觉：Symphony 暴露了一个大多数人还没意识到的 gap。

我们现在用 AI 编程的方式，本质上还是在「自己做」——只不过旁边多了一个帮手。你开一个会话，你说它做，你 review。这跟 pair programming 没有本质区别，只是你换了一个更快的搭档。

但当你有 10 个、20 个、50 个活要干的时候，pair programming 的模式就撑不住了。

你需要的是派活的能力。

这不是技术能力，是一种思维方式。派活意味着：你能把一个模糊的想法拆成明确的 task，能定义「做成什么样算合格」，然后放手让别人（或者 agent）去做，最后只出现在需要你做判断的那个节点。

很多工程师从来没练过这个能力。我们被训练成自己动手的人——接到需求、写代码、提 PR。我们不是 manager，所以我们没学过怎么把活派出去。

现在 AI 让你不得不学。

话又说回来

别误会，我不是说每个人都要去装一个 Symphony。它现在只支持 Linear，而且最好用在已经为 agent 优化过的代码库里。如果你的项目连自动化测试都没有，agent 跑起来也是盲人摸象。

但 Symphony 真正的价值不在代码，在那个思路：把 issue tracker 变成控制平面，让 agent 从被动执行变成主动领活。

这个思路不限于 OpenAI 的工具链。你可以用 Claude Code、Cursor、任何 agent。核心是那个转身——从「我管理 AI 会话」变成「我管理任务，AI 自己找活干」。

一个有意思的副作用

还有一个细节让我想了很久。

OpenAI 的产品经理和设计师现在可以直接往 Symphony 里丢需求。他们不需要 checkout 代码库，不需要管 Codex session，描述一下功能，拿回来一个 review packet，里面甚至有一个视频，演示这个功能在真实产品里跑的样子。

这意味着什么？

能发起工作的人变多了。

产品经理、设计师、工程师——所有人都能向同一个系统发起工作

以前，能往代码库贡献改动的人，是那些会 git、会跑测试、懂代码结构的人。现在，一个产品经理只要能把需求写清楚，就能启动一次完整的开发流程。

这不是「产品经理要取代工程师」。这是「发起工作的门槛降低了」，跟 20 年前建站门槛降低到让不会写 HTML 的人也能开博客一样。

门槛一降，参与的人就会指数级增长。然后事情就再也回不去了。

回到最开始的问题

文章开头我说，我们一直在问错问题。

我们问「AI 能不能写出好代码」，就好像 1995 年问「互联网能不能用来买东西」。答案当然是能——但真正改变世界的不是「能」这个事实本身，而是「能」之后，人们重新设计了整个系统来适配这种能力。

OpenAI 的 Symphony 就是那个「重新设计系统」的第一步。

它的意义不是让 PR 多 500%，而是向我们展示了一件事：当写代码的成本趋近于零的时候，真正的稀缺资源不是编码能力，而是「知道该让 AI 干什么」的判断力。

你不需要写得更快。你需要想得更清楚。

你觉得现在团队里，最该让 AI 接手的重复性工作是什么？

原文参考

Alex Kotliarskyi, Victor Zhu, and Zach Brock. An open-source spec for Codex orchestration: Symphony. OpenAI Engineering Blog.https://openai.com/index/open-source-codex-orchestration-symphony/