问团队今年发了什么会得清单，问砍了什么便安静。做面向消费者的金融服务应用时，作者拒绝做文档中心（document hub）与通知中心（notifications centre）。两者易想，却是让组织脱责牺牲用户，尽管用户已期待。底下问题真：遗留系统产PDF因原邮寄，合规谈持久渠道，应用需放处。懒招是文档中心文件列表，但干系人加料终成谷歌硬盘（Google Drive）。

问一个团队今年发了什么，你会得到一张清单。问他们砍掉了什么，全场安静。

在做面向消费者的金融服务类 app 时，有两样东西我一直尽量硬顶回去。

一个是「文档中心」。

一个是「通知中心」。

这两个你都想象得出来，不用我多解释。在我看来，它们都是为了让组织省事、把代价转嫁给用户。当然也得承认，大量用户已经被训练成期待这些东西，并且大致知道怎么用——尽管它们很烂。

底层的问题本身是真实的。企业有遗留系统会生成 PDF——信函、对账单之类——因为最初这些东西是要邮寄出去的。合规专家还会跟你谈「持久通信渠道」。所以你需要在 app 里找地方放这些东西。

偷懒的解法就是文档中心。一个文件列表，选中，打开。

看起来很简单。

问题是，每个相关方都想学《神探可伦坡》再来一句「就多一件事」。到最后你基本上重建了 Google Drive，有标签、归档、打印，还有跨多个渠道的分享，每个渠道都有自己的怪毛病。更别提还要过安全和鉴权的关卡，确保对的人只看到对的文件。如此等等，没完没了。

而这只是把它做出来。

更别说你给自己造出来的维护负担，月复一月，年复一年，每次 iOS 发布周期一来，你赖以支撑某个功能的某个小特性被苹果单方面拿掉。或者被 Google、微软、亚马逊拿掉。

通知中心是同样的故事，只是开场白不同。某个相关方问，我们能不能在屏幕右上角放一个带小红点的铃铛图标。几个月后，你就在做一个劣质版 Gmail。

把账单摆在他们面前

这两样东西我都碰上过好几次。让人放弃脑子里的那个心智模型并不容易，尤其当用户焦点小组还在某种程度上给它背书的时候。老掉牙的亨利·福特那句话就浮上来——如果你去问人们想要什么，他们会说要更快的马，而不是汽车。

我发现真正管用的是把运行成本摆出来。不是开发成本，是运行成本，按年摊开。这往往能让人从悬崖边退回来。

但砍掉这个平台，原本的问题并不会消失。我们要怎么用适合客户的方式跟客户沟通，同时满足我方在法律上的义务？

我每次绕回来的答案都是：把每个用例单独拿出来看。严格追问到底需要说什么、什么时候说。然后毫不留情地问，它是否需要一个完整平台先建起来。这跟我一直用来挑问题的标准是一样的——它能让船跑得更快吗？

大多数时候——公平地说，不是所有时候——答案是：用一个简单的东西，或者用已经存在的东西，哪怕它并不完美。

抵制、抵制、再抵制那种做一个万能方案的冲动。

我甚至见过通知中心真被建出来了，结果那条原始消息想传达的意思，恰恰没法被这个为传达它而建的东西传达。

所以我的建议分两部分。对你允许加进系统里的东西要极其挑剔。对移除东西要像打仗一样坚决。

没人因为删东西而升职

第二部分比第一部分难得多，而且这不只是懦弱。Gerry McGovern 说这话说了很久了：

创造和发布的人得到奖赏和仰望，因为我们的文化仍然奖励生产东西，胜过其他一切。去审查、去维护、去移除——这些都被视为次要的工作。

他的 Top Tasks 研究发现，砍掉一个网站大约 80% 到 90% 的内容，反而让公司卖得更多、客服电话变少、用户更快找到想要的东西。移除本身就是改进，而不是改进之后的收拾。我之前也讲过一个缩小版的类似论证——删掉 FAQ 页面。

而且这比组织架构图更根深蒂固。Klotz 等人在《自然》上做了八项实验，发现人们系统性地忽视「做减法」的改变，即使移除明显是更好的选择。加法的想法来得又快又便宜，减法的想法要花真正的认知努力。所以我们是天生如此。

这意味着得花脑力去搞清楚成功到底是什么。而成功通常是客户世界里的事，不是组织内部的事。

可现在开发几乎不要钱了，不是吗？

DHH 对「无尽的执行」非常欢喜——在 agent 时代，每一个点子、每一个直觉、每一个实验都触手可及。

我觉得这很容易被误解成「那就一直做更多东西」的理由。

在我看来，用 agent 来做修剪才是更聪明的做法。做维护。审慎地移除东西，而且比任何靠人手做的人都要更仔细。

Stewart Brand 的《Maintenance of Everything》建立在这样一个悖论上：维护绝对必要，同时又完全可选。

