BROKE是一个目标驱动的Prompt结构化框架，包含五个核心要素：Background（背景）、Role（角色）、Objective（目标）、Key Results（关键结果）、Evolve（演进）。本文通过三个实战案例，展示如何运用BROKE框架获得高质量的AI输出。

BROKE框架概述

BROKE框架借鉴OKR（目标与关键结果）的思想，强调目标导向和可衡量的成果：

要素 含义 作用
B - Background 背景信息 提供任务的上下文和约束条件
R - Role 角色定位 定义AI扮演的专业角色
O - Objective 核心目标 明确要达成的最终目标
K - Key Results 关键结果 定义可衡量的成功标准
E - Evolve 演进迭代 支持多轮对话和持续优化

BROKE vs CRISPE

维度 BROKE CRISPE
核心理念 目标驱动、结果导向 任务驱动、步骤详尽
适用场景 战略规划、复杂决策、迭代任务 明确任务、技术实现、一次性输出
灵活性 高（支持演进迭代） 中（步骤相对固定）
衡量标准 关键结果明确可量化 输出格式和示例为参考

示例一：产品需求分析场景

场景背景

为一个电商平台设计会员积分系统，需要完整的需求分析文档。

BROKE提示词

B - Background（背景）

我们是一家中型电商平台，月活用户50万，日均订单2万单。
当前痛点：
- 用户复购率仅15%，行业平均25%
- 缺乏用户忠诚度激励机制
- 竞品已推出积分系统，我们正在流失高价值用户

技术约束：
- 后端：Java Spring Boot微服务架构
- 数据库：MySQL + Redis
- 需要与现有订单系统、用户系统对接
- 预算：3个月2人开发资源

R - Role（角色）

你是一位拥有10年经验的产品经理，专注于电商会员体系和用户增长。
你曾主导过3个千万级用户平台的会员系统设计，熟悉积分经济学和用户行为分析。

O - Objective（目标）

设计一个完整的会员积分系统方案，帮助平台在6个月内将用户复购率从15%提升至22%。

K - Key Results（关键结果）

请输出满足以下关键结果的方案：

KR1: 积分规则设计
- 至少覆盖5种积分获取场景（购物、签到、评价等）
- 每种场景包含积分计算公式和上限规则
- 积分有效期和过期策略

KR2: 积分消耗体系
- 至少3种积分使用方式（抵扣、兑换、抽奖等）
- 每种方式的兑换比例和使用门槛
- 防刷机制设计

KR3: 会员等级体系
- 3-5个会员等级定义
- 升降级规则和计算周期
- 各等级专属权益清单

KR4: 技术实现要点
- 核心数据表结构设计
- 关键API接口定义
- 与现有系统的集成方案

KR5: ROI预估
- 积分成本测算模型
- 预期收益分析
- 投资回报周期预测

E - Evolve（演进）

这是第一版方案，后续我可能会：
1. 要求细化某个模块的实现细节
2. 讨论积分规则的参数调优
3. 评审技术方案的可行性
4. 补充运营活动的积分策略

请在输出时保持模块化结构，便于后续针对性迭代。

应用要点

  • B-背景：提供业务现状、痛点和技术约束，让AI理解真实场景
  • R-角色：定义资深产品经理，带入专业视角
  • O-目标：设定可量化的业务目标（复购率15%→22%）
  • K-关键结果：5个KR覆盖完整方案维度，每个KR都有具体交付物
  • E-演进：预设后续迭代方向，支持多轮深化

BROKE框架让需求分析目标明确、结果可衡量，便于后续迭代优化。

示例二：系统架构设计场景

场景背景

设计一个高并发秒杀系统，需要完整的技术架构方案。

BROKE提示词

B - Background（背景）

业务场景：
- 电商平台大促秒杀活动
- 预计参与用户：100万人同时在线
- 秒杀商品：10个SKU，每个限量1000件
- 活动时长：每场10分钟，每天3场

现有基础设施：
- 云服务商：阿里云
- 容器平台：Kubernetes
- 现有QPS承载能力：5000
- 数据库：MySQL 8.0主从集群

历史问题：
- 去年大促系统崩溃，损失500万销售额
- 超卖问题导致大量客诉
- 页面响应时间超过10秒

R - Role（角色）

你是一位高并发系统架构专家，曾主导过双11级别的秒杀系统设计。
你精通分布式系统、缓存策略、消息队列和限流熔断机制。

O - Objective（目标）

设计一个能承载100万并发用户的秒杀系统架构，确保：
- 系统稳定性：99.99%可用性
- 响应性能：P99延迟<200ms
- 数据一致性：零超卖

K - Key Results（关键结果）

请输出满足以下关键结果的架构方案：

KR1: 整体架构图
- 使用Mermaid或文字描述完整架构
- 标注各层职责和技术选型
- 说明数据流向和调用链路

KR2: 流量削峰方案
- 前端限流策略（验证码、排队等）
- 网关层限流配置（令牌桶/漏桶参数）
- 服务层熔断降级规则
- 预期从100万QPS削减到多少

KR3: 库存扣减方案
- 库存预热和缓存策略
- 原子扣减实现（Redis Lua脚本）
- 数据库最终一致性保证
- 防止超卖的兜底机制

KR4: 订单处理方案
- 异步下单流程设计
- 消息队列选型和配置
- 订单状态机设计
- 失败重试和补偿机制

