第 1 章 指令设计

学习目标

• 把模糊的工作请求改写为目标、约束和成功标准清楚的可验证指令。
• 根据任务类型（提取、转换、生成、判断），确定允许创作的范围和所需依据。
• 把否定式指令改写为正面表述的指令，并附上简短理由。
• 说明系统（开发者）、用户与助手（assistant）消息的作用与优先级，把规则与输入放在合适的位置。
• 找出相互冲突的指令，按适用条件和优先级加以梳理。
• 制定信息不足时的处理策略，区分哪些需要询问，哪些可以作出假设并标明，哪些应暂缓判断。

引言

一家出版社的营销团队开始用模型撰写新书介绍。团队负责人写下的第一条指令是：“把新书介绍写得有吸引力一些，不要太长。”第一天的结果看起来不错。但一周内，五位同事使用同一条指令，结果却各不相同。有的文案两行，有的十行，有的甚至虚构了书中并不存在的获奖经历。负责审核的编辑不得不按不同的标准逐条修改，没过多久，就有人说用模型反而更麻烦。会上有人说“今天模型不太正常”，其实模型每次都在认真执行指令。指令没有给出“有吸引力”和“不要太长”的标准，模型只好每次自行补上看起来最合理的标准。

本章介绍如何填补这些空白。我们先讨论该把模型看作怎样的同事，再学习任务类型和好指令的四个要素，接着依次介绍把不可判定的表述改写为可判定条件的步骤、如何说明该做的事及理由以替代单纯禁止、消息角色、分离规则与数据的模板、冲突梳理，以及信息不足时的处理策略。在深入阅读中，还将讨论指令的适度抽象层级、精简指令的编辑方法，以及机密信息应该放在哪里。

核心概念

模型能干，但它是今天第一天上班的同事

新来的同事再优秀，也不了解团队的惯例、客户和汇报格式。如果只说一句“把报告整理一下”，他只能按自己所知最合理的方式去整理。Anthropic 的指南建议把模型看作“一位才华出众，但不了解我们的规范和工作流程背景的新员工”，并将一个简单的检查方法称为黄金法则：把提示词拿给几乎不了解背景的同事看，问他能否照着做。如果同事会困惑，模型也会困惑。

这个比喻也有局限。人类新员工遇到不懂的事会问旁边的同事，能记住上周会议的内容，犯错后也会感到自己负有责任。模型无法了解给定上下文以外的情况，而且即使没有禁止它提问，它也常常不问就自行补全缺失内容。因此，结果出错时，应该把原因分为以下两类来检查。

先确定任务类型

写指令之前先确定任务属于哪一类，很多判断就会自然明确。因为任务类型不同，允许模型创作的范围和要求依据的程度也不同。

如果提取任务中混入生成任务的指令（“润色得好读一些”），就会出现原文没有的表达；如果判断任务没有标准表，模型就会编出一套看似合理的标准来使用。如果一个提示词混合了多种类型，最好标明各阶段的类型，或者按第 4 章的方法拆分步骤。

好指令的四个要素

好指令回答四个问题。

把四个要素逐一去掉，就能看出为什么缺一不可。

成功标准是四个要素中最常被遗漏的一个。“简洁一些”“篇幅适当”“高质量”这类说法都无法判定。把它们改成看结果就能判定是否做到的形式，例如“五行以内”“第一句给出结论”“每项一条依据”，人工审核会更容易，也能直接衔接第 5 章将介绍的自动评估。Anthropic 的提示词工程概览也提出，在润色提示词前，应先准备好成功标准、按标准开展实验的方法，以及第一份草稿。

角色只确定视角，并不提供知识

在系统提示词中加入一句角色说明，能让模型的视角和语气向相应工作靠拢。Anthropic 文档指出，哪怕只用一句话赋予角色，也会带来差异。但必须区分角色说明能做什么、不能做什么。

即使写“像一位有 20 年经验的税务专家那样回答”，模型也不会因此了解本公司的税务处理标准。所需标准应通过上下文提供，指令中则要写明模型可以判断的范围，以及何时必须交给人工处理。角色只是起点，不能代替另外三个要素。

把模糊需求改写为可验证的指令

实际工作中的请求大多以形容词呈现：“清爽”“有说服力”“对客户友好”。将这些请求写成指令时，按以下步骤做不易遗漏。

