城市合伙人体系 · 资金分账合规 · AI 私有化 · 大V 获客引擎

00结论先行

你这轮提的六件事，有两件按目前设想直接落地会触犯监管，一件在商业上自相矛盾。 好消息是：三件都能通过重新设计规避，且改动不大。先把这三件事说清楚。

0.1 一个必须先说的交叉点（本轮最重要的发现）

0.2 六件事的处理结论

01⚠️ 两条监管红线

1.1 红线一：资金二清

什么是二清

# 央行银办发〔2017〕217 号文界定（多来源引述一致）
无支付牌照平台，用户付款资金先进入平台对公账户，
平台扣除佣金后再手动/自动转账给入驻商家，
私自沉淀资金、建立资金池、自主清算
→ 属于无证经营支付结算业务，即「二清」（二次清算）

# 后果
没收违法所得 · 罚款 10 万–100 万 · 支付通道关停 · 平台下架
金额较大 → 涉嫌非法经营罪（刑事）

微信支付如何识别与处罚

合规路径（三条）

1.2 红线二：商业特许经营（俗称「加盟连锁」）

什么情况会构成特许经营

# 《商业特许经营管理条例》第三条
拥有注册商标、企业标志、专利、专有技术等经营资源的企业（特许人），
以合同形式将其拥有的经营资源许可其他经营者使用，
被特许人按照合同约定在统一的经营模式下开展经营，
并向特许人支付特许经营费用的经营活动。

# 法定义务（缺一不可）
1. 特许人必须是企业（个人、个体工商户不得开展）
2. 「两店一年」：至少 2 个直营店，且经营超过 1 年
3. 首次订立合同起 15 日内向省级商务主管部门备案
4. 订合同前至少 30 日书面披露 12 项核心信息
5. 每年第一季度报告上一年度特许经营合同情况

处罚标准

# 原文（地方商务主管部门公开说明）
三、不属于商业特许经营的情形
以下商业活动因不具备「统一经营模式」的实质特征，不属于法律意义上的商业特许经营：
  · 商品生产特许(贴牌生产)或商品销售代理
  · 单一的商标许可、专利许可，且不涉及统一经营管理
  · 委托他人(品牌方)管理自有店铺
  · 平台(系统)所有者仅提供平台使用服务，撮合交易或管理业务流程，
     并收取服务费的行为（如部分电商平台、众包配送系统等）

合规设计原则：四条必做，四条绝不做

02城市承办方体系设计

你要的"每个地市 2~3 家、引入竞争提升质量、统一培训建立标准、公司轻资产"， 这套思路本身是对的，而且是这类平台唯一能做大的方式。但角色定义必须从「加盟商」改成「城市服务商」， 原因见 01.2。

2.1 角色定义（这一节的名称决定了你的法律风险）

2.2 为什么是 2~3 家，而不是更多或更少

你说"最好是两个到三个"——这个数字不是拍脑袋，它有明确的经济学理由。 我把三种配置放在一起对比，你会发现 2~3 是唯一的平衡点：

2.3 竞争机制怎么设计才真的提升质量

"有竞争"不等于"竞争有效"。随机派单或价低者得，只会把质量拖垮（劣币驱逐良币）。给一套可直接实现的机制：

2.4 防飞单：不能用保证金，那用什么

这是轻资产模式的固有代价，也是你这套体系最大的运营风险。既然收保证金这条路被 01.2 封死了， 必须用业务手段替代。按有效性排序：

2.5 "统一培训建立标准体系"怎么做才安全

03资金与分账架构

3.1 先数清楚：一场培训会到底有多少钱要分

你的场景比电商复杂得多——一笔客户付款背后有 5~8 个收款方。这是这套系统最难的部分， 先把角色列清楚：

3.2 合规资金结构

3.3 分账规则引擎：可配置，不要写死

你的分账规则会频繁变（不同城市、不同客户、不同承办方等级），硬编码是一场灾难。设计成规则引擎：

// 分账规则：按优先级匹配，第一条命中的生效
settlement_rule {
  id, tenant_id,                    // 可为 null = 平台默认规则
  scope: CITY | PROVIDER | ACTIVITY | TENANT,
  scope_value,                      // 如 city_code = 350200（厦门）
  priority: 100,                    // 数字越小优先级越高
  valid_from, valid_to,
  splits: [
    { role: PLATFORM,     calc: PERCENT, value: 15 },
    { role: CONTRACTOR,   calc: PERCENT, value: 15 },
    { role: RECOMMENDER,  calc: PERCENT, value: 3  },
    { role: RESIDUAL,     calc: REMAIN   }        // 剩余部分归服务商池
  ],
  hold_days: 7,                     // 活动结束后冻结 7 天再结算（留争议窗口）
  min_payout_minor: 1000            // 低于 ¥10 不分账，累积到下次
}

