简述

Shopee 是东南亚最大的电商平台之一，业务覆盖新加坡、马来西亚、印尼、泰国、越南、菲律宾、巴西、智利八个国家与地区。在每一笔订单背后，都有一个官方智能客服机器人 Shopee Chatbot（角色类似淘宝小蜜、京东 JIMI）在处理咨询、催单、退款、物流异常 —— 它服务亿级用户，但真正配置它的，只有 200 人的运营团队。

Smart KB（Smart Knowledge Base）就是这个机器人的「配置后台」。运营人员通过它搭建客服对话流程、设置消息分发规则、定义 AI 介入的边界，是 Shopee 除订单系统外最复杂、改动最频繁的内部工具之一。

而这份记录想说的，其实是这一个判断：

在 AI Agent 看起来能解决一切的 2025 年，我们没有先让 AI 接管一切。
而是先把系统理顺，再让 AI 进入那些重复、耗时、但可以被人校验的工作。

第一期：先把复杂系统变简单。第二期：则是放开 AI，深入应用。

当上百条客服流程长成一张网，“控制台”也困住了运营

一、项目背景

1. 业务定位：智能客服的“控制台”

Smart KB 决定 Shopee 客服机器人说什么、何时说、下一步做什么。客服流程调整、促销话术上线和政策变更后的全链路同步，都要在这里完成。一个节点配错，可能影响一个国家的客服体验。

2. 体验现状：系统越长越大，维护越来越难

Smart KB 长期通过增加功能响应业务，最终变成了一张越来越难维护的流程网：

30+ 步，配置一个优惠券业务逻辑；
100+ 条 workflow，政策变化后需要一个一个手动更新，手都要断了；
2 个月，新人才能搞明白这套配置系统。

后台的复杂，最终出现在用户的每一次对话里：

每月 3,000+ 条意图识别错误相关差评；
每月 11,000+ 条“回答了，却没解决问题”的反馈。

而这是 chatbot配置后台最开始的样子

二、定义方向 —— 一个反直觉的判断

2025 年初，整个互联网行业都在做一件事：把现有产品改造成 AI Agent 形态。我们的项目从那年3月启动。我们面前有两条路：

1.「让 AI 接管」—— 用户用自然语言描述意图，AI 自动生成完整流程。市面上已经有团队在跑（最典型的是通义晓蜜），路径听起来更快、demo 也更好看。

2.「Workflow + 部分 AI」—— 保留可控的工作流结构，AI 仅在限定边界内辅助，让运营保留对每个节点的判断权。这条路看起来更"老派"，但争议也更小。

我们选择保留 workflow，不是因为更保守，而是一次 user shadowing 让我们发现：

Febby 维护着 50+ 条 workflow。她每天只有 1–2 小时搭建新流程，剩下 7 小时都在处理报错和同步政策。

每天 5–10 次：客服报错，要求 30 分钟内定位并解决
每周 2–3 次：政策变化，需要当天更新上百条流程

她真正需要是：

出错时，快速定位并修复 ; 政策变更时，改一次、全局同步

而只要有任何资损或者事故，她就有可能随时走人。

三、设计思路

判断定下来之后，第一期的目标就清晰了：让运营用户把现有的 Smart KB 简单高效的用起来。

我们梳理了历史用户反馈，并对中国、台湾、印尼、巴西四个区域的运营做了访谈与设计走查，归集出 100+ 条 Pain Point，收敛为三类核心问题：

1. 看不懂 —— "画布节点上百，找不到自己在哪、不知道下一步要点哪里"； —— 来自 CN/ID/TW，频次最高。

2.改的慢 ——"改一次政策要在 50+ workflow 里搜 100 次、点 100 次；连一个按钮、一张卡片都要 scroll 半天才能找到"； —— 来自 ID/BR，"政策更新"和"日常配置"两个场景。

3.验不全 —— "测试用例靠手动造数据，很多边界 case 上线前根本没覆盖"。—— 来自 ID，"上线前测试"环节。

结合用户原声回到用户真实配置过程，我们逐渐看清：无论处理哪个flow，都绕不开三件事——先看懂，再修改，最后验证。

前两步比较直接；而最后的“确认”，其实包含两层：先从用户视角看看最终效果，再用测试数据验收。

于是，我们顺着用户的工作节奏，一步步把这条链路理顺：先看清画布，再复用规则；先预览结果，再让 AI 帮忙验证。

