001. Prompt工程全景：从提示词到系统工程

前言

在动手写第一条提示词之前，先问一个问题：当一个提示词在 A 模型上表现很好，换到 B 模型或提高 temperature 后输出明显变差，这到底是“词没写对”，还是我们缺少一套可复用的工程方法？

本专栏的第一篇不着急讲具体模板，而是先建立全景：Prompt 工程不是单一话术，而是围绕输入侧展开的系统化设计、优化、评估与治理。理解了这一点，后面学习 few-shot、CoT、结构化输出、RAG 等技巧时，才不会被零散技巧带走节奏，也不会把“改一句话”误当成完整方案。

文章目录

• • 一、从一段“时灵时不灵”的提示词说起
  • 二、Prompt 工程的系统定义：设计、优化、评估与治理
  • 三、实战：一个客服问答任务的两版提示词
  • 四、验证：如何衡量提示改进，而不靠感觉
  • 五、常见误区：话术化与忽视评估
  • 六、本专栏的结构地图
  • 总结
  • 参考资料

一、从一段“时灵时不灵”的提示词说起

很多团队在接入大模型时都会遇到类似现象：

• 同一个提示词，在演示环境输出很好，上线后换一批数据就出现格式散乱；
• 增加一句“请专业一点”，有时有效，有时反而让输出更啰嗦；
• 换一个模型版本，原本精心调整的提示词几乎不再适用；
• 某次输出非常理想，但当你想复现时，模型却给出不同甚至矛盾的结果。

这些问题的根源在于，大语言模型是基于 Token 和条件概率生成内容的。提示词本质上是任务的重表述：它改变了模型在给定上下文条件下对下一个 Token 的条件概率分布，但它并不像一个确定性的函数那样，只要输入不变就必然给出唯一输出。

Pre-train, Prompt, and Predict 这篇系统性综述早就指出，提示方法需要把任务重新表述为模板，并匹配相应的答案映射，这种“重表述”本身就存在设计空间与不确定性。

因此，提示词的质量不能只靠“读起来像好指令”来判断，而要看它是否能在目标任务、目标模型和采样参数下稳定地产出可接受的输出。这正是 Prompt 工程要解决的问题。

二、Prompt 工程的系统定义：设计、优化、评估与治理

如果只把 Prompt 工程理解为“如何写出更好的提示词”，就会漏掉大量工程实践。从系统视角看，Prompt 工程至少覆盖四个方面：

The Prompt Report 是目前较系统的提示技术综述之一，梳理了 58 种文本提示技术，并给出了术语分类体系。它说明了一件事：提示技术不是零散的经验技巧，而是一个可以归类、比较和研究的体系。这为“Prompt 工程是一门系统方法论”提供了顶层参照。

厂商官方文档也早已不是“给几条建议”的写法。

OpenAI 的官方指南把提示工程归纳为六类策略：写清晰指令、提供参考文本、拆分复杂任务、给模型思考时间、使用外部工具、系统化测试。可以看到，最后一条“系统化测试”已经把评估放进提示工程的闭环里，而不是把提示当一次性文本。

Anthropic 的总览页则强调，提示工程是一个迭代过程：从明确目标开始，逐步加入结构、示例和约束，再通过评估驱动修改。

Google Cloud 的提示设计入门同样覆盖任务描述、输入输出格式、模型选择与评测流程，形成一个可操作的工程化路径。

这里有一个重要区分：提示词技巧关注“怎么把一句话写得更像会成功的样子”；提示系统工程关注“如何设计、验证、复用和监控提示资产”。下表可以帮助建立边界感：

把二者混为一谈，是实践中最大的认知偏差之一。提示词技巧是系统中的一个环节，而不是全部。

三、实战：一个客服问答任务的两版提示词

为了看清差异，我们用一个简单的客服问答任务：用户问“我买的东西可以退货吗？”模型需要依据给定政策回答，不能凭空编造。

