别再对着 AI 干瞪眼了：常用 Prompt 框架整理

#AI #Prompt Engineering #LLM #Productivity

框架是死的，但用对了，AI 的回答会活过来。

0 说在前面

用 AI 写代码、查资料、做翻译，到今天已经不是什么新鲜事了。但我发现一个很普遍的现象：很多人和大模型对话的方式，跟在搜索引擎里敲关键词没什么区别。问出来的问题越模糊，得到的答案就越像废话。

Prompt Engineering 这个词已经被说烂了，但真正在日常中用结构化框架来写 Prompt 的人并不多。大部分人的用法还停留在「你帮我写个 XXX」或者「解释一下 XXX」，然后对着一坨不痛不痒的回答摇头。

整理了我接触过的十几个 Prompt 框架，有些确实好用，有些场景比较窄，我会一个一个说清楚它们是什么、怎么用、以及什么时候该用哪个。

1 为什么需要框架

直接说「帮我写一封邮件」和「你是一个资深的商务经理，需要给合作方写一封关于项目延期的致歉邮件，语气正式但不卑不亢，控制在 200 字以内」，得到的结果差距是巨大的。

框架的本质就是帮你把脑子里模糊的想法，拆成大模型能理解的结构化信息。你给的上下文越完整、约束越明确，模型的输出就越接近你想要的东西。

不用把框架想得太复杂，它就是一个填空模板，帮你在提问之前多想几步。

2 框架详解

2.1 RTF — Role / Task / Format

最简单的框架，三个字段，适合日常快速使用。Role 定角色，Task 说任务，Format 定格式，没了。

示例：

Role: 你是一个高级前端工程师
Task: 帮我审查以下 React 组件的性能问题，并给出优化建议
Format: 用编号列表输出，每条包含问题描述和修改方案

RTF 的好处是门槛极低，对于大部分日常对话已经够用。缺点是缺少上下文和约束，复杂任务容易跑偏。

2.2 ROSES — Role / Objective / Scenario / Expected Solution / Steps

比 RTF 更完整的版本，多了场景描述和期望步骤。先说你要 AI 当什么 Role，再说 Objective 目标，然后描述当前 Scenario 是什么情况，接着告诉它你期望什么样的 Expected Solution，最后拆一下 Steps 让它分步走。

示例：

Role: 你是一个 DevOps 工程师
Objective: 帮我排查生产环境 Kubernetes Pod 频繁重启的问题
Scenario: 一个 Node.js 服务在部署后每隔 5 分钟 OOMKilled，内存 limit 设置为 512Mi
Expected Solution: 给出排查思路和可能的解决方案
Steps: 1. 先分析可能的原因 2. 给出排查命令 3. 根据不同原因给出对应修复方案

ROSES 适合技术类问题，尤其是排查和方案设计类的场景，结构清晰，AI 回答的层次感会好很多。

2.3 CO-STAR — Context / Objective / Style / Tone / Audience / Response

新加坡 GovTech 团队推广的框架，在 2024 年的一次 Prompt Engineering 竞赛中拿了第一名后火了一阵。六个字段分别管六件事：Context 交代背景，Objective 明确目标，Style 定写作风格（学术、口语、技术文档之类的），Tone 定语气（正式还是轻松），Audience 说清楚写给谁看，Response 规定输出格式。

示例：

Context: 我们公司刚完成一轮融资，需要在社交媒体上发布公告
Objective: 撰写一条 LinkedIn 公告
Style: 专业但不刻板
Tone: 自信、感恩
Audience: 潜在投资人、合作伙伴和求职者
Response: 一段 150-200 字的中文文案，附带 3 个合适的 hashtag

CO-STAR 最大的优势是对「语气」和「受众」的单独拆分，这对于内容创作类任务特别有用。写代码的时候用不太上，但写文案、做翻译、写邮件的时候非常好使。

2.4 CRISPE — Capacity & Role / Insight / Statement / Personality / Experiment

这个框架更偏向于让 AI 进入一个「人格化」的状态。Capacity & Role 先定能力范围和角色，Insight 喂给它一些你知道的背景知识，Statement 说你要它干嘛，Personality 告诉它该用什么样的个性来回答，最后 Experiment 让它多试几种方案。

示例：

Capacity & Role: 你是一个有 10 年经验的技术写作专家
Insight: 目标读者是刚入门的初级开发者，他们可能不了解云原生的概念
Statement: 写一篇关于 Docker 容器化入门的教程
Personality: 耐心、幽默、善于用比喻解释抽象概念
Experiment: 提供两个不同的开头版本让我选择

