提示词四要素

绝大多数"AI 答得不好"的抱怨，拆开看都不是模型的问题，而是那句话本身就没说清。一条可用的提示词由四块拼成：任务（要它干什么）、上下文（它需要知道哪些背景）、约束（哪些边界不能越）、格式（产出长什么样）。这四块里少哪一块，模型就会在那一块上自由发挥——而它的自由发挥往往不是你要的。这一节把四要素逐块拆开，配上大量"烂提示 vs 好提示"的对照，给出可以直接复制的模板。最后要处理一件很不舒服的事："让 AI 扮演资深专家"这条被抄了三年的技巧，在一项 162 种角色、2410 道事实题的学术测量里，平均收益并不显著——而厂商官方文档至今仍在推荐它。两边我们都摆出来。

先把"提示词"这个词彻底说清

提示词（Prompt，读作"普朗普特"，也常直译"提示"）这个词听着玄，其实就是你发给模型的那段文字，一个字不多一个字不少。它不是什么特殊格式，也不是需要特定语法的编程语言——就是自然语言。你在对话框里敲的那句话是提示词，程序里拼出来发给 API 的那一大段也是提示词。

那为什么要在这个平平无奇的东西后面加上"工程"两个字？因为模型对输入极其敏感，而这种敏感又没什么规律可循。同一个意思换个说法，产出质量可能天差地别（§10.5 会给出一组差 13 个百分点的实测数据）。既然输入的微小差异会带来输出的巨大差异，那"怎么写输入"就从随手一敲变成了一项需要方法、需要测量、需要版本管理的活儿。工程两个字指的就是这个：有方法、可复现、能测量。

顺手澄清一个常见混淆：提示词工程不是微调。微调（Fine-tuning，指用你自己的数据继续训练模型、改动模型内部参数）需要数据、算力、时间，而且改完就固化在模型里了。提示词工程完全不碰模型的任何参数——模型还是那个模型，一个数字都没变，你只是把话说得更清楚了。打个比方：微调是把厨师送去培训班学做本帮菜，提示词工程是把菜谱写清楚递给他。前者贵、慢、一劳永逸；后者免费、即时、每道菜都得重新说。在绝大多数场景里，你应该先把菜谱写好，再考虑要不要送去培训。

为什么四要素这个划分靠得住

"四要素"不是某篇论文的定理，而是从大量失败案例里归纳出来的检查清单。它的价值在于可诊断性——当模型答得不对时，你可以逐条对照，快速定位是哪一块漏了。这比"再试一次""换个说法"这种没有方向的瞎试要高效得多。

注意最后一列。这四类症状你大概全都遇到过，只是当时没意识到它们各自对应一块具体的缺失。知道这个对应关系之后，"AI 答得不好"这个笼统的抱怨就变成了一个可以定位、可以修的具体缺陷。

要素一 · 任务：动词才是核心

任务这一块最容易被人以为"我当然写了"，实际上写得非常含糊。判断标准很简单：你的提示词里有没有一个明确的动词，而且这个动词只有一种理解方式。

"帮我看看这份文档"——"看看"是什么动作？校对错别字？提炼摘要？评估逻辑漏洞？改写成更专业的语气？找出与去年版本的差异？这五件事的产出完全不同，而"看看"这个词一个都没排除掉。

右边那一列有个共同点：它们都能被验收。"优化一下"没法验收——你说好了没有？"缩短到 300 字以内、保留三个核心数据"可以验收，数一下字数、点一下数据就知道。一个好的任务描述，读完之后你应该能想出怎么检验它做到了没有。想不出来，说明还不够具体。

还有一个实用技巧：如果任务本身有多个步骤，就把步骤编号写出来。不要指望模型自己拆解你脑子里的流程。

❌ 帮我把这些访谈记录整理成一份报告。

✅ 请按以下步骤处理这五份访谈记录：
   1. 逐份提取每位受访者提到的具体痛点，用原话引用
   2. 把所有痛点合并去重，按被提及的人数从多到少排序
   3. 对被三人以上提到的痛点，各写一段 50 字左右的归纳
   4. 最后列出只被一人提到、但你认为值得关注的两条，说明理由

