Prompt Engineering 不是「魔法咒语」，而是用结构化语言约束模型行为的系统工程。在生产环境中，一个设计良好的 Prompt 模板可以将输出格式的错误率从 30% 降到 3% 以下。本文总结我们在多个 LLM 项目中验证过的实用技巧。
结构化 Prompt 框架
推荐使用「角色 + 任务 + 约束 + 输出格式」四段式结构：
## 角色
你是一位资深 Java 代码审查专家。
## 任务
审查以下 Pull Request 的代码变更，指出潜在 bug 和性能问题。
## 约束
- 只关注 diff 中变更的行
- 不要建议改变公共 API 签名
- 如果代码质量良好，明确说「未发现明显问题」
## 输出格式
以 JSON 返回，结构如下：
{
"issues": [{"severity": "high|medium|low", "file": "...", "line": 0, "message": "..."}],
"summary": "一句话总结"
}Few-shot：示例胜过千言
对于格式要求严格的任务，在 Prompt 中提供 2–3 个输入输出示例，效果远好于纯文字描述。注意：
- 示例应覆盖边界情况（空输入、异常输入、正常输入）
- 示例的输出必须是你期望的「标准答案」
- 示例越多，token 消耗越大——在质量和成本间取平衡
Chain-of-Thought 的正确用法
CoT（思维链）让模型在给出最终答案前先展示推理过程，显著提升复杂推理任务的准确率。但生产环境中建议：
- 要求模型在
<thinking>标签内推理，最终答案放在<answer>标签内 - 只向用户展示
<answer>部分，隐藏推理过程 - 对简单分类任务不要使用 CoT，徒增延迟和成本
输出约束技术
当需要机器可解析的输出时，按可靠性从高到低排列：
- Structured Output / JSON Mode：API 层面强制 JSON schema
- Function Calling：让模型调用预定义函数，参数即结构化输出
- Prompt 内嵌 Schema：在 Prompt 中写明 JSON 结构 + 示例
- 后处理修复：用 json-repair 库兜底解析失败的输出
Prompt 版本管理
把 Prompt 当作代码来管理：
- 每个 Prompt 模板有版本号和变更日志
- 用 golden dataset（50–200 条标注样本）做回归测试
- A/B 测试新旧 Prompt，对比准确率、延迟、token 消耗
- 避免在 Prompt 中硬编码会变化的数据（日期、用户名），用变量注入
Prompt 是应用逻辑的一部分，不应散落在代码各处——集中管理、可测试、可回滚。
常见陷阱
- 过度约束：规则太多导致模型「不敢回答」，适当留白
- 语言混用：中英文指令混写会降低遵循度，统一用一种语言
- 忽略 token 窗口：长 Few-shot 示例 + 长上下文会挤占输出空间
- 没有 fallback：解析失败时应有默认回复，而非直接报错
小结
高质量的 Prompt 工程 = 清晰的角色定义 + 精确的输出约束 + 可量化的评测体系。投入时间建立 Prompt 测试流水线，回报远高于反复手动调措辞。