最近我一直有一个挺强烈的感受。
我现在其实同时在两家科技创业公司工作，而且两边都还是比较偏开发、比较需要持续推进事情的工作。
但我现在居然还可以比较好地 handle 过来。
后来我自己想了一下，我觉得一个非常重要的原因，不只是因为 AI 帮我写代码变快了，而是因为我现在已经开始把这些 Agent 当成真正的“员工”来用了。
以前我会把 Codex、Claude 这种东西理解成一个 coding assistant。
就是我有一个问题，我问它。
我有一个功能，我让它写。
但是现在我的用法越来越不是这样。
我会开始想：
这个任务应该交给哪个 Agent？
哪个 Agent 更适合做什么？
哪些任务可以同时做？
哪些任务必须按顺序做？
谁来负责跟踪这些任务？
哪些问题可以让 Agent 自己决定，哪些问题一定要回来找我？
所以慢慢地，我自己的角色也发生了一点变化。
以前我的工作更像是：
需求来了，我去理解，然后我自己写代码，自己 debug，自己跑测试，再继续下一个任务。
现在我越来越像是在管理一个非常小型的工程团队。
某种程度上，我觉得自己的工作方式开始有一点像 CTO。
当然，我说的不是职位。
更多是那种工作的感觉。
我现在花越来越多的时间在决定方向、拆任务、分配工作、处理阻塞、review 结果，而不是自己去完成每一个具体的 implementation。
我现在不太纠结哪个 Agent 最强，而是哪个 Agent 更适合做什么
我现在越来越觉得，把 Agent 当成员工以后，有一个事情会变得特别明显：
不同 Agent 其实是有“性格”的。
或者更准确地说，它们的产品方向、训练方式和工具能力，会让它们在实际使用中表现出很不一样的特点。
所以我现在已经不是特别喜欢讨论：
到底 Codex 强，还是 Claude 强？
我觉得这个问题其实有一点像问：
一个 Tech Lead 和一个很强的 senior engineer，到底谁更强？
这个问题本身就不太对。
更重要的问题应该是：
你想让它做什么？
比如说我自己现在对 Codex 的感觉，就是它特别适合放在一个偏 leader、偏 coordination 的位置。
这是我目前自己的使用体验，不是什么客观 benchmark。
我觉得 Codex 有几个特点特别适合做这个事情。
第一个，是它对外部程序和新工具的接入比较积极。
我自己的感觉是，Codex 背后的产品方向会比较重视“怎么让模型跟其他工具一起工作”。
比如终端、外部程序、各种新的 tool、workflow，甚至比较新的能力，它通常接得比较快。
所以如果我现在要让一个 Agent 不只是坐在那里回答问题，而是真的去：
读 Linear，
操作 terminal，
查看另外一个 Agent 的状态，
调用外部工具，
或者把几个不同的系统串起来，
我会比较自然地想到 Codex。
第二个是多模态。
这个也是我自己的一个很明显的体验。
我的理解是，Codex 所在的这个产品方向本身会比较重视多模态能力。
比如语音。
我现在其实很喜欢直接用语音跟 Codex 沟通。
因为对于开发来说，很多时候我脑子里面有一个东西，但是它其实还是一个半成品。
如果让我完整地把它打成文字，我会觉得很慢。
尤其是那种：
“这个 ticket 我觉得应该这么改，但是这里可能又要考虑另外一个东西，然后这个地方其实跟之前那个功能还有一点关系……”
这种东西。
你让我打字，我可能要打一大段。
但是如果直接说，我可能几十秒就讲完了。
然后让 Codex 帮我把它整理出来。
而且我自己的感觉是，它对语音的识别和理解会比较稳定。
所以这就让它非常适合作为我跟整个 Agent team 之间的第一个 interface。
还有一个特点，就是 Codex 的回复通常会比较简洁。
这个对我来说其实也很重要。
因为如果它是在一个 leader 的位置，我不是每次都需要它给我写一篇几千字的 reasoning。
我很多时候只需要知道：
现在这个 ticket 做到哪里了？
哪个 Agent 卡住了？
哪个已经 finished？
哪个需要我回答一个问题？
下一步我们应该推进什么？
它如果能够很快地给我一个摘要，对我来说反而更有价值。
Claude 给我的感觉完全不一样
Claude 给我的感觉更像一个很纯的工科生。
这个是我自己一直以来很强的一个感觉。
它比较谨慎。
它的 reasoning 也会比较重。
比如你给它一个 repo，让它去改一个功能，它很多时候不会马上冲进去改。
它会先去看：
这个项目有没有 AGENTS.md。
有没有相关的开发规则。
有没有 README。
这个 repo 里面本来是怎么做事情的。
有没有既有的 pattern。
然后再开始修改。
而且它在改代码的时候，经常会有一种“我改了这里，会不会影响别的东西”的意识。
比如一个功能看起来只改一个地方，它可能会继续往外看：
这个函数还有谁在用？
这个类型改了以后会不会影响别的模块？
这个状态是不是在另外一个地方也被消费？
已有测试会不会被影响？
这种谨慎其实有时候会让它显得比较慢。
甚至有的时候它会太谨慎。
它会一直 needs input。
会问你：
这个地方你到底希望是哪一种行为？
这个 permission 能不能给？
这个改动是否允许影响另外一个模块？
但是我反而觉得，这种性格很适合让它去真正做 implementation。
所以我现在的分工大概是：
我负责方向。
Codex 更像 leader。
Claude Agents 更像一线的工程师。
当然，这不是说 Codex 不写代码，或者 Claude 没有办法做 planning。
不是这么绝对。
只是按我现在真实的使用经验，这样搭配起来特别顺。
Linear 很适合变成整个 Agent team 的工作系统
然后就是 workflow。
我现在基本上是基于 ticket 来推进开发。
比如我们用 Linear。
我越来越觉得，Linear 这种工具其实天然适合 Agent。
因为 ticket 本身就是一个非常明确的工作单位。
而且它还有自己的状态：
Backlog。
In Progress。
Review。
Complete。
甚至还可以有不同的自定义状态。
所以从某种程度上说，它本身就是一个开发工作的状态机。
这对 Agent 特别友好。
因为如果没有 ticket，所有东西都在聊天里面，其实会很乱。
今天我们讨论一个东西。
明天讨论另外一个东西。
后天再回来，你都不知道那个事情到底做到哪里了。
但是 ticket 不一样。
它有一个明确的对象。
有 description。
有状态。
可以有 comment。
可以记录决定。
也可以继续拆出新的 ticket。
所以我现在每天的工作方式，有时候会很简单。
我直接跟 Codex 说：
你先去读一下 Linear。
看一下最近有什么 ticket 可以继续推进。
哪些在做。
哪些卡住了。
哪些已经可以 review 了。
然后它先帮我做一次汇总。
我再跟它一个 ticket 一个 ticket 地聊。
我现在会先跟 Codex 把 ticket 讲清楚，再让 Claude 下去做
这个也是我现在 workflow 里面一个挺重要的变化。
以前我经常会直接把一个 ticket 丢给 Claude。
但后来我发现，这其实很容易返工。
因为人写 ticket 的时候，本身就不一定写得很清楚。
甚至很多时候，我自己脑子里面的需求也没有完全想清楚。
比如我可能会说：
“这个地方优化一下。”
或者：
“把这个 workflow 改得更顺一点。”
但是这其实不是一个真正的 engineering task。
里面有很多默认信息。
比如：
哪些功能不能动？
已有行为要不要保留？
这个东西只是 UI 改，还是 backend 也要改？
怎样才算完成？
有没有特别的 edge case？
需要补什么测试？
如果这些没有讲清楚，Claude 很可能非常认真地把一个“错误的问题”做好。
然后它做完，我一看：
不是，我不是这个意思。
然后又返工。
所以我现在越来越喜欢先跟 Codex 讨论。
我可能先用语音，把我的想法讲出来。
不用特别完整。
甚至可以很乱。
然后让 Codex 帮我整理。
它可以反过来帮我确认：
你这里真正想解决的问题是什么？
这个行为是不是必须保留？
这个地方有没有依赖？
如果实现 A，会不会影响 B？
最后什么算是 acceptance criteria？
等我们把这些东西讲清楚以后，再让它把任务整理成一个更适合 Claude 执行的 prompt。
这样 Claude 下去以后，方向通常会更准。
所以我现在甚至觉得：
以前大家一直讲 prompt engineering。
但以后很多时候，给 Agent 写 prompt 这个事情，可能也会被 Agent 自己做掉。
也就是说：
我不是直接给 Claude 写一个非常完整的 prompt。
而是先跟 Codex 说人话。
Codex 再把我的话转成更适合工程 Agent 执行的任务。
这其实效率高很多。
当然，这里面还有一个前提。
Codex 也可能理解错。
所以我还是会看它整理出来的东西是不是我真正想要的。
AI 给 AI 写 prompt，并不意味着人就可以完全不看。
Codex 更像一个中间管理层
我觉得这整套东西真正有价值的地方，不是在只有一个 Agent 的时候。
如果你只有一个 Claude，那其实没什么特别复杂的。
你给它一个任务。
它做。
做完以后你看。
就这样。
真正有意思的是，当你同时开始推进很多任务以后。
比如说我现在有十个 ticket。
这十个 ticket 里面，可能又会拆成二十个甚至更多的子任务。
比如一个 ticket 本身可能涉及：
frontend。
backend。
database。
migration。
test。
不同 module。
这个时候，人的管理压力会突然变得特别大。
因为你不可能同时盯二十个任务。
而且二十个任务的状态都不一样。
有的正在工作。
有的已经完成。
有的测试失败。
有的 needs input。
有的要 permission。
有的做到一半发现了另外一个 bug。
有的发现当前 ticket 之外其实还有一个事情应该做。
如果所有这些东西全部直接回来找我，我其实会被完全打断。
这时候 Agent 越多，我反而越忙。
所以我需要 Codex 在中间做一层。
它不是只负责“把任务发出去”。
它还要负责：
读下面 Agent 的状态。
把多个任务的信息汇总。
一些很明显的问题先自己处理。
真的需要我做决定的事情，再升级给我。
这样我不需要直接面对二十个 Agent。
我只需要面对 Codex。
它可能告诉我：
现在有十二个任务还在跑。
五个已经完成。
两个测试失败，但是原因比较明确，已经让它们重新处理了。
还有一个需要你确认产品行为。
这就够了。
我觉得这个东西很像真正公司的管理结构。
一个 CEO 或者 CTO 不可能直接管理几十个人每天的所有细节。
中间一定会有一层，把信息压缩。
我现在觉得 Lead Agent 做的就是这个事情。
Agent 多了以后，并行才是真正大的收益
还有一个我觉得 AI coding 很容易被低估的地方。
大家经常会讨论：
AI 写一个功能，比人快几倍？
但我现在越来越觉得，这可能还不是最大的效率提升。
真正大的效率提升来自并行。
比如一个 ticket 涉及三个不同模块。
如果这三个模块彼此之间没有强依赖，那其实完全可以同时做。
Codex 可以先帮我拆。
它判断：
A 必须先做。
B 和 C 可以并行。
D 要等 B 的接口稳定以后再做。
然后它就可以把 B 和 C 同时交给两个 Claude Agent。
以前如果我自己做，我就是：
先做 B。
做完。
再做 C。
再做 D。
现在很多工作会变成同时发生。
所以我觉得 AI 带来的一个很大的变化，是软件开发从以前比较强的串行工作，开始越来越多地变成并行工作。
而且这不只是“机器比较快”。
更重要的是，我本人不用一直 block 在一个任务上。
比如我把三个 implementation 发出去了。
Claude 在那边做。
我这个时候可以继续：
跟 Codex 讨论下一个 ticket。
去开一个会。
review 另外一个 PR。
处理另外一家公司的事情。
想一个新的需求。
所以很多以前对我来说是 blocking 的工作，现在开始变成 asynchronous。
我觉得这个其实是我为什么能同时 handle 两边工作非常重要的一个原因。
不是说 AI 让我变成一个三倍速程序员。
而是说，我可以同时让很多东西往前走。
为什么我让 Codex 通过 terminal 管 Claude
这个也是我觉得挺有意思的一个设计。
我现在更喜欢让 Codex 通过 terminal 去操作和查看 Claude Agent。
而不是让它像人一样：
打开一个界面。
切到另外一个窗口。
再去看另一个窗口。
我觉得 terminal 对 Agent 来说反而更自然。
GUI 是给人设计的。
人看 GUI 很快。
一个颜色。
一个 icon。
一个 progress bar。
一眼就知道发生什么。
但是 Agent 不一定需要这些东西。
对 Codex 来说：
Agent A: running
Agent B: needs input
Agent C: test failed
Agent D: completed这种东西可能反而更容易理解。
它可以直接读。
直接操作。
直接查进程。
直接发命令。
所以我有时候会觉得：
terminal 其实很像 Agent 自己的 UI。
人类有 dashboard。
Agent 有 CLI。
这个对我来说特别顺。
权限其实也可以做一层管理
Claude 比较谨慎，这个事情其实既是优点，也是问题。
因为它会经常停下来问。
比如：
要不要给这个权限？
这个文件能不能改？
这个命令能不能跑？
这个东西是不是允许删除？
如果我同时有很多 Agent，这种 permission request 会特别多。
所以我也在想，Codex 其实可以帮我先做一层判断。
但这里我觉得有一个很重要的边界。
不是说：
Codex 觉得没问题，所以什么都自动允许。
我觉得应该是人先定义一个 permission boundary。
比如：
跑测试，可以。
读代码，可以。
改本地文件，可以。
一些明确低风险、可逆的操作，可以。
但是如果涉及：
production。
敏感数据。
删除重要东西。
不可逆的 operation。
或者明显超过了它当前任务的范围。
那还是必须回来找我。
也就是说，我希望 Codex 帮我减少的是那种没必要的人工确认。
而不是把责任全部交出去。
特别是因为我本身同时在两个公司工作。
不同公司的 repo、数据、权限，其实更加不能混。
所以 Agent 越多，边界反而要越清楚。
一个 ticket 做完以后，还可以继续长出新的 ticket
这个我现在也觉得挺自然的。
现实开发里面，一个 ticket 很少真的就是孤立的。
你改一个功能，可能做到一半发现：
这里其实还有一个老 bug。
或者：
这个模块以后应该重构。
或者：
这个东西现在能工作，但是还有一个 follow-up。
以前我可能顺手就继续做了。
结果一个 ticket 越做越大。
现在我更愿意让 Codex 新建一个 ticket。
比如它发现：
当前 ticket 已经满足 acceptance criteria。
但是这里还有另外一个问题。
那就把它记录下来。
建立新的 Linear ticket。
然后先把当前 ticket 完成。
新的问题重新进入 backlog。
之后再继续讨论、拆解、分配。
这样其实会形成一个很自然的循环：
我跟 Codex 交流。
Codex 读 Linear。
我们一起明确 ticket。
Codex 拆任务。
Claude 开始执行。
Codex 读取 Claude 的状态。
低风险问题它先处理。
需要我决定的问题回来找我。
任务完成以后 review。
如果又发现新的工作，就建立新的 ticket。
然后进入下一轮。
我现在其实越来越习惯这种循环。
但是做到这里以后，我反而越来越觉得：人不能被拿掉
如果只看我前面讲的这些东西，很容易得出一个结论：
那是不是以后人就没用了？
Codex 管 Claude。
Claude 写代码。
Linear 管 ticket。
那我干什么？
但我自己的感觉其实正好相反。
越把这套 workflow 做得自动化，我越觉得人的角色很重要。
只是人的角色在往上移。
最简单的例子就是：
如果 Linear 里面已经有一个非常清楚的 ticket，
AI 可以做很多事情。
它可以：
读 ticket。
分析 ticket。
拆 ticket。
写代码。
跑测试。
review。
甚至继续建立 follow-up ticket。
但是如果根本没有这张 ticket 呢？
谁来提出第一张 ticket？
我觉得这个非常重要。
因为很多真正对公司有价值的事情，一开始根本不会以 ticket 的形式存在。
可能只是：
我在会议里面发现，大家一直在被这个东西卡住。
我发现客户其实真正想要的不是我们现在做的这个功能。
我发现这个 workflow 长期一定会成为瓶颈。
我发现现在这个技术架构短期没问题，但是半年以后一定很难维护。
或者反过来：
一个东西虽然技术上特别有意思，但是对公司现在根本不重要。
这种判断其实很难只从 repo 里面得出来。
因为人掌握的是更完整的业务上下文。
你知道公司现在往哪里走。
你知道客户真正 care 什么。
你知道团队资源有多少。
你知道为什么这个东西现在重要。
你也知道为什么有些东西虽然看起来不错，但是现在不应该做。
AI 可以读很多 context。
但是它永远只能从它拿到的 context 出发。
而现实公司的 context 很多根本没有被写下来。
甚至有很多东西还只是存在人的脑子里面。
所以我特别喜欢这样描述：
AI 可以帮我写 ticket。
但是人要先发现：这里应该有一张 ticket。
这个是我觉得人现在特别重要的一个位置。
人还需要做长期决策
另外一个 AI 很难完全替代的部分，就是长期的方向。
比如说：
这个功能短期能不能做？
通常很好判断。
但是：
我们要不要因为这个客户的需求改整个 architecture？
这个技术债现在要不要还？
我们是做一个快速 workaround，还是趁这个机会重构？
这个东西对未来半年有没有价值？
我们现在应该优化速度，还是先增加能力？
这些问题很多并不是纯技术问题。
里面有：
商业判断。
时间。
资源。
风险。
团队情况。
客户关系。
未来规划。
甚至还有公司战略。
AI 可以帮我分析。
我也会让它给我不同的方案。
但是最后做这个判断的人，我还是觉得应该是人。
因为最终承担后果的也是人。
还有一个事情：人有时候反而会想到更简单的办法
这个我自己在开发里面也经常碰到。
AI 有一个特点。
你给它一个问题，它通常会很认真地解决你给的这个问题。
比如你说：
这个 workflow 要怎么支持另外一种状态？
它可能会开始：
加状态。
改 schema。
加 service。
加 migration。
补测试。
然后给你一套非常完整的 engineering solution。
但是有时候我一看会说：
等一下。
为什么一定要支持这个状态？
这个入口直接拿掉行不行？
或者：
为什么要改 backend？
前端直接不让用户进入这个情况，不就好了？
甚至：
这个需求是不是根本不值得做？
我觉得这个特别重要。
因为有时候好的工程不是把复杂问题解决得非常漂亮。
而是发现：
这个问题其实根本不需要这么复杂地解决。
AI 当然也可能想到简单方案。
我不是说它想不到。
但我现在不会假设它一定会主动帮我质疑最开始的问题。
所以我还是会不断问：
我们真的需要这么做吗？
有没有一个更简单的方法？
有没有可能是我们的 framing 一开始就错了？
这也是我觉得人现在特别重要的一部分。
所以我理解的“像 CTO 一样工作”，其实不是少写代码这么简单
我现在说自己有一点像 CTO，不是因为：
我不写代码了。
然后下面一堆 AI 给我干活。
我觉得不是这么简单。
更准确地说，是我的注意力开始往不同的层级移动。
以前我一天的工作可能大量是：
怎么把这个函数写出来。
这个 bug 到底在哪里。
这个 test 为什么挂了。
这个 API 怎么接。
这些我现在当然还是会看。
但是我花越来越多时间在：
什么事情值得做？
这个 ticket 定义得对不对？
这个任务怎么拆最合理？
哪些东西可以并行？
这个结果是否满足业务真正想要的东西？
这个 permission 能不能放？
这个 Agent 是真的卡住了，还是只是缺信息？
这个问题应该现在解决，还是新建一个 ticket 以后再做？
这个架构决定对未来会有什么影响？
这些东西。
所以我觉得 AI 并没有让人变得不重要。
它只是让人的价值开始从 execution 往 judgment 移动。
以前可能是：
Decision + Coordination + Execution 全部是我。
现在越来越像：
我主要负责 Direction、Judgment、Prioritization。
Codex 负责 Coordination、Decomposition、Communication。
Claude Agents 负责 Execution、Implementation、Verification。
当然现实中不会分得这么干净。
但是大概是这个结构。
我现在越来越觉得，AI coding 的终点可能不是“更快的程序员”
我以前其实也会觉得：
AI coding 最终就是让一个程序员变得特别快。
以前一天做一个功能。
以后一天做五个。
但是现在我越来越觉得，可能不是这么简单。
真正改变的可能是整个软件开发的组织方式。
因为当一个人可以同时带很多 Agent 的时候，瓶颈就不再只是：
写代码有多快。
而会变成：
你能不能定义好问题。
能不能把任务拆得合理。
能不能建立好的上下文。
能不能管理权限。
能不能控制并行带来的复杂度。
能不能让真正重要的问题回到人这里。
以及最重要的：
你能不能判断，什么事情值得做。
我现在觉得，如果以后一个工程师真的要同时管理很多 Agent，那么 engineering management 的能力反而会越来越重要。
只是以前你管理的是人。
现在你可能还要管理 Agent。
而且不同 Agent 真的很像不同类型的员工。
它们有自己的强项。
也有自己的弱点。
你不能把所有事情都交给同一个人。
你也不能因为某一个模型 benchmark 更高，就觉得它什么事情都应该做。
你还是要了解它。
然后把它放到最适合的位置。
对我来说，现在比较舒服的状态就是：
我跟 Codex 说。
Codex 帮我协调。
Claude 下去做。
Codex 再把状态带回来。
真正重要的判断回到我这里。
然后我们继续推进下一个 ticket。
这套东西让我可以同时处理比以前多得多的工作。
但它也让我越来越清楚一件事：
我可以把很多“怎么做”交给 Agent。
但什么值得做、为什么做、什么时候做、应该做到什么程度，以及最终要承担什么结果，这些事情，仍然是人的工作。
而且至少现在，我觉得这反而是整个系统里面最重要的部分。