第 13 章 · 能力抽象

引言#

前面我们聊到，面对越来越复杂的业务，产品经理不能只盯着一条条需求，而要看见背后持续存在的对象、关系和规则。可这些东西一旦被看见，新的问题很快就会出现：下一次类似需求再来，我们还要不要从头做一遍？业务做得越久，这个问题越绕不开。今天做一次，过两个月换个场景又做一次；这次改几个规则，下次换一批用户、换一个活动，再重新设计、开发、测试。单看每一个需求都有自己的理由，也都能解释为什么“这次不一样”。可把一段时间里的项目摊开来看，又会发现团队不断把时间花在一些已经解决过、只是换了一种样子重新出现的问题上。

作为产品经理，我们看到这种重复以后，很容易想到复用。一个功能做过几次，就想把它做成公共能力；一段逻辑反复出现，就考虑能不能改成配置；几个需求看起来差不多，也会下意识地想把它们合到一起。这个思路当然没有错，重复开发本身就是成本。如果每一次业务变化都需要产品重新写一遍需求、研发重新实现一遍逻辑、测试重新验证一遍规则，团队很快就会被大量相似工作拖住。尤其当业务进入高频迭代以后，真正稀缺的往往不是一个功能能不能做出来，而是产研还有没有时间去处理那些真正新的问题。

但真正做多了以后会发现，事情没有“把重复的东西抽出来”这么简单。重复出现，不代表它已经稳定；看起来相似，也不代表它们真的应该共用同一套能力。有些需求只是参数不同，底下做的其实是同一件事；有些需求虽然页面、流程甚至名字都很像，背后服务的目标、约束和风险却完全不同。更麻烦的是，一旦某个东西被沉淀成公共能力，它影响的就不再只是眼前这一场业务。今天为了省一次开发做出的抽象，可能会成为以后很多需求都绕不过去的一层规则。抽得太晚，团队会一遍遍解决旧问题；抽得太早，又可能把一个还在变化的业务提前固定下来。所以我们不能把能力抽象简单理解成“怎样提高复用率”，复用只是结果，真正困难的是在一次次相似需求里判断：哪些东西已经稳定到值得从具体项目里拿出来，哪些东西还应该继续留在业务里变化。这一章我们就从这个问题开始，看一看当重复不断出现以后，产品经理到底应该看什么，才能判断一个东西是不是真的到了该被抽出来的时候。

13.1 识别重复——重复不是偶然#

2021年，我加入另一家头部社交电商企业，起初负责营销产品线。公司于2019年上市后，注册用户规模突破1亿，业务的主要服务对象也逐渐转向C端用户。随着用户运营、促销和大促经营越来越重要，营销活动的密度迅速上升，累计做了100多场活动、几十种不同玩法。内部通常按照S+、S、A、B几个级别组织营销活动：双11、周年庆这样的S+级活动，需要重新设计一套大型主玩法；38节、双12、国庆等重要节点会有中型玩法；月中、月末和日常促活里，则会穿插大量轻量玩法。我接手这块业务时，营销玩法已经不再只是给活动增加一点氛围，而是在用户活跃、交易转化和大促增长里承担越来越重要的作用。轻一点的有红包雨、九宫格、大转盘、下单红包，用户完成某个动作以后获得一次机会，再参与抽奖或者领取奖励；中型玩法通常围绕节日和促销主题展开，把签到、浏览、分享、拉新、下单等任务串在一起，让用户连续几天参与，再逐步获得积分、奖励或者兑换资格；到了双11、周年庆这样的公司级大促，玩法又会复杂很多，主线、支线、任务、社交互动和奖励体系往往会被组织成一套完整体验。站在用户面前，它们看起来当然不是同一种东西；站在业务侧，每场活动的目标、主题和节奏也各有不同。

