第 24 章 · 写出能给别人看的 Review

Review 是唯一会离开你手里的东西，它必须自己站得住。

对付：分发鸿沟

Builder Review 是这一轮唯一会离开你手里的东西。

它会被贴进群里、发给想做类似事情的人、几个月后被你自己翻出来。所以它必须自己站得住——读它的人没用过你的作品，也不知道九个阶段是什么。

机制

Builder ReviewBuilder Review

一轮结束时的九段总结：问题、当初的依据、做了什么、发布了什么、谁看到了、谁用了、发生了什么、学到了什么、下一步决定。

为什么是九段而不是一段感想：这九段对应的是一轮里每一个可能出错的地方。写不出某一段，说明那个环节当时就是空的。

九段里最有价值的是第二段和第七段：

当初的依据（第二段）保存了你当时的无知——在什么认知下做的判断。这是以后能学到东西的部分。

发生了什么（第七段）是现实的回答。它经常和第二段矛盾，而那个矛盾就是这一轮的全部收获。

三条具体要求：

不要用课程术语。 不写「我完成了 Observe 阶段」，写「我花了两周观察这件事多久发生一次」。读者不需要知道这套框架。

给数字。 「发给 12 个播客主，7 个试用，0 个第二周再来」比「反响一般」有用一百倍。

写出失败的部分。 一份只有成功的 Review 没有人会认真读，因为它读起来像宣传。真正会被转发的是那些写清楚了「我原以为 X，结果是 Y」的。

两段对照合成案例

周言的 Review 第二段和第七段 · 停止之后

当初的依据：「我自己每期花 26 小时做逐字稿，连续两年。翻了三个播客社群，近半年 11 条抱怨转录质量。我自己维护了一份 300 词的专名替换表，周围至少两个主播在做类似的事。我据此认为：中文播客主需要一个专名准确的转录工具。」

发生了什么：「发给 12 个播客主，7 个点开试用，3 个传了音频，0 个第二周再来。追问其中 4 个，得到的回答高度一致：他们已经不做逐字稿了。有人改成只发音频，有人用 AI 生成摘要代替全文。」

学到了什么：「痛点是真的，但他们解决它的方式不是『找更好的转录工具』，而是『不做这件事』。我验证了问题，没验证解法是否被需要——这两件事我当时以为是一件事。」

第二段每一句都有数字和来源，所以第七段的反驳才有分量。如果第二段只写「我觉得播客主需要这个」，第七段就什么都证明不了。

把九段写出来，然后做一个检验：把它发给一个完全不了解这个项目的人，问他三个问题。

三个都答对，这份 Review 站得住。答错任何一个，就是那一段写得不够——通常是因为用了只有你懂的说法，或者缺了数字。

写出九段 Builder Review，每段都能被一个陌生人读懂。

至少三段里有具体数字。

写完做一次陌生人检验，根据结果改。

写不出某一段，说明那个环节当时是空的

不要硬编。写不出「谁用了」，就写「没有人用，我没有做到这一步」。

那是一条真实的信息，而编出来的内容会让整份 Review 失去可信度——包括真实的那几段。

只有成功的 Review 不会被读

它读起来像宣传，而且不提供任何可迁移的东西。

会被转发的是那些写清楚「我原以为 X，结果是 Y」的——因为别人可以用它检查自己的假设。