约 7 分钟4 张卡

提示词工程

提示词工程是为模型写清任务、约束、输入材料和输出格式，并用评测结果迭代提示的过程。本文覆盖提示的组成、Few-shot 与思维链的适用条件、结构化输出，以及怎样用数据而非感觉调优提示。

1. 面试核心

先记住这几条，再读正文

一份生产提示通常包含角色与任务、规则与约束、输入材料、示例、输出格式和异常处理说明。规则写成可检查的条件，而不是形容词。卡 · 提示的组成
调优以评测集驱动：收集失败样例，归类原因，修改提示，在同一评测集上比较，确认没有引入回归。卡 · 评测驱动的调优
Few-shot 用于约束格式和边界判断，示例要覆盖难例且避免全部同类；思维链用于多步推理，代价是更多输出 Token 和延迟。卡 · Few-shot 与思维链
需要程序解析的输出使用结构化输出或工具调用的 JSON Schema 约束，解析后仍要做业务校验：格式合法不等于内容正确。卡 · 结构化输出

2. 提示的组成

<role>你是电商售后客服助手，只处理订单、物流和退款问题。</role>

<rules>
- 退款金额超过 500 元时，调用 create_ticket 转人工，不直接承诺退款。
- 用户未提供订单号时，先询问订单号，不猜测。
- 只依据 <order> 中的信息回答；信息缺失时说明无法确认。
</rules>

<order>{{order_json}}</order>

<examples>
  <example>…</example>
</examples>

<output_format>
用中文回复，不超过 120 字；需要转人工时在末尾说明工单号。
</output_format>

几条写法上的经验：

规则可检查：“回答要专业”无法验证；“不超过 120 字、必须引用订单状态字段”可以验证。
说明原因：“不要使用省略号，因为回复会被语音合成朗读”比单纯禁止更容易被泛化到相似情况。
用标签分隔材料：指令和数据分开，模型更容易区分，也便于程序替换变量。
说明异常情况：信息不足、请求越界、工具失败时怎么做，比只描述正常流程更重要。
模板化与版本管理：提示存放在仓库中，用模板引擎填充变量，每次修改有版本号，便于回滚和对照评测。

3. Few-shot 与思维链

卡 · CoT 和 Few-shot 分别适合什么场景？

Few-shot（少样本示例）在提示中给出输入和期望输出的例子。它最适合传达难以用语言描述的格式、风格和边界判断。示例应覆盖难例和反例；全部示例都属于同一类时，模型会倾向输出这一类。示例过多占用上下文，也可能让模型照抄具体内容。

思维链（Chain of Thought）让模型在给出答案前写出推理步骤，适合计算、多条件判断、规划等多步任务。代价是输出变长、延迟和费用增加。许多模型已内置推理模式，可以通过参数开启，不一定需要在提示中要求“一步步思考”。直接的分类、抽取、改写任务通常不需要思维链。

场景	优先手段
输出格式、风格难以描述	Few-shot
分类边界模糊	Few-shot，包含边界附近的正反例
多步计算或条件判断	思维链或推理模式
简单抽取、改写	清晰指令 + 输出格式，不加推理

4. 结构化输出

卡 · 想要模型按照固定结构输出，应该怎么做？

程序需要解析模型输出时，只在提示中说“请输出 JSON”不够可靠：可能多出解释文字、缺字段或类型错误。可靠性从低到高：

提示中描述格式并给示例，程序侧用正则或解析器容错。
JSON 模式：保证输出是合法 JSON，但不保证字段符合预期。
结构化输出 / 工具调用：提供 JSON Schema，由提供方约束解码，输出符合 Schema 的字段和类型。

schema = {
    "type": "object",
    "properties": {
        "intent": {"type": "string", "enum": ["refund", "logistics", "other"]},
        "order_id": {"type": ["string", "null"]},
    },
    "required": ["intent", "order_id"],
    "additionalProperties": False,
}