提示词的四个部件

背景、要求、限制、验收。缺哪一段，就会在哪一段上跑偏。

上一节说提示词要「把该说的说清楚」。这一节把它变成一份可以逐条对照的清单：**背景、要求、限制、验收。**提示词工程的核心工作，就是把这几类信息安排明白。prompt-eng-wiki

你会遇到的现象：

• 写了很长一段提示词，效果还是不稳，但不知道该改哪
• 它答得挺好，就是格式每次都不一样，程序没法自动处理
• 它在你没交代的地方自作主张，还编了几个数字

四个部件

**背景 —— 这是给谁的、在什么场景下。**包括：用户是谁、产品是什么、这段内容会出现在哪、有什么前情。这一段最容易被跳过，因为写的人脑子里全都有，觉得是常识。但模型是个完全不了解你们的新同事，你的「当然」它一个都不知道。缺了它，你会得到一段放之四海而皆准、也因此毫无用处的通用内容。

**要求 —— 具体要它做出什么。**动词要具体。「分析一下」是模糊的，「列出三个可能的原因，每个配一句判断依据」是具体的。如果任务有多个步骤，就把步骤写出来。缺了它，它会挑一个它认为你想要的解释——通常是最常见的那种，未必是你的。

**限制 —— 不许做什么、边界在哪。**这一段的性价比最高，也最常被忽略。「不要编造数据，没有依据就说没有」「不要提竞品名称」「不要用感叹号」「只用给定材料里的信息」。

为什么反面描述这么有效？因为模型在收窄可能性，而排除一整类写法，比正面描述你要的那类收窄得更快。一句「不要写成营销腔」，顶得上三句「请专业、克制、有分寸」。缺了它，它会自由发挥。缺依据的地方它会补上最像的内容，而且语气和真话一模一样。

**验收 —— 什么样算做完了。**输出几条、每条多长、什么格式、要不要编号、要不要 JSON。这一段决定了你的程序能不能自动接住它的输出。缺了它，每次的格式都不太一样，你的代码就得写一堆兼容逻辑。格式控制这件事有专门的办法，但先决条件是你得在提示词里说清楚。

一个真实的例子

看同一个任务的两种写法。

改之前：「帮我总结一下这些用户反馈。」它会给你一段中规中矩的摘要。可能挺好，但每次结构不一样，也不知道它是按什么维度归的类。

改之后：

背景——这是我们 B 端 SaaS 产品上周收到的 200 条工单，用户主要是中小企业的行政人员。要求——按问题类型归类，列出出现最多的五类，每类给出条数和一句典型原话。限制——只用材料里出现过的内容，不要推测原因，条数必须是真实统计而不是估计。验收——用 Markdown 表格输出，三列：类型、条数、典型原话。

第二种写法长了不少，但它每一句都在收窄范围，没有一句废话。而且这段提示词是可复用的——下周的工单直接换材料就行。OpenAI 官方指南里那句「要求越明确，输出越稳定」，说的就是这个。openai-prompt-eng

注意「不要推测原因」这一条。少了它，模型很可能会自动帮你分析成因，听起来很有洞察，其实是编的。限制那一段防的就是这个。

按症状反查

这四个部件真正的用处，是让你在效果不好时能快速定位，而不是整段重写。

看到什么症状，就往对应的部件查：

顺带说一句顺序。这四段在提示词里的排列，通常是背景在前、要求居中、限制和验收在后。原因很实际：开头和结尾是模型看得最清楚的位置，而限制和验收是最不能被忽略的两段，所以压在最后。

定位到部件之后，补完那一件再跑样例验证——这正是下一节要讲的迭代方法。