智能体编码：与行业领导者的圆桌讨论

大家好！

本周或过去两天，您已经听到了许多 Android 团队 Google 员工的分享。

因此，我们认为，如果能在大会结束时，听听来自外部、来自社区、来自 Android 开发者社区的一些人的声音，那将是一件非常棒的事情。

我们将探讨智能体编码及其在现实世界中的影响。

首先，我们来做个自我介绍。

我叫 Ben，来自 Android 开发者关系团队。

大家在本次大会上已经听过我的发言，现在让我们请出其他嘉宾。

大家好！

我叫 Vinay，负责 Databricks 的 AI 工具开发工作。

很高兴来到这里。

大家好，我是 Luis Artola。

我在 Google 地图工作。

我领导的团队正在使用 AI 构建智能体体验并改进软件开发周期。

大家好，我是 Annyce Davis。

我在福特工作。

我负责领导一些工程团队，他们负责开发我们的订阅和忠诚度产品。

大家好！

我是 Ty Smith。

我在 Uber 负责为开发者提供支持。

移动设备长期以来一直占据主导地位。

在过去几年中，我们一直专注于这个令人兴奋的新时代，即 AI 工具时代。

大家好！

我是 Kaushik Gopal。

我是 Instacart 的首席工程师，同时也是 Android 开发播客“Fragmented”的创办人。

正如 Ty 所说，我们最近稍微调整了策略，开始讨论 AI 开发。

好了

我们有 30 分钟的时间。

我想时间会过得很快，所以我们会直接进入尖锐的问题。

我们 Android DevRel 团队一直致力于让应用开发变得更快速、更轻松。

现在 AI 来了，正如您在台上听到的那样，“AI 确实是

我们认为，这样可以更快、更轻松地构建应用。”

但我想提出一个问题：我们是否真的加快了应用发布速度，还是只是生成了一大堆无用的代码？

Vinay，我们开始吧。

好的。

是的，我们都在互相看着对方。

太好了！

因此，如果仅看纯粹的数字，我们肯定会发现，在 PR 和代码行数方面，输出速度大幅提升。结果，我们在代码存储位置等方面也遇到了扩缩挑战，对吧？

因此，这种加速是非常真实的。

不明显的是它对结果的影响，我认为整个行业都在努力弄清楚衡量结果的正确指标是什么，以及如何了解它对净利润的影响。

但我确实看到了它的实际应用。

我认为，我们在过去六个月中发布的代码比之前更多，同样，我不会说得太具体，但可以说比过去很长一段时间都多。

因此，我认为我们的策略在如何衡量工作效率方面也发生了变化，对吧？

因为有各种各样的思考方式。

我们正在努力找出如何提高中位数，对吧？

因为如果查看异常值和中位数，这两类人之间存在 5 到 10 倍的差距，我们的重点是提高下限、提高中位数，让这些人的工作效率与周围那些高效的同事一样高。

我们看到了一个角色组合。

有些人的行动速度要快得多。

有些人每天能提交上百个 PR，他们的工作成果令人惊叹。

但这就是他们所处的领域。

他们可能更倾向于从零开始，或者更熟练地使用这些工具。

我们还看到，有些人在棕地或平台工作中投入了更多精力，他们支持的是另一种类型的工作，这些工作可能没有那么快，因为他们必须花更多时间进行人工判断，并确保不会出现问题。

这两者的结合，你知道，比以前快得多，但我认为对我们来说真正有趣的话题是，即使我们交付了更多，企业实际上是否向最终用户交付了更多？

过去一年，我们一直在这一领域进行投入，以真正了解我们是否在更快地发布功能，而不仅仅是更快地发布代码。

早期迹象表明我们确实做到了，但与纯粹的 PR 相比，情况大不相同。

我认为，很明显，人们正在发布更多代码，PR 的数量和计数都在增加。

但我认为，即使在当下，很多人的想法仍然是：“我们如何利用 AI 这种工具来加速现有流程？”

对吧？

比如，以前我们发布代码时，总觉得需要有人全程盯着，直到代码上线。

但现在，我们看到的是，这种方式确实有效。

我们正在推出更多功能。

但我们遇到了以前从未见过的各种瓶颈，对吧？

因为我们过去从未遇到过这些问题，但现在，我们正在加速多步骤周期中的一个环节，我认为这就是有趣的地方，就像是，“好吧。

