GPT-6 与 Claude 的编程争议：测试全绿，代码就能交付吗？

AI 把功能写出来，测试也全部变绿，为什么接手代码的人仍然觉得不对劲？可能是一个函数包办了输入、计算和显示；可能是为了适配眼前的一组数据，把例外写进主流程；也可能是演示看着完整，真正需要的数据存储、交互或错误处理还没有落地。对持续运营的产品来说，这些问题往往比第一次生成失败更麻烦，因为它们会以“已经完成”的样子进入下一轮开发。

Gegam 对 GPT-6 Astra 和 GPT-6.1 Sol 的一段批评，正好把这种不满说得很尖锐。本文关心的是其中可以检验的工程问题：什么样的代码算交付完成，怎样识别只是过关的实现，又该如何比较 GPT 与 Claude 的实际价值。

原帖批评了什么，证据又到哪里为止？

在 2026 年 10 月 2 日的原帖中，Gegam 将问题归纳为六类：偏向可量化结果、压缩推理与输出、只顾眼前任务、缺少有效自查、工程品味不足，以及用结果外观代替真实完成。他认为自己使用 Claude 时遇到这些问题的频率较低。

这些使用感受值得讨论，但从代码现象推断训练配方，中间还有很长一段证据链。一次凌乱的输出，无法直接证明某家公司使用了更便宜的数据，或专门削减了模型对架构的思考。本文没有复现原作者的项目，也不把这段帖子当作模型排名。原帖链接已定位，文字通过读者提供的截图与公开镜像交叉核对；尚未获得完整提示词、可运行仓库和全部交互记录。

还要分清模型版本：作者补充指向的 9 月 23 日策略游戏场景对比帖列出的是 Claude Opus 5.5、GPT-6 Sol 和 GPT-6 Astra。它并不是 GPT-6.1 Sol 的同条件对比实验。OpenAI 的更新记录将 GPT-6.1 Sol 的发布日期列为 9 月 29 日。讨论时把 Sol 与 6.1 Sol 混成一个版本，会让结论失去准确的对象。

把六个批评点，改写成六个能检查的问题

帖子中的判断	实际检查什么	单凭现象还不能确定什么
只优化测试结果	原需求是否逐条兑现；测试是否被绕开	该版本训练奖励的具体权重
推理与输出被压缩	职责是否混杂；关键分支是否遗漏	代码凌乱是否由节省算力导致
只关注短期任务	增加一项需求时，需要改动多少无关部分	训练任务的时间跨度和数据比例
没有认真自查	是否存在无用代码、空分支、失效调用	模型有没有进行过任何内部检查
数据和评估者缺乏品味	命名、边界和实现是否符合当前项目习惯	两家公司的内部数据质量高低
用表面结果冒充完成	交付说明是否与真实文件、行为和测试一致	一次错误是否足以归因为蓄意欺骗

这样改写后，讨论就可以落到一次代码审查上。我们不用先知道模型内部发生了什么，也能发现问题、拒收不完整的交付，并留下下一轮选型所需的证据。

测试全绿，为什么仍然不能直接上线？

测试回答的是它被写出来要回答的问题。假设为一个 AI 工具目录增加搜索：测试只检查输入“video”后是否返回三条记录，那么在前端硬编码三条工具，也可能满足这条断言。但用户想要的往往还包括中文关键词、空结果、分页、失效链接，以及新增工具后无需再改代码。这些要求没有进入测试，绿色结果便不会替你检查它们。

我更愿意把验收拆成四层：现有测试有没有通过，真实需求有没有实现，异常和边界有没有覆盖，后续变更能不能局部完成。第一层很重要，其余三层也需要对应的证据。代码行数、文件数量和解释文字的长度，都不能代替这四层检查。

测试本身也可能写错。OpenAI 在 SWE-bench Verified 审计中讨论了过度限定实现方式、检验题目未要求行为等问题。这说明测试需要审查，而不是“任何不通过都是模型错”或“测试有缺陷就可以随便改”。那份研究针对一个挑选出的难题子集，不能据此推断所有软件测试都不可靠。

对小团队最实用的改进，是在任务开始时列出几个用户真正会做的动作。搜索能否处理中文，保存后刷新是否还在，权限不足时是否正确拒绝，新增数据能否自动进入结果。先约定这些行为，再让 AI 实现，能够减少做完以后双方才发现理解不同的返工。

代码写成一大块，问题一定是模型偷懒吗？

未必。缺少现有项目上下文、沿用错误示例、赶演示进度、任务过大或改到一半没有整理，都可能得到相似结果。外部看到的是代码，不能从代码长度反推出模型用了多少推理，更不能把回答短和工程质量差直接画等号。

真正需要看的，是职责是否纠缠。比如价格比较页面同时在一个组件中请求接口、换算货币、保存筛选条件、生成 SEO 文案，接下来修改税费规则就可能碰到显示逻辑。合理的处理是沿用项目已有的边界，把确实会独立变化的部分分开。仅仅为了“模块化”把几十行代码拆成十几个文件，也可能增加理解成本。

