当我们在网上看到AI在各大编程基准上不断刷榜时，一个现实的问题摆在了每位程序员面前：这些高分，究竟在多大程度上预示着我们的未来？一个在"考场"上能拿满分的AI，是否意味着它在真实的"战场"中也能所向披靡。
今天这篇文章，我准备从评估AI代码能力的"考题"演进开始，聊聊我个人认知下的AI在编程领域的真实边界，并最终落回到我们最关心的问题：在这场浪潮之下，我们应该如何重新思考和锻造自己的核心竞争力，找到属于程序员的、不可替代的价值。
AI生成代码能力的评估进化 - 从"静态评估"到"动态评估"的演进
要评估AI对于我们程序员可能造成多大的影响，我们首先要看对当前AI生成代码能力的评估是否能真实反映程序员的真实工作场景。AI大模型早前评估代码能力，主要使用HumanEval和MBPP等基础测试，这是一种相对静态的评测基准，给定一个问题描述和测试用例，统计一次性生成正确的成功率（pass@1）和k次生成中包含正确答案的几率（pass@k）作为效果评估，随着大模型训练的代码规模越来越大，这类指标的得分也越来越高。
然而无论是HumanEval的164个Python编程任务还是MBPP的974个Python编程任务，都严重脱离我们真实的开发环境。真实的开发状态很少像上述评测一样进行孤立的函数编写，而更多的是在一个复杂的项目仓库中进行开发、修改和调试。当绝大部分顶尖的AI大模型在HumanEval等基准上达到很高的pass@1分数（例如超过90%），这些基准的区分度就会下降。因此，各大AI厂商的研究员就开始出更难、更接近程序员真实状态的"考题"来识别各模型的真实能力差距，像现在各家模型能力评测中经常出现的SWE-bench和AiderPolyglot基准正是往前迈出的一步。
与HumanEval等函数级生成的评测不同，SWE-bench是在一个复杂的、多文件的项目仓库中评测解决实际问题的能力。具体形式为给定一个完整的GitHub仓库和一个真实的Issue，模型需要通过修改代码库中的一个或多个文件来生成一个patch，并让相关的单元测试通过。这就要求模型具备远超函数生成的能力，它需要理解项目仓库，各种类和函数之间的依赖关系，并在复杂的代码文件集中找到需要修改的代码并将其修改正确，这种评估方式无疑更贴近我们真实的开发场景。而AiderPolyglot的评估则更强调代码的静态调试能力，模型有两次机会解决每个问题。如果第一次尝试失败，系统会向模型展示失败的单测结果，并让其进行第二次尝试。这直接测试了模型根据错误反馈进行自我修正和调试的能力，在编程助手等应用场景中非常重要。
上述无论是HumanEval、MBPP还是SWE-bench、AiderPolyglot，虽然评测的方式持续向程序员实际的工作场景去贴近，但本质还是偏静态场景，也就是完成一个明确的任务即可。而在真实环境中，我们时常面临动态调整，例如临时修改需求、推翻现有方案等，一个优秀的程序员往往能很好的应对以上的场景。那如何评估大模型在这方面的能力？LiveCodeBench就是第一个将交互 作为核心评估维度的主要基准。 
LiveCodeBench的评估方式是在一个会话中解决一个编程问题，这个过程是交互式的，用户（可以是人，也可以是一个AI智能体）在这个过程中会提供修改建议、指出错误、甚至修改需求，模型需要理解这些实时反馈并相应的调整代码。LiveCodeBench的评估也是多维的，它不仅看最终代码是否能通过所有用例，更重要的是评估整个问题解决的过程，评估指标可能包括：首次提交通过率、最终通过率（经过多次交互后）、交互效率（需要多少轮交互）、人类评估等等。这也意味着，对AI生成代码能力的评估开始从静态的 "代码生成" 转向动态的 "问题解决过程" ，这极大地考验了模型的代码调试、用户意图理解和多轮对话能力。
很明显可以看出，研究员们在努力构造真实的开发场景去评估和激发AI大模型在编程领域的潜力，评测基准在往真实场景迈近的同时评测性能却在持续降低，这表明AI在短期内难以完全取代真实的我们。
了解评测基准后，我们现在可以预设一个场景： 当SWE-bench、LiveCodeBench等评测基准在模型能力的持续进化中也达到了90%甚至95%以上的得分，此时AI在编程领域的局限性还有哪些？接下来我们需要先聊聊这个问题，因为只有持续去研究、思考这个问题，我们才能慢慢洞察作为程序员的我们要如何更好的适应这个时代。
探索边界：当前AI在编码领域的局限与挑战
无论AI的代码写的有多快、多好，AI大模型的本质还是基于大规模数据的内联模式识别与Token概率推断 。这也意味着基于对过往知识的泛化从而快速学习新的概念、或者为一些疑难问题找到更具创造性的解决方案等方面，AI往往无法很好的应对。当然，这部分能力对我们自身来讲也提出了不低的要求。
举一个大家熟悉的例子，调试"海森堡（海森堡bug）"，这个现象可能很多程序员朋友在工作中经常会遇到，但是却不知道维基百科中有一个专业的术语来描述它。一个"海森堡"其实指的就是当你尝试通过调试工具去观察它时，其行为就会改变或者消失的bug，非常令人头疼。这类Bug往往是由于开发和线上环境差异、编译器优化、或是复杂的时序问题引起，在任何教程中都没有固定模式的解决方案。咱们可能都尝试过，向AI提出这类问题后，它可以扫描全部代码，根据其训练数据中所有已知的bug模式进行比对，最后可能也会提出一些常规性的修复建议，比如"检查空指针"或添加"线程同步逻辑"，但是当这些都无效时，AI便会陷入困境，因为它无法凭空想象出一个从未见过的、可能由多个系统非线性交互产生的全新错误模式。
这时候，就需要依靠经验丰富的程序员依靠过往的工作沉淀所创建的心智模型来定位和解决，咱们可能都有体会。有时候，我们可能在闹脑海中模拟了整个系统的运行流程，对数据流、线程调度进行"思想实验"，尝试能找到线索。此外，普通的调试方案无法解决的话，我们可能会尝试设计一些巧妙的、非侵入式的手段，比如通过修改日志级别、调整系统负载、甚至引入一些小的延迟来引诱Bug复现。这种解决疑难问题的过程，本质上是一种基于过往认知的探索，它要求的是假设、实验、验证的创造性循环，而这恰恰是基于概率推断的AI模型所不具备的。
AI的另一个根本性局限，在于它目前只能承载有限的上下文。 虽然各大AI模型发布时，经常将"超长上下文窗口"（从ChatGPT 3时代的4k到如今Gemini 2.5 Pro的128K）作为核心卖点，而上下文长度的进化，也确实让AI能处理更复杂的任务。然而，这种线性增长的背后，是Transformer架构固有的注意力计算复杂度（具体可以看我之前的文章：《大语言模型（LLM）的原理与应用》）。即使做了像DeeSeek这种近乎变态的工程优化，但信息在传递过程中的"有损压缩"本质并未改变。这直接导致了当输送给AI模型的上下文过长时，经常会出现信息衰减的问题。
而这也引出了一个更深层次的问题：AI的"上下文窗口"与咱们程序员的"认知上下文"根本就是两个维度的概念。 AI的上下文是线性的、有形的，需要被输入的数学层面的信息；而程序员的上下文则是立体的、无形的、由无数经验、直觉、失败教训和正式或非正式沟通交织而成的隐形知识网络。我们很难将后者完整、无损地结构化后，塞进前者的窗口里。
最典型的体现是，我们在编程时，决策往往不是基于一个孤立的技术问题，而是一个对包含了项目的整体背景、动态变化的商业化目标、以及来自线上用户的直接反馈的"认知上下文"进行综合权衡的结果。在这种复杂的背景下，我们的编码策略会灵活调整：有时为了快速上线验证一个商业化思路的可行性，用最快的、比较粗暴的方式快速实现功能。而有时，我们又会为了项目后续的健康与可维护性而进行大规模的重构。
AI模型在缺乏这种复杂的、难以被完整描述的上下文时，往往只会依赖从起海量训练训练数据集中学到的通用"最佳实践"模式，去实现一个与当前真实需求可能脱节的局部最优解。
最后，还有一个无法回避的问题就是AI生成代码的安全性。AI模型的训练数据源自广阔的，未经筛选的公开互联网，其中自然夹杂着大量已知或未知安全漏洞的代码。AI在学习这些海量数据的过程中，不可避免地会将这些不安全的编码模式也学习到。
这就导致AI在基于概率生成代码时，有时会无意识的复现这些安全问题。从最常见的SQL注入、XSS、到更隐藏的不安全反序列化、路径遍历和缓存溢出，这些在各种安全培训中被反复警示的错误，可能会通过AI编程助手被规模化、自动化地注入到新的项目中。因此，现阶段AI生成的代码，一定需要我们去仔细审查，当然，还有一种稍微偷懒的方式是在AI生成代码后，再接一个通过AI进行代码审查的工作流，并强调让其注重各类安全问题的审查，这能自动提前帮我们发现一些隐藏的安全问题，但依然无法完全取代我们人工审查，但是可以作为一个很好的互补，一定程度上避免我们在审查偷懒时一些问题被放过。
下图是SCET的一项研究，它构造了一些测试用例，发现通过现在主流AI大模型生成的代码，40%未能通过安全编码指南的检测。
上述聊到的种种局限中，我们需要认识到两种截然不同的挑战，一类是技术或者工程性难题，另一个类则是根本性的鸿沟。前者的解决只是时间问题，例如生成代码的安全性问题，随着现在大模型都融入了长思考能力，在正式生成代码之前，模型会经过深度熟虑思考用户的意图及如何尽量提升响应的质量，很多安全隐患也许在思考的过程中就会被扼杀在摇篮中。
而后者则触及了当前AI技术范式的核心边界。例如上文聊到的AI的上下文窗口与人类的认知上下文的核心差异，完全是两个不同概念的东西。人类的认知跃迁往往是非结构化的、跨领域的、甚至是偶然的。它要求的第一性原理、独立的价值判断和敢于挑战现有范式的勇气。这些难能可贵的品质都是AI很难拥有的。
塑造未来，AI时代程序员的核心竞争力
了解了上述种种的局限性后，我们才能更好的去思考如何在AI时代去培养自己的核心竞争力。首先我们要明白，AI的能力在飞速进化，上述提到的在SWE-bench、LiveCodeBench等评测基准中达到95%以上的得分属于技术工程性挑战，而非根本性鸿沟，也许在不久的将来就能实现，AI会深刻准确的理解我们的代码仓库，只要提出清晰明确的需求指令，它就能很好的完成工作。这也意味着一些常规的编码任务将越来越多的被AI所取代， "唯手熟尔" 的 "资深" 程序员沉淀多年的优势将不复存在。那我们需要做的是什么？我认为有两个核心点。
1. 终身学习，从一个勤奋的码农变成一个智慧的"AI架构师"
既然绝大部分基础的编码或者说是研发工作在未来都会由AI来完成，那我们我们就需要快速且持续去学习AI的方方面面，从基础的能熟练掌握与AI工具的交互，编写有效的提示引导AI产生预期的输出，并理解如何引导AI的行为，到更深层次的掌握如何组合多个AI工具，管理它们的交互，并将它们有效的集成到复杂的工作流中。都是为了将自己从之前一个纯粹的打工牛马角色转变成能安排不同的AI工具或AI工作流帮我们自己准确高效的完成任务的AI架构师。
以上说的是 "术" ， "术" 往往决定了我们能走多快，而 "道" 却能决定我们能走多远，这里的 "道" 则意味着对AI原理的学习和理解，持续跟踪AI技术正在沿着哪些关键路径演进，哪些是昙花一现的噱头，哪些则是真正定义下一代技术的突破。"道"能帮助我们我们保持在正确的方向上前进。只精于"术"而不明"道"，我们可能会成为一个高效的工具使用者，却也容易在技术浪潮的更迭中迷失方向。
我在学习AI的过程中也注重保持着"术"与"道"两个层面并行的持续学习。具体可以看看之前的一系列文章。
2. 拥抱"根本性鸿沟"：在AI的边界之外，构筑我们的核心壁垒
在上文剖析AI编程的局限性中，一类是技术工程层面的挑战，这类问题往往随着时间的推移及算力的增强很快能解决。另一类则是根本性鸿沟，例如解决复杂问题的创造性思维，以及AI的"上下文窗口"与程序员的"认知上下文"的根本性差异。第二类AI的局限性恰恰是我们作为人类开发者，相对于AI可能 拥有的核心竞争力。注意，我这里强调了可能二字，这是因为这些能力也并非与生俱来，更非一劳永逸，而是一项需要我们以极大的意愿，付出持之以恒的努力去刻意的锻炼，最终才能赢取和保持的能力。 具体如何做呢，这里聊聊我个人的体会。
首先，当AI盛行后，网上喧嚣的技术无用论我非常不认同，恰恰相反，它会对我们的技术掌握提出更高的要求，着重体现在技术思维的锻炼上。这并非指做更多的需求，解更多的Bug，而是培养一种"第一性原理"式的，跨越模式的工程思维。当AI能穷举所有已知的解决方案时，我们的价值便在于处理那些未知的、没有现成范本的挑战。这并非能一蹴而就去实现，而是需要咱们像锻炼肌肉记忆一样，持续刻意的练习。
比如，工作中接到需求后，我们的思维应该从 "如何实现" 转变到 "为何实现" 。"如何实现"的思维可能习惯于接到需求后就立即开始思考或者调研"我应该用哪个框架/库来实现这个功能"，而"为何实现"则要求我们先去了解"这个需求的本质是什么？要解决的核心问题是什么？为什么现有的方案不适用？"在理解了问题的本质后，再去思考"哪种技术原理（而非具体工具）"最适合解决这个问题。在这个过程中当然也可以借助AI帮助我们拓展思路和加速新领域的学习速度。
接着，需要从 "关注局部" 转变到 "着眼全局" 。我自己也在带技术团队，我有时和团队的同学1v1时也会提醒他们工作中不要只盯着自己的那一亩三分地儿，多抬头观察和思考。不要仅满足于做好自己的需求模块，一个简单的扩展思考，就是在写自己负责的功能模块时，始终思考它在整个项目或系统中的位置："我的模块会给上下游带来什么影响？它的性能瓶颈会不会成为整个系统的瓶颈？未来如何需求变更，我的设计是否易于扩展"。你实现的代码逻辑AI也能快速准确的完成，但你长期习惯性思考所形成的全局洞察力AI却很难拥有。
还有，我们需要从 "寻求唯一答案" 转变到 "权衡多种可能" 的思维方式。怎么理解呢？当被分派一个任务时，我们固化的思维方式可能是"这个任务最好的实现方式是什么？"，而转变后的思维则可能是"针对这个任务，有哪些不同的实现方案？它们各自的优缺点是什么？在当前的时间、成本和人力限制下，哪种方式是最合适的（而非最好的）？"上文也聊到过，AI是基于海量数据模式识别后的概率推断，因此常常会陷入局部最优解。它很难拥有我们这种立体的"认知上下文"，因此我们就需要刻意的去持续扩宽和使用我们这种得天独厚的上下文，让其充分发挥自己的优势来达到最优解。
最后，如果说上述的技术思维锻炼是硬实力，那么工作中我们对"人"和"业务"的深度洞察则是我们要锻炼的软实力，能进一步增大我们的"认知上下文"与"AI上下文窗口"之间的鸿沟。我们必须走出IDE，向产品、运营等角色的同学去了解业务的形态、目标，去理解他们背后的焦虑。我们的工作不能只从一份需求文档开始，而是要参与到需求的诞生过程中，技术如何在这个过程中更好的进行赋能。当AI承担了大部分编码工作后，我们与人的沟通的能力就变得空前重要。比如我作为一个技术Leader，就需要重点去关注，如何清晰地向非技术背景的其他合作同事阐述一个复杂的技术决策？如何在一个有争议的技术会议上，通过共情其他同事与逻辑达成最后的共识？如何让团队更好的应用AI，从而激发所有成员的最大潜力？如何让技术团队不再纯执行，而是成为能够预见机会、定义问题、并用技术驱动业务增长的价值共创者。
最后
当然，以上仅为我个人现阶段的思考与体会，旨在抛砖引玉。若有不同见解，欢迎在评论区理性探讨，交流碰撞。