代码写得越快，后续维护的工作也越多。OpenAI 核心实验团队的 Rodrigo Roim 分享了他们怎样用 Codex 清理旧代码、排查过时实验和加速测试，连实际使用的提示词与模型成本对比也一并给了出来。以下为全文翻译，文中的“我”和“我们”均指原作者及其团队。
OpenAI 核心实验团队如何用 Codex 删除闲置代码、清理过时实验，并改进 CI。
每个不断扩大的代码库都需要维护：删掉不用的代码，清理已经结束的实验，修复测试。在 OpenAI，编程 Agent 帮我们加快了开发速度，也让维护需求随之增加。
我在 OpenAI 的核心实验团队（Core Experimentation）工作。我们构建和维护的软件，为全公司的实验提供支持，覆盖从前端更新到模型推理服务效率优化的各个环节。
GPT-6 Astra 发布后，我们开发和维护软件的速度进一步提高；GPT-6.1 Sol 则以更低的成本取得了相近的效果。这篇文章会介绍我们怎样用这些模型寻找值得清理的地方、收集证据，并准备好改动交给团队评审。
删除不再使用的代码
在 Agent 编程出现之前，许多软件工程团队依赖复杂的静态分析系统，再结合运行时日志，来发现并删除不再使用的代码。即使有这些系统，又做了仔细的代码评审，仍然会出错。我就记得好几次因误删代码而引发的故障。需要考虑的边界情况太多了：反射可能干扰静态分析，一条看似无人使用的代码路径，也可能是留着在未来故障发生时启用的应急手段。
在 Codex 中使用 GPT-5.6 Sol 时，我可以指定一个排查范围，给出明确的验证标准，然后让模型编写静态分析逻辑、删除死代码。与现有静态分析系统相比，这些针对性提示词更容易编写和维护，可靠性也相近。
拿到 GPT-6 Astra 后，我们想看看，能不能只给它一个更宽泛的要求，让它自己判断该去哪里找，以及需要什么证据才能证明每一处删除是合理的。我们先给 Codex 写了一条很短的提示词，它对 GPT-5.6 Sol 来说过于含糊，后者无法完整处理。下面就是这条提示词，连原来的笔误也保留着：
请帮我找出并清理仓库里的死代码。你可以查看 Slack、Statsig［我们使用的功能开关与实验平台］，或者其他任何需要的来源，确认这些东西确实已经不用了，可以删除或简化。Astra 很好地处理了这种模糊性。它查看过去的 PR，从 Slack 讨论串里收集背景，还查阅内部项目跟踪记录。它读取生产环境的性能剖析表，确认被删除的代码行从未被执行。Astra 还解释了每一处删除的理由，加快了我们的评审。
看到 Astra 的表现后，5 名工程师一起在不同仓库中运行了这条提示词的不同版本。我们合并了超过 1,400 个拉取请求（PR），删除了超过 80 万行代码。大部分工作是在两周内利用零散时间完成的，当时我们主要还在做其他项目。代码评审则分给了了解相应项目的各个团队。这些删除带来了可衡量的收益。例如，一个服务的容器镜像从 3.31GB 缩小到 1.72GB，减少了 48%；另一组清理则从测试套件中移除了约 400 个视觉快照变体。
找出早该清理的实验
软件维护里更难的一件事，是清理早已失去用途的实验。它们未必完全没有使用：代码可能仍在生产环境中运行，也可能依赖随时会变化的资格判定，这让静态分析难得多。过去，我们用确定性的静态分析配合数据库查询来清理这些实验，再用当时最强的模型 GPT-5.6 Sol 编写和改进相关脚本。我们知道，这套方法会产生不少漏报，确实已经过时的实验也可能识别不出来。
用 GPT-6 Astra 清理死代码取得成效后，我决定再用一条短提示词试试清理过时实验。一开始我也不确定从何入手，于是先和 Astra 一起讨论，让它写一条可以在新会话中试用的短提示词：
找出并删除项目 {A} 和 {B} 中，与已经过时、取值固定的 Statsig 功能开关／配置，或已放弃的实验相关的大块死代码。核实线上当前生效的 Statsig 配置，检查 Git 历史和涉及相同改动的 PR。保持生产环境行为不变，保留运维保障，以及用作紧急关闭开关等用途的功能开关／配置。忽略 SDK 回退值和本地覆盖配置。每项清理分别创建一个小型草稿 PR，并在摘要中附上对应的 Statsig 配置控制台链接。Astra 遵守了提示词里的保护要求，准备好改动，并附上团队可以评审的证据。我在它的 PR 中留下评论，再让它阅读这些评论、吸收反馈，写出一条用于扫描整个代码库的新提示词。我担心找到的待清理项太多，却不知道该先处理哪一项，因此也请 Astra 帮忙。它给出了下面这条提示词：
/goal 找出整个仓库中每一个已经过时、取值固定、被放弃或已全面上线的 Statsig 功能开关、配置、实验和实验层，前提是删除它们不会改变生产环境行为。审查所有 Statsig 项目及其对象清单，不要只看标记为过时的对象。
通过枚举、常量、封装、别名、schema、动态拼接的名称以及跨服务调用方，查找间接使用。逐一核对生产代码所引用的所有常量；不要只列出一份保守的候选短名单就停下。
考虑每个对象使用的云资源，包括 CPU。能取得生产遥测和性能剖析数据时，用它们找出开销较大的无效检查。
［原文为简洁起见省略了以下内容：Astra 生成的详细说明，涉及如何验证生产行为、优先处理较旧对象、保留有意设置的保护措施，以及理解 SDK 回退行为。］
生成一份 Markdown 报告，按可以并行处理的归属团队／文件工作流，对所有已核实的候选项分组。列出生产环境取值、证据、负责人、调用位置，以及能够取得的实际求值开销或 CPU 开销。
不要修改线上配置或服务。生成的报告很有希望。Astra 利用我们的监测工具，调查了每个过时实验的 CPU 开销。排在最前面的几项带来了很大的效率提升，而这些实验多年来一直没人发现早已过时。我仔细核实了这些收益较大的发现，随后展开完整清理，移除了数百个实验和功能开关。
有个例子很能体现 Astra 的判断。几年前，我们的一名工程师创建了一个 Statsig 功能开关，让内部开发者可以覆盖所有与新功能有关的其他开关，以便测试。实现这一配置，只用了一行 Python 代码，把这个开关映射到所有其他功能。这行代码夹在数百条类似的功能开关映射中，很不起眼。
Astra 发现，上面这行代码由于映射到了全部功能，造成了显著的 CPU 扇出开销。它调查了这部分 CPU 成本，但没有直接处理，而是提交给人来评审：这个开关在功能开关管理控制台里被明确标为“Permanent”（永久），可能仍有运维用途。评审后，我们删除了这个开关，估算为主要受影响的服务节省了 0.42% 的 CPU。
用 GPT-6.1 Sol 提高成本效益
最近，我们又在相同工作流上测试了 GPT-6.1 Sol，看看它能否以更高的效率，达到 GPT-6 Astra 的效果。
为了比较不同模型清理过时实验的能力，我把上面的同一条提示词交给不同的模型与推理强度组合，让 Codex 审查某个仓库中的指定子目录，找出过时实验。这些子目录覆盖 6,000 多个文件、100 万行代码，涉及 Python、TypeScript、Go 和 Rust。我逐项评审并验证了结果。下图展示了 3 种模型与推理强度组合的表现：
过时实验清理对比
API 费用：GPT-6 Astra Ultra 为 109.06 美元，GPT-6.1 Sol Ultra 为 15.12 美元，GPT-6.1 Sol Medium 为 5.27 美元。
发现的清理项：GPT-6 Astra Ultra 为 142 项，GPT-6.1 Sol Ultra 为 131 项，GPT-6.1 Sol Medium 为 86 项。
每个清理项的平均费用：GPT-6 Astra Ultra 为 0.77 美元，GPT-6.1 Sol Ultra 为 0.12 美元，GPT-6.1 Sol Medium 为 0.06 美元。
费用按标准 API 价格计算，包括研究子 Agent，以及 Codex 为完成各项目标而自动执行的后续轮次。
在这次对比中，GPT-6.1 Sol Ultra 找到的清理项数量达到 GPT-6 Astra Ultra 的 92%，API 费用则只有后者的 14%。GPT-6.1 Sol Medium 找到并通过评审的清理项更少，费用也更低。
我查看了不同模型与推理强度组合之间的差异，发现了一些规律。例如，在 Ultra 强度下，两种模型的大部分差异，都来自那些取值固定、又被其他功能开关用作依赖的开关。GPT-6 Astra 找到了它们，GPT-6.1 Sol 却漏掉了。
找出这样的错误模式，有助于我们编写提示词进行纠正，让成本更低的模型也能取得接近更贵模型的结果。不过，新模型发布后，这些修正也可能不再需要，所以每次有新模型推出，都值得重新检查提示词。
其他可以尝试的方向
我用 Codex 得到的一些最喜欢的发现，起点就是下面这样的短提示词。可以先用 GPT-6.1 Sol Medium 试试；如果效果不错，再考虑提高推理强度，扩大审查范围。
修复不稳定测试（flaky tests）：
/goal 查看最近所有 CI 运行记录，找出不稳定测试。对每项不稳定测试，尝试修复，成功后提交一个 PR。你的任务是为简单问题找到明确的修复办法，而不是把每一个不稳定测试都彻底修好。改进 Agent 的上下文：
查看我最近的 Codex 会话，找出一条看起来误导了 Agent 或造成了多余工作的 AGENTS.md 指令。选取出现该问题时会话最初的提示词。从相同的仓库快照出发，使用相同模型，把这条提示词重放两次：
1. 保持当前 AGENTS.md 指令不变。
2. 只移除或修正这一条指令。
比较任务质量、Agent 行为、工具调用、token 用量、运行时间和费用。展示这条指令，并说明更新它是否有帮助。降低持续集成（CI）的成本和运行时间：
你有哪些办法可以减轻这个仓库的 CI 负载？把想法列成一张表，并依据这个仓库的 CI 运行历史，按估算每天可以节省的 CI 分钟数，为所有想法排序。最后这个想法帮助我们缩短了 CI 时间。运行这条提示词并跟进建议后，我们合并了约 30 个 CI 优化 PR。CI 完成时间的中位数从大约 10 分钟降到 4.5 分钟，第 90 百分位则从 12.5 分钟降到 6 分钟。在后来的一次修复中，补上一个缺失的 mock，又让一组包含 63 项测试的解析器测试套件，从 592.6 秒缩短到 29.8 秒，耗时减少了 95%，全部 63 项测试都保留了下来。
从小处开始，评审后再扩大范围
GPT-6 系列改善了核心实验团队大规模维护软件的方式，也带来了多方面的效率提升。
到目前为止，我们团队已经合并了超过 1,400 个由 GPT-6 建议发起的维护 PR。它们带来了更快的测试、更小的镜像、更低的 CPU 占用，以及许多其他收益。不过，有些建议引入的复杂度超过了预期收益，因此，确定优先级和衡量效果始终是工作流的重要部分。
在较大的代码库中，GPT-6 模型能找出的优化项很容易多到让人应接不暇。借助监测工具和上面介绍的提示词方法，Codex 帮我们排出了这些改进的优先级。
如果你也想在自己的代码库里试试，我建议先从一项小型维护任务开始：一段不用的代码、一个过时的功能开关，或者一项不稳定测试。让 Codex 找出一个实例，收集证据，再提出一个小型草稿 PR。针对这项小任务，比较不同模型和推理强度，因为更便宜的配置可能就够了。
小范围尝试取得好效果后，再扩大到一个子目录，或一个边界清楚的项目。每一步都让 Codex 把你的代码评审意见吸收到下一条提示词中。等你对模型的表现有了把握，再扩展到整个代码库。
我们的核心实验团队正在招聘工程、数据科学和产品管理岗位。如果这篇文章让你感兴趣，欢迎通过我们的招聘页面申请！
参考链接
-
原文：https://developers.openai.com/blog/maintaining-software-with-the-gpt-6-family