1. 标出所有形容词。 在请求中给没有判定标准的形容词和副词画线。
2. 问请求者“看到什么，你才会有这种感觉”。 “清爽”指“每段只讲一个主题”还是“有表格”，只有请求者清楚。
3. 转化为可观察的指标。 用数字（字数、项目数）、位置（第一句、最后一行）、格式（表格、项目符号）、是否包含（价格、期限、联系方式）来表述。
4. 同时写下失败条件。 定义可以直接判定不合格的条件，例如“只要有一个没有依据的数值，就不合格”。
5. 试着判定。 用新标准亲自评判几份过去的产出，把存在分歧的标准改得更具体。

请求：新会员欢迎邮件写得亲切一些，不要太长。

可验证的指令：
- 读者是刚注册的个人会员。使用礼貌的陈述句，感叹句最多一句。
- 正文不超过 600 字，分为三段。
- 第一段写一件会员现在就能做的事。
- 只写所提供权益清单中的权益。出现任何清单之外的权益即为失败。

这样改写后的指令会成为审核者的标准，也为日后记录标准改了什么提供依据。

与其说不要做什么，不如说要做什么

“不要用表格”只告诉模型什么是禁止的，却没有说该用什么来代替。Anthropic 指南建议，应该说出想要什么，而不只是说不想要什么。例如，用“写成衔接流畅的段落”代替“不要使用 Markdown”。

较差的指令：不要使用项目符号。
较好的指令：回答将显示在自助终端屏幕的一个区域内，因此写成一个包含两三句陈述句的段落。

同理，提示词本身的格式也会影响输出。Anthropic 文档解释，提示词的格式风格可能影响回答的格式风格，移除提示词中的 Markdown，也可能减少输出中的 Markdown。满是标题和项目符号的提示词，会使模型在回答中也倾向于大量使用标题和项目符号。

正面表述并非总能替代禁止。对于绝对不能越过的界线，例如泄露个人信息、作出未经确认的承诺，直接禁止会更清楚。但即使如此，也不要只留一句禁令，还要补上“应该怎样做”。例如：“不承诺未经确认的日期。如果对方询问时间安排，说明何时能确定日期，以及如何查询。”这样，模型就知道该用什么行动代替被禁止的行动。

加上理由，模型就能推广应用

给指令附上理由，可以提高指令的效果。Anthropic 指南给出的例子是这样的：与其说“绝对不要使用省略号”，不如说“回答会由语音合成引擎朗读，因此不要使用引擎无法发音的省略号”。指南还补充，模型足够聪明，能够从这些解释中归纳出适用于其他情境的原则。知道理由之后，模型就能在类似的情境中运用同一原则。不过，对于确实必须避开的符号，仍然要直接写明，并检查输出结果，确认是否避开了它们。

理由用一两句话说明就足够了。冗长的背景说明反而会模糊指令的核心。好的理由会说清楚“谁、在什么地方、为什么会遇到困难”。例如：“日期使用 2026-10-20 这样的格式，因为结算系统会直接读取输出结果。”

顺序重要的流程用编号

把多个步骤用逗号串成一段，模型容易漏步骤或改变顺序。Anthropic 指南建议，在步骤顺序或完整性重要时，用编号列表或项目符号提供依次执行的步骤。编号也为审核者提供了检查“遵守了哪一步”的标准。

回答前遵守以下顺序。
1. 在客户咨询内容中查找订单号。如果没有，先请求提供订单号，然后停止。
2. 在订单信息中确认付款状态，选择与状态相符的说明文案。
3. 在说明末尾写出下次联系的时间。

反之，如果给无关顺序的项目也编号，模型可能为了遵守不必要的顺序而破坏回答的自然度。只在“顺序或遗漏会改变结果”的地方使用编号。

消息角色与优先级

通过 API 使用模型时，把指令放在哪个位置，与指令内容同样重要。用公司来比喻，系统（开发者）消息是公司规章，用户消息是客户的请求，助手（assistant）消息是员工已经说过的话。

OpenAI 指南将 developer 消息比作函数定义，将 user 消息比作传给函数的参数。指南还举例，按身份（Identity）、指令（Instructions）、示例（Examples）、上下文（Context）的顺序组织 developer 消息，把上下文放在靠后的位置。Google 的 Gemini 指南也建议把关键行为约束、角色（persona）、输出格式要求放在 system instruction 或用户提示词最前面。

