为什么AI编程能快速落地？

2024 年预期的 AI 应用爆发并没有到来，但是编程领域却是个特例。AI 编程工具正在引领大模型落地的浪潮，展现出明显的产品市场契合度（Product Market Fit，PMF）。

从市场表现看，编程领域的 AI 发展最为迅猛，一批估值增长最快的 AI 初创公司，比如 Cursor、Windsurf、Devin 等主营业务都是构建编程智能体。在 2024 年 12 月，Cursor 的开发商 Anysphere 宣布完成了超过 1 亿美元的 B 轮融资，投后估值高达 26 亿美元。孵化自北京大学软件工程研究所的硅心科技，专注于企业私有大模型部署，也于今年 1 月宣布成功完成 B 轮融资。

在实际应用方面，AI 编程的渗透率已经达到了一个惊人的水平。据谷歌透露，超过 25% 的新代码是由人工智能生成。Github 表示他们目前新写的代码中由 30% 都是在 Github Copilot 辅助下完成的。除了大型科技公司，个人开发者也借助 AI 工具也实现了开发效率的显著提升，编程能力得到全面增强。仿佛一夜之间，所有程序员都用 AI 武装上了自己。

与此同时，模型性能也在持续突破，在软件风格基准测试 SWE-bench verified 中，GPT-o3 模型准确率达到 71.7%，相比 GPT-o1 模型提升超过 20%。在 CodeForces 竞赛中，GPT-o3 模型更是达到 2727 ELO 分，远超 O1 的 1891 分，展现出强劲的技术进步势头。似乎模型的进化仍在狂飙。

那么，为什么是编程领域率先实现了 AI 的有效落地？

AI 跑通了 PMF 是一个结果，而非原因。其背后的根本原因是编程领域独特的“可信验证”机制。

而要理清这一问题，我们不妨先从 AI 编程的发展现状入手。

AI 编程工具的发展历程

AI 编程工具的发展呈现出明显的自动化演进路径，目前按照自动化程度大致可分为三类：

首先是以早期的 Github Copilot 为代表的代码补全工具。这类工具主要提供实时代码提示和自动补全功能，并不能主动编写代码。自动化程度相对较低。随着技术发展，这类工具正在向更高级的智能编程助手演进，逐步融入更多自动化特性。

第二类是以 Cursor、MarsCode 为代表的半自动编程工具，标志着 AI 编程迈入了更高级的发展阶段。这类产品不仅提供代码补全功能，还创新性地引入了“Apply（应用）”机制，让 AI 生成的代码可以一键直接集成到目标文件中。用户不需要再把代码复制过去，自己进行调整修改。虽然自动化程度有所提升，但仍需要开发者的持续参与和判断，体现了“人机协作”的特点。

第三类则是以 Devin 为代表的全自动编程工具。这类工具自动化程度最高，Devin 被称为全球首个 AI 程序员，可以自主调试部署。构建部署应用、自主调试等多项能力。支持使用 AI 规划进行任务分解，并自动部署代码。用户只需下达任务指令，静待结果即可，就像与真实程序员协作一样。

AI 编程工具的发展历程清晰展现了一条从辅助到自主的演进路径。第一代代码补全工具专注于提升专业程序员的编码效率，通过智能补全实现段落级别的开发加速。随后，以 Cursor 为代表的半自动工具将 AI 能力进一步扩展，通过代码直接应用等功能，在保持人工把控的同时显著提升了开发效率。而 Devin 的出现则开创了全自动编程的新范式，实现了从需求理解到部署的端到端自主开发。

这一演进过程本质上反映了 AI 编程范式的重要转变：从“实时交互”走向“批量处理”。这不仅降低了用户参与的频率，更重要的是大幅降低了编程门槛，使得 AI 编程工具的受众群体得到显著扩展。

代码生成其实更难？

“代码的关键词少，规则固定，所以更容易生成。”这是一种常见的评论。乍看似乎很有道理，相比自然语言浩如烟海的词汇量，编程语言的关键字确实少得多，采样空间相比自然语言小太多了。

