> 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-hant/2025/w22-differences-between-c-side-and-b-side.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）之間的差異。