内容主要分为两个部分，第一部分是探索作为API的消费者，如何从零到一使用API。第二部分是阿里云在过去的十年为开发者做哪些服务。以及讲过去十年的故事。

 

一、API的用户旅程

今天内容跟API相关，但不直接从API讲起，当提到云计算的时候，第一步想到的不是控制台，而是计算存储网络，想到计算存储网络就会认为云计算是服务器。然后才涉及到需要登录到控制台完成实例的创建，以及完成非常复杂的环境配置和各种类型镜像的配置，然后保存，最终下单，完成实例的生成。在这个环节过程中，开发者还需要复制相关的信息，以供后续的使用，在这个环节对非常简单的业务系统来讲是没有问题的，有一台服务器、一台云存储和一组网络，就可以搭建属于自己的应用和网站。

并不是所有的业务都简单。举一个非常复杂的游戏公司的案例，某个游戏在全世界各地都有部署。在香港的Region部署一套架构，后天以及下这个月以及明年，需要在全世界各个Region部署同样的业务架构，该如何高效的完成这些资源的批量增删改查，如何高效进行复用模板，一直以来对体量相对复杂，它的复杂程度上升到某个程度的开发者需要面临的问题，在整体的业务团队和运维团队合作的过程中，都知道运维受业务驱动，如何把运维团队和业务团队衔接的更加的紧密，在DevOps背景下，怎么让业务团队和运维团队在CI/CD的流程下，Pipeline变得更加的高效的相互之间的衔接。除此之外还有个性化的平台。

控制台是阿里云作为官方以一个通用的规范的范式提供给开发者通用的一种能力，也有很多开发者搭建个性化的平台，以某个大客户为例，需要做的一件事情是搭建web端的应用，在web端的运维平台上有个性化的组装和设计，作为客户未必需要选择付费类型。所有的业务都是按量付费。按钮没有用，下面的实例规格有具体的对应的选择，对所有业务来讲都是固定。为什么需要有按钮。

开发者搭建一个属于自己的控制台，这是一个非常典型的案例，还有一个有趣的案例，比如可以通过移动端的app、移动端的h5来查看实例的运行状态，比如有一些运维的同事在外面，拿着手机可以看到实例的运行状态，并不是阿里云提供的能力，所有这些东西都是由开发者搭建的，所以上面的所有的问题通过控制台无法解决，需要有什么手段解决。

前面提到交互，交互也不再是传统的可视化的交互，交互不再是通过一个网页端，通过一个app，通过手机鼠标的点击，然后和服务端产生交互。以最上层为例，很多客户会通过的SDK， CLI， Terraform来跟阿里云产生互动，代表的是客户背后有非常大量的自动化的需求，也有客户通过ROS，CADT方式来进行可视化的自动化编排。

代表的是对模板化的，对自动化有很大的需求，但它相较于SDK， CLI技术要求相对不高。前面提到开发者需要有自己搭建的控制台，有自己搭建的web端和移动端，最典型的是最上层的业务服务界面，业务服务界面是开发者第一时间最强的体感。直接所使用的界面，把它定义为业务服务界面，第二层阿里云控制台，刚刚提到作为官方提供给用户没有任何定制化的能力，所有都是通用的，都是范式的。

有既定的交互逻辑和数据处理的逻辑，无论开发者通过什么样的方式和阿里云的后端产生交互，本质上通过的云API产生。就像人和人的沟通一样，有些时候不代表人和人的沟通只能过面对面的对话来产生，也有很多媒介和渠道，可以通过广播，通过报刊、书籍等方式，最终的目标都是为信息产生有效的传递和交互，所以API本质上是这样。API背后通过CRUDL影响资源的存在，每次API的调用都有身份，权限、流控、监控这一套属于阿里云自己的配套，所有的内容都围绕着Open API来展开。

