00结论先行：矛盾总表

00.1 矛盾总表（按处置优先级排序）

严重度：致命=做了会出事或白做　重=必须调整设计　中=可延后处理

#	矛盾	冲突的双方	严重度	来源	处置
C1	资金二清	「客户付款给平台，平台抽成后转给承办方」 vs 央行 217 号文无证资金清算	致命	第 4 件	走分账通道，平台不碰货款
C2	EspoCRM 是 AGPLv3	「用开源件搭平台」 vs AGPL 网络条款（改后对外提供服务须公开你的源码）	致命	本件核实	API 集成不 fork；或买商业授权
C3	Chatwoot 社区版无白标/权限	「平台向客户提供客服系统」 vs 社区版缺 custom branding、roles、SSO、SLA	致命	本件核实	降为内部工具，或买授权
C4	特许经营豁免 vs 统一培训	「统一培训建立标准体系」 vs 特许经营「统一经营模式」要件	致命	第 4 件	标准写进系统，不写进合同
C5	分账 30% 上限	需分出去约 75~90% vs 微信分账默认上限 30%	致命	第 4 件	今天就申请突破限额
E1	10~20% 养不活承办方	提成比例 vs 一场百人会需要的 12~15 人日投入	重	本件测算	改基数 + 只招有存量业务的公司
E2	单场收入撑不起团队	平台单场约 1 万元 vs 5~8 人技术团队年成本	重	本件测算	收入重心移到摊位招商 + AI 线
E3	免费私有化 vs 现金流	「AI 智能体低价或免费」 vs 真私有化首年 5~15 万/家	重	第 4 件	分三档，免费档≠私有化
E4	摊位对冲 vs 平台抽成基数	摊位费帮客户降本 → 客户办会预算下降 → 平台抽成基数变小	重	本件	平台从摊位费抽成，不只在支出端抽
S1	轻资产 vs 技术重资产	「运营变轻资产」 vs 「自建强大后台 + AI + 采集」	中	第 3 件	明确定性：交付轻、技术重
S2	全球格局 vs 地市地推	「做全球的格局」 vs 「每个地市招 2~3 家」	中	第 1 件	模型预留，市场只做国内
S3	严格多租户 vs AI 推荐	「每客户只看自己的数据」 vs 「后台大量数据做 AI 分析与推荐」	重	第 1/3 件	聚合特征可跨租户，明细不可
S4	四套技术栈	Node(主体) + PHP(EspoCRM) + Ruby(Chatwoot) + Python(Dify) 三套数据库	重	本件	砍到两套：Node + Python
S5	免费 AI 获客链条断裂	「免费 AI 有利于学员报名到主播客户」 vs 免费 AI 的受众是企业，学员是个人	重	本件	重新定义免费 AI 的受众
R1	需求 3 与需求 4 重叠	「学员项目资源链接」 vs 「服务商摊位展示」本质是同一件事的线上/线下版	中	第 1 件	合并为一个域
R2	需求 1 无 API 支撑	「内容制作分发到各种平台」 vs 视频号/小红书无第三方发布 API	重	第 1 件	改为「任务派发 + 交付物跟踪」
R3	三线撞单	自营业务员 / 城市承办方 / 代理商 抢同一客户	重	本件	按客户类型划清，写撞单规则
R4	资源归属 vs 承办方干劲	「资源签平台不签承办方」 vs 承办方觉得「我干活你摘桃」	中	第 4 件	按引入资源的使用量计酬
R5	垫资与月结	「平台不碰资金」 vs 供给侧普遍要求预付/月结	重	本件	确立不垫资原则

01致命级：5 项按现状落地会出事

这一节的共同特征是：系统做完了才发现跑不起来，或者跑起来了被叫停。 其中 C2、C3 是本次新核实的，前几份文档没有覆盖——因为它们藏在你「用开源件搭平台」这个策略里，不查许可证看不出来。

C1 · 资金二清（已知，但要补一条边界）

第 4 件已详述，此处不重复。补充一件当时没说清的：不是所有钱都不能碰，很多团队知道二清后会过度收紧，把自营业务也绕走，白白损失收入。