我们现在交付的内容更多了，但现在就像是特效的消防水管一样。”

因此，我们遇到了其他挑战。

这个观点非常有趣，对吧？因为仔细想想，虽然有很多不同的步骤，但从宏观角度来看，可以将它们分为三个阶段，对吧？

编码，这显然正在加速。

正式版发布准备情况包括法律、隐私权等诸多方面，以及让您能够发布产品的事项，然后才是发布，对吧？

而且，配送在不同地区有不同的含义，对吧？

如果您开发的是完全在服务器端运行的产品，那么发布可能意味着一个更精简的流程。但如果您发布的是面向消费者的产品，那么在实验阶段，您可能只是处于整个流程的中间阶段，对吧？

您仍然需要进行大量实验和衡量，这与您刚才说的很像：您感觉自己身处大都市区的高速公路上，遇到了一个瓶颈，然后您开始加速，心想：“太好了，

我进展很快”，但现在您遇到了下一个关卡。

AI 的出现让一些问题变得非常明显，那就是你会更清楚地看到摩擦点，而其中一些摩擦点与编码或技术无关。

它涉及流程和人员，以及如何利用 AI 优化这些流程和人员。

如何简化端到端流程，这是一个非常有趣的挑战。

我们正在思考的一个有趣问题是，个人或团队在完全交付产品方面有多大的自主权？

因此，从内部来看，有很多团队可能在构建内部工具，或者不向客户交付的产品。

配送速度快得多，对吧？

他们有充分的自主权，可以立即将这些内容发布给客户。

如果您有一个外部产品，而该产品仍需经过用户实验，或者，您知道，应用商店发布时间，或者，您知道，与设计和产品团队合作，所有这些其他瓶颈都在累积，而编写代码的人在快速推进方面的主动权要少得多。

因此，他们只是遇到了系统中的其他瓶颈。

因此，我认为将这些内容分为两个不同的领域，可以真正突出您的业务流程可以改进的地方。

是的，我同意。老实说，我认为工程技术从来都不是瓶颈。

我多年来一直这么说。

工程部门做事非常严谨，总是从业务角度出发，探究“问题是什么？”

你会得到 10 个不同的答案。

然后，‘好的。

现在，我们来了解一下如何通过产品来解决这些问题。

现在，让我们好好思考一下。

噢，我们可能需要和设计团队沟通一下。

踢到那边去。”

当问题到达工程团队时，我们已经大致了解了需要做什么。

然后，我们只需尝试访问 Stack Overflow，复制并粘贴一些内容，然后将该内容发布出去。

因此，在 AI 的助力下，我看到合规性工作效率提升最明显。

比如，我们一直想对 XYZ 进行现代化改造，或者我们一直想快速升级 Spring Boot 版本。

我们正在快速推进。

但就实际功能交付而言，我不能说我真的看到了显著的改进。

你们都提到，瓶颈可能已经转移，你们现在遇到的这些流程以前并不是真正的瓶颈，但现在却成了瓶颈。

不过，这些流程可能源自过去惨痛的教训，对吧？

那么，您是否感受到了改变这些流程的压力？我认为最明显的例子就是代码审核。

我们认为代码审核的未来是什么？

我们目前在做什么？

所以，我很想听听您的看法。

这又回到了我之前提到的那个观点。

我觉得很多瓶颈都是因为我们思考的方式。打个比方，如果你有一根魔杖，可以重新发明软件工程，而且你现在有 AI，对吧，我们会使用很多相同的东西吗？我们会做同样的事情吗？

例如，代码审核是因为我们需要人工来审核，比如进行最后的交叉检查。

我认为这种情况也在发生变化，比如，我们现在对代码审核的看法是，也许我们应该对这样的想法持开放态度：如果你在重构名称，或者你在尝试重构代码，并且你知道自己有很好的测试，而每个人显然都有。

我们有 AI 来写，没问题。

不，我的意思是，您是否能比那个代理机构做得更好？

我不知道，比如，也许就不要花时间去审核。

不过，如果您发布了有 bug 的版本，并且接到了 CEO 的电话，对方基本上会说：“嘿，这个 bug 让我们损失了 X 美元。”这时，您可能需要找出关键区域和系统，并说：“嘿，这是一个关键区域。

