今天呢,我想问大家一个问题啊,一个 ai 工具如果把它所有的能力在第一秒都全部摆出来,会发生什么?你看用户呢会被淹没掉,上下文呢也会爆炸,模型呢直接就乱了。所以 cloud code 选择了一个完全不同 的路子,叫做渐近式。譬如那今天呢,我就带大家从源码这个层面去看一看,这套机制到底是怎么工作的。我先说背景, cloud code 里面有一个叫做 skills 的, 这个机制啊,我现在大家已经用了很多了。那最近呢,在开发者社区啊,也讨论的很火, 很多人看了之后就会觉得,哎,这不就是一堆 prom 的 文件吗?有什么特别的?但如果你真的会去翻他的原码,你会发现他在解决核心问题其实是一件很精妙的事情,也就是怎么让模型知道是有技能可用, 同时呢,又不会把这个上下文啊给它撑爆掉。而这两个目标表面上是矛盾的,你要告诉模型的东西越多,那上下文就越贵,但你要告诉他的越少呢,他越不知道该去调用什么。那这个矛盾就是间接性批录要去解决的。 ok, 那 具体怎么做呢? cloud code 它把间接式批录拆成了五层,我一层一层给大家去剖析。第一层呢,只需告诉模型技能机制存在,系统提示里面就有一句话,你可以用 skill two 来执行技能,但只能去调用列出来的那些,不要乱拆。 而且要注意,这一步只暴露了机制,没有去暴露任何的内容。第二层呢,就是给模型看技能的名称和剪短描述,不是所有的技能都能进入这个列表,得满足可描述性的要求,比如有描述,有试用场景,说明没有这些技能对模型来说是不可见的。那这一刀呢,我觉得剪的还是很聪明的。 第三层呢,就是列表本身要走预算的压缩源码,里面有个常量叫做 skill budget context percent 默认只占上下文的百分之一。 他如果技能太多超了预算呢,就会截断描述,截断情况下退化成只去发技能的名字,先给最小可用缩影,不给正文。 第四层呢,技能列表呢,是增量下发的,不是每轮都去全量重发。他维护了一个叫做 send skill names 的 一个集合,第一次发出始批次,后面只发新增的很多 agent 会每轮把所有的工具全量重发。 cloud code 在 这里真的认真的省了很多的 token。 第五层呢,就是真正的技能的权威了,直到模型决定要调用某个技能,才会通过 get prompt for comment 来展开完整内容来做变量替换,来去做权限的注入来去 fox 注册 全是在这个时候才发生的。另外,除了延迟加载以外,它有个更隐蔽的设计叫做条件激活。如果你在技能定义里面写了 python 制断啊, 比如这个技能只适用于 t x x 的 这个文件,那它启动的时候就不会出现在模型的技能列表里。只有当你真的读写了一个 t s x 的 文件,技能系统才会激活它。而这个激活时机挂在了文件操作工具上,像 file write tool, 像 file write tool, 像 file edit tool 都有这个副作用。碰到文件往上去走目录数,找没有新的技能的目录找到呢,就动态地加载进来,那效果是什么呢?技能集合会随着你在项目里走到哪里而变化,你进了前端目录,前端相关的技能才会出现, 你进了测试目录,测试相关的才会出现。这个不是静态注册,这更像是一个条件的规则系统。最后呢,也给大家说一个细节,也是很多人去做 agent 的 时候啊,容易忽略的地方。 skills 的 执行有两条路, 一条呢叫做依赖技能,展开成一批新消息,融入到主对话里面,继续跑,返回值很轻,就一句,正在加载技能,真正的内容通过消息流去回到主线城。第二条呢,叫做 fork, 技能会启动一个子代理,再独立的上下文,把活给干完,再把结果摘掉,返回给主线城。 主对话全程就不知道子弹里发生什么。上下文呢,不受污染。这个区分很有价值,知识型、流程模板型的技能适合的是硬赖模型,需要跟着一起推理任务。委派型的技能适合 fork。 结果重要,过程不重要。如果不做这个区分,那主上下文会越来越胖,要么记忆力度的控制能力呢,会全部的丢失, ok。 最后呢,把这一套的东西整体看一遍。所以 skills 的 间接式,譬如就是在做一件事情控制,譬如成本,同时保留足够强的技能召回能力,先给锁影,再给局部集合,再给正文,最后呢才给执行结果。你可把它理解成一个搜索引擎的逻辑,你搜东西先看资料,觉得对了才点进去,进去了才消费全书, 没有人会把整本书扔给你,你也没有精力一次性读完,然后 ai agent 的 上下文就是这本书的成本, cloud code 选了一个很工程化很克制的方式来管理它。所以如果你在自己的 agent 里面也想去复刻这套逻辑呢?我建议你就记住下面的核心锁影和正文,给它分离开。
粉丝20.1万获赞72.0万

今天我们带着大家去装一下 cloud code 啊,注下,这个方法不需要你有 cloud 的 账号,不需要你对接它的模型,不用担心封号,全国内环境对接我们国内的大模型,相信我啊,一旦你用上它,你就进入到另外一个世界,一步步跟着做,任何人都可以安装成功。好,我们开始 这次是在 mac 笔记本上去做安装 windows 的 小伙伴,等下一期的视频。首先点开你的启动台,其他文件夹里面有一个终端命令行,点开你们应该就可以看到这么一个终端制服的页面,直接粘贴这个指令,安装 homebrew, 这个是 mac 系统上的一个命令行的管理工具包,有了它我 我们后面就可以安装 cloud code, 你 不用管这个命令是啥意思,直接复制粘贴运行就行。这里面有几个选项,通常选择一,选择二都可以选择一,输入你的开机密码,这里面会检测到你之前有没有安装过啊,我这个机器很干净,没有安装过,选择 yes or no 都是可以的,如果你安装了,它会默认把你之前的删掉,再给你装个新的。好,我们耐心的等待一下,这个时候它需要你按回车键开始快进一下啊。安 装成功之后,需要输入开机密码确认一下它,这里会提示 next steps。 直接复制这个命令,把 homebrew 添加到你的电脑的环境面板里,你也不用管这个命令行的意思,直接复制这三行贴进去看底部没有报错就是 ok 了,你就可以直接调用 homebrew 去管理你的安装包。为了方便下一步的演示,六叔把这个终端的这个屏幕清空一下,你们看得更清楚一些, 我来验证我们的 blue 有 没有安装成功。你可以输入一个 blue gambos, 我 们看一下显示 home blue, 五点一点九最新的版本,证明你安装成功了。好,第二步就用 blue 这个命令去安装我们 color code, 你 不用管它啥意思,直接复制安装这个指令回车,现在就开始安装了,我们还是快进一下好。装好之后,终端输入 color code, 你就可以直接进入到这个页面。看到这个小螃蟹啊,这个时候你还用不了,因为我们还没有对接国内的模型,下一步我们就演示怎么去对接国内大模型啊。所以我们使用国内的模型,不是用这种对话的方式,而是要进入到它的开放平台,去调用它的 a p i 去接入国内几个比较好的,智普、 kimi, mini max, deepsafe 都是可以的,目前 deepsafe 是 按次去收费,我们可以快速看一下它的价格啊。 sick flash 版本百万输入两分钱,一百万包肯出出两块钱,相对还是比较便宜啊。 pro 版本现在有折扣,像智普的、 kimi 的, 他们都是可以包月包年,按照自己的预算去采购合适的模型去接入。这个时候我们要下载另外一个工具, 开始打开命令。行,好,我们装一个 c c switch, 专门批量管理不同大模型的工具,方便你可说话的配置,方便你一键切换同样的输入这段命令,不用管它什么意思,直接截图复制回车,快进一下。安装完之后。好,我们打开 c c switch, 它可以管理各种 a 检测,包括小龙虾,包括克劳德 code, 包括 codex。 好, 我们选中克劳德,添加供应商。我们这次是拿 deepsix 举例子啊, 选择 deepsafe 供应商的名称,官网链接,它已经给你生成好了,这里面你只用去管 a p i key。 进入到官网,点击 a p i 开放平台,记住一定要充值啊,这里面就有个 a p i key, 我 这里是创建好的,你可以重新创建一个新的,然后去复制就行了。 打开 cc switch 贴进去,这里面因为 deepsafe 发布了新的模型,我们主模型改成 vc pro, 只用添加你的 a p i key 和你的模型的名称,点 一添加就已经添加完成了。好,装完之后大家一定要注意啊,点开它的这个设置,里面有一个跳过卡尔的 code, 出示安装确认,这个一定要把它打开啊,一定要打开,打开终端,我们测试一下输入卡尔的 code 的 这个密令啊, 但如果说你也可以用这个密令先验证一下你的卡尔的 code 之前安装好没有,如果出现的是版本号,证明你就安装好了。如果没有这个或者是报错,证明你之前那一步是没有安装好的,然后这个时候就直接执行卡尔的密令,选择 yes, 进入到它的一个使用界面,注意看这个模型,可以跟它对话, 正常回复就对了啦。不需要克劳德的账号,不需要对接他的模型,直接配置我们国内的模型就行了。这个装好之后呢,就可以参照六叔之前那些视频,怎么去安装一些好用的 skill, 怎么去基于 skill 去解决你的一些个性化的需求, 你就可以用上啦。除了 deepsix 之外呢,其他几个主流的模型 coding plan, coding 能力也都很强,比如智普的也会有自己的 coding plan, 你 只用获取它的 api key, 打开 c c switch, 选中对应的模型,智普 确认配置,他会给你放上去,你只用把你的 t 填上去对应的模型主模型确认好,比如现在智普的主模型是五点一,就直接把这个五点一贴上去,点击添加,你就可以灵活的在这个里面去切换你的大模型了。好了,这个保姆机的实操大家学会了吗?赶紧试一试吧!室友说,关注我持续复述你的爱奇艺的用户拜了个拜。

