“很少有人懂Python，但每个人都懂‘人类语言’。”
—— 英伟达（NVIDIA）首席执行官黄仁勋
图片来源：由ChatGPT5生成
语言的障碍
众所周知，互联网上充斥着诸如“编程已死”、“AI是新的软件工程师”、“软件开发将在2030年过时”等言论。这些预测的背后，隐藏着一个引人入胜的论点：编程正在经历又一次迭代演进。从早期的汇编（Assembly）等低级语言，演变到C语言和Python等高级语言。自那时起，Python程序员便无需关注汇编层面的细节。同样地，这一论点认为，自然语言如今可以取代经典的编程语言，成为构建软件的强大工具。更进一步，一旦完成向自然语言的转变，届时，人们将能够开发出令人惊叹的生产级软件产品，同时完全无需了解底层“经典”代码的复杂性。
乍看之下，这一论点颇具说服力，特别是考虑到其所借鉴的历史先例发展轨迹。几十年来，编程语言一直在向更高的抽象度和表达能力演进。顺应这一趋势，最终达到抽象层次的顶峰——人类语言，似乎是水到渠成。此外，语言不正是思想的载体吗？因此，只要思想能够得到表达，所使用的具体语言似乎只是一个无关紧要的细节。
将思想置于核心位置，而将语言仅仅视为表达思想的技术工具，可以进一步阐述上述论点：人类一直拥有令人惊叹和富有创造力的新产品构想，但直到最近，他们只能通过计算机自身的语言来与计算机进行沟通。在这种观点看来，程序员是精通多国语言的能手，掌握着普通人所不具备的语言技能，而这便是他们的超能力。只有他们知道如何“哄骗”计算机执行指令，就像巫师掌握着能驯服狂野元素的神秘咒语。然而，如今计算机技术已经取得了巨大进步，能够理解人类语言，一个新时代由此开启，每个人都可以无需学习特殊语言即可构建软件。此外，这还将使编程语言对于（几乎）所有人而言变得多余，而不仅仅是这些新入行者。Python和Java将步汇编语言和机器代码的后尘，因为它们相对于自然语言几乎没有实际优势。
以下是英伟达（NVIDIA）首席执行官黄仁勋于2025年6月在伦敦科技大会上表达的观点：
“AI是一个伟大的‘平衡器’。我来解释一下原因。在过去的五六十年里，计算机科学成为一个独立的科学领域，全球数十亿人中，只有数千万人能够接触并受益。这项技术使用起来很困难。人们必须学习编程语言，必须进行架构设计，必须设计这些极其复杂的计算机。数千万人因此受益，但现在，突然出现了一种新的编程语言。这种新的编程语言就叫做‘人类语言’。大多数人不懂C++，很少人懂Python，但每个人都懂‘人类语言’。如今，你编程计算机的方式就是请求它为你做些什么，比如编写程序、生成图像、创作诗歌。只需礼貌地提出要求即可。”
尽管这些理论和预测听起来优雅且令人信服，但仍需谨慎分析。这种说法或预测在实践中是否站得住脚？迄今为止，证据尚无定论。越来越多的代码通过AI代理生成，越来越多的非程序员使用“意念编程”（Vibe Coding）平台（如Base44）进行创作，一些公司甚至冻结了招聘工程师的计划——但经典的编程方式依然活跃。早在2025年3月，Anthropic首席执行官达里奥·阿莫代伊（Dario Amodei）曾表示：
“距离一个由AI编写90%代码的世界已不远——预计在3到6个月内就能实现；12个月后，AI或许就能编写几乎所有代码。”
然而，截至2025年10月，七个月过去了，人类程序员似乎仍是收入最高的群体之一。有迹象表明，AI编程可能不像一些人所希望的那样有用。METR最近一项备受讨论的研究论文发现，AI反而会降低经验丰富的程序员的工作效率，他们对AI生成的代码接受率不足50%。甚至有网站专门收集AI编程的“恐怖故事”，这表明这些AI代理并不可靠。当谈到完全依赖“人类语言”进行编程时，一种新的职位名称正在出现，这预示着潜在的问题：“意念代码清理专家”。这些只是诸多迹象中的一部分，表明放弃经典编程的道路——如果确实走在这条路上——至少并非一帆风顺。
AI恐怖故事：怪物确实隐藏在衣柜里。
面对这些看似矛盾的现象——AI代理的强大能力与它们在实际应用中喜忧参半的成功——我们该如何理解？身处一场革命之中，总是充满困惑的时期，因为很难分辨哪些是昙花一现、注定失败的潮流和实验，哪些又是为未来重大变革奠定基础的暂时挫折和宝贵经验。
当前，需要一个强大的概念框架来分析现状与发展方向。本文将尝试提出这样一个框架，并以此论证程序员和编程语言将长期存在，而自然语言并非编程层级的下一个演进阶段。
关键差异
问题的核心在于：编程语言之所以会长期存在，是因为它们（与自然语言不同）是形式化的，用它们编写的程序由一系列完全明确的指令构成。
执行命令 x = 1+2 时，变量x在执行后将始终获得值3。这同样适用于任何软件中的任何命令——其预期行为毫无歧义。正是这种特性，让人们能够完全信任软件，确信今天能正常运行的代码明天依然有效，一台机器上的代码在另一台机器上也会表现出相同的行为。
当然，计算机的行为仅在命令所针对的层面得到完全明确。命令 x = 1+2 精确地指定了“x”中存储的值，但并未指定这些信息在物理内存中的存储位置。因此，此类命令在程序员感兴趣的层面是完全明确的，正如其命令所述（计算1和2的和并将结果存储在变量x指向的位置），但在其他实现细节方面则不够明确，这些细节被委托给较低的编程层级，并可能在不同的系统条件下（例如，可用的内存地址）表现出不同的行为。
上述所有特性都适用于形式化的编程语言。然而，自然语言中的指令本质上是不明确的，即使在指令所涉及的兴趣层面也是如此。例如，如果一位妻子要求丈夫“去超市买些牛奶”，丈夫通常会自然地认为“买”是指“购买”，而非“偷窃”。这里的重点是，该命令（“买牛奶”）并未完全指定如何执行该动作，而是由丈夫在执行任务时自行补充细节。
这是语言和人类交流中一个众所周知且普遍存在的特点。笑话的意图通常需要心领神会，事实上，过度解释和完全明确其意图往往会破坏幽默效果。人类言语的这种不明确性有时会被巧妙利用，针对同时在场的不同听众传达多层含义（任何在孩子在场时与配偶交流信息的父母都深谙此道）。这也会导致日常对话中频繁的误解，即使是与拥有相同文化或职业背景的人交流时亦是如此。当然，在商业和专业环境中，误解更是司空见空，例如，每个产品经理都深知在计算机项目中清晰无误地传达规范有多么困难，因为一个人认为显而易见的事情，在另一个人看来却未必如此——正如这段经典视频以一种可爱的方式所展示的那样：
在AI辅助编程的世界里，这个问题同样众所周知。如果告诉AI希望代码的单元测试通过，它既可能修复代码，也可能直接修改测试。在另一个近期案例中，当OpenAI的o1模型与国际象棋引擎Stockfish对弈时，它竟然决定入侵Stockfish并重写其代码以求获胜。这类案例常被誉为“智能”的体现，但在更技术层面，这些行为是不明确的自然语言指令的例证。o1在自己的“私人草稿本”中写道：“任务是‘战胜强大的国际象棋引擎’——并非必须以公平的游戏方式取胜”。它因此采纳了对不明确指令的一种可能的“具体化”理解。这种行为是否是程序员所期望的，无人能知（事实上，有人可能会争辩说，作弊并不算“赢”，这再次凸显了指令的不明确性）。1
在大型语言模型（LLM）的语境下，自然语言的这一特性还存在另一面。给定一段目标代码或特定图像，以及一个强大的LLM，是否存在一个能够精确生成该代码或图像的提示词？进一步来说，假设这样的提示词确实存在，人们是否知道如何逆向工程并找到它？在合理假设下，这两个问题的答案都可能是否定的2。因此，自然语言似乎不适合用于精确地制定编程语言旨在完成的目标和任务。
症结在于：计算机之所以能够融入人类社会，是因为它们可预测——程序员能够自信地声明计算机被告知要做什么（或者，如果代码中存在错误，程序员可以审查、发现并修复这些指令以恢复这种信心）。在从形式化语言转向非形式化语言作为编程模式的过程中，人们将永远失去对指令是否足够严谨以使计算机完全按照意图行事的确定性。同样，人们也将失去对机器最终能否与意图保持一致的控制，因为无法保证存在一个命令（例如提示词）能够以LLM会遵循的方式准确捕捉人类的意图。
最重要的是，这是通信媒介——自然语言与形式化语言——的固有属性，它构成了系统的输入。因此，无论在训练还是推理过程中，AI系统本身的任何改进都无法解决这一局限性。诚然，提供更多上下文和数据有助于缩小不确定性范围，但无法将我们带入一个与形式化语言具有同等确定性和控制力的世界。即使是未来的GPT-17或Claude-19.5模型，通过自然语言输入的指令也将像今天一样不明确。
编程即翻译
“构建软件的难点在于决定说什么，而不是如何去说。”
—— 弗雷德里克·布鲁克斯博士，《没有银弹》
在明确区分了这两种语言类型之后，这样一来，就能更清晰地理解语言转换过程中发生的变化，以及更重要的是，当这一转换步骤从人类（程序员）转移到计算机（AI代理）时会发生什么。
可以首先将程序员视为翻译者：他们是一类特殊的翻译者，负责将一种类型的语言（人类的、自然的、不明确的）翻译成另一种（形式化的、完全明确的）语言。从这种类比中，从一般翻译的挑战中，可以为我们具体的应用场景学到什么？
翻译工作远非外行人想象的那么简单。不同的语言拥有不同的结构和约定，这使得实现完美翻译变得困难重重。例如，从无性别的英语翻译到有性别的法语，在某些情况下，这种转换会极大地改变一段文字的阅读感受和接受方式。再比如，考虑翻译歌曲歌词所带来的挑战：保持韵律、意义、文字游戏、文化典故等。所有这些在跨越语言障碍时都绝非易事。
因此，面对这些挑战时，译者不仅仅是将相同的意义从一种表达形式转换为另一种。相反，他们会在将意义转化为新语言时，在不同的维度之间（有意识或无意识地）构建一个重要性等级，并据此做出选择。例如，一位译者可能为歌手翻译，因此即使需要重构整个诗节，也会强调与原曲调的匹配。而另一位译者可能旨在帮助非母语人士理解原歌词，因此即使翻译结果不押韵，也会优先考虑精确的字面翻译。
适用于人类语言的道理，在将英语指令翻译成形式化语言（如计算机程序）时更是如此。程序员面临的第一个问题与任何翻译者无异：转换到新语言可能不会一帆风顺。新的（编程）语言可能会以源语言未曾限制的方式约束程序员3。同样地，在自然语言中可以简单表达的短语，在目标编程语言中可能需要彻底重构，反之亦然。编程语言像任何其他语言一样，拥有其自身的约定和风格4，不熟悉这些约定和风格的人将生成难以阅读且充满灾难性错误的代码。
此外，从不明确语言到完全明确语言的转换，迫使程序员/翻译者对当前任务的理解达到更高的清晰度。详细阐明（即完全明确）如何处理各种情况的过程，不仅仅是写下已知内容；它更是一个发现和揭示所有被源语言不明确性所掩盖的隐藏假设和潜在影响的过程。
需要明确指出的是：很多时候，通过编码过程所揭示的并非“人类规范中最初的意图”，而是“由于从未被完全思考透彻，而在人类规范中未被明确阐明的内容”5。要编写代码，就必须明确先前未明确的事物，因此，这是一个创造性过程，也是一个发现实际需求和编码方向的过程6。
正是基于这一事实，人们最终能够认识到，每当将这一翻译步骤从人类转移到机器时，都会发生以下重大变化：
- 首先，当让AI编写代码时，人们将脱离发现过程，对所构建产品的关键方面一无所知。关于成本、速度和稳定性权衡的决策将在人们不知情的情况下发生，甚至人们可能根本意识不到需要进行这样的权衡。关于代码哪些部分应模块化、哪些部分可以更僵化的决策也将同样发生，再次强调，人们甚至可能不知道已经达到了一个关键的岔路口并做出了选择。重要的是，这很大程度上是因为放弃了作为编码者的角色，人们缺乏对代码细节的深入了解，因此可能会发出自认为完全明确的指令，但实际上并非如此。
- 其次，与人类程序员不同，AI通过（有根据的）猜测，弥合了不明确指令与完全明确代码之间的鸿沟。它随机生成代码，使其与训练过程中见到的类似指令保持一致。这里的关键在于“随机”——在训练数据中，任何被不明确措辞所涵盖的内容，都可能在此过程中出现。虽然这样的代码在某些基本技术层面上可能写得很好，但它自然会带来副作用，其中一些可能是无害的，但另一些则可能产生意想不到的、问题重重的影响。
这种统计驱动的代码生成与人类程序员所经历的发现驱动过程有着根本性的不同。人类程序员的决策是有意的——他们在某种程度上意识到每一行代码将如何影响其所工作的更广泛系统。这包括产品的其他部分；非编码利益相关者（经理、同事、投资者、客户）；以及他们自身的需求和愿望（工作与生活平衡、声誉等）。AI编程代理缺乏所有这些上下文或目标集合，因此无法像“意念程序员”那样，预见并规避那些事后可能希望自己早知道的障碍。
归根结底，权衡始终存在：给AI的提示中未明确的内容越多，代码的生产就绪度就越低。若允许AI代为做出原本不知需做的决策（因为我们未经历上述发现过程），那么在发布产品并向公众——即我们的指定用户和付费客户——保证其可靠性之前，将需要更多次地重新审视这些决策。
自主性、责任与意念编程
文章中提到了代码的未来用户，他们确实是系统及其动态中常被忽视的组成部分。他们无意中决定了在开发流程中，“意念编程”（即纯粹使用“人类语言”编程）在何处可行。能够代表人类自主行动的AI代理极其强大，以正确方式运用这种力量可以带来惊人的成果。但尽管人类和机器都可以是自主的，只有人类才能为他们创建的代码承担责任。下文将论证，这决定了“意念编程”在何种情况下是可行的编程方法。
什么是“自主性”（或“能动性”）？基于两种语言类型的区分，将有可能揭开这个术语的神秘面纱，使其在技术层面更具实用价值7。在理解中，自主性是设备或计算实体在给定空间内实现目标的能力，其中行动指令（即目标和“允许”的行动）是不明确的。给定一个具有技术约束（即其物理和计算限制）的系统，并假设该系统经过训练以遵循用户指令，那么用户在指令中未明确说明的内容越多，系统就拥有越高的自主性。一个被指示“做好事”的聊天机器人比被告知“在纽约市建立一个孤儿院来做好事”的聊天机器人拥有更高的自主性，而后者又比被告知“在纽约市建立一个孤儿院，并遵守所有地方、州或联邦法律法规来做好事”的聊天机器人拥有更高的自主性8。
然而，这种意义上的自主性并未说明是什么决定了AI的行动。AI确实是自主的，因为它能够接受不明确的指令并将其转化为完全明确的指令，但其进行这种转换的方式完全由其程序、模型、提示词和随机种子决定。在这种观点看来，是用户做出了选择，发出了不明确的指令，并寄希望于AI不会以出乎意料的方式来填补指令中的空白9。
鉴于上述所有论点，AI所做的一切的责任都将完全落在用户身上。用户必须解释他们有什么保证，确保AI不会在去冲咖啡的路上突然进行一场杀戮狂欢。答案可能存在于与AI开发公司的服务协议中，但当然，这只是将问责要求转移到其他人类实体，而从未转移给AI。责任链条始终连接着一个或一群人类，从未断裂。
责任程度和失败后果是决定“意念编程”适用范围的关键因素。概念验证（PoCs）、个人项目和探索性代码都是“意念编程”蓬勃发展的领域，因为用户并不关心所构建产品的诸多方面。他们希望通过一些核心逻辑让基本功能运行起来，而无需考虑许多细节（例如，后端开发人员希望有一个UI来调用其API，而无需关心配色方案、包支持、Web端或移动端支持等）。在这些情况下，任何合理的方法都可行，责任也并非首要考量，因为没有人会严重依赖所产生的系统。
此外，通过“意念编程”如此轻松地生成想法原型，可以极大地提高生产力。其原因直接源于上述分析：看到自然语言陈述的完全明确的实例，可以帮助开发人员、产品经理和客户自己弄清楚他们真正想要什么——这是探索和发现流程的一部分。早在1986年，弗雷德里克·布鲁克斯博士在他的论文《没有银弹》中就雄辩地阐述了这一点：
“构建软件系统最困难的部分是精确地决定要构建什么……我甚至会进一步断言，对于客户而言，即使与软件工程师合作，在构建并尝试过其所指定产品的某些版本之前，也几乎不可能完全、精确、正确地指定现代软件产品的确切需求。
因此，当前最有前途的技术努力之一，也是解决软件问题本质而非偶然因素的努力之一，就是开发系统快速原型的方法和工具，作为需求迭代规范的一部分。”
正是在这一点上，程序员们非常乐意利用AI编码代理的自主性，并惊叹于无需做出那么多决策就能让某个东西运行起来。但若将这些案例推断到涉及数百万美元风险的生产级代码世界中，那将是一个类别错误。
总结与展望
本文旨在阐明经典编程不会很快消失，也不会被“人类语言”取代的观点。文中论证了，如果要保留当今软件产品所具备的许多特性，那么形式化语言必须是与计算机交流的语言。在文章结尾，将对编程的未来分享一些看法。
此前，曾将程序员比作翻译，但或许更好的类比是：“代码是程序化思想世界的‘官僚体系’，而程序员则是编写这些‘法律’的‘立法者’。”在现实世界中实现一个社会政治理念，需要将其分解为定义责任、资源和实施衡量标准的官僚流程。编程以类似的方式，将抽象的技术和商业提案转化为具体的、可衡量的流程，这些流程可以在资源有限的实际机械系统中得以真实执行10。若不进行这种转换，计算机便无法行动，正如一项政策不能仅仅通过政治家的口头声明就在现实世界中生效一样——它必须被编纂成法律。
当一个人学习编程时，他们确实是在学习一门新语言（就像新银行柜员需要学习银行业的内部术语一样），但他们在工作中培养并能从一种编程语言迁移到另一种编程语言的技能，与纯粹的语言技能有所不同。这些技能包括（但不限于）：
- 如何将大问题分解为更小、模块化且可解决的子问题；
- 如何定义可执行、可跟踪和可调试的软件流程；
- 如何封装系统的不同部分，使其输入和输出完全明确，并可作为与其他组件的接口/契约；
等等11。这些才是程序员工作中带来的更深层次的技能。
在AI编码代理辅助下，生产级编码发生了什么变化？主要变化在于，如今，对编码了解越多，就越能自如地指导AI执行任务。随着经验的积累，更多的代码对程序员来说将成为“样板代码”，因为他们清楚自己想要什么，能更清晰地指示AI完成任务，也更容易发现潜在的实现风险。经验丰富的程序员知道如何指导AI使用何种结构和包，如何提供精确且形式化地捕捉其意图的具体示例和代码片段，以及如何判断生成的代码是否符合要求。
因此，这些深层技能才是带来回报的关键。如何培养这些技能？就像他们一直以来所做的那样：亲自动手编写代码。构建项目，经历失败，调试错误，然后再次构建。从不使用AI开始，在必要时才使用它，剖析错误，然后重复这一过程。只有这样，才能成为一个能够实际且有效地分解问题，将其转化为对应现实存在且可行的逻辑组件，并同时满足客户需求的人。
未来数月乃至数年，程序员的工作内容以及他们为有效完成工作所需的专业知识，无疑将发生重大变化。很难预测编程的未来会是怎样。新的AI优先编程语言可能会出现，程序员可能需要从头开始学习他们的职业。尽管如此，本文认为，未来几年内能蓬勃发展的程序员，将是那些明白其核心技能并非编写完美语法，而是将模糊的人类需求转化为形式化、可执行规范的人。在这个新时代，这项技能将比以往任何时候都更有价值，而非减弱。程序化思想的“官僚体系”仍然需要深思熟虑的“立法者”。
脚注
- 这也是艾萨克·阿西莫夫《我，机器人》中反复出现的主题，其中“伤害人类”（机器人三定律中的第二定律）的概念定义不明确，导致机器人行为出人意料。例如，机器人会拒绝向人类提供信息，以免信息伤害人类的感情。
这些行为之所以令人惊讶，正是因为人类语言允许我们以如此不明确的方式陈述事物。在阿西莫夫的故事中，人类社会在制定机器人三定律时，能够在机器人行为中植入不确定性，而没有意识到这种不确定性的程度。这种不确定性在编程语言中是不可能存在的。↩︎
- 例如，不考虑那些逐字母或逐像素地详细说明程序或图像应如何构建的提示词。
