三条业务线、20 个场景：开源选型与图解实施教程

研究归档：本篇保留2026年9月30日前后的本地公开资料研究。开源版本、功能、许可和星数属于当时快照；技术决策应复核所列官方来源。架构与交付计划为参考设计。

更新：2026-10-01。适用对象：准备向跨境独立站、中国企微私域和制造业等企业客户交付 AI 客服、知识库及业务助手的产品负责人和实施团队。

研究状态：本文件根据官方仓库、固定版本源码和官方文档编写。WeKnora 本地基线为 v0.8.2，RAGFlow 为 v0.27.2；其他项目以文中链接的当前官方资料为线索，客户项目必须固定 tag/commit。本文没有在本机启动任何服务，没有接入真实客户系统，没有测得准确率、并发、成本或 ROI。以下带“拟建”的网关、连接器、审批和模板都需要二开。

阅读路线与结论

如果第一单是独立站客服，用 Chatwoot 社区版做网站聊天与人工坐席，WeKnora 做知识问答，WooCommerce/Shopify API 查订单；若客户主要从 WhatsApp 来，改用 Whatomate 承接官方 WhatsApp Cloud API。若第一单是中国企微私域，先核 IYque-SCRM 的开源版、企微接口权限和品牌条款，再接 WeKnora 的证据检索。若第一单是制造/报价，WeKnora 管手册和政策，ERPNext 或客户现有 ERP 管 BOM、成本、库存、报价；AI 只提取需求与生成草稿，金额由规则计算并经人审批。

图 1 为本方案的拟建架构。WeKnora、Chatwoot、Whatomate、IYque 和 ERPNext 均有各自现成能力；图中“自有策略网关”并非任何上游产品内置的完整功能，需自己开发。具体来源：WeKnora v0.8.2 API、Chatwoot API 分类、Whatomate README、IYque README、ERPNext REST API。

技术组合和边界

许可核对：WeKnora v0.8.2 主体 MIT，RAGFlow v0.27.2 Apache-2.0；Chatwoot 仓库的企业目录有独立许可且 Captain AI 有付费边界；Whatomate 为 AGPL-3.0；IYque 根 LICENSE 为 Apache-2.0，但其 README 另称二开商用应保留 Logo/产品名，做白标前需要书面厘清；ERPNext 为 GPL-3.0。请针对实际采用的 tag、插件、模型、字体和交付方式复核条款，而不是只看仓库首页的许可徽章。Chatwoot Enterprise LICENSE、IYque LICENSE、Whatomate LICENSE、ERPNext 仓库。

二开的一条硬边界

• 知识：产品说明、保修政策、销售 SOP、制造工艺、批准的报价条款入 WeKnora，并记录来源、版本、生效期、密级。
• 实时事实：订单状态、物流、库存、BOM、成本、价格、客户阶段实时从商店/CRM/ERP 查询。不要把它们当作永久不变的 RAG 片段。
• 写动作：发消息、打标签、建任务、退款、改价格、创建报价等要由业务工具网关校验身份、参数与幂等；第一阶段默认“AI 草稿，人工确认”。
• 租户边界：一个客户的凭据和数据不得因共享模型或共享控制面泄漏到另一客户；文件引用直链、缓存、日志和评估数据都要测穿透。

20 个可售场景总览

“优先级”表示建议产品化顺序，不是市场规模排名。P0 可用有限数据和可控流程做第一批样板；P1 需要订单/企微/ERP 等接口；P2 涉及更复杂治理或较高业务风险。每个场景必须由具体客户的痛点、采购人和可授权数据验证；Star 数不是需求证明。

A. 跨境独立站：01–06

01｜多语种商品与政策问答。 访客问产品功能、保修和配送范围时，WeKnora 按语言检索已发布的商品说明及政策，Chatwoot 显示带出处的回复草稿；坐席先确认再发送。二开重点是店铺/地区/语言过滤、翻译后的政策一致性和无证据拒答。验收用真实英文及目标语问法，逐条检查引用是否属于该地区当前有效版本；不能仅看语言是否流畅。Chatwoot Website Inbox、WeKnora 知识库。