早期大部分玩法还是按照一个个独立项目来做，从规则设计、交互视觉到研发测试，基本都围绕当次活动重新组织。这种方式最直接，也最容易满足当时的业务节奏。一个新玩法来了，产品先把参与规则、任务和奖励设计出来，设计团队完成交互和视觉，研发围绕这场活动做前后端实现，测试再把参与资格、次数、奖励、库存和异常情况逐项走一遍。轻量玩法通常需要1～2周，中型玩法往往要投入2～3周，大型玩法则经常需要数十人一起协作，一个月甚至更久。活动越来越密以后，不可能每一次都真的从零开始。已经做过的代码会被留下来，碰到相似需求时继续修改；一些结构相对简单、反复使用的小玩法，验证几次以后，也会逐渐把奖品、时间、投放页面这些地方改成可配置。但对大量中型玩法来说，更常见的还是把过去的项目翻出来，在原来的基础上做二次开发。

一次两次这样做并没有什么问题，真正麻烦的是，旧项目改得越来越多以后，过去每一场活动留下来的差异，也一起留在了代码里。去年为了某批用户增加的判断还在，今年又加了一套新的参与条件；原来只有一种奖励，后来又变成不同用户对应不同奖品；有些逻辑已经没人说得清当初为什么这样写，但又不知道还有没有其他活动依赖，也不敢轻易删掉。于是一个听起来只是“在去年玩法上改一下”的需求，研发常常要先把历史逻辑重新梳理一遍，再决定哪些保留、哪些修改、哪些继续兼容。产品也一样，旧PRD虽然还在，人群、任务、奖励、次数这些规则仍然要重新确认，测试也很难因为“去年做过”就直接跳过。当这种情况从一两个项目变成十几个、几十个项目以后，一些重复也开始变得越来越明显。今天是签到以后给一次抽奖机会，下一场可能变成浏览商品以后发积分；这次要求每个人每天参与3次，下一次又要限制任务完成次数；奖品从优惠券变成积分、实物或者其他权益以后，库存怎么控制、什么时候发、发放失败怎么办，又要重新讨论。它们并不是一模一样的需求，有些玩法放在一起看甚至完全不像，但产品、研发和测试真正坐下来拆规则时，会发现很多问题已经讨论过不止一次。

刚开始看到这种现象，我们很容易把它理解成“功能有点像，那就想办法复用”。两个抽奖玩法长得差不多，会先看看页面能不能共用；连续两年做相似的节日活动，会想直接沿用去年的代码；某个轻量玩法用得多了，就把整套玩法做成模板。这些办法当然都有价值，但它们解决的更多还是“怎么少做一点”。随着项目越来越多，另一个问题逐渐变得更明显：页面看起来相似，不代表背后做的是同一件事；页面看起来完全不同，也不代表里面没有同一种业务动作在反复出现。九宫格和大转盘在用户眼里很像，都是点一下以后得到一个结果。但用户为什么能获得这次机会、奖品从哪里来、每个人能参与几次，背后的规则未必一样。反过来看，集卡和红包雨在用户面前几乎不是一回事，一个围绕收集、合成和社交互动展开，另一个更像短时间内的即时抽奖，可真正做进系统以后，两边都会碰到任务有没有完成、机会怎么获得、奖励怎么发、什么用户可以参加、一天最多参与几次这些问题。到了大型玩法，这种差异会更加明显。每一次大促都需要新的主题、新的故事和新的用户体验，不可能因为去年投入很大，就把整套玩法原封不动地搬到今年。

