什么是提示词工程
更新: 7/2/2026字数: 0 字 时长: 0 分钟
先说结论：提示词工程不是什么玄学，也不是在写什么神秘咒语。
你刷到过那种「30 个让你效率翻倍的 Prompt 模板」吧？我也刷到过。但实际用起来就会发现，光抄模板根本解决不了问题——模板是别人的场景，你的任务是另一回事。
那提示词工程到底是什么？
其实就是把你脑子里的需求，用模型能稳定理解的方式说出来。不是什么高深的学术概念，就是一个"把话说清楚"的动作。只不过我们平时和人说话靠默契、靠上下文、靠"你懂的"，跟模型不行，它真的会瞎猜。
你有没有遇到过这种情况？
对着 AI 说一句：
帮我优化一下这段代码然后它改了，但改的是可读性，而你想要的是性能。
你说：
帮我写个周报然后它洋洋洒洒写了一篇，跟你实际做的事毫无关系。
问题不在模型笨，而在于我们没说清楚。就像你跟同事说"帮我做一下那个"，同事一定一脸懵。但你对 AI 这样说的时候，反而期待它猜到，这不是挺奇怪的嘛。
那怎么写才算"说清楚"？一个模板就够了
不用看那些花里胡哨的框架，真正好用的就六件事：
1. 你是谁 → 让模型知道用什么角色回答
2. 要干嘛 → 目标是什么
3. 背景是啥 → 现有材料、业务上下文
4. 别干嘛 → 约束条件
5. 怎么输出 → 格式、长度、结构
6. 怎么算对 → 验收标准套个例子你就明白了，还是刚才那个"帮我优化代码"，改成这样说：
你是 Vue 前端开发。
目标：在不改外部 API 的前提下优化这个组件的可读性。
约束：
- 不新增依赖
- 不改 props 和 emit 名称
- 保留现有 CSS class
输出：
修改后的代码 + 改动原因 + 3 个需要跑的验证命令这样写出来，模型基本不会跑偏。不是因为更"长"了，而是因为把那些你脑子里觉得"不言自明"的东西写出来了。
几个实际场景的例子
让 AI 帮你写文章
你是技术博主。面向前端同学解释 RAG。
要求：
- 先用一个生活类比讲清楚是什么
- 再画个流程图
- 最后给个实际产品怎么用的案例
- 别堆术语，读起来像在聊天重点：告诉它读者是谁、要什么风格、结构怎么搭。
让 AI 帮你写代码
你是 TypeScript 后端。
请根据下面的接口返回结构生成类型定义和转换函数。
注意：
- 不引入第三方库
- 可选字段要做空值保护
- 输出代码后补 3 个边界测试用例重点：交代技术栈、边界条件、要不要测试。
让 AI 帮你做分析
分析这份用户反馈。
输出分 5 块：
1. 高频问题都集中在哪几类
2. 每类挑 3 条真实原文
3. 你觉得根因是什么
4. 产品上可以怎么改
5. 哪些结论需要再找数据确认
不确定的地方单独列"待验证"。重点：别让它直接下结论，先整理归类。
几个真的好用的小技巧
1. 喂材料
如果你手上有参考文档，直接丢给它，然后加一句：
只基于我给的资料回答。如果资料里没有，直接说"资料里没提到"。这条在做知识库问答、看合同、查制度的时候尤其救命——能挡住一多半瞎编。
2. 定格式
让它输出 JSON 就别害羞，直接写清楚结构：
{
"summary": "一句话总结",
"risks": ["风险1", "风险2"],
"nextSteps": ["行动1", "行动2"]
}格式越明确，后面你写脚本处理的时候越省事。
3. 别一口气做完
复杂任务拆成几步走，每一轮只推进一小步：
你中间确认一下，比你让它从头干到尾然后推倒重来省时间得多。
4. 让它老实交代
加这句：
不确定的地方单独列"前提假设与风险"，别把推测写成事实。能大幅减少那种"说得头头是道但你一看就知道是编的"的情况。
我踩过的坑
| 坑 | 为什么是坑 | 怎么绕过去 |
|---|---|---|
| 觉得提示词越长越好 | 废话多了关键信息反而被稀释 | 只塞跟任务相关的东西 |
| 只说目标不说背景 | 模型会脑补你的场景 | 上下文该给就给 |
| 只看输出顺不顺 | 顺不代表对，可能是编的 | 让它标注信息来源 |
| 一次要求做太多 | 做着做着就跑偏了 | 拆成几步，轮着来 |
| 完全相信输出 | 幻觉是个真实问题 | 关键结论自己再过一遍 |
每次发之前，问自己 6 个问题
- 任务我讲清楚了吗？
- 背景我给了吗？
- 不能做什么我说了吗？
- 输出格式我定了吗？
- 怎么判断好坏我说了吗？
- 我让它不确定的时候老实交代了吗？
说实话，我自己也不是每次都能写这么好。但每次翻车前回看，基本都是上面漏了某一条。
一句话
好提示词不靠玄学，靠你把目标、背景、边界和验收标准讲清楚。剩下的事，交给模型。
延伸阅读