这不是关键区域”，然后尝试重新构想。

比如，我认为我们现在不是这样运作的，对吧？

现在，它会说：“嘿，有一个 PR。

我是工程师。

我专注于这件事。

价格会上涨。

我会在半夜找 Vinay 帮忙进行代码审核，因为我只想尽快合并代码。”

而现在，我们可能需要重新思考这些问题。

我完全同意，我认为代码审核是一个验证问题。我的意思是，如果我对自己验证某项内容的能力充满信心，我是否仍会审核 100% 的 PR？

可能不会，对吧？

因此，代码审核有两个目的。

一是验证我们是否在做正确的事情，二是教育，对吧？

比如，您周围的人会知道您在做什么，以及他们是否同意您的决定。

因此，肯定有一类工作，我们应该放心地加快其进度，并确保其顺利进入代码库，甚至发布。

现在，这可能不适用于 100% 的情况，但我认为它应该适用于非常高的两位数百分比。

我认为我们正在准备做出这些改变，作为社区，我们都需要确保我们的系统为此做好准备，因为这一天即将到来。

这是无法避免的。

漏斗顶部非常宽，有各种平台，可让您创建更多 PR。

而您的速度取决于流程中最慢的步骤。

对于许多团队来说，这就是代码审核，而那些行动更快的团队已经弄清楚并接受了这一现实。

是的，说实话，我看到的 PR 中有 70% 看起来都不错。

如果我们搜索全球所有代码库，会发现 PR 评论中到处都是“看起来不错”(LGTM)。

所以，部分原因在于，作为工程专业人员，我们有时会高估自己的能力。

我们真的认为自己已经融入其中。

“他们是否使用了命令模式？”

不，我们只是说：“好吧。

是的，我觉得挺好的。”

那么，为什么不能让智能体来做这件事呢？

我真的认为，未来我们会看到这样的场景：什么是“我觉得不错”，它的特征是什么，是什么样的行为让你有这种感觉？

然后，确保智能体也寻找相同的内容。

或者，从另一个角度来看，也可以尝试思考不同的审核方式，对吧？

比如，我知道现在 Twitter 上有人会说这样的话，对吧？

比如，现在验证 PR 时，可以让智能体以不同的方式将其可视化，对吧？

嘿，给我看看之前的样子。

给我看看之后的效果。

向我展示您编写的测试，而不是逐行审核代码。

但它确实对…提出了挑战。Luis，你刚才想说什么？

不，我认为这是一个发人深省的问题，对吧？

比如，我们最终会达到一个阶段，让您能够非常放心地让 CL 或 PR 在没有人工干预的情况下通过。

所以，我在这里要唱一下反调。我想说的是，当我们谈论阻力时，人们往往会认为阻力是不好的，但其实阻力有好有坏。

我认为，评价仍然属于良性阻力。

问题在于我们如何减轻开发者的负担，对吧？

有时，问题不在于如何让当时的审核更高效或更出色。

而是如何利用 AI 让上游开发更加精准，对吧？

因为如果你只是…取决于你如何使用 AI，比如好的输入会产生更好的输出，但糟糕的输入会产生非常糟糕的结果，对吧？

因此，我认为，要达到那种理想的最终状态，必须从一开始就利用 AI 对整个流程进行全面改进，利用 AI 更好地理解架构，在开发者付出更少努力的情况下，制定出非常可靠的规范，从而提高生成的代码质量。

因此，审核对开发者造成的阻碍也更少。

我认为，最终状态不会有太大争议，大多数人都认为所有这些代码最终都会在没有人工审核的情况下落地。

我认为，与此同时，我们正处于一个不断变化的环境中，模型越来越好，我们不再那么担心它们犯技术错误，而是更担心它们犯商业错误，或者担心它们在判断或构思方面出现问题。

因此，这也属于信号，您需要在审核阶段将其分离出来。

比如，我们应该在 PR 中进行逐行审核，还是审核他们想要推送的意图？

我们正在从几个不同的角度思考这个问题。

一个是，我们如何向用户提供更相关的信息，以便他们开始确定优先顺序？

另一个问题是，在哪些更安全的领域，我们可以开展实验，并在这类计划中更快地推进？

正如 Kaushik 所说，并非所有领域都需要同样严格的控制。

我们可以识别出这些情况，并开始让一些流程更快地通过，降低风险，同时保持那些更注重合规性或非常基础的领域具有更高的摩擦力，直到我们真正达到不仅信任模型，而且信任输入到模型中的数据的程度

是正确的决定。

比如在 Uber 应用中重构新的 Android 模块，可能还行。

为所有 Android 开发者提供免费乘车服务，可能需要检查一下该代码。

我得向我们的 CEO 确认一下。

抱歉，Kaushik。

但我也认为，这个问题已经得到了解决。

我们已经有了类似的功能标志。

我们已经有蓝绿部署。

我们已经拥有了许多组件。

挑战在于，我们一直太忙，没能真正做到这一点。

我们已经有行为跟踪。

我们有各种各样的数据，但它们分散在不同的系统中。

我们已经跟踪了突发事件。

我们有大量数据，但将所有数据整合到一个全面的跟踪中，这正是我们所欠缺的。

一旦我们最终弄清楚这种工程上下文服务在所有这些不同公司中的样子，我们就不必再担心了，因为即使 PR 只是合并，它也是安全的。

因为我们知道，我们已经通过功能标志将其隐藏。

我们有蓝绿部署。

我们已经具备了所有可观测性。

这样，您就可以非常自信地说：“哦，把它放到流水线中。”

如果发生不好的事情，我们沿途有所有这些警卫和关卡。

我认为，响应速度也非常重要，对吧？

如果您知道，我们来拿 Android 举个例子，如果您在 Android 中发布一项更改，而该更改需要通过 Play 商店发布，然后向消费者推出，那么您立即进行热修复的能力就会受到很大限制，而如果您在内部部署中进行更改，并具有内部可观测性，且有代理立即处理，那么您就有更多机会更快地采取行动。

所以，我想问大家的一个问题是，这些应用需要进行一些工作，但有些是绿地应用，比较容易处理，有些是棕地应用，需要花时间进行大量检查，这样才能推广 AI 的使用。

我知道你们中很多人都在开发大型应用，对吧？

所以，我想知道您对此有何看法？

是说，CEO 给我 3 个月的时间，让我把这个应用准备好，或者说，每天都添加一点？

没错

反正他们也从来不这么做。

不太合适

我的意思是，大多数公司永远不会有这样的奢侈。

我认为，我们必须像过去处理技术债务那样，专门投入时间来做这件事，比如用 20% 的时间来做这件事，用 5% 的时间来改进提示。

然后甚至理解提示的作用，并改进上下文。

正如我们之前讨论过的，我认为很大一部分原因在于工程师们仍然不了解它的工作原理。

它仍然让人感觉非常神奇和神秘，因此他们没有像配置和调整它那样，以最好的方式从中获得更好的价值和效率。

因此，我认为领导者必须在某个时刻思考：“我们需要做些什么来提升团队的能力，让他们了解 AI 的运作方式，从而获得更多收益？”

也是一种延续

因为变化太快了，如果我让一个团队此时此刻花一周时间学习最新、最棒的技术，并将其付诸实践，然后他们就没有时间继续学习或试验，那么到明年我们再检查时，他们就会远远落后于新功能。

因此，我们必须在实践中不断摸索，就像在飞行中建造飞机一样。我们需要设置防护措施，不断学习，并根据实际情况进行调整，团队也需要时刻关注这些变化。

在大型组织中，会有像我们这样的团队，尝试提炼这些信息，让它们更贴近生活、更易于理解。

但这是目前整个行业面临的挑战。

我想稍微调整一下。

你们中的许多人都在从事开发者基础设施方面的工作。

数千个 PR，您的测试基础设施、服务器等是否都崩溃了？

我很想听听一些实战故事。

Ty？

是。

他们势如破竹。

我的 CI 每天晚上都哭着入睡。

目前，我们几乎所有的开发者基础设施团队都在努力解决计算方面的扩缩问题和效率问题。

比如，发布红色警报。

他们看到流量大幅增加。

我们正在对代理进行架构更改。

我们正在努力尽快扩展使用 Bazel 的远程构建执行和缓存，研究如何让所有主分支始终保持绿色，或者是否可以开始在某些领域使用代理进行前向修复，研究来自工程师的工作量，尝试进行自我修复持续集成或缩短反馈环等，所有团队都在积极投资这些领域，以便在保持一定效率的同时跟上增长步伐。

