示例提示与结构化输出

为什么给一个例子比多写几个形容词更直观

“写得简洁一点”允许很多解释；展示一份你认为简洁的结果，能更直接地说明希望的处理方式。模型可以把这些示例作为当前上下文，模仿其中的模式，再处理新输入。这通常叫示例提示；给少量样例时，也常被称为 few-shot 提示。

它与重新训练不同。你是在本次输入中提供参照，没有因此自动修改模型参数。示例的价值在于减少任务歧义，而不是让模型永久获得一项新能力。

用分类任务看看示例怎样工作

假设你希望整理客户留言，输出“类别、主要问题、需补充信息”。先给两个例子：留言“衣服尺码小了”对应售后问题，可能需要订单信息与换货需求；留言“这个包多重”对应商品咨询，需要具体型号。

再给“杯子收到就是碎的，怎么处理”，模型就有了一个可参照的模式：类别为售后，问题是商品破损，补充信息与订单、破损情况有关。它不应该因此直接答应退款，因为例子只定义了整理方式，没有提供退款政策或执行授权。

好的例子应覆盖真正会遇到的差异。如果所有例子都非常简单，模型遇到“杯子碎了，配送也晚了三天”时，可能强行只分进一个类别。你可以补充多问题样例，说明允许多个标签，并保留各自的问题。

输出格式为什么重要

固定栏目让人更容易检查缺项，也方便后续程序使用。例如，同样是整理活动信息，一段散文中的日期不容易批量提取，固定为“时间、地点、人数、报名方式”后，就能逐项核对。

JSON可以先理解成一张字段明确的数据表。下面是教学示例，不是某家服务的固定接口：

{"time":"周六15:00","place":"二楼会议室","capacity":8}

左边的time、place、capacity是字段名，右边是对应值。程序可以直接找到capacity并读取8，不必从一大段文字中猜哪个数字表示人数。

格式正确和内容正确怎样分别检查

一份JSON即使能被程序读取，也可能把周六写成周日。反过来，事实正确的散文也可能不符合软件要求的结构。真正使用时，需要分别检查格式是否满足约定，以及内容是否忠实于材料。

对于缺失信息，先约定怎样表示，例如写“未说明”，或使用接口允许的空值。不要为了填满所有栏目而让模型编造。模型若用于程序流程，程序还应拒绝不合要求的结果，并决定补问、重试或转人工。