如果一个高手用 ai 开发的水平是九十分,那么这个人至少是九百分,因为他就是 cloud code 的 创造者 boris charney。 最近, boris 接受了一场采访, 里面分享了很多他自己使用 codecode 的 真实技巧。说实话,看完后我最大的感受就是我们很多人还在把 codecode codex 当做一个开发工具,但在他手里, codecode 已经变成了一整支 ai 开发团队。所以这期视频我想重点拆解他最值得普通人学习的三个用法, 看完后你的 web coding 功力定会大涨。先说第一个技巧,不要只开一个 ai 窗口,要并行开多个任务。 boris 说,他现在很多工作都是直接在手机上完成 的。他打开 cloud app, 左边有一个 code 标签页,里面会同时跑很多个绘画,通常至少有五到十个,而每个绘画里又有一堆的 a 件在干活儿。采访里,他甚至说,白天可能有几百个 a 件在跑, 晚上会有几千个 agents 做更深层的工作,比如一些 agent 负责修 bug, 一 些 agent 负责写测试,一些负责改前端,一些负责查看用户的反馈等等。听起来很夸张,但这就是当你不再为 token 费用担忧时能做的事情。 第二个技巧是他特别推荐的用 loop 让 ai 循环干活。 boris 说,他现在越来越多地使用 loop 这个东西,可以理解成让 cloud code 定时执行任务,比如每分钟跑一次,每天跑一次。 他自己举了几个例子,一个路普专门盯着他的代码任务,哪里报错了他自动去修,如果项目更新了,他就自动去同步。 另一个路普会持续检查整个项目的运行状态,确保不会宕机。还有一个路普,每三十分钟抓一次推特上的用户反馈,然后自动帮他分类整理。 有了这种定时任务,你就可以持续让 ai 自动优化和迭代你的想法了。第三个技巧,让 ai 自己验证结果。 boris 在 采访里反复提到一个思路, ai 不 能只是写完就完了,他还要跑测试发现错误持续修正。也就是说,你要给 ai 一个反馈必还。这也是很多人用 ai 编程效果特别差的原因, 很多人只会说,帮我写一个功能,到底什么才算真正完成了,其实并没有讲清楚。更好的做法是,你要让 ai 自己运行测试,检查报错,修复问题。 更重要的是提前把验收标准清晰的告诉他。比如页面最后要长什么样,功能必须做到什么程度,哪些地方绝对不能出错。 因为很多时候 ai 不是 不会写,而是不知道你真正想要的结果是什么。好了,以上就是 cloud code 的 创造者亲自分享的三个用法,赶紧用起来吧!我是阿朱,关注我,让我们一起在 ai 潮头冲浪!
粉丝1.5万获赞49.1万

很多人一开始用 cloud code, 其实有个困惑,就是你的这个对话记录,你提的问题,还有他的回答,有一些是对于你来说很有价值的,以后可能会去查它,但是呢,这个 cloud code 因为是在终端里运行命令行的,它默认没有显示出来这个历史记录, 像这个 girl, 还有 gbt, 还有豆包这种,它是有这个历史对话记录的,因为这些东西它是在这个网页里很方便的,可以查。那 cloud code 这边就是个命令行界面啊,然后这是你问的问题,然后他回答, 然后你把这个终端呢,你关掉,关掉之后它就没了,下次就是一个新的了。那其实 cloud code 提供了一个 reload 这个命令, reload 这个命令, 那这里呢,你就可以看到,他可以把你的历史对话包括他的回答都列出来,那这里有一个设置,有一个搜索底下是最近的一个对话, ctrl a, 那 么可以列出来更多的所有你的历史对话。可以用光标切换某一个历史对话,找到你想要看的那个,然后空格就可以回到原来的这个对话状态,这个其实很重要啊,这样呢, 你同样一个问题问好了之后可以随时回来查,不用再去同样的问题重复问他了。一个是给你自己省 token, 因为这个东西要米的,还可以省公共资源。你一个问题重复问没有意思,浪费他的算力,然后还浪费你的 token 啊,这个其实是一个很好的功能,只是很多人可能还不知道。

如果你现在用 cloud code 只会一句一句发需求,那我建议你先别急着让它写代码,因为你可能不是不会用 ai, 而是根本没把它的隐藏能力打开。这期直接讲六个很多新手没打开的核心能力。开完以后, cloud code 才不是一个临时帮你写代码的聊天框,而是一个能长期配合你的开发搭档。 第一个项目,记忆入口名叫 innit, 很多人每次开新绘画都要重新解释技术栈、目录结构和代码风格。 innit 的 价值 就是让 cloud code 生成 cloud md 这种项目,说明先认识你的项目,再开始干活。第二个, play mode。 新手最容易犯的错就是还没想清楚就让 ai 直接改代码。 play mode 的 意义是先让它读项目,拆方案,判断风险,再进入执行。第三个 compact, 压缩上下文,绘画异常, ai 很 容易被前面的信息冲淡,越聊越散。 compact 就 像给对话做一次整理,把真正重要的方案接口和未完成任务留下来。 第四个,自定义命令,官方叫 custom slash commands。 很多人每天都在重复输入同一类提示词,比如代码审查、提交总结、性能检查。它的价值 是把常用提示词沉淀成自己的自定义命令,命令以后随时赋用成工作流。第五个, sub agents。 复杂项目不要总让一个 ai 绘画硬扛所有事情,它的关键是分工,主绘画统统方向, the agent 分 别负责审查、排错、测试和文档。第六个 hoops, 这个能力很多新手完全没碰过,但它决定了 cloud code 能不能守流程。你可以把它理解成自动质检员,改完代码以后提醒检查 结束任务前提醒验证结果。所以真正拉开差距的不是会不会问一句帮我写代码,而是你有没有把 cloud code 配成稳定工作流,项目记忆解决重复沟通 play mode 解决乱改压缩上下文解决跑偏自定义命令解决重复提示词 sub agents 解决分工 hooks 解决交付质量这六个能力建议收藏起来慢慢吃透。关注我,后面继续把 cloud code 的 高阶玩法拆给你看。

可拉库的必须要知道的三个命令啊,首先就是编辑,它直接会帮你在项目中生成项目说明、代码规范,技术栈要求,能够让 ai 一下就懂你要做什么。第二个就是瑞众,如果你不小心关掉了可拉库的窗口啊,重新打开选项继续上一轮对话,就可以直接运行这个命令啊。第三个命令就是 compact, 如果你上下文很长的时候运行这个命令会直接帮你压缩上下文,能够节省 token, 也能避免 id 的 因为上下文过长而跑偏。

你敢信吗? cloudcoat 的 启动速度比这个工具慢了整整二百四十五倍! jcoat 手帧只要十四毫秒,而 cloudcoat 要三点四秒, openai codex 也要八百八十三毫秒, cursor 将近两秒。 jcoat 的 渲染帧率超过一千 fps, 你 看不到任何闪烁。 它是一个用 rest 丛林打造的 coding agent, 性能碾压所有主流竞品,内存差距更离谱, j code 单绘画只占二十八兆, cloud code 要三百八十七兆,差了将近十四倍。当你开十个绘画并行工作, j code 总共才二百六十一兆, cloud code 要吃掉二点三 g。 open code 更夸张,直接干到三点二 g。 j code 每多开一个绘画,只增加不到十兆内存,限性增长完全可控。这是最让我兴奋的功能。 swarm 多 agent 协助你同时开多个 agent, 在 同一个仓库工作,它们会自动发现彼此 agent。 a, 编辑了一个文件 agent b, 马上收到通知,自动检查有没有冲突。每个 agent 还能自己 spawn 新的队友并行干活,一个变三个 消息,支持私聊、广播、仓库内群聊三种方式,团队管理全自动。传统 ai agent 每次开心绘画就像失忆了一样,什么都要重新说。 j code 不 一样,它有完整的语义记忆系统, 每轮对话自动生成向量嵌入,通过鱼弦相似度自动匹配相关记忆。你不用主动去调什么记忆工具,它自己就想起来了。而且它会自动提取、存储、整合记忆,还有 m b n mode 在 后台自动帮你整理,这才是真正像人类的记忆方式,这个概念太疯狂了。 j code 的 agent 可以 进入自我开发模式,直接修改自己的原代码,编辑编辑测试重载,二进置全部自动完成,不需要写插件,不需要做扩展能力,完全没有上线 改完之后自动重载,所有活跃绘画无缝切换。开发者建议用最前沿的模型来做这件事,因为 j code 的 代码库可不简单。 j code 是 rust 丛林打造的,不是套壳,它自研了 mermaid 渲染库,比 python 版快了一千八百倍。 还有自研终端 handterm 实现原声滚动, agent graph 会返回文件结构信息, agent 不 用读整个文件就知道里面有什么。最实用的是跨 agent 绘画恢复, cloud code 崩了,直接在 j code 里 resume 继续。 三十多个 ai provider 全支持,包括 deep seek, ala ma brock 等等,还有内置的浏览器自动化, firefox agent bridge 一 型命令就能用。 j code 现在有超过一千二百克 star, 每天还在快速增长。 mit 开源协议完全免费,支持 linux, macos 和 windows 全平台, 快二百四十五倍轻十四倍,渲染超一千帧,这就是 rest 丛林打造的优势。关注我,下期继续带你发现 deephop 上的宝藏项目!