很多人用了 cloud code 的 一段时间,都会发现一个问题,一开始很聪明,后面越用越笨,回答越来越乱,头啃还消耗巨快。那其实很多时候并不是模型本身的问题,而是你不会用这五个最基础的命令。那今天这条视频带你一分钟掌握。 第一个命令, config。 这个命令可以说是 cloud code 的 控制中心,那输入斜杠 config, 你 可以查看和修改当前的各种配置,比如是否自动压缩会话,是否自动切换思考模式等。建议你把每个配置项都了解一下。 第二个命令, model。 如果你想切换模型,直接输入斜杠 model, 就 可以看到当前支持的模型列表,直接选择就可以切换普通任务,你可以选择 so net 模型, 复杂任务你可以选用 opus, 性价比最高。第三个命令, clear。 很多人会发现一个问题啊,聊着聊着, claus 回答开始抽风了,越来越乱,越来越慢,而且 token 消耗飞快。这其实是因为上下文啊太长了,这个时候只需要输入斜杠 clear, 就 可以清空当前对话的上下文, 重新开始一个新的绘画。我建议每个独立的任务啊,都可以开启一个新的绘画。第四个命令, compact。 如果你不想完全清空对话,但是又想减少上下文的长度,那就用斜杠 compact, 它会自动压缩历史绘画,保留关键的信息。简单理解啊,就是给绘画做一次瘦身。 那第五个命令, continue。 有 时候 cloud code 会回答到一半的时候,因为意外的各种情况,导致终端的窗口不小心被关闭了。很多人这个时候啊,就会把之前的输入再重新来一遍,但其实大可不必如此,那直接输入斜杠 continue cloud 就 会接着之前的回答继续输出。 总结一下,学会这五个命令,不仅可以让输出的质量更高,关键是还更省 token。 那 你觉得哪个 cloud code 的 命令最好用呢?欢迎在评论区告诉我,我是新启,关注我,每天分享一个外部限定的小技巧。

如何防止 ai 幻觉?在大家深度使用 ai 的 时候,大家肯定会遇到这种情况,就是你的 ai 会突然间胡说八道,或者说你的文件实在太多了之后你没有建立好完整的架构。 然后呢, ai 他 不是通过最后的时间存入去搜索你的文件的,而是他会通过关键词去搜索,所以他会导致你的旧数据和新数据在打架。所以呢我就设置了很多约束 ai 幻觉的方法,今天简单跟大家分享一下。 呃,这上面是他做的一些专业的术语,我听不太懂,那我就用大白话分享给大家。 那第一个就是,呃,要给 ai 装一个门禁卡,呃,这个门禁卡的意思其实就是他最初的一个宪法,就是 ai 在 每一次对话的时候,他会自动的去读他的核心文件,那个核心文件我们会给他描述之后,让他自动去翻哪个文件。就比如说我要说 我今天要做一个 ai 脚本,那它呢,就会自动去翻关于 ai 脚本的一些相应的 sop 或者一些 skill 技能,然后呢它才会去回答我们的问题。 第二个是写规矩,因为 ai 这个行业的变化实在很快, ai 的 知识库也很短,我们呢要让 ai 跟上时效的方法就是让它每一次涉及到 ai 的 内容之后,必须要联网, 然后呢防止他自己自动的去给我一些答案,就是他必须找到相对应的链接,相对应的数据才能告诉我去完成。 那因为我们在过程中也遇到很多问题,我让他在每一次的事故中,然后都沉淀出来相应的问题,告诉他在学习的过程中不要再犯同样的问题。 那第三个就是设置减元,这个方法呢是我现在经常用到的,我会开不同的可多的窗口。 比如第一个窗口我只用 play 只做一个计划,就是我把我的灵感输入之后,然后呢,他根据我的文件去列出完整的计划,这个呢,我不让他执行,我让他去做一个全新的一个窗口的指令。然后呢,我会新开一个 b 窗口去执行, b 窗口执行完之后,我不会让 b 窗口自己去验收,也不会让 a 窗口去验收,我会再开一个扣带的的窗口去验收,或者说我再开一个新的扣的的窗口去进行验收。然后呢, c 窗口验收完的反馈再给 a 窗口 a 窗口进行最终的确认, 因为这是受限于一个很大的一个完整的系统计划的话,就会需要设置 a b 或者一个 a 窗口就 ok 了。 第四个就是我会设置多个 ai 智能体, ai 智能体它每一个涉及到的任务是不同的。然后呢,我们 触发关键词,比如我需要写一个脚本,那可能直接就触发内容 a 进的,比如我们涉及到就是报价,它会自动触发我们的成交, a 进的我们可能要聊一些公司了,或者未来的 ai 方向了,它会自动触发战略的。 这个呢就是相应的,他不会在同一个 a g 呢污染上下文,让他专业的 ai 做专业的事情。 最重要的是,说实话,我觉得那个 g p d 五点四的模型是要比可乐四点七模型在思考架构上 是要强的,所以说我会在重要的一些决策方面上会和勾代的去进行交流。嗯,一句话总结就是 ai 不是 不约束就不出错,越约束越聪明。 我的理解这句话的意思是 ai 是 我们要放权给他,但是呢,我们要把他头上戴上一个紧箍咒,不是说让他干了所有的活,但是要告诉他明确边界,哪些能干,哪些不能干,不要出现幻觉,自己去蛮干。 然后我们相应装的这些规矩和规定,包括质检,还有多 a g 的 的护审,其实就是为了约束 ai 出现的幻觉。我也建了一个 ai 的 交流群,欢迎大家互相探讨,互相学习。

