那么在现在系统中真正拖住他们的,是这三件事——
1. 问题总是出现了才知道
过去，一个错误要被看见，得走完一整条链：一线客服在群里陆续踩到 → 汇总上报 → 运营回头定位 → 修复 → 重新上线。等这条链走完，客户早就骂完了。
2. 搭建一个 Workflow，累到怀疑人生
一份政策文档发下来，运营得先啃懂里面的处理流程，然后一个框一个框地画、一根线一根线地连。费时、费力、还烧脑，一个流程就是一整天。
3. 规则只改两个数字，却要到处找
物流延迟从 3 天改成 2 天，赔付从 5 块调到 10 块，看起来只改两个数字，运营却得一个地方一个地方地找、逐处修改，漏掉一处就可能出错。
设计方向
怎样让运营少一点忙乱，多一点从容？
设计方向：让 AI 当“同事”重活交给它，决定留给你
三个问题本质都是同一个问题：我们现在的用户干了太多重复的、dirty的脏活累活。
那么我们能不能利用 AI，让它负责那些重复却占大量时间的工作，什么盯异常、巡流程、整理资料、生成草稿的脏活累活全 cover 掉，我们人只负责更重要的判断。
于是，我们开始设计 AI Assistant。
更主动
能不能在客户抱怨前，先看见问题？
一、更主动：问题扩大前，AI 先来“汇报”
过去，我们的运营用户像巡楼一样，一条条翻Workflow，在各种群关注反馈。可真正的问题，往往要等到指标下滑、用户开始投诉，才被看到。
现在，AI Assistant 先替运营盯指标、巡流程。一有异常，它就带着证据和优先级来找你。AI 负责发现和排序，用户来负责核验与处理就好。
（举例: 泰国 Songkran泼水节 快到了，但是Workflow 里却还停在常规的“下单 1-3 天就到”。用户下单前反复追问“节日前到底能不能到？着急！”，机器人答不准，只能转人工。等运营发现时，人工咨询已经堆起来，Deflection Rate 也开始有下滑苗头。)
更省力
第一稿，让运营不用再从零开始。
二、更省力：政策一交，初稿到手
比起之前的一份政策文档发下来,运营得先啃懂里面的处理流程,然后一个框一个框地画、一根线一根线地连。费时、费力、还烧脑。
现在当运营有了一些 workflow 初步构想草案时，他可以直接把内容交给 AI Assistant。
AI会根据内容通过聊天的方式，提取场景、规则、条件和回复，再生成一条可编辑的 Workflow 草稿。用户再也不用从空白画布一个框一个框地画，而是把时间花在确认关键规则和调整流程上，妥妥释放人力！
更省心
只改两个数字，能不能少一点提心吊胆？
三、更省心：规则一改，引用全找齐
我们再看最后一个场景。
当印尼市场因为 9.9 大促活动，更新了物流延迟赔付政策：延迟超过 3 天改为超过 2 天，赔付金额也从 5 美元调整为 10 美元。（这是非常频繁且常见的事情）
听起来只是改两个数字，真正动手却像一场“全系统寻人”。同一条规则散落在 Function、Workflow 和不同版本里。过去，运营只能一个个搜索改“组件”、一个个核对。规则改起来不难，难的是谁也不敢保证自己没有漏。
这次，运营只需要对 KMS Assistant 说：“物流延迟超过 2 天即可赔付，赔付金额调整为 10 美元，同步相关 Function 和 Workflow。”
AI 直接进行全维度无死角的查询修改，改好报给我们用户。
回到最开始
回到最开始:AI 到底扮演什么角色
前面三个 case 做下来，其实都在解决一件事：用户太多时间花在找问题、翻流程和补规则上。
这些事不难，但特别磨人，也最怕漏。
所以我不想把 AI Assistant 做成一个等人提问的聊天框。它会自己盯着指标和流程，发现问题就带着证据来；收到新政策，先把初稿搭好；规则有变化，就能定位到所有的规则。
至于改不改、什么时候发布，还是用户说了算。
一些思考
AI 多做一步，人怎样依然心里有底？
一些思考
结果怎么样？
上线之后,我最在意的不是大盘数字好不好看,而是两件更能说明问题的事——AI 推的东西,人愿不愿意处理;同样的活,AI 比人少花了多少时间。
第一件事,答案是 100%。AI 每个月主动推给运营的问题不到 10 条,覆盖 8 个市场。但这不到 10 条,运营全部都跟进处理了。推得少,却条条值得处理——这比"推了很多"更能说明问题:它没有变成噪音,而是真的成了一份可信的"汇报"。
第二件事,答案是从大半天变成 15 分钟。过去搭一条 Workflow,运营得先啃完政策文档,再一个框一个框地画、一根线一根线地连,一整天就没了。现在把文件丢给 AI,大约 15 分钟就能拿到一版可编辑的初稿;规则变了,也能由 AI 统一去调数据关联、变量和节点。人不再拼装,只做判断。
AI 越主动,人的「控制感」越要被设计出来
主动、生成、批量修改,这三件事都让 AI 更强。但强的另一面,是打扰、越权和不可逆。所以在做的过程中,我给它划了三条边界。
第一条,什么才配打断人。主动不等于什么都报。影响整体流程、波及面大的问题——比如某条流程的 Deflection Rate 明显下滑——才值得主动弹到用户面前;而文案措辞、局部小逻辑这类,沉淀进检查列表就好,不打扰。
第二条,谁来拍板。AI 负责理解、抽取、生成低保真草稿,比如从一份 PDF 直接生成 Workflow 初版。但关键规则的确认、二次加工和最终定稿,一定要留给人来做校验。
第三条,错了怎么退回去。不追求 AI 永远正确,而是保证"哪怕它错了,人也能随时退回去"。我们的 Workflow 自带版本历史,可以一键回滚到任意版本;AI 的每一步操作和对话也全程留痕、可追溯。
越想让 AI 帮你画,越要先把组件库立起来
这个项目我没有停在"画完 Demo",而是把整套界面沉淀成了一套可被 AI 直接调用的组件库——基础层是颜色 Token、basic 组件;业务层是 AI 对话组件和画布组件。某种程度上,这件事很像一个自我印证:这个项目主张让 AI 替运营干脏活,而我自己,也在让 AI 替设计师干拼装的脏活。它在三个地方帮到了我:
1.改小需求的时候快。 在一条很大的 Flow 里做调整、加组件,不用从零画——输入一段自然语言,调用组件库,秒级拼出界面,十几类组件反复复用。
2.做 0→1 的时候更真。 我能产出最接近真实用户状态的流程。给用户看的时候,他们是从"成品"的角度体验功能,而不是"demo"的角度——反馈因此更具体、更落地。
3.交付的时候稳。 交付给开发的是一个没有真实数据、但有真实权重和交互行为的分支页面。还原有据可依,设计与实现之间的走样少了很多。