02｜规格、尺码、兼容选型。 用户给出型号或尺寸，助手从产品知识解释差异，同时实时查商品变体和可售库存；缺少关键尺寸时先追问。二开需要结构化属性表、规则校验和不兼容组合的拒绝规则，不能单凭向量相似度推荐。验收用边界尺寸、停产型号、无货变体；错配率单独统计。WooCommerce REST v3有商品和变体资源，Shopify 店铺另走其官方 API。

03｜订单与物流查询。 客服先验证顾客对订单的访问资格，再用店铺 API 按订单号查状态和履约信息，WeKnora 只解释“状态意味着什么”。二开是身份核验、订单字段最小化、物流商适配、请求限流。验收用冒用订单号、拆单、延迟回调、取消订单；不能把上次同步的物流状态包装成实时信息。WooCommerce Orders API。

04｜退换货资格判断。 WeKnora 检索按国家、品类和日期生效的政策，订单 API 提供购买日期/商品/履约状态；规则引擎计算是否在退货窗口内，AI 解释规则并生成工单草稿。例外、赔付和退款写入均由人批准。验收包括促销商品、跨境税费、过期政策和缺少订单证据。

05｜线索收集与弃购跟进。 站内会话收集需求和明确的联系偏好；CRM 保存线索和同意记录。AI 归纳兴趣，不自动外呼或群发。若走 WhatsApp，需按官方通道消息窗口和经批准的模板发送；不同渠道窗口不同，Chatwoot 渠道限制表列出 WhatsApp 的限制。验收看有效线索率、取消订阅和重复触达，而不是只看会话数。

06｜投诉升级与人工接管。 AI 检出退款争议、破损、法律/安全风险或重复失败时，停止自动答复并把会话摘要、订单时间戳、证据交给坐席。Chatwoot 与 Whatomate 均有人工会话工作台；二开需要风险分类、转接队列、SLA 和接管后停止机器人继续发送。验收看“该转人工却未转”的漏判和上下文是否完整。Whatomate README。

B. 中国企微私域：07–13

07｜活码获客与来源归因。 以 IYque 的活码/标签和渠道统计为业务壳，记录来源活动、员工、客户 ID 和首次触达时间；WeKnora 可生成不同产品线的欢迎知识卡。二开是归因字段和 CRM 去重，不应把个人微信自动化误当企微官方接口。验收看渠道归因准确、重复客户合并、离职员工交接。IYque 开源版功能。

08｜销售回复副驾。 销售在企微工作台看到知识出处、可选话术和下一步问题；AI 不自行代表销售发送价格承诺。IYque 源码已有 AI 客服和人工状态判断，二开应把 WeKnora 检索结果置于“生成草稿”之前，并保留销售最终选择。IYque 客服实现。验收看建议采纳、错误承诺、跨员工越权。

09｜价格与政策异议。 售前先读取客户地区、等级和商品，WeKnora 给出最新批准政策的引用；实际客户价从 CRM/报价系统读取。二开把折扣授权做成规则：超出授权范围只显示“待经理审批”。验收用过期折扣、跨区域价目表、无权查看客户价等反例。

10｜客户群知识服务。 将群公告、产品 FAQ、活动规则分库管理；群成员提问后由运营人员选择是否发布回答。二开需群 ID 到知识范围的映射、敏感内容过滤和活动失效撤回。群消息读取与自动回复能力以客户实际取得的企业微信接口权限和平台规则为准，不能从“源码有群发功能”推断任何客户都可用。

11｜跟进提醒与沉默客户挽回。 AI 从有授权的客户阶段和历史跟进摘要生成“下一步建议”，CRM 创建待办草稿；由销售确认联系内容、时间与渠道。二开要做触达频率上限、客户拒绝联系标记和负责人归属。验收用多个销售抢同一客户、客户已成交/已退订、节假日等情况。效果看有效跟进完成率，而不是发送数量。

