粉丝42.4万获赞455.7万

大家好,欢迎回到我的频道。 antropic 刚刚为 cloud code 推出了一个重磅更新, 这次更新的核心是自动化代码审查,这项功能就叫 code review。 目前该功能已向团队版和企业版用户开放研究预览。 如果你平时在团队中写作,已经受够了漫长的代码审查等待,或者总有 bug 没被查出来就上线了,那这个功能绝对是你的福音。接下来我们看看它的具体功能。 简单来说,只要管理员未组织开启该功能,它就会通过 github app 连接到你的代码仓库。之后,每当你提交拉取请求或向 pr 分 支推送代码时, cloud 都会自动审查你的代码。 而且它不只是进行简单的表面检查,它利用多个专门化代理并行分析代码变更, 并结合整个代码库的完整上下文。我所说的完整上下文是指它不只是查看代码差异而已,它会分析周边的代码导入项以及依赖关系, 包含所有关键信息来判断你的修改是否会引发故障。它能检测逻辑错误、安全漏洞、异常的边界情况以及细微的回归问题。 说实话,这确实非常厉害,而这就是它的与众不同之处。整个流程中内置了一个验证环节,在 a 键识别出潜在问题后,还会对这些后选进行二次检查,结合实际代码行为,从而过滤掉误报。 随后系统会自动去重,并按严重程度排序,最后发布以行内注示的形式标注在发现问题的代码行下方。如果未发现任何问题, cloud 只会在 p r 中留下一条简短的确认信息。 这种体验真的很赞,严重程度系统的运作方式是为发现的每个问题打上级别标签。 红色代表常规 bug, 必须在合并前修复。黄色代表小瑕疵,指那些值得改进但不影响合并的小问题。紫色则代表代码库中早已存在的旧 bug, 并非由你当前的 pr 所导致。这个紫色标签的设计非常贴心,因为它能帮你识别遗留问题,而不会误怪到当前的 pr 作者头上。 我觉得很多团队都会非常认可这种细微的区分。另外,我非常喜欢的一点是,代码审查并不会自动批准或拦截你的 pr, 它只会在发现问题的代码行直接添加行内注示, 这样你现有的审查流程就能完全保持原样。人工审核依然拥有完全的控制权。每个发现的问题旁都有可折叠的逻辑说明,方便你展开查看,从而准确了解 cloud 标记问题的原因 以及相关的验证过程。这非常有帮助,因为你得到的不再是没头没脑的警告,而是完整的推理逻辑。 现在来看看如何进行设置。整个过程其实非常简单直观。管理员只需进入 cloud 管理员设置页面,找到代码审查板块,点击设置后,系统会引导你在 github 组织中安装 cloud 的 应用, 该应用会请求读写权限。针对代码内容, esu 和 pr 安装完成后,选择要启动代码审查的仓库, 接着为每个仓库选择一种触发方式。你可以设置为仅在创建 pr 时审查,即在 pr 开启时仅运行一次,或者设为每次向 pr 分 支推送时审查, 以便在 pr 迭代中及时捕捉新问题,修复标记的问题后甚至能自动解决评论。这个自动解决功能非常赞,因为这能让你在迭代时保持 pr 的 整洁。 你还可以通过添加 cloud md 文件或 review 导 m 的 文件到仓库来自定义检查规则。 cloud dl 适用于所有 cloud code 任务,而不局限于代码审查。所以如果你已经有了包含项目指令的文件, code, review 会读取它,并将新引入的违规项视为琐碎级别的建议, 甚至反过来也行得通。如果你的 pr 修改了代码,导致 cloud md 中的规则不再适用, cloud 也会提醒你需要同步更新文档。这功能简直太赞了! review the md 文件专门用来存放代码审查规则。 你可以在其中定义诸多团队的代码风格指南或特定框架的开发,约定 cloud 必须指出的事项。例如任何新增的 api 路由都必须包含集成测试,也可以设置忽略像,比如无需对代码格式或自动生成的代码进行评论, cloud 会自动检测仓库跟目录下的 review data made 文件,因此无需进行任何额外配置。这一点也同样非常出色。接下来我们聊聊定价, 因为这部分内容非常有看点。每次 pr 的 审查费用平均在十五到二十五美元之间,费用取决于 pr 规模和代码库的复杂度, 审查平均耗时约二十分钟。如果你设置为每次推送都审查,而非仅在创建 pr 时,显然成本会随着推送次数成倍增加。 因此我建议先设置为仅在创建 p r 时触发,之后再针对那些确实需要持续覆盖的代码库切换到推送时触发。此外还有分析仪表板,方便管理员进行局监控。 你可以查看每日 pr 审查数、每周支出及反馈统计,其中包括已自动解决的评论数量,包含开发者修复问题的统计,以及按仓库划分的详细明细。 管理员设置中还会显示每个仓库的平均审查成本,你甚至可以在使用设置页面中设置每月支出上限。总之,这里提供了丰富的控制选项来压低成本。 另外需要说明的是,此功能不适用于其用了零数据保留的组织。 如果你想运行 code 在 自己的 c i 基础设施中而不使用这项托管服务, 你也可以使用 close code 配合 gitup actions 或 gitlab c i c d。 总的来说,这是一次非常有诚意的功能更新。 如果你使用的是 teams 或是企业版用户,且希望自动化代码审查能真正读懂你的代码库,那这个功能非常值得关注。虽然它目前并不完美,毕竟还处于研究预览版,且每个 p r 十五到二十五美元的成本。 对于 p r 平凡的团队来说,这笔开销会积少成多,但其多智能体架构、积少成多标签系统 以及通过 review 点 md 实现的自定义配置表现都非常亮眼。我相信大型团队会发现它非常实用,能在人工审查之外再加一层安全兜底。总的来说,这个功能挺棒的。我们下期视频再见。拜拜!

anthropic 为了抢 open ai 的 用户,出了一个匪夷所思的大招,叫做导入记忆 import memory, 因为很多人在使用 ai 的 三助手,它的最核心的壁垒就是有记忆,用的越多呢,越熟悉聊天内容模型都能记住,所以这也是为什么很多用户不愿意从叉 g b 离开的原因, 因为叉 g b 是 最早的推出 ai 的 聊天机器人。 anthropic 呢,虽然有很强的模型,但是在前期更多的 focus 专注点是在企业端,我 是 consumer, 而这次呢,为了去把这位用户抢过来呢, adopter 呢,有一个非常有效的,可以说是骚操作吧,就是给用户提供了一段提示词,用户只要在叉 g b 中通过粘贴这份提示词呢,就可以获取系统记录的个人的记忆的内容,然后再把这份记忆内容呢复 是粘贴到 cloud 的 记忆设置页面,系统就会自动的识别并整合这些内容到现有的记忆结构中。整个过程呢,是无需导出特殊的文件,无需使用 api, 无需技术的配置,也不涉及,比如说数据结构的处理或者账号绑定, 耗时呢,不超过一分钟。这种低摩擦的迁移方式呢,显著的降低用户在不同的 ai 平台间切换的心理跟操作成本,主要的就是 gpt 到 cloud。 当然他这个牵引呢,主要是他的一些理解,可以说是原数据 mate data。 一 般来说,记忆呢,他都会分成一些数据结构,比如说人物,他的年龄,性别,姓名,他的兴趣,以及他沟通的一些卡片中的一些核心的一些特困信息, 虽然他不会去涉及到用户的隐私数据,我觉得这是一个非常有效的方式来热启动一些新的 ai 的 应用,让用户一上来就体验到他在其他的 ai 产品中的一些记忆的流盘,所以我们呢也会按照这样的思路推动一下记忆的迁移。