四、设计方案

1.流程一眼看懂：让复杂画布体验看得懂、找得到、操作得顺

Before

找不到当前位置：节点过多，用户很难判断自己当前在什么位置；
理不清上下游关系：上下游关系不明显，用户找不到操作焦点；
画布操作不跟手：画布交互主要基于鼠标滚轮设计，但真实场景中用户经常使用触控板，缩放、拖拽、定位都不够顺手。

After

看得懂自己在哪——当前位置可感知：点开一个节点，它和上下游路径会一起亮起来。这条逻辑从哪来、往哪去，一眼就能看清；
打乱也能找回来——布局自动归位：连线从直角线调整为更易追踪的曲线，再加上一键整理，画布拖乱了，也能马上恢复；
只看当前关注的路径——复杂分支，按需收起：暂时用不到的分支可以先收起来，不再让无关节点塞满整个画布；
不用鼠标，也能顺畅操作——支持多模态交互：缩放、平移和拖拽都适配了触控板，只用笔记本也能自然操作。

当客服流程长成一张网，
原有的工作流又该如何重构？

Shopee Chatbot（类似淘宝小蜜、京东 JIMI）服务东南亚及拉美八个市场的亿级用户，处理咨询、催单、退款与物流异常，但真正配置它的只有约 200 名运营人员。Smart KB 是它的配置后台，用于搭建对话流程、设置消息规则与 AI 介入边界，也是 Shopee 最复杂、变化最频繁的内部工具之一。

2025.03—2025.09客服工作流设计知识库产品设计AI验证

Smart KB · 客服流程配置

项目背景

功能更多了，人怎么更累了？

CONTEXT

流程长成一张网，也困住了运营

Smart KB 决定着客服机器人说什么、何时说、下一步做什么。促销话术上线、政策变更后的流程同步，都要在这里完成。一个节点配错，就可能影响一个市场的客服体验。

业务一直往前走，系统也不断加功能，最后长成了一张越来越难维护的流程网：

30+ 步，才能配置好一个优惠券业务逻辑；
100+ 条 Workflow，政策一变，就得一个一个手动更新，手都要断了；
约 2 个月，新人才能搞明白这套系统。

同一时期，每月还有 3,000+ 条意图识别错误相关差评，以及 11,000+ 条“回答了，却没解决问题”的反馈。

改造前的配置后台

关键判断

比起 AI，他们更着急什么？

DIRECTION

我们为什么没有急着让 AI 接管

2025 年 3 月，项目启动。让 AI 直接生成完整流程，看起来更快，演示也更好看；保留 Workflow、让 AI 辅助部分工作，则显得有些“老派”。我们带着这两条路线，去看了运营真实的一天。

跟着运营 Febby 工作，我们才发现：她维护着 50+ 条 Workflow，每天只有 1–2 小时搭建新流程，剩下约 7 小时，都在处理报错和同步政策。

每天 5–10 次客服报错，30 分钟内就得定位并解决；
每周 2–3 次政策调整，当天就要改完上线。

她最着急的，是出错了赶紧找到问题，政策变了能一次改完。跟着她工作后，我们的判断清楚了：第一期先把系统理顺，再让 AI 进入那些重复、耗时、能被人核对的工作。

我们访谈了中国、台湾、印尼、巴西四个区域的运营，再对照历史反馈和设计走查，100+ 条问题慢慢指向同样的困扰：看不懂、改得慢、验不全。

回到他们的工作，无论哪条流程，都绕不开“先看懂，再修改，最后验证”。于是，我们顺着这个节奏：先看清画布，再复用规则；先预览结果，再让 AI 帮忙验证。

设计方案

每天费劲的事，能省下来吗？

DESIGN

顺着运营的工作，一步步把流程理顺

画布再复杂，也能找到自己在哪

画布节点上百，点进去却不知道自己在哪、下一步该看哪条线。更别扭的是，运营常用笔记本触控板，原来的缩放和拖拽却围绕鼠标设计，操作起来并不顺手。

看清路径：点开节点，上下游一起亮起来，逻辑从哪来、往哪去都能看清；
找回布局：曲线连线更好追踪，画布拖乱了也能一键归位；
收起分支：暂时不看的链路先折起来，眼前只留需要关注的部分；
操作跟手：缩放、平移、拖拽都适配触控板，只用笔记本也能顺畅操作。

