文章摘要
某AI研发团队推出新一代代码大模型预览版。测试者订阅139元套餐，接入代码平台，让模型修复真实Bug。首个任务因有公开方案结果作废，第二个任务中，模型首版补丁被反例挑战，与另一款模型测试难分伯仲，显示其具备工程能力，但审核仍不可少，对正式版表现更值得期待。

不久前，某AI研发团队宣布了新一代代码大模型的发布计划，正式版本将达到2.4T参数并开放权重，当前率先推出了预览版，开发者可直接在相关开发平台上体验使用。研发团队对这款新模型的评价较高，称其性能表现处于第一梯队，预览版已经可以直接调用，无需等待正式版本上线。

为了真实测试模型的工程能力，我们没有选择常规的榜单测试或网页生成任务，而是选择了订阅基础开发套餐，将模型接入代码开发平台，让它修复真实存在的未解决Bug。本次测试的结果超出了预期：第一个Bug修复任务中，模型很快完成了修复，但我们发现该问题已有公开修复方案，因此作废了这次测试结果；第二个任务中，模型通过了所有初始测试，却被我们设置的反例测试难住了。

测试套餐的选择

我们选择了139元每月的标准档位，原价为180元，活动期间有优惠。没有选择低价的Lite套餐是担心代码代理在大型仓库中频繁读取代码会快速消耗额度，而499元的Pro套餐对于这次测试来说配置过剩，139元的档位刚好适合本次深度测试。活动期间，预览版的调用额度在白天享受1折优惠，个人用户夜间还能叠加额外2折折扣，性价比不错。

测试的设计思路

网上曾流出一张该模型的内部测试图，测试集包含400个真实的代码开发和协作任务，预览版被纳入多款国内外模型的对照测试中。但这类内部测试集无法对外逐题验证，我们更关注模型脱离固定题库后，能否在陌生项目中自主阅读代码、定位问题、修改实现、补充测试，并通过严格的审核。

GitHub上的Issue正好适合这类测试，它不是预设的演示题目，而是真实的用户需求，代码是长期迭代的产物，现有测试不会为模型妥协，最终可以通过代码差异和反例验证结果。不过需要注意的是，Issue处于开放状态并不代表网络上没有现成的解决方案，这是测试中的一个潜在陷阱。

第一个Bug测试：Click进度显示问题

第一个测试任务来自Python命令行工具库的#3571 Issue。该Bug的表现为：当进度总数设置为20，同时开启show_pos=True和update_min_steps=7时，程序运行结束后进度停留在14/20，没有显示最终的20/20进度。

模型用时约2分29秒，复现了该问题，定位到ProgressBar.finish()方法没有刷新最后一段累计进度的问题，补充了修复代码和回归测试，最终测试结果显示：

1940 passed, 25 skipped, 1 xfailed

开局的表现相当顺利，但随后我们检查公开资料发现，早在6月就有开发者在分支仓库中提出了类似的修复方案，测试当天上游仓库也出现了相关的PR，核心思路都是在finish()方法中刷新_completed_intervals变量。这意味着虽然模型的修复本身没有问题，但无法证明它是独立找到的解决方案，因此这次测试结果作废，我们更换了新的测试任务。

第二个Bug测试：mypy插件类型问题

第二次测试前，我们调整了流程：先通过评论、关联PR、仓库搜索和公开网页确认该问题是否已有公开解决方案，再将任务交给模型。最终我们选择了mypy的#21744 Issue。

mypy是Python类型检查领域的老牌开源项目，从2012年开始开发，在GitHub上拥有超过2万颗星标和1.3万次提交，Issue编号已经超过2.1万，我们测试的主测试文件包含八千多条用例。如果将Python程序比作待审核的文稿，mypy就像是专业的编辑，在代码运行前就能提前找出类型不匹配的问题，而不需要实际运行程序。

本次的Bug隐藏在插件系统中：mypy允许插件临时修改方法的类型签名，当使用普通调用self.method(1)时，插件可以正常工作，但当调用super().method(1)时，插件没有生效。这就像同一栋楼有两扇门，self.method()走正门时有核验，而super().method()走侧门时，mypy知道路径对应的方法，却忘记将调用请求转发给插件检查。

我们确认该Issue在测试前后都没有评论和关联PR，也没有找到公开的同问题修复方案，任务材料仅包含Issue描述、最小复现示例、目标行为和验收要求，没有提供源码位置或现成答案，适合作为正式测试任务。

模型的首版修复与反例挑战

模型很快定位到了问题所在的mypy/checkexpr.py文件。普通方法调用使用MemberExpr路径，而super().method()则走SuperExpr路径，旧代码仅从MemberExpr路径中提取方法名和对象类型，导致SuperExpr路径下的插件调用无法获取查询信息。

模型找到了根因，首版补丁仅为SuperExpr路径补充了分支逻辑，并添加了回归测试，聚焦测试、插件测试和super相关测试全部通过，模型给出的结论是：

All checks pass.

但当我们将测试用例中的self替换为合法的其他实例super(Base, other).method(1)时，首版补丁立刻暴露出问题。模型错误地将“代码所在的类”当成了“实际调用方法的实例类型”，在原始测试案例中两者恰好是同一个类，因此测试全部通过，但当我们拆分这两个概念时，模型的插件调用就出现了错误。

看到反例后，模型很快承认了问题的正确性，这比单纯的测试通过更有价值，说明模型能够在收到精确反例后推翻初始假设，继续优化解决方案，而不是固守已有的测试结果。

对比另一款代码模型的表现

为了确认这类问题是否是该模型独有的，我们将相同的Issue、基线代码和验收要求交给了另一款代码模型。它同样找到了MemberExpr和SuperExpr的路径差异，并且避免了前一个模型的“代码所在类”错误，但却用另一种方式答错了。

该模型选择了方法最初定义的类，而mypy插件真正需要的是实际调用的实例。一个错误地将调用绑定到代码所在类，另一个错误地绑定到方法的原始定义类，正确的逻辑应该是绑定到当前实际调用的实例。当我们加入反例测试后，两款模型的初始补丁都被驳回，但在收到反馈后，两款模型都理解了问题并修正了方案，最终在相同的测试环境中通过了完整测试，结果显示：

8192 passed, 33 skipped, 7 xfailed

测试结果：难分伯仲

仅从这一次测试来看，两款模型难分高下。它们都能够进入陌生的大型代码库，通过语法树和插件调用链找到真正的问题根源，都在初始补丁中使用了看似合理的类型判断逻辑，被独立的反例测试难住，最终都能在收到反馈后修正方案完成任务。这说明该预览版模型已经具备承接真实工程开发任务的能力。

同时，这次实测也再次提醒我们，代码代理在能够编写代码后，还需要搭配专门的审核人员，通过反例测试来验证方案的完整性。由实现者和审核者分别负责，再结合固定测试和仓库规则来把关，比让模型自主完成所有测试和验证更加可靠。

对正式版的期待

需要注意的是，本次测试使用的仅是预览版模型，正式版将达到2.4T参数并开放权重，正式上线后还需要重新测试其能力、稳定性和开放方式，预览版的表现不能代表正式版的最终水平。但从预览版的表现来看，它已经能够在真实的开源项目Issue中与成熟的代码模型互有来回，这为正式版留下了很大的想象空间。

我们对正式版的期待是，能够在进入代码仓库后，更少依赖事后的反例修正，而是提前考虑到更多潜在的边界情况，毕竟漂亮的演示示例已经足够多了。最后需要说明的是，本次实验没有向相关开源仓库提交AI生成的PR。

以上内容不代表本平台立场，仅供读者参考