一页纸讲清楚 · One-Page Explainer

§0 你一定经历过这个场景

> 你刚看完一份 45 页的竞品分析报告，VP 发来消息：「5 分钟后碰一下，你说说核心结论」。
>
> 你盯着满屏的图表和文字，脑子飞速运转——总不能说「等我翻到第 37 页」吧。
>
> 你的 AI 助手能把这份报告总结成 3 页、5 页、甚至 10 页——但你要的不是更多，是更少。
>
> 你要的是一页纸。一张能放在 VP 面前、让他 30 秒看完、然后说「可以，推下去」的纸。
>
> 你需要的不只是总结——你需要一个能把任何东西压到一页纸的压缩机。

One-Page Explainer 做的事情：接收任意长度的信息输入，按你选择的压缩模式，输出一张不超过 A4 纸的内容。不是截断，不是随机删减——是语义压缩。删掉的是水分，保留的是骨架。读完这张纸，你不需要回去翻原文。

它和「总结」的区别：总结是"这文档说了什么"，一页纸是"这文档里你需要知道什么才能行动"。

§Q 快速上手

唤醒方式

对 AI 说以下任意一句即可启动 One-Page Explainer：

七种压缩模式速览

模式选择速查

你的场景是？                      → 用哪个模式
────────────────────────────────────────────
向领导汇报，30 秒讲清楚       → 电梯演讲
数据分析、项目复盘             → 一页纸报告
要拍板选方案                   → 决策备忘录
学新概念、帮别人快速理解       → 知识卡片
团队要干活、需要 checklist     → 执行清单
要比较两个或多个选项           → 对比一页
梳理事件经过和时间线           → 时间线一页
不确定                         → 说「压到一页纸」，自动选

§1 核心能力详解

F1：七种压缩模式完整定义

模式一：电梯演讲（Elevator Pitch）

> 如果你只有 30 秒向最重要的人解释这件事

模板结构：

For [目标受众]
Who [他们的痛点/需求]
The [产品/方案/建议]
Is a [品类/定位]
That [核心差异点]
Unlike [替代方案/竞品]
We [关键优势]

字数上限：150 字（约 30 秒朗读时间）

压缩策略：只保留一个核心主张 + 一个核心差异点。所有背景铺垫、技术细节、数据支撑全部剥离。

示例输入：一份 30 页的新产品 MRD
示例输出：

> For 跨境电商运营团队，他们每天花 3 小时手动翻译和上架商品到多个平台。OneSKU 是一个一站式多平台上架工具，自动翻译、适配格式、批量发布。Unlike 现有的 ERP 插件（需要逐个平台配置），我们实现一次编辑、同步上架 8 个平台。

模式二：一页纸报告（One-Page Report）

> 把一次分析或复盘浓缩到 4 个模块

模板结构：

【问题】一句话定义
【数据】3 个以内关键数字
【结论】核心发现（不超过 3 条）
【行动】下一步建议（不超过 3 条，每条带负责人）

字数上限：500 字

压缩策略：以行动为导向反推。先确定「结论」和「行动」，再从原文中找支撑数据。与数据无关的背景描述全部删除。

示例输入：Q2 用户增长复盘文档（18 页）
示例输出：

> 【问题】 Q2 新增用户环比下降 23%，但付费转化率上升 5%。
>
> 【数据】
> - 新增：4,200（目标 5,500），达成率 76%
> - 自然渠道占比从 55% 降至 38%
> - 付费转化率：3.2% → 3.4%
>
> 【结论】
> 1. 投放预算削减导致自然流量连带下降（SEO 内容产出同步减少）
> 2. 存量用户质量在提升（付费率反升），说明产品本身没有退化
> 3. 核心问题是获客管道收窄，不是产品力下降
>
> 【行动】
> 1. Q3 恢复 SEO 内容产出，目标月度 12 篇 → @内容组
> 2. 测试 2 个低成本获客渠道（小红书 + 知乎）→ @增长组
> 3. 维持现有投放预算，暂不加量 → @市场部

模式三：决策备忘录（Decision Memo）

> 帮决策者在 5 分钟内完成「了解选项 → 理解推荐 → 知道风险」