cloud code 有 几十个命令,但是如果你是新手呢,就一定先掌握下面这九个,其他的你可以先去放一放, 把这九个用熟了,你的使用效率和头肯的消耗都会好太多了。第一个命令就是 config, 这个是 cloud code 的 一个控制中心,那你输入杠 config 呢,就可以去查看和修改当前的一个配置, 比如说是否去自动的压缩对话,是否自动切换思考模式等建议呢,你可以把每个配置项都去过一遍。 第二个命令呢,叫做 model, 想切换模型呢,直接去输入杠 model。 普通的任务呢,你可以去选 sonnet。 复杂任务呢,你可以上 opus, 性价比啊最高,你看,就这么一个简单的选择,也能够去帮你去省不少的 token。 第三个命令是 clear, 聊着聊着呢, cloud 开始抽风了,越来越慢,透坑消耗的越来越快呢,这是因为你的上下文啊,已经太长了,那你呢,可以输入让 clear 去清空当前对话的一个上下文,重新开始一个新的对话。那我建议呢,每个独立的任务都开一个新的对话。第四个命令呢是 compact, 如果你不想完全的去清空对话,但又想减少上下文的一个长度,你可以输入杠 compact, 它会自动的去压缩历史对话,去保留关键信息,简单去理解呢,就是给对话做一次瘦身。第五个命令呢是 resume, 想回到之前的对话,你就输入杠 resume, 就 能看到当前目录下的一个历史对话列表,选择任意一个,就能直接去跳回去继续,相当于给你的 ai 编程加了一个历史记录的功能, 随时去切换不同的任务。第六个命令呢是 revend, cloud 写着写着去偏离方向了,或者提示词写错了,你不用重开对话,输入杠 revend 就 能回到刚才那一步对话,相当于给你的 ai 编程加了一个撤销键。 第七个命令呢,是 btw 任务中途突然想到了一个小的问题,比如这个文件是干嘛的?输入杠 btw, 解释文件作用, cloud 会去回答,但是不会去打断当前任务流程,也不会污染你的上下文。第八个命令域 name, 给对话去重命名有三种用法,第一个就是杠驴 name, 加上首页重构,你可以去做直接命名,然后如果你杠驴 name 不 带参数呢?让 cloud 自动从对话去生成这个名称。 第九个命令 export, 把诊断对话导出成一个 plaintext 文件打杠例 export, 当前的这个对话会被导出,包括每一个提示回复和工具调用,也可以加文件名参数,直接去写入指定文件,适合呢?在去解决棘手问题后啊,这个备份 方便后续的复盘或者分享。 ok, 那 总结一下这九个大的命令啊,覆盖了配置,覆盖了效率、覆盖管理三大场景,显著去改善你使用 cloud code 的 一个体验,输出质量呢,也会更加稳定,透根的消耗也会降低。 至于像 simplify, 像 branch 分 支等功能和 insights 复盘报告可以去,等进阶了再去学。现在已经有两千多位朋友了,如果你想在 ai 的 路上和我一起同行呢?欢迎在评论区我们一起去交流一下。

一个 ai 如果既能记住所有上下文,又能同时指挥多个代理干活,软件开发会变成什么样?这次枯落的释放的信号很直接,他不想只做聊天工具了,而是要往能真正做事的工程系统走。 最值得叮嘱的是两个变化,第一,枯落扣的速度限制直接翻倍,而且 pro max、 teams、 enterprise 全部覆盖,高峰期限制也被拿掉了。对重度编码的人来说,这不是小优化,是工作流能不能顺畅跑起来的分水岭。 第二,多代理编排开始变得更清晰。一个主代理负责拆任务、调度任务,再把前端后端调试研究,这些活分给不同子代理并行处理。也就是说,他越来越像一个技术负责人,而不是单纯的问答框。 更关键的是下一代模型的方向。官方释放出来的重点很明确,更高的工程判断力,更像资深工程师的代码品位。无限上下文窗口,还有更持久的长城推理。这里的无限上下文意义很大, 它不是单纯让模型能塞更多字,而是让它在长项目里不丢历史决策,不忘文件关系,不反复问同一个问题。 在叠加多代理协调, cloud 的 未来就不只是会写代码,而是能记住项目分配任务持续推进,像一个小型开发团队一样运转。 所以这次真正的变化,不是某个功能点变强了,而是 cloud 的 定位变了,它正在从聊天机器人往完整自主软件工程系统靠近。 ai 的 下一步,可能不是替人类回答问题,而是替人类处理那些最耗时间、最容易断档、最不想反复解释的工程活。关注全球 ai 速递,获取更多 ai 前沿资讯!

