一、五要素结构
一个可复用的提示通常包含：
- 角色：以什么身份回答（影响语气与专业深度）。
- 任务：具体要做什么，动词明确（总结、改写、分类、生成）。
- 上下文：背景信息、读者是谁、已有材料。
- 约束：长度、风格、必须包含/禁止包含的内容。
- 输出格式：JSON、表格、Markdown 列表、纯文本。
你是资深后端工程师。请把下面这段报错解释给非技术同事听。
要求：不超过 150 字，不用专业术语，最后给一条可执行的建议。
输出：一段话 + 一行「建议：…」。五要素不必每次全写，但任务和格式几乎总要写清楚。
二、少样本示例（few-shot）
给 1–3 个「输入 → 输出」的样例，比长篇描述更有效，尤其适合固定格式的任务：
把商品标题改成「品类 + 卖点 + 规格」的结构。
示例1：
输入：Apple iPhone 15 128G 蓝色 全新
输出：智能手机｜A16芯片超长续航｜128G 蓝色
示例2：
输入：Nike 跑步鞋 男 透气 42码
输出：跑步鞋｜透气轻量缓震｜男款 42码
现在处理：小米 空气炸锅 4L 家用 白色要点：示例要覆盖「边界情况」，别只给最典型的；示例里的格式必须和期望完全一致。
三、让它分步想
复杂推理任务（数学、多条件判断、长文分析）可以要求先列步骤再给结论：
先列出判断依据（3 条以内），再给出结论。这能减少「直接跳到答案」的错误。但注意：思维链不是万能的，对事实性问题它可能编出看似合理的推理过程。涉及事实的内容仍要自己核实。
四、避免歧义
- 「简短」是模糊的：写「不超过 100 字」。
- 「专业一点」是模糊的：写「面向有 3 年经验的开发者，可用术语但需解释缩写」。
- 「优化一下」是模糊的：写「减少被动句、把长句拆成两句、去掉形容词」。
- 代词指代不清：把「它」换成具体名词。
五、常见任务的具体写法
总结：指定长度、面向对象、是否保留数字与结论。
用 5 条要点总结全文，每条不超过 25 字，保留关键数字，面向管理层。改写：给风格样例，而不是形容词。
改写成下面这种风格：「结论先行，一句话说清，再补两条依据。」分类：给类别定义与「无法判断」时的处理方式。
把工单分为「退款/物流/质量/其他」四类。无法判断时输出「其他」并说明原因。抽取：明确字段与缺失值规则，要求 JSON 输出。
从文本中抽取：订单号、金额、下单时间。缺失填 null。只输出 JSON，不要解释。六、迭代与评测
一次写出完美提示很难，正确流程是：
- 写最小可用版本。
- 用 5–10 个真实样本跑一遍。
- 找出错误类型（漏字段？格式错？理解偏？）。
- 针对错误加约束或加示例。
- 固定一组测试集，每次改提示都回归一遍。
没有测试集的「调提示」等于盲调，改好一个场景可能弄坏另外三个。
七、几个实用技巧
- 把最重要的要求放最后：长提示里，末尾的指令更容易被遵循。
- 正面表述优于否定：说「用短句」比「不要用长句」有效。
- 给「不知道」的出口：允许回答「资料中未提及」，能显著减少编造。
- 分离指令与数据：用分隔符（
---、###）把待处理内容包起来，避免被当成指令。 - 控制输出长度：明确字数或条数，否则容易啰嗦。
八、安全与合规
- 不要把密码、密钥、客户隐私粘进公共模型。
- 生成的代码要审查后再运行，尤其是涉及文件删除、网络请求的部分。
- 事实性内容（法律、医疗、财务）必须核对来源，模型可能给出过时或错误的答案。
小结
写清角色、任务、上下文、约束、格式；给示例比讲道理有效；模糊词换成可量化的要求；用真实样本建测试集迭代；给模型「不知道」的出口以减少编造。