模板结构：

【背景】一句话（为什么需要做这个决策）
【选项】每个选项一句话 + 一句话利弊
【推荐】推荐哪个，一句话核心理由
【风险】最大的风险是什么，怎么兜底
【如果不选推荐的】备选方案是什么

字数上限：500 字

压缩策略：不是罗列所有信息，而是筛选决策者真正需要的——他不知道的、会影响判断的、关联风险的信息。

示例输入：技术选型讨论纪要（8 页，三个方案 A/B/C）
示例输出：

> 【背景】 搜索服务需要升级，当前 ES 7.x 版本已 EOL，需在 Q3 前完成迁移。
>
> 【选项】
> - A. 升级到 ES 8.x：迁移成本最低（约 2 周），但新特性有限
> - B. 迁移到 Meilisearch：性能更好（延迟低 40%），但团队无运维经验
> - C. 迁移到 Typesense：与 B 类似，但社区更小，文档更少
>
> 【推荐】 选 A（升级 ES 8.x）。理由：Q3 还有 3 个业务需求要做，不宜在此投入超过 2 周的工程资源。性能提升不是当前瓶颈。
>
> 【风险】 ES 8.x 的 EOL 时间是 2027 年，意味着 2 年内可能再次面临迁移。兜底：如果 2026 Q4 搜索性能成为瓶颈，提前启动 B 方案 POC。
>
> 【备选】 如果团队有人愿意在 Q3 业余时间做 B 方案 POC，不阻止。但不作为主线任务。

模式四：知识卡片（Knowledge Card）

> 把一个复杂概念压缩到一张学习卡片

模板结构：

【概念】一句话定义
【一句话原理】最核心的原理，用类比
【例子】一个最小可运行的例子
【边界】什么情况下不适用 / 什么时候不该用
【对比】与最相似的另一个概念的差异（一句话）

字数上限：400 字

压缩策略：用类比替代定义，用例子替代解释。不追求全面——追求「懂了这一个例子就能理解核心」。

示例输入：gRPC 技术文档（12 页）
示例输出：

> 【概念】 gRPC 是 Google 开源的高性能 RPC 框架，让不同服务器之间像调用本地函数一样互相调用。
>
> 【一句话原理】 可以理解为「HTTP/2 + Protobuf 序列化」——用 HTTP/2 做传输管道（快、双向流），用 Protobuf 做数据压缩格式（比 JSON 小 3-10 倍）。
>
> 【例子】
> python > # 定义服务（.proto 文件） > service Greeter { rpc SayHello(HelloRequest) returns (HelloReply); } > # 客户端调用就像调用本地函数 > response = stub.SayHello(HelloRequest(name='world')) >
>
> 【边界】 不适合浏览器直接调用（需要 gRPC-Web 代理）；如果只是简单 CRUD，REST + JSON 更省事。
>
> 【对比】 gRPC vs REST：gRPC 更快更小，但调试麻烦（二进制）；REST 慢但人人都能 curl。

模式五：执行清单（Execution Checklist）

> 把一堆待办变成能贴在墙上照着执行的清单

模板结构：

【目标】一句话
【检查点】按阶段排列，每阶段 ≤5 条
  阶段 N：[检查项] ──依赖：{无 / 阶段 N-1}
【关键依赖】跨阶段的阻塞项
【第一步行什么】明天就能做的一件事

字数上限：500 字

压缩策略：区分「必须做的」和「最好做的」。只保留必须做的。每个检查点必须是可验证的（完成/未完成，没有中间状态）。

示例输入：项目启动会记录（7 人发言，15 个行动项）
示例输出：

