读书笔记丨《启示录：打造用户喜爱的产品》

作为一个程序员，最近在 Vibe Coding 自己的 Side Projects 的时候，时常感觉到自己的产品设计能力有点捉襟见肘。不管是在 UI 还是 UX 的设计上，脑袋里基本上没有什么思路和方法论，只能寄希望于跟 AI 抽盲盒。结果自然也不会太好，因为在缺乏相关专业知识时，连需求都无法清晰跟 AI 进行准确传递。

举个例子，我在发现 Claude 的博文往往能给读者带来一种沉浸式阅读的体验时，我就萌发了参考它设计我的个人博客框架 Garden 的想法。

如果你不知道 Claude 的博文展示效果是什么样的，可以阅读下面这篇博文感受一下：

但是当我想跟 AI 进行交流如何设计这个博文的样式和交互逻辑时，我发现我对 Claude 的认可只能停留在一种"感觉"上面。我不知道如何去表述它，我也无法对 Claude 的博文页面带来的沉浸感做出相关的分析和解释。

又比如，当我尝试以 CUI（Conversational User Interface）的形式构建我的个人 AI 健身私教 Soma 时，如何将 GUI 和 CUI 进行结合、取长补短，从而设计出让用户使用起来真正舒服的 UI 和 UX 体验，也是让我无从下手。截至目前为止，我依旧是靠"感觉"。

为此，我开始尝试搜罗一些产品设计相关的材料，企图在这块能有所补足。我选择的第一本书是硅谷产品管理专家 Marty Cagan 所撰写的《启示录：打造用户喜爱的产品》（后面简称《启示录》）。因翻译质量问题，我阅读的是第一版。

本书并没有具体讲产品设计的具体实操和方法论，而是从人员、流程和产品 3 个角度，去讲述为了打造用户喜爱的产品，我们需要配备什么样的人员，这些人的职责划分和协作方式又应该是怎样的，在产品探索、执行过程中的流程管理又应该怎么进行，最后如何验证一款产品是用户真正喜爱的，并如何不断迭代它。

坦白而言，本书对于我在构建「产品」层面上，倒是没有给出太多新的启示，反而是在「人员」和「流程」这两个方面给我带来了很多的反思。当我在 Vibe Coding 的时候，我的身份更多的已经转移到类似产品经理这样的角色了，而我所陷入的低效和做无用功的误区，都是书中着重强调的点。具体详情我将在后文进行展开~

重点总结

按照惯例，还是先对书籍本身做一个笼统的概括总结。本书围绕三大模块进行展开：

人员

解决的是团队到底需要哪几类人，各自管什么、不管什么，他们如何进行合作。

流程

从冒出一个点子到软件上线，先迈左脚还是先迈右脚，怎么用最低成本试错。

产品

一款真正的好产品本身长什么样，有哪些绝不能碰的死穴。

人员

书中首先对比了"平庸团队"与"顶尖团队"的本质区别，这也是我们很多工程师在日常工作中最有共鸣的部分。

在传统/平庸的瀑布流模式下，经常会陷入下面这种循环中：

业务方/老板提需求

产品经理画原型、写 PRD

设计师涂颜色

工程师写代码上线

没人看上线后的实际效果，直接做下一个需求

这里的主要误区是团队成了"功能工厂"，以产出（Output，上线了多少功能）为衡量标准，而忽略了成果（Outcome，解决了什么业务指标或用户问题）。最糟糕的是，系统中最聪明的人（工程师）在最后一环才介入，沦为单纯的敲代码工具人。

而在现代顶尖团队中，高层只需给定战略目标（OKR/业务成果），由一个高度赋能的跨职能小团队（产品+设计+研发）自己去探索用什么方案来实现这个目标，并对最终的商业结果（Outcome）负责。

按照作者的思路，我们可以用 3 条具体的用人规矩来进行概括：

把"定义产品"和"搞营销、管进度"彻底切开

