10月27日，AI编程公司Cognition发布FrontierCode 2.0测评榜单。该版本测评将重点转向AI编程在真实软件工程任务中的通过率，共包含132项任务，在任务复杂度与工程质量要求上均较以往版本有明显提升。测评结果显示，主流模型得分普遍大幅缩水：Claude Opus 5.5虽仍居首位，但得分从FrontierCode 1.1版本的54.6％降至45.5％；排名第二的GPT-6 Astra从53.3％降至42.8％；Grok 4.7跌幅更为显著，从47.6％降至28.6％。
榜单结果在社交媒体X及开发者社区引发讨论。不少声音指出，部分模型在传统编程测试中能够取得高分，但在真实应用中却频繁出现问题，反映出测评体系与工程实践之间存在落差。开发者分享的失败案例包括：模型为修复缺陷直接删除公共API、误读需求后强行实现错误理解等。这类操作在孤立测试中可能不被察觉，但在生产级系统中往往引发连锁问题。
从工程实践角度看，AI在代码补全、函数生成等环节带来的效率提升已得到广泛认可，基于自然语言描述生成简单应用的vibe coding能力也是此前难以想象的。但真实软件工程中，生成代码仅是起点。在既有系统中增加功能，需要同时兼容旧接口、遵循项目架构、避免引入安全漏洞，并确保其他模块不受影响。需求文档通常不会写明全部约束，开发者还需理解代码仓库的历史设计、维护者习惯以及模块间的依赖关系。从需求理解到测试验证、代码维护，任一环节出错都可能导致最终结果不可用。
有开发者提出“Vibe谬误”的概念，认为随着AI编程能力快速普及，基准任务的门槛几乎被踏平，容易让人形成“编程不过如此”的认知。但真实软件工业处理的是包含多重约束的系统工程，且正确答案往往并不唯一——一个功能可通过多种方式实现，但只有部分方案符合现有架构、性能要求和维护规范。目前多数问题仍需有经验的工程师解决，典型情况是AI在修复当前问题后留下新的隐患；随着代码修改权限扩大、可自主调用工具并连续修改多个文件，错误的影响范围也随之扩大，可能在项目推进至中后期或维护阶段才显现，甚至导致推倒重来。
今年以来，编程Agent发展迅速，逐步深入企业开发流程，但多数Agent在长程任务、多组件系统的配置与集成等领域表现仍不理想。叠加审查验证、生产环境接入与组织治理调整等环节的不同步，AI编程大多仍困于本地窗口，真正完成端到端交付的案例并不多。部分AI研发团队正在尝试更“AI原生”的路径：打散传统线性任务流程和组织架构，由AI承担代码开发、人类加码评审工作，通过项目制聚合编程Agent与人类各自所长。但相关实践多集中于本身从事AI研发的团队，且往往以小团队先行或将大团队拆分为项目组分别推进，所用工具多为自研或定制化编程工具。对于相对传统的软件开发领域，即使不考虑Token成本，直接复用这些包含个性化工具开发与组织架构变革的模式仍面临诸多瓶颈。
模型层面，AI大模型仍在加码编程能力。10月24日Kimi发布的K3.1 Pro与10月27日OpenAI发布的GPT-6.1 Terra，均强调AI编程在真实场景中的能力提升与成本下降。其中K3.1 Pro通过训练范式变革，着重增强真实任务编程、长程Agent及金融等能力，测评显示任务成功率显著提升。有业内人士分析认为，Kimi当前技术攻关的重心是解决现有模型在100步以上长思维链中容易陷入死循环的问题，并将复杂数理证明能力和工程代码能力作为可验证推理能力的重点方向。在主流模型代码补全能力已不易拉开差距的背景下，长程链路方向的突破有望让AI在复杂软件工程、前沿研究及物理世界推理等场景表现更佳。不过从已公开的测评结果看，K3.1 Pro距离突破100步门槛仍有相当距离，其他模型也在通过不同技术路线提升真实场景落地能力。长程Agent何时能够真正可靠，仍是AI编程交付能力大考的关键所在。
该文观点仅代表作者本人，企服科学平台仅提供信息存储空间服务。