CRISPE 在需要 AI 产出「有个性的内容」时效果不错，比如写博客、做播客脚本、或者给产品写推广文案。但如果你只是想让它帮你跑个 SQL 查询，就没必要动用这个了。

2.5 SCOPE — Situation / Complication / Objective / Plan / Evaluation

借鉴了麦肯锡的 SCQA（Situation-Complication-Question-Answer）叙事结构，加了执行计划和评估标准。套路是：先说 Situation 现在什么情况，再说 Complication 卡在哪了，然后定 Objective 想要什么结果，接着让它出个 Plan，最后给一套 Evaluation 标准来判断方案行不行。

示例：

Situation: 我们团队使用 Monorepo 管理 10+ 微服务
Complication: CI/CD 构建时间已经超过 30 分钟，每次 PR 都要等很久
Objective: 将构建时间缩短到 10 分钟以内
Plan: 分析当前流水线瓶颈，提出优化方案
Evaluation: 方案需要考虑实施成本、维护复杂度和对现有流程的影响

SCOPE 特别适合咨询类、决策类的问题，因为它自带了「问题-方案-评估」的完整链路。

2.6 SAGE — Situation / Action / Goal / Expectation

SCOPE 的简化版，去掉了 Complication 和 Evaluation，更适合快速场景。四个字段：Situation 说背景，Action 说要干什么，Goal 说目标，Expectation 说期望的产出。

示例：

Situation: 我有一个 Express.js 后端项目，目前没有任何日志系统
Action: 帮我集成 Winston 日志库
Goal: 实现分级日志输出，支持文件和控制台双输出
Expectation: 给出完整的配置代码和使用示例，兼容 TypeScript

SAGE 算是一个「刚刚好」的框架，不会太简单导致回答质量低，也不会太复杂让你在写 Prompt 上花太多时间。

2.7 BROKE — Background / Role / Objective / Key Results / Evolve

带了 OKR 思维的框架，Key Results 这个字段很有意思，它让你在提问的时候就想清楚「什么算做好了」。流程是 Background 交代背景、Role 给角色、Objective 定目标、Key Results 量化结果指标、Evolve 留一个迭代方向。

示例：

Background: 我们的 SaaS 产品注册转化率只有 2%，行业平均是 5%
Role: 你是一个增长黑客专家
Objective: 提升注册页面的转化率
Key Results: 方案需要在不增加广告预算的情况下，将转化率提升到 4% 以上
Evolve: 如果第一轮方案效果不明显，给出 A/B 测试的迭代方向

2.8 RISEN — Role / Instructions / Steps / End Goal / Narrowing

强调步骤分解和范围收窄的框架。Role 定角色，Instructions 给详细指令，Steps 把步骤拆开，End Goal 说清最终要什么，Narrowing 画红线——什么能做、什么不能做。

示例：

Role: 你是一个数据库优化专家
Instructions: 分析以下慢查询 SQL 并给出优化方案
Steps: 1. 解释为什么这条 SQL 慢 2. 给出优化后的 SQL 3. 建议需要添加的索引
End Goal: 查询时间从 5 秒降到 500 毫秒以内
Narrowing: 不能修改表结构，只能添加索引和优化 SQL 写法

Narrowing 这个字段是亮点。很多时候 AI 给的方案很理想但不切实际，加上约束条件之后回答会务实很多。

2.9 APE — Action / Purpose / Expectation

极简三件套，比 RTF 更直接。Action 说要做什么，Purpose 说为什么做，Expectation 说想要什么结果。连角色都省了。

示例：

Action: 将以下 Python 2 代码迁移到 Python 3
Purpose: 项目需要升级运行环境，Python 2 已经停止支持
Expectation: 保持功能不变，标注所有修改的地方，并解释每处改动的原因

APE 适合任务明确、不需要太多角色扮演的场景，比如代码转换、格式调整、文本改写这类。

2.10 RACE — Role / Action / Context / Example

带示例的框架，Few-shot 学习的结构化版本。Role 定角色，Action 说任务，Context 给上下文，最后挂一个 Example 当参考——这就是它跟其他框架最大的区别。

示例：

Role: 你是一个 API 文档编写专家
Action: 为以下 REST API 接口编写文档
Context: 这是一个用户管理模块的 CRUD 接口，供前端团队调用
Example: 参考以下已有的文档格式：
  ## GET /api/users
  **描述**: 获取用户列表
  **参数**: page (int), size (int)
  **返回**: { data: User[], total: number }