• 产品经理只干两件核心事： 第一是评估产品机会（判断哪个点子值得做），第二是探索并从细节上定义要开发的产品（包含功能和用户体验）。
• 绝对不能让做市场推广或销售的人来定义产品，也不能一个人定高层商业需求，另一个人写底层需求文档。一旦拆成两个人，就没人对最终产品负责，底下的产品经理也会退化成只会写文档的传声筒。
• 在频繁发版的互联网公司里，必须配备专职的项目经理来负责制定计划、跟踪进度和统筹发布，把产品经理解放出来专心研究用户和产品定义。

---

交互设计绝不能外包，且必须第一天就介入

• 用户体验设计细分为四个角色：用户研究、交互设计、视觉设计、原型制作。
• 视觉设计（配色、字体布局）在必要时可以外包，但交互设计（梳理解题思路、导航和操作流程）是核心竞争力，绝对不能外包。

---

把程序员拉到最前面探路，并留出 20% 的自由时间

• Marty Cagan 有一句名言："如果你只是把工程师当成写代码的资源，那你只发挥了他们一半的价值。"真正懂技术边界的是工程师。因此，资深工程师必须从产品探索阶段就介入，和 PM 一起探讨用什么技术方案能更巧妙地解决用户问题。
• 别只靠产品经理一个人憋创意，去开发、系统工程、客服等各个角落找出公司里最聪明的那几个人，把他们当成产品副经理，从更多的视角收集更多的思路和创新点。
• 推荐给开发团队预留 20% 自由支配的时间，由程序员自己决定拿去重构烂代码、完善架构还是打磨基建，防止技术债务不断累积，最终影响整个系统的稳定性和迭代效率。同时尤其是在大公司中，创新往往源自员工在这 20% 的自由时间中的自由摸索。

流程

为什么绝大多数公司（产品）都会失败？其中一个非常重要的原因，就是大部分团队都把大部分的精力花在了交付（Delivery）上，而没有做足够的探索（Discovery）。这一点笔者在今年入职大厂后感触是非常深刻的，也是笔者在阅读《启示录》后进行了最大的反思的一点，后文将单独进行详细展开。

不过作者在这一部分的叙述，我个人觉得还是偏适合从 0 到 1 的产品一些，对于从 1 到 100 的产品来说，值得借鉴的地方，就比较有限了。

这里我们可以用 5 个步骤来概括作者的核心思想，分别是：

立项前

定规矩

产品探索阶段

工程开发阶段

发布与改版阶段

立项前

我们前面说到，产品经理的核心职责就是评估产品机会和定义产品能力。作者建议在立项前，不要去写那种长篇累牍、没人看的市场需求文档（MRD），而是在投入人力之前，先回答 10 个机会评估的问题：

产品价值

产品要解决什么问题？

目标市场

为谁解决这个问题？

市场规模

成功的机会有多大？

度量指标或收益指标

怎样判断产品成功与否？

竞争格局

有哪些同类产品？

竞争优势

为什么我们最适合做这个产品？

市场时机

时机合适吗？

营销组合策略

如何把产品推向市场？

解决方案要满足的条件

成功的必要条件是什么？

继续或放弃

根据以上问题，给出评估结论。

这一步只准讨论待解决的问题，严禁讨论具体怎么设计的解决方案，防止因为某个具体方案遇到困难就把整个好机会一起扔掉，也避免花费了大量资源去解决一个无意义的问题。

定规矩

大部分团队会议之所以低效，甚至是存在争吵且无法达成一致共识，往往不是因为对事实有争议，而是每个人心里对"什么目标最重要"排序不同（比如到底易用性第一、响应速度第一、还是安全隐私第一）。

故而在做具体的产品决策之前，必须先把团队的价值准则，从最重要到不重要排好序写在白板上。这样才能在团队内部形成一致的价值观和判断标准，所有人的力才能使到一块去。

产品探索阶段

