你肯定遇到过：想让 AI 输出 JSON，它偏要在 JSON 外面加一行「好的，以下是结果：」。想让 AI 按步骤推理问题，它却直接给了一个错误答案。这篇教程不是入门科普，而是针对已经用过 GPT/Claude 一段时间、想要让输出更稳定可控的进阶指南。
技巧一：Chain-of-Thought（链式思考）
最简单也最有效的技巧。做法是在提示词里加一句：
Let's think step by step.
为什么有用？因为不强制要求推理步骤时，AI 倾向于直接跳到答案（类似人类的直觉反应），容易出错。强制它推理后，准确率大幅提升。
实际案例——不要这样问：
2023 年上市的手机中，电池容量超过 5000mAh 的有多少款？而要这样问：
请先列出 2023 年上市的主要手机型号和电池容量，然后逐个对比筛选出超过 5000mAh 的型号，最后给出总结。这个过程中请展示每一步的思考。更优雅的写法——用标签结构化思考过程：
请按以下格式回答：
<thinking>
一步一步分析问题和约束条件
</thinking>
<reasoning>
基于约束条件逐步推理
</reasoning>
<answer>
给出最终答案
</answer>这个标签法的好处是：你可以让前端只展示 <answer> 部分，隐藏思考过程。或者反过来，在调试阶段看 <thinking> 找问题。
技巧二：Few-Shot Prompting（少样本提示）
不给例子 AI 就瞎猜，给 2-3 个例子它就老实了。这是最被低估的技巧。
错误做法：
把以下用户反馈分类为正面/负面/中性。正确做法——给 3 个标注好的例子：
请把用户反馈分类为：正面 / 负面 / 中性。
示例：
「用了三个月，电池续航还是很强」→ 正面
「客服态度差，等了一小时没人理」→ 负面
「还行吧，凑合着用」→ 中性
现在请分类以下反馈：
「快递比预期的快，包装也很用心」AI 看了三个例子后再分类，准确率从约 60% 提升到 95%+。做数据标注、文本分类、情感分析的朋友一定要掌握。
技巧三：结构化 JSON 输出
这是工程场景最实用的技巧——让 AI 输出稳定的 JSON，方便程序解析。
常见错误：只说「输出 JSON 格式」。AI 输出的 JSON 可能包含不合法字段、多出文字说明、或者嵌套层级不对。
正确做法——给 JSON Schema 级别的约束：
请严格按照以下 JSON Schema 输出，不要添加任何 JSON 以外的文字。
{
"type": "object",
"properties": {
"title": { "type": "string", "maxLength": 50 },
"summary": { "type": "string", "maxLength": 200 },
"tags": {
"type": "array",
"items": { "type": "string", "enum": ["技术", "产品", "运营", "设计", "管理"] },
"maxItems": 3
},
"score": { "type": "number", "minimum": 0, "maximum": 10 },
"is_published": { "type": "boolean" }
},
"required": ["title", "summary", "tags", "score"]
}
请分析以下文章，输出符合上述 Schema 的 JSON。
文章内容：[粘贴文章]几个要点：
- enum 约束了 tags 只能从 5 个值里选，不会出现「数据库」「运维」等意外分类
- maxLength 防止 AI 写太长（对 Claude 尤其重要，它有时还会在 JSON 里写小作文）
- required 字段确保必须有这些 key，不会漏掉
- 「不要添加 JSON 以外的文字」这句话很重要——没有它 AI 大概率会在 JSON 外面加废话
技巧四：给 AI 一个「角色」但没有角色感
网上流传的「你是一个资深的 XX 专家」提示词其实效果很差——角色设定越模糊越没用。正确的用法是：不给头衔，给具体的约束条件。
对比一下：
差：「你是一个 Python 专家，帮我写一段代码」
好：「用 Python 写一段代码。要求：用标准库实现（不依赖第三方包），变量名用下划线命名法，每个函数有 docstring，代码行数不超过 50 行，优先使用 list comprehension 而非 for 循环。」
第二种方式的每一个约束都是可验证的——AI 不敢偷懒，因为它知道你会逐条检查。
技巧五：对抗幻觉——让 AI 标注不确定度
RAG 和知识库场景中，AI 有时会编造不存在的内容。一个简单有效的方法：强制 AI 对每个陈述标注信息来源。
回答问题时，对每一个事实性陈述，用括号标注信息来源：
- [已验证]：你确定的事实
- [推断]：你根据上下文推测的
- [不确定]：你没有把握的信息
- [来源：XX]：你的知识截止日期或提供的文档中的信息
示例：
Python 3.13 于 2024 年发布 [已验证]。它引入了改进的 GIL 实现 [不确定，请核实]。
现在回答：什么是 WASM？它和 JavaScript 的关系是什么？这个技巧让 AI 学会了「不知道就说不知道」，大幅降低了幻觉率。在生产环境的 AI 应用中非常推荐。
进阶组合技巧：全部串起来
一个真实的生产级提示词模板，融合了以上所有技巧：
<task>
分析客户邮件，提取关键信息并分类紧急程度。
</task>
<format>
严格按照以下 JSON Schema 输出，不要添加其他文字。
{
"type": "object",
"properties": {
"customer_name": { "type": "string" },
"issue_category": {
"type": "string",
"enum": ["账单问题", "技术故障", "投诉建议", "一般咨询"]
},
"urgency": {
"type": "string",
"enum": ["紧急", "普通", "低优先级"]
},
"summary": { "type": "string", "maxLength": 100 },
"confidence": {
"type": "object",
"properties": {
"category": { "type": "number", "minimum": 0, "maximum": 1 },
"urgency": { "type": "number", "minimum": 0, "maximum": 1 }
}
}
},
"required": ["customer_name", "issue_category", "urgency", "summary"]
}
</format>
<examples>
邮件：「你们的系统又崩了！我从早上到现在登不了，损失了好几单生意。你们赔吗？」
→ {"customer_name": "未署名", "issue_category": "技术故障", "urgency": "紧急", "summary": "用户反馈系统无法登录，导致业务损失，要求赔偿", "confidence": {"category": 0.95, "urgency": 1.0}}
</examples>
<thinking_rules>
1. 先判断邮件中是否明确提到了具体问题
2. 根据措辞强度判断紧急程度（愤怒/经济损失 → 紧急）
3. 如果信息不足，标注 confidence 较低
</thinking_rules>
请分析以下邮件：
[粘贴邮件内容]这个提示词包含了：结构化输出（JSON Schema）+ 少样本（examples）+ 链式思考（thinking_rules）+ 不确定度（confidence）+ 角色约束（rules）。是你在实际工作中可以改一改就直接用的模板。
总结
提升提示词质量的终极心法不是记住更多技巧，而是：
- 把 AI 想象成一个很聪明但没见过你项目的实习生——你不把约束说清楚，它就会按惯性办事
- 能用结构化格式约束的，不用自然语言约束（JSON > 描述）
- 给例子比给规则更有效（Few-Shot > Zero-Shot）
- 强制推理步骤，能避免 AI 偷懒跳步骤（CoT 几乎零成本提升准确率）
- 衡量提示词好坏的标准只有一个：输出结果的稳定性。如果跑了 10 次有 8 次不符合要求，不是 AI 不行，是你的提示词不够硬