ChatGPT 提示词速查表 - 高效 Prompt 编写技巧大全
把提示词写成可复用模板的价值不在于某一次回答变好，而在于输出从"每次形状不同"变成"每次结构相同"。这张表的模板按角色设定、结构化输出、代码相关、文本处理、少样本提示、思维链六类铺开，正好对应六种不同的失效原因：身份含糊导致语气漂移、格式没定导致要靠正则抠结果、任务没拆导致跳步、示例不足导致风格不统一、推理没展开导致算错。什么时候该翻它：你在写第四个功能相似但措辞不同的提示词——此时该停下来做的是抽象模板而不是继续调措辞；或者模型总在 JSON 前面加一段客套话——这是没写"只输出不要解释"而不是模型不听话。判断一条模板是否合格的检验方法是把它交给一个没见过这个任务的人照着用，以及在两次不同输入下输出结构是否完全对齐；后者比前者更能暴露模板里隐含的假设。
角色设定（System Role） 5
你是一位资深{领域}专家，拥有 10 年以上经验，请用专业但易懂的方式回答以下问题：{问题}作为{角色}，请严格按照{规范/标准}完成以下任务：{任务描述}你现在的身份是{角色}，你的目标是{目标}，你的约束是{约束}。请开始：{输入}请以{角色}的视角分析{问题}，给出 3 个不同角度的观点，并说明每个观点的依据。假设你是一名{职位}，正在{场景}，请给出处理{问题}的完整步骤和注意事项。结构化输出（JSON/表格/Markdown） 5
请将以下内容输出为 JSON 格式，字段包括：name、description、tags。只输出 JSON，不要解释。内容：{文本}请用 Markdown 表格对比{A}和{B}，对比维度包括：性能、易用性、生态、学习成本。请以如下结构输出：## 标题 / ### 子标题 / - 要点。主题：{主题}请严格按此 JSON Schema 输出，不要包含任何解释文字：{schema}。输入：{输入}请把下面的需求拆解成 checklist 表格，列包含：任务、优先级、预估工时。需求：{需求}代码相关（生成/审查/解释/重构） 5
请用{语言}实现以下功能：{需求}。要求：包含错误处理、注释、单元测试示例。你是一位资深{语言}开发者，请审查以下代码，指出 bug、性能问题、可读性问题，并给出改进版本：
```
{代码}
```请逐行解释以下代码的作用、原理和潜在问题：{代码}请重构以下代码，目标：降低复杂度、提升可读性、保持行为不变。说明每处改动的原因：{代码}请为以下函数编写单元测试，覆盖正常路径、边界情况和异常情况：{函数}文本处理（总结/翻译/改写/提取） 5
请用 200 字以内总结以下内容的核心观点，并提取 3-5 个关键词：{长文本}请将以下内容翻译成{目标语言}，保持专业术语准确，语气{正式/口语}：{文本}请将以下内容改写为{风格：科普/学术/营销}风格，目标读者是{受众}：{文本}请从以下文本中提取所有{实体类型：人名/地名/日期/金额}，以列表形式输出：{文本}请对比以下两段文本的差异，从观点、论据、结论三个维度分析：{文本A} vs {文本B}少样本提示（Few-shot） 4
示例：
输入：好的 → 输出：很棒
输入：差 → 输出：糟糕
现在请处理：{输入}任务：将客户评论分类为正面/负面/中性。
示例：产品很好用 → 正面
物流太慢 → 负面
请分类：{评论}按照以下格式生成 SQL：
Q: 查询所有用户
A: SELECT * FROM users;
Q: {自然语言查询}
A:风格模仿：以下是我之前的写作风格示例
{样例1}
{样例2}
请用相同风格续写：{开头}思维链（Chain of Thought） 4
请一步步推理以下问题，先列出已知条件，再分析思路，最后给出答案：{问题}请像数学老师一样，分步骤解答以下问题，每步说明依据的公式或定理：{问题}请在回答前先思考：1) 问题的关键约束是什么 2) 有哪些可行方案 3) 各方案的利弊 4) 推荐方案。问题：{问题}请对以下决策进行利弊分析，先列出所有影响因素，再权衡，最后给出建议：{决策}提示
- 角色设定 + 约束条件 + 输出格式三件套同时给，比单写"帮我写个 XX"质量高一个量级。
- 要求 JSON 等结构化输出时，务必加"只输出 JSON，不要解释"，否则模型容易在前面加废话导致解析失败。
- 复杂推理任务用"一步步思考"触发思维链，数学和逻辑题准确率明显提升；GPT-4 以上模型可显式写 "Let's think step by step"。
- Few-shot 给 2-3 个示例即可，示例过多会过拟合且浪费 token；示例的输入输出格式要和真实任务完全一致。
- 给出 JSON Schema 比列出字段名更硬，模型越出界的概率明显更低。
- 让它"给 3 个不同角度并说明依据"，比直接要一个答案更容易暴露你没考虑到的约束。
- 风格模仿类任务给两段自己的真实样例，比描述"专业又亲切"稳定得多。
常见问题
为什么让模型输出纯 JSON 时它总会加解释？
因为「不要解释」这种软性约束不够强。有效做法是同时给格式和禁止项：「只输出 JSON，不要包含任何解释文字」并在末尾明确「不要解释」，或者直接给一段 JSON Schema 说「严格按此结构输出」。前者用自然语言约束，后者用结构约束，后者更稳定，必要时还能配合 --output-schema 之类的参数做硬校验。
思维链提示对哪些任务最有效？
对需要多步推理的任务最有效：数学计算、逻辑判断、多条件的技术选型。做法是要求它先列已知条件、再分析思路、最后给答案，比如「请一步步推理以下问题，先列出已知条件，再分析思路，最后给出答案」。对纯检索类任务则帮助不大，因为答案不依赖推理链，硬加反而让输出冗长。
Few-shot 和零样本该怎么选？
任务的输入输出映射清晰、且格式必须稳定时用 Few-shot，给两三个示例模型会自动泛化格式，例如把评论分类为正/负/中并附示例，准确率通常明显高于零样本。任务简单或示例难凑齐时零样本即可。关键点是示例要覆盖你真正会遇到的输入分布，只给理想示例会让模型在边缘输入上失效。
怎么让模型不要写套话？
给出可判定的约束，而不是形容：「不要列举」「除非必要不要寒暄，直接给答案」「除非我要求否则不要给总结」。套话通常出现在没有明确排除项时——模型默认会加上「当然可以」「希望对你有帮助」这类前后缀。把它明确禁掉，输出会立刻干净很多。
代码审查时怎样提问才容易得到有用结果？
分维度提问比泛泛地说「看看有没有问题」有效得多：明确要求分类指出 bug、性能问题和可读性问题，并要求给出改进版本。比如「请审查以下代码，指出 bug、性能问题、可读性问题，并给出改进版本」。这样得到的反馈结构清晰、覆盖完整，也便于逐条判断是否采纳。
由 巧匠 维护
公开更新于 2026年7月31日，内容持续校对官方文档。