改一次规则，让上百条流程一起更新

政策只是把“延迟 3 天赔付”改成“延迟 5 天”，运营却要在 100+ 条 Workflow 里逐一寻找同一套逻辑。一套赔付规则有 30+ 步，一轮更新往往要花 1–2 周，还容易漏改。

这让我想到 Figma 的 Component：规则能不能也只改一次？于是，我们把重复的赔付判断做成“规则组件”。政策变化时改一个组件，引用它的 Workflow 就能一起更新。

我们也带着方案找了印尼、巴西、台湾的运营，对照他们各自的配置场景，检查这套思路是否适用。

写什么，就能看到用户收到什么

用户看到的只是一张退款进度卡，运营却像在蒙着眼拼卡片：填完长表单，仍不知道最后长什么样。我们甚至遇到过一张退款 Timeline，时间顺序配错，直到用户给了差评才发现。

这次，我们让编辑内容直接呈现为用户会收到的消息样式，常用卡片也可以选中即用。发布前，运营终于可以先替用户看一遍：回复对不对，卡片和节点顺序有没有问题。

找数据交给 AI，答案对不对留给人

运营本来只想确认：出来的答案对不对？可测试一条催单赔付流程，得先跨 2 个系统、走 6 个步骤、做 30+ 次操作，把订单、用户等数据找齐再搬回来。

Febby 说得很直接：

“数据太多了，太复杂了，我有时候就直接 skip。”Febby · 运营用户

所以，我们让 AI 根据节点条件和历史案例匹配测试数据，把找数据、搬数据的工夫省下来。运营可以把注意力放回真正关心的事：这次模拟运行，答案对不对？

验证与迭代

省了操作，能让人放心吗？

VALIDATION

最后一道关：让运营敢用、放心用

这次改造牵着多个市场的客服流程，一处逻辑偏差就可能沿着整条链路放大。上线前，我们还需要确认：运营能不能看懂、敢不敢用，能不能在出错前发现问题？

我和产品一起找来 5 位有 2 年以上配置经验的运营，用真实案例完整跑一遍新系统。

“不用手动找了真好。”Rika 的反应很直接。5 位运营都对 AI Autofill 感兴趣，但也有顾虑：Alin 想“先搞懂它怎么运作”，Nadya 则说“我会用，但数据必须准”。

我低估了这份顾虑：把工作交给 AI，运营仍然要对答案负责。他们需要看得懂过程、核对得了结果。所以，我补了两处设计：

看得见它怎么做：先选择测试分支，再由 AI 补齐数据；画布同步展示执行路径与各节点结果。
结果自己确认：运营核对模拟运行的答案，也能把确认过的数据存成 Test Case，下次继续用。

上线结果

忙了半年，他们轻松些了吗？

OUTCOMES

2025 年 9 月，新版本上线

近半年的设计与落地后，新版本在 2025 年 9 月上线。我们回头看了几件事：配置要花多久，新人多久能上手，运营每天投入多少时间，以及新加坡市场的用户是否更满意。

配置时间对比采用线上数据与可用性测试数据；新人上手情况来自印尼区域，其余业务指标为上线后五个月的对比。

下一步

流程顺了，还能帮他们什么？

WHAT’S NEXT

系统理顺之后，我开始想下一步

这半年，我们梳理了意图识别、Workflow 和基础 API，也让原本散落各处、依赖人工经验的知识，逐渐变得可调用、可管理。

做到这里，我开始想：知识已经积累起来，能不能让创建更省力、质检更主动，也让它们在使用中持续变好？这是我继续探索 AI 知识运营助手的起点。

下一段探索：Smart KB · AI 助手

2.让规则可复用：改一次，100+ 条 workflow 自动同步

Before

Smart KB 中存在大量重复的规则配置。

以赔付券为例：“订单延迟超过 3 天补偿 5 美元，超过 7 天补偿 10 美元”, 配置一次需要完成 30+ 步。当政策从“超过 3 天”改为“超过 5 天”时，运营还要进入 100+ 条 workflow，逐一寻找并修改同一套逻辑。（一次更新通常需要 1–2 周，也很容易出现漏改和版本不一致）

After

巧了，这不是和figma里的component很像嘛，当我们定义好组件，只要轻轻改一下组件，全部页面都可以调整好了。

于是，我们把重复出现的赔付判断，封装成 Figma Component 一样的“规则组件”。