资金类型	能否由平台收款	依据
摊位招商费（服务商付）	可以	平台是服务的直接提供方，属于自营收入，普通商户号收款即可
AI 产品订阅费	可以	同上，自营收入
SaaS 会员费 / 平台服务费	可以	同上
场馆、餐饮、住宿、拍摄费	不可以	服务由第三方提供，平台代收即构成二清 → 走二级商户号 + 分账指令
学员报名费（学费）	不可以	除非平台自己当主办方并承担交付责任（那是重模式），否则学员应直接付给主播
承办方佣金	不可以	不是「平台收钱再分给他」，而是由分账指令直接从订单金额中分给他

这条边界很重要：摊位招商是你的高毛利收入，而且它恰好不受二清约束——因为它就是你自己卖的服务。 这从合规角度再次印证了第 1 件的判断：摊位招商才是这个平台真正的收入引擎。

C2 · EspoCRM 是 AGPLv3，不是 MIT（新核实）

对你意味着什么，取决于你怎么用它：

用法	AGPL 风险	说明
内部自用，不修改，不对外	无	不触发。纯配置（用它的 Entity Manager 建实体）一般不算"修改"
独立部署，你的平台通过 REST API 调用	低~中	进程间通过 API 通信，通常不被认定为"衍生作品"。这是相对安全的用法，但不是零风险
Fork 源码改 PHP、加模块、改实体定义	高	明确构成修改 → 你的 CRM 定制代码须以 AGPL 公开。这与你"自建商业平台"的目标直接冲突
把它包装成产品卖给你的客户	高	官方与第三方评测均指出：AGPL 会阻止转售定制化托管版本而不公开代码

另外附带的两个现实问题：

• EspoCRM 是 PHP + MySQL。你的主体后端（方案 A）是 Node/TS + PostgreSQL。引入它等于引入第二语言栈 + 第二数据库 + PHP 运维。
• EspoCRM 是单租户设计。它是"一个实例 = 一个组织"。你要的是多租户 SaaS，得靠 teams/角色模拟或多实例，前者隔离弱、后者运维重。

C3 · Chatwoot 社区版缺少你要的那几个功能（新核实）

这直接撞上你两处设想：

你的设想	社区版能否支撑	说明
平台向客户提供客服系统作为增值能力	不能	没有白标，客户看到的是 Chatwoot；没有角色权限，做不到多租户内部分级
企业 AI 官网里嵌 AI 客服 widget	勉强	社区版有 live chat + API channel 可用，但界面无法去除 Chatwoot 标识，企业客户通常会介意
用 Captain AI 做自动回复	不能	Captain AI 自 Premium 起才有，且走 OpenAI，数据出境问题与你的"私有化"承诺冲突
平台自己的客服（内部用）	可以	内部使用无白标需求，社区版完全够用

处置：把 Chatwoot 定位为你自己的内部客服台（不是卖给客户的能力）。 对客的 AI 客服 widget 走第 3 件 8.x 节定的自建路线——那本来就是四块很小的技术（pgvector + 对话管理 + widget + 复用 IAM）， 而且自建反而更符合你"私有化"的承诺，因为不存在 Captain AI 把数据发给 OpenAI 的问题。

C4 · 特许经营豁免与「统一培训 + 标准体系」的交叉（新发现的冲突）

第 4 件给了一条豁免路径：不收任何前置费用、不授权商标与统一形象、收益只来自成交分成，则不构成特许经营。 但你这一轮提出「到公司培训后建立的标准体系」——这一条恰好接近《商业特许经营管理条例》里「统一经营模式」的要件。

C5 · 分账 30% 上限与佣金基数未定义

第 4 件已指出默认上限 30%。这里补上当时没做的算术——一场 10 万元支出、100 人的培训会：

分出去的项	占支出比	金额	说明
场馆 + 会场搭建	25%	¥25,000	硬性成本
餐饮	15%	¥15,000	硬性成本
住宿（道旅等）	20%	¥20,000	硬性成本
拍摄 + 媒体	10%	¥10,000	硬性成本
承办方佣金	15%	¥15,000	你给的比例
需分账合计	85%	¥85,000	远超默认 30% 上限
平台留存	15%	¥15,000	含你的毛利与税费