在软件开发过程中,同行评选一直是保障软件质量的重要环节,它能够早期发现漏洞,保持代码库的一致性。然而,随着氛围编程的兴起,开发者借助 ai 工具,通过自然语言指令就能快速生成大量代码。这让传统的评选机制遭遇了新挑战, 因为这类工具虽然显著加速了开发流程,但也带来了新型漏洞、安全风险以及难以理解的代码等问题。 为应对这一趋势,人工智能公司 osmic 在 本周一推出了全新产品 cold review, 并将其集成于 cloud code 平台。目前, cloud code 在 企业用户中增长迅猛,大量自动生成地拉取请求,让代码审查成了交付瓶颈, 而 code review 正是针对这一问题的解决方案。该工具首阶段面向 cloud for teams 与 cloud for enterprise 客户开放研究预览版 code review 主要面向以大规模采用 cloud code 的 大型企业团队,技术负责人可一键起用。 它会与 github 深度集成,自动分析每个拉取请求,并直接在代码行添加评论,指出潜在问题及修复建议。值得注意的是,它聚焦于逻辑错误而非代码风格,因为可操作性不强的建议容易引发开发者反感。 当然,使用这款工具是有成本的,它采用按 token 计费模式,单次审查平均成本在十五至二十五美元, 具体取决于代码复杂度。不过,在 ai 深层代码加以普及的当下,这将成为必要的投入。 anthropic 希望借助 code review 助力企业以前所未有的速度构建更少漏洞的软件。关注科技趋巧,看见更全面的科技世界。

