提示词框架

前两篇提示词工程讲了"它是什么、用在哪些场景、典型应用实例",提示词优化讲了"怎么把烂 prompt 系统化地优化成好 prompt"。这一篇换一个更工程化的角度:当 prompt 从"一段散文"变成"反复复用的工程对象"时,我们需要模板,需要框架。本文结构:先讲为什么需要"框架",再讲什么时候该上框架,之后逐个详解当前主流的 9 个提示词框架(定义 + 适用场景 + 完整示例),最后落到"为什么单靠框架已经不够"以及上下文工程的兴起。

1. 背景:为什么需要"框架"

1.1 一句话本质

提示词框架 = 把一段 prompt 拆成固定的几个槽位(角色 / 背景 / 任务 / 风格 / 输出...),让任何人在任何场景下都能按槽填字、稳定产出。

它是"提示词工程"从个人手艺 → 团队工艺的关键一步:有了框架,新人不再靠语感写 prompt,直接填空就能拿到七八十分的初稿。

1.2 没有框架时,prompt 会怎么烂

痛点	现象
每次重写一遍	同一个任务,不同人写出来的 prompt 完全是两套结构,代码里没法复用
关键要素漏写	新人常忘写"风格"或"输出格式",导致模型输出飘忽
规则互相打架	prompt 越长,越容易出现"既要又要还要",模型注意力稀释
不可评测	没有统一骨架,评测集也无从对齐——A 写的 prompt 跟 B 写的根本不是同一回事
难传承	核心工程师离职,他/她写的"魔法 prompt"成为黑盒

框架解决的就是"让 prompt 成为可复用、可评测、可传承的工程对象"。

1.3 框架 ≠ 万能模板

一个常见误解:把框架当成"填空模板",把所有 prompt 都硬塞进去。事实是:

框架是骨架,不是填充物。同一份"角色 + 任务 + 输出"骨架,不同业务的填充细节可以差出十万八千里。
过度框架化 = 形式主义。一段 50 字的小任务,硬套 6 段框架,反而拖慢迭代。
框架要按场景挑。客服场景适合"角色 + 边界 + 工具",代码生成场景适合"输入 + 步骤 + 示例",分析场景适合"背景 + 任务 + 输出格式"——不是所有框架都适合所有任务。

2. 场景:何时该上框架

框架的性价比随任务复杂度变化。下表是经验法则。

任务类型	是否上框架	用哪种
单次、一次性的小问答	❌ 不必	直接自然语言即可
固定业务模板(周报 / 总结 / 邮件)	✅ 必上	选最轻的(APE / TAG)
多角色、多边界的客服 / 助手	✅ 必上	CRISPE / CO-STAR / LangGPT
多步骤推理 / Agent 工具调用	✅ 必上	BROKE / RISE / LangGPT
多团队、多人协作维护的 prompt 库	✅ 必上	LangGPT(模块化)
长上下文、含 RAG 检索	⚠️ 部分上	在骨架上加 `<retrieved>` `<question>` 等占位区
纯创意 / 探索性对话	❌ 不必	框架反而约束了发散

经验法则:

prompt 越是要被"多人复用 / 多次迭代 / 进入版本控制",就越值得上框架;反之,一次性问答不必硬上。

3. 主流框架详解

下面逐个详解当前社区里 9 个主流框架。每个框架给:定义 → 适用场景 → 一个完整可执行示例。示例可以直接复制改造。

3.1 CRISPE(Matt Nigh)

来源:GitHub mattnigh/ChatGPT3-Free-Prompt-List 仓库。CRISPE 是六大主流英文框架里出现最早、引用最广的一个。

首字母含义:

字母	含义	作用
CR	Capacity and Role(能力与角色)	让模型扮演某个具体角色
I	Insight(洞察)	给任务提供背景信息、上下文
S	Statement(陈述)	明确说出"你要做什么"
P	Personality(个性)	锁定回复的风格 / 语气
E	Experiment(实验)	让模型给出多个示例 / 多版本回答

