PREP
PREP communication
按观点、理由、例子、观点的顺序组织表达。
需要在短时间内说明一个观点并提出行动请求时使用。用观点、理由、例子和重申组织材料，保留关键证据条件。
听众、明确观点、可追溯依据、合适例子和希望对方考虑的请求。
结构清楚的简短表达和需要补充的证据。
先理解，再动手
使用步骤
围绕一个结论按Point观点、Reason理由、Example例证、Point重申组织表达。例证支持同一理由，结尾明确行动请求；没有事实材料不能编造证据。
- 01
先写出核心观点
- 02
补充支持观点的理由
- 03
加入事实、案例或数据
- 04
最后再次强调观点和行动建议
表达结构不证明结论。历史比例保留样本和时期；例子不能代表总体或证明因果，试点请求不等于获批或实施。
看清框架结构
从一份空白提纲开始
复制到你的文档，填入真实的业务事实与判断。
查看空白提纲
PREP · 空白提纲 什么时候用：需要在短时间内说明一个观点并提出行动请求时使用。用观点、理由、例子和重申组织材料，保留关键证据条件。 需要准备：听众、明确观点、可追溯依据、合适例子和希望对方考虑的请求。 预期产出：结构清楚的简短表达和需要补充的证据。 使用边界：表达结构不证明结论。历史比例保留样本和时期；例子不能代表总体或证明因果，试点请求不等于获批或实施。 工作问题： 期望结果： 已有证据与假设： 未知项与下一项核查： 填写说明：最希望对方记住的观点。 1. 结论： 填写说明：支持这个观点的理由。 2. 理由： 填写说明：支持理由的事实、案例或数据。 3. 例子： 填写说明：再次强调结论与希望对方采取的行动。 4. 重申： 检查清单 □ 开头直接给出观点。 □ 理由和例子支撑同一结论。 □ 结尾能强化重点或行动。 考虑下一个框架 业务改善提案表: 简短表达提出流程改善，但评审还需要资源、风险和验收信息时，用业务改善提案单补齐请求与验证条件。 https://bizthinkframe.com/zh/frameworks/business-improvement-proposal-sheet BizThinkFrame · https://bizthinkframe.com/zh/frameworks/prep
跟着案例走一遍
虚构教学案例三分钟说明为什么先做小试点
组织、人物、数据和结果均为虚构，仅用于说明框架用法。
背景与问题
星港负责人需要向主管解释为何不立刻全公司上线需求系统。
汇报先讲技术细节，主管听完仍不知道需要做什么决定。
手头有哪些材料
- 两个试点部门即可覆盖主要流程
- 历史抽样显示 40% 申请需补材料
如何使用这个框架
- 先说建议与需要的决定，再解释理由。
- 选择一个直接支持理由的例子，说明数据口径。
- 结尾重申行动请求，补充试点结束的评估标准。
形成简洁、可作决定的汇报结构。
8/20 的 40% 只描述案例给出的历史样本；统计时期与总体范围未补充，不能扩大到全公司，也不能证明补材料的原因或新字段已经有效。
润色论证前，先检查三种错位
PREP适合让听众听懂、质疑并回应一个集中的观点。先定希望对方考虑什么，再写理由。观点、理由、例证、重申都要服务同一建议。顺序清楚方便检查推理，不会让建议自动正确。
三种情况先停：开头和结尾要的决定不同；例证的人群或结果与理由对不上；短发言容纳不了重要证据或风险。这时可以用PREP开场，完整材料另备。
不确定性紧靠证据。小历史样本可以支持提出问题，不能直接证明原因。不要为显得自信而删掉限定，也别把“请批准”说成“我们将执行”，除非实际已经批准。
选择短论证，还是完整决定材料
结构取决于对方需要作什么决定。建议可以简短，支撑记录仍需可取用。换格式时保持请求、证据和替代方案之间的连接。
| 方法 | 起始材料 | 产出 |
|---|---|---|
| PREP | 一个观点、理由及相关例证 | 集中论证和重申请求 |
| BLUF | 结论与必要成立条件 | 主旨在前的开场 |
| 金字塔原理 | 问题与有逻辑分组的支撑 | 可检查推理的层级 |
| 决策矩阵 | 可行备选与有依据的判据 | 有条件比较，不自动批准 |
完整案例：把历史样本写成有限请求
继续使用星港请求系统虚构案例。两个部门覆盖主要流程；历史样本20条请求，8条需要补资料，时期和选样方法未给。8/20=40%只描述这个样本，不是全公司实测率，更不是拟试点结果。
建议是在两个部门先试两周，再考虑全面铺开。理由是要检查新表单是否清楚。历史记录使这个问题值得试，但不能证明8次补资料都由字段不清造成。两个部门提供有限流程环境，也不自动代表全公司。
下面是可直接口述或改成书面的完整草稿。批准、定义和阈值都保留待定；不编试点资源，不承诺未来减少多少。这样证据与请求对齐，又不会伪装成评估已经发生。
| 部分 | 可用草稿 |
|---|---|
| 观点 | 我提议先在两个部门试点两周，再考虑扩大。本次请求在下述条件达成约定后，批准这项有限测试。 |
| 理由 | 我们需要先在主要流程检查表单是否清楚，这两个部门可以提供有限验证环境。 |
| 例证 | 历史20条请求中8条补资料，样本内为40%。时期未知，这个数字不能证明新字段已经有效。 |
| 重申 | 请在口径、阈值、资源和复查安排达成约定后批准有限试点。扩大前一起看补资料、填写时间与用户反馈。 |
先演练含义，再复查真实决定
结论是申请测试，不是证明应该推广。请一位听众复述范围、为什么做、40%描述什么、还缺什么。如果听成两周后必然全面上线，就改开头和结尾，保留复查条件。
开始前确认谁能批准，约定纳入规则、什么事件算补资料、重复退回怎样计、填写时间如何测、反馈怎么收。案例阈值仍未定；没约好就记没约好，不能看见漂亮结果后再选门槛。资源可用与参与者同意也不由这段发言自动产生。
复查追加听众问题、修正证据与实际决定。批准试点不是批准全面上线。试点若执行，保留完整窗口、未解决请求和反对假设的反馈，再据此写新建议。原PREP稿仍是可追溯请求，说得有说服力不能替代缺少的评估。
检查你的思考
再问自己几个问题
- 我最想让对方记住的观点是什么？
- 这个观点背后的理由是否充分？
- 有什么具体例子能让观点更可信？
完成前的检查清单
- 开头直接给出观点。
- 理由和例子支撑同一结论。
- 结尾能强化重点或行动。