提示词编写技巧：把大模型当同事，而不是许愿机
你可能有过这种体验：同一句话问大模型，今天答得像专家，明天答得像百科；让它“输出 JSON”，它偏要加一段解释；让它“别编”，它还是能编得头头是道。
这篇文章不讲“玄学咒语”，只讲一套能反复复用的写法：把提示词写成需求说明书，让输出稳定、可复用、可评测。
1. 为什么你的提示词不稳定？
提示词不稳定，通常不是模型“忽然变笨”，而是你给的信息不够“可执行”。常见问题有：
- 目标太虚：比如“请详细总结”，没有可验收标准。
- 约束缺失：没说“不要编造”“信息不足先问”，模型就会填空式补全。
- 输出格式不明确：说“给个表格/给个 JSON”，但没写字段与结构。
- 任务太杂：让它又总结又抽取又决策，最后每样都做不稳。
接下来我们用一个简单原则解决：提示词=需求说明书。
2. 提示词=“需求说明书”
把提示词当成给同事的需求说明书，而不是对 AI 的祈祷文。一个好提示词通常包含四类信息：
- 任务目标：要做什么（总结/抽取/写代码/改写/对比）。
- 输入资料：原文、数据、约束条件、上下文（能看到什么）。
- 硬性约束：不能做什么、必须遵守什么（字数/口吻/字段/禁止编造）。
- 输出格式：要怎么交付（JSON/Markdown/表格/列表），字段名要明确。
如果你只记住一句话：把“验收标准”写进提示词里。
3. 写提示词的 6 条黄金原则（实战够用版）
3.1 明确“角色”，但别演太多戏
角色用于校准语气与关注点，例如“资深后端工程师/法务/面试官”。
不要写一堆无关设定（占上下文，还可能跑偏）。
3.2 把“目标”写成可验收的结果
坏例子：请详细总结。
好例子：输出 5 条以内要点 + 3 条行动项（含负责人/截止时间/验收标准）。
你甚至可以更“工程化”一点：限制每条字数、必须包含哪些字段、必须引用输入中的句子等。
3.3 用“硬约束”减少幻觉与跑题
建议常用这三条（尤其在严肃场景）：
- 不确定就说不确定，并列出需要补充的信息清单
- 不得编造引用/链接/版本号
- 如果输入不足，先问澄清问题再输出最终结果
3.4 给输出“模板/字段”，让格式稳定
你想要结构化输出，就把结构写死，例如：
- JSON：字段名、类型、是否允许多余字段
- Markdown：标题层级、列表格式、表格列名
一句话：别说“给个 JSON”，要说“给这个 JSON”。
3.5 给 1 个“正例”，通常比 100 句描述更有用
模型对“示例”很敏感。你可以给：
- 输出示例（最有效）
- 反例（告诉它不要这么写）
3.6 复杂任务拆两步：先抽取，再写作
对复杂任务，把它拆成两步往往更稳：
- 先抽取关键信息（要点/字段）
- 再基于抽取结果生成最终文本
如果你在做 RAG，这个思路尤其重要：先从证据里“抽取事实”，再写最终回答。
4. 一个通用可复用的提示词模板（建议你收藏）
把方括号替换成你的实际内容：
你是[角色]。
你的任务：根据【输入】完成【目标】。
硬性约束：
1) 不要编造事实；不确定就明确说“不确定”，并给出需要补充的信息清单；
2) 如果输入不足以完成任务，先输出【澄清问题】再停止；
3) 输出必须严格符合【输出格式】，不得添加多余字段/段落（除非允许）。
【输入】
[粘贴资料/数据/需求]
【输出格式】
[写清楚结构：字段名、顺序、示例]
这个模板的价值在于：你每次只改【输入】和【目标】，其余“安全护栏”保持不动，输出就会更稳定。
5. 三个可直接复制的场景示例
5.1 把文章总结成“要点 + 结论 + 风险”
你是资深技术编辑。
任务：把【输入】总结成 3 部分：要点、结论、风险/注意事项。
约束：
1) 要点不超过 6 条，每条不超过 30 字；
2) 不要编造未出现的事实；如存在不确定处，用“待确认：...”标注；
3) 输出用 Markdown，且只允许出现这三个标题。
【输入】
（粘贴文章）
【输出格式】
### 要点
- ...
### 结论
- ...
### 风险/注意事项
- ...
5.2 从文本抽取结构化字段（适合做 RAG/入库）
你是信息抽取助手。
任务：从【输入】中抽取字段并输出 JSON。
约束：
1) 只输出 JSON，不要解释；
2) 不存在的字段输出 null；
3) 禁止编造：如果文本没有明确提到，必须为 null。
【输入】
（粘贴文本）
【输出格式】
{
"title": "string|null",
"author": "string|null",
"date": "YYYY-MM-DD|null",
"keywords": ["string"],
"summary": "string|null"
}
5.3 写代码（避免“能跑但不对”）
你是资深后端工程师。
任务：根据【需求】生成可运行的代码，并给出最小示例。
约束：
1) 先复述你理解的需求与边界条件（不超过 5 条）；
2) 如果需求不清晰，先问最多 3 个澄清问题；
3) 代码必须包含：异常处理、注释、一个可运行示例；
4) 不要使用未声明的外部依赖。
【需求】
（粘贴需求/接口说明/输入输出示例）
6. 常见坑与修复方式（踩一次就会记住）
6.1 “写得太空”
表现：输出泛泛而谈、像百科。
修复：加验收标准（条数/字段/示例/必须引用输入中的句子）。
6.2 “信息太少还强行输出”
表现：编造细节。
修复：加硬约束——缺信息先提问或用 null/待确认。
6.3 “一次做太多事”
表现：写作、抽取、对比、决策混在一起，结果不稳。
修复：拆成两轮：先抽取/列要点，再生成最终输出。
6.4 “格式漂移”
表现：说好 JSON，最后混进解释文字。
修复：强调“只输出 JSON”，并给字段 schema；必要时加 stop sequences（工程侧）。
7. 一分钟自检清单（建议你每次都过一遍）
- 目标是否可验收（条数/字段/示例）？
- 输入是否完整（原文、约束、背景）？
- 不确定怎么处理是否写清楚（先问/输出 null/待确认）？
- 输出格式是否“写死”（字段名、顺序、是否允许多余内容）？
- 是否需要拆步（先抽取再生成）？
8. 结语：从“会写提示词”到“可上线的提示词”
如果你只是自己用，做到“清晰 + 有格式 + 有约束”就已经很好了；但一旦要接入业务（客服、知识库、数据入库、自动化流程），你还需要把提示词工程化：做评测集、做回归、做 RAG 引用与可追溯、做工具调用与结构化输出。
