后端选型决策 · 开源集成边界 · 供给侧获客引擎 · AI 企业服务产品线

00结论先行

四句话：后端锁方案 A；Dify 进架构但只能做 AI 层，且有一条许可证红线； 爬虫+AI 不是一个后台功能，它是一个独立子系统（SAE），需要单独排期； 采集能自动化，但"拿到电话并打过去"这一步受严格监管，自动化空间比你想的小得多。

0.1 对你三个质疑的直接回应

01后端选型：锁 A，附切换条件

1.1 先给结论

1.2 决策表：按你团队现状对号入座

把下面 5 个问题按实际情况打分，选 A 或 B 只需看第 1 条和第 4 条，其余是校验项。

1.3 一个我没在主文档说透的点：真正的风险不在语言

你担心选错后端。但把过去十年这类平台项目的失败原因排个序，语言选型进不了前五。 真正的杀手是下面三个，而它们和 A/B 无关：

结论：不要在 A/B 之间反复权衡，这是低价值决策。把精力放在上面三条上，它们的回报高一个数量级。

1.4 关于"业务线长"的架构补充

你说"业务线很长"，这在工程上的正确解法不是换语言，是划清模块边界。给一条可执行的硬规则：

做到这三条，即使你今天用"模块化单体"（A），将来业务真的大了要拆微服务或换语言重写某个模块， 都是可控的局部手术而不是推倒重来。这才是应对"业务线长"的正确姿势——用边界换未来的灵活性，而不是用语言。

02开源系统的集成边界（Chatwoot / EspoCRM / Dify / n8n）

你熟悉开源项目、倾向用开源降本——这个方向完全正确。但集成开源系统有个致命陷阱： 让业务状态住进了开源系统的数据库里。一旦如此，你的核心业务就被别人的数据模型绑架了， 将来想换掉它的成本等于重写业务。这一节就是划清"谁拥有什么数据"。

2.1 核心原则：一个数据只有一个 Owner

2.2 四个开源系统的定位与集成方式

2.3 统一身份：SSO 是集成的地基

四个系统 + 自建后端，如果不做 SSO，用户要记 4 套密码、运营要在 4 处开账号—— 这套东西上线三个月就会被人绕过。做法：

03Dify 的定位、红线与工作流清单

3.1 先说为什么主文档漏了它

主文档写的是"LLM 网关 + 多模型抽象"，这只解决了"调哪个模型、限不限流、怎么降级"。 但你的业务里 AI 要做的是跨多步的逻辑——比如"拿到一条机构数据 → 判断它是不是连锁酒店 → 提取可承接的会议规模 → 生成一段首触话术 → 决定该派给哪个城市的业务员"。这是编排（Orchestration）问题，不是调用问题。 自己用 LangChain 写这套，代码量不大但迭代极痛苦：换个 Prompt 要发版、运营不能改、没有执行日志。Dify 解决的就是这一层。

3.2 ⚠️ 一条你必须先看的许可证条款

# 原文
1. Dify may be utilized commercially, including as a backend service for
other applications or as an application development platform for enterprises.
Should the conditions below be met, a commercial license must be obtained
from the producer:

a. Multi-tenant service: Unless explicitly authorized by Dify in writing,
you may not use the Dify source code to operate a multi-tenant environment.
    - Tenant Definition: Within the context of Dify, one tenant corresponds
      to one workspace. The workspace provides a separated area for each
      tenant's data and configurations.

b. LOGO and copyright information: In the process of using Dify's frontend,
you may not remove or modify the LOGO or copyright information...

这对你意味着什么：三种用法，两种安全，一种要谈

3.3 Dify 在你架构里的确切位置

3.4 一期要跑的 Dify 工作流清单

按优先级排序。前 4 个属于 SAE（见 04 节），是你现在最需要的；后几个按业务节奏后置。

3.5 部署与运维的现实参数

04供给侧获客引擎 SAE（Supply Acquisition Engine）

