OpenAI反向整活！5人两周狂删80万行代码，便宜模型竟更香！
最近一个月，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 分钟。
主题：代码|GPT-6Astra