12｜企微售后客服与转人工。 已批准的保修/安装/售后 SOP 进入 WeKnora；IYque 承担官方企微客服收发与人工接管。第一阶段只对低风险 FAQ 自动草拟，高风险问题转专人。二开点在 IYque 的客服处理链：先判断人工接待状态，再检索租户允许的知识库；无证据、投诉、退款等转人工。验收覆盖接管后机器人静默、相同客户连续消息、撤回的旧政策。

13｜会话总结与质检。 有权限的主管查看脱敏摘要、客户需求、承诺事项与待办；质量规则识别漏回、越权承诺、未及时转人工。IYque README 描述会话总结和服务记录，但获取会话全文、存档范围与使用目的必须按企业实际授权配置。二开需按岗位控制访问、短保留期和人工复核。验收要看摘要是否遗漏关键承诺、是否把不同客户对话混合。

C. 企业知识与制造/报价：14–20

14｜企业制度与入职助手。 HR 上传最新版员工手册、差旅、采购与 IT 指引，WeKnora 按公司/部门/岗位过滤并给引用。二开是 SSO、部门 ACL、文档生效期、离职禁用和内网入口。验收用工资、考核等高敏资料穿透测试；“无依据”时给制度负责人而非编造答案。WeKnora 租户认证。

15｜制造工艺 SOP 助手。 车间工人扫码设备/工序，只见该产线有效的作业指导书、工艺变更通知和安全警示。二开是设备/工位身份、版本追溯、离线或弱网策略、关键步骤人工确认；不让 AI 直接控制设备。验收用过期 SOP、相似型号、跨车间资料及安全停机问答。客户已有 MES 时，工单状态从 MES 读。

16｜BOM 与替代料查询。 工程师查询产品结构和批准替代料时，WeKnora 解释设计说明，ERPNext 或客户 ERP 返回当前 BOM 版本、物料与库存。二开需要物料号精确匹配和变更生效日校验；模型不能因为描述相似就认定物料可替换。验收对多层 BOM、版本切换、缺料和未批准替代料逐项核对。ERPNext BOM。

17｜设备故障与维修助手。 工程师输入故障码、设备序列号和症状，助手列有来源的排查顺序并查询历史维修记录；危险操作只提示停机/上报，不给无资质人员执行指令。二开是设备台账、权限和维修工单接口。验收比较故障定位时间、引用准确率和错误维修建议；ERPNext 提供 Maintenance Visit 等业务记录。

18｜质量检验与 8D 整理。 质检员上传测量记录和异常描述，AI 归类缺陷、检索历史案例、生成 8D 草稿；判定合格、放行或供应商索赔仍由质量经理按规则签核。二开需要检验限值表、批次追溯、图片/表格解析与批准流程。ERPNext 有 Quality Inspection，但 8D 自动化是拟建行业功能。验收要查数值单位、上下限、批次串档和草稿引用。

19｜报价助手。 销售把询价邮件或规格书交给助手，AI 提取型号、数量、交期、币种和特殊工艺；WeKnora 检索批准条款，ERPNext/ERP 查询 BOM、库存和有效价目表；确定性规则计算成本、毛利、税/运费，再生成待审批 Quotation。二开是规则版本、例外审批、汇率/税率时点和报价差异解释。验收用缺失规格、过期价、不同币种、低于最低毛利及重复提交。ERPNext Quotation 官方步骤。

20｜标书、方案与合同草稿。 售前复用批准的案例、技术参数和服务承诺，AI 根据客户需求填方案模板并对每项承诺给内部证据。二开需要章节级权限、客户可外发信息白名单、保密审查、变更比较与法务审批。验收重点不是文笔，而是条款一致性、无虚构资质/案例、附件版本正确。合同签署和对外投标保持人工责任。

图解操作教程：从一条客户链路开始

