提示工程入门指南：7种适用于任何大语言模型的模式
网上大部分「提示工程」建议，都是某个人声称灵验的魔法短语清单——「开头写‘你是一位专家’」「结尾加上‘一步一步思考’」「用‘深入探讨’这个词」。说到底，这些词本身并没有什么用，真正起作用的是结构。
我在GPT、Claude、Gemini 和开源模型上写并测试了几百条提示之后，发现所有好用的提示都逃不出7种模式。学会这些模式，你就能给任意模型、任意任务写出好提示，根本不用背什么魔法短语。这篇指南就是我刚开始时最希望看到的。
模式1：给模型一个角色
告诉AI它应该扮演什么角色。这不是演戏——而是把相关上下文加载到回答里。
弱： 写一个Bug报告。
强： 你是一名资深QA工程师，已经写过500多份Bug报告。针对这个问题写一份Bug报告：[描述问题]。
「资深QA工程师」这个角色会调动模型知道的惯例：复现步骤、预期与实际对比、严重级别。没有角色，你只能得到一份泛泛的描述。
什么时候用： 任何时候。这是成本最低的改进方式。
模式2：把上下文和约束分开写
两个最常见的错误是：(a) 不给足够上下文； (b) 把约束埋到上下文里，导致模型忽略它们。把你的提示结构写成上下文和约束肉眼可分的格式：
上下文：我在给一家B轮创业公司的工程VP写冷邮件。我们的产品是AI代码审查工具。他们刚发了招聘5名高级工程师的帖子。
约束：
- 主题行：最多5个词，不用大写（看起来像真人）
- 正文：最多90个词
- 不要感叹号，不要用「革命性」「颠覆性」
- 结尾用问题，不用会议链接
输出：主题行单独一行，然后是正文。
注意约束部分采用了项目符号列表。模型遵循列表式约束远比遵循埋在段落里的约束可靠。
什么时候用： 只要输出需要遵循规则（长度、语气、格式、禁用词）的时候。
模式3：少样本示例
展示，而不是说教。给模型1-3个输入→输出的例子，然后再给一个新输入。
将每条客户投诉转换成结构化工单。示例1：输入："上传照片时应用一直崩溃。" 输出：{"issue": "crash", "trigger": "photo upload", "severity": "high", "area": "mobile"} 示例2：输入："无法登录，提示令牌无效。" 输出：{"issue": "auth_failure", "trigger": "login", "severity": "high", "area": "auth"} 现在转换：输入："今天早上加载仪表盘花了很久。"
少样本学习是获得一致输出格式最可靠的方法。它之所以有效，是因为模型从示例中学习模式的效果要优于从描述中学习。
何时使用：任何需要特定输出格式的时候，尤其是结构化数据（JSON、表格、工单）。
模式4：思维链（但只在有帮助时使用）
"一步步思考"之所以出名，是因为它能提升数学和逻辑问题的表现。但在简单任务上，它不仅没有帮助，反而可能拖后腿。当任务包含多个推理步骤时再使用思维链：
一位客户的订单在周二发货，预计3个工作日到达。今天是下周一。客户要求退款。请结合我们的政策一步步分析他是否符合条件：[粘贴政策]。然后给出结论。
对于简单任务（比如"概括这段文字"），跳过它。在摘要里加"一步步思考"只会让输出变长，没有任何好处。
何时使用：数学、资格/逻辑判断、多步骤决策、调试。
模式5：明确指定输出格式
AI 输出难以使用的头号原因：模型自己决定输出格式。解决方法是把要求说清楚。
输出一个 Markdown 表格，列名为：工具 | 价格 | 最适合 | 限制。每工具一行。不要开头段落，不要结尾段落，只要表格。
或者对于代码：只输出函数本身。前后不要任何解释。如果我要粘贴到编辑器里，不要 Markdown 代码块。
单是"不要开头，不要结尾"这条指令，就能帮你省下删除几百字废话的时间。
何时使用：只要你打算把输出粘贴到别处，就用。模糊表达会让你多花时间编辑。
模式6：负面约束（禁止废话）
模型有一些口头禅式的毛病。
模式 6：负面约束——告诉模型别用什么词
模型特别喜欢用“当然可以”“我很乐意”“值得注意的是”“总之”这类套话。你可以直接禁止它们——比如在提示词里写上：“不要使用以下任何词语：‘当然可以’，‘我很乐意’，‘值得注意的是’，‘总之’，‘请随意’，‘深入探究’，‘鲁棒’，‘利用’，‘无缝’。” 并且不要加开头或结尾段落，直接写正文。
负面约束之所以有效，是因为模型对哪些填充词会冒出来是相当可预测的。禁止掉最常用的五六个词，就能把大部分输出中的废话清理干净。
什么时候用： 每次你手动删反复出现的套话时——这就是一个信号，该从源头把它禁掉了。
模式 7：迭代——你的第一条提示词只是草稿
没有人能第一次就写出完美的提示词。正确的流程是：
- 写提示词
- 运行它
- 看输出，问自己：哪里不对？
- 加一条约束或一个例子，专门修那个问题
- 再次运行
- 重复直到输出可用
我通常要迭代 3～5 次，提示词才能达到生产可用级别。迭代——就是 “提示工程” 里的 “工程” 二字。
进阶技巧： 把最终的提示词存进文档。下次遇到类似任务，直接拿过来改，不用从零开始。几个月下来，你会积累一个个人提示词库，效率大幅提升。
综合应用：一个真实案例
下面这条提示词一次性用上了全部七种模式：
角色：你是一位技术写作者，专门为初级开发者简化 API 文档。
背景：我正在为一个返回用户通知的接口写文档。现有文档假设读者懂 webhook，但初级开发者不懂。
约束：
- 解释部分不超过 150 字
- 假设读者从未听说过 webhook
- 包含一段 JavaScript 代码示例
- 禁止使用这些词：“简单地”、“只需”、“显然”、“直截了当”
语气示例（我想要的效果）：
不要说“只需订阅 webhook”，而要写“告诉我们的服务器注册一个 URL，以便向你发送更新。”
输出格式：一个标题，接着是解释文字，然后是代码块。不要开头和结尾段落。
这条提示词之所以有效，是因为每种模式针对一种不同的失败场景：
- 角色（Role）加载了正确的写作惯例；
- 约束（Constraints）控制了长度和语气；
- 示例（Examples）展示了具体语气；
- 输出格式（Output Format）省去了后续编辑。
常见错误要避开
别急着写长提示。别为一个简单任务写500字的提示词。从小处着手，只有输出不满意时才逐步增加限制条件。
不要轻信第一次输出。一定要检查。模型会自信地胡说八道。
别照搬"魔法短语"。如果你的提示词本身模糊不清，写上"扮演一位世界级专家"也毫无用处。
忘掉指定输出格式。这是头号浪费时间的事。要明确告诉模型你想要的形状。
这七种模式就是基础。一旦你真正掌握它们，就不会再四处搜索"完美提示词"，而是开始设计真正有效的提示。
我把自己在写作、编程、营销和运营中最常用的提示词整理成了几个工具包。如果你需要一个经过验证的起点，开发者产品发布提示包提供了7个可直接复制使用的提示词，而开发者生产力提示库则包含30个适用于日常开发工作的提示词。
你觉得哪种模式对你的提示词帮助最大？我一直在完善这个清单。