> 【目标】 10 月 15 日前完成用户中心 v2 上线
>
> 【检查点】
> 阶段 1：设计定稿（9.20 前）
> - [ ] 交互稿评审通过 ──依赖：无
> - [ ] 视觉稿评审通过 ──依赖：交互稿
> - [ ] API 接口文档定稿 ──依赖：无
>
> 阶段 2：开发（10.5 前）
> - [ ] 前端页面开发完成 ──依赖：阶段 1
> - [ ] 后端接口开发完成 ──依赖：阶段 1
> - [ ] 联调通过 ──依赖：前端 + 后端
>
> 阶段 3：测试与上线（10.15 前）
> - [ ] QA 回归通过 ──依赖：阶段 2
> - [ ] 灰度 5% 流量观察 24h 无异常 ──依赖：QA
> - [ ] 全量发布 ──依赖：灰度
>
> 【关键依赖】 交互稿需要设计总监审批，她 9.18-9.22 休假。必须在她出发前（9.17）完成评审。
>
> 【第一步行什么】 明天上午约设计总监，锁定 9.16 交互评审时间。

模式六：对比一页（Comparison Sheet）

> 把多个选项的核心差异放在一页上，一眼看出区别

模板结构：

【对比维度】维度 1 / 维度 2 / 维度 3 / 维度 4 / 维度 5
【方案 A】数值或一句话
【方案 B】数值或一句话
【方案 C（如有）】数值或一句话
【推荐】选 X，理由一句话
【取舍说明】选 X 意味着放弃什么

字数上限：500 字（含表格）

压缩策略：最多 5 个对比维度。超过 5 个说明维度选取有问题——合并相似维度或删除非决策关键维度。

示例输入：三家云服务商方案书（共 60 页）
示例输出：

> 【推荐】 方案 A（阿里云）。核心理由：延迟和合规是本次选型的硬门槛，阿里云在这两项无短板且费用适中。
>
> 【取舍】 选 A 意味着放弃腾讯云的低价和 AWS 的最低延迟。如果未来出海，需要重新评估 AWS。

模式七：时间线一页（Timeline Page）

> 把一段时间内发生的事按时间轴展开，标注事件-影响-关联

模板结构：

【时间范围】202X.XX - 202X.XX
【时间轴】
  T1 时间：事件描述 → 直接影响：XXX
  T2 时间：事件描述 → 直接影响：XXX（关联 T1：因为 T1 的 XXX，所以…）
  T3 时间：事件描述 → 直接影响：XXX
【关键转折点】哪一个事件改变了方向
【模式识别】是否有重复出现的模式

字数上限：500 字

示例输入：某项目延期复盘记录
示例输出：

> 【时间范围】 2026.03 - 2026.07
>
> 【时间轴】
> - 3.10 项目启动，目标 6.1 上线 → 团队 5 人全员到位
> - 3.25 需求评审通过，但 PO 备注「可能还有一轮需求变更」 → 未引起重视
> - 4.15（关键转折）需求第二轮变更，新增社交分享模块 → 未调整排期。直接影响：开发预估偏差从 +15% 扩大到 +40%
> - 5.10 开发进度落后 12 天，首次暴露 → 决定加人（关联 4.15：需求变更时未评估影响是根因）
> - 6.01 未能上线，延期至 7.01 → 新加入成员需要 ramp-up，实际加速效果有限
> - 7.05 实际上线（延期 35 天）
>
> 【关键转折点】 4.15 需求变更未同步调整排期——这是唯一一个「花 1 小时排期讨论就能避免 35 天延期」的时刻。
>
> 【模式识别】 过去 3 个项目中有 2 个存在同样的模式：需求变更 → 不调整排期 → 后期加人 → 加速效果有限。建议：需求变更必须触发排期重估，写入 SOP。

F2：硬约束机制

一页纸的核心约束：Markdown 渲染后不超过一页 A4。

实际执行标准：

超一页时的处理流程：

输出超过一页
    │
    ├─ 第一步：标注当前字数 vs 目标字数
    │   「当前 780 字，目标 ≤500 字，需删减 280 字」
    │
    ├─ 第二步：标注可删减内容，按优先级
    │   ① 必须保留（核心结论、关键数据、行动建议）
    │   ② 建议保留（支撑论据、上下文说明）
    │   ③ 可删减（背景铺垫、次要细节、过渡句）
    │
    └─ 第三步：给出删减后的一页纸版本

禁止的行为：
- 通过缩小字体、调整行距、减小页边距等方式「视觉上强行挤进一页」
- 把核心内容从 500 字砍到 300 字，尾注写「详见原文第 X 页」
- 模式混用——例如在「电梯演讲」模式下塞入对比表格