适用场景:复杂业务角色扮演、需要多种回答候选的创意类任务。

示例:让模型给出 3 个备选营销文案

text

# Capacity and Role
你是一位"消费电子品类"资深营销文案策划,有 8 年 Apple / Dyson / 小米生态链文案经验。

# Insight
- 产品:无线降噪耳机 X3
- 卖点:主动降噪 40dB、续航 30 小时、Hi-Res 金标、首发价 ¥899(原价 ¥1299)
- 受众:25-35 岁城市白领,通勤为主,日常办公 + 出差场景
- 平台:小红书图文笔记

# Statement
请基于以上信息,撰写 3 个不同角度的小红书笔记标题 + 开头 50 字。

# Personality
- 风格:小红书"种草"体,亲切、可信、可量化
- 避免:夸张的"绝绝子"、过度使用 emoji

# Experiment
请给 3 个不同切入角度(性价比 / 场景痛点 / 技术背书),每个角度一组。

3.2 BROKE(社区,受 OKR 启发)

来源:社区方法,灵感来自 OKR(Objectives and Key Results)。它把"目标管理"思路搬到 prompt 设计里。

首字母含义:

字母	含义	作用
B	Background(背景)	任务背景、约束、已知信息
R	Role(角色)	让模型扮演的具体角色(尽量具体,不要只写"专家")
O	Objectives(目标)	具体、可执行、可量化的目标
K	Key Results(关键结果)	期望的交付格式、长度、结构、验收标准
E	Evolve(演进)	让模型自我审视 / 提出后续优化建议

适用场景:产品 / 运营类需求,目标导向、强调交付物形态。

示例:设计 Gen-Z 健身 App 的 MVP 核心流程

text

# Background
我们正在开发一款面向 Gen-Z 的"AI 健身搭子"社交 App。MVP 阶段预算 1 个前端 + 1 个后端 + 2 个月时间。核心差异化是"AI 实时陪练 + 短视频打卡 + 挑战赛"。

# Role
你是一位有 3 年互联网健康赛道经验的产品经理,熟悉 Keep / 咕咚 / Strava,擅长 MVP 范围控制。

# Objectives
为 MVP 设计"用户从注册到发起第一次挑战赛"的核心流程图。

# Key Results
- 流程节点 8-12 个
- 标注每个节点的"成功判定 + 失败回退"
- 用 Mermaid flowchart 语法输出
- 至少标出 5 个关键决策点(分支判断)

# Evolve
- 流程图若超过 12 个节点,请自动合并同类项
- 输出完毕后,另起一段给出"3 条可能让流程更短的简化建议"

3.3 CO-STAR(Sheila Teo,新加坡 GPT-4 比赛获奖)

来源:Sheila Teo 在 2023 年新加坡 GPT-4 Prompt Engineering Competition 中凭此结构获奖,后被广泛传播。

首字母含义:

字母	含义	作用
C	Context(上下文)	任务背景、用户场景
O	Objective(目标)	明确要完成的任务
S	Style(风格)	想要的写作风格(学术 / 口语 / 新闻)
T	Tone(语气)	情感色彩(正式 / 共情 / 幽默)
A	Audience(受众)	谁会读这段输出
R	Response(响应格式)	输出形态(JSON / 表格 / 段落 / 列表)

适用场景:对"风格 + 受众"敏感的内容任务——营销 / 公关 / 教育 / 公文。

示例:为 SaaS 产品起草一封客户教育邮件

text

# Context
我们的 SaaS 产品"灯塔报表"刚上线了"自助数据导出"功能。目标客户是中小电商的运营负责人,他们过去一直依赖客服手工出报,响应慢、错率高。

# Objective
写一封"功能上线通知 + 引导首次使用"的客户教育邮件。