你说"'AI 和爬虫'作为后端技术支持不够"——这句话是对的，而且比你想的更对： 它根本不是后台的一个功能模块，它是一个有自己数据模型、自己的调度、自己的人工工作台、自己的合规边界的独立子系统。 本节按子系统规格重做。先给一个可能改变你想法的判断。

# 高德官方文档原文
目前搜索是不支持返回全量数据的，同请求参数翻页查询最多支持获取 200 条数据
（page_size 取值 1-25）

4.1 SAE 的目标与产出定义

4.2 数据源分层：四条路，成本与合规差别极大

把你说的"自动抓取"拆开看，实际上是四类完全不同的数据源，混为一谈是设计失败的根源。

4.3 采集层架构

4.4 数据模型（新增实体）

以下是 SAE 需要新增的核心表，与主文档 21 个实体的关系是： supply_org 在服务商确认合作后升级为 ServiceProvider（主文档已有实体）， SAE 的实体位于它上游。

// ① 原始线索（只增不改不删，保留抓取现场）
supply_lead {
  id, dedup_key(唯一索引), source(L1_MAP|L2_QCC|L3_SELF|L4_WEB),
  source_url, raw_json(jsonb),          // 原始响应全量留存，争议追溯依据
  fetched_at, job_id,
  status(NEW|PARSED|MERGED|REJECTED|DUPLICATE)
}

// ② 正式档案（SAE 的主产出）
supply_org {
  id, name, alias, category(场地|会展布置|视频拍摄|媒体传播|酒店|餐饮|停车|其他),
  city_code, district, address, lng, lat,
  uscc(统一社会信用代码, 可空), poi_id(可空),
  website, intro,
  quality_score(0-100), confidence(0-1),
  verify_status(UNVERIFIED|AI_VERIFIED|HUMAN_VERIFIED|FIELD_VERIFIED),
  lifecycle(LEAD|CONTACTED|NEGOTIATING|SIGNED|COOPERATING|CHURNED),
  owner_agent_id,                        // 归属业务员/代理商
  created_at, updated_at, last_verified_at
}

// ③ 联系人（一个机构多人，区分"公开座机"与"个人手机"）
supply_contact {
  id, org_id, name, title,
  phone_type(PUBLIC_LANDLINE|PUBLIC_MOBILE|PROVIDED_BY_SELF),  // 合规关键字段
  phone_encrypted,                       // 加密存储
  consent_at, consent_channel,           // 同意时间与来源：合规证据
  is_primary, do_not_contact(bool),      // 拒触达黑名单，写入即永久生效
  source
}

// ④ 能力标签（决定能否被匹配到具体需求）
supply_capability {
  id, org_id, cap_type(HOSTING|CATERING|PARKING|SHOOTING|LIVE|EXHIBITION),
  max_pax, min_pax, indoor_area_sqm,
  has_projector, has_stage, has_parking, parking_slots,
  price_band, currency, unit(DAY|SESSION|PERSON),
  valid_from, valid_to, verified_at
}

// ⑤ 触达任务与触达记录（每一次联系都必须留痕）
outreach_task  { id, org_id, channel, template_id, status, assignee_id, scheduled_at }
outreach_attempt {
  id, task_id, channel(CALL|SMS|EMAIL|IM|VISIT),
  ai_generated(bool), human_approved_by,  // AI 生成 + 谁批的，缺一不可
  content_snapshot, sent_at,
  result(NO_ANSWER|REACHED|INTERESTED|REJECTED|INVALID_NUMBER),
  recording_url, do_not_contact_triggered(bool)
}

4.5 AI 处理流水线：AI 做什么，不做什么

把 AI 放进这条链路时，最大的错误是让 AI 从采集一路干到发送。正确做法是按"决策风险"切分， 不同环节给 AI 不同的权限。

4.6 运营确认工作台（人在这里做什么）

你说"AI 初步对接，然后运营人员确认"——这个界面设计得好不好，直接决定 SAE 是省人还是费人。 给一份具体的界面规格。