enzo pick 内部有一个人叫做 boris chaney, 上个月他先分享了自己个人去使用 cloud code 的 使用方式,他呢是 cloud code 的 核心工程师。 那最近呢,又整理了一份团队内部怎么去使用 cloud code 的 清单,一共有十条,大家可以去上网去找一找。 相信很多人看完的第一反应都是,哇,原来还能去这么去用。所以今天我不会去照本宣科的给你去把这十条给背一遍。我想带大家去过一遍,告诉大家哪些是真正的思维升级,哪些只是工具技巧,以及最重要的这些技巧背后, 整个团队的工作方式到底发生了哪些变化?首先第一条是要去同时去跑三到五个 walk chain, 那 团队的第一条技巧就是不要只去开一个 cloud code 的 对话,要同时去开三到五个。他们的做法呢,就是用 gitwalkchain, 每个 walkchain 呢,是一个独立的工作目录, 运行各自的 cloud 的 绘画。然后呢,用 z a, z b, z c 这样的需要的一个别名啊,一键去切换。 有人呢,甚至还专门有一个只读的分析 worktree, 专门用来去看日制跑 big query 的 查询,不去做任何的代码改动。而 boris 本人呢,也不用 worktree, 他 用的呢是多个的 git checkout, 机制不同,但本质是一样的,去隔离上下文,并且进行推进。 那我觉得这条技巧呢,背后有一个更深的认知转变,就是你不再只是去写代码,你是在管理一支 ai 的 施工队。以前我们的思维是串起的,我想好, 我去写,我去改,我去测。现在思维呢,就是 a 组去实现这个功能, b 组去写测试, c 组去做代码审查,我自己喝咖啡。然后呢,容易有结果。 但有个问题要警告大家,上下文切换的成本是真实存在的,你开了五个窗口,每次切回来都要去重新理解这个绘画走到哪里了。如果你的项目不够复杂,或者你还没有去建立清晰的任务分工,多开窗口只会让你更乱,不会更快。所以这个技巧是给有架构意识的工程师用的,不是给所有人的。 第二条呢,就是 plan mode。 这个不只是用来开始,更加呢,是用来去做重启。那团队所有人都会去用 plan mode, 但有一个人的用法特别聪明,他让 cloud 启动计划之后,再单独开一个 cloud 绘画,让第二个 cloud 去扮演资深的工程师 来去 review 这个计划,把规划过程变成对抗性的,而不是合作性的。更关键的是,当任务进行到一半,出问题了,别继续硬推,要切回 plan mode 重新去规划。那这一点我自己很有深有体会啊,很多人,包括我自己啊,用 cloud code 遇到问题的时候,下意识的反应就是再追加一条指令去试一试,结果呢,是越补越乱,最后的上下纹变成一团烂泥。 那 cloud 开始去瞎说,你还以为是模型问题,但其实是流程问题。 pre mode 是 一个认知锚点,它强迫你在行动之前先搞清楚方向,遇到障碍就重新锚定,是软件工程里面停下来思考 比盲目行动更快的进阶原则。只是 ai 让这个原则更容易去忽视了,因为它总是在生产输出,你会以为是在进展。 第三条就是让 cloud 自己去写规则,这条是我个人认为十条里面最有洞见的一条做法呢,是每次 cloud 犯了一个错误,你纠正完以后,在 prompt 结尾加一句,把这条经验更新到你的 cloud 点 md 里面,以后不要再犯那 cloud 点 md 是 cloud code 的 一个项目配置文件,相当于给 ai 的 一个行为手册, 可以在里面去写规则,写禁忌,写代码风格的要求。但这个团队的做法也更激进,他们让 ai 自己去写这个手册,犯一次错,记一条,一个工程师甚至专门维护了一个 note 的 目录,每做完一个 pr 就 去更新一次,那 cloud md 指下的是这个目录, 所以你知道这意味着什么,这意味着你在做的事情不只是用 ai 去完成任务,而在训练一个越来越了解你的这个项目的 ai 学作者。今天花五分钟去维护这个文件,未来每个绘画都会变得更加省事。但有个陷阱, cloud md 不 能无限长文档,太长规则就被稀释了。 在 cloud 读到后面就会望到前面。这个不是玩笑,这个是真实的上下文窗口限制导致的行为特征,所以他们的原则是定期精简。当你发现 cloud 的 老是去犯同一个错误,先去检查规则里面的措施是否清晰,而不是一直往里去加新的条目。 第四条呢,就是 slash command, 是 可以去附用的思维结晶,那团队用 slash command 来去封装高频操作。举个例子,通过 gun tag 每次绘画结束前呢,找出并且清理重复代码。还有更复杂的就是一个 context dump 的 命令啊,自动去拉取最近的七天的 slack 消息, google drive 的 文档, asana 的 任务和 github 的 提交汇总成一份上下文,让 cloud 在 新的绘画里面快速去了解。哎,最近发生什么? 我觉得这项技巧背后有一个非常重要的工程哲学,就是如果一件事你做了不止一遍,就把它变成一个可重复的流程,而不是靠记忆每次去重做。这个不是新的观点,这是软件工程里自动化一切重复的基本原则。只是现在 ai 让这个原则的适用范围啊大幅 拓展了。以前这个原则主要是用在代码上,现在它同样适用于你和 ai 的 交互方式的文本本身。但 头上的这项技巧的一个门槛也不低,你需要先对自己的工作留以清晰的认知,知道什么是真正重复操作。然后呢,才有东西可以去封装。 不过你刚开始用 cloud code, 先把工具用熟,别急着去封装。命令第五条呢,就是用 c l i 工具,不要去依赖 m c p 啊。那团队用 m c p 啊,去集成了 stack, 可以 让 cloud 的 直接去读写 stack。 但有人去提不同意见,就是能用 c l i 解决的就用 c l i, 不要去上 m c p, 理由就是 c l i 更简单,更容易调试,在本地和 c l i 的 行为是一致的。而 m c p 呢,适合需要双向通信的场景。对于读多写少的工作流,一个写的很好的 c l i 脚本往往是更可靠的。 那我自己是支持这个观点,但我想把它说的更加直接。越复杂的集成,失败的方式就越多。刚开始用 ai 工具的时候,你的主要精力应该用在让 ai 产出更有价值上,先把简单路走通,再去考虑复杂的集成。 第六条就是把 cloud 当成一个学习工具,不只是一个执行工具。这样呢,团队说的不够明显,那我觉得这是被严重低估的用法。那具体技巧就是你可以让 cloud 生成代码的可实时图表和交互式的 html 的 探索器,帮助你理解一个陌生代码库。 还有呢,概念图模式,让 cloud 帮你去画出一个领域里面的知识结构、知识盲区和范围编卷。我想说的是呢,大多数人把 cloud code 当成一个写代码的工具,但它同样可以是一个帮你去思 的工具。你可以让他去解释一个你不熟悉的架构决策,也可以让他给你画出某个系统里数据流动的路径,可以让他帮你去梳理一个模块的前置依赖这些事情不铲除代码,但他们能够去帮你建立理解,而理解是写出好代码的前提。 第七条是图片和截图是被忽视的上下文。这道技巧很实用,在 plunk 里面直接附上截图、架构图或者 api 文档的图片。道理很简单,文字描述一个 ui 的 bug 可能需要两百个字,一张截图零个字, cloud 的 能读图,那为什么不用呢?这个原则同样适用于架构讨论,你画一张草图, 拍张照片传进去,比你用文字描述左边有一个服务,右边有个消息队列要清楚的多啊。第八条我觉得蛮有意思的,就是 ci 工具的自学习, 但这个呢,也经常被忽略。做法呢,就是遇到 cloud 不 认识的 c i 工具,不要自己去查文档,然后告诉 cloud, 直接让 cloud 自己去学。那提示词呢?你可以用下面的,比如说使用负杠 c i 杠 help 来去了解这个工具,然后呢用它来完成 a、 b、 c 三个任务,那 cloud 自己会去读这个 help 输出,自己去理解语法,自己去执行命令,甚至对你公司内部的资源去理解语法,自己去执行命令,甚至对你公司有 help 文档,那 cloud 就 会学会去用它。 这背后的意义我觉得就是 cloud 是 一个会学习的执行者,而不是一个只能用来去预制知识的助手。你不需要事先教会他一切,你只需要去给他学习的路径。第九条呢,就是平行不等于更快,任务分配才是核心。 那关于多 a 卷的并行啊,团队有一个非常具体的警告,不要让多个 a 卷的同时去修改同一个文件,因为结果是最后写入者是获胜的, 也就是说其中一个 a 卷它的工作会被覆盖掉,什么提示也没有。那团队的建议就是先从非代码任务开始去并行,比如说像 pr review, 像 bug 调查,像文档整理, 这任务不会互相的覆盖,等你建立清晰的任务隔离习惯以后,再去考虑并行去实现代码。那这道技巧的一个生存含义,我觉得就是多一些的协同,需要的是任务设计,不是把任务拆开扔给几个窗口就完事了。你需要像管理团队一样去思考谁负责什么,哪些任务有依赖,哪些是可以真正独立运行。 ok? 那 第十条最后一条就是更新,一定要经常更新,这条听起来是最简单,但是真正做到的人啊,真的不多。经常更新 cloud code 的, 因为小版本更新经常会包含非常有用的改动。比如有一个版本加了对大 pdf 文件的分页支持,直接解决了在文档密集项目里面,上下文窗口易出问题。 另一个版本改了大型工具输出的存储方式,大幅减少了上下文占用。这些改动不会出现在头条新闻里,但他们实实在在的影响你的日常体验。 ok, 那 到现在时下就过完了,也感谢大家听到现在。然后我想说最后一件事情,就是这些技巧虽然看起来很散,但它背后还是有一条一致的线索。 cloud code 团队对这个工具的理解是把它当成一个可以被塑造的协作者,而不是一个固定的工具。你看, cloud d m d 可以 被训练, dash command 可以 去被定制规则,可以被 ai 自己去写流程呢,可以被分装成可以附用的技能。每一条技巧都在往同一个方向去走,让你 和 cloud 之间的协调关系随着时间越来越顺,越来越高效,越来越符合你的项目特点。这个才是真正值得学的东西,不是任何一个具体的快捷键,而是这种持续优化人机合作界面的思维方式。