# Style
简洁、克制、技术可信;段落短,避免营销腔。参考 Stripe / Notion 的"功能发布邮件"风格。

# Tone
专业但不冷,带一点"我们知道你之前在等这个"的共情。

# Audience
中小电商的运营负责人(30-45 岁,有一定数据基础,但不写 SQL)。

# Response
- 主题行 1 个(20 字以内)
- 开头 2-3 行(说明价值)
- 功能亮点 3 条(每条一行,带具体数字)
- "立即试用"按钮文案 1 句
- 落款(产品名 + 团队署名)

3.4 RTGO(社区)

首字母含义:

字母	含义	作用
R	Role(角色)	模型扮演的角色
T	Task(任务)	要完成的具体任务
G	Goal(目标)	这次任务的最终目的
O	Output(输出)	输出格式 / 形态

适用场景:极简、聚焦"做什么"的快速任务。RTGO 是 6 字母框架(CRISPE / CO-STAR)里最精简的一个。

示例:把一段会议录音转写稿润色成纪要

text

# Role
你是一位"互联网公司"行政助理,擅长把口语化的会议转写整理成结构化会议纪要。

# Task
基于下方 `<transcript>` 包裹的会议转写稿,整理成会议纪要。

# Goal
让"没参加这次会议的同组同事"读完后能清楚知道:讨论了什么、决定了什么、谁负责什么、什么时候交付。

# Output
- 必含四段:会议主题 / 关键讨论点(按议题分组)/ 决议与负责人(含 deadline)/ 遗留问题
- 输出格式:Markdown,二级标题用 `##`
- 长度:500-800 字
- 不要输出转写原文、不要输出"未明确"之类的占位

<transcript>
{{MEETING_TRANSCRIPT}}
</transcript>

3.5 RISE(社区)

首字母含义:

字母	含义	作用
R	Role(角色)	模型扮演的角色
I	Input(输入)	任务输入 / 上下文 / 数据
S	Steps(步骤)	推理 / 操作步骤(显式 CoT)
E	Expectation(期望)	输出格式 / 验收标准

适用场景:多步骤推理任务、Agent 工具调用、需要"分步走"的复杂任务。

示例:让模型帮用户排查一个 Linux 服务器故障

text

# Role
你是一位有 10 年 SRE 经验的 Linux 故障排查专家,擅长从有限线索快速定位根因。

# Input
- 服务器:CentOS 7.9,跑了 3 年
- 现象:从昨天 18:00 起,业务反馈 HTTP 502 比例上升到 15%(平时 0.5%)
- 当前已知信息:
  - `top` 显示 CPU 30%,内存 60%,负载 2
  - `df -h` 显示磁盘使用率 80%(根分区)
  - `dmesg` 没有 OOM 记录
  - nginx error log 最近 1 小时出现大量 "connect() failed (110: Connection timed out) while connecting to upstream"

# Steps
请按下面顺序排查,并在每一步给出命令 + 期望看到的结果:
1. 检查 upstream(后端 Java 应用)的健康状态
2. 检查网络连接性
3. 检查文件句柄 / 进程数
4. 给出最可能的 3 个根因 + 验证方法

# Expectation
- 输出:Markdown,含"命令 / 期望输出 / 当前观察"三列表格
- 最后一段给出"按可能性排序的 3 个根因假设 + 各自的验证步骤"

3.6 LangGPT(中文社区,模块化结构化提示词)

来源:中文 LLM 社区推动的"结构化提示词语言",用 Markdown 标题层级天然表达"角色 / 规则 / 工作流 / 示例"等模块,工程化程度最高。

核心结构:

text

# Role: <角色一句话>

## Profile
- author: <作者>
- version: <版本号>
- language: <语言>
- description: <角色详细描述>

## Skills
- <技能 1>
- <技能 2>
- ...

## Rules
- <规则 1>
- <规则 2>
- ...

## Workflow
1. <步骤 1>
2. <步骤 2>
3. ...