但这种“词少就容易”的逻辑其实经不起推敲。如果按这个逻辑，数学问题应该是最容易的才对——数学符号更少，规则更严格。但现实恰好相反，大模型在数学领域的表现并不理想。

这种误解的根源在于混淆了“生成”和“应用”两个截然不同的阶段。在生成阶段，编程语言的有限词汇让模型的选择空间大大缩小。但在实际应用阶段，代码的难度远超自然语言。

在对话时，用户对大模型的容忍度很高。它可以犯语法错误，可以前后矛盾，可以逻辑混乱，我们依然能从中提取有价值的信息，甚至我们自己都发现不了他有语法错误。但代码生成完全是另一个维度的挑战——它就像数学题，代码要么能跑通, 要么跑不通，不存在“基本正确”或“大致可用”的中间状态。每一个分号、每一处缩进、每一个变量名，都必须精确无误。这种对精确性的严格要求，也注定了代码任务的难度其实要更高的。

可信验证机制

AI 编程成功的核心原因，在于它具有一种可信验证机制。

什么是可信验证？简单而言，就是一种能够快速、客观地判断 AI 输出结果的可用性的验证模式，具备三个关键特征：

1. 客观性：验证结果不依赖人或者 AI 模型的主观判断；

2. 即时性：能够立刻得到验证结果；

3. 确定性：验证结果是非黑即白的；

这种可信验证机制对 AI 编程领域产生了两个方向的影响。使其达到了“能用且好用”的状态。

从应用端来说，编程领域的可信验证机制，为 AI 应用创造了一个近乎完美的用户体验闭环。

代码编写后，需要使用编译器将其翻译成机器可执行的程序。同一种语言会使用统一的编译器，会基于严格设定的语法规则，这有效保证了客观性。

编译后的结果也是二元的，只有“能运行”和“不能运行”两种状态，不存在模棱两可的情况。让用户不需要主观判断，可以完全依据客观结果来做决策。此外，编译过程通常时间较短，可以让用户及时知道 AI 生成的代码是否可用。

这种依赖编译器的可信验证，几乎不需要用户的专业知识，只要他能点“运行”按钮就够了。这极大扩展了 AI 编程工具的受众群体。这也解释了为什么现在很多零知识用户都在尝试使用 AI 来写程序。

所谓“零知识用户”，指的是那些不懂编程但想开发应用的人。这类用户对可信验证的需求最为迫切，因为他们无法自行处理异常情况。这个概念同样可以推广到 AI 的其他应用领域。

在所有 AI 应用场景中，很少有哪个领域能像编程这样拥有如此理想的验证机制。这也解释了为什么 AI 编程工具能够率先实现规模化应用——它为用户提供了一个可靠、高效、低门槛的使用环境。

再从模型端来说，为什么大模型在编程领域的进步如此显著？答案可能会让人意外：在当前训练数据普遍枯竭的背景下，编程或许是大模型为数不多可以持续进步的领域。原因还是在于可信验证。

让我们先看看大模型训练的困境。业界频繁强调自家模型在代码和数学方面的突破，却很少宣称“AI 说话更像人了”。这背后是一个公开的秘密：自然语言训练数据正面临枯竭危机。在大模型训练中，数据质量与模型架构同等重要。数据的枯竭，就意味着模型能力提升也在放缓。

面对这个困境，大模型厂商通常采取两种应对策略：一是人工生产新数据，通过网络爬取或人工编写；二是使用更高级的模型合成数据。但这两种方案都存在明显缺陷：人工生产成本高昂，而合成数据则可能导致模型崩溃。大量研究表明，质量差的合成数据会让模型输出逐渐偏离人类表达方式，加重模型幻觉问题。

业界主要依赖两种方式来判断合成数据质量：用更强大的模型筛选，或依靠人工来主观判断。这不仅成本高昂，还难以规模化，且可靠性无法保证。一旦涉及到主观意识，它就很难设置统一标准。会导致数据质量参差不齐。