为什么编号有效？因为编号把一个模糊的大任务变成了四个可以逐一验收的小任务，而且顺序被固定了。模型不会跳过第 2 步直接写第 3 步——它在生成时会顺着你给的结构走。这就像装修时给工人一张施工顺序单，而不是说"你把这间屋子弄好"。

要素二 · 上下文：把"你应该知道"变成"我告诉你"

上下文是四要素里最容易被漏掉的，因为它漏掉的恰恰是你自己觉得理所当然的东西。你脑子里装着公司的产品线、这个项目的历史、这份文档要给谁看、上一版为什么被否掉——而模型对这些一无所知。

Anthropic 官方文档给了一个特别好用的心智模型：把模型当成一个聪明但完全缺乏你们内部语境的新员工。他智力没问题、学东西快、什么都愿意干，但他今天是第一天，你们组的黑话、默认约定、上次踩过的坑，他一件都不知道。

配套的黄金法则（Golden rule）也来自官方文档，值得抄在便签上：把你的提示词拿给一个完全不了解这个任务的同事看，如果他会困惑，模型也会困惑。

这条法则的妙处在于它把一个抽象问题变成了一个可执行的动作。你不需要理解模型的注意力机制，你只需要找个人读一遍。换成大白话：你写不清楚的东西，模型读不明白；人能读明白的，模型基本也能。

第三行值得多说一句，因为它和"幻觉"直接相关。模型不会说"这个我不知道"，它会填一个统计上最合理的东西进去。你问"我们上季度的续费率是多少"，它不知道，但它见过成千上万篇提到续费率的文档，于是它给你一个看起来很合理的数字。你没给上下文的每一处空缺，都是一个幻觉的入口。好比你让新人填一张表，有几栏你没告诉他，他又不敢来问——他就按经验估一个填上去，表格看起来完整，数据全是假的。

要素三 · 约束：给自由发挥划一道边

约束说白了就是"哪些事不许干、范围到哪儿为止"。它和任务的区别是：任务说"做什么"，约束说"做到什么程度、不许越什么线"。

约束通常分五类，写的时候可以照着过一遍：

• 长度约束"不超过 200 字""正好三条""每条一句话"。这是最有效也最常被忘的一类——不给长度，模型倾向于写长，因为它的训练数据里"详尽的回答"通常被评价为更好。
• 信息边界约束"只使用我提供的材料，材料里没有的信息不要补充""如果材料里找不到答案，直接回答「材料中未提及」"。这一条是对抗幻觉最直接的手段，而且给了模型一条体面的退路——不然它只能编。
• 风格与语气约束"用平实的书面语""不要用感叹号""不要出现「赋能」「闭环」这类词"。
• 受众与深度约束"假设读者不懂技术，每个术语第一次出现时用一句话解释""不要解释基础概念，读者是资深工程师"。
• 流程约束"先列大纲，等我确认后再写正文""如果信息不足以判断，先向我提问，不要直接给结论"。最后这半句极其好用——它把"猜"这条路堵上了，改成"问"。

★ 约束怎么写：说"要做什么"而不是"不要做什么"

这是 Anthropic 官方文档明确给出的一条原则，而且它反直觉的程度值得单开一节：正面指令比否定指令有效。

官方给的对照例子非常具体：

为什么正面的更好？可以这样理解：否定句只划掉了一片区域，没有指出该往哪儿走。你说"不要用 markdown"，模型知道不能用井号和星号了，但它可能改用一堆短句加破折号、或者用编号列表——那也不是 markdown，可离你想要的"流畅散文"还差得远。而"由流畅连贯的散文段落组成"直接给了一个目标形态，模型有了可以对齐的东西。