产品探索阶段其实要解决的就是"做正确的事"。这里的核心是在写任何一行生产代码之前，先用最低的成本造出高保真的原型，去验证 3 个核心风险：

1. 价值风险（Value）：用户真的需要吗？会买单吗？能否为企业创造价值？
2. 可用性风险（ Usability）：用户知道怎么用吗？交互顺畅吗？
3. 可行性风险（Feasibility）：现有技术架构、时间、算法或工程能力能实现吗？

这里作者提出一个最重要的观点就是废掉冗长的需求文档（PRD），用能模拟真实交互细节的"高保真原型"，外加少量的用例注释，直接作为交付给开发和测试的说明书。然后征集少量真正被问题困扰的目标用户作为"特约用户"，将原型给特约用户进行试用，观察他们的犹豫和表情，判断是否能真正解决他们的困扰。

这个建议我觉得在现在 AI 时代是更加提倡的，而且它的门槛被大大降低了。有了 AI 的加持，你可以很快速、很低成本地制造出能用于交互的系统原型。更关键的是，它的改动成本也被大大降低了，一旦出现设计上的不合理或是需要改动的地方，由于有了 AI 的辅助，改动时的抵触心理会被大大消解。

还有一个点就是，哪怕是用敏捷开发（Scrum），产品经理和设计师的进度也必须比开发团队领先一到两个迭代周期，绝不能一边画图一边让程序员写代码。

工程开发阶段

一个开发过程中老生常谈的问题：削减功能还是延迟工期？

作者给出的答案是不再试图定义最终产品，转而定义只满足基本要求（价值、可用性、可行性）的产品，简称基本产品。一旦基本产品确定，且通过了目标用户的测试，就不可能再削减任何功能。如果还能削减，那说明你定义的不是基本产品。

在这样的一个前提之下，我们可以定下两条铁律：

1. 如果写代码时发现工期估算太乐观，优先延长工期，而不是削减功能，因为你已经没有东西可削减了。
2. 一旦进入开发阶段，产品经理就不能随意修改设计。如果有新的设计点子，请安排到后续的迭代版本中。

发布与改版阶段

这一阶段主要是要把握 3 个点：

• 平滑部署： 老用户天生讨厌改变使用习惯。大改版时不要搞突然袭击，采用新旧版本并行过渡、按区域逐步放开或分成小块增量发布的方式，保护用户信任。
• 快速响应阶段： 产品刚发布的几天到一周内，项目团队绝对不能立刻解散撤军，必须留出时间每天开短会盯着线上量化指标和用户反馈，以最快速度打补丁解决暴露出来的问题。
• 改进产品： 改进产品不能一味地添加新功能，而是要分析用户体验相关的指标，能改进提升这些指标的功能，才是需要重点关注的。

产品

坦白而言，我是冲着学习产品设计的目标而读的《启示录》这本书的，不过在产品这一部分，我的收获是比较少的，个人感觉书中这部分的含金量也是比较低的。

作者认为任何一个优秀产品都必须同时满足 3 个本质特征：

• 可行性：工程师确认现有的技术条件和架构能做出来。
• 可用性：用户拿过来不用看说明书，就能知道怎么操作。
• 价值：不仅要能用，还需要用户内心极度渴望用它、愿意掏钱买单，或者愿意主动推荐给朋友。没有市场价值的产品，代码写得再好、功能做得再花哨，也是彻底的失败。

三个反思

在这个部分，我主要想分享一下我阅读完这本书后，以及在跟 Gemini 进行的多次探讨之后，回看我自己日常在工作中写业务代码、用 AI 开发个人项目，以及写这篇读书笔记的过程中，我得到的 3 个最大的反思：

流程上的反思

先探索后交付，别在 AI 面前成为自己最讨厌的那类"老登领导者"。

分工上的反思

分工的边界、笨功夫的必要性与对 OPC（一人公司）的重新理解。

写作上的反思

