提示工程即需求工程：我们早已熟悉这项技能

在急于从AI工具中获取最大价值的浪潮中，提示工程——编写清晰、结构化的输入以指导AI工具输出的实践——已成为焦点。但对软件工程师而言，这项技能并不新鲜。几十年来，我们一直在以不同的名称实践着它的某个版本。

我们今天编写AI提示时面临的挑战，与软件团队几代人一直在应对的挑战相同。今天讨论提示工程，实际上是在延续一个更古老的对话：开发人员如何阐明他们需要构建什么、在什么条件下、基于什么假设，以及如何向团队传达这些信息。

软件危机的根源

软件危机是这个问题从1960年代末开始被赋予的名称，特别是在1968年北约软件工程会议上，当时引入了"软件工程"这个术语。这场危机指的是行业普遍经历的现象：软件项目超预算、延期，且常常无法交付用户实际需要的东西。

当时存在一个普遍的误解，认为这些失败是由于程序员缺乏技术技能或团队需要更多技术培训。但该会议的小组讨论聚焦于他们认为是真正根本原因的问题：团队及其利益相关者难以理解他们正在解决的问题以及他们实际需要构建什么；难以清晰地沟通这些需求和想法；难以确保交付的系统符合该意图。这本质上是一个人类沟通问题。

会议参与者精确地捕捉到了这一点。贝尔实验室的Edward E. David Jr.博士指出，通常甚至无法以逻辑严密的方式指定软件应该做什么。MIT的Douglas Ross指出了这样一个陷阱：你可以指定你要做什么，然后去做，就好像这解决了问题一样。W.L. van der Poel教授总结了不完整规格说明的挑战：大多数问题在开始时根本没有被充分定义，因此你没有构建正确解决方案所需的信息。

这些都是导致团队在编写任何代码之前误解他们正在创建的软件的问题。对于今天使用AI生成代码的开发人员来说，这些问题都应该听起来很熟悉。

“做我意指之事，而非我所说之事"问题

大部分问题可归结为我经常称之为经典的"做我意指之事，而非我所说之事"问题。机器是字面意义的——团队中的人也常常如此。我们的意图很少被完全阐明，让每个人都对齐软件应该做什么一直需要刻意且常常困难的工作。

Fred Brooks在他经典且影响广泛的《没有银弹》文章中对此进行了论述。他论证永远不会有一个单一的神奇过程或工具能使软件开发变得容易。在整个软件工程历史中，团队一直 tempted 寻找那种能让理解和沟通的困难部分消失的银弹。当我们看到困扰软件团队多年的相同问题在他们开始使用AI工具时重新出现，这并不令人惊讶。

质量运动的见解

到1970年代末，这些问题开始从质量角度被重新框架。Philip Crosby、Joseph M. Juran和W. Edwards Deming这三个人对质量工程领域产生了巨大影响，他们各自对为什么这么多产品没有完成它们应该做的工作有影响力的看法，这些观点在涉及软件时尤其正确。

Crosby认为质量本质上是符合要求——如果你不能清楚地定义你需要什么，你就无法确保它会被交付。Juran谈到适用性——软件需要在其真实环境中解决用户的真实问题，而不仅仅是通过一些检查清单。Deming更进一步，强调缺陷不仅仅是技术错误，而是破碎系统的症状，特别是糟糕的沟通和缺乏共享理解。他专注于工程的人性面：创建帮助人们学习、沟通和共同改进的过程。

需求工程的诞生

通过1980年代，质量运动的这些见解被应用于软件开发，并开始结晶成一个称为需求工程的独特学科，专注于识别、分析、记录和管理利益相关者对产品或系统的需求。它作为自己的领域出现，拥有完整的会议、方法论和专业实践。IEEE计算机学会在1993年通过其第一次国际需求工程研讨会正式确定了这一点，标志着它被认可为软件工程的核心领域。

1990年代成为需求工作的黄金时代，组织大力投资于正式流程和模板，相信更好的文档格式将确保更好的软件。像IEEE 830这样的标准编纂了软件需求规格说明的结构，软件开发生命周期和CMM/CMMI等过程模型强调了严格的文档和可重复的实践。许多组织大力投资设计详细的模板和表格，希望正确填写它们能保证正确的系统。在实践中，这些模板对一致性和合规性很有用，但它们没有消除困难的部分：确保一个人头脑中的内容与其他人头脑中的内容匹配。

