人类不会取代-Python

人类不会取代 Python

原文：towardsdatascience.com/human-wont-replace-python/

“很少有人知道 Python。每个人都知道‘人类’。”

– 英伟达首席执行官黄仁勋

来源：由 ChatGPT5 生成的 AI 内容

注意： 这篇文章是与Eitan Wagner**共同撰写的。

当 AI 打破语言障碍

你知道这一点：互联网上充满了诸如“编码已死”、“AI 是新的软件工程师”、“软件开发将在 2030 年变得过时”之类的说法。在这些预测背后，有一个吸引人的论点：我们正在经历编程演化的又一次迭代。低级语言，如汇编语言，让位于高级语言，如 C 和 Python。从那时起，Python 程序员可以舒适地忽略汇编级别。同样——论点是这样说的——自然语言现在可以取代经典编程语言，并成为构建软件的工具。此外，一旦完成向自然语言的转变，我们将生产出令人惊叹的生产级软件产品，同时却对“经典”代码的底层结构毫无察觉。

乍一看，这个论点似乎有道理，尤其是在考虑到它所受到的历史先例的轨迹。编程语言几十年来一直在向抽象和可表达性的高度发展。跟随这一趋势到其自然的结果，达到抽象层次的最顶端：人类语言，这是合情合理的。此外，语言只是思想的载体，对吧？所以，只要思想能够被表达，我们使用的具体语言似乎只是一个无关紧要的细节。

将思想放在中心，将语言仅仅视为一种技术工具来表达它们，这使得我们可以重申之前的论点，即：人们总是有关于新产品令人惊叹和富有创意的想法，但直到最近，他们只能通过用计算机自己的语言来表述这些想法来与计算机沟通。在这个观点中，程序员是多语言者，他们知道普通人不懂的语言，这是他们的超能力。只有他们知道如何说服计算机按照他们的意愿行事，就像知道可以控制未驯服元素的秘密复杂措辞的巫师一样。然而，如今，计算机已经进步，能够理解我们的语言，因此一个新的时代已经到来，在这个时代里，每个人都可以构建软件，而无需学习一种特殊语言。此外，这将使编程语言对（几乎）每个人来说都变得多余，而不仅仅是这些新来者。Python 和 Java 将遵循汇编语言和机器代码的道路，因为它们在自然语言之上几乎没有任何实际优势。

这些正是 NVIDIA 首席执行官黄仁勋在 2025 年 6 月伦敦 Tech 上发表的明确观点：

“AI 是伟大的平等化者。让我解释一下原因。在过去 50 年、60 年里，计算机科学成为了一个科学领域，它对数十亿人中的数千万人是可用的。这项技术很难使用。我们必须学习编程语言，我们必须设计它，我们必须设计这些非常复杂的计算机。数千万的人能够从这个特定领域受益，但现在，突然之间，出现了一种新的编程语言。 **这种新的编程语言被称为“人类”。 **任何人——大多数人不知道 C++，很少有人知道 Python。每个人都了解“人类”。你今天编程计算机的方式是请求计算机为你做某事，甚至编写程序，生成图像，写一首诗。只需礼貌地请求。”

虽然听起来优雅且令人信服，但理论和预测必须谨慎分析。这个主张或预测在实践中有说服力吗？到目前为止的证据并不明确。越来越多的代码是通过 AI 代理编写的，越来越多的非程序员正在使用 Vibe 编码平台（如 Base44）来创建，一些公司甚至冻结了招聘工程师的计划——但经典编程仍然充满活力。回到 2025 年 3 月，Anthropic 的首席执行官Dario Amodei表示：

“我们离一个世界不远了——我认为我们将在 3 到 6 个月内到达那里——AI 将编写 90%的代码，然后在 12 个月后，我们可能处在一个 AI 几乎编写所有代码的世界。”

尽管已经过去了七个月（我们是在 2025 年 10 月写下这些的），似乎人类程序员仍然是收入最高的群体之一。有迹象表明，AI 编程可能不像一些人希望的那样有用。在 METR 最近引起广泛讨论的研究论文中，发现 AI 反而让经验丰富的程序员工作效率降低，而不是提高，并且只接受不到 50%的 AI 代码生成。甚至还有专门收集 AI 恐怖故事的网站，表明这些代理是多么不可靠。当谈到全面投入“人类”编程时，一个新的职位名称正在出现，暗示那里可能正在酝酿麻烦：即“Vibe 代码清理专家”。这些只是表明，放弃经典编程的道路——如果我们确实在这条路上——至少不是一条平坦的道路的几个迹象。