我抓包了 cloud code 系统提示词,发现了什么惊人的秘密?下面我们来一起揭开这份提示词是怎么被拿到的呢?用 proxima 拦截 cloud code 的 网络请求,可以直接看到每次对话的完整系统提示词。约七千字,是 antropics 写给 cloud 的 行为说明书。很多人以为 ai 能力全在模型参数里,但产品及 ai 的 真实行为 很大程度由系统提示词决定。开头只有一句话,你是一个帮助用户完成软件工程任务的交互式智能体。后面七千字都是在解释这句话。一、执行任务, ai 被明确告知不要过度帮忙提示。此里列了一串禁令,都是 ai 天然倾向于作,但 anthropic 主动叫停的行为。不要添加多余功能或引入抽象。不要为假设的未来需求设计三行类似代码,比过早抽象更好。默认不写注目指在为什么不明显时才加对。探索性问题,先给二到三句建议,别在用户同意前就动手实施 前端改动,必须在浏览器真实测试,不能只靠类型检查说成功。二、谨慎操作可逆与不可逆的边界。核心逻辑按可逆性区分对待编辑文件运行测试等。本地可逆操作,可自由执行删除文件、强推 get reset、 hard 推送代码、关闭 p 二、向第三方上传内容。这些必须先确认原话是暂停,确认的代价很低,而不必要操作的代价可能非常高。用户批准一次不等于永久授权。遇到障碍也不要用 noverity 绕过,而是找根本原因修复。三、工具使用而语气细到令人惊讶的规范, 优先用专用工具,而非 bash。 无依赖关系的工具并行调用,有依赖的顺序执行任务。委托给子代理后,不要自己重复搜索。语气规范,同样细致。禁用表情符号,回答简短精炼。引用代码带文件路径和横号。工具调用前不要加冒号, 因为工具调用不会直接显示,让我读取文件。工具调用这样的结构对用户是断裂的,应写完整句子加句号。四、文本输出哲学, 沉默不是美德,核心观点出乎意料,沉默不是好事。发现问题,改变方向,遇到阻碍时要给出简短更新。一句话几乎总是足够,但同时不要叙述内部思考过程。两条合在一起,就是说有用的话,不说废话。每轮结束给一两句总结,改了什么,下一步是什么。简单问题直接回答,不要套标题和章节结构。 五、自动记忆被教会该记什么,不该记什么。 word code 有 一套基于文件的持久记忆,用来跨对话、积累写作上下文该记什么。 四类用户记忆、反馈记忆、项目记忆、参考记忆,不该记什么?代码结构架构、文件路径 gitlab 历史 gitlog 是 权威调试方案,修复在代码里 临时任务状态,那是当前对话的事,记忆会变陈旧,用前必须验证记忆与代码冲突时信任现在观察到的反馈记忆。还有一条,不能只记纠正,也要记成功做法,否则 ai 会变得过于谨慎。你学会了吗?看到这里的小伙伴别忘了关注哦!

我今天给大家说一下啊, codex 啊,还有这个 cloud code, 还有 opencloud, 这三个到底什么区别?很多人根本不知道它这三个区别到底在哪里?普通人到底怎么去用起来?普通人到底适合用哪一种工具 能够帮助他在 ai 时代实现这个?不管说这个工作效率提升还是财富的跃迁,咱们这几个工具一定要了解清楚。第一个我们讲的这个, 嗯, cloud code, cloud code 呢,它是一个类似于编程代码的这样的工具,它对这个比较懂研发啊,懂这个数据代码的人,他比较友好,因为不用再去写代码了。 但是呢,对于小白来说入门其实挺难的,我们前段时间一二月份的时候一直在用这个 cloud code 的, 但是我发现对于普通用户上手来说是相对来说没那么容易。 那我第二个讲的就是这个 codex, codex 是 今年的五月份的时候,我们五月一号的时候,我已经开始正式在用起来了 啊, codex 给我整体使用起来感觉就是非常的友好啊,我不懂编程,不懂代码,但是它依旧可以操控我的电脑,依旧它可以写代码,就我只要发送指令就可以了。它所以说它对小白来说更友好,而且它内置了 gbt 的 这个大模型在里面,所以它有理解能力。 最重要的是什么?它没有太大的算力消耗的这个 token, 它不像这个其他的,像这个 cloud code, 像 opencloud, 它可能更多的是要调这个 token, 要接 api, 但是这个 codex 是 不需要的啊,我们只要订阅它就可以了, 所以整体来说还是比较省算力的,我充了两百美金啊,反正是非常够用的。然后讲的是这个 opencloud。 opencloud 前段时间龙虾爆火啊,那很多人都第一反应是啊,你们是不是在使用这个 open? 但是我跟大家讲,我们并没有使用。第一呢,觉得他安装的起来太复杂了,不适合我们普通人。第二呢,他没有大模型的这个能力,他也要掉别人的这个大模型。第三呢,就是他的算力消耗的 talk 是 非常大的,很多普通人根本支撑不起。所以综上所述的话, 如果说入门级别的,我觉得还是建议大家使用 qdax 已经够大家了,而且这个能力非常强。想跟小林姐姐学习的啊,在评论区扣六六六,我来教大家。

这期视频呢,将会教会你使用 cloud code, cloud code 呢,和只会聊天的对话式 ai 不 同,它可以在你本地的电脑上自主运行。那为什么 cloud code 很 强呢?因为它拥有很强的 highness, 可以 理解为各种工具的集成。 cloud code 虽然有 code 这个词,但是它做的好的不仅仅是编程。我们直接进入安装环节。首先呢,我们打开浏览器搜索 vs code, 我 们找到官网, 在这里呢有一个其他安装包,之后根据你的系统下载对应的安装包即可打开安装包,我们同意协议下一步 完成安装之后呢,打开 vs code, 如果你是第一次使用,那么你的 vs code 应该是英文的。这时候呢,我们去左边点开四个小方块组成的那个图标,在里面搜索, 找到下载量最多的那一个,下载完成之后,右下角会让你重启,我们直接重启。嗯,这时候我们就可以安装 cloud code 了,我们 ctrl alt 加 i, 打开它自带的 agent, 我 们可以直接用这个 agent 来帮我们安装 cloud code, 告诉他帮我安装 n o d e, 并且用 n p m 安装最新版本的 cloud code。 如果这样说呢,他会默认把 cloud code 安装在 c 盘。 安装完成之后呢,我们创建一个文件夹,将这个文件夹用 vs code 打开, 选择信任作者,在最上边的菜单栏选择终端,新建终端,第一次下载使用默认终端就出现在 vs code 的 下边, 我们在终端里面输入 cloud, 就 可以启动 cloud 了,我们点信任作者,这时候的 cloud 是 使用不了的,因为我们安装的 cloud 就是 一个工具包,还没有给它接入大模型, 我们给它接入 deepsea 微四大模型,如果想把图奥的 code 和 deepsea 组装到一起,我们需要一个链接软件,这个软件呢就是 cc switch, 如果你们下载的很慢的话,可以去评论区拿我的百度网盘的链接下载。 下载完成之后呢,我们在上边选择 cloud, 在 右边点击加号。供应商呢,我们选择 deepsea, 点进去之后,我们只需要填写 apikey, apikey 从哪获得呢?我们在我们打开浏览器搜索 deepsea, 进入 deepsea 的 官网, 找到 deepsea, 找到 api 开放平台, 我们只需要在这里创建一个新的 apikey 就 可以了。 之后呢,将 a p i k 复制到 c c switch 里边。这时候呢,我们就可以让 cloud 帮我们做小项目了, 我让他帮我做一个视频项目管理网站吧。值得注意的是,我们的对话框下边有一个 plan mode on, 在 这个模式下呢,他会倾向于跟你讨论方案,哎,出来了,我们随便选一下。 而 cloud code 实际上有三种模式,第一种呢就是我们刚刚说的 plan 模式。第二种就是默认模式,这时候呢,它会自己衡量哪些能做,哪些不能做,也会自动的切换模式。第三种呢就是编辑模式,这个模式下它有权进行文件修改,但是有些命令还是需要经过你的审核。 这三种模式呢,按 shift 加 tab 可以 切换,但这三种模式都有点麻烦,它总是会找你确认。 所以 c c 呢?还有一种模式,我称它为无视风险模式,它需要在打开 c c 的 时候加上这样一句话,因为绝大部分情况下我也不会管 c c 要什么权限,我都是直接同意的,这时候会多出来一种模式,当然这四种模式依然可以自动切换。完全做好了我们可以看一看。 嗯,还是不错的,之后大家就可以出几期视频,把我觉得常用的功能分享给大家。

cloak 净化的一个地方就是他现在在处理一些比较复杂的任务的时候,他会自己拆分几个指令去执行这些任务。 也就是说你一个复杂任务,他可能会派几个不同的角色吧,去做不同的事情,然后完成之后他再去汇总他对应任务的一个结果,然后再给到一个主 n 准里面,这样的话对上下文的一个 嗯,压缩我理解是有帮助的,因为如果你全部都是主 n 卷去做的话,你的所有的上下文可能就很快就会爆,但是你要是主 n 卷去,嗯,分别去做调研, 然后再汇总结果给到主 n 卷的话,那主 n 卷的那个上下文就可以得到比较好的控制。这是最近使用 coco 的 一些感受吧。

