先说个我自己的经历。早年我一直做C端产品后来有一次接手一个面向企业客户的交易类系统习惯了用“用户漏斗”和“次日留存”思考问题结果上线第一周就被客户方的采购负责人按着合同条款逐条质疑说我们的规则设计“不具备履约刚性”。那次之后我才意识到所谓B2C、B2B、B2G的产品规则根本不是同一件事——它们之间的差异大到足以决定一个功能模块从设计到上线全过程的走向。这也是我想开这个系列的原因。这个系列准备用五十二篇的篇幅把B2C、B2B、B2G三种业务形态下的产品规则做一个系统性的拆解。写这件事的底气不是我多厉害而是过去这些年确实在这些领域里摔过、补过、复盘过。这个系列的定位是给三类人看的一是正在从C端转向B端或G端的产品经理二是需要把业务规则落地成系统逻辑的数据工程师三是做售前或交付的解决方案同学——你们每天跟客户谈需求时那些被客户反复强调的“我们公司的规定”本质上都是产品规则在不同场景下的变形。这篇作为系列的第一篇先把地基打好为什么产品规则要按B2C/B2B/B2G拆开讲三者的差异到底体现在哪几个关键维度以及整个五十二篇的总体框架是什么。1. 为什么这个系列要从“模式分类”讲起很多人会觉得规则就是规则不管什么商业模式用户下单就要校验库存、企业采购就要走审批流、政府采购就要走招投标这有什么区别区别大了。区别不在于流程本身而在于规则被谁定义、为谁服务、以什么形式存在、错了要付出什么代价。1.1 一次跨模式转型的尴尬经历刚才提到我那次从C端转B端的经历值得详细说说。当时我做的那个项目本质上是一个给企业客户用的采购协同平台业务上需要支持多种结算方式还要跟客户自己的ERP系统做对账。我按C端的习惯把结算规则写得很“灵活”比如支持自动抹零、支持优惠券叠加、支持支付后修改收货信息等。结果客户方在验收测试时直接抛了个问题你们的规则在合同里对应哪一条我们约定的是“月结30天逾期按日万分之五计息”你的系统里怎么没有体现我一下子懵了。在C端规则是平台说了算用户只能接受在B端规则是双方在合同里写死的系统只是把合同条款翻译成可执行的逻辑。你说这能一样吗那次经历给我最大的教训是产品规则的第一性问题不是“怎么实现”而是“这些规则是从哪里来的、代表谁的意志、在什么约束条件下成立”。C端的规则像店铺门口的告示商家定、顾客看、不满意可以换一家B端的规则像双方法务审过的合同条款每一条都有编号、有责任人、有违约后果G端的规则更像法律法规的执行细则不仅要合规还要经得起审计和追溯。1.2 三种模式背后的“生意本质差异”再往下拆一层。B2C、B2B、B2G的本质差异要放到“生意”的语境里看。B2C的生意是高频、低客单、海量用户的零售逻辑。规则要解决的矛盾是“让用户体验顺畅”和“防止平台被薅羊毛”之间的平衡。所以C端规则必须轻、快、用户几乎感知不到。B2B的生意是低频、高客单、深度服务的合作逻辑。规则要解决的矛盾是“双方权利责任对等”和“流程效率可接受”之间的平衡。所以B端规则必须重、准、每一条都能追溯到合同或商务约定。B2G的生意是项目制、预算制、强程序逻辑的公共采购与服务逻辑。规则要解决的矛盾是“合规透明”和“按期交付”之间的平衡。所以G端规则必须全、稳、经得起任何一方的审计。这个差异不是某一个人拍脑袋定的而是由三种市场里“钱从哪来、决策怎么走、关系如何存续”决定的。B2C里用户用脚投票B2B里客户用合同投票B2G里一切依程序而行。产品规则不过是这些底层逻辑的表层投影。1.3 五十二篇的整体地图既然定了要写五十二篇这个系列自然需要一个结构。我把它拆成六个子系列每块大约八到十篇首尾再各留开篇与收篇。子系列覆盖篇数核心内容方法论篇01-06规则的本质、来源、结构、退化、演进与治理B2C规则篇07-18用户侧规则、交易规则、风控规则、营销规则、个性化规则B2B规则篇19-32合同规则、SLA规则、结算规则、权限规则、组织与审批规则B2G规则篇33-44招投标规则、预算与支付规则、交付验收规则、合规留痕规则数据科学视野45-50规则数据化、规则挖掘、规则仿真、规则评估与A/B测试专题与案例篇51-52跨模式融合案例与全年精华复盘在这个框架里每一篇都会避开“教科书式”的讲法尽量用我在具体项目里遇到的真实冲突和取舍来讲。今天这篇是方法论的起点后面每一篇都会引用这里建立的概念框架。2. B2C、B2B、B2G的硬差异到底在哪一线对比这一节要做的是一件很朴素的事把三种模式摊开来逐项比。很多人对B2C/B2B/B2G的差异停留在“客户不同”这个层面但落到产品规则的颗粒度差异被我分成四个维度客户与决策链、生命周期、价值度量、规则属性。2.1 客户、份额与决策链的差异B2C的客户是个人决策链基本等于一个人。哪怕家里要买个大件商品最多也就是两口子商量一下决策周期以小时到天计。这意味着C端规则可以走“默认最优快速纠错”的路线因为任何一个用户的反悔成本都很低。B2B的客户是一个组织决策链由使用者、采购者、决策者、法务、财务甚至高层共同构成。我见过最夸张的案例是一个几百人的企业客户买一套报销系统光内部评审就跑了两轮涉及六个部门签字周期拖了小半年。B端规则要服务的是这条链子上所有人的诉求使用者要体验、采购者要比价、财务要合规、法务要免责、高层要战略价值。B2G的客户本身就是“程序”的产物决策链藏在公开的采购流程里。产品规则设计的核心不是让哪个人满意而是让整套程序走得通资格预审、招标文件、评标标准、合同签订、验收交付每一环都有明确的规则要求几乎没有留给产品经理自由发挥的空间。2.2 规则属性的差异隐性 vs 契约化 vs 刚性这是我特别喜欢讲的一个维度。B2C的规则大部分是隐性规则。平台设置了风控规则但不会告诉用户“你的账号因为异地登录被拦截了”平台设置了价格规则但不会把价格计算公式公示出来。C端用户感知到的是“规则的结果”很少看到“规则本身”。B2B的规则是契约化规则。客户跟你签约时附件里往往有一份几十页的服务条款里面的SLA、结算周期、数据归属、违约责任全部要落到系统里。B端规则不存在“藏着掖着”的可能任何一个字段的变化都可能在审计时被要求提供依据。B2G的规则是刚性规则。政府采购的评标办法、预算定额、支付条件全都有公开的文件依据。系统里如果某个字段校验规则与招标文件不一致那就不只是系统Bug的问题而是会被质疑为“违规操作”。G端的规则不是用来“优化用户体验”的是用来“证明我们按规矩办了事”的。2.3 一张表看懂三种模式的产品规则重心把上面这些铺开需要一张能放进收藏夹的对照表。对比维度B2CB2BB2G客户主体个人组织公共部门决策链长度1-2人5-20人程序化流程采购频率高频低频低频项目制客户生命周期短依留存而定中以合同周期计长以项目与框架计价值度量转化率、客单价、留存合同金额、续约率、毛利率项目回款、合规率、复投率规则存在形式隐性、动态可调显性、契约绑定刚性、程序绑定违约代价用户流失赔偿、诉讼、商誉损失处罚、失去准入资格规则变更频率极高中低系统侧典型形态推荐、风控、营销CRM、ERP、合同、BPM政务平台、采购系统、审计系统这张表不是绝对的比如部分高频B2B服务如云服务充值就更接近C端形态但不影响它作为判断框架。当你拿到一个项目先拿这张表对照一下大概率能快速判断这个产品里什么样的规则才是主角。3. 产品规则到底从哪里来四大来源与拆解讲完了三种模式的差异接下来就要回答一个更根本的问题产品规则凭什么这么定很多产品经理都有一个误解以为规则是产品经理“设计”出来的。其实不是产品经理更多的是“翻译”和“取舍”把来自不同方向的约束转译成系统逻辑。我把产品规则的来源归纳为四类。3.1 组织基因规则自带“出身”第一个来源是组织基因也就是这家公司自己长期形成的打法。比如一家起家于电商的公司它做任何交易类系统时都会天然把“用户体验优先”写进规则里而一家起家于企业软件的公司做同样功能时第一位考虑的一定是“权限清晰、留痕完整”。这在跨模式做产品时特别容易踩坑。我见过一个团队公司是做B2B起家的后来想做一款面向个人用户的企业服务工具硬是把企业端的审批流塞给个人用户结果用户流失率极高。根子就在于团队的产品基因还停留在“B端规则是契约的一部分”这个认知里没有切换成“C端规则是体验的一部分”。所以拿到一个项目先去问这个团队的基因在哪公司过去最擅长的那套规则逻辑是什么这个逻辑到了新的业务模式里哪些该保留、哪些必须推翻3.2 客户契约B端和G端的规则之源第二个来源是客户契约这是B端和G端产品与C端最显著的分水岭。B端的合同、SLA、SOWG端的招标文件、框架协议、实施合同里面所有的条款都直接决定了系统的规则字典。我一个做企业服务的朋友给一家外资客户做项目排期系统客户方的法务要求所有系统的时钟必须统一使用UTC时间而不是本地时区理由是为了跨区域审计的一致性和证据链的完整性。这种规则看起来“不讲道理”但它是写在合同附件里的系统就必须遵守。契约里给了一条规则的依据系统里就要有呈现该依据的字段这就是B端规则的设计常态。做B端或G端产品第一步检索的不是用户画像而是合同与法规。把“付款条件”“交付标准”“验收流程”“违约条款”全部列出来再看系统需要哪些规则来承接。3.3 历史补偿规则的“补丁”逻辑第三个来源是历史补偿它解释了为什么很多系统的规则看起来“又多又怪”。每一条怪规则背后大概率都有一段被钻空子的血泪史。举一个最常见的例子很多电商或交易平台在早年支持“下单后修改收货地址”后来有人利用改地址功能刷单或诈骗平台就加了一条规则“订单支付后24小时内可修改一次超过时限或部分商品不支持修改”。这条规则不是凭空设计的而是对历史漏洞的补偿。新同学看到这种规则时最忌讳的是“帮用户吐槽”或试图“简化规则”。在动任何看似不合理的规则之前先去查一下它的历史背景它是谁在什么时候加的当时出了什么问题如果把这个规则删掉当年的那个漏洞还会不会再次被打开3.4 法规映射合规不是规则本身而是规则的前提第四个来源是法规映射。这里说的不只是“公司要遵守法律”这种大而化之的东西而是具体的法律条文如何映射成系统里的字段校验、流程分支和权限控制。比如各类交易系统里的发票规则为什么同一个商品有时能开专票有时只能开普票为什么个人用户和企业用户的税率字段不同这些都不是产品经理的偏好问题而是税务规则在系统里的落地。再比如消费者权益保护相关的规则为什么七天无理由退货在C端是“默认开启”而在B端设备采购里却是“商务谈判决定”背后就是监管逻辑对不同交易场景的差异化要求。做产品规则的人必须建立一种“规则解释”的习惯每一条规则都要能回答“它对应的是什么依据”这个依据可能是内部制度、客户契约、历史教训或外部法律。如果你发现一条规则什么都对不上那它要么是废规则要么是你还没找到它的出处。4. 规则冲突时怎么办仲裁优先级真实世界里规则之间是会发生冲突的。一个典型的场景客户在双十一大促期间下单平台的价格规则说“满减可叠加”但企业的协议价规则说“该客户不参与大促满减”两边一碰撞到底按哪个走这种问题不解决系统就会表现出“时灵时不灵”的规则飘忽感。要解决就得给规则建一套仲裁优先级。4.1 一个真实的冲突案例我之前参与过一个混合型平台既有面向个人的零售业务又开放了面向企业客户的采购通道。有一天运营报了一个Bug某个企业客户在平台上采购了一批商品结算时系统按C端促销规则自动套用了“跨店满减”导致结算金额比合同协议价还低财务那边直接炸了。排查下来根因是系统的促销引擎和协议价引擎是两套独立服务促销引擎先计算了C端优惠协议价引擎后覆盖时发现金额已经不匹配于是选择了“不再调整”。两条规则都执行了但执行顺序错了形成了事实上的“规则冲突”。这个案例说明了一个很朴素的道理在混合业务模式里规则的冲突不是“有没有”的问题而是“何时发生、怎么裁决”的问题。4.2 规则优先级仲裁的基本设计我后来在实践中总结了一套相对稳妥的仲裁层级不一定适用于所有场景但可以作为初始设计优先级规则层级说明P0平台底线规则法律合规、资金安全、账户安全、人身安全相关P1契约规则合同约定、协议价格、SLA、结算条件等白纸黑字的条款P2活动规则促销、优惠、积分、补贴等活动类规则P3默认规则平台默认的展示、排序、推荐等体验类规则这个逻辑的顺序是合规底线优先于契约契约优先于活动活动优先于默认体验。实际操作中是先跑P0的强制校验再按P1的协议值锁定关键字段最后才允许P2的活动逻辑在锁定的空间里做增量优惠。还拿刚才那个例子来说正确的顺序应该是先判断该客户是否为协议客户如果是则锁定协议价再判断该协议是否允许叠加活动优惠如果允许则在协议价基础上叠加如果不允许促销引擎直接不参与该客户的计算。4.3 仲裁之后还要做的两件事定了优先级不是终点还有两件事必须跟上。第一件事是留痕。规则仲裁的每一次命中都要记录下走了哪条分支、命中了哪条规则、为什么这个分支优先。这在B端和G端尤为重要因为将来任何时候客户或审计方都可以要求你解释一笔异常金额是怎么算出来的。没有留痕的规则仲裁等于没仲裁。第二件事是通知面。被“降级”的那条规则要有对应的感知路径。比如协议客户的订单没有享受大促满减如果客户不问、运营不解释那没问题但如果客户问起来系统要能给出解释依据。C端往往不需要这么较真但在B端这就是履约能力的一部分。5. 数据科学视角下的规则工程这个系列既然被归到了“信息科学与工程学”和“数据科学”的门类下就必须要讨论一个问题产品规则如何被当成一种数据对象来管理而不是躺在产品文档里的文字描述。5.1 把规则当成“可观测的数据对象”很多人对规则的认知是“代码里的if else”或者是“后台配置项”。这两种认知都太窄了。如果规则真的是系统的核心资产那么它就应该像用户表、订单表一样可以被查询、被分析、被监控。我建议的规则工程化做法是每一条规则都有一个全局唯一编号、生效时间区间、适用人群标签、版本号、命中条件、动作结果以及最后修改人。把它作为一张关系表来维护——这就是把规则“数据化”的第一步。举个实际的例子。一个库存扣减规则在数据层面可以表达为字段名示例值说明rule_idRULE_2024_0018规则全局唯一编号rule_type库存预占规则类型分为校验类、计算类、分支类scene_codeORDER_CREATE_PRESALE适用场景编码对应下单预占priorityP1仲裁优先级conditionsku_status ON_SALE AND stock 1命中条件由业务与工程共同确定actionstock stock - 1命中后执行的动作ext_json{source:合同附件3.2条}规则出处与备注这种结构化的好处在于当规则出了问题时你不是去翻代码、翻文档而是直接查这张表看它的来源、版本和变更记录。5.2 规则质量的四个核心指标规则既然是数据对象就必须有质量指标。我常用的四个指标是命中率、误杀率、覆盖率、退化度。命中率在全部符合条件的事件里规则被正确触发的比例。比如风控规则命中率过低说明大量风险事件漏网了。误杀率在全部触发事件里被规则错误干预的比例。C端风控误杀率直接表现为“正常用户被限制”这对体验伤害非常大。覆盖率某类业务场景里有效规则覆盖的比例。比如100个SKU里有10个SKU没有库存规则那覆盖率就是90%剩下10个可能在极端情况下出问题。退化度规则生效的准确率随时间下降的趋势。业务在变用户行为在变规则会“变旧”。退化度就是量化这个变旧过程的指标。这四个指标要在规则上线前设定基线上线后周期性监控。C端规则可以小时级监控B端规则可以按周边期监控G端规则至少要按项目阶段监控。5.3 规则退化的三个信号最后说一下规则退化这件事因为我发现很多团队不会主动发现规则“变旧”一定要等出了事故才回头排查。第一个信号是命中率突变。某条规则的命中率在一段时间内明显上升或下降都要警惕。明显上升往往是条件写得过于宽泛把不该管的也管了明显下降则可能是业务已经绕过了这条规则。第二个信号是用户反馈侧重点变化。当客服或售后收到的提问集中在某几个“为什么不能这么操作”时这些提问背后大概率对应着几条已经不适配当前业务的规则。第三个信号是业务方“绕行”行为增多。运营或销售开始频繁申请“特批”“人工处理”时意味着现有规则和实际业务已经脱节了。这些特批短期看是救火长期看是规则的“影子系统”。如果不及时把特批沉淀回规则引擎影子系统会越来越大终有一天反噬主体。6. 规则演进节奏不同模式的“呼吸频率”前面讲了很多关于规则的静态维度最后要讲的是规则的动态维度规则多久变一次、怎么变、变错了怎么办。三种模式在这件事上的差异几乎和它们的业务差异一样大。6.1 B2C的高频试验节奏B2C的规则演进是“小时级”的。营销规则可以随时调整推荐规则可以按天更新模型风控规则则需要按实时流量反馈做分钟级微调。这意味着C端规则体系必须支持快速上线、快速回滚。我特别想强调“回滚”这件事。很多C端团队在做规则改动时只准备了上线方案没准备回滚预案。结果一旦新规则出问题就只能“修复式上线”用另一个新规则去补旧规则的漏洞而不是直接回到改动前的稳定态。正确的做法是任何C端规则变更都要有明确的回滚点也就是变更前一个基线版本的快照确保可以在5分钟内恢复到改动前。6.2 B2B的谨慎演进节奏B2B的规则演进要慢一个数量级周期以周、月甚至季度为单位。原因在于B端规则是契约的一部分任何改动都可能牵涉到客户沟通、补充协议甚至法务流程。我见过一个B2B系统调整了客户账单的展示规则本意是让账期信息更清晰结果几家客户的对账人员在同一周内分别来电质问“你们的账单格式变了是不是结算规则也变了”。往来沟通耗了两个星期最后还是按老格式兼容展示才平息。B端规则的演进本质上不是“优化”而是“变更管理”。每次改动前必须评估影响客户范围、是否需要提前告知客户、是否要提供并行期。B端客户对规则的预期是“稳定大于先进”这点和C端完全相反。6.3 B2G的低频重构节奏B2G的规则演进是最低频的因为规则的依据是公开文件与合同而这些文件的重招标、新立项周期通常以年为单位。G端系统的规则一旦上线往往要支撑整个合同周期的运行。这不是说G端系统就不改了而是每次改动都要走“变更申请—影响评估—审批—回归测试—上线留痕”的完整链路。任何规则字段的变化都要能追溯到对应的变更申请单。在G端做产品规则慢不是缺点是保护自己最有效的方式。6.4 演进节奏对比表演进维度B2CB2BB2G典型变更周期小时/天周/月/季度年/项目周期变更驱动因素数据反馈、竞争、营销节奏商务谈判、续约、新增服务招标文件、政策文件、审计发现回滚难度低支持分钟级回滚中需要客户同步高需要完整审计链变更首要原则快速试错稳定有序程序安全做产品规划时把“规则演进节奏”当成一个设计输入来考虑会让后续的架构选择清晰很多。比如在技术选型上C端适合配置化规则引擎加实时监控B端适合版本化管理加合同关联G端适合流程化管理加审计归档。7. 写给接下来五十一篇阅读路径与我的体悟这个系列接下来会按子系列逐个深入每篇都会落到一个具体的产品规则场景里把今天这篇建立的框架反复使用。如果你对B2C感兴趣可以重点看第07-18篇如果你主要做企业服务第19-32篇的内容会更贴近如果你做的是公共部门相关项目第33-44篇一定要逐篇看。第45-50篇会把数据科学的方法集中展开适合想往规则工程方向走的人。写这一篇的时候我自己的感受是做产品规则这么多年最大的体会是规则本质上是对商业不确定性的管理。B2C用规则管理用户行为的波动B2B用规则管理合作关系的边界B2G用规则管理公共事务的程序完整。规则不是产品文档里的装饰而是公司、客户、用户之间在风险分配上的隐形契约。理解了这一层再看任何一条规则你就不会只想“它合不合理”而是会问“它在为谁承担什么样的风险”这个问题的答案往往比规则本身更有意思。下一篇我们直接进方法论的第二篇聊一聊“规则的分层结构”为什么有的规则要放在业务层、有的要放在系统层、有的要放在数据层以及分层不当会带来什么样的灾难。到时候见。
先说个我自己的经历。早年我一直做C端产品后来有一次接手一个面向企业客户的交易类系统习惯了用“用户漏斗”和“次日留存”思考问题结果上线第一周就被客户方的采购负责人按着合同条款逐条质疑说我们的规则设计“不具备履约刚性”。那次之后我才意识到所谓B2C、B2B、B2G的产品规则根本不是同一件事——它们之间的差异大到足以决定一个功能模块从设计到上线全过程的走向。这也是我想开这个系列的原因。这个系列准备用五十二篇的篇幅把B2C、B2B、B2G三种业务形态下的产品规则做一个系统性的拆解。写这件事的底气不是我多厉害而是过去这些年确实在这些领域里摔过、补过、复盘过。这个系列的定位是给三类人看的一是正在从C端转向B端或G端的产品经理二是需要把业务规则落地成系统逻辑的数据工程师三是做售前或交付的解决方案同学——你们每天跟客户谈需求时那些被客户反复强调的“我们公司的规定”本质上都是产品规则在不同场景下的变形。这篇作为系列的第一篇先把地基打好为什么产品规则要按B2C/B2B/B2G拆开讲三者的差异到底体现在哪几个关键维度以及整个五十二篇的总体框架是什么。1. 为什么这个系列要从“模式分类”讲起很多人会觉得规则就是规则不管什么商业模式用户下单就要校验库存、企业采购就要走审批流、政府采购就要走招投标这有什么区别区别大了。区别不在于流程本身而在于规则被谁定义、为谁服务、以什么形式存在、错了要付出什么代价。1.1 一次跨模式转型的尴尬经历刚才提到我那次从C端转B端的经历值得详细说说。当时我做的那个项目本质上是一个给企业客户用的采购协同平台业务上需要支持多种结算方式还要跟客户自己的ERP系统做对账。我按C端的习惯把结算规则写得很“灵活”比如支持自动抹零、支持优惠券叠加、支持支付后修改收货信息等。结果客户方在验收测试时直接抛了个问题你们的规则在合同里对应哪一条我们约定的是“月结30天逾期按日万分之五计息”你的系统里怎么没有体现我一下子懵了。在C端规则是平台说了算用户只能接受在B端规则是双方在合同里写死的系统只是把合同条款翻译成可执行的逻辑。你说这能一样吗那次经历给我最大的教训是产品规则的第一性问题不是“怎么实现”而是“这些规则是从哪里来的、代表谁的意志、在什么约束条件下成立”。C端的规则像店铺门口的告示商家定、顾客看、不满意可以换一家B端的规则像双方法务审过的合同条款每一条都有编号、有责任人、有违约后果G端的规则更像法律法规的执行细则不仅要合规还要经得起审计和追溯。1.2 三种模式背后的“生意本质差异”再往下拆一层。B2C、B2B、B2G的本质差异要放到“生意”的语境里看。B2C的生意是高频、低客单、海量用户的零售逻辑。规则要解决的矛盾是“让用户体验顺畅”和“防止平台被薅羊毛”之间的平衡。所以C端规则必须轻、快、用户几乎感知不到。B2B的生意是低频、高客单、深度服务的合作逻辑。规则要解决的矛盾是“双方权利责任对等”和“流程效率可接受”之间的平衡。所以B端规则必须重、准、每一条都能追溯到合同或商务约定。B2G的生意是项目制、预算制、强程序逻辑的公共采购与服务逻辑。规则要解决的矛盾是“合规透明”和“按期交付”之间的平衡。所以G端规则必须全、稳、经得起任何一方的审计。这个差异不是某一个人拍脑袋定的而是由三种市场里“钱从哪来、决策怎么走、关系如何存续”决定的。B2C里用户用脚投票B2B里客户用合同投票B2G里一切依程序而行。产品规则不过是这些底层逻辑的表层投影。1.3 五十二篇的整体地图既然定了要写五十二篇这个系列自然需要一个结构。我把它拆成六个子系列每块大约八到十篇首尾再各留开篇与收篇。子系列覆盖篇数核心内容方法论篇01-06规则的本质、来源、结构、退化、演进与治理B2C规则篇07-18用户侧规则、交易规则、风控规则、营销规则、个性化规则B2B规则篇19-32合同规则、SLA规则、结算规则、权限规则、组织与审批规则B2G规则篇33-44招投标规则、预算与支付规则、交付验收规则、合规留痕规则数据科学视野45-50规则数据化、规则挖掘、规则仿真、规则评估与A/B测试专题与案例篇51-52跨模式融合案例与全年精华复盘在这个框架里每一篇都会避开“教科书式”的讲法尽量用我在具体项目里遇到的真实冲突和取舍来讲。今天这篇是方法论的起点后面每一篇都会引用这里建立的概念框架。2. B2C、B2B、B2G的硬差异到底在哪一线对比这一节要做的是一件很朴素的事把三种模式摊开来逐项比。很多人对B2C/B2B/B2G的差异停留在“客户不同”这个层面但落到产品规则的颗粒度差异被我分成四个维度客户与决策链、生命周期、价值度量、规则属性。2.1 客户、份额与决策链的差异B2C的客户是个人决策链基本等于一个人。哪怕家里要买个大件商品最多也就是两口子商量一下决策周期以小时到天计。这意味着C端规则可以走“默认最优快速纠错”的路线因为任何一个用户的反悔成本都很低。B2B的客户是一个组织决策链由使用者、采购者、决策者、法务、财务甚至高层共同构成。我见过最夸张的案例是一个几百人的企业客户买一套报销系统光内部评审就跑了两轮涉及六个部门签字周期拖了小半年。B端规则要服务的是这条链子上所有人的诉求使用者要体验、采购者要比价、财务要合规、法务要免责、高层要战略价值。B2G的客户本身就是“程序”的产物决策链藏在公开的采购流程里。产品规则设计的核心不是让哪个人满意而是让整套程序走得通资格预审、招标文件、评标标准、合同签订、验收交付每一环都有明确的规则要求几乎没有留给产品经理自由发挥的空间。2.2 规则属性的差异隐性 vs 契约化 vs 刚性这是我特别喜欢讲的一个维度。B2C的规则大部分是隐性规则。平台设置了风控规则但不会告诉用户“你的账号因为异地登录被拦截了”平台设置了价格规则但不会把价格计算公式公示出来。C端用户感知到的是“规则的结果”很少看到“规则本身”。B2B的规则是契约化规则。客户跟你签约时附件里往往有一份几十页的服务条款里面的SLA、结算周期、数据归属、违约责任全部要落到系统里。B端规则不存在“藏着掖着”的可能任何一个字段的变化都可能在审计时被要求提供依据。B2G的规则是刚性规则。政府采购的评标办法、预算定额、支付条件全都有公开的文件依据。系统里如果某个字段校验规则与招标文件不一致那就不只是系统Bug的问题而是会被质疑为“违规操作”。G端的规则不是用来“优化用户体验”的是用来“证明我们按规矩办了事”的。2.3 一张表看懂三种模式的产品规则重心把上面这些铺开需要一张能放进收藏夹的对照表。对比维度B2CB2BB2G客户主体个人组织公共部门决策链长度1-2人5-20人程序化流程采购频率高频低频低频项目制客户生命周期短依留存而定中以合同周期计长以项目与框架计价值度量转化率、客单价、留存合同金额、续约率、毛利率项目回款、合规率、复投率规则存在形式隐性、动态可调显性、契约绑定刚性、程序绑定违约代价用户流失赔偿、诉讼、商誉损失处罚、失去准入资格规则变更频率极高中低系统侧典型形态推荐、风控、营销CRM、ERP、合同、BPM政务平台、采购系统、审计系统这张表不是绝对的比如部分高频B2B服务如云服务充值就更接近C端形态但不影响它作为判断框架。当你拿到一个项目先拿这张表对照一下大概率能快速判断这个产品里什么样的规则才是主角。3. 产品规则到底从哪里来四大来源与拆解讲完了三种模式的差异接下来就要回答一个更根本的问题产品规则凭什么这么定很多产品经理都有一个误解以为规则是产品经理“设计”出来的。其实不是产品经理更多的是“翻译”和“取舍”把来自不同方向的约束转译成系统逻辑。我把产品规则的来源归纳为四类。3.1 组织基因规则自带“出身”第一个来源是组织基因也就是这家公司自己长期形成的打法。比如一家起家于电商的公司它做任何交易类系统时都会天然把“用户体验优先”写进规则里而一家起家于企业软件的公司做同样功能时第一位考虑的一定是“权限清晰、留痕完整”。这在跨模式做产品时特别容易踩坑。我见过一个团队公司是做B2B起家的后来想做一款面向个人用户的企业服务工具硬是把企业端的审批流塞给个人用户结果用户流失率极高。根子就在于团队的产品基因还停留在“B端规则是契约的一部分”这个认知里没有切换成“C端规则是体验的一部分”。所以拿到一个项目先去问这个团队的基因在哪公司过去最擅长的那套规则逻辑是什么这个逻辑到了新的业务模式里哪些该保留、哪些必须推翻3.2 客户契约B端和G端的规则之源第二个来源是客户契约这是B端和G端产品与C端最显著的分水岭。B端的合同、SLA、SOWG端的招标文件、框架协议、实施合同里面所有的条款都直接决定了系统的规则字典。我一个做企业服务的朋友给一家外资客户做项目排期系统客户方的法务要求所有系统的时钟必须统一使用UTC时间而不是本地时区理由是为了跨区域审计的一致性和证据链的完整性。这种规则看起来“不讲道理”但它是写在合同附件里的系统就必须遵守。契约里给了一条规则的依据系统里就要有呈现该依据的字段这就是B端规则的设计常态。做B端或G端产品第一步检索的不是用户画像而是合同与法规。把“付款条件”“交付标准”“验收流程”“违约条款”全部列出来再看系统需要哪些规则来承接。3.3 历史补偿规则的“补丁”逻辑第三个来源是历史补偿它解释了为什么很多系统的规则看起来“又多又怪”。每一条怪规则背后大概率都有一段被钻空子的血泪史。举一个最常见的例子很多电商或交易平台在早年支持“下单后修改收货地址”后来有人利用改地址功能刷单或诈骗平台就加了一条规则“订单支付后24小时内可修改一次超过时限或部分商品不支持修改”。这条规则不是凭空设计的而是对历史漏洞的补偿。新同学看到这种规则时最忌讳的是“帮用户吐槽”或试图“简化规则”。在动任何看似不合理的规则之前先去查一下它的历史背景它是谁在什么时候加的当时出了什么问题如果把这个规则删掉当年的那个漏洞还会不会再次被打开3.4 法规映射合规不是规则本身而是规则的前提第四个来源是法规映射。这里说的不只是“公司要遵守法律”这种大而化之的东西而是具体的法律条文如何映射成系统里的字段校验、流程分支和权限控制。比如各类交易系统里的发票规则为什么同一个商品有时能开专票有时只能开普票为什么个人用户和企业用户的税率字段不同这些都不是产品经理的偏好问题而是税务规则在系统里的落地。再比如消费者权益保护相关的规则为什么七天无理由退货在C端是“默认开启”而在B端设备采购里却是“商务谈判决定”背后就是监管逻辑对不同交易场景的差异化要求。做产品规则的人必须建立一种“规则解释”的习惯每一条规则都要能回答“它对应的是什么依据”这个依据可能是内部制度、客户契约、历史教训或外部法律。如果你发现一条规则什么都对不上那它要么是废规则要么是你还没找到它的出处。4. 规则冲突时怎么办仲裁优先级真实世界里规则之间是会发生冲突的。一个典型的场景客户在双十一大促期间下单平台的价格规则说“满减可叠加”但企业的协议价规则说“该客户不参与大促满减”两边一碰撞到底按哪个走这种问题不解决系统就会表现出“时灵时不灵”的规则飘忽感。要解决就得给规则建一套仲裁优先级。4.1 一个真实的冲突案例我之前参与过一个混合型平台既有面向个人的零售业务又开放了面向企业客户的采购通道。有一天运营报了一个Bug某个企业客户在平台上采购了一批商品结算时系统按C端促销规则自动套用了“跨店满减”导致结算金额比合同协议价还低财务那边直接炸了。排查下来根因是系统的促销引擎和协议价引擎是两套独立服务促销引擎先计算了C端优惠协议价引擎后覆盖时发现金额已经不匹配于是选择了“不再调整”。两条规则都执行了但执行顺序错了形成了事实上的“规则冲突”。这个案例说明了一个很朴素的道理在混合业务模式里规则的冲突不是“有没有”的问题而是“何时发生、怎么裁决”的问题。4.2 规则优先级仲裁的基本设计我后来在实践中总结了一套相对稳妥的仲裁层级不一定适用于所有场景但可以作为初始设计优先级规则层级说明P0平台底线规则法律合规、资金安全、账户安全、人身安全相关P1契约规则合同约定、协议价格、SLA、结算条件等白纸黑字的条款P2活动规则促销、优惠、积分、补贴等活动类规则P3默认规则平台默认的展示、排序、推荐等体验类规则这个逻辑的顺序是合规底线优先于契约契约优先于活动活动优先于默认体验。实际操作中是先跑P0的强制校验再按P1的协议值锁定关键字段最后才允许P2的活动逻辑在锁定的空间里做增量优惠。还拿刚才那个例子来说正确的顺序应该是先判断该客户是否为协议客户如果是则锁定协议价再判断该协议是否允许叠加活动优惠如果允许则在协议价基础上叠加如果不允许促销引擎直接不参与该客户的计算。4.3 仲裁之后还要做的两件事定了优先级不是终点还有两件事必须跟上。第一件事是留痕。规则仲裁的每一次命中都要记录下走了哪条分支、命中了哪条规则、为什么这个分支优先。这在B端和G端尤为重要因为将来任何时候客户或审计方都可以要求你解释一笔异常金额是怎么算出来的。没有留痕的规则仲裁等于没仲裁。第二件事是通知面。被“降级”的那条规则要有对应的感知路径。比如协议客户的订单没有享受大促满减如果客户不问、运营不解释那没问题但如果客户问起来系统要能给出解释依据。C端往往不需要这么较真但在B端这就是履约能力的一部分。5. 数据科学视角下的规则工程这个系列既然被归到了“信息科学与工程学”和“数据科学”的门类下就必须要讨论一个问题产品规则如何被当成一种数据对象来管理而不是躺在产品文档里的文字描述。5.1 把规则当成“可观测的数据对象”很多人对规则的认知是“代码里的if else”或者是“后台配置项”。这两种认知都太窄了。如果规则真的是系统的核心资产那么它就应该像用户表、订单表一样可以被查询、被分析、被监控。我建议的规则工程化做法是每一条规则都有一个全局唯一编号、生效时间区间、适用人群标签、版本号、命中条件、动作结果以及最后修改人。把它作为一张关系表来维护——这就是把规则“数据化”的第一步。举个实际的例子。一个库存扣减规则在数据层面可以表达为字段名示例值说明rule_idRULE_2024_0018规则全局唯一编号rule_type库存预占规则类型分为校验类、计算类、分支类scene_codeORDER_CREATE_PRESALE适用场景编码对应下单预占priorityP1仲裁优先级conditionsku_status ON_SALE AND stock 1命中条件由业务与工程共同确定actionstock stock - 1命中后执行的动作ext_json{source:合同附件3.2条}规则出处与备注这种结构化的好处在于当规则出了问题时你不是去翻代码、翻文档而是直接查这张表看它的来源、版本和变更记录。5.2 规则质量的四个核心指标规则既然是数据对象就必须有质量指标。我常用的四个指标是命中率、误杀率、覆盖率、退化度。命中率在全部符合条件的事件里规则被正确触发的比例。比如风控规则命中率过低说明大量风险事件漏网了。误杀率在全部触发事件里被规则错误干预的比例。C端风控误杀率直接表现为“正常用户被限制”这对体验伤害非常大。覆盖率某类业务场景里有效规则覆盖的比例。比如100个SKU里有10个SKU没有库存规则那覆盖率就是90%剩下10个可能在极端情况下出问题。退化度规则生效的准确率随时间下降的趋势。业务在变用户行为在变规则会“变旧”。退化度就是量化这个变旧过程的指标。这四个指标要在规则上线前设定基线上线后周期性监控。C端规则可以小时级监控B端规则可以按周边期监控G端规则至少要按项目阶段监控。5.3 规则退化的三个信号最后说一下规则退化这件事因为我发现很多团队不会主动发现规则“变旧”一定要等出了事故才回头排查。第一个信号是命中率突变。某条规则的命中率在一段时间内明显上升或下降都要警惕。明显上升往往是条件写得过于宽泛把不该管的也管了明显下降则可能是业务已经绕过了这条规则。第二个信号是用户反馈侧重点变化。当客服或售后收到的提问集中在某几个“为什么不能这么操作”时这些提问背后大概率对应着几条已经不适配当前业务的规则。第三个信号是业务方“绕行”行为增多。运营或销售开始频繁申请“特批”“人工处理”时意味着现有规则和实际业务已经脱节了。这些特批短期看是救火长期看是规则的“影子系统”。如果不及时把特批沉淀回规则引擎影子系统会越来越大终有一天反噬主体。6. 规则演进节奏不同模式的“呼吸频率”前面讲了很多关于规则的静态维度最后要讲的是规则的动态维度规则多久变一次、怎么变、变错了怎么办。三种模式在这件事上的差异几乎和它们的业务差异一样大。6.1 B2C的高频试验节奏B2C的规则演进是“小时级”的。营销规则可以随时调整推荐规则可以按天更新模型风控规则则需要按实时流量反馈做分钟级微调。这意味着C端规则体系必须支持快速上线、快速回滚。我特别想强调“回滚”这件事。很多C端团队在做规则改动时只准备了上线方案没准备回滚预案。结果一旦新规则出问题就只能“修复式上线”用另一个新规则去补旧规则的漏洞而不是直接回到改动前的稳定态。正确的做法是任何C端规则变更都要有明确的回滚点也就是变更前一个基线版本的快照确保可以在5分钟内恢复到改动前。6.2 B2B的谨慎演进节奏B2B的规则演进要慢一个数量级周期以周、月甚至季度为单位。原因在于B端规则是契约的一部分任何改动都可能牵涉到客户沟通、补充协议甚至法务流程。我见过一个B2B系统调整了客户账单的展示规则本意是让账期信息更清晰结果几家客户的对账人员在同一周内分别来电质问“你们的账单格式变了是不是结算规则也变了”。往来沟通耗了两个星期最后还是按老格式兼容展示才平息。B端规则的演进本质上不是“优化”而是“变更管理”。每次改动前必须评估影响客户范围、是否需要提前告知客户、是否要提供并行期。B端客户对规则的预期是“稳定大于先进”这点和C端完全相反。6.3 B2G的低频重构节奏B2G的规则演进是最低频的因为规则的依据是公开文件与合同而这些文件的重招标、新立项周期通常以年为单位。G端系统的规则一旦上线往往要支撑整个合同周期的运行。这不是说G端系统就不改了而是每次改动都要走“变更申请—影响评估—审批—回归测试—上线留痕”的完整链路。任何规则字段的变化都要能追溯到对应的变更申请单。在G端做产品规则慢不是缺点是保护自己最有效的方式。6.4 演进节奏对比表演进维度B2CB2BB2G典型变更周期小时/天周/月/季度年/项目周期变更驱动因素数据反馈、竞争、营销节奏商务谈判、续约、新增服务招标文件、政策文件、审计发现回滚难度低支持分钟级回滚中需要客户同步高需要完整审计链变更首要原则快速试错稳定有序程序安全做产品规划时把“规则演进节奏”当成一个设计输入来考虑会让后续的架构选择清晰很多。比如在技术选型上C端适合配置化规则引擎加实时监控B端适合版本化管理加合同关联G端适合流程化管理加审计归档。7. 写给接下来五十一篇阅读路径与我的体悟这个系列接下来会按子系列逐个深入每篇都会落到一个具体的产品规则场景里把今天这篇建立的框架反复使用。如果你对B2C感兴趣可以重点看第07-18篇如果你主要做企业服务第19-32篇的内容会更贴近如果你做的是公共部门相关项目第33-44篇一定要逐篇看。第45-50篇会把数据科学的方法集中展开适合想往规则工程方向走的人。写这一篇的时候我自己的感受是做产品规则这么多年最大的体会是规则本质上是对商业不确定性的管理。B2C用规则管理用户行为的波动B2B用规则管理合作关系的边界B2G用规则管理公共事务的程序完整。规则不是产品文档里的装饰而是公司、客户、用户之间在风险分配上的隐形契约。理解了这一层再看任何一条规则你就不会只想“它合不合理”而是会问“它在为谁承担什么样的风险”这个问题的答案往往比规则本身更有意思。下一篇我们直接进方法论的第二篇聊一聊“规则的分层结构”为什么有的规则要放在业务层、有的要放在系统层、有的要放在数据层以及分层不当会带来什么样的灾难。到时候见。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
