Prompt工程即需求工程[译]

人们争相从 AI 工具中榨取最大价值，提示词工程（Prompt Engineering）——也就是编写清晰、结构化的输入来引导 AI 输出的实践——随之站上了舞台中央。但对软件工程师来说，这门手艺不算新。几十年来，我们一直在做类似的事，只是叫法不同罢了。我们今天编写 AI 提示词所面临的挑战，和软件团队几代人以来一直在努力解决的难题，并无二致。今天我们谈论提示词工程，其实只是在延续一个更古老的话题：开发者如何清晰地说明他们需要构建什么、在什么条件下构建、基于什么假设，以及如何将这些信息传达给整个团队。

从 1960 年代末起，这个问题被冠以“ 软件危机 ”之名，尤其是在 1968 年的北约软件工程大会上，“软件工程”一词也正是在那时被提出。这场危机指的是当时业界普遍的困境：软件项目总是超预算、延期，并且交付的成果常常无法满足用户的实际需求。

当时普遍有个误解，认为这些失败是由于程序员技术不行，或是团队需要更多的技术培训。但在那次大会上，专家组却把焦点放在了他们认为的真正病根上：团队和项目干系人难以理解他们正在解决的问题，搞不清到底需要构建什么；他们无法在内部清晰地沟通这些需求和想法；也无法确保最终交付的系统与最初的意图相符。这根本上是一个人与人之间的沟通问题。

与会者精准地抓住了这一点。贝尔实验室的小爱德华·E·大卫博士指出，我们常常“甚至没法用逻辑严谨的方式，去规定软件该做什么”。麻省理工学院的道格拉斯·罗斯则指出了一个陷阱：你“规定了要做什么，然后就去做了”，好像这样问题就解决了。W.L. 范德波尔教授则总结了需求不完整的挑战：“大多数问题在刚开始时，定义得就远远不够好，所以你根本没有足够的信息来构建正确的解决方案。”

这些问题都会导致团队在写下任何一行代码之前，就误解了他们正在创造的软件。对于今天那些使用 AI 生成代码的开发者来说，这一切听起来应该再熟悉不过了。

很多问题可以归结为我常说的那个经典难题：“ 照我心里想的做，而不是照我嘴上说的做 ”。机器是死板的——团队里的人也常常如此。我们的意图很少被完整地表达出来，要让每个人对软件应该做什么达成共识，向来需要刻意、甚至艰难的努力。

弗雷德·布鲁克斯在他那篇影响深远的经典文章《没有银弹》中也谈到了这一点。他认为，永远不会有某一个神奇的流程或工具，能让软件开发变得轻而易举。纵观软件工程史，团队总是禁不住去寻找那颗能让理解与沟通这些硬骨头消失的“银弹”。所以，当团队开始使用 AI 工具时，那些困扰了软件行业多年的老问题再次出现，也就不足为奇了。

到了 1970 年代末，这些问题开始被从“ 质量 ”的角度重新审视。菲利普·克罗斯比、约瑟夫·M·朱兰和 W·爱德华兹·戴明，这三位对质量工程领域影响巨大的人物，都对“为何如此多的产品无法胜任其本职工作”提出了极具影响力的见解，而这些观点在软件领域尤为适用。

• 克罗斯比认为，质量根本上是 符合需求 ——如果你不能清晰地定义你所需要的，你就不可能确保它被交付。
• 朱兰谈到 适用性 ——软件需要解决用户在真实场景下的真实问题，而不仅仅是通过几项清单检查。
• 戴明则更进一步，他强调缺陷不只是技术失误，而是 系统性问题的症状 ，尤其是沟通不畅和缺乏共识。他关注工程中人的因素：创造能帮助人们共同学习、沟通和改进的流程。

整个 80 年代，这些来自质量运动的洞见被应用于软件开发，并逐渐结晶成一门独立的学科，叫做 需求工程 ，专注于识别、分析、记录和管理利益相关者对一个产品或系统的需求。它作为一个独立的领域崭露头角，拥有了自己的会议、方法论和专业实践。1993 年，IEEE 计算机学会举办了第一届国际需求工程研讨会，标志着它被正式承认为软件工程的核心领域。

90 年代成了需求工作的鼎盛时期，许多组织投入巨资建立正式的流程和模板，相信更好的文档格式能保证更好的软件。像 IEEE 830 这样的标准规范了软件需求规格说明书的结构，而软件开发生命周期和 CMM/CMMI 等过程模型则强调严谨的文档和可重复的实践。许多公司投入大量精力设计详尽的模板和表格，希望只要正确填写就能保证做出正确的系统。实践中，这些模板在保持一致性和合规性方面确实有用，但它们并没能消除最难的那部分：确保一个人脑子里的想法，和所有人脑子里的想法，是完全一致的。