今天我们要聊的是 cloud code 的 最佳实践。 cloud code 不 仅仅是一个聊天机器人,它还是一个代理式编码环境,能读取文件,运行命令,做出更改,甚至可以自主解决问题。 但像所有强大的工具一样,要真正用好它,需要我们理解它的工作方式和一些经过验证的模式。我们进入正题,所有最佳实践都建立在一个核心约束上, cloud context window, 它保存着整个对话,每条消息,每个读取的文件,每个命令的输出。当这些内容填满时, cloud 的 性能就会下降,可能开始遗忘早期的指令或者犯更多错误。 所以 context window 是 你最需要管理的资源。右侧列出了四个主要的消耗者,读取的文件、历史消息、命令输出和 cloud 的 回复。频繁使用 clear 在 不相关的任务之间重置,用 safari 隔离探索任务,以及使用 compact 进行智能压缩。 记住,把 context 当做有限的内存,而不是无限的硬盘空间。接下来这个实践可能是今天最高杠杆的一个给 cloud 验证自己工作的方式。什么意思呢?就是不要只告诉 cloud 你 要什么,还要给它判断成功或失败的标准。比如 与其说实现一个验证邮箱的函数,然后运行这些测试,用力看看结果对不对。有了明确的标准, cloud 可以 自我检查和迭代,而不需要你做唯一的反馈回路。验证方式有很多,测试套件,截图对比、 link 检查,或者简单的 bash 命令做输出校验。这一页讲的是工作流的节奏, 很多时候我们会忍不住直接让 cloud 开始编码,但这可能解决的是错误的问题。正确的节奏分四步,第一步,用 plan mode 探索代码库,只读不改。第二步, 让 cloud 创建一个详细的实现计划,你还可以按 ctrl 加 g 直接编辑。第三步,切回 normal mode, 让 cloud 蛋计划实现。最后一步,提交并创建 pr。 对于修复拼写错误加日制这些简单任务,直接上就行。核心原则,如果拿不准怎么改或者要改多个文件,就花时间规划。一句话能说清的 diff 直接开干。这一页是关于如何给 cloud 更精确的指令。我把四种策略放在左侧。 第一,限定任务范围,说清楚哪个文件,什么场景怎么测。第二,指向来源,让 cloud 去看 get 历史或相关文档,而不只是凭猜测。 第三,参考现有模式,代码库里已有的实现就是最好的规范。第四,描述症状,给到错误信息位置和修复目标。右侧是提供丰富内容的四种方式,用 at 引用文件粘贴截图,提供 url 或者直接管道传数据。 你越精确,需要改正的次数就越少。当然,在探索阶段,模糊一点的提示反而可能有意外收获。 cloud md 文件是灵魂配置文件,每次对话开始时自动读取运行 inate, 就 能根据项目结构自动生成一个基础版本, 然后你可以持续优化它。左侧是具体什么该写,什么不该写,应该包含 cloud 猜不出来的 bash 命令、代码风格、规则、测试偏好、分支命名、约定架构决策,不要写 cloud 能从代码里读出来的东西。标准语言、约定长文档、 cloud md 文件可以放多个位置局的、 cloud cloud md 项目共享的以及个人的本地文件。关键原则是保持简洁,每加一行就问自己 删掉这行 cloud 会犯错吗?如果不会就删掉。这一页展示的是扩展能力的全景图,有五个主要扩展点, skills 放在 cloud skills 目录下,按需加载领域知识和工作流,不会像 cloud md 那 样每次对话都加载。比如你定义一个 fix issue skill, 直接传 issue 号就能调用。 subbots 是 最强大的工具之一,它们在独立的 context 中运行, 可以用来做安全审查,代码审查这类消耗大量 context 的 任务,不影响主绘画。 m c p servers 连接外部生态系统,数据库, figma, notion 都可以集成。还有 hooks 确定性的脚本,比如每次编辑后自动跑 lint plugins, 把前面几个打包成一个可安装单元,以及 cli 工具 gh os, 这些是跟外部服务交互最高效的方式。这一页是关于怎么和 cloud 有 效沟通以及管理你的绘画。左侧是沟通技巧, 第一,像问资深工程师一样提问日制怎么工作的,为什么用夫而不是 bar。 第二,对于大功能,让 claud 先采访你,他会用 escuircass 整挖出你没考虑到的边界情况, 然后写一份完整的规范。第三,尽早改正方向,发现偏了就用 s 停下两次,改正不行就 clear 重新开始。右侧是对话管理,自动压缩,在 context 快 满时帮你总结 b t w 做清量查询,不占历史 检查点,让你能回到任何之前的状态。还有跨绘画恢复功能,让任务可以跨越多个终端绘画。对于自动化和扩展, cloud code 可以 水平扩展,不再是一个人一个绘画的模式。首先是非交互模式,用 cloud 杠屁命令加提示, 可以集成到 c i pre commit hooks 或脚本中,输出格式支持纯文本 j s o n 和流式 j s o n。 其次是多绘画并行,你可以同时跑多个 cloud。 用 writer review 模式,让一个写代码,另一个在干净的 context 里审查,这样审查质量更高。 第三个是跨文件删出,先让 cloud 列出所有需要迁移的文件,然后写个脚本循环调用 cloud p 并行处理。 别忘了用 ltooth 限制权限,安全第一。最后是 auto mode 分 类器,自动审查命令,只阻止有风险的操作,日常工作无提示执行。 这一页列出了五个最常见的坑,以及怎么避开它们。第一个是厨房水槽绘画,从一个任务开始,中途又差了不相关的问题,再回来时 context 已经脏了,用 clear。 第二个是重复改正, cloud 做错了,你改它还是错再改。这时候 context 已经被失败的方法污染了两次,改正不行就 clear 重来。 第三个是 cloud mb 写太长,重要规则淹没在噪音里, cloud 直接忽略了一半,需要无情修剪。第四个是没有提供验证标准,实现看起来没问题, 但实际上不处理边界情况。记住那句话,你不能验证的东西就别发布。第五个是无限探索,让 cloud 调查什么东西,但不限定范围。结果他读了上百个文件, 用 safetent 或者严格限定范围。最后来总结一下,以上这些最佳实践不是一成不变的规则,而是经过验证的起点。 随着你使用 cloud code 越来越多,你会形成自己的直觉,知道什么时候该具体,什么时候该开放,什么时候该规划,什么时候该直接上。但作为起点,还需记住四个核心原则, 第一,管理好你的 context window clear 隔离任务, compact 压缩, btw 清量查询。第二,给 cloud 电政工作的方式,没有标准就没有质量。第三,先探索,再编码 plan mode, 让你的研究和实现分离。 第四,善用扩展能力,多绘画 auto mode, 让你的产出倍增。建议今天就开始运行 init, 创建你的第一个 cloud md 文件,然后给 cloud 一个可以自检的任务,感受一下差异。

