当产品方向稳定后，客户差异不会消失，反而成为产品演进的关键考验。本文提出一套判断链：先明确产品真正要守的标准，再识别客户差异触及的层级，最后决定差异应如何承接。结合能源管理与设备维修场景，帮助产品经理在标准化与定制化之间找到平衡。

上一篇讨论项目交付中的产品演进时，核心问题是：产品已经形成以后，项目仍然会带回来新的需求和新的业务证据，产品不能拒绝真实修正，也不能让每一个项目重新定义产品。再往后走一步，问题会变得更具体——当产品方向已经相对稳定、目标客户没有发生根本变化、很多能力也经过多个项目验证以后，后续项目到底应该越来越标准，还是继续为不同客户保留差异？

真正做过一批项目以后会发现，客户差异不会因为产品成熟而消失。同样做设备维修，有的企业报修后直接派工，有的要部门负责人审核，有的达到一定金额还要增加审批；同样做能源管理，有的按部门核算，有的按成本中心，有的又按楼宇和经营单元核算。解决的是同一类问题，但对象关系、管理规则、流程责任和业务口径都可能不同。

麻烦不在于承认这些差异存在，而在于判断它们应该怎么被产品承接。有些差异是目标客户中长期存在的，产品如果不承接，就只能适配最早那批客户；有些只是当前客户的历史条件，硬做进标准产品，只会留下越来越多特殊逻辑；还有一些看起来只是字段、流程上的“小改动”，实际上已经开始改变产品原有的业务结构和责任边界。

团队最容易走向两个极端：一个是“这是标准产品，客户尽量按产品来”，另一个是“客户业务确实如此，那就想办法支持”。前者把早期项目经验固化成标准，后者则会让配置、开关和例外越来越多。久而久之，表面上仍然只有一个标准版本，内部却装满了不同项目留下来的特殊逻辑。

所以这篇文章真正要解决的，不是“客户差异怎么配置”，而是配置之前的一整条产品判断链。 面对一句“我们这里不一样”，先判断产品真正要守什么，再判断客户到底改了什么；然后判断这个位置是否应该长期允许不同，定义允许变化的边界，最后才决定差异应该放在配置、场景模板、扩展能力还是项目定制里。

这条链路里，前面的判断看起来比直接讨论功能更慢，却决定了产品几年以后会变成什么样。产品成熟以后，真正要积累的并不是一套“所有客户都一样”的固定答案，而是越来越清楚的标准与差异边界。

为了便于理解，后文会结合能源管理和设备管理两类产品中的典型场景进行拆解说明，让这些判断方法更容易对应到实际工作中。

一、先找准产品真正要守的标准

项目进来以后，最自然的动作就是拿客户需求和现有产品比较：现有产品是三级组织，客户需要五级；现有产品一张维修单对应一台设备，客户希望一次处理多台；产品现在的流程里有部门审批，客户说自己没有这个环节。这种比较对识别项目范围、工作量和交付风险当然有价值，但如果产品判断也停在这里，就很容易把“产品目前就是这么做的”误当成“产品以后必须一直这么做”。

而且产品运行时间越长，这个问题越隐蔽。数据库已经这样建、页面已经这样画、实施人员也按照同一套方式交付了两三年以后，很少有人再追问当初为什么这样做。历史实现慢慢就会获得一种“标准”的身份，后面的客户只要不一样，就被判断成特殊需求。

用设备维修的场景来举一个例子，假设早期几个客户都是“报修—班组长确认—维修主管派工—维修人员处理—报修人验收—工单关闭”，跑过几个项目以后，这套流程很容易被称为“标准维修流程”。后来新客户说自己没有班组长审批，报修后直接进入维修中心。如果只比较现有系统和客户流程，问题很快就会变成“要不要支持审批节点调整”。

但产品经理更应该先问一句：班组长审批，真的是维修管理这项能力不能变化的东西吗？把当前页面和流程暂时放到一边，回到维修管理本身，它解决的是设备发生故障以后，维修任务能够被正式接住，有人负责处理，过程能够追踪，最后形成明确结果。顺着这个问题往回拆，真正稳定的部分其实是故障或设备对象、维修任务、责任承接、处理过程和最终闭环，而“班组长审批”只是一种具体的管理控制方式。