真正反复出现的，并不一定是玩法本身。2021年双11让这件事变得更容易看清，那一年我们做了“集卡赢大奖”主玩法，里面有任务抽卡、组队、限时领卡、赠卡、索卡等多个机制，从产品设计到研发测试接近30个工作日，上线以后又连续运行了23天。把整个玩法摊开来看，用户签到、浏览、分享、下单是在完成不同任务；任务完成以后获得卡片，涉及机会和奖励；限时领卡要处理时间、次数和库存；不同用户是否可以参加，又涉及身份和资格；组队、赠送、索取，则进一步带来了用户之间的关系和状态变化。项目越完整，过去散落在不同玩法里的东西，反而越集中地出现在同一套系统里。那次项目结束以后，再回头看过去几年做过的玩法，很多事情开始连在一起。产品一次次重新定义任务，研发一次次重新实现奖励和机会，测试一次次重新验证参与资格、次数和库存。与此同时，我们又不能简单得出一个结论，说“这些东西都差不多，全部合起来就好了”。红包雨还是红包雨，集卡还是集卡，大型玩法也仍然需要新的创意和体验。真正值得追问的是另一件事：在这些不断变化的玩法里面，到底有哪些事情其实一直在重新发生？

过去拿到一场新活动，我们更习惯问：这次准备做什么玩法，去年有没有相似项目，哪些代码还能拿过来继续改。到了这个阶段，问题需要再往前走一步：先把红包雨、转盘、集卡这些最终呈现在用户面前的形态放到一边，看看这么多年反复设计、开发和测试的，到底是什么。如果看到的只是几个页面长得差不多，最后得到的很可能只是更多模板；只有当我们开始看见不同场景里反复出现的业务动作，能力抽象才真正有了起点。识别重复，不是急着把相似的东西合在一起，而是先看清：变化一直发生的时候，究竟什么东西还在反复出现。

13.2 抽出能力——先把稳定部分拿出来#

看见这些重复以后，下一步似乎很自然：既然任务、奖励、机会这些东西一直在不同玩法里出现，那就把它们抽出来；红包雨、大转盘、九宫格反复使用，就继续往模板化走；再往后，人群、任务、奖池之间还需要不断组合，规则引擎似乎也迟早要有。站在后来形成的系统往回看，这些答案都不难想到，但在当时，团队并没有直接按照这张“未来架构图”往下建。玩法中心的第一阶段只先做了两个能力：奖池和任务池。模板库没有同步建设，规则引擎也没有上，更没有把过去几十种玩法一次性整理成一套完整平台。因为真正需要判断的已经不是“这些东西以后能不能复用”，而是：哪些东西已经足够稳定，值得现在先从具体玩法里拿出来。

这个区别很重要，因为能力抽象本身也是一笔投入。过去定制一场活动，虽然会有重复开发，但目标至少很清楚：规则是什么，什么时候上线，这一场把它做完就结束了。可一旦要把某段逻辑变成公共能力，事情就不再只服务眼前这个需求。产品要重新梳理过去不同项目里的规则，判断哪些应该统一、哪些必须保留；研发要把原来耦合在活动代码里的逻辑拆出来，还要考虑以后不同玩法怎么接入；测试面对的不再是一组确定规则，而是不同条件组合以后会不会出问题；运营也要从“提一个需求”变成真正使用这套能力的人。与此同时，大促和日常活动还在继续发生，不会因为产品团队准备建设玩法中心就停下来等几个月。如果为了一个尚未被验证的未来，把大量产研资源先抽去搭平台，眼前业务反而被拖慢，这种抽象本身就未必划算。所以当时我们没有先讨论“玩法中心最终应该长成什么样”，而是重新把过去做过的玩法拉出来复盘。团队把历史活动里的任务、奖品和相关规则重新整理，看哪些东西出现得足够多，哪些已经在真实业务里反复验证过，接下来几场活动是不是马上还会继续使用，以及它解决的到底是不是一个长期存在的问题。这个过程和做未来规划有一点不一样：不是先想象以后可能需要什么，再把能力提前准备好，而是先看过去已经发生的事实，判断哪些东西其实已经被业务一遍遍证明了。

任务和奖励就是在这个过程中最先被确认下来的。签到、浏览、分享、拉新、下单这些任务会出现在轻量玩法里，也会进入节日活动和大型玩法；玩法外壳不断变化，“让用户完成一个动作，并判断这个动作有没有完成”这件事却始终存在。奖品也是一样，优惠券、积分、实物和其他权益一直在换，但业务始终需要准备奖励、管理奖励，再在满足条件以后把它交给用户。更关键的是，这些需求并不是产品团队为了做平台才假设出来的。它们已经在过去几年里被大量活动真实使用，近期业务还会继续需要，而每一次重新开发又确实在持续消耗产品、研发和测试的时间。到了这个程度，把它们从单个项目里拿出来，才有了比较明确的理由。