F3：压缩策略——不是截断，是蒸馏

七条压缩原则：

压缩深度等级：

F4：与对话到方案（StoryGraph）联动

对话碎片（群聊记录、1v1 讨论、脑暴笔记）
        │
        ▼ StoryGraph
   结构化方案（分章节、有逻辑结构、覆盖完整）
        │
        ▼ One-Page Explainer
   一页纸（汇报/备忘录/清单——可直接用于行动）

分工清晰：
- StoryGraph 负责「散 → 整」：从碎片信息重构结构
- One-Page Explainer 负责「整 → 精」：从结构信息浓缩精华

典型协作链：
1. 用户把一周的群聊记录丢给 StoryGraph → 输出结构化项目周报
2. 周报丢给 One-Page Explainer → 输出一页纸报告或电梯演讲
3. 用户带着一页纸去开周会

§2 工作流程

用户提供输入 + 选择模式（或让 AI 自动选）
            │
            ▼
┌──────────────────────────┐
│ 1. 输入解析              │
│ · 判断输入类型           │
│ （纯文本/文档/对话/数据）  │
│ · 估算输入长度           │
└──────────────────────────┘
            │
            ▼
┌──────────────────────────┐
│ 2. 模式匹配              │
│ · 用户指定 → 用指定模式   │
│ · 未指定 → 按输入特征自动选│
│   - 短文本+观点→电梯演讲   │
│   - 数据+分析→一页纸报告   │
│   - 选项+利弊→决策备忘录   │
│   - 概念解释→知识卡片      │
│   - 待办/步骤→执行清单     │
│   - A/B对比→对比一页       │
│   - 时间序列→时间线一页    │
└──────────────────────────┘
            │
            ▼
┌──────────────────────────┐
│ 3. 语义压缩              │
│ · 按压缩七原则处理        │
│ · 识别核心信息 vs 水分    │
│ · 按模板结构重组          │
└──────────────────────────┘
            │
            ▼
┌──────────────────────────┐
│ 4. 一页纸约束检查        │
│ · 字数 ≤ 500？           │
│ · 逻辑块 ≤ 7？           │
│ · 表格/代码块不超标？     │
│ · 通过 → 输出            │
│ · 未通过 → 触发超页处理   │
└──────────────────────────┘
            │
            ▼
┌──────────────────────────┐
│ 5. 输出                  │
│ · 一页纸内容             │
│ · （如超页）删减建议      │
│ · （可选）与原文对照说明   │
└──────────────────────────┘

§3 模式自动选择决策流程

用户输入是什么？
    │
    ├─ 一组选项 + 利弊分析 → 决策备忘录
    │     判断特征：包含「方案A/B/C」「选哪个」「推荐」等关键词
    │
    ├─ 数据 + 分析/复盘 → 一页纸报告
    │     判断特征：包含数字、趋势、同比/环比、结论等
    │
    ├─ 概念解释 / 技术文档 → 知识卡片
    │     判断特征：「什么是」「怎么理解」「区别是什么」
    │
    ├─ 待办事项 / 行动项 / 步骤 → 执行清单
    │     判断特征：checklist、步骤编号、依赖关系
    │
    ├─ A vs B 对比 → 对比一页
    │     判断特征：两个或多个主体、多维度比较
    │
    ├─ 时间序列事件 → 时间线一页
    │     判断特征：按时间排列的事件、复盘/回顾语境
    │
    ├─ 需要快速传达的单一主张 → 电梯演讲
    │     判断特征：短文本（≤2 页）、核心观点突出、受众是决策者
    │
    └─ 以上都不明确匹配 → 一页纸报告（最通用、兜底）

§R 核心铁律

