一句话定义
Prompting 指的是设计发给模型的输入，让它稳定产出你想要的结果。输入通常包含四部分：指令、上下文、示例、输出格式要求。
它曾经被叫作「提示词工程」，让人误以为存在某种咒语。真实情况更朴素：把任务说清楚，比说得好听重要得多。
为什么重要
因为它是零成本的。同一个模型，输入组织得好与不好，效果差距可以大到像换了两个模型。
更重要的是，好的提示会暴露出任务本身定义不清的地方。你写不出清晰的指令，通常说明你自己还没想清楚要什么——这才是最有价值的反馈。
四个真正有效的动作
-
给角色和目标，而不只是动作 ❌「总结一下这篇文章」 ✅「你是给非技术读者写摘要的编辑。用 5 句话说明这篇文章的核心结论和它对实践的影响。」
-
给示例，而不是给形容词 「写得好一点」没有信息量。给两个你满意的样例，模型立刻知道标准在哪里。
-
规定输出格式 要求 JSON、表格、固定字段。格式约束会显著降低后续处理的成本。
-
把判断标准写进指令 与其说「仔细检查」，不如说「检查是否存在与原文矛盾的数字，若有则单独列出」。
常见技巧及其真实价值
| 技巧 | 作用 | 注意 |
|---|---|---|
| Zero-shot | 快速试探任务可行性 | 复杂任务几乎一定不够 |
| Few-shot | 对齐格式与判断标准 | 示例质量决定上限 |
| 思维链 | 提升多步推理正确率 | 简单任务上是浪费 |
| 让模型先问再答 | 补全缺失信息 | 会增加一轮交互 |
常见误解
- 「提示词是玄学」：多数失败可以归因为信息不足、目标含糊、没有格式约束。
- 「有万能提示词模板」：模板只能提供结构，判断标准必须来自你的领域知识。
- 「模型变强之后提示就不重要了」：正好相反，模型越强，模糊指令带来的方差越大。
从提示到上下文
如果反复调措辞仍然不稳定，问题通常不在措辞，而在你给它看的东西不对。这时应该转向 Context Engineering。
延伸阅读
- Context Engineering：提示工程的上位问题
- LLM API：系统提示、温度等参数如何影响输出