朋友们,今天继续聊聊 colocode 元代码新币的事儿,咱们重点说说 colocode 的 记忆系统,看完你就明白,这记忆系统才是 i agent 的 真正王牌。大家都知道,大元模型上下文记忆优化一直是个难题。比如你今天问了 deepsea 一个问题,明天他就不记得了。 colocode 的 记忆系统是四加一结构, 四个记录系统,再加一个做梦系统,听着就是很好玩,对吧?咱们一个个说。首先是 cloud code 点 m d 文件,这不是 ai 自动生成的,是你自己写,它框定了记忆的大框架,比如你是谁,项目是啥,规范就咋定。这文件加载还有讲究,分四层, 公司统一的、个人全职的、团队共享的、本地私有的,离你越近的,指令越优先,个人配置能盖过公司规范,这说明啥?你把 ai 的 入职培训写得越明白,越个性化,它就越能精准干活。 然后是自动记忆系统,他在后台偷偷记东西,你根本察觉不到有个独立的记忆提取 i 简称,一边和你聊天,一边分析哪些内容值得存存的东西。再分四类, 你的身份、画像,你纠正过他的地方、项目上下文、外部资源链接。最绝的是他不光记批评,还记认可,就跟带团队一样,光批评不鼓励人会摆烂, i i 也会越来越保守。还有个细节,涉及时间的,必须存绝对时间,比如下周四得存成二零二六年四月十号,不然过阵子就 失效添乱了。用户的每一次反馈都是金子,得有系统把它存好。那上下文满了怎么办?人家有三重压缩机制,微压缩、自动压缩,完整压缩, 根据窗口剩余空间来选。自动压缩的出发线是上下文窗口,减一万三千个头啃压缩时必须保留,改了哪些文件,踩过哪些坑,用户反馈,还有最后一条对话的原话,还有一个著名的三行代码,之前因为压缩失败,每天浪费二十五万次 a p i 调用,后来改成连续失败三次就停, 这可真的是真金白银的教训啊。 a a, 产品优化缓存太重要了,你以为它用了向量数据库?错了,它用的是纯文本系统,每条记忆是一个 markdown 文件,有标题类型内容, 人能直接打开看,还能 get 管理回滚,所以文件最多两百行,每条不超过一百五十字。为啥不用向量数据库?我猜是因为人能审查的记忆信任成本更低,后期改规则也方便。这是 ai 控制感的来源,你知道它记了啥,心里才踏实。最后是最魔幻的自动做梦系统 模块叫 auto dream, 出发条件是上次整理超过二十四小时,且中间至少有五个工作。 chen, 做梦分四部定向,搞清楚自己是啥, 收集扫描日记,找有用信息整合,把信息写入时间转,绝对修正矛盾记忆简之删无用信息,保持缩影整洁。整合时还有记忆漂移概念,就是以前对的记忆,现在情况变了就得修正。这跟人老睡觉整理记忆一模一样,简直在模拟人类认知。用 ai 这么久,有 模型好就万事大吉。后来才发现,记忆才是壁垒。 cloud 这套记忆系统,分层提取,压缩、审核、做梦,一套下来,绝了。一个越用越懂你的 a a 和一个每次都从头来的 a a 能一回事吗?所以啊,做 a a 产品记忆是核心。不知道今天的分享对你有没有帮助?关注我评论区,一起聊聊。

cosco 的 桌面端接入 deepsafe 第三方 api 教学,点开应用后点击右上角,在 help 里继续点击, 在这个位置有一个开启开发者模式,启动后在右上角点击开发者,继续点击第三个, 进入这个界面,保持 get 位,输入 url, 可以 去 deepsafe 官网寻找,复制后粘贴,然后输入自己的 a p i。 接下来添加模型信息, 我这里添加 deepsafe v 四 pro, 开启一百万上下文,然后就可以正常使用了。 想要 cloud code 的 中文语言的方法很简单,随便使用一个 ai 告诉他你需要 cloud code 的 桌面端中文语言包,他就会推给你,还是完全免费的。

codex 跟 c c 到底哪个好?我想大家各自都有自己的判断。在我个人为二者都充了二百刀的 pro max 会员以后,我个人的体感是 二者的模型能力之间并没有本质的差异,甚至都足够惊艳,让人心喜。但它们其实代表了两种完全不同的人。与 ai 合作的费洛索费 本质上,我们不是选择两个工具,而是选择两种与 ai 交互的模式。你习惯使用哪种模式,你的工作场景是哪种模式,你就应该选择支持哪种哲学的普顶工具。通常来说,抽象的讲, 软件工程开发的模式可以粗略地分为两大类,首先一类是那些探索性不确定的 idea。 在这种场景下,我们自己可能对需求要做什么,最终的一个中态是什么,甚至过程中该如何实现,它都没有一个明确的定义,它更多是我们一个拍脑袋的灵机一动的想法。当我们解决这类问题时,我们期待的一个 partner, 无论是不是 ai, 它应该都要能 快速的与我们进行交互,通过一些他主动的提问甚至判断给我们更多的信息输入,通过一系列的沟通,最终确定出一个相对更结构化,信息密度更高的思维原型来指引我们后续的执行。 而另一种常见的工作模式则是一个更明确的需求,比如说产品已经给我们了相对明确的 p r d, 那 我们剩下要做的只是说把这个项目 真正转移为一个可以被执行的代码而已。对于绝大多数的研发而言,这种场景下想要做的事情是基本完全确定的,我们在此时要做的无非只是一些 dirty work, 把那个 p r d 转化为真正写出来可用的代码而已。 而结合我自己的使用经历来看, c c 更适用于前者者的工作模式。它会在你输出一些观点之后快速地给你响应,并且高频地向你发出提问,以确定它后续的一些方向执行思路。但 codex 则完全相反,它会在你给完需求以后, 非常认真且可靠地将你的需求描述执行完。这个过程会花很长的时间,但是 结果往往是令我们满意的。想要更明确的拆分这两种工作模式的分野,我们不如从三个维度上来进行拆分,首先是任务商,也就是目标的清晰程度以及约束条件的多少。其次则是以我们预期的交互结构, 我们到底期待着与其他 partner 是 同步的沟通,还是说是一些异步的沟通模式?另外则是一个人类所占主动性的比例, 我们到底期望 ai 占据多少责任?他们是只是执行任务,还是说给我们也有一些他自己的认识建议?其实这三者并非是一个非常正交的关系。一个很明显的结论是,如果一个 目标的本身并不清晰,只是我们拍出的粗糙 idea, 那 我们显然就需要我们的协作者能快速的发问,帮我们把 自己大脑中一些比较模糊的观念导出出来,并且通过一些沟通确定哪些思考是我们需要的,哪一些是可以被删除的。通过这种 快速的同步沟通,得出来一些更结构化的结果,那在这个流程中, ai 需要介入的部分以及引导的主动性就会占比更多,但如果这个需求本身就像我们之前讲的已经相对来说明晰,是一个低伤的场景,那我们就不太 需要。它是一个很同步,事无巨细都要向我们发问的流程,它完全可以在我们把事情说清楚之后,一步的完成这个工作,从而解放我们人类自己的时间。我们也不需要给他太多主动发挥的空间,他只需要忠实的执行我们给他的需求就可以。我觉着对未来工具的使用以及工作流的设计,也都是从这三个维度去进行判断,动 态的选择。我们到底适用于哪种工具,应该主要采用哪一种工作流的思路?如果要打一个比方的话, c c 更像是坐在你隔壁工位的好蜂蜜, 会在有了一些 idea 之后立马的打断你现在的所作所为,跟你去探讨它的一些碎片化想法。而 codex 则更像是一个你忠实可靠的下属,在你交代完任务需求以后,忠实的可靠的帮你把事情完整的办完再通知你。我已经做好了。 每个模型都有它们自己的性格,我们也可以顺应的这种性格,在不同的工作场景中选择不同的工具以及模型。 以上是二零二六年二月我对这两个投影工具的一些使用场景总结,但我相信这个领域是日新月异的,二者工具之间 大概率在未来也会发生一些融合。不会说一个工具只是一种工作流场景,那就需要我们未来本身人类自己有一些对需求使用场景的预判,从而能告诉模型它应该采用哪些工作流模式。软件工程永远没有银弹, 不可能说我们用着一种模式,一条道走到黑,就可以得到一个很完美的结果。如果你在错误的场景使用了错误的工作模式,那模型给你提供的支持也就会非常有限。 结合自己的需求,场景动态切换自己的工作流模式才是一个更高效率开发的必经之途。以上是本视频的全部内容,如果你有一些想法或者建议,期待评论区讨论,谢谢大家!