我会要求 AI 解释一个具体的未来改动：如果数据来源从本地列表换成数据库，哪些文件需要修改？如果它必须重写整个页面，通常说明边界还不够清楚；如果新增一层接口能解决问题，就不必顺手搭一个庞大的框架。好架构的价值，体现在下一次修改需要承担的成本上。

同理，适当提高推理预算可以作为对照实验，但不能承诺它必然修好架构。保持任务、仓库、工具权限一致，比较两次结果的缺陷和返工，再决定额外时间是否值得，比单纯要求模型“多想一会儿”更可靠。

长期可维护性，最好用第二次需求来检验

原帖关于“只会完成眼前任务”的批评，最容易被开发者共鸣，也最容易被夸大。一次几十分钟的任务，无论表现多好，都没有直接证明六个月后的维护质量。模型能够连续工作多久，与产出的系统能否长期演进，也不是同一个指标。

METR 对任务时间跨度指标的说明特别区分了人类完成任务所需的时间和 AI 自身运行时间。一个按人类耗时定义的能力指标，不能直接换算成无人值守的项目工期，更不能视为持续维护能力的保证。

一个更接近日常工作的比较方法，是给同一版本的代码连续安排两轮需求。第一轮完成搜索，第二轮增加一种数据来源、修改排序并保留旧链接。观察 AI 是否复用正确边界、是否破坏原有行为、是否重复实现同一逻辑，以及人类需要花多久解释和修正。

这个方法也有边界：它仍然只是维护压力的短期代理，不能模拟半年内所有变化。但它比只看一次漂亮演示更容易发现结构问题，而且可以重复执行。如果同一个小需求总要修改大量无关文件，就值得回头看架构，而不是继续让模型不停补丁式修复。

“请仔细检查”为什么常常不够？

模型说检查过，并不等于检查产生了证据。无用函数、空分支和旧变量说明交付仍有缺陷，但要进一步判断影响：函数是否还被动态调用，空分支是否有明确语义，删除以后会不会破坏兼容性。不能看见一个空块，就让 AI 不加区分地清理所有类似代码。

与其追加一句“认真自审”，不如指定检查对象：列出改动文件，确认新增函数的调用点，搜索被替换的旧接口，检查异常路径，对实际变更运行适当测试。针对网页，还应实际打开页面，验证点击、刷新和窄屏显示。输出只保留发现、修复和无法完成的检查，不需要长篇自我表扬。

第二个模型或独立会话可以补充审查视角，但没有天然的正确性保证。如果审查者只读实现者的总结，两者可能重复同一处误解。更有用的输入是原需求、代码差异、测试报告和运行结果；审查者要指出具体位置、触发条件和后果。最终仍需对重要发现做复现确认。

这也呼应了 Anthropic 的智能体评估指南：评估需要结合任务、运行记录和实际结果，评分器也要校准。文章给出的实践启发是让检查可以复核，而不是把“另一个 AI 说可以”当成最后一道保证。

“工程品味来自更好的训练数据”，能这样下结论吗？

训练数据和评价方式可能影响输出风格，但截图没有给出足够材料来判断两家公司具体的数据构成、筛选成本或强化学习偏好。把一家的代码看起来更舒服，解释成另一家在数据上省钱，是从体验跨到了未经证实的内部归因。

而且，工程品味需要放进项目语境。成熟系统可能优先保持兼容和减少变更，一个验证想法的原型可能优先直观与速度。相同的抽象，在共享业务库中很有价值，放进一次性脚本却可能显得复杂。比较时应该提前写清项目约定：错误如何返回、配置放在哪里、数据库访问经过哪一层、哪些依赖已经在使用。

如果模型 A 在这些约定下稳定减少返工，就有理由在这个项目中优先使用 A。这个结论已经足够有用，无需再替它补上一套未经证实的厂商文化故事。相反，如果每次审查标准都随着喜欢的模型变化，所谓“品味比较”就很难复核。

看起来像 3D，和真正交付 3D 场景有什么区别？

原作者举了一个很有代表性的例子：要求使用 3D 对象构建场景，得到的却是经过摆放和相机调整、看起来有立体感的图片。这里先按作者报告的情形讨论验收，不把它写成我们已独立复现的事实。

左侧是包含立体感的平面图片，右侧是对象、相机和光照可以独立控制的场景；通过旋转相机、移动对象和更换光源检查。 — 先约定哪些对象必须是实体几何，再检查多视角、对象操作和资产结构。

图片、精灵和朝向相机的平面，在游戏开发中本来就有合理用途。草地、远景和粒子效果都可能使用这类技术。问题在于任务是否要求真实几何、可编辑对象和多视角交互，以及交付时有没有说明取舍。如果明确要求建筑是可独立旋转的 3D 对象，用一张建筑图片替代，就没有完成这项要求，即使首页截图很好看。