维修任务必须有人承接并最终闭环，是产品需要守住的；班组长必须审批，不一定是。 产品真正的标准，应该来自它必须持续解决的业务问题、必须成立的对象关系和必须保证的结果，而不是过去版本碰巧采用的某种实现方式。

实际项目里也不需要为了每个争议需求重新做一次完整的产品定义。哪个能力正在被客户挑战，就把那个位置往回拆一遍。通常把下面四个问题说清楚，已经足够建立判断基准：

1. 这项能力到底在解决什么业务问题，最终要让什么事情成立？
2. 业务里真正重要的对象和对象关系是什么，哪些是后续能力成立的基础？
3. 哪些关系一旦被破坏，原来的业务就解释不通，数据结果也失去可信基础？
4. 产品最终要对什么业务结果负责，责任到哪里结束，再往后是否已经进入另一类业务问题？

以能源费用管理为例，它可以负责费用从计量来源归集到核算对象，并形成可解释、可追溯的费用结果；但这并不意味着客户后面提出财务开票、资金结算时，产品也要一路继续承担。同样，维修管理负责维修任务的接住、处理和闭环，并不天然等于还要继续负责供应商对账、合同扣款和付款申请。把这个责任终点找准以后，团队才真正有了一把判断客户差异的尺子。

二、客户说“不一样”，先看他到底改了什么

客户现场很少会按照产品经理方便判断的方式描述差异，更多时候给出来的已经是功能答案：“这里多加两级审批”“这个字段改成多选”“告警值改成80”“一张维修单关联多台设备”“费用再增加一种分摊方式”。项目团队如果把这些话原样带回来，讨论很容易立即进入开发：工作流能不能支持、字段要怎么改、影响多少页面、预计多少工作量。

但这些看起来都叫“客户差异”的需求，对产品的影响深度完全不同。真正有价值的动作，是把客户给出的功能答案重新翻译成业务变化，先搞清楚它动到了产品的哪一层。大体可以从浅到深看成五层。

第一层：只是表达方式不同

例如生产设备单元叫“车间”，客户习惯叫“生产单元”；我们叫“维修工单”，客户内部叫“设备处置单”。业务对象没有变化，对象关系没有变化，最终结果也没有变化，本质上只是名称和表达习惯不同。这样的差异通常不会改变产品结构。

第二层：参数或业务口径不同

系统默认告警阈值70，客户要80；有的企业5000元以上维修需要审批，有的是10000元；统计周期有的按日，有的按周。这类差异已经进入业务规则，但规则本身没有变化，变的是规则里的参数和口径，通常比较容易形成受控的可变点。

第三层：规则和流程不同

同样是设备维修，有的客户直接派工，有的必须审批，有的根据维修金额决定审批层级；同样是能源费用，有的统一按面积公摊，有的不同能源类型采用不同分摊规则。到了这一层，已经不是换一个参数，而是同一项业务“怎么运行”本身存在不同，后面要继续判断这种不同是不是目标客户中长期存在的管理差异。

第四层：业务对象或对象关系发生变化

比如产品原来是一张维修单对应一台设备，客户要求一张维修单同时管理多台设备；原来一个计量点对应一个核算对象，客户现场却是一块总表同时服务多个独立核算部门。这类变化最容易被低估，因为从界面上看可能真的只是把“单选”改成“多选”，但如果原有产品的大量逻辑都建立在一对一关系上，后面会继续影响设备履历、维修费用、故障统计、能耗归集和报表分析。

第五层：产品承担的业务结果发生变化

比如维修完成以后，客户还希望继续处理供应商对账、合同扣款、付款申请和财务凭证。入口仍然是维修工单，看起来只是“流程又多了几步”，但产品实际上已经从维修任务管理向供应商管理、采购甚至财务结算延伸。到了这一层，问题已经不再是功能怎么改，而是产品责任是不是开始发生变化。

所以，差异分类的价值不是把需求装进五个盒子，而是迫使团队把“功能改动”还原成“业务变化”。实际评审时，可以要求一个差异至少完整说清四件事：现有产品现在怎么处理，客户为什么不能这么处理，真正改变的是哪一层，以及这个改变还会继续影响什么。