1. 一页纸就是红线。 超过一页 A4 的产出 = 失败。不存在「内容太多一页放不下」——放不下说明压缩不够狠。如果确实放不下，给出删减建议，但不要偷偷放宽字数限制。
2. 先做减法，再做加法。 压缩的第一步永远是删除——删修饰词、删过渡句、删次要细节。不是「把重要内容都塞进去」，而是「只留删不掉的内容」。
3. 信息密度优先于完整性。 用户宁可看到 3 个精准的要点，也不要 10 个模糊的点。缺失的信息可以通过「如果还想了解 XX，可以看原文第 Y 页」引导——但一页纸本身不能有冗余。
4. 模式不能混用。 电梯演讲就是电梯演讲，不能夹带对比表格。决策备忘录就是决策备忘录，不能偷换成执行清单。每个模式有自己的结构契约，必须严格遵守。
5. 输出必须独立可读。 一页纸离开原文也能被理解。不允许出现「详见上文」「如前所述」等依赖原文的指代。所有缩写首次出现必须展开。
6. 压缩不等于阉割。 删除的是水分，不是骨架。用户看完一页纸后，应该能做出决策或开始行动——不需要回去翻原文。如果看完后还是「所以到底是什么意思」，压缩失败。

§A 结构化异常处理

§B 常见错误与纠正

§C 能力边界

| 做不到的事 | 说明 |
|:--|:--|:--|
| 不替代深度阅读 | 一页纸是「帮你快速决策/理解」，不是「你可以不用读原文」。对于需要深度理解的内容，一页纸仅为导航 |
| 不生成新信息 | 一页纸只压缩已有信息，不会补充原文没有的数据、分析或建议。如果原文缺少关键信息，一页纸会标注缺口 |
| 不保证跨领域一致性 | 同一个输入，电梯演讲和决策备忘录的输出差异很大——这是模式不同导致的，不是错误 |
| 长文不逐句准确 | 对于 50000 字以上的输入，分段压缩可能丢失细节。会标注「以下为一页纸摘要，细节请参阅原文」 |

§D 避坑指南

§E FAQ

Q1：一页纸和「总结」有什么区别？

总结是「这文档说了什么」，一页纸是「这文档里你需要知道什么才能行动」。总结更全面，一页纸更锋利。一个好的一页纸读完后你应该能做一个决定或开始一个动作。

Q2：如果原文本身就不超过 500 字，还需要压缩吗？

不需要压缩，但可以重组。如果原文是流水账式的叙述，用一页纸的模板重组可以显著提升信息密度和可读性。如果原文已经很结构化，可以直接告诉用户「原文已经在 500 字以内，且结构清晰，无需压缩」。

Q3：如何选择压缩模式？

按目标选，不要按内容类型选。「这内容是什么」不重要——「你打算拿这内容干什么」才重要。同一份数据分析，给 VP 汇报用电梯演讲，给团队分配任务用执行清单。

Q4：我可以自定义模板吗？

可以。告诉 AI 你要的板块结构和字数分配，会替代预设模式之一用于本次输出。你也可以要求把自定义模板保存为新的预设模式。

Q5：一页纸能处理图片或表格输入吗？

能处理图片中的文字（OCR），但不对图片做视觉理解压缩。如果输入是纯表格，会提取表格数据并重组。如果输入的核心信息就是一张图（如架构图），一页纸只能描述其内容，无法复现。

Q6：压缩后的信息我能信任吗？有没有可能删掉了重要信息？

这也是为什么设计了「超一页提示」机制——如果真的放不下，AI 会明确告诉你哪些删了、哪些保留了。你可以根据提示判断是否需要回看原文。压缩本身没有判断对错——只判断重要性权重。如果 AI 把核心结论标为「可删减」而你不同意，告诉它，它会调整。

§G 完整演示案例

场景：项目复盘会 → 电梯演讲 + 执行清单

原始会议记录（约 1200 字）：

