行业系统做成白牌，先看领域模型能不能复用

一个团队做了三年的建材供应链系统，第二个客户是农资经销商。团队觉得两边都是多商户、库存、订单、结算，换个名字就能卖。

第一个月就卡住了。农资按吨卖，按批次管效期，按赊销结算；订单不是下单付款，而是业务员抄单、店长审核、仓库出库、月底对账。建材那套“下单锁库、支付发货”的模型，一个环节都对不上。

两边真正的差距在模型，跟行业没关系：名词随便换，关系的改造成本集中在账务层。

界面之下，才是白牌的成本

换 logo、换主题色、换菜单名，两天能做完——前提是主题和菜单走租户配置，不是改模板文件。客户看着像自己的系统，销售也能拿着截图去谈下一家。

然后第二个客户提需求：我们的结算不是按订单，是按合同分期；我们的库存不是按 SKU，是按批次和效期；我们的权限不是部门，是片区和经销商等级。每一条都指向同一件事——模型要改。

改模型不是加字段。一个字段背后是查询、报表、权限、对账、历史数据。加一个“批次号”容易，让库存、结算、退货都认这个批次，是把半套系统重写。重写量可以数出来：库存表从 (sku_id, warehouse_id, qty) 变成 (sku_id, warehouse_id, batch_no, produce_date, expire_date, qty)，唯一键跟着变；出库明细、退货明细加 batch_no；扣减从按 SKU 汇总改成按批次先到期先出、加行锁；对账报表按批次重算。四行改动，每行都是一遍回归，医疗器械要的追溯链就落在这四行上——召回按出库明细的 batch_no 反查单据链。

还有一个更隐蔽的成本：数据迁移。第一个客户的脏数据、历史单据、旧编码，第二个客户不会有相同的形状；迁移脚本每单都要重写，这部分工作量经常被算进“实施”，最后把利润吃光。报价时把迁移单独列一项，客户才知道这笔钱花在哪。

所以判断白牌能不能做，先别看界面。看第二个客户的需求里，有多少是配置能解决的，多少是要动表的。数法是一次需求打标：逐条标成“配置 / 适配器 / 改模型”，改模型指动主键、唯一键、状态机取值集、账务实体这四样；改模型的条目超过三成，这一单还是定制。

领域模型先看关系

实体名字不一样，不一定是问题。建材的“销售单”和农资的“赊销单”，都能映射成订单；客户、商品、仓库，也都能找到对应。真正难的是关系：谁欠谁的钱、货权什么时候转移、退货冲减哪一笔。我服务的那家建材客户是先款后货，钱到账才出库；农资客户是赊销，出库时记应收，月底对账，年底清账。同样是“订单-出库”，一个产生收款单，一个产生应收账。账务模型不同，结算报表就完全不同。

落点是最小两张表——receivable(order_id, customer_id, amount, settled_amount, status) 加 settle_record(receivable_id, source_type, source_id, amount)，先款后货是出库前校验收款单，赊销是出库确认生成应收，退货冲减挂红字应收指向原单。

状态机也一样。电商订单是待付款、待发货、已发货、已签收、已完成；批发订单是草稿、待审核、已审核、部分出库、已出库、待对账、已对账——两边都只列了主链，取消、驳回、部分退款这些分支才是跨行业对不上的地方。后者的“已审核”不是支付状态，“已出库”也不等于交易完成。硬把批发的单塞进电商状态机，业务只能靠备注栏沟通；能落地的拆法是状态分域，pay_status、fulfill_status、settle_status 三列各走各的，对外展示状态由三者推导，迁移映射写死校验，不开放给客户配置。

医疗器械更典型。同一个“商品”，医院看注册证和效期，经销商看批次和冷链；一件货从入库到用在病人身上，中间要能追溯到批号。把这类商品塞进普通 SKU 模型，字段能加，追溯链加不了。

这张表不用填得很细。任意一行落在右边就要打问号，两行及以上直接按定制报，别做白牌。换名词，换不掉模型。

流程复用，数节点不数页面

页面是最便宜的一层。同样的审批页，改个标题、换几个字段，一天能出三版。流程不是。