但这也极具挑战性。

是的，我完全同意 Ty 刚才所说的一切，但我认为这也迫使我们反思并诚实地思考：如果从现在开始，我们的规模要扩大 10 倍，我们准备好了吗？

对大多数人来说，答案可能是否定的。

因此，在思考未来时，我们有意尝试让我们的雄心壮志与基础设施可以支持的规模相匹配。

AI 带来的一个变化是，它让我们所有人变得更有雄心壮志，因为我们已经看到了有意义的飞跃，所以我们正在认真重新思考我们的系统。

没错，我们会思考还有哪些系统可能会出现故障，或者我们预计哪些系统会出现故障，以及我们可以采取哪些措施来提前应对，以免措手不及。

实际上，我们是在努力避免意外情况。

对，只要我们觉得一切尽在掌控，大家就会感到满意。

一旦遇到意外，对所有人来说都是坏消息。

对吧？

因此，现在正是反思、回顾、审核和找出下一个可能出现故障的环节的好时机，因为故障迟早会发生。

这是不可避免的。

我们只是想提前做好准备。

我曾听 Inflow 的首席执行官说过一句很有意思的话。

她描述了 Google 达到如今数十亿行代码规模所经历的时间线，大约用了 20 年。而随着 AI 的加速发展，许多公司将在短短几年内达到类似的规模。

而且我认为，并非所有公司都准备好拥有 Google 级别的开发基础架构。

那么，关于这个话题，贵公司是否实施了某种支出限额？

比如，如何管理那些现在什么都用最好的模型、疯狂消耗 token 的开发者？

比如，您是否发现了一些策略，还是说最好让他们自由发挥，因为实验会带来不错的结果？

我认为去年是实验之年。

完成所有任务。

甚至在今年上半年，也只是合理使用。

自 9 月起，我们还设置了 token 限制。

因此，我们实际上对开发者的 token 使用量设置了限制。

然后，我们还提供了一些检测工具，以便他们了解：您的会话是否良好、健康？

什么是健康的会话？

您是否在每个会话中进行了这么多轮对话？

什么是轮次？

因此，我们也在努力通过工具来教育开发者。

我认为这只是第一步。

您知道，您必须先知道自己有问题，然后才能解决问题。

所以，至少让他们看到，这不是免费的。

以前，AI 真的感觉像是免费的。

人们只是在使用它。

我希望它能说：“更改我的分支”，然后说：“没问题，Annyce，我会为您更改该分支，费用为 5 美元”，对吧？

现在，我们已经到了这样的阶段：“好吧，我可以去命令行，自己动手，对吧？”

因此，我认为我们将开始让工程师真正了解实际成本。

更像是，我不会只是启动 ECS 实例，然后就不管了。

也许在 AWS 刚推出时，我们会想：“是的，我可以自己创建实例。”

我们当时让公司损失了大量资金。

我认为，现在代币也面临着同样的情况。

我认为，实际限制也带来了非常有趣的机会，对吧？

因为回想一下，我们最初开始使用 LLM 时，会把所有内容都丢给它们，对吧？

它们会检查代码，找出问题，并为您施展魔法，对吧？

但这也带来了代价。

而且我们实际上是真实的，你知道，业界正在意识到这一点。

这实际上迫使开发者和组织思考如何优化这一过程，对吧？

为什么呢？我来举个具体的例子：假设你有一个生成器，它负责生成用户界面组件，这些组件需要符合特定的结构、单元测试等要求。如果你能让模型生成一个确定性的工具，让这个工具来为你创建这些组件，那你为什么还要让模型实时生成它们呢？

因此，您有很多机会可以利用 token 和用量限制来发挥优势，从而提高效率。

是的，围绕这些主题，我们确实引入了限制，至少在 Instacart 是这样。

但我认为，目标不一定是限制 AI 的使用量，而是要建立某种规范，或者像您所说的，进行反思，对吧？

例如，您应该在什么情况下使用某些模型，而不是其他模型。

您知道，您可能不需要 Fable 或 Astra 来告诉您时间或更改 Git 分支。

对吧？

您可能需要花一些时间编写脚本，但脚本是永久免费的。

这样就不会浪费任何 token。

对吧？

因此，我认为，如果能添加一些约束条件，其目的不一定是限制使用，而是帮助您跳出思维定势，而不是一味地把所有东西都扔给它。