例如客户只说“一张维修单需要关联多台设备”，讨论很容易停在设备字段怎么改。更完整的表达应该是：当前产品按一张维修任务对应一台设备管理；客户现场存在一次检修同时处理多台设备的情况；真正变化的是维修任务与设备之间原有的一对一关系；一旦调整，会继续影响设备履历、故障统计、维修费用归属以及工单完成判断。这样大家看到的就不再是一个“多选需求”，而是一个核心对象关系变化。

需求开发量的大小，和它对产品的影响深浅往往不是一回事。 一个字段从单选改多选，代码可能并不复杂，却可能动到核心对象关系；一个页面改几十个字段，工作量很大，却可能只是展示和交互调整。工作量要算，但产品判断不能跟着工作量走。

三、还在产品范围内，不等于产品以后都要接

把差异看清楚以后，下一步才是判断：这个位置是不是产品以后本来就应该允许不同。这里最容易混淆两个问题——“这个需求还属于当前产品解决的问题”与“产品是否应该长期为这种差异保留一个入口”，它们不是同一件事。

还是用维修审批来举例，客户A没有审批，直接派工；客户B一级审批；客户C根据维修金额走不同审批层级。通过拆解，我们已经知道三家客户的设备、维修任务、处理责任和最终结果都没有变化，变化集中在任务进入处理之前采用什么管理控制。它们都没有越出维修管理本身，但这只能说明差异没有越界，不能直接推出“所以产品一定要把审批开放成配置”。

同一个产品问题内部，也可能存在某个客户自己的特殊历史条件。如果只要“没越界”就全部留下来，产品最终还是会不断膨胀。更完整的判断，可以看成连续四道门槛。

第一道门槛：它仍然属于原来的产品问题

这一步确认的是产品责任没有被改变。审批层级不同，仍然是在解决维修任务怎样被接住和处理；如果需求已经继续延伸到供应商结算、付款和财务凭证，就不能再把它当成普通的维修流程差异。只有先守住这道边界，后面的“共性”判断才有意义。

第二道门槛：它是目标客户中客观、长期存在的差异

这和简单统计“有几个客户提过”并不完全一样。多个项目反复出现当然是重要证据，但有些差异即使目前只遇到两三个客户，也能看出它不是偶然。企业规模、组织权限、金额授权制度不同，维修审批天然就不可能只有唯一答案；相反，如果某个客户要求维修单编号必须兼容十年前自研系统的一套规则，即使这个项目很重要，也很难据此判断目标客户以后普遍都会有同样问题。

第三道门槛：这种不同有稳定、可描述的变化方式

光知道“客户经常不一样”还不够，产品要长期承接一个差异，至少要能够描述这种不同通常发生在哪里。连续看几个维修项目以后，可以发现审批真正变化的通常是是否需要审批、审批几级、由什么角色审批、什么条件触发不同流程。每家组合出来的结果不完全一样，但变化维度是清楚的。产品要沉淀的不是“A客户三级审批、B客户一级审批”，而是“审批控制本身是维修管理中一个长期可变的位置”。

反过来，如果做了几个项目以后，每个客户都说自己特殊，但这些特殊逻辑完全找不到共同变化方向，今天和旧合同有关，明天和老系统有关，后天又来自老板临时规定，那么即使它们都发生在同一个模块，也不意味着产品应该为它们创造一个“万能差异入口”。

第四道门槛：这种变化能够被约束和控制

最后还要确认变化不会把产品自己的业务结果一起开放掉。如果我们只知道客户这里经常不同，却说不清哪些东西不能变、变化最多到哪里，最容易得到的方案就是“做一个万能工作流”“让客户自己配”。表面上支持了所有客户，实际上只是把复杂度转交给实施和客户。

维修审批可以不同，但不管审批怎么变化，维修任务都应该有明确责任，需要产生处理结果，最终进入一个可判断的结束状态。如果某种所谓流程差异已经让这些基础结果都无法保证，那它就不能被当成普通变化点直接开放。