AI 恐怖故事：怪物确实躲在衣柜里。

如何理解这些看似矛盾的模式，AI 代理的明显优势与他们在该领域的混合成功？处于革命之中总是令人困惑的时刻，因为很难知道哪些是短暂的趋势和注定要失败的实验，哪些是暂时的挫折和教学经验，这些经验一旦我们解决了问题，就会为重大转变奠定基础。

此时我们需要一个强大的概念框架来分析我们现在在哪里以及我们将要走向何方。在接下来的内容中，我们试图提出这样一个框架，并使用它来论证程序员和编程语言将长期存在，而自然语言不是编码层次结构中的下一步。

临界差异

让我们直接切入问题的核心：编程语言将长期存在的原因是它们（与自然语言不同）是形式化的，因此用它们编写的程序构成了一系列完全指定的指令。

当执行命令 x = 1+2 时，x 在执行后将始终接收值 3。这同样适用于任何软件中的任何命令——命令的预期行为没有歧义。正是这种属性使我们能够完全信任软件，知道今天工作的代码明天也会工作，一台机器上的代码在另一台机器上表现相同，等等。

当然，计算机的行为只有在指令所指向的级别上才是完全指定的。指令 x = 1+2 明确指定了存储在“x”中的值将是什么，但并没有指定这个信息在物理内存中的存储位置。因此，这样的指令在程序员所关注的级别上是完全指定的，正如他们在指令中所表述的那样（将 1 和 2 相加并将结果存储在变量 x 指向的位置），但在其他实现细节上是不完全指定的，这些细节被委托给编程的较低级别，并且可能在不同的系统条件下表现出不同的行为（例如，可用的内存地址）。

所有这些都适用于形式化的编程语言。另一方面，自然语言中的指令在相关的指令级别上天生是不完全指定的。例如，如果一个妇女要求她的丈夫“去超市买些牛奶”，丈夫自然会假设（大多数时候）动词“买”意味着“购买”，而不是“偷”。这里的要点是，命令（“买牛奶”）并没有完全指定如何执行这个动作，而是留给丈夫在执行任务时填补空白。

这是一种语言和人类交流中众所周知且常见的特征。笑话被设计成隐含地被理解，实际上，很多时候过度解释和完全指定意图会破坏幽默效果。人类陈述的不确定性有时被巧妙地利用，不同的意义层被设计给同时收听的不同听众（正如任何在孩子们听的时候与配偶分享信息的父母都深知的那样）。这也导致我们在对话中经常出现误解，即使是在与分享我们的文化或职业背景的人交谈时也是如此。当然，在商业和职业环境中，误解是常态的，例如，每个产品经理都知道如何明确地传达计算机项目的规格是多么困难，因为一个人认为显然的东西并不总是另一个人认为的那样——正如这个经典视频以可爱的方式所展示的：

在 AI 辅助编程的世界里，这个问题也是众所周知。告诉 AI 你希望你的代码单元测试通过；它们修复你的代码的可能性与修改测试的可能性一样大。在另一个最近的例子中，当 OpenAI 的 o1 模型与棋盘引擎（Stockfish）对弈时，它决定黑客 Stockfish 并重写其代码以获胜。这类案例通常被赞扬为“智能”的例子，但在更技术层面上，这些行为是未指定自然语言指令的例子。“任务是要‘战胜一个强大的棋盘引擎’——并不一定是在棋局中公平地获胜”，o1 在其“私人”草稿纸上写道。因此，它采用了可能的“具体化”之一。这种行为是否是程序员有意为之，这谁也说不准（正如人们可能会争论的那样，当一个人作弊时，他并没有“赢”，这再次突出了指令的不确定性）。^(1)

在 LLMs 的语境中，这种自然语言的特征也有其反面。给定一个目标代码片段或特定的图像，以及一个强大的 LLM 可供使用，是否存在一个能够精确生成该代码或图像的提示？还有一个后续问题：假设这样的提示存在，我们知道如何逆向工程并找到那个提示吗？在合理的假设下，这两个问题的答案很可能是负面的。因此，自然语言似乎不适合精确地制定编程语言被设计来执行的目标和任务。

