Prompt Engineering 进阶：6 个让输出更稳定的实用技巧

概述

Prompt Engineering 的核心是把任务边界、输入结构、输出约束和失败处理写清楚。对 LLM 应用来说，好的 prompt 应该稳定、可解析、可调试，而不是只追求"说得更详细"。

1. 角色 + 受众双重设定

角色决定回答的专业边界，受众决定解释深度。只写"你是专家"通常不够，模型不知道该用入门解释、工程实践还是架构视角。

python 复制代码

prompt = """
你是一个 AI 专家，解释什么是 RAG。
"""
# 差：原因：只有角色，没有受众，输出深度不可控

python 复制代码

prompt = """
你是一位有 3 年 LLM 应用开发经验的后端工程师。
请面向会写 Python、刚接触 LLM 开发的工程师，
解释 RAG 的作用、基本流程和一个最小使用场景。
"""
# 好：原因：角色限定专业视角，受众限定术语和解释粒度

2. Chain of Thought（先给依据再给答案）

在应用里，不建议要求模型输出完整隐藏推理链。更稳的做法是让模型先给可检查的判断依据、步骤或检查项，再输出结论，便于人工或程序复核。

python 复制代码

prompt = """
判断这个 prompt 写得好不好：
请帮我总结这篇文章。
"""
# 差：原因：只要求结论，无法判断模型为什么这么评估

python 复制代码

prompt = """
评估下面的 prompt。

请按顺序输出：
1. 任务是否明确
2. 输入是否完整
3. 输出格式是否可控
4. 修改建议
5. 最终结论

Prompt:
请帮我总结这篇文章。
"""
# 好：原因：要求先给可检查依据，再给结论

3. Few-shot 正例 + 负例

Few-shot 不只是给模型看"应该怎么做"。加入负例可以明确禁止行为，减少输出跑题、格式漂移和过度解释。

python 复制代码

prompt = """
把用户问题改写成搜索关键词。

用户问题：怎么让 OpenAI 返回 JSON？
"""
# 差：原因：没有示例，模型可能输出解释而不是关键词

python 复制代码

prompt = """
把用户问题改写成搜索关键词，只输出关键词。

正例：
用户问题：怎么让 OpenAI 返回 JSON？
输出：OpenAI JSON 输出格式 response_format

负例：
用户问题：Prompt Engineering 有什么技巧？
错误输出：Prompt Engineering 有很多技巧，比如角色设定和 Few-shot。
原因：这是回答问题，不是搜索关键词。

现在处理：
用户问题：怎么减少大模型幻觉？
"""
# 好：原因：正例定义目标，负例定义不要做什么

4. 输出格式显式约束（JSON/结构化）

只说"结构化输出"不够。只要结果要进程序，就要明确字段、类型、取值范围和是否允许额外文本。

python 复制代码

prompt = """
分析用户反馈，返回结构化结果：
登录后页面一直转圈。
"""
# 差：原因：没有字段约束，程序解析不稳定

python 复制代码

prompt = """
分析用户反馈，只返回 JSON，不要 Markdown，不要解释。

字段：
- category: 字符串，取值为 bug、feature、question
- severity: 字符串，取值为 low、medium、high
- summary: 字符串，20 字以内

用户反馈：
登录后页面一直转圈。
"""
# 好：原因：字段、类型和输出边界明确

5. XML 标签结构化输入

当 prompt 同时包含任务、背景、规则和原文时，用 XML 标签分隔可以减少混淆。它尤其适合长上下文和多段输入。

python 复制代码

prompt = """
请总结下面内容。背景是线上事故复盘。内容是 Redis 连接池耗尽导致登录失败。
"""
# 差：原因：任务、背景和正文混在一起，边界不清

python 复制代码

prompt = """
<task>
总结事故复盘，输出原因、影响、修复动作。
</task>

<context>
读者是后端工程师，关注可执行改进。
</context>

<content>
Redis 连接池耗尽导致用户登录失败，扩容连接池后恢复。
</content>
"""
# 好：原因：任务、上下文和待处理内容边界清楚

6. 给模型退出通道（减少幻觉）

信息不足时，模型可能为了完成任务而补全不存在的事实。给退出通道，就是允许它说"不知道"，并说明还缺什么证据。

python 复制代码

prompt = """
根据日志判断接口超时根因：
ERROR request timeout
"""
# 差：原因：证据不足但强行要求根因，容易编造

python 复制代码

prompt = """
根据日志判断接口超时根因。

要求：
- 如果证据不足，回答"无法判断"
- 说明还需要哪些日志、指标或配置
- 不要编造服务名、时间线、调用链或根因

日志：
ERROR request timeout
"""
# 好：原因：允许退出，并约束模型不要补全不存在的信息

组合使用建议

实际开发中，可以按固定顺序组装 prompt：先写角色和受众，再写任务目标，然后用 XML 放输入，接着给正负例，最后约束 JSON 输出和失败出口。

调试时不要一次改太多。先固定 3 到 5 条测试输入，观察输出是否稳定；如果格式不稳，先加强输出约束；如果语义跑偏，补 Few-shot；如果出现编造，增加退出通道和证据要求。Prompt 的目标不是让模型永远正确，而是让错误更少、更早暴露、更容易处理。