最近很多人在后台私信问我说怎么根据自己的业务去设计一个真正能帮自己干活的一个 agent, 所以 今天就给大家分享一下,我认为的能真正帮你去接手业务的一个 agent, 具体应该长什么样子,有哪些必要的要素?我这里举的例子是我自己在做的一个自 动化广告,出价的一个 agent, 那 对于这个 agent 而言,核心的文件就是一个 skill 的 文件,这是一个大的 skill。 看过我之前视频的应该都知道,大的 skill 都是由小的 skill 来构成的,那我这里是一个大的整体的一个工作流的 skill。 那 我会用这个具体的例子给大家讲一下,一个真正能帮你干活的 agent, 他 需要的一份 skill 应该长什么样子,有哪些必要的要素。 首先第一个就是一定要有一个核心的目标。对于 agent 而言,目标直接决定了 agent 的 一个思考方式,以及他 他所有思考和执行的一个出发点,所以定义好目标是很重要的。然后第二个就是边界约束的定 义,对于业务 agent 而言,这种边界约束其实是很重要的,因为我们不敢把一些非常重要的工作交给 agent, 就是 因为我们害怕他把某些事情搞砸了,所以我们一定要把这种可能会让 agent 犯大错的一些东西变成代码的文件 去做强教练,让 agent 无法跨过这种硬约束,这样就能保证 agent 输出的结论,它至少一定是不会犯大错的,不会对你的业务结果产生灾难性的影 响的。第三个部分也是 agent 整个工作流或者整个设计里面最重要的一部分就是 agent 的 工作流程,我们需要先梳理清楚自己的业务流程, 在没有 agent 的 时候,我们是怎么去做这样一件事情的,然后把它拆解成详细的步骤,第一步、第二步、第三步、第四步具体是怎么做的,然后把这个工作流程梳理清楚之后交给 ai, 让 ai 学会这样一套工作流程来给你输出一个符合你业务预期的一个结果。 然后这里有一点可以注意的,就是如果你的业务上是存在应约束的,那你可以直接在工作流里面让他一定要跑一遍自教练,这个自教练其实就是一个你业务上的一个应约束的教练脚本,如果他教练不通过,那就一定要让他打回去重新进行推理,然后产出一个业务结果,直到这个教练满 足要求,这样的话就能够保证 agent 它输出的结果一定不会是出大错的,至少它是符合你的应约束要求的。


兄弟们,这个开源项目太顶了,开源才几天就在 github 上拿到了十万 star, 这是一个完整的 cloud cool 的 配置合集, agent skill、 快 捷指令规则, m c p 配置等等都包含。安装方式非常灵活,可以一键安装,也可以手动复制需要的组建, 还贴心的把所有的脚本用 note 重写了,全面支持 windows max o s, 并且所有的教程和安装步骤全部都开源给你学习。凭借这个开源项目,这个作者赢得了黑客松的冠军,足以证明这个开源项目的含金量。

兄弟们,今天这个项目离谱到不行, ai 大 佬亲手下场, open ai 元老 carp 亲自写的 cloud 调教指南,一个文件扔进去, cloud code 智商直接拉满, 让他不瞎改代码,不过度设计,不乱加功能,还能逼他先问清楚再动手。不懂就说不懂,一条命令装好,本周涨了四千多星,喜欢的话关注我,每天发现宝藏项目!

cloud code 终于出桌面端了,而且支持国产模型,这对于新手来说会更容易上手一些。想入门 ai 也可以从这里开始。以前用老板 cloud code 特别麻烦,还要用 cc switch 来回折腾,步骤多到绕晕。现在 cloud code 的 桌面端一出来, 直接简化到离谱,两步就能配置好,配置好信息就能用,不需要复杂的流程,我个人也比较推荐。接下来手把手带大家一步步操作配置。第一步,先装好桌面板,安装完成,打开软件,不用登录,直接点顶部 help, 在 单栏找到开启第三方插件的选项,我这边已经开过了, 所以不显示,你们第一次进来都会有这个入口,我也把入口样式截图放好了,照着点就行。点进去之后就能看到 developer 开发者选项,选择三方配置,就会弹出配置文件页面,核心就是配置网关,这里可以自定义命名,随意切换,还能复制现有配置再修改,非常方便。我已经提前配置好了,教大家怎么自己填写, 只要填杯子 u r o 和配置信息,再添加对应模型就行,模型可以手动输,也可以直接添加。很多小伙伴肯定好奇我用的配置 都是从哪里来的,今天一次性讲清楚,全都教你们怎么配置。首先先先说小米配置获取方法,有两种方式,第一种,参加小米官方活动,可以直接领取免费额度。第二种,直接注册小米 ai 开发者账号,注册完成 新用户直接送免费体验额度。讲完小米,再来说 deepsea 配置怎么获取,看这里,只需要配置基础信息就能使用,点击新建配置信息生成后直接复制保存,直接叫我配置里的填写就行,官方皆可,文档 也是同一个地址,然后就开始对话,开启你的 ai 之旅了。整套流程就这么简单,配置完就能无缝切换小米 d p c k 模型。

一套 ai 编程工作流能把成本压到很低, deepsea v 四搭上 cloud code, 思路不是堆最贵的模型,而是把钱花在刀刃上。 关键就在于, deepsea v 四很适合长链路代理任务,它不是只会短打几居,而是偷啃更省长,上下纹理更耐用,特别适合反复调用、持续执行的编码流程。 更重要的是,它的定位非常清醒,不是去硬碰 g p t 五点五或 opps 四点七,而是承担那些不值得烧高级额度的活儿, 比如快速搭建自动化脚本、基础胶水代码、一次性小工具,甚至单元测试和工具调用这些任务,它往往够用,而且便宜得多。这样一来, cloud code 里的高价模型就能留给真正复杂、需要高判断力的环节。 deepsea v 四还有两个很关键的底牌,一个是一百万 toc 的 上下文窗口,长代码、长文档、长任务轨迹都能装得下。另一个是 mit 许可,意味着本地部署和二次开发空间很大,精准表现也说明它不是便宜但弱。在软件工程、浏览器终端、工具调用这些 a 阵场景里都能干活儿, 但边界也要看清,它更适合低风险、一次性快速完成的任务,不太建议直接拿去做严肃 web 开发、代码审查、文档写作或安全审计,因为这些场景一旦出错,代价就不只是没写好,而是可能影响工程质量。 最后,这个成本差距很直接。 deepsea v 四的平均 token 成本大约比 g p t 五点五和 opus 四点七便宜百分之七十六。这就解释了为什么它适合做 cloud code 的 备用驱动,不是替代最强模型,而是分担最琐碎的工作。 ai 编程真正聪明的用法,从来不是把最贵的模型一直开着,而是让不同模型各做各擅长的事。关注全球 ai 速递,获取更多 ai 前沿资讯!