以下步骤按“客户授权的隔离测试服务器”编写，不是本机执行记录。不要把同一台演示机同时塞入 WeKnora、ERPNext、Chatwoot、Whatomate、Milvus 和本地大模型，再把性能当成产品结论。先选一个场景、一套业务壳、一个知识内核。若客户已有 CRM/ERP/POS，优先接现有系统，不为 AI 再造第二套业务数据。

第 0 步｜签订 POC 边界和资料清单

客户业务负责人、IT、安全/法务与实施方先确认：选哪个场景，谁为知识负责，哪些消息可读，哪类动作只生成草稿，哪些数据不得出网。建立一张来源表：

POC 样本建议覆盖常见问题与高风险反例，实际数量按客户业务量定。每一题标注“允许的来源、期望答案、应拒答或转人工的条件”。样本应先冻结再评估；不要边调边用同一测试集宣布效果。既有交付评估框架列出了更完整的评分口径。

第 1 步｜定版本、许可、运行环境和密钥

1. 固定所有上游项目的 tag/commit 和镜像 digest；保存 LICENSE、第三方通知和模块清单。不要用浮动 latest 当客户交付版本。
2. 在客户控制的测试环境准备 Linux、HTTPS 域名、反向代理、备份存储、日志与监控；按各项目官方资源要求和客户并发估算容量，模型推理若调用外部 API 则单独计费。WeKnora 官方安装说明提供标准 Compose 路线和依赖。
3. 将数据库密码、API Key、Meta App Secret、企微 Secret、模型密钥放入客户的密钥管理系统或只在服务器可读的环境变量。首次使用所有上游示例时替换默认管理账号/密码；不要复制仓库示例里的密钥到生产。尤其 Whatomate 配置说明要求生产环境设置加密密钥，否则账号 token 可能明文保存。
4. 每个客户用独立数据库/存储/密钥至少进行逻辑隔离；敏感客户用独立实例。模型服务商、区域和数据传输需客户批准。

第 2 步｜在客户测试环境创建 WeKnora 知识库

本轮只提供操作说明，不执行命令。依WeKnora v0.8.2 安装文档完成部署后，先用健康检查验证，再在浏览器中注册/登录。生产部署关闭公开注册并用邀请制和组织身份管理；空间 Owner 与平台管理员分别授权。

1. 打开「知识库」→「新建」，按客户、业务线和密级拆库，例如“公开商品 FAQ”“售后政策”“内部报价条款”“车间 A 工艺”。不要把全部客户文档放进一个可被任意 Agent 检索的库。

2. 在初始化向导选择对话模型和Embedding 模型，按资料类型选重排/解析策略，点击测试连通性。Embedding 模型变更会影响旧索引，升级要安排重建和回归。快速上手。

3. 上传文档或导入网页，为文件打地区、产品线、门店、岗位、密级、生效期等标签；文档名称和源端 ID 保留在元数据里。上传完成后等待异步解析到 completed，查看分块和引用，而不是只看“上传成功”。

4. 用 10 条真实但已脱敏的问题检查引用。点击每条回答的来源，核对它支持答案、版本仍有效、登录角色有权读取原文。无来源问题应拒答或转人工。

这些四张截图直接来自 Tencent/WeKnora v0.8.2 官方文档截图目录，用于说明上游 UI；客户实际界面会随版本和权限变化。不是本机运行截图。

第 3 步｜建行业 Agent 和服务端密钥

在「智能体」选择新建/编辑，配置名称、提示词、允许的知识库、检索策略与必要工具。对外客服 Agent 只允许访问公开政策，报价 Agent 才能访问经授权的内部价目条款。不要用提示词代替权限；权限应由 WeKnora 空间/知识库和自有网关双重限制。WeKnora Agent 文档。

给 BFF 分别创建只具备“检索”与“聊天”权限的服务端 API Key，尽可能绑定允许的 KB ID；不要把全权 key 嵌入独立站 JS 或企微前端。WeKnora v0.8.2 API 总览明确机器 key 的能力门控、KB 白名单和引用文件访问差异。以下是未来客户测试环境的请求样例，文中占位符不得原样使用：