必须今天就申请突破限额，有审批周期。第 4 件已列为最高优先级，此处只是把数字摊开—— 85% 与 30% 差了近三倍，这不是"接近上限"，是完全不在同一个量级，不能抱侥幸心理。

02经济账：4 处算不平

这一节的数字都是量级估算（非承诺值），但即便上下浮动 50%，结论方向不会变。 四笔账共同指向同一件事：线下培训会执行这门生意的毛利，撑不起一个平台的固定成本。 这不是劝你放弃，而是说明收入重心必须换地方。

E1 · 10~20% 的佣金，养不活一家承办方

先算承办方办一场会的真实投入（100 人、1 天）：

阶段	人日	说明
前期：需求确认、选址比价、供应商询价	3~5	需要与场地/餐饮/住宿多方谈判
中期：报名对接、房餐统计、物料、彩排	4~6	学员信息核对最容易出错的环节
现场：执行 2~3 人 × 1.5 天	3~4.5	签到、餐饮、住宿、停车、摊位
后期：对账、结算、复盘	1~2	多方发票与尾款
合计	11~17.5	取中位 14 人日

按二三线城市执行人员含社保约 500 元/人日计，单场直接成本约 7000 元。 提成 15% × 10 万支出 = 15,000 元，毛利 8000 元。单场看是赚的。

问题出在年总量上——这才是矛盾真正的位置：

E2 · 平台单场收入 vs 团队固定成本

平台单场收入项	保守	乐观	说明
支出端服务费	¥6,000	¥10,000	10 万支出中平台留存 6~10%
摊位招商抽成	¥4,000	¥10,000	保守：4 个摊位 ×5000 ×20%；乐观：10 个摊位
拍摄/媒体自营差价	¥1,000	¥3,000	取决于是否自营
单场合计	¥11,000	¥23,000	取中位约 1.5 万

年固定成本	金额	说明
技术团队 6 人	约 ¥180 万	含社保，二线城市薪资水平
运营 + 地推 4 人	约 ¥80 万	城市经理 + 运营
服务器 / API / AI	约 ¥20 万	量级估算
合计	约 ¥280 万	不含你自己的机会成本
盈亏平衡所需场次	约 190 场/年	按单场 1.5 万计

这不是说项目不成立，而是说明一件事：培训会执行不能是平台第一年的收入来源。三条出路，建议同时走：

1. 把摊位招商做成主要收入。它边际成本极低（摊位一旦标准化，多招一个摊位的成本几乎为零），且不受二清约束（C1），还能帮客户降本。这是唯一一个三重利好叠加的收入项。
2. 让 AI 产品线当现金流。它是订阅制、可规模化、毛利高，且你已经具备交付能力（第 3 件 08 节）。用它养平台，而不是指望平台养它。
3. 先做 1~2 个城市，不要铺 10 个。单城密度比城市数量重要得多——同一个城市的第 20 场会，成本远低于第 5 个城市的第一场。

E3 · 「免费 / 低价」与「私有化」在成本上互斥

第 4 件已给三档方案（S 版 SaaS 多租户 / P 版企业云 VPC / E 版真本地机房）。此处只补一句关键判断：

E4 · 摊位对冲与平台抽成基数：动机冲突

这是全套设计里最隐蔽的一处，也是最容易被忽略的：你最想做的那件事（帮客户用摊位费对冲成本），会直接减少你自己的收入。

场景	客户支出	摊位收入	平台从支出端抽 10%	平台从摊位抽 20%	平台总收入
不做摊位招商	¥100,000	¥0	¥10,000	¥0	¥10,000
做摊位招商（只抽支出端）	¥100,000	¥50,000	¥10,000	¥0	¥10,000
做摊位招商（两端都抽）	¥100,000	¥50,000	¥10,000	¥10,000	¥20,000

03战略层：5 处自相矛盾

S1 · 「轻资产」与「自建强大后台」是两件不同的事