这是我被 cloud code 封的第三个号了,申诉也没有用,我现在已经准备放弃官方订阅了,不想折腾了。那 open code 一 直很火,最近我也在开始用它了,尤其是 cloud off 四点六和 gpt 五点三 codex 出来之后, 我现在是多个模型配合去干活。那发挥每个模型的优势,用四点六去做架构设计,用五点三 codex 去做代码执行,如果有前端的一个 ui 需求的话,再拿 gmail 三点零 pro 去做前端的一个 ui。 那 opencode 到底是什么呢?用一句话,它其实就是一个开源版的 curlcode, 功能上的话两者差不多,但 opencode 有 一些独特的优势,就是它是一个任意模型,你可以支持多家厂商的, 你也可以用国产的,你也可以用国外的模型都支持。第二点就是代码完全开源免费,这一点非常重要,你可以自己去改,自己去定制。同时代码开源之后,那开源社区的人就可以去围绕它做很多功能,毕竟人多力量大嘛。比如这个插件 opencode, 这就是社区去搞的,现在已经三十 k star 了。 这个插件其实是一套多 agent 多魔性去协助干活的一个插件,最近我体验下来也挺好用的。它这边准备了十个 agent, 有 主控 agent, 有 去专门干代码的,专门去探索代码的,也专门去做前端 ui 的, 挺好用的。 open code 整个的架构的话,其实跟那个 cloud code 差不多,用户输入成有绘画管理嘛,然后有 agent, 有 plan 就 计划,那 kolco 的 那边也有,那有 build 就是 直接干活的嘛,还有些探索的,其实 kolco 的 那边不是都有吗?以及你制定一些 agent 都有,那调度层这边就有些差别了。关于大模型的调度,因为 kolco 的 那边他只支持 angelic 协议的嘛,那这边的话就是实现了一套支持其他各种供应商的整体的架构的话,其实有很多值得学习的地方,如果大家对 kolco 感兴趣了,可以去他官方原码仓库去拉下来去学一下,那个仓库现在已经一百多 k 了,特别火。 那下面就是这个 oh my open code, 这个是我们今天讲的重点,因为他这一套多 a 镜的多模型的一个机制, 能让一个任务去拆解成各个阶段去开发,有复杂的用复杂的模型,简单的用简单的模型,这种才是一个 理想状态下的一个写作的方式嘛。那它本质上就是我刚才说的,它就是一个插件,通过 open code 暴露的一些钩子去拦截这一个 ai 的 一些行为,它的整个工作流程就是来一个用户输入之后,它去拦截 open code 的 一些钩子,这时候去做一些增强上下文呀,或者去选择多 a 帧特有可能是多个模型去协助,最后返回结果整体的一个流程就是这样子的。 那为什么需要多个代理?哈?他这边说的一个说法是专业的代理去做专业的事情,然后规划和执行分离,可以并行执行,按需去选模型,并且节省成本。那他现在这一个多代理的话, 就像最近 cloud code 新出的那个 agent teams 一 样,只不过 cloud code 它是很久很久之后才出的嘛,这个是老早就有了 omago code, 那 下面是它的一些 agent 的 一个分工,这一个是它的一个主要 agent 是 用了 cloud 的 off 四点六这个模型。 还有一些规划师就是在规划方面以及编排方面,他用的卡尔的最顶尖的模型,那代码磁性这一块的话是用的是 gbt 五点三 codex, 如果是一些比较轻量的任务,你可以用 gm 啊,或者 mini max 啊,以及其他都可以。那些前端这块的话,他用的 jimmy 三 plus 或者 pro, 这样子的话就一个任务进来之后他由这个去规划,规划完了之后,他让 jimmy 五点三去做执行,然后发现有前端任务,他这个时候就用 jimmy。 如果涉及到一些小修小改啊,比如说是一些国际化处理啊,多语言处理,这个时候它就完全可以用很低的那种模型去做这个事情嘛。这样的一个搭配其实我体验下来挺好的。 好,下面我们就开始分别去安装 opencode 和 oemopencode 的 这个插件。桌面端它现在也支持了,支持 macos、 windows、 linux, 我 体验下来的话,它有一些断流的情况,所以说我更推荐大家在使用 cio 版本,我们先来安装一下。 好,它提示我们已经安装了,我们来进去看一下,我们先切到一个免费的模型,你上面搜一个 free 这些模型的免费,我就用 mini max m 二点一吧,我们输入一下测试一下,看它安装好没有。 ok, 如果看到这步就证明你 open code 已经安装好了,这个时候我们就有安装那个插件,因为现在在 ai 时代,其实你安装东西都非常方便,尤其是它如果有文档,有开箱库的话, 你看这一个插件哈,欧麦 opencode 的 一个官方仓库里面直接就告诉你了,你直接用 qq 编辑的去装就行了,我就把这个复制一下,然后粘到刚刚我们开的这个 opencode 的 里面,用免费的 mini max 让他给我们去装,那下面就是他会弹出来让你做一些选择, 可以看到他让我们回答一些问题嘛,你有没有订阅 cloud code, 有 没有订阅 openai, 有 没有一些 jimmy 的 一些 model, 你 就根据自己的情况去选择就行了。强烈建议你不要在 open code 里面去用 cloud 的 模型,通过订阅的方式去用封号的概率非常高。那这边我就说都没有, 待会我也给大家一个配置,直接就可以用了,你只需要去搞一个 api k 过来,你就可以直接把这些模型都用上了,这时候我们都说都没有就完事了,因为这个配置后期都可以去改的。可以看到我们把插件安装成功之后,下面的这一个 a 镜头就变了,变成了 omone code, 它的那一套多 a 型的体系,可以看到它有好几个 a 型的体系可以去用,并且 这个插件那还有个好处,它的兼容性做得比较好。它已经把 cloud code 那 边你有的一些 skills, mcp, 还有那些自定义的命令全部弄过来了,比如说 skills 可以看到我的那些 script 它全部弄过来了,这样非常好。也就是说你可以来回签嘛,你有时候你要回去 copy 到那边用也可以。现在我们开始配模型,你可以通过 connect 这个命令去连接你想要的一些模型, 如果你有恰当的 gpt, 里面就选恰当的 gpt, 你 有其他的你就选其他的。那我这边的话,平时会用 jimmy 三点零去写前端嘛 code, 四点六去写架构和具体的一些代码,然后 gpt 五点三 codex 去做一些代码之星,以及解决一些疑难杂症。我喜欢用每一个模型擅长的能力哈,但是对大家来说的话,你如果像我一样去订阅三家的 ai 模型,其实你要花三分钱。我 订阅的一百刀的 code code, 然后今门来我订阅了两个号,一百四十刀, open ai 我 订阅了二十刀,那加起来就是一百六十刀。并且哈,我们刚也说了,如果你用 code code 的 去 授权到这边 opencode 的 去用的话,你封号的概率特别高。之前我还出了一期视频,专门去讲这个 curlcode 的 大面积去封禁 opencode 的 用户的一个事件, 因为刚开始他是不管的,后面他发现这个 opencode 的 日渐壮大之后,他就开始封禁了,你就不能授权到这里面用。 所以如果你要在 opencode 里面去用 cloudof 四点六的一个模型,我建议大家去用中转站,通过按 api 去计费用多少就算多少。那我这边推荐一个我一直在用的中转站接口 i, opencode 的 这边也已经支持了接口 i, 也就官方支持了嘛。 那前面几期视频我也推荐过,如果我要用到一些国外的模型,按 api 调用的话,我都用的是接口 i, 挺稳定的。最关键的一点,你不需要模仿网络,而且是国内付款的一个方式。 最近他们还专门针对海外的顶尖模型增加了一个套餐的方式,也就是说你可以用一份钱去用国外这些顶尖模型呢,目前有三个档位哈,可以按自己的一个需要去选择,相较于官方 api 按量计费的话,这一个套餐模式帮你省了百分之二十五的钱。 好,下面我们先来去创建一个 api key, 在 这个地方新建,我就随便取一个,我们就取 opencode 的 点击复制。这个时候我们回到 opencode 的 这边 附着 apk 之后,我们供应商选择接口,点 ai 敲击回车,把我们的 apk 输入下,然后保存,这时候你可以看到国内国外的模型都可以用,用一个 apk 你 就解决了多模型的一个适配问题。好,下面我们来进行一些其他的配置。 当你安装完 open code 以及欧曼 open code 插件之后,你会在你的工作目录下面点 config, 下面有一个 open code 目录,这里面有两个节省的配置文件,一个是配置 open code 的 一些模型的,另外一个是配置我们这一个 多 a 帧的协助的时候,它具体用哪些模型。这边的话我给大家直接准备了现成的,你直接到我的一个开源仓库里面直接去复制就可以了。下面来我这一个开源仓库里面,直接把这两个配置可以复制一下,把它粘过去就完事了。 好,我们把它覆盖一下保存,再把 omecode 的 也复制一下回来点击复制。 那这一块的话,你可以根据你自己的需要哈,因为 gpt 五点三这一个扣袋子模型的话,官方是没有出 api 的 版本,那后续如果 open i 那 边出了 api 版本接口, i 这边也会跟上,你就根据自己的需要嘛去看这块要不要注视这个内容,我们来复制一下。 好,我们把它覆盖完了,覆盖完了之后,我们重启一下,你就可以看到 color 的 open 四点六已经可用了, 就这几个 a 帧的,它配置的模型都可用了。那下面我们开始进入实战的一个环节,有了 o my open code 插件之后,我们看一下多 a 帧多模型协助的一个流程。我这边有一个纹身图的 a 帧,我希望让它去加一些功能,在这边加一些删除的动作,能把历史记录删除掉,同时在左下角 做一些设置的动作,可以去更新你的一些头像啊,以及我们那些历史提示词,能支持去快速的复制展开开干, 那提示词的话也比较简单,我们这边加一个 alterwork, 让它去更深入的去工作,去分析。 好,我们切到 opencode 这边,这个就是它的整个架构 agent, 它用的是 off 四点六,那这个的话是干活的 agent, 它用的 gpt 五点三,还有些其他的 agent, 也就说它是多 agent 多模型去写作的一个流程。好,我们把提示词粘过来让它干活, 这里提示 autowork 已经开启了,这个时候可以看到它开启了一个探索的沙背 a 技能吗?用的是很便宜的一个模型,这个过程就跟在 clockcode 的是一样的,这里又开了一个新的, 可以看到它一直在开一些新的沙背 a 技能的任务去做探索。啊。好,这里又开启了一个计划的 task, 也就是一个沙背 a 技能,我可以点进去看一下它在做什么, 可以看到他就是把已有收集到的一些代码信息,整个代码空间来去做一轮分析,让这个 off 四点六做一个计划出来,这个时候他这一个主要的协调 a 技能在等,等他这个后台的这个计划任务完成完了之后,这个时候他再去协调其他的 a 技能去干活。 可以看到它这一个经过几轮的一个探索之后哈它得到了一个突突像,那这个突突像的话,它根据后端、前端以及一些小需求拆成了很多突突像,这个时候它就开始去并行执行修改任务了,可以看到它这里又开启了几个 safari 的。 有一个点要看的话是他的这个三倍镜,他开的时候,他其实这个时候是用的 jamal 三 plus 这个模型,也就说他认为这个任务其你根本就没必要用一个很高的模型去做这个事情,所以说他默认给你路由到了一个简单模型, 它这种规划任务的方式就能把模型最大化的利用起来。复杂的任务用复杂的模型,简单的任务用简单的模型就很完美。可以看到它开始去执行 t 四跟 t 六这两个任务了,而且它依赖关系也找出来了。这个就像前两天发布的 cloud agent teams 的 一个写作流程,只不过这个是老早就有了这个插件老早就有了这种多 a 的 写作,最终被 cloud code 写到一个官方的库里面去了。 然后他们那种通信机制就跟爱信的 tim 是 很像。哎呀妈这个系统通知 coco 的, 其实他很多方案是借鉴了社区的,因为社区搞出来之后, 他觉得确实是 ok, 可以 的,那他就把它集成到 coco 的 里面。所以这 coco 的 从它诞生之后的很多功能迭代都参考了开元社区的一些做法,而且他的也在他的一些技术博克里面有,感谢一些开元社区的人提供了一些解决方案。 就像你做产品一样,你产品迭代的过程中,你光靠产品经理去,有时候发觉不了用户的一些真实的需求,那真实的需求暴露出来之后,社区他就解决了,那你就可以去把一些已经解决的痛点的问题提升到自己的产品里面。 可以看到这所有的凸凸像它全部完成了哈,包含三个任务,我们现在来看一下它整体的效果怎么样。首先是左侧的这个删除功能好,确认删除 ok, 确认可以,并且弹窗也是正常的。其实我们看这个可以复制已有的提示词, 可以复制折叠展开是 ok 的。 下面就是这一个左下角的设置,可以去更新昵称跟头像这一些啊,可以看到他这边其实也做好了。 好,我找一张图像试一下看可以吗?前面加一个我的名字吧,看可以吗? 可以,已经保存了。可以的,这个看起来他做的挺好的,英文啊,英文设置也是 ok 的, 多源设置也是 ok 的。 整体这一次任务的话,他全部搞定了呀,就是虽然不是特别难的,但是他协调了多个 a 镜的去干活,而且都能交付的很完美,中间我没有做任何的介入, 所以说这个工具啊,真的推荐大家去用一下这个多 a 镜的协助真的挺好用的,下面我来总结一下。使用 open code 再加那个插件, open code 再配合你用一个接口外的中转站,可以做到 模型自由稳定,省心,你也不怕被封号。第二个的话是成本灵活,这就是今天所有的视频内容,如果你觉得这期视频对你有帮助的话,可以给我一件善良,谢谢大家。拜拜。拜拜。