但同样的判断放到大型玩法上，答案就完全不同。双11和周年庆几乎每年都会发生，投入也远比普通玩法大。如果只看频率和产研成本，它们反而应该是最值得复用的一类：去年几十个人做了一个月，今年如果整套拿回来，不是可以省掉更多资源吗？可大型玩法承担的本来就是大促里的新鲜感和用户体验，主题会变，故事会变，互动机制也会变。今年集卡跑出了不错的结果，不代表明年还应该让用户重新集一遍同样的卡；周年庆今年围绕一个品牌故事展开，下一次也可能完全换一种表达。它们每年都会出现，却并没有因此变得稳定。高频只能说明一件事经常发生，不能说明它已经成熟到值得被固定下来。一些刚出现的探索性玩法就更明显，第一次做的时候，我们可能连用户会不会接受、规则有没有效果都还不知道，更谈不上下一次会不会继续使用。如果只是因为觉得“以后可能还会用”，第一版做完就急着抽成公共能力，很容易把一次尝试里的临时判断直接写进系统。为了兼容想象中的未来场景，产品会增加更多配置，研发会预留更多扩展，最后业务还没有验证清楚，系统倒先变复杂了。这样的能力即使以后真的用上，也可能因为第一版边界判断得太早，反而需要花更多时间重新调整。

所以后来再判断一个东西是不是该从具体项目里拿出来，频率只是一个起点。真正需要看的是：这个东西是不是已经经过足够多的真实业务验证，规则有没有开始稳定，接下来的业务还会不会继续使用，以及它现在造成的重复成本，是否已经大到值得我们承担一次公共化改造。一个能力出现十次，但十次都在大改，未必比一个只出现五次、却始终按照相近方式被使用的东西更值得先做。前者只是经常变化，后者才可能已经开始形成稳定的业务秩序。这里还有一层更容易被忽略的代价。定制逻辑做错了，影响的通常是一场活动，需求结束以后还有机会随着项目一起退出；公共能力一旦建出来，后面的业务会开始依赖它。新的需求会围绕它继续扩展，运营会按照它提供的方式做配置，产品需要持续维护它的边界，研发和测试也要保证旧场景不能因为新变化被破坏。原来藏在一个项目里的判断，慢慢会变成很多业务共同遵守的规则。所以能力抽象并不是简单把重复开发省掉，而是在判断：哪些业务判断已经足够成熟，可以从一次项目里的临时实现，变成团队愿意长期维护的公共能力。

从这个角度再看第一阶段为什么只做奖池和任务池，就没有那么神秘了。不是因为它们在架构图上应该处在最底层，也不是为了先把玩法中心搭出一个样子，而是当时的业务已经给出了足够多证据：它们会继续出现，基本动作已经稳定，而且继续每次重新开发的成本已经没有太大意义。至于模板库和规则引擎，团队虽然已经能够想象出来，却没有为了系统完整而提前建设。我们更愿意继续等真实业务往前走，看看新的变化会不会把这些能力真正“逼”出来。真正该先拿出来的，不是看起来最容易复用的东西，而是那些已经被业务反复验证、规则足够稳定，继续留在单个项目里只会不断产生重复成本的部分。

13.3 保留变量——让抽象跟着业务继续生长#

第一版只有奖池和任务池，并不意味着玩法中心已经设计完成。我们当时也没有急着把模板、规则和未来可能需要的各种配置一次性补齐。前面已经讲过，一个东西只有经过真实业务反复验证，稳定到一定程度，才值得从具体项目里拿出来。既然如此，后面的能力也应该按照同样的方式出现：不是先画出一张完整架构图，再让业务往里面填，而是让新的业务继续往前走，看原来的能力到底能支持到哪里。后来，裂变红包雨就是一次很典型的变化。

普通红包雨当时已经是一个比较成熟的轻量玩法，在不同级别的营销活动里都使用过。它的基本过程并不复杂：针对特定用户，在特定时间和页面触发红包雨，用户点击红包，满足条件以后获得一次抽奖或者领取奖励的机会。任务池和奖池建起来以后，其中两件事情已经可以独立处理：用户需要完成什么，以及完成以后获得什么。但业务并没有停在普通红包雨上。后来不同社群希望把红包雨和裂变结合起来，美妆社群可能希望用户先分享一段内容，美食社群可能要求分享某个商品，服饰社群则可能希望用户邀请好友助力。任务完成以后，有的活动增加一次抽奖机会，有的希望让红包“膨胀”，让用户进入一个价值更高的奖池。原来的任务池依然可以支持分享、助力这些任务，奖池也可以继续管理不同奖励。可把这两部分准备好以后，一场裂变红包雨仍然没有办法直接跑起来。新的问题变成了：这个玩法本身怎么玩，以及这些已经拆开的能力应该怎样组合。

过去做红包雨时，我们很少需要刻意区分这些东西。红包怎么下落，用户怎么点击，点击以后怎么开奖，谁可以参加，做什么任务，发什么奖品，一天可以参与几次，往往都跟着一场活动写在同一套玩法里。只要项目能够按时上线，这样做并没有明显问题。但任务和奖池被独立出来以后，再回头看红包雨，会发现其中有些东西其实一直没有怎么变。红包从页面上落下来，用户点击红包，完成一次开奖，这套核心交互是红包雨之所以成为红包雨的部分，页面结构和基础流程也相对稳定；相比之下，什么用户参加、需要完成什么任务、最后进入哪个奖池、完成任务以后增加几次机会，却会随着每一场活动不断调整。于是我们开始把红包雨本身和这些变化拆开：模板只保留页面基本结构、红包下落和点击方式、开奖动作以及基础流程，任务和奖品不再写死在模板里面，而是从外部绑定。这样一来，同一个红包雨模板可以接分享任务，也可以接助力任务；可以使用普通奖池，也可以在特定条件下进入更高价值的奖池。另一场活动如果只想做普通红包雨，也不需要带上裂变规则。红包雨没有因为被模板化就只能按照一种方式使用，反而因为稳定部分被留下来，变化的地方有了更明确的位置。

但做到这里，问题还是没有完全解决。任务、奖池和模板可以分别存在以后，它们之间怎么发生关系，仍然需要被表达。比如某类用户完成分享任务以后增加一次抽奖机会，完成助力任务以后进入另一个奖池；不同人群可以绑定不同任务，同一个任务完成以后也可能触发不同结果。如果这些关系每一次仍然写进红包雨代码，那么任务和奖池虽然已经拆出来，玩法一变化，研发还是要重新开发，规则能力就是在这个阶段变得必要的。它不负责某一个具体任务，也不负责某一种奖励，而是表达这些能力在什么条件下发生关系：谁完成了什么，接下来获得什么；满足哪个条件以后增加机会；什么人使用哪一组任务和奖池。过去藏在一场玩法代码里的判断，开始可以被单独配置和组合。到了这里，玩法中心里的几类能力才有了更清楚的分工：奖池回答“给什么”，任务回答“做什么”，模板回答“怎么玩”，规则回答“这些东西怎么组合”。

回头看，第一阶段没有模板和规则，并不是当时漏掉了这两个能力。如果当时只是为了让玩法中心看起来完整，完全可以提前把它们画进架构图，也可以先做出一套看起来很灵活的配置后台。但那时业务还没有把问题暴露到这个程度，产品很难知道模板到底应该固定什么，规则又应该允许哪些东西组合。提前做出来，很可能只是按照当时有限的经验去猜未来。裂变红包雨的价值就在这里：它没有推翻之前的任务池和奖池，而是在原有能力继续被使用的同时，把新的问题暴露了出来。原来已经稳定的部分继续保留，新的变化则帮助团队进一步看清，哪些东西属于玩法本身，哪些应该独立配置，哪些关系不能再继续写死在代码里。

所以“保留变量”并不是尽可能多做一些配置项，也不是为了以后什么需求都能支持。更重要的是在业务继续变化时不断确认边界：已经稳定的部分，不需要再跟着业务反复变化；仍然没有稳定的部分，也不要急着固定下来。当某种变化开始反复出现，而且边界越来越清楚时，再判断是不是应该把它从原来的能力里独立出来。第一版先有任务池和奖池，后来的业务又逐渐需要模板和规则，玩法中心就是这样一步一步形成的。它不是一次设计完成以后不断往里塞功能，而是在业务变化中把已经稳定的部分留下来，同时给新的变化保留空间。抽象不是让业务停止变化，而是让变化发生在该变化的地方。

13.4 纳入治理——复用越广，越需要边界#

玩法中心持续迭代以后，越来越多活动开始直接使用已经沉淀下来的任务、奖池、模板和规则。任务池后来积累了20多种任务能力，奖池基本覆盖了优惠券、积分、虚拟权益、实物奖品等常见奖励形态，模板库也逐渐有了10多个经常使用的玩法。过去很多需要产品和研发重新做一遍的事情，慢慢变成运营可以直接选择和配置。能力真正被用起来以后，我们遇到的问题也开始和以前不太一样。过去更关心的是一个东西能不能复用，后来才发现：复用得越多，一次修改可能影响的范围也越大。有一次A级大促，我们就在共享奖池上吃过亏。当时一个C端红包雨和另一个B端玩法恰好使用了同一个奖池，两个玩法虽然共用了奖池，对奖励的要求却不完全一样。C端玩法更在意用户参与后的完整体验，即使没有抽中主要奖励，一般也会准备一个兜底奖品，至少不要让用户点开红包以后什么都没有；B端玩法更强调PK和竞争，有些场景并不要求每个人都拿到奖励。负责B端玩法的运营调整奖池时，并不知道这个奖池同时还在被C端红包雨使用。修改以后，C端红包雨出现了“空包”，用户点开红包却什么都没有，很快引发了一轮集中客诉。

事情发生以后，第一反应当然是检查哪里配错了，把奖池恢复回来，再提醒相关同学以后操作时注意。但再往下追，会发现问题没有这么简单。负责B端活动的运营并没有主动去改C端红包雨，他只是修改了自己这场活动正在使用的奖池。真正变化的是，这个奖池已经不再只属于一场活动。过去一个奖池跟着一个项目走，谁在用、改了会影响哪里，几个项目成员基本都知道；现在同一个奖池可能同时被几个玩法调用，甚至在不同活动之间长期复用。对操作人来说，他看到的还是眼前这场活动，但系统里的影响范围已经变了。以前改的是一场活动里的配置，现在改的可能是几场活动共同依赖的东西。所以后来我们先补的，并不是什么新的玩法，而是让这种依赖能够被看见。运营准备修改奖池时，系统会提示当前还有哪些玩法正在使用，让他在真正修改之前先知道这次操作还会影响哪里。后来又发生过一两次类似问题，一些重要奖池的修改进一步接入了飞书OA审批，不再是谁能够进入后台，谁就可以直接改完生效。哪些人可以修改，哪些调整可以直接生效，哪些需要额外确认，也开始有了明确区分。

但审批也不是答案的全部，活动多起来以后，选错配置、改错条件，或者在不合适的时间动了一项规则，很难保证永远不会发生。真正重要的是，出了问题以后能不能尽快发现，能不能知道最近谁改过什么，又能不能尽快恢复。于是修改记录、异常提示、监控和回退这些过去并不起眼的东西，也开始变得重要。它们不是因为玩法中心做大了，所以后台应该越来越完整，而是因为同一个能力被更多业务使用以后，一次错误已经可能影响其他活动。复用减少了重复建设，也把原来彼此独立的业务连接在了一起。这件事也让我后来重新理解了“运营自己配置”这句话。刚开始做玩法中心时，我们当然希望把已经稳定的东西交给运营，让很多活动不再必须经过产品、研发才能上线。但“可以自己使用”和“可以随意修改公共能力”其实不是一回事。运营可以决定自己这场活动选择哪个任务、绑定哪个奖池、使用哪个模板。可如果要改的是一个已经被其他活动共同使用的奖池，或者一条很多玩法都依赖的公共规则，就不能再只从当前活动出发。使用能力可以尽量简单，改变公共能力却必须知道边界。

进入治理也不意味着玩法中心要把所有相关事情都自己做一遍。营销活动里会碰到数据观察、异常用户、薅羊毛和黑产风险，公司原本就有专门的数据和风控能力。玩法中心发展到一定阶段以后，我们更多是把这些成熟能力接进来，而不是重新做一套自己的数据和风控系统。玩法中心继续负责任务、奖励、模板和规则这些营销玩法里的事情，需要数据判断和风险控制时，就使用公司已经存在的能力。做到后面会发现，玩法中心也不需要因为自己已经成了一个平台，就把所有相关能力都收进来。该自己长期负责的能力要接住，已经有成熟公共能力的地方，则直接使用已有体系。

从最开始的定制开发走到这里，玩法中心面对的问题已经不只是“能力能不能复用”。当越来越多活动开始共同依赖这些能力以后，我们还要继续面对另一件事：一个公共能力被修改时，其他正在使用它的业务怎么办。如果这个问题解决不了，复用得越广，风险也会跟着一起放大。复用让一个能力可以被更多业务使用，治理则是让它在被很多人共同使用以后，仍然知道谁能改、会影响谁，以及出了问题应该怎样收回来。

闲言碎语#

有时候最难拒绝的，不是业务提出来的新需求，而是自己脑子里那张越来越完整的架构图。一个能力已经做出来了，很自然会想到旁边还有什么可以一起解决；一套配置已经能够覆盖几种场景，也很容易继续往下想，还有哪些情况可以提前兼容。再多走几步，原本只是为了处理眼前问题的系统，慢慢就会有更多层次、更多配置，也给很多未来可能发生的事情提前留好了位置。站在设计者的角度，这种感觉其实很好，原来散落在各处的东西被一点点整理起来，架构越来越完整，很多问题似乎也都有了自己的归属。

但业务很少会按照我们画好的结构往前走。有些当时觉得迟早会用到的能力，后来一直没有真正出现；有些为了兼容未来增加的配置，过了一段时间连产品自己都要重新研究才能说清楚；还有一些设计时觉得足够通用的东西，真正交到业务手里以后，反而因为理解成本太高，大家宁愿绕开它。系统里能做的事情越来越多，并不等于业务因此变得更简单。有时候复杂度没有被解决，只是被系统接管了：原来散在各个项目里的问题，换成了一种更集中的方式存在，任何一次变化，都会牵动更多地方。

所以后来面对这种“顺手再多做一点”的冲动，我会比以前更谨慎一些。产品经理当然应该想得比眼前的需求更远，但想得到和现在就要做，是两回事。一个暂时没有进入系统的东西，以后真的需要时还有机会再判断；一个过早放进公共层的设计，却可能很快被业务依赖，后面再想拿掉，成本反而更高。很多时候，知道一个东西可以怎么继续做并不难，真正难的是判断它现在有没有必要继续往前做。能力抽象做到最后，考验的不只是我们能不能把复杂的东西整理清楚，也包括能不能接受系统暂时没有那么完整。好的抽象不需要证明自己提前想到了多少未来，它更重要的是知道，哪些事情到了今天已经应该做，哪些事情还可以留给明天。