工程效能 on Codexer

五个 Codex 同时在跑，先管哪个在等你

Sun, 11 Oct 2026 07:50:00 +0800

说个你可能很熟的下午。

你在三个终端里各开了一个 Codex，一个改搜索接口，一个修 CSV 导出，一个整理发布说明。你去接了杯水，顺手开了个会，一个半小时后回来。第一个终端停在一条命令的批准提示上，等你按 y。第二个早就跑完了，输出滚了三百行，你不知道哪一行是结论。第三个在二十分钟前就因为缺一个 .env 里的变量停了，屏幕上那句「需要你确认」被后面的日志淹了。

你一直以为自己在并行三个任务。实际情况是，三个任务里有两个卡在你身上，而你根本不知道。

这里的问题不在模型。该干活的都在干活。坏掉的是另一半：你在多个会话之间怎么知道谁在等你、怎么在不切窗口的情况下把一个补充要求递进去。这一半以前基本没人管。

Codex CLI 0.149.0 补的就是这一半。这个版本在 2026 年 8 月 20 日发布，带了两个东西：codex agents 打开的一块面板，和一个叫 codex queue 的命令。它们不会让任何一行生成的代码变好，只处理人的这一侧。

面板只报三种状态，但顺序不是随便排的

在终端里敲 codex agents，面板就开了。它把本机上所有 Codex 任务列出来，按工作目录分组，每个任务给状态、名字、所在目录和当前分支。子 agent 的动作会挂在自己那个主任务下面，不单独占一行。

状态只有三种：

状态	含义	该做什么
Need input	卡在你身上，等你回答、批准或做选择	马上看
Working	正在跑	一般别动它
Ready	这一步做完了，等你验收	排队看输出

面板顶部给的是这三种状态的计数。这个设计里真正的信息是排序：Need input 排第一位。Working 的任务不需要你，Ready 的任务晚十分钟看也不会变，只有 Need input 的那些，是你不动它就不动的。你把它们当成待办队列从上面往下清，就把「到底该管哪个」这个问题消掉了。

键位大概是这样：上下选任务，回车打开完整对话，Ctrl+F 搜任务，Ctrl+S 换分组方式，Ctrl+R 改名，Ctrl+X 停掉。从某个任务的会话里回到面板，用 /agents，或者按默认快捷键 Alt+A。这些键是可配的，以你面板底下那行提示为准。

名字是地址，不是备注

codex queue 全靠名字找任务，所以起名不是审美问题，是这个命令能不能用的前提。

Codex 自动给的名字通常长这样：「Fix the header and then adjust…」，截断在中间。这种名字你记不住，也没法当地址用，第二天打开面板你还是得逐个点开看。给正在跑的任务起个短名字：

3864 个 Bug 拆开看：Codex 出错，八成坏在模型之外

Sat, 10 Oct 2026 07:40:00 +0800

先讲个场景。

你在 Codex 里让它改一个文件。它想了两分钟，输出一段正确的补丁，然后什么都没发生，文件还是老样子。你换个说法再问一遍，还是没改。第三次你有点火了，在群里丢一句：「这模型今天又降智了。」

问题是，模型没做错。补丁它写对了，没干活的是那个负责把补丁落到磁盘上的工具。

这种误判有多常见？约克大学和康考迪亚大学的一篇实证研究给了个量化答案。他们手工把三个 AI 编程工具仓库里 3864 个公开上报的 bug 全部标注了一遍：Codex CLI 1192 个，Claude Code 2343 个，Gemini CLI 329 个。逐条读描述、读讨论、读开发者的回复，再按类型、位置、根因和症状归类。这是目前针对这类工具做的第一份系统性 bug 研究。

结论不太符合直觉：这些工具身上的毛病，绝大多数不在那个「AI」上。

六成七的 bug，是功能本身没工作

按 bug 类型分，67% 落在「功能性」这一类，也就是工具没做到它该做的事。往后是 UI 易用性 17.9%，兼容性 7.6%，性能 5.9%，安全只占 1.7%。

功能性占大头不奇怪，真正值得看的是根因落在哪。

根因分类	占比
API 与集成错误	21.4%
配置与安装	15.9%
用户交互与界面	11.1%
环境与平台兼容	10.5%
AI 逻辑与行为	10.0%
性能与资源	8.1%
命令执行	6.8%
状态与上下文管理	6.5%

头号根因是 API 与集成错误，21.4%。把它和配置、安装合并计算，占比 36.9%。而模型自己的「AI 逻辑与行为」只有 10%。

换成一句人话：能追到模型身上的 bug 大约只有 12%（推理加提示工程），剩下 88% 都是常规软件工程问题，集成契约、平台兼容、状态管理，只不过恰好发生在一个 AI 工具里。

代码变便宜，看懂它没有：评审为什么成了 AI 时代最贵的环节

Thu, 08 Oct 2026 07:40:00 +0800

「写得比读得快」这件事，软件行业享受了很多年，只是没人特意设计过它。

一个资深工程师读代码的速度，本来就快过一个初级工程师写代码的速度。评审因此能跟得上开发节奏，团队在互相读 diff 的过程里，也顺带把系统长什么样装进了脑子。这套流程管用，靠的是一个相对速度上的巧合：写代码慢且贵，读代码快且便宜。

这个巧合已经不成立了。

agent 写出一千行格式规整、大致合理的代码，用的时间比我读完这一段还短；而人的阅读速度，从我们开始整天盯着屏幕那天起就没怎么变过。约束于是往下游挪了一格，挪到唯一没有变快的那一步：一个人得确认这处改动是对的。

Addy Osmani 今年写了一篇长文，把过去一年里被反复量出来的数据、被反复争论的问题整理成了一张地图。他的结论是，评审没有因为 agent 的到来变得次要，它变成了核心工作。这个判断我认同，而且觉得对国内团队尤其值得看一眼，因为我们的讨论大多还停在「AI 到底能不能写好代码」。

数字比观点更硬

先看被量出来的东西。

Faros AI 从低 AI 采纳度到高采纳度跟踪了 4000 个团队、22000 名开发者，这是 2026 年 3 月的数据。好的一面先说清：开发者合并的 PR 明显变多，人均吞吐上升，活儿干得更多了。然后是同份报告的其余部分：

代码 churn 上涨 861%
事故与 PR 的比值上涨 242.7%
人均缺陷率从 9% 升到 54%
评审时长中位数上涨 441.5%，首次评审等待时间和平均评审时间都大致翻倍
零评审直接合并的 PR 增加 31.3%

最后一条最难解释，因为没人主动做过这个决定。评审者跟不上量，代码就开始在没人读过的情况下合进去，然后这变成了常态。还有一点，工程规范成熟的团队被冲击的程度和别人一样。好流程没保住他们，量的到来比任何流程设计的吞吐都快。

CodeRabbit 在 2025 年 12 月研究了 470 个开源 PR，其中 320 个有 AI 参与、150 个纯人工。AI 改动带来的问题大约多 1.7 倍：逻辑与正确性问题多约 75%，安全问题多 1.5 到 2 倍，可读性问题翻了三倍多。他们 AI 负责人 David Loker 把这些称为「可预测、可度量的弱点」。可预测三个字是关键，弱点已知、能定位，就意味着无论人工还是自动的评审流程，都能对着它们瞄准。