OpenAI官方文档:我们的核心实验团队如何使用 Codex 删除无用代码、清理过时实验并改进 CI

每个不断发展的代码库都需要维护：删除无用代码、清理已经完成的实验、修复测试。过去，编码代理帮助我们更快地构建软件，但这也增加了维护工作的需求。

我在 OpenAI 核心实验团队工作，我们负责构建和维护支持全公司实验的软件，工作内容包括前端更新以及提升模型服务效率。

GPT-6 Astra 的发布帮助我们更快地构建和维护软件，而 GPT-6.1 Sol 也取得了类似的效果，同时成本更低。在这篇文章中，我将分享我们如何使用这些模型发现清理机会、收集证据，并准备好供团队审查的代码变更。

删除无用代码

在使用智能编码代理之前，许多软件工程团队依靠与运行时日志集成的复杂静态分析系统，来检测并删除无用代码。

即使有这些系统和严格的代码审查，错误仍然会发生。我记得曾经发生过几起因误删代码而导致的问题。

需要考虑的边界情况太多了：例如，反射机制可能干扰静态分析，或者某条看似无用的代码路径实际上可以在未来用于缓解事故。

使用 Codex 中的 GPT-5.6 Sol 时，我可以指定一个需要调查的区域和明确的验证标准，然后让模型编写静态分析逻辑并删除死代码。

这些有针对性的提示词比我们现有的静态分析系统更容易开发和维护，同时可靠性相近。

当我们获得 GPT-6 Astra 后，希望了解它能否根据更宽泛的请求自主判断应该查看哪些地方，以及需要收集哪些证据来证明每次删除都是合理的。

我们先从一条简短的 Codex 提示词开始。这条提示词对 GPT-5.6 Sol 来说过于模糊，无法完全处理。下面是原文，包括其中的拼写错误：

Astra 很好地处理了其中的模糊之处。它查看了过去的 PR，收集了 Slack 讨论串中的背景信息，还检查了内部项目跟踪系统。它读取了生产环境的性能分析表，以确认被删除的代码行从未被执行。

Astra 还解释了每次删除的理由，从而加快了我们的审查速度。

看到 Astra 的表现后，五名工程师开始在不同代码库中协作运行这条提示词的多个变体。最终，我们合并了 1,400 多个拉取请求，删除了超过 80 万行代码。

我们主要利用两周中的业余时间完成了这项工作，同时仍以其他项目为主。代码审查被分发给不同团队，并附带每个受影响项目的背景信息。

这些删除带来了可衡量的收益。例如，一个服务的容器镜像从 3.31 GB 缩小到 1.72 GB，减少了 48%；另一批清理工作则从测试套件中删除了大约 400 个视觉快照变体。

查找过时实验

软件维护中更困难的问题之一，是清理过时的实验。这些实验不一定完全没有被使用：相关代码可能仍在生产环境中运行，或者依赖于随时可能变化的资格评估条件，因此很难进行静态分析。

过去，我们通过确定性静态分析配合数据库查询来清理过时实验，并使用当时能力最强的模型 GPT-5.6 Sol 来构建和改进相关脚本。我们知道，这种方法会产生很多漏报，因为分析系统无法识别所有真正已经过时的实验。

鉴于使用 GPT-6 Astra 清理死代码取得了成功，我决定用另一条简短的提示词来处理过时实验。我当时还不确定应该如何开始，于是先和 Astra 进行头脑风暴，并让它为新的对话写一条简短提示词：

Astra 遵循了提示词中的安全要求，并准备了带有证据的代码变更，供团队审查。我在它提交的 PR 中留下评论，然后让 Astra 查看这些评论、整合我的反馈，并为扫描整个代码库设计一条新的提示词。

我担心需要清理的项目太多，没有办法确定优先级，因此也请 Astra 帮助我处理这个问题。它建议使用下面这条提示词：

使用 GPT-6.1 Sol 提高成本效益

最近，我们在相同的工作流程中测试了 GPT-6.1 Sol，想了解它能否以更高的效率达到 GPT-6 Astra 的效果。

为了比较不同模型在清理过时实验方面的表现，我使用了上面的同一条提示词，并测试了不同的模型和推理强度组合。

我让 Codex 审计代码库中的特定子目录，查找过时实验。这些子目录包含超过 6,000 个文件和 100 万行代码，涉及 Python、TypeScript、Go 和 Rust。我审查了模型的发现并进行了验证。下图展示了三种模型/推理强度组合的结果。

在这次比较中，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 尝试它们；如果结果有潜力，再提高推理强度，进行范围更广的审计。

修复不稳定测试

改进智能代理上下文

降低持续集成的成本和运行时间

最后这个想法帮助我们减少了 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 将你的代码审查反馈整合进下一版提示词。当你对模型的表现有足够信心后，再扩展到整个代码库。