一个客户的采购审批是五步：申请人、部门经理、采购总监、财务、总经理。另一个客户是十二步，中间还有片区、集团、风控、法务。页面上看都是“审批”，背后是节点、角色、条件、超时、转办、加签六样。每加一个节点都要改代码，这套流程就没有复用。

比较现实的做法，是把六样装进一张节点表：flow_node(flow_key, node_order, node_type, handler_role, timeout_hours, timeout_action, allow_transfer, allow_countersign) 加一张 flow_condition(node_id, expr)——节点决定走到哪，角色决定谁能批，超时、转办、加签都是节点上的字段，加签就是条件命中时插入的临时节点。做到这一步，五步和十二步的差别是配置，不是分支代码。注意这里配的是审批流，不是单据状态机：状态机的语义固定、迁移校验写死，能配置的只有审批流，两件事别混。

赊销额度是个好例子。建材客户可能不需要额度，农资客户必须有：每个经销商一个额度，超限要审批，逾期要冻结。这个能力如果写在订单服务里，第二个行业就用不上；抽出来做成额度模块，订单只调用“是否允许赊销”，换行业时换的是规则，不是订单。额度模型最容易错的是占用时点和并发：credit(customer_id, total_amount, used_amount, frozen_amount, version)，出库确认时占用、冲减时释放，单体里做成出库同一事务内的模块，超限判断带行锁。

流程配置也有边界。完全自由的流程引擎，最后会变成客户自己画流程图，实施顾问变成流程顾问，交付更重。配置项要收敛到业务真正会变的那几处，其余写死。这个取舍没有标准答案，但有一条：客户一年改不到一次的流程，不值得做成配置——接单前直接问，过去一年这套流程改过几次、谁提的。

组织模型也常被忽略。建材客户按分公司分权，农资客户按片区加经销商等级分权；同样是“部门”，一个挂在公司下，一个挂在片区下。组织树如果写死三级，第二个客户就得改表。落点是 dept(id, parent_id, path, type)，数据权限用 path 前缀或闭包表过滤，用户权限绑 org_id 不绑层级号；经销商等级做成独立的 grade 字段，不塞进组织树。

接口复用，看外部系统是不是同一批

行业系统很少孤立运行。支付、电子面单、税控、银行代发、地磅、考勤机、客户原来的 ERP，每一个都要对接。白牌能不能复制，很大程度取决于这些外部系统是不是同一批。同一个行业里，供应商往往集中。建材商城的支付和电子面单，换个客户还是那几家；农资可能要接农药追溯平台，劳务要接银行代发和人社系统。跨行业时，外部系统换一批，适配器就要重写。

适配器要放在防腐层里。订单服务不直接调快递公司，而是调“发货接口”；支付服务不直接拼银行报文，而是调“收款接口”。换供应商时，改的是适配器，不是业务代码。这个道理不新，但很多定制项目为了赶工期，把第三方 SDK 直接塞进 Service，第二个客户一来就傻眼。私有化部署会把这个问题放大。客户的内网版本、数据库版本、浏览器版本都不一样，外部系统的接口也可能更老。接口要有契约测试，按对接类型分组覆盖：支付收银类是登录、下单、回调、退款、对账，物流类是面单、轨迹、取消，设备类是读数、心跳、断线重传——别拿一套动作打天下。没有契约测试，换一个客户环境就要人肉回归一遍。

接口清单要跟着白牌一起交付。客户最常问的不是功能，是“能不能对接我们现在的 ERP、税控、地磅”。清单上写清楚支持哪些版本、对接要几天、谁出接口文档，比产品介绍有用。

对接清单上最好再写清楚失败模式：对方系统超时怎么办、回调丢了谁补、对账口径按谁的，这些问题在实施时没人问，上线后每个都会变成工单。

合规复用，许可证跟客户走

有些行业的门槛不在代码，在证。劳务派遣要劳务派遣经营许可证，职业中介要人力资源服务许可证，支付业务要牌照，医疗器械要经营备案或许可，食品要食品经营许可证。系统能帮客户管证照、记有效期，但不能替客户持证。白牌卖的是软件，不是资质。