上期视频我们分析了一个 how low 请求的全部细节,结果发现将近消耗了三万个 token。 很多朋友留言问,那如果连续聊十条,那是不是三十万 token 了? 不会的,所以这期我们就详细讲解一下 clock code 里面 prompt cash 提示词缓存是如何工作的。上期介绍的 clock trace 是 在代码里打补丁,有很多粉丝反馈了最新的二点一点一一九版本已经不能用了。确实是有这个问题的,因为我自己是用 n p m 安装的二点一点一一二版本, 现在官方已经不支持 npm 安装了。所以为了解决这个问题,我发现了一个新工具叫 cloud tab, 它的工作方式是在本地起一个代理服务器, 你启动它以后,它自动启动 call code 的 所有的 api 流量,经过代理转发退出后生成 html 文件,打开浏览器就能看,生成的 html 是 这样的,左边是导航栏,列出了每一次 api 的 请求,然后右边最底下就是原始的请求的 json 数据, 这个和之前的 cloud trace 生成的网页是一样的。但是 cloud tab 做得最好的地方就是把这个 tools, 然后 messages, system 这些重要的数据子段抽离出来,然后变成独立的模块显示在这里。比如这里对应的是工具, 然后系统提示词,然后还有消息你看,打开以后,他还做了每一块的分行的渲染,原始请求里面不是有很多一堆这个分行符对吧?看着都头疼,现在排的整整齐齐的,一眼就能读的懂。他还有一个杀手功能叫对比,上次 他可以把相邻两次请求放在一起对比新增的内容高亮,然后没有变的就灰色, 比如系统提示词,工具,这里都没变化,今天我们就用这个功能来看看请求是怎么变化的。 ok, 然后用法很简单,我们只要用 cloud tab, 然后杠杠 tab live, 收集所有请求,启动 cloud, 然后我们回去, 然后我们发三条消息, hello, 然后第二条 fine, 然后最后一条 thank you, 然后做完以后我们退出来,然后就能看到收集的提示词了,然后我们用这个来做分析。在看数据之前,我先讲一下 prompt cache 的 核心概念,它的正式名称叫前缀缓存 prefix caching, 什么意思呢?就是你每次发消息, cloud code 要把整个完整的请求都发给 api, 那 么请求里有什么呢?工具的定义,系统的提示词,还有用户输入的上下文,还有对话的历史, 服务器就按这个固定顺序排列它们,它们一起组成了缓存的查询键。那么前缀缓存的逻辑也很简单,两次请求,只要它们的前缀是一样的,那么第二次就不用重新推理了,就重新推理, 那么什么叫一样的呢?福气会对这个前缀做哈希,一个字母不差,就算命中了,差一个字母,那么哈希就变整个缓存就全部失效了。 打开抓取的 html, 结果里面第一个请求,我们按照前缀的顺序来看看里面有什么。最前面的是工具,里面有三十一个工具的定义, 然后中间的是工具的身份,然后他怎么做事,还有各种的行为准则, 然后最后的是消息,你的消息被包成了五个 block, 前四个是 cloud code 注入的后台配置, m c p 的 指南, skills 列表,还有比如说什么 cloud, md, 最后的最后才是你写的 hello, 这些上期都讲过,没记住的朋友记住,好好去复习一下上次的视频。今天你只要记住一件事,就是你的输入永远在最末尾,前面所有的内容,你的输入永远在最末尾,前面所有的结果了。 现在看重头戏。打开第一个请求的返回值,我们找到 usage, 一个字段,三个关键字, input tokens 等于六, cash creation input tokens 四万八, cash read input tokens 零,对不对?记住它们, 这里 input tokens 是 六,对应的是 hello 的 本身,然后 cash creation 是 四万八,将近五万个 token。 那 么前面所有的内容,工具的定义,系统提示词,用户输入上下文,全部首次写入缓存, 然后 cash read 是 零,那么第一条消息没有缓存可以读,这就是冷启动。我们继续看第二个请求,我们先用这个对比,看看请求变了什么。 你看消息从一条变成了三条,新增了 assistant 的 回复, hi, what would you like to work on, 然后还有 user 的 消息 fine, 然后系统提示词没有变,然后工具的定义也没有变,变得只有用户的消息。 然后我们再看 usage, 记住音符的 tokens 是 六, cash creation 二十四, cash read 四万八, 这里 cash 的 read 四万八是不是和上一轮 cash 的 creation 四万八完全一样,证明缓存完全命中了? 然后这里的 cash create 和二十四就对应了新增的 assistant 的 回复,还有用户的新的消息 fine, 所以 只有新增的两条消息需要加入缓存,我们继续看第三个请求,然后对比上次, 然后选对比最后一次,我们看到还是多了两条消息,对不对? assistant 回复 got it let me know, 然后用户回了一句 thank you, 其他的依然没有变,然后我们继续看 usage, 我 们只要记住这一个 cash read 是 四万八千六百七十八, 我们看看这个四万八千六百七十八哪来的呢?那就是上一次的开始 read 的 这个四万八千六百五十四,加上这个二十四,是不是就是四万六千 六百七十八了,对不对?所以也是上一次所有写入的缓存全部命中了, 然后这次写入的二十九个 token 也是新增的这个回复,对吧?然后再加上最后的 thank you, 把三轮数据放在一起看过滤就很清楚了,每一轮的 cash read 等于上一轮的 cash read, 加上上一轮的 cash creation, 所以 缓存就像滚雪球一样,越滚越大,但是每轮新增的只有几十个,总的上下文三轮了 只多了五十三个,然后信息从一涨到了五条,但是新增的计算量几乎可以忽略不计。 这些工具的定义,然后系统提示词,然后用户的注上下文,每次每轮都要带上,但是只有第一次才做了真正的推理,后面全部走了缓存,光看 token 数还不够直观,我们看一下比例关系, 缓存有三种计费方式,普通的输入就是正常价,然后 cash 的 写入比正常价贵一点点,五分钟缓存写入是一点二五倍,然后一小时缓存是两倍,但是缓存的读取只有正常价的十分之一, 所以第一轮冷启动将近五万个 token, 只能按照两倍的写入,看起来比较亏,对吧?但从第二轮开始,这五万个 token 几乎全部是走的 cash 读取,所以只有正常价的十分之一。第三轮、第十轮、第五十轮都是一样的, cash read 越来越大,但是每个 token 只花十分之一,所以对话越长,缓存的优势就越明显。 ok, 那 我们总结一下, prompt cash 就是 前缀的复用 工具的定义,然后系统提示词,对话的历史只有在第一轮,在计算后面的每轮新增的就只有几十个 token 了,对话越长, cash 省的越多。然后我觉得大家留言提的问题都非常好,给了我很多的启发,希望这期大家看完以后有什么问题可以多多提问,我每条都会看。

最后是 cloud code 里面的常用命令,这里我用一个例子把它们串起来。首先用 cloud code 打开一个新的目录,最新出式化命令, 它就会帮你在目录下创建一个 cloud md 文件。这个文件能干嘛呢?它是你这个项目下面最顶层的遮掩性文件,你可以把你的项目背景规则都写进去,比如我这是一个什么什么项目,我有很多规则,一,你不允许删除我的文件。二, 每次修改文件你要自动备份,把所有你认为重要的信息全部写进去,每次卡拉扣打开之后,都会自动去读取这个文件,这样你不需要每次重复的告诉你的卡拉扣的你的背景,你的规则。如果你的项目很复杂,那如何编辑这个 md 文件 也同样非常重要。有机会就可以单独开一期视频讲一下下一个杠 model 命令,你可以切换你的模型,因为我这里配置是 deepsea 模型,你可以在 pro 和 flash 模型之间进行切换。艾特命令, 我当前目录下有三个 t x d 文件,输入艾特符号,你就能看到这三个文件。比如我现在想对三这个 t x d 操作,帮我解锁国外 ai 大 模型方面的论文,写十篇进去, 所有的操作都会只针对于这个文件。下一个是 b b t w 命令,也就是 by the way, 因为现在他正在执行,我不想打断他,但我又想问他问题,那怎么办呢?我们用杠 b t w 命令,比如我现在问他一句,现在进度怎么样, 我们就能实现不打扰他主对话的情况下问问题。这里需要强调一下,你用这个命令来跟他对话,对话结束之后,他的记忆就被销毁了,所以他只适合问一些无关紧要的问题,不适合用来干活。然后你干着干着,发现 clock 的 理解出现了偏差, 他做出来的东西跟你的预期相差甚远。这时候你有两种选择,第一种,直接跟他对话,你做的东西有问题帮我改回去。 或者我们直接用 win 的 命令,你也可以连续按下两次 esc, 效果是一样的,你就能看到你所有的对话历史。比如我想回到这一步,点击回车,然后你能看到五个选项,你不需要知道每个的意思, 我们最长的是第一个 restart code and conversation, 它是什么意思?还原代码,还有对话意思是从这一步到最后,所有的文件改动都会被撤销,所有的对话记录都被清空,相当于时间回溯到这里,我们执行一下, 可以看到我们回到,回到了这一步,你就可以从这个时间节点重新开始聊。任务结束,你想关闭 cloud code 窗口,直接用 e x i d 命令就退出了我们的 cloud code 窗口。第二天你想接上昨天的对话接着聊。你可以用 cloud 杠 r, 就能看到你所有的历史对话记录。刚刚我们要用的是这个,我们就能继续接着聊,或者直接 cloud 进入之后,我们杠 resolve 命令, 效果也是一样的,选择一个历史对话接着聊。最后是 go 命令目标,他是最近更新的,需要你的版本大于 v 二点一点一三九。这个命令的作用。简单来说,你设定一个目标,他能帮你持续的干下去,直到完成你的目标。 你可以理解为不达目的不罢休,他需要你设定一个清晰的目标,你需要给他一个清晰的目标, 然后他朝着你的目标去执行,如果失败了,他会自己去验证,迭代,再次执行,循环往复,持续执行,直到目标完成,这是一个很强大的命令。学 coco 最快的方法就是你自己去操作一下,自己去玩一玩,其实都很简单。好,我们下期见。

今天我用 curl code 帮我做一个中等以上需求的一个需求说明书,考虑到 curl 的 像大模型都是一个注意力机制的这么一个大模型,那我可能我的第一步就是在 tst 里边先把整个需求的背景,包括需求的功能点,包括让它呃要设计的一个注意注意要点,然后包括我对这个需求的整体的一个理解,把它呃列举成一二三。然后我在 tst 文档里边 梳理一下整个需求,然后就让 clark called 帮我做做一个详细的设设计说明书,然后他做完做完出来之后,他给我设计的相关的表结构,然后接口说明文档,包括还有时序图,包括还有那个注意事项,甚至还有一些测试的案例。 那设计完了之后,我就会对整个文档做了一个呃快速的呃浏览之后发现它里边其实还有一些设计的点比比较粗,比如说有一些定时任务,它可能是就默认了就每五分钟执行一次,但是它和实际的那个 呃时间是有冲突的。比如说我定时计划是一个随机的九点十三分来执行一个任务,如果他每五分钟来执行一次的话,他在极端情况之下,他可能会在九点十七分才会执行到我九点十三分的一个任务,那在这种情况之下就会造成那个任务的延时, 所以我就让他,我说,我就让他呃做任务的一个前置,然后再呃单独再做一个派发的任务,那就显显著的降低了这个任务的 呃时效性。然后在关于这个 clock code 帮我设计的需求说明书,他也是不断地在从事啊,不断地在迭代,然后最终把这个设设计说明书呃给出出来 啊,最终呢,有一点就是因为它设计说说明书里边本来我已经配置了很多的呃本,本来我已经配置了基本的 clock code 点 m d, 包括 enigma 点 m d。 在 这个不断的对话的过程中,因为这个需求的文档在不断的迭代,也触发了它好几次的那个压缩机制。 所以我觉得就是有一个技巧,就是当你把那个设计说明书如果说多次绘画呃到一定程度的时候,可以执行一下杠 clear 来,嗯,把那个上下文给清空一下,然后再基于它现在生成的那个文档来继续来生对文档进行处理,这样可能 呃让这个自然理更聪明,不会让它产生幻觉。呃,我从这个计划说明书的这个实践过程中,我觉得 clockcode 呃做设计说明,然后再让 呃,比如说 ctrl 或者是去来编编辑代码会更加的呃快速和有效。你们觉得呢?欢迎评论留言。