对吧？

我赞同您的说法，去年感觉就像是实验之年。

今年，大家更关注的是如何有效使用这项技术。

没错

这里的很多故事也让我们产生了共鸣。

尤其是从更多实验转向效率和责任的平衡。

这得益于我们在多个领域的投资。

例如，为开发者提供培训和提高可见性。

就像 Annyce 提到的活跃会话费用和信息。

投资于安全默认设置等，有助于避免无效互动，确保他们使用的技能能够高效地查找回归问题等。

并对所产生的费用负责。

所以，我们确实有 token 限制。

当开发者达到这些限制时，他们只需点击一个按钮并输入理由，其经理就可以批准。

因此，如果有出色的工作，我们希望他们能经历这个过程。

但是，如果他们可能在做一些更浪费或更具实验性的事情，他们无法向经理证明为什么他们应该在这方面花钱，那么这也有助于他们控制这种情况。

这不仅能避免不必要的工作，还能让我们审视并思考：这是正确的模型选择吗？

这个重量正确吗？

显然，由于竞争压力，这些 token 的成本已经开始下降。

但总的来说，让我们的工程师思考如何妥善管理我们提供的资金，我认为这是目前正确且健康的做法。

从长远来看，我们希望能够完全免除他们做出此类决策的负担。

对吧？

您希望实现自动模型路由等功能，让用户无需费心考虑这些问题。

不过，在此期间，这是一种健康状态。

没错

我认为，我们一直专注于做一些事情，比如模型路由器，这样我们就可以让开发者不必做这个决定，而是尝试将任务映射到正确的模型。

但也要有合适的绊网。

因此，我们从以下几个方面来考虑词元限制。

我们绝不希望阻碍开发者。

但我们确实希望确保在某些时刻，我们可以停下来思考一下，确保这些资金用在正确的领域和以正确的方式使用。

因此，我们设置了每日限额等限制，这纯粹是为了起到警示作用，开发者可以自行解除限制。

他们只需前往门户，点击一个按钮，然后说：“嘿，我

一切由我掌控。”

对吧？

这只是一个简单的控制手段，因为每个人都在进行循环，而这些循环可能会通宵运行，我们不希望这会增加成本。

因此，这非常合理。

另一方面，我们也希望确保开发者能够使用最优质的模型。

但对于这些类别的模型，我们制定了前沿预算。

因此，我们设置了每月预算。

已经够高了。

您未被屏蔽。

如果您需要解除屏蔽，可以申请例外。

发送给您的经理。

在这个时刻，您需要描述自己正在做什么。

作为平台团队，我们并非决策者，因为这些决策应该由最接近实际工作的人来做出。

在使用前沿模型方面，我们同样为您提供了充分的灵活性，并设置了上限。

之所以能做到这一点，是因为这最终会为流程带来可预测性。

对吧？

我们希望确保在预算 token 支出时（这对每个人来说都是一个挑战），我们已经考虑到了我们的计划，而这些杠杆可以帮助我们做到这一点。

你知道这些对话中让我着迷的是什么吗？

我认为这是因为我们都在公司工作。

因此，企业

因此，我们必须为每个 token 付费。

对吧？

但互联网上还有一整套订阅价格模式。

因此，对他们来说，这是一种截然不同的考量。

对吧？

但我认为，大家迟早都会面临同样的问题，那就是必须开始考虑每一个 token。

到那时，另一只靴子可能就会落地，即承担更多责任，就像我们现在在公司中必须做的那样。

或者，您在一家前沿实验室工作，拥有无限预算。

然后，您只需继续运营，并创造许多令人兴奋的 AI 原生工作方式，这些方式在 Twitter 上随处可见。

我们所有的公司都想效仿，但他们不想花费代币…

我们有 Google 员工在这里。

我非常好奇。

它有什么作用？

Google 提供的预算是多少？

Luis，你想回答这个问题吗？

我认为我不是讨论其经济效益的合适人选。

Google 是一家规模庞大的公司，拥有许多不同的组织。

不过，这正好为我们的讨论画上了完美的句号，因为我们的时间刚刚好。

这很方便。

Saved by the bell。

朋友们，这就是 A+ 级管理。

公关人员…

总之，感谢我们的专家，也感谢大家参加 ADS。