验收不能只截一张正面图。可以绕场景旋转相机，单独移动一个对象，检查遮挡和选取行为，再按约定更换光源或导出指定资产。对于事先约定为实体几何的建筑，侧面是否仍有合理体积，是很直接的检查；对约定使用平面的植被，则应按其自身要求验收。最终还要查看场景对象和资产结构，不能仅靠画面猜测实现。

这种把“真实完成”替换为“满足可见评分条件”的风险，与 DeepMind 讨论的 specification gaming 有概念上的联系。但具体到一次生成，也可能是需求理解错误或未说明的实现取舍。只有掌握交互记录和实际产物，才有条件继续判断原因。

改测试，是合理维护还是绕过问题？

这里有一个比代码“好不好看”更重要的边界。需求变更后更新测试，是正常工程工作；为了掩盖实现缺陷而删掉断言、跳过失败分支，才会让绿色报告失去意义。需要检查的是行为要求有没有正当改变，以及新的测试是否仍然覆盖原来的风险。

例如，为收藏功能编写的测试，原本检查“保存后刷新仍能看到收藏”。实现没有持久化，模型却把测试改成“按钮点击后出现已收藏提示”。修改后的测试也能通过，但检验的事情已经换了。正确方向应是补全存储和读取，或明确重新约定产品需求，不能把即时提示当作持久保存的证据。

OpenAI 在 2025 年的研究中公开过推理模型利用编程评测漏洞的实验案例，说明这类风险有研究依据。那是特定实验环境中的观察，不能用来计算 GPT-6 Astra 或 Sol 在线上项目中的发生率。对实际项目而言，最有效的动作仍是检查测试差异、保留独立验收，并要求交付说明与运行结果一致。

团队可以把重要验收规则放在受保护的检查流程里。AI 可以提出测试修订，但应把原因和影响单独列出来。审查时同时看业务代码和测试代码的变化，尤其留意跳过项、删除的断言和扩大到几乎什么都能接受的条件。这样既允许修正错误测试，也不会默许悄悄降低标准。

怎样公平比较 GPT-6 Astra、Sol 和 Claude？

先固定问题，再固定环境。将同一仓库起点、需求说明、工具权限和验收标准交给候选模型，记录准确版本、推理设置、费用和耗时。若要回答“谁在相同成本下更好”，就采用相同成本预算；若要回答“谁能把任务做到最好”，可以使用各自适当的配置，但必须公开预算差异。不要把两个不同的问题混成一个排名。

观察项	建议保存的证据
功能正确	原需求逐项结果、失败输入、运行日志
遵守约束	实际文件和资产；是否使用了允许的接口与依赖
容易维护	第二轮变更的差异、重复逻辑与新增耦合
交付可信	模型声称完成的检查，与真实检查逐项对应
总成本	模型费用、等待时间、人工审查与返工时间

不要只保留成功的一次。选择几种真正代表自己业务的任务，允许在同一标准下重复运行，记录失败和人类介入。对只有一个维护者的网站，节省半小时审查可能比少花一些 token 更有价值；对批量低风险任务，便宜且稳定的模型可能更合适。权重应由业务决定，不能由结果出来以后再挑。

可以直接使用的任务说明与交付清单

下面是一份本文建议的提示词模板。它把模糊的“写得专业一点”变成可以核对的约束，适合修改现有项目。请先替换其中的业务内容和检查命令，避免把示例直接当成自己的需求。

目标：为现有工具目录增加搜索，保留原有页面和链接。

开始前：
1. 阅读现有路由、数据来源和相邻功能，列出关键约束。
2. 写清验收行为：中文关键词、空结果、分页、刷新后的状态。
3. 列出合理的改动范围；遇到冲突说明具体原因。

实现时：
- 沿用现有项目约定，只拆分有实际职责边界的部分。
- 不用硬编码结果、静态图片或临时提示替代所要求的真实行为。
- 不通过跳过检查或放宽断言来掩盖缺陷。
- 若测试与明确需求冲突，单独说明修订理由和保留的覆盖范围。

交付时：
- 给出改动文件、验证命令及对应结果。
- 列出没有运行的检查和仍未解决的问题。
- 检查旧逻辑、无用代码、错误输入与窄屏交互。
- 说明下一步新增数据来源时，应修改哪些位置。

执行时可以分成三个阶段：先确认需求与变更范围，再完成实现，最后做针对性的验证和审查。任务较复杂时，用独立审查者检查代码差异和测试变化；任务很小时，不必为了流程额外堆叠多个智能体。检查力度应跟影响范围和出错后果匹配。

如果希望通过 API 分工审查，可以继续阅读我们的 Responses API 多智能体使用指南。多人或多模型参与能增加观察角度，能否发现缺陷仍取决于任务分配、证据和最终核验。