过度抽象会带来正确的废话，只有具体动作才能带来踏实的理解感。

流程上的反思

随着 AI 能力的不断加强，我们对效率似乎有了一种近似疯狂的追求，我们团队在今年上半年大肆宣扬要将研发效率提升 10 倍！虽然到年底的时候，已经没人再谈这件事情了。（😳）

不过 AI 给我们带来的编码上效率的提升，确实是无法否定的，至少在短期内来看，它确实极大提升了我们的开发速度。但是这也带来了不少的问题。

第一个问题就是领导会把开发工期压得极低，总要求在 1 到 2 天内拿到线上数据结果。关键是（我们团队）现在需求都不安排测试人员了，都需要自测。而公司内部的验证和发布流程又极其漫长。我估算了一下代码推到测试服并验证大概要 1 个小时，而走完线上发布加冒烟测试基本要 4~6 个小时起步，更复杂的业务系统光发布就要 7~8 个小时。再加上我们每周要进行若干次的日会汇报，留给需求分析、技术方案设计和代码审查的时间被挤压殆尽。更折磨人的是集成联调阶段，代码写完后总能撞上底层基建 Bug、第三方服务缺陷、或是测试服与正式服逻辑不一致，这个时候跨团队扯皮和等待排期会把耐心消磨得一干二净。

另外一个问题就是 AI 给我们的响应和反馈总是特别快速和及时，这导致我们的耐心和对空白的忍受力，似乎大大降低了。本来短视频这种精神鸦片就已经对我们的注意力产生了巨大的破坏了。AI 似乎让这个情况变得更糟了，更值得警惕的是，AI 会给我们带来一种"我一直在很努力学习、工作和产出"的假象。

回想我最近在使用 AI Coding 进行工作和开发个人项目的时候，即便在我一次又一次的"悔恨"之后，还是持续在犯一个很典型的错误：

注意

总是很着急拿到成果，然后一次又一次逃避思考，在不够冷静的情况下持续向 AI 输出错误或不够明确的指令，最后在踩了一个又一个坑之后，以更多时间交出了更差的结果。

我回头一想，在这种为了快速交付那个未曾深度探索和思考过的结果而疲于执行的过程中，我不正在一步步成为我最讨厌的那类"老登领导者"吗？—— 需求排期倒排，不懂技术细节却又爱胡乱指挥，需求说不清楚又爱责备，看到 Agent 闲着就心痒难耐而强行派遣一些无意义的工作。

为什么会陷入这种"越急越忙、越改越慢"的死循环呢？如《启示录》所提到的，是因为我把绝大部分的精力都砸在执行上面，却跳过了最关键的探索阶段。这种盲目驱使 AI 干活的方式，不仅会导致出现 AI 越强我越累的情况，还会让我在拼命忙碌了一段时间后只能得到一股一无所获的空虚感。

最近 X 上有一篇《如何在 AI Agent 工作时保持批判性思考》的文章非常火爆，可见有不少人也是遇到跟我一样的问题，感兴趣的读者可以阅读一下：

事实上，即便是此时我有如此痛定思痛的反省，我也无法确定未来再次深陷泥潭时，我是否还能拥有足够清晰的头脑以及做出足够冷静的判断。但此时此刻，还是希望能够给"未来的自己"提一些建议和行动指南，哪怕它们只能改变 1%，那也足矣。

