阿里云esc快照功能怎么关闭

哈喽，大家好。呃，我今天就是把咱们定这个阿里云服务器怎么做快招备份这个设置给大家这个介绍一下。其实这个操作也很简单，但是我们很多可能也不太知道，不太熟悉这个场景，怎么用，怎么把它用好 啊？首先我们找到那个阿里云控制台，进到控制台找到这个存储与快照，里面有个快照栏目，进行一个快创建快照策略啊，那我们就可以看得到这里的策略其实很简单，可以实现到了就是每一天啊，可以最小单位是每隔一个小时 这个备份的时间，假设我每天晚上的十点钟，每天晚上十二点钟做一次备份啊，来进行这样一个设置，可以比方说我自定义可以保留三天啊，这样子这个设置就做好了， 所以这个纬度的话，其实就是可以实现到就是每隔一个小时都可以做备份，这样子的话你的场景里面其实可能更多了。比方说咱们如果说是类似于像 erp 这个数据变化比较快的这个行业，其实保留个两到三天就可以的。 然后备份的时间可以每天多做个两次，比方说每天一点钟做一次啊，就十点钟十二点钟做一次，中午的十二点钟也可以做一次，这样子就是说他的一个好处，就是说你的这个备份的这个 快照多，然后你的这个如果出现的中毒中啰嗦的这种几率之后啊，这个时候我们就可以根据我们的辈分的节点来进行自定义恢复，这个就很方便，所以这个场景可以大家把它用好，还是挺有帮助的。

hello， 大家好。呃，昨天有给大家介绍了一下如何做阿里云快造自动备份，那么今天我也花一点时间把咱们这个 快招备份如何做恢复回滚给大家简单介绍一下。其实这个场景咱们可能也会遇的比较多，就主要如果说您这个发现业务系统中啰嗦病毒了，那这个时候咱们的云服务器 有做了自动快照备份，那这个如何进行快速的恢复，保证业务系统的这个快速的响应，其实这个操作非常简单，那以以现在我这个界面为例的话，大家可以看到 我这台服务器的这个数据盘是，嗯，每天晚上的十一点钟有做了一个备份，大家可以看到有二十六号，二， 二十七号、二十八号，那如果我今天早上是二十九号来发现这个业务系统中招了，那么我就最优先的话回滚到昨天晚上的十一点钟。四月二十八号这个数据 其实只需要选中这个云盘，然后进行服务器的这个停机之后点一下回滚云盘，那这个时候的这个数据盘其实就会自动 恢复到昨天晚上十一点钟的数据，那这个过程中其实我们就可能丢的话就丢了晚上那几个小时数据，但这个是最有效的一种方式，那直接点这个回滚过去之后，建议的话把操作系统进行一个重装，这样子的话就更安全一点。 那其实这个操作大家看了一下，非常的简单啊，但这个场景的话其实也比较多，一个是当咱们发现中了勒索病毒，这个可能是最多的。 第二个是如果有误伤的数据，那么也可以通过这种方式呃来进行，把这个数据第一时间呢可以找回恢复。在这个过程中其实还是有一个小技巧给大家分享一下， 就是说当我们把云服务器的这个环境部署好了之后，第一次可以手动打一个镜像快照，这样子可以把它进行一个永久的保存 啊，以便下次我们就需要回滚。做操作系统重置的时候，就不用去重新部署环境了，不用部署软件，只需要点一个按钮，那你的这个系统盘其实就是你需要的操作系统了。

在阿里云的拍平台上部署了一个轻量级的 compui 的 一个嗯，镜像，这个镜像呢，它你可以用它自带的一些节点，自带的模型，但是呢，不能自己去自定义节点，也不能自己上传模型或者是开发自己的，嗯， 节点，我这里是直接跑了一个它自带的工作流，工作流的名字呢，叫 e z animate， 五点一，它既支持视频生成，就是视频生成视频，也支持图声视频，文声视频。 我这个工作我已经运行了将近十分钟了，还没有出结果。那么昨天呢，我也是运行了一个自带的工作模板，这是一个万象的，万象的出声视频的模板，跑了两次都没有跑通。而今天一看呢，在阿里的控制台上看到我已经产生了两块一毛二的费用， 昨天跑了两天工作的没跑通，那还是产生费的。为什么？因为你我虽然没跑通，但是他也是就是说在这个派的平台上使用了他的专利去推理，他主要是推理产生了推理的这个这个 token， 那 么他就会就会去产生费。当然目前我选的这个已经是最轻量级的一个镜像，他部署的时候是不收费的，如果你部署标准版或者是更更全面的镜像呢，可能部署环节就需要收费，另外推理肯定会收费，还有就是存储在 平台，在阿里云上存储一些数据的时候也会收费，我选的这个是已经是相对最便宜的了啊，现在这模型终于快要结束了，提示，此时生成一个小狗在摇晃脑袋。目前来看，这个视频生成的结果还是和预期应该还是比较吻合的，它是一个帧率为八的视频，此时九帧大概就是六秒左右的视频。 明天的话我再来看一下会产生多少费用。昨天是产生了两块一毛二，到目前为止，我感觉如果是你想学习，也就是说你在学习过程中会不停的试错、试运行，那么它都会产生费用，所以说用这个品用它的话就不太划算，所以你 你保证工作流没有任何问题，就像这样它确实可以生成视频，生成图像，那么每次运行它都可以成功。这种类似于生产达到生产条件的需求呢？我觉得是可以在这个产品使用的。