⚠️ 重要提示：以下代码示例未实际运行，输出仅为示意。请读者自行设置 OPENAI_API_KEY、替换为目标模型并运行验证，实际结果会因模型版本、采样参数和上下文而不同。

版本一：原始一句话提示词

from openai import OpenAI

client = OpenAI() # 读取环境变量 OPENAI_API_KEY

def ask_with_prompt(prompt: str, temperature: float = 0.7) –> str:
resp = client.chat.completions.create(
model="gpt-4o-mini", # 可按需替换为目标模型
messages=[{"role": "user", "content": prompt}],
temperature=temperature,
max_tokens=150,
)
return resp.choices[0].message.content.strip()

raw_prompt = "用户问：我买的东西可以退货吗？请回答。"
raw_answer = ask_with_prompt(raw_prompt)
print("原始提示输出：\\n", raw_answer)

预期输出（示意）

原始提示输出：
当然可以！我们支持退货，但具体要看商品类型和购买时间。建议你联系客服确认。

这个输出看起来没问题，但存在明显风险：模型在没有任何政策依据的情况下，也可能会“补充”出错误规则，例如“生鲜可以退货”“所有商品都支持无理由退货”等。而且语气和长度不稳定，难以直接嵌入工单系统。

版本二：结构化提示词

structured_system = (
"你是电商客服助手。你只能依据给定的退货政策作答，"
"不得编造政策；如果政策未覆盖，回答：'我不确定，建议查看官方退货页面。'"
)
policy_text = (
"退货政策：自签收之日起7日内可无理由退货；"
"商品需未使用、包装完整；生鲜和定制商品不支持无理由退货。"
)
structured_user = f"""
请根据以下政策回答用户问题。

【政策】
{policy_text}

【用户问题】
我买的东西可以退货吗？

【输出要求】
1. 简体中文回答；
2. 不超过80字；
3. 先给结论，再补充条件；
4. 不要使用“作为AI”等多余开头。
"""

resp = client.chat.completions.create(
model="gpt-4o-mini", # 与原始提示使用同一模型
messages=[
{"role": "system", "content": structured_system},
{"role": "user", "content": structured_user},
],
temperature=0.2,
max_tokens=120,
)
structured_answer = resp.choices[0].message.content.strip()
print("结构化提示输出：\\n", structured_answer)

预期输出（示意）

结构化提示输出：
可以退货，但需同时满足：签收后7天内、商品未使用且包装完整。
生鲜和定制商品不支持。

结构化版本并没有引入任何“高深技巧”，只是做了四件事：给定角色边界、注入政策上下文、明确输出格式、降低随机性。但这四件事已经构成了一个可复用的提示资产：政策文本可以替换，输出要求可以版本管理，系统提示词可以被多个任务共享。

四、验证：如何衡量提示改进，而不靠感觉

前面的对比如果只停留在“看起来更好了”，就无法支撑工程决策。尤其是当两个提示词在不同采样次数下各有胜负时，我们需要一个可重复的评估方法。

下面给出一个简化版的稳定性评估思路：对同一问题、同一提示，在固定 temperature 下多次采样，观察长度极差和唯一答案数量。这里的数字均为示意，实际结果受模型、采样参数和具体问题影响。

def evaluate_stability(answers: list[str]) –> dict:
"""粗略评估多轮输出稳定性。

适用于同一问题、同一提示、多次采样。
更严格场景应使用评测集与标注分数，而非只看文本重复率。
"""
lengths = [len(a) for a in answers]
unique_answers = set(a.strip() for a in answers)
return {
"length_range": max(lengths) – min(lengths),
"unique_count": len(unique_answers),
"total_runs": len(answers),
}

# 假设已获得原始提示和结构化提示在 5 次采样下的答案：
raw_answers = [
"当然可以！我们的退货政策是……",
"一般来说7天内可以退，但具体看商品。",
"可以退货，如果你不满意。",
"有7天无理由退货，但生鲜不行。",
"建议联系客服确认。",
]