1. 提交排期时要适当悲观一些，多加一点 buffer，不要迫于压力就主动压排期，遇到不合理的排期要求，通过将整个研发过程的每一个环节所需的人力进行拆解阐述，寻求共识。
2. 往往越急于交付结果的时候，越要停下来冷静思考，每一次指挥 AI 都不应该是为了快速看到 AI 的回复，而是要想清楚，如果我将这条指令交给一个真实的人，或是另外一个我，我表达得是否清楚，我有没有说清楚我要的是什么结果，这个结果通过什么方式可以得到验证，以及实现方式是否有一些必须要进行考虑、规避点。在 AI 实现之后，一定要深入细节去弄清楚整个逻辑的来龙去脉，更重要的，必须要知道如何通过外部环境进行观测、验证，并手动执行一遍确保可行。
3. 当 AI 陷入恶性循环、处于无限打补丁的情况时，那就必须要抽离出来，从源头思考，是不是哪些地方没讲清楚，是不是某些地方存在矛盾，还是说，连自己都根本没有想清楚要的到底是什么。
4. 在与 AI 交流的过程中，如果过程中出现不确定的点，那可以开启另外一个全新的会话进行探讨，不要在原会话进行探讨，避免上下文膨胀污染。而通过开启一个全新会话，可以逼迫自己对整个任务进行全面回顾和梳理，通过对一个空记忆的 Agent 讲清楚所有的上下文和关键阻塞点，能够更好理清思路，有助于找到突破点。
5. 永远不要一次性指挥多个 Agent，尤其是那种需要频繁介入的多 Agent。人的注意力是有限的，频繁切换上下文对大脑是一个极其大的挑战，更是对长期专注力的巨大破坏。慢就是快，少就是多。每一次都专注于以清醒的头脑指挥一个 Agent 完整完成一件独立的任务，效率和效果，都会是更优的结果，也能有效避免在巨大的忙碌之后感觉什么都没做的空虚感。

分工上的反思

《启示录》在人员篇里强调，产品经理、交互设计师、项目经理和程序员必须职责清晰，同时程序员要跨过边界，从探索初期就参与评估方案，而不是在下游当单纯敲代码的工具人。

AI 的到来打平了跨专业的入门门槛，让我们能靠 AI 在陌生领域演得像一个有 3 到 5 年经验的老手。但是对于像笔者这样的普通人来说，这似乎不全是一个好消息，随着而来的，更多是对自己职业生涯的危机感。而各类社交媒体的大肆宣扬，更是让我们无时不刻被这样的危机和焦虑所笼罩。

现在社交媒体充斥着各种"用 AI 一天搓一个产品"的爽文。随之而来的还有各种 OPC（One Person Company，一人公司）、OPT（One Person Team，一人团队）的概念。所有人都在鼓吹人人都是 Builder，所有人都在鼓吹执行再也不重要了，重要的是判断力和品味。如果不通过深入、重复地执行来了解底层细节的方方面面，我不知判断力和品味能从何而来。对于只站在宏观视角进行观望就能提升判断力和品味这一点，我是持疑的。

虽然我们前面在总结《启示录》时，一直反省缺乏深度探索的执行是如此低效，但我始终认为执行依旧是非常重要的一环。当然这里指的是带着思考的执行，或者称之为刻意练习，而不是麻木的重复劳动。

在我做 Side Project 的时候，我才深刻意识到要做一款优秀的、用户喜爱的产品，仅在做出来这一件事上，就需要凝聚太多个专业的智慧结晶了。更别说，做出来和卖出去，又是两件完全不一样的事情。

在跟 Gemini 探讨《启示录》这本书之前，我一直对 OPC 这类概念是持一种鄙夷的态度的。AI 虽然能降低我们入门其他专业的门槛，但是如果你都对这个领域不专业，你又如何指挥 AI 呢？你又如何对 AI 的产出进行有效判断呢？更何况，在产品运营过程中，每个环节都需要有人承担不同的责任，每个环节出现问题时都需要有人能做出判断和处理，那得多么天才的人才能同时在多个职责上都能够承担相应的责任并做出合理的判断和处理。会有，但我相信一定是凤毛麟角。

在本篇的开头，我讲到了我在参考 Claude 博文风格设计我的个人博客框架 Garden。在做的时候，我才知道自身对于审美这个词理解有多么匮乏和空洞。到底什么是审美？不知道，或许每个人都有自己的答案。但是如果你要去解释为什么 Claude 的博文页面的设计能带来这么好的阅读体验，你至少需要回答不同的色系、不同颜色搭配对于阅读体验有什么不同的影响；你还要知道不同的网页布局、交互动线对读者是否自然顺畅、是否会带来割裂打断；你还需要了解不同的字体、字间距、行宽和行间距会对阅读疲劳感带来什么不同的感受。

