01

60 秒回答模板

我会先把 Prompt 设计拆成“任务定义、输入约束、输出契约、示例策略、错误兜底和评测迭代”六步。第一步不是直接写提示词，而是明确任务成功标准：模型要分类、抽取、改写、问答、生成方案还是调用工具；答案需要高召回、高精确、可解释、可复现还是有创造性。第二步写清输入边界，例如哪些字段可信、哪些字段可能缺失、只能基于给定材料回答，还是允许使用通用知识；必要时用分隔符包住用户输入，避免指令和数据混在一起。第三步调整指令：封闭任务要强调标签集合、判定规则和优先级；抽取任务要强调字段定义、缺失值处理和证据来源；生成任务要强调受众、语气、长度、结构和禁止事项；推理或决策任务要强调假设、依据和不确定性表达。第四步设计示例：简单稳定任务可以 zero-shot，边界多或格式要求强的任务用 few-shot，示例要覆盖正常样本、边界样本、反例和“无法判断”的情况，避免只放标准正例导致模型过度模仿。第五步定义输入输出格式，最好给出结构化 schema、字段含义、枚举值、单位、长度限制和错误返回；如果需要 JSON，就要说明只能输出 JSON，以及未知字段如何填。第六步把 Prompt 当成可迭代资产，用评测集、badcase、版本管理和回归测试验证改动。一个好的回答要体现：不同任务的差异主要体现在目标函数和验收方式不同，所以 Prompt 的指令强度、示例数量、输出格式和约束边界也要随之变化。

考点 任务先行
难度 真实面经题
回答目标 让候选人能把 Prompt 设计讲成可工程化的方法：围绕任务目标调整指令、示例、输入输出契约和约束，并用评测闭环验证稳定性。
02

深入解析

01

先定义任务和验收标准

Prompt 不是文案润色，而是把任务目标转成模型可执行的约束。设计前要明确模型最终产物是什么、谁使用、怎么判定对错，以及失败成本有多高。封闭式任务通常追求一致性和可评测，开放式生成任务更关注相关性、完整性和表达质量，决策类任务还要说明依据和不确定性。任务目标越清楚，后面的指令、示例和输出格式越不容易漂。

02

指令要体现任务差异

不同任务的指令重点不同。分类任务要给出标签集合、判定标准、优先级和无法判断规则；信息抽取要定义每个字段、来源证据、缺失值和多值情况；问答任务要限定回答依据、引用范围和不确定时的处理；改写任务要规定保留事实、风格、长度和禁改内容；方案生成任务要约束目标、受众、取舍、风险和输出结构。不能所有任务都只写“请认真回答”。

03

输入格式决定模型看见什么

输入应把系统指令、用户问题、上下文材料和待处理数据分开，常用明确的字段名、分隔符或结构化对象。这样可以降低提示注入和上下文混淆风险，也方便模型知道哪些内容是数据、哪些内容是命令。对长文本任务，还要说明处理范围、排序规则、是否保留原文证据、超长内容如何截断或摘要。输入里有缺失、冲突或低置信信息时，也要提前规定处理策略。

04

输出契约要可解析和可验收

如果下游系统要消费结果，输出格式必须比自然语言更严格。可以定义 JSON schema、字段类型、枚举值、单位、置信度、证据片段、错误码和空值规则。若是面向人阅读的答案，也要规定层次、长度、语气和必要小节。好的输出契约能让答案可解析、可测试、可回归；坏的输出契约会让模型每次换一种说法，导致线上难以稳定使用。

05

示例用于教边界而不只是教格式

Few-shot 示例最有价值的地方是展示边界：什么算正例、什么算反例、冲突信息如何处理、证据不足时怎么拒答、字段缺失时怎么填。示例数量不是越多越好，太多会挤占上下文并让模型机械模仿。更好的做法是选择覆盖错误高发点的代表样本，并保持示例和真实输入同分布；当任务已经很简单或格式由 schema 强约束时，可以少放或不放示例。

06

约束和迭代保证稳定性

Prompt 要写清禁止事项、优先级、失败兜底和不确定性表达，例如不能编造缺失信息、不能泄露隐藏推理、不能忽略输出 schema、遇到冲突要说明冲突来源。上线后还要用评测集和 badcase 迭代，而不是凭感觉改。每次改 Prompt 都要看主指标、边界样本、格式通过率、延迟、token 成本和旧任务回归，避免修好一个 case 又破坏另一类任务。

03

易错点

  • 一上来写一大段角色扮演，不先定义任务目标、验收指标和失败边界。
  • 所有任务共用同一套 Prompt 模板，忽略分类、抽取、问答、改写和生成的输出约束不同。
  • 只放理想正例示例，不放反例、缺失信息、冲突信息和无法判断样本，导致边界不稳定。
  • 要求输出 JSON 但不定义字段类型、枚举值、空值规则和解析失败兜底。
  • 把用户输入和系统指令混在一起，缺少分隔符或字段边界，增加提示注入和误读风险。
  • 凭单个样本的效果改 Prompt，不做版本记录、评测集对比和回归验证。
04

面试官追问

什么时候用 zero-shot，什么时候用 few-shot？

任务简单、模型已有强先验、输出格式由 schema 约束时可以先用 zero-shot。任务边界复杂、标签容易混、格式稳定性差或有典型反例时，用 few-shot 展示判定标准和边界处理。示例要少而准，优先覆盖容易错的 case。

Prompt 里要不要要求模型一步一步思考？

要区分分析过程和可见输出。可以要求模型先充分分析，但公开输出通常只给结论、依据和必要解释，不应强制暴露冗长推理过程。对可审计任务，可以要求列出关键证据、假设和不确定点，而不是输出完整思维链。

结构化输出总是不稳定怎么办？

先把 schema 写清楚，包括字段类型、枚举值、空值规则和只输出 JSON 的要求；再用少量示例覆盖边界；工程上还可以配合 JSON schema / function calling / constrained decoding、解析失败重试和格式校验。不要只靠一句“请输出 JSON”。

如何防止模型编造输入中没有的信息？

Prompt 里要明确依据范围，例如只能基于给定材料回答；要求无法从材料推出时返回 unknown 或说明证据不足；输出中可带证据字段或引用片段。评测时要专门放信息缺失样本，检查模型是否会硬猜。

Prompt 迭代怎么避免越改越差？

把 Prompt 当版本化配置管理。每次改动记录动机和影响范围，用固定评测集比较主指标、格式通过率、badcase 修复率、旧样本回归、成本和延迟。不要只针对一个失败样本手工加补丁。