接下来看阿里云在过去的十年时间，为开发者提供怎么样的能力和服务。讲三段故事。在2015年的时候，在这个阶段，Open API开放的数量非常少，有很多客户是通过主动的提出需要开放一个接口，在这个时候不一定叫API，是开一个接口。被动的给开发者提供接口。比如有客户希望OSS的服务的某一个动作开放一个API。在这个阶段，很多的API相对来说都比较碎片化，也受客户的需求驱动而被动化的提供API。在这个阶段，但凡涉及到API的调用，肯定涉及到需要编码。

需要去处理密钥的问题，需要去处理签名，这是钥匙，需要去处理HTTP请求还需要去处理End point等，以及复杂的数据逻辑处理，所以提到API的调用，没有人可以躲开编码，在2015年之后给很多开发者提供第一代的Java， Python和PHP的SDK。

这个时候提供的SDK全部都是通过纯手写的方式给开发者提供，从最早的SDK上可以看到有一些人为编写的优雅性在上面，在同年也对客户提供第一版的CLI，第一版的CLI是基于Python搭建，Python相对简洁的脚本式的语言，CLI很快可以来实现事情，CLI和API的调用本质上是像API和控制台一样，CLI依然是通过人肉，但它是通过相对更加固定的范式命令行的方式对后端产生发起，产生请求，也有开发者会通过COI编写自动化脚本方式。对后端产生自动化相关的业务动作，事情发展到17年、18年左右，直到20年，对客户也已经提供有7到8门语言的SDK。

直到这个阶段，已经大约覆盖了80%、90%的开发者使用的语言，所有的语言的开发者大多数提过来，通过被动式的方式支持。要哪个API，就来支持，需要什么样的环境，什么样的复杂的数据逻辑，就来支持。属于SDK的特性，但在这个时候也逐渐意识到所有的信息都散落在各个平台，因为早前API本身自己没有一套规范，统一的管理的体系，以Java为例，Python为例，PHP为例，所有的语言官方都有属于自己的一套包管理平台，甚至在帮助中心都不一定能找到对应的SDK，在不同的云产品下文档里也能找到不同的SDK，所以在这个时候所提供的信息相对来说是非常的基础，非常的碎片化，也是非常的零散，所以需要更加低成本，更加高效并且能够对客户统一的管理方式。在1.0的时代把它称之为工具时代。

到2.0的时代，发布API Explorer， API Explorer顾名思义就像电脑上有internet Explorer。API Explorer最主要的是帮助开发者去Explorer API，帮助开发者了解学习与探索API。这个版本的API Explorer主要支持两大板块的内容的工作，第一把所有API的文档集中到的API Explorer点，第二是帮助用户可以通过wed站点一站式发起API的调用，在同年也发布cloud shell，前面有提到CLI， cloud shell顾名思义是cloud云上的shell。它解决的问题主要是开发者用本地的CLI的时候需要安装各种各样的环境。home brew，各种三方的库。各种各样的库需要去安装。

cloud shell保持实时upto date。所有的内容开发者通过shell.阿里云.com访问进去之后，内容都是更新的。支持所有的预装软件，支持COI支持caryform，甚至开发者可以通过cloud shell跑一些基础的脚本，后来API Explorer发展到了API开发者门户，看一下API开发者门户，站点的名字从explore到开发者门户，明显把范围扩大。API Explorer以前做的事情是从0到1的事情，但API开发者门户做的事情是从0到1，从1到100，围绕着API搭建全链路的能力，围绕着API的开发者来搭建所有的能力，在API门户上，不只支持文档的查阅，调试，还支持在遇到报错可以通过一站式的平台抓取到每个报错背后的解决方案。

甚至在开发者完成API的集成之后，还有调用统计的数据帮助到组织可以来观测有哪些API，在业务环境运行的趋势怎样，报错的情况怎样，调用的来源怎样，帮助企业更好的对API运行情况的治理，1.0时代SDK面临很多的问题，面临着碎片化，被动化。

在2.0的时代SDK发生非常大的变化，发布了Darabonba 的语言，Darabonba本质上是通过DSL的方式来帮助所有的API通过原数据模板的方式来生成所有的多语言，关键词叫做生成。从1.0和2.0时代的跃迁，从手写变成生成，背后的逻辑大概是什么。