你把这两件事放在一起说了，但它们指的是不同的资产类型，混着看会做出错误的资源分配决策。

正确表述：BizLink 是「交付轻资产、技术重资产」。这意味着你的现金流压力集中在前期， 所以 E2 的结论才那么重要——必须先有一条能产生现金流的业务（AI 产品线）养着平台，而不是反过来。

S2 · 「全球格局」与「每个地市招 2~3 家」是两种扩张逻辑

这两句话单独看都对，放在一起会稀释资源。全球意味着：多币种与汇率、多时区日程、多语言（且不只是翻译，是排版与阅读习惯）、 跨境支付通道（Stripe/PayPal/空中云汇）、GDPR 或个人数据跨境规则、各国发票税务。这套东西的成本大致等于把国内版重做一遍。

S3 · 严格多租户 vs AI 推荐（以及开源件的单租户本质）

你有两个要求：「每个客户只能看见自己的客户和业务」和「后台大量信息后通过 AI 分析、内容推荐、课程推荐」。 这两者之间存在张力，但不是无解——关键是分清"特征"和"明细"：

数据层级	能否跨租户	例子
L1 公开 / 聚合统计	可以	"制造行业类课程的平均完课率"、"某城市的场馆均价区间"
L2 业务明细	不可以	A 客户的学员名单、报价、合同、结算金额
L3 个人信息	需单独授权	学员手机号、身份证、人脸签到

可行做法：跨租户学习聚合特征，租户内做具体决策。模型可以说"这类课程在二线城市的完课率通常偏低"， 但不能说"A 客户的学员名单和 B 客户相似，所以把 A 的学员推荐给 B"。

附带一个同类问题：Chatwoot、EspoCRM、Dify 这三个开源件本质上都是单租户设计。 把它们拼成多租户 SaaS 的适配工作量，在很多场景下高于自研——这是"开源优先"策略与"多租户平台"目标之间的内在张力。 第 3 件已就 Dify 给出结论（只用内部运营），本件 C2/C3 补了另外两个。

S4 · 四套技术栈：这是运维层面的真实风险

组件	语言	数据库	建议	理由
BizLink 主体	Node/TS	PostgreSQL	保留	核心，无争议
Dify	Python	PG + Redis + 向量库	限内部	只服务内部运营，不开放前端（第 3 件结论）
Chatwoot	Ruby/Rails	PG + Redis	降级	降为内部客服台；对客 widget 自建（见 C3）
EspoCRM	PHP	MySQL	重估	AGPL + PHP + 单租户三重问题（见 C2）。先回答「我真的需要独立 CRM 吗」； 若需要，只能走「独立部署 + REST API 集成 + 不 fork」

四种语言、三套数据库、四套升级节奏。对一个 5~8 人团队，这不是"省了开发量"，是"把开发量转移到了运维上，而且是持续支出"。 建议目标态：Node/TS（业务主体）+ Python（AI 侧，含自建 RAG 与 Dify）两套，一套 PostgreSQL。

S5 · 免费 AI 的获客链条是断的

这句话有三种可能的真实意图，对应的产品完全不同，必须选一个：

#	可能的真实意图	产品形态	定价
A	给主播客户免费工具，让他更容易办会和运营学员	学员运营 AI：招生文案、课纲生成、学员答疑机器人、会后跟进	免费/低价成立
B	用免费办公 AI 把企业拉进来，再从企业里转化学员	企业办公 AI（现有业务）+ 后续转化	链条不通
C	给学员免费 AI 工具，作为报名赠品	学员端 AI 助手（课程问答、资料检索）	可行但价值弱

04需求与组织：6 处冲突

R1 · 需求 3 与需求 4 是同一件事的两个版本

需求 3「对学员有项目资源链接的服务」与需求 4「为服务商举办摊位展示，让学员与服务商建立咨询和链接」—— 本质都是"学员 ↔ 服务商的连接"，区别只在发生在线上还是线下会场。当成两个需求做，会做出两套重复的资源库和匹配逻辑。

处置：合并为一个域「资源链接」，线上版（长尾、持续）与线下版（摊位、会期）共用同一套服务商档案、标签体系和匹配规则， 只是触发时机不同。这样既省一半开发量，也让"摊位"从一次性活动变成长期关系的起点。

R2 · 需求 1 的定位必须改写

第 1 件已核实：微信视频号、小红书均无面向第三方的内容发布 API。所以"内容制作并自动分发到各平台"这个表述实现不了。 但你仍然需要这块能力——因为它是主播客户的真实痛点。

R3 · 三套外部主体会撞单

主体	职责（建议）	收入来源	冲突点
自营业务员	只做 KA 与跨城客户	底薪 + 提成	与承办方抢同一个本地客户
城市承办方	本地交付 + 本地供给引入	成交分成	做了业务员的活，会要求更高分成；也可能被业务员绕过
代理商	AI 产品线分销	订阅费分成	与业务员在 AI 产品上重叠

处置（三条）：

1. 按客户类型划线，不按地域划线：跨城连锁 / 年办 5 场以上的 KA → 自营；本地单场 → 承办方；只要 AI 产品不要培训会 → 代理商。
2. 写死撞单规则并在系统里强制：客户以 owner_type 归属，先报备先得，保护期 90 天；归属变更后原主体保留该客户历史订单的佣金。
3. 业务员与承办方重叠的那部分，明确定为业务员不做本地交付——他拉来的单也必须派给承办方执行，并按约定比例计入承办方业绩。 这样业务员不会变成承办方的竞争对手。

R4 · 资源归属与承办方干劲

第 4 件已给结论：资源必须签平台（否则承办方带走资源，城市供给一夜消失）， 但实地考察和砍价交给承办方（他是本地人），并按引入资源的使用量计酬。 这里补一个执行细节：计酬必须可持续而不是一次性——一次性 500 元/条的录入奖励，会换来一批低质量录入。 建议按"该资源被实际使用产生的 GMV"持续分成（比如 1%~2%，持续 2 年），这样承办方有动力引入真的会被用到的资源。

R5 · 「平台不碰资金」与「供给侧要预付」的冲突

合规方案要求钱直接进供应商账户。但现实是：场馆普遍要求定金，酒店要求预授权，搭建方要求预付材料款。 如果不能垫资，很多单子谈不下来。

R6 · 最根本的一条：范围在持续膨胀，但没有任何一件事被放弃

所以下一节的核心不是"再规划一次"，而是明确列出「这一期不做什么」。 一份没有"不做什么"的规划，等于没有规划。

05收敛后的目标形态

05.1 一句话定位（重写）

这个定位把四件事统一了：客户价值（不花钱）= 你的独特能力（摊位对冲）= 系统价值（全链路可视）= 你的收入来源（摊位抽成，E4）。 它同时也是一句销售话术——第 1 件我说过会小二帮你找场地砍价但不管成本怎么收回来，这就是那句话的正面版本。

05.2 系统边界：现在做 / 后置 / 砍掉

05.3 收入模型重排（这是最重要的一张表）

原来的隐含假设是"平台靠培训会抽成活着"。E2 的测算否定了它。重排为三层：

层	业务	毛利	规模化	在体系中的角色
L1	企业 AI 服务（现有业务）	高	强	现金流。你现在就有客户和交付能力，用它养平台。注意：必须是产品化交付，否则变成外包（第 3 件 8.4）
L2	摊位招商抽成	高	中	平台主收入 + 核心卖点。不受二清约束（C1）、帮客户降本（E4）、边际成本近零、竞品没有
L3	培训会执行服务费	低	弱	规模与数据。毛利低但带来场次、数据和客户粘性。不要指望它养团队

05.4 合规资金流向（重设计）

06修订版路线图

与第 1 件原版路线图相比有三处实质改动：① 资金合规从"并行"提到"前置"；② 城市从"多城试点"改为"单城打透"； ③ AI 产品线从"平台的一部分"改为"前期的现金流来源"。

