AI 编程到底把软件工程变成了什么样？这个问题谁都能聊上两句，但真正靠得住的答案少得可怜。

你在 X（推特）上能看到一堆「前沿」说法，什么「我已经三个月没看过自己的代码了」「我们团队每天烧掉十亿 token」。但这类信息最大的问题是没法验证，讲的人可以随便夸大，反正没有数据打脸。演讲也一样，公司高管在台上说出来的话，往往是他想让你听到的版本，而不是真实情况。

于是有人想到一个更靠谱的观察窗口：OpenAI 开源的 Codex 仓库。

为什么盯上一个「开源仓库」#

这个思路其实很巧妙。想搞明白「AI 时代最好的工程实践长什么样」，最缺的不是观点，是地面真相（ground truth）。而 OpenAI 的 Codex 仓库恰好是一个难得的、公开的、能被逐条验证的样本。

原因有三。第一，Codex 是 OpenAI 内部团队在用的产品，他们能摸到模型能力的最前沿，据说内部已经在用比 GPT-5.6-sol 更强的 Astra。第二，这个仓库从 2025 年发布起就是开源的，三年里发生过什么，全都摊在明面上。第三，如果要选一家「最懂怎么用 Agent 方式写软件」的公司，OpenAI 大概率排在全世界最前列。

于是工程师 John Wang 干了一件事：他用 Codex（gpt-5.6-sol）加上 Claude Code（Fable 5）两个 Agent，把整个仓库从头到尾分析了一遍，想看 OpenAI 到底是怎么干活的。挖出来的东西，比想象中有意思得多。

一组让人惊讶的「提速」数据#

他第一个观察是：Codex 仓库的提交速度，在过去几个月里出现了一次量级跃迁。

2025 年 5 月，Rust 实现只有 98 次提交，来自 6 个作者，其中一个人写了 89 次。到了 2026 年 8 月的前 25 天，提交数已经超过 1000 次，作者数涨到 135 个。

把这个变化摊成一张表，感受会更直观：

指标2025 年 5 月2026 年 3 月2026 年 8 月
月提交数98791893
提交 5 次以上的常规作者22835
最忙作者贡献占比91%14%18%
中位活跃日的作者数112~18
中位活跃日改动的 crate 数416~28

月提交量涨了差不多 8 倍，从 98 次涨到近 900 次。最忙的那个作者，贡献占比从 91% 一路掉到 18%，说明「英雄独行」的模式彻底结束了，取而代之的是一群人和一群 Agent 在各自独立的模块上并行工作。

当然，提交数不是完美的产出指标。但背后的信号是一致的：同一个代码库里，同时在干活的人变多了，同时被改动的地方也变多了。这个仓库最初是 2025 年 4 月 16 日以一个 TypeScript CLI 的身份诞生的，最初的 Rust 版本由 Michael Bolin 一个人写，前 169 次 Rust 提交里他占了 150 次。而现在，团队已经扩到 137 人。

值得玩味的是，这次提速并不全是因为 Agent 变强了。很大一部分来自团队规模的扩张，以及一套让「很多人和很多 Agent 同时改代码」不打架的规则和自动化。后者的价值，恰恰是被很多人低估的部分。

AGENTS.md：写给 Agent 的「规矩」#

当几百个提交同时涌进一个仓库，靠人肉约定显然撑不住。所以 Codex 团队把规矩写进了 AGENTS.md。这个文件有 322 行，而且团队一直在狠心地删掉冗余和废话。里面有几条规则特别有意思。

第一条：永远不要新增或修改任何跟 CODEX_SANDBOX_NETWORK_DISABLED_ENV_VAR 或 CODEX_SANDBOX_ENV_VAR 相关的代码。原因很有意思，有些测试会读这两个环境变量，来判断自己能不能安全地跑嵌套沙箱或者联网行为。而一个 Agent 很可能看到这些判断逻辑后，觉得「这些检查碍事了」，顺手把它们「修好」。提前把这类「作弊行为」写进规则，等于给 Agent 打了个预防针。

第二条：不要给「静态定义的常量」写测试，也不要给「已经被删掉的逻辑」写反向测试。这两条瞄准的是同一个问题：Agent 特别擅长生成那种看起来很严谨、实际上啥也没验证的测试。明确告诉它「什么不该测」，反而能让测试套件把火力集中在真正可能回归的行为上。

第三条：任何改变 Agent 逻辑的功能，必须加集成测试。因为 Agent 的行为是上下文、工具、模型响应和 turn loop 共同作用的结果，一个小的单元测试根本验证不了「Agent 到底会不会做对事」。Codex 为此专门造了一个 TestCodexBuilder 测试框架，让真实的 Agent 循环跑在伪造的模型输出流上。

第四条：避免用 bool 或者含义模糊的 Option 参数。如果 API 一时改不了，那就在传参时给 false、None 这种不透明值加上 /*参数名*/ 注释。

我最喜欢的一条 lint 规则#

上面第四条规则，引出了整个仓库里我最喜欢的一个细节。

在 Rust 里，很容易写出这样的调用：