如果说 90 年代专注于正式文档，那么 2000 年代的敏捷运动则转向了一种更轻量、更侧重对话的方式。用户故事应运而生，作为对厚重规格文档的刻意反拨——它用用户的视角，对功能进行简短、朴素的描述，易于编写也易于理解。用户故事并不试图在一开始就捕捉所有细节，而是作为开发者与利益相关者之间对话的“话头”。这种做法刻意简化，其理念是： 共识源于对话，而非文档 ，需求是通过迭代和可工作的软件演进的，而不是在项目开始时就一成不变。

所有这些都巩固了需求工程作为软件工程实践中一个合法领域的地位，一个拥有自身技能体系的真正职业路径。现在业界普遍认同，需求工程是软件工程中至关重要的一个领域，它专注于揭示假设、澄清目标，并确保所有参与者对需要构建什么有共同的理解。

提示词工程，就是需求工程

提示词工程和需求工程 根本就是同一项技能 ——运用清晰度、上下文和明确的意图来 沟通你的目的 ，并确保最终构建的东西符合你真正所需。

用户故事是从传统的正式规格文档演变而来的：一种更简单、更灵活的需求方法，但目标相同，即确保每个人都理解其意图。它们在整个行业得到广泛接受，因为它们帮助团队认识到，需求的本质是 创造对项目的共识 。用户故事给了团队一种轻量级的方式来捕捉意图，然后通过对话、迭代和可工作的软件来完善它。

提示词工程扮演着完全相同的角色。 提示词就是我们与 AI 对话的那个轻量级的“话头” 。我们同样通过迭代来完善它，补充上下文、澄清意图，并对照我们心里真正的想法来检查输出结果。但真正重要的是与 AI 的完整对话及其上下文；单个的提示词只是沟通意图和上下文的手段。就像敏捷开发把需求从静态文档变成动态对话一样，提示词工程也把我们和 AI 的互动，从一次性的命令，转变为一个迭代优化的过程——尽管在这个过程中，我们必须从输出结果中反推缺少了什么，而不是等着 AI 向我们提出澄清问题。

用户故事有意识地将工程工作的焦点拉回到人和他们头脑中的想法。无论是一份 Word 格式的需求文档，还是 Jira 里的一个用户故事，最重要的从来都不是我们写下的那张纸、那张票或那份文件。最重要的是，我脑子里的东西，和你脑子里的东西，以及所有其他参与者脑子里的东西，要保持一致。那张纸只是一个方便的工具，帮我们搞清楚我们是否达成了一致。

提示词工程要求的是同样的结果。只不过我们不是与团队成员对齐心智模型，而是在与一个 AI 沟通，但目标并未改变：产出高质量的产品。戴明、朱兰和克罗斯比提出的质量工程基本原则，在提示词工程中有着直接的对应：

• 戴明对系统和沟通的关注 ：提示词的失败可以追溯到流程问题，而不是人的问题。它们通常源于糟糕的上下文和沟通，而不是“AI 太笨”。
• 朱兰对适用性的关注 ：当他将质量定义为“适用性”时，朱兰的意思是我们产出的东西必须满足真实需求——而不仅仅是看起来合理。如果输出结果不能解决真正的问题，那么提示词就毫无用处，而无法创造出“适用”的提示词，最终会导致 AI 产生幻觉。
• 克罗斯比对符合需求的关注 ：提示词不仅要规定功能性需求，还要规定非功能性需求，如可维护性和可读性。如果上下文和问题框架不清晰，AI 生成的输出将符合其训练数据的分布，而非真正的意图。

这些质量原则在提示词工程中最清晰的体现之一，就是现在所谓的 上下文工程 （Context Engineering）——决定模型需要看到什么才能生成有用的东西，这通常包括周边的代码、测试输入、预期输出、设计约束和其他重要的项目信息。如果你给 AI 的上下文太少，它会用它训练数据中最可能的内容来填补空白（这通常不是你想要的）。如果你给得太多，它可能会被信息淹没，抓不住你真正要问的核心。这种判断——包含什么、省略什么——向来是需求工作中最核心的挑战之一。

需求工程和提示词工程之间还有另一个重要的相似之处。早在 90 年代，许多组织掉进了我们所说的**“模板陷阱”——相信只要有了正确的标准化表格或需求模板，就能保证好的结果。团队花费大量精力设计和填写文档。但真正的问题从来都不是格式，而是底层的意图是否被真正地共享和理解了**。