除了从读者的角度出发，你还要去思考，对于作者来说，当纯 markdown 无法很好表达观点的时候，如何引入类似 ChatGPT Intelligent UI 这样表现力更丰富直观的组件帮助作者表达观点，而组件带来的额外表达力，和其本身给写作带来的挑战和心智负担，这二者之间的权衡，你又要如何去抉择。

你必须分别深度担任作者和读者这二重身份，你必须亲自撰写足够多的文章你才能了解整个写作动线是否合理，你必须亲自阅读足够多的文章你才能知道距离真正的沉浸式阅读体验还有多少差距，你也必须去学习背后所涉及的专业知识，你才能对这些体验和差距给出更加准确的判断和前进方向。

又如我想尝试使用 AI 做健身私教而做 Soma，抛开技术本身，除了 UI、UX，你还必须对心理学、营养学、运动康复学和运动训练等各个专业领域知识都有所了解，你才可能做出来一款真正能帮助用户达到更健康的体魄的愿景。

我相信有过类似经历的读者，是可以理解我对 OPC 这类概念的鄙夷的态度的。自言自说的时候，我也时常用亚当·斯密在《国富论》里说的"社会生产力提升源于分工"这样的论据来加强自己对上述结论的认可感。不过坦白讲，你很难讲这里面没有掺杂一些因 AI 冲击带来的职业危机的防御性心理，以及我在大厂里长期担任螺丝钉（其实是螺纹 😄）所造成的眼界的局限性。

不过在与 Gemini 探讨之后，我的想法有了一些变化。

我虽然一直在肯定分工所带来的效率提升作用，但是我又何尝不是一直在经受分工所带来的折磨呢？为什么我在工作过程中，会常常因跨团队协作、对齐、扯皮而消耗了大量时间和精力呢？恰恰是因为我们的分工太细了！ 当每个团队、每个角色都只守着自己一亩三分地，只对自己那一环负责时，角色与角色之间的交接摩擦和沟通损耗就会呈指数级爆炸。

那是亚当·斯密错了吗？亚当·斯密在《国富论》里说的"社会生产力提升源于分工"，在今天的大厂和 AI 时代还成立吗？

我觉得依旧是成立的，但是我们需要额外去思考，分工带来的专业化收益，在什么条件下会被协调成本抵消？

亚当·斯密所处的时代，其实更多指的是造实物的物理世界，比如造车、造针。它是确定性的。造一根针，可以被拆分成约 18 道工序，由不同工人分工完成。因为铁丝的物理性质不会变，上一道工序切出来的铁丝，下一道工序直接磨尖就行，两个人之间不需要说话、不需要开会对齐。

而在信息世界开发软件是高度不确定的。需求天天变，上游改个字段、下游改个逻辑，全都要靠人跟人沟通来对齐。经济学里有个概念叫交易成本（在这里就是沟通扯皮的成本）。

重要

当大厂把组织切得像螺丝钉上的螺纹一样细时，分工省下来的那点写代码时间，远远抵不上跨团队拉群、开会、对齐协议、排期等待所消耗掉的时间。也就是说，在大厂里，很可能已经越过了提升效率的临界点，进入了越分工、越内耗的负收益阶段。

值得一提的是，AI 降低了执行成本，却没有自动降低判断、验证与协调的成本。因此，当执行速度大幅提升时，原本被执行时间掩盖的问题反而会集中暴露。

而《启示录》里面区分了产品经理、交互设计师、项目经理和程序员这样不同的角色和职责，是为了说明需要具备这些不同的专业能力，但绝不是让大家各管各的一摊事。作者强调的是技能专精，但边界高度重叠。在还没开始写代码的探索阶段，工程师就必须和产品经理、设计师坐在一起讨论。

