RTF框架是什么
📍 In One Sentence
RTF是一个三部分提示词骨架 — Role、Task、Format — 为日常任务提供刚好足够的结构，而没有更大框架的开销。
💬 In Plain Terms
告诉AI它是谁（Role）、要做什么（Task）以及如何格式化答案（Format）。就这样。三件事。适用于80%的日常任务。当不再足够时，您就升级到CO-STAR或SPECS。
RTF框架是一个三部分提示词模式，告诉模型它是谁、要做什么，以及答案应该如何显示。 与其发送一个松散的问题，您可以显式指定Role、Task和Format。这适用于GPT-4o、Claude Opus 4.7、Gemini 3.1 Pro和您通过Ollama或LM Studio运行的本地模型。
RTF故意保持最小化。仅有三个字段，易于记住，填写速度快，对许多日常任务足够灵活。当您不确定使用哪个专业框架时，您可以将其视为"默认提示词骨架"。
RTF的三个组件
一个强大的RTF提示词清楚地定义了三个组件中的每一个，这样模型对其工作没有歧义。 您可以将它们写成标记行或仍包含所有三个部分的一个句子。
典型定义：
- Role：模型应采用的角色或专业知识（例如"您是一位资深数据分析师"）。
- Task：您想要的具体行动，用一到两句话描述。
- Format：输出的结构、长度和风格（例如"3个要点加一个2句话的总结"）。
🔍 Format是关键
Role和Task是显而易见的 — 大多数人已经说出他们想要什么。Format是RTF增加真正价值的地方。"3个要点，每个最多50个词，Markdown格式"产生的输出一致性远高于"给我一个摘要"。Format字段是RTF的秘密武器。
RTF为什么有用
RTF框架很有用，因为它提供了更复杂框架的大部分好处，同时几乎没有额外复杂性。 它迫使您在发送提示词之前做出三个决定 — 谁、什么和如何。
实际优势包括：
- 比多部分框架更快地编写日常工作的提示词。
- 跨模型和运行的一致性更好，因为格式总是显式的。
- 轻松让团队成员入门，他们可以在几分钟内学会RTF并在任何地方重复使用。
示例：不好 vs 优秀的RTF提示词
RTF版本准确告诉模型如何思考内容以及如何打包结果，以便他人可以立即使用它。
❌ 非结构化请求
总结这次会议。
✅ RTF提示词
Role：您是一位运营经理，为高管领导总结项目状态会议。Task：阅读记录文稿，识别会议中讨论的主要决定、未解决的风险和后续步骤。Format：输出Markdown摘要，包含三个部分（`决定`、`风险`、`后续步骤`）。每个部分下使用3-5个要点。保持总摘要在250个字以内。
何时使用RTF
当您希望一个简单的、可重复使用的模式仍能强制执行清晰度和结构时，应该使用RTF框架。 它是一个强大的默认框架，当您不需要长规范或多步推理轨迹时。
典型用例包括：
- 电子邮件或聊天的短报告、摘要和总结。
- 为客户或内部利益相关者起草回复，具有清晰的结构。
- 生成小代码片段或重构，具有指定的输出格式。
- 快速内容片段，如产品文案、常见问题条目或简单检查清单。
RTF不是正确选择的时候
| 场景 | RTF的限制 | 改用 |
|---|---|---|
| 面向客户的内容，其中语气和受众至关重要 | 没有显式的受众或语气字段 | CO-STAR（包含Style、Audience、Tone）或CRAFT（Constraints、Role、Audience、Format、Tone） |
| 需要严格的数据结构或模式强制执行 | Format字段可以请求JSON但没有约束语法 | SPECS（包含显式Constraints字段） |
| 需要多步推理或决策逻辑 | 没有显式的逐步推理字段 | TRACE（包含Trigger、Response、Action、Consequence、Evaluation） |
| 具有条件逻辑的复杂工作流 | 每个提示词单一Role/Task/Format | APE（Action、Process、Examples）或自定义多轮工作流 |
对比表
RTF与其他主要框架的对比：
基于维度的对比
| 维度 | RTF | CO-STAR | SPECS | TRACE |
|---|---|---|---|---|
| 字段数量 | 3（Role、Task、Format） | 6（Context、Objective、Style、Audience、Response、Tone） | 5（Settings、Person、Examples、Pattern、Constraints） | 5（Trigger、Response、Action、Consequence、Evaluation） |
| 设置时间 | 30秒 | 2-3分钟 | 3-5分钟 | 2-3分钟 |
| 最适合 | 日常的、重复性任务 | 语气和受众控制 | 严格的模式和约束 | 显式推理步骤 |
| 输出一致性 | 良好 | 优秀 | 优秀 | 良好 |
| 需要示例？ | 否 | 可选 | 是（强模式） | 否 |
成对对比（RTF vs其他）
| 对比 | 获胜者 | 原因 |
|---|---|---|
| RTF vs CO-STAR | CO-STAR（如果受众重要） | CO-STAR包含显式的受众和语气字段。RTF强制将语气放入Role或Format中，这会变得混乱。如果您不在意声音，RTF更快。 |
| RTF vs SPECS | SPECS（如果需要严格约束） | SPECS包含专用的Constraints字段并期望示例。RTF可以在Format中请求约束但缺少结构化语法。对于JSON、CSV或结构化数据，SPECS赢。 |
| RTF vs TRACE | TRACE（如果推理重要） | TRACE显式建模因果关系（Trigger → Response → Action → Consequence）。RTF没有推理步骤字段。使用TRACE处理复杂逻辑，使用RTF处理简单输出。 |
| RTF vs Chain-of-Thought | 互补 | RTF定义角色和输出格式。CoT改进推理。结合它们：使用RTF构建提示词结构，为复杂数学或逻辑添加"逐步思考"。 |
如何编写RTF提示词
- 1Role：定义AI扮演谁。 具体的角色胜过通用的。不好："您很乐于助人。" 好的："您是审查代码性能回归的资深后端工程师。" 角色越具体，输出越一致。
- 2Task：说明AI应该做什么。 要具体。不好："总结这个。" 好的："识别讨论的三个关键决定、未解决的风险和后续步骤。"
- 3Format：指定结构、长度和风格。 这是RTF增加价值的地方。不好：（缺少Format）。好的："3个要点，每个最多50个词，Markdown格式，总共200个字以内。"
- 4分离Task和Format。 将它们合并成一个团块，两者都缺乏足够的具体性。保持它们独立。
- 5始终包含Format，即使看起来很明显。 没有它，模型默认为散文段落。
5个真实RTF案例
以下是五个生产就绪的RTF提示词，用于常见工作流：
案例1：每周状态摘要
Role： 您是为执行领导层撰写每周状态摘要的运营经理。
Task： 总结本周的项目进度、做出的关键决定、识别的风险和下周的优先事项。
Format： Markdown，四个部分（摘要、决定、风险、下周），每个部分3-5个要点，最多300个字。
案例2：代码审查反馈
Role： 您是审查代码的资深后端工程师，关注可维护性、性能和安全性。
Task： 审查这个代码块并识别任何问题、建议改进，并对整体质量进行评级。
Format： Markdown，三个部分（发现的问题、改进、质量评级1-5），代码块用于示例。
案例3：客户电子邮件草稿
Role： 您是起草对客户投诉的专业、同情回复的客户成功经理。
Task： 解决他们的关注点，在适当时道歉，解释解决方案，并恢复信心。
Format： 电子邮件格式（问候语、2-3个段落、关闭语），专业语气，150-250个字。
案例4：会议记录到行动项
Role： 您是从原始会议记录中提取行动项的项目协调员。
Task： 识别做出的决定、讨论的风险以及具有所有者和截止日期的后续步骤。
Format： Markdown，包含三个部分（决定、风险、行动项），行动项作为带受理人和截止日期的复选框列表。
案例5：为非技术用户的产品文档
Role： 您是向非技术用户以简单语言解释功能的技术作者。
Task： 解释此功能的作用、他们可能使用它的原因，以及如何在三个简单步骤中使用它。
Format： 1句话介绍、3个带示例的编号步骤、1句话结论。避免行话。
将RTF与其他框架结合
应该通过将RTF视为轻量级默认值并在约束增加时切换到更重的框架来结合RTF与其他框架。 一个实际的模式是：
- 对于大多数需要快速清晰结构的新任务，从RTF开始。
- 当需要严格的模式、示例和约束时，切换到SPECS。
- 当想要最终答案之前的显式推理步骤时，使用TRACE或APE。
- 当受众和语气是中心时，使用CRAFT等创意框架。
常见RTF错误
❌ 模糊的Role — "您是一个乐于助人的助手"
Why it hurts: "乐于助人的助手"是默认的。它什么都不增加。模糊的角色意味着模型选择自己的角色，在运行之间变化。
Fix: 要具体："您是一位资深后端工程师"或"您是一位针对首席财务官的B2B营销经理"。角色越具体，输出越一致。
❌ Task和Format合并成一个团块
Why it hurts: "用要点总结这次会议"混合了任务和格式。当它们合并时，两者都缺乏足够的具体性。
Fix: 分离它们：Task ="识别决定、风险和后续步骤。" Format ="Markdown，3个部分，每个3-5个要点，总共250个字。"
❌ 完全缺少Format
Why it hurts: 没有显式的Format，模型默认为散文段落 — 这可能不是您需要的。这是"AI给我一堵文字"的#1原因。
Fix: 始终指定Format。即使"Format：3个要点"也比什么都没有好。
❌ 对需要受众/语气控制的任务使用RTF
Why it hurts: RTF没有受众或语气字段。如果您正在编写语音重要的面向客户的内容，RTF迫使您将语气塞入Role或Format字段中，这会变得混乱。
Fix: 当语音重要时，切换到CRAFT（具有显式受众和语气字段）或CO-STAR（将Style和Audience分开）。
❌ 从不将RTF提示词保存为模板
Why it hurts: 每周从头开始编写相同的"会议摘要"RTF提示词会浪费时间并引入不一致。
Fix: 在PromptQuorum中将有效的RTF提示词保存为命名模板。通过仅交换输入数据来重复使用它们。
PromptQuorum如何实现RTF框架
PromptQuorum是一个多模型AI分发工具，将RTF框架作为其内置提示词结构之一包含在内，以便用户可以以一致的方式应用Role-Task-Format提示词。 当您在PromptQuorum内选择RTF选项时，界面公开Role、Task和Format的字段，并将它们组合成单一的形成良好的指令。
在PromptQuorum中，RTF框架让您能够：
- 填入Role、Task和Format一次，并将相同的结构化提示词发送到25个以上的模型，如GPT-4o、Claude Opus 4.7、Gemini 3.1 Pro以及通过Ollama或LM Studio配置的本地模型。
- 将RTF提示词保存为重复工作流的模板 — 例如"每周状态摘要"、"客户回复草稿"或"错误报告摘要"。
- 在您的团队中共享RTF模板，即使非专家也可以创建产生一致、结构化输出的提示词。
- 在多个模型之间并排A/B测试相同的RTF提示词，以找到最适合您的用例的模型。
中国企业应用方案
在中国，遵守数据安全法、网络安全法和行业特定合规要求对于处理敏感信息的企业至关重要。 RTF框架与本地推理（通过Ollama、LM Studio等本地模型）结合，为企业提供了一种结构化、合规的方式来部署AI能力。
数据安全法与RTF
中国2021年数据安全法要求企业对数据处理采取安全措施。本地推理确保企业数据不通过公共API传输，符合数据本地存储和处理的核心要求。
通过使用RTF框架定义清晰的Role（谁处理数据）、Task（处理什么）和Format（如何输出），企业可以建立可审计的数据处理流程，满足监管检查和内部治理要求。
- 本地推理：数据保留在企业网络内，不跨境传输
- 清晰的角色定义：RTF的Role字段定义谁有权访问和处理敏感数据
- 输出格式控制：Format字段确保敏感信息按照合规要求输出（例如，日志记录、审计跟踪）
- 任务边界：Task字段明确定义允许的操作范围
亚太地区跨境数据框架
如果企业在中国、东南亚或亚太地区多地运营，理解跨境数据流框架很重要。RTF框架帮助企业在不同地区明确定义数据处理政策。
中国CAC（网络安全审查）框架、泰国PDPA（个人数据保护法）和其他地区法规都要求企业对数据处理有明确的治理。RTF提示词通过显式定义数据处理逻辑来支持这些要求。
金融、医疗、法律行业部署
金融机构、医疗保健提供商和律师事务所处理高度受管制的数据（PCI-DSS、HIPAA等价物、行业保密标准）。RTF框架与本地模型部署相结合，为这些行业提供了可审计、可控的AI能力。
- 金融服务：使用RTF定义交易分析、风险评估、法规报告的提示词，确保输出符合金融监管要求
- 医疗保健：RTF的Format字段确保患者信息按照行业标准（如医疗记录保密性）输出
- 法律服务：定义清晰的Role和Task确保法律咨询、合同审查提示词遵循专业道德和客户保密要求
- 常见做法：大型企业（如阿里巴巴、腾讯、华为、百度）使用类似的结构化提示词框架来管理内部AI部署，确保合规性和可追溯性
常见问题
RTF代表什么？
RTF代表Role、Task、Format — 一个三部分的提示词结构，其中Role定义模型应该扮演的角色，Task指定模型应该做什么，Format描述所需输出的结构。
RTF与CO-STAR有何不同？
RTF最小化并专注于三个字段：Role、Task、Format。CO-STAR更全面，添加了Context、Style、Audience和Tone。对于快速直接的任务使用RTF；当受众和语调很重要时使用CO-STAR。
何时应该使用RTF？
当您需要来自明确定义的角色的结构化输出时使用RTF。示例：总结会议、生成代码、以特定格式编写电子邮件或创建文档。RTF非常适合基于模板的工作流。
我可以将RTF与其他框架结合吗？
可以。您可以使用RTF进行初始输出生成，然后应用RISEN进行迭代细化。或者将RTF与Chain-of-Thought结合来添加推理。混合搭配框架来处理复杂的工作流。
如果我不确定应该指定什么角色怎么办？
从最适合该任务的最简单角色开始："您是一位技术作家"、"您是一位产品经理"或"您是一位Python专家"。要具体但不要过度详细。测试不同的角色以查看哪个产生更好的结果。
Role、Task、Format的顺序重要吗？
传统顺序是Role → Task → Format，但模型无论顺序如何都会理解您的意图。但是，保持这个标准顺序可以使提示词更容易读和模板化。一致性比严格的顺序更重要。
RTF可以与所有语言模型一起工作吗？
可以。RTF与框架无关。它适用于GPT-4o、Claude、Gemini、Llama 3.2等开源模型，以及通过Ollama或LM Studio的本地模型。这些原则普遍适用于任何遵循指令的LLM。
我如何编写一个好的Format规范？
要具体：不是"Format：好的输出"，而是写"Format：5个要点，每个少于15个字"。指定结构（要点、段落、代码块、JSON）、长度（字数、项目数）和语调（正式、随意、技术性）。
- Schulhoff, L., et al. (2024). Prompt Engineering Guide. https://www.promptingguide.ai
- Brown, T. B., et al. (2020). "Language Models are Few-Shot Learners." OpenAI. arXiv:2005.14165
- OpenAI. (2026). Prompt Engineering Best Practices. https://platform.openai.com/docs/guides/prompt-engineering
- Anthropic. (2026). Prompt Engineering — Claude API Documentation. https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering