BizLink · B端全链接商务对接平台

00结论先行：这个项目能不能做、先做什么

能做，但不能按你现在列的 1→5 顺序平行推进。你这个需求本质上是四家公司叠在一起： 内容分发 SaaS、MICE 会议培训 O2O 交易平台、本地生活供应链（酒店/餐饮/停车）、AI 推荐引擎。 每一块单独都有成熟玩家。但把它们围绕「一场培训会」这条主线串起来，目前没有强竞争对手 —— 这是你唯一的、也是足够大的机会窗口。

0.1 五个需求的真实定位（重要，决定开发顺序）

0.2 我建议的切入顺序（与你的原始顺序不同，理由已列）

0.3 一句话业务定义

0.4 关键量级参考（用于判断投入产出，均为公开信息推算，需自行复核）

来源：会小二官网/百科公开数据、道旅(dida.com) 官网、美团分销平台官网。数千万级融资与 40 万企业客户为公开报道口径，非审计数据。

01外部依赖核实：哪些 API 真能用，哪些是幻觉

你说"不允许乱写"，所以这一节的每一条我都去查了官方文档，标了来源。 这节决定了架构里哪些模块能自动、哪些必须人工。

1.1 结论汇总表

1.2 这三条核实结论如何改变架构

02业务架构

业务架构按 五层划分：渠道层（谁去拿资源/拿客户）→ 角色层（谁在用）→ 业务域层（系统做什么） → 平台能力层（通用能力复用）→ 数据智能层（沉淀什么）。 右侧两根竖轴是贯穿全局的横切关注点，必须在架构第一天就内置，后期补代价极高。

2.1 六个业务域的职责边界（防止后期耦合失控）

03技术架构

3.1 关键架构决策与理由

3.2 技术栈选型对比

两套都能做，差别在团队与生态。结合你现有的技术背景（Node.js / Strapi / 阿里云 ECS + Nginx）， 我倾向 方案 A；若你团队 Java 人手充足且预期要做私有化大客户交付，选 方案 B。

04多租户与权限设计

你的要求："客户必须是多租户的模式，每个客户只能看见自己的客户和业务"。 这一节是整份文档里最不能出错的部分——它一旦做错，后期改造需要动所有查询、所有表、所有接口，成本相当于重写。

4.1 谁是"租户"

4.2 隔离方案选型

4.3 跨租户的三种合法场景（必须单独设计，否则业务跑不通）

4.4 全球化字段预留（P0 埋点，P4 启用）

4.5 权限模型：RBAC + 数据域（Data Scope）

纯 RBAC 不够用——同一个"活动经理"角色，在 A 租户只能看自己负责的活动，在平台侧要能看全局。 所以采用 RBAC（功能权限）+ Data Scope（数据范围）双维度。

// 权限判定伪代码 —— 两个维度同时满足才放行
function canAccess(user, action, resource) {
  // ① 功能权限：角色是否包含该操作
  if (!user.roles.some(r => r.permissions.includes(action))) return false;

  // ② 数据范围：该资源是否落在用户的数据域内
  const scope = user.dataScope;   // 见下表
  switch (scope.type) {
    case 'TENANT':    return resource.tenantId === user.tenantId;
    case 'OWN':       return resource.ownerId  === user.id;
    case 'ORG_TREE':  return orgTreeContains(user.orgId, resource.orgId);
    case 'AGENT':     return user.ownedTenants.includes(resource.tenantId)
                       && user.cities.includes(resource.cityCode);
    case 'PROVIDER':  return hasEngagement(user.providerId, resource.eventId);
    case 'PLATFORM':  return true;  // 记录审计日志
  }
}

05数据模型（领域模型）

下图为 核心实体关系图，共 21 个核心实体、分 4 个域带。 橙色字段为外键（FK），几乎所有业务表都带 tenant_id —— 这是 4.2 节隔离方案的落地体现。

5.1 表清单与索引策略

06业务流程与状态机设计

这一节回答你的硬要求："所有流程都要让客户在 Web 和手机端都可以看到每个节点状态和进度"。 做法是：所有需要进度可视的单据，统一挂在 workflow_instance 上，由工作流引擎驱动状态机， 前端用同一套进度组件渲染。这样不用为每个流程单独写进度条，也保证 Web/H5 状态定义绝对一致。

状态机图例

6.1 主干流程：培训会 / 展会全周期（需求 2）

流程节点明细（这张表就是开发任务清单，也是前端进度条的数据源）

6.2 学员报名与签到流程（需求 2 的分支）

6.3 服务子单流程：餐饮 / 住宿 / 停车 / 搭建（需求 2 的执行层）

6.4 项目资源撮合流程（需求 3、需求 4）

6.5 摊位招商与预订流程（需求 5 —— 你的杀手锏）

6.5.1 成本对冲模型（这是整个平台最值得做的差异化功能）

你的原话："支持学员从事的工作的项目落地的服务商可以预定摊位，来实现线下成本的支出对冲"。 把它做成一个实时看板，就是客户续费的最大理由。

// 培训会成本对冲实时模型（每次摊位成交/每笔支出变动时重算）

  总支出 Cost
    = 场地费 + 餐饮费 + 住宿费 + 停车费
    + 搭建物料 + 拍摄/媒体 + 人员差旅 + 平台服务费

  对冲收入 Offset
    = Σ 摊位费(booth_order.amount)
    + Σ 赞助/广告位收入
    + Σ 项目撮合佣金分成（客户方分成部分）

  净成本 NetCost   = Cost - Offset
  对冲率 OffsetRate = Offset / Cost × 100%

// 关键产品化动作：把这三个数字做成实时卡片，放在客户工作台首屏
┌──────────────┬──────────────┬──────────────┐
│  总支出       │  对冲收入     │   净成本      │
│  ¥ 186,000   │  ¥ 152,000   │  ¥ 34,000    │
│              │  对冲率 81.7% │  ↓ 较上届 -44%│
└──────────────┴──────────────┴──────────────┘
   招商进度 ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓░░░  34/40 个摊位已定
   距成本打平还差 2 个摊位（¥ 8,000）  ← 这句是促成交的关键提示

6.6 内容制作与分发流程（需求 1）

6.7 统一工作流引擎：让"进度可视"成为平台能力而非重复开发

你有五条主流程、约 50 个节点。如果每个模块自己写状态字段和进度逻辑，前端要做 5 套进度条， 且超时提醒、SLA 统计、催办都要重写五遍。做法：所有需要进度可视的单据，统一挂载 workflow_instance。

状态机定义（配置驱动，非硬编码）

// workflow_definition —— 用 JSON 描述，支持版本管理与热更新
{
  "code": "training_event_v1",
  "version": 1,
  "bizType": "TRAINING_EVENT",
  "states": [
    { "code": "DRAFT",      "name": "需求草稿",   "type": "START" },
    { "code": "MATCHING",   "name": "资源匹配中", "assignee": "ROLE:OPERATOR",
      "slaHours": 4,  "escalateTo": "ROLE:OPS_LEAD" },
    { "code": "QUOTED",     "name": "方案报价中", "slaHours": 24 },
    { "code": "CONFIRMED",  "name": "客户已确认", "assignee": "ROLE:CUSTOMER" },
    { "code": "LOCKED",     "name": "档期已锁定",
      "onEnter": ["freezeQuote", "lockResourceCalendar", "openBoothSale"] },
    /* ... 其余状态省略 ... */
    { "code": "CLOSED",     "name": "已完成结项",
      "type": "END", "onEnter": ["generateReviewReport", "pushProviderRating"] },
    { "code": "CANCELLED",  "name": "已取消", "type": "END" }
  ],
  "transitions": [
    { "from": "DRAFT",      "to": "MATCHING",  "on": "SUBMIT",       "guard": "requirementComplete" },
    { "from": "MATCHING",   "to": "QUOTED",    "on": "QUOTE_READY" },
    { "from": "QUOTED",     "to": "CONFIRMED", "on": "CUSTOMER_CONFIRM" },
    { "from": "CONFIRMED",  "to": "LOCKED",    "on": "PAY_DEPOSIT", "guard": "contractSigned" },
    { "from": "LOCKED",     "to": "ENROLLING", "on": "OPEN_ENROLL" },
    { "from": "CONFIRMED",  "to": "CANCELLED", "on": "CANCEL", "guard": "penaltyRule" },
    { "from": "LOCKED",     "to": "CANCELLED", "on": "CANCEL", "guard": "penaltyRule" }
  ]
}

6.8 "全节点进度可视"的产品实现（你的硬要求）

核心思路：Web 和 H5 调用同一个接口、同一份数据契约，前端用同一套组件渲染。 下面是统一的进度数据结构——后端只需要为每种单据实现一次"生成这个结构"的方法。

// GET /api/v1/progress/{bizType}/{bizId} —— Web 与 H5 共用同一接口
{
  "bizType": "TRAINING_EVENT",
  "bizId": "EVT20260901001",
  "title": "2026 秋季智能制造总裁班（上海站）",
  "currentState": { "code": "PREPARING", "name": "会前准备中" },
  "overallPercent": 62,
  "slaRisk": "NORMAL",          // NORMAL | WARNING | OVERDUE
  "nodes": [
    { "code": "DRAFT",     "name": "需求草稿",   "status": "DONE",    "at": "2026-09-01T10:12:00Z" },
    { "code": "MATCHING",  "name": "资源匹配中", "status": "DONE",    "at": "2026-09-01T14:30:00Z" },
    { "code": "QUOTED",    "name": "方案报价中", "status": "DONE",    "at": "2026-09-02T09:05:00Z" },
    { "code": "CONFIRMED", "name": "客户已确认", "status": "DONE",    "at": "2026-09-03T11:20:00Z" },
    { "code": "LOCKED",    "name": "档期已锁定", "status": "DONE",    "at": "2026-09-04T16:00:00Z" },
    { "code": "ENROLLING", "name": "报名进行中", "status": "DONE",    "at": "2026-09-05T09:00:00Z" },
    { "code": "PREPARING", "name": "会前准备中", "status": "CURRENT",
      "subTasks": [
        { "name": "餐饮需求确认", "status": "DONE",      "assignee": "服务商·锦江餐饮" },
        { "name": "住宿预订",     "status": "PROCESSING", "assignee": "系统·API通道", "dueAt": "2026-09-20T00:00:00Z" },
        { "name": "停车需求确认", "status": "PENDING",    "assignee": "场地方·张江中心" },
        { "name": "搭建与物料",   "status": "PENDING",    "assignee": "服务商·XX会展" }
      ]
    },
    { "code": "ONGOING",   "name": "活动进行中", "status": "PENDING" },
    { "code": "SETTLING",  "name": "结算中",     "status": "PENDING" },
    { "code": "CLOSED",    "name": "已完成结项", "status": "PENDING" }
  ]
}

通知与超时升级规则

07服务资源库与供给侧运营

你说要"收集每个城市的培训场地、会展部署机构、视频拍摄机构、媒体传播机构"， 并让"业务员或每个市的渠道代理商去对接这些服务机构"。 先说结论：这是整个项目最贵、最慢、最不可绕过的一环，且它不是技术问题。 会小二做到 9 万家深度合作场地用了约 10 年。你必须在动工第一天就并行启动地推， 系统只负责让录入快、让撮合成、让结算准。

7.1 七类资源的采集字段模板（直接给地推人员用）

不同类型资源差异极大，统一用 resource_item 主表 + attrs JSONB 存差异。 下表是必须采集的核心字段——字段太少匹配不准，太多地推不愿填。建议：标 ★ 为必填，其余后补。

7.2 冷启动：资源从哪来（可执行的六条路径）

7.3 渠道代理商体系设计

7.4 服务商入驻与抢单

08AI 能力设计：做什么、不做什么、什么时候做

你的描述里有"通过 AI 对接美团和携程""AI 进行分析、内容推荐、课程推荐"。 我必须客观地说：这里面只有一部分是 AI 能做的，其余是工程问题或运营问题。 把 AI 放在正确的位置，能省大量成本；放错位置，会做出没人用的花瓶功能。

8.1 四个真实落点（按 ROI 排序）

8.2 落点①详解：需求结构化（P1 就做，立刻省人力）

// 输入（客户在 H5/Web 里的一句话，或语音转文字）
"我下个月中想在上海办一场智能制造的培训，大概 80 人，三天两晚，
  场地要有投影和一个能分组讨论的小会议室，住宿要离场地近一点，
  最好能安排停车位，总预算控制在 20 万以内。"