给 AI 一个示例，比写十行描述都管用。RACE 的核心思想就是 show, don’t tell。

2.11 ICIO — Instruction / Context / Input / Output

偏工程化的框架，结构接近函数调用。Instruction 给指令，Context 补上下文，Input 喂数据，Output 定返回格式。写过接口的人对这个结构应该很眼熟。

示例：

Instruction: 从以下 JSON 数据中提取所有用户的邮箱地址
Context: 这是从第三方 API 返回的用户数据，结构可能不一致
Input: [{"name": "Alice", "contact": {"email": "[email protected]"}}, {"name": "Bob", "email": "[email protected]"}]
Output: 返回一个纯邮箱地址的数组，如 ["[email protected]", "[email protected]"]

ICIO 特别适合数据处理类的任务，输入输出定义清晰，AI 基本不会跑偏。

2.12 CREATE — Character / Request / Examples / Adjustments / Type / Extras

字段最多的框架之一，适合需要精细控制的场景。Character 设角色，Request 提需求，Examples 给示例，Adjustments 说哪里需要特别调整，Type 定输出类型，Extras 补充其他信息。

老实说，这个框架字段太多了，日常用起来有点重。但如果你在做一个需要反复调用的 Prompt 模板（比如自动化内容生产流水线），把这些字段都填上，输出的一致性会好很多。

2.13 CARE — Context / Action / Result / Example

和 RACE 很像，但把 Role 换成了 Result，更关注结果导向。

Context: 我们在做一个面向海外市场的电商 App
Action: 将以下中文产品描述翻译成英文
Result: 翻译需要地道、吸引人，适合放在 Amazon 产品详情页
Example: 
  中文：轻便折叠伞，一键开合，晴雨两用
  英文：Ultra-light foldable umbrella with one-touch open/close, perfect for sun and rain

3 怎么选

说了这么多，你可能会想：我到底该用哪个？

实话说，不用纠结。这些框架之间的差异没有那么大，核心逻辑都是一样的：给够上下文、说清目标、定好格式。

如果非要给个建议：

  • 日常快速对话，RTF 或 APE 就够了，别把简单的事搞复杂
  • 排查技术问题，用 ROSES 或 RISEN，步骤拆得越清楚回答越靠谱
  • 写文案、做翻译这类内容创作，CO-STAR 或 CRISPE 对语气的控制力最好
  • 做方案、做决策，SCOPE 或 BROKE 自带评估环节，省得你追问
  • 数据处理、代码生成这种输入输出明确的活，ICIO 最对口
  • 如果你手上有参考示例，RACE 或 CARE 能让 AI 直接照着学
  • 不知道用啥，SAGE 万金油，什么场景都能凑合

4 一些实际的经验

框架是工具，不是教条。用了几个月下来，我总结了几条实际的经验：

  1. 不用每次都严格套框架。很多时候你只是想快速问一个问题，直接问就好。框架是在你发现 AI 回答不理想的时候，帮你反思「我是不是少说了什么」的检查清单。

  2. Role 真的有用。哪怕只加一句「你是一个资深的 XX 工程师」，回答的深度和专业性都会明显提升。这不是玄学，是因为 Role 帮模型定位了「应该从哪个知识子集里提取信息」。

  3. 给示例比写描述更有效。如果你花了三行描述输出格式，不如直接给一个示例。Few-shot 在大部分模型上的效果都比 Zero-shot 好。

  4. 约束条件很重要。「不要超过 500 字」「只用 Python 标准库」「不要修改现有的数据库结构」这类约束，能帮你过滤掉大量不切实际的方案。

  5. 迭代比一次写对更现实。第一次 Prompt 不完美很正常，看看 AI 的回答哪里不对，补充上下文或者调整约束，两三轮下来基本就能得到你想要的东西。

5 最后

Prompt 框架不是什么高深的东西，说白了就是「提问的艺术」换了个名字。但它确实能帮你从「AI 好像不太聪明」的挫败感中走出来——大部分时候不是 AI 不行，是我们问的方式不行。

选一两个顺手的框架，在日常工作中有意识地用起来，你会发现和 AI 的协作效率能上一个台阶。

好的 Prompt 不是写给 AI 看的，是写给自己看的——它逼你先想清楚自己到底要什么。合格的产品经理，应该对提示词做到指哪打哪。

评论