Prompt Engineering

Prompt Engineering 是 AI 工程师的核心技能。好的 Prompt 能让输出质量提升数倍，并降低迭代成本。

1) Prompt 基本结构（推荐模板）

[角色/风格] 你是一名...
[任务] 帮我完成...
[输入约束] 输入格式/语言/领域
[输出格式] JSON/Markdown/表格；字段定义
[边界] 不知道时要说不知道；不要编造引用
[示例] 可选 few-shot 示例

这个模板看着简单，但在实际项目中能解决 80% 的 prompt 质量问题。最常见的错误是只写了任务，没有给输出格式——结果 AI 每次返回的格式都不一样，下游代码根本没法解析。

下面这张对比图展示了同一任务（从客户评价中提取情感和关键词），模糊 prompt 和结构化 prompt 的输出差异：

2) 常见模式与示例

• 指令与重写：改写成正式语气；压缩为 100 字摘要。
• 分类：多标签/单标签，给定标签集合，要求只输出标签。
• 信息提取：从文本抽取实体，定义字段名与类型。
• 问答：基于上下文回答，未知时回复"未知"。
• 转换：格式/语言转换（JSON ↔ Markdown）。
• 代码：解释、改写、生成单元测试。

3) 示例驱动：Few-shot / CoT / ToT

掌握了基本结构之后，下一步是学会用示例来「教」模型。不同的示例策略适用于不同场景：

• Few-shot：提供 2-5 个示例，输入输出格式完全一致，避免多风格。生产环境中我们发现，3 个高质量示例比 10 个低质量的效果好得多——关键是示例之间的一致性。
• Chain of Thought (CoT)：要求"逐步推理"，适合复杂计算/逻辑；可限制步骤数。踩过的坑：如果不限制步骤数，模型有时会展开 20 步推理，token 消耗暴增但结果并没有更好。
• Tree of Thoughts (ToT)：让模型给出多个方案再选择，适合创意/规划；可设置评分标准。
• Self-critique：让模型先给答案，再用 checklist 自评并修正。在代码生成场景特别有效——让模型自己检查有没有 edge case 没处理。
• ReAct：让模型"思考-行动-观察"循环，用于工具调用/搜索。

4) 角色与风格控制

有了示例策略，接下来要学会控制模型的「人格」和边界：

• 明确角色（架构师/律师/编辑），限定语气（简洁/正式/友好）。
• 硬性边界：不得编造、不输出敏感内容，语言/长度限制。
• 输出格式：指定"仅输出 JSON"，并给出示例。

生产环境中常见的问题是：给了角色但没有给边界，结果模型遇到不会的问题就开始编造。加一句"如果不确定，回复'我不确定，建议人工确认'"就能解决。

5) 结构化输出与校验

这一部分对 AI 工程师来说特别重要——因为你的 prompt 输出通常要被代码解析，而不是给人看的。

• JSON Mode：OpenAI response_format={"type":"json_object"}；或在 prompt 中示例。
• 校验：用 JSON schema 校验，失败时让模型"只修复结构重试"。在生产中我们会设置最多 3 次重试——如果 3 次都不过，说明 prompt 本身有问题，需要调整而不是继续重试。
• 表格：指定表头与字段含义，避免自由发挥。

6) 约束与防幻觉

结构化输出解决了格式问题，但模型「编造事实」的问题需要单独处理：

• 资料边界：说明"仅根据提供的上下文回答"，没找到则返回"未在上下文中找到"。
• 引用要求：回答时附上片段编号/行号，便于追溯。
• 事实检查：要求模型先列出依据，再给结论。
• 负面指令：写明"不回答与任务无关的问题""不虚构引用"。

实际测试中发现：「仅根据上下文回答」这一句指令就能把幻觉率降低 60% 以上。但如果上下文太长（超过 50K tokens），模型的注意力会分散，这时候需要配合检索来缩短上下文。

7) 迭代与调试技巧

写好 prompt 只是开始，调到好用才是真功夫。

• 缩小步长：先让模型给"思路/步骤"，再让它写最终结果。
• A/B Prompt：对比两个提示的输出质量与 tokens 成本，选择更优。
• 提示分层：system 负责原则；user 负责任务；assistant 负责历史。
• 观测：记录 prompt、模型、温度、tokens，便于回放与优化。
• 日志：保存 prompt 版本号与样本输出截图，方便回溯。

踩过的坑：很多人改 prompt 不做版本管理，改了半天发现之前那版其实更好，但已经找不回来了。建议用 Git 管理 prompt 文件，每次改动写清楚改了什么、为什么改。

8) 代码与推理专用提示

从通用场景切换到代码场景，有几个特殊注意点：

• 先验条件：告知语言/版本/依赖/平台。不写这些，模型可能给你一个 Python 2 的语法或者用了你没装的库。
• 生成测试：要求先给测试用例，再给实现。这个顺序很重要——先写测试能帮模型更准确地理解你的需求。
• 调试：提供报错日志，要求模型"复现步骤 + 猜测原因 + 直接给补丁"。
• 安全网：限制修改范围（例如"仅修改函数体，不要改其他代码"）。

9) 多轮对话与状态

单轮 prompt 搞定之后，多轮对话是下一个挑战：

• 关键约束放在 system，每轮都带；history 中只保留必要信息，避免膨胀。
• 重设指令：当话题切换时重新声明角色与输出格式。
• 检查粘性：偶尔让模型复述当前约束，避免漂移。在长对话（20+ 轮）中，模型很容易「忘记」最初的系统指令——定期重申能有效缓解。
• 线程标识：用 conversation_id 或 traceId 关联日志，便于复现。

10) 质量评估

怎么判断你的 prompt 够不够好？光靠手动看几个输出是不够的。

• 手工评估维度：相关性、完整性、事实性、格式、简洁度。
• 自动化：准备一批样本，写检查脚本验证是否满足格式/关键词/引用。
• 负面样例：测试"应该拒绝"的场景，防止越权输出。这一步很多人忽略了，结果上线后被用户用各种方式绕过限制。
• 示例检查脚本（伪代码）：

const cases = loadCases(); // {input, expectedKeys, allowCitations}
for (const c of cases) {
	const out = await callModel(c.input);
	assert(hasKeys(out, c.expectedKeys));
	if (c.allowCitations) assert(hasCitations(out));
	assert(!containsBanned(out));
}

11) 常见坑与规避

这些是我们在教学和实际项目中反复见到的问题：

• 提示过长：精炼上下文，避免触顶；必要时用摘要或检索。见过有人把整个文档丢进去，结果 token 费用比预期高 10 倍。
• 含糊需求：补充输入格式与边界条件。"帮我写个总结"和"帮我把这段 500 字的会议记录压缩到 100 字以内，保留关键决策和行动项"的输出质量天差地别。
• 自由输出：必须指定格式，否则易跑题。
• 语种混乱：明确"只用中文/英文"。多语言 prompt 如果不指定，模型可能中英混杂。

12) 实践练习

学完理论，动手试试。这三个练习覆盖了最常用的场景：

1. 写一个"需求澄清 Prompt"：输入模糊需求，输出澄清问题列表（JSON）。
2. 写一个"代码审查 Prompt"：输入代码+报错，输出复现步骤、原因推测、补丁建议。
3. 写一个"引用型问答 Prompt"：给上下文（带编号），回答时需标注引用编号。

建议每个练习至少跑 3 次，看看输出是否一致——如果不一致，说明 prompt 的约束还不够明确，需要继续迭代。