大家好,欢迎来到今天的分享,今天我们要聊一个让可乐扣的从好用变成超好用的关键能力,并行绘画。大家有没有过这样的场景呢?就是一个终端在跑测试,你就只能干等着,或者是一个模块在重构,然后另一个模块的 bug 修复呢,只能排队。 如果这个时候你点头了呢?那证明今天的内容对你是有用的。我们这一期内容还是分为上下两期,然后我们今天主要聚焦最基础也是最常用的两层并行能力。然后下一期呢,我们会讲一个进阶的 agent teams, 还有 headless 的 一个非交互模式的一个并行的使用。 然后我们先看一下,当我们提到并行里的第一个反应是什么呢?是不是多开两个终端,然后多开两个 clout, 其实这个是没有错的,就是其实大多数包括百分之九十的人刚用的时候可能都是这样,但是这个可能不完全对,就是说,嗯,只是做到这种并行其实是完全不够的。 首先我们看一下可乐扣的四层并行的能力,像基础的呢,就是去开多个 clout, 那 是一个进程级的隔离。 那第二个呢,就是 agent 子代理的这样的一个形式,这个可以理解为一个县城级的隔离,那更高级别的做法呢,就是一个 agent teams 的 一个代理团队,这个就是绘画级的隔离。再往下呢就是 headless 这样一个非交互模式的啊,批量脚本级别的一个隔离。 那我们今天的上期呢,先讲 l 一 和 l 二,然后我们下一期来讲 l 三和 l 四的两层。那今天呢,我们讲一个核心的观点就是并行不是开多个窗口,而是工作流的重新设计。其实开多个窗口呢,只是最原始的并行,真正的效率来自选择正确的并行层级,然后并且正确的隔离。 那为什么并行这么重要呢?因为 cloud code 和传统的 id 最大区别就是它不是等你输入的工具,而是替你执行任务的代理。当你只有一个 cloud 的 绘画时,你的工作流就是这样的,给他一条指令,然后 cloud 去执行,然后你去等待它, 然后你去等待他的反馈,然后你再来去做下一条。所以说你的时间线是串行的,这样你就呃有些任务是不能并行处理的。那如果说并行的这个模式呢,就是你会可以有多个任务或者多条命令,然后让多个客户一起工作, 然后一起去并发的处理任务。那你这个时候就是一个并行的过程,所以你的等待时间呢,就是 n 乘以这个 time 变成你的一个 n 个任务的最大的 time。 ok, 在 我们实操之前呢,有一个非常关键的概念就是隔离, 这个概念我们需要理解就是绘画它最大并行,绘画最大的敌人不是速度,而是冲突,两个 collude 同时 get commit 的 话,就会互相的有冲突, 所以解决核心冲突的手段就是隔离。那我们怎么样去隔离呢?就是用 gitworktree 去隔离,让每个绘画有自己的工作目录和分支,然后文件层面呢就完全被隔离开了。 还有一种就是权限隔离,就是不同的绘画给不同的工具权限,这个呢也是一种方式。还有一种就是任务隔离,就是不同的绘画负责不同的文文件和模块, 就是模块级别的隔离,边界清晰。那这个呢,我们是要先记住的,就是你在做并行绘画之前,肯定是先要考虑你到底要使用哪种隔离手段,然后再去并行。 那我们常用的肯定就是 getworktree 这样的一个隔离方式。像任务隔离这种呢,可能就是你去让他做不同的任务,比如说一方面一个绘画在做测试,然后另一个画画在做啊,主线的一个叠带编编码,所以说这种就天然它是不会有冲突的, 但是你在呃这个时候使用的时候,是要注意自己的一个模块的边界隔离的,然后权限隔离呢?这个其实大多数就是工具级别的隔离。 ok, 接下来我们看一下最基础的一个 l e, 就是 我们开多个终端去并行去做处理任务。 但是我们这个时候会遇到一种问题,就是可能会有文件冲突,或者是造成 git 的 分支混乱。那我们这个时候刚刚也提到了我们的一个比较重要的手段,就是去做隔离,那我们的运行核心呢,就是用 worktree 去做这里面呢?这个 gitworktree 呢,就是可以用 clock 杠 w 这样的一个操作,就是后面的是一个分支的名, 那这样做有一个好处,就是它会自动调用 get 和 tree 去创建一个分支,然后每个 tree 呢,它都是独立的工作目录加上独立的分支,两个 code 可以 同时改同频文件,然后也互不影响。只是你在 get 末置合并分支的时候去解决一下有冲突的问题。 好,接下来我们演示一下。首先呢我们有这样的一个远程的一个分支,然后啊 master, 然后我们这个里面其实很简单,就是一个打印的一个代码,然后我们现在去给它创建 两两个并行的 root, 那 这个呢就是我们的一个分支名称,然后是我们基于哪个分支创建, 然后再创建一个 f 二。 好,然后我们现在让它做一个简单的打印。 ok, 我 们这样,嗯,有两两个任务,然后我们让它同时处理,然后如果说我们不去这样用 word tree 去进行处理的话,那它可能会发现发生一种状态,就是说它会覆盖,也就是说有可能只打印出一条 log, 所以 说我们用这种方式来看一下最终的一个并行的一个安全的一个效果。 ok, 看到这边它已经分别完成了它的任务,然后我们在这里看一下,它会生成两个 rocree 的 这样的一个分支,然后我们可以手动墨制一下,因为我这边是为了给大家演示的清楚一些,所以说我这边是手动给它墨制。 ok, 这个时候可能会有一点冲突,我们需要去解决一下。 好,我们选择接受组合,然后完成,这个时候可以看到我们两个任务都已经呃合入进来了, 那我们再看一下刚刚的这两个绘画,我们在退出的时候它会有两个选项,一个是保持这个 void 保留,还有一个就是删掉,那我们把 m 一 的 f 一 的删掉,然后在 f 二的时候保留它,这个时候我们再看一下, 那这个 workshop 还是存在的,所以说我们这个时候再去进入这个 workshop, 可以 看到我们还是会可以再一次进来的。 ok, 那 我们继续去讲下面的内容。 ok, 我 们下一个 i 级别的这个 b 型呢,就是一个 sub agent 的 这样的一个应用方式,这里面呢其实我们就会就不需要打开新的终端了,然后子弹里呢会在完成任务后主动回到主会话, 然后适配适合做一些小块而且专注的一个任务。我们这边可以看一下大概的一个对比,就是多终端就是多个窗口,但是 sub agent 呢,它是一个绘画窗口,然后我们在多终端平行的时候呢,是你的结果是需要自己去大概去参与处理的,但是但是 sub agent 这个是 不需要你去关注的,它会自动去汇总到你当前绘画,所以说第一个的成本是相对高一点,然后我们这种应该是几乎没有一个切换成本。 其实 code code 也自带了几个内置的字代理,像这个 explore 这种文件探索代码探索的,还有就是制定实施计划的 plan 模式,还有一个就是复杂多步骤任务的这个 general purpose 这样的一个模式, 然后 code code 会根据你的请求自动去选择这几种合适的字代理,然后你也可以显示的指定,比如说像用 explore 去搜索你项目中的 a p i 端点。 ok, 接下来我们看一下他的两种方式,一种是前台运行,然后一种是后台运行,那前台运行一般是默认的,就是他会阻滞你的主绘画,然后权限都是呃要通过你来同意的。还有一种就是后台的一种并行运行的方式,他运行完了会通知你结果, 那这个后台权限呢,他是在启动的时候会做一些啊预审批,然后之后就是自动拒绝的,所以一般后台任务都只给只读权限是比较安全的。这里呢就是一个禁用后台运行的一个配置 啊。接下来呢是讲一下,大概是去创建一个自定义的一个代理文件。那创建方式呢?很简单,就是一个 markdown 的 文件,然后存到这个 加目录的 dr cloud agents 下面,或者是 dr cloud agents 这两个目录下面都可以。然后这里面呢大概有几个常用的字段 啊?首先这个内幕呢,就是说你这个 sub agent 的 一个名字,然后 description 呢,就是你的这个 sub agent 它描述的一个职责和专场,就是它用来是干啥的。然后 tos 呢,就是它这个能调一度的一些工具列表,然后 model 呢,可能就是你会使用哪种类型的模型去做 这个呢?接下来呢这个是隔离策略与工作范围啊, background 呢,就是附加背景说明和指定。 ok, 我 们有几种调用的方式,首先呢就是说你在绘画里面直接给他讲说调用子弹里去来完成任务,或者是直接去艾特他的名字,就是我们刚刚内幕上面配置的名字,然后或者呢是直接是 gloud 加刚刚 agent, 然后再加上他的名字去启动。 还有一种方式就是我们可以在啊绘画里面快速去定义一个 sub agent, 就是 不需要我们刚才说的那个文件那样去定义。 ok, 我 们继续看一下这个 sub agent 的 一个创建,然后我们是在这个选择这种方式就是在加目录下面的 agent 目录下面 去编辑一个 code reviewer 这样的一个 md markdown 的 文件,然后呢里面就是去写一个代码审查的一个 sub agent, 然后这里呢我们让他去审查一下我们当前那个代码, 那我们选用这种艾特的名字的方式去调用它,然后看这个时候它是在前台运行的一个模式,这也是它默认的一个模式 啊,它这边是生成了一个审查的一个报告,那我们再去让它用中文生成一遍,那我们接下来让它在后台运行 看,这个时候我们是跟刚才不一样的,我们是可以继续来跟他对话的,然后他在后台做一些运行,然后这也才提醒你看,这是他说你可以继续做其他事情,然后无需等待 啊,这个时候他就已经完成了。 ok, 我 们看一下,我们刚刚问了他一下,在他处理的过程中,我们问了一下进展,然后他跟我们说他还在处理,然后处理完了之后,他就会把这个结果发给我, 这他就是一个并行的一个操作。这里面可以看一下我们这个 subagent 它常见的三种并行方式吧,一种呢就是去并行的一些探究,然后让一些呃把探究结果进行一个汇总。 还有一种就是劣势的,这样的三维形的,就是反复的去找问题,然后修复,然后自动闭环。然后还有一种呢就是让子弹里去跑一些刺套件,然后隔离高输出量,然后只报失败和结果,然后不过度占用上下文的对话。 ok, 这一期我们总结一下,大概呢就是我们首先有一个认知,就是啊 cloud code 的 运行并不是开多个终端,其实我们是需要去 啊重新对我们的工作流做一个设计的。第二个呢就是我们要先做好隔离再去并行,不然的话你可能会有一些呃覆盖啊,或者是引入一些新的问题,这个就比串行还还比较还难了。然后还有一种就是呃升级一点的这个 servicent, 这个还是会有更好的一个用法,也值得我们更多的去探求。 那我们下一期呢就是讲一下 agent 的 team 和团队的代理,还有一个 f 四的 headless 的 一个啊非交互的模式,然后是用脚本大量批量去做一些事情, 还有一些我们会做的一些遇到的一些坑啊,还有一些比如说大概的什么时候,我们用哪些啊?兵行手段啊?我们下期见。