4.7 "AI 初步对接"能做到哪一步：五个等级与合规边界

你希望"用 AI 和他们初步对接"。这一条我必须把话说清楚：技术上五个等级都能做， 但合规上只有前两级可以放心做。这不是保守，是因为国内对营销触达的监管近两年明显收紧。

4.8 成本量级测算（5 城 × 6 类，约 5000 家机构）

前提假设：每城每类用 4 组关键词 × 8 页（达到官方 200 条/组合上限），去重后总规模约 5000 家。 所有价格为量级估算，实际以各平台实时报价为准。

4.9 冷启动节奏：先做 1 城 1 类，别铺开

05服务商直连：不依赖对方改造的对接方案

你强调"必须做好和每个服务商直接的交互，比如停车场系统的二维码接入到我们的系统中"。 这一条我上一版设计错了——我默认服务商是"有 API 可被我调用的对方"， 真实情况是 90% 的服务商没有 API、没有技术团队、也不会为你的平台做二次开发。 他们的数字化能力就是"一部手机 + 一个微信 + 一个收款码"。 按这个前提重新设计，结论完全不同。

5.1 先给服务商分级，不同级别用不同对接方式

5.2 停车场二维码：三条路径的真实对比

我核实了停车行业主流厂商的开放能力，结论和"接个 API 就行"的直觉差别很大。

5.3 统一核销码协议（UVCP）：一套码覆盖全部线下服务

停车、餐饮、住宿、会场签到、甚至摊位入场——本质是同一件事：凭码履约 + 留痕 + 对账。 不要给每类服务各做一套，做一套统一的。

码的设计

// 二维码内容（短链接，不要把业务信息明文写进码里）
https://biz.link/v/A7X2K9QM

// 服务端 voucher 记录
voucher {
  code:            "A7X2K9QM",     // 8-12 位随机短码，服务端生成，不可预测
  voucher_type:    PARKING | CATERING | ROOM | VENUE | BOOTH,
  tenant_id,                            // 归属客户（多租户隔离）
  activity_id,                          // 关联活动
  provider_id,                          // 服务商
  sub_order_id,                         // 关联子单
  status:          ISSUED | USED | VOID | EXPIRED | SETTLED,
  valid_from, valid_to,                 // 时效窗口（防止转卖/隔天使用）
  max_redeem:      1,                   // 一码一次，防重复使用
  geo_fence:       {lng, lat, radius_m}, // 可选：核销地理围栏，防异地扫码
  settlement_price_minor, currency,     // 结算价（最小货币单位整数）
  redeemed_at, redeemed_by, redeemed_geo // 核销留痕
}

核销时序

5.4 合作酒店信息入库：区分"库存"与"资产"

你说"合作的酒店信息也要保存到我们的系统中"。这里有个容易混淆的点，必须先分清两类完全不同的酒店数据：

5.5 对账与结算：半自动化的最后一公里

06合规红线：一条与你的需求高度对标的判例

# 判决要点（据公开法理评述整理）
徐某某通过"爬虫"软件从"企查查""天眼查"等网站上获取
企业法定代表人的联系方式等信息 414,994 条，
整理成 excel 表格后出售给范某某，获利 12,420 元。
→ 法院认定：属于非法获取公民个人信息予以出售获利，
  构成侵犯公民个人信息罪，且属情节特别严重。

6.1 三条不能碰的红线

6.2 四个必须做的合规动作（低成本，高保护）

1. 数据只自用，绝不外流：不售卖、不提供对外查询 API、不给第三方共享。 这一点必须写进公司制度并体现在产品权限上（没有"导出全部"按钮）。 它决定了你是"合理使用"还是"数据交易"——两者法律定性完全不同。
2. 保留来源与时间戳：每条记录存 source / source_url / fetched_at / raw_json。 将来有人质疑"你哪来的我的电话"，你能拿出证据说明来源合法、时间明确。
3. 一键退订与拒触达永久生效：do_not_contact 一旦置位全平台永久生效， 且不因换业务员、换批次而重置。
4. 隐私政策与告知：在服务商自助入驻页与首次触达时，明确告知"信息来源、用途、如何要求删除"。 对方主动提交时勾选同意框，并留痕 consent_at。

