提示工程实战：用结构化 Prompt 让 LLM 输出更可控
提示工程实战：用结构化 Prompt 让 LLM 输出更可控
提示工程不是「换个说法试试」——它是一组可复用的模式。本文讲四种核心技法：角色定义、few-shot 示例、链式推理、输出格式约束。每种附可复制的 Prompt 骨架，帮你从「碰运气调 Prompt」转向「按模式构造 Prompt」。
30 秒版本
角色定义给模型一个立场，few-shot 给模型几个范例让它学会模式，CoT 让模型先想再答，输出格式约束让结果可以直接解析。四者组合使用效果最好。
技法一：角色定义
角色定义影响模型的知识侧重、语气和回答边界。它不改变模型的能力，但改变模型「以什么身份回答」。
# 基础版
你是一个技术文档编写助手。
# 增强版（加约束）
你是一个技术文档编写助手。
- 你的目标读者是有 3 年经验的开发者
- 避免使用未定义的缩写
- 每个概念第一次出现时给一句解释
- 代码示例使用 TypeScript
角色定义的原则
增强版给了模型 4 条可执行的约束（读者是谁、避免什么、如何解释、用什么语言），比「你是助手」具体得多。角色定义越具体，输出越可预测——但不要塞满每次都用不到的规则，那会浪费 token。
技法二：Few-shot 示例
Few-shot 在提示词里给模型 2-3 个输入-输出对，让模型学会你的输出模式。
将以下产品描述改写为图像生成提示词。
示例：
输入：一款蓝牙耳机
输出：A sleek wireless earbud floating against a gradient background, studio lighting, product photography
输入：一款咖啡杯
输出：A ceramic coffee cup with steam rising, warm morning light, kitchen counter
现在改写：
输入：一款机械键盘
输出：
Few-shot 的两个原则
① 示例的格式必须与期望输出完全一致（包括标点和大小写）；② 2-3 个示例足够，更多示例会增加 token 但不一定提升效果。示例应覆盖不同类型的输入，而非同一个模式的重复。
技法三：链式推理（CoT）
CoT 让模型在给出答案前先展示推理步骤。这对数学、逻辑、代码审查等复杂任务显著提升准确率。
请一步步推理以下问题，然后给出最终答案。
问题：一个团队有 5 个人，每个人需要完成 3 个任务，每个任务需要 2 小时。
如果团队每天工作 8 小时，需要几天完成所有任务？
CoT 的适用边界
CoT 对数学、逻辑、多步推理显著有效；对事实查询、创意写作、简单分类效果不大——反而可能让模型输出不必要的推理过程。按任务类型决定是否使用。
技法四：输出格式约束
让模型直接输出可解析的格式（JSON、表格、模板），省去解析自由文本的成本。
分析以下代码，按以下 JSON 格式返回结果：
{
"issues": [{"line": <行号>, "description": "<问题描述>", "severity": "<low|medium|high>"}],
"summary": "<一句话总结>"
}
只输出 JSON，不要添加其他文字。
代码：
<在这里粘贴代码>
JSON 输出的两个技巧
① 在提示词末尾加「只输出 JSON，不要添加其他文字」，减少模型前后添加解释文字的概率；② 如果模型仍然输出非 JSON 内容，在代码里加一层「提取 JSON 部分」的预处理（用正则或 JSON.parse try-catch）。
四种技法的组合使用
| 场景 | 角色定义 | Few-shot | CoT | 格式约束 |
|---|---|---|---|---|
| 文档分类 | ✅ 简短 | ✅ 2-3 个示例 | ❌ | ✅ JSON |
| 代码审查 | ✅ 详细 | ❌ | ✅ 逐文件推理 | ✅ JSON |
| 创意写作 | ✅ 详细 | ✅ 1-2 个范例 | ❌ | ❌ 自由 |
| 数学/逻辑 | ❌ 不需要 | ❌ | ✅ 必需 | ✅ 最终答案 |
| 产品描述改写 | ✅ 简短 | ✅ 2-3 个 | ❌ | ❌ 自由文本 |
上线前检查清单
- 用固定评测集（30-50 条）跑通过率，按类别分别统计
- 检查输出格式：JSON 任务解析每一条、统计解析失败率
- 测量 token 消耗：平均和 p95
- 用温度 0 和 0.7 分别测试，部分提示只在低温下稳定
- 测试边缘情况：空输入、超长输入、混合语言、模糊指令
- 记录提示词版本：日期、变更内容、评测分数
- 检查提示注入漏洞：用户内容能否覆盖系统指令
通过以上 7 项检查的 Prompt 才是生产可用的。评测不是一次性的——业务变化、新模型上线、新增任务类型都可能改变最优 Prompt。每月用固定评测集做回归，才能持续保证质量。
常见误区
误区一：提示越长越好。 冗长的系统提示会稀释注意力、增加 token 成本、但不一定改善质量。3-5 条清晰规则优于 10 条含糊指令。
误区二：Few-shot 示例越多越好。 2-3 个覆盖不同模式的示例足够；超过 5 个可能让模型混淆。示例的多样性比数量更重要。
误区三：CoT 对所有任务都有效。 CoT 对数学和逻辑显著提升，但对事实查询和简单分类可能反而增加 token 消耗而不改善答案。
误区四：改了提示词不需要跑评测。 每次修改都应跑固定评测集。改了提示词但没跑评测=改了代码但没跑测试。
FAQ
Few-shot 和 CoT 可以同时用吗？
系统提示应该多长？
温度参数对输出有多大影响？
如何判断 Prompt 是否需要优化？
这些技法对开源模型和 GPT 效果一样吗？
价格在哪里看？
相关阅读
- JSON 结构化输出指南 — 格式约束的深入
- 模型评测方法论 — 用评测集衡量 Prompt 效果
- 上下文工程实战 — 窗口预算管理
- Agent 框架实战 — Agent 中的 Prompt 设计
- 定价 — 云端实时价格