GPTMap

OpenAI 自家用 GPT-6 家族维护软件:1,400+ 维护 PR、80 万行死代码与一次 92%/14% 的模型对比

OpenAI Core Experimentation 团队工程师在官方开发者博客发布《Maintaining software with the GPT-6 family》:GPT-6 Astra 从含错别字的短 prompt 出发清理死代码,5 名工程师两周兼职合入 1,400+ 个 PR、删掉 80 万余行;同工作流对比中 GPT-6.1 Sol Ultra 以 14% 的 API 成本产出 Astra Ultra 92% 的发现。

TL;DR
OpenAI Core Experimentation 团队工程师在官方博客发布《Maintaining software with the GPT-6 family》(页面日期 2026-10-14):GPT-6 Astra 从含错别字的短 prompt 出发清理死代码,查 PR、Slack、Statsig 与 profiling 表取证,5 人两周兼职合入 1,400 余个 PR、删 80 万余行,一个容器镜像 3.31GB 缩到 1.72GB;同任务对比中 GPT-6.1 Sol Ultra 以 14% 成本($15.12 对 $109.06)拿到 Astra Ultra 92% 的发现;约 30 个 CI 优化 PR 把中位 CI 时间从约 10 分钟降到 4.5 分钟。
《Maintaining software with the GPT-6 family》是 OpenAI 开发者博客上由 Core Experimentation 团队工程师署名的工程实践文(页面日期 2026-10-14),记录该团队用 GPT-6 Astra 与 GPT-6.1 Sol 在 Codex 里做死代码清理、陈旧实验下线与 CI 提速的完整工作流,并给出三种模型/effort 组合在同一任务上的成本与产出对比。文中所有数字均为官方自报,未经第三方核验。

OpenAI 的模型营销文案见过很多,官方工程师写自己怎么用这些模型维护内部软件的第一人称复盘少见。《Maintaining software with the GPT-6 family》发布在 developers.openai.com 博客,页面日期 Oct 14, 2026,作者是 Core Experimentation 团队工程师——一支「构建并维护支撑全公司实验的软件」的队伍。本站 2026-10-18 抓取全文,下文所有数字均出自原文,且全部是官方自报口径。

死代码清理:一句带错别字的 prompt 顶掉自研静态分析

文章的第一幕是死代码。作者回忆,团队过去靠复杂的静态分析系统加运行时日志找无用代码,仍会误删。转折点是 GPT-5.6 Sol 时代——定向 prompt 加清晰验证标准,让模型自己写静态分析并删代码,可靠性相当且更好维护。到 GPT-6 Astra,他们把门槛进一步降低:一句带着「feel free to check slack, statsig」错别字的短 prompt,直接丢给模型。

Astra 的取证路径是这篇文章最有信息量的部分:翻过往 PR、读 Slack 线程、查内部项目跟踪器、读生产性能 profiling 表确认被删代码确实不可达——并为每处删除解释理由。随后 5 名工程师在多个仓库跑这个 prompt 的变体,两周内以兼职方式合入超过 1,400 个 PR,删除超过 80 万行代码。官方给出的可度量收益:一个服务的容器镜像从 3.31GB 缩到 1.72GB(降 48%);另一批清理从测试套件里移除约 400 个视觉快照变体。

陈旧实验:让 Astra 自己写审计 prompt

第二幕更难——陈旧实验不一定无代码在跑,删错会破坏生产。作者先与 Astra 头脑风暴,让模型自己写一段 /goal 形式的审计 prompt:全库扫描 Statsig 门、配置、实验与 layer(包括枚举、常量、包装器、别名、动态拼名等间接引用),核对生产取值,保留 killswitch 类安全配置,「不要在产出保守短名单后就停下」。

结果:清出数百个实验与特性标志。文章给了个能看出模型判断力的案例——多年前一位工程师写的单行 Python 代码,把一个内部覆盖标志映射到全部其他标志。这行混在数百行相似映射里的代码造成显著 CPU 扇出;Astra 查了 CPU 成本,但因为该标志在管理台被标为「Permanent」而主动上交人工复核;复核后移除,主受影响服务估计节省 0.42% CPU。

同任务模型对比:6.1 Sol Ultra 用 14% 成本拿到 92% 发现

第三幕是成本。作者在同一工作流上对比了三种模型/effort 组合,对象是一个覆盖 6,000 余文件、100 万行 Python/TypeScript/Go/Rust 代码的子目录集,人工复核全部发现:

组合API 成本发现数单发现成本
GPT-6 Astra Ultra$109.06142$0.77
GPT-6.1 Sol Ultra$15.12131$0.12
GPT-6.1 Sol Medium$5.2786$0.06

