第 5 章 · 写出 30 秒能讲清的说明
你能在 30 秒内把它讲清楚吗？
讲不清不是表达问题，是范围还没想清楚。
- 这一章回答
- 你能在 30 秒内把它讲清楚吗？
- 你会做出来
- 一页纸的项目说明，含至少三项明确不做的东西
第一阶段的最后一章，产出是一页纸的项目说明。
检验标准只有一条：30 秒内让一个不了解背景的人听懂你在做什么、给谁做。讲不清几乎总是范围问题，不是表达问题。
机制
30 秒大约 120 字。这个长度逼出一件事：你只能提一个用户、一个任务、一个产出。
想塞第二个，句子立刻出现「以及」「同时」「还可以」。这些连词就是诊断信号——它们标记着你还没做的那个取舍。
一页纸讲清五件事：目标用户、问题、核心产出、成功标准、明确不做。
它不是给别人看的文档，是你自己的约束装置。三周后你想加功能时，回来看一眼就知道该不该加。
四个「一个」：一个主要用户、一个核心任务、一个核心产出、一个主要成功标准。
成功标准必须可验证。「做得好」「体验流畅」「提升效率」没有判定方式，所以永远不会失败，也就永远不给你信息。可验证的写法是某人在某天做了某件事——「下周一小林真的用它出了周报」在下周二就有确定答案。
写下来的、这一轮不碰的东西，至少三项。
强制三项是因为：列不出三个你会手痒的东西，说明你没认真想过边界。真正收敛过的范围一定有被砍掉的东西，而且你记得它们是什么。
现实案例
品牌文档里的定位：「EONLOOM builds focused AI systems that turn fragmented signals into useful outputs across creation, commerce and markets.」——一家做四个 AI 产品的公司。
网站配置里的定位：「EONLOOM builds products and learning systems for understanding, creation and informed judgment.」——一家做产品 + 学习系统 + 社区空间的公司。
两句话都在仓库里，都在生效：前者管 X 的内容，后者管网站。
这份冲突被记进了 open-questions.md，并标注为「这里最要命的一条，它改变了 @eonloom 被理解成什么」。
值得注意的是处理方式：他们没有当场选一个，而是给每一条冲突写了临时规则（「X 内容按品牌文档走，不要把学习系统和 Café 带进去」）和解决条件（「决定学习系统是不是公开叙事的一部分」）。
把悬而未决的事情写成「暂时怎么办 + 什么时候算解决」，比假装已经定了要诚实，也比一直悬着可执行。
第二版还有一个不明显的好处：它可以失败。下周一小林没用，你立刻知道，而且知道该去问什么。第一版永远不给你这种信号。
动手试
先确认问题本身成立——如果第 2 章那四条还没全中，说明还不到写说明的时候。
通过之后把说明写出来，对照下面的检查标准逐条过。
你的行动
写出一页纸的项目说明：目标用户、问题、核心产出、成功标准、至少三项明确不做。
然后做 30 秒测试：念给一个不了解这个项目的人听，问他「你觉得这是给谁用的、解决什么」。
他说错了就回去改说明——改成砍掉一些东西，不是解释得更详细。
检查标准
- 只有一个主要用户，句子里没有用「和」「以及」连起来的第二种人
- 只有一个核心任务和一个核心产出
- 成功标准写成了「某人在某天做了某件事」，可以在确定的时间点判定是或否
- 明确不做至少三项，每项都是我真会手痒去做的东西
- 我念给一个不了解背景的人听过，他复述对了
容易搞错的地方
第一反应往往是「解释得不够清楚，再加几句」。加完会更糟。讲不清几乎总是因为里面有两件事，正确的动作是砍掉一件。
写「不做区块链」没有意义，你本来就不会做。要写的是那些你已经想过而且觉得挺合理的：登录、保存历史、导出 Excel、移动端。这份清单的价值取决于它拦住的是不是真正的诱惑。
本章自测
- 为什么 30 秒讲不清通常是范围问题？
- 「提升效率」为什么不能作为成功标准？
- 「明确不做」里该写什么、不该写什么？