3. 提示词框架
CO-STAR 框架
CO-STAR 由数据科学家 Sheila Teo 提出,在 2023 年新加坡首届 GPT-4 提示词工程大赛中夺冠。它的设计哲学是:把提示词当成一份"创意简报"(creative brief)来写。
广告公司给设计师下需求时,从来不会只说"做个海报",而是会给完整的简报:项目背景、商业目标、视觉风格、品牌语气、目标受众、交付物形式。CO-STAR 把这套思维方式移植到了提示词上。
六个维度详解
Style vs Tone 的区别:
- Style 是"怎么写":海明威风格、学术风格、新闻报道风格、博客随笔风格
- Tone 是"什么情绪":温暖、严肃、幽默、紧迫、亲密、专业
举例:同一篇道歉信
- Style 可以是"商务正式",Tone 可以是"诚恳但不卑微"
- Style 也可以是"私人书信",Tone 可以是"愧疚而恳切"
示例一:职场场景 — 给老板写项目延期邮件
# CONTEXT
我是一名产品经理,负责一个 B2B SaaS 产品的支付模块重构项目。
项目原定 11 月 30 日上线,因为支付服务商接口变更,需要延期 2 周。
我已经向团队确认过新的交付日期。我的老板是 CTO,风格务实、讨厌长篇大论。
# OBJECTIVE
写一封邮件向 CTO 说明延期,核心目标:
1. 让他在 30 秒内理解发生了什么
2. 让他相信团队完全掌控局面
3. 避免后续追加问询
# STYLE
商务正式,但简洁直接,接近备忘录(memo)风格。
# TONE
冷静、专业,不卑不亢。不要过度道歉,不要找借口。
# AUDIENCE
CTO,技术背景出身,关注交付确定性而非过程细节。
# RESPONSE
邮件正文不超过 150 字,包含:
- 一句话说明延期事实
- 一句话说明原因
- 一句话说明新的交付日期和缓解措施
- 不需要寒暄和签名
示例二:内容创作场景 — 公众号文章
# CONTEXT
我运营一个聚焦"职场新人成长"的公众号,粉丝主要是 22-28 岁、工作 1-3 年的白领。
最近想写一篇关于"如何在会议上发言"的文章。
我之前的爆款文章都有一个特点:用一个真实故事开头,然后总结方法论。
# OBJECTIVE
写一篇 1500-1800 字的公众号文章,主题是"职场新人如何在会议上有效发言"。
要让读者读完后:(1) 觉得"这就是我",(2) 至少记住 3 个可立即实践的技巧。
# STYLE
故事开头 + 方法论结尾。语言口语化,多用短句。
模仿"半佛仙人""粥左罗"类的公众号风格,但更温和、不要太刻薄。
# TONE
像一个前辈在分享经验,亲切、有共鸣感,偶尔自嘲。
绝对不要"高高在上"或"说教式"。
# AUDIENCE
22-28 岁的职场新人,在会议上不敢发言、发言效果差,有自我提升意愿但缺乏方法。
# RESPONSE
- 1500-1800 字
- 结构:开头故事(300字)+ 3 个核心技巧(每个 400 字左右,含小标题、案例、可操作步骤)+ 结尾金句
- 给出 5 个标题候选,每个不超过 25 字
- 推荐 3 个适合的 emoji 用于文末
示例三:日常生活场景 — 给房东写涨租谈判信
# CONTEXT
我在上海租房 2 年,合同 12 月底到期。房东今天发消息说要涨租 800 元/月(从 6500 涨到 7300)。
我了解过周边同户型行情是 6800-7000。我不想搬家(刚装修过,公司近)。
房东是个 50 岁左右的阿姨,平时关系还不错,但比较强势。
# OBJECTIVE
让房东接受我提出的涨幅 200 元/月(涨到 6700),并续签 1 年。
不能让她觉得我在威胁要搬走,也不能显得软弱。
# STYLE
微信消息体,口语化,但有逻辑。分成 2-3 条发,不要一长段。
# TONE
真诚、理性,带一点恰到好处的"为难"。避免冷冰冰的列数据,也避免过度卖惨。
# AUDIENCE
50 岁强势型女房东,吃软不吃硬,在意"被尊重"和"长期关系"。
# RESPONSE
- 3 条微信,每条 50-100 字
- 第一条:表达续租意愿 + 简单提周边行情
- 第二条:给出我的方案(涨 200)+ 简单理由
- 第三条:表达对未来关系的期待,留出谈判空间
CO-STAR 的常见错误
Style 和 Tone 写成一样的
正确写法:
# STYLE
学术论文风格,严谨、引用充分
# TONE
客观中立,避免主观判断
Audience 写得太宽泛
这等于没写。改成:
# AUDIENCE
30-45 岁的传统行业管理者,听说过 ChatGPT 但没系统用过,
担心 AI 取代自己,但又不想被时代抛下。
Objective 写成任务而非目标
这是任务,不是目标。目标应该是任务完成后产生的效果:
# OBJECTIVE
写一篇文章,让读者读完后愿意主动分享给同事,
并在文末点击订阅按钮(订阅转化率目标 5%)。
Response 不限制长度
未指定长度时,模型倾向于以"详尽"为默认策略,输出可能远超预期。务必明确长度约束,使用"不超过 X 字"或"X 至 Y 字"的精确区间。
RTF 框架
RTF 由三个核心要素构成:Role(角色)+ Task(任务)+ Format(格式)。
作为最精简的提示词框架,RTF 以最少的字段覆盖最关键的三个维度,足以应对大多数日常场景。其设计哲学是:以最低的认知成本,捕捉提示词中最容易被忽略的三个核心问题。
这三个维度分别对应三类典型缺陷:
- Role:界定模型的身份定位,直接影响回答的知识深度、专业视角与措辞风格。
- Task:明确任务本身,避免指令模糊导致输出偏离。
- Format:约束输出形态,规避格式失控与长度膨胀。
适用场景
- 日常快速提问,无需复杂背景铺垫
- 任务边界清晰,上下文要素较少
- 不希望投入大量时间编写长提示词
- 测试与探索阶段:先用 RTF 快速验证可行性,再视需要升级至 CO-STAR 等更精细的框架
示例一:技术问题
角色:资深 Python 开发工程师,有 10 年后端经验。
任务:解释什么是 Python 的 GIL(全局解释器锁),以及它对多线程性能的影响。
格式:300 字左右,先说"是什么",再说"为什么有",最后说"实际开发中怎么应对"。
示例二:写作场景
角色:擅长写产品文案的资深营销总监。
任务:为一款"售价 199 元、容量 800ml、能用 24 小时保温的智能水杯"写电商详情页主标题。
格式:5 个候选标题,每个不超过 20 字,突出"24 小时保温"这个卖点。
示例三:决策辅助
角色:有 15 年经验的产品经理。
任务:我们 SaaS 产品在用户引导环节流失率 60%,帮我分析可能的原因。
格式:列出 5 个最可能的原因,按可能性从高到低排序,每个原因 1 句话说明 + 1 句话验证方法。
RTF 的常见错误
Role 写得太泛
"专家"是什么领域?什么深度?应该写:
角色:专注 SaaS 行业 10 年的资深增长产品经理,操盘过 3 个 ARR 千万美金级产品。
Task 同时塞多个任务
任务:帮我写一篇文章,同时给我几个标题,再列一下营销渠道。
RTF 是"一个任务"的框架,多任务请用 CO-STAR 或拆成多个提示词。
Format 写成"详细一点"
"详细"是主观的。应该写:
格式:800-1000 字,分 3 个小标题,每个小标题下有具体案例。
BROKE 框架
BROKE 由五个要素构成:Background + Role + Objective + Key Result + Evolve(背景 + 角色 + 目标 + 关键结果 + 演进)。
它的核心特色是借用了 OKR(Objectives and Key Results)管理框架的思想,把"目标"和"可衡量的关键结果"分开,强制思考"什么样的输出才算成功"。此外,Evolve 字段引入了"迭代意识"——提示词不是一次性产出,而是需要持续优化的过程。
五个维度详解
核心区别(Objective vs Key Result):
- Objective 是方向("我要写一篇有传播力的文章")
- Key Result 是标准("文章不超过 1500 字、有 3 个核心观点、包含 1 个真实案例")
示例一:产品发布稿
# Background(背景)
我们是一家做企业级数据分析 SaaS 的创业公司,本月即将发布 3.0 大版本,
最大的新功能是"AI 自动生成洞察报告"。
我们的目标客户是 200-1000 人规模的中型企业 CFO 和数据分析主管。
上个版本发布时新闻稿反响一般,主要被吐槽"营销味太重,缺乏技术信息"。
# Role(角色)
扮演一位有 10 年 B2B 科技公司 PR 经验的资深公关总监,
擅长在专业性和传播性之间找平衡。
# Objective(目标)
撰写一篇新版本发布的官方新闻稿,目标是让目标客户看完后愿意点击预约 Demo。
# Key Result(关键结果)
- 全文 800-1000 字,中文
- 必须包含 3 个核心新功能的具体说明(不能只是营销话术)
- 必须包含 1 段 CFO 视角的引用语录(可虚构,但要符合行业用语)
- 必须包含 1 个量化的客户价值数据(如"分析效率提升 X 倍")
- 结尾必须有明确的 CTA(行动召唤)
# Evolve(演进)
在给出新闻稿后,请额外提供 3 个改进方向:
- 哪些段落可以更技术化以提升专业度
- 哪些表达可能被读者认为"营销味重"
- 标题可以如何优化以提升打开率
示例二:学习计划制定
# Background(背景)
我是一名 28 岁的产品经理,工作 5 年。最近 AI 浪潮让我焦虑,
我想系统学习"AI 产品经理"必备的技术知识。
我没有编程基础,但学过基础统计学。每周可投入 8-10 小时学习。
# Role(角色)
扮演一位既懂技术又懂产品的资深 AI 产品教练,
带领 100+ 名传统 PM 转型 AI PM。
# Objective(目标)
为我制定一份 3 个月的 AI 产品经理学习计划,
让我能在团队的 AI 产品讨论中有专业话语权。
# Key Result(关键结果)
- 计划分为 12 周,每周有明确学习主题
- 每周列出:必读资源(3-5 个)+ 实践任务(1 个)+ 输出物(博客/笔记/Demo)
- 必须覆盖 4 个领域:LLM 基础、Prompt 工程、AI 产品设计、数据评估
- 每周时间投入控制在 8-10 小时
- 第 12 周结束时,我应能独立写出一份 AI 产品 PRD
# Evolve(演进)
计划给出后,请额外指出:
- 3 个最常见的"半途而废点"以及如何避免
- 如果我中途因工作太忙落下 2 周,如何快速追赶
- 学习过程中应该追踪哪些指标来判断自己是否真的进步了
示例三:商业决策分析
# Background(背景)
我经营一家有 30 人的设计公司,在二线城市。
最大客户(年合同 200 万,占营收 25%)突然提出降价 20%,理由是"经济形势不好"。
拒绝可能丢单,接受会让其他客户跟进要求降价。
# Role(角色)
扮演一位有 20 年 B2B 服务行业经验的战略顾问,
擅长处理大客户谈判和定价策略。
# Objective(目标)
帮我分析这次降价请求,给出一个既能保住客户又能稳住价格体系的应对策略。
# Key Result(关键结果)
- 给出 3 种可行策略(从"硬扛"到"接受"的光谱中各选一种)
- 每种策略包含:具体话术 + 风险评估 + 成功概率估计
- 必须包含一个"如何避免其他客户跟进降价"的具体方法
- 最后给出你推荐的策略,以及理由
# Evolve(演进)
在策略给出后,请额外补充:
- 谈判前我应该准备哪些信息和数据
- 如果客户依然坚持降价,如何优雅地结束这次合作
- 这件事反映出我的客户结构有什么风险
BROKE 的常见错误
Objective 和 Key Result 不分
# Objective
写一篇好的新闻稿
# Key Result
写一篇好的新闻稿
两个字段写一样,等于没用上 BROKE 的核心特色。正确做法是 Objective 描述方向,Key Result 列具体的可衡量标准。
Evolve 写成"请尽量改进"
"优化"太抽象。Evolve 应该指明改进的具体维度:
# Evolve
- 哪些表达可能让目标读者不信任
- 哪些数据可以更具体
- 标题有什么优化空间
Background 写得太短
BROKE 的核心是"思考全面",Background 一句话带过会让模型只能基于通用知识回答。要把场景、约束、历史尝试都讲清楚。
用 BROKE 做简单任务
# Background
我饿了
# Role
你是营养师
# Objective
推荐午餐
# Key Result
列出 3 个选项
# Evolve
告诉我哪个最健康
此类场景使用 RTF 三个字段即可完成,套用 BROKE 属于过度设计。
ICIO 框架
ICIO 由四个要素构成:Instruction + Context + Input Data + Output Indicator(指令 + 上下文 + 输入数据 + 输出指示)。
它的设计哲学非常"工程化",把提示词拆解成函数式的四个部分:指令(做什么)+ 上下文(为什么)+ 输入数据(基于什么)+ 输出指示(产出什么样)。
这种结构特别适合有具体输入材料的任务——比如分析一份文档、改写一段文字、处理一份数据。它和 BROKE、CO-STAR 的核心区别在于:ICIO 显式区分了"输入数据"和"上下文",这两者在其他框架里往往是合并在 Context 字段里的。
四个维度详解
核心区别(Context vs Input Data):
- Context 是"为什么做这件事"——目的、场景、约束
- Input Data 是"基于什么做这件事"——具体的文本、数据、文档
这种拆分让模型不会把"背景信息"和"待处理材料"搞混。
示例一:文档分析
# Instruction(指令)
分析以下用户反馈,提炼出影响最严重的 3 个产品问题,
并对每个问题评估优先级。
# Context(上下文)
我是一款笔记类 App 的产品经理,App 上线 6 个月,有 5 万活跃用户。
最近一个月差评激增,1 星评论从每周 20 条涨到 80 条。
我需要快速判断该优先修复什么。
# Input Data(输入数据)
以下是过去一周从 App Store、安卓市场、用户社群整理的 50 条负面反馈:
[1]"同步太慢了,等了 10 分钟还没好"
[2]"我的笔记又丢了!这是第三次了!"
[3]"新版界面太丑,以前那个干净多了"
[4]"搜索功能完全不能用,找不到我要的笔记"
[5]"登录总是失败,提示网络错误但我 WiFi 正常"
……(共 50 条)
# Output Indicator(输出指示)
- 用 Markdown 表格输出,列:问题 | 出现频次 | 严重程度(高/中/低) | 修复优先级(P0/P1/P2)
- 表格下方用 200 字总结你的判断逻辑
- 最后给出一句话的整体行动建议
示例二:文字改写
# Instruction(指令)
将以下技术文档改写成面向非技术人员的科普文章。
# Context(上下文)
我在做一家区块链公司的市场总监,需要向投资人(传统金融背景,不懂技术)
介绍我们的产品。技术团队写的文档充斥术语,投资人看了三页就放弃了。
我需要一份能让投资人愿意读完的版本。
# Input Data(输入数据)
[原技术文档]
我们的协议基于零知识证明(ZKP)架构,采用 zk-SNARKs 实现链下计算的链上验证。
通过递归证明压缩技术,可将多笔交易的证明聚合为单个证明,
TPS 理论上限可达 10000+。Gas 费比 L1 降低约 95%。
共识机制采用 PoS,验证者通过质押 TOKEN 参与出块,
每个 epoch 随机选择验证者集合,Slot 时间 12 秒。
……
# Output Indicator(输出指示)
- 500-700 字
- 不能出现 ZKP、SNARK、TPS、Gas、PoS、epoch、slot 等技术术语
如果一定要用,必须用类比解释(如"像高速公路收费站")
- 必须包含至少 3 个生活化的类比
- 文章结尾要让投资人想了解"这能赚钱吗"
示例三:数据整理
# Instruction(指令)
将以下杂乱的客户信息整理成结构化的销售跟进表。
# Context(上下文)
我是 B2B 销售经理,团队有 5 个人,大家平时把客户信息存在微信聊天记录里。
现在需要把过去 3 个月的沟通记录整理出来,做月度复盘。
我需要一份清晰的表格,让我能快速看出哪些客户值得继续跟进。
# Input Data(输入数据)
[聊天记录摘录]
- 5 月 3 日,联系了 A 公司的张总,介绍了我们的产品,他说要内部讨论一下,
下周回复。后来一直没回。A 公司是制造业,500 人规模,在杭州。
- 5 月 7 日,B 公司王经理主动联系,问报价。我发了报价单,
他说价格偏高,要再考虑。B 公司是金融,200 人,上海。
- 5 月 15 日,C 公司李总同意试用 1 个月,试用期到 6 月 15 日结束。
C 公司是医疗,1000 人,北京。
- 5 月 20 日,D 公司刘总明确拒绝,说预算砍了。D 公司零售业,300 人,深圳。
- 6 月 1 日,B 公司王经理又来问,说预算下来了,但只有原报价的 70%。
……
# Output Indicator(输出指示)
- 用 Markdown 表格输出
- 列:公司 | 联系人 | 行业 | 规模 | 地区 | 最新状态 | 推进阶段 | 跟进建议 | 优先级
- 推进阶段分为:首次接触 / 报价中 / 谈判中 / 试用中 / 已成单 / 已流失
- 优先级分为:高 / 中 / 低
- 表格下方用 100 字总结整体情况(共多少客户,几个高优先级,建议本周重点跟进谁)
ICIO 的常见错误
Context 和 Input Data 不分
把所有背景信息都堆在 Context 里,Input Data 留空,或者反过来。这样就失去了 ICIO 的核心价值。
正确的判断标准是:
- 会被 AI"处理"的原材料 → Input Data
- 帮 AI 理解"为什么做这件事"的信息 → Context
Input Data 给得不完整
# Input Data
以下是用户反馈:
[反馈 1]
[反馈 2]
……
模型不知道省略号代表什么,会自己脑补或忽略。Input Data 必须是完整的真实数据,不能用占位符代替。
Output Indicator 太笼统
# Output Indicator
输出一份分析报告
"分析报告"是什么形式?长度?有哪些章节?改成:
# Output Indicator
- Markdown 格式
- 包含:摘要(100 字)+ 三个主要发现(每个 200 字)+ 行动建议(列表)
- 总长度 1000-1200 字
Instruction 写成大而空的目标
"做"是什么动作?分析?整理?可视化?预测?Instruction 必须用具体动词:
# Instruction
对以下销售数据进行同比分析,识别出销售下滑最严重的 3 个产品线,
并推测可能的原因。
COT 框架
Chain-of-Thought(CoT,思维链)不是一个填空式框架,而是一种触发模式。它的核心是:让模型在给出最终答案前,显式写出推理步骤。
三种触发方式
方式一:零样本 CoT
在提示词末尾加一句魔法话术:
或英文版(在某些模型上效果更好):
Let's think step by step.
这一句话就能让模型显式推理。
方式二:少样本 CoT
提供 2-4 个"问题—推理过程—答案"的示例,让模型模仿推理风格。
方式三:结构化 CoT
明确告诉模型"按以下步骤推理",每一步具体做什么。
示例一:数学推理(零样本 CoT)
小明买了 3 件衣服,每件原价 200 元,商店打 7 折,
此外还有满 500 减 50 的活动。问小明实际花了多少钱?
请按以下步骤思考:
1. 先计算 3 件衣服的原价总和
2. 再计算 7 折后的价格
3. 判断是否满足"满 500 减 50"的条件
4. 给出最终金额
让我们一步步推理。
效果差异:不用 CoT 时,模型可能会算错(比如忘记考虑满减条件的顺序)。用 CoT 后,错误率显著下降。
示例二:商业决策分析
你将帮我分析商业决策。请参考以下示例的推理方式:
【示例 1】
问题:我们要不要进入 X 市场?
推理:
- 市场规模:X 市场年规模 50 亿,增速 15%,值得进入
- 竞争格局:有 3 个头部玩家占 60% 份额,但都是传统打法
- 我方优势:我们有差异化技术,可以切中头部玩家的盲区
- 风险:进入成本约 2000 万,占我方现金 30%,需谨慎评估失败后果
结论:有条件进入,建议先用 500 万做 6 个月 MVP 测试
【示例 2】
问题:要不要为某客户做定制开发?
推理:
- 客户价值:年合同额 800 万,占我司营收 5%
- 定制成本:估算 3 个月工程师投入 = 150 万,占用核心团队
- 产品影响:定制功能 70% 可以沉淀为通用功能,30% 是一次性投入
- 机会成本:这 3 个月本可以做产品 2.0 版本
结论:不接受全部定制,谈判改为"70% 通用化 + 30% 定制",降低 30% 收费
【请分析以下问题】
问题:我们公司目前 50 人,要不要在三线城市设立第二个办公室?
(请按上述示例的推理方式分析)
示例三:复杂写作任务
我需要你写一篇关于"远程工作是否会取代办公室工作"的深度分析文章。
请严格按以下推理步骤进行,每一步都要明确写出:
【步骤 1:定义问题边界】
- 明确"远程工作"指什么(全远程?混合制?自由职业?)
- 明确"取代"的标准(50%以上员工?所有行业?某些岗位?)
【步骤 2:列出关键利益相关方】
- 员工、企业、城市经济、商业地产、家庭关系
- 每个相关方的立场和诉求
【步骤 3:分析支持"取代"的证据】
- 至少 3 个有数据支撑的论据
- 标注数据来源(如盖洛普调查、麦肯锡报告等)
【步骤 4:分析反对"取代"的证据】
- 至少 3 个有数据支撑的论据
- 同样标注来源
【步骤 5:综合判断】
- 给出你的核心论点(不能骑墙)
- 说明在什么条件下你的论点成立
- 指出你的论点的局限性
【步骤 6:输出最终文章】
- 基于以上分析,写一篇 1500 字文章
- 必须有明确立场,不能"两边都对"
CoT 的常见错误
错误一:不必要的 CoT 浪费 token
对于简单事实性问题:
这是浪费。CoT 适合需要多步推理的任务,简单问题直接问即可。
错误二:CoT 步骤设计不合理
太抽象。模型会自己编步骤,但可能漏掉关键维度。应该明确告诉它有哪些步骤:
请按以下 5 个步骤分析:
1. 市场规模
2. 竞争格局
...
错误三:在带 thinking 能力的模型上多此一举
Gemini 2.5/3、Claude 3.7+、GPT-5 等新一代模型自带"thinking"能力,会自动进行内部推理。在这些模型上,显式要求 CoT 的必要性大幅降低。
对于这些模型,更好的做法是:
- 不需要写"请一步步思考"
- 但可以写"请深入分析这个问题"或"请仔细考虑各种因素"
- 让模型自主决定推理深度
CoT 在以下场景依然有价值:
- 使用没有 thinking 能力的轻量模型(如 Gemini Flash 早期版本)
- 希望看到模型的推理过程(用于调试或学习)
- 复杂任务需要按特定步骤推理
错误四:把 CoT 和其他框架对立
CoT 不是与 CO-STAR、RTF 互斥的,它们可以叠加使用:
# CONTEXT
[CO-STAR 的背景]
# OBJECTIVE
[CO-STAR 的目标]
# 思考步骤
1. 先分析 X
2. 再考虑 Y
3. 综合后给出结论
# RESPONSE
[CO-STAR 的输出要求]
评论
0 条