一个差异“还属于原来的产品问题”，只是第一道门槛。 只有当它同时是目标客户中长期存在的客观差异、变化维度能够被描述、变化范围又能够被控制时，产品才值得正式承认：这个位置，不同客户本来就可以不同。

这个判断形成以后，团队的工作方式会发生明显变化。下一个客户再说“我们的审批流程不一样”，大家不需要重新争论一次“这是不是个性化需求”，只需要确认这次不同仍然落在已经定义的变化范围里，还是出现了新的业务变化。产品真正沉淀下来的，也不是某一家客户的具体流程，而是一个被正式承认的差异位置。

四、决定长期承接以后，先把变化边界画出来

到了这里，维修审批已经不再是“临时满足某个客户”的问题,产品已经确认审批控制是维修管理中一个长期可变的位置，接下来才轮到“怎么接”。这个时候团队最容易说的一句话仍然是：那就做成工作流配置。配置当然可能是最终方案，但在决定实现方式之前，必须先回答一个更重要的问题——这个变化到底准备开放到什么程度？

一个长期差异要真正变成稳定的产品能力，至少要把三层边界说清楚：稳定部分、可变部分和变化限制。三层缺一层，都很容易让所谓“灵活”变成失控。

第一层：什么无论如何都必须成立

维修任务总要对应明确的故障或设备对象，任务需要有人承接，处理过程能够留下记录，完成以后形成结果，最后进入一个能够明确判断“这件事结束了”的状态。这些不是某一家客户的流程偏好，而是维修管理这件事能够成立的基本条件，也是后续任何变化都不能破坏的稳定部分。

第二层：哪些位置允许客户不同

是否需要审批可以不同，审批几级可以不同，由班组长、维修主管还是部门负责人审批可以不同，是所有任务都审批还是达到某个金额、故障等级以后再审批也可以不同。把这些变化位置定义出来以后，产品开放的就不再是“任何流程都能配”，而是几组已经被理解清楚的业务维度。

第三层：变化最多能走到哪里

没有任何处理结果的维修任务，不能因为流程配置而直接进入“已完成”；已经关闭的历史工单，不应该因为后来修改审批模板就重新改变原有状态；流程配置不能产生无法结束的循环；关键责任即使允许更换角色，也不能出现任务进入一个谁都不负责的状态。这些规则看起来不像功能，却决定了产品开放以后会不会把业务结果一起开放掉。

产品决定长期接住一个差异以后，不要马上跳到“配置几个字段”。 先把三句话说清楚：什么必须一直成立，哪些地方本来就允许客户不同，这种不同最多可以走到哪里。稳定部分越清楚，产品才越有资格把真正需要变化的地方开放出来。

五、差异被承认以后，才决定它应该放在哪里

前面几步走完以后，配置、场景模板、扩展能力和项目定制才真正开始有意义。因为这时我们已经知道差异是什么、为什么长期存在、变化范围在哪里，最后的问题不再是“做不做”，而是“这种差异放在产品体系的什么位置最合适”。不同性质的差异，本来就不应该被塞进同一种承载方式。

1. 配置：承接明确、稳定的长期变化点

像审批金额、审批角色、告警阈值、统计周期这些变化，位置明确、变化维度稳定，也有清楚的约束边界，通常适合通过配置承接。配置解决的不是“客户什么都能改”，而是“这里长期会不同，而且产品已经知道大致会怎么不同”。这也是为什么受约束的配置比固化一条所谓标准流程更合理。

2. 场景模板：承接成组重复出现的差异

还有一些差异单独看都能配置，但在某类客户里总是成组出现。比如能源管理产品连续做几家医院以后，可能会发现医院在重点能源对象、指标体系、重点设备分析和报表关注方向上经常形成一套相似组合。如果每做一家医院，实施人员都要把几十项配置重新组合一遍，研发虽然没改代码，项目团队实际上还是在重新设计一次。这个时候更值得沉淀的，不是更多配置项，而是一套经过项目验证的医院场景模板。

3. 扩展能力：承接已经形成独立业务问题的能力

