OpenAI 团队分享如何用 GPT-6 系列模型维护大型代码库

每个不断增长的代码库都需要维护：移除无用代码、清理已完成的实验、修复测试。在 OpenAI，编码智能体帮助我们更快地构建，这也增加了我们的维护需求。

我在 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 表现如此出色后，五名工程师协作在各个代码库中运行该提示的变体，我们合并了 1400 多个拉取请求，删除了超过 80 万行代码。我们主要是在从事其他项目的同时，利用两周的业余时间完成了这部分工作的大部分。代码审查被分派给各个团队，并附上每个受影响项目的相关背景。这些删除带来了可衡量的收益。例如，某个服务的容器镜像从 3.31GB 缩小到 1.72GB，减少了 48%；另一组清理则从我们的测试套件中移除了约 400 个视觉快照变体。

追查过时的实验

软件维护中一个更难的问题是清理过时的实验。这些实验未必是无用的：它们的代码可能仍在生产环境中运行，或者依赖于随时可能变化的资格评估，这使得静态分析困难得多。过去，我们团队通过确定性的静态分析并辅以数据库查询来清理过时实验，并使用我们最强大的模型（当时是 GPT-5.6 Sol）来构建和改进相关脚本。我们知道这导致了许多假阴性，即我们的分析无法识别出真正过时的实验。

鉴于我们使用 GPT-6 Astra 清理死代码的成功经验，我决定再试一个简短的提示词来处理过期的实验。我不确定该如何开始，于是和 Astra 一起头脑风暴，并让它写一个简短的提示词，以便在新线程中试用：

Astra 遵循了提示词中的安全措施，并准备了带有证据的变更供我们团队审查。我在它的拉取请求上发表了评论，然后让 Astra 查看我的评论、采纳我的反馈，并制定一个新的提示词来扫描我们的整个代码库。我担心要清理的东西太多、无法排定优先级，所以我也让 Astra 帮我解决这个问题。Astra 建议了以下提示词：

生成的报告很有前景。利用我们的埋点数据，Astra 调查了每个过期实验的 CPU 开销，排名靠前的几个结果都是巨大的效率收益，而这些实验多年来一直无人认定为过期。我仔细验证了那些较大的结果，并继续进行了全面清理，移除了数百个实验和功能标志。

有一个例子体现了 Astra 的判断力：几年前，我们的一位工程师创建了一个 Statsig 功能标志，允许内部开发者覆盖我们所有其他与新功能相关的功能标志，用于测试目的。这个配置通过一行 Python 代码实现，将那个标志映射到所有其他功能。这行代码与数百个类似的功能标志映射放在一起，看起来毫不起眼。

Astra 发现上面那行代码导致了显著的 CPU 扇出，因为它将该标志映射到了所有功能。它调查了 CPU 开销，但将这一发现提交人工审查，因为该标志在我们的功能标志管理控制台中被明确标记为“永久”，并且可能仍有运维用途。经过审查，我们移除了该标志，预计在受影响的主要服务中节省了 0.42% 的 CPU。

用 GPT-6.1 Sol 提升成本效益

最近，我们在相同的工作流上测试了 GPT-6.1 Sol，看它能否在更高效的同时达到 GPT-6 Astra 的效果。

为了在过期实验清理上比较这些模型，我在不同的模型/推理强度组合上运行了上面相同的提示词，让 Codex 审计我们某个代码库中的特定子目录，以找出过期实验。这些子目录涵盖 6,000 多个文件、100 万行代码，涉及 Python、TypeScript、Go 和 Rust。我审查了这些发现以进行验证。下图显示了 3 种模型/推理强度组合的结果：

在这次比较中，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 个测试的 resolver 套件的运行时间从 592.6 秒缩短至 29.8 秒——减少了 95%，且全部 63 个测试均得以保留。

从小处着手，审查，再扩展

GPT-6 系列改善了我们的 Core Experimentation 团队大规模维护软件的方式，并带来了多项效率提升。

到目前为止，我的团队已经合并了 1,400 多个源自 GPT-6 提议的维护性 pull request。这带来了更快的测试执行、更小的镜像、更低的 CPU 利用率以及许多其他好处。然而，有些提议带来的复杂性超过了其预期收益所能证明的合理性，因此优先级排序和度量仍然是我们工作流程中的重要组成部分。

在更大的代码库中，我们发现很容易被 GPT-6 模型所能发现的优化数量所淹没。借助插桩和上文分享的提示词技巧，Codex 帮助我们确定了这些改进的优先级。

如果你想在自己的代码库中尝试这一点，我会从一个小型维护任务开始：一些未使用的代码、一个过时的功能开关，或者一个不稳定的测试。让 Codex 找到一个实例、收集证据，并提交一个小型草稿 PR。针对这个小任务比较不同的模型和投入程度，因为更便宜的配置可能就足够了。

一旦小规模尝试效果良好，就将其扩展到某个子目录或范围明确的项目。在每一步中，让 Codex 将你的代码审查反馈纳入下一个提示词。当你对模型的表现有信心时，再扩展到整个代码库。

我们的 Core Experimentation 团队正在招聘工程、数据科学和产品管理方面的人才。如果这篇文章让你感到兴奋，请通过我们的招聘页面申请！