代码审查 on Codexer

GPT-5.5 Codex 推理强度实测：low、medium、high、xhigh 到底差在哪？

Thu, 09 Jul 2026 09:00:00 +0800

你用 GPT-5.5 Codex 写代码的时候，有没有纠结过该选哪个推理强度？low、medium、high、xhigh，这四个选项摆在面前，到底哪个最适合日常使用？网上众说纷纭，有人说 low 就够了，有人说必须拉满 xhigh，还有人担心高推理强度会「过度思考」反而写出烂代码。

stet.sh 的作者做了一个实验：在同一个开源仓库 GraphQL-go-tools 上，用 GPT-5.5 Codex 的四个推理强度分别跑了 26 个真实合并过的 PR，然后从多个维度对比了结果。这篇文章就是他的实验报告。

先交代背景：GraphQL-go-tools 是一个 Go 语言实现的 GraphQL 工具库，涉及 schema 解析、联邦查询、gRPC 数据源、订阅处理等复杂场景。26 个 PR 涵盖了并发安全修复、输入校验重构、别名语义处理、AST 合并优化等不同类型的任务，比跑几个算法题要有说服力得多。

实验不是简单地看测试过没过。作者设定了五个评价维度：

测试通过率：最基本的指标，patch 能不能让现有测试通过。
语义等价性：AI 提交的 patch 是否实现了和人类提交者相同的意图。这个比测试通过率更严格，因为测试可能覆盖不全。
代码审查通过率：用 GPT-5.4 作为评审模型，判断人类审查者会不会接受这个 patch。
代码质量评分：从清晰性、简洁性、一致性、意图明确性、健壮性、指令遵守度、范围约束、diff 精简度八个子维度打分。
足迹风险：AI 相比人类提交者多触碰了多少代码。触碰越多，审查负担越重，引入 bug 的风险也越大。

Low 和 Medium：测试平手，质量悬殊

最让人意外的一个发现是：low 和 medium 在测试通过率上打成平手，都是 21/26（80.8%），但语义等价性差了整整 15 个百分点（15% vs 42%）。

这意味着如果你只看「测试过没过」这个指标，你会得出「low 和 medium 一样好」的结论，然后心安理得地省钱用 low。但如果你坐下来认真读那些 patch，你会发现 medium 写的代码质量明显更高。

举个例子，PR #1297 要求 Agent 在 GraphQL Federation 中验证可以为 null 的外部依赖。如果一个可空字段返回 null 且带有 error，依赖它的下游查询不应该收到被污染的数据。low 的方案虽然通过了测试，但它用的是启发式的字段匹配，看到 required 字段加 error 就拦截，完全没有理解 Federation 的 nullable metadata 结构。medium 则明确追踪了被污染的对象，在下游输入中正确过滤。

AI 编程代理的审查循环为什么不收敛？Convergo 给出了答案

Wed, 08 Jul 2026 10:00:00 +0800

如果你最近在用 AI 编程代理做稍微复杂一点的工作，你大概经历过这样一个场景：你让 AI 审查另一个 AI 写的代码。第一个审查者发现了三个问题。你让 AI 修复，然后让同一个审查者再看一遍，通过了。但你不放心，又找了一个新的审查者看，结果它发现了三个完全不同的问题。

你深吸一口气，修复，再来。第五轮的时候，代码没变好多少，但 docs/impl-notes.md 已经长到了 500 行。

这就是 AI 编程代理的审查循环问题。它不是 AI 不够聪明，而是审查循环本身有结构性缺陷：每一轮都在发散，而不是收敛。

审查循环为什么发散？

先定义一下概念。当我说「审查循环」，我指的是这样一个流程：

AI Agent A 写了一些代码
AI Agent B 审查这些代码，给出修改建议
AI Agent A 根据建议修改
AI Agent B 重新审查
重复 2-4，直到 B 说「没问题」

这个流程看起来没毛病。但实际上，它经常不收敛，而且失败的方式很隐蔽：