这里的问题是：计算机能够融入人类社会，因为它们是可预测的——程序员可以自信地声明计算机被告知要做什么（或者，如果代码中存在错误，程序员可以审查、找到并修复这些指令以获得这种信心）。在从形式语言到非形式语言作为编程模式的转变中，我们永远失去了指令被紧密定义以使计算机执行我们意图的确定性。我们同样失去了对机器最终与我们的意图对齐的控制，因为没有保证有一个命令（例如提示）能够以 LLM 会遵循的方式捕捉我们的意图。

最重要的是，这是一个固有属性，属于通信媒介——自然语言与形式语言，它们构成了系统的输入。因此，这种限制无法通过改进 AI 系统本身来克服，无论是训练期间还是推理期间。当然，提供更多上下文和数据可以帮助缩小不确定性的范围，但并不能带我们进入一个与形式语言具有同等确定性和控制力的世界。即使在未来的 GPT-17 或 Claude-19.5 模型中，通过自然语言输入也将像今天一样不够具体。

编码即翻译

“软件构建的难点在于决定说什么，而不是说它”

——弗雷德里克·布鲁克斯博士，《没有银弹》

在明确了两种语言之间的区别之后，我们现在可以揭示当我们从一种语言转换到另一种语言时会发生什么，最重要的是，当我们把这一步从人（程序员）转移到计算机（AI 代理）时会发生什么。

让我们先考虑程序员作为翻译者：一类特殊的翻译者，他们从一种类型的语言（人类、自然、不具体）翻译到另一种（形式、完全具体）语言。我们能从这种类比中学到什么，从一般翻译的挑战到我们特定的用例？

翻译永远不会像外界看起来那么简单。不同的语言有不同的结构和惯例，这使得实现完美的翻译变得困难。例如，从英语翻译到法语，意味着从一种无性别的语言转换到一种有性别的语言，在某些情况下，这种转换将极大地改变段落被阅读和理解的方式。或者考虑翻译歌曲的歌词，这所涉及到的挑战：保持节奏、意义、文字游戏、文化参考等。所有这些在跨语言障碍时都是非平凡的。

面对这些挑战时，翻译者并不仅仅是将相同的意思从一种表达形式转换到另一种表达形式。相反，他们在将意义转移到新语言时做出了选择，构建了（有意识地或无意识地）不同意义维度之间的重要性层次。一个翻译者可能是在为歌手做翻译，因此强调匹配原始曲调，即使这意味着要重构整个诗句。另一个翻译者可能是在帮助非母语者理解原始歌词，因此优先考虑精确的口头翻译，即使结果与韵律毫不相干。

对于人类语言来说，当将指令从英语翻译成一种正式语言，如计算机程序时，这一点尤为如此。程序员面临的第一问题是任何翻译者都会遇到的问题：进入新语言可能不会顺利。新的（编程）语言可能会以源语言所没有的方式限制程序员^{(3)。同样，在自然语言中可以简单表达的表达方式，在目标编程语言中可能需要完全重构，反之亦然。编程语言有像其他语言一样的惯例和风格}(4)，不熟悉这些的人会生成难以阅读的代码，充斥着灾难性的错误。

此外，从一种不明确的语言到一种完全明确的语言的转变，迫使程序员/翻译者对自己的任务理解达到更高的清晰度。详细说明（即完全指定）如何处理各种情况的过程，不仅仅是写出已知的内容；这是一个发现和揭示所有隐藏的假设和后果的过程，这些假设和后果是源语言的不明确性允许掩盖的。

很重要的一点是明确这一点：很多时候，通过编码过程揭示出来的并不是“人类规格说明中原本的意思”，而是更接近于“由于从未完全思考清楚，因此在人类规格说明中未明确表达出来的内容”。^(5) 要用代码编写，就必须明确那些之前未明确指定的事项，因此，这是一个创造性的过程，也是对实际需求和编码应采取的方向的发现过程。^(6)

正是从这个事实中，我们最终意识到，每当我们将这一翻译步骤从人类转移到机器时，都会发生重大的变化：

• 首先，当我们让 AI 编写代码时，我们就从发现过程中抽身出来，对我们所构建的具体产品的关键方面视而不见。关于成本与速度、稳定性之间的权衡决策将在我们不知情的情况下进行，甚至我们甚至没有意识到这种权衡是必要的。关于代码的哪些部分应该模块化，哪些可以更加严格，这些决策也将在我们甚至不知道已经达到一个转折点的情况下发生。重要的是，其中很大一部分发生是因为我们放弃了作为编码者的角色，我们缺乏对代码细节的深入了解，因此我们可以给出我们认为完全指定的命令，但实际上并非如此。