structured_answers = [
"可以退货，需满足：签收后7天内、商品未使用且包装完整。",
"可以退货，需满足：签收后7天内、商品未使用且包装完整。",
"可以退货，需满足：签收后7天内、商品未使用且包装完整。",
"可以退货，需满足：签收后7天内、商品未使用且包装完整。",
"可以退货，需满足：签收后7天内、商品未使用且包装完整。",
]

print("原始提示稳定性：", evaluate_stability(raw_answers))
print("结构化提示稳定性：", evaluate_stability(structured_answers))

下方预期输出与上方答案列表的实际统计结果一致；实际运行时应以真实采样结果为准。

预期输出（示意）

原始提示稳定性： {'length_range': 9, 'unique_count': 5, 'total_runs': 5}
结构化提示稳定性： {'length_range': 0, 'unique_count': 1, 'total_runs': 5}

这个比较说明：结构化提示在限制输出空间后，提供了更高的可预测性。

需要注意的是，“唯一答案数量”很低并不总是好事，它可能意味着输出过于刻板；但在客服政策问答这类任务中，确定性通常比多样性更重要。真实项目中应增加自动评测指标和人工抽检，并把提示版本、模型版本、采样参数一起纳入回归记录。

五、常见误区：话术化与忽视评估

初学 Prompt 工程时，最容易出现的几种误区如下：

误区一：把 Prompt 工程等同于“会写话术”

“请专业一点”“请仔细思考”“请给出高质量答案”这类泛泛指令，本质上是在把不确定的期望压给模型。这类词既不能明确规则，也无法被稳定评估。Prompt 工程要做的不是堆叠礼貌用语，而是设计清晰、可验证、可复用的输入结构。

误区二：忽视评估，只靠一两个例子下结论

同一提示词在 10 个测试例子上表现好，可能只是巧合。没有评测集、没有回归流程，任何“优化”都可能只是把提示词调得更适合某一条样本。OpenAI 官方指南也把“系统化测试”列为六大策略之一，说明评估不是可选项，而是提示工程的基础设施。

误区三：忽视上下文与消息结构

很多输出不稳定并不是某句话写得不对，而是系统提示、历史消息、工具返回内容之间存在边界不清的问题。下一节会展开说明，提示词只是输入侧的一部分，用户、助手、系统角色的使用方式同样会改变模型行为。

误区四：忽视安全与治理

提示工程还必须考虑攻击面。OWASP 的 LLM 应用 Top 10 中，提示注入（LLM01）位居首位。也就是说，如果只追求输出效果，而忽略输入侧对抗风险，系统很容易被诱导执行非预期行为。NIST《AI 600-1》也强调生成式 AI 的风险管理需要覆盖整个生命周期，提示工程的评估、监控与治理不能脱离这个框架。

六、本专栏的结构地图

为了让后续学习不散乱，本专栏按“认知 → 技巧 → 系统化 → 治理 → 进阶 → 实战”展开。下面这张图就是整体路线：

各模块的主要目标如下：

这张路线图也对应了社区广泛使用的 Prompt Engineering Guide 的技术索引思路：从最基础的指令设计开始，延伸到多步推理、工具调用和自动化优化。区别在于，本专栏更强调“验证”与“工程落地”，而不是单纯罗列技巧。

总结

本文建立了 Prompt 工程的整体认知：它不是一组散装话术，而是一套围绕输入侧展开的系统方法，覆盖设计、优化、评估与治理。同一个客服问答任务，原始一句话提示与结构化提示在输出稳定性上会有明显差异；这种差异需要通过固定评测集、固定采样参数和回归流程来验证，而不是靠感觉。

从下一篇开始，我们将深入 LLM 的生成机制，理解 Token、概率以及提示为什么能够影响输出。理解了那个底层过程之后，再回来讨论提示消息结构、官方策略和具体技巧，就不会只停留在“这样写好像更有效”的层面，而能逐步形成可解释、可验证、可复用的工程判断。

参考资料