做减法比做加法更困难

最近和 AI 一起写东西，无论是设计一个产品还是敲一段代码，我有一个越来越强烈的直觉：相较于拼命的加模块加功能，真正更困难且更有价值的是做减法。

加法现在便宜到近乎免费。Coding Agent 如此发达，我们想加一个功能就是几句话的事，一天几十上百个commit，几乎可以无限地往上叠功能叠需求，叠到自己都记不清当初为什么要叠。但问题恰恰出在这里：过去那个"写起来很麻烦"的过程，本身就是一道天然的过滤器。麻烦会逼我们掂量，会让我们在动手之前先问一句"这玩意儿到底值不值得"，会让我们在做的过程中反思这么做的意义所在。现在那道过滤器被 AI 拆掉了。

于是问题的形状变了，从"我能不能做出来" 变成 "我该不该做"。前者 AI 替我们解决了，后者它一点忙都帮不上。能做和该做之间的那道鸿沟，在这个时代被拉得前所未有地宽。人的判断力没有被取代，只是被挤到了减法这一端，挤到了品味和克制上面。

工具越强大，对使用者的品味和克制力要求反而越高。加法需要脑子一热需要想象力，减法需要判断力。加法可以靠冲动驱动，减法只能靠原则驱动。加法让我们感觉自己在前进——commit在涨，功能列表在涨，多巴胺在涨。减法让我们感觉自己在删东西，那种「今天好像什么都没干」的焦虑是真实的。

但成本是恒定的。难道不用亲手写代码就把成本省下来啦？可惜并没有。

成本只是从开发那头，悄悄转移到了认知这头。每多一个功能，用户就多一分困惑，未来维护的人就多一层心智负担，整个系统就多积一份熵，最终变成让人头大的一大坨屎山。

最后附一下马老板的五步工作法：

第一步：质疑每项需求：先问：这个需求是不是本身就很蠢？不要因为需求来自聪明人、老板、客户、制度，就默认它合理。

第二步：删除不必要的部分或流程：尽最大努力删东西。删错了可以加回来，但大多数组织的问题是“为了保险而加东西”。如果你从来没有把东西删到需要加回来的程度，那说明你删得还不够狠。

第三步：简化和优化流程：等确认这个东西真的应该存在之后，再优化它。不要优化一个本来就不该存在的东西。

第四步：加速迭代：前面三步做完后，再提高迭代速度、交付速度、生产速度。也就是说，不要在一堆错误需求和冗余流程上卷效率。

第五步：自动化：最后才自动化。因为如果你先自动化，很可能只是把一个烂流程变成高速运行的烂流程。