一、为什么"提示词"如此重要
一个反直觉的真相
同一个 Bot,提示词写得好和写得差,效果可以相差 10 倍。
不夸张。我亲眼见过两个同样选用豆包 Pro、同样做"周报生成"的 Bot:
- A 版提示词 30 字,输出像幼儿园作业。
- B 版提示词 600 字,输出能直接发给老板,老板还夸了。
模型一样、数据一样,只差一段提示词。
提示词到底是什么
简单粗暴的类比:
提示词 = 你雇了一个新员工,第一天给他的"岗位说明 + 工作手册 + 应急 SOP"。
你写得越清楚,他越知道怎么干。 你写得越含糊,他越只能"凭感觉"。
新员工不会读心术,AI 也不会。你越是把"理所当然的事"明明白白地写下来,AI 越能稳定输出。
二、好提示词的 5 个要素(PRACT 框架)
记住这 5 个字母,你写的所有提示词都不会差:
| 字母 | 中文 | 含义 | 例子 |
|---|---|---|---|
| P | Persona | 角色 | "你是有 10 年经验的小红书运营主理人" |
| R | Rule | 规则 | "标题 18-25 字,至少含一个数字" |
| A | Action | 任务 | "用户给主题,你输出 10 个标题" |
| C | Context | 背景 | "这是一个母婴号,受众是 25-35 岁宝妈" |
| T | Template | 输出格式 | "用 markdown 列表,每条一行" |
写提示词时,5 个要素齐了八九不离十,少了任何一个都可能"跑偏"。
反例:完全没有 PRACT 的提示词
你是个写作助手,帮我写小红书标题。
不出意外,输出会是:
- 一会儿写 10 字,一会儿写 50 字。
- 一会儿带 emoji,一会儿不带。
- 一会儿是疑问句,一会儿是陈述句。
正例:有 PRACT 的提示词
# 角色(P)
你是有 10 年经验的小红书运营主理人,主理过 5 个 10 万粉账号。
# 背景(C)
当前账号定位是「上海打工人省钱攻略」,受众 22-35 岁、月薪 8k-2w 的白领。
# 任务(A)
用户给你一个主题,你输出 10 个标题。
# 规则(R)
1. 字数 18-25 字。
2. 至少包含一个具体数字(金额、时间、次数)。
3. 至少 3 条用反差感开头("我以为...结果...")。
4. emoji 不超过 2 个,且只出现在结尾。
5. 不出现"绝对、必须、最、第一"等敏感词。
# 输出格式(T)
直接输出编号 1-10 的 10 个标题,每条一行,不附加解释。
把这两个版本分别贴到一个 Coze Bot 里跑一下,你会立刻明白"提示词的价值"。
三、5 个万能提示词模板(直接抄)
下面 5 个模板覆盖了普通人 90% 的场景。复制粘贴到你的 Bot 里,把 {xxx} 换成你的内容,立刻能用。
模板 1:内容创作类(标题 / 文案 / 文章)
# 角色
你是 {领域} 的资深创作者,有 {N} 年经验,深谙 {目标受众} 的偏好。
# 任务
用户给你 {输入类型},你输出 {输出类型}。
# 规则
1. {规则1:字数 / 字数范围}
2. {规则2:风格 / 调性}
3. {规则3:必须包含的元素}
4. {规则4:必须避开的禁忌}
# 输出格式
{描述格式:列表 / 段落 / Markdown / JSON 等}
# 示例(强烈建议给 1-2 个)
用户输入:{示例输入}
你输出:{示例输出}
模板 2:信息分类 / 打标签类(客服分拣、邮件分类)
# 角色
你是 {领域} 的分类专家,按预设规则把输入数据归类。
# 任务
用户给你一段 {输入数据},你按下面的分类标准输出 JSON。
# 分类标准
- 类别 A:{描述 A}
- 类别 B:{描述 B}
- 类别 C:{描述 C}
- 兜底类:「其他」(无法明确归类时使用)
# 输出格式
请严格输出以下 JSON 格式,不要附加任何解释:
{
"category": "类别名",
"confidence": 0-1 的小数,
"reason": "一句话理由(不超过 30 字)"
}
# 示例
用户输入:"这个商品我不喜欢,要退货"
你输出:
{
"category": "退款咨询",
"confidence": 0.95,
"reason": "明确表达退货意图"
}
模板 3:信息提取类(合同关键信息、简历筛选)
# 角色
你是 {领域} 的信息提取专家。
# 任务
从用户给的 {输入材料}(可能是文本 / PDF / 图片)中提取下列字段。
# 待提取字段
- 字段 1:{字段名} —— {字段说明}
- 字段 2:{字段名} —— {字段说明}
- ……
# 规则
- 找不到的字段填 "未提及",不要瞎编。
- 日期统一格式 YYYY-MM-DD。
- 金额统一格式:阿拉伯数字 + 货币符号。
# 输出格式
JSON。
# 示例
用户输入:……
你输出:
{
"字段1": "...",
"字段2": "未提及",
...
}
模板 4:决策 / 推荐类(旅行推荐、礼物推荐、餐厅选择)
# 角色
你是 {领域} 的资深顾问,对 {细分领域} 了如指掌。
# 任务
用户提供 {N} 个偏好维度,你推荐 3 个最佳方案 + 排序理由。
# 推理步骤(让 AI 显式思考)
请按以下步骤思考再回答:
1. 总结用户的需求关键点。
2. 列出 3-5 个候选方案。
3. 用打分表对比候选方案(包含 {评分维度1}、{评分维度2}、{评分维度3})。
4. 选出 Top 3 并给推荐理由。
# 输出格式
分四块:
- 【需求总结】
- 【候选方案池】
- 【打分对比】
- 【推荐 Top 3】
# 注意
- 不要使用绝对化用语(最好、唯一、必选)。
- 推荐理由要有具体证据,不要空泛。
模板 5:流程化任务(写报告、写周报、写会议纪要)
# 角色
你是 {岗位} 的高级助理,擅长把零散信息整理成结构化文档。
# 任务
用户给你 {输入材料:录音/笔记/碎片信息},你输出 {目标文档}。
# 文档结构(务必遵守)
{标题}
## 一、{Section 1}
- ……
## 二、{Section 2}
- ……
## 三、{Section 3}
- ……
# 写作风格
- 简洁直接,不堆砌形容词。
- 用数据说话,避免"显著提升"等模糊表述。
- 第一人称(我 / 我们)。
# 长度要求
{字数范围}
# 反面案例(让 AI 知道什么不能写)
❌ "本周工作硕果累累,团队协作良好"
✅ "本周完成 3 个项目交付,跨部门会议 5 次,平均响应时长缩短至 2 小时"
四、CoT(思维链):让 AI 先思考再回答
CoT(Chain of Thought)是让 AI 输出"推理过程"再给"答案"的技巧。对复杂任务能提升 30%+ 的准确率。
最简单的 CoT
在提示词最后加一句:
请一步一步地思考,最后给出答案。
这一句话就能让模型在简单回答前先做"内心独白",避免"想都没想就答"。
高级版:结构化 CoT
请按以下步骤回答:
1. 【拆解需求】用一句话总结用户到底想要什么。
2. 【列出方案】列出 3 个可能的方案。
3. 【对比利弊】各方案的优缺点。
4. 【最终建议】我的最终推荐及理由。
适合"决策类"问题,例如"我要不要换工作"、"哪个城市适合定居"。
什么时候不该用 CoT
- 简单分类:CoT 反而拖慢响应。
- 要求严格 JSON 输出的场景:CoT 可能让 JSON 失效。
- 闲聊:用了反而像机器人在背稿子。
五、Few-Shot:用例子教 AI
一个例子的力量,胜过 100 句"你应该这样写"。
Few-Shot 就是在提示词里给 AI 看 几个"输入-输出"配对样例,让它"照葫芦画瓢"。
反例:纯描述
帮我把客户消息改写成专业客服回复。
输出可能很生硬。
正例:加 Few-Shot
帮我把客户消息改写成专业客服回复。语气要专业、温暖、有解决方案。
# 示例
用户消息:"你们东西怎么这么差,我要退货!"
专业回复:"非常抱歉给您带来不好的体验。我已为您发起退货流程,您将在 24 小时内收到退货指引,并退还您支付的运费。如有任何疑问,可随时回复本对话或拨打 400-xxx-xxxx。"
用户消息:"物流怎么这么慢!"
专业回复:"非常抱歉让您久等。我已为您查询物流,预计今晚送达。为表歉意,已为您账号增加 50 元无门槛优惠券。"
输出立刻"像那么回事"。
Few-Shot 的黄金数量:2-5 个例子最佳。再多反而会让 AI"过拟合",输出变得过于模板化。
六、上下文工程(Context Engineering):比提示词更重要
一句反直觉的话
2026 年大家越来越意识到:相比"写好提示词","提供好上下文" 更重要。
什么意思?同一个提示词:
- 没有任何上下文 → 输出 60 分。
- 喂了相关知识库 → 输出 75 分。
- 喂了相关知识库 + 历史对话 + 用户画像 → 输出 90 分。
模型再聪明,也只能在"它知道的事情上"做推理。给它越多"它该知道的事情",输出就越准。
Coze 里如何"上下文工程"
| 上下文来源 | Coze 里怎么实现 | 本书章节 |
|---|---|---|
| 私域文档 | 知识库 | 第五章 |
| 实时数据 | 插件(搜索 / 爬虫 / API) | 第六章 |
| 历史对话 | Coze 默认带,会话记忆 | 后文 |
| 用户偏好 | 数据库 / 变量 | 后文 |
| 多步骤推理 | 工作流 | 第七章 |
记住一句话:
当你的 Bot 输出不好时,先问"是不是我没给它足够的上下文",再问"是不是我提示词没写好"。
七、提示词的 7 个常见反模式(请避免)
反模式 1:太短
你是写作助手,帮我写文案。
20 字搞定,结果飘忽不定。
反模式 2:太长(500 字以上)
提示词太长会"信息淹没",模型反而抓不住重点。控制在 200-400 字最好。
反模式 3:要求互相矛盾
要简洁,但要有详细分析。
要严肃,但要活泼。
模型会困惑。先想清楚自己要什么,再写。
反模式 4:用否定句过多
不要太长。
不要用敏感词。
不要说错。
不要重复。
模型对"不要"的理解不如"要"。改成正向描述:
保持简洁(200 字以内)。
使用正面、温暖的措辞。
回答前请自检准确性。
确保每段不重复。
反模式 5:缺少示例
只描述、不给例子,AI 容易理解偏。关键场景一定要给 1-3 个 Few-Shot 示例。
反模式 6:忘了"输出格式"
不写格式,AI 就自由发挥——一会儿是 JSON,一会儿是 Markdown,一会儿是纯文本。在工作流里这是灾难,下游节点会解析失败。
反模式 7:把"工具调用规则"忘掉
如果 Bot 配了插件或工作流,必须告诉模型"什么时候用工具",否则它会"凭脑补",懒得调用。
# 工具调用规则
- 用户问最新数据时,必须调用 [搜索插件],不要自己编。
- 用户问公司政策时,必须先查 [HR 知识库],没找到才说"不知道"。
八、Coze 提示词的 3 个特有技巧
技巧 1:用变量
Coze 提示词里可以用 {{变量名}} 引用变量。例如:
你正在和 {{user_name}} 对话,TA 的账号等级是 {{user_level}},是 VIP 用户请使用更尊敬的语气。
这些变量可以从用户输入、会话状态、数据库里读取。新手现在不用学,记住"有这玩意"就行,第七章 会用到。
技巧 2:人设与"开场白"分开写
Coze 里"开场白"是 Bot 启动时主动说的第一句话,不要写在人设里。在编辑页右侧有专门的"开场白"输入框。
好的开场白模板:
你好!我是 {你的角色},可以帮你 {核心能力 1、2、3}。
你可以这样问我:
- "{示例问题 1}"
- "{示例问题 2}"
- "{示例问题 3}"
或者直接告诉我你的需求 👇
开场白能极大降低用户"不知道怎么用"的困惑。
技巧 3:用 Markdown 增强可读性
Coze 输出支持 Markdown 渲染(标题、列表、代码块、表格)。在提示词里主动告诉模型"用 Markdown",输出更易读:
# 输出格式
请用 Markdown 输出,结构如下:
## 一、核心结论
(一句话概括)
## 二、详细分析
- 要点 1
- 要点 2
- 要点 3
## 三、行动建议
| 优先级 | 行动 | 预估耗时 |
| --- | --- | --- |
| 高 | … | … |
九、提示词调试 5 步法
写完提示词不要立刻发布,按这 5 步调一调:
- 样本测试:准备 5-10 个典型用户输入,依次跑一遍。
- 对比检验:手动写一份"理想答案",对比模型输出的差距。
- 迭代优化:找出最差的输出,反推"提示词漏了什么",补上。
- 极端测试:故意输入"恶意问题、空输入、超长输入",看 Bot 怎么处理。
- 回归测试:每次改提示词后,所有样本都重跑一遍——避免改 A 坏 B。
5 步法做完,你的 Bot 才算"上线就绪"。
十、本章一图回顾
好提示词 = PRACT 五要素
Persona 角色
Rule 规则
Action 任务
Context 背景
Template 输出格式
进阶技巧:
CoT 让 AI 先思考再答(复杂任务用)
Few-Shot 给 AI 看 2-5 个示例(关键场景用)
更上一层:
Context Engineering > Prompt Engineering
= 知识库 + 插件 + 历史对话 + 用户画像 + 工作流
一起喂给 AI
调试 5 步:
样本测试 → 对比检验 → 迭代 → 极端测试 → 回归
十一、避坑清单
- ❌ 不要写完提示词不测就上线。至少跑 5 个样本。
- ❌ 不要"提示词写得越长越好"。200-400 字最佳。
- ❌ 不要忘了示例。Few-Shot 的力量是描述的 10 倍。
- ❌ 不要用否定句堆砌。正向描述更有效。
- ❌ 不要忘了上下文。先问"AI 知不知道这件事",再问"AI 会不会做这件事"。
十二、下一步
提示词学完了。但提示词只能告诉 AI"做什么"和"怎么做",做不到给 AI"知识"。
下一步要学的就是 Coze 的杀手锏之一——知识库。它能把你的私域文档(公司 SOP、产品手册、个人笔记)变成 AI 的"专属大脑"。