让它稳定听懂：Markdown、示例与格式控制

把提示词写成带标题、列表、分段的 Markdown，模型解析得更准。这不是审美偏好，是降低歧义的工程手段： 标题划清段落边界，「背景」「要求」「材料」不会互相粘连； 列表让并列项一目了然，模型不易漏项； 代码块把「要处理的原材料」和「你对它的指示」物理隔开。 经验法则：一两句话的短请求随意；只要提示词超过五行，就用 Markdown 组织。尤其当你在做产品、提示词会被反复执行时，结构化的收益会随调用次数放大。

与其花一百字形容「语气要专业但不生硬」，不如直接给一个符合期望的示范段落。这就是少样本示例（few-shot）：在提示词里附上一两个输入输出的配对样本，让模型照着模仿。 用法上有三条纪律： 数量：一到三个足够，太多反而挤占上下文、模糊重点。 同构：例子必须和真实任务的输入输出长得一样——例子里是三行表格，任务输出也该是三行表格。 干净：示例里的错误会被忠实学走。例子里有个错别字、一个错误格式，输出就会复刻它。 反过来说，什么时候不该给例子？当你只有「大概像这样」的材料时。低质量的例子比没有例子更糟。

当输出要交给程序处理而不是给人阅读时，格式必须说死： 明确写出「只返回 JSON，不要解释」，并给出字段清单和类型； 提供一个最小骨架示例； 说明异常路径——解析失败或字段缺失时如何表现。 两个进阶提醒： 流式输出的场景下，前端会收到不完整的半截 JSON，解析逻辑必须容忍中间态； 格式约束越强，越要在真实的最大负载上验证一次——资料一长，模型偶尔会在几百行之后「忘记」格式约定，程序侧要有兜底校验。 一个生活化的比喻：跟模型要 JSON 输出，就像在餐厅点菜——你不只说「来个炒菜」，而是说「一份宫保鸡丁，微辣，不要花生，盛在白色圆盘里」。说得越精确，上菜越不会出错。