提示词工程实战：让大模型稳定输出你要的结果

很多团队把大模型接进业务后，发现输出时好时坏。问题往往不在模型，而在提示词工程没做扎实：没有给出明确的角色、任务、上下文和格式，模型只能靠猜。本文把提示词工程拆成一套可复用的方法论，让你每次都能稳定拿到想要的结果。

一、为什么提示词工程决定 AI 应用的成败

大模型是概率系统，同一个问题换种说法就可能得到完全不同的答案。提示词工程的目标，就是用确定性的”指令结构”去约束这个概率系统：把模糊的人类意图翻译成模型能稳定执行的明确步骤。它和更上层的上下文工程互补——上下文工程决定”喂给模型什么”，提示词工程决定”怎么让它照做”。

一个常被忽视的事实是：同样的模型，提示词写得好坏，输出合格率可能差出三到五成。把提示词当成可迭代的工程资产，而不是一次性的聊天句子，是团队能不能把 AI 真正用起来的分水岭。

二、RTFC 框架：角色、任务、上下文、格式

写提示词最稳的起手式是 RTFC 四要素：Role（角色）、Task（任务）、Format（格式）、Context（上下文）。少了任何一项，模型都会自行补全，而补全往往不符合你的预期。

# 结构化提示词模板（RTFC）
你是一名资深 Java 代码审查专家（Role）。
任务（Task）：审查下面这段 Spring Boot 控制器，指出 3 个最可能导致
并发安全问题的点，并给出修改建议。
格式（Format）：用 Markdown 列表输出，每条含"问题 / 风险 / 修复"三段。
上下文（Context）：
<代码>
@RestController
public class OrderCtrl {
  private int counter = 0;
  @GetMapping("/next")
  public int next() { return counter++; }
}
</代码>

三、少样本与思维链（Few-shot / CoT）

当任务有隐含规则时，给 1–3 个示例比写一长段规则更管用，这就是少样本（Few-shot）。而思维链（Chain of Thought）则要求模型”先一步步推理再给答案”，能显著降低复杂推理的出错率。

# 思维链示例：让模型先推理后结论
问题：仓库有 120 件货，周一卖 1/3，周二卖剩下的 1/4，还剩多少？
请一步步思考：
1. 周一卖出 120 × 1/3 = 40，剩 120 - 40 = 80。
2. 周二卖出 80 × 1/4 = 20，剩 80 - 20 = 60。
答案：60 件。

现在用同样的方式解答：……

四、用输出约束锁定结构

自然语言输出最难被程序消费。生产环境应优先要求模型返回结构化数据：JSON、函数调用或 XML。主流 API 支持 response_format 或 JSON Schema 约束，能从协议层杜绝格式漂移。

// 用 JSON Schema 锁定输出结构（OpenAI 兼容接口）
fetch("https://api.example.com/v1/chat/completions", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({
    model: "agnes-2.5-flash",
    messages: [{ role: "user", content: "提取订单：买2个A和3个B" }],
    response_format: {
      type: "json_schema",
      json_schema: {
        name: "order",
        schema: {
          type: "object",
          properties: {
            items: { type: "array", items: {
              type: "object",
              properties: { name: { type: "string" }, qty: { type: "integer" } }
            }}
          },
          required: ["items"]
        }
      }
    }
  })
});

五、系统提示词与用户提示词的分层

把”恒定不变的身份与规则”放进系统提示词，把”每次变化的输入”放进用户提示词。分层后，系统提示词可以长期沉淀为资产，用户提示词保持轻量。在AI Agent 工作流里，系统提示词通常承载工具使用规范，用户提示词承载具体任务。

# 分层示例
system: 你是运维助手，只允许调用已授权工具，禁止执行删除类命令，
        回答用中文，结论前置。
user:   查一下生产环境 Nginx 最近 5 分钟的 5xx 错误率。

六、检索增强（RAG）里的提示词技巧

RAG 不只是”把文档塞进上下文”。提示词要明确要求模型只基于检索片段作答、标注引用来源、检索不到就直说不知道。检索质量本身也依赖Embedding 模型选型与文本向量化——提示词和检索是同一链路的两端，缺一端都拿不到好答案。

七、用提示词缓解幻觉

幻觉无法根除，但提示词能显著降低概率：要求”不确定的内容标注[存疑]””禁止编造链接与数据””先列证据再下结论”。更系统的做法见大模型幻觉检测与缓解实战，提示词是其中成本最低、也最该先上的第一道防线。

八、把复杂任务拆给 Agent

单条提示词塞不下复杂流程时，用 Agent 把任务拆成多步：规划→调工具→汇总。每一步用短提示词约束单一目标，比一条超长提示词稳定得多。配合人工确认节点，还能在关键动作前拦截风险。

例如”先生成 SQL，再交人工确认后执行”，比”直接让模型改生产库”安全得多；把”生成”和”执行”拆成两个带独立提示词的步骤，风险边界就清晰了。

九、评测与回归：提示词也要测试

提示词改一次就可能悄悄退化。把它当代码管：建一组固定用例，每次改动后跑回归，对比通过率。下面这段脚本用固定问题集批量打分，低于基线就报警。

# 提示词回归测试（伪代码）
cases = [("提取订单", expect_json), ("总结邮件", expect_bullets)]
for q, expect in cases:
    out = call_llm(SYSTEM_PROMPT, q)
    score = rubric(out, expect)      # 准确性 + 格式合规
    assert score >= 0.8, f"回归失败: {q} 得分 {score}"

# 评测维度：准确性 / 格式合规 / 稳定性 / 成本 / 延迟

十、实战清单：10 条可直接抄的规矩

把上面所有方法压成十条铁律：① 写清角色与任务；② 给输出格式；③ 复杂任务给示例；④ 推理题加”一步步想”；⑤ 生产环境锁 JSON/函数调用；⑥ 系统/用户提示词分层；⑦ RAG 要求标注来源；⑧ 禁止编造；⑨ 复杂流程拆给 Agent；⑩ 提示词进回归测试。照做，你的大模型输出会从”看运气”变成”可交付”。

小结

提示词工程不是玄学，而是把人类意图结构化、可测试化的工程实践。从 RTFC 起步，逐步叠加少样本、思维链、输出约束与评测回归，你就能把大模型稳定锁进业务需要的形状。它和上下文工程、RAG、Agent 是一整套能力，而提示词是其中最常被低估、也最该先打好的地基。