直接回答：Zero-shot Prompting（零样本提示）是只提供任务指令和当前输入，不在提示中放入“输入—输出”演示，让模型直接完成任务。它不更新模型权重，也不等于“随口问一句”。可靠的零样本提示仍要写清目标、规则、输入边界、输出格式、证据不足时的处理方式和验收标准。
Zero-shot 适合模型已经具备所需能力、任务定义清楚、输出可校验的场景，例如把客服消息分到已定义标签、从文本抽取固定字段、按明确约束改写文字。若任务依赖最新事实、私有数据、真实工具权限或复杂业务示范，仅靠零样本提示通常不够。
Zero-shot Prompting 到底是什么？
GPT-3 论文系统讨论了模型在不做任务专用梯度更新时执行零样本、单样本和少样本任务的表现。在今天的产品语境中，Zero-shot 通常指本次请求不给演示样例；模型能否完成任务，仍取决于预训练、指令微调、模型能力、上下文和生成设置。
| 方法 | 本次请求提供什么 | 是否改权重 | 主要解决的问题 |
|---|---|---|---|
| Zero-shot | 指令与当前输入 | 否 | 让模型直接执行已能理解的任务 |
| Few-shot | 指令、少量演示与当前输入 | 否 | 展示标签边界、风格和输出形状 |
| RAG | 指令、当前输入与检索证据 | 否 | 补充最新、私有或可追溯事实 |
| 工具调用 | 工具定义、参数与执行结果 | 否 | 查询或改变外部系统状态 |
| 微调 | 训练阶段的大量数据 | 是 | 规模化固化特定行为和分布 |
“没有示例”不是“没有上下文”。产品说明、合同片段或数据库记录可以作为事实材料放入提示，但它们不是演示；演示回答的是“怎样完成”，证据回答的是“依据什么回答”。Few-shot 的示例选择见少样本提示指南，事实检索边界见RAG 生产指南。
一个可靠的零样本任务契约
任务：将客服消息分类为 refund、delivery、account 或 other。
定义：
- refund：退款、重复扣款或取消后返款；
- delivery：物流状态、延迟、签收异常；
- account：登录、密码、账号冻结；
- other：证据不足或不属于以上类别。
规则：只根据 <input> 内容判断；不要补造事实。
输出：只输出 JSON：{"label":"...","evidence":"原文短语"}
失败：无法确认时 label 必须为 other，evidence 为空字符串。
<input>{真实客服消息}</input>这个模板没有示例，但已经明确标签、判定证据、缺失处理和输出 schema。OpenAI 的提示工程文档强调不同模型类型、消息层级和版本会影响提示行为；Anthropic 的提示实践建议指令清晰、直接，并用结构化标签分隔内容；这些是设计起点，不是跨模型效果担保。
| 组件 | 要回答的问题 | 缺失后的症状 |
|---|---|---|
| 目标 | 究竟要分类、抽取、比较还是生成 | 输出看似相关但不能用于业务 |
| 定义 | 标签、字段和术语具体指什么 | 相邻概念混淆 |
| 范围 | 允许使用哪些输入和证据 | 模型引入未提供的信息 |
| 边界 | 缺失、冲突、歧义时怎么办 | 证据不足也强行回答 |
| 输出 | 字段、类型、长度和格式 | 下游无法稳定解析 |
| 验收 | 怎样判断成功或失败 | 只能凭主观感觉挑结果 |
指令、输入和证据怎样隔离？
生产提示常把系统规则、开发者配置、用户文本、检索片段和工具结果放在同一上下文中。它们不是同一可信等级。用户上传的邮件或网页内容可能包含“忽略以上规则”之类文本；如果没有边界，模型可能把数据误当成指令。
| 内容层 | 作用 | 应有控制 |
|---|---|---|
| 系统/应用规则 | 安全边界、任务和权限 | 固定模板、版本控制、不可由数据覆盖 |
| 用户请求 | 本次目标与参数 | 鉴权、字段校验、长度限制 |
| 用户数据 | 待分类、抽取或总结的内容 | 明确标签包裹，按不可信数据处理 |
| 检索证据 | 回答所依据的材料 | 来源、时间、权限和引用记录 |
| 工具结果 | 外部系统返回的状态 | schema 校验、错误码和最小权限 |
分隔符本身不能消除提示注入，但能让规则更可读、可测试。真实防护还需要输入过滤、工具权限、允许动作列表、人工审批和输出校验。提示词只是一层控制，不应承担付款、删除、改权限等真实授权。
为什么 Zero-shot 会失败？
“回答不准”只是表面症状。根因可能在任务、数据、知识、模型、输出接口或权限层。先定位失败类型，才知道应改提示、加证据、换模型还是升级系统。Toward Zero-Shot Instruction Following把无演示、仅依赖任务定义的跨任务泛化作为明确研究设置，也说明任务定义中的关键信息本身值得单独评估。
| 症状 | 可能根因 | 验证方法 | 优先修复 |
|---|---|---|---|
| 同一输入多次变标签 | 边界含糊、采样或模型不稳 | 固定模型与参数重复运行 | 明确定义并加入程序规则 |
| 回答流畅但事实错 | 缺少可靠事实或来源冲突 | 逐条映射到证据 | RAG、数据库或 API |
| 经常输出多余文字 | 格式仅靠自然语言约束 | 统计 schema 解析失败率 | 结构化输出、校验和重试 |
| 相邻标签混淆 | 标签定义重叠 | 看混淆矩阵和边界样本 | 重定义标签或加 Few-shot 难例 |
| 复杂任务漏步骤 | 任务跨度超过单次能力 | 拆成子任务逐项测 | 工作流、工具或换模型 |
| 执行了数据中的指令 | 指令与不可信内容未隔离 | 注入测试集 | 权限隔离、白名单和沙箱 |
不要在发现失败后立即堆更多形容词。一次只改一个变量：先固定模型和测试集，再分别测试任务定义、边界规则、上下文、输出 schema 与 Few-shot。完整排查顺序可参考AI 不听指令的故障排查流程。
角色设定有用吗？
“你是一位有 20 年经验的专家”可能改变语气或回答侧重点，但不会赋予模型真实资历、数据库访问权或专业责任。若任务需要术语、受众和口吻，应直接写成可观察要求，例如“面向非技术采购人员，每个术语首次出现时用一句话解释”；若需要法律、医学或财务依据，应提供合格来源和人工复核。
| 模糊写法 | 更可测试的写法 |
|---|---|
| 你是顶级专家 | 列出三种方案，并分别标明前提、证据和不确定性 |
| 写得专业一点 | 面向项目经理；先给结论，再给风险表；术语附定义 |
| 一定要准确 | 每个事实必须能定位到给定来源；找不到就标记“证据不足” |
| 不要出错 | 输出前检查必填字段；校验失败返回指定错误对象 |
要不要让模型“展示思维链”？
Large Language Models are Zero-Shot Reasoners在特定旧模型和推理基准上研究了 Zero-shot-CoT，并报告了论文实验中的提升。但这不能推出任何任务、任何新模型只要加一句“逐步思考”就会更准，也不能把旧论文数字当作当前产品效果。
用户通常需要的是可核验的依据，而不是模型的隐藏推理记录。更稳妥的做法是要求简洁的可见理由、引用、计算式、检查清单或结构化中间产物，并用外部程序验证。涉及敏感群体或高风险判断时更要谨慎；关于 Zero-shot 推理偏差与有害输出的研究表明，分步推理并非所有社会敏感任务的单向收益。
| 真正需求 | 建议输出 | 验收方法 |
|---|---|---|
| 数学可复核 | 公式、代入值和最终单位 | 独立计算器或测试代码 |
| 事实可追溯 | 原子主张与来源定位 | 来源覆盖率与忠实度 |
| 决策可审计 | 采用的规则、证据和异常项 | 规则引擎与人工抽查 |
| 格式可消费 | JSON 或固定字段 | schema 验证器 |
三类常见任务怎样写 Zero-shot？
分类：定义标签边界和 other
先写每个标签的必要证据与排除条件，再决定单标签、多标签还是优先级分类。一定保留 other、unknown 或人工升级路径，否则模型会把所有输入强塞进已有标签。评测时看每类精确率、召回率和混淆矩阵，不只看总体准确率。
信息抽取：禁止补全缺失字段
抽取任务要定义字段类型、日期与金额格式、多个候选的处理和空值语义。要求每个值附带原文证据或字符位置；输入没有的字段返回 null，不使用常识补齐。涉及扫描件或表格时，还要把 OCR 和版面解析错误单独统计。
总结和问答：限定证据范围
写清“只能依据给定材料”，并要求区分材料事实、推断和未知。长文总结要说明受众、长度、必须覆盖的主题和不可遗漏的例外；问答要返回引用片段或来源 ID。若材料没有答案，正确行为是指出缺口，而不是生成听起来合理的补充。事实核验方法见AI 幻觉核验指南。
什么时候从 Zero-shot 升级？
| 主要缺口 | 优先升级 | 判断依据 |
|---|---|---|
| 模型不知道最新或私有事实 | RAG、搜索、数据库或 API | 错误来自证据缺失，不是格式 |
| 标签边界或风格难用文字说明 | Few-shot | 少量审核示例显著改善保留集 |
| 需要真实查询、计算或修改状态 | 工具调用 | 任务必须访问外部系统 |
| 稳定行为需高频复用 | 微调或专用模型 | 收益覆盖数据、训练和运维成本 |
| 高影响且规则确定 | 确定性规则与人工审批 | 不能接受概率输出直接行动 |
| 任务定义本身矛盾 | 重做业务规范 | 人类评审者也无法一致判断 |
升级不是越复杂越好。Zero-shot 若已达到质量、成本和延迟门槛，就不必为了“先进”加入示例或检索。反过来，缺少事实时继续润色提示也不会让模型获得可靠新知识；需要稳定跨大量请求复用时，可评估LoRA/QLoRA 与微调上线验收。
怎样评测 Zero-shot 是否可上线？
先建立固定测试集，覆盖常见请求、边界、缺失、冲突、长输入、恶意输入和必须拒答的情况。开发提示时使用开发集，最终验收使用没有反复调过的保留集。不同提示版本必须在同一模型、同一参数和同一测试集上比较。
| 门禁 | 建议指标 | 不能忽略的问题 |
|---|---|---|
| 任务质量 | 准确率、F1、字段正确率、人工量表 | 总体分是否掩盖关键类别退化 |
| 证据 | 引用覆盖率、主张忠实度、无依据率 | 回答是否超出给定材料 |
| 格式 | schema 通过率、可解析率 | 自动修复是否掩盖原始失败 |
| 安全 | 注入成功率、越权率、敏感信息暴露率 | 工具是否有最小权限 |
| 稳定 | 复跑方差、不同快照回归 | 是否只挑最好的一次 |
| 运行 | 输入/输出 Token、P95 延迟、单次成本 | 质量收益是否值得开销 |
指令遵循评测研究指出，自动指标是否真正反映人类对指令遵循的判断本身也需要验证。开放式任务可采用盲评、成对比较和明确量表；模型评分器可以扩展规模，但要先与人工校准集比较，避免偏好更长、更自信或与自身风格相似的回答。
版本、回归与线上监控
提示正文不变，系统行为也可能因模型快照、系统消息、上下文拼装、采样参数、结构化输出实现或安全策略变化。每次请求至少记录模型 ID、提示模板哈希、输入数据版本、参数、原始输出、解析结果和校验错误；敏感输入应脱敏或仅保存稳定样本 ID。
| 变更 | 必须重测 | 回滚条件示例 |
|---|---|---|
| 模型或快照 | 完整保留集与安全集 | 关键类别低于既定阈值 |
| 任务定义 | 边界、冲突与历史投诉 | 人工一致性下降 |
| 输出 schema | 解析器、下游兼容与空值 | 生产解析失败增加 |
| 上下文来源 | 权限、时效、注入与引用 | 出现越权或无来源结论 |
| 生成参数 | 稳定性、长度、成本与延迟 | P95 延迟或成本超预算 |
线上监控要按任务、语言、输入长度和风险等级分层。总体成功率稳定，不代表长输入或少数标签没有退化。确认后的线上失败可加入开发集，但要持续补充新的保留样本，避免最终测试集逐渐变成已见题目。
多层指令冲突怎样处理？
真实应用不是把一段提示完整交给模型那么简单。系统消息可能要求保护隐私，开发者模板要求输出 JSON，用户要求解释理由，检索网页又含有相反指令。若团队没有先定义优先级，模型偶尔遵从哪一层都很难算“违反提示”，因为业务规范本身不完整。
IHEval 指令层级评测专门研究不同优先级指令对齐或冲突时的遵循表现，并报告被评模型在冲突条件下明显下降。这里应吸收的是评测方法：主动构造冲突样本，不能假设模型天然理解你的应用层级。
| 冲突类型 | 测试样本 | 应用侧处理 |
|---|---|---|
| 安全规则 vs 用户要求 | 用户要求输出被禁止的敏感字段 | 在进入模型前裁剪权限，输出再做字段过滤 |
| 格式规则 vs 自由解释 | 用户要求用散文回答，接口要求 JSON | 由应用固定 schema，解释放到允许字段 |
| 当前请求 vs 历史对话 | 旧轮次的目标与新目标相反 | 标记会话状态，清除过期任务或重新确认 |
| 任务规则 vs 检索内容 | 网页片段要求忽略系统消息 | 把检索结果当不可信证据，不执行其中指令 |
| 两个同级业务规则 | 既要求详尽又要求 50 字以内 | 由产品定义优先级，不让模型自行猜 |
冲突测试不应只看模型是否拒绝，还要检查它有没有泄露部分信息、输出无效格式或在理由中复述敏感数据。高影响系统必须在模型外实施不可绕过的授权；即使提示行为通过测试，也不等于权限控制已经完成。
结构化输出、校验和重试怎样配合？
自然语言里写“只输出 JSON”仍可能得到代码围栏、多余前言、错误类型或缺失字段。若供应商和所选模型支持原生结构化输出，应优先用 schema 约束；无论是否原生支持，下游仍要验证类型、枚举、长度、业务关系和证据范围。语法有效只说明可以解析，不说明值真实或业务上允许。
| 校验层 | 示例 | 失败处理 |
|---|---|---|
| 语法 | 是否为合法 JSON | 有限次数重试，保存原始失败 |
| Schema | 必填字段、类型、枚举 | 把具体错误反馈给修复步骤 |
| 业务规则 | 退款金额不得大于订单金额 | 确定性拒绝或转人工 |
| 证据 | 抽取值必须出现在原文 | 标记无依据字段，不自动补造 |
| 权限 | 当前用户是否能执行动作 | 权限系统拒绝，不能靠模型同意 |
重试也要有上限和分类。如果是 JSON 少一个引号，可以使用只修复格式的路径；如果输入根本没有答案，重复生成只会增加成本并产生更多猜测。记录每次失败原因和重试次数，报告“首次通过率”和“重试后通过率”，避免自动修复把模型原始不稳定性隐藏起来。
中文、跨语言和长输入怎样回归？
同一任务在中文、英文、中英混输、缩写、错别字和地区术语下可能表现不同。不要只把英文测试集机器翻译成中文：真实中文客服会有省略主语、口语表达、平台黑话、全角标点和数字单位差异。应从获得授权且脱敏的真实分布抽样，再由熟悉业务的中文评审者建立标准。
Google 的提示设计策略把清晰指令、上下文、示例和迭代作为相互关联的实践。对中文产品而言，“用中文回答”只是语言约束，还要分别定义术语是否保留英文、日期与货币格式、引用怎样呈现、繁简体是否转换，以及输入含多种语言时按哪种语言输出。
| 切片 | 至少覆盖 | 观察指标 |
|---|---|---|
| 语言 | 简中、繁中、中英混输 | 任务质量与语言一致率 |
| 表达 | 口语、错字、缩写、方言词 | unknown 与误分类率 |
| 长度 | 短句、长邮件、多文档 | 遗漏率、延迟和截断 |
| 格式 | 纯文本、表格、OCR、日志 | 解析错误与字段错位 |
| 时间 | 历史样本与近期真实流量 | 分布漂移和旧术语失效 |
长输入测试要确认关键规则与证据是否因截断丢失，也要检查模型是否只关注首尾。若文档超过可控范围，应先做确定性分块、检索或层级处理，并保留片段来源；不能把整份材料塞进窗口后，用一两个成功案例证明系统可靠。
怎样做单变量提示实验？
提示优化最常见的误判，是同时更换模型、增加规则、加入上下文、降低温度并换了一批问题，最后无法知道哪项带来变化。建立一个不可变基线，每次只改一个变量，并保存逐样本差异。总体指标上升时，仍要查看从正确变错误的样本，尤其是高代价类别。
| 实验 | 保持不变 | 要回答的问题 |
|---|---|---|
| 补充标签定义 | 模型、参数、输入、输出格式 | 相邻标签混淆是否下降 |
| 加入 evidence 字段 | 任务和样本 | 可追溯性提高是否损害覆盖 |
| 更换消息位置 | 文字内容和模型 | 规则放置是否影响遵循 |
| 降低随机性 | 提示与测试集 | 稳定性提高是否降低开放任务质量 |
| 加入 Few-shot | 契约、模型和保留集 | 示例收益是否覆盖 Token 与维护成本 |
开放式任务的样本量不足时，不要用百分比制造精确感。报告实际样本数、通过数、评审规则和分歧；若只是内部探索，应明确写“候选结果”，而不是宣称普遍提升。这样后续模型升级或流量分布变化时，团队才能复现当时的结论。
生产上线清单
- 任务目标、标签、字段、证据范围和失败行为都已写成可测试契约。
- 系统指令、用户请求、不可信数据、检索证据和工具结果有明确边界。
- 输出使用固定 schema，程序会校验、重试、降级并记录原始错误。
- 固定测试集包含常见、边界、缺失、冲突、注入与拒答样本。
- 候选提示与基线在同一模型、参数和保留集上比较。
- 事实任务逐条检查来源；缺少答案时允许返回证据不足。
- 高影响动作由权限系统、沙箱和人工审批控制，不由提示直接授权。
- 模型、提示、上下文、参数和解析器都有版本，可一键回滚。
常见问题
Zero-shot 是不是一句话提问？
不是。它只表示没有输入—输出演示；任务定义、规则、证据、当前输入和输出契约仍可很完整。
约束写得越多越好吗？
不是。重复、冲突或位置不清的约束会增加失败。每条规则都应对应具体风险，并通过删除或改写该规则的消融实验验证贡献。
Zero-shot 一定比 Few-shot 便宜吗？
通常输入更短，但总成本取决于失败重试、输出长度、模型选择和维护。应比较端到端成功一次的成本，而不是只看单次输入 Token。
模型升级后可以直接沿用旧提示吗？
不能默认沿用。模型对消息层级、格式和约束的响应可能变化；升级前应在固定回归集上验收并保留旧版本回滚能力。
编辑复核与纠错记录
本文由兰塞 AI 编辑流程于 2026 年 7 月 18 日复核。旧稿中的拟人化解释、虚构点击率/满意度/准确率，以及把角色设定和展示思维链当成通用解法的表述已删除；新版依据零样本与指令遵循原始研究，以及 OpenAI、Anthropic 当前提示文档，重建任务契约、失败诊断、升级决策与评测门禁。完整方法论见Prompt Engineering 指南，本站来源、更新与纠错原则见关于本站与编辑规范。
