Prompt Engineering 最佳实践：从入门到写出能用的 Prompt
一、什么是 Prompt Engineering
Prompt Engineering（提示工程） 是设计与优化输入给大语言模型（LLM）的提示词，以引导模型生成高质量、准确、符合预期的输出的系统性方法。
核心公式：
输出质量 = 模型能力 × Prompt 质量
模型能力是天花板，Prompt 质量决定了你能多接近这个天花板。一个好的 Prompt 可以让 GPT-3.5 的输出碾压一个随便写的 GPT-4 Prompt。
二、Prompt 的基本结构
一个完整的 Prompt 由以下层次构成（由浅入深）：
2.1 最小可行 Prompt
请解释什么是闭包。
这能工作，但输出不可控。对简单问题够用，复杂场景需要加料。
2.2 标准 Prompt 四要素
[角色] 你是一位 Python 高级面试官。[任务] 用一句话解释什么是闭包，然后用一个代码示例说明。[约束] 代码不超过 10 行，不要使用外部库。[格式] 先用粗体写定义，再附代码块。
| 要素 | 作用 | 示例 |
|---|---|---|
| 角色 | 框定模型的"人设"和知识域 | 你是一个资深后端工程师 |
| 任务 | 明确要做什么 | 写一个用户注册接口 |
| 约束 | 限定输出的边界 | 只用标准库，不超过 50 行 |
| 格式 | 指定输出的形态 | 用 Markdown 表格列出 |
2.3 高级扩展要素
[背景] 我们公司正在从 REST 迁移到 GraphQL，有一个 500 万用户的电商平台。[受众] 写给对 GraphQL 有基础了解的团队技术负责人看。[示例] 类似这种格式：[附上一个你满意的输出示例][负面约束] 不要使用过时的语法，不要提 Apollo 已被废弃的 API。[语调] 专业但不死板，允许适度的技术幽默。
三、核心技巧
3.1 角色设定：给模型一个"人设"
❌ 解释量子计算✅ 你是一位理论物理学教授，向有编程背景但无物理基础的工程师解释量子计算的基本原理。 请用"比特 vs 量子比特"作为切入点，避免数学公式，多用类比。
效果：模型会调取其训练数据中"物理学教授 → 工程师"的语料分布，回答更精准。
最佳实践：角色要具体到领域 + 受众。不要只说"你是一个专家"，要说"你是一个有 10 年经验的 React 性能优化专家"。
3.2 思维链（Chain-of-Thought, CoT）
要求模型展示推理过程，而非直接给结论。
❌ 这个 SQL 查询有性能问题吗？ SELECT * FROM orders o JOIN users u ON o.user_id = u.id WHERE YEAR(o.created_at) = 2025✅ 这个 SQL 查询存在性能问题吗？请按以下步骤分析： 1. 先解释查询做了什么 2. 指出哪些地方可能导致索引失效 3. 给出优化后的 SQL 4. 说明优化前后的索引使用差异
核心原理：模型每生成一个 token 都基于前文。强制它先"想"再"答"，思维链中的中间推理会提高最终答案的正确率。数学题、逻辑推理、代码 review 场景提升显著。
3.3 少样本提示（Few-shot Prompting）
在 Prompt 中提供 2-5 个期望的输入→输出对。
请将以下用户反馈进行分类：功能需求 / Bug 报告 / 体验建议。输入："登录按钮太小了，经常误触到旁边广告"输出：体验建议输入："订单支付成功但状态还是未付款"输出：Bug 报告输入："希望增加批量导出 CSV 功能"输出：功能需求现在请分类："图片上传后一直转圈，半小时没反应"输出：
关键：示例的质量远重于数量。2 个精心挑选的示例常常优于 10 个随便写的。
3.4 结构化输出控制
直接告诉模型输出格式，必要时给模板。
请用以下 JSON 格式输出（不要包含其他任何文本）：{ "summary": "<一句话总结>", "sentiment": "positive|neutral|negative", "keywords": ["关键词1", "关键词2", "关键词3"], "score": <1-10 整数>}分析文本："今天快递送到了但包装已经裂开，里面的书折了角，很失望。"
进阶技巧：让模型自己生成 Schema 再校验。
在输出 JSON 前，先生成 JSON Schema 描述你的输出结构，然后按 Schema 生成数据。
3.5 分步引导（Prompt Chaining）
复杂任务拆成多轮对话，而非一个巨型 Prompt。
第 1 步：根据这个需求文档，列出所有需要开发的 API 接口第 2 步：针对第 3 号接口，写出完整的 OpenAPI 3.0 规范第 3 步：基于以上规范，生成 Express.js 路由代码第 4 步：为上一轮的代码写集成测试
为什么有效：单一 Prompt 越长，模型注意力越分散。分步可以每轮聚焦一个小目标，且上一轮的正确输出作为下一轮的可靠上下文。
3.6 负面约束
显式告诉模型不要做什么，比只说要做什么更有效。
❌ 写一篇 React 入门教程✅ 写一篇 React 入门教程。注意： - 不要使用 Class Component（只用函数组件 + Hooks） - 不要使用 create-react-app（用 Vite） - 不要引入 Redux（状态管理用 useState 和 useContext） - 不要用 React 17 及以下的 API
3.7 要求模型反思（Self-Critique / Self-Refine）
请完成以下任务后，自己检查输出中是否存在以下问题：1. 是否有事实错误2. 是否有逻辑矛盾3. 是否有遗漏的边界情况4. 代码是否能在最新版 Node.js 上运行如果发现问题，请直接在原输出中修正，不要额外说明。
或者更简洁：
写完后，自己 review 一遍，修正任何你发现的问题，直接给我最终版本。
3.8 分贝调节：用语气词控制深度
这是一个常被忽视但极有效的技巧——用 concise/detailed/verbose 等指令调出精准深度。
用一句话解释递归。（短）用一个例子解释递归。（中）详细解释递归原理、栈调用过程，附 3 个不同语言的代码示例。（长）
更精细的控制：
请用以下三个深度分别解释"加密"和"哈希"的区别：- ELI5 级（像给 5 岁小孩解释）- 开发者入门级- 密码学工程师级
四、场景化 Prompt 模板
4.1 代码审查（Code Review）
你是资深 [语言] reviewer。审查以下代码，输出一个报告：## 评审项（逐项打分 1-5 并说明理由）- 逻辑正确性- 安全性（尤其是注入、越权）- 性能（算法复杂度、N+1 查询）- 可读性（命名、注释、结构）- 边界处理（空值、超时、并发）## 输出格式| 维度 | 评分 | 问题描述 | 改进建议 |最后总结一个"最值得改进的 3 个点"。代码：[粘贴代码]
4.2 技术文档生成
你是 [项目名] 的维护者。请为以下函数/接口编写文档：内容要求：- 一句话概述- 参数列表（名称、类型、是否必填、说明）- 返回值（类型、说明）- 使用示例（至少 2 个）- 常见错误（至少 1 个反面示例）- 相关接口的交叉引用不要写"注意"和"提示"这种套话，直接用事实陈述。待文档化的代码：[粘贴代码]
4.3 Debug 助手
你是调试专家。下面是一个 Bug 报告，请按以下步骤分析：1. 复述你对问题的理解（确认你没理解错）2. 列出所有可能的原因（按概率排序）3. 对每个原因给出验证方法（具体的命令或测试步骤）4. 给出最可能原因的修复代码（diff 格式）Bug 描述：[描述]错误日志：[粘贴日志]相关代码：[粘贴代码]
4.4 SQL 优化
你是 DBA 优化专家。分析以下 SQL 并提供优化方案。输出内容：1. 当前执行计划分析（走什么索引、扫描行数预估）2. 瓶颈定位（一句话指出根源）3. 优化后的 SQL4. 建议添加的索引（给出 DDL 语句）5. 预期性能提升（对比优化前后的估算）数据库：MySQL 8.0，表数据量约 500 万行SQL：[粘贴 SQL]
4.5 从需求到代码
你是全栈工程师。基于以下需求，生成完整实现方案。输出步骤：1. 技术选型（框架、库，各附一句话理由）2. 数据库表结构（DDL + 注释）3. API 接口列表（Method、Path、Request/Response 示例）4. 核心逻辑伪代码5. 目录结构建议6. 潜在风险点（性能瓶颈、安全漏洞、扩展难点）需求：[粘贴需求文档]
五、常见错误与纠正
| 错误 | 问题 | 纠正 |
|---|---|---|
| “帮我优化这段代码” | 太模糊，模型不知道优化目标 | “优化执行速度，可以牺牲少量可读性” |
| “写一个登录功能” | 缺少安全和框架上下文 | “用 Express + JWT + bcrypt，含防暴力破解” |
| Prompt 太长（>2000 字） | 模型注意力分散，关键信息被稀释 | 拆成链式多轮或精简到核心指令 |
| 用反问句 | 模型可能回答"是/否"而非展开 | “请详细分析并列出三点原因” |
| 在一个 Prompt 里换了好几个话题 | 模型前后发散，输出混乱 | 一个 Prompt 一个核心任务 |
| 给模型选择题 | 模型可能都选或都拒绝 | 直接要求最可行方案，有争议时并列对比 |
| “不要用 A 方案” | 模型过度关注 A，不经意间用了 A 的变体 | 不仅要禁止 A，还要给出替代 B 的方向 |
六、系统化优化 Prompt 的方法
6.1 迭代四步法
1. 写出初版 Prompt → 跑一次 → 看输出2. 标注不满意的点 → 在 Prompt 里加约束 → 再跑3. 重复 3-5 次直到稳定4. 拿 3 个不同输入测试 → 确定鲁棒性
6.2 A/B 测试
对同一个任务写 A、B 两个 Prompt，拿 5-10 组测试数据对比输出，按以下维度打分（1-5）：
- 准确性：信息是否正确
- 完整性：是否覆盖所有要求
- 格式符合度：是否按规定格式输出
- 简洁度：是否有多余废话
- 一致性：多次运行结果是否稳定
6.3 元 Prompt：让模型帮你写 Prompt
我想让 AI 帮我 [做某件事]。请帮我设计一个最优的 Prompt，包含角色、任务、约束、输出格式。你自己先评估可能踩的坑，然后给出最终版本。另外，请解释你设计的这个 Prompt 中，每个部分的作用分别是什么。
七、进阶话题
7.1 System Prompt vs User Prompt
System: 你是一个严格遵循 RESTful 规范的 API 架构师。回答始终包括： - 资源命名（名词复数） - HTTP 方法语义 - 状态码选择理由 - HATEOAS 链接结构User: 设计一个博客系统的 API。
原则：System Prompt 放持久性约束（角色、规则、风格），User Prompt 放每次不同的任务。不要在 User Prompt 里重复 System Prompt 的内容。
7.2 Token 预算管理
- 输入 token 越多，输出质量在达到某拐点后反而下降（注意力稀释）
- 输出 token 留够，否则模型会仓促收尾
- 经验法则：输入控制在 500-1500 token 区间效果最稳定
7.3 温度与创造力控制
温度 0：适合数学计算、代码生成、法律/医学咨询（需要确定性）温度 0.3-0.5：适合技术文档、分析报告（稍有变化但不离谱）温度 0.7-0.9：适合头脑风暴、文案创意、故事写作（需要多样性）温度 1.0+：适合探索性实验（可能出神作也可能胡言乱语）
八、Prompt 模板库速查
# 快速生成 → "用 [语言] 写一个 [功能]，只输出代码不要解释"# 解释概念 → "像给 [受众] 解释 [概念]，用类比，不超过 150 字"# 翻译代码 → "把这段 [源语言] 代码翻译为 [目标语言]，保持逻辑完全相同"# 总结摘要 → "用三个要点总结以下内容，每个不超过 15 字"# 对比分析 → "对比 A 和 B：各自优劣、适用场景、迁移成本，用表格呈现"# 重构建议 → "不改动行为的前提下优化此代码：可读性、性能、安全性各给一个建议"# 命名建议 → "这段代码里 [变量/函数] 的命名有什么问题？给出 3 个更好的名字"# 正则编写 → "编写正则匹配 [模式]，逐段解释你的正则做了什么"# 补充测试 → "为以下函数写测试：正常路径、边界值、异常输入、性能基准"# 错误解释 → "解释这个错误信息：[粘贴]，告诉我是什么导致的以及怎么修"
九、核心口诀
角色要具体，任务要单一。
先让模型想，再让模型答。
告诉它不要什么，比只告诉它要什么更强。
复杂任务拆开做，简单任务别啰嗦。
一个好 Prompt，是迭代出来的，不是想出来的。
—— 没有银弹，但有方法。Prompt Engineering 的本质是：用结构化的方式，与一个概率性的系统进行确定性沟通。