今天，许多公司在 提示词库 （即预先写好的提示词目录，旨在规范实践并降低编写提示词的难度）上掉进了类似的陷阱。提示词库作为参考或起点可能有用，但它们无法取代构建问题框架和确保共识的核心技能。正如 90 年代一份完美的需求模板不能保证做出正确的系统一样，今天现成的提示词也保证不了生成正确的代码。

几十年过去了，布鲁克斯在他的《没有银弹》一文中的观点依然成立。没有哪个模板、库或工具能够消除理解“需要构建什么”这一内在的复杂性。无论是 90 年代的需求工程，还是今天的提示词工程，最难的部分始终如一： 建立并维护对意图的共识 。工具可以提供帮助，但它们无法取代这门学科本身。

AI 使得这个核心的沟通问题变得更加严峻。与你的团队成员不同， AI 不会反驳，也不会追问 ——它只会根据你给的提示词，生成一些看起来合理的东西。这使得清晰地沟通需求变得愈发重要。

作为需求工程基石的“理解对齐”，在我们将 AI 工具引入项目时甚至更为关键， 因为 AI 没有判断力 。它有一个庞大的模型，但只有在被正确引导时才能有效工作。AI 需要我们以代码、文档和其他项目工件的形式提供上下文，这意味着它对项目的了解，完全来自于我们告诉它的东西。因此，拥有检查和验证 AI“所知”是否与我们所知相符的方法就显得尤为重要。

经典的需求工程问题——特别是戴明所警告的沟通不畅和缺乏共识，以及需求工程师和敏捷实践者几十年来试图解决的问题——在我们使用 AI 时被加剧了。我们仍然面临着清晰沟通意图和明确规定需求的相同挑战。但现在，这些需求不仅仅是给团队阅读的，它们还被用来建立 AI 的上下文。问题框架的微小变化，都可能对 AI 的产出产生深远影响。越来越多地使用自然语言来取代结构化、无歧义的代码语法，这移走了一道关键的护栏，而这道护栏在传统上一直保护着软件免于因理解失败而崩溃。

需求工程的工具能帮助我们弥补这道缺失的护栏。敏捷的迭代过程——开发者理解需求、构建可工作的软件、并与产品负责人持续评审——是一种确保误解被及早发现的检查机制。我们越是让 AI 直接从需求生成代码，从而跳过翻译和理解的额外步骤，所有参与者——无论是利益相关者还是工程师——对需要构建什么拥有真正共识就变得越重要。

当团队成员合作构建软件时，他们会花大量时间交谈和提问，以理解要做什么。与 AI 一起工作则遵循一种不同的反馈循环—— 你只有在看到它的产出后，才知道它缺少上下文 ，而且你常常需要逆向工程它的行为，才能弄清楚到底少了什么。但这两种互动都需要需求工程师一直在实践的、围绕上下文和沟通的同样基本技能。

这在实践中体现在几个方面：

• 语境和共识是基石。 好的需求帮助团队理解哪些行为是重要的，以及如何判断它是否正常工作——这既包括功能性需求（做什么），也包括非功能性需求（做得怎么样）。同样的区分也适用于提示词，但纠错的机会更少。如果你遗漏了关键信息，AI 不会反驳，它只会用看似合理的东西来回应。有时，那个输出看起来很不错，直到你试用它时才发现，AI 解决的是另一个问题。
• 界定范围需要真正的判断力。 那些在使用 AI 写代码时遇到困难的开发者，通常会陷入两个极端：要么提供太少的上下文（一句话的提示，生成的东西看起来对，实际却跑不通），要么粘贴整个文件，期望模型能自动聚焦到正确的方法上。除非你明确指出什么是重要的——包括功能性和非功能性需求——否则它不知道重点在哪。
• 语境会漂移，而模型并不知道。 在人类团队中，理解的偏差会通过签到会和交谈逐渐修正。而对于提示词，这种漂移可能在几次交流中就发生了。模型可能一直在流畅地生成回应，直到它提出了一个毫无意义的修复方案。这是一个信号，表明上下文已经漂移了，你需要重新构建对话——也许可以要求模型解释一下代码，或者重述一遍它认为自己正在做什么。

历史总在重演：从堆满零散需求的活页夹，到 IEEE 标准，再到用户故事，直到今天的提示词，这门学科的本质从未改变。当我们把它当作真正的工程来对待时，我们就能成功。 提示词工程是需求工程演进的下一步。它确保了项目中的每一个人——包括 AI——都拥有共识，并且它要求我们始终如一地保持那种为避免误解、构建正确之物所必需的谨慎、清晰和刻意的沟通。

原文：Prompt Engineering Is Requirements Engineering – O’Reilly