GPT-6 Astra 代码审查评测：收益、隐私与成本

代码审查中最困难的工作往往发生在变更行之外。一处改动在孤立环境下看起来正确，却仍有可能破坏系统中其他位置的代码。

这正是我们初步测试 OpenAI GPT-6 Astra 最有意思的地方。在我们的评测中，Astra 通过可操作的发现（actionable findings）捕获了约 4% 的标签 bug，比 GPT-5.6 Sol 多 22%，比 Opus 5 多。

最大的提升出现在更难的跨文件审查场景，Astra 在这些场景中的优势比 Sol 高出 20%，比 Opus 5 高出 33%。在客户规模上使用这一能力，同时也意味着要保护客户数据并评估模型公开 API 的定价。

Astra 为代码审查带来了什么

我们这里的衡量指标是可操作 bug 覆盖率（actionable bug coverage），即模型通过开发者可操作的发现捕获了多少标签 bug。

覆盖率保留一位小数；相对收益使用未舍入的值。

在这一首个评测指标中，相比 GPT-5.6 Sol 的整体收益看起来不大。该评测也包含了更简单的审查，这些简单审查可能留给更强模型差异化表现的空间更小；Astra 的更大优势出现在更难的跨文件子集上。这是一个早期的、方向性的结果。

覆盖率保留一位小数；相对收益使用未舍入的值。由于审查难度与整体评测不同，请在本图表内进行模型对比。

这个更难的跨文件对比更令人鼓舞。Astra 的相对优势扩大到比 Sol 高 20%，比 Opus 5 高 33%。这表明，将变更意图与分布在代码库中的后果联系起来是有价值的。

这些结果描述的是审查表现的一个方面。它们不能建立审查质量的总体排名，不能预测团队的缺陷率，也不能承诺在每个 pull request 上都能获得同样的收益。

将上下文利用起来

更大的上下文窗口为信息创造了空间。有效的推理要求模型识别哪些片段重要，将它们联系起来，并得出有证据支持的结论。

我们的解读是，Astra 最有趣的进步在于连接正确的信息。它在更难的跨文件审查上更大的收益表明，在相关信息分散分布的工作上取得了进展。它们没有隔离出这一进步的根本原因，也没有证明更多的上下文本身就能提升模型表现。

OpenAI 将 Astra 定位于跨代码、浏览器和专业软件的多步骤工作。

对于使用模型构建产品的团队而言，有用的问题是：额外的推理在何处足以改变结果并证明其成本合理。相比已经被更便宜的模型可靠处理的常规任务，证据分散的困难任务是更值得研究的候选对象。这并不意味着将每个会话都切换到 Astra、将推理力度开到最大然后放手不管。

更强的推理需要付出更高代价

根据 Astra 公布的定价，其标准 API 费率为每百万输入 token 10 美元、每百万输出 token 50 美元。Fable 5.1 具有相同的基础输入和输出费率，尽管缓存价格不同。Anthropic 的定价文档提供了完整细分。

为了解这些价格 context，考虑一个使用 100,000 个未缓存输入 token 和 10,000 个计费输出 token（包括推理 token）的示例性任务。保持 token 使用量不变使公布的费率更容易比较；实际任务成本随使用量而变化。

所有数字均使用公开列出的标准 API 价格，已于 2026 年 9 月 4 日核对。OpenAI 数字使用短上下文费率。Sol 的公开促销价至少在 2026 年 11 月 21 日前有效。本示例不含缓存、缓存写入、工具、重试、区域溢价和服务层级调整。实际任务可能使用不同数量的 token。

在这个固定使用量下，Astra 的成本是 Sol 的 2.5 倍，大约是 Terra 的 4.7 倍，大约是 Luna 的 47 倍。这些是相当可观的溢价。它们不是每个已完成任务的成本差异的预测。需要更少 token 或更少尝试次数的模型可能会缩小差距。

OpenAI 在其某些自有评测中报告了 Astra 更低的估算任务成本，尽管 token 价格更高。这一点使得每次成功结果的总成本值得在自己的工作上测量，而不是假设 token 价格或能力分数就能决定选择。阅读 OpenAI 的效率指南。

什么可能迁移到代码审查之外

可迁移的想法是跨独立来源的关系进行推理。我们的发现表明有几个值得评估的用途；我们尚未在这些任务上测量 Astra：

研究综合：调和相互冲突的报告，将论点与其证据联系起来，识别每份文档摘要都会错过的空白。

运营调查：从日志、事件记录和操作手册中组装出一致的解释，同时区分观察和假设。

需求与策略分析：追踪一项提议变更对规范、内部策略和实施计划的影响，标记出需要专家审查的不一致之处。

