3. 提示词框架


CO-STAR 框架

CO-STAR 由数据科学家 Sheila Teo 提出,在 2023 年新加坡首届 GPT-4 提示词工程大赛中夺冠。它的设计哲学是:把提示词当成一份"创意简报"(creative brief)来写。

广告公司给设计师下需求时,从来不会只说"做个海报",而是会给完整的简报:项目背景、商业目标、视觉风格、品牌语气、目标受众、交付物形式。CO-STAR 把这套思维方式移植到了提示词上。

六个维度详解

维度含义
C - Context(上下文)任务的背景信息,让模型理解处境
O - Objective(目标)希望达成什么,要可衡量
S - Style(风格)写作的整体风格
T - Tone(语气)情感色彩和语气
A - Audience(受众)输出给谁看
R - Response(响应格式)输出形式(长度、结构、媒介)

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
专业

正确写法:

# STYLE
学术论文风格,严谨、引用充分

# TONE
客观中立,避免主观判断

Audience 写得太宽泛

# AUDIENCE
所有对 AI 感兴趣的人

这等于没写。改成:

# AUDIENCE
30-45 岁的传统行业管理者,听说过 ChatGPT 但没系统用过,
担心 AI 取代自己,但又不想被时代抛下。

Objective 写成任务而非目标

# 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 字段引入了"迭代意识"——提示词不是一次性产出,而是需要持续优化的过程。

五个维度详解

维度含义作用
B - Background(背景)任务的上下文环境、场景、为什么要做这件事让模型理解处境
R - Role(角色)模型应扮演的专业身份确定回答的视角和深度
O - Objective(目标)希望达成的核心目标给模型一个明确方向
K - Key Result(关键结果)可衡量的成功标准、具体的产出形态让"完成"变得可判断
E - 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 应该指明改进的具体维度:

# 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 字段里的。

四个维度详解

维度含义作用
I - Instruction(指令)要 AI 做的具体动作任务的核心描述
C - Context(上下文)任务的背景、目的、场景让 AI 理解"为什么"做这件事
I - Input Data(输入数据)需要 AI 处理的具体内容任务的"原材料"
O - Output Indicator(输出指示)输出的格式、风格、长度等要求限定"成品长什么样"

核心区别(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 必须用具体动词:

# 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
还没有评论,来写第一条吧