在 RAG 应用的过程中，关于提示工程的设计有什么心得和技巧吗？

标签：AI、大模型、RAG、提示工程

🏛 业务架构师

提示工程在 RAG 里的作用常被低估——很多人以为检索准就万事大吉，其实最终答案质量的一半取决于提示设计。我的心得：

职责分离：System Prompt 定角色和规矩（"你是 XX 公司客服，只依据提供的资料回答"），检索内容用明确的分隔符（如 XML 标签）注入并编号，用户问题放最后——结构清晰，模型才知道"哪些是事实、哪些是指令"。
强制引用：要求答案标注引用来源（如 [1][2]），既能溯源核实，也天然抑制幻觉——编造的内容挂不上出处。
给退路：明确指示"资料中没有就说不知道，并建议转人工"。这句Prompt 能把"强行胡编"变成"诚实拒答"，对客服场景是投诉率的分水岭。
少样本引导：放一两个理想问答样例，输出格式立刻稳定，比反复描述要求有效。
版本化管理：提示词当代码管理，变更走评测集回归，禁止线上手改。

业务视角：提示工程是 RAG 里"投入最小、见效最快"的杠杆——改一句话可能顶得上换一个模型，应该每周都调，而不是一次性写完就不管。

🏗 系统架构师

我的提示工程心得可以压缩成四条工程纪律：

结构化分区：角色（你是谁）→ 任务（做什么）→ 上下文（检索内容用明确分隔符包住）→ 约束（格式、长度、禁区）→ 输出格式（JSON Schema 或示例）。分区让长 Prompt 可维护，也让 Prompt Cache 命中前缀成为可能（把稳定内容放前面，动态内容放后面，缓存命中能省 50%~90% 的输入费用）；
约束用"正向指令 + 少量示例"：示范一个好例子比十条"不要 XX"有效；必须禁止的事项放最后重申（指令遵循对首尾位置敏感）；
把"不知道"合法化：明确写"检索内容中没有依据时回答'未找到相关信息'"，这是治 RAG 幻觉性价比最高的一句话；
版本化管理：Prompt 是代码，进 Git、带版本号、改动跑回归集，绝不在生产控制台手改。

架构补充：复杂系统里 Prompt 是分层拼装的（系统层 + 领域层 + 动态上下文层），我会做模板引擎 + 变量注入，配合灰度发布。技巧层面（few-shot、CoT）都是战术，纪律层面（版本化、评测、缓存友好的布局）才是把 Prompt 工程从手艺变成工程的关键。

💻 全栈开发专家

我的提示工程就三条铁律加一套模板：

铁律：

结构与分隔：角色、任务、上下文、约束、输出格式分段，用 XML 标签或分隔符隔离不可信内容（防注入）；
约束显式化：不要写「简洁」，要写「不超过 3 条，每条不超过 30 字」；
给例子：few-shot 示例对格式对齐的作用远大于形容词。

我们的生产模板字段（做成版本管理的配置）：

yaml

prompt_template: "v2.3"
fields:
  role: "你是 {company} 的{domain}专家"
  task: "根据 <context> 中的资料回答用户问题"
  context: "<context>{documents}</context>"
  constraints:
    - "仅使用 context 中的信息，不得编造"
    - "无法回答时回复：知识库中未找到相关信息"
  output_format: "JSON: {answer, citations:[{doc_id, quote}]}"
  examples: [...]          # 2~3 个覆盖边界情况

迭代心法：提示词当代码管理——进 Git、语义化版本、每次改动跑评测集回归；坏例驱动迭代，每两周把线上 badcase 归类补进 few-shot 或约束。还有个省钱技巧：system prompt 前缀保持稳定能吃满 prompt caching，动态内容放后面，成本能降 50% 以上。