每个API背后的原数据结构，相对来说是结构化的，是固定的，有入参，有出参，有参数的类型，有错误，有an point，每个API背后所具备的元素和字段相对固定，通过DL shell方式，通过统一的自研的Darabonba的语言，可以通过API的原数据同时生成多达8到9门语言的SDK，生成机制并不是简单的降低自己在维护SDK方面的成本，更主要对消费者来讲，最主要的体验上的升级。

一门语言的发布，代表着八门语言的发布，一门语言的特性的发布，代表着八门语言所有特性的拉起，所有的SDK的能力得益于Darabonba的自动生成，做到完全的拉起，同步的发布，对客户的体验也上升到比较好的高度。到2.0的API服务时代，已经提供相对比较完善的一站式的服务平台能力，主要以API Explorer为代表，以Darabonba为典型的重大的突破。随着开发者越来越多，使用API发现很大的问题，API门户，SDK都是在客户真正开始集成API之前。拿到API之后，验证它怎么用，最终API要把它写代码，写到业务系统里。

在这个环节下所有的开发者都会做一件事情。SDK代码下载后放到的本地的IDE环境里，继续进行编码。无论IDE是本地的还是云端的，它都是IDE。涉及到一个问题，开发者需要持续的进行多窗口之间的切换，开发者需要切换API门户，开发者需要切换帮助中心，开发者需要切换github，开发者需要切换包管理平台等。

在过去的一两年时间，把所有上面提到的能力都放到IDE插件里，可以通过IDE插件完成API文档的查找，完成API的调试，完成SDK代码的直接插入，完成这些基础环境的配置，相当于能帮助开发者更加沉浸式的在IDE的环境中完成所需要的编码的工作。当然AI的浪潮也很重要，把通义1000问底层的能力集成到API门户上，帮助到开发者能够通过AI助手相对自由的对话方式来解决一些未知的问题，经过三个阶段的发展，有1.0，2.0，3.0。

对API的builder，在整个旅途中所涉及到的各个环节与大图动作已经逐渐明了，把它分为三个动作，不要认为图非常的复杂，先看最上面，builder刚进来涉及到咨询、验证与开发，做任何事情，集成业务，需要用这个产品，要了解它背后的能力是什么，它的业务是什么，确定它是想要的东西，包括买东西要知道它是多少钱，所以第一步-咨询，在咨询的环节，要找到需要使用的API。第二个动作验证。看到的东西只是一个表面，需要去测试它符合的要求，需要测试它符合的预期。需要测试它是安全与稳定的。到第三个动作是确保东西是想要的，确保东西符合预期，才把API放到业务环境里。

所有的动作都可以借助Open API门户、IDE插件和AI助理来完成，API门户和IDE插件本质上是在平台能力上提供的非常具体的用户操作的功能和路径，相对来说是圈定的用户能够使用的东西，但AI助理不一样，AI助理通过大量的语料，对其进行一些加强的训练，通过一些检索的召回，帮助到开发者提供预期之外的能力，因为有很多东西通过平台的固定的能力并不一定能够真正帮助开发者解决问题，但AI的能力，大模型的能力有如此强大的知识领域，知识库，它有非常强大的语言处理的能力，AI助理某种程度来讲解决一些开发者在使用过程中发散性会遇到的问题，所有的三个动作和三个平台能力，背后都有服务与工具做支持。最后形成的是中间的这条线路，发现API、调试API和集成API，叫做三个阶段，图变得不复杂。

 

二、精准搜寻API

接下来把前面提到的三个阶段，发现、调试与集成做进一步详细的展开，第一步精准搜寻API，在过去的十几年过程中，也陆续已经大约有300款的云产品开放2.2万个API，这2.2万个API随着后续阿里云的发展，云计算的发展，也随着产品能力的迭代升级，数量肯定会持续的上升。在最早的时候假设只有一个API，叫run instances。创建一条实例。只有这个能用。不需要纠结需要选择哪个。但随着有2.2万个API，有二三十万参数的情况下，有很多的API的设计是类似的，类似不代表不合理。