// 输出（结构化 JSON，直接预填培训会需求表单，客户确认即可提交）
{
  "city": "上海",
  "startWindow": { "earliest": "2026-10-11", "latest": "2026-10-20" },
  "duration": { "days": 3, "nights": 2 },
  "headcount": 80,
  "budget": { "amount": 20000000, "currency": "CNY" },  // 单位：分
  "requirements": {
    "venue": { "capacityMin": 80, "needProjector": true,
               "breakoutRoomsMin": 1, "layout": "分组讨论" },
    "hotel":  { "roomsEstimate": 40, "preferNearVenue": true },
    "parking": { "needReserve": true }
  },
  "confidence": { "city": 0.99, "headcount": 0.95,
                  "budget": 0.88, "startWindow": 0.72 },  // 低置信项高亮让客户确认
  "missingFields": ["dining.mealStandard", "venue.city_district"]
}

8.3 落点④的数据门槛：什么时候才配谈"推荐"

门槛值为行业经验数量级，非精确阈值；实际以你自己的 A/B 实验结果为准。结论：P1~P3 不要碰推荐算法，把精力放在把数据结构和埋点做对。

8.4 落点③：RAG 知识库（租户隔离是红线）

// 向量化的对象与隔离策略
可向量化内容：
  · 课件 / 讲义（courseware）        → 学员问答、课程推荐
  · 项目资源描述（project_resource） → 学员-项目语义匹配
  · 服务商能力描述（resource_item）  → 需求-资源语义匹配
  · 历史工单与处理方案              → 客服问答
  · 活动规则 / 服务标准 / FAQ        → 通用问答

强制约束：
  ① 每条向量必须带 tenant_id，检索时作为硬性过滤条件（不是相似度权重）
  ② 平台级内容（如通用服务标准）用 tenant_id = NULL，检索时并入
  ③ 服务商敏感信息（底价、内部备注）禁止入向量库
  ④ 内容删除时必须同步删除向量，否则会造成"删了还能搜到"的合规事故
  ⑤ 向量库只是派生存储，可从主库全量重建 —— 主库才是事实来源

8.5 LLM 网关：不要把命运交给单一厂商

09工程落地：可以直接开工的部分

9.1 仓库结构与模块划分（monorepo）

bizlinkbiz/
├── apps/
│   ├── web-customer/        # 客户工作台 (Next.js) —— 租户视角，PC 主战场
│   ├── web-admin/           # 平台运营后台 —— 审核/清算/风控/全局视图
│   ├── web-provider/        # 服务商工作台（Web 版，可选）
│   ├── h5/                  # 移动端 H5（学员/服务商/代理商共用，uni-app 或 Taro）
│   └── api/                 # 后端单一应用（模块化单体）
│       └── src/
│           ├── modules/
│           │   ├── iam/         # 租户/用户/角色/组织/代理商
│           │   ├── supply/      # 服务商/资源/档期/抢单
│           │   ├── event/       # ★ 培训会/报名/行程/签到（主干）
│           │   ├── trade/       # 摊位/订单/合同/支付/结算
│           │   ├── match/       # 项目/撮合/商机/分佣
│           │   ├── content/     # 素材/审核/分发
│           │   ├── workflow/    # 状态机引擎（被所有域依赖）
│           │   └── platform/    # 通知/文件/搜索/配置（禁止其他域重复实现）
│           ├── adapters/        # ★ 外部依赖隔离层（见 9.3）
│           │   ├── hotel/       # HotelSupplier 接口 + dida/美团/人工 三种实现
│           │   ├── venue/       # 场地：仅人工实现（无 API）
│           │   ├── catering/    # 餐饮：仅人工实现
│           │   ├── parking/     # 停车：仅人工实现
│           │   ├── distribution/# 抖音/快手/B站/YouTube/小红书(半自动)/视频号(半自动)
│           │   ├── payment/     # 微信/支付宝（国内）+ Stripe/PayPal（海外）
│           │   ├── contract/    # 电子签章
│           │   └── llm/         # LLM 网关（多模型抽象）
│           ├── common/          # 租户上下文/异常/幂等/日志/审计
│           └── infra/          # 数据库/缓存/队列/对象存储/搜索
├── packages/
│   ├── shared-types/        # 前后端共享的 TS 类型（状态枚举、DTO）
│   ├── ui/                  # 组件库（含通用进度条 —— Web/H5 复用同一份状态定义）
│   └── workflow-schema/     # 状态机定义 JSON + 校验器
├── deploy/
│   ├── docker-compose.yml   # 一期：单机/双机 Compose 即可
│   └── nginx/               # 与你现有 Nginx 运维经验一致
└── docs/
    ├── api/                 # OpenAPI（自动生成）
    └── workflows/           # 各流程状态机定义（本文 6.x 节的 JSON 落地）

