用 AI 编程，写提示词如今成了最慢、Bug 最多的方式。忘掉那些巧妙的提示词吧。这里有一份 AI 编程生产力实战指南，包含你在别处找不到的洞见。

当《人月神话》遇上 10 倍 AI 开发者

如果你做过软件开发，很可能经历过企业那种轰轰烈烈的降本运动：生产力突然成了裁员的魔法口令。管理层最爱提的就是神话中的 10 倍开发者。

Frederick P. Brooks Jr. 的《人月神话》被顺手曲解成：增加开发者只会拖慢项目。但我们开发者太清楚软件工程的机房里究竟发生着什么了：软件开发不是打字比赛。

Microsoft 的研究揭示了组织结构和协作如何影响软件质量。给相互独立的任务增加开发者，产出可能会增长。但让他们处理紧密耦合的代码，协调成本就可能吞掉你原本期待的所有生产力收益。

没有什么神奇的团队规模。规模选错了，钱可能烧上好几个月，才有人察觉。

几十年来，我们一直困在人类团队的这个难题里，直到 AI 出现，承诺让每个 CEO 的梦想成真。

可惜，对那些垂涎欲滴的 CEO 来说，现实另有打算：AI Agent 能制造出与人类开发者一样的协调乱局，只不过速度快到足以让混乱成倍放大。

如果软件根本不能正常工作，那么再强的代码生产能力也屁用没有。与交付可靠且具有商业价值的软件相比，生成堆积如山的代码实在容易得多。

Google 的 DORA 研究表明，AI 会同时放大现有工程实践的优点和缺点。给 AI 一套有问题的工程流程，你可能只是得到了同一场灾难，只是它现在以机器的速度运转。

AI 编程生产力的惨状：只有 2% 的人报告提升了 10 倍

遗憾的是，证据似乎印证了那些 AI 编程恐怖故事。只有约 2% 的人报告，AI 带来了 10 倍或以上的惊人生产力提升。

就连这可怜的 2%，依据的也是自我报告的提升，而不是对已交付软件增量的独立测量。AI 正在生成堆积如山的代码，也让开发变得更快，但把这些产出变成可靠且具有商业价值的软件，依然是一场工程噩梦。

这就是 AI 生产力悖论：代码堆积如山，已交付软件的增长却远远跟不上。涌入市场的应用数量增至七倍，而一款典型应用每个月的收入，却只够吃一顿像样的晚餐。

我怀疑，令人失望的生产力提升与毫无商业价值的 AI 生成软件，存在同一个问题：开发者误解了高效 AI 编程背后的数学和计算机科学。有问题的规格说明，靠写提示词是救不了的。

顶尖 1% 背后的科学：停止琢磨提示词，开始做工程

真正的优势，始于你理解 AI 不知道什么、只能猜测什么，以及你能通过规范的工程实践迫使它做对什么。第一个陷阱，就是隐藏上下文。

隐藏上下文陷阱：你忘了告诉 AI 的，它并不知道

让 AI 编程助手为支付系统实现一个退款函数，几秒内就得到了一份像样的代码。直到有人被退了两次款，尽管 AI 编写并通过的那些漂亮测试全都亮着绿灯。因为你那个聪明的 AI 助手从来没人告诉过：同一笔付款不能被重复退款。

更深层的问题，不只是缺少信息，而是缺少语义上下文：也就是那些决定代码是否真正正确的业务规则和依赖关系。

基于 token 的生成模型可以对上下文进行推理，但它们无法可靠地重建或验证专业软件赖以运作的所有隐藏语义。同样的提示词，不同的上下文，对应不同的正确实现。

你越早不再把提示词当作主要的软件开发策略，而是把它仅仅视为具有科学依据的工程流程中的初步步骤，就越早能在不牺牲交付软件质量的前提下，实现显著的生产力提升。

AI 编程中代价最高的错误：让 AI 评判你的业务需求

当你忽视工程原则，让 AI 编写代码、生成测试、审查自己的工作，然后自豪地报告一切通过时，你很容易得到一堆内部完全自洽、却完全错误的软件。AI 生成的每个测试都亮着绿灯，因为你让 AI 去评判业务需求，而没有亲自检查。

在涉及保险费、银行转账、客户合同或跨仓库库存的商业软件里，一条规则会改变另一条规则的含义，想用一个神奇的提示词理清它们，祝你好运。

转换式 AI 与传递式 AI：能保留下来的语义，就别再猜了

生成式 AI 根据学到的模式和它能访问的上下文生成代码，往往不得不猜测那些埋在系统其他位置的语义关系。既然可以把含义明确表达出来，并贯穿整个开发流程，为什么还要让 AI 一遍遍重建这些含义？

这就是传递式 AI 的基本思想：传递编程系统中已经存在的语义信息，而不是反复从 token 中重建它。

同一种违法行为，在某种情况下可能导致相似的结果，在另一种情况下却可能截然不同。相同的退款操作，不同的业务规则，以及两种都完全有效、却不能互换的实现。

第一条路径，上下文一致：

第二条路径，上下文分歧：

别再把业务规则埋进提示词里，给它们一个结构

为什么不把这些规则写成工程工具真正能够理解和检查的半形式化规格说明呢？将几何概念映射到软件中的对应概念：

下面是退款操作的一份简化 YAML 规格说明：

从语义几何到一套能运转的 AI 编程系统

首先，用一份半形式化规格说明定义业务规则，以及这些规则适用的上下文。然后，由一个上下文引擎理清哪些规则相关、它们如何相互作用，以及是否存在缺失或矛盾。确立这些规则后，由 AI Agent 生成代码，同时通过独立验证检查结果是否真正满足需求。

在上下文之间迁移，需要进行变换：

当涉及多个上下文时，这些变换必须遵循明确的复合规则：

现在，你已经领先一步：从仅仅描述上下文中的含义，迈向真正利用这些含义进行计算。把它用到你的下一个项目中吧。