敏捷运动的转变

虽然1990年代专注于正式文档，但2000年代的敏捷运动转向了更轻量级、对话式的方法。用户故事作为重量级规格说明的刻意对立面出现——从用户角度讲述功能的简短、简单描述，设计得易于编写和易于理解。用户故事不是试图预先捕获每个细节，而是作为开发人员和利益相关者之间对话的占位符。这种实践刻意简单，基于这样的理念：共享理解来自对话而非文档，需求通过迭代和工作软件演化，而不是在项目开始时固定下来。

所有这些都强化了需求工程作为软件工程实践的一个合法领域和具有自己技能集的真实职业道路。现在广泛同意需求工程是软件工程的一个重要领域，专注于揭示假设、澄清目标，并确保每个相关人员对需要构建什么有相同的理解。

提示工程即需求工程

提示工程和需求工程字面上是相同的技能——使用清晰性、上下文和意向性来沟通你的意图，并确保构建的内容匹配你实际需要的内容。

用户故事是传统正式规格说明的演进：一种更简单、更灵活的需求方法，但具有确保每个人都理解意图的相同目标。它们在整个行业中获得广泛接受，因为它们帮助团队认识到需求是关于创建项目的共享理解。用户故事给团队提供了一种轻量级的方式来捕获意图，然后通过对话、迭代和工作软件来精炼它。

提示工程扮演完全相同的角色。提示是我们与AI对话的轻量级占位符。我们仍然通过迭代来精炼它，添加上下文，澄清意图，并根据我们实际意指的内容检查输出。但与AI及其上下文的完整对话才是重要的；单个提示只是沟通意图和上下文的一种手段。就像敏捷将需求从静态规格说明转变为活生生的对话一样，提示工程将我们与AI的互动从单次命令转变为迭代精炼过程——尽管在这个过程中我们必须从输出中推断缺少什么，而不是让AI问我们澄清问题。

质量原则在提示工程中的体现

用户故事有意将工程工作重新聚焦于人和他们头脑中的内容。无论是在Word中的需求文档还是在Jira中的用户故事，最重要的不是我们写的那张纸、工单或文档。最重要的是我头脑中的内容匹配你头脑中的内容，并匹配其他每个相关人员头脑中的内容。那张纸只是一种方便的方式，帮助我们弄清楚我们是否同意。

提示工程要求相同的结果。我们不是与队友合作对齐心智模型，而是在与AI沟通，但目标没有改变：生产高质量产品。Deming、Juran和Crosby阐述的质量工程基本原则在提示工程中有直接对应：

• Deming对系统和沟通的关注：提示失败可以追溯到过程问题，而不是人的问题。它们通常源于糟糕的上下文和沟通，而不是来自"坏AI”。
• Juran对适用性的关注：当Juran将质量框架化为"适用性"时，他的意思是我们生产的东西必须满足真实需求——不仅仅是看起来合理。如果输出没有解决真实问题，提示就是无用的，而未能创建适用于用途的提示将导致幻觉。
• Crosby对符合要求的关注：提示必须指定不仅是功能需求，还包括非功能需求，如可维护性和可读性。如果上下文和框架不清晰，AI将生成符合其训练分布而非真实意图的输出。

上下文工程的重要性

这些质量原则在提示工程中体现的最清晰方式之一是通过现在称为上下文工程的实践——决定模型需要看到什么才能生成有用的东西，这通常包括周围代码、测试输入、预期输出、设计约束和其他重要的项目信息。如果你给AI太少的上下文，它会用基于训练数据似乎最可能的内容填充空白（这通常不是你所想的）。如果你给它太多，它可能被信息淹没，失去你真正要求什么的线索。这种判断调用——包括什么、排除什么——一直是需求工作核心最深层的挑战之一。

模板陷阱的再现

需求工程和提示工程之间还有另一个重要的相似之处。回到1990年代，许多组织陷入了我们可能称之为模板陷阱的情况——相信正确的标准化表格或需求模板可以保证良好结果。团队花费巨大精力设计和填写文档。但真正的问题从来不是格式；而是底层意图是否真正被共享和理解。