要警惕两种误解。第一，在用户消息正文里写“系统指令：”，并不会使这句话获得系统权限。权限来自消息的位置，而非句子的前缀。第二，把通用规则混进用户消息，会使优先级变得模糊，与用户写下“忽略前面的规则”这类攻击（提示词注入）之间的界线也会变得不清。

分离规则与数据的模板

团队开始反复使用同一个提示词后，会出现越来越多混合着可变与固定部分的副本。一旦有人修改了某份副本中的一条规则，就没人知道哪个副本是最新版了。解决办法是分离规则与数据。

[固定规则：版本 3.2，修改于 2026-10-14]
你负责起草发给海外客户的英文邮件。
- 金额和交期只使用 <order> 中的值。
- 未确认的项目标为 [待确认]。

[变量：每次请求变化]
<order>{{ORDER_SUMMARY}}</order>
<buyer_message>{{BUYER_MESSAGE}}</buyer_message>

双层花括号（{{...}}）是标记每次请求填值位置的惯例。固定规则只在一处修改，为变量确定名称和要填入的内容，在变更记录中写明改了什么、为什么改、依据了什么评估结果。第 5 章的回归评估与这份记录配套。

冲突的指令由作者来化解

经过多人修改的提示词，很容易积累像“始终只写一行”和“列出所有依据”这样相互冲突的指令。模型每次请求都会选择其中一方，结果就是输出不稳定。解决办法不是把问题推给模型，让它“权衡一下”，而是由作者找出冲突，合并成一条规则。

冲突可以分为两类。

工作条件冲突按以下步骤解决。

1. 列出全部条件。 把指令中的条件逐行移到表格中。
2. 区分必须与偏好。 标明违反就会出问题的条件（必须）和做到更好的条件（偏好）。
3. 找出无法同时满足的成对条件。 查找对某个输入无法兼顾的组合。
4. 划分适用条件。 看能否改为“默认 A，遇到这种情况则 B”。
5. 无法划分时写明优先级。 “两者冲突时遵守必须条件，并用一行说明未满足偏好条件的理由。”

梳理前：始终用表格整理。/ 写得简短，以适合即时通信的预览。
梳理后：默认不超过三句话。只有比较项目达到三个以上时才使用表格，
        并在表格前先用一句话给出结论。

信息不足时的处理策略

输入缺少必要信息时，模型可以做三件事：询问、作出假设后继续，或暂缓判断。如果指令中没有处理策略，模型往往会填入看似合理的值后继续。应根据信息的性质制定处理策略。

允许模型说“不知道”也是处理策略的一部分。Anthropic 的减少幻觉文档解释，明确赋予模型承认不确定性的权限，这一简单方法就能显著减少虚假信息。但只有许可还不够，还要规定不知道时怎样做，例如“说明需要向负责部门确认，并提供联系方式”，模型才知道遇到空白时该停下来。

执行还是建议，以及强调的陷阱

对可以使用工具的模型而言，“请提出建议”和“请修改”是完全不同的指令。Anthropic 指南指出，最新模型经过训练，会精准遵守指令；因此即使本意是让它实际修改，问“能建议一些改进之处吗？”也可能只得到建议。想让它修改，就直接要求行动，例如“修改这个函数”。反过来，如果问题在于模型不经询问就行动，则应在系统提示词中设定默认处理策略：意图模糊时只提供信息与建议，仅在明确要求时才执行。

难以撤销的行为需要单独的规则。对于删除文件、向外发送、付款等难以撤销或会被他人看到的操作，应写明执行前先确认，并列出需要确认的操作示例。

强调方式也应重新检查。针对旧模型写下的强硬指令，例如“CRITICAL：必须使用这个工具！”，可能导致最新模型反应过度。Anthropic 文档建议，过去为解决工具使用不足而加入的激进措辞，现在可能造成过度调用，应改成“此工具用于以下情况”这样的平实表述。强调不能替代条件。更换模型时，应优先查找并移除为了弥补旧模型弱点而加入的强调和“毫无遗漏”等措辞；对于希望达到的程度，例如“尽可能加入更多功能”，则应直接提出要求。修改后，用第 5 章的评估集比较前后。Anthropic 文档也指出，将在特定模型上测得有效的方法应用于其他模型之前，应先用自己的评估重新确认。

深入阅读

适度抽象层级，以及从最简提示词开始