KR5: 监控告警体系
- 核心监控指标清单
- 告警阈值和升级策略
- 应急预案和快速恢复流程

E - Evolve（演进）

这是架构设计阶段，后续我会：
1. 要求提供关键模块的详细设计
2. 讨论具体技术选型的对比分析
3. 进行容量评估和压测方案设计
4. 制定上线灰度发布计划

请确保架构方案具有良好的可扩展性，便于后续深入讨论。

应用要点

  • B-背景：详细描述业务规模、技术现状和历史问题
  • R-角色：定义高并发架构专家，确保方案专业性
  • O-目标：三个可量化的技术指标（可用性、延迟、一致性）
  • K-关键结果：5个KR覆盖架构设计的关键模块
  • E-演进：预留后续详细设计和实施的迭代空间

BROKE框架让架构设计指标明确、模块清晰，支持从概要到详细的渐进式设计。

示例三：数据分析场景

场景背景

分析用户流失原因，制定挽回策略。

BROKE提示词

B - Background（背景）

公司概况：
- B2B SaaS产品，企业协作工具
- 当前付费客户：2000家
- 月流失率：从2%上升到5%（近3个月）
- ARR（年度经常性收入）：5000万

已有数据：
- 用户行为日志（登录、功能使用、操作时长）
- 客户工单和反馈记录
- 续费/流失记录（含流失原因分类）
- NPS调研数据（季度）

流失初步分析：
- 30%标注"价格因素"
- 25%标注"功能不满足"
- 20%标注"竞品替代"
- 25%标注"其他/未知"

R - Role（角色）

你是一位资深数据分析师，专注于SaaS产品的客户成功和流失分析。
你擅长用户行为建模、队列分析和预测性分析，熟悉客户健康度评分体系。

O - Objective（目标）

通过数据分析找出真实流失原因，设计流失预警模型，制定针对性挽回策略，
目标在3个月内将月流失率从5%降至3%。

K - Key Results（关键结果）

请输出满足以下关键结果的分析方案：

KR1: 流失特征分析
- 流失客户的共性特征画像
- 行为指标对比（活跃度、功能使用深度等）
- 流失前30天的行为模式变化
- 关键流失信号识别

KR2: 流失原因深挖
- 对"价格因素"进行细分（预算削减？ROI不足？竞品更便宜？）
- 对"功能不满足"进行聚类（缺失什么功能？使用障碍？）
- 隐性流失原因挖掘（实施服务？客户成功支持？）
- 各原因的量化占比和优先级排序

KR3: 流失预警模型
- 健康度评分指标体系（5-8个核心指标）
- 各指标权重和计算方法
- 风险等级划分标准
- 预警触发规则和时机

KR4: 挽回策略矩阵
- 按流失原因分类的挽回策略
- 按客户价值分层的资源投入建议
- 具体行动方案和责任归属
- 预期挽回率和ROI测算

KR5: 监测看板设计
- 核心流失指标定义
- 看板布局和可视化建议
- 日/周/月报告模板
- 关键告警规则

E - Evolve（演进）

这是分析框架设计阶段，后续我会：
1. 提供真实数据样本进行验证分析
2. 讨论预警模型的阈值调优
3. 设计A/B测试验证挽回策略效果
4. 迭代优化健康度评分体系

请确保分析框架具有可操作性，便于用真实数据验证和迭代。

应用要点

  • B-背景：提供业务数据、现有分析结论和数据资产情况
  • R-角色：定义SaaS领域的数据分析专家
  • O-目标：明确的业务指标（流失率5%→3%）
  • K-关键结果：5个KR形成完整的分析→建模→策略→监测闭环
  • E-演进：预设数据验证和策略优化的迭代路径

BROKE框架让数据分析业务导向、结果闭环，从分析到落地形成完整链路。

BROKE框架使用总结

三个案例对比

场景 核心价值 关键结果数 迭代重点
需求分析 目标量化、方案完整 5个KR 模块细化
架构设计 指标明确、模块清晰 5个KR 详细设计
数据分析 业务导向、结果闭环 5个KR 数据验证

BROKE使用建议

  1. 背景要充分：提供足够的上下文，包括现状、约束和历史问题
  2. 角色要专业：定义具体领域的资深专家，带入专业视角
  3. 目标要量化：设定可衡量的业务或技术指标
  4. KR要SMART：Specific具体、Measurable可衡量、Achievable可达成
  5. 演进要预设：规划好后续迭代方向，支持多轮深化

何时选择BROKE？

选择BROKE：

  • 战略规划、复杂决策类任务
  • 需要多轮迭代优化的场景
  • 目标明确但路径不确定
  • 需要可量化成功标准

选择CRISPE：

  • 明确的技术实现任务
  • 一次性输出的场景
  • 步骤清晰的操作流程
  • 需要详细示例参考

掌握BROKE框架，让你的AI对话从”模糊探索”升级为”目标导向”，实现高效的多轮迭代优化。

📎 附件下载

BROKE框架完整模板 - 包含详细的背景信息、角色定位、目标设定、关键结果定义和演进迭代指南。

🔗 下载 BROKE Prompt框架模板

该模板文件包含了本文中所有示例的完整版本，以及更多实用的BROKE提示词模板，可以直接复制使用并根据具体需求进行修改。同时模板中还包含了BROKE与CRISPE框架的对比分析，帮助你根据不同场景选择合适的框架。