拿生活里的事打个比方：你带孩子去超市，说"不要乱跑"——孩子不跑了，开始原地转圈、扒货架、摸别人推车。你说"你负责推车，跟在我右边，帮我把清单上的东西一样一样找出来"——他有事干了，问题自然消失。"不要 X"给的是禁区，"要 Y"给的是任务。人和模型在这一点上出奇地一致。

更多可以直接照抄的改写：

要素四 · 格式：产出要能直接被下一环用掉

格式这一块的判断标准特别硬：模型吐出来的东西，能不能不经手工加工就进入下一个环节？如果你还得复制粘贴、删掉客套话、手动改成表格，那格式就没写好。

格式要素通常包含四层信息：整体形态（表格 / 列表 / JSON / 一段话）、结构细节（几列、列名叫什么、字段类型）、排序规则（按什么排）、包裹要求（要不要外层解释、要不要包在某个标记里）。

❌ 把这些商品信息整理一下给我。

✅ 输出一个 JSON 数组，每个元素包含四个字段：
   name   （字符串，商品名，去掉品牌前缀）
   price  （数字，单位元，保留两位小数，不要带货币符号）
   stock  （整数，缺货写 0）
   tags   （字符串数组，最多三个，从「新品/热销/清仓」里选）

   按 price 从高到低排序。
   只输出 JSON 本身，前后不要有任何说明文字、不要用代码块包裹。

最后那一句"只输出 JSON 本身，前后不要有任何说明文字"是血泪经验。模型天性喜欢在正经内容前后加一层客套——"好的，这是您要的 JSON："和"希望这对您有帮助！"。这两句话足以让下游的解析程序直接崩掉。凡是产出要被程序消费的场景，都必须显式禁止额外包装。

另一个非常好用的格式技巧是直接给一个填空模板，让模型照着填：

请严格按以下格式输出，不要增删小标题：

【一句话结论】
（这里写不超过 30 字的结论）

【三条支撑理由】
1.
2.
3.

【最大的不确定性】
（这里写你认为最可能出错的一个环节）

【建议的下一步】
（这里写一个具体到可以明天就开始做的动作）

这招之所以好用，是因为它把"格式要求"从描述变成了实物。你不是在说明想要什么样子，你直接把样子摆出来了。模型只需要填空，不需要理解你的描述。这就像去银行办事，柜员不会跟你口头描述表格该怎么填，他直接递给你一张表格。

四要素合起来长什么样：一个完整对照

光看单块容易觉得"这不都是常识吗"。把四块拼起来对照一次，差距就非常刺眼了。同一个需求，两种写法：

━━━━━━━━ 烂提示（一行） ━━━━━━━━

帮我写一下这个功能的需求文档。


━━━━━━━━ 好提示（四要素齐全） ━━━━━━━━

【上下文】
我们是一个面向中小餐饮商户的 SaaS 收银系统，商户平均门店数 1-3 家，
店主大多四十岁以上、不太会用复杂软件。这份文档要给外包开发团队看，
他们不了解我们的业务。上一版需求因为「没写清异常流程」被开发退回过一次。

【任务】
把下面这段口头描述，写成一份可以直接交付给外包的功能需求文档。
   （这里贴入口头描述原文……）

【约束】
- 只使用我提供的描述，描述里没提到的规则不要自行补充；
  如果某处必须补充才能实现，单独列在文末「待确认问题」里，不要写进正文
- 每个功能点必须写出正常流程和至少两条异常流程
- 不要出现「用户体验更好」这类无法验收的表述，改成可测量的条件
- 全文控制在 1500 字以内

【格式】
按以下结构输出：
   一、功能概述（不超过 100 字）
   二、名词定义（表格两列：术语、含义）
   三、功能点清单（表格四列：编号、功能点、正常流程、异常流程）
   四、验收标准（编号列表，每条以「当……时，系统应……」句式写）
   五、待确认问题（编号列表）

右边这份提示词看着长，但你只写一次，之后每个功能都能复用。而左边那一行，你得来回改五轮，每轮都得重新读一遍产出、重新解释一遍你想要什么。算总时间，长的那份反而快。好比去菜市场买菜，带一张清单看着啰嗦，可比"到了再想"少跑三趟。