问题一：审查者只看到症状，看不到根因。 一个缺失的不变量在八个不同的地方产生了影响，审查者可能把这些当成八个独立的问题，一个接一个地发现，一轮接一轮地修复。本该一次修补计划就能解决的事，变成了八轮局部打补丁。

问题二：写代码的 AI 在修补丁，而不是修结构。 当审查者说「这里有个 bug」，写代码的 AI 倾向于在出问题的地方打个补丁。但如果这个 bug 的根源是一个不完整的设计决策，贴补丁只会让代码库越来越复杂，而问题依然存在。

问题三：每一轮都在增加内容，而不是减少不确定性。 审查发现一个问题，写代码的 AI 加一段文字解释。下一轮发现另一个问题，再加一段文字。经过几轮之后，artifacts 越来越长，越来越模糊，伪代码越来越多，这些伪代码又成为新一类审查发现的来源。这是一个正向反馈循环，方向是错的。

问题四：同一审查者的「通过」不可信。 同一个 AI 审查者在看完第六轮修改后说「通过」，可能是因为它已经适应了代码的风格，或者它已经「累了」。它的通过不是真正的无疵，而是认知惯性的产物。

这四个问题叠加起来，就形成了一个典型的发散螺旋：越改越大，越改越模糊，越改越不确定什么时候算「改好了」。

Convergo 的三条核心规则

Convergo 是 Miles 在七月初发布的一个开源插件，同时支持 Claude Code 和 Codex。它源自 Compound Engineering 的设计理念，但加了一个关键的改进：边界。Convergo 的目标不是让审查更彻底，而是让审查循环必然终止。

Codex 不只是写代码了：OpenAI 把它变成了安全扫描器

Tue, 30 Jun 2026 10:00:00 +0800

2025 年 4 月，OpenAI 发布了 Codex，一个运行在终端里的 AI 编程助手。那时候，大家对它的期待很简单：让 AI 帮忙写代码、改 bug、跑测试。一年多过去了，Codex 的用户已经不只是写代码的程序员，它还在变成一种全新的工作方式。

而最近，OpenAI 又给 Codex 加了一个让人意想不到的功能：安全漏洞扫描。

没错，就是那个在终端里帮你写 Python 脚本的 Codex，现在可以像专业安全审计工具一样，扫描你的代码仓库、发现安全漏洞、验证误报、生成修复建议，甚至整合到你的 CI/CD 流程里。这个功能叫 Codex Security，它标志着 AI 编程 Agent 正在从「帮人写代码」进化成「帮人守护代码」。

一个插件，两种形态

Codex Security 目前有两种使用方式：

第一种是本地插件。 在 Codex 桌面应用中安装 Codex Security 插件，然后在代码仓库里开启一个新线程，对它说一句「Run a Codex Security scan on this repository」，Codex 就会开始扫描你的代码。你可以选择标准扫描或深度扫描，可以指定扫描范围（整个仓库还是某个文件夹），甚至可以提供特定的威胁模型来指导扫描方向。

扫描完成后，Codex 会生成一个完整的工作区，包含按严重程度、类别、目录分类的漏洞列表，以及一份可移植的完整报告 report.md。你可以在 UI 里逐条审查，也可以把报告分享给团队成员。

第二种是云端服务（Codex Security Cloud）。 目前还处于 research preview 阶段，但已经可以连接 GitHub 仓库，自动对每次提交进行安全扫描。它会为每个仓库构建特定的威胁模型，用真实的代码上下文来检测漏洞，然后在隔离环境中验证高危发现，最后把经过筛选的结果呈现给你。

云端的核心设计理念是「降噪」。传统 SAST 工具的一个大问题是误报太多，安全工程师经常要在几百条告警中手动筛选真正的问题。Codex Security Cloud 用 AI 来承担这个筛选工作，它只把经过验证的高信号发现推送到你面前。

不只是「发现问题」，而是「驱动修复」

Codex Security 的工作流分为几个阶段：