今天，许多公司在提示库上陷入类似的陷阱，提示库是预写提示的目录，旨在标准化实践并消除编写提示的困难。提示库作为参考或起点可能有用，但它们不能替代构建问题框架和确保共享理解的核心技能。就像1990年代完美的需求模板不能保证正确的系统一样，今天的现成提示不能保证正确的代码。

没有银弹的持久真理

几十年后，Brooks在他的《没有银弹》文章中提出的观点仍然成立。没有单一的模板、库或工具可以消除理解需要构建什么的基本复杂性。无论是1990年代的需求工程还是今天的提示工程，困难的部分始终相同：构建和维护意图的共享理解。工具可以提供帮助，但它们不能替代纪律。

AI提高了沟通问题的赌注

AI提高了这个核心沟通问题的赌注。与你的队友不同，AI不会推回或提问——它只是根据给定的提示生成看起来合理的内容。这使得需求的清晰沟通更加重要。

当我们将AI工具引入项目时，作为需求工程基础的理解对齐甚至更加重要，因为AI没有判断力。它有一个巨大的模型，但只有在被良好指导时才能有效工作。AI需要我们以代码、文档和其他项目信息及工件的形式提供的上下文，这意味着它关于项目唯一知道的是我们告诉它的内容。这就是为什么特别重要的是要有方法来检查和验证AI"知道"的内容是否真正匹配我们知道的内容。

当我们使用AI时，经典的需求工程问题——特别是Deming警告过的糟糕沟通和缺乏共享理解，以及需求工程师和敏捷实践者花费数十年试图解决的问题——被放大了。我们仍然面临沟通意图和清晰指定需求的相同问题。但现在这些需求不仅仅是给团队阅读的；它们被用来建立AI的上下文。问题框架的微小变化可能对AI产生的内容产生深远影响。使用自然语言越来越多地替代结构化的、无歧义的代码语法，移除了传统上帮助保护软件免受理解失败的关键防护栏。

需求工程工具的价值

需求工程的工具帮助我们弥补那个缺失的防护栏。敏捷的迭代过程——开发人员理解需求、构建工作软件，并持续与产品负责人审查——是一种确保误解被及早捕捉的检查。我们越多地通过让AI直接从需求生成代码来消除那个额外的翻译和理解步骤，每个相关人员——利益相关者和工程师 alike——对需要构建什么有真正共享理解就变得越重要。

当团队中的人合作构建软件时，他们花费大量时间交谈和提问以理解他们需要构建什么。与AI合作遵循不同类型的反馈循环——直到你看到它产生什么，你才知道它缺少上下文，而且你通常需要反向工程它做了什么来找出缺少什么。但这两种类型的互动都需要需求工程师一直实践的关于上下文和沟通的相同基本技能。

实践中的体现

这在实践中以几种方式体现：

• 上下文和共享理解是基础：良好的需求帮助团队理解什么行为重要以及如何知道它在工作——捕获功能需求（构建什么）和非功能需求（它应该工作得多好）。相同的区别适用于提示，但纠正路线的机会更少。如果你遗漏了关键内容，AI不会推回；它只是用任何看起来合理的内容响应。有时那个输出看起来合理，直到你尝试使用它并意识到AI正在解决一个不同的问题。

• 范围界定需要真正的判断：难以使用AI生成代码的开发人员通常陷入两个极端：提供太少上下文（产生看起来正确但在实践中失败的单个句子）或粘贴整个文件期望模型聚焦于正确的方法。除非你明确指出什么是重要的——功能和非功能需求——它不知道什么重要。

• 上下文漂移，模型不知道它已经漂移：对于人类团队，理解通过检查点和对话逐渐转变。对于提示，漂移可能在几次交流中发生。模型可能仍在生成流畅的响应，直到它建议一个没有意义的修复。这是一个信号，表明上下文已经漂移，你需要重新框架对话——也许通过要求模型解释代码或重述它认为它在做什么。

历史不断重演

从装满分散需求的活页夹到IEEE标准，到用户故事，到今天的提示，纪律是相同的。当我们将其视为真正的工程时，我们就会成功。提示工程是需求工程演进中的下一步。这是我们确保项目中每个人——包括AI——之间有共享理解的方式，它要求我们一直需要的相同关怀、清晰和刻意沟通，以避免误解并构建正确的东西。