# 【运营】AI 重塑客服管理：滴滴出海14 国实战 > **合规声明（生成式 AI 服务）**：前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。 > > **完整资料：如果想了解更多内容可以访问:https://events.amazoncloud.cn/china-summit-on-demand/ > > **免责声明**：本摘要仅为便于您了解峰会内容而提供，我们不对其完整性及准确性作出任何保证，且不构成任何建议或结论。相关内容仅供参考，实际内容以峰会回放视频为准。 ## 一、基础信息 - **会议类型**：专题演讲 - **Persona**：通用业务用户 - **时间信息**：6月24日 | 13:30 - 14:00 - **标题**：【运营】AI 重塑客服管理：滴滴出海14 国实战 - **PDF 资料**：有 - **视频回放**：有 ## 演讲人信息 ### 会议信息 - **地点**：上海世博中心（2026 亚马逊云科技中国峰会） - **日期**：2026年6月24日（Day 2） - **时间**：13:30 - 14:00 - **会议类型**：专题演讲 - **面向 Persona**：通用业务用户 ### 亚马逊云科技演讲人 - **张欣蕊**：产品经理 ### 客户 / 合作伙伴演讲人 - **Raphael Hua**（滴滴）：滴滴国际化事业部 ## 二、会议资料 PDF 转录内容 --- Page 1 --- 2026年6月23日-24日 上海·世博中心 --- Page 2 --- AI 无处不在：打造令人难忘的客户 交互体验 Laura 张欣蕊 Amazon Connect 中国区产品经理 亚马逊云科技 --- Page 3 --- 关键 的客户会因一次不佳体验， 就放弃与曾经喜爱的品牌继续合作 --- Page 4 --- 快速响应 全渠道触点 贴合需求 任何规模 合法合规 主动服务 体验一致个性定制 稳定运行 快速部署 --- Page 5 --- Connect Customer 全球覆盖 Amazon Connect 在全球 11 个区域实现部署 覆盖 110 个国家的呼入，以及 230 个国家的呼出 区域 美国东部（弗吉尼亚北部） 美国西部（俄勒冈） 非洲（开普敦） 亚太地区（首尔） 亚太地区（新加坡） 澳新地区（悉尼） 亚太地区（东京） 加拿大（中部） 欧洲（法兰克福） 欧洲（伦敦） GovCloud（美国西部） --- Page 6 --- 自助服务 人工坐席 语音 | 消息 | 网页 AI Agent 工作区 | 指南 | 工单 编排 流程 | IVR 与对话式界面 | Agent 设计器 | 开箱即用 Agent | 营销活动 | 任务 分析与可观察性 对话分析 | Agent 性能 | 预测、容量规划与计划 | 端到端沟通历史 | 测试与模拟 | 分析数据湖 沟通渠道 语音 | 聊天 | 邮件 | 短信 | 应用内 | 社交媒体 知识与数据 客户画像 | 企业级工具 | 记录系统 --- Page 7 --- 与我们携手加速创新进程 Connect Customerwith Unlimited AI 大语言模型提升 全球语音与 短信；应用内、网页 电子邮件、 准确率，覆盖： 沟通渠道 电话 聊 通 天 信 任务管理 声纹实时身份验证 外 全 呼 球 营 业 销 务 活 韧 动 性 与 及 人 视 工 频 智； 能 基 的 于 自 生 助 成 服 式 务 W 消 ha 息 ts、 Ap A p p p 商 le 业 自 应 助 用 服 内 务 功、 能 商业信息 与邮件优化 Connect AI agent, Connect AI Agent 多 Agent 协作： 座席赋能 A 控 ge 制 nt 面 沟 板 通 客 统 户 一 档 的 案 Agent 辅助 A 案 ge 例 nt 管 工 理 作 和 区 详细指南与客户档案 推荐详细指南， 基于客户沟通数据 数据映射 并支持第三方应用 创建/优化 AI Agent 数据分析、 Agent 评估与计划 业务洞察、 历史数据 实时 高级报告 Agent 预测与计划 Agent 评估、 自定义数据大屏、 能力升级， 分析 语音分析 屏幕录制与分析数据湖 客户沟通摘要与自动 对话分析新增 流程优化 化 Agent 评估 34 种语言 200+ 项新功能 201 项新功能 171 项新功能 117 项新功能 88 项新功能 14、24 和 33 项 38 项新功能 新功能 颠覆传统 长远布局 行业领军 2017、2018、2019 2020 2021 2022 2023 2024 2025 --- Page 8 --- 利用亚马逊云科技呼叫中心加速客户体验创新 Amazon Connect Customer 核心优势概览 拓展全球安全合规 AI 原生，赋能的每一次交互 带来真实的业务成果 Amazon Connect 能快速扩展到 电信线路齐全 部署快 利用流程中心数据分析和洞察 成千上万坐席规模 加速创新 不断优化运营 按使用量付费，无需签订合同、无需预付费或承诺用量 高可用的全球电话服务： 40 家下游运营商，+110 个呼入国家和地区，+230 个呼出国家和地区 能与 200 多项亚马逊云科技服务集成使用 --- Page 9 --- 灵活的 AI Agentic AI 传统机器学习 人工辅助 --- Page 10 --- 协作 --- Page 11 --- 演示 --- Page 13 --- Connect Customer 拥有数以万计的客户，每天支持超过 1600 万次交互。 --- Page 14 --- AI 重塑客服管理：滴滴出海 14 国实战 和亚马逊云科技一起搭建客服 AI 质检系统 滴滴国际化 · 客服质检自研之路 Raphael Hua 朱子琦 客户智能洞察总监 深度学习架构师 滴滴国际化事业部 亚马逊云科技生成式人工智能创新中心 --- Page 15 --- 亚马逊云科技生成式人工智能创新中心 致力于协助客户加速生成式人工智能转型及商业价值实现——通过快速构建、 部署、优化运营生成式人工智能解决方案驱动突破性创新。 我们能帮助您 500+ 1000+ 识别高价值应用场景并排定优先级 全球范围 1 客户合作经验 对齐人工智能技术与商业价值产出 生成式人工智能专家 提供生成式人工智能专业指导与最佳实践 2 架构搭建、模型选择、优化等 >70% 45 最短 构建并部署生产级别的生成式人工智能解决方案 3 科学家动手支持您从原型开发到生产 项目最终部署到生产 天完成原型到生产 辅助生产环境中的规模扩展与优化 4 MLOps、模型可解释性、成本优化等 * 在 2025 年，超过 70% 的生成式 AI IC 客户项目被部署到生产环 境中，部分项目短至 45 天内即完成上线。 --- Page 16 --- 多语言质检从数小时缩短到几分钟，实现更高准确率 挑战 滴滴的国际业务覆盖了拉美、亚太和非洲的14个国家，为当地市场提供以出行 为主、涵盖外卖和金融等多样化服务。他们希望用一套透明、可控的方案替换 原有的第三方质检系统，规模化处理多语言合规质检，并主动发现趋势。 解决方案 滴滴携手 Amazon 生成式 AI 创新中心，在 Amazon Bedrock 上构建了一套 智能质检系统，包含三条核心流水线：意图流水线校验客服标注的用户进线 原因；评估流水线通过动态变量注入，在单次 LLM 调用中完成全部质检项； VOC 流水线通过并行抽取与语义聚类实现批量分析。 多语言多业务线智能客服质检 成果 特性 滴滴在西班牙语和葡萄牙语客服场景中实现 o 进线原因验证准确率从38% 提升至86% o Amazon 服务： 90%+ 的合规打分准确率，并将耗时数小时 o 合规打分准确率达到90%+ - Amazon Bedrock 的业务趋势分析压缩到几分钟。 o VOC 分析从数小时缩短至几分钟 --- Page 18 --- 滴滴 IBG · 服务海外上亿用户 2018 从巴西起步，一路走到拉美、亚太、非洲 业务布局 3 14 → 1亿+ 1300万+ 800万+ 条业务线 年活跃用户 日均单量 · 2025 Q4 年活跃司机骑手个国家 出行 · 外卖 · 金融 客户体验团队 —— 连接公司与用户的窗口：服务好坏，用户最先感知，直接关系信任与品牌 --- Page 19 --- 人工抽检，3 个瓶颈 管理靠定期、定量地抽检工单、逐条分析 ——体量一大，光靠人工越来越吃力。 慢 不稳 看得少 抽检本身就滞后 理解有差异，影响对业务的判断 受成本限制，无法大规模铺开 于是，我们开始和 Amazon 一起，用 AI 来破局。 --- Page 20 --- 一套系统，回答两个问题 运营团队 交付团队 用户在关心什么 服务得好不好 他们为什么来找我们、是什么造成他们进线。 客服的用语、态度、操作，有没有达到公司的标准。 同一批数据 → 一次处理 → 产出两份结果 --- Page 21 --- 用户洞察 · A¹ （从浅到深，分两层） 方向一 · 用户在关心什么 第一层 · 把「进线原因」判准 第二层 · 下钻 VOC（为什么） 逐条总结 · 提取根因标签 首版准确率 两处优化后 → 用户具体遇到了什么、是什么造成了进线 <40% 85%+ 汇总成趋势报告 问题集中在哪、哪些在涨、背后根因是什么 优化① 开放题 → 判断题：给 AI 已选好的类别，只判「合不合 理」。 完成运营洞察 优化② 定义清晰边界：正向 / 反向 / 前提，把场景差异讲清楚。 运营要的洞察，系统整套产出 --- Page 22 --- 服务质量 · A² 方向二 · 服务得好不好 合规评分 Amazon ↔我们· 一起验证 多维度逐项打分 推理链，让它更准 从态度、用语，到是否符合服务标准 —— 对每一次进线逐 想省成本省掉「判对」的推理，准确率反而明显下掉 —— 项评分，审查软实例 推理链也在逼模型认真判断 透明· 可追溯 灵活配置 每项判定都带推理 按业务线 / 国家可配 为什么给这个分、依据是哪一句话，被评客服都看得到，有 质检项调整，新国家接入，只要补上配置。 争议能复核 --- Page 23 --- 结果 · RESULT 一个系统，一次输入，两个方向都解决 缓存 把规则模板、业务背景这些固定信息缓存起来 → 单条处理成本再降一截 质量 覆盖率大幅提升 效率：几天 → 每天早上 85%+ 意图 看得多 → 能做更多维度分析：从一 运营每天早上扫一眼昨天的高频问题， 个「平均分」，到看出谁稳在高分、 就掌握前线，有更多时间做方案。 90%+ 谁忽高忽低。 合规 --- Page 24 --- 思考 · REFLECTION 让 AI 落地，瓶颈往往不在模型 以模型为基础，结合业务特点，构建 Pipeline：把业务说明书从「给人看」适配成「给 AI 看」。 规则边界 数据埋点 给业务规则补上清晰边界，先让 AI 能懂你的业务逻辑。 人一眼能看到的操作，要先埋点补上数据，让 AI 看得到细节。 黄金样本 反馈闭环 沉淀一批可信的标准答案；模型迭代快，换不换、好不好，靠 让人定期回看 AI「判对」的结果，挑出漏判、反馈回去，持 它评估。 续校准。 --- Page 25 --- Thank you --- Page 26 --- AI 重塑客服管理：滴滴出海14 国实战 扫描上方二维码 填写调查问卷 ## 三、会议回放视频转录内容 大家好，我叫朱子琦，来自于亚马逊云科技的生成式 AI 创新中心 那在接下来要介绍的这个滴滴客服 AI 质检的这个项目中呢 我主要是作为深度学习架构师，然后负责算法和技术落地这方面的工作 那首先我来快速的介绍一下我们团队 其实我们团队是一个遍布全球的算法科学家这样的一个团队 主要的工作就是和客户一起去进行共创工作 然后加速生成式 AI 解决方案的生产和落地 那这里面其实从项目立项一直到上线 我们团队都可以进行全程的参与 这里面包括比如说在项目初期和客户一起去进行一些高价值场景的讨论 进行一些需求的讨论 提供一些模型还有架构的这种选型方案和建议 一直到开始开发 我们可以提供一些 POC 的原型构建 包括到最后一些生产级别方案的这个解决方案的部署 所以说基本上整个流程 我们团队都是可以进行算法方面的这种开发和参与的 那其实我们团队成立到现在大概3年左右的时间 那在过去的3年里呢 我们也在全球范围内积累了1000多个客户的合作经验 那在我们参与过的项目中呢 也有超过70% 的项目 现在已经都成功部署到生产环境中 其实滴滴就是我们合作过一个非常成功的案例 那在过去的半年内 我们也是和滴滴的团队一起去共创 构建了一套这样服务于多业务线 多语种的智能的 AI 客服系统 那这个呢其实也是主要针对于滴滴的拉美市场 对当地的这种出行金融外卖这种业务线 去进行了一个客服质检 那通过这套方案呢 其实整体来讲 整个的运营效率得到了很大的提升 然后单工单的这个质检成本也得到了很大的下降 那关于这个项目具体的内容呢 接下来让我们有请 滴滴侧这个项目的总负责人 滴滴国际化事业部客户智能洞察总监 Raphael 来向大家进行分享 掌声有请 谢谢子琦 大家下午好 我是 Raphael 来自滴滴 IBG 这个 看一下 今天非常荣幸 可以接到亚马逊云科技邀请来到这里 跟大家分享我们和 GAIIC 团队一起合作共建的 这个客服的智能质检系统 先做一个简单自我介绍 我在滴滴五年多的时间 大部分时间我是做数据的 从去年开始呢 我的工作开始转向 AI 这个方面 今天介绍的这个项目呢 也是我全程整体负责的 今天分享的主要会分成四个方向 先讲一下我们的背景 我们为什么做这件事情 第二个部分讲一下 我们怎么搭建这个平台可以有什么能力 我们搭建过程中遇到什么问题怎么解决的 第三个部分讲一下我们的 achievement 到现在 最后我想跟大家分享一下 我的一些感受在这个过程中 先介绍一下我们的公司 滴滴大家都比较熟悉了 IBG 是滴滴的海外业务线 我们是2018年开始从巴西起步的 八年多的时间 我们现在是覆盖了拉美亚太非洲 在内的14个国家 提供出行外卖金融 三条主要的业务线 根据二五年公布的数据 我们现在日均单量可以达到1300万 年度的活跃用户超过一个亿 年度活跃司机骑手超过800万 那么在这样大的一个体量的业务下 用户难免会遇到各种各样的问题 那么当他们遇到问题的时候 找到客服的时候 客服团队提供的解决方案和服务的态度 会直接影响到用户对于我们的信任 和我们的品牌形象 那么怎么更加有效的去管理好 我们的客服团队呢 就是今天这个故事最开始了 那么当用户找到客服的时候 客服系统会创造一张工单 就像刚才展示的那样 我们也是会创造工单 那么这个工单是定期定量的 从这些海量的工单里面抽检出一部分出来 逐条进行分析 然后评估总结 是管理客服的一个非常重要的一个手段 那么当体量小的时候 这些工作交给人工来处理 是完全可以 cover 住的 但是随着体量越来越大 业务变复杂 语言种类也变多 那么这项工作交给人工来处理 瓶颈也就越来越多 那么总体上这三项 大家其实可以理解 慢不稳定 看得比较少 因为受成本的制约 那么随着 AI 的能力越来越提升 我们也开始和亚马逊云科技团队一起接触 看看是不是有可以使用 AI 帮我们提供一些解决方案 去处理这方面的瓶颈 那么如果我们想搭建一个产品 我们必须先想清楚 我们这个产品 需要帮我们解决什么问题 我们需要让这个帮我们做什么任务 那么从客服管理的角度上讲 我们整体会让它分成两个大的团队 一个团队是 Operation Team 运营团队 他们最关心的是用户关心什么 用户为什么来找我们 他们遇到什么样的问题 因为他们会需要提供解决方案 同时要降低发生概率 另外一个团队是 我们的交付团队 交付团队他们管理着 我们前线的所有的客服人员 那么他们最关心的是 这些客服人员 他们操作是否符合我们的标准 用语是否够礼貌 是否标准这些方面 那么当他们 因为这两个团队 关注的重心不一样 那么他们当进行抽检的时候 他们也都是分开自己 各自团队去进行的 但是因为我们是数据团队 我是数据团队五年 我数据团队 他们需要处理这些分析的时候 他们找到我们团队 去寻求数据的支持 我们发现一个很有意思的点 就是我们给他们提供的数据 其实一致性是非常高的 也就告诉我们 其实相同的数据 既可以告诉给我们提供 用户关心什么这个 insight 同时也可以告诉我们 服务好不好这个 insight 都可以做到 那么我们就想 是不是可以搭建一套系统 用一套系统一套模板 一次分析 同时给两个团队 解决他们需要处理的问题 那么下面我们就分这两个方面去看 先看第一个方向 用户到底是关心什么 那么这个层面 我们需要分两个层面去讲 由浅到深 当用户进线的时候 客服会创造这个工单 那么前线的客服 那 CSI 他们会把这个工单 归到一个归类里边 它到底是取消类的工单 还是物品遗失类的工单 那么这个工单归类 归的准不准是非常重要的 因为后面 很多的分析都是要基于分类的 那么所以我们第一步需要 让 AI 去做的就是去判断 这个归类 前线客服归的准不准 那么我们做法是 把所有的对话的数据 和相关的数据一起喂给 AI 同时我把我们的 进线分类的列表 也一起给到 AI 让 AI 去进行 语义的抽取分析总结 然后在我们的列表里边 选取一个他认为最正确的 然后拿着 AI 的结果 和 CSI 的结果 进行交叉对比 那么第一版结果出来以后 我们也是比较诧异的是 因为我们的 AI 的准确率 只有不到40% 我们理解的 现在 LLM 他们其实对 语言的理解能力是很强的 但是我们的结果却很差 那么我们也是让子琦 帮我们做了很多的分析 子琦也是 看到大量 bad case 以后 问题的原因 在于我们的进线列表里边 它的名称 一致性有的时候会比较高 从语义层面讲 它容易造成混淆 那么对于一个 probability 的 model 来说 它肯定就会 准确率就会降低 那么如果这个 这个 root cause 知道了以后 其实 solution 也就比较明确了 那么我们只需要 我们是定了两个优化的方向 第一个方向 是我们要简化我们的任务 我们的目标是让 AI 去判断 客服选的对不对 那么我们就把客服选的结果 一起喂给 AI 让 AI 进行综合语义以后 去判断客服选的对不对 那么这样就从一个开放性的问题 变成一个 简化成一个 true or false 的判断题 这样任务变得简单了 第二个方向 是既然我们的列表里边 这些选项 AI 不能区分出 它们有什么区别 那么我们就给它 每一个选项 搭建完整的框架 我们设置了新的三个 dimension 第一个是正向的边界 什么情况下用它 第二个是互斥的边界 什么情况下不用它 第三个是 pre-condition 什么 condition 才能用它 比如说是行程中 还是行程结束了以后 那么当我们把这两个优化点 都上线了以后 我们的正确率 也是从40% 一路提升到85% 以上 那么当第一层做完了 就是确定好了 前线客服判断的准不准 进线归类归的准不准之后 第二步 就会相对比较简单了 我们只需要让 AI 去进行 把对话内容里面进行总结 根因分析 是什么造成了用户进线 这个总结出来 然后形成报告 那么我们这一步 需要给运营团队提供的洞察 那就已经完成了 那么再看第二个方向 客服服务的态度好不好 那么这个方向里边 大部分都是合规评分的 去做合规的评分 那么交付团队对我们的要求 是一定要透明 而且可追溯 所以我们对这个模型的设计 是当它给出每一项的评分的时候 是需要同时告诉 给出整个的推理链条来的 那么你为什么给这个分 给多少分 为什么给这个分 是基于哪一句话 给打出这个分 给出这个判断的 是要给出完整的推理的 那么这样的话 当被检客服 他们有异议的时候 我们会快速地定位问题 同时如果我们需要去修改模型 发现模型问题 快速地定位 那么当这一套整体都 搭建完成了以后 出于成本考虑 我其实也在思考 对于那些被判为 fail 的 这些质检项 肯定是会有人看的 但是那些被判为 pass 的质检项 其实没有太多人去关注 对吧 那么我们是不是可以 从成本的角度上讲 把 pass 的推理链条 就不要去展示了 因为毕竟推理的过程 也是需要耗费 token 的 那么子琦也是快速地帮我们 去做这些验证 验证发现其实不行 那么而且还有一个很有意思点 就是不行的原因是 你如果不让他把整个推理写出来 这个模型他会偷懒 他就像小学生做数学题一样 你不让他一步一步写 结果大概率就会出问题 所以他的准确率 但我们不让他写 他准确率也是下降 所以我们这个不能省 另外由于我们的业务线 和国家比较多比较复杂 那么我们的质检标准 和质检要求也比较多 那么在这里头 我们 GAIIC 团队也是帮我们 搭建的是灵活可配置的一个 一个平台部分 那么这样他独立于 我们的 pipeline 之外 当我们需要进行 迭代修改的时候 可以快速地进行 且不影响我们的 pipeline 那么到这里 我们其实一开始定的目标 就已经达成了 一个系统一次输入 两个方向的解决方案 就全都有了 那么当这个系统完备 到这个状态的时候 GAIIC 团队帮我们 搭建了一个缓存的区域 这个缓存区域 可以存储我们 这些固定的业务内容 业务背景 评分标准 评分模板 这些东西 每张工单都是固定的信息 存储在这里边 这样的话 可以大幅降低 我们的 input token cost 当 cost 降低到一定程度的时候 我们就可以提高 我们的覆盖率了 提高覆盖率的优点 在于我们不仅可以让我们的 conclusion 更加 solid 同时也可以提供 更加多维度的分析 比如说以前 我们可能只能告诉 我们的交付团队 你们的客服 这个客服评分是80分 我们现在还可以告诉你 这个客服它是一个 high standard deviation 它波动性很高的一个客服 表现的还是很平稳的一个客服 那么这样对于客服的 培训方向也会不一样 因人而异 同时从效率的角度上讲 对于我们的 operational team 他们对于 时效要求很高 因为他们需要快速的发现 问题定位方向 找寻找解决方案 以前可能需要几天 才能找到的 report 现在快速的 每天都可以提供给他们 从这样的角度上讲 我们现在这个平台 现在的意图识别准确率 达到85% 以上 合规的准确率 达到90% 以上 那么这个就是 我们整体现在 这个平台的一个效果了 那么在我结束 我今天的这个分享之前 我想 谈一点我自己个人的发现 和感受 给大家抛砖引玉吧 我觉得现在 想让一个好的 AI 产品落地 效果真正能达标 能够效果好 其实重点 往往不在于 这个基座模型的能力 而在于我们对这个业务的理解 以及围绕我们的业务特点 去搭建我们的 pipeline 就像我们最开始 我们的那个 准确率不到40% 的那个事情 那么我们把它提高到85% 其实也并不是因为 我们换了一个更好的基座模型 而是因为 我们重新梳理了 我们的整个的业务逻辑 那么为什么这个动作 如此有效呢 我觉得 其实大家这么多天 听各种讲座 大家都在讲 context 我觉得这个其实真的就是 context 的问题 那么 以前那我们的 这些业务逻辑 在创造出来的时候 那时候还没有 AI 那么他们这些 业务逻辑的消费者是人 是我们这些上班这些人 那么今天 这些业务逻辑的消费者 变成了 AI 那么我们需要做 适配性的调整 就仅此而已 就好像我们 以前一个 app 在手机上是苹果的手机 那苹果的 app 你现在要在 Android 上用 你也是需要 适配性的调整的 那么我感觉 会有这四个方向 就在这里 这四个方向 会大家需要去考虑一下 看看 第一个是规则的边界 你要让 AI 真正理解到你的业务规则是什么 边界在哪里 实际业务是什么 第二个是 数据的埋点 以前有一些埋点 你是不需要的 比如说客服的 一些操作 我们可能在人工去质检的时候 他人工打开平台 是完全可以看到的 但是你现在 要让 AI 去看到 这些业务的特点 细节 你是需要重新看一下埋点的 如果没有 就需要补课 这个是需要做的 第三个 黄金样本数据集这个事情 半年的时间 我们搭建这个平台 半年的时间 这个基座模型 换了三个 因为迭代 最开始那个基座模型 也已经 进入了生命周期的末端了 应该已经是快下线了 那么在这种快速迭代的时候 你需要一套标准答案 去验证你的模型 好不好的 效果好不好 需不需要调整 该怎么调整 这个是需要的 最后一个是反馈的闭环 你需要人在环中 不管是去检查 AI 的错判 还是检查 AI 的漏判 这个都是需要考虑到的 那么这些东西 其实放在今天的 AI 的环境里头讲 听起来是 最不性感的东西 是非常笨重 沉重的工作 但是你如果想 我感觉如果想要 模型的效果好 落地效果好 这个还是非常重要的事情 好就好在这些东西 都是 Once for All 你做一次 之后你的其他产品 也都是可以用到的 这些能力 那么这些 就是我今天 想跟大家一起分享的 谢谢大家 再次感谢亚马逊云科技 对我们的邀请 也感谢子琦 感谢 Michael 感谢衡量 在一些帮助