## Initialization
<开场白 / 第一句话>

适用场景:

多人协作维护的 prompt 库(版本号 + author 让"谁改过"清晰可查)
需要把"角色 / 技能 / 规则 / 工作流"分开迭代的复杂 Agent
中文场景下的工程化 prompt 模板

示例:一个"代码评审员" Agent

text

# Role: 代码评审员

## Profile
- author: twolf
- version: 1.0.0
- language: 中文
- description: 你是一位严格的"代码评审员",对每一次评审都给出可执行、可落地的具体意见,而不是"建议优化"这种废话。

## Skills
- 读懂 Java / Python / Go / TypeScript 四种主流语言的常见反模式
- 识别 N+1、循环里查询、长事务、锁竞争、未关闭资源等性能 / 安全问题
- 给出符合 Google / Alibaba 编码规范的修改建议

## Rules
- 任何评审意见必须包含"问题点 + 改写后代码片段",不接受"建议重构"式空话
- 不重复赞美,只指出问题;若实在没问题,只回"OK"
- 不输出 markdown 二级及以上标题,只用项目符号
- 评审长度 ≤ 200 字 / 函数,超过则按函数分段

## Workflow
1. 读取 `<diff>` 内的代码 diff
2. 按"严重性"排序问题:严重 / 一般 / 风格
3. 每条问题:严重性标签 + 位置 + 改写建议
4. 最后给一行"是否建议合并":merge / revise / reject

## Initialization
请提交你要评审的 diff。

3.7 三个轻量框架(APE / TAG / SPAR)

下面三个适合"任务短、目标明确、不需要 6 段结构"的场景。

3.7.1 APE(Action / Purpose / Expectation)

字母	含义	作用
A	Action(行动)	模型要做什么
P	Purpose(目的)	为什么要做
E	Expectation(期望)	输出形态

示例:

text

# Action
把下方 `<meeting>` 内的会议转写,整理成会议纪要。

# Purpose
让未参会同事快速对齐:讨论了什么、决定什么、谁负责。

# Expectation
- Markdown 格式
- 必含四段:主题 / 讨论 / 决议 / TODO
- 长度 300-500 字

<meeting>
{{TRANSCRIPT}}
</meeting>

3.7.2 TAG(Task / Action / Goal)

字母	含义	作用
T	Task(任务)	任务一句话定义
A	Action(动作)	具体怎么执行
G	Goal(目标)	达成什么标准

示例:

text

# Task
把用户的英语邮件改写成更专业、更简洁的商务邮件。

# Action
1. 保留原意,不增减事实
2. 删掉寒暄(Hi / Hope you are well 等)
3. 把长句拆短,每句 ≤ 20 字
4. 用词从"日常口语"升到"商务正式"

# Goal
- 输出长度比原文减少 20%-40%
- 没有任何语法错误
- 风格接近 Stripe / Linear 客户邮件

3.7.3 SPAR(Situation / Problem / Action / Result)

字母	含义	作用
S	Situation(情境)	当前情境
P	Problem(问题)	遇到的困难
A	Action(行动)	你希望模型做什么
R	Result(结果)	期望产出

示例:

text

# Situation
我是某 SaaS 公司的客服负责人,团队 8 人,日均工单 200。

# Problem
最近两周"功能咨询类"工单占比从 25% 上升到 45%,明显拖慢响应速度;但产品文档已具备 FAQ。

# Action
基于下方 `<faq>` 内的产品 FAQ,设计一个"自动回复 Agent"的 prompt 骨架(不要写代码,只要 prompt 模板)。

# Result
- 输出 Markdown,含"角色 / 触发条件 / 回答规则 / 拒答规则 / 升级人工触发条件"五段
- 不少于 200 字
- 至少 5 条可执行的"拒答规则"

<faq>
{{PRODUCT_FAQ}}
</faq>

4. 框架怎么选:一张速查表