还有一些需求确实有复用价值，但它已经不是原有能力里的一个变化点。比如维修管理不断往供应商维修、合同、结算方向延伸，如果这些内容逐渐形成自己相对独立的业务对象、规则和业务闭环，就不应该无限往维修工作流里继续加。更合理的方式，是把它形成相对独立的扩展能力：仍然属于整个产品体系，但不让所有客户都承担这部分基础复杂度。

4. 项目定制：承接没有稳定复用规律的特殊条件

最后一定还会剩下一些需求：某个客户因为老ERP需要特殊编码，某项业务因为一份特殊合同需要一次性处理规则，或者某种逻辑完全来自客户历史系统，又看不到其他目标客户存在同样条件。这样的需求留在项目里没有问题。真正需要担心的不是“还有定制”，而是明明是定制，却为了看起来产品化，把它包装成标准能力或隐藏开关。几年以后，系统里会留下很多谁都不敢删的配置，因为大家只知道“某个老项目在用”，却已经没人能解释它背后是什么稳定业务规律。

配置、场景模板、扩展能力和项目定制，不是产品成熟度从高到低的四个等级。 它们只是不同性质的差异，在产品体系里的不同承载位置：明确的长期变化点进入配置，成组重复的变化沉淀为场景模板，已经形成独立业务问题的能力独立扩展，没有稳定复用规律的特殊条件则明确留在项目。

到这里，从客户一句“我们这里不一样”开始，整条判断链才算真正走完：先找产品真正的标准，再看客户到底改变了什么；判断这个位置是否是目标客户中长期存在的合理差异；决定长期承接以后，把稳定部分、可变部分和变化限制说清楚；最后再选择合适的承载位置。直接从客户需求跳到“配置还是定制”，其实是把前面最重要的产品判断全部省掉了。

六、项目越多，产品真正应该积累的是边界

刚开始做产品的时候，我们非常想找到一套“正确答案”：标准组织应该几级，标准维修流程应该几步，标准报表应该有哪些，最好第一批项目做完以后，后面的客户全部照着复用。但真正做过一批项目以后会慢慢发现，很多行业场景根本不存在唯一的标准答案。企业规模、内部制度、业务成熟度不同，同一个业务问题出现不同做法并不奇怪。

所以项目数量增加以后，产品真正应该积累的，不是越来越多的客户做法，而是团队对边界越来越有把握。以前新客户说审批流程不一样，大家要从头讨论这个需求要不要做；后来知道审批控制本来就是长期可变的位置，只需要判断这次变化有没有超出现有边界。以前一张工单关联多台设备可能被当成普通字段改造；后来知道它进入了核心对象关系，就必须重新确认业务结构。以前客户说维修以后还要做供应商付款，项目可能顺势往流程里继续加；边界清楚以后，会更早意识到这已经不是审批怎么配置，而是产品责任开始发生变化。

反过来，如果一个普通项目团队已经知道哪些位置本来可以配置，哪些场景可以从现有模板开始，哪类需求需要重新进入产品边界判断，哪些特殊条件直接留在项目，那么产品的复制能力才真正开始出现。标准化最终降低的也不只是研发成本，它更重要的价值，是减少组织反复判断同一个问题的成本，降低业务长期依赖少数核心人员经验的风险。

回头看这篇文章的方法并不复杂：先从产品解决的问题和业务结果里找真正的标准；再把客户的功能要求还原成差异发生的层级；接着通过产品范围、目标客户长期差异、稳定变化维度和可控边界判断这个位置要不要长期承接；一旦决定承接，再把稳定部分、可变部分和变化限制画清楚；最后才决定它进入配置、场景模板、扩展能力还是继续留在项目。

难的从来不是记住这几步，而是项目一忙起来以后，我们很容易直接跳到最后一步：客户要什么，就讨论怎么实现。但产品做得越久越会发现，前面那些看起来慢一点的判断，才决定几年以后产品会不会变成一个谁都不敢动的“历史项目集合”。

标准产品不是让所有客户最后都变得一样， 更现实、也更成熟的状态，是随着项目越来越多，团队越来越清楚哪里必须一样，哪里本来就允许不同；为什么可以不同，以及这种不同最多能走到哪里。产品真正从“已经有了一个标准版本”走向“可以持续复制”，靠的不是消灭差异，而是把差异放进一条越来越清楚的边界里。