大家好,不知道你是使用什么工具来启动 clock code 进行编程的,那最近呢,我试用了好几款这种 clock code 的 编程工具啊,每一款工具在使用的体验上都差距特别大,那本期视频就给大家介绍一下我使用的这几款 clock code 编程工具,看一下哪一款更适合你。首先呢,我对 clock code 的 这些编程工具 有以下诉求,第一个呢,就是一定要使用这种终端命令行去开启 curl code, 这样不使用 a c p 的 方式,终端是一等公民最好。那这句话什么意思呢?比如说我们在这里打开终端,然后 我们去启动的时候,那在终端里面我们是可以使用 coco 的 所有的命令的,但是如果你使用 a c p 的 方式,那所谓的 a c p, 就 比如说这个,那么是它自己做的这种输入框啊,去跟 coco 进行通信,那么有些命令它就用不了。比如说我们要想用 查看插件这个命令,他就会提醒我们要使用这个终端命令行打开这个命令,所以他不是所有的命令都支持的。第二个要求就是一个界面啊,可以开启多个终端,多个项目, 因为我们在开发过程中啊,经常要开启克拉扣的,还要开启我们的,比如说 npm 去启动前端项目,有可能像我们还要开启这种 kimi 其他的编程工具,比如说 open code, 那 我们可以在一个界面里面去开启多个这样的指令,或者说多个项目的话是非常方便的,省得我们切来切去。 所以第二个是非常必要的一个条件啊,第三个条件就是可以在工具里面查看 markdown 文档,如果有预览模式最好,那这局为什么也是非常必要的?因为我们在使用工作流的时候啊,经常会产生一些啊文档,比如说 stack 文档 啊,计划文档,任务文档,那这些文档我们是自己要去省略的,那如果说这个编程工具都不支持省略文档,那么你要用通过其他的工具去打开,这样就很繁琐了。那比如说在这款工具里面,我们可以打开一个这样的文档,那么这个就是一个啊接口文档,那么我们可以去看他的内容, 他也可以去预览一些复杂的一些流程图啊,比如说这种复杂流程图,那么你也可以去审阅他这种,比如说规格文档生成的这种规格文档,那么你也可以去看, 所以这是最基本的需要,因为我们需要去审阅这个文档有没有问题,所以这个是一定要有的, 那么你也可以是用原始的模式,那么就是我们 markdown 的 语法。这种最后一个呢,就是有方便的地的管理流程啊,比如说可以去查看地府啊,去创建分支啊,去进行可密的,或者创建用 pr 操作,能够点击按钮的方式,这操作最简单了,就不用自己再去手敲命令。 那这四个点里面,中间两个点是必须要有的啊,不能缺,缺的话就不在我这个筛选范围之内,那另外两个呢?可以稍微降低要求。 那么基于以上四个这个诉求啊,那就已经排除了一些啊,我经常用的,以前经常用的一些工具啊,比如像 vs code, 或者说电脑自带终端啊,或者说这个 item, 或者说其他的,比如像这个 ghosty 啊,或者说 smokes 啊,那么这些 都是纯终端的,那么也是排出在外面的。那么以下的这五个就是我最近一直在使用的,然后我对每每一个这样有有这样四个维度来对比一下,然后来给大家讲解一下每一款这些工具是怎么个体现的,然后屏蔽的结果是什么样子的。 第一个是 z 的, 那在我的视频里面经常用这块工具来给大家展示这样个项目开发过程,那么它是支持全部端的都可以下载来使用,那这个就是 z 的, 那么它跟 vs code 是 非常像的,但是它的启动速度比 vs code 快 非常多。那 z 的是怎么来启动 color code 的 呢? 那么它有两种方式,一种是它官方出的这个 a c p, 然后我们可以在这边开启,然后的话你可以在这边去安装它,这边不仅也支持这个 cloud code, 也支持像 open code 的, 或者说像这个 kimi 啊, coser 都支持这种终端模式,那么你可以直接在这边去对话,但是呢就像刚刚我讲,他使用的是这个 a c p 的 模式,所以说有些命令是不支持的,那么除了这种方式启动的话,你也可以使用终端的方式启动, 那启动完之后,那么你就可以这边去使用了,那在这里的话,你可以去创建多个项目啊,这边也是可以去创建多个项目,那么你就可以在一个界面去管理不同的目录啊, 然后除了这个之外,那么你在这边是可以去看到我们的这个项目的这个文件啊,这边是它的文件目录,那么你也可以在这边查看 markdown 的 这个详细内容啊,然后去进行审阅。但是呢,在 z 的 里面, 终端并不是一等公民啊,他自己推出了这个 agent, 或者说他自己自带的 ai 工具,是一等公民。所以说你这个终端的位置调整就很麻烦,比如说我,我这边要开启多个的话,只能这样并排着,没办法像这样竖的, 这样的话,我就操作起来就要去切换这个窗口啊,比较麻烦,而且它这个位置调整也是比较费劲的,那么在 get 里面也能很方便去管理我们的 get 的 操作啊,比如说这个全选,那这边的话是可以 kimi kimi 的, 然后也可以去提交 pr 请求,非常的简单方便啊。 第二款就要介绍最近开源的这个 wap 这个工具啊,那这个工具是非常有意思的,那么它是通过终端的方式,你可以开启这个 agent 和 tiffany 的 终端,然后去开启我们的这个 cloud code, 然后它这边对所有的这个终端命令都有种快捷方式,你看比如说 cloud, 它这边就会有一个这样的快捷方式,按下 table, 它就帮你输一输好了,有很多这种提示啊,就任何的命令它都会有提示,非常方便,非常好。 microsoft 文件预览的话,它这边也是做的非常不错的,比如说我们可以看一个啊,这样的一个文件,那么它支持这种啊,预览格式也支持这种原文格式,那么你可以看到所有的这个内容,也可以看到这样 核心的这个流程啊,也是非常不错。但是呢,它对于 get 的 这个啊管理的话,目前只能看到就是啊所有的变更 啊,并不能说去操作 command 或者说去提交。第三个呢,就是 wave 这款工具,启动 color code 的 话也是用纯终端的方式,它这边可以开启很多终端,比如说开这样三四个终端,然后你打开之后呢,你可以把这个终端可以放大啊,比如说你可以在这里操作, 然后的话你也可以去查看,就是我们具体的一个文件啊,但是他这个打开的话是默认是在个目录里面,你需要自己去找到你的这个所在的目录看一下, 然后的话你可以是放大,然后的话可以使用 pro v 模式,这样的话就能看比较清晰了,能看到他的所有信息,还有这样的流程图,非常方便。但是呢, vivo 这款工具现在没有 get 管理啊,所以就少了一个很重要的功能, 那 vivo 呢,也是可以开启多个项目的,比如说你可以在这边去新增多个 table, 那 每个 table 你 可以去进入不同的目录, 那就代表了就是不同的项目。那接下来就是这款 conduct 了,目前只支持 mac 版的这个系统下载啊,这款工具呢是跟 get 结合的比较紧密的,所以呢,你在用这个工具之前,一定要把这个项目 get 输出化一下, 然后你可以看到在这边会有两个项目,那么你这边也可以创建不同的 workspace, 大家点击创建之后,它就会创建不同的分支 啊,然后开发完之后,它就会通过分支合并到主分支的方式,那这样的话可以很方便的去进行管理啊,然后这边也是可以添加不同的项目,那你在这边是能看到不同的项目来同时协助了,那么它的 cloud 的 使用方式就通过 a c p 的 方式, 那么在这里面你是不用去启动啊终端的,那么你直接可以在这边操作,你也可以使用里面的命令,但是有一些命令你是用不了的, 那比如说我们去查看插件呀,这种安装插件呀,都需都需要单独打开终端才可以,那么它也是调用你本机装的这 clock clock 的 实力啊,所以说这个模型就跟你自己本地配的是一样的。 那么再看一下 conductor 的 key 的 操作,如果你有任何的变更,你在这边可以看到变更的详细的情况,你也可以通过这个按钮 review, 然后发送一条这样的对这个 review 进行一个你的这个代理的一个审查啊,就看一下这个 review 的 有没有什么问题, 如果没有什么问题之后呢,你可以点开这个 checks, 那 么你是可以进行 kimi 的 和这个 push 的, 然后它也是通过这种代理去直接去操作, 所以是非常方便。就如果你的项目跟 github 是 紧密关联的,那么你可以使用这款工具啊,它跟 github 的 工作流结合的是非常好,非常方便的。那这一款就这个 super side 这款工具的话,也是非常有意思的。那首先我们来看一下它启动 color code 的 方式啊,它它自己内置了很多这样的命令,比如说我们点一下它就启动一个这样的 color code 的 实力,那我们点个 code x, 它就启动 code x, 非常方便,而且它这边的话也是支持可以去开启多个这样的项目啊或者终端啊,在这边可以去开启多个这样的项目同时去运行啊,你也可以看到所有的文件,比如说你可以看 markdown 的 这个详细的内容 啊,也支持用这种原始的方式和预览的方式。那么如果有变更的话,你也可以去这边查看它的这个 changes, 那 么也可以去很方便进行 cmd 操作。 这款工具非常好用啊,但是呢,它有个问题,就在你长时间运行这个 curl code 这个编程之后啊, 他有些中文会变成绕吗?这个非常奇怪。那以上就是我对这五款工具的一个介绍啊,那最后我来对这五款工具进行评比啊,只是基于我自己的使用经验,那别说自己的我会给他三颗星,那么他是基本上符合了我的诉求啊,虽然说他的终端面料好啊,不是一等公明,但是也算是还还挺好用, 然后 rap 的 话也是非常不错的。然后最近我是在使用它,因为它这个快捷方式啊,它这个字典呢,觉得看着非常舒服,虽然说它不能进行 get 管理,但是应该是可以用其他的方式来实现的, 所以我也给了三颗星。那 vivo 的 话,因为它缺少这个 get 的 管理啊,所以我只能给他两颗星,那可能也是非常不错啊,最近也拿到了融资,说明它在市场上是有一定的产品力的。 那 success 的 话,因为中文乱码的问题,我只给他两颗心。如果说他解决了这个中文乱码的问题啊,我觉得可以给他三颗心,也是非常不错的。那么以上就是我对这些工具的一个介绍和评比了,也不知道你使用的是什么工具,然后这些工具哪一款会比较适合你的口味呢?