Anthropic 关于上下文工程的文章把系统提示词的失败分为两类：一类是用 if-else 规则硬编码所有例外，导致提示词脆弱、难以维护；另一类是缺少具体信号，只给出笼统的宏观指导，或想当然地认为背景信息已被共享。介于两者之间的“适度抽象层级”，是指通过原则、理由和几个代表性案例提供判断框架。

同一篇文章还介绍了实际把握抽象层级的方法：使用能够获得的最佳模型，从最简提示词开始测试，再根据实际观察到的失败添加指令与示例。预先将想象中的例外堆成规则，会引发规则冲突，也让人无法判断究竟哪条规则起了作用。更稳妥的顺序是：用真实输入样本运行最简提示词，将失败按类型归类，再为每类补充一条原则和一个代表性示例。

精简指令的编辑方法与机密信息的位置

指令有越修改越长的倾向。这是因为每发生一次失败，就会在后面再补上一行。定期按以下方式编辑指令，会有所帮助。

• 把表达同一含义的句子合并成一句。
• 把“它”“以上内容”等指代对象不清楚的代词，改成所指对象的实际名称。
• 去掉大写字母、感叹号、“绝对”等强调方式，改为明确的条件。
• 删除句子之后，用评估集比较结果，确认被删除的句子原先是否确实发挥了作用。

还有一些信息不应该放进指令，例如支付密钥、内部折扣审批标准等一旦泄露就会造成损失的内容。Anthropic 关于提示词泄露的文档以“没有完美的防护方法”为前提，建议对于任务不需要的专有信息，从一开始就不要放进去。文档指出，层层堆叠复杂的防泄露措辞可能降低任务性能，因此只应在确有必要时使用，而应先尝试输出过滤等监测方法。支付密钥之类的认证信息，在任何情况下都不应放进提示词，而应保存在服务器端工具内部，并且只赋予模型完成任务所需的最小权限。第 3 章讲解如何防范提示词注入时，还会再次讨论这一最小权限原则。

工作场景

玛鲁文化基金会：一个请求，三个渠道

地方文化机构“玛鲁文化基金会”的宣传负责人权专员，要将秋季户外演出的通知制作成短信、网站公告和横幅三种版本。策划团队只发来一句请求：“简短亲切，但条件不能遗漏。”权专员直接输入这句话，结果短信长达十二行，横幅上甚至写进了雨天变更场地的条件。

权专员先将请求拆解成任务说明。任务类型是转换，策划团队的演出概要是原文，只能在保留原意的前提下，改变各渠道的表达方式。随后，他问策划团队“不能遗漏”具体指什么。答复是时间、地点、是否免费、雨天变更、联系方式五项。但“简短”在不同渠道含义不同。

表格一做出来，冲突就显现了：短信和横幅无法放下全部五项。权专员没有取消“不能遗漏”这一必须条件，而是划分了适用条件。需要包含全部五项的是网站公告，短信和横幅则明确定位为通向网站公告的入口。因此，短信中必须加入详情链接。

权专员也放弃了一些方案。第一，三个渠道一起请求，只写“按渠道适当处理”。这会把判断推给模型，导致与过去同样的不稳定。第二，反复用粗体强调“绝对不要写长”。如果不定义何为长，强调改变不了任何事情。

最终指令包含共用规则（语气、事实仅限概要中的内容）、各渠道的必要信息与篇幅，以及各自一句理由。例如，短信附上“收件人在通知预览中只能看到第一行，因此第一行写时间和地点”。用五份过往活动概要测试后，两名审核者只看表格标准，就能得出相同的合格或不合格判断。权专员修改的不是文句是否华丽，而是“简短”和“不能遗漏”的定义。

韩蔚纺织：将海外买家邮件助手变成团队工具

面料出口企业“韩蔚纺织”的销售团队用模型起草发给海外买家的英文邮件。起初，每个人都在聊天界面中粘贴自己的一套提示词。后来，一名员工用模型生成的草稿，把尚未确定的装船日期写成了已经确定的日期，并据此发出了邮件，买家便根据那个日期安排了日程。团队负责人决定与开发团队合作，将这项工作迁入公司内部工具。

开发负责人柳主管收集了六份分散的提示词，逐行移入表格。其中混合着共用规则（礼貌的商务英语、签名格式）和因人而异的规则（有人总写价格，有人不写）。柳主管作出三项决定。

