2026西湖龙井茶官网DTC发售：茶农直供，政府溯源防伪到农户家 

在编写软件时，打字从来不是工作的核心。提示词工程也不是。

借助人工智能编程，编码步骤变得更容易了，而思考步骤却变得更难了。

你要求实现一个功能。人工智能构建了它。它能运行，也通过了测试。但它完全错了——架构本末倒置，解决了一个你根本不存在的问题。代码本身没问题，有问题的是你的需求规格说明。

这不是提示词工程的问题，而是心智模型的问题。

敲击键盘的时间减少了70%、80%甚至更多。反馈循环闭合得更快，样板代码消失了，在你喝完咖啡之前，初稿就已经呈现出来。但脑力工作并没有减少，只是向左转移了（即提前到了更早期的阶段）。

编码的本质究竟是什么

在人工智能出现之前，优秀开发人员的工作核心从来主要不是打字。键盘只是一个流程的最后一步，该流程大致如下：

你接收到一个问题。你花费时间——阅读文档、参加会议、与同行辩论、在淋浴时、在跑步时、在深夜盯着白板——来构建心智模型。这个系统实际上是如何工作的？这个功能在架构中处于什么位置？哪些约束条件是不可妥协的？有三种方式可能导致出错，哪一种最有可能发生？

构建这种心智模型的许多方面源于以往的编码经验。过去使用的编码隐喻。对问题领域的了解，这些知识并未出现在问题陈述的任何地方。其他开发人员用简略语提及的团队内部隐性知识，这些信息量巨大（“那是X构建的。”“哦，所以它会过度复杂且没有注释。”；“别忘了Y版本发布！”“对，我需要测试那个奇怪的边界情况。”）。理解客户或甲方偏好但未在任何规格说明中提及的事项。

然后，只有在那时，你才坐下来编写代码。打字是一种翻译过程。你是将你已构建的心智模型转换为机器可执行的语言。我个人的典型策略是用注释勾勒出即将编写的代码， sketching out 大致轮廓和整体图景，然后填充细节。优秀的开发人员能写出清晰的代码，因为他们拥有准确的心智模型。平庸的开发人员写出令人困惑的代码，因为他们的心智模型不完整——而代码忠实地反映了这种不完整性。

彼得·诺尔（Peter Naur）——2005年图灵奖得主、ALGOL语言的贡献者、巴科斯-诺尔范式的联合创造者——在1985年正式提出了这一论点。他的文章《作为理论构建的编程》[1] 提出，程序并非开发的主要产物。主要产物是共享的心智模型——即所有构建者所持有的关于问题的“理论”。代码是该理论投射到机器上的一种有损投影。当团队解散时，理论也随之消散。剩下的只是地图。它所描述的真实领域仅存在于构建者的头脑中。

地图并非疆域本身。 拥有共享心智模型的开发团队能生产出更紧凑、错误更少的代码——这并不是因为他们更聪明，而是因为地图与疆域的匹配度更高。代码反映的是团队真正理解的内容，而不仅仅是他们设法写下来的内容。

键盘是让模型变得可见的地方。它从来不是真正工作发生的地方。

人工智能编程的本质究竟是什么

人工智能编程需要相同的要素，但处理方式不同且范围有所扩大。

翻译层已经改变：你不再将心智模型直接转换为代码，而是将其转换为规格说明，再由人工智能将其转换为代码。但这个链条并非那么简单：在编写规格说明之前你需要构建的心智模型，比在编写代码之前所需的心智模型要广泛得多