运营在 workflow 中只需选择并调用即可。政策变化时，只需要修改一次“组件”，所有引用它的 workflow 都会自动同步最新规则。

（当时“组件“方案我们还速速找了 ID，BR，TW 区域用户做了一下mapping，果不其然，BR 用户大为称赞）

3.让结果可预览：所见即所得

Before

用户看到的是一张一目了然的退款进度卡，运营面对的，却是一张仿佛填不到头的长表单。

文案、按钮、日期、时间节点、变量字段……所有内容都要逐项填写，却看不到它们最终出现在用户面前的样子。整个过程就像蒙着眼拼卡片：漏了什么、顺序对不对，往往要到上线后才知道。我们甚至遇到过一张退款 Timeline，因为时间顺序配错，直到收到用户差评才被发现。

（同样还有催单卡片、优惠券卡片、充值提现卡片等等，全都要填这种“看不到头的”大表单）

After

写什么，就看到什么：内容直接以用户收到的消息样式呈现；
常用卡片，选中即用：退款 Timeline、催单等卡片选择就好，无需从头搭建；
发布前，先替用户看一遍：完整预览最终回复、卡片和节点顺序，再也不用摸黑搭建了。

4.让验证自动化：找数据交给 AI，验证答案留给用户

Before

测试一条催单赔付流程，运营本来只想确认：出来的答案对不对？

但在看到答案之前，她要先确定业务类型，再切到客服系统寻找历史 Case，翻页筛选合适的数据，复制 Case ID、Order ID、Shop ID 和 User ID巴拉巴拉一堆，最后逐项粘贴回 Smart KB。2 个系统、6 个步骤、30+ 次操作，时间都花在了找数据和搬数据上。

Febby 说得很直接：“数据太多了，太复杂了，我有时候就直接 skip。”

After

AI 自动推荐测试数据：系统根据当前节点条件和历史 case，自动匹配合适的测试数据；
人保留最终判断：AI 负责准备数据，配置者只需要判断 simulation 结果是否符合预期。

最最后一道关：不仅要能用，还要值得信任

这是一次近 1000 人日、跨区域、强依赖的系统改造。它连接 Chatbot 主流程与多个市场的配置工作，一处逻辑偏差，就可能沿着整条链路放大。所以，我们最后验证的不只是“功能能不能跑”，而是：运营能不能看懂、敢不敢使用，并在出错前发现问题。

因此，我和产品一起组织了一场跨区域 usability testing。5 名资深运营，均 2 年以上配置经验，用真实 case 在模拟场景里完整跑一遍新系统。

测试里最关键的一点: 5 位资深运营都对 AI Autofill 数据表现出兴趣,没有人抗拒。但他们的接受是有条件的。

Rika 直接说「不用手动找了真好」;

但 Alin 的态度更典型——他习惯手动录入，愿意用 autofill，前提是「先搞懂它怎么运作」;

Nadya 则补了一句「我会用,但数据必须准」。

这暴露出一个我原本低估的问题:对资深用户来说，AI 帮不帮他们做事不是关键,关键是它的过程是否看得见，结果是否可以核对。

所以我在方案里补了两处回应:

过程看得见：先选择测试分支，再由 AI 补齐数据；执行路径与每个节点的结果都会显示在画布上。
结果由人确认：AI 匹配真实测试数据，运营负责核对，也可以把确认过的数据保存为 Test Case 复用。

上线结果

经过近半年的设计与落地，我们的改版项目于 2025 年 9 月正式上线。

上线后，新版本在配置效率、学习成本、运营投入和用户满意度上都获得了明显提升，也验证了前期围绕 Workflow 配置体验与知识库结构化管理的设计方向。

Next Step

在完成整个配置后台的核心体验改版中，我们用了半年多时间进一步梳理系统底层能力，包括用户意图识别、解决方案配置 Workflow，以及基础 API 的建设。

这一阶段的重点，是将原本分散、依赖人工经验维护的知识内容，转化为可被系统理解、调用和管理的结构化资产。随着知识库的数据基础逐渐成型，项目的核心问题也发生了变化：
相比较与如何沉淀更多知识，如何让知识被更高效地创建、更主动地质检，并在真实使用中持续优化更为重要。因此，在下一阶段，我将设计方向从“知识库管理工具”进一步推进到 ”AI 增强的知识运营助手“的搭建。欢迎查看