官方口径:GPT-6.1 Sol Ultra 产出 Astra Ultra 92% 的发现,只花 14% 的 API 成本;Medium 更便宜但发现更少。成本按标准 API 定价计算,包含 research subagents 与 Codex 为达成目标自动运行的跟进步骤。差异模式也有交代:Ultra 档两模型的发现差异多来自「被其他标志当作依赖的常量特性标志」——Astra 能识别、6.1 Sol 会漏。官方的建议是把这些误差模式写进 prompt 修正,同时提醒新模型发布会让修正过期。

CI 提速与官方自己的告诫

文末把同一方法论推到 CI:让模型按「预估每日节省 CI 分钟数」排序降载点子,落地约 30 个优化 PR 后,中位 CI 完成时间从约 10 分钟降到 4.5 分钟,p90 从 12.5 分钟降到 6 分钟。一个单独的修复——给解析器套件补上缺失的 mock——把 63 个测试的运行时间从 592.6 秒压到 29.8 秒(降 95%,63 个测试全部保留)。

文章没有把成效写成神话:官方明说部分提案的复杂度超出了预期收益,优先级排序与度量始终是工作流的一部分;大代码库里,模型能找出的优化多到让人消化不了,团队靠 instrumentation 与分优先级来避免被淹没。

下一步

  • 想复用的团队:文中三段 /goal prompt(flaky 测试修复、AGENTS.md 指令审计、CI 降载清单)在原文里可直接复制,官方建议从 GPT-6.1 Sol Medium 起步、有前景再加 effort。
  • 追模型选型的:本站GPT-6 家族扩容:gpt-6-sol、gpt-6-luna、gpt-6.1-sol 进驻官方 SDK,dots 与 Intelligent UI 同窗亮相有四个模型 ID 在两包 SDK 枚举中的类型层事实,本文补上了它们在真实任务上的官方自报成本面。
  • 引用提醒:文中全部数字为 OpenAI 官方自报(含 0.42% CPU 这类内部估计),第三方无法复核,引用时注明口径。

关键要点

  • 作者来自 OpenAI Core Experimentation 团队,文章发布于 developers.openai.com 博客,页面日期 Oct 14, 2026(本站 2026-10-18 抓取全文);两个模型主角是 GPT-6 Astra 与 GPT-6.1 Sol,历史基线是 GPT-5.6 Sol
  • 死代码清理:起点是一句带错别字的短 prompt(原文允许查 Slack、Statsig 等)。Astra 查过往 PR、Slack 线程、内部项目跟踪器,并读生产性能 profiling 表确认被删行确实不可达;之后 5 名工程师在多个仓库跑该 prompt 的变体,两周内以兼职方式合入超过 1,400 个 PR、删除超过 80 万行
  • 官方自报的可度量收益:一个服务的容器镜像从 3.31GB 缩至 1.72GB(降 48%);另一批清理从测试套件中移除约 400 个视觉快照变体
  • 陈旧实验清理:Astra 受邀自写审计 prompt(/goal 形式),全库扫描 Statsig 门、配置、实验与 layer 的间接引用;清出数百个实验与特性标志。典型案例:一行把内部覆盖标志映射到全部其他标志的 Python 代码被 Astra 定位为 CPU 扇出源——因该标志在管理台被标为「Permanent」而先交人工复核,复核后移除,主受影响服务估计节省 0.42% CPU
  • 同任务模型对比(一个覆盖 6,000+ 文件、100 万行 Python/TypeScript/Go/Rust 代码的子目录集):GPT-6 Astra Ultra 成本 $109.06、142 个发现、单发现 $0.77;GPT-6.1 Sol Ultra $15.12、131 个、$0.12;GPT-6.1 Sol Medium $5.27、86 个、$0.06。官方口径:6.1 Sol Ultra 以 14% 的成本产出 Astra Ultra 92% 的发现;成本按标准 API 定价计,含 research subagents 与 Codex 自动跟进步骤
  • CI 提速与告诫:把同一思路用于 CI 负载分析后落地约 30 个优化 PR,中位 CI 完成时间从约 10 分钟降至 4.5 分钟、p90 从 12.5 分钟降至 6 分钟;一个补 mock 的修复把 63 个测试的解析器套件运行时间从 592.6 秒降至 29.8 秒(降 95%,63 个测试全部保留)。官方同时告诫:部分提案的复杂度超出预期收益,优先级排序与度量始终是工作流的一部分

常见问题

它们是 OpenAI 官方工程师的自报数字:来源是开发者博客原文,本站 2026-10-18 抓取全文逐字核对过引用部分,但没有任何第三方能复核其内部度量(profiling 表、Slack 取证、CI 统计都在 OpenAI 内网)。把它当官方一手案例数据读,而不是可独立复现的基准。

官方参考

相关文章

订阅 GPTMap Weekly

每周一封邮件,精选 OpenAI 重要更新、深度解读与最佳实践。无广告,可随时退订。

提交后将在新标签页打开 Buttondown 完成订阅确认。

GPTMap Editorial发布于 2026-10-18 7 分钟阅读