把上面 9 个框架按"完整度 / 适用场景"压缩到一张表,挑选时按行扫即可。

框架	段数	主战场	强度	典型场景
CRISPE	6	角色 + 创意 + 多候选	强	营销 / 创意 / 多版本输出
BROKE	5	目标导向 + 交付物	强	产品 / 运营 / 流程设计
CO-STAR	6	风格 + 受众 + 格式	强	公文 / 邮件 / 内容营销
RTGO	4	极简任务	轻	整理 / 改写 / 摘要
RISE	4	多步推理 + Agent	中	排查 / 工具调用 / 复杂任务
LangGPT	多	模块化 + 多人协作	强	团队级 prompt 库 / Agent 化
APE	3	极简	轻	一次性任务 / 快速验证
TAG	3	风格改写	轻	改写 / 翻译 / 润色
SPAR	4	案例分析	中	咨询 / 设计 / 复盘

怎么挑:

任务是否强调"风格 / 受众"? → CO-STAR
任务是否需要"角色 + 多候选"? → CRISPE
任务是否"目标驱动、有交付物"? → BROKE
任务是否"多步推理 / 调工具"? → RISE
任务是"模块化、要进版本控制"? → LangGPT
任务很轻、几句话能讲完? → APE / TAG / SPAR
任务只是"整理 / 改写"? → RTGO

5. 当前框架法的边界:为什么"单靠框架"已经不够

到这里你应该已经把 9 个主流框架的"骨架"都过了一遍。但作为系列文章的"阶段小结",必须诚实讲清楚一件事:框架法本质上还是 prompt 层面的工程化,它没有解决 LLM 应用里更大的一类问题。

5.1 框架没解决的几件事

框架能做的	框架做不了的
锁定"角色 + 任务 + 风格 + 输出"骨架	决定哪些信息应该进入上下文
让新人快速产出可用 prompt	控制长上下文的信噪比与注意力分配
让 prompt 可复用、可版本化	决定多轮对话里"该记住什么 / 该忘掉什么"
让评测集能对齐"同一份骨架"	处理"什么时候该检索 / 什么时候该调工具 / 什么时候该沉默"

换句话说:框架解决"怎么写 prompt",不解决"prompt 该用什么信息"。 而后者,在真实业务里往往决定了 80% 的输出质量。

5.2 一个真实例子:客服 Agent

一个"客服 Agent"用 CRISPE 写得再漂亮:

角色:"小塔"
边界:不回答范围外问题
工具:get_order_status / track_shipment / estimate_refund
输出:≤ 80 字

但如果上下文里塞了 200 条历史对话、3 篇产品手册、20 个 FAQ,模型注意力立刻被稀释;如果多轮对话里把"用户 3 轮前问过的关键约束"丢了,模型立刻跑偏;如果用户问题模糊时,模型直接猜而不是追问,体验立刻下降。

这些都不是"换一套更好的框架"能解决的。这是**上下文工程(Context Engineering)**的事。

5.3 上下文工程:从"写好 prompt"到"管好上下文"

Anthropic 在 2025 年明确把"Context Engineering"作为继 Prompt Engineering 之后的下一个阶段。它的核心主张是:

不要只优化"你给模型的那段文本"。把"模型在每一步推理时实际看到的全部信息"——系统提示、工具描述、检索结果、对话历史、长期记忆——当作一个整体来设计、剪裁、压缩、注入。

它关心的不是"prompt 怎么写",而是:

该把什么塞进上下文窗口(selection)
该按什么顺序塞(ordering)
该压缩什么、丢弃什么(compression / pruning)
该在什么时候注入新信息(dynamic injection)
该在多轮里保留 / 遗忘什么(memory management)

可以理解为:Prompt Engineering 关心的是"一段话",Context Engineering 关心的是"模型眼前那个完整的世界"。

本系列下一篇会专门讲 Context Engineering——它与本篇的"框架法"是上下衔接关系:框架决定了"骨架",上下文工程决定了"血肉";二者合起来,才是 LLM 应用的完整工程面。