点开阿里云软件 av 五，点开右下角我的点开权限管理空白处，按住五秒出现广告开关，关闭即可。

新人免费额度消耗完后，如何避免自动从阿里云账号余额扣费？您可以通过以下方式管理扣费风险，一、删除已创建的 api key 删除 api key 后，您将无法通过 api 调用摆链上的模型，因此也不会再产生模型调用费用。二、设置高额消费预警 当设置的预警产品日账单大于预警预值时，每天短信提醒一次。最后提醒大家，当免费额度列显示无免费额度或不显示免费额度区域，说明账号下该模型的免费额度已到期，应提前设置。欢迎评论了解更多解决方案。

呃，我先自我介绍一下，就是我是来自那个阿里云数据库部门的日进，然后目前是负责那个 p g 还有思茅、贝斯两个产品的那个研发。 然后，呃，其实我本人的话，其实刚毕业在一二年左右的时候，其实那个时候是非常流行这个 for stack， 就是 全站工程师的。然后那个时候确实当时那个时候其实也没有这个 view、 react 这些东西， ts 也没有，当时的话其实全站也是从这个前端一直写到数据库社口层， 那那个时候的可能就是用这个，比如说很古老的这种杰奎瑞，叫什么 angel g s 这种去首抽这种前端的。那今天的话，其实我在这个数据库领域的话，其实已经有大概七八年的时间了。那 在 ai 时代的话，作为一个后端的同学的话，我觉得，呃现在有这种 ai 时代到来之后，其实我觉得是把这个前端和这个后端的距离会拉的拉的非常近。对， 然后在这个分享之前的话，我其实想呃调研一下，就是有多少同学现在听过 software 这个东西，能举下手吗？ ok， 比我想象的要稍微多一些。然后希望今天的我的这个介绍的话，能够让大家对于这个 software 有 一个更全面的了解，然后看看就是大家能不能在这个 software 上能够应用到自己的这个日常的这个工作里面去。对， 然后今天的话，我的分享主要其实分三个部分，然后第一个的话就是我们在这个 ai 时代的话，为什么需要一个新的这种开发方式。对， ok， 然后大家其实可以看到，呃左边这边的话，其实是一个非常传统的一种开发方式，那就是比如说我们有前端、后端还有数据库，那前端比如说就是 vivo react 这种，然后在后端的话，其实它的这个技术占就非常非常多了，那比如说语言就至少有很多很多种。 然后比如说对于这种 java 比较熟悉的话，我们可能在应用里面有经典的这种三层到四层架构，从这个 controller 暴露这个 rest for api， 到再到这个 service， 再到这个 catch 层，然后最后再到到层，然后这个到层的话又通过这个 jdp 去跟我们底层的数据库去打交道。 那呃，其实在这个底层数据库里面的话，它其实这个种类也非常非常多。那比如像这种常见的 my circle pg， 还有像缓存的这个 radis， 还有像存文档的这种 e s， 那 在这个里面的话，其实就是说从上到下整个的那个距离是非常长的，而且基本上前端后端还有数据库都属于不同的，这种在公司内部都属于不同的团队。 那比如说你在沟通一个需求的时候，你这个可能要前端和后端的同学要去反复的去沟通，我的这个 api 的 定义是什么样子的？ 那比如说打趣的说，后端同学说我们永远也不能相信这个全端传过来的这个参数，有可能造成这种叉 s s 攻击，有可能造成这种售购注入。那前端同学说你后端的这个 a r 应该返回给我一个空数字，而不是一个 a r， 所以像这种呃反复的沟通，这个成本是非常非常高的。然后第二个的话就是呃三个组建里面，他的整个的这个发布迭代的这个周期，你也要去花大量的时间去做这个同步的。比如说我前段已经到了一点三的版本， 那我的后端和数据库可能还处在一点二和一点一的版本，那这个时候有时候这个发布代码之后，那可能就会出错，因为可能这个组建的版本没有对齐。 然后第三个就是呃，如果前端同学想做一个这种呃数据交互非常丰富的这种应用的时候，其实他面临的一个问题就是可能后端的这个技术的这个学习的这个周期会比较长一点，会导致就是说可能我们一个这个应用上线的周期会非常非常长。 然后最后的话，其实就是我们一个系统里面的话，其实有很多这种重复建设的这种代码或者说功能模块。那比如说 普通的这种数据管理啊，侦查改查，然后像这种用户的这种认证，还有像这个消息通信，对吧？前后端这种消息通信，还有就是像这种文件的这种存储， 那其实这里面的话，就是可能原来的开发模式里面的话，基本上做的好一点，把这几种模块的话抽在公司内部抽成一种呃通用的底层的这种组建，然后供上层的这个呃新的这种应用去组装调用， 那如果做的不好，那可能就是我的每个应用里面都有大量重复的这种代码，那在现在这个时代的话，就是有没有一种这种所谓的这种智能后端服务，就是把我们这种系统里面大量的这种重复的这种功能 能够给他有一种非常轻量化的方式来实现，能够拉近就是说我们前端和后端的一个距离。 然后第二个的话就是说在 ai 时代，其实大家现在经常用这种呃，用 prompt 的 方式去生成很多的这种应用，然后部署，那么它其实整个的这个呃周期是非常非常短的。那我们比如说我们的这些前端同学或者我们的产品经理 想去验证一个自己的产品上的一个想法的时候，也就是我们说的这个最小可行性产品 mvp。 那 么需不需要像左边这样啊？有这么复杂的一个组织架构和这个周期去开发， 对吧？所以呃在当前的这个时代下，呃是有一些这个解法去解决这个问题。那这里的话就引入了一个这个叫做 support base 的 这么一个 back end service， 就是 后端级服务。 那这个 storebase 的 话，其实它早期的话，其实它是一个这个基于这个 p g 库的，然后它最早期的口号就是可以作为这个谷歌的这个 filebase 的 开源替换的后端机服务。那其实 在现在呃近两年 ai 这个开始火爆起来之后，其实这个替不替换 filebase 其实已经不重要了，那么它也是逐渐地成为这个 呃比较标准的这种开源的这种向 ai 进尺，或者说 gai 平台的这种后端的服务。那大家其实可以看到一个有趣的现象，其实在这个呃 gai 平台出来之前，其实它整个的这个增长是比较平缓的。 那从这个 bot 到这个 lovable， 再到这个 rapid， 这种平台出现之后，大家可以看到它的增长曲线是明显高了很多，所以其实现在类似于这种平台，它其实都在逐步地去接这种后端机服务。 对，所以这是它的一个这个发展的这个曲线。在 ai 时代， 那如果有了一个这个 bug 之后的话，我们怎么在这个 ai 时代去打造一个这种 ai 应用平台，去释放我们整个的这个生产力？包括在公司内部，包括对于个人来说，那其实我觉得呃其实有三个要素啊。第一个就是前端，因为现在 整个的这个前端的这个交互逻辑其实可以做的非常非常的顺滑，以及非常的这种呃呃比较复杂。因为它这个里面的话，其实这从前端用户从前端进入之后的话，其实整个系统里面的话 还是会有比如说像这种用户权限管理，还有就是说基于我们这种大模型的这种多轮对话和这种上下文的管理，因为我们深层应用的时候 需要跟大模型进行多人的对话，让他能够理解我们的意思，然后去深层对应的这种正确的这种应用。然后就是在这个平台上我们肯定要去比如说上传一些文件，去给这些大模型一些 demo， 告诉他我想做成什么样子， 然后还有像这种多 agent 的 这种编排交互的逻辑等等等等等等。然后第二部分前端有了之后的话，其实我们这边就需要一个 bus 平台去给这个前端提供这种长期记忆，也就是说里面我们这种多人对话 要历史都能多好保存下来。因为可能如果我不保存这个的话，大模型后面根本不知道我的个人的这种设计的偏好和习惯是什么，所以有一个长期记忆的能力。第二个的话就是在霸气平台上的话，提供标准的这种数据访问的接口， 就不需要说我在这个，比如说我要新增一个功能，要新增一张表的时候，我还要让后端同学去写这个复杂而且重复这种道程 去去访问数据。然后第三个的话，就是刚刚像这种 beta 二子的这种平台也介绍，就是说我的这个用户认证其实是比较复杂的，那我如果重复建设的这个周期和人力成本 roi 是 非常非常高的， 所以在霸气平台上也要提供这个用户认证管理。然后就是呃传统的数据库，我们知道它可能只提供这种行级数据，一条一条这种行级数据做 insert update delete， 那 现在在 as 的 话，其实在我们的这个 back end service 的 话，其实必须具备这种 多模态数据的存储，就是像这种呃文件、音视频等等这种非结构化数据，还有像这种节省的半结构化数据，还有像就是传统的这种结构化数据。最后就是呃在数据层面 我们要提供这个数据的版本管理，类似于我们的代码的版本管理，这个等下后面会介绍。然后第三部分其实就是一个比较核心，就是说因为我们是这种对话式生成应用嘛，那大模型的这个能力非常关键，包括你写代码要用这个 code 模型， 然后去跟大模型去做这种意图的交流，那就是这种对话模型还有像意图识别，然后最后就是在大模型里面做这种分布式的 callin。 所以呃，我总结下来的话，现在在这个 ai 时代的话，其实我们要通过这种前端的工程能力，将这种 bus 屏，将这种 bus 的 服务，然后模型工具还有工作流等等，通过这个 标准的协议来整合成一个后前端薄后端的这么一个生产地平台。那这个地方可以给大家先提前剧透一下，就是待会我的那个同事三果那边的话，主要可以给大家介绍一下在 ai coding 领域的一些一些东西， 然后我今天主要是聚焦在这个 bus 平台能够为前端提供嗯，什么样的能力？ 对， ok， 那 就是进入到这个第二部分就是 rds superbus 的 能力，以及它相比于这种开源的 superbus 我 们提供了怎样的企业能力。对， 那 superbus 本身的话，它其实，呃从开源的角度来说，它其实是整合了大概有十几种开源的这种项目，然后把它整合到这个 pg 作为用 pg 作为统一的这种后端，所以它做了一些改造，但它本身也是基于大量的这种开源的项目来整合成的一个项目。那 rds support base 的 话，其实很简单，就是我们用这种开源的 support base 加上云上的这个 rdspg， 然后加上我们云上的这种基础设施 来提供这个 rds service 的 服务。因为，呃，我不知道大家有没有自己在这个线下，或者说自己比如说去购买一个 ecs 或者这种计算节点去部署过这个 service， 有 有有吗？有同学自己去部署过吗？ 对，因为它 softwarebase 本身里面的这种组建是非常非常多的，然后它底层又是基于这个 postgrads 这种数据库，那个人玩一玩的话其实没什么问题，但是 一旦把这个东西应用在这种生产环境，那么第一点我的这个 postgrads 里面的数据，我怎么保证它的这个 呃容灾性？就说我的数据怎么能做到不丢？因为数据其实是一个应用的最核心的东西嘛，那数据的安全性我怎么保证？然后第二个的话就是 support base 本身因为它的主键非常非常多，那这主键之间资源用量的调配等等 也是比较复杂的，所以呃我们这里从下至上的话是基于这种云的这种技术设施，包括像这个对象存储安全容器，还有像这种摆类模型， 然后在上面基于这个 postgress rds postgress 那 么提供这种呃弹性高可用，然后数据备份安全还有容灾的能力保证，就是说在我的这个 bus 平台的这个数据是绝对安全可靠。 对，然后再往上其实就是呃我们是封装了这个开源的售后备份，那这个里面的话，其实 呃 supportbase 原生的 supportbase 的 话，它其实在这个长期记忆就是 context 这管理上其实还是比较弱的。那么我们在这个基础之上的话，其实自己去 基于 pg 的 这种多模态的能力的话，去做了一个这个叫做 reg agent 去管理它的这种长期记忆，然后在网上那就是提供了很多这种标准的呃接口，去让用户可以继续 supportbase 或者 sask 服务等等等等等等。 对，这个就是整个从下到上的一个这个呃产品的一个架构， 对，那 rds superbase 里面的核心能力的话，其实呃总结起来有四个。那第一个就是这个 os 认证，那它在里面提供的这个认证的这种方式其实也是比较丰富的，那像这个邮件、匿名、用户名、密码、短信、 os， 还有这个 simo， 对吧？这个都是基础能力。然后因为这个呃开源的收费，是的话本身没有适配这个中国本土的一些这种热门的这种 平台登录平台，那么我们其实在这个云上的话，也是提供的像支付宝、微信，还有就是阿里云的这个 sms， 让这个用户能够开箱就能够去基于这些平台去做这种认证集成 啊。第二个的话就是这个 data base 本身的管理，那这个 data base 本身的管理的话，它其实就已经从这个传统的 j d b s driver， 然后变换到了这个 rest for api， 它把这个它们之间做了一个转换，它提供了像这种 rest api， 就是 说你访问一个新的库表，那么其实不用写银行代码，你只要在 sdk 里面把这个相关的逻辑生成就好了。 然后第二个的话就是 graphui api， 那 么它其实也是一种呃，虽然和这个 restful api 不 一样，但是它也是一种结构化的一种查询的一种方式。然后第三个的话，就是我们 利用这个 p g 本身的这种非常强大的这种插件扩展能力的话，在里面实现了这种增强的这种向量 和 graph 的 这种查询能力。还有就是像里面内置的一些这种定时任务的插件，还有像这种通过 circle 去调用这个外部 http 服务的这种方式来增加这个本身伺候 base 这个 function 的 这个扩展能力。然后第三个就是这个 real time， 那 刚刚跟那个文昭同学可能介绍的能力可能会有一点类似，就是基于这个 real time 的 话，其实你可以通过这种 web socket 的 方式实现这种前后端的这种双下的同步，包括你基于 real time 去构建一个这种多人 实时对话聊天的这种应用都是可以的。那它本身的话，呃底层还是基于 p g 的 这种呃变更数据捕捉的这种形式，我们叫 c d c， 那捕捉完之后它通过这个呃 web socket 把这个变动的这个消息推送到你定义的这个客户端上去，那通过这个可以做这种消息相关的这种应用。然后最后的话就是呃 swabiase 的 话，它基于这个云上的这种对象存储， 然后实现这种非结构化数据的这种存储。包括像这个对象存储的话，它其实可以挂载到这个 cdn 里面去做这种加速，那比如说像一些前端的这种静态文件 等等等等，包括像我的这些文档数据库文档，那么都可以放在这个 storage 里面，那么整个这个里面的话，它统一都是由这个 pg 本身的这种叫做 role level security， 就是 行级这种安全去保证多个用户之间的这个权限管理。 对，这个是整个 rds superbase 的 这个核心能力，那刚刚其实提到的就说 superbase 本身它在这个 context 管理上其实没有那么强大，那其实我们在这个呃 superbase 的 这个长期记忆里面去做了这个 reg agent， 那 我们可以把它定义成这种 ai 定制的这种第二大脑。因为呃传统的我们这个大模型训练完之后，那它其实都是基于这种开源的公开的这种文档来做的。那其实还有更多这种有价值的文档其实都在企业内部，而且这些文档是不可能 对外，而且也不可能送呃吐给这种开源的这种大模型，因为这可能会造成这个知识的这种泄露。 然后如果是想基于这些文档去做 fight， 那 可能成本也比较高，所以我们需要一个外挂的这个存储 contact 存储，那其实就是这个在 superbay 底下这个 reg agent， 那 大家可以看到，其实呃整个的逻辑里面的话，就是用户其实它上传文档的时候，其实是直接上传到这个 superbay 的 这个 storage 下面，那包括像 pdf doc， 然后 markdown， 然后表格、音视频、图片等等。那这里面进入到这个 storage 之后，其实像这个在这个 regular 里面，它其实有一种叫做 auto in bidding 的 技术， 去不断地扫描这些文档的这个标签的变更，扫描过来之后，然后去并发地去通过这个，像这种，比如说我们的音视频，还有这种图片，我们把它的这种图片里面的这些描述， 然后像音视频里面的这种图片的描述，就是抽针对视频抽帧抽成图片描述图片生成文字 embedding， 然后里面的音频 变成解析成这个文字，文字变成 embedding， 然后这些东西全部做完之后，那么把它存到这个 r s p g 数据库里面，那这个地方的话 生成 embedding， 我 们就集成这个 embedding 的 model， 然后生成这个呃图。也就是说传统的我们比如说一个小说里面有有很多段的这个文字， 这文字里面有人物，那如果没有这个 graph 的 话，这些人物之间的这个关联关系其实不太好去搜出来。那作为这种引白点这种语义的搜索，那么通过这个 graph， 让这种推理大模型去把我一段文字里面的，比如说人物关系 两两之间是什么关系，这些关系构成一个 graph， 那 么后续在这个我的这个搜索里面的时候，我可以搜出更多丰富的这种内容，来补充我单路 in bing 这种搜索的这个一个短板， 对吧？然后最后其实就是我们对于这些深层的这些文本也是做 checkin， 放到这个数据库里面可以也可以做这种关键字搜索， 最传统的关键字搜索，那最后这种三路的这种数据搜索之后，其实可以丢给一个 rerancing 大 模型，让它帮我去做这种排序。 哪些这个文本和我要问的这个问题是最相关的。然后做这种召回，那整个这个就是整个 reg agent 里面一个核心的能力，就是相当于第一个它可以把这个结构化、半结构化，还有这个非结构化数据 从上层的这个应用的角度来说存在一起。第二个的话就是会把这些数据全部做成这种语义关系，还有这种关键字，然后最终做统一的这种召回。那这里面 扩展一下，比如说我就可以做这种文搜图图、搜图图、搜视频文搜视频等等，只要这里面有 inviting 和这个关系搜索，我其实都可以把它搜出来啊，这个是我们的这个 reg agent， 对，然后下面就是我们其实在那个 superbase 里面的话，其实提供了多种丰富的这种接入方式，能够和我们整个的这个 ai 生态做集成。 那比如说，呃，基于云上的这种标准的 open api， 它可以对这个 superbase 实力的话做这种全周期的生命管理， 还有就是配置安全，还有就是这个数据版本的管理，那像这种数据版本管理的话，你就可以比如说接到这个 get 的 这个 action 里面去，然后像这个生命周期管理，你可以接入到这个 runtime 里面去，然后集成到自己公司的这个 c i c d 的 这个流程里面去。 然后第二个的话，就是这个提供的这个 endpoints 里面的话，我们是提供的像这种公网 ip， 还有弹性公网 ip， 还有公网。 net， 如果不想开公网的话，还提供这种 vpc 内部的这种服务。还有就是安全组，那就像这种公网的话，可以自己去挂自己公司的域名 dns， 然后上传自己公司的这种证书，然后对外提供这种域名服务。然后第二个的话，就像这种 endpoints， 对 吧？比如说我这个 reg agent 有 这个 endpoints 的 话，我其实可以集成到像 diffi 或者 n 八 n 这种 agent 的 这种 workflow 编排的工具里面去， 去增强它的比如说迭发里面的这种 rek 的 能力，对吧？然后第三个 m c p， m c p 的 话，这个大家都非常熟悉，在 as 的 m c p 是 这个 a 件词里面的这个 使用最大的这种这种接入协议，那里面的话，其实我们在 m c p 里面的话，像提供了像这种 projects 的 管理，然后像认证 data base， 还有像这个 docs。 因为刚刚其实前面有几位同学其实也提到了像这种 context 七这种框架，那 context 七这种框架的话，它是把很多的这个开源的这种文档 sdk 的 文档扒到一起，然后你在 ai 这个 ai ide 里面去做这种集成搜索，能够让你生成更这个准确的代码。而且这个 doc 也是就是呃官方集成的这个它的这个 doc 的 这个服务，那么通过这个 doc 你在集成 software based 的 时候，那可以把这个 software based 的 这个代码能够生成的更准确。然后最后就是这个 rek， 然后 sdk 里面的话，它其实提供了几种比较主流的，像 gsts， python， 还有一些这种移动 app 开发的这种这种框架，那可以方便地集成到这个 app 的 这个开发里面。那 sdk 的 话，像这种呃 revit lovable， 像这个阿里的这个 code， 那么都可以通过 m c p 或者 s d k 去做集成。那最后它其实还是提供了最传统的这种 j d b c 的 访问方式，那这种 j d b c 的 访问方式的话，在这种 agent 和 context engineering 的 这个工程里面的话，其实像很多的这种热门的这种框架，像曼谷林，像 long graph 这种，它的天然支持这种 g d p c 的 方式集成，这个收费费。所以通过这五种这种按这种不同的这种接口都要暴露的服务的接口，那么可以都可以集成到我们现在在这个 ai 口令和 ai 开发里面的所有的主流的框架里面，对是非常方便的。 对，那有了这种集成之后，那呃大家可以考虑一下，就是说在这个我们常规的这种代码开发里面，那代码的话其实它是有做这个 get 集成的 get 来管理我这个代码的这个版本。那在 ai 构建时代的话，其实 我们的这个版本的这个变更的这个频率会变得异常的高，因为你只要基本上输入一个 prompt， 那 ai coding 就 开始开始工作了，那他有可能 会把你的这个原来好的这个版本的代码改坏。那比如说我要新增一个，比如说在一个 app 里新增一个资产管理的一个东西，那他要在资产管理里面 去写一段逻辑，然后在资产管理里面需要新增一张这个表去管理这个资产相关的信息，那他有可能会把我之前的这个代码还有我的这个数据库搞坏。那现在代码的话，其实我们有存储解决方案，其实就是 get 去去管理这个代码的版本，那与之对应的我的这个数据怎么去管理？我不想让这个 ai coding 去把我线上数据库的这些 库表 schema 改坏，因为这个有可能是不可回退的，因为数据啊数据没有像代码那样那么容易回退，因为数据的回退其实是很麻烦的。所以这个地方的话，其实也是像海外的一些这种数据库厂商， 他们开始在这个 ai coding 时代的话，提出了这个数据的编程的概念，那么我们在这个数据库下其实也是实现了这么一套这个数据的这个编程，那大家可以看到其实它的这个编程和我们这个代码的这个编程其实一对应的。那传统的比如说从命分之到 代五分之，再到两个 future 分 之，那么我两个 future 分 之可能需要实现两个新的特性，需要每一个特性需要自己形成两张表， 那么我们就可以从我们这个带五分支去拉两个新的这个 superbase 的 branch 出来。那这个数据和我的这个带五分支数据和 main 数据是完全隔离的，也就是在它上面的变动不会影响到带五分支和 main 分 支，这样保证我那个线上的这个稳定性。 然后的话每一个分支的话它都有自己的这个 endpoint 能够供我这个应用去部署，去访问。 对，这样的话我们就能做到这个从代码层面到这个数据层面都有统一的这个版本管理，这样的话也就是，呃做到了，就是说我的前后段发布的时候，我可以做到版本的一个统一，不用再去呃做多团队之间的这个沟通。 那通过这个建 ai 平台，通过我们提供的这个 mcp 和 open api， 就 能统一做到这个数据加代码，同时这个管理的这么一个能力，对， ok。 然后上面的话，其实把这个 softwarebase 里面的核心能力都大概介绍了一遍，那么下面就可以我来介绍一下，就是说 arduino 在 ai coding 上面的一些实践。 那，呃，比如说现在，其实，呃自从我们这个 superbase 发布以来的话，其实出现一个非常有意思的现象，就是 和我打交道的客户已经慢慢地从这个传统的 dba 团队逐渐地往这个前端团队 转变，也就是现在其实我很多打交道的客户都是前端团队的同学，那么，呃，现在很多公司他们其实都有这种 ai 提效的这么一个 okr， 对 吧？需要用 ai 给自己公司内部的这些流程之类的做这种提效，那 其实很多时候我们都要去建一个这种 gai 的 平台，不管是给这个 pd 也好，给这个权限也好，对吧？那做一个 gai 平台的这么一个实践流程的话，其实，呃可以分三个部分。然后第一个的话，其实就是 在这个平台上面，我要去实现整个比如说公司的这种认证体系的接入，因为每个公司都有自己的这个 认证的这个平台就是个人用户啊，个人的这个员工的这个认证，那上面这一部分的话，其实就是基于这个搜索背时的长期记忆，去给这个 ai coding 这个平台去管理这些公司内部的知识库， 然后通过这个 out 的 话去借公司内部的这个认证平台，对吧？那这样的话，其实借完之后，那我的管理员的话，其实可以根据我的这个组织架构 去分不同的这个 data set， 那 这个 data set 里面，比如说我的研发一组，研发二组里面它有自己的这个研发规范， 因为这个研发研发规范外部的这种扣电大模型是完全不知道的公司特有的。然后第二个的话，就是在研发体系里面 有很多时候会自己去实现一些这个 sdk， 就是 公司特有的 sdk， 不 管是基于开源魔改也好，还是说从零到一建设也好，都有这种 sdk 的 文档，那这个在外部他也是不可能知道的，所以可以继续对它 set 去做这个文档的管理。权限管理，那 进入到这个 gai 平台之后，那么首先可能我们的这个进入的时候做一个登录来取得这个员工，他对应的这个 role 是 什么？那比如说就是这个 role， 可能就是，比如说我是研发一组的研发同学， 那是研发二组，还有像这种产品组，那么他们去找这个知识库里面的知识的时候，天然通过这个文档权限管理，每个员工只能获取到自己有权限获取的这些文档， 那获取出来之后，把这些文档放到这个 prompt 里面，然后去跟我们下面的这种生成代码的 agent 也好， bugfix 的 agent 也好，或者其他这种 agent 编排的流程去做打交道，然后去生成这个项目工程， 那这个项目工程的话，呃，可能每一个项目工程它都要独立嘛？它这个如果共用一个这个 server base 的 话，它可能存在这个重复的这个数据的这个访问的问题，那在这个里面的话， 呃 server base 的 话就有另外一个作用，其实它是去支撑这个我深层的应用，底层的这个 back end 的 这个服务。 所以 superbase 在 这个里面有两个作用，第一个是在这个 gai 平台里面去做这种权限的管理，那在权限管理完了之后，基于我的这种 log 文档去生成应用之后，那么我的 superbase 又可以去支撑我的这个项目去做部署，然后提供这种数据服务， 对吧？那比如说我下面在这个 superbase 这个里面的话，给这个 ai 应用还有这个 ai 智能生成了一批这种 呃 sapbase 的 这个实力，然后放到一个娱乐池里面，我上传一个 prompt， 生成一个应用之后，自动绑定一个空的这个 sapbase 去给它提供服务。那在这个过程中的话，其实这个 ai coding 的 话，基于你的这个 sapbase 的 配置去生成它对应的库表， 它对应的那个接口的 sdk， 然后写到比如像我们的这种 ts 代码里面，那然后上传到这个这些代码的话，去在 git git 上托管。 然后这个时候我们比如在云上做一些这种函数计算的这种服务，那么他监听到这个 get 的 这个提交记录之后，他自动去把这个代码给你拉下来部署，那这个时候应用就已经完成整个的上线和对外服务，那可以做到一个一体化的这种这种这种体验。 然后第三个的话，就是，呃，刚刚其实也说到了内部文档，其实是非常私域的文档，没有哪个公司想把自己的这种核心文档放到这种呃公开的这个服务上去。那这里面的话，其实像在这个说被子平台里面的话，我们在模型服务里面的话， 呃开箱可以支持这种百炼模型，那可以比如说做一些这种 poc 验证，那还有像这种可以对接不同的这种编程模型，比如像 cloud、 gmail 或者说这昆山 code。 然后第三个的话，比如说你要想这个，呃安全性更高一点，那比如说可以在云上买一些这种大的这种 gpu 服务， gpu 机器去部署自己的私域化模型，然后把这个 application 配置到这个数据库里面来，这样 保证了这个呃整个文档的这种安全性。对，这是整个建 a p i 平台的一个整体的实践的一个流程。 那刚刚说，呃，比如说我 promt， 我 想做一个企业的这种 rack 的 自助库管理的平台，那我下面生成好了这个工程之后，我就直接通过一个这个底下的这个 storebase 提供这个 rack 服务了。那 比如说这个呃生成的这个平台整个的这个流走向是这样的，然后右边那个的话，其实是我们基于这个客户给的这个 p r d 文档， 就是产品原型文档，然后通过多人的自动对话调试生成的一个这种 red 平台的这种 demo。 那 整个流程的话，其实呃开发者通过这个或者说产品经理通过这个 p r d 去定义产品原型之后，我们进入到这个 g i 平台的这个 word 里面去做这个 prom 的 去生成这个代码，然后去做部署。那比如说我在这个里面实现了像这种文档管理、消息推送， 还有生成式对话，还有就像用户管理这四个功能的话，那首先的话，比如说我的这个管理员他有这个权限去上传文档，那么他通过这个文档管理的这一个服务上传文档，然后我们做刚刚说的这种 autore 白顶， 然后生成了引爆点之后的话，其实他会往这个数据库里面去插一条这个文档解析的这个记录。这个时候的话，我们就可以用刚刚说的这个 real time 这种基于 webshop 的 这种双向同步机制去做这个消息同步告诉这个管理员这篇文档已经解析好了，因为文档可能是个异步的过程，那基于 real time 我 可以做一个消息队的管理。解析好之后，那接下来我的这个用户首先登录这个 re 的 这个平台，那么他取得他的一个 role， 那他取了他的一个 ro 之后的话，他开始基于这个平台去做这个生成式对话管理去问，呃，比如说我公司某某某产品的 今年的这个销量怎么怎么样？那如果这个 ro 是 有这个这个文档的访问权限的话，那么他基于这个 prom 加上这个文档内容去跟这个大模型对话，那最后大模型能够给他生成正确的这个 response 回来，这就是整个一个基于 superbase 的 一个应用里面，它是这个数据是怎么流转的？对， 对，所以大家其实可以看到这个最终的这个效果其实还可以比较超出我的预期。那后面随着这个 code 模型越来越强大的话，我觉得这个后面生成的这个应用的这个能力也会越来越强大。 对，然后最后的话就是给大家举几个现在，比如说国内还在也在用这个 superbase， 阿迪斯 superbase 的 一些平台，那第一个的话就是像这个蚂蚁的这个 vivo fox 平台， 那他们现在已经全面接入这个阿迪斯 superbase， 那 那大家其实看到这个是一个，这三个平台其实都是类似的一个通过开启对话的方式，然后去绑定一个数据库生成应用。那比如像这个 vivo fox 里面的话， 那我们从这个输入这个 promont 里面，我，我比如说让他开发一个这个什么呃请假管理的平台，那这个时候它其实里面内置了一些这个 agent 的 一个 workflow， 然后最下面大家可以看到的话，就是它有一个确认是否存到这个云端数据库，那这个其实就是 r 的是 superbase 的 sdk 去生成了很多的这种相关的这种底层数据的调用的这种接口，然后最后他可以做这种自动化的部署，部署到平台上。那另两个像像淘宝的这个 yy 平台， 还有像一个海外初创的这么一个这个 gai 的 平台，他们其实在这个界面上都集成了这种起用数据库，那其实就底层就是通过 support 来给他们提供这种应用的数据支撑，对， 对， ok， 然后最后做个总结，就是，其实啊我觉得现在像这种阿迪斯威这种巴斯夫的话，能够成为这种前端的好伙伴，能够让前端同学也能够比较轻松的去打造一个自己的这种 gai 的 平台， 对，让这个后端变得不再那么神秘，对， ok， 这个是呃我们阿力士 pg 和收腹背子的交流群，然后如果大家感兴趣的话可以进群，然后在群里可以找到我。 如果后续比如说有一些这种呃产品上的这种想试用啊或怎么样的话，都可以在群里面艾特我，我会支撑好大家，谢谢大家，这是我今天的分享。