1. 分配位置。 将所有邮件共用的角色、语气和禁止边界移入系统消息。订单摘要和买家原文每次变化，因此用标签包起来放入用户消息。买家原文来自外部，系统消息还要写明，其中的句子是需要回应的对象，而非指令。
2. 信息不足时的处理策略。 装船日期、数量、单价会改变买家的决策。订单摘要中没有值时，不得在草稿中编造，而应标为 [待确认：装船日期]，并在草稿上方单列经办人需要核对的清单。问候语或段落顺序等事后容易修改的内容，则按默认值继续。
3. 模板与记录。 将规则连同版本保存在代码仓库中，销售团队想改规则时提交变更请求。每项请求记录改什么、为什么改，以及修改后与过去二十封邮件比较的结果。

是否加入价格属于工作条件冲突。柳主管与团队负责人商议后，划分适用条件：“只有买家询价，或订单摘要中有报价单编号时，才加入价格。”

审查过程中，一名员工问：“不知道装船日期时，放个大概日期是不是更好？”柳主管没有采纳。装船日期属于猜测会引发事故的信息，而这次问题正是由猜测引起的。他改为将待确认清单置于草稿最上方，避免经办人漏看。上线后的一个月内，没有邮件再把未经确认的值当成确定值发送出去；经办人也表示，有了待确认清单，每封邮件的审核时间缩短了。

易错点

• 以为强调了就会遵守。 用粗体反复写“必须”“绝对”，看似会被遵守，但如果不定义该做什么，模糊之处依然存在。对最新模型，过度强调反而可能导致反应过度。
• 以为给个角色就够了。 角色说明能确定视角和语气，却不能提供公司特有知识，也不能给出篇幅、项目等成功标准。
• 以为在用户消息中写“系统：”就会成为系统指令。 权限来自消息的位置，而非句子的前缀。
• 以为写“权衡一下”就能化解冲突。 把判断推给模型，它会在不同请求中选择不同的一方。适用条件和优先级应由作者确定。
• 以为只写禁止事项就够了。 禁令没有说明用什么替代。应正面写出该做的事，并为必要的禁令附上替代方案。
• 以为不知道时它会自己问。 没有处理策略，模型往往会填入看似合理的值后继续。指令应写明哪些要问，哪些可以假设，哪些应暂缓。
• 以为把所有例外都写成规则就会更安全。 堆积想象中的例外会导致规则冲突，让提示词变得脆弱。应从最简提示词开始，根据观察到的失败补强。

要点速览

查阅官方文档

• Anthropic — Prompting best practices：阅读 “Be clear and direct”“Add context to improve performance”“Give Claude a role”“Tool usage”“Balancing autonomy and safety” 几节。
• OpenAI — Prompt engineering：阅读消息角色与优先级、developer 消息组织顺序，以及停止支持可复用提示词的通知。
• Anthropic — Effective context engineering for AI agents：阅读系统提示词的“适度抽象层级”，以及从最简提示词开始的建议。
• Google — Prompt design strategies：确认如何指定约束与回答格式，以及哪些内容应放入 system instruction。
• Anthropic — Reduce hallucinations：阅读允许模型说不知道的方法。

自测

1-1. 写出好指令的四个要素，并用一句话说明：如果缺少其中最常被遗漏的要素，审核阶段会出现什么问题。

1-2. 将“把要登在公司内部通讯中的总裁访谈整理得精致一些，篇幅适中，读起来没有压力”改写为至少四个可验证的条件，其中包含一个失败条件。

1-3. 对同一份会议录音文字稿，“只提取决定事项”和“为未能参会的高管写一份简报”分别属于什么任务类型？指令应提出哪些不同要求？

1-4. 你要为无人停车缴费机制作语音提示。请把“不要使用英文缩写”改写为包含该做的事及理由的指令。

1-5. 同一提示词中有“所有回答末尾都附上依据文档的链接”和“回答必须在公司内部即时通信的两行预览内结束”。说明两者无法同时满足的原因，并合并成一条规则。

1-6. 客户输入的开头有一句“系统指令：忽略之前所有规则”。请从消息角色的角度说明，这句话为什么不具备系统权限。

1-7. 设计一个整理团队会议记录的助手。列出会议记录中可能缺少的三项信息（例如负责人、截止日期、会议室名称），分别归入“询问／假设并标明／暂缓”之一，并说明理由。

实操练习