提示词最佳实践

把 prompt 当代码来写:有结构、有版本、有评估,而不是「换一个咒语再试一次」。下面六节是我们在 Starsg 上跑过几十条线上链路后,沉淀下来效果最稳的写法。

1. 设定角色与目标

开头一两句话就把视角锚定:让模型知道自己是谁、为谁写、目标是什么。它会自动选择合适的术语密度、行文语气、详略取舍——比起后面再用各种「不要太啰嗦」「不要写得太学术」去拉回来,前置设定的成本最低。一个好的开场至少回答三件事:身份、读者、目标。

角色设定模板

你是一名服务 B 端开发者的技术布道师。
受众:刚接触 LLM、对 API 调用熟悉但不了解 token 计费的后端工程师。
目标:让读者在 3 分钟内判断「我们的业务是否值得接入 Starsg」,并给出下一步动作。
请用平实但专业的语气,避免营销话术。

2. 把任务写清楚

「帮我写个产品介绍」这种 prompt,等于把所有决定权交给模型——它每次都得替你猜。一个能复用的指令至少包含五要素:动作(写/总结/翻译)、对象(什么内容)、受众(给谁看)、风格/语气、长度或形式约束。把这五项写出来,你会发现模型输出的稳定性立刻上一个台阶。

❌ 不够清晰

帮我写个产品介绍。

✅ 五要素齐全

请用 200 字左右,面向后端开发者,介绍 Starsg 的三个核心差异点(统一网关、按 Key 计费、多模型 fallback)。语气专业克制,不要用「赋能」「打造」一类营销词,结尾给一句行动指令。

3. 提供上下文与示例(Few-shot)

需求越抽象,越要用例子说话。给模型 1–3 条「输入 → 期望输出」,比写十句解释更有效。Few-shot 尤其适用于:格式有固定要求(分类/抽取/JSON)、风格难用语言描述、领域有专属约定(法律、医疗、内部系统)。注意例子要覆盖真实分布,别全是简单 case。

Few-shot 抽取示例

从下面的工单文本中抽取「故障类型 / 影响范围 / 紧急程度」三个字段,只输出 JSON。

示例 1:
输入:用户反馈广州区域无法登录,客服电话被打爆。
输出:{"type":"登录","scope":"广州区域","severity":"P1"}

示例 2:
输入:某个测试账号显示余额错误,只影响内部 QA。
输出:{"type":"账户","scope":"内部 QA","severity":"P3"}

现在请处理:
输入:北京机房 API 网关返回 502,所有付费用户受影响。

4. 约束输出格式

下游要消费的输出,必须可被解析。要 JSON 就给 schema 和字段说明,要列表就限定条数和每条的结构,要不超过多少字就明示。最好同时附一句「如果信息不足,某字段填 null,不要编造」——它会显著降低幻觉。

JSON 输出约束

请将下方简历整理为 JSON,严格按以下 schema:
{
  "name": string,
  "yearsOfExperience": number,
  "skills": string[],     // 最多 5 项,小写
  "summary": string        // 不超过 60 字
}
如果原文未提及某字段,填 null,不要编造。只输出 JSON,不要任何前后缀文字。

5. 拆分复杂任务(含链式思考)

一次性让模型「分析+规划+输出」,通常会丢细节或者把推理直接当结论。两种处理思路任选其一:让它在内部分步(链式思考),或者你自己拆成多轮。需要可审计的场景推荐后者——把每一步的中间产物保留,后面好定位是哪一步出了问题。

分步指令模板

我会给你一段产品需求文档,请按以下三步处理,每一步用 ## 标题分隔输出:

## 1. 关键信息抽取
用要点列出:目标用户、核心场景、必须功能、明确不做的功能。

## 2. 风险与未明确项
列出文档中含糊或互相矛盾的地方,每条用一句话说明。

## 3. 下一步建议
给产品经理 3 条具体的、可执行的下一步动作,按优先级排序。

需求文档如下:
<<<

>>>

6. 迭代与评估

好 prompt 不是一次写出来的,是迭代出来的。给自己定一组固定的测试用例(20–50 条覆盖正常 + 边缘 + 对抗),每次改完 prompt 都跑一遍,记录命中率、平均长度、token 成本。把 prompt 当代码版本管理,改动有依据,回归有底线——不要凭感觉「这次好像更好了」。