Prompt Engineering 的几个反模式
Prompt engineering 这两年火得一塌糊涂，各种"技巧"满天飞。什么"few-shot"、“chain-of-thought”、“角色扮演”，一套一套的。
有些确实有用。但更多时候，我看到的是技巧堆砌让输出变得更差。这篇文章聊几个我认为的反模式。
反模式一：角色扮演等于没说
最常见的模板：
你是一个资深后端工程师，有10年经验...这句话等于废话。
模型训练数据里已经有足够多的"资深工程师写的代码"。你告诉它"你是工程师"，它就按通用的工程师风格输出，跟你的具体场景没任何关系。
更有效的做法：
你是一个 Go 后端工程师，负责维护一套高并发 API 服务。
我们的技术栈：Gin + GORM + Redis。
约束：必须兼容 Go 1.21，禁止使用 any 类型...具体的技术栈、约束、上下文，比"10年经验"值钱太多。
反模式二：Few-shot 滥用
Few-shot 是给你示例让模型学习格式。但很多人把它用成了"例子堆砌"。
问题在于：例子越多，模型越容易过度拟合例子里的表层模式，而不是真正理解任务。
我见过最夸张的 prompt，扔了 20 个 Q&A 对话作为 few-shot examples。结果模型开始模仿对话的语气、措辞、甚至表情包，完全偏离了任务本身。
什么情况下 few-shot 有用：
- 输出格式必须严格遵循某种结构（比如 JSON schema）
- 任务边界模糊，需要例子来定义"什么叫对"
什么情况下 few-shot 是负担：
- 任务定义已经很清楚
- 需要模型做推理而不是模仿
反模式三：Chain-of-Thought 乱用
CoT 是让模型"一步步思考"。但它解决的是推理链长、容易跳步的问题，不是所有任务都需要。
比如：
2 + 2 = ?不需要 CoT，模型直接答 4。强制让它"思考"只会降低效率。
CoT 真正有效的是：
- 数学推导
- 逻辑推理
- 多条件判断
不需要 CoT 的是：
- 事实查询
- 格式转换
- 简单分类
反模式四：长度约束"不少于 XXX 字"
“请写出不少于 800 字的文章”。
这种约束是给模型加锁，而不是给质量加码。
模型为了凑字数，会往废话里注水。“综上所述”、“从以上分析可以看出"这类填充句就出现了。
质量不是字数堆出来的。 如果你的内容需要凑字数才能"显得完整”，问题在结构，不在字数。
反模式五：让模型"思考过程"透明
有些 prompt 要求模型"先给出思考过程，再给结论"。
这在某些场景下合理（比如调试），但日常使用往往是负担。
模型输出的"思考过程"，本质上是在模拟一个"思考的人类"，不是它真正在推理。这些"思考"经常是圆场的废话，浪费 token。
更高效的用法：
- 简单任务：直接给结论
- 复杂任务：先让它出一个 plan，你批准后再执行
- 调试场景：让它解释假设和推导
反模式六：用"你是一个 AI"开头
你是一个 AI 语言模型...这句话的唯一作用是提醒模型"你只是个程序，别当真"。没有任何工程价值。
如果你的 prompt 以这句话开头，通常意味着你对自己的任务定义还没想清楚。
有效的 prompt 共性
我观察下来，真正有效的 prompt 有几个共同特征：
- 任务边界清晰 — 不是"帮我写代码"，而是"在 GIN 框架下写一个带 JWT 认证的 /user/:id 接口"
- 约束具体 — 不是"代码要健壮"，而是"错误要返回特定 HTTP status code 和 JSON 格式"
- 验收标准明确 — 不是"写得好一点"，而是"跑通 test case A/B/C"
- 给原材料，不给二手总结 — 直接给文档/代码片段，而不是"根据你知道的 XXX"
最后
Prompt engineering 不是魔法，模型的能力有上限。好的 prompt 不是在突破这个上限，而是在让模型的上限稳定发挥。
与其研究技巧，不如把任务定义清楚。模糊的任务 + 花哨的技巧 = 垃圾。