API的名称是类似的，参数是类似的，参数的组合是类似的，中文的描述是类似的。在过去四年，API的数量也大约是每年成10%到15%的数量的增长，到23年的时候已经大约有两万个API，对开发者来说，使用API并不像想象的这么简单。用API之前，要考虑到参数的格式，要考虑到如何进行授权，如何进行安全的访问控制，资源类型是什么，操作是什么，API最大的并发量是多少。

1秒钟请求10次还是1秒钟请求100次。假如说1秒钟，要请求一万次该怎么办。是不是不能用，留空的信息，报错的信息。遇到报错该怎么办。遇到报错肯定不是预期所想要的。背后该怎么去解决。所有的问题都不是添油加醋的。

作为开发者在集成API过程中，在集成API之前，API已经在业务环境中稳定的运行所面临的问题。该怎么解决。前面讲的都是相对API的一些比较碎片化的内容。API文档是什么。API的文档不只是API的文档，因为API背后有很多参数。刚提到有各种各样的授权信息，流控信息。某种程度上API的文档是产品能力对客户的窗口。

有很多开发者会做的一件事情是不看产品介绍，就看API有哪些，看参数有哪些，大概知道产品是干什么的。去看自然语言，API的文档本质上是产品能力对客户的窗口。通过API门户一站式把所有的API的碎片化的信息收拢起来。通过文档结构化的方式最终呈现出来是信息的可视化，也是借助非常大量的信息，底层的信息，未来有很多的探索的空间，无论是AI被二次利用，还是通过开放源数据，让开发者搭建一些属于自己的生态。

现在看第一个Demo，通过Open API门户，API.阿里云.com，搜索API-发送短信。日常生活中每个人每天都有发送验证码的短信。查看API文档，看到接口的说明。接口说明是人为编写的，它可以发挥自己想要的东西，流控信息，API支持每秒5000次的请求。授权的信息，作为开发者，把API放到组织下，如何管理它的访问控制，请求参数当然是最核心的东西之一，可以看到有对应的参数的描述，参考取值来源，通过大数据的方式来获取到参数，可以通过哪个API来获得，示例值和返回的参数。

响应的参数最直观的告诉开发者大概在看文档的时候就知道API怎么表现，可以返回哪些信息，有些场景下，并不代表所有的场景都是单个API集成。有可能是多个API之间的组合，所以API门户提供多达8种语言的SDK场景化的实例，整个场景背后有两个API之间的组合，让开发者不需要过多关心参数之间的编排，API之间的编排。再来看另外一部分错误码的内容。

错误码往往容易被忽略。放到后面再说，先吊起来，但错误码解决不了，影响开发者最终集成的效率，变更的历史，每个API的变更历史能够帮助到开发者最快时间的了解到API最近做哪些特性的变更，是不是有一定的影响，是不是可以集成它的新能力，通过API.阿里云.com整个API门户可以查看到2到3万个API，所有在阿里云上统一网关的API都可以通过一站式的平台完成API的搜索，开发者不再需要通过无论是开源的社区，无论是散落在各处的文档。无论是各种各样的平台，通过一站式，通过非常大的域名，非常容易技术的域名API.阿里云.com来完成。

 

三、高效调试API

API的表面，以及API背后的业务是什么。不知道API真实的表现是什么。可以返回实例ID。在API的调试的环节，开发者最主要不得不去关心的有以下几点。第一个是功能验证，刚举的例子，比如参数验证，参数类型是string，文档里写的是string，实际上是什么。是不是long，是不是bullying。对一些编程语言来讲，对参数类型的敏感性非常高，也有不一样甚至会造成非常大的代码的运行错误，除此之外是错误处理。有些时候报错并不一定是预期之外的，需要有意的来触发一些报错，来设计整个API背后的逻辑。比如需要创建一台机器，在创建一台机器之前，需要通过一个接口查一把。

通过查一把获得一个报错来确保这台机器在环境下可以进行创建，所以需要验证一个错误，当然也要知道对应的错误逻辑，有一些极端的情况下，边缘的情况下，后续该去怎么处理。因为在代码逻辑里会写，遇到报错该怎么去处理。