阶段	目标	关键动作	完成判据（可验证）
P0 第 0~1 月 不写代码	把三个阻塞项同时启动	① 申请微信支付服务商资质 + 分账限额突破 ② 法务过渠道协议措辞（C4） ③ 给 3 家关系最好的客户打电话，只问现状不推销	拿到受理回执；法务书面意见； 3 家客户中至少 2 家确认"今年有办会计划且当前流程麻烦"
P1 第 2~5 月	人工跑通一场真实培训会	① 用微信群 + 表格 + 电话跑通 1 场，把真实流程逐步记下来 ② 同期只建 4 个技术底座：IAM/多租户、工作流引擎、核销码、统一进度接口 ③ AI 产品线继续接单赚钱	一场真实活动交付完成，且流程文档被当事人确认无遗漏节点。 这一步不能省——系统应该自动化已验证的流程，而不是边开发边猜流程
P2 第 6~10 月	系统承载 + 摊位招商上线	① 把 P1 记录的流程搬进系统 ② 摊位招商与对冲看板优先于任何其他功能 ③ 打通分账（若 P0 已获批） ④ 单城市签约 1 家承办方	同一城市完成 3 场以上，其中至少 1 场实现摊位费覆盖部分成本； 客户能在手机上看完整进度
P3 第 11~18 月	单城打透 + 复制第二城	① 单城做到 12 场/年以上再考虑加第 2 家承办方 ② 道旅酒店 API 接入（商务应已完成） ③ 复制模式到第 2 个城市	单城年场次 ≥12；承办方从平台获得年收入 ≥10 万（E1 的存活线）； 单位 economics 为正
P4 第 18 月+	才轮到这些	企业 AI 私有化 P/E 版、大V 库与收益测算器、AI 推荐、代理商体系、全球	——

07需要你拍板

#	问题	为什么现在必须定	我的建议
1	能否接受：零加盟费、零保证金，只用业务手段约束承办方？	这是整套合规设计的地基（C4）。若不能接受，后面所有架构都要重来	接受。防飞单用「让他吃饱 + 资源签平台 + 虚拟号隔离」
2	佣金基数到底是哪个？①采购支出额 ②平台毛利 ③客户学费收入	三种口径承办方到手相差 3~5 倍（C5/E1）。不定死，结算代码必然返工	用 ①（采购支出额），它对承办方最直观、最容易自己算明白
3	S5 里免费 AI 的受众，是 A（主播学员运营）还是 B（企业办公）？	决定两条产品线是否分开（S5）。选错会导致产品两头不讨好	选 A。企业办公 AI 继续付费，主播运营 AI 免费做钩子
4	EspoCRM 还要不要？（AGPL + PHP + 单租户）	C2。如要，只能走 API 集成不 fork；如不要，CRM 模块自研	不要。你的实体在第 1 件领域模型里已有，自研界面即可
5	Chatwoot 的定位？内部客服台，还是卖给客户的能力？	C3。社区版无白标与权限，做不了对客产品	内部客服台。对客 widget 自建（顺带更符合私有化承诺）
6	第 1 年做几个城市？	E1/E2。城市越多，每个城市场次越薄，承办方越养不活	1 个城市。最多 2 个，且必须是你关系最密的那个
7	能否接受：第 1 年平台不盈利，由 AI 产品线养？	E2 测算：盈亏平衡需约 190 场/年，第 1 年不可能达到	接受，并把这当成既定前提写进预算，而不是到时候才发现
8	学员报名费是否由平台代收？（沿用第 1 件未决项）	C1。涉及预收资金与存管要求	不由平台代收。学员付给主播，平台只收服务费

07.1 本件对前四份文档的修订（需回写）

文档	原结论	修订为
第 1 件 业务架构	五需求平行推进；多城试点	需求 3/4 合并为一个域（R1）；需求 1 改为任务派发（R2）；城市收敛到 1~2 个（E2）
第 2 件 道旅接入	——	不变。但商务启动时间提前到 P0，与技术解耦
第 3 件 后端与供给	Dify 只做内部运营 AI	不变。新增：Chatwoot 降为内部工具（C3）；EspoCRM 需重估（C2）
第 4 件 渠道分账	每地市 2~3 家承办方	改为按年场次分档：一线 2~3 / 二线 1~2 / 三线 1，且第 1 年一律 1 家（E1）
第 4 件 渠道分账	统一培训建立标准体系	培训内容限缩 + 标准写进系统而非合同（C4）
第 4 件 AI 私有化	三档方案	不变。但明确「免费」只对应 S 版，不得与"私有化"同时承诺（E3）

