✅ BRTR 是什么？

BRTR 是一种 轻量、结构化、适合工程师的 Prompt 模板，用于让模型在执行任务时更稳定、输出更可控。

它由四个部分组成：

B — Background（背景）

告诉模型任务的上下文、背景设定、已有信息、约束条件。

R — Request（需求）

明确你希望模型做什么，是任务的目标。

T — Task（任务步骤）

告诉模型应如何执行任务（步骤、方法、重点检查项）。

R — Result（输出格式）

限制输出结构，让模型按你需要的形式回答（如 JSON、列表、Markdown）。

---

📌 为什么工程师爱用 BRTR？

因为它比 CRISPE 更轻量，比 ICIO 更自然，特别适合：

• 代码分析
• 日志分析
• 技术文档总结
• 架构讨论
• 工程方案生成

---

✅ BRTR 示例（工程师场景）

这是一个你可以直接用来分析日志问题的 Prompt：

---

B — Background（背景）

你是一名资深后端工程师，熟悉分布式系统、服务端日志、性能调优。我提供的日志来自生产环境，其中包含服务报错与堆栈信息。

R — Request（需求）

请你分析这些日志，找出导致服务异常的根因，并提出可操作的修复建议。

T — Task（任务步骤）

1. 从日志中识别错误类型、模块、调用链
2. 判断问题触发条件与上下游影响
3. 给出可能的根因与验证办法
4. 提供修复方案（代码级或配置级）

R — Result（结果格式）

请按如下 JSON 输出：

{
  "root_cause": "",
  "evidence": [""],
  "impact": "",
  "fix_suggestions": [""],
  "risk_if_unfixed": ""
}

同一个任务：三种 Prompt 框架对照

下面三段 prompt 内容完全针对 同一个任务：分析日志 + 找根因 + 给修复建议

---

① ICIO Prompt 示例

（Instruction / Context / Input / Output）

---

Instruction

请分析我给出的错误日志，识别可能的根因，判断影响范围，并给出可执行的修复建议。

Context

这些日志来自后端微服务，运行在生产环境，近期出现响应时间变慢和偶发 500 错误。

Input

<在此贴入你的日志内容>

Output

请用 JSON 输出以下结构：

{
  "root_cause": "",
  "evidence": [""],
  "impact": "",
  "fix_suggestions": [""],
  "risk_if_unfixed": ""
}

---

② CRISPE Prompt 示例

（Context / Request / Information / Specifics / Purpose / Expectation）

---

C — Context & Capacity（上下文 & 能力）

你是一名擅长分布式系统与日志诊断的资深后端工程师。我将提供生产环境的错误日志。

R — Request（任务）

请识别异常、分析根因、评估风险，并生成可直接执行的修复建议。

I — Information（信息）

系统近期出现：

• 响应延迟升高
• 偶发 500 错误
• 依赖服务正常

S — Specifics（特殊要求）

• 强调证据链：引用日志中的关键字段
• 如有多种可能性，请按概率排序
• 不要猜测未出现的信息

P — Purpose（输出目的）

用于创建修复方案并向 SRE / Dev 团队同步。

E — Expectation（输出格式 & 禁用事项）

输出格式：

{
  "summary": "",
  "root_cause_hypotheses": [""],
  "key_logs": [""],
  "fix_plan": [""],
  "follow_up_actions": [""]
}

禁止：

• 不要输出无结构的长段落
• 不要使用模糊表达（如“可能需要优化”）

---

③ BRTR Prompt 示例

（Background / Request / Task / Result）

---

B — Background（背景）

日志来自生产环境订单服务。用户反馈间歇性请求失败，问题尚未复现。

R — Request（需求）

请基于日志内容分析根因、提供证据，并提出最可能的修复措施。

T — Task（任务步骤）

1. 提取错误堆栈与关键字段
2. 判断问题所属类别（逻辑 / 性能 / 配置 / 外部依赖）
3. 评估风险与影响范围
4. 生成修复建议，必要时包含代码级修改方向

R — Result（输出格式）

# 问题总结：
# 根因分析：
# 日志证据：
# 修复建议：
# 需要进一步验证的点：

---

🧩 三种框架的区别（快速理解）

框架	特点	适用场景
ICIO	轻量、结构直接清晰、输入输出分明	代码分析、文本处理、任何结构化任务
CRISPE	信息量大、可控性强、最适合高难度业务任务	RAG、Agent、正式文档生成
BRTR	简单好记，工程师最喜欢，逻辑自然	日志分析、架构讨论、调试任务