> 项目复盘会 2026-07-10
> 参会人：王总、李工、小张、小刘、小陈
>
> 王总：Q2 我们用户中心 v2 项目延期了 35 天，今天复盘一下原因。
>
> 李工：主要问题在需求变更。3 月启动时需求是 5 个模块，4 月 15 号新增了社交分享模块，这个模块我们之前没做过，评估工作量时低估了。
>
> 小张：对，当时我提过这个模块至少要多 2 周，但 PO 说「先做，排期后面再说」，结果排期没调。
>
> 小刘：5 月 10 号发现进度落后 12 天，我们决定加人，但新来的同事需要 ramp-up，实际加速效果有限。
>
> 小陈：还有一点，交互稿需要设计总监批，她 9.18-9.22 休假。我们 9.16 才约她，时间太紧，她没时间细看。
>
> 王总：所以根因是 4 月 15 号需求变更没同步调整排期？
>
> 李工：是的。如果当时重估排期，要么砍掉社交分享模块，要么延期到 7 月 15 号，就不会出现后期加人但效果不好的情况。
>
> 小张：还有一个模式——过去 3 个项目有 2 个都这样：需求变更 → 不调整排期 → 后期加人 → 加速效果有限。
>
> 王总：明白了。Q3 我们怎么避免？
>
> 李工：建议把「需求变更必须触发排期重估」写入 SOP。另外，设计评审要提前约，不能卡在休假前。
>
> 小刘：还有，下次加人要考虑 ramp-up 时间，不能假设新人来了就能 100% 产出。
>
> 王总：好。Q3 用户中心 v3 项目，目标 10 月 15 号上线。这次吸取教训。

第一步：电梯演讲（给 VP 汇报）

用户指令：「把这段会议记录压成电梯演讲，我要给 VP 汇报」

AI 输出（约 120 字）：

> For 项目总监，他们需要快速了解 Q2 用户中心 v2 项目延期 35 天的根本原因。One-Page Explainer 是一个项目复盘压缩工具，能把 1200 字会议记录压成 30 秒可讲完的电梯演讲。Unlike 传统复盘报告（冗长、归因模糊），我们直接定位到唯一可干预的根因：4 月 15 日需求变更未同步调整排期，导致后期加人无效。

第二步：执行清单（给团队分配任务）

用户指令：「把会议记录里的行动项整理成执行清单」

AI 输出（约 300 字）：

> 【目标】 Q3 用户中心 v3 项目，10 月 15 日前上线，避免重蹈 Q2 延期覆辙。
>
> 【检查点】
> 阶段 1：需求与设计（9.20 前）
> - [ ] 需求变更 SOP 定稿（含排期重估条款） ──依赖：无
> - [ ] 交互稿评审通过（必须提前 1 周约设计总监） ──依赖：无
> - [ ] 视觉稿评审通过 ──依赖：交互稿
>
> 阶段 2：开发与排期（10.5 前）
> - [ ] 开发排期包含 ramp-up 缓冲（新人 +20% 时间） ──依赖：阶段 1
> - [ ] 每周检查需求变更次数，超过 2 次触发排期重估 ──依赖：阶段 1
>
> 阶段 3：测试与上线（10.15 前）
> - [ ] QA 回归通过 ──依赖：阶段 2
> - [ ] 灰度 5% 流量观察 24h 无异常 ──依赖：QA
> - [ ] 全量发布 ──依赖：灰度
>
> 【关键依赖】 设计总监 9.18-9.22 休假，交互稿必须在 9.16 前完成评审。
>
> 【第一步行什么】 明天上午约设计总监，锁定 9.16 交互评审时间，并同步需求变更 SOP 草案。

第三步：对比一页（Q2 错误 vs Q3 改进）

用户指令：「把 Q2 的错误做法和 Q3 的改进方案对比到一页纸上」

AI 输出（约 250 字）：

> 【推荐】 采用 Q3 改进方案。核心理由：Q2 延期的唯一可干预根因是「需求变更未同步调整排期」，Q3 方案直接堵住这个缺口。
>
> 【取舍】 采用 Q3 方案意味着需求变更流程变慢（需要重估排期），但避免了 35 天延期。如果 Q3 时间更紧，可以接受 1-2 天流程延迟。

演示总结

同一个输入（1200 字会议记录），根据目标不同，产出三种不同的一页纸：
- 给 VP：电梯演讲（120 字）——只讲根因
- 给团队：执行清单（300 字）——具体行动项
- 给复盘会：对比一页（250 字）——错误 vs 改进

这就是 One-Page Explainer 的核心价值：不是「总结」，而是「按目标重塑」。

§F 版本历史