把项目讲清楚
汇报思路与文档表达
两个常见困惑：一是汇报讲了很多但听众抓不住重点；二是别人的语雀文档结构清晰、格式丰富，自己的显得说不清、单调。
这两件事的根因是同一个——信息没有分层。
上篇汇报：让听众能做判断
1汇报不是把事讲完，是帮听众做一个决定
听众不需要知道你做过什么，他需要能判断：这事值不值、成不成、要不要支持。所有技巧都从这一条推出来。
以"讲完整"为目标，产出的是工作汇总：时间线、功能清单、架构全貌。以"让人能判断"为目标，产出的是判断依据：问题多严重、方案为什么成立、证据是否可信、下一步需要什么。
后者听众听完会有动作；前者听完只会说"辛苦了"。
2动手前先定三件事，缺一件就白讲
这三件事不写在纸上，后面的内容一定会跑偏。
2.1听众是谁，决定了讲什么
| 听众 | 真正关心 | 你该重点给 |
|---|---|---|
| 直属主管 | 你的判断力和推进力 | 取舍过程、被否掉的路线、你踩到的坑 |
| 跨团队 | 接口、边界、他要付出什么 | 协作方式、对他的收益、明确的分工线 |
| 业务方 | 结果和体验变化 | 用户故事的前后对比、真实案例 |
| 更高层评审 | 是否值得继续投、能不能复制 | 一句话结论、量化收益、复制的前提条件 |
同一个项目对四种听众是四份材料，不是一份材料讲四遍。
2.2你要他做什么决定
认可价值、批人力、拉某个团队配合、把方案推成团队标准——四种诉求对应完全不同的讲法。诉求不写出来，汇报就没有落点，听众听完不知道该给你什么。
2.3一句话结论是什么
如果听众只记住一句，是哪句。写不出来，说明你自己还没想清楚——这时候不该开始做 PPT，该回去想问题。
3用户故事的关键是具体，不是覆盖面
"提升研发效率"等于没说。抽象的说法听众记不住，也没法判断严重程度。
3.1锚定一个真实的人和一个真实时刻
3.2把现状动线摊开，再摊开新动线
同一个人、同一件事，走几步、每步多久、卡在哪。这一段必须是你真去看过的，不能是想象的。
红色块是"在等人"，这是最有说服力的部分——它说明问题不在个人能力，在流程。
3.3一个故事讲透，胜过五个场景排列
其他场景一句话带过说"同类"。铺开五个都讲一半，听众一个都记不住。
4方案设计按这个顺序讲，架构图不要放在开头
开场就放架构图，听众到第五页还不知道你解决什么问题。
方案对比不要用段落写，用表格：
| 路线 | 成立的前提 | 为什么没选 |
|---|---|---|
| 路线 A | 需要各业务方主动接入 | 推动成本高于收益，半年内拿不到覆盖率 |
| 路线 B | 需要统一的数据标准 | 标准目前不存在，且不在我们职责内 |
| 路线 C（选中） | 只依赖已有的构建产物 | —— 无需他人配合即可验证 |
5证据部分最容易翻车的三个地方
5.1数据必须有基线对比
5.2区分"跑通"和"在用"
跑通是 demo，有人反复用才是价值。用了几次、几个人、留存多少，比功能清单重要得多。
| 说法 | 听众实际听到的 |
|---|---|
| 功能已上线 | 可能没人用 |
| 完成了 12 个能力 | 不知道哪个有用 |
| 5 个人本周用了 23 次，其中 3 人是第二周继续用 | 这事是真的 |
5.3主动说失败案例和当前边界
说了显得你在真实世界里干活；不说，稍微懂行的人一问就崩。边界要自己划，不要等人来划。
6阿里体系里额外要交代的两点
| 要交代 | 不交代的后果 | 怎么说 |
|---|---|---|
| 为什么是你们做 | 方案再好也推不动 | 说清和你团队职责的关系、相邻团队在做什么、分工线在哪 |
| 是点还是能复制 | 拿不到继续投入的判断 | 说清复制的前提条件；不要把一次性方案吹成通用平台 |
7六页骨架，以及讲完后的反面清单
| 页 | 内容 | 这页要达到的效果 |
|---|---|---|
| 1 | 结论：解决谁的什么问题 / 现在什么状态 / 需要什么支持 | 听众马上知道要不要认真听 |
| 2 | 用户故事：一个人、一次完整动线、前后对比 | 听众能感到疼 |
| 3 | 难点与取舍（含被否的路线） | 听众相信这事不简单、且你想过 |
| 4 | 主链路图 | 听众知道方案长什么样 |
| 5 | 效果与证据：基线对比 + 真实使用 + 失败案例 | 听众相信是真的 |
| 6 | 边界与下一步：赌什么、需要谁配合 | 听众知道该给你什么 |
下篇文档：为什么别人的语雀文档更清晰
8格式是结构的产物，不是让文档清晰的手段
别人先把信息之间的关系想清楚了，加粗、表格、图只是把已经存在的层次显出来。
没想清楚就套格式，只会变成"花的乱文档"。
所以"我的文档显得单调"这个感受，真正的名字是没有分层——通篇句子的信息密度一样，读者不知道哪句可以跳过、哪句必须停下。他只能全读或者全不读，于是选了全不读。
9你永远读不到自己文档里的困惑
读别人的文档时你是纯读者，能直接体验到"清晰"；写自己的文档时你有全部上下文，感受不到读者卡在哪。这个差距不靠努力补，只能靠机制补：
- 放一晚再读一遍
- 只看目录，问自己能不能懂全文脉络
- 找一个没有背景的人读前两屏，看他先问什么
10六个病症，逐条对照
10.1标题是标签，不是信息
好文档的目录单独拎出来，本身就能读懂全文脉络。这一条改完，清晰度提升最大。
10.2每段没有结论句
默认写法是把想到的按顺序摊开，读者要自己总结。改成每段第一句就是结论，后面是支撑——读者读首句就能决定要不要细看。
10.3该换形式的地方硬用文字
这是"单调"感最主要的来源，规则见 第 11 节。
10.4缺具体物
真实数字、真实报错、真实截图、真实的人名和时间。抽象说法后面不挂具体例子，读者脑子里没有画面，就会觉得空。
10.5篇幅平均分配
最重要的部分和背景交代占一样长度，读者判断不出轻重。重要的展开写、给例子给图；次要的压成一行。
10.6写了过程，没写结论
11三个硬规则：什么时候必须换形式
不用犹豫，命中就换。自己文档单调，常常就是这三类信息全被压成了段落。
方案对比、角色权限、各环境配置
流程、时序、模块关系。文字描述分支必然绕
读者需要逐条核对的东西
12改写顺序按收益排，不要从头逐字改
13格式工具的作用是给读者发信号
加粗、色块、折叠、引用这些，本质是在说：这里可跳过 / 这里必须看 / 这几项是同类。
用得少不是问题，用得没有规则才是问题。同一篇里加粗只用来标结论、色块只用来放风险提示——这种一致性才产生"专业"的观感。乱加反而降低清晰度。