所以以前我完全不相信所谓的 OPC，觉得光把一款产品做出来就要凝聚设计、研发、交互太多专业的智慧，更别提还要卖出去和日常运营，普通人根本承担不起这么多职责。

但对照《启示录》的基本产品原则，我意识到自己掉进了完美主义陷阱。我心里默认的好产品，是那种功能完整、界面像 Claude 官博一样精美、各个细节都挑不出毛病的产品。如果要做这种级别的产品，一个人确实绝对做不出来。 但是，现实中能赚到钱的一人公司，从来不做这种大而全、方方面面都专业的产品。

重要

一人公司真正的活法是：只找一个非常具体、非常小众的痛点，把这一个点解决掉，其他不重要的地方全部凑合。

写作上的反思

最后，再聊聊我在撰写这篇读书笔记时遇到的一个问题。

现在互联网就是一个巨大的垃圾场，到处都是 AI 生成的图文。我司内部论坛也全是那种 AI 生成的毫无营养的水文。为了对抗 AI 可能对深度思考和表达能力产生的负面影响，我开始要求自己要坚持阅读纸质书籍和手写文章。但是我总觉得在阅读完一本书之后，脑袋里空空的，很难说出我到底收获了什么。每当我想要落笔的时候，却又不知从何开始。

于是，我就硬着头皮写了一份读书笔记的草稿，发给了 Gemini，请它给我指点一二。

我当时对《启示录》做出了 4 点总结，当时的草稿是这样的：

如果对作者的核心观点进行抽象，那么可以用几句话来进行归纳：专业的人做专业的事情、做什么比怎么做更重要、永远以用户价值为中心、少即是多。

• 专业的人做专业的事情：作者提出了几种非常重要但是实践中却时常被模糊化的角色，分别为产品经理、项目经理、视觉设计师和交互设计师。在很多团队中，这几个角色的边界时常是模糊的，或是一人担任多个角色，或互有交叉，或是部分只能充当领队的传声筒，无法做出自身的价值判断。虽然能找到同时在多个方向都精通的综合性人才是最好的结果，但是每个人的认知带宽、学习精力、时间空间、责任承担都是有限的，这种属于是可遇而不可得。更多情况下，专业的人做专业的事，是更加可落地的选择。
• 做什么比怎么做更重要：很多团队往往花费大量的精力急于把一个产品快速做出来（实际上也不快速，过程中没有思考好的不确定性的事项，往往让工期比预期的要长得多），将大部分的精力都花在了执行层面。但是在执行之前的探索、思考、调研、验证却投入得不多。同时为了应对现实条件的各种约束和矛盾，必须在团队层面定义上层的团队原则和产品原则。
• 永远以用户为中心：这不是用户说要什么就做什么，用户是大概率无法阐述自己真正的本质需求的。这句话的意思是，在探索产品的时候，不能仅仅去思考产品的功能是什么，而要去思考产品的价值是什么，要去思考产品真正能解决用户的什么问题，以及能不能让用户以一种非常轻松、低摩擦、低认知负担、交互舒适流畅的方式来使用产品，这里面包括了产品的本身的功能价值、视觉价值和情绪价值。
• 少即是多：这是前面 2 条的另外一个综合体现，很多团队急于堆砌各种复杂、花里胡哨的功能，将整个界面设计得冗余、混乱，将交互设计得复杂、冗长、难以理解和习惯。本质上是没思考好到底要做什么，以及用户到底需要的是什么。

Gemini 给我的评价是这样的：

确实是如此啊！作为一个程序员，我们一直提醒自己要提升抽象能力，在写代码时，要养成提取公共方法的习惯。看到几段相似的逻辑，我就想把具体的业务细节擦掉，提炼出一个最通用的接口。