curl -X POST 'https://kb.customer.example/api/v1/knowledge-search' \
  -H 'X-API-Key: <RETRIEVE_ONLY_KEY>' \
  -H 'Content-Type: application/json' \
  -d '{"query":"这款产品的保修期多久？","knowledge_base_ids":["<PUBLIC_POLICY_KB_ID>"]}'

该端点返回检索片段，不负责订单查询、企微发消息或报价计算。若需要 WeKnora 直接生成知识回答，先创建会话，再调用 POST /api/v1/knowledge-chat/:session_id 并处理 SSE 流、引用和终止事件；不要把一次响应当成普通 JSON。会话与聊天 API。对外引用优先走有鉴权的资源代理，不将限时匿名直链写入客户可长期查看的工单。

若只想做“网站问答”演示，可在 WeKnora「发布集成 → 网页嵌入」创建渠道、填真实宿主域名白名单、选安全模式，将小组件嵌入测试站。该组件有独立访问令牌、限流和事件 Webhook，但 Webhook best-effort 且失败不重试；完整客服闭环仍应在 Chatwoot/Whatomate 等收件箱中实现人工接管。网页嵌入文档。

第 4 步｜跨境独立站主线：Chatwoot + 商店订单 + WeKnora

1. 在客户测试环境按 Chatwoot 官方自托管文档安装并创建管理员，确认使用的是社区版可用模块；不要把 Captain AI 当作免费能力。
2. 在 Chatwoot「Settings → Inboxes → Add Inbox」选 Website，填站点域名、欢迎语、工作时间并加入坐席；复制系统生成的 JS 片段放到客户测试站的页面。官方首次网站收件箱教程列有这一步。
3. 在「Settings → Integrations → Webhooks」新建指向自有 BFF 的 HTTPS 回调，只订阅需要的 message_created 和必要的状态事件。BFF 用原始请求体、时间戳与 Webhook secret 计算 HMAC，常量时间比较签名，拒绝过旧时间戳；按 delivery/message ID 幂等，且只处理访客的 incoming 文本，避免机器人回答触发自己。Chatwoot Webhook 官方说明给出签名头和事件类型。
4. BFF 从可信配置映射 Chatwoot account/inbox 到客户租户和允许的 WeKnora KB；不能相信访客自行提交的 tenant ID。先检索知识，再按场景用只读商店凭据查订单/商品。WooCommerce 的 REST v3 Orders可查订单；Webhooks可订阅订单/商品变更并带签名。Shopify 店铺则使用其官方 Webhooks和受权限约束的 Admin API，接口版本单独固定。
5. 初始发布采用“AI 生成私有坐席草稿 → 坐席核实并发送”。草稿中分别展示知识引用、订单字段及“查询时间”；无订单授权时只答一般政策，不查具体订单。客户同意且低风险问题的样本验证通过后，才扩大自动回复范围。
6. 用五类真实测试消息验收：商品政策、冒用订单、物流延迟、超期退款、投诉升级。检查客服能否一键接管、机器人是否停发、知识原文是否可打开。多语种必须分地区抽样检查政策适用性。

WhatsApp 分支：如果主渠道不是网页而是 WhatsApp，可用 Whatomate代替 Chatwoot 的入口；不要为了一个渠道先部署两套收件箱。按官方 Configuration准备生产环境密钥和 HTTPS，在「Settings → Accounts → Add Account」填 Meta Phone Number ID、WABA ID、Access Token、App Secret，并在 Meta 应用中设置 Whatomate 的 GET/POST /api/webhook 回调及相同的 Verify Token。Whatomate Webhooks指出：如果回调缺签名头或账号未配置 App Secret，入站载荷可能被接受而未验证；上线前必须用网关规则和真实回调测试确保只接受可验证的请求。不要用默认管理员账号或默认密码。模板消息、窗口期与活动发送另按 Meta 当前规则审批。