// 执行：一笔订单 → 生成一张分账指令，而不是多笔
settlement_instruction {
  id, order_id, rule_id,
  total_minor, currency,
  lines: [ { payee_type, payee_id, sub_merchant_id, amount_minor, status } ],
  status: PENDING | EXECUTING | PARTIAL | DONE | FAILED,
  channel: WECHAY_PROFITSHARE | ALIPAY_SETTLE,
  channel_txn_id, executed_at
}

3.4 结算周期与发票

04地市资源托管：媒体 / 拍摄 / 住宿 / 场地

你说"这个主体对应的后端媒体发布的组织单位、拍摄的、还有住宿的，都要一起弄到整个平台里面去"。 这里有一个决定成败的设计选择：资源签给谁？

4.1 关键决策：资源必须签平台，不能签承办方

4.2 谁来开发这些资源？

承接上一版的 SAE（供给侧获客引擎）。这里要解决一个新问题：SAE 是你在总部远程采集， 但土地资源的核实和谈判需要本地人。答案是分工：

4.3 资源库结构（承接 SAE 的 supply_org）

SAE 采集的 supply_org 在签约后升级为平台资源资产，新增绑定关系：

// 资源 × 城市 × 承办方 的可见性（关键：可见 ≠ 可自主交易）
resource_binding {
  resource_id,                       // 场地/酒店/拍摄/媒体/餐饮/停车
  city_code,
  contract_type: PLATFORM_SIGNED,    // 恒为平台签约
  visible_to_contractors: [ids],     // 本市承办方可见
  price_tier: AGREEMENT | MARKET,    // 协议价 vs 市场价
  agreement_price_minor, currency,
  allow_direct_contact: false,       // 默认false：承办方不得私下联系
  introduced_by_contractor_id,       // 谁引入的 → 用于计酬
  valid_from, valid_to
}

allow_direct_contact = false 这个字段是把"资源侧绑定"落到代码里的方式。 承办方能在系统里看到、能下单、能用，但看不到对方的直连信息。

05AI 智能体私有化：经济账与现实路径

你说"企业办公 AI 智能体如何做成私有化部署，提供企业安全的环境，这个 AI 智能体搭建可以低价或免费"。 这两句话放在一起是矛盾的——我先把账算给你看，再给解法。

5.1 核心矛盾：私有化不可能免费

"私有化部署"意味着模型跑在企业自己的机器上，那硬件成本由谁承担？下面是真实量级：

显存数据来自公开技术资料整理，实际还受上下文长度、并发数、推理框架影响，以实测为准。

5.2 但是——企业说的"要私有化"，往往不是字面意思

这是本节最有价值的一点。我建议你在部署前先问清楚客户这句话到底指什么，因为大多数情况下答案不是"必须在我们机房"。

5.3 三档交付模型（解决"免费获客"与"私有化成本"的矛盾）

5.4 技术栈建议（承接上一版 8.5 节）

// 复用上一版结论：对客 AI 产品自建，Dify 只做内部运营 AI
推理框架：vLLM / SGLang（生产级吞吐与并发）
          开发验证用 Ollama，国产硬件考虑 LMDeploy
知识库：  PostgreSQL + pgvector（与主库同实例，省运维）
模型：    不要一上来就上大模型
          办公场景 7B~8B INT4 通常足够 → 单张 24GB 卡即可
对话管理：自建（OpenAI 兼容 API，便于将来换后端）
交付形态：Docker Compose 一套镜像 → 同一份可交付给 SaaS / VPC / 本地三种场景
          这一点很关键：一份镜像决定你能否低成本做三档交付

判断是否该自建 GPU 的经验公式

公开资料里给了一个实用的判断方法，我原样转给你：

06大V 获客引擎：不要爬，用官方平台

你说"运营后端也要有 AI 或爬虫去把全国的大V 都抓取过来"。 技术上能爬，但这条路是错的——不是因为合规，而是因为官方平台已经把这件事做得好得多，而且是免费的。

6.1 官方接单平台就是你最好的数据源

门槛与数据字段为公开资料整理，各平台政策会变，请以官方最新说明为准。

6.2 但你的真正需求不是"抓数据"，是"给博主算一笔账"

你说"了解博主的情况，给潜在客户定制线下培训方案和收益情况"。这里有个重要的换位思考： 博主关心的是"办一场线下活动，我能赚多少、粉丝买不买账"，不是"你们平台有什么功能"。

6.3 业务员工作台：从"一堆数据"变成"今天该联系谁"

07代理商与合作商体系

7.1 三个容易混淆的角色，必须分开

7.2 代理商的分润设计

08修订、优先级与待你决策

8.1 对你既有文档的修订

8.2 开发优先级：资金合规必须先于所有交易功能

8.3 待你决策的问题