可信验证机制有效保证了代码合成数据质量的下限。

人类和 AI 写的代码都只有正确性这一客观评判标准。只要代码能通过编译和运行，两者代码就可以看作等价的。无非是谁写的质量更高的问题。但这保证了合成数据具备基本的训练价值。这等价于有成千上万个不知疲倦的初级程序员在持续产出数据。

可信验证机制让合成数据形成良性循环：模型生成代码，验证机制筛选，有效代码反馈回训练集。有趣的是，通过这种方式生成的代码，质量要高于 GitHub 上很多代码。这种低成本的质量保证机制，确保了模型在代码领域能持续提升。

应用端和模型端的双向价值完美解答了 AI 商业化的两大难题：用户敢不敢用，模型怎么持续进步。特别是在企业级市场，可靠性一直是最大的痛点。而可信验证提供了一个完整的解决方案：输出结果可控可验证，配合自动化测试框架和现有的代码审查机制，极大降低了应用风险。此外，对零知识用户的友好让 AI 编程迅速破圈。如此也就不难理解为什么 AI 编程普及率那么高了。

AI 编程存在的问题

尽管 AI 编程拥有独特的可信验证机制，但它依然存在很多问题。

第一，AI 生成的代码生成质量有待提高。可信验证机制确实为代码质量提供了一个基本保障——能运行的代码至少是“可用的”。但“可用”并不等于“好用”。当前 AI 生成的代码仍然面临着多个层面的质量问题：比如代码风格不一致、代码性能不稳定、在面对复杂工程时无法处理复杂的依赖关系。

大语言模型在代码生成中依然存在幻觉问题和不稳定性，这可能导致代码风格和命名规范的不一致，甚至出现歧义名称。虽然可以通过提示词进行一定程度的约束，但效果有限。这种代码风格的问题表面上看对程序运行影响不大，但到后期人类的阅读难度增大、甚至连 AI 都会被自己的代码搞混。严重时可能导致程序难以继续开发。

可信验证可以保证程序的最低运行标准，但现实中的软件往往需要根据具体场景进行优化。当前的大语言模型在场景评估和针对性优化方面仍显不足。这一局限性在复杂工程中尤为明显：当对软件进行优化时软件架构的权衡和优化往往需要基于实际环境作出决策，才能找到它的问题。而 AI 目前并不具备这样的分析能力。

这也解释了为什么零基础用户通常只能借助 AI 完成一些基础程序开发，比如快速搭建简单的网站或小程序。但当需要扩展功能或深化开发时，往往会遇到瓶颈。当用户缺乏对软件结构的深入理解时，而仅依赖 AI 目前还无法有效构建和优化复杂的软件架构。虽然 AI 能够快速实现一个框架，但对于核心功能的开发往往需要大量重构和优化工作。

第二，AI 编程对语言支持并不平衡。对于较为灵活的编程语言，容错率较高的语言支持效果更好（如 Python）这里主要有两点原因：

首先是训练数据量的差异。Python 作为 AI 时代最火的编程语言，开源社区为其提供了海量的高质量训练数据。而其他语言的数据量相比较少。

其次是语言特性的影响。Python 的语法相对灵活，容错性更高，这使得 AI 更容易生成可用的代码。相比之下，Java 等强类型语言的语法约束更严格，对代码生成的要求也更高。所以成功率也会低一些。

第三个问题，虽然 AI 编程工具都在追求更高程度的自动化，但“批处理”式的开发模式未必是最优解。这种模式虽然效率看似提高了，却削弱了用户对代码变更的实时把控，反而可能增加认知负担。Devin 在这个问题上表现的淋漓尽致。

以 Devin 为例，这个被誉为全球首个 AI 程序员，号称具备全栈开发、自学新技术、构建部署应用、自主调试等多项能力。初次体验时，这种全自动的开发体验确实令人惊艳。就像拥有了一个 AI 实习生，可以独立完成任务，让我能专注于其他工作。

