如果你刷到过那些”ChatGPT必杀prompt秘籍”，大概率已经发现一个问题——别人的prompt怎么那么好使，自己照着写出来还是稀巴烂。
其实不是你学艺不精。今年的提示词工程已经相当成熟了，该踩的坑有人踩过了，该总结的框架也有人总结好了。这篇直接给干货：有哪些确实有效的提示技术，有哪些拿来就能用的框架，还有大多数人一直在犯的错。
一、今年还在用的提示技术
先过一遍今年仍在生产环境中验证有效的核心技术。不讲理论，直接说用法。
1. Chain-of-Thought（思维链）
如果你只能学一种提示技术，就学这个。
CoT不是什么新鲜玩意了（Google Research 2022年就发了论文），但它的威力至今没衰减。原理简单：让模型在给出答案之前，先把推理过程写出来。
怎么用：
零样本版：在prompt末尾加一句”请逐步思考”或”Please reason step by step”。Google的数据显示，零样本CoT能把算术推理准确率从10.4%拉到40.7%。
少样本版：在prompt里给几个带完整推理步骤的例子。模型看了就知道照这个模式走。
什么时候用： 数学题、逻辑推理、因果分析、任何需要多步推导的场景。
注意： 简单任务上CoT可能多余，还多烧token。别拿大炮打蚊子。
2. Few-Shot Prompting（少样本提示）
给模型看几个输入输出对，让它学会你要的模式。Google白皮书说得很直接：一定要带few-shot示例，零样本不被推荐。
有个实验很经典：在GSM8K数学基准上，8个精心写的示例让一个5400亿参数的模型打败了经过微调的GPT-3。
关键： 示例质量比数量重要。2-5个好例子，好过10个凑数的。
3. Self-Consistency（自一致性）
CoT的升级版。思路是：同一个问题跑多次（比如5次），每次走不同的推理路径，然后取出现频率最高的答案。
如果你在搞高风险的决策支持系统，这招特别好用。缺点是要烧钱——每次推理成本直接乘以采样次数。
4. Tree-of-Thought（思维树）
CoT是走一条线，ToT是同时探索多条不同的推理路径，评估然后挑最好的。
复杂度高、成本也高，但适合需要深度思考的复杂决策。今年的前沿模型大多内置了类似能力——你甚至不需要在prompt里显式写”树”，模型自己就会干类似的事。
5. ReAct（Reason + Act）
CoT只产生文本，不动工具。ReAct让模型”一边想一边干”——想一步，查个工具，根据结果再想下一步。
Agent系统里的标配。但你如果只是写对话prompt，不太需要这个。
6. Least-to-Most Prompting（由简到繁）
把一个复杂问题拆成从简单到难的子问题，一个个解决，每个子问题的答案用来构建下一个。
适合”一步搞不定，但分步可以”的场景。
二、拿来就能用的提示词框架
上面说的是”技巧”——怎么让模型思考。接下来是”框架”——怎么组织prompt的结构。
RTF（Role-Task-Format）
最简单的框架，适合快速上手：
```
Role: 你是一个XXXX
Task: 请完成XXXX
Format: 输出格式为XXXX
```不需要花里胡哨。当你已经知道模型要演什么角色，只是想说清楚做什么和怎么做，RTF就够了。
RACE（Role-Action-Context-Expectation）
比RTF多了一层上下文和期望：
```
Role: 你是一个XXXX
Action: 请完成XXXX
Context: 背景信息是XXXX
Expectation: 我期望的输出是XXXX
```适合内容生成类的任务。
COSTAR（Context-Objective-Style-Tone-Audience-Response）
新加坡政府技术团队推广的，结构最完整：
– Context：提供足够背景
– Objective：明确目标
– Style：写作风格
– Tone：语气（正式/随意）
– Audience：目标受众
– Response：输出格式
适合对外输出的内容——营销文案、客户沟通、正式报告。
RISE（Role-Input-Steps-Expectation）
适合任务驱动的prompt：
```
Role: 定义角色
Input: 输入数据
Steps: 执行步骤
Expectation: 期望的输出
```5-S框架
由教育场景设计的（Set the Scene, Specify task, Simplify language, Structure response, Share feedback），在企业环境也挺好用。
怎么选： 简单日常用RTF，内容输出用RACE或COSTAR，任务驱动用RISE。没有”最好的框架”，只有最合适的。
三、你大概率在犯的错
按伤害程度排，越靠前越致命。
1. 什么都在一个prompt里干完
一个prompt里同时要求审校、翻译、格式化、摘要、分析——结果一样都干不好。
模型注意力是有限的。你把十个任务塞一个问题里，它十个任务都做得稀烂。拆，一个prompt只干一件事。
2. 往里塞一堆废话
无关信息稀释了模型对关键指令的注意力。prompt越长，如果冗余越多，准确率越低。
检查你的prompt：每句话有没有存在的理由？没有？删。
3. 不给示例指望模型自己猜
Google白皮书说得很直白：零样本不是优先选择。虽然模型零样本能力在提升，但有示例永远比没有好。
特别是当你需要精确的输出格式时——不给例子，模型大概率自己造一个格式。
4. 让模型身兼数职
“你是一个拥有30年经验的顶级SEO专家、数据科学家、文案写手和心理咨询师”——你让模型到底演哪一个？
角色定义要精确。一个prompt给一个角色就够了。
5. 数据一大坨，问题放前面
先给背景数据，再放具体问题。这个顺序的影响比你想象的大。Google白皮书明确说：具体问题放在上下文数据之后。
6. 以为”礼貌”在所有模型上通用
不同模型的训练数据里”礼貌指令”分布密度不一样。在GPT上有效的词，换Claude可能毛用没有。别迷信”魔法词”，测试才是硬道理。
7. 不测试直接上线
demo里跑得好好的，一上线翻车。为什么？demo只跑了一次，生产跑了几百次，方差暴露了。
正确做法：准备一套测试数据，同一个prompt反复跑，统计一致性和准确率。
8. 上下文不够
反面极端：prompt太短，模型不知道你在说什么。你扔一句”帮我写个方案”，模型只能猜你要什么方案、写给谁、什么风格。
给足上下文。模型不会读心。
四、快速自查清单
写prompt的时候对着这个查：
– [ ] 每个prompt只做一件事吗？
– [ ] 上下文够用但不冗余吗？
– [ ] 需要精确格式的话，给了示例吗？
– [ ] 角色单一且精确吗？
– [ ] 问题放在数据后面吗？
– [ ] 有验收标准吗？
– [ ] 生产环境测过多次运行吗？
– [ ] 删掉所有凑数的废话了吗？
如果只改一件事，改这个：拆任务。一个prompt只做一件事，输出质量提升比你学任何框架都明显。
总结
prompt工程在今年已经不是什么玄学。技术层面就那几个核心技巧（CoT、Few-shot、Self-Consistency、ToT、ReAct），框架层面选一个顺手的用（RTF、RACE、COSTAR、RISE），错误层面上大多数人犯的问题根因都一样——不够精确。
把prompt当需求文档写，别当聊天消息写。精确，而不是花哨，才是它的核心。
📖 推荐阅读
看看这些文章，你可能会感兴趣：