07.2 本件未能验证的部分（不掩饰）

• E1/E2 的场次估算是量级推算，不是调研数据。「二线城市全年约 50 场百人级付费培训会」这个数字我没有可靠的公开来源， 是按场地数量 × 使用频次 × 品类占比推的，误差可能达 ±50%。它是用来说明"量级关系"的，不要拿去做预算。 真正的数字只能靠 P1 阶段在目标城市实地问出来。
• 微信分账限额突破的实际成功率与周期，未核实。我确认了默认上限的存在，但"能否申请突破、需要什么条件"取决于你的商户资质与谈判， 建议直接问支付服务商经理，比查文档快。
• EspoCRM 的商业授权价格未查到公开报价，需直接联系官方。若你决定保留它，这是必问项。
• C4 的法律判断是风险提示，不是法律意见。「标准写进系统」这个建议能降低风险，但不能替代律师对协议文本的审阅。

08分佣口径与可配置结算参数（V1.1 新增）

针对你本轮的三点回应：① Chatwoot / EspoCRM 是自用 + 给客户部署 + 只收运维费 ——这个前提改变了 C2/C3 的结论，我在 08.1 修正；② 佣金原来想的是利润的 15% ——这个口径在行业里几乎不存在，且换算后只有常规做法的 1/5 ~ 1/7，见 08.2； ③ 比例做成后台可配置并给默认值——08.4 给出完整参数表，08.5 给出变更规则。

08.1 许可证结论修正：「自用 + 给客户部署 + 只收运维费」

但两个软件的边界不同，必须分开看：

软件	收运维费	给客户部署	必须守的边界
EspoCRM AGPLv3	可以	可以，有条件	① 绝不 fork 改 PHP 源码。一旦修改，修改部分必须向每个拿到部署的客户公开。 ② 部署时必须附 AGPL 声明 + 源码获取途径（成本几乎为零，但不做就是违规）。 ③ 用它的 Entity Manager 做配置一般不算"修改"，风险可控。
Chatwoot MIT 主体 + 商业 EE 目录	可以	可以，有条件	① 社区版不能白标、没有角色权限、没有 SSO。客户会看到 Chatwoot 标识。 ② ⚠ 若部署后出现 SSO 登录页，说明你在跑 enterprise/ 目录的代码 → 生产使用需订阅。 这是最容易无意违规的一点：Docker 完整镜像包含企业版代码，能跑起来不代表可以用。

一句话处置：EspoCRM 恢复可用（我上一轮"建议不用"的判断过于保守，撤回）， 但守住"不改源码 + 附声明"两条；Chatwoot 可用于内部客服 + 给客户部署， 但白标和 SSO 是硬缺口，客户一旦提出这两个需求，要么买授权（$19 或 $99/agent/月），要么你自建。 运维费报价里要把这个授权成本算进去，或在合同里写明"白标/SSO 需另购授权"。

08.2 「利润的 15%」——这个口径建议换掉

你问常规做法是多少。先给核实到的行业惯例（2026 口径）：

角色	行业惯例	常见比例	基数
销售/渠道方 拿 commission	SaaS 推荐伙伴 10~15% 首年 ARR； 转售商(VAR) 20~30% 首年 + 5~8% 续费； MSP/代理 20~35%	10~30% 中位 20~25%	销售额 / ARR
活动执行方 拿 management fee 或 markup	支出百分比法 10~20% of total event cost； 成本加成法 net cost + 12~18%； DMC 惯例 15~25% 项目成本 或 净价 + 15~30%	12~25%	采购成本 / 项目支出
按利润分成	行业里几乎不用	罕见	利润

参考口径：活动公司整体毛利率 25~45%、净利率 10~20%；企业活动类毛利 35~50%、净利 15~20%； 研讨/培训制作类常见利润基准 15~25%。

为什么行业不用"利润分成"：