foo(false, None, 1000)

这种代码基本没法读，不跳回函数定义，你根本不知道这三个值是什么意思。Codex 团队希望你先改 API 让参数变得清晰，但如果暂时改不了，就要求你写注释：

foo(
    /*enabled*/ false,
    /*parent_turn_id*/ None,
    /*timeout_ms*/ 1000,
)

更狠的是，他们专门写了一个 lint 规则，去检查注释里的名字是否和函数定义里的参数名完全一致。这条规则 2026 年 3 月引入，几天内就应用到了整个 Rust 工作区，随后进了 Bazel CI。

整个仓库一共有 38 条 lint 规则。这些规则不是一次性冒出来的，而是一条条「沉淀」下来的。AGENTS.md 的支持 2025 年 5 月落地，更细的测试指南在那个夏天跟上，快照要求 2026 年 2 月出现，3 月加了 codex-core 的警告，4 月补了 trait 指南，6 月又加了模型上下文和改动规模的规则。

你能看到一条清晰的路径：一个问题先在 code review 里反复出现，然后被写进 AGENTS.md，让下一个人和下一个 Agent 在动手之前就看到，等规则足够稳定了，再把它变成 lint 或者 CI 检查。不是每条规则都能走到最后一步，但那些代价高、又能被客观检查的，基本都会。

40% 的代码是测试，还造了个「假模型」#

另一个让我印象深刻的点，是他们对测试的投入。测试代码大约有 61.5 万行，占了整个代码库的 40%。

他们还花了不少功夫造了一个 mock 测试框架：大约 7000 行代码、300 多次提交，用来 stub 掉 Responses API 的 HTTP 响应。这个框架会跑一个真实的 Codex 线程，能调用工具、应用审批、像真的收到 LLM 响应一样迭代请求。用这种确定性的方式去测 Agent 行为，是相当聪明的做法，因为 Codex 的循环本身就是这个产品最核心的部分。

那问题来了：测试这么多，开发速度怎么还这么快？

答案是，他们不会在每一个阶段都跑同一套庞大的测试。开发时只跑被改动到的那个 crate 的测试，改动终端 UI 就只跑终端 UI 的测试，不碰整个工作区，日常的「改完就跑」循环得以保持飞快。合并之前，CI 会把覆盖面放大，Bazel 在 macOS、Linux、Windows 上跑兼容的 Rust 测试，另外有单独的 job 检查 SDK、格式化、依赖和仓库规则。代码进了 main 之后，才跑最彻底的那一档：跨五种平台和架构组合的完整 Cargo 测试套件，每套编译一次、分发给四台机器执行。

一句话总结就是：开发时只跑相关测试，越接近上线越严格。这样既能保证快速发布，又能在长期保住正确性和安全性。

用 feature flag 和 lint 完成的迁移#

还有一个细节让我看到了扎实的工程功力：他们把「大改动」做成阶段化的迁移，而且最后用 lint 规则把迁移成果锁死。

TUI 迁移是个很好的例子。3 月 16 日，团队在 tui_app_server 这个 feature flag 后面创建了一个临时的并行实现；十天后，这个实现被默认启用；等它稳定了，就删掉旧的 TUI、下线 feature flag，同时继续在配置里接受旧的 flag 值，让老用户不会报错。又过了两周，他们加了一条 CI 规则，禁止 TUI 直接导入 codex-core。

我觉得这是收尾迁移最漂亮的方式。清理一次依赖不难，但团队一大，迟早有人会把它加回去，除非 CI 出面拦住。feature flag 让切换可以循序渐进，lint 规则则确保没人能无意中把工作倒退回去。

我的几点思考#

看完这组观察，我最大的感受是：AI 让「写代码」变便宜了，但它没有让「工程」这件事变简单，反而让经典的工程素养变得更值钱了。

第一，速度和规范不是对立的，而是互相成就的。Codex 团队能在 8 倍提速的同时保持质量，靠的恰恰是那 38 条 lint、40% 的测试、以及一套「评审反馈 → AGENTS.md → CI 检查」的闭环。很多人以为上了 AI Agent 就可以砍掉测试和 review，这个例子恰恰说明，Agent 越多，越需要这些护栏。

第二，规则要「可执行」，而不是「写出来就完事」。AGENTS.md 里的每一条几乎都对应着一个具体的、Agent 容易犯的错误，而一旦规则稳定，就立刻下沉成 lint 或 CI 检查。这比写一堆漂亮的口号有用得多。

第三，测试策略要分层。开发时快、合并时严、上线后最严，这种「渐进式加严」的思路，是很多团队可以直接抄的作业。它解决的正是「测试太多拖慢开发」和「测试太少埋下隐患」这对老矛盾。

说到底，Codex 仓库给我们的启示可能很朴素：当「实现」的成本趋近于零，区分好团队和差团队的，反而回到了那些最经典的东西，测试、边界、抽象、lint，还有招到靠谱的人。这些东西在 AI 时代，不但没贬值，反而更值钱了。

参考来源：Learnings from the Codex repo（John Wang）