帕累托 8:2 — 机器人卸下 80% 的重复执行
把客服咨询按类型统计，种类有几十种，但实际来量集中在少数几类。账号标识查询、登录与邮箱变更、简单状态确认等定型咨询占了来件的大部分。按类型数只有 20%，工作量上却吃掉 80%，这是典型的帕累托 8:2。
这 20% 的类型答案早已确定，查一次运营数据库就完事。它是人没理由反复做、却又最耗时的工作。所以自动化的第一目标就在这里。AI 客服机器人卸下的正是这 80% 的重复执行。
关键在于区分类型与件数。类型多并不意味着难以自动化，只把件数集中的少数类型交出去，就能大幅减轻人的负担。所以挑选自动化对象时，看的不是'最难的咨询'，而是'最常重复、答案已定'的咨询。
客服机器人如何处理重复咨询
我们在一家药店软件公司的客服运营中跑了这套结构。客服在内部即时通讯频道呼叫机器人，机器人便查询运营数据库并附上依据回复。比如问某家药店的账号 ID，它就查出来告诉你；收到变更注册邮箱的请求，它会识别账号、确认是否可变更，再指引流程或直接处理。
关键有两点。第一，敏感变更须经人工确认，而简单查询与指引则自动完成。第二，每条答复都标注所查依据，以此控制幻觉。可信不是因为机器人聪明，而是因为它所参考的数据准确、答复带有依据。
看实际界面，流程很清楚。客服 @ 机器人询问药店账号，机器人便在运营数据库里找到账号并附依据回答。遇到要变更注册邮箱的请求，它会识别账号，用营业执照号与药店名缩小范围找到确切账号，尝试变更并复核结果——把人原本要做的查询、比对、确认逐步走了一遍。
下一步 — AI 自主规划并开发新服务
卸下重复执行之后，是规划与开发。AI 监测领域社区的帖子，按周分析，并就有哪些议题、哪些未满足需求反复出现整理成简报。它不止步于此：把反复出现的需求自动规划成新服务或新功能，登记为 JIRA 议题。
接下来是开发。对于人判定为 Go 的议题，AI 自动开发并执行 E2E 测试。也就是说，'做什么'的发掘与规划，以及'怎么做'的实现与验证，都移交给了机器一侧。这套结构目前正在 SH Consulting 构建中。
简报不只是摘要。它把反复出现的抱怨与变通请求汇成'机会'项，当同一需求超过一定频率，就把它升格为新功能或新服务候选。不必重新做市场调研，而是把社区里已经堆积的声音，直接接入产品待办列表作为输入。
人只在两处做判断 — HITL
在这条流水线里，人介入的点正好两个。第一是两周冲刺会议上的 Go/Stop 决定：在 AI 登记的规划议题中，由人挑选实际要做什么。第二是开发完成后的功能测试：人对通过 E2E 的成果做最后验收，决定是否上线。
这两个点并非偶然。定方向（做什么）与对上线质量负责（是否上线），是必须由人承担的判断。而其间的重复劳动——监测、分析、写规划、编码、写测试——交给机器。这就是 Human In The Loop（HITL）的设计原则。
两道闸门性质不同。前面的 Go/Stop 是方向的判断——值不值得做；后面的功能测试是质量与责任的判断——能不能就这样发给用户。一个把守入口，一个把守出口，中间的执行全归机器。
为何是 HITL 而非完全自动
完全自动化的风险，是把错误方向又快又大量地造出来。把定方向和上线决定交给机器，一旦出错，回退成本就会变大。两道人工闸门正好吸收这份风险。不是 AI 自己扼杀坏点子，而是人用 Go/Stop 来筛选。
越是把工作交给 AI——从执行（客服机器人）到规划与开发（自主流水线）——人的工作就越收敛到两个判断点。AX 指向的，不是把人挤出流水线，而是把从重复中解放出来的人，恰好留在需要判断的位置。
这套结构最终改变的是人的角色。人不再处理重复执行，而是把时间花在决定做什么、并对产出负责的判断上。如果 AX 的目标不是取代人，而是让组织自我进化，那么 HITL 就是把这个目标作为结构刻进自动化流水线的方法。