去年十一月, ansorepic 发布了一系列新的测试版功能,只在解决我们在构建 ai 智能体时遇到的一些实际问题。 工具定义在你发送第一条消息之前就已经占用了大量的上下文。当智能体连续执行多个工具调用时,这些工具调用的中间结果会进一步膨胀上下文。 而且随着你在系统中增加工具的数量,智能体在为任务选择合适工具时会变得非常吃力。因此,这些测试版功能帮助解决了这些问题。而且随着两周前 sony 四点六的发布,这些功能已经在云 api 上全面开放。 在他们的原始帖子中,他们展示了这些功能如何帮助实现了八十五百分之的 token 使用量减少。 这也导致一些网友宣称 entropic 已经终结了工具调用,或者至少是传统的工具调用方式。虽然这种说法有些夸张而且确实不准确,但这两个功能编程是工具调用和工具搜索工具 确实是非常巧妙的解决方案,在集成到任何 ai 智能体中时都能发挥极高的效用。而且关键在于这些功能并不是云 api 独有的,也并非最初就是 entropic 的 创意。 这些是智能体构建的核心模式,适用于任何框架或模型。我会解释这两种高级工具调用如何运作,并演示如何集成到你的定制智能体中。 这正是我在这里所做的事情。我已经把它集成进了我的系统,这个系统是我用 python 和 react 定制开发的应用,这是我在本频道过去四期视频中逐步搭建出来的。 我还用全新的困三点五,拥有二百七十亿参数的模型来测试这些高级工具调用方法。所以与其直接跳进理论部分,不如我们在应用里演示一下。 而最简单的切入点大概就是先演示一下工具搜索工具。所以即使只是打个招呼,我们也能收到一个简短的回复。但在底部,你可以看到我们正在追踪本次绘画的上下文窗口。 我们已经用了一万三千个 token, 为了弄清楚发生了什么,如果我们切换到 langfuse, 如果我们看一下这个生成追踪,你会发现已经有六十个不同的工具被加载到上下文中了。 虽然听起来很多,但实际上只有两个 mcp, 就是 playrite mcp 和 github mcp, 再加上一些我在前几期节目中开发的工具。 所以工具搜索工具的关键点在于你不会一开始就加载所有内容。你会延迟加载让代理去搜索他,所以他会多出一个额外的步骤。现在我会把这些 m c p 服务器标记为延迟加载,然后让我重启一下服务器。 如果我再次问同样的问题,比如我们打开一个新的聊天窗口,输入 hello, 然后得到一个回复,你可以看到我们现在只用了六千三百个 tokens。 如果我们看一下这个追踪,你会发现现在只有十二个工具被加载到上下文中。第十二个就是这个工具搜索工具。 这个工具允许代理在工具注册表中搜索,通过名称或关键词来发现并加载工具。为了演示工具搜索的实际效果,我们让他获取这个项目的最新提交。这是一个私有项目,所以他需要使用 m c p。 你 可以看到他现在正在触发工具搜索。他找到了一个工具, 就是 list commits 工具,然后他用仓库的信息触发了这个工具。好了,我们得到了提交 id 以及提交内容的信息。 如果我们查看这次工具搜索的响应,你会发现 listcommits 是 一个延迟加载的 mcp 工具,它会把这个工具的完整模式加载到上下文中。 现在这个工具已经被加载到接下来对话的上下文中了。所以如果我再问任何后续问题,就不需要再去搜索这个工具了。比如说给我最后一个提交,我就可以直接使用 listcommits 工具。 如果我们切换到 langfuse, 在 我发送的第一条消息中,你可以看到只有十二个可用工具。然后在它触发工具注册表搜索后, 在下一次调用中,我们有了十三个工具,包括 list commits, 并且它能够对此作出响应。而在我后续的问题中,我们同样有十三个可用工具。 简而言之,这就是工具搜索实际的工作方式。虽然这已经非常有用,但我认为以编程方式调用工具更加令人印象深刻。如果我们开启一个新的聊天,现在我们在 opodder 上使用的是 cloud hikou, 我 一会会切换到 queen 三点五。但我想先给大家展示一下云端模型和开源模型在这里是如何工作的。为此,我们将使用 anthropic 在 其文章中发布的官方示意。 这里他给出了一个预算合规检查的例子。然后问题是哪些团队成员超出了他们第三季度的差旅预算? 这里有三个可用工具,分别是获取团队成员,获取支出和按级别获取预算。他在这里展示了传统的方法,也就是需要大量的工具调用和许多中间响应,这会导致上下文窗口被迅速填满, 所以我已经写好了云端代码来生成这个场景的虚拟数据。首先我们来看一下传统的做法,我已经关闭了沙河,现在我来提问哪些团队成员超出了他们第三季度的差旅预算。 正如我之前提到的,我们现在用的是嗨酷模型,所以他正在执行工具搜索,获取报销数据,获取团队成员。现在他正按照这种传统方式操作,需要为每一位成员逐一获取报销信息, 让我们看看会得到什么答案。所以第三季度差旅预算分析显示,有三个人超出了他们的差旅预算,这是他给出的结果。 根据测试数据,这个答案是正确的,但实际上应该有四个人,所以他似乎漏掉了一个。 marcus johnson 超出了预算一千七百, 所以这种传统方法实际上消耗了大量的工具调用。实际上有五十六次工具调用。正如你在这里看到的, 它处理了七万六千个 tokens, 但实际上并没有给出一个准确或者说全面的答案。这正是程序化工具调用能够解决的问题,因为所有这些其实都可以通过脚本自动完成。 因为一旦你知道了团队成员和预算水平,你就可以用一个负循环来获取每个用户的开销,并计算实际的超支情况。 那么现在让我们起用沙盒,并尝试用程序化工具调用来实现。好的沙盒已经开启,让我们重启后端,打开一个新的聊天窗口。好的哪些团队成员超出了他们第三季度的差旅预算?现在正在进行工具搜索。他找到了所需的三个工具。 现在他进入了编程模式,并创建了一个即将被执行的脚本。他抛出了一个错误。这其实并不奇怪,因为他并不知道这些工具的输出结构。所以本质上,如果没有所有信息,他就无法一次性完成。 现在他正在不断迭代自己的代码,实际上是在尝试得到一个结果。你可以看到他不断抛出错误,并且正在逐步解决。 与 anthropomorphic 的 论文相比,这可能是更贴近现实的程序化工具调用方式。因为我相信在 anthropomorphic 的 论文中,它是一次性完成的,而实际上并不会这样。经过多次迭代后,我们得到了一个准确的答案, 所以二千二百, sarah, chen, marcus, alex, emily。 所以 我们得到了所有正确的答案。 这很好,但这才是程序化工具调用的现实。它的方法相当迭代,就像 cloud code 或 open code 一 样。出于兴趣,我们再运行一次,看看能不能得到正确的答案。它会不会走一条不同的路径。我们假设是的, 很有趣。这一次它实际上是在预算层面获取团队成员的信息,所以它实际上是先获取所需的数据,然后再生成代码。所以这次它可能一次性就能完成。 但实际上他并没有做到,他仍然在自我迭代。不过我们确实得到了正确的答案,所以结果是对的,每一次都是如此,只是到达结果的路径不同。所以我们来看看这两条追踪记录。在我刚才运行的那一次中,总共进行了六轮调用, 总共调用了十二次工具,总提示词数为五万八千。现在如果我继续这个对话,目前只用了一万三千,但这是在与大语言模型进行了六轮来回交互的情况下。而之前那一次是在十一轮中用了十一万六千个 prof tokens, 都是为了得到正确的答案, 所以我确实没有看到 anthrax 所报告的八十五百分之的 token 节省。但这其实非常依赖具体的用力。 比如说这里我是在和二十个团队成员一起工作的,如果你有两千个团队成员,那情况就完全不同了,因为大圆模型需要运行两千次单独的调用,这根本行不通, 所以在那种情况下,就需要程序化的工具调用。或者你就需要一个真正的端点,让实际的数据处理在服务器端完成,而你只是获取信息并将其展示给用户。所以这其实切中了这个话题的核心。 也就是说,你的大圆模型到底应该像这样临时进行数据处理,还是应该仅仅从一个预先创建的脚本中传递信息? 比如说这个脚本可以放在一个技能文件夹里,因为这是我们在上一个视频中搭建的一个完整的技能部分。你可以有一个 python 文件,一旦创建测试并验证后,它就能真正完成这项工作,或者你也可以把它放在工具调用的 m c p 端,这样它就只是简单地传递接收到的信息。 那么我们把 cloud haiku 换成 queen 三点五二十七亿参数,来看看它的实际表现如何。我现在是在网络上运行这个模型,这里用的是欧拉玛,我有一个十万个上下文窗口长度,这里用的是 rtx 五零九零,显卡有三十二 gb 的 显存。 那么我们保存一下,重启服务器,然后问同样的问题,哪些团队成员超出了他们第三季度的差旅预算?现在加载需要一点时间,因为他需要把模型加载到内存中。好了,他已经触发了工具搜索,然后直接开始生成代码。 他实际上在工具调用之间没有输出文本,但你可以看到他正在生成代码本身,而且他正在经历和嗨酷一样的迭代过程,他正在从错误中学习, 并且在不断完善。看看,这就是我们的答案。让我看看二二百十五十七,还有三百,看起来很准确,我觉得这比嗨酷用的 tokens 更少,这很酷,我们来深入看看追踪记录吧。 是的,这次用了四万五千个 tokens 就 得到了准确的回应,这真的很棒,只用了四次工具调用,这已经相当不错了。这是我们 ai builder 系列的第五个视频。在这个系列中,我们正在用云端代码构建一个功能完善的 ai 系统。 本模块的 prd 可以 在我们的公共 github 仓库中获取完整的课程和代码库则在我们的社区中提供 相关链接在下方描述中。那么好吧,这一切到底是如何运作的呢?因为你可以看到我们正在这里的沙箱中触发代码执行,但这实际上意味着什么呢?所以这是一个完全本地化的系统。 我之前用的是嗨酷配合 open router, 但现在用的是 queen 三点五,这里内置了一些文档和 r a g 功能,使用的是 queen 三的嵌入模型。所以你看到的这个代码执行其实是在 docker 中触发了一个沙箱。你可以看到 现在所有这些容器都已经启动了。这里有一些孤立的容器是因为我一直在重启后端。但总体来说,代码执行都是在这里的一个隔离沙箱中进行的。 而这个架构安全性的一个关键部分就是工具桥的概念。所以从头到尾,当用户提出问题时,他会先到 fast api, 然后到 python, 接着再转发到 ai 模型。无论是远程还是本地的, 我们会收到一个工具调用,也就是你需要去执行这段 python 代码,这时后端就会启动一个沙箱容器。 我在上一个视频里已经介绍过这个的设置过程,但本质上我们用的是这个 github 仓库,也就是 llm sandbox。 这是一个非常清亮即可移植的沙箱环境,你可以配合 docker 这样的工具使用。或者如果你不用 docker, 也可以用 portman。 但本质上,这大大简化了启动这些环境的复杂性。 它们支持多种语言,还有许多不同的高级功能。你可以预先启动容器,而不是按需启动。 你也可以使用自定义镜像。这个项目里有很多很棒的功能,所以我会在描述区留下相关链接。我在上一个视频里已经非常详细的讲解过了,所以基本上我们就触发了那个容器的创建, 然后我们会把代码和一个绘画 id 一 起传递进去。所以现在在这个容器里,我们有一个 python 运行器,它会执行那段代码。在我们之前的例子中,有很多不同的工具需要被触发,比如获取预算水平、获取部门、获取团队成员, 而所有这些都可以存在于比如说一个外部系统中,但我们并不希望让沙乡访问外部服务。 相反,我们创建了一个安全的工具桥梁连接回 python 应用程序,然后每当工具或函数在 python 脚本中被触发时,都必须通过这个桥梁。正如你之前看到的,单个脚本中可能会有五十次不同的 api 调用或工具调用, 所以对于每一次工具调用都需要通过这个桥梁,它会使用绘画 id 来进行身份验证, 然后 python 应用程序会将该调用路由到外部系统获取响应后再将其发送回沙乡。因此,除了访问这个 python 应用程序中的 fast api 之外,沙乡没有任何互联网访问权限。从安全角度来看,你可以对这个 fast api 进行严格限制, 这些限制是基于工具本身的精确模式,所以所有这些工具片段、工具定义都是在创建时作为存根发送到沙箱中的。因此,多个工具调用会在 python 代码中,比如说在一个 for 循环内进行, 而且这样做速度非常快,因为此时你完全忽略了 l l m 没有任何中间代码堵塞上下纹。在这里, l l m 完全不参与这个过程,直到 l l m 完成脚本并生成响应。你在之前的演示中已经看到了, 然后这个响应看起来大致是这样的,这就是我们的脚本结果,然后这个结果会被反馈给 l l m。 l l m 接着可以决定下一步该做什么。 如果它已经获得了所有需要的信息,就可以生成综合响应并返回给用户。或者正如你在演示中看到的,它需要对代码本身进行迭代。在很多情况下,它会生成更多的代码,并再次触发沙盒环境。 这就是端到端的流程。我在这里提到了 gviser, 因为 docker 容器并不是你能拥有的最安全的隔离沙盒,因为它们与整个系统共享内核。 所以为了真正保障像 ram, sandbox 这样的安全性,我建议你搭配 gviser 一 起使用。 cloudflair 曾经做过一些有趣的研究,探讨了 ram 在 生成 python 代码或 type script 以及触发工具和 mcp 方面的有效性。他们发现,当工具以 type script api 的 形式呈现,而不是标准的 mcp 时,智能体能够处理更复杂的工具。 我认为这是有道理的,因为他们在训练时接触了大量原生的 python 和 javascript, 所以 在 cloudflared code mode 版本中,也就是我们所做的类似,他们会把 mcp 的 schema 转换成 type script, 因此 l l m 只是生成 type script 代码来触发 m c p。 这和我们正在做的事情非常相似。所以我刚才提到,工具存根被发送到沙盒中。因此,我们在智能体层面定义的 m c p 和工具会被转换成 python 存根 自动生成的 python 函数。这样,当 ai 为沙盒生成代码时,它实际上只是触发 python 函数, 而且因为这是原声 python, 所以 它在这方面会非常擅长。而且重要的是,沙盒永远不会接触到 api 凭证,它永远不会接触到任何机密信息或类似的内容。 我之前提到过需要高效的工具设计,因为在早期,有太多的 mcp 服务器完全塞满了你的上下文窗口,让你根本无法完成任何实际工作。 即使在 anspec 自己的文章中,他们试图解决的挑战也是关于臃肿的 mcp。 在 这里,他们提到 github 的 mcp 有 三十五个工具和两万六千个 tokens。 但即使是在这篇文章发布之后, github 也发布了他们 mcp 的 新版,现在这个数字大约是四千个 tokens。 所以 在 mcp 和工具调用端其实可以做很多工作来确保不会无谓的给你的上下文窗口增加负担。 最后, entropy 在 他们的高级工具调用工具包中还加入了另一个功能,就是关于工具使用视力的这个概念。因为虽然 jason schema 非常擅长定义结构,但它无法表达使用模式。 他们举了一个例子,比如说截止日期,它的数据类型是自复串。日期格式有很多种传递方式, 那么他们到底希望用哪种日期格式呢?除非你真的引导他,否则大圆模型是不会知道的。所以,通过工具使用势力,你可以为每个字段提供一个势力,以便让大圆模型朝着正确的方向前进。比如在这里,日期格式就是年月 日。在他们的测试中,他们发现这能将复杂参数处理的准确率从七十二百分之提升到九十百分之,这很合理,因为本质上这就是多轮提示。你只是给了一个你想要的视力,这绝对会引导模型朝着正确的方向。 实际上,我不确定你是否需要把这个设置成系统中完全独立的功能。我认为,使用技能这个概念意味着你可以在加载技能时提供视力,这样就可以触发你想要实现的任务的执行顺序。 你会发现 cloud 也有点类似,里面有很多功能是重叠的。 antropic 之所以没有取消工具调用,是因为他们认为你应该有策略力对这些功能进行分层。 所以,如果你的上下文因为工具定义工具搜索而变得臃肿,如果你有大量中间结果污染了上下文,那就走沙河路线。或者,如果 ai 总是把错误的值传递给参数,那么使用工具势利就是有意义的。非常感谢你的观看,我们下期再见。