• 其次，与人类程序员不同，AI 通过（有根据的）猜测弥合了不明确的指令和完全明确的代码之间的差距。它随机生成代码，使其与训练期间对类似指令所看到的相匹配。这里的关键是“随机”——任何被不明确的措辞所涵盖的内容，如果在训练数据中有任何支持，都可能在这个过程中出现。虽然这样的代码可能在某些基本技术层面上写得很好，但它自然会带来副作用，其中一些可能无害，但其他可能具有问题性的不可预见的影响。

这种基于统计的代码生成与人类程序员经历的以发现为导向的过程在本质上不同。人类程序员的决策是有意的——他们在意识到某种意义上，每一行代码将如何影响他们所工作的更广泛系统的情况下采取行动。这包括产品的其他部分；非编码利益相关者（经理、同事、投资者、客户）；以及他们的需求和愿望（工作与生活的平衡、声誉等）。AI 编码代理缺乏所有这些上下文或目标集，因此无法关注这些绊脚石，这些绊脚石是 vibe 编码者可能事后希望了解的。

底线是，总会存在权衡：我们在向 AI 的提示中留下越多的不明确之处，我们的代码就越不成熟。我们允许 AI 为我们做出更多我们不知道需要做出的决策（因为我们没有经历上述的发现过程），那么在发布产品并向公众——我们的指定用户和付费客户——保证其可靠性之前，我们就需要更多地重新审视这些决策。

自主性、责任感、Vibe 编码

我们在这里提到了我们编码的未来用户，确实，他们是系统中一个通常未被考虑的组成部分及其动态。他们无意中决定了我们可以在我们的开发流程中使用 vibe-coding（即纯粹在“人类”中进行编码）的地方。代表我们自主行动的人工智能代理非常强大，以正确的方式使用这种力量可以产生惊人的结果。但尽管人和机器都可以是自主的，只有人才能对他们创建的代码承担责任。正如我们下面将要论证的，这决定了 vibe-coding 在特定情况下是一种可行的编码方法。

那么，“自主性”（或“代理”）是什么意思呢？利用我们探讨的两种类型语言之间的区别，我们相信有可能消除这个术语的神秘感，并在技术意义上使其变得有用.^(7) 在我们看来，自主性是指一个设备或计算实体在给定空间内实现目标的能力，其中行动的指令（即目标以及“允许”的行动）是未充分说明的。给定一个具有技术约束的系统（即其物理和计算限制），并且假设该系统被训练去遵循用户指令，那么用户在指令中未明确说明的部分越多，系统就越具有自主性。被指示“做好事”的聊天机器人比被指示“在纽约市建立孤儿院做好事”的聊天机器人具有更多的自主性，甚至比被指示“在纽约市建立孤儿院做好事，并遵循所有当地、州或联邦的法律”的聊天机器人还要多.^(8)

然而，从这种意义上说，自主性并不能说明是什么决定了人工智能的行为。人工智能确实能够自主地从一个未充分说明的命令过渡到一个完全说明的命令，但它是完全由其程序、模型、提示和随机种子决定的。在这个观点中，是用户做出了选择，发布了一组未充分说明的指令，并希望人工智能不会通过对他们指示的意外解释来填补这些空白.^(9)

鉴于上述所有情况，任何人工智能行为的责任都完全落在用户的肩上。他们必须解释他们有什么保证，确保人工智能在去冲咖啡的路上不会，比如说，发动一场杀戮狂潮。答案可能在于与开发人工智能的公司签订的服务协议中，但当然，这仅仅是将问责的要求转移到了某个其他人类实体，而不是人工智能。将责任链回溯到人类或一组人类，这条链永远不会断裂。

责任程度和失败后果是决定在哪里采用 vibe-coding 的关键因素。PoC（原型）、侧项目以及探索性代码都是它繁荣的案例，因为用户并不关心正在构建的产品许多方面。他们只想用一些核心逻辑实现一些基本功能，而不必考虑许多细节（例如，后端开发者希望有一个 UI 调用他的 API，而不关心配色方案、包支持、Web 与移动支持等）。在这些情况下，任何合理的方法都可以，而且责任并不重要，因为没有人会严重依赖产生的系统。

此外，使用 vibe-coding 可以如此轻松地生成想法的原型，这可以极大地提高生产力。这种原因直接源于我们上面的分析：看到自然语言中一个语句的完整指定实例可以帮助开发者、产品经理和客户明确他们真正想要的是什么——这是探索和发现流程的一部分。回到 1986 年，弗雷德里克·布鲁克斯博士在他的论文《没有银弹》中巧妙地表达了这一点：