我用 cloud code 做了一个发票自动下载的小工具,现在在桌面上有个图标,它叫 发票自动处理,双击运行,它就会自动读取上一次处理到哪一天,那从那一天开始的第二天,扫描所有的发票邮件。其实不一定说非得用 cloud code 来做,只是说在这个过程当中,我学到比较多的是怎么样跟 ai 说话,它才能听得懂。 第一,我们要跟他说目的,不说方法,不要说去某一个数据库去连接,然后读取你要什么东西,不需要说这些,你只要跟他说,帮我从 qq 邮箱自动下载发票, 剩下的要怎么做,让他去决定怎么做。那第二步呢?报错就粘贴完整的出错信息,把红色的报错的信息整段复制给他,不要自己去翻译或者总结那一串英文,对于他来说,其实信息量很大,你翻译一遍反而丢失了很多细节。 第三呢,就是截图比描述更强,有些问题用文字很难描述清楚,比如下载的时候,他弹出一个框,上面写了什么,直接截图扔给他,效率会翻倍。第四,反馈要具体,没用, 不对,这种反馈是帮不上忙的,那程序跑完了,没有报错,但发票文件夹还是空的,这才是有效的反馈,说清楚发生了什么,没有发生什么。第五,迭代是正常的,不是失败。 这一次的尝试呢,其实我来回调整了好几次,不是 ai 不 行,是这种自动化本来就有很多边界的情况,要一个一个处理,每次出问题也是把程序变得更健壮的机会。自动化不是一步到位,是一点一点调试出来的, 但调试完了之后它就是你的了,就是一个真正属于你的工作的工具。如果你也有类似的重复性的工作整理文件呐,下载呀,还有发邮件, 可以试着跟 cloud code 描述你下一个需求,说不定比你想象中的要简单很多。

之前我吐槽 coldcode 跑长任务不靠谱,没想到 entravagic 直接出手了。新版内置了 go 命令,官方自己说这就是我们抄的 ralphloop。 今天带你看看官方下场到底行不行, 呵呵呵。用法,升级到最新版,输入 go, 加一个完成条件,比如 go 所有 test 下的测试通过, lint 无报错。跟普通对话最大的区别,每轮结束不等你自动开始下一轮。 屏幕上有实时状态条,三个命令记住就够,够条件开始够查状态够 clear 取消最重要的坑条件。写模糊模型会糊弄你, 写写完整的测试,它能给你造几十个空格。测试全通过,然后宣布完成正确姿势要写具体 npm test 退出码为零,不允许修改原码。二十轮没完成自动停止。 最后这条最关键,没有轮次上线 token 账单汇报原理本质是一个独立的评估循环,主模型干活儿干完之后把对话记录扔给一个独立的小模型来判断目标有没有完成。关键设计找不到明确证据,默认视为失败。 默认立场是怀疑,不是信任。横向对比, be raft loop, raft loop 是 模型自己判,自己输出个标记就算完成。没有独立验证, go 至少多了一层外部裁判。 be codex go codex 的 评估模型可以真实跑测试 grab 代码来验证,造假成本高。 cloud code 目前只能看对话文字,差距明显。 总结一句话,不管是评估循环还是权限控制,真正有效的约束都写在代码里,不在提示词里。提示词的规则模型可以绕代码的边界,绕不了。这就是为什么 agent harness 是 必要的, 够对于条件清晰的任务是目前最省心的方案。但记住,十几轮跑下来,主模型 token 消耗轻松翻倍,设好轮次上线保护你的账单。

曾经我对 cloud code 的 终端爱不释手,但现在我只能说一句, codex 真香啊,真香! 大家好,我是布鲁。随着 codex 近期频繁的更新,我自己的工作站也已经全面的切换过来了。今天就来分享一下我自己的完整使用经验,怎么用 codex 打造一套不打断心流的生产力闭环。 本期视频我把它分成了七个章节,每一张都是我自己实际在用的技巧,希望能对你有所帮助。那我们话不多说,直接开始 第一张,先来介绍一下我的工作站是怎么布局的。左上方是 codex 的 对话框,下方是 terminal 终端。 你可能会问,已经有 codex 的, 为什么还要开一个 terminal 跑 c c? 因为我发现对于一些需要探索、需要设计的任务, c c 的 表现要更出色一些。所以我的习惯是用 c c 来做方案设计,配合 planning with files 这个 skill, 把设计思路直接落成文件, 然后再让 codex 读这份计划,接手后续的具体实施。这样一来, cloud code 负责想, codex 负责做,两者可以各司其职。 右上方这个区域我用来做任务完成后的查看和审阅,比如代码的 review, 文件的浏览,还有浏览器都在这里。虽然现在浏览器还不支持多标签页,但对于日常的任务来说完全够用。这边我就分享一个实际的案例, 我让 c c 参考了最近很火的这篇卡巴西提出的知识库的文章,让他借鉴里面的思路,出一份设计稿和完整的实施计划。目的呢是做一套前端的页面,方便我日常的维护文档使用。 接着 c c 就 会调用 planning with file 这个技能啊,将所有的计划落成文档,然后我就会回到 colex 这边,让 colex 去阅读当前项目内的这份计划文件,然后基于这份计划文件让他进行开发。开发完结果之后,我会在这边 内置的浏览器里面去进行结果的 review, 包括代码的一个审查,整个过程从设计到开发再到 review, 全都在这一个工作站里面完成,不需要切换任何的窗口,这就是我前面所说的,心流不会被打破。 第二章,批注功能。这个功能是我觉得 codex 真正强大的原因之一,也是最能体现沉浸式开发的地方。 以前我们改代码的方式是找到文件定位到哪一行,描述问题,让 ai 修改,整个过程中你的注意力是在代码上的,但现在 codex 的 批注功能让这件事情变了,你可以直接在文件上进行批注,告诉他哪里怎么改,需要怎么改。 更厉害的是,现在这个批注功能不止限于代码文件,你可以直接在前端页面上进行批注,看到哪个按钮位置不对,哪块布局不满意,直接在页面上标出来, codex 就 能理解你的意图,并帮你进行调整。这件事的意义在于,正好对应了 webcodd 的 核心理念, 开发者的重心不在于怎么写,而在于写出来的东西对不对。批注功能把这个理念落地了。 第三章,上下文管理 codex 项目里可以同时开多个县城,每个县城对应一个任务,互相独立,不干扰。对比 cloud code 需要开多个对话窗口, codex 把所有县城都收在了一个项目下,管理起来会清晰很多, 然后是项目的记忆核心就是 a 键的点 md, 这个文件你可以类比为 cloud md, 把项目的背景、开发规范都写进去, ai 每次进来都会读取,不用反复的交代。 还有一点, codex 的 上下文管理非常省心,它会自动帮你压缩上下文,它也没有提供像 cloud code 中 compact 的 那样的命令,这种事情让 ai 自己处理就好了,你专注于任务本身就行。 第四张,自动化这块是我觉得 codex 比其他 agent 做得更好的地方,几个原因,第一,用起来非常的方便,直接在 gui 里面新建自动化任务,还内置了很多模板可以选择, 大到项目管理技术、眼镜,小到个人的生活习惯,都可以交给它来定期的处理。第二,自动化可以调用 codex 自身的能力,比如插件、 skill、 mcp、 浏览器操作、电脑操作等全都能用进来,这就是为什么我说 codex 在 逐步形成自己的生态。 第三,我们可以根据不同的场景来灵活的选择模型和推理强度,简单的任务用轻量模型,复杂的任务上强推理,这样的话头肯可以用的更加的合理。第四,稳定性,我实测下来, codex 相较于其他的 agent, 定时任务的准确性已经能达到生产级别,相当的靠谱。 第五张插件和技能, codex 有 相当丰富的官方插件和 skill 生态。先说说两者的区别, skill 就是 纯文档,本质是给一份 ai 的 说明书,告诉他在特定场景下应该怎么做事。比如说我前面提到的 planning with files, 就是 一个 skill 插件的概念会更大一些,你可以把它理解为 codex 打补丁,里面可以包含 skill, 也可以带上 mcp 配置,甚至集成其他的 app。 一个插件装下去, codex 就 多一套能力。 另外, codex 在 插件和 skill 的 管理体验上面要比 cloud code 的 友好太多了。 cloud codex 需要改配置文件,而在 codex 里直接在界面上点击安装,或者自己创建,整个过程非常的直观。 第六章浏览器和电脑操作 codex 可以 直接操控浏览器,你可以让它自动填表,抓取数据,验证 ui 效果。 比如我需要批量收集一些网页上的信息,直接告诉 codex 去哪个页面拿什么数据,它就能自己打开浏览器去完成操作,整个过程中都不需要你的介入。除了浏览器, codex 还能直接操作你的电脑文件的整理,应用的打开都可以交给它来处理,相当于有一个助手在帮你操作桌面。 不过这里要说明一点,随着 ai 自动化越来越普及,现在已经有不少软件开始加强安全控制,对自动化操作做了限制,所以实际能操作的范围会因软件而异,遇到限制情况也很正常,大家用的时候留意一下。 第七章通用功能这些功能不是 codex 独有的,很多 agent 都支持,但作为一个完整的工作站,这些基础能力 codex 当然也不会缺少。先说 play mode, 在 执行一个比较复杂的任务之前,先让 codex 把完整的计划列出来,你过一遍觉得方向对了再让他动手, 这个习惯能帮你省掉很多返工的时间,大任务尤其推荐开 play mode。 再说 m c p, 也就是模型上下文协议,通过 m c p 可以 把各种外部的工具和服务接进来,让 q d x 能力边界大幅扩展,无论是连接数据库,调用第三方的 api, 还是接入自己家的服务,配置好之后, q d x 就 能可以直接调用。 另外还有一点, q d x 相较于 logot code 的, 有一个非常关键但很容易被忽视的小功能,语音识别。目前我的任务几乎都是语音发起的,连打字都很少了。 ok 以上就是我在使用扣袋子过程中总结的一些技巧,如果对你有帮助的话,希望能得到你的点赞和关注。 最后我想说一句, ai 发展太快了,各家 a 键的功能越来越趋同,但工具再多,适合自己的才是最好的。有时候做做加法,找到真正需要的,做做减法,去掉用不上的,慢慢摸索出一套自己的工作范式才是最重要的。我是布鲁,我们就下一期再见。