哈喽,大家好,我们现在来教大家去如何去安装和使用酷呆斯增强版。我们首先 拿到这个 get up 的 地址,我们会在评论区放出来,我们首先访问这个 get up 的 仓库,先进来首先点一个 star, 然后我们再看 安装方法。 mark linux wsl 的 话可以直接使用这一行命令,我们复制它,直接在终端粘贴就可以安装了。 windows 的 也是一样的,复制这一行命令,然后在你的终端 粘贴,然后就可以继续安装了。我们打开我们的终端,然后粘贴刚才的命令,我们直接回车等待它的安装。 安装话跟你的网速有关系,如果你的网速不够快的话,可能需要等一会, 不快,它安装好了,它默认的话会把你二进字文件安装在你的 logo 并目落下的。我们可以检查一下使用命令,我们检查一下它安装好了是不是 ok, 确定安装好之后,我们可以查看一下它的最新版本, 最新版本的话是一点二点零,默认的脚本安装就会安装最新版本到你的本地。 然后我们查看一下当前酷带 s 增强版具体有哪些新增的功能,比如 agent, teams, hux, 繁琐拎拎, ip agent 以及 webui。 我们可以先看一下路由 server 是 怎么实现的,可以看到路由 server 是 使用 httpss 去进行实现的,这样最大的优势呢就是, 呃,你启动多个 c 型只会占用一个进程,这样的话你的进程消耗就会非常少。我们直接使用路由 server 将微博 ui 启动起来。 cordless server 会随机启动一个端口和随机的托克密钥,你拿到这个端口和密钥呢?可以在本地启动一个内网穿透,这样你在外面就可以通过手机访问微博 ui 去进行远程的微博扩顶。 我们可以直接切换到移动界面去进行测试,先随机选择一个目录 发送嗨来进行测试。 ok, 我 们开始测试下一个功能,我们回到仓库地址,我们看一下 agent team 和 hux 以及奥斯突击 api agent, 我 们首先演示一下 agent team, 使 我们来到这个仓库,我们通过 code s 启动。然后怎么使用呢?首先第一步你需要在配置文件里面去启动多媒体的配置,我们 可以看一下在这个配置文件 copy 里面去将这个配置多媒体给它启动, 我们就可以开始那个尝试这个功能了。比如说我们 use agent teams 这样子告诉模型,告诉模型,比如说告诉了五点二, 我们需要需要启动 a 键的 team 来去做接下来的工作。比如说我们分析当前项目,就代表了我们使用 a 键的 team 来分析当前项目, ai 会分析任务难度来判断具体创建多少个 a 帧。 ok, 我 们看到它根据呃项目复杂度启动了五个 a 帧,五个分析帧 这个中括号括起来的这个就是我们的具体的一个执行 aint, 比如说是其中的五个分析的 aint, 然后来去并行的执行分析当前项目,它对于仓库结构 rooster 的 库的代码,然后 build c i 以及文档以及安全 sandbox, 然后去单独的 每一个单独的去进行分析。啊,这五个的话就是在并行的那五个都是同时创建,然后在并行的这里就会有一个等待所有的 a 帧,我们现在可以等他返回。 ok, 全部 a 帧已经返回了,五个 a 帧都已经执行完成,然后返回了他的一个结果,分析结果, 然后五个 a 帧的全部返回成功之后呢?慢 a 帧就会去收集五个 a 帧返回的内容,做一个汇总,然后再去判断当前的分析是否完成了,然后模型会自己去判断 是否还会需要继续的去进行分析,如果不需要的话,他就会直接返回结果,如果需要的,他还会去再次的创建 a 帧去进行分析。 ok, agent teams 全部结束,返回了最终的结果,这就是整个 agent teams 的 一个调用过程。