9.2 核心 API 清单（按域，一期范围）

9.3 外部 Adapter 的统一接口（这是架构中最值钱的一段抽象）

// 所有外部供给能力实现同一接口 —— 换供应链不改业务代码
interface SupplierAdapter {
  search(req: SearchRequest):  Promise<SearchResult[]>;   // 查询可用资源
  quote(req: QuoteRequest):    Promise<Quote>;            // 询价
  book(req: BookRequest):      Promise<BookResult>;       // 下单（幂等）
  cancel(req: CancelRequest):  Promise<CancelResult>;     // 取消
  query(req: QueryRequest):    Promise<OrderStatus>;      // 查状态
}

// 三种实现，按配置动态路由
class HotelApiAdapter    implements SupplierAdapter { /* 道旅 / 美团分销 / 协议价直采 */ }
class HotelManualAdapter implements SupplierAdapter { /* 生成工单，人工处理并回填 */ }
class CateringManualAdapter implements SupplierAdapter { /* 餐饮只有人工实现 */ }

// 带熔断降级的调用包装 —— 业务层无感知
async function callWithFallback(order: ServiceOrder) {
  try {
    return await circuitBreaker.execute(() => adapter.book(order));
  } catch (e) {
    await downgradeToManual(order, e);   // 自动转人工工单
    await alertOps(order, e);            // 告警运营（不可静默）
    return { accepted: true, mode: 'MANUAL' };  // 业务继续，客户看到"处理中"
  }
}

9.4 编码规范（CI 强制执行，这四条能省掉未来 80% 的返工）

• 所有新增业务表必须有 tenant_id 且非空 —— CI 扫描 migration 文件，缺失直接失败
• 禁止在模块间直接访问对方数据表 —— 只能调用对方导出的 Service 接口；用 ESLint 自定义规则或依赖检查工具卡口
• 禁止裸 SQL 拼接 —— 统一走 ORM/Repository，租户过滤由全局拦截器注入
• 所有写操作接口必须接收 request_id 幂等键 —— 缺失则 CI 报警
• 金额字段类型必须是 BIGINT + currency_code —— 发现 FLOAT/DOUBLE 直接拒绝合并
• LLM 输出必须过 JSON Schema 校验后才允许写库

9.5 通用系统（客服 / CRM / IM）：集成优先，不要自研

你提到"平台提供大量的有用的软件，客服系统、CRM系统、AI企业服务"。自研这三样会吃掉你至少一半的研发资源， 且做出来大概率不如成熟的开源方案。

9.6 部署拓扑与成本量级（阿里云，估算区间，需自行核算）

成本为公开定价推算的量级区间，未含人力、短信、AI Token、第三方 API 调用费； 实际请以云厂商当前报价与你自己的压测结果为准。短信与 AI 调用是可变成本，务必设置月度预算上限与告警。

9.7 团队配置建议（按阶段）

10分期路线图与 MVP 边界

10.1 五阶段总览

10.2 MVP 边界：必须严格守住（决定你能否在 7 个月内上线收钱）

10.3 关键里程碑（可用于内部考核）

11风险清单（按严重度排序）

12需要你确认的 8 个问题

这份设计里有 8 处我做了假设。这些假设会实质影响架构与排期，建议你逐条确认后再进入开发。

1. 首批城市选哪 2~3 个？ 决定资源库范围与地推投入。建议选你或团队有人脉、且培训需求密集的城市。
2. 首批客户从哪来？ 你手上是否已有 3~5 个愿意共建的大V/企业客户？如果没有，这会是比开发更大的瓶颈。
3. 技术栈选 A（NestJS/TS）还是 B（Spring Boot/Java）？ 取决于你现有团队构成。
4. 支付与资金：是否涉及向学员/服务商预收资金？ 涉及预收就有资金存管与合规要求，架构上要引入分账与对账，需提前咨询法律意见。
5. 是否接受"餐饮/停车在前 18 个月都靠人工撮合"？ 这是现实约束，若坚持要自动化，项目会延期。
6. CRM 是否直接用你已有的 EspoCRM？ 复用能省 3~4 个月，但要接受它与平台的数据同步成本。
7. 渠道代理商是自营团队还是外部合作？ 影响分佣系统复杂度与税务处理方式。
8. "全球格局"的时间点？ 建议 P4（18 个月后）。但若你有明确的海外客户来源，需要提前规划，我可以单独出一版国际化设计。