为什么必须是“平台逻辑”？
核心前提：平台逻辑的重申
运力池归属平台： 所有服务/配送人员属于平台，不是某个商户的专属员工。
算力由平台调配： 平台根据LBS（地理位置）、负载情况、商户等级（付费情况）进行智能派单或广播抢单。
结算由平台兜底： 资金流经过平台，平台抽成后结算给服务人员，平台承担信用背书。
- 成本最优： 平台统一调度，可以让一个服务人员同时承接A商户的维修单和B商户的配送单，路线规划最优，避免空跑。
- 标准统一： 不管是哪家商户的服务人员，都必须遵循平台制定的节点上传标准和服务规范，维护的是整个平台的声誉，而非单店声誉。
- 数据闭环： 所有的照片/视频数据归平台所有，可以用于AI识别服务质量（如垃圾是否清理）、信用背书（处理客诉）、以及二次营销（社区种草）。
这个设计方案的核心在于，把“服务人员”和“配送人员”当作平台的资源，通过技术手段（强制节点、多媒体视频/图片上传）进行标准化管理，再通过平台流量（社区同步、次卡）反哺给商户和人员。
对于多商户或多门店商城 的服务人员 和配送人员要解决的问题。最主重要的是，它的逻辑应该是平台逻辑，不像单PRO商城 因为它的算力和运力应该是平台来调配，而不是单个用户（商户）单独调用，单PRO商城是可以的。这是重中之中。
1、就是服务人员 和配送人员 要有平台服务/抢单大厅.
2、必须要是服务或配送的过程 过程要上传照片或视频并配文字 而服务的节点要自定义文字，并且要有服务进度条。进度条下面有上传照片或视频。（这些节点的照片或视频要可以同步到社区）
SOP（标准作业程序）节点自定义引擎
- 逻辑： 不同商户（家政、维修、配送）服务流程不同。平台应提供后台配置功能，让平台运营（或付费商户）自定义该品类的服务节点（文字全部可以自定义适应该不同行业 如：已接单 ->开始服务-> 已上门 -> 服务中->维修中 -> 需加料 -> 完成服务）。
3、服务+次数（次卡）+商品（是否邮寄,快递，配送等信息）=服务完整化交付。这个要考虑。
一个平台就要有平台的像子，而不是和单PRo一样。这样没法落地！