完全免费 enfabrics 推出 enfabrics 学院的项目包含 agent skills, m c p, a p i 等十三门课程,而且都是认证课程。最重要的是完全免费,我马上来教大家怎么上课。来到 enfabrics courses 的 这个页面,你会看到这里面有很多课程,有 coco inaction 啊,还 有一些 ai 的 素养,还有 a p i, m c p 等课程。如果呢,你看不懂英文,没关系,你只需要装一个这个插件,它就可以沉浸式的翻译。装完以后呢,它会显示在右方,你只需要点一下, 然后你看到它就有中英文的显示。比如说,这里面是学习 coco, 集成到你的工作开发当中,这里面呢,就是完成日常的任务,还有它的素养啊, m c p 啊,一目了然。接下来我们来点一下第一个课程,来试一下。 来到它这个课程的页面,你会发现已经是翻译了,但是呢,因为中英文呢,它可能有一些乱码,我们可以先取消它,你会看到就是整个课程的预览,学习什么都帮你说清楚了。那我们进入课程的第一课介绍, hello and welcome my name is stephen greiter and i'm a member of technical staff at entrop。 它是有 c c 字幕的,但是呢,没有中文。所以呢,刚刚那个插件就派上了用场了,装了这个插件,它会显示在这个位置。 before we get into anything too technical i want to give you a quick overview on what we'll be learning。 其它的课程也是同样的方法,如果你不懂英文,就像我一样装一个插件,赶紧学起来吧。 ok, 以上有今天的所有分享,我们下期再见。