哈喽,之前都在讲 clock 有 多好用,今天来讲一个返利,就是我一直有讲说不要把,不要觉得这个 ai 很 万能,也不要把它神话,不要觉得有了 ai 一 切都能做到,嗯, 当然他就会继续的做的更好,但目前还是蛮多不足的,比如说前几天,呃,我想让他把在我所有的相册,呃,在我的视频里 按人脸去搜索,就是我跟他说你帮我识别出来这个人,只要涉及到这个人,单独给我放在文件夹里,结果他一顿操作猛如虎,一看战绩零杠五,呃,就是下载了很多什么插件啊,什么他自己下载,然后最终识别率特别的低。 呃,还有一个返利,就是我之前说我要用微信来控制我的 cloud, 好像有个叫 ccconnect, 这个是更好的,结果他,他没有用这个 plug in, 他 自己掉了一个叫做什么 wechat channel 的 这个 plug in 实际上已经很久没有人更新,但它没有识别出来,结果特别拉垮,一下就掉线,一下掉线,嗯。

本期视频只讲一件事,新手如何快速上锁 cloud code, 让他帮你干活提效开始。首先, cloud code 中有三种常用的工作模式,默认模式、自动模式和计划模式。默认模式每一步都需要你确认, 写文件、执行命令都需要你手动同意,步步确认,它是最安全的,但也是最慢的模式。自动模式,文件操作会自动执行,但涉及到有风险的命令,比如网络请求、 m c p 工具的调用,他仍然会停下来问你,向你申请权限。计划模式,这个模式上来不会先帮你干活, 他会先跟你讨论需求,帮你制定出一个完整的可信性计划,你确定计划没问题之后,他才会动手。我们打开我们的 cloud code 界面, 在左下角就能看到我们当前的模式,按住 shift 加 tab 进行模式切换,空白就是默认模式,紫色的就是自动模式,然后绿色的 plan 就是 计划模式。在项目的开始阶段或者涉及到复杂的需求, 我都建议开启 plan 模式,跟卡扣讨论出一个完整的计划,剩余的执行阶段你都可以保持自动模式。接下来是几个卡扣中比较重要的知识点。第一个 skill 技能,他是给 color code 的 标准操作手册,没有 skill, color code 每次都在极尽发挥同一件事情,他今天可能这样做,明天那样做,结果是不稳定的。就像你给厨师一本固定的菜谱,这样他做出来的菜菜的味道都是固定的,不会给你乱发挥。 color code 中我们输入斜杠, 会列出所有你已经安装过的技能,按 tab 键可以选中这个技能。比如帮我创建一个 word 文档,这样它就能调用这个技能。或者你也可以这样做,帮我创建一个 word 文档, 点击回车,然后大模型会自动识别到你这个需求,可以用到刚刚的 d o c s 这个技能,它就会自动帮你调用这个技能。 m c p 卡拉扣的他的内置能力,他是有边界的,他做不到。帮你控制浏览器,帮你收发邮件。 mcp 就是 让卡拉扣的与其他软件互联互通。 比如你装上浏览器的 mcp, 他 就能帮你控制浏览器。装上数据库的 mcp, 他 就能帮你控制数据库。装上搜资料的 mcp, 他 就能帮你自动搜索资料。就像你给厨师配了一部专线电话,直通时代商外卖平台助理,他不用出厨房,他就能调用外部所有的资源。我们在卡拉扣中输入斜杠, mcp 就能查看我们安装的所有 m c p 工具。 pux 钩子有些动作你希望可拉扣子每次都自动执行,不想每次提醒它。 pux 就是 在特定的节点自动触发的预设规则。比如你配置一个文件,改完就自动备份的钩子, 这样以后每次文件改完,他就会自动帮你备份。就像厨房里的铁绿,每次上菜前都自动撒一把葱花。这个钩子功能对我们有什么用呢?我举个简单的例子,卡奥克德会频繁向我们申请权限,有时候我没有看到,他就会一直在那边等着我们, 不往下执行就会浪费很多时间。然后你就可以对你的 code code 说,帮我配置一个 hux 钩子,作用是每次 code code 向我申请权限时都播放一个音乐,然后你的 code code 就 会把你移步配置,我这里已经配置完了,我直接演示一下,我让它读取一个其他路径的图片,它就会向我申请权限。 它会播放一个超级玛丽的声音,这是我自己配置的,你们也可以选择自己喜欢的音乐作为提示音。 sub agents 自带礼 如果有一个任务很复杂,那么一个 clock 的 创建处理就很慢,这个时候就可以用到三倍镜子弹里。它的作用就是把一个复杂的任务拆成一个小的任务,让这些任务同时去执行,就像主厨同时指挥,几个副厨同时开工。那我们具体怎么用呢?其实也非常简单,直接跟我们 clock 对 话。 我现在有个很复杂的任务,请你帮我用 sub agents 代理执行。这里我只是举个例子,因为实际中你的任务可能很复杂。题是和很多 plug 插件 skill m c p hooks 要一个配置很繁琐,插件就是打包好的解决方案, 你只需要一键安装就能拥有整套能力。包克隆书,斜杠, plug 就能打开插件管理页面,在线安装管理我们的插件上下文窗口。 cloud code, 每次对话他能记住的信息他是有上限的, 你的对话文件执行过的内容全部都在占用这个空间,如果占用过高,就会出现大模型反应变慢了,他的回答质量下降了,就是我们俗称的大模型变笨了。再一个, 占用过高,大模型可能就会忘记你开头说的东西,就像人的短期记忆,同时记忆太多就开始混乱。那我们该怎么处理呢?首先我们用 context 命令, context 命令可以看到当前的占用情况现在是百分之三,当占用超过百分之五十的时候,我们就需要注意及时的使用杠 compact 命令 去压缩我们的对话。这个命令的作用是把之前所有的对话做一个摘要总结,存到记忆里面去,释放大量的上下文空间。还有一个命令杠克拉命令, 这个命令的作用是清空当前的上下文空间。如果你当下的任务已经完成了,克拉口的当下的记忆上下文对你来说已经没有用了,你就可以用这个命令来清空整个上下文,准备做下一阶段的任务,相当于清空大脑。