Prompt 工程就是软件工程
第一次听到"Prompt 工程"时，我以为这不过是给 ChatGPT 写指令的花式叫法。经过两年构建生产级 LLM 系统，我现在认为它更准确的描述是：对一个随机函数编程。
输入是自然语言，输出是概率性的。但底层的工程纪律——清晰的规范、边界情况处理、测试——是纯粹的软件工程。
以下是我在每个生产系统中都在用的模式。
模式一：角色 + 上下文 + 任务 + 格式
最基础的提示词结构。每个生产提示词都应该包含这四个要素：
[角色]
你是一位专注于 SaaS 指标分析的资深数据分析师。
[上下文]
用户正在查看一家 B2B 软件公司的月度营收数据。
可用指标：ARR、流失率、扩展营收、客户数量。
[任务]
分析所提供的指标，识别前 3 大业务风险。
[格式]
以 JSON 格式回答，包含 risks 数组，每项包含：
title（字符串）、severity（low|medium|high）、explanation（字符串，不超过 100 字）
将这四个关注点分离，让提示词迭代更容易定位问题：输出不对时，可以判断是哪个部分出了问题。
模式二：思维链（CoT）处理复杂推理
对于任何需要多步推理的任务，让模型在回答前先思考：
在给出最终答案之前，请逐步思考：
1. 我有哪些信息？
2. 缺少哪些信息？
3. 有哪些可能的处理方式？
4. 考虑约束条件，哪种方式最合适？
然后按指定格式给出你的最终答案。
这在以下任务上能稳定提升输出质量：有边界情况的分类、代码生成、数学推理和规划。
模式三：接地规则（RAG 系统必备）
如果你的系统使用了检索，必须加入明确的接地规则：
关键规则：只能基于下方 <context> 中的信息作答。
如果上下文信息不足以回答问题：
- 说"根据现有文档，我没有足够的信息来回答这个问题。"
- 不要推测，不要使用上下文以外的知识。
- 不要只说"我不知道"——请说明具体缺少什么信息会有帮助。
这一条规则能预防 RAG 系统中绝大多数的幻觉问题。
模式四：结构化输出 + 校验
能用结构化输出就绝对不要解析自由文本：
from openai import OpenAI
from pydantic import BaseModel
class EvaluationResult(BaseModel):
score: int # 0-10
reasoning: str
recommendation: str
response = client.beta.chat.completions.parse(
model="gpt-4o",
messages=[...],
response_format=EvaluationResult,
)
result = response.choices[0].message.parsed
这能消除 JSON 解析错误，让整个管道端到端类型安全。
模式五：少样本示例保持一致性
需要输出风格保持一致时，3-5 个示例的效果远胜于详细说明：
以下是分析格式的示例：
输入："营收增长 15%，但流失率上升至 8%"
输出：{"sentiment": "mixed", "key_risk": "用户留存", "priority": "high"}
输入："NPS 从 32 提升至 45，扩展营收增长 22%"
输出：{"sentiment": "positive", "key_risk": "无", "priority": "low"}
现在分析这个输入：{user_input}
模式六：防御性提示
始终明确边界情况该怎么处理：
- 输入模糊时怎么做
- 超出范围的请求怎么处理
- 信息不足时怎么处理
- 无法完成任务时返回什么
如果你不指定，模型会自由发挥——而生产环境中的自由发挥是危险的。
测试你的提示词
没有测试的 Prompt 工程是在瞎蒙。我为每个提示词维护一个包含 20-30 个输入的测试集，涵盖：
- 正常路径（直接输入）
- 边界情况（异常或模糊输入）
- 对抗输入（设计用来干扰模型的输入）
- 回归用例（曾经失败的输入）
每次重大提示词变更都跑一遍评估。用 LLM-as-Judge 评估质量指标，用精确匹配校验结构。
模型已经非常强大。你的工作是给它们正确的结构，让这种能力可靠地释放。