除此之外也是一个底线的要求-安全性验证，给API，给用户、给租户、给角色配置对应的访问控制，它的表现跟预期是不是一致的，它的数据传输是否符合规范，符合自己的要求，经过一系列验证，才能觉得API可以用。所以回到API.阿里云.com API门户提供一站式的在线调试的能力，过去开发者怎么调试。行业内有非常有名的比如postman，postman下载下来之后，依然还需要去配置一些签名，参数，end point等。

还是需要手动配置一些东西，也有一些开发者能力相对比较强，会编写一个脚本，编写一段代码。来手动的发起API的请求。但换一个API，又要重新去编写。这也是一个问题，有些开发者会运行直接提供的SDK示例来进行调试API。现在通过浏览器访问API.阿里云.com，唯一需要做的事情是这台电脑连网络。所有的开发者免除任何的配置。

所有的开发者不需要任何的编码，无论是测试工程师，文档工程程师，无论是CEO，无论是小白用户都可以非常轻而易举的在平台对API发起验证，刚刚提到还有跨平台的能力，代码有浏览器。无论是在mac ，linux，windows都可以访问页面来完成API调试。再来看这个Demo，从首页进去搜到一个API。现在创建默认的VPC，这是一个非常高频的接口。创建一个VPC，在一个网络环境下，所有的调试界面，中间是表单的输入框，右侧有文档，有SDK示例，开发者把各种各样的语言集成到API门户，开发者直接可以通过调试页面来完成API的调试搜索，并且右侧可以直接下载它所需要的SDK语言，然后发起调用，看到调用已经调用成功，VPC的IDE也已经给出，可以通过右侧最简单的调用结果来了解所有的API的表现。它本身的body怎么样。

Request Header是什么。Response header是什么。再一次发起调用，现在发现遇到报错，有个特殊的链接是问题诊断，问题诊断跳到对应平台之后，可以通过request ID，通过error code来了解到每一个报错背后的原因，背后的业务是在地域已经存在一个默认的VPC，所以不能再创建第二个。所以API的调试平台希望做的是能够帮助到开发者最快速度看API就可以把API确认想用，因为刚刚提到API不确定想用的时候就没法到下一步。对API没有信心就没法到下一步。

再看一个相对复杂的API，可以看到，API有非常多的参数，它即使复杂，但到页面之后并没有切换到任何页面。API有很多输入参数，参数的可填值有非常的多。通过表单枚举的方式，把所有参数背后可以支持传入哪些值枚举出来，直接显示给开发者选。可以看到通过API门户的调试，希望帮助到开发者以最快的速度、最低的成本完成API的调试，同时甚至不给开发者犯错的机会。

在这里要是填一个其他东西是填不了的，只能填正确的东西，不给开发者犯错的机会。所以现在整个API门户的调试是门户最主要、最核心也最热门的能力。所有的API在门户上经过调试，成功率已经达到90%。

无论是什么水位的开发者，无论是什么能力的开发者，无论对云产品的理解有多深，到页面自然会根据引导，自然会根据平台提供这些的能力来完成API的调用。成功率大约有90%左右，到这一步，API的旅程已经完成API的查找和调试。

 

四、沉浸式集成API

下一步要开始进行API的集成，如何能够进行更加沉浸式的API集成来帮助到开发者在集成API的编码的环节有更好的体验。现在是第三个时代，第一个时代是比较粗放式的，提供一些手写的SDK，然后向开发者提供一些散落在各地的一些文档，一些事例。第二个时代通过API门户为大家提供一站式的API开发者门户，能够让大家从创意需求到最终的实现上，去缩短中间所花费的各种代价，从一个需求到真正的代码运行到线上。把阿里云的资源用起来，能力用起来挺费劲，在第三个时代，这是一个体验的时代，现在有AI然后也有各种工具，在这个过程中还要用到各种各样的工具，环节非常的长，在这一年提供的能力是通过AI能力和IDE插件来帮助开发者更沉浸式的使用API的服务。