你给 a i、 c 的 东西越多,它就越蠢。最近 cloud code 的 核心开发者呢,写了两篇的技术博课,把他们团队踩过的坑呢,全盘托出了。这些坑不光是搞开发的人会踩,任何在用 ai 的 人都会踩。他们总结出一个原则,叫做渐进式批录。 一句话讲的就是别一股脑的把所有的东西都摊在 ai 面前,让他自己按需要的去找。这个原则是他们栽了三次跟头,才真的想明白了一件事情,第一个坑,你替 ai 准备好的资料呢,他反而消化不了。 cloud code 最早的做法是,用户一提问,系统就自动把相关的资料塞到对话里边, 听起来很贴心对吧?但后来砍了,因为这些资料呢,是你替他选的,他根本不知道自己为什么要看这些东西,改成让 ai 自己去搜之后呢,效果反而变好了,他自己清楚自己缺什么,自己找到的东西呢,才接得上他的思路。 你用 c 的, 就像是你替别人做了笔记,然后递给他,他翻都懒得去翻一下。第二个坑呢,就是选项越多, ai 越不会选。 你可能会觉得多给 ai 几个工具总没有坏处,对吧?但实际上每多一个工具呢, ai 做决定的时候就多一个选项,要纠结, 就跟你打开外卖软件一样,三家店呢,你很快就能选,三百家店,你就得刷半个小时。 cloud code 团队一共才给了 ai 大 概二十个工具,还觉得太多了,遇到新场景怎么办?他们不加工具,而是让 ai 在 需要的时候自己去发现和调用, 不多给选项,但能力确实扩大了。第三个坑,最隐蔽的,曾经有用的东西会过期,早期 cloud code 记性差,经常呢,干着干着就忘了前面在做什么了。团队就做了一个代办清单,每隔几轮呢,还谈个提醒,别忘了,你的当前任务。 当时确实管用,但模型升级变聪明了之后,问题来了, ai 一 看到这个提醒,就觉得这是一个死命令,我必须严格执行,不能改。本来该灵活调整的事情,它死守着不动了。 就像你给一个实习生列了一个详细的操作手册,他成长为骨干之后呢,你还拿着那个手册管他,他反而放不开手脚。 你看这三个坑呢,有一个共同的规律,每一次出问题,都不是因为给少了,而是因为给太多了。这个规律其实不光是搞开发的人需要知道,你平时用拆 jpt, 用 cloud, 用任何的 ai 工具,本质上都在面对同一个问题,你给他的信息,到底是在帮他,还是在干扰他? 我自己有一个很直接的体会,我用 cloudco 的 时候呢,之前配置文件写了好几百行的规则,结果 ai 反而变得束手束脚,什么都要跟我确认。 后来砍到十几行,只留最核心的信息,详细的东西让他需要的时候呢,自己去找,效果立刻好了一大截。所以,如果你发现你的 ai 最近好像变笨了,先别着急怪模型,回头看看你给他的那些提示词,那些规则,那些上下文,是不是太多了。 整个 ai 行业花了一年多的时间,终于搞明白了一件事,信息不是越多越好,信息是有成本的,你 c 给 ai 的 每一条规则,他都得花算力去理解,去权衡,去遵守。 你以为在帮他,其实是在占用他本来可以用来思考问题的空间,少给一点他反而会做得更好。这个道理说出来很简单,但你看啊,连造 ai 的 人自己都踩了一年多的坑才搞明白。好,今天就聊到这,我是胡博,我们下期视频再见。拜拜。

我用 cloud code 给我的一人公司搭建了一个十亿人的专家团队,他们没有工资,不需要工位,但每一个都比我专业。这里就是我要给大家演示的十一个人的软件研发团队。 第一个的话就是产品经理,第二个的话就是架构师、设计师、数据库工程师、后端工程师、前端工程师、 小程序工程师、 q a 测试工程师、代码评审专家、安全工程师、运维工程师,然后就是总指挥。 那个时候我就有个想法,就是做一款 app, 让我用手机可以直接对话操作电脑里的文件和数据。然后我就有了一些问题,比如需求理不清,不知道要落地哪些功能,不知道设计上面有多复杂,也不知道要做多久,也不知道怎么去保证代码质量, 然后这些问题我都不知道该跟谁去讨论。然后照着这个思路,我给公司成立了五个团队,第一个就是刚才说的标准开发团队,第二个是小程序团队,第三个是自媒体团队,第四个是商业闭环团队,第五个是公司的一些服务团队。然后在这里简单演示一下我是如何在 cloud go 的 里面调用我的标准开发团队的。 然后这里的话就可以看到我的标准开发团队已经上岗待命,被激活状态。这里简单罗列一下我的团队成员的呃一个职责,呃产品经理的话,就是要通过拆解用户的需求来输出 prd 企业文档,然后把企业文档给到架构师,架构师的话要出 api 企业和 db 的 scan 码, 最终能够达到这个上线的目的。那整个过程呢?我其实就是充当一个甩手掌柜的角色,因为我的团队完全是一比一复刻真实的研发团队的,所有的 prd 签约文件都是后续工作的一个基石。 我们都知道在正常的软件研发过程中,很多问题的沟通,比如说跟项目经理的沟通,比如前后端之间的沟通,比如前端和产品经理,后端和产品经理的沟通等等,过程中都会遇到很多问题, 其实很多时候遇到问题的根因就是因为没有沉淀的文档,或者文档没有持续的更新导致的,所以整个过程中的企业文档是产品靠谱的根本。下面给大家演示一段我通过这个团队做出来的一个 app。 以上给大家演示的这款智联远控的小程序呢,不是为了卖,是为了让大家看到一件事情,就是从一个想法到用户真正能够操作的一款 app, 从想法到上线,全程都是由 ai 团队帮我完成的,我只在关键时刻做出决策, 而这件事情比产品本身重要一百倍,只要你有一点点想法,团队就能帮你完善到完整且专业。 如果大家也想搭建一个自己的软件研发团队,实现从需求到一键上线的目的,请在评论区里扣一,最后记得一键三连哦,不然下次刷不到我了。

