Prompt Engineering 实战：让大模型稳定输出的方法论与 7 个技巧

很多人用大模型效果不好，第一反应是“模型不行”。但换个更强的模型往往也没救——真正的问题是 Prompt 写得太随意：一句“帮我写个总结”，模型只能靠猜，猜出来的东西自然时好时坏。

Prompt Engineering 不是背咒语，它的本质是把你脑子里模糊的需求，变成模型能精确执行的规格说明。这篇先讲清楚模型为什么会“听 Prompt”，再给七个在生产里反复验证过的技巧，最后聊聊评测和常见坑。

一、先理解：模型为什么会照做

大语言模型的核心机制是“根据上下文预测下一个词”。当你在 Prompt 里给出角色、示例、格式要求时，本质上是在构造一段上下文，让“接着这段文字往下写”的最优解恰好就是你想要的答案。

这解释了两个现象：

• 为什么示例比描述管用：你描述“要正式一点”，模型对“正式”的理解和你未必一致；但你给两个范例，模型直接模仿范例的风格和格式，这叫上下文学习（In-Context Learning）；
• 为什么模糊指令会翻车：上下文约束越弱，模型越可能滑向训练语料里的“平均答案”，而不是你的具体需求。

所以好 Prompt 的方向很明确：用上下文把模型的自由度，收窄到“只有正确答案最合理”的程度。

二、技巧 1：给角色，更要给边界

只说“你是一个翻译”是不够的，角色要配约束。把能想到的边界都写全：

你是一名资深技术文档翻译，负责把中文文档翻译成英文。
要求：
- 专业术语（如 Kubernetes、Pod、Sidecar）保留英文原文，不翻译；
- 语气正式、简洁，不要口语化；
- 代码块和命令原样保留，不改动；
- 只输出翻译结果，不要加任何解释或前后缀。

角色设定激活模型相关领域的表达习惯，边界约束则砍掉你不想要的行为。两者配合，输出稳定性立刻上一个台阶。

三、技巧 2：用示例代替描述（Few-Shot）

格式、分类标准这种“描述起来很绕”的要求，给例子最省事：

请将用户评价分类为：正面 / 中性 / 负面。

评价：物流很快，包装也用心，好评！
分类：正面

评价：东西一般吧，没有宣传的那么好。
分类：中性

评价：用了三天就坏了，客服还不理人。
分类：

模型会精准模仿示例的格式、口径甚至边界判断。几个经验：

• 示例要覆盖典型和边界情况，尤其是容易判错的中性、模糊样本；
• 示例的标签分布别极端（全是正面会让模型倾向正面）；
• 示例从 2~5 个起步，多了费 token 还边际递减。

四、技巧 3：让模型先思考再回答

数学、逻辑、多步规划类任务，模型直接给答案容易错。让它先推理：

请先列出解题步骤，再给出最终答案。

这就是思维链（Chain-of-Thought）的朴素用法。它有效的原因是把“一步到位的难判断”拆成了“多步简单判断”，每步模型都能基于前面的正确结论继续。

需要程序解析输出时，别让推理过程污染结果，要求模型把思考放在指定字段：

{ "reasoning": "这里放分析过程", "answer": "这里放最终答案" }

要注意：简单任务（分类、抽取）加思维链反而拖慢、增成本，只在真正需要推理时用。

五、技巧 4：结构化输出，直接给 Schema

要让程序消费模型输出，千万别靠正则去解析一段自由文本。直接规定 JSON 结构：

请以 JSON 格式输出，字段如下：
{
  "intent": "查询订单 | 退款 | 投诉 | 其他",
  "order_id": "订单号，没有则为 null",
  "urgency": "high | medium | low"
}

再配合模型的 JSON Mode / Function Calling（工具调用） 能力，把 Schema 作为参数传进去，成功率能接近 100%。枚举值、必填/可空、嵌套结构都在 Schema 里写死，模型几乎不会跑偏。

六、技巧 5：复杂任务拆成流水线

一个 Prompt 又要总结、又要翻译、又要排版，结果往往每项都打折扣——模型的注意力被多个目标稀释了。拆成流水线，每步一个专门 Prompt：

flowchart LR
    Raw["原文"] --> Sum["① 总结<br/>专用 Prompt"]
    Sum --> Trans["② 翻译<br/>专用 Prompt"]
    Trans --> Fmt["③ 排版/格式化<br/>专用 Prompt"]
    Fmt --> Out["成品"]

单步 Prompt 更短、目标更单一，质量更高；而且每步可独立调试、可重试、可缓存，某步出问题不用整条重来。这正是工作流模式的雏形（详见大模型架构模式篇）。

七、技巧 6：预置“拒绝”策略

模型有“尽量回答”的倾向，遇到不会的也爱硬编。与其事后用关键词过滤，不如在 Prompt 里明确告诉它什么时候该闭嘴：

如果问题与产品售后无关，请回复：“抱歉，这个问题超出了我的服务范围。”
如果资料里没有相关信息，请回答“知识库中未找到”，不要编造政策或流程。

在 RAG 场景这一条尤其关键：给模型一个“体面的退路”，能挡掉大量幻觉。

八、技巧 7：把 Prompt 当代码管理

Prompt 是会持续迭代的生产资产，要享受代码的待遇：

• 进 Git：每次改动有记录、可回滚，别散落在聊天窗口和文档里；
• 建测试集：准备 20~50 条典型输入（含正常、边界、刁难样本）；
• 回归测试：改完 Prompt 跑一遍测试集，对比输出有没有变差；
• 线上灰度：大改动先放一小部分流量，观察指标再全量。

没有评测的 Prompt 调优，等于闭眼改代码。

九、再进一步：从 Prompt 到上下文工程

单个 Prompt 打磨到一定程度，瓶颈往往在“上下文喂得对不对”。几个进阶点：

• 把稳定指令放 system，变动内容放 user，结构清晰也利于缓存；
• 上下文别堆满：RAG 检索回来 8 段、实际相关只有 2 段，无关内容会分散注意力、还费钱；
• 把复杂规则外置成工具：能查数据库、能调函数的，就别让模型凭记忆“背”规则；
• 当某个任务的 Prompt 已经臃肿到难以维护、且需求高度重复稳定时，才考虑微调——微调改的是模型本身，Prompt 改的是当下这次调用，两者别混为一谈。

十、常见反模式

• 指令互相打架：一边说“详细展开”，一边说“控制在 100 字”，模型只能随机妥协；
• 否定式约束太多：“不要啰嗦、不要客套、不要分点……”模型对“不要”的遵循弱于正面指令，尽量说“要什么”；
• 一次塞太多任务：见技巧 5，拆开；
• 只看一次输出就上线：单次成功不代表稳定，必须跑测试集看通过率；
• 迷信长 Prompt：长不等于好，关键信息被埋在废话里反而更糟。

小结

Prompt Engineering 说到底是一门“把模糊需求写成精确规格”的功夫。模型越强，这门功夫越像在做需求分析和接口设计——它不神秘，只是需要你像对待代码一样认真对待每一句话。

本文由 AI 辅助创作，所有内容仅供交流与参考。