第一个沉浸式的体验是由IDE插件带来的，插件提供了两个平台，一个是intelligent 平台，然后常用的IDEA或者Python，Pycharm之类的东西，还有Goland之类的东西，另一个大的平台是vs code。在这个过程中两个平台能力上大致是等价的。开发者的需求可以通IDE插件，然后直接把在门户上提供的一些能力。比如搜寻API，调试API，执行COI做SDK的插入。希望能把过去在门户和IDE之间的切换，把gap直接拉近，把所有的API的信息和能力跟大家的开发的日常的流程结合起来。

进入第一个Demo。Demo是通过IDEA来演示的。

准备一个比较干净的项目，第一步装IDE插件，在市场上找到插件，Logo比较纯真。这些都是一些常见的操作，重启一下然后生效。打开插件以后可以像在门户一样用一些API的服务，比如查找API，看API的文档，门户上常有的IDE插件里面也能提供，调试API，可以选择自己本地的身份，门户上要切换身份相对比较复杂一点，发现IDE和门户之间是互补的关系，门户能做很多事情，IDE有的不能做，但是IDE也有自己的特殊的优势。

通过另一个调试，通过另一个接口来交叉验证刚刚创建是否真的成功，用刚才的参数，作为下一个API的输入，得到一个结果。结果不太方便看，但可以直接本地IDE打开整个全部的结果，可以详细的查看，多语言的代码示例也提供。上面目前有六门语言的SDK代码示例，可以把代码示例导入项目。发现有的地方标红，这是日常开发中经常出现的问题，因为缺失依赖。可以通过插件做依赖的导入，它能自动的根据本地已有的依赖和API所需要的依赖，自动计算完之后追加上缺失的，然后保存。

依赖问题解决完成，依赖是门户的一个体验，它没办法提供给客户，还得到门户上反复的确认，但通过IDE插件有本地的一个优势，让开发者能节省一些精力，这里面是默认的代码，它会提供一个填写access king ID凭证的示例，对用户的安全，凭证的安全是非常关心的，但缺少一定的手段，假设小王写一个明文的AK，写在代码里。直接提供一个插件，然后把警告给到大家，意识到问题，引导大家把问题修正，这里会引出更多凭证方式，凭证的设置是有多种，门户把体验从原来的填空题变成一个选择题。但如何扫描一个明文的AK，几乎是没有办法完成。

这里有几种更安全的凭证设置方式。介绍一个叫做默认凭证链，把刚才写明文AK的代码改成一种更安全的方式，这是结合IDE插件，能够结合COI的凭证管理的机制，把本地的能力用起来。这是导入的credentials包的过程。导入之后再对源代码做一遍修改，这样不用在代码里写相关的AK信息，直接删掉，然后会用到刚才引入的包，如果不引用可以试一下本地运行，会有一个空指针，是因为凭证没有设置，把默认凭证链设置。

这是凭证的导入过程，过程中可以看到还不够优雅。但未来可以继续把凭证导入，能够更加的自动化，用到凭证设置的提供credential provider的机制，能够不用传任何的配置，用一个默认的凭证链，会用到COI的配置，在右下角有一个阿里巴巴cloud一个Logo是当前的凭证，运行成功，并没有任何的明文AK，更安全。刚刚效果不太好，优化一下打印，打印成功。在门户和IDE插件之间，切触的过程已经少了很多，演示第二个沉浸式的体验。过去用COI。COI是一种又爱又恨的东西。有时候非常高效，但有时候在黑漆漆的terminal里面写起来有一种恐惧感，不知道下一个参数怎么写。

这次写对了然后下次再写。不一定能再次记起来。这次提供新的COI的插件，插件提供一种叫做notebook的模式，会帮COI安装引导，凭证的管理，命令参数提示快速运行，然后集成到插件里面。是vs code的一个演示，在扩展市场里面找，Logo比较纯真，插件包里面包含API的插件，API插件跟刚刚演示的IDEA里面体验是一致的，另外它还包含一个COI的插件。如果没有安装，它会引导安装，过去装COI，如果不知道还要去翻挺多文档。只要有一个插件之后它会根据平台，根据环境告诉去哪里下载，下载之后直接安装就好。这是过去一年对mac的优化。