但当把这个习惯带到写读书笔记时，读完 300 多页的《启示录》，大脑自动开始提取公共方法，把书里具体的硅谷公司案例、具体的开会流程、具体的原型测试动作全部擦掉了，最后提炼出了四个最通用的句子。但其实它们都是正确的废话，这几个道理，不用读书，所有人都知道。或者说，我能从任何一本同类书籍里都总结出这几点，那就没意义了呀。

Gemini 给出的结论是：

重要

一本书真正值钱的地方，从来不是它的最终道理，而是作者为了做到这个道理，发明出来的"具体操作动作"和"反常识的规定"。

那如何重写这 4 句话呢？我们一起来看看 Gemini 的答案：

专业的人做专业的事

作者规定：产品经理、设计师、核心工程师这三个人，在需求还没定下来之前，必须每天坐在一起办公，共同对最终的业务指标负责。 尤其是工程师，绝对不能等产品经理画好原型图、写好需求文档了才开始看需求；工程师必须从第一天就介入，因为很多最巧妙的产品方案，是工程师根据现有的技术能力直接提出来的。

---

做什么比怎么做更重要

老板们开会天天念叨这句话，但底下人还是照样天天盲目加班写代码。为什么？因为没人告诉大家怎么在不写代码的情况下，证明一件事值得做。

作者给出了一套极其具体的动作：在让工程师写任何一行正式代码之前，必须先花几天时间做高保真原型（比如用交互软件画个假页面，或者写一段只有前端壳子、没有后端数据库的假代码），直接拿去给 5 到 10 个真实用户当面点一点、用一用。 如果这几个人用不明白，或者不愿意掏钱，这个需求当场砍掉，哪怕一行正式代码都不准写。

---

永远以用户价值为中心

所有的公司都说自己以用户为中心，但发任务的时候全是在发功能列表。

作者要求直接废掉传统的功能排期表（Roadmap）。上级给团队派活时，不准指定具体做什么功能，只准给要解决的用户问题或业务指标。比如上级不能规定下个月上线智能客服弹窗，只能规定下个月把用户的二次咨询转化率提高 10%。至于到底是用弹窗、还是改搜索算法，由团队自己去试。

---

少即是多

道理谁都懂，但在公司里，业务方提过来的需求都说很重要，你根本砍不掉。

什么是多，什么是少，不如任何新需求立项前，回答我们前面提到的评估产品机会的所需要回答的 10 个问题，定义出真正的基本产品。问题答不上来，或者逻辑不通，这个需求直接拒掉，这就从制度上帮做到了少即是多。

总结

什么是经典，《启示录》从 2008 年距今（2026）已经快 20 年了，即使这近 20 年来，互联网突飞猛进，技术也经历了无数次更迭，我们也到了所谓的 AI 时代了，书中所提到的人性、协作的摩擦、对真实价值的渴望这一内核从来没有变过，我们也不断地在重演历史上人们犯过的错误。

现在的互联网上充斥着太多的宏大叙事和速成爽文，有人告诉我们不用学代码了，有人告诉我们只有判断力和品味是这个时代唯一的竞争力。但当你真正深夜坐在屏幕前，去踏踏实实把一个小功能调优到能令自己满意甚至是欣喜的时候，你就会发现，那些浮于表面的喧嚣瞬间就会退去。而留给我们的，依然只有亲手触摸泥巴时的笨功夫，和在每一次踩坑与复盘中，那一点点艰难但真实长出来的认知。

我当然没有在这本书里面找到 AI 时代的答案，或许每一个时代的答案，也只有当时代落寞时，才会显现出来。但它给了一把足够锋利的尺子。拿着这把尺子去丈量当下的工作与生活，至少能让我在被算法和 deadline 推着向前跑的时候，还能停下来，清醒地知道自己究竟在为什么而思考。也衷心希望我这些谈不上思考的碎碎念，能够给你带来一些共勉，如果能有一些帮助，那就更好了~

Happy Reading~