6. 一句话总结

提示词框架是 prompt 工程化的"骨架工具"——CRISPE / BROKE / CO-STAR / RTGO / RISE / LangGPT 等各有侧重,选对框架能让 prompt 从"一段散文"升级成"可复用、可评测、可传承的工程对象";但单靠框架解决不了"该给模型看什么"的问题,这正是下一阶段——上下文工程——要回答的事。

7. 进一步阅读

本仓库相关

提示词工程——框架法的"被作用对象":为什么需要结构化 prompt。
提示词优化——把烂 prompt 系统化优化的 12 条原则与 8 项反模式。
LLM 介绍——理解 LLM 的能力边界,知道哪些事优化 prompt 也救不了。
LLM 工作原理——理解 next-token prediction,有助于理解"为什么这样的 prompt 能起效"。

外部参考

Matt Nigh ChatGPT3-Free-Prompt-List(GitHub)——CRISPE 框架的原始仓库。
Sheila Teo — How I won Singapore's GPT-4 Prompt Engineering Competition(Medium)——CO-STAR 框架的获奖复盘。
LangGPT GitHub 仓库——中文社区推动的模块化结构化提示词语言。
Anthropic — Effective context engineering for AI agents(2025)——上下文工程的代表性论述。
The Prompt Report(Schulhoff et al., 2024)——对提示词技术的系统性综述,含分类与评测。

提示词框架 ​

1. 背景:为什么需要"框架" ​

1.1 一句话本质 ​

1.2 没有框架时,prompt 会怎么烂 ​

1.3 框架 ≠ 万能模板 ​

2. 场景:何时该上框架 ​

3. 主流框架详解 ​

3.1 CRISPE(Matt Nigh) ​

3.2 BROKE(社区,受 OKR 启发) ​

3.3 CO-STAR(Sheila Teo,新加坡 GPT-4 比赛获奖) ​

3.4 RTGO(社区) ​

3.5 RISE(社区) ​

3.6 LangGPT(中文社区,模块化结构化提示词) ​

3.7 三个轻量框架(APE / TAG / SPAR) ​

3.7.1 APE(Action / Purpose / Expectation) ​

3.7.2 TAG(Task / Action / Goal) ​

3.7.3 SPAR(Situation / Problem / Action / Result) ​

4. 框架怎么选:一张速查表 ​

5. 当前框架法的边界:为什么"单靠框架"已经不够 ​

5.1 框架没解决的几件事 ​

5.2 一个真实例子:客服 Agent ​

5.3 上下文工程:从"写好 prompt"到"管好上下文" ​

6. 一句话总结 ​

7. 进一步阅读 ​

本仓库相关 ​

外部参考 ​

提示词框架

1. 背景:为什么需要"框架"

1.1 一句话本质

1.2 没有框架时,prompt 会怎么烂

1.3 框架 ≠ 万能模板

2. 场景:何时该上框架

3. 主流框架详解

3.1 CRISPE(Matt Nigh)

3.2 BROKE(社区,受 OKR 启发)

3.3 CO-STAR(Sheila Teo,新加坡 GPT-4 比赛获奖)

3.4 RTGO(社区)

3.5 RISE(社区)

3.6 LangGPT(中文社区,模块化结构化提示词)

3.7 三个轻量框架(APE / TAG / SPAR)

3.7.1 APE(Action / Purpose / Expectation)

3.7.2 TAG(Task / Action / Goal)

3.7.3 SPAR(Situation / Problem / Action / Result)

4. 框架怎么选:一张速查表

5. 当前框架法的边界:为什么"单靠框架"已经不够

5.1 框架没解决的几件事

5.2 一个真实例子:客服 Agent

5.3 上下文工程:从"写好 prompt"到"管好上下文"

6. 一句话总结

7. 进一步阅读

本仓库相关

外部参考