文档和电子表格工作：检查报告及其支持材料中的假设、公式和叙述结论是否一致。

共同的结构是证据分散且其各部分之间存在依赖关系。从边界明确、答案可验证的工作开始。测试 Astra 是否适合你的工作流或产品的最简单方法是将它与你当前的模型在相同任务上并行运行，然后比较答案质量、验证时间和总成本。

构建和平衡 NIGHTSHIFT

我们还用 Astra 构建了一整款游戏：NIGHTSHIFT，这是一款使用 Godot 和 GDScript 制作的动作 RPG。它最难的问题是在系统之间平衡交互，然后在游戏发生变化时重新调整这种平衡。

NIGHTSHIFT，通过人类指导和迭代使用 Astra 构建。

这意味着要推理七个角色职业、一个受传奇游戏 Path of Exile 被动技能树启发的 988 节点被动技能树、主动技能、符文和可插槽升级、技能进化以及合作模式。在 10 个篇章 40 个区域中，战役引入了越来越复杂的敌人蜂群和组合。更改一个职业也可能改变哪些升级有用、技能如何发展以及队伍能处理什么。

我们在开发过程中对核心系统进行了根本性修改，并要求 Astra 推演后果并重新平衡它们。在这样的游戏中，"平衡"是引人入胜的游戏玩法最困难的创意挑战。你如何在进行彻底改动或引入全新的游戏系统和机制的同时，保持进度、战斗和难度的连贯性？

我们还希望玩家能够通过职业、属性、物品、被动技能和主动技能的巧妙组合发现过强力的终局 build。挑战在于塑造一种进度，在这种进度中，即使达到中期也是不确定的，但创造力和实验能够以惊人的方式获得回报。找到这些组合的奖励是能够构建出一个能够令人满意地融化敌人蜂群的 build。

这个过程意味着在与其他工作之间回到游戏，给 Astra 反馈，并给予它充分的自主权来运用其判断力完善平衡。Astra 还构建了原生 PS5 和 Xbox 手柄支持、原生 macOS、Web 和 Linux 构建版本，以及合作模式。合作模式特别有趣，因为 Astra 能够为在同一计算环境和 LAN 上游玩构建它，由于我们想分发给运行 macOS 的同事，这需要生成一个新的 Xcode 项目、App Store Connect 账户、建立多个证书和权利，以及公证。

Astra 完全自主地处理了这一切，只是偶尔停下来询问它还没有的权限。作为一个有趣的附加功能，游戏还为 agents 本身构建了玩家身份，这在与 Astra 作为队友进行实时合作游戏时有些超现实。我们中的一些人发现很难放下它。"我正在做模型评估"成为了当经理路过时解释为什么打开游戏的一个有用借口。

观看 NIGHTSHIFT 游戏演示视频。一个较早的 NIGHTSHIFT 街机原型，展示了 18 秒的自动化游戏演示。

这款游戏为我们提供了一个创意环境来探索在代码审查中同样突出的能力。Astra 必须推理每个变更如何影响系统的其余部分。

我们接下来想看到什么

下一个令人兴奋的进步是使这种推理深度变得足够可靠以更频繁地使用。这意味着在困难工作上保持一致的收益、人们可以验证的结论，以及更低的每次成功结果的总成本。

这需要更好的相关上下文选择、更清晰的支撑证据，以及更少的不必要步骤。这也意味着隐私保护的部署路径，使高级能力能够在真实的客户承诺下使用。

Astra 给了我们一个关于跨文件推理的令人鼓舞的信号。实际的机会是将这种能力转化为更有用、更值得信赖的工作。就像将任何新模型上线到 CodeRabbit 一样，评估只是该决策的一个部分。

保护客户数据

CodeRabbit 和我们的模型提供商都不会在 CodeRabbit 客户的专有代码或私人代码审查期间收集的个人信息上训练 AI 模型。阅读我们的隐私政策。

OpenAI 和 Anthropic 有不同的数据保留策略：

OpenAI：GPT-6 Astra 为符合条件的 API 客户提供零数据保留。OpenAI 的 API 数据控制描述了 ZDR 资格和支持的能力。Astra 公告，OpenAI 数据控制。

Anthropic：Fable 默认要求 30 天保留以进行安全监控，但符合条件的客户现在可以在引入 Enterprise Frontier Safeguards 的同时将 Fable 5 和 5.1 与 ZDR 一起使用。对于为其他企业服务的产品，该选项需要与 Anthropic 达成协议。EFS 旨在将保留的活动数据保存在客户控制的基础设施中。覆盖模型保留策略，Enterprise Frontier Safeguards，资格详情。

我们用于客户审查的任何模型都必须满足我们的数据保护要求。