最近一个月，AI 大厂开始流行晒「80 万行代码」。
GitHub 晒 Copilot 自己改造自己，一位工程师带着一群智能体，把 Copilot 背后那套核心引擎整个重写成了 80 多万行 Rust。
谷歌晒Gemini 4 Argon，它正在把自家操作系统 Fuchsia 内核中的 80 多万行 C/C++ 代码迁移到 Rust。
轮到 OpenAI，画风突变。它晒出的 80 万行代码，是用 AI 删掉的。这波反向整活，有点绝。
5 位工程师，两周，用GPT-6 Astra在 Codex 里合并了 1400 多个 PR，删掉了 80 多万行代码。他们还顺手做了个对比，让更便宜的GPT-6.1 Sol和更贵的 Astra 在同一个仓库里找过期的功能实验代码，结果 Astra 找出 142 处，Sol 找出 131 处，然而 Sol 的成本只有 Astra 的七分之一。
重置哥这几天疯狂重置 Codex 额度，用哪个模型最划算，OpenAI 已经提前给你算好了。
清理代码这活儿，需要小心小心再小心，毕竟只要删错一行代码，生产环境就可能出事故。
10 月 14 日，OpenAI 核心工程师 Rodrigo Roim 发表了一篇长文，专门介绍 OpenAI 团队是怎么用GPT-6系列模型维护自家代码的。
清理代码的坑，他见过不少，「我记得有好几次事故，都是误删代码引起的。」来到GPT-6 Astra时代，他们只需要给 Codex 发送这么一段看起来有些随意的提示词。
帮忙找一下仓库里的死代码，清理掉。Slack、Statsig 尽管去查，别的地方需要的话也尽管查，确认这些代码确实已经没人用了，能清理就清理，能简化就简化。这么含糊的要求，上一代GPT-5.6 Sol只能做个半吊子，Astra 却一次搞定。它先翻看了一遍历史 PR，接着去 Slack 聊天记录里收集背景信息，还读了线上的性能分析数据，确认要删的代码一次都没被执行过。每删一处，它都写清楚了理由。
看 Astra 干得这么漂亮，5 位工程师用这段提示词的各种变体，把 OpenAI 多个代码仓库都扫描了一遍，文章开头那 1400 多个 PR 就是这么来的。仅一个服务的容器镜像，就缩小了快一半。
相较于过期的功能实验，清理死代码可能还容易点。功能实验早就完成了，代码和开关却还留在仓库里，有的甚至还在线上运行，仅凭静态分析很难判断是否可以安全清理。
Rodrigo 一开始也不知道从哪下手，于是他干脆让 Astra 先写了一段提示词小试牛刀。小范围测试结束，他给 Astra 提了一些反馈意见，再让它生成一版扫描整个仓库的提示词，同时计算每个过期实验占用的 CPU。结果 CPU 占用最大的那几个实验，都已经过期好几年了，一直没人发现。前前后后，他们总共清理了几百个功能实验和开关。
被清理的功能开关中，有一个是几年前 OpenAI 团队一位工程师为了方便内部测试创建的总开关，打开它就能一键覆盖所有新功能。代码只有很短的一行 Python，混在几百行长得差不多的开关映射里，普通到谁都不会多看它一眼。
Astra 一眼看出了问题。这行代码连带着所有功能，牵一发而动全身，CPU 占用小不了。但 Astra 没直接动手删除。它的判断是，「这个开关在管理后台被明确标成了永久，说不定还有运维上的用处。」所以它只把资源消耗计算清楚，交给人来决定删不删。
最终经过审查，OpenAI 团队把这个开关删了，受影响最大的那个主服务，CPU 成本预计节省 0.42%。
重置哥 Tibo 立下 28 天军令状后，隔三岔五就来一次全员额度重置。
OpenAI 自己，最近就认真算了算这笔 token 账。
Rodrigo 用同一段排查过期实验的提示词，分别让GPT-6 Astra和GPT-6.1 Sol各执行一遍，扫描一个有 100 多万行代码的仓库。两个模型用的都是 Ultra 模式，这是 Codex 最高档的推理强度，模型会召唤几十上百个子智能体当牛马，把复杂任务拆开并行执行。
结果，GPT-6 Astra总花费 109 美元，约合人民币 730 元。GPT-6.1 Sol只花了 15 美元，约合人民币 100 元，而它找到的过期实验数量，是 Astra 的 92%。
Astra 比 Sol 多找出 11 处过期实验，为此多花了 94 美元。成本是 Sol 的 7 倍多，多干的活儿不到 10%。
那么，你到底应该用 Sol 还是 Astra？答案是，具体任务具体分析。
国内专门做企业级智能体的特赞科技，就采用了这个思路。「按任务动态选择、编排模型，统一管理质量、成本、权限与合规。」
特赞基于这个思路搭建了一个系统级模型平台，取名Tezign Model Hub。平台接入了 30 多个基础模型，有特赞自研的，也有商业闭源的、开源的和私有化部署的。收到一个任务后，系统会先评估哪个模型最合适，必要时甚至可以多个模型一起上，任务完成后还会根据结果复盘，调整下一次遇到类似的任务该怎么选模型。
这次是更便宜的 Sol 更划算，换个任务就不一定了。在特赞看来，「便宜的 token 有时候比贵的更贵。」以 OpenAI 的账单为例，Sol 执行同样的任务，成本是 Astra 的七分之一，可要是得做 10 次才能得出一个可用的结果，总成本可能比 Astra 一次做对还高。
Rodrigo 只对比了两个模型，手动还算得过来。企业里几十个模型，成百上千个任务，靠人手动很难算得明白，这时候 Model Hub 可以替人来选出最佳模型。
你也有一个越写越臃肿的代码仓库？下面三段提示词也许可以帮到你。建议先上GPT-6.1 Sol+ Medium 推理强度试试，效果满意，又想扫描得更深入，再往上调。
/goal启动 Codex 目标任务。
/goal 查看最近所有的 CI 运行记录，找出不稳定的测试，每个都试着修复一下，修好了就提交一个 PR。先挑简单的修，修复方法要明确，用不着把每个不稳定的测试都修好。AGENTS.md 是你写给智能体的项目说明，Codex 每次开工前都会先读一遍，里面有一条写得不准确，它就可能一路跑偏。
查看一下我最近的 Codex 会话，看看 AGENTS.md 里有没有哪条指令把智能体带偏了，或者让它白干活，挑一条出来。再找到出问题那次会话的第一条提示词，用同一个仓库快照、同一个模型，把这段提示词分下面两种情况各运行一遍。1. AGENTS.md 里的这条指令保持原样；2. 只删掉或者改好这一条指令。 对比两次的完成质量、智能体的做法、工具调用、token 用量、耗时和成本。最后把这条指令贴出来，告诉我修改以后有没有用。CI 太慢，也可以先问问 Codex 有什么办法，让它把每个方案能省多少时间计算出来。
给这个仓库的 CI 减负，你有哪些思路？把思路列成一张表，根据这个仓库的 CI 运行记录，估算每条思路每天能省下多少分钟的 CI 时间，按省下的时间从多到少排。这段提示词 OpenAI 官方认证有效。按照 Codex 给出的建议，OpenAI 团队合并了约 30 个优化 PR，每次 CI 的耗时中位数从 10 分钟降到了 4.5 分钟。
Rodrigo 在博文开头这样写道，AI 智能体让他们代码写得更快，但要维护的代码也跟着变多了。
一位网友出了个主意，「有智能体每天往仓库里加代码，那也应该有一个智能体每天删代码。」
机智。
谢谢你能看到这里。我是木易，每天帮你先一步看见 AI。这篇如果有用，顺手点个赞和在看，转给身边用 AI 的朋友。想第一时间收到更新，给我加个星标⭐。我们明天见。
