All Pages Edit on GitHub

Prompt Engineering

Prompt Engineering 的目标不是写漂亮句子，而是让模型在真实产品里稳定、可控、可评测地工作。

Prompt 的本质

Prompt 不是一句“咒语”，而是任务接口。它把业务目标、上下文、约束和输出格式翻译成模型能执行的指令。

一个工程化 Prompt 应该满足三点：

如果一个 Prompt 只能靠某个人现场解释才能用，它就还不是一个可靠的工程资产。

一个好的 Prompt 应包含什么

Prompt 分层

在真实应用里，Prompt 通常不是一整段字符串，而是多层信息组合：

层级 内容 是否经常变化
系统规则 角色、安全边界、总体原则 很少变化
任务模板 当前功能的目标、步骤、输出格式 中等频率
业务上下文 产品规则、用户状态、文档片段 经常变化
用户输入 用户当前问题 每次变化
示例 少量高质量输入输出样例 偶尔变化

分层的好处是便于测试和替换。比如你可以单独评测任务模板，也可以比较不同上下文检索策略。

推荐模板

你是一个{角色}。

任务：
{明确任务}

背景：
{上下文信息}

约束：
- {约束 1}
- {约束 2}

输出格式：
{格式要求}

如果信息不足：
{澄清或拒答策略}

更适合生产的结构化模板

角色：
你是一个{业务场景}中的{助手类型}。

目标：
{一句话说明任务成功标准}

可用信息：
{上下文、资料、工具结果}

必须遵守：
- 只基于可用信息回答
- 不确定时说明缺少什么信息
- 不输出内部推理过程
- 不执行权限之外的建议

输出格式：
{JSON schema 或 Markdown 结构}

失败处理：
如果无法完成，返回{固定失败格式}，并说明原因。

生产场景要特别重视“成功标准”和“失败格式”。这会让后续评测和错误处理更容易。

新手最容易犯的错误

错误写法：

帮我总结一下这个文档。

更好的写法：

你是一个产品经理助手。请阅读下面文档，输出一份面向研发团队的需求摘要。

要求：
- 用项目符号输出
- 必须包含目标用户、核心需求、风险和待确认问题
- 不要编造文档中没有的信息
- 如果信息不足，请写在“待确认问题”里

区别在于：后者明确了角色、读者、输出格式、边界和失败处理。

常用技巧

Few-shot 示例怎么写

Few-shot 是给模型少量示例，让它模仿格式和判断标准。示例不需要多，但要有代表性。

好的示例应该覆盖：

不要放太多相似示例，否则会浪费上下文。示例也要和真实线上输入接近，不要只写理想化样例。

Chain-of-thought 和可解释输出

在产品里不一定要让模型输出完整思考过程。更推荐让模型输出“简洁理由”或“依据字段”，例如：

{
  "category": "billing",
  "confidence": 0.82,
  "reason": "用户询问发票和扣款问题",
  "need_human_review": false
}

这样既能帮助人工复核，也不会把冗长、不稳定的推理过程暴露给用户或下游系统。

输出格式设计

如果输出要给程序使用，尽量满足：

示例：

{
  "answer": "string",
  "sources": [
    {
      "title": "string",
      "url": "string",
      "chunk_id": "string"
    }
  ],
  "cannot_answer": false,
  "missing_info": []
}

好的 schema 会减少很多后处理麻烦。

项目检查点

Prompt 版本管理

当项目变复杂后，Prompt 应该像代码一样管理：

Prompt 评测方法

Prompt 改动后，不要只看一个样例。至少准备三类测试：

类型 目的
正常样例 确认常见输入能稳定完成
边界样例 检查信息不足、歧义、超长输入
失败样例 检查拒答、格式错误、越权请求

记录每次改动前后的通过率、失败原因和示例输出。这样 Prompt 才能像代码一样迭代。

适合结构化输出的任务

不适合只靠 Prompt 解决的问题

这些问题应该结合代码、规则、工具、评测和人工复核一起解决。

实战练习