但实际体验下来，相比 Cursor 等半自动 AI 编程工具，存在两个致命问题：一是反馈周期过长，用户需要等待较长时间才能知道结果是否正确。如果指令有误或思路错误，前期的等待就成了纯粹的时间浪费，沉没成本显著提高。二是调试成本的剧增。AI 生成的代码量越大，理解成本就越高，调试时常常难以判断到底是代码生成的问题，还是操作出了偏差。这对零知识用户来说尤其困难。

在软件开发生命周期中，缺陷修复的成本与发现时间呈指数级关系。越晚发现问题，修复成本就越高。软件开发从需求分析、系统设计、代码实现到测试验证、运行维护，是一个环环相扣的过程。当 AI 接管的越多，就导致发现问题的环节推后。而此时的修复不仅涉及单个函数，还可能引发连锁反应，甚至出现架构设计层面的缺陷，需要整体上重新设计。开发人员在此时往往需要深入理解 AI 生成的代码，才能进行有效修复。

笔者专门做了个实验：完全以零知识用户的身份，让 Devin 写代码，再用 Claude 来 debug。实际体验下来，Devin 写了 20 多分钟的程序，Claude 修了一个小时，核心功能依然没能跑通。只能选择重做。

与自动驾驶不同，开车时你可以随时接管，因为车辆的当前状态是显而易见的。但在编程中，如果 AI 走错了方向，之前的工作就全部作废了。那几十分钟的等待，就真的变成了纯粹的时间浪费。得到的是你和 AI 都处理不了的一大堆代码。

AI 编程的未来发展：更高级的可信验证

目前应用端的可信验证还很初级，主要是看代码“能不能跑”，考虑的是终端输出结果。但随着技术发展，会出现更高级的可信验证方法，考虑更多的因素。

例如现代 IDE 已经能够自动检测性能隐患和安全漏洞。这些自动化的质量评估机制同样可以传递给大模型——它们同样具备客观性和即时性，只是验证维度更加丰富。

将 DevOps 实践等现代化的软件工程实践方案引入 AI 辅助开发流程，建立更完善的代码质量保障体系，确保 AI 生成的代码不仅能够运行，更能够满足现代软件工程的高标准要求。及时测试并反馈。自动化测试框架能够生成测试用例、检查边界条件、验证业务逻辑，包括对代码性能进行检测，提供了另一层次的可信验证。

这些客观的质量指标同样可以反馈到模型。随着验证机制的不断完善，AI 编程将会从“基本可用”进化到“高质量”，而像 Devin 这样的全自动编程工具也将迎来更广阔的应用空间。因为它代表了 AI 编程的未来方向：真正实现开发者的解放，让人类专注于更具创造性的工作。尽管我们不知道它什么时候能被实现。

但是笔者认为这种 AI 编程可能依然不适合零知识用户，它的未来或许就是极大的增加程序员的生产力。对于零知识用户，或许零代码平台（比如 Dify）更可靠。因为它不需要担心“能不能跑起来”的问题。

AI 编程领域的成功经验给我们一个重要启示：任何领域要想成功应用 AI，都必须建立起有效的可信验证机制。

虽然不是每个领域都能像编程那样拥有编译器这种精确的验证工具，但我们可以借鉴这一思路，建立适合各自领域特点的验证体系。这个验证机制无需一开始就做到完美，但至少要能给出基本的可用性判断。模型的上限很重要，但是对于大模型的应用，模型的下限同样重要。可信验证不仅能降低 AI 应用的使用门槛，还能为模型优化提供可靠的反馈数据。AI 领域最理想的场景，应该同时具备“用户友好”和“模型可进化”这两个特质。

参考文献

1.https://www.nature.com/articles/s41586-024-07566-y

2.https://github.blog/news-insights/octoverse/octoverse-2024/

运营/排版：何晨龙