> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/zh/2025-nian/w22c-yubde-cha-yi.md).

# W22-C与B的差异

引入 C 端的视角来理解和总结 B 端的特殊性，这是后续要持续做一件事情。通过穷举不同的切面进行抽象，帮助 B 端更好地被认知和理解，并在合适的时机做出更有利于长期发展的技术决策。

从经营的本质复杂度来看，上周田老板的一句话很贴切：“C 端的刀是支付，B 端的刀是结算。”两者最终都目标是一样的——将流量活跃转化为账户活跃。只是路径不同：C 端的起点是收单活跃，而 B 端的起点是结算活跃。在“账”“余额”“卡”等关键心智上，B 端要比 C 端更强，这也构成了“生意账本”“统一余额”“生意卡”等产品形态的基础。

在角色分类方面，B 端的复杂度超过 C 端。即使不引入用户分层，仅就角色本身而言，已经涵盖了 KA、SMB，经营者、从业者，商户、履约者，品牌商、服务商、供应商等多个维度。一个账号的实际操作人，可能是老板，也可能只是店里的收银员。因此许多 B 端产品在 C 端找不到对应形态，也因此更难理解，比如面向骑手的服务费代发、面向服务商的分账等。

供给端面临极强的经营合规要求，而且这些要求还在持续抬杆。在 C 端几乎无需考虑“消费合规”，甚至没有这个概念。而 B 端所谓“经营合规”则是一个多面复杂的体系，涉及多个监管主体，对应也有诸如资质合规、支付账户合规、税务合规等不同维度。虽然 C 端也存在与支付账户合规、反洗钱相关的案例，但这并不构成日常工作的主线。毕竟，大多数诈骗或洗钱行为的最终目的，都是通过结算链路把资金提出去，真正有效的反制举措，还是在这条链路上做功。

在业务范围与服务组成上，C 端与 B 端也存在不小差异。我认为这种差异更多是由组织架构带来的人为复杂度。比如目前 B 端划分的“基础服务”和“钱包”两个产品团队，钱包团队的职责早已超出了“钱包首页流量”所涉及的内容，基础服务中也存在许多 C 端无法对应的产品能力。

在前端层面最有价值也最具挑战性的工作，集中在容器和基建。远景方案是构建一个统一的业务接入 SDK，所有服务运行在标准的动态化增强容器 EHC 中。EHC 提供多种增强能力，并抹平不同引擎（如 KNB、Recce）之间的差异。