提示词的四个部件 | 提示词工程 | 做产品

提示词的四个部件

上一节说提示词要「把该说的说清楚」。这一节把它变成一份可以逐条对照的清单：背景、要求、限制、验收。

你会遇到的现象

• 写了很长一段提示词，效果还是不稳，但不知道该改哪

• 它答得挺好，就是格式每次都不一样，程序没法自动处理

• 它在你没交代的地方自作主张，还编了几个数字

四个部件

① 背景 —— 这是给谁的、在什么场景下。

包括：用户是谁、产品是什么、这段内容会出现在哪、有什么前情。这一段最容易被跳过，因为写的人脑子里全都有，觉得是常识。但模型是个完全不了解你们的新同事，你的「当然」它一个都不知道。

缺了它，你会得到一段放之四海而皆准、也因此毫无用处的通用内容。

② 要求 —— 具体要它做出什么。

动词要具体。「分析一下」是模糊的，「列出三个可能的原因，每个配一句判断依据」是具体的。如果任务有多个步骤，就把步骤写出来。

缺了它，它会挑一个它认为你想要的解释——通常是最常见的那种，未必是你的。

③ 限制 —— 不许做什么、边界在哪。

这一段的性价比最高，也最常被忽略。「不要编造数据，没有依据就说没有」「不要提竞品名称」「不要用感叹号」「只用给定材料里的信息」。

为什么反面描述这么有效？因为模型在收窄可能性，而排除一整类写法，比正面描述你要的那类收窄得更快。一句「不要写成营销腔」，顶得上三句「请专业、克制、有分寸」。

缺了它，它会自由发挥。缺依据的地方它会补上最像的内容，而且语气和真话一模一样。

④ 验收 —— 什么样算做完了。

输出几条、每条多长、什么格式、要不要编号、要不要 JSON。这一段决定了你的程序能不能自动接住它的输出。

缺了它，每次的格式都不太一样，你的代码就得写一堆兼容逻辑。格式控制这件事有专门的办法，但先决条件是你得在提示词里说清楚。

四个部件，以及它们该排在什么位置

① 背景　这是给谁的、什么场景 缺了它 → 换个产品也能用的通用内容

② 要求　具体要它做出什么 缺了它 → 它挑一个最常见的解释，未必是你的

③ 限制　不许做什么 性价比最高，也最常被忽略：缺了它，它会编

④ 验收　什么样算做完了 缺了它 → 格式每次都不一样，程序接不住

模型的注意力

开头看得最清 中段最容易被忽略 结尾也看得清

所以顺序不是随意的：最不能被忽略的限制和验收，正好压在结尾这个高注意力位置。

右边那条曲线解释了左边的排序。四个部件里，③ 限制的性价比最高——排除一整类写法，比正面描述你要的那类收窄得快得多。

一个真实的例子

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

改之前：「帮我总结一下这些用户反馈。」

它会给你一段中规中矩的摘要。可能挺好，但每次结构不一样，也不知道它是按什么维度归的类。

改之后：

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

第二种写法长了不少，但它每一句都在收窄范围，没有一句废话。而且这段提示词是可复用的——下周的工单直接换材料就行。

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

按症状反查

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

症状缺的是补什么 写得很泛，换个产品也能用背景补上用户是谁、产品是什么、用在哪。 答的不是你问的，或者只答了一半要求把动词写具体，多步任务把步骤列出来。 编了数据、加了戏、提了不该提的限制写一份反面清单，明确「没依据就说没有」。 内容对但格式乱，程序接不住验收规定条数、长度、格式，最好给个格式样例。 大部分时候对，偶尔离谱—这是稳定性问题，不是部件问题。看温度和迭代方法。

最后一行值得单独留意：偶发性的差异通常不是提示词缺了什么，而是随机性没控住。这两种问题的解法完全不同，别混着调。

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

系统提示与用户提示 这四个部件，该分别写在哪一层。

提示词不是咒语 为什么每补一个条件，效果就好一截。

三段式提示 用在让 AI 写代码、做产品这个具体场景上的版本。