与其说可选，不如说是「在被需要之前都是可选的」。

穿高领毛衣的那头大象

房间里那头穿着定做三宅一生黑色高领毛衣的大象，当然是乔布斯 1997 年那张四格矩阵。两个消费产品，两个专业产品，每个格子里一款王牌产品。

四个格子。每个格子一款产品。其余全部取消。

随后他关掉了人们正在做的所有其他产品线。这把工程人才聚拢起来，而不是摊薄。这是个勇敢的举动，也确实奏效。

苹果目前数下来有大约 52 种不同的产品和服务，所以终局从来不是只卖四样东西。重点在于让组织聚焦在最重要的那些上，这样他们才没有浪费掉那个让他们成为全球最大公司之一的机会成本。

一次一件事。Une chose à la fois.

（本来想写得更短，但想不出还能删什么。）

讨论整体偏向「少做、敢砍、别让维护成本拖垮团队」，但对「谁有权判定什么该砍」以及「有些功能其实是行业约定、砍不掉」存在明显分歧；另有一条反直觉经验：快速做出粗糙原型，反而比想清楚更能发现什么不该建。

认为砍功能才是真正的交付方式

• 别向功能蔓延妥协，把附着在船底的藤壶一个个铲掉；他们常把「自定义报表」这类需求顶回去一个月，先做用户真正会用的东西。（高赞）
• 发布的最佳方式就是砍需求，工程负责人必须长期在产品与设计面前为这件事据理力争。（较多人）
• 砍掉听起来酷、却不解决核心问题的功能，省下无数个迭代，代码更少、维护更轻；有团队就是靠加强版路线图修剪，才没把几个月浪费在没人要的东西上。（较多人）
• 有公司奉行「加一个按钮就先删一个按钮」：任何新 UI 元素上线前，先找一样东西删掉。（较多人）

认为最该先想清楚的是愿意接受哪些硬约束

• 「不建什么」其实只是第二重要的决定，第一重要的是你准备接受哪些限制与约束，而它们很少在项目初期被识别出来；最难逆转的往往是系统或数据施加的硬约束——数据可能根本拿不到、文件处理要跑几小时、单核跑不动持续增长的数据。（较多人）
• 真正能摧毁团队产能的是不断膨胀的维护成本：他见过六十年代建起来、如今废弃的公园和社区中心，教训就是先算养护账；再高质量的东西也要养，预算里必须留出运行阶段的开销。（较多人）

认为有些功能是行业约定，用户预期本身就改不动

• 如果做的是用户已经熟悉的产品，改变预期也许不难；但在他所在的睡眠领域，用户就是预期看到睡眠分期图和睡眠评分——这些东西其实说明不了什么，对多数人价值很小，但那就是行业默认的期待。（少数人）

认为问题在于「谁来判断」，而不在于该不该砍

• 这条原则谁都知道，但很少由单个工程师决定：产品在自己的领域里有判断力，高层在大公司里通常也大体一致；LLM 让快速造东西变得容易，这恰恰是陷阱。更麻烦的是，没人说得清「它能让船跑得更快吗」这个测试该由谁来执行。（较多人）
• 咨询顾问还得学会对客户说不：面对海量需求，排对优先级和管理进度才是关键，客户满意是优先项，但智慧更值钱。（少数人）

认为与其做五个低影响功能，不如直接修根因

• 宁可做一个高影响的功能，也不做五个没影响的；与其搭一个廉价的通知中心，不如解决「为什么需要通知」这个问题本身。（较多人）
• 他修过好几次宕机，源头都是学生被产品经理直接指挥、在没有资深技术负责人把关的情况下随手糊上去的「文档存储」「通知系统」，有一次甚至是用户头像把整个站点拖垮——做企业软件根本没人需要头像。（较多人）

认为快速做粗糙原型是发现「不该建」的最快办法

• 故意做得差一点反而有用，别困在整洁代码和测试覆盖率的教条里；时间约束压得越紧，越不容易做出毁掉整个项目的工程决定。90 分钟原型做完发现不成立，损失的也只是 90 分钟，而且这样更容易向利益相关者证明判断。（少数人）

有价值的补充

• 有人想用 LLM 自动接听并审问骚扰电话，靠语音识别和逐步提问把机器人挡在铃响之前，结果在安卓开发者社区得知：非 root 设备根本拿不到通话音频处理权限，iOS 同样不行。这个权限限制直接替他省下了一百小时。
• 做金融相关产品请务必提供一个「正式函件」页面：把每份被视为正式沟通的文件按名称、发送日期和下载链接列出来，只能追加、长期留存、按时间倒序排列，参与各方都该有。
• 一个精巧的玩笑概括了共识：决定很难，但必须做——毕竟我不是在建太空电梯。（@SP3269）
• 真正难的是知道何时停手，总觉得上线前还有一件事可以再改好。