07对主文档的修订、待你决策的问题

7.1 主文档需要同步的修订点

7.2 需要你拍板的 6 个问题

7.3 三天内可以启动的事（不需要等系统开发完）

• 申请高德开放平台企业开发者 Key，用 Postman 跑一次 POI 搜索，确认 tel 字段返回情况与配额。
• 给你最熟悉的一个城市做人工试点：用高德搜索"培训场地/会议酒店"，手工收集 30 家， 打电话问价格与承接能力。这 30 通电话的价值超过后面所有设计文档——它会告诉你真实的话术、真实的拒绝理由、真实的价格带。
• 给 Dify 官方发一封授权确认邮件（见 3.2）。
• 注册企查查开放平台，先不付费，确认接口返回字段是否满足你的核验需求。
• 找一位数据合规律师做一次咨询（几千元量级），把 06 节的三条红线给他过一遍。

08AI 企业服务产品线：外链 → 内链的渗透路径

8.1 这条路径回答了我上一轮最担心的问题

主文档和本文反复强调：这个项目最大的风险不是技术，是供给侧冷启动—— 会小二做到 9 万家深度合作场地用了约 10 年；没有种子客户、没有服务商，平台就是空转。

而你现在手里其实已经有三样东西：

8.2 三层渗透模型

8.3 被低估的资产：企业网站 AI 客服的会话数据

这一条我认为是你手里最有价值、且竞品买不到的东西。

8.4 三个必须警惕的风险

8.5 技术分界：对客 AI 产品自建，Dify 只做内部运营 AI

这是本节最重要的工程结论，也是 3.2 节许可证讨论的延伸。 一旦你要给多家企业交付 AI 产品，Dify 的多租户条款就会从"理论风险"变成"实际要处理的问题"。

对客 AI 产品的最小技术栈（参考）

// 不需要重，核心只有四块
1. 知识库与检索：PostgreSQL + pgvector（与主库同实例，省运维）
                  文档 → 切片 → embedding → 检索 + rerank
                  // 与你此前调研的向量/Embedding 路线可直接对接
2. 对话与会话管理：自建（对话历史、上下文窗口、引用溯源）
                   // 比 Dify 简单，因为你不需要通用的编排能力
3. 租户与配额：复用 BizLink 的 IAM + tenant_id
                   // 这是复用价值最大的一块，别重写
4. 嵌入与交付：一个 JS widget（官网挂一段代码即可）+ 一个后台 H5
                   // 决定交付成本的关键：做到"挂代码即用"，不做定制

这四块对一个有 20 年经验的工程师是几周的工作量，不是几个月。 真正的难点不在技术，在于把它做成不需要定制的产品——对应 8.4 的风险①。

8.6 本周就能做的三件事（验证这条路径是否成立）

1. 统计你的历史客户转化数据：做过 AI 官网（L1）的客户里，有多少家后来买了 AI 办公或后续服务（L2）？ 这一个数字决定整条路径的价值。低于 20% 说明"外链→内链"的渗透假设不成立， 那 BizLink 的冷启动要另想办法（比如直接做垂直行业的培训会）。
2. 挑 3 家关系最好的企业客户，直接问一个问题： "你们今年有没有办客户培训会/渠道会/招商会的计划？现在怎么找场地、怎么管报名？" 不要推销 BizLink，只问现状。如果三家都说"有，而且很麻烦"，你的需求假设就被验证了； 如果都说"没有"，那说明目标客户画像要调整。
3. 翻一下你服务过的企业官网 AI 客服的会话记录（如果有的话）： 把高频问题按主题聚个类。看看有没有明显集中在某个主题上—— 那就是你的第一场培训会最可能的选题，而且你知道它一定有受众。