1. 利润不可验证。毛利还是净利？摊不摊平台运营费？承办方无法核对 → 必然产生纠纷。
2. 会诱导双方做假账。平台有动力把成本摊高（利润变低 → 分成少），承办方有动力质疑每一笔分摊。
3. 风险收益不匹配。承办方承担全部执行风险（现场出问题它背），却只按剩余利润分成。

08.3 建议改为：三层结构（而不是单一比例）

承办方是交付方，不是销售方。交付方行业惯例拿的是"管理费/成本加成"，不是"佣金"。 而且这个改动还有个额外好处，见下面的 callout。

组成部分	默认比例	建议区间	作用
① 执行服务费 cost-plus	15%	12~20%	在其承接的采购成本上加成。成本 8 万 → 承办方得 1.2 万。这是主体收入
② 成本节约奖励	30%	20~40%	低于基准成本的部分，30% 奖励给承办方。用来抵消 cost-plus 的固有缺陷（见下）
③ 资源引入持续分成	1.5%	1~2%	它引入的场馆/餐饮/酒店每被用一次，按 GMV 分成，持续 24 个月

08.4 后台可配置参数表（含默认值）

按你的建议，全部做成后台可配置。下表可直接作为 settlement_rule 表的初始种子数据。

参数键	默认值	建议区间	可覆盖维度	说明
contractor.service_rate	15%	12~20%	全局 / 城市 / 承办方等级	执行服务费（cost-plus）。二线 16%、三线 18%（量少则略高）
contractor.saving_share	30%	20~40%	全局 / 承办方	成本节约奖励
contractor.resource_share	1.5%	1~2%	全局 / 资源类型	资源引入持续分成，duration_months=24
platform.service_fee	10%	8~15%	全局 / 客户 / 单场	平台对客服务费率
platform.booth_commission	20%	15~25%	全局 / 城市	摊位招商抽成（E4，主收入）
agent.ai_subscription_share	25%	20~30%	全局 / 代理商等级	代理商分销 AI 产品：首年 ARR 25% + 续费 5%
agent.renewal_share	5%	3~8%	全局	续费分成（促其维护客户而非只拉新）
sales.gross_margin_share	10%	8~15%	全局 / 业务员	自营业务员提成。此处用毛利率分成是合适的（内部人员，数据可信）
contractor.score_threshold	70	60~80	全局	低于此分暂停派单（评分权重派单用）
contractor.grade_step	+1%	0.5~2%	全局	每升一级，service_rate 上浮幅度

覆盖优先级（单向覆盖，不支持多级相乘）

// 从窄到宽查找，命中即停止 —— 不要用"全局×城市×等级"连乘，那样算出来的数没人看得懂
单场覆盖  >  承办方等级  >  城市  >  全局默认

// 示例
resolve_rate(contractor_id, city_code, event_id) {
  if (override = rule.find(event_id))          return override   // 单场特批
  if (r = rule.find(contractor.grade))         return r
  if (r = rule.find(city_code))                return r
  return GLOBAL_DEFAULT                                          // 15%
}

08.5 配置变更必须遵守的三条规则

08.6 对 07 节待拍板项的确认状态

#	问题	状态	结论
—	每地市 2~3 家承办方	已确认	第 1 年每城 1 家，随场次增长再放宽（E1）
—	两处逻辑冲突（C4 统一培训 / S5 免费 AI 受众）	已确认	按本件方案调整：标准写进系统；免费 AI 走 A 方案（主播学员运营）
2	佣金基数	待改	原设想"利润 15%"≈ GMV 2.25%，建议改为 cost-plus 15% + 节约奖励 30%（08.2/08.3）
4	EspoCRM 去留	修正	撤回"建议不用"。自用 + 给客户部署 + 只收运维费可行，守住"不改源码 + 附声明"
5	Chatwoot 定位	修正	可给客户部署并收运维费，但白标/SSO 是硬缺口，需买授权或自建
1,3,6,7,8	零加盟费 / 免费 AI 受众 / 城市数 / 第 1 年不盈利 / 报名费代收	仍待定	见 07 节