★★ 角色扮演的真相：一项 162 种角色的大规模测量

现在讲本节最反常识的一段。

你一定见过这种建议："提示词开头一定要加一句「你是一位有二十年经验的资深 XX 专家」，模型的回答质量会大幅提升。"这句话在中文互联网上被抄了三年，几乎成了提示词教程的第一课。

2023 年 11 月，一篇论文专门去测了这件事。Zheng 等人的《When "A Helpful Assistant" Is Not Really Helpful: Personas in System Prompts Do Not Improve Performances of Large Language Models》（标题直译：《当"一位乐于助人的助手"其实并不那么有用：系统提示中的角色设定并不提升大语言模型的表现》），arXiv 编号 2311.10054，2023 年 11 月 16 日，后被 Findings of EMNLP 2024 录用。

先看它的实验规模，这决定了结论的分量：

• 角色数量162 种角色。分两大类：6 类人际关系型角色（比如"你的朋友""你的老师"这种关系设定）+ 8 个专业领域的职业角色。
• 模型数量4 个主流 LLM 家族——不是只测一个模型碰巧的结果。
• 题目数量2410 道事实性问题。注意"事实性"这个限定词，它非常关键，后面细说。
• 对照组系统提示里完全不加任何角色的那一组。

核心结论：相比不加角色的对照组，在系统提示里加入角色设定，并未提升模型表现。

论文还有一层更细致的发现，也是更值得琢磨的一层：角色的性别、类型、所属领域确实会影响准确率——加"你是一位医生"和加"你是一位律师"，分数是不一样的。但问题在于，这种影响的方向近乎随机。论文原文的措辞是 "the effect of each persona can be largely random"（每个角色的效果在很大程度上可能是随机的）。也就是说，你没法从"这个角色和任务是否对口"推断出它会不会帮上忙。让模型扮演医生去答医学题，有时候还不如什么都不加。

最后一条最狠，也最容易被忽略：论文发现，如果对每道题都事后挑出表现最好的那个角色再汇总，准确率确实能显著提高——但"自动识别每道题的最优角色"这件事做不到，各种预测方法的效果常常不比随机挑选更好。

换成大白话：事后诸葛亮能看出哪个角色好，事前没人能预判。这就相当于你手里有 162 张彩票，开奖后回头看确实有几张中了大奖，但开奖前你完全不知道该买哪张——那么"买彩票能致富"这个结论对你毫无操作价值。

★ 关于角色扮演，准确的表述该怎么说

这里必须非常小心地措辞，因为一不留神就会从一个错误滑到另一个错误。

不要说"角色扮演完全没用"。准确的表述是：

那角色提示到底还有什么用？有，而且是那篇论文没测的部分：语气、风格、输出体裁的调控。

"你是一位小学语文老师，请用小学生能懂的话解释" 和 "你是一位学术期刊审稿人，请用严谨的学术语言评述"——这两句话产出的文风差别是巨大的、稳定的、可复现的。这跟"答得对不对"是两个完全不同的维度。那篇论文测的是准确率，没有测风格调控效果。用它的结论去否定风格调控，是超出了论文的适用范围。

最后一行是本节最实用的一句建议：如果你想让它"像专家一样思考"，与其给它一个专家头衔，不如直接告诉它专家会关注哪几件事。头衔是间接的、要靠模型自己联想；关注点清单是直接的、可验收的。这就像你请人来验收装修，说"你是个资深监理"和说"请检查：墙面空鼓、地砖平整度、插座位置、防水闭水试验记录"——后者显然更可能让活儿干到位。

★ 必须并列呈现：厂商官方文档仍在推荐角色提示

如果这一节只讲那篇论文，就不算诚实。因为与此同时，Anthropic 的官方文档仍然在推荐给模型设定角色——那条建议的标题就叫 "Give Claude a role"（给 Claude 一个角色），说在系统提示里设定角色可以"聚焦其行为与语气"。

这就出现了一个非常典型的分歧：