“构建软件系统最困难的部分是精确地决定要构建什么……我会更进一步地断言，即使是客户，即使与软件工程师合作，在构建和尝试他指定的产品的一些版本之前，也不可能完全、精确和正确地指定现代软件产品的确切需求**。

因此，当前技术努力中最有希望之一，它针对的是软件问题的本质，而不是偶然性，就是开发快速原型系统的方法和工具，作为迭代需求规格说明的一部分。”

正是在这里，程序员们非常乐意利用 AI 编码代理的自主性，我们对此感到惊奇，因为我们不必做出所有决定就能让某物运行起来。但是，将这些案例推广到涉及数百万美元的生产级代码世界，将会犯分类错误。

结论

在这篇文章中，我们试图阐述一个观点，即经典编码在不久的将来不会消失，也不会被“人类”所取代。我们论证，如果我们想要保留今天软件产品的大部分特性，形式化语言必须是我们与计算机交流的语言。在我们的结束语中，我们想分享一些关于编程未来的思考。

之前，我们将程序员比作翻译者，但也许更好的类比是：“代码是程序性思想世界的官僚机构，程序员是制定它的立法者”。*在现实世界中实施社会政治理念需要将理念分解成定义责任、资源和实施测量标准的官僚程序。以类似的方式，编程将抽象的技术和商业提案转化为具体、可衡量的流程，这些流程可以在有限的资源下在真实的机械系统中实际执行。如果不进行这种转变，计算机就无法行动，就像政策在现实世界中仅仅通过政治家的声明就无法实施一样——它必须被编码成法律。

当一个人学习编程时，他们确实学习了一种新的语言（就像新的银行出纳员需要学习银行业务的内部术语一样），但他们在工作中发展和转移到的技能与语言技能相当不同。这些包括（但不限于）：

• 如何将大问题分解成更小、模块化和可解决的子问题；

• 如何定义可执行、可追踪和可调试的软件流程；

• 如何封装系统的不同部分，使得它们的输入和输出完全指定，并可以作为与其他组件的接口/合同；

等等^(11)。这些是程序员在工作中带来的更深入技能。

使用 AI 编码代理进行编码到生产的改变是什么？在我们看来，主要的变化是现在，你对编码了解得越多，你就能越自由地指导 AI 做什么。随着经验的增加，更多的代码对你来说变成了“样板”，因为你知道你想要什么，可以更清晰地指导它，并且更容易地检测到实施风险。经验丰富的程序员知道如何指导 AI 使用特定的结构和包，如何提供具体示例和代码片段，以精确和正式地捕捉他们的意图，以及如何识别生成的代码是否足够。

因此，这些更深入的技能是能够带来回报的。如何构建它们？就像他们一直做的那样：通过真正地坐下来自己编码。构建项目，失败，调试，然后再构建。开始时不使用 AI，在必须时使用它，剖析你的错误，并重复。只有这样，你才能成为一个知道如何现实和有效地将问题分解成逻辑组件的人，这些组件实际上映射到存在且可行的事物，并且也会符合客户需求。

在接下来的几个月和几年里，程序员将花费时间的主要领域以及他们为了在岗位上有效工作所需的专业技能，肯定会发生重大变化。很难预测编程的未来会是什么样子。新的以 AI 为先的编程语言可能会出现，程序员可能需要从头开始学习他们的职业。尽管如此，我们相信，在未来的几年里，能够繁荣发展的程序员将是那些理解他们的核心技能不是编写完美的语法——而是将模糊的人类需求转化为正式、可执行的规范的人。在这个新时代，这种技能比以往任何时候都更有价值，而不是更少。程序性思想的官僚主义仍然需要深思熟虑的立法者。

脚注

1. 这也是阿西莫夫的《我，机器人》中的一个反复出现的主题，其中“伤害人类”的概念（如机器人第二法则所述）定义不明确，导致机器人以令人惊讶的方式行事。例如，拒绝向人类提供信息，以免信息伤害他们的感情。

   这些行为之所以令人惊讶，仅仅是因为人类语言允许我们以这种不明确的方式表达事物。在阿西莫夫的故事中，人类社会在制定机器人三大法则时，能够在机器人行为中嵌入不确定性，而没有意识到这种不确定性的程度。这种不确定性在编程语言中是不可能的。关于这一点，稍后将有更多介绍。↩︎