你知道有 skills 和没有 skills, 它的准确度能差多少倍吗?一个智能体它最多能放多少 skills 才是它最佳的性能,以及怎么样才能让它调用好这些 skills? 今天给大家分享这个 long chain 的 一个研究报告, 他们评估了一下像 cloud code 的 这种编程工具,想要编好它们的 long chain, long graph 相关的一些代码,如果没有 skills, 它的准确度能达到百分之九十五, 其实本质上的原因是来自于因为他们的这些库都是很新的库,所以说如果是让这些大模型去拆的话,它的效果肯定是不好的。当装了 skills, 它就有这样的一些内容和技能,或者说它的一些规范存在,那么它编辑的代码才是准确的。 他们还发现当超过十二个技能的时候,它的效果就是在急剧下降的。所以说大家在装这个 skills 的 时候,不要装一堆,不要装几十个一百个,特别像 open curl, 你 又用的不是 cloud 的 这种模型, 那么你千万别装特别多的 skills, 或者你把它分成不同的智能体。第三个就是怎么样让这些智能体可以调用好你的 skills, 不要把它放在这个 skills 的 这个最前面的原数据,它调用的准确度不高, 那么怎么放呢?直接把它放在 edge 和这个 cloud code 的 原数据里面,这个数据是一定会加载到模型里面的。你的 skills 虽然你上面的原数据是可以加载的,但是它调用的时候可能大模型认为你的这个重要性不够高,所以说它调用的时候准确度不高, 然后他们也测试过,在有些情况的时候,没有 skills 的 时候,它的成功率只能会下降到百分之九,接近差了九倍。 而且还有一个特别重要的点,其实现在的模型根本没有好好的用上 skills, 哪怕显示的提示这些模型要去调用 skills, 这些 cloud 自己的模型它的准确率都只能达到百分之七十左右。所以说为什么现在很多人为什么我装了这个 skills, 它为什么执行出来的还是不准呀? 就是因为你根本没有显示的去调用,就算你显示的去调用了,那么你的这个模型的性能也是会决定它调不调用。用这个 skills 的 一个巨大的原因,因为要调用 skills, 它模型必须具备一个能力,就是它自己对自己的认知能力,就是我现在的上下文是否 支撑我去完成这个任务,有没有一些内容是我猜的,它必须要非常详细的知道自己的这种上下文的能力,有自我的认知能力。 所以说大家现在调用的时候,你如果知道有哪些 skills 能帮助你完成这个任务,你最好就直接叫他去看这个 skills 去完成你这个任务,而不是让他你去完成我这个任务,什么交代都不告诉他。

