提示工程核心原则

摘要：本文面向需要在生产环境稳定调用大模型的 SRE / 平台工程师与后端开发者。我们以 OpenAI 官方 Prompt Engineering 指南与 Anthropic 官方提示工程指南为骨架，提炼出六条可落地的核心原则，并补充「把 prompt 当代码管理」的工程化视角。适用模型：GPT-4o 系列（上下文 128K）、Claude 4 系列（上下文 200K）等主流对话模型；具体数值与功能标注 [版本相关]。

核心概念：提示工程不是玄学

提示工程（Prompt Engineering）的本质是用规范化的输入约束概率模型的输出分布。与微调（fine-tuning）相比，提示工程资源需求低、迭代快、成本可控——Anthropic 官方也明确指出提示工程通常比微调更高效。但它同样需要工程纪律：版本化、可测试、可回滚。

两条主线来源

• OpenAI 官方指南：给出六条策略（Write clear instructions / Provide reference text / Split complex tasks / Give the model time to think / Use external tools / Test changes systematically）。
• Anthropic 官方指南：面向 Claude 模型，强调「明确具体、提供上下文、谨慎示例、积极指导」四条基础原则，并给出按优先级排序的实践（XML 标签、预填充、链式提示等）。

架构与原理：模型如何读 prompt

大模型不会「读心」。它基于训练分布对输入做最大似然续写。prompt 写得越模糊，模型需要猜测的隐含假设越多，输出方差越大。六条原则对应六类「减少猜测」的机制：

生产实践：六大原则逐条落地

原则 1：写出清晰的指令

模型读不懂隐含意图。把「给谁看、用在哪、什么格式、长度多少、如何算成功」写进 prompt。

清晰指令的四个维度

1. 包含细节：与其问「怎么在 Excel 加数字」，不如说「对整个 sheet 的每行美元金额求和，结果放在右边名为 Total 的列」。
2. 赋予角色：让模型扮演领域专家（见 系统提示词与角色设计）。
3. 用分隔符：三引号、\n\n、XML/Markdown 标题把不同部分清晰隔开，减少歧义（Anthropic 官方强烈推荐 XML 标签 <context>...</context>）。
4. 指定步骤与长度：明确列出操作步骤，并用段落/要点而非精确字数约束长度（字数计数受 tokenizer 影响，易漂移）。

原则 2：提供参考文本

语言模型在冷知识、引用、URL 上会自信地编造（hallucinate）。给它参考文本，相当于开卷考试。

• 指令要求「仅依据参考文本回答，找不到就说不知道」。
• 要求「用参考文本中的段落引用作答」，引用可用代码比对程序化校验。

参考文本：
"""
<粘贴你的知识库/文档段落>
"""
问题：{{user_question}}
要求：仅使用上述参考文本回答；若文本不含答案，输出"信息不足"。

原则 3：把复杂任务拆成子任务

复杂任务错误率高于简单任务。拆分手段：

• 意图分类：先识别用户问题属于哪类，再路由到对应指令集。
• 长对话摘要/过滤：对话接近上下文上限时，自动摘要历史或检索相关片段。
• 长文档递归摘要：分块总结，再汇总成全篇摘要。

原则 4：给模型时间「思考」

模型匆忙作答比逐步推理更容易出错。手段包括：

• 要求先输出「自己的解法」再下结论（避免被错误示例带偏）。
• 用「内心独白」或分段查询隐藏推理过程，只对用户暴露结论。
• 追问「上一轮是否遗漏了什么」。

原则 5：使用外部工具

用工具弥补模型弱点：

• 嵌入检索（RAG）：相关文档喂给模型，解决新鲜度与引用。
• 代码执行：复杂计算、调用外部 API 交给沙箱执行。
• 函数调用（function calling）：模型产出符合 schema 的参数，由你的代码执行。注意：执行模型生成的代码本质上不安全，必须用沙箱隔离 [安全相关，见官方警告]。

原则 6：系统化测试变更

改一个 prompt 可能在个别样例变好、整体变差。建立 eval 集（gold-standard 答案），用「控制变量法」逐元素修改，用模型或人工对照评分。这与 评测方法论 一致。

不要一次改多个变量

提示工程的回归测试必须遵循单一变量原则。同时改角色设定和输出格式，你无法判断性能变化来自哪一处。建立一份覆盖边界场景的 eval 集，是 prompt 可维护的前提。

操作步骤：建立提示工程工作流

1. 把 prompt 模板化、版本化

固定部分（角色、输出格式）与变量部分（用户输入、检索结果）用占位符分离，纳入 Git 管理：

# prompt_template.py
SYSTEM_TEMPLATE = """你是一个资深 SRE。
背景：我们在排查生产告警。
要求：
1. 先列出最可能的 3 个根因
2. 每个根因给一条可执行的排查命令
3. 输出纯 JSON，字段为 root_causes(list)、commands(list)
上下文：
<incident>
{ticket}
</incident>
"""

def build_messages(ticket: str):
    return [{"role": "system", "content": SYSTEM_TEMPLATE.format(ticket=ticket)}]

2. 用 eval 集回归

# 伪命令：对 eval 集跑全部用例并比对评分 [未实测，按你的测试框架替换]
pytest tests/prompt_eval.py --benchmark --model gpt-4o

验证

• 单元层：单个样例跑通，检查输出是否符合格式与事实。
• 集合层：eval 集上统计通过率、幻觉率、格式错误率，建立基线。
• 线上层：灰度流量对比新旧 prompt 的业务指标（如用户采纳率）。

回滚与清理

prompt 变更同样需要回滚预案

prompt 一旦上线影响全体请求。变更前保留旧版本模板与 eval 基线；发现线上指标下降时，通过配置中心/模型路由秒级切回旧版。不要把 prompt 硬编码在多个服务里。

故障排查

现象	可能原因	排查
输出格式飘忽	指令不够明确/缺示例	加分隔符、补 few-shot 示例
编造事实/引用	缺参考文本	原则 2，要求引用并校验
长任务中途出错	未拆分	原则 3 拆子任务
推理题答错	未给思考时间	加 CoT / 自我一致性
改 prompt 整体变差	多变量同时改	单一变量 + eval 回归

安全与合规

• 不要把密钥、PII、内部文档直接塞进 prompt；敏感内容脱敏、最小化。
• 执行模型生成代码须沙箱化（原则 5）。
• 提示本身属于业务逻辑，应纳入访问管控与审计（见 提示注入攻防）。

成本与性能

• 提示工程零训练成本，主要成本是推理 token。上下文越长、调用越频繁，费用越高；可通过长上下文缓存（见 上下文压缩与缓存）摊薄固定前缀成本。
• 原则 4 的「多路径自我一致性」会产生 N 倍调用，需在准确率与成本间权衡 [版本相关，价格以官网为准]。
• 模型选型：复杂指令类任务优先 GPT-4o/Claude 4；简单分类可下放到小模型以降成本。

参考资料

• OpenAI 官方 - Prompt engineering 指南
• Anthropic 官方 - Prompt Engineering 指南（Claude）
• Anthropic 官方 - Prompt Engineering 最佳实践（12 项）
• OpenCS Aalto - Prompting Basics & Taxonomy（复述 OpenAI 六策略）