2. 例如，我们不考虑那些逐字逐句或逐像素描述程序或图像应该如何构建的提示。

   为了半正式地讨论，考虑长度为 N 的可能字符串。在我们的词汇中（包括空格和一些标点符号），有 32 个字符，因此有 32^N=2(5N)个可能的字符串。让我们将这个数字与具有 RGB 值从 0 到 255 的小型 250×250 像素图像进行比较。有 256^(3250250)=2¹⁵⁰⁰⁰⁰⁰个可能的图像。为了使字符串涵盖所有可能的图像，N 必须大约是 300K 个字符。因此，一个小图像对应于长度相当于小说的字符串。当然，这个计算是一个上限，人们可能想要产生的图像空间要小得多。这里的计算仅仅是为了说明，图像空间比自然语言能够真正捕捉的空间要大得多。↩︎

3. 现代编程语言不断演变，正是为了这个目的。新的需求出现，因此需要为程序员提供新的功能，以便他们能够轻松编程，找到与他们心中意义相匹配的“词”（命令）。↩︎

4. 例如，递归的概念在编程中很常见，但对于非程序员来说却很难理解。即使是循环，对于初学者来说也往往令人困惑。这将在自然语言输入级别上导致非常不同的规范，这取决于你是否知道这个约定（=经验丰富的程序员）或者不知道（门外汉）。↩︎

5. 因此，它不是通过经典的“更多上下文”方法来解决的，因为额外的上下文在开始时并不对用户可用——他们还没有发现它。↩︎

6. 以一个简单的例子来说明：在 Linux 系统中，rm是删除文件或文件夹的命令。当人类提示代码“删除文件夹 X”时，并没有指定应该对文件夹的内容进行什么操作，以及在什么条件下应该阻止删除，但rm命令的每个版本都完全指定了这些内容的行为。只有通过编写代码，我们才被迫解决人类语言允许我们留白的那些内容。↩︎

7. 当人们在人工智能的背景下使用这个术语时，似乎存在很多混淆，其中很大一部分源于我们自然的拟人化倾向。人们通过说“无人机将能够自己决定这样做”之类的说法来讨论人工智能的自主性，将决策权归咎于无人机、机器人以及我们周围的其它人工智能实体。这样的说法虽然简洁，但却掩盖了无人机只是严格遵循其代码，没有任何主动性和自由意志的事实。此外，由于人类的自主性导致了对自己行为的责任，我们已经开始听到一些将“责任”归咎于人工智能代理当它们造成伤害的情况。在有人建议人工智能应该在它们的（人工智能）同侪面前受审并被惩罚之前，还需要多久时间？↩︎

8. 我们在这里描述的可以被称为“弱自主性”，其中用户向人工智能系统提供一个未充分指定的目标，而经过训练能够执行指令的人工智能系统，使用某种统计模型选择（实际上无限多的）完全指定的行动计划之一。因此，弱自主性适用于我们今天拥有的系统，这些系统的目标是由外部来源（在我们的情况下，是人类）规定或插入的。“强自主性”，即系统拥有自己目标的能力，可能是获得意识的一部分，这超出了我们讨论的范围。↩︎

9. 即使在非常简单的场景中，这也是正确的。如果一个 Python 程序员编写了x=3+5，并且调试器显示在这个操作之后x==1，我们知道该把责任归咎于哪里：底层系统中的某个地方有 bug，程序员可以免责。现在考虑一个平行宇宙，在这个简单的操作被一个提示所取代，提示说“将 x 设置为以下两个数的和：三和五”——我们会知道问题在哪里吗？我们能否像这样轻易地免除这个场景中的程序员的责备？不，因为这是可能的——尽管可能性很小——AI 可能将这个命令理解成了与预期不同的方向——例如，也许它执行了x = 3+5 (mod 7)。然后还有 x 最终会变成x="eight"的情况……这种可能性甚至存在，突显了随着每次转向自然语言，我们如何失去控制和确定性，程序员将承担起构建具有更宽松组件的产品责任。↩︎

10. 这个观点也与丘奇-图灵定理有关，但这超出了我们在这里讨论的范围。↩︎

11. 另一个我们可以看到这种区别暗示的地方是在讨论新算法或流程时对伪代码的常见使用。伪代码是你从代码的语言特定语法中“脱衣”后剩下的，以其形式化的形式保持的想法。↩︎