嘿,大家好,今天咱们来聊个特好玩的话题,怎么把你的 ai 编程搭档从一个只会敲代码的助手,直接升级成一支能打硬仗的超级战队?准备好了吗?咱们马上开始。 你可以先问问自己一个问题啊,你现在用的 ai, 它到底只是个代码生成器呢?还是说它已经成了你离不开的那个神队友?咱们肯定都遇到过这种情况对吧? ai 聊着聊着就忘了上下文,有时候给出的点子也没啥新意,总感觉跟咱们自己的工作流隔着点什么, 哎,这时候 cloud 代码插件就派上大用场了,简单来说,它就是一个官方精选的工具箱,里头都是高质量的好东西。有了它们, cloud 就 不再是一个单打独斗的程序员了,摇身一变成了一个由各种专家组成的超强开发团队。 那怎么把这些专家请到你的团队里来呢?超级简单,就两个办法,你要是知道名字,就直接输入斜杠 plugin install, 后面跟上插件名搞定。要是想逛逛看有什么好东西,那就输入斜杠 plugin, 然后选那个 discover, 整个插件市场就都在你眼前了。 不过呢,这有个时候我得重点提醒一下,不管你是安装更新还是用任何一个插件,都得先确认你信得过它。这个不是开玩笑的,毕竟安全永远是第一位的。 好了,咱们来看看今天的路线图,我们先聊聊怎么让你的 ai 水平上个新台阶。然后呢,我们会挨个认识几只超能小队,有负责流程的工作,刘奇才有专门搞创造的创意主力,还有一支自动化与安全卫队。 最后我们再看看怎么把他们完美的整合成你的全新超级战队。好,首先登场的就是我们的工作刘奇才小队, 顾名思义,他们的任务就是帮你把整个开发流程给捋顺了,让所有事儿都变得井井有条。 你有没有这种痛点?就是项目失忆症,每次新开一个绘画 cloud 就 跟失忆了一样,之前聊的啥关键信息都给忘了。别担心啊,这个小队里的第一位成员 cloud md management 就是 来解决这个问题的,他就是你项目的记忆管家,保证 ai 记性特好。 它有两核心工具配合得特别好。一个叫 improver, 你 可以把它当成是定期的项目维护,它会确保你的项目档碗和代码库十种保持一致。 另一个是 revise 命令,这个你每次聊完天用一下它,就能把你这次绘画里所有新的重要的信息都记下来,不断更新项目的长期记忆。再来看第二个痛点,代码越写越复杂的,维护起来想死的心都有。 没关系,团队底的代码重构大师 code simpler fire 插件来了,它最拿手的就是把乱七八糟的代码梳理得清清楚楚。 它的工作特纯粹,就是简化复杂代码,让代码读起来更清晰,风格更统一,维护起来也更容易。最关键的是什么呢?它在帮你大扫除的同时,会保证你代码原有的功能一样不少,绝对不会好心办坏事。 接下来是咱们每天都得打交道的。 get 手动处理 pr, 绞尽脑汁写 canmake 信息,是不是特别烦人? 别当心,我们有两位 get 专家,一个叫 pr review tokit, 帮你自动检查代码合并请求。另一个是 commit commands, 能根据你的代码改动,自动生成标准又好看的提交信息。它们俩就是来帮你把这些琐事化动搞定的。 好的流程理顺了,咱们该干点正事了,搞创造。接下来认识一下我们的第二支队伍, 创意助理。这支小队专门负责干那些创造性的重活,不管是教 cloud 新技能,还是丛林开发,一个全新的功能都包在他们身上。 你是不是已经烦透了,每天都在手动重复同样的工作流程,感觉自己像个机器人那么 skill creator 这个插件就是来解放你的,它能让你教会 cloud 各种新招数,而且是永久学会,以劳永逸。 创造一个新技能的过程也特别简单,他遵循一个清晰的循环,第一步,你先告诉他你想干嘛,第二步,他帮你写个技能草稿。第三步,你给他一些测试案例。最后一步就是不断的运行评估,再改进。 这么一循环,任何重复的工作都能变成 cloud 的 一个永久技能。开发新功能的时候,是不是经常场面一度混乱,最后 bug 满天飞?这个时候就该请出我们团队里的首席开发了 feature dev 插件 儿,它就像一个经验丰富、思路清晰的技术主管,被装进了一个小盒子里,你看它厉害就厉害。在有一套超级严谨的七步工作法, 从需求探索、研究代码库,到提出问题澄清需求,再到架构设计动手实现,最后还有质量审查和总结。有了这么一套章法,就能确保开发过程不跑偏,交付出来的东西质量杠杠的。 还有一个痛点, ai 生成的前端界面,总感觉缺点儿灵魂,一股浓浓的 ai 味儿,特别平淡。这时候,团队里的明星设计师 front and 底自然插件就要闪亮登场了,它的任务就是让你的 ui 一下子变得又酷又亮眼。 好了,最后咱们来看看在幕后默默守护你的自动化语安全卫队。这些专家不显山不露水,但他们能确保你的开发过程又安全又高效。 手动一遍又一遍的跑任务来修 bug, 是 不是又慢又让人抓狂? ralph loop 插件儿就是一位永不放弃的特工,他会不知疲倦地替你迭代,跟问题死磕到底,直到解决为止。这个插件的精髓说出来就一句话, ralph 就是 一个半死循环。 没错,你没听错,它就是一个简单的死循环,逼着 cloud 不 断地去尝试,去修改自己的代码,直到代码能成功。运行。 方法简单粗暴,但效果那是真的好。咱们每个开发者心里可能都有一个共同的噩梦,在错误的地方手一抖,敲下了 r m r f hokify 这个插件就是你在命令行上的守护天使,它能通过一个特别简单的配置文件,在你执行那些高危命令之前拦你一下,让你再确认一遍。 写代码的时候,是不是也怕自己不小心就埋了个安全漏洞?这个 security guidance 插件就像是你身边一位随叫随到的安全顾问,就会马上给你报警,为你保驾护航。 好了,到现在我们这支超级战队的所有成员你都认识了,现在咱们就来看看怎么把它们组合起来,真正打造一个更智能、更安全也更有创造力的工作流程。 在实际工作中,你可以这么玩,用 cloud management 来让 ai 始终记的项目背镜。要开发复杂新功能了,就请出 feature def。 碰到像修复测试这种需要反复试错的活儿,就交给 ralph loup 去死磕,同时让 hukifai 和 security guidance 在 后台时刻保护你的安全。最后剩下所有其他的重复性工作,通通交给 skill creator, 把它们变成自动化技能。 好了,这支队伍你已经认识了。那么现在问题来了,你打算先招募哪一位成员加入你的项目呢?别犹豫了,赶紧去插件市场里逛逛吧,你的超级战队就等你来组建。