这两个结论其实并不直接冲突——它们测的根本不是同一件事。论文测准确率，官方谈行为与语气。冲突只发生在人们把官方建议误读成"给角色能让它答得更准"的时候。

但也不必替任何一方圆场：厂商建议和学术测量之间存在紧张关系，这本身就是这个领域的真实状况。厂商的建议来自海量实践观察，覆盖面广但难以复现；学术测量精确、可复现，但每次只能测一个很窄的切面。换成大白话：一个是老师傅几十年的手感，一个是实验室里的精密测量。两者都值得听，但要听清各自在说什么。在一个还在快速变化的领域里，如实展示分歧，比强行给出一个"标准答案"更负责。

给一条可落地的折中做法：要风格就用角色，要准确就用别的手段。而且如果你的场景对准确率敏感，那么"加了角色是不是真的变好了"这件事，应该由你自己的评测集来回答，而不是由任何一篇文章（包括这一篇）来回答。这正是 §10.5 要讲的事。

把四要素做成一张可复制的检查清单

下面这份清单建议存下来。每次写重要提示词之前过一遍，二十秒的事，能省掉好几轮返工。

【任务】
  □ 有一个明确的动词吗？这个动词只有一种理解方式吗？
  □ 如果有多步，步骤编号写出来了吗？
  □ 我能说出「怎么检验它做到了没有」吗？

【上下文】
  □ 产出给谁看？说了吗？
  □ 会被用在什么地方（邮件正文 / PPT / 数据库字段）？说了吗？
  □ 相关的具体数据、日期、人名，我贴进去了吗？
  □ 有没有「已经排除的方案」需要告诉它，免得它重新推荐？
  □ 有没有我们内部才懂的行话，需要解释一句？
  □ 参考材料是贴了原文，还是指望它凭记忆？

【约束】
  □ 长度说了吗？
  □ 允许不允许它补充材料之外的信息？说了吗？
  □ 如果信息不足，是让它猜还是让它问？说了吗？
  □ 我写的是「不要 X」还是「要 Y」？能改成正面的吗？
  □ 有没有必须回避的词、句式、语气？

【格式】
  □ 整体形态说了吗（表格 / JSON / 列表 / 一段话）？
  □ 结构细节说了吗（几列、列名、字段类型、排序）？
  □ 要不要禁止前后加说明文字？
  □ 能不能干脆给一个填空模板？

【最后一问 · 黄金法则】
  □ 把这段拿给一个完全不了解此事的同事看，他会困惑吗？

一个可以长期复用的四要素模板

这份模板可以直接复制走，把方括号里的内容换成你自己的。它的结构和 §10.4 要讲的结构化标签是相通的，可以看作那一节的预习。

【背景】
  我是[你的角色/所在业务]，正在做[项目/场景]。
  这份产出要给[受众]看，会被用在[使用场景]。
  相关背景：[必须知道但对方不可能知道的事实、数据、历史决策]

【要做的事】
  请[明确的动词]，具体分为：
    1. [第一步]
    2. [第二步]
    3. [第三步]

【材料】
  ---
  [把原始文档、数据、代码原样贴在这里]
  ---

【要求】
  - 长度：[具体字数或条数]
  - 信息边界：只使用上面「材料」部分的内容；材料中未提及的，
    写「材料未提供」，不要自行补充
  - 信息不足时：先向我提出你需要澄清的问题，不要直接给结论
  - 表述：[正面表述的风格要求，比如「用平实的书面语，多用短句」]

【输出格式】
  [填空模板，或明确的结构说明]

【自检】
  写完后，请用一句话说明你在哪些地方做了推测、哪些地方依据不足。

最后那个"【自检】"块值得专门说一句。让模型自己标出"哪里是推测"，是一个成本极低、收益极高的做法。它不会因此变得更准确，但它会把不确定的地方暴露给你，让你知道该重点核对哪几处。好比请人帮你算一笔账，除了要结果，还要他标出哪几个数字是估的——这样你复核时就知道该盯哪儿。

常见误解一次澄清