合同里要写清楚：业务资质由客户提供，平台不承担用工、医疗、金融责任，客户超范围经营时的追偿条款也要有；同时保留功能开关和暂停服务的合同权利，交付时让客户出一份资质承诺函留档。也要清楚条款的边界：它只在你们两家之间有效，对受害的第三方和行政处罚无效。这句话不写，出事时第一个找的是软件供应商；写了，也不是挡箭牌，具体写法让执业律师过一遍。

数据合规也要按行业看。招工系统要存身份证、银行卡、人脸，教育系统要存未成年人信息，医疗系统要存病历，留存期限和授权方式都不一样。同一套字段表卖到不同行业，轻则不合规，重则不能用。比较稳的做法，是把敏感字段做成行业包：招工包、医疗包、教育包，各自带字段定义、加密方式、留存策略、授权文案。

留存期限也不要统一设。招工的身份信息、医疗的病历、教育的未成年人信息，规定各不相同；系统要能按行业包配置留存期和到期处理方式，别写死一个三年。到期处理枚举成提醒、归档、匿名化、删除四种，法定留存期内禁止物理删除——误删是恢复不回来的事故。证照这件事同理：许可证不跟着代码走，系统交付到哪，证都在客户自己手里。

什么时候值得做白牌

第一单做完就抽白牌，通常抽不出来。你只有一个样本，不知道哪些是行业共性、哪些是客户怪癖。把怪癖做成产品，第二个客户就会替你纠偏，代价是一整轮返工。比较稳的节奏是接三到五单，再用打标法看重复度。同样的问题被第三个客户提起，才值得做成配置；同样的报表被第四个客户要，才值得做成模板。配置可解的条目占比到六成以上，白牌才有意义；低于这个数，做的是复用型定制，别对外说是产品。这条要和「改模型条目超过三成就是定制」一起用，冲突时按定制算：六成五配置、三成半改模型的单子，配置占比过了线，改模型那条照样把它打成定制。

比 logo 更重要的，是交付包。安装脚本、初始化数据、升级步骤、回滚方案、运维手册，这些东西决定第二单要不要再派一个人驻场两个月。白牌卖的是可复制的交付，不是一份源码。

报价也要拆开：软件授权、实施服务、年度维护，三笔钱分开报。白牌价只覆盖授权和标准实施，定制、接口、驻场另算。混在一起报，客户会把定制当成产品的一部分，下一单更难谈。对同行买家那一半，合同要另写一节，一条都不能省：交付物形态（源码还是部署包）、能否改包名、能否二次转售（转售另签授权）、定制部分的知识产权归属、版本升级义务怎么计费、缺陷响应责任和时限。这六条写清楚，白牌才是生意；写不清楚，买家用你的系统接了单，回头还是你的售后。白牌的定价逻辑在这里：它卖的是低成本交付，跟低价是两回事。

判断方法其实很土：把第二个客户的需求逐条标上“配置、适配器、改模型”。改模型的条目超过三成，就别按白牌报价。判别表最好拿真实的一对行业填一遍——建材到农资：实体能一一映射，落左边；先款后货对赊销，落右边；主链能映射、缺对账节点，落右边；记账时点不同，落右边。四行里三行在右边，结论就是按定制评估，和打标的结果互相印证。按定制报，客户认就做，不认就放。放过一单不丢人，用白牌价接一单定制，后面每一单都会被这个价格锚住。

第二个客户不会替你验证白牌

白牌最危险的时刻在第二单报价。销售拿着第一单的截图，报了一个产品价；实施一看需求，发现要改三分之一；老板觉得已经投入了，硬着头皮接。最后这单不赚钱，团队还多了一个“产品化”的包袱。

白牌是交付成本降下来的结果。模型稳了、流程能配了、接口有防腐层了、合规能分行业打包了，白牌才成立。顺序反过来，先做官网、先做品牌、先招渠道，最后还是要回到代码里补那四层。

系列：上一篇 蓝领招工难在实名和日结 ｜ 下一篇 为什么国内 B 端买家要源码买断，而不是 SaaS 订阅 ｜ 相关 一个人做行业软件，先接单再做产品