25 分钟，16 页，讲完立刻被拆解

这是全场第一个登台的一场。台下坐着 8 位观察团嘉宾——海亮科服 CDO、顺丰 AI 平台负责人、vivo 互联网研发总监、乐凯撒 CTO、货拉拉高级 AI 与大数据架构师。没有一位是来听概念普及的。

16 页讲义（全部收录）

我的读后感 · 六条

1. 讲义讲的是全球 AI 智能客服平台的业务与技术架构，以及演进中碰到的四类问题和解法。
2. 更值得学的是架构师的系统思维：先定义问题，再分析，最后解决。例：选 NATS，是因为做 IM 订阅有完善 SDK——参数是及格线，工程成本才是决策线。
3. 技术问题解决模型
   定义（问题与关联部分、操作步骤）→ 分析（原因、验证方法、优先级）→ 解决（按优先级投入、迭代验证）。
4. 换掉前提条件，这些解法会失效；问题定义不清，解法更无从谈起。
5. 技术问题被解决 → 系统功能正常 → 客户满意 → 业务增长。
6. 下次遇到问题，先走一遍模型再动手——方向错了，努力本身就是成本。

延伸思考

客服 AI 的计费正从「按席位」转向「按结果付费」

（该模式增速 89%，AI 单次解决成本约 0.62 美元，人工约 7.40 美元）。所以 P12 那十条机制不只是可靠性设计：状态机决定工单归属、幂等决定不重复计费、审计决定结算有据——结果付费是技术命题，不只是商务条款。

观察团点评：两条最值钱的批评

点评意见 01「内容太多，容易让听众失去焦点。」台上摊开 16 页、十几个问题点，最后被反复追问的却只有 NATS 选型一条——讲得最多的没被记住，被追问的是我原本只打算一笔带过的细节。

点评意见 02「过程中要跟观众互动、采集反馈，据此调整焦点。」25 分钟没设任何检查点，等于用开讲前五分钟的判断赌掉整场。而采集，必须发生在还能改的时候。

两条合起来是一句话：我按「我知道什么」排了内容，而不是按「听众能带走什么」排内容。

如果重讲一次：三步走

第一步 · 定义｜内容做减法先定「听众只能带走的一句话」，再决定讲什么。16 页压到 1 条主线 + 3 个案例，其余降级为答疑材料。

第二步 · 分析｜过程做互动第 4 分钟举手表决「最想细看哪一类」，第 15 分钟按票数重排时间。两个检查点合计 60 秒。

第三步 · 解决｜结果做迭代点评与答疑分「内容 / 表达 / 结构」三类存档，下一版只改优先级最高的一处，下一场用同一检查点验证。

如果把这场分享压缩成一句话：

把一个 AI 客服做好，考验的是模型能力；
把一千个 AI 客服做好，考验的是系统工程与商业设计。

李福春

资深软件架构师 · 腾讯云架构师深圳同盟

长期负责多租户 AI 智能客服平台架构设计与全球化交付，服务 1000+ toB 客户、3000+ 项目空间。