OpenAI/Gemini共斩ICPC 2025金牌，AI编程已经超越人类了吗？

答案是否定的。

在大语言模型（LLM）出现之后，传统意义上的编程竞赛事实上已经失去了其原本的价值与指向性。这类竞赛本质上是高度“套路化”的：它们考察的并非现实问题的建模与治理能力，而是在既定算法知识库中，能否在有限时间内检索并选取一个时间复杂度合规的解法。出题者本身必然知晓标准答案，而对 LLM 而言，只要并发搜索规模足够大，通过模式匹配与暴力尝试，最终获得正确解法几乎是必然结果。人类在这一过程中处于天然劣势，其问题不在于“不会”，而在于大脑的搜索、验证与回溯速度远远无法与机器并行能力相提并论。

更重要的是，这类竞赛并不真正考验对复杂性的处理能力，这一点恰恰与现代软件工程师的核心要求背道而驰。

从实现层面看，竞赛算法代码往往被严格限制在较小规模之内，通常不超过数百行，极少超过一千行。其代码复杂度本身并不高，且大量题目属于重复出现的“模板题”——递归、回溯、动态规划等套路早已被反复书写与训练。对于初学者而言，这些问题确实具有一定挑战性；但对于经验丰富的工程师来说，这些复杂性早已被内化，几乎不存在认知障碍。真正的难点，仅在于如何在脑海中快速检索到满足时间复杂度约束的算法模型。

这也正是许多资深工程师普遍厌恶算法题的根源。在 LLM 已经出现的当下，继续将算法竞赛或刷题作为能力评判标准，某种意义上已接近于浪费生命：在一个工程实践中几乎不会被直接调用的知识库里，强迫开发者检索一个“可行解”，更像是一种对现实软件开发工作的误读，甚至是对工程经验的贬损。诸如“翻转二叉树”之类的问题，在真实软件系统中几乎没有对应价值。

真正的软件工程，乃至“码农”或“架构师”，处理的是高度贴近现实世界的问题，而现实世界的显著特征正是随机性、不确定性与非标准化。即便只是一个看似简单的仓储出入库与报表管理流程，不同企业之间也可能存在成百上千种截然不同的业务规则。绝大多数情况下，并不是企业去适应软件的“标准流程”，除非你已经具备世界级体量与话语权。即便强如 SAP，也必须大量驻场，为客户进行深度定制——买方永远是大爷，试图强推统一标准，往往只会遭遇现实的反噬。

在 C 端软件中，目标用户是大众，容错空间极大。哪怕推荐算法质量平庸，用户也极少会要求工程师为其“量身定制”一套逻辑。然而在企业软件中，逻辑恰恰相反：工程师必须去适配各种混乱、非标、甚至彼此冲突的业务规则，系统的复杂性主要来自对现实差异的妥协与吸纳。

也正因如此，现实中的业务编程与算法竞赛几乎属于两个世界。大量企业级代码库规模极其庞大，模块边界高度失控，代码中混杂着无效逻辑、历史遗留 bug、随意堆叠的业务规则以及大量复制粘贴的代码碎片。这类系统的信息熵极高，而真正有效的信息占比却极低。一个看似微不足道的改动，可能在遥远的模块中引发连锁式的系统性故障。

这正是为何经验丰富的软件工程师在修改代码时普遍表现出极端谨慎——不是因为技术能力不足，而是因为他们深知系统复杂性的真实代价。

这些问题既包含业务本身不可约简的复杂性，也叠加了人员、流程与管理失控所引入的“人为复杂性”，例如模块高度耦合、规则缺乏边界、随意复制代码等。现代软件工程并不要求开发者凭空解决一个算法难题；当计算复杂度过高时，直接调用成熟算法库即可。而真正需要深度算法优化的场景，往往由专门团队负责，他们也拥有自己的方法论与工具链。

早已有前辈总结过经验：“拿不准，就穷举。”这一点与 LLM 的行为逻辑在本质上高度相似。区别只在于，人类的穷举往往依赖有限的蒙特卡洛式搜索，而 LLM 的穷举则是对整个知识空间中算法模式的并行匹配。

在我看来，编程真正迈向 AGI 的标志性时刻，并不是它能多快解出一道竞赛题，而是它能够在完全无需人工介入的前提下，将一个拥有上千万行代码、充满“狗屎业务逻辑”的系统梳理得井井有条，在保持原有行为（甚至包括依赖 bug 的行为）的同时进行重构与演化。因为在现实世界中，许多系统正是“靠 bug 在运行”，贸然修复反而会引发更严重的灾难。

因此，评价 LLM 能力高低的真正标准，应当是：它能否处理多高的信息熵与复杂度，且该结果无法被轻易验证；而不是看它在一个答案易于验证、复杂度极低的封闭领域中，解决了多少形式精巧却现实意义有限的问题。