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 来说过于模糊，无法完全处理。就是下面这段，连拼写错误都保留着：

GPT-6 Astra

Can you help identify and clean up dead code in the repo please, feel free to check slack,
statsig [a feature flag and experimentation platform we use], or any other source you need to
confirm that things are indeed no longer being used and can be cleaned up or simplified

Astra 很好地处理了这种模糊性。它查看了过去的 PR，从 Slack 讨论串中收集上下文，并检查了内部项目跟踪器。它阅读了生产性能分析表，以确认被删除的代码行从未被执行到。Astra 还解释了每次删除的理由，这加快了我们的审查速度。

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

追踪过期的实验

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

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

GPT-6 Astra

Find and remove substantial dead code associated with stale, constant Statsig gates/configs or
abandoned experiments in projects {A} and {B}. Verify live Statsig configuration and check git
history and overlapping PRs. Preserve production behavior, operational safeguards and
gates/configs intended as killswitches or similar. Ignore SDK fallbacks and local overrides.
Create one small draft PR per cleanup, linking its Statsig configuration console link in the
summary.

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

GPT-6 Astra

/goal Find every stale, constant, abandoned, or fully shipped Statsig gate, config, experiment,
and layer present in this entire repository that can safely be removed with no production
changes. Audit all Statsig projects and inventories, not just objects labeled stale.
Find indirect usages through enums, constants, wrappers, aliases, schemas, dynamically assembled
names, and cross-service consumers. Reconcile every production-referenced constant; do not stop
after producing a conservative shortlist.
Consider each object's cloud resource usage, including CPU. Use production telemetry and
profiles where available to identify expensive dead checks.
[Omitted for brevity: detailed instructions, generated by Astra, on verifying production
behavior, prioritizing older objects, preserving intentional safeguards, and interpreting SDK
fallbacks.]
Produce a markdown report grouping all verified candidates into parallelizable ownership/file
workstreams, including production values, evidence, owners, callsites, and observed evaluation
or CPU costs if available.
Do not modify live configurations or services.

生成的报告很有前景。利用我们的埋点数据，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 种模型/努力程度组合的结果：

在这项比较中，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 试试它们，如果结果有前景，可以考虑加大投入以进行更广泛的审计。

修复不稳定的测试：

GPT-6.1 SolMedium

/goal Look at all recent CI runs to find flaky tests. For each flaky test, try a fix and if
successful put up a PR. Your job is to find clear fixes to simple issues, not to exhaustively
fix every flaky test.

改进智能体上下文：

GPT-6.1 SolMedium

Look through my recent Codex sessions and find one AGENTS.md instruction that appears to have
misdirected an agent or caused unnecessary work. Choose the original session prompt where that
happened. Replay that same prompt twice from the same repository snapshot and model:
1. With the current AGENTS.md instruction unchanged.
2. With only that one instruction removed or fixed.

Compare task quality, agent behavior, tool calls, token usage, runtime, and cost. Show the
instruction and whether updating it helped.

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

GPT-6.1 SolMedium

What ideas do you have to relieve CI load in this repository? List your ideas in a table and
rank all of them by estimated CI minutes saved per day based on this repo's CI run history

最后一个想法帮助我们缩短了 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 团队正在招聘工程、数据科学和产品管理方面的人才。如果这篇文章让你感到兴奋，请通过我们的招聘页面申请！