直接提供一个可视化的安装器，不用写代码，不用敲命令安装，装完之后，这里提供一种以阿里云为后缀的文件格式，可以在里面写代码，可以通过COI配置的本地的凭证。这上面是真正配置的一些凭证，有一个有效的凭证演示。这是切换凭证。以前切换凭证要敲命令去切换，现在选一下就可以。可以看到命令的自动提示，API的自动提示，可以直接在IDE里面点一下，然后就可以运行，也可以在 IDE编辑器里面运行，这样得到结果直接在IDE里面查看，相关的文档在terminal里面很少能够看到文档的提示，但可以直接在这里面hover上去，会提示相关的一些信息。API提示，参数提示，输入两个横线，就可以触发。

notebook模式叫juper book。从比较流行的模式里面借鉴过来，在terminal里面运行完之后，可以通过记事本，把常用的命令都放在记事本，经常用的命令不需要每次去terminal里面重新输入，只需要在笔记本里面点一下，把命令做成一个一键可执行的东西，还可以结合其它命令运行，比如jq，可以通过它做更多的数据分析和格式化的改造。这是COI的一个沉浸式体验，这是最后一个沉浸式的体验，是基于AI打造的一个能力，云栖大会的会场都是有AI一体的。过去是通过门户去各个地方找，如果熟悉门户的服务，会知道功能点在哪里，文档怎么组织，流控信息，权限信息，endpoint信息。

所有的依赖都能找到。但对刚接触服务的开发者而言，这些东西还是会走一定的弯路，提供一个智能化AI助手来帮助大家直接通过自然语言的方式去描述，而不是在GUI的迷宫里面，AI助手目前在灰度中，会后会把它完全的放开给所有的用户使用。通过Demo感受一下，首页右下角就能看到助手，可以把它全屏化的打开，找API原来是在搜索框里做。

用助手，有需求然后找到最适合的API，然后发短信，这里用比较常见的例子。需要代码示例，要什么语言。直接问助手，背后用一套思维链的技术，分析需求然后结合自己的资源做出最好的推断，推断出一个SDK的示例代码，示例代码跟门户上调试得到的示例代码比较一致，参数上有一些差异，因为它还不知道更多的上下文，如果再问还会继续精细化。继续问助手，写代码的话经常遇到问题依赖没有怎么办。

结合API的原数据信息做数据的抓取，分析，然后推断出结果告诉客户，体验完成正确率非常的高，经常写代码用阿里云的服务的时候搞不清楚end point该填什么。如果还有其它问题，可以继续问助手。助手会告诉相关的依赖需要处理，这是由AI助手带来的沉浸式体验。不用看文档，不用看调试界面，体验时代所带来的创新。助手还在持续打磨中，如果在使用过程中有宝贵的经验，希望能够提交去持续优化，希望未来在一个助手里。甚至把助手搬到IDE里，在IDE里面直接用阿里云API所需要的知识常识，常见的问题，解决办法都能够集成到一起，这是未来的一个方向。

最后进行总结分享。从2015年开始，提供一些工具，即只提供各种语言，最开始是最主流的语言，后来逐渐扩展到常见的语言，再后来发现工具还不够，还需要配套一些服务，可以在开发的过程中用更少的精力和时间，完成更高效的需求。这是服务的过程，这里面是API Explorer和Darabonba多语言的生成的代表。现在的时代是一个体验时代，可以通过IDE和工作，能够更交融的在一起，和表达方式更贴合在一起。然后在方式上提供更多的服务，未来会把这些更智能化、更沉浸式的、更好的体验提供给大家，会持续为大家提供更好的工具、服务和体验。作为一个使命，会继续做一些创新。左边的二维码可以体验门户，进去之后可以体验助手，IDE插件的引导在门户里面也有，右边的二维码是关于阿里云的API资源等更多的资料，可以通过二维码获取。