第 5 步｜中国私域主线：IYque-SCRM + WeKnora

1. 先比对 IYque 开源版 README与其商业版功能表，只把开源版可见源码和实际取得企微权限的能力写进客户范围。按其官方开源部署入口在客户隔离环境准备 Spring Boot、数据库、前端及回调域名；部署细节以选定 commit 的文档为准。
2. 由客户企微管理员创建/授权相应自建应用和客服能力，配置合法回调域名、可信 IP、密钥与员工可见范围。会话存档、客户联系、群服务是不同的接口权限，不取得权限就不实现对应场景。先用测试员工与测试客户完成一次消息收发和人工接管。
3. 源码扩展点建议放在 IYqueKfServiceImpl 的“收到文本→判断是否人工接待→检索知识→生成回复”链路。该文件已有人工接待状态和未命中知识时的分支。新增单独的 KnowledgeEvidenceGateway 服务端接口，不把 WeKnora key 写在前端；用员工和客户角色计算允许的 KB 列表，调用 WeKnora 检索，返回片段、来源 ID 和版本。
4. 第一版把检索结果送进“建议回复草稿”界面，销售/客服确认后再调用原有企微发送能力。对于无证据、政策冲突、敏感价目表、投诉/退款，直接转人工。不要简单替换现有 sendAiKfMsg 为“所有消息自动发”，因为已进入人工状态的会话不应继续自动发。
5. 检查源代码里的配置样例和日志：示例凭据全部换成客户密钥；现有 AI 客服处理路径会记录提示词及客户消息，生产改为脱敏、限权和短保留，并避免完整聊天正文进入普通应用日志。对会话分析等功能先确认客户授权与保留期限。
6. 验收：员工 A 看不到员工 B 的客户报价；同一客户切人工后不再收到 AI 回复；撤回的活动规则不再被引用；消息重试不会重复发；离职员工授权及时回收。

若 IYque 的品牌条款或版本能力与客户合同不匹配，可将 OpenSCRM作为 Apache-2.0 的企微业务壳对照，但其 README 未证明完整原生 AI 客服能力，接 WeKnora 的工作量更高。

第 6 步｜制造业/报价主线：WeKnora + ERPNext 或客户现有 ERP

1. 由客户工艺/销售负责人确认商品、物料、BOM、价格表、税费、运费、币种、最低毛利和审批矩阵。ERPNext 的 BOM、Work Order、Quotation是业务对象；已有 ERP 时改接已有对象，不强迫迁移。
2. WeKnora 创建“可外发产品资料”“内部工艺”“报价政策”三个授权范围。对于扫描件、表格多的客户，可按公平对照流程以相同真实文档测试 RAGFlow，只有引用质量和总体运维成本符合 POC 目标才切换。
3. 报价助手表单让销售填写客户、型号、数量、交期、地区、币种和特殊工艺；AI 仅提取未结构化询价中的候选字段。每个字段显示来源和校验状态；缺型号或工艺参数时要求补录，不自动猜。
4. 服务端调用 ERP 的只读接口取得已批准 BOM 版本、库存和成本；Frappe REST API提供按 DocType 的资源读写。报价规则由程序计算：物料/工时/加工/税运/汇率/毛利等各项明细必须可复算，AI 只解释规则和引用合同条款。
5. 生成“报价草稿”供主管检查。使用 ERPNext 时，完成主数据后进入「Selling → Sales → Quotation」新建/审阅，或由服务端经受限 API 创建草稿；最终提交和外发由有权用户完成。记录输入快照、BOM/价目表版本、规则版本、审批人和结果。
6. 验收至少包含：BOM 版本变化、库存不足、成本缺失、汇率过期、含税与未税混用、低于底价、重复询价和跨客户价目表。任何一个高风险用例失败，报价模块只能保留为内部建议工具。

第 7 步｜实现自有 BFF：统一身份、检索与动作

