Prompt Engineering

好提示先回答四个问题#

谁来读结果？要完成什么任务？允许依据哪些材料？缺少信息怎么办？把这些说清，比反复加入“你是顶级专家”“必须完美”更容易建立可检验的要求。官方指南把提示设计视作需要迭代的方法，而非保证结果的咒语。1

把模糊要求改成可验收任务#

教学示例：整理客服工单。 “分析下面内容并输出结果”没有规定要提取什么，也没有规定如何处理缺失信息。可以改成：

任务：从 customer_message 中提取问题类型和订单号。
问题类型：物流、退款、其他，只能选一个。
依据：只能使用消息中明确出现的信息，不推测订单号。
缺失：没有订单号时记为 null；含义不清时类型记为“其他”。
输出：问题类型、订单号、作为判断依据的原文短句。
customer_message：包裹还没到，帮我查一下。

这段提示用于理解任务设计，并不是某家 API 的完整调用代码。若结果直接进入程序，还要配置 结构化输出 和业务校验。

示例什么时候有帮助#

Few-shot prompting（少样本提示）是在输入中给出少量示例，展示你接受的分类边界或输出风格。Google 文档提供了这种方法的具体说明。2

示例不应全是容易题。如果“多久到货”属于物流，“地址填错想取消”归退款还是其他，就需要写清规则。否则模型可能从几个例子中归纳出与你业务不同的边界。

也不要把调试样例同时当成最终测试集：已经针对它改过提示，答对它不足以证明能处理新输入。

一次只改一个假设#

本站建议保存提示版本，并记录“预期修复什么”。例如：

1. 发现缺失订单号被编造，提出假设：缺失策略不明确。
2. 只增加缺失策略和一个反例，其他条件保持一致。
3. 同时检查编号缺失、编号正常、包含多个编号三类输入。
4. 记录错误数量和具体样例；确认修复没有让正常编号被丢弃。

如果错误来自过期资料，改提示通常不是第一步。先换正确资料；如果错误来自权限，应改应用控制；如果格式不稳定，应检查输出约束。

提示的能力边界#

提示可以约束任务表达，但不能代替可信数据、权限检查或数学计算。外部文档里的“忽略之前指令”也不应被当作新的系统要求；仅用分隔符不能建立完整安全边界。

当你开始管理检索资料、对话历史、工具说明和中间结果时，问题已进入 上下文工程。