我找到了一个免费使用 cloud code 的 办法,不需要自行购买,墨星厂商的扣丁 plan 也可以使用。今天分享给大家,我刚刚成功领取到了小米赠送的七亿 token, 够我使用一段时间了。 看完这个视频,你也可以领取并进入到 cloud code 之中。这就是小米最近推出的创造者百亿 token 激励计划。我们只需要填写五道题目就可以免费申请领取。 我们申请这个活动只需要下面两步,第一步,打开活动官网,然后填写页面中的问题。前三道题随便填写,但真正卡人的就是第四题。 因为很多小白不知道如何使用 agent 或者 ai 构建项目,但没关系,我已经将我成功申请使用的项目描述可进入到 cloud code 的 详细步骤,写入到了文档之中想要的评论区留言。 我们在完成题目提交申请之后,我们就只需要等待审核。审核通过之后,我们会收到小米官方的邮件,邮件中会包含开放平台的地址。我们进入到开放平台,首先需要进行登录,如果你还没有注册过小米账号,可以先使用手机号进行注册。注册完成之后,你也可以使用手机号进行登录。 登录完成之后,我们可以点击右上角的头像,选中个人中心,然后再绑定我们申请使用到的邮箱。绑定完成之后,我们再点击控制台,然后再点击左侧的订阅管理, 我们就能看到我们领取的 token plan。 在 这里我们可以申请 token plan 的 专属 api key。 下面就是将我们领取到的 token plan。 通过 cc switch 接入到 cloud code 之中,我们需要打开 cc switch, 然后点击加号添加一个新的模型供应商。在这里我们选择小米 miimo, 选中之后我们向下滑,然后将上面申请到的 api key 填写在这里。注意这个请求地址需要改成这个,因为这是 token plan 的 专属请求地址,具体的地址我已经放在文档中了。下面的模型最好也贴换成小米最新的 mimo v 二点五 pro 模型。 配置完成之后,我们点击保存就可以了。添加完成之后,我们点击骑用小米 mimo 的 配置就可以了。 我们可以打开终端,启动 cloud, 然后检查我们的配置是否生效。 token 我 们已经成功领取到了, cloud code 也接通了。如果你想知道如何使用 cloud code 实战,麻烦点个关注,我们下期开始讲解实战内容。

cloudcode 是 今年最热门的 ai 工具之一,接下来我会把两件事给你讲清楚,第一, cloudcode 跟你熟悉的 ai 聊天工具到底什么不一样?第二, cloud 的 四条产品线作为国内用户,我们最应该用哪一个?听到 cloudcode 的 这个名字的时候,大部分的第一反应就是, 哎,这不是跟程序员写代码的 ai 吗?这个理解其实不完整,恩施诺比格官方确实把它叫做编程智能体,但用户早就把它用成了一个什么都能干的通用 ai 助手。 那为什么可洛克的能做这么多呢?因为它是一个会编程的 ai, 它不仅能写代码,还有一种其他 ai 没的能力,就是它可以现场造工具。 举一个我自己干过的事情,创享大的 ai 平台有一个 obc 资讯的模块,要汇总全国各个城市针对于一人公司的政策,这个是已经实现了效果。 这个功能看起来其实很简单,但是要做完整需要四步。首先,我们需要扎起全国各个城市针对于一人公司的政策原文并进行解读,然后转成 html 美化排版, 最后推送到数据库给小程序展示。并且我还让他每周定时给我扫一遍全国的数据,并进行更新。 普通对话 ai 肯定做不到,他最多是帮你找几个链接,抓的数据也不完整,链接还有点不开的,更别说把数据推到本地并推送到数据库里面去了。 格式库的不一样,他会自己做计划,然后调用插件写,派上脚本,装好依赖,然后自己跑。 你看这个汇总文件,他会把标记的每一条扎起的状态,哪些成功啊?哪些失败啊?失败原因是什么?然后下次再跑的时候就会直接跳过与成功的只解锁没有过去的地区。 这只是一个例子,他能干的事情其实远远不止写代码。我们再来看下面的例子,把硬盘里面一千份文件按内容自动分类并且规档, 把杂乱的几十个网页和 pdf 提起核心,并且总结圣 markdown 纯净本地制度库里面做一条短视频直接发布到平台,然后根据 excel 的 数据啊,做一个多维度统计分析的网站,你只需要下达目标,他自己判断就会去做,不会做的就会写个工具来做。 这里有个关键的差异,普通 ai 只会给你一段代码,让你自己去跑 code, code 的 运行方式是写代码,跑测试,然后发现报错自动改,然后再跑一遍给你结果。 他是带闭环能力的行动者,你给目标他自己跑完所有的步骤。这就是智能体和对话 ai 的 根本区别。讲完定位的话,我们讲用法。先拎清一个很多人会混的概念, cloud 是 ansono 前平台的 ai 产品线,三个形态,网页端、桌面端和移动端。 cloud code 是 特指基于命令行的 c r i 工具,是生态里的第四种形态,前三个大家都知道,第四个才是 n s o p k 真正的大招。下面我们来介绍这四种形态的区别。 第一个 cloud 的 网页端,打开浏览器,输入 cloud, 点 ai 登录就能聊,但是看不到你本地上的文件,也不能操作你的电脑,一句话就是它是一个纯聊天的对话框。 然后第二个是 cloud 的 桌面单功能,是最齐全的三个主要的模式, bot 模式就是原来的聊天 app call work 模式,二零二六年的一月份上线的,面向不会写代码的普通人, 像跟助理聊天一样,把需求说清楚就行,他会自己规划执行,调用本地的文件和外部工具,最后把成品交还给你。 code 模式是把 c i 版的 codecode 的 核心能力啊,搬到了图形界面,想用 codecode 又不想碰终端的,就用这个。如果你不开发大型项目,桌面单其实是最适合普通人的形态。图形界面开箱即用,不用碰命令行体验最顺 门槛主要是海外的账户加订阅者。不过新版的桌面端有个开发者模式,能外接 gm、 kimi、 tiffany 等这些国产模型的 api 配置入口比 ci 更隐蔽一点,但路是通的。 第三个是 cloud 的 移动端,手机上的 cloud app, 手机形态天然就受限了,只能用官方账号和官方模型,定位也很清晰。 你碎片时间聊天查询工具,路上想问什么,查个资料方便。搭配桌面端的 dispatch 功能,还能做手机派活桌面执行手机搜结果。第四个重头戏, c l i 终端,这是咱们今天要讲的主角, c l i 就是 你 mac 上的终端, windows 上的 power cell cloud code。 c l i 就是 跑在命令卡里面的智能体,它有四个特点,能嵌进任何工具里面。 命令行程序的好处就是想在哪用都行,脚本里用,自动化里用,插进别的 ai id 里面也能用。然后第二,指定文件夹后直接动手,它会给你一个项目文件夹, 它就能读改、创建、删除里面的文件,跑命令、部署操作 get。 全在你本地。第三,能接国产大模型, gm, kimi, tbc 都能接,不用海外账号,不用海外支付,那怎么配置?我们后面会有单独的章节会来介绍。 那第四点是能切入任何的 a i d。 你 像国内的去 code codebody, 谷歌的 inequality 这些 a i d。 只要能调出内置的终端, codecode 就 直接可以用了。配置一次全部都能通用。四种形态没有高低之分,是不同场景的不同路口。 偶尔问答,我们用网页端,不想碰命令行,用桌面端,碎片时间,我们用移动端,想接国产模型或者深度玩的,我们用 c l i 的 终端。 如果你已经有了一个 code 的 账号,比如 pro 或者 max, 这个账号的四种形态之间是通用的,网页、桌面、移动、 c l i 都是同一个账号,登录 对话记录、订阅额度,付费权益全部共享,不用分别去付费。最后给跨界小白打一记防御针,别被命令行和这个 k 框框给吓到了。 c l i 不 需要你记住任何指令,你还是能用大白话跟他沟通, 没有任何使用门槛。后面几张我也会带你一步步的配好环境。这一集我们就讲两件事,第一, cloudcode 不 只是一个编程工具,它是一个能自主造工具的工具。然后第二, cloud 的 产品线分为网页端、桌面端、移动端和 cloudcode c l i 端,官方订阅账号,四端通用,没有官方订阅的,我们推荐直接用 cloudcode c l i 端。