以下接口是建议自行开发的契约，不是 WeKnora、IYque 或 Chatwoot 的现成接口：

POST /v1/assistants/{assistant_id}/responses
Authorization: Bearer <CUSTOMER_USER_TOKEN>
Idempotency-Key: <REQUEST_ID>
Content-Type: application/json

{
  "message": "订单 1234 什么时候到？",
  "context": {"store_id": "store-eu", "conversation_id": "cw-100"}
}

建议响应：answer、citations、facts_as_of、handoff、proposed_actions、trace_id。服务端处理顺序固定：

1. 从已验证的用户/渠道凭据解析客户、角色、门店/店铺；忽略用户文本中的“我是管理员”。
2. 根据助手发布版本取允许的 KB 与工具名单；知识检索前完成租户和文档权限过滤。
3. 若问题涉及订单、客户、BOM、库存、价格，调用只读业务工具并标注读取时间；不能让模型自行构造未获授权的查询。
4. 检索/生成后再次检查引用仍可读、文档未撤回、生效期未过；无证据、冲突或高风险给人工处理。
5. 写动作只返回“待确认计划”；用户确认时重新校验身份、字段、审批和幂等键，然后调用业务系统并保存回执。
6. 审计仅保留必要元数据和脱敏片段，记录模型/知识版本、检索 ID、工具结果、延迟及反馈。

这是现有架构研究的具体落地顺序。服务端 key、模型 key 和外部渠道 token 永远不出现在浏览器或客户会话消息中。

第 8 步｜评估、灰度与交付

按每个场景生成固定的回归表，至少记录：问题、角色、客户/门店、允许的资料、期望答案、是否需转人工、是否允许写入、风险级别。上线前分层检查：

指标阈值应在 POC 开始前由客户和实施方按基线共同确定。WeKnora v0.8.2 的评估 API可计算检索指标，但其任务结果在内存中，重启后可能丢失；客户项目应外部保存评估样本和结果。先灰度一个店铺、一个客服小组或一条产线，观察错误类型，再扩大范围。

客户交付包至少包含：版本与许可证清单、架构/数据流图、账号与密钥移交、知识责任人表、接口字段映射、权限矩阵、评估原始样本与结果、备份恢复和回滚步骤、人工接管流程、费用口径及运维责任。报价可分为一次性实施、行业连接器/模板、持续维护、模型/渠道用量；不要在未测量的情况下承诺“节省 X% 人工”。

常见分叉与排查

推荐实施顺序与取舍

第一个可卖样板建议选 01 多语种商品政策问答或 14 企业制度问答：资料容易整理、业务写入少、可以迅速得到真实问题集。第二个样板选 08 企微销售副驾或 19 报价助手，前提是客户能提供官方接口/ERP 权限和审批人。06、12 的人工接管能力应随第一个客服样板一起完成，不能当作可选锦上添花。03/04/16/18 等高风险场景只有在身份、实时事实和评估过关后才扩。

这 20 个场景共享同一套租户、知识治理、评估和工具策略，但每个客户只有一个主工作台和一个权威业务数据源。可复用的是代码适配器、字段契约、问题集结构和行业模板；客户正文、聊天记录与私有配置不跨客户复制。

一手资料与图片说明

• 知识内核：WeKnora v0.8.2 文档、API、许可证；RAGFlow v0.27.2。
• 独立站：Chatwoot 官方开发文档、Chatwoot 社区版说明、WooCommerce REST v3、Shopify Webhooks、Whatomate 官方文档。
• 企微私域：IYque 官方仓库、IYque 客服源码、OpenSCRM 官方仓库。
• 制造与报价：ERPNext BOM、Quotation、Quality Inspection、Frappe REST API。
• 四张深色 SVG 流程/架构图为本教程原创示意图；六张界面 PNG 复制自 WeKnora v0.8.2 官方文档，已在各图下标明来源。所有图都位于相邻的 tutorial-assets 目录，离线阅读本 Markdown 时请保留该目录。