ClaudeCode项目手册写法

cloud code 必看开源项目啊！今天要分享的是 cloud code 的 best practice， 这个项目目前已经收获接近四十 k s 的， 堪称 cloud code 生态里的实战教科书啊！它是一套完整可直接套用的 cloud code 开发规范与提示式体系啊。用了它，你不用自己反复摸索指令结构，不用纠结怎么描述需求才精准。 作者把多年实战总结的最佳提示时，项目开发流程调试话术全部整理好，直接复制就能用啊。不管你是写接口大项目改 bug， 还是做架构设计啊，都能让可拉扣的理解更准，输出更稳，代码质量直接上一个档次啊。

这是一款零基础，小白也能从零到一手写 cloud code agent 的 教学仓库。记住这个开源项目，他在 github 已经拿下四十六 k 的 star。 他 把 cloud code agent 的 学习拆解成十二个渐渐式三神， 手把手带你从零搭建完整的智能体能力。最良心的是，它根本不是干巴巴的文字教程， agent 的 每一步执行流程都给你做成了直观的动画演示，不用再对着绘色原码死磕逻辑，看动画就能秒懂原理。同时还搭配了完整的文字讲解、 流程拆解和工作原理解析，层层递进，讲得明明白白。哪怕是零基础，小白也能轻松吃透 ai agent 的 核心逻辑。

cloud code 安装好了不会用或者不熟悉怎么办？这是一个已经有八万开发者关注的开源项目。 cloud code 学习指南 cloud hello 二 专门解决官方文档太基础，没有明确的学习路径。 cloud hello 二这个项目就在这两三天的时间， github 上的实答数从一千五冲到了八千三。他给出了明确的学习路径，征集路径，中级路径、高级路径， 选择适合自己的学习路线，也可以根据完整的路线图表按顺序学习。初学者路线主要是基础概念、常用命令。 中级路线主要讲述技能、 webhook、 mcp 代理等。高级学习路线主要针对高级用户与团队负责人，包括复杂规划模式、权限控制、扩展思考、后台任务等。该项目还针对你的学习时间做出合理的学习计划。十五分钟学习方法，一小时学习方法，还有一个周末的学习方法。 文档中包含命令说明、流程图、操作截图及实际事例内容图文并茂，清晰直观，贴心的给出了学习技巧、不同风格的学习方法 以及学习进展的自我验证。最后，这个项目声明会永久免费，并与每个可乐扣的版本同步。可乐扣的每个版本的新功能都会有介绍，大家可以放心使用。 好了，本期视频就到这，喜欢的朋友可以点个赞、关个注，评个论，我们下期见。

自己做个 skill 啊，其实只要五分钟，你不需要懂代码，你也不需要去翻说明书。今天我们就手把手教你做出属于你的第一个 skill。 首先啊，我们需要用到 skill creator 这个 skill 来帮助我们创建 skill。 那 它被称作是语言 skill， 即帮助你写 skill 的 skill， 就是说你不需要去背官方的标准和规范，他已经把这些信息全部都内置了，你直接让他去帮你实现需求即可。那主流的 ai agent 基本上都内置了这个 skill， 你 可以直接使用。我们以 ai 写稿这个场景为例啊，来演示如何制作你的第一个 skill。 那 ai 写稿通常会有这三个步骤，第一个是联网获取最新的信息，第二个是呢，根据获取信息去写稿件。那最后一个步骤呢，就是把 ai 稿件去 ai word。 我 在这已经准备好了一个提示词，那你的提示词里面只需要告诉你想要干什么，然后把步骤或规则告诉 ai 即可。 那在 color code 里面，我们先来调出 scale creator 这个命令，然后把题旨词粘贴进去，然后点击回车，那这个时候 scale creator 就 会帮助我们来创建这个 skill。 那 注意啊，我们在题旨词中用到了 parameter 这个 skill， 它是专门用来去 airword。 那 也就是说你可以在做 skill 的 过程中去引用其他的 skill 来帮助你完成当前的这个 skill。 那现在我们的 skill 已经创建好了，那我们来验证一下它是否能够正常工作，那我们还依然通过斜杠命令来引用这个 skill。 那 我直接用这里的主题帮我写一篇关于二零二六年 ai agent 趋势的稿件， 看它现在已经触发了联网搜索啊。好了，现在我们的稿子已经写出来了，它已经调用了回文 maker 这个 skill 来处理这篇稿件，然后去除 ai 的 痕迹。 那下面就是去 i o r 之后的最终稿件，它这里包含了来源的参考，以及主要修改了哪些地方。 那如果你想要修改这个 skill 怎么办呢？那我们一般用 skill creator 这个 skill， 那 直接告诉你你想要修改的地方在哪里。比如说我让他帮我们修改 content writer 这个 skill， 那 限制输出的字数在一千字，那接下来 skill creator 就 会来帮你去修改这个 content writer 这个 skill 来限制输出的字数。 那如果你还有其他的需求，那依然也可以这样来操作，那这样的话，你的第一个 skill 就 完成了，是不是很简单？ 那其实做 skill 啊，最难的一步不是技术，是你想不想解决那个麻烦。那现在就去试一试啊，把你平时觉得最烦，重复最多那件事变成你的第一个 skill。 如果你在使用 ai 的 过程中踩了什么坑，或者做出了什么牛掰的功能啊，欢迎在评论区分享出来，我们一起交流。

bloodcode 的 创始人 boris cherny 的 c， l， a， u， d， e 点 and d 文件只有一百行，它的推文直接八百万播放，为什么大家写八百行的配置还不如它一百行的好用？ 说白了，大部分人的 c， l， a， u， d， e， d 犯了一个致命错误，写太多了。 boris 的 原则是每一行都问自己删掉这行会不会让 cloud 犯错，如果不会就删掉配置，文件不是越长越好，而是越精准越好。 boris 怎么用 c， l， a， u， d， e 点 memdi 的， 他说这是一个活文档，每次发现 cloud 做错了什么，就加一条规则进去，不是一次性写完八百行，然后祈祷他生效，而是每天迭代，每天优化，这才是正确的用法。 更夸张的是， boris 同时跑十到十五个 cloud code 的 绘画，五个终端，五到十个网页，还有手机上几个。每个绘画用独立的 git worktree 修改，不冲突，这是他们团队的头号生产力技巧。 所以核心就三点，第一， c， l， a， u， d， e 点 m d 要精简，每行都有用。第二，把它当活文档，每天叠带。第三，多绘画并行，用 worktree 隔离。 创始人都这么用，你的 c， l， a， u， d， e 点 m， d 写对了吗？评论区聊聊。

今天咱们来聊一个事儿， cloud 点 md， 这是 cloud code 全站观察的第一集， 你有没有遇到过这种情况？你让 cloud 帮你改个 bug， 上来就把你的代码风格全改了，你用的 tab 缩进它给你换成空格，你用的中文注视它给你翻成英文，你让它写个接口， 他不知道你项目用的是 r e s t 还是 grapho， 不知道数据库是 mexico 还是 mango db 每次都要跟他重新解释一遍，累不累？说到这儿， cloud 点 md 就是 专门解决这个问题的。 简单说，它就是给 ai 写的一份项目说明书，你把规则写好， cloud 点 md 到底是个啥？ 我打个比方你就明白了，你新招了一个实习生，第一天上班，你不得跟他交代一下，咱们项目用 react， 不是 view， 代码风格用 prettier， 提交信息用中文个是必须写。 cloud 点 m d 就是 干这个事的，只不过它不是写给实习生的， 是写给 ai 的。 技术上讲， cloud 点 m d 是 一个 markdown 文件，放在你项目的根目录下， cloud code 启动的时候会自动读取这个文件，把它作为上下文加载进来，你在里面写的每一条规则， cloud 都会遵守。 说到这儿，这就很关键了， cloud 点 m d 不 只是一个文件，它是一个三级配置体系。第一级，大局配置 放在用户主目录的 cloud 文件夹下，所有项目共享。第二级，项目配置放在项目根目录，只对当前项目生效。第三级，目录配置 放在特定子目录下，只对那个目录下的操作生效。这三级是继承关系，子级可以覆盖父级，就像 c s s 的 层叠一样，全局是默认样式，项目是主题定制 目录是组建级别的微调。那么问题就来了， cloud 点 md， 到底该怎么写？咱们先说说什么不该写。很多人一上来就把整个技术文档粘进去，写了五百行代码，大错特错。 cloud 的 上下文窗口是有限的， cloud 点 m d 越长，留给实际工作的空间就越少。记住一个原则，只写 cloud， 不 可能自己猜到的东西。具体来说，这三类信息最值得写。第一，代码规范，缩进用 tab 还是空格， 命名用驼峰还是下划线，注视用中文还是英文？这些是风格层面的， cloud 不 可能猜对。 第二，技术栈约束，前端用 react 还是 view， 后端用什么框架，数据库用什么类型？这些 cloud 看的代码能推断，但你直接告诉它更省事、更准确。 第三，项目特有规则。比如不要修改 dot e m v 文件，提交信息必须包含 j i r a 公单号，公共组建改动需要同时更新测试，这些是业务层面的规则。 cloud 不 看 cloud 点 m d， 根本不可能知道。 说到这儿，有个高级玩法，很多人不知道目录级配置。比如你有个 api 目录， 里面全是后端代码，你可以在这个目录下单独放一个 cloud 点 m d， 写上这个目录下的代码，使用 snake case 命名接口，返回格式遵循 j s o n a p i 规范，这样 cloud 在 处理这个目录下的文件时，会自动加载这些额外规则。 说到这儿，咱们来聊聊最常见的几个坑。第一个坑写太长，我见过有人写了八百行的 cloud 点 m d， 把整个项目架构、所有 api、 文档、数据库、 schema 全塞进去了，结果呢？ cloud 光读这个文件就消耗了大量 token， 留给实际工作的上下文不够用了，反而表现更差。 记住，代码量控制在五十到一百行以内，只写最关键的规则。第二个坑，写太模糊，比如代码要写好，注是要清楚，这种话跟没写一样，你得写具体的使用双引号函数，必须有返回类型注解， 每个组键导出前加 js doc 注试，越具体越好。第三个坑，忘记更新项目，技术栈升级了，从 javascript 迁移到 type script 了，但 cloud 点 md 还在写使用 javascript， 这会误导 cloud。 cloud 点 md 不是 写一次就完了的，它应该跟项目一起演进。我建议每次大版本更新的时候，同步检查一下 cloud 点 md。 第四个坑，局配置滥用 局。 cloud 点 md 适合放真正通用的规则，比如使用中文交流，提交信息格式。但如果你把项目特定的规则放局了，那你在做别的项目的时候， cloud 就 会犯迷糊，明明是 a 项目的规则，它用到了 b 项目上。 说到这儿，给大家一个我总结的万能模板，总共就五个部分，第一部分，语言，写明项目使用的编程语言和版本。第二部分，技术栈，前端框架，后端框架、数据库测试框架，用一行列清楚。第三部分， 代码风格缩进命名、引号类型、注视语言这些最基础的。第四部分，项目规则，特殊约定、禁止事项必须遵守的流程。 第五部分，目录结构简单，列一下主要目录和它们的职责，就这五部分，代码量控制在五十行以内， 就能覆盖百分之八十的场景。好了，今天咱们就聊到这儿，咱们来回顾一下今天讲的重点。第一， cloud 点 m d 是 给 ai 写的项目说明书， cloud 启动自动加载。第二，三级配置体系局局项目目录继承覆盖灵活精准。 第三，只写 cloud 不 可能自己猜到的规则，代码量控制在五十到一百行。下一集咱们要聊的是 hooks 让 cloud code 自律，你写完代码忘了跑测试， hooks 帮你自动跑，提交之前忘了格式化， hooks 帮你自动格式化，让 cloud code 变成一个不需要你操心的自律助手。别忘了点赞、收藏、关注系列持续更新，咱们下期再见！

好，今天我们来聊聊这个 cloud code 手册，它呀，正在彻底改变我们写代码的方式。这一句话简直说出了咱们开发者的心声啊，就是那些烦人的无穷无尽的细节工作。 那如果 ai 不 只是个辅助，而是能直接帮你干活的同事呢？哇，这想法可就颠覆了。所以你看重点来了， cloud code 不是 一个更聪明的补全，它是个全新的五折， 一边是给你建议，另一边是直接采取行动。 ai 不 再是你的副驾驶了，它现在能自己开车。所谓 ai 代理，核心就是行动，它不是跟你聊天，而是个有工具，能直接动手干活的系统。 你看，读写文件，跑命令，跑测试，上网书读写，这些能力加起来才是真正的智能代理。 那当 ai 能搞定这么多事儿，我们开发者的角色会变成什么样呢？你的角色变了，变成了系统导演，你定个大方向， ai 去执行，你最后来验收就行。也就是说，你终于能从那些模板、代码和语法里解放出来，专心搞架构和判断了。 而且啊，这可不是什么未来预测，是正在发生的事实数据最有说服力了。我们来看看全球 github 提交里，居然有百分之四是 cloud code 写的，这数字想想都觉得厉害。 还有这个生产力直接翻了两倍，百分之两百，早用上的人，开发速度已经完全不一样了。那么面对这种变化，什么才是现在最值钱的新技能呢？没错，就是和 ai 工具写作的能力，怎么指挥它，评估它，这已经是最核心的专业能力了。 ai 帮你解决了怎么做的细节，但做什么和为什么做，还得靠我们人类的判断，你看技术的门槛儿几乎没了。那现在问题就揪给你了，你想用它来创造点什么呢？

大家好，欢迎观看本期视频，本期视频让你搞懂 cloud code 的 cloud 文件夹。 你有没有注意过，每次用 cloud code 的 时候，项目根目录下总会出现一个 cloud 文件夹，大多数人看到它要么无视，要么直接删掉。但我告诉你， 这个文件夹才是你把 cloud 从一个普通 ai 助手变成你团队专属编程伙伴的关键。今天这期视频，我会带你把这个文件夹从头到尾拆开看一遍，看完之后你会知道怎么配置 cloud， 让它真正按你的方式写代码。 在正式开始之前，先纠正一个常见的误解。很多人以为只有一个点 cloud 文件夹，其实有两个。第一个在你的项目目录里 属于团队配置，你可以把它提交到 get 团队里，每个人拉取代码后，都能获得相同的规则、 命令和权限。第二个，在你的用户主目录下，也就是系统账户目录下，这个是你的个人配置，存储你的偏好，绘画、历史和自动记忆，不会影响其他人记住这个区别，后面的内容理解起来会轻松很多。 好，我们从最核心的文件说起。 cloud 点 md 这个文件相当于 cloud 的 说明书，每次你启动 cloud code 的 绘画，它第一件事就是读取这个文件，把内容加载到系统提示词里，整个对话过程中一直参考。 换句话说，你写什么， cloud 就 遵循什么。你告诉他实现之前先写测试，他就会先写测试。你说不要用 ctrl log， 用自定义的 log， 他 每次都会照做。 那 cloud 点 md 里到底该写什么呢？很多人容易走两个极端，要么只写一行，请认真写代码，要么写了五百行，恨不得把项目文档全塞进去， 这两种都不好有效的 cloud md 应该包含这几类信息，第一，构建和测试命令，比如 npm， run， test， make build 这些，让 cloud 知道怎么运行你的项目。第二，关键架构决策， 比如我们用的是 turbo ripple 的 mono ripple 结构，一句话就够。第三，容易踩坑的地方，比如 type script， 开了严格模式，未使用的变量会报错。第四，编码规范，导入顺序，命名风格错误，处理方式， 不该写的是什么？已经有 linter 管的事情不用重复写，能通过链接看到的完整文档不用复制进来。解释原理的长段落也不需要一个关键原则，控制在两百行以内， 超过这个长度，上下文消耗太大， cloud 对 指令的遵循度反而会下降。我给大家看一个大约二十行的视力， 它包含了命令、架构、规范和注意事项，简洁，但什么都没落下。这就是一个好的 cloud 点 md 该有的样子。 接下来说一个很实用的小功能， called dot local dot md。 有 时候你有一些个人偏好，比如你喜欢不同的测试运行器，或者习惯用特定的方式打开文件， 这些是你个人的习惯，不应该强加给整个团队。这时候你在项目跟目录创建一个 cloud 的 local md 就 行了。 cloud 会在读取主 cloud 的 点 md 的 同时读取它，而且它自动被 get nori。 你 的个人配置永远不会进入代码仓库。团队规则归团队，个人习惯归个人。 随着项目变大，团队变多，一个 cloud 的 电 m d 可能不够用了，你发现它从一百行变成了三百行，乱成一团，没人维护， 这时候就需要用到 russ 文件夹了。 cloud russ 里的每一个 markdown 文件都会自动和 cloud md 一 起被加载。 你可以按关注点拆分 code style， md 管代码风格， testing， md 管测试规范， api conventions， md 管 api 约定。 负责哪个模块的人就编辑对应的文件，互不干扰。但真正厉害的是路径作用域功能。你在规则文件的头部加一个 emo front matter， 指定 pass 四段， 这个规则就只在 cloud 处理匹配路径的文件时才会生效。举个例子，你定义了一个 api 设计规则， pass 设置为 s r c api 星星斜杠星点 ts。 那 当 cloud 再编辑一个 react 组件时， 这个规则根本不会被加载，只有在它碰到 a p i 相关代码时才会生效。这就避免了不相关的规则占用。上下文窗口非常精准。 cloud code 自带一些斜杠命令，比如 help 和 compass。 但你知道吗？你可以自己创建命令。方法非常简单，在 cloud commands 里放一个 markdown 文件，文件名就是命令名。 比如你创建一个 review 点 md， 它就变成了 project review。 创建 fix issue， md， 它就变成了 project fix issue。 让我来演示一个代码审查命令。 在 review md 里，你可以用感叹号加反引号的语法嵌入 shell 命令，比如写上 get diff main dot dot dot head。 当你运行 project review 时， cloud 会先执行这个 get 命令，拿到真实的代码差异，然后注入到提示词中，再进行分析。这不是普通的模板， 它能动态获取真实数据，这才是自定义命令真正强大的地方。你还可以用美元符号加 arguments 来接受参数，比如做一个修复 issue 的 命令，运行 project fix issue 二三四的时候， cloud 会自动去获取 issue 二三四的内容，理解 bug， 追溯根音，修复代码，然后写测试。另外提一点，项目级命令在 cloud commands 中提交到 get， 给团队共享。 个人命令放在到 cloud commands 中显示为 user。 命令名只有你自己能用，这个好习惯会让你受益。 说完命令，我们来看一个更高阶的概念， skill 命令和 skill 表面上很像，但有一个根本区别，命令需要你手动输入斜杠来触发，而 skill cloud 可以 自己判断什么时候该用。 当你在对话中说，帮我检查一下这个 pr 有 没有安全问题。 cloud 如果有一个安全审查 skill， 它会自动识别到需求匹配，然后主动调用。你不用记命令名，不用敲斜杠。每个 skill 放在 cloud skillless 第一个子目录里，核心文件是 skill 点 md， 里面的 yaml frontmatter 描述了这个 skill 的 名称 何时应该被使用，以及允许使用哪些工具。跟命令相比， skill 还有一个重要优势，它可以捆绑多个文件，比如一个安全审查技能。不光有 skill 点 md， 还可以附带一份详细的安全标准文档。 命令只能是单个文件，而 skill 是 一个完整的包。当任务复杂到一定程度，你可以定义专门的子代理。 在 cloud agence 里创建一个 markdown 文件，比如 codriver dmd， 在 里面定义他的角色，描述可使用的工具和首选模型。比如你定义了一个代码审查代理告诉他你是一位专注于正确性和可维护性的资深代码审查员，限制他只能使用 read， grab， globe 这些指读工具。模型选用 sonnet， 当 cloud 需要做代码审查时， 它会在一个独立的上下文窗口中启动这个代理。代理完成工作后把结果压缩汇报回来。 你的主绘画不会被大量中间过程占据，保持干净高效。这里有两个设计细节值得注意， tos 字段限制代理权限，安全审计员不需要写文件的能力。 model 字段让你为简单任务选择更快更便宜的模型，把高端模型留给真正需要的地方。 最后一个关键文件 settings 点 jason。 这个文件决定了 cloud 能做什么，不能做什么。它有两个核心列表，允许列表和拒绝列表。 允许列表里的命令 cloud 可以 直接执行，不用每次都问你，比如 mpm， run， test， get status 这些常用命令。 拒绝列表里的命令无论如何都被禁止，比如 r m 杠， r f， curl 以及读取点 n f 这类敏感文件。两个列表都没有包含的命令呢？ klo 的 会在执行前先问你一声。这个设计很聪明，给你安全保障，同时不用穷举每一种可能。同样的，你也可以用 settings local jason 做个人覆盖，自动被 get 个 nory， 不 影响团队配置。 好，让我们把所有内容串起来看一下完整的目录结构。项目层面有 clad md 和 clad local md。 cloud 文件夹下有 settings， json， commands， roulette， skills 和 agents。 局层面的到 cloud 是 大有你的个人 cloud 的 电 md 局设置， 个人命令， skills， 代理以及自动保存的项目记忆。项目级别管团队，局级别管个人，两层配置，互相补充，互不冲突。 如果你之前从没配置过，别急，按这五步来就行。第一步，在 cloud code 里运行斜杠 in it， 它会自动读取你的项目，生成一个 cloud 点 m d， 你 在这个基础上删减到核心要点就好。 第二步，创建 settings， 点 json， 至少允许常用运行命令，禁止读取 n b。 第三步，为你最常做的事情创建一两个自定义命令，代码审查和 action 修复是最好的起点。 第四步，考己 md 臃肿时，开始拆分到 ruse 文件夹。第五步，添加 cloud cloud， 点 md， 写入你的个人编码偏好百分之九十五的项目，到这一步就足够了。 skill 和 agent 是 进阶优化。 最后总结一句话， cloud 文件夹本质上是一种协议，告诉 cloud 你 是谁，你的项目做什么，以及它应该遵守哪些规则。你定义得越清晰， 纠正 cloud 的 时间就越少，它帮你干活的效率就越高。拷机 m d 是 杠杆最大的文件，先把这个搞好，其他一切都是优化。如果这个视频对你有帮助，别忘了点赞收藏、关注，我们下期见！

如果你也在用 cloud code， 但只会一个 cloud 命令就开干，那这条视频你一定要看完，我把我自己天天在用的命令和插件全部给你打包好了，看完直接上作业。先说说怎么启动，最基础的就是直接敲 cloud 回车就能用，但你要是跑长任务，频繁被全键弹窗打断，有两个金阶姿势。 第一个叫 cloud 杠杆， dangerously skip permissions， 意思是完全禁用所有权限提示 cloud 想干啥就干啥。速度快是真快，但它几乎没有 promote 注入防御，所以最好别用在你自己的主力机上。推荐在 dog 或者一次性虚拟机这种隔离环境里跑。 第二个操作，其实我更推荐叫 cloud 刚刚 permission auto mode 自动模式，它不是躺平，而是后台有个安全分类器，判断哪些操作是安全的，哪些需要提醒你有兜底，有风险低的，特别适合你信任的大方向，但不想中途被打断的长任务。 还有一个很实用的 cloud 刚刚 review 启动的时候，它会让你挑一个历史绘画继续，它可以接着昨天的活继续干，不用从零开始。启动完进入到绘画，里面有几个斜杠命令，你必须学会。第一个是杠 model， 它可以让你去选择模型，但这里我要提醒一下，这里不建议中途换。为什么？因为大模型是有 k v k 缓存机制的，你每一轮对话都是在用上下文 里面去追加消息。命中缓存的话，价格可以直接打一折，而且响应还非常快，但是一旦你切换模型了，缓存就废了，又贵又慢。 然后第二个是 effort， 它可以去设置思考程度，简单任务低一点，复杂任务拉满。加来几个是关于上下文的技巧。第一个杠 clear， 这个是彻底气功，相当于重新开一个全新的绘画，什么都不留。还有一个是杠 compact， 这个是把你之前的上下文做一个压缩，当你的上下文用量比较高的时候，你可以使用这个命令。 对，然后你如果说想打断这个命令，你可以直接按 esc， 这也是一个技巧。 还有个技巧是你可以连续按两下 esc， 这个的话就可以回退到你之前的命令，然后你之后他会有三个选项，第一个是回退到之前命令，第二个是你以你当前的绘画为基础，做一个呃上下文的压缩。第三个是什么也不做。接下来重点来了， 有个命令叫白泽伟，这个一般是用在呃什么场景呢？他一般是我们有一个长任务正在跑着，但是突然有一些无关紧要的事情，或者是有一些问题要问他，比如说刚刚这个文件的配置目录 是什么？那这个时候可以去用白泽位这个东西来问一下他，他是能看到当前绘画的全部上下文的啊，但是他的内容是不污染主上下文的，也不去，不会去打断 claus 正在跑的任务。他缺点是不能用工具。 对，他和 sub a 的 区别就是说啊，白泽位有上下文，但是没有工具， sub a 的 有工具，但是他没有你主绘画的上下文， ok？ 最后一个还有一个技巧就是呃打一个感叹号，这感叹号相当于你可以在终端里面直接执行 batch 命令，比如说 b p、 w、 d， 就 可以看到你在幕后是什么 命令。讲完了，再讲几个我正在用的工具还有插件。第一个是查看上下文的，呃， cloud code 插件叫 cloud hub， 你 可以看到效果就是这样，它可以看到你上下文的使用情况，你的 token 的是，呃，还剩余多少？对，然后它的 github 地址是在这边， 它目前是有十八点三 k 和 star。 对， 安装命令也很简单这一行即可。呃。第二工具是豆包输入法，因为我们目前和大圆模型对话最方便的模式肯定是语音输入， 我们在这边直接按住 option 就 可以输入语音，比如说帮我实现一个历史动画效果， 你可以看到他的翻译是非常精准的啊。最后一个就是啊，我非常喜欢的一个功能就是这个灵动导模式，可以看到我这个上面是有一个灵动导模式的。然后这边，呃可以在多个 a 镜头里面去切换，而且它可以实时显示你的一个头款的使用情况 啊。比如说我在格式里面说你好，然后又在口袋里面说你好， 在这边实现类似动画效果，你看这边好了，它都会提示你去切换，这样就非常方便了。 以上就是 clockcode 我 每天都在用的全套命令和工具的使用技巧，如果你觉得有用的话，请点赞、收藏、评论区留言，我会把所有工具的下载地址整理出来发给你们，我们下期再见。

大家好，今天给大家分享十五条我经常使用的 clockcode 技巧，那这十五个技巧有些是我自己总结出来的，那有些也是学习别人学到的，那每一个技巧我都会讲解一下。第一个呢，就是设置这个 clockcode 的 别名啊，那当我们要启动一个绕过权限的这个 clockcode 的 十一的时候，我们要敲 这么一大串 mini， 那 有时候可能是会经常忘记的，这个时候你就可以设置一个别名，那么你就可以使用这种 c 杠 d 的 方式来启动，那是非常非常方便的。比如说我已经配置好了我的别名，那我就输入 c 杠 d， 那么它就会帮我启动一个最高权限的 curlcode 的 实力。除了上面这种方式啊，你也可以在 curlcode 的 配置文件里面去配置这个 skip dangerous， 然后把它设置成 true， 那 么你也可以是绕过权限的。那第二个就是 any 命令去重构或者初步化 cloud md 文档。 那 cloud md 文档呢？是 curlcode 的 非常重要的记忆文件，在我们跟 curlcode 的 进行对话的每一次 过程中， cloud md 都会加入到这个上下文里面，所以说非常非常重要。那么如果你不知道怎么写，或者说这是一个老的项目，那么你就可以使用 edit 命令，让它去了解你的代码库，然后去编写一个最初的 cloud md 文档。那么你拿到这个文档之后呢，我是非常建议你去做一些手动的调整， 那么你可以按照这个结构来进行调整啊，比如说第一个是对这个项目的一个简短的描述，那第二个呢，就是代码的规范，就是你的编码规范是什么，这里不要写的太多，如果写的太多的话，你可以在这里直接引用，通过艾特符号，引用文件的方式把它引到外面去，让他写代码的时候去遵守这样的编码规范。 那第三个就是常用的命令，比如说你的启动的命令，你的测试的命令，这边写上去就方便 call 去执行，这样命令的时候不用去猜想你的项目是什么，你的启动的命令是什么， 那第五个是你的文件的主要的结构，那第六个就是非常非常重要的，就是你要让 ai 记住最重要的事情是什么，那么怎么去碰， 那么怎么去分辨哪些信息该留下来的，哪些信息给去掉了，你就记住这一句话，你把这条信息删掉之后，大模型返回的代码质量就会很差，有可能就会报错，那么你就把这条内容给留下来就行了。所以呢，我们的 curl md 文档一定要尽量的简洁，留下最重要的信息，不要留下 太多的信息，这样的话反而是起不到更好的效果的。那么在最新版本的这个 int 命令已经更加的智能了，当你执行这个 int 命令之后啊，它会 它会去搜索你代码库的信息，也会来帮你配置对应的技能插件和钩子，那么这个是非常非常重要的。那么在最新版本里面，你需要在 settings 点接收 开启这个 cloud code new edit， 然后输入一，那么你再重新打开输入这个命令，它就会按照新的方式流程来执行了，可以大家可以去尝试一下。 那第三个就是有些人是不喜欢使用这种 curl 的 终端，其实输入字母啊，或者说对话起来非常费劲，那么你也可以使用带有 ui 的， 然后并且具备 curl 的 能力的这种啊，客户端或者说终端， 那 vs code 呢？加上 curl code 的 官方插件也是可以的。那这里有一个项目叫 web 看版了，也是非常有意思的，它是一个网页，那么它是连接了 curl code 的， 这些能力全部都有，比如说你用技能啊，用命令啊，全部都可以直接调用， 那它是可以把你的项目分成不同的阶段，比如说你现在开启一个任务，然后这个任务在进行中，已完成或者 review， 每一个阶段你都可以拖到对应的这阶段里面去开启，然后它也是可以多开 多个这样的 worktree 的 实力啊，是非常非常有意思的一个一个项目。那当然除了这两个之外，还有非常非常多像这种 cloud code 的 管理的工具。第四个就是个小技巧了，当你按 一次 esc 键的时候是停止输入，那么你连续按两次的话，会直接进入 word 模式来进行回滚，你也可以直接使用这个命令来进行一个回滚，那当你关闭 curl 的 实体的时候，它会出现下面一段的符，就是用来进行一个恢复的。那比如说我们现在把它关掉之后，这边就会出现一个这样的重启， 那么你就可以直接下一次输入这样命令去重启了。那么你也可以把这个命令啊设置一个快捷键，然后的话这边输入一个特定的参数，也是可以使用刚刚我说的这种别名的方式来重启的， 那这样敲命令重启之后，他就会回到你的这条对话的这个最后的一次记录里面去，是非常的方便的。第五个就是我最近经常在用的，就说跟 clock 的 对话的时候啊，你最好提供一个详细的反馈列录。 那什么是详细的反馈链路？我们可以从下面这个例子来体会一下。如果没有反馈链路的这种方法，那么没有反馈链路的方法，这样比如帮我做一个邮箱密码登录的功能， 那么 ai 在 接收到你的需求的时候会开始去写代码，写完之后他就会告诉你已经完成了，那么实际上真正的完成了吗？我觉得是肯定是不够的。那么提供反馈链路的方法是什么样子呢？就是你要让他做完代码之后进行一套流程，比如说进行编辑， 然后进行代码测试，进行页面的测试，然后一些还有一些流程的测试，那么你呢给他定义 完成这些链路之后才叫成功，那这样的话是可以极大的提高这样准确率的。那如果说这条链路哪个地方没有完成 测试失败了，让他继续修复，这样的话，他所谓的成功就不是那么简简单单把代码写完就成功了，所以呢，这是一个非常好的优化的方法。那其实除除了你自己去写这样的一个啊电路的话，那么很多 spag 工具，就规范驱动的工具啊，它会生成对应的场景， 场景的测试用力，那么基本上也是含盖这些链路的。但是当然如果不用规范驱动的话，那么你可以自己去手写这样的链路，这是一个非，这是一个很好的一个提升效率的办法。那第六个呢，就是安装一个针对于语言的代码，这种插件啊，就是 lsp， 那 么 lsp 的 作用就是每次文件编辑完之后，自动会给拷入或者缺少返回类型啊，语法错误啊，那拷拷扣的都可以去提前发现， 那么如果没有 a s p 的 话，很可能需要在翻译的阶段才能发现这个问题，那安装也是非常方便的。在这边输入 print 插件，然后你要找到 在 marketplace 里面你是不是安装这个官方推荐的插件，如果没有的话，你需要先把这个插件安装好，安装好之后呢，你就在这个 discover 里面去搜索，你说回到这个搜索框里面搜 l s p， 那 么这里面就会出现它目前支持的 l s p 了，那么你就可以选中，呃， 然后这边按 ctrl 键，然后去选择是安装到你的这个用户级别的还是工程级别的，然后你就点确定就安装完了，那你就可以去使用了。第七个就是老生常谈的问题啊，尽可能多的去使用技能，或者自己去创造技能，因为技能真的是非常非常有用， 你可以用简单的理解就是技能是等于把一套流程封装好，并且是让大模型给出一个确定的结果，比如说我们我们用到了前端设计的技能，那么大模型看到这个技能之后， 会按照技能里面描述的流程来进行设计描述规范来进行设计，那么它一定得出来的结果是符合这个技能要求的，这个就是减少了 ai 返回代码的不确定性或者功能的不确定，所以说非常非常重要，那么在你的整个 ai 编程的每个环节 都可以去思考怎么去使用技能来提效，那比如说头脑风暴、需求拆解、 ui 设计、技术设计、 plan task、 开发测试流程上线复盘，那么其实每一个流程，每一个节点 都有一些比较好用的这个技能可以去使用，那这边的话是可以听通过这个网站去搜索你需要的技能，那么你也可以安装一个 查找技能的技能，所以说他是有是非常这么就是这么强大，可以输入你的需求去查找你要的这个技能啊，安装好 也非常推荐啊，使用这个命令去安装技能啊，不需要自己去下载这样的包，去放到你的目录里面去，因为我们不同的 ai 编程工具，它的这个技能的目录还不一样了，比如说 css 啊， cloud code 啊， codex 啊，它们的技能的目录是不太一样的，那么用这个命令的话是可以去安装，可以去适配到不同的 ai 编程工具，非常非常方便。第八个就是当你不确定如何处理这个需求和事件的时候，使用计划模式吧，就 prime 模式， 那么这个是非常非常有效率的。那 plan 这个模式呢？是 cloud code 的 内置的一个代码里，它是会去搜索你的代码，搜索你所有可以看到的文件文字，然后去跟你去沟通这个需求，最终确定一个这样的需求文档，然后再去执行代码，这样的话你 跟 ai 之间呢需求这块的逻辑就对齐了，就不会有任何的问题，那么使用也是非常方便的，那么你只要连续按切换这样的 cf 的 tab 键，你就可以看到这里 pre 默的 on， 那 么你就可以去对话了。那第九个就是我相信大家都是这么做的，就是不要用自己的话去转述 bug， 那 直接把报错的日期相关的资料，第一手的资料直接发给 cloud code 就 行了。比如说你如果自己去解释这样的信息的话， 很有可能漏掉这个原始的信息，那不是比比如说这举个例子啊，登录跳转有问题，应该是 tiktok 没存上，你帮我修一下，那么 coco 接受你的需求之后，他就会往这个坑，往这个 token 没存上，这个问题去排查去解决了。 如果你自己的怀疑是有问题的，那么就错失一个非常好的一个修复的机会啊。所以最好的方式是什么呢？你可以加上自己怀疑的方向，但是最最重要的是把日制给贴上， 把原始资料给贴上， ai 就 会去参考你的意见，同同时也会分析拿到的这个日制啊，去排查所有的可能性。所以呢，你要去 二次加工这样的错误信息，除非你有很明确的这个问题是什么，那么你可以去这样去调试。第十个就是这个 clear 操作，就当你在进行下一个任务的时候，你这个任务跟上一个任务是完全没有关联线的， 你不需要用到上一次对话的这个上下文，那么你就可以使用 clear 去清除这样上下文。因为我们在跟 ai 对 话的时候，上下文是不断增加的，那增加到一定量的时候，它就会进行压缩， 那进行压缩是会损失整个代码对话的质量的，那会影响到所有 ai 的 返回的结果，所以呢我们可以去及时去做，进行 clear 去清除，那这样会保持一个代码上下稳的一个干净啊。 还有一种情况是什么呢？是就是说你在跟 ai 讨论某个问题， ai 一 直修复不了，兜兜转转的解决不了的时候啊，这个时候非常建议用 clear 一下，重新开始，你会发现 新的世界。那么我之前碰到过好几次这样的，可能是模型的问题，他就一直解决不到点上，这个时候我就把他颗粒了一下，让他重新再来分析，再来排查，那么就他就完全清醒了，所以这个也是在可以在适当的时候可以救急，可以使用一下。 第十一个就是使用子代理来保持这个上下文的清晰，那这个也是对于上下文的一个管理的一个方式啊，因为为什么呢？因为子代理他是个独立的上下文，他跟 ai 对 话产生上下文是不占用主上下文的，相当于开了一个异步县城，自己去做自己的事情。 那么系统也是自带了一些子弹，比如说搜索代码生成计划，还有处理一些复杂任务。那 cork 在 处理复杂任务的时候，会自动委托给这个子代理去分析，去执行，去完成， 那么你也可以去使用自定义的子代理，那这个是我们经常用到的，那什么情况下要去使用子代理呢？那我的理解就是有很多种情况啊。第一种呢就是你马上要进行这个任务，是一个非常耗时间的任务，而且你的主代理 对这个子代理执行的这个过程是不关注的，你需要的是他的一个结果，那非常典型的就是 code review， 那 么主代理需要的是 code review 的 结果，比如这个代码到底哪里出现了问题，对吧？然后给到我，拿给我，我去修复。那么还有一些是什么？就专家型的，比如说你需要一些 支付漏洞的扫描专家，那么这一类的可以作为是 code review 类型的，让他们去扫描漏洞，找到漏洞，然后反馈到主代理这边去，让他去进行修复，那么这一类是非常适合使用这种子代理的。还有一种就是说你这种 运行测试啊，获取文档这些大量输出的任务，也就是会占用大量上下文的，也可以使用这种子代理的方式。 那么这里还有一种是什么呢？就是你可以你想要把这个任务分拆给多个子任务，同时并行执行，那么也是可以用子代理，但是呢这种的话就比较强调怎么去把子代理建立的非常的独立，互不影响，因为你操作的是同一个代码库，如果说每个子代理之间是相互交叉影响了， 可能导致代码就混乱了。那第十二个就是啊，非常有意思的一个命令叫斜杠。 btw， 那 这个命令有什么意思呢？就是你在 curl code 在 运行过程中，你可以使用这个命令额外的去对话，它是不占用上下文的。那比如说我们现在举个例子啊，我们随便让它去做点事情， 好，他现在正在开始去进行这样的一个代码搜索了，那么你可以使用 b t w， 然后呢输入你的问题就是你现在对这个项目或者对哪里有问题，比如说 他这边就会开启一个这样的一个窗口啊，去对话，但是你的你的这个前面这个任务是在进行的，然后他这边呢也是在进行，而且他这个的对话的记录产生的结果是不会占用你的上下文的，相当于开一个小差， 所以这个还是非常有意思的，可以在你这个过程中去了解一些你想要了解的额外的信息啊。那第十三个就是使用 worktree 去并行开发， 那第三个呢，就是使用 worktree 并行开发，那咱们 color code 里面你使用这个命令， color code 杠杠 worktree， 那 后面这个是一个分支的名称，那这个命令你就会启动一个 worktree， 并且开启一个新的分支， 如果你执行多个的话，相当于多个这样的分支，而且多个这样的一个副本，那么你就可以去并行开发，而且不会相互影响。 那么你也可以使用一些第三方的工具，比如像 conduct， 或者说刚刚对刚刚的这个看板，你可以更加方便界面化的去管理，这样的我可以这样， 那么我使用沃克翠吧，用的比较少，因为我感觉自己脑子弄不过来啊，就是如果开启多个沃克翠的话，那我会我需要关注多个这样的 coco 的 代理去完成这样的任务，我感觉我自己管用不过来。如果你可以 搞定多个同时进行的，那么沃克翠是一个非常非常大的一个效率的提升啊，四个就是选择合适的 m c p 来提升效率，那么现在呢？因为有了技能啊， m c p 的 这个作用范围是进一步压缩了，所以呢，我们只需要安装一两个 m c p 来 做我们的这个很多事情，比如说 pro rite 的 这个 ui 的 测试，它可以自动的去打开浏览器，那么你也可以使用这个 my circle 的 这种 m c p 啊，那么就可以直连去查里面数据，因为有时候我们要测试的时候，我们要让它去查询我们的数据是不是插入成功啦，或者是不是这个查询的数据是不是有问题啊，这个都可以使用 m c p 的 方式，比它去执行脚本要高效的多。那第五十五个呢，就告诉 curl code 要看哪些文件， 那虽然说 coco 有 搜索代码的能力非常强啊，那随着版本的提升，他搜索的能力也在逐步的提升，但是如果你是个技术，你懂代码，那我也非常建议你通过艾特符号去告诉 coco 的 哪些文件的代码 是有相关的，让他去更加快速的去找到这样的代码，因为你如果不告诉他，他去搜索其实也是消费你的 talking 的， 所以呢，我使用自己的加 qq 的 命名方式，那我这边也能看到代码具体情况，那么如果我觉得是哪些文件有问题，我可以直接拖过去，这样的话就能很方便让他去 定位到具体的文件了，这样是极大的提升了这样的一个搜索的效率。那么以上就是这十五个技巧了，那这十五个可能远远不止啊，可能很多人有其他的些技巧，那么这些是我最近整理出来的，里面没有涉及到一些复杂的技能啊，插件啊，我觉得那些是， 那些也是，我觉得那些也是非常重要，但是用好 qq 也是个非常重要的事情。 ok， 那 本期视频就到这，希望这个视频能帮助到你，祝你生活愉快。

今天给大家分享我用了八千到一万刀的托肯，用了两个 max 二十 x 的 cloud code 的 会员，就是两百美金那个得出来的 web coding 的 经验， 我也是把它稿子写了非常长啊，因为今天这个视频可能会又臭又长，至少四十五分钟以上，所以说我把稿子和过程都已经写下来了，我会把这一个月的这个 web coding 的 经验毫无保留的全部说出来。呃，因为我明天也要准备去分享一个呃， 包含了我这个接近十万行代码的一个实际项目，基本上是达到了这个 openai 的 harness engineering， 他 们那个项目应该有到百分之六十到七十的这种 工作的流程，全程没有手写一行代码，从零到服务器的部署，甚至我对这种工程经验我是比较欠缺的，我可能会比较了解这种哦哦哦智能体的项目，但是对这种工程经验我是很欠缺的，甚至我连服务器也不知道怎么购买，都 是由 cloud code 指导我进行购买，并且部署好了之后让它进行这个处理。整个流程我是准备先给大家介绍一下 k v k 曲的一个重要性。第二个就是上下文，去看一下这个 cloud code 它的上下文 com context 它是由哪些组成， 然后是常见的 cloud code 的 一些使用方法，这些这些都很简单。还有就是 cloud code 它的一些架构和子智能体，然后是 m c p 它大概的一个情况和 skills 的 情况，因为这两个东西是你 web coding 必须要做配置的，而且这两个东西都会影响你的上条文。最后是这个 open i 它的 harness， 这篇文章 最最后是我开源的一个 cc team， 呃， creator 的 一个开源项目，可以用这个 creator 去创建这个 cloud code 的 team 模式。呃，里面有三个比较大的重点啊。呃，首先第一个还是最近已经基本上说烂了的这个 harness 约束，我也就是最近非常重要的这个 web coding 的 重点，因为现在的模型它， 嗯，还达不到化腐朽为神奇，你必须要对他进行约束，然后他才能在你的范围内给你一个你想要的结果，要不然他就胡乱发挥，是没有没有一个好的结果的。 这个我也是讲了三次，也给大家分享了三次。在二月份，二月十一号 open 发的那篇文章的时候就给大家讲过一次，当时时看的时候只能说，哎，讲的很有道理，但是是没有概念的。 然后在半个月之前，我再深度的使用这个 web coding 来完成一些项目的时候，我又去读了一点，呃，然后会有更加的深入的一些理解，并且我把它里面的很多细节 都融入到了我那篇那个项目里面进行实现，并且也融入到了这个我的一个开源项目 cctime creator。 这个开源项目 很多很多里面的设置我都是按照这个呃 openai 的 这个 harness engineering 来做的，大家也可以关注一下。嗯， 第二个就是围绕这个多角色的智能体，也就是 cloud code， 它的 team 为是 team 模式为主，因为只有你创建这个 team 模式，你才能让这个 cloud code 跑上几个小时及以上，或者去完成一些自动化的任务，要不然你 使用那个死循环的那个方式，用后壳的方式又把它调回来，又去看你的这个文档，它其实完完全全都是依靠的模型的能力， 稍微难一点的问题，或者说稍微复杂一点的问题，它万一陷进了局部追优，它可能就爬不出来，然后可能就出问题了，或者给你乱改了，比如说给你改一个兜底的情况出来这种，这种是经常出现的，比如说扣袋子，比如说卡拉扣的经经常出现这个问题。呃。 但是有一个，呃建议啊，就是最好不要超过两个小时，但是如果你是单智能体，或者说单一一个你随便起个卡拉 ok 的， 你大概率是 碰不到一个小时的边的，甚至你连半个小时的边你都碰不到，就是他运行一个小时或者半个小时，你完全碰不到这个边。呃。你必须要使用这种听模式，要不然你就是死循环的模式。那那个模式我是不不建议大家使用的，因为他是没有角色的规范的，而且没有这种 文档的规范，我这个反正不是太建议。呃。为什么不能超过两个小时啊？因为，呃。之前其实有一篇文章他们测试过，像 opus 四点五、四点六，他在一个小时的时候，他的准确率或者叫成功率，他能达到百分之九十几以上。 呃。当然这个东西也是按照这个模型，按照你的项目的难度来的，你如果只是让他去重复的执行某一个循环的话，那当然当然都差不多了。但是 嗯，他的那个方式的话，如果他超过两个小时，他的准确度就基本上在下降到了百分之八十了。呃。如果是五个小时，他应该是下降到了百分之五十，就 相当于一半一半的成功率，这样其实效果是很差的，所以说性价比最高的时间段应该是在一个小时到两个小时之间， 但是你要达到这个样的时间，那么你必须要用它的 team 模式，或者你自己配一个。呃， cloud code 的 这种 team 模式。呃，但是我目前使用下来还是，呃，呃，不是 cloud code 的， 之前你用自己去做一些 codex 的 team 模式。呃，这个目前我们也是准备开源一个，但是，呃还没做出来， 嗯，我也是让我们公司的小伙伴去做了一件这个这个开源项目，到时候如果说能做出来这个 codex 的 给大家分享一下，因为 codex 它的性能还是非常不错， 并且它的这种限制会稍微小一点，成本稍微低一点。 ok。 呃，首先我先给大家看一下我使用这个 t 模式的一个效果图吧，因为，呃，我，我其实之前也我今天下午也在做开发。 呃，可以可以，可以，先看一下，先把它往上面拉吧。因为，呃，我是用终端，它的这个时间会它的内容会非常少，可以看到 这些全部都是他自己在进行沟通，这个是测试这端到端，测试这个收后端，然后这他就定三十六个板块，他就已经收尾了。状态权力，呃，他都是有几个智能体进行协助来完成的，我中间是没有没有进行反馈的，或者说没有进行调调试的。 然后这是我给他的一个新任务，我让在他在我的服务器里面装一些 r 语言的环境，然后他自己去检测的。可以可以，可以，看到我们也是让他梳理了一下整个流程，这个流程我都还没看， 呃，这个流程也是他梳理出来了非常多哈。首先，嗯，第一个丁零阶段我就让他进行团队的启动，他就按照我之前用我那个 cctime creator 而去创建的一个，呃，这个配置文件，这是之前的文件， 因为呃没有没有什么改变，他就直接按照这个文件直接进行配了，他就不需要再去读这个读这个 skills 了，他就的上下文就可以节省一点，然后 tokin 也能节省一点， 然后他就创建了这样几个，呃，一会也会给大家讲一下这几个东西。呃。首先后端的开发，前端的开发，然后探索，呃，这个探索研究者我是弄了两个进行并行执行，因为，呃我基本上所有的功能或者项目他都要先进行探索， 不管是搜索也好，还是读代码也好，还是读一些参考的项目也好，因为我这个项目基本上是按照这个 open code 来进行第二次开发的，呃，所以说他必须要读一些 open code 的 原码，他才知道怎么样进行开发，然后连调测试。第一步我就让他 把遗留的问题都做了，因为我这个 qq， 呃做出来的话他是有文档的，他这个文档会非常的详细，呃，包括之前没有做的， 没有做的一些内容，因为我之前上一次已经关掉了上一次没有做的内容，他也会继续的去把遗留的问题去检查一下，检查一下他发现这些就就就完成了。去去去， 他就按照呃这样去拆分并行派发任务，让这个后端去看这些文档，然后前端，然后就去测试、复验，复检，复验这个结果。因为我这个是前后端的，所以说他用的是那个 m c p play o r t 去做的测试，然后这个是又去调研一个新的新的这个问题是不是真的存在， 然后他就发现发现了什么东西。然后第二阶段，然后反正他就自己再按照他的一个方式进行执行。呃，然后进行修复，首先追加新能力， 然后大概就是这样，第五个阶段就是开始了生产那个服务器的部署，然后第六个阶段，第七个阶段反正我是给他了非常多的这种任务和功能，然后他自己进行的拆分和并行。 ok， 我 们也看一下其他两张图吧，再看一张图吧，因为我之前是记录下来有一张图还是算不错的。 这张图应该是记录下来啊，不是这张，这张，这张图看起来是会非常不错。比如说我直接进到了一个新的， 呃，新的一个 cloud code， 我 就直接让他读一下我的这个项目文档，读了之后他会读这个项目文档，以及呃，我刚才那个已经预定好的这个配置文件，就是 team 的 配置文件，就是这些角色的呀，配置文件啊，这些他读了之后，他就直接去创建他的团队，然后我将给他新的任务。嗯，研究者我是让他给 创建两个，因为如果不说的话，他可能就只创建一个。研究者你可以多创建，你甚至并行创建非常多个就可以。呃，因为我想要让他做的功能不止一个，所以说我提前就让他创建了两个，这样的话他的效率就会高点，然后速度会快点，然后我就让他并行去调用，去研究。 呃， ok， 他 就开始读了，他读到了那个，呃，那个配置文件，但是我让他注意一下这个研究者，他们的这个属于他们自己维护的这个文件夹是一样的，他发现啊，他的一些内容啊，他都会写在那个文件夹下面。 ok， 他 全部启动起来了，可以看到全部启动起来了， 全部上线就绪，可以看到这个是管家，这个是后端，前端研究者两个，然后这个是端到端的测试，这是代码 review， 就是 完成了之后他会让 review 去 review 一下。呃，然后我就给他了非常多个完全不相关的指令， 首先就是一个一个命令，让他去检查有没有可以省略，这是前端的一些东西，然后生成了新的数据，这又是一个任务，这又是一个任务，然后这一个又是一个任务，相当于四个任务。我直接给到他，然后他四个问题，他自己去拆分成了两组，然后让这个调研，去调研，然后 呃他，他说了一下，因为他之前有一些遗留的问题，一一起顺带修复。 而且我我不知道是不是因为之前没有总结文档，所以说我就直接让他如果没有写文档，可能已经做了，可能已经修复了这些遗留的任务，然后他自己进行执行。 ok， 他 就收到了，然后他去测试，这又是我又给他了一个新的任务，相当于前面是四个任务，然后定五个任务，定五个任务里面有三个 三四个这种小的任务。然后我又让他，因为我知道他的那个端到端测试的这个智能体他是没有没有没有去使用的，所以说我为了不要让他停下来，我就又给他了一个新的任务，就是二元执行好像有问题，我让这个端到端的去测试，调研一下在服务器上的这个问题， 然后可以看到他们全部都开始去执行了，可以看到任务任务，任务执行排查，然后后面我几乎就没有任何的呃这个反馈了， 都是由他自己去完成，而且这个时间非常的长。呃，首先他去这个调研，调研回来，呃第一个任务他是什么问题？然后第二个任务是什么问题？这个这个是由于我那个呃中转站，因为我们搭了一个中转站，呃他有一些不稳定，所以说呃有些调调整，呃， 然后他就去哒哒哒，然后我因为在这有个默停止了，所以说我提醒了他一下，然后其他的我都没有做操作的，然后他就按照这样的一个流程，因为 opus 他 理解非常强，而且他并行执行的能力也很强。 但是我我用那个 codex 就是 gpt 五点四，然后转了一遍，用它的 api 放在 cloud code 里面，我感觉它的模型没有任何区别，就是 opus 和呃 gpt 五点四，甚至我认为 kimi k 二点五它都不会有这种逻辑上的问题， 就是我认为它们的逻辑能力是一样的，只不过可能模型和模型之间它的这个注意力是不一样的，因为 提米啊，像国内的这些模型，它几乎都是呃这种吸收注意力的机制，所以说它可能会忘记某些问题，但是它整体的思路我觉得都不会有大问题的，所以说模型大家可以不要呃 过于过于关注或者那啥，有条件我们就用好一点的，没有条件我们就用稍微差一点点的。但是 leader 我 们尽量要用稍微大一点的模型，因为呃它才能去控制它， ok， 可以 看到他就付这些角色就在汇报给这个 leader 了。其实我们现在这个对话框就在 leader 里面，当然我们也可以切换了，然后他就开始调查，然后呃他就发现了有一个问题，我就一个呃另外的问题，然后我就让他先不要改，后面再说吧， 然后他们就就搁置了这个问题，然后就继续去执行执行执行执行，但是太长的话我就没有没有一直把它全部录下来，而且我那个中转站又出了一些问题，但是我全程是没有任何的这种 独取，或者我的呃去思考这些代码应该怎么怎么样操作，我全程都是引导他去让他自己去测试，然后自己去 review， 自己去推送，自己去部署到这个端。这个呃服务器上面 整体大概是这么一个情况，这个就是我达到的一个效果，我相信，呃，如果说有工程能力的人，他们的效果可能会更强，因为我是工程经验是不足的，只有只有这种部署的经验，呃，只有这种智能体相关的经验， ok？ 呃呃，现在还是第一步就是 k v k h。 呃，说一说一句啊，这个没有 k v k h 的 这种中转站或者什么乱七八糟的，只要它没有 k v k h 的 命中率，不告诉你有 k v k h， 比如说现在很多的动不动我送你两个亿的 token， 两个亿的 token 够干什么？因为像我，我这个， 我这个项目他请求一次你输入输出就已经掉了三三百八十七 k 了，他如果输入和输出全部算成托管的话，那两下就没了，你三亿两亿又怎么样呢？对吧？你如果没有缓存，那么就是在耍流氓， ok， 继续 呃，可能，可能有点有点说的过过分了啊，但是我觉得呃是没有毛病的。不聊 k v k h 命中率的，全部是耍流氓。 k v k h， 如果说命中和不命中它的那个上下文，比如说刚才那个三三百八十 k， 如果你是一个新的，没有 k v k h 的， 你的成本是十的话，你如果有 k v k h， 你的成本一可能都要不了。所以说这个 qcatch 是 非常重要的东西，但是很多人呃没有关注这个点，只有一些正规的平台，比如说像 deepsea 啊，像这种，嗯， 大平台它会会说这个，但是像很多中转平台它都不会说这个东西。呃，推荐大家一定要看这个东西啊，如果没有的话，它不管再低的价格，它都是耍流氓，都是更贵的。但是，呃，如果你中转，它是有 qcatch 的， 这个这个是 ok 的。 呃，这样的价格其实是，呃可以可以接受的，因为中转一般它的价格都还是比较便宜的。呃， 还有一个点就是大家用这个 max， 呃， cloud code max 二十 x 的 时候，第一第一天或者说前面一周使用的时候，它的量都很少 的一个原因，并不是说那个 cloud code 的 snoop， 它们在降低量。呃，很大的原因就是由于你的任务是你的任务，你的上下文， 呃是在不断的切换的。你的 kuvcatch 其实是没有建立的，所以说，呃，你如果都是新任务的话，那么你的这个使用量肯定就是更少的。 但是如果你呃都是一些老任务，呃它的 kuvcatch 啊，这些建，建立啊，构建啊，它会给你构建非常多，多了之后它的命中率就高了，然后它的 token 消耗就会降下去，呃也会，你的使用量也会增加。如果你是使用中转的方式的话， 这也是我们的一个经验。 ok， 我 们还是简单说一下这个 kuvik 的 一个原理吧，因为很多人呃他 不知道 kuvik 的 重要性，很多时候他是不知道原理的。呃呃，像现在的这些大模型，他都是使用的这种 attention 的 机构，然后 attention 他 要计算下一个词，他都使用的这种自回归的方式，比如说我爱， 可能下一个字是我爱你，那么这个字他必须要跟前面的这几个字去做这种矩阵乘法，然后去得到定四个字，他的一个 k 和 v， 那 么他得出来了之后， 这个 k 和 v 他 是不会改变的。当你下一次又有一个字来的时候，你想要预测下一个字的时候，那么呃他这些 k、 v 是 不变的。如果你把这些丢弃掉， 那么你就重新又要计算一遍。如果你不丢弃掉，你直接只用计算这个 q 和这些 k、 v a a 全部计算一遍，然后得到下一个 k 和 v 就 可以了。这个东西就是 k、 v、 k、 h， 如果你没有了这个 k v、 k、 h， 那 么你就得把之前的全部再计算一遍，这样的话成本就会非常的高。 这个里面就有一个特点， k v catch 的 命中率就在于，呃，我们聊天的时候，比如说我们调用工具也好，还是聊天也好，还是像叉 g p 这样也好，呃，你所有的绘画都是 呃，他回答完了之后，你增加一条绘画，他全部是放在下一个，呃，全部是直接放在这个历史记录的后面的， 所以说它的 k v k h 前面是完全没变的，所以说你这个加进去它的成本是不会特别大的。如果说要按照那种全量完全没 k v k h 的 话，比如说像 cloud code， 别说二百美二百美金一个月，它就是两千美金一个月，它都抵不住这个计算的损耗。 呃，这个里面就有一个特别特别特别重要的点，就是一定你的中间的键是不能破坏的。比如说你自己用 cloud code 的 时候，你把中间，比如说它的历史记录中间你去改一个，改一个关键词，比如说你在中间改一个动态的，动态的比如说时间， 你想让这个大模型它知道时间，那么这件事情就是非常错误的，因为它只要在这变了，那么前面的是可以，嗯，完全用之前的 kuvatch， 但是这后面的 kuvatch 全部报废了， 这就是为什么我们的 qqcatch 不 能动的原因。这个也会引发另外一个问题，也是我之前呃一直错误的一个观点，就是，呃，我之前会用一些比较便宜的模型，比如说嗨酷，比如说用其他的一些简单的模型，呃，去拿到上下文了之后，我再用一些好的模型，比如说 opas， 我 去 对这些东西进行一个呃再推理，这样的话，它岂不是它就不用再去拿前面的上下文了，它就可以得出来一个比较好的结果了？但是不是这样的， 就算你用嗨酷的模型，它的成本都没有 k v k h 已经命中的时候，它成本低。特别是像 cloud code， 它所有前面，比如说调用了工具返回的结果，它是完全没有动的，所以说它上下纹才会那么长，嗯，它的上下纹是完全没有动的，主要就是这个原因， 这个 k v k 的 原因也就是让大家不要去动这个呃 k v k 的 呃不要去动这个模型完成一个任务的时候，你最好就是从上到下全部不要动， 不要在中间去切换模型，切换一次那个成本是你完全无法接受的。不管是呃所有所有的这个呃 code plane 也好，还是什么也好，它们都是在潜在去看了这个 k v k 的 命中率的， 所以说他们才会说说是一个浮动的区间，比如说呃九百到呃一千二的这个呃请求，他们都是计算了这个 k v k h 的， 计算了这个成本的。当你破坏 k v k h 破坏的非常严重，你的重命中率很低的时候，它的这个用量肯定就低了， 当然也包括这些 cloud code 啊，也包括这些 g o m 啊，或者说其他的一些 code in play ok， 呃，这个 q k g 大家应该也是比较比较了解了，然后我们来看一下这个 cloud code 的 一个 context， 就是 它上下文到底是由什么组成的。这个东西也是我非常踩坑的一个点，因为我之前 呃我会装很多 m c p 啊，装很多 skills 啊，甚至我会把呃这个 cloud 的 点 md 文档，我又会给它写的非常的详细，所以说就会造成 我的上下文直接就没有了，比如说可拉的点 md， 因为我想那你可拉的点 md， 你 一直加在在这个呃模型的上下文，肯定我写多一点，然后这个模型他肯定就能按照我这个进行执行，他效果肯定就会更好嘛。其实不是的， 现在这个是没超过呃两两三百行的，但是这个都还是太多了，最好最好就是一百多行， 然后里面写的东西就是呃你的文件结构，还有就是你的一些规划，就是你的规则，你应该怎么样写，怎么样写，反复出现的这种失败模式啊，和一些行为偏好啊，比如说你要用哪些库啊，呃，还有就是这这个东西其实都不应该写， 然后反正这些东西都应该非常简化， ok， 我 们还是是不要跑题啊。还有这些 cloud 的 点 md 文档写的非常详细的时候，我 第一次一打开这个 contacts， 我 拿一个新的对话，啊，这，这也是一次新的对话，我拿新的对话打开的时候，我发现我只有八十多 k 的 正常使用量， 但是大家不要高兴的太早，你们去打开一下，你大概率也不会多于一百 k 就是 你可以使用的， 相信我，肯定是这样的，大家看着这两百 k 的 上下文，它是哇，还是挺长的，两百 k 可以 放好多东西，但是就算你什么都没装， 基本上都没装，你都只有一百四十 k 不 到，应该是一百二十到一百三十 k 可以 使用，但是你肯定不可能什么都不装，比如说 m c p， 你 总得装个把吧？然后 skills 你 要装吧，你的这种记忆文件，比如说这个点 m d， 你 还是得装一点点吧， 一装下来，而且这个都是我优化过后的，都只剩下百分之五十八了。就是，呃，这个两百 k 的 百分之五十八只有一百一十多 k， 当时我没有做优化的时候，里面只剩下八十多 k， 还是蛮震惊的，我就是说我的完成一个项目怎么 还没怎么弄呢，就已经已经搞搞掉了百分之六七十的这个，这个工作空间， ok， 我 们不不聊太多了。呃，首先就是他这个上下文， 首先占比最大的就是自动压缩的一个空间，他是留了百分之十六点零五的一个空间， 呃，是用了三十三 k 的 托肯，这个是占比最大的，但是大家应该使用的时候会发现，他其实压缩出来的内容，他只有个三点几 k 到四 k 多，他不可能用到三十多 k 的， 所以说这个这个点他其实留了非常大的余量。 嗯，这个这个东西我也我也不太清楚它为什么会留这么大的余量啊，按理来说如果说四五 k 的 话，你就算这个有一些突然的爆发，那么你这个东西应该也是在个二十 k 就 够了呀，它这个已经远远多出来了十 k 以上的这个量，所以说还是非常的恐怖啊。 然后就是系统提示词，这个是静态的，然后这个是系统的工具，这两个东西是你完全不能动的，可 outcode 里面的相当于有三十 k 左右，是你完全不能左右的。还有就是 m c p 的 工具给大家，这个是最大的一个坑哈， m c p 的 工具会占非常多的。呃，这个 token 消耗，我就只装了一个 playrite， 之前我装了好几个，然后我把它全部卸载了，全部不要， m c p 全部不要。你如果说非要用，你就直接把它放在 skills 里面，因为 skills 它是动态加载，按需加载的，所以说它初时的 token 不 会消耗太多。什么情况下应该放在这个 m c p 是 需要装的呢？ 就是你要非常长时间的使用，而且你又必须这个东西。呃呃，怎么说呢？你又必须要 经常用，而且你需要大模型知道你有这个工具，那么你才是。呃，要把这个 m c p 给装上的，要不然尽量都不要装，尽量把它放成这个 skills， 按需加载。当然现在好像也有这个 to search， 但是我我就想的， 如果我不是不是必须要的话，我就直接放在 skills 里面了，我就把这些，其实现在很多 m c p 它都是放在 skills 里面的， 然后这个是用户的一些 index， 你 可以自定义 index 的， 这个，这个基本上不会消耗到特别多的托管。嗯，这个托管基本上就是你自己去安装很多插件的时候，它可能会给你预定义一些子 index 的， 这个是子 index 的 话，这个不是 t 模式的。然后这个是 member 一 些记忆的文件，它其实是叫记忆的文件，但是它记文，记忆文件里面分了很多哈。还有 skills， skills 是 你自己装的，它只加载这个原数据，比如说我要看一下哪一个？呃， skills 给大家看一下。 呃，这个 skills 就是 我的 creator， 这个 skills 它只会加载这个内容，每一个 skills 它只会加载这个内容，所以说它的 token 其实不多的。所以说 skills 大家可以多装一点，无所谓，但是尽量还是不要太多，反正，嗯，有一些这种 benchmark 去测试出来大概是两到四个效果是最好的。 呃，如果说那个，呃 longchain 它们也测过，大概是在十二个左右，它那个效果就已经在下降了。 嗯，我，我认为大家尽量这些东西都不要多装，因为 skills 它的出发条件，呃，你装的多了，它出发就不太精准，它就有点笨，它会分掉它的注意力。如果你不呃主动地显示地要求它去出发这个 skills 的 话，它大概率是不会出发的。如果你装多了， 然后这个 message， 呃， message 就是 发的这个消息了，就刚才我们发的这个 context， 呃，这个就是你自由的，自由的上下文有多长。这个东西，呃，大家最好自己去检查一下。 ok， 我 们也看一下这个 m c p， 这个是 m c p 具体的每一个工具，它的一个 tool。 然后是其实最重要的是这个， 呃，它自带有一些 agent 的 tool， 这个是我自己装的，这些都是我自己装的。呃。有一些，呃 md 的 文档，呃，这些 token 其实最消耗的是这个，呃， cloud 点 md 文档，这个花掉了五点五 k， 就是 给大家刚才看的这个 cloud 点 md 的 文档，虽然只有两三百行。 还有一个就是 member， 呃，他会把你的一些习惯呀，你的东西，比如说你说，哎，你记住以后不要这样，他自己会去打开这个 member， 他 会把这些条件记进去，但是 member 他 只会加载两百行， 只会加载前两百行去到他的上下文文件，而且他记录的都是一些，呃，非常简要的规则，他不会记录非常复杂的规则哈。呃。所以说 这个东西你也可以看一下，然后做一些优化也是可以的。比如说他最后就建议要去优化一下这个 member 文件，但是优化了之后他肯定是有损失的，这个东西大家还是要评估一下到底是不是要做。 ok 哇，这个时间已经太长了，我们继续啊，继续快一点。 嗯，再就是稍等。呃。再就是这个 cloud code 怎么样去配置， 我是使用 cctime 会比较多一点，然后模型的话，呃。自己看自己的能力。呃。我个人感觉，比如说你要用 team 模式，它的主对话 leader， 你 最好还是要用这个一照上下文的，所以说用千万三点六也是比较好的。然后 kimi k 二点五， 因为 kimi 它是专门对这种病病情处理，它是做了优化的，所以说 kimi 也是比较推荐。因为我我们今天聊的基本上都会跟这个 cloud code 的 team 模式相关啊。呃。但是我个人感觉效果蛮不错的， 就是这个 gpt 的 五点四，因为我是专门用这个中转站去测试过这个 gpt 的 五点四，甚至我觉得它在步骤规划呀，病情处理呀，指令遵循呀，是比这个 opus 要好的。 oops， 它有时候还会忘记一些东西，或者说它注意力没有那么多，但是我感觉 gpt 的 五点四它指令遵循啊，这些都会都会记得，比如说像我的这些 team 模式，它会记得要。呃。首先要去用研究，研究了之后要把东西给到这个 呃前后端去实现，实现了之后还要丢给这个 code review 去看一下这个代码是不是 ok， ok 了之后他会再去做测试，去部署测试，测试了之后他又会让这个管家去看一下他这些文档是不是 ok 的， 然后这些 ci 是 不是 ok 的。 这个这个 cloud 的 这个 gpt 的， 我感觉它的效果是最好的，比这个 opas 效果都好，因为 opas 它经常会忘记，经常会忘记。比如说我里面有一个特别重要的点，就是 leader 去下发任务的时候，这些员工他应该跟这个 leader 去多次重复， 多次对齐这个需求。万一有一些 leader 它是没有看具体代码的，很多细节它是不知道的，所以说它们需要去沟通。但是像 cloud 的 模型很多时候是会忘记掉这个东西，但是 gbt 它是 ok 的， 但是它很很大的问题就是 gbt， 呃，现在的基本上它都只支持二百七十五 k， 呃，它是不支持一照的，但是你的 leader 没有一照上下文，所以说效果是不好的。因为一照上下文它并不是一照上下文它能给你带来多少的能力的提升，而是一照上下文你能选择压缩的这个时机， 压缩是你选择的，而不是他到了两百 k， 到了两百七十 k， 然后他自动压缩的，这个是非常重要的，因为就算有一兆我也不会用到一兆，我最多最多的时候我用到过五百 k， 但是很明显的感觉到出来他的上下纹腐烂的问题很严重。就算是欧巴斯， 他到三百 k 的 时候效果基本上都很差了，因为你肯定不可能一个任务你能完成。嗯，他的上下文长度能到三百 k， 因为 leader 他 只派发任务，他不做具体的代码，所以说 肯定是多个任务多个任务完全的这样执行下来，所以你三百 k 的 时候，你塞了非常多的这种任务在他上下文，而上面的这些任务其实跟下面的任务它相关性很低， 所以说你你你，你后面这个上下文腐烂的问题非常严重。到三百 k 的 时候，我基本上都在做一些收尾的工作了，呃。要考虑压缩上下文了，我就直接告诉他，呃。我准备压缩上下文，嗯，你做一些收尾的工作，看一下还有哪些工作是没有做的，有哪些测试还是没有做的，有哪些文档还是没有归类的， ok， 呃。就算没有 gpt 或者 cloud 的 这种比较顶尖的模型，其实用这种，呃 plus 的， 用这种千问，用这种 kimi， 它其实都还是可以的。它们的逻辑性我觉得都是没问题的。 我认为最大的问题是注意力的问题。就像我刚才说的就是模型，它在执行这个任务的时候，它就把之前的一些指令给忘记了，因为我们要让它效果好，你给它的指令其实是非常多的，比如说你在执行完了之后，你应该写一下文档， 如果说这种这种比较比较差的模型，他可能就会忘记，所以说，呃，这个东西你提醒他一下也是 ok 的。 呃。他的这种逻辑性，我觉得这些模型跟我们人比起来的话，呃。跟我比起来吧，跟大部分人比起来，他的逻辑性都是非常严密的，而且设计都是非常好的。 呃。所以说我觉得不用，如果能能用好一点的模型就直接用好一点的模型，如果用不了好一点的模型也不需要觉得。呃。我用差一点的模型就完成不了这个任务。只要你把 hernes 把约束，把这些规范弄好，然后你注意一下，呃，去多去提醒他显示的提醒他呃。要记得去调用这个模型，然后你可以让他呃去 完成这个任务的时候要怎么样的一个员工流程，先让他梳理一遍，然后再去完成某一个具体的这样的任务。还有就是模型的常见的命令，其实我用的命令都很少，就是我，我其实用的不太好命令，但是我觉得已经够用了。 首先第一个就是这个 dennis， 呃，虽然最近他出了一个自动的模式，但是我认为那个自动模式还是不够自动啊。呃。我觉得这个这个模式还是最好的，因为我我们的项目都不是一些特别机密，然后有非常巨量的这种用户的，然后风险零度感度非常高的，所以说我用这个方式是完全没问题的。 呃。我有一个观点哈，就是大家如果是大大，相信大家去看到这种什么呃。模型商铺跑路的， 自己没有遇到过吧？或者说你身边的人实际的情况下是没有遇到过的。用一些稍微正常一点模型，你别用一些本地模型，应该是没有遇到过这种问题的吧。 如果说你因为这种问题你给自己设了很多限，我觉得这个是得不偿失的。你因为一些潜在的风险，然后自己给自己设了很多限，然后自己给自己呃造成了很多困扰，比如说你要每经常去点击，去同意他的这些命令， 我觉得是得不偿失的，只要你的风险敏感度不是，呃你完全无法接受的，我觉得大家可以冒一定这个风险。 然后这个就是比较常见的继续之前的一个对话，呃，但是我我个人认为哈，你最好不用继续之前的对话，你要不然就直接压缩，要不然你就直接结束了，重新起一个就行了。因为用我的那个 tim tim 模式的话，他会把所有的内容直接放到这个文件夹里面，直接放到这个 点 plan 的 文件夹里面，他下一次启动的时候直接把这个文件夹发给他的话，他就是自己能拿到上下文继续进行执行的。 呃。还有就是这个，呃选择绘画的主题，呃，你可以用这个方式，你可以看一下这个项目里面 你之前的一些绘画，你可以选择之前的一些绘画，这些都是比较基础的操作了。然后就是项目初识画，呃，其实我对这个的话是比较抵触的，因为这个初识画有一篇文章是说过，如果是由模型生成的这种初识画的项目文档其实是没有意义的，没有价值的， 它其实就是专门去生成这个 cloud 点 md， 它的目的就是为了比如说你有个非常大的项目，它这个 cloud 点 md 的 文档会把你这个项目下面的所有哦架构啊这些，呃地图啊这些写在这个 cloud 点 md 里面，然后模型在推理的时候想要找东西的时候，它就直接知道这个地图了，它就知道在哪里去找了， 但是真实测试下来，首先它的准确度不会提高。第二个点就是它的 token 消耗会增加百分之二十以上，因为它有这样一个地图了之后，它会迫使它自己去查看更多的一些细节， 但是很多细节呃，其实是没有必要的，它就用一些。呃，这种 graph， 用这种关键词正则匹配的方式其实就能解决这个问题了，它并不能提高这个准确率。但是这个东西适合拿来做什么？适合拿来做你的这些文档的一些地图， 适合拿来做你的一些，比如说在这个项目里面的一些踩坑的点，比如说你有一个错，你每一次用模型来执行，他都要去绕很多的弯路才能执行成功。那么这个东西你应该记下来， 记得是经验，是教训，是他特殊的一些规则，甚至是你的一些工工作流。比如说刚才我们的那个就是你的这个成员，这些成员到底有哪些？然后这些成员的功能是什么？这个东西我觉得才是可以记得。还有就是这个压缩了， 就是手动压缩，这个绘画记录千万千万千万千万有这个重点说三次啊。压缩尽可能都是由你自己选择的压缩，而不是他自动的压缩。这个点非常重要，因为你选择压缩之前，你可以把你的文档沉淀下来，下一次你继续完成任务的时候，你才能拿到这些信息。 呃，例如可以结束一个大任务之后就可以压缩，比如说你上下文快到这个窗口期了，就可以压缩。比如说你有一照上下文的时候，你快到两百 k 或者三百 k 了之后，呃，你就可以考虑这个工作，这个任务就可以收尾了，不要让他自行压缩。 呃，你先收尾，先保留这些上下文，保留这些文档，让下一次可以执行就可以了。然后切切换模型啊。 呃，我建议大家只要是机械的实现都使用这种 sonata 的 模型就有。有条件的话，如果说你用 cloud code 啊，或用 cloud 模型啊，用其他的话，有条件用 sonata 需要理解和规划，比如说 leader 用 opus。 嗯，这个东西呢，反正能用好一点的就用好一点的吧，但是也没关系，只要你写好，然后对这个过程规划 hardness 了解的比较深，你自己愿意多说两句话。其实性能我觉得是没有没有没有，没有特别大的差距吧。 ok， 注意啊，就是千万别中途切模型，他的效果这个成本是很难接受的，除非是对话指出。比如说你压缩了，然后我切一下模型，这个是 ok 的。 呃，比如说你新新开的时候，你直接换一个模型，这个也是 ok 的。 比如说你有个一百 k 上下文了之后你又切个模型，那么这这件事情千万不能干，他 k v k h 是 直接被破坏掉了。还有就是双击 这个就可以消除消息，然后哦 ctrl u 就 可以删除一行消息，然后空空白消息。双击的话就可以会去选择之前的历史记录。呃，它好像现在也，它现在也是有这个。呃， check check point 的， 就是它可以返回你之前的一个版本， 它是有版本控制的，它之前没有，但是现在是有了。嗯，但是我推荐大家尽量使用这个呃 get get 来进行版本控制啊，尽量不要不要使用这个方式，这个方式其实效果不太好，很容易出问题，有时候它就是 ok 的， 有时候它那个版本又是有问题， 然后是使用技巧，尽量大家去做的时候，你直接问它这个东西是什么？这个，呃，子智能体是什么？你有几个子智能体？ 子智能体是怎么样弄的？然后 task 它现在是有 task 的， 就是它会记录在它的这个，呃，那个那个工作目录，不是在你的这个工作目录，在它的一个工作目录下，它会去把任务写成这种 task 的 文件， markdown 的 文件，然后再去按照这个文件的这个指令进行执行。 同时它也可以让这些子智能体啊，或者 team team 成员啊这些它会去读这个 markdown 的 文件，它就可以知道。呃，按照这个文件来进行执行，就不像之前用的 to do list 的 方式，它是没有文件沉淀下来的。 呃，但是这个有有有点问题啊，它就没有在你的文件夹下，但是我们按理来说这些东西都应该在我的文件夹下，所以说我的那个 team team creator 也是跟这个做了一些优化的。它这个 task， 呃，我是让它只写一些聚焦的。呃核心的点摘要，然后引用一下我们现在的这个这个文档，这个文档里面具体的这个。呃 plan， 具体的 task plan 可能会写得稍微详细一点， 这样的方方式，这样的方式的话又没有破坏他们自己调试好的这种提示词，然后效果也还蛮不错的。然后他下发任务啊，这种 task 的 内容也会比较短一点，所以说效果还是蛮不错，因为我们写的提示词啊，写的一些指令其实是没有他们写的好的，不要跟他们的指令有冲突， 不要有矛盾，会造成模型的困惑，你可以让它稍微改一下，比如说 test， 你 不要让它写得特别复杂，特别详细，你就指导它引导回来你的这个文档就可以了。还有就是 这个 skills， skills 大家配的时候可以配到你的这个项目文件夹下面，也可以配到这个。呃。用户级别，就是它可以在全局都使用这些 skills。 呃。这个 skills 就 不详细说明了吧。 呃。一会一会给大家最后讲一下我这个。呃。这个 teamwork 的 时候。呃， team cici， team quitter 的 时候。呃，给大家讲一下这个 skills 大 概是个什么情况，因为现在已经非常长的时间了。呃， 另外一个点，如果解决不了这种特别难的问题，因为很多时候我们还是会有一些问题。呃。解决不了的，可以直接用这个 codex 的 五点四的模式，直接用这个最高的推理性能的模式，或者直接起一个 opas， 你 把它这个思考作用调到最高， 基本上都可以解决，因为我我们的项目其实没有没有那么深度了。呃，但是绝大多数的项目都没有那么深度，但是很大的问题并不是说他解决不了，而是他掉进了这个局部追优，他爬不出来了。所以说很多时候你的这些文档，你一定要跟他说一下， 你不要去查看这些文档，或者说不要按照之前的文档来思考可能是错的啥的，让他自己来思考，自己去做推理，这样这样也是 ok 的。 然后就是插件的问题。呃，有两个比较好的插件，这，这是有点分开的。呃，第一个插件就是上下文占比的一个插件，比如说这个，呃，我，我的一个可以看到 我的模型，然后 contacts 他， 但是他这个不是特别精准，但是大概是没太大问题的。还有他调用了什么工具，看了什么文件，然后，哦，他都会写在这，甚至这，这个，这个是另外的啊，这个是，呃，他的这些 team team 员工，你可以这样 shift 上下键去切换，这个都没啥， 这个东西非常重要，就是上下文你只有看得到，你才能控制你的。呃，控制你压缩的这个时机啊，这个太重要了啊，大家，大家一定要注意注意这个点。呃，这个模，这个插件叫做 cloud hold， 大家自己去看一下。然后就是任务完成的一个通知插件，这个也是比较重要的。 呃，通知插件，我这个这个是没打开，大家也可以直接搜吧。 cloud no notification go， 这个插件其实蛮多的，就是他完成了，他给你回一次消息，他会在右下角提示一下，这个还是挺挺挺好用的，因为我们做做这个，呃， web coding 啊，或者开发啊，这些都会并行进行开发。几个任务进行并行的时候，往往就忘记了我开了之前的一个对话，下一个对话怎么怎么怎么样了， 但是，呃，你有了这个东西的话，他就会提示你。呃，嗯，但是我用了这个 teamwork 之后就没有那么大的问题了，就是，呃，我基本上都是在那个 teamwork 里面直接进行并行开发，这样的话我只用控制一个，然后就算很多任务他是完全不相关的，呃，他这个 leader， 这个 oppas， 他 都能去解决，去去分配这样的一个任务， ok？ 嗯。这个东西， 呃， team skills 就是 我开源的这个项目，我们先看这个 open ai 的 harness engineering 这篇文章吧，然后再给大家讲一下，详细讲一下我这个 skills 它是怎么样配置的。呃，这个开源的， 大家如果听听不下去，也可以直接用它，这个就是一个 skills 配，配置上去了之后，你直接问 cloud code 也可以， ok， 呃。先说一下这个 harness engineering， 这里面有非常多的 经验是值得吸取的，而且值得非常多遍非常多遍的去读，我一共是读了，呃，就是给大家分享，都分享了三遍，所以说我读了非常多遍。呃，当你没有用好这个 ai 编程 web coding 的 时候，你会发现，哎，他讲的好像有点道理， 但是你用了一下之后你就能想起来，哎，他这些逻辑在指导你可以进行编程，特别是完成一个比较大的项目，或者说一些大的项目进行编排的时候，你要把他因为之前的一些项目他可能 都没有文档，那么你应该想一想，呃，怎么样用这个 harness 去改造这个项目，让后面的这种，嗯， cloud code codex 它能继续地去完成任务，然后哈你就自己慢慢会有意识或者思想去放进这种 ai 编程，然后最后再读一遍， 你可以结合他的一些思想和你项目，因为你已经做了 web coding， 你 项目里面的一些文档设计，然后第一步应该怎么做？第二步应该怎么做？然后你再让 cloud code 或者说 codex 或者任何编程工具去看一下这篇文档， 这篇文章，然后再读一下你之前的这些文档，让他给你一些优化建议。我们有哪些东西是没有做好的？比如说文档没有写好的，比如说 他的这个 c i 检查是没有写好的，你有哪些做的欠缺的，他会告诉你，然后你告你跟他说怎么样去优化，然后让他去给你做优化就可以了。 ok， 我 们直接打开这个 这个文章吧，这个文章也还再次给大家详细的再读一遍，因为这个文章太重要了，不管是所有讲 web coding 的， 或者说最近两个月都绕不过去这个 harness engineering， harness 约束。 ok， 这个是 open i 他 们发的这篇文章是由一个团队，他们里面有一个团队是专门去构建一个内部的一个软件产品，一共是好像是五十万行代码， 好像是五十万行代码，然后是没有用一，没有手写一个代码的，然后大概只用了十分之一不到的时间，直接就完成了这样一份工作，然后是由人来进行指挥，然后都是由这些智能体进行执行。哦，是一百万行代码， 然后还是非常非常离谱啊，大概有每天处理三点五个 p r 太太离谱了，他们用了五个月，五个月，然后一百万行代码，一百万行还是非常非常离谱的事情。 ok， 他 们是从一个空的代码开始的，他们当时都只是使用的 g p t 五，然后都没有五点四，没有这个 cloud o p s， 他 们用这个 g p t 五和这个 codex 来进行使用的。 可以讲到，首先这是呃它的一个工作吧，工作量吧，然后哦它们的核心理念就是不手写一行代码， 然后工工程师的主要工作偏向了系统架构以及如何撬动这个呃 ai 编程。 cloud， 呃，不是 cloud code codelex， 它的一个杠杆作用。 然后早期的时候他们是比较慢的，跟跟跟我的那个过程也是很很相似啊，我跟他们的过程很相似，因为我基本上呃我开发那个我的这个项目十万行代码大概是用了半个月多，但是前面 一个星期到十天是非常慢的，甚至都是在呃跑一些弯路，都是在构建这个 cc team creator 这个 skills， 我我想让他去完成，去结合这个这个 team 模式，然后去结合呃这些 harness 的 机制，然后去配合呃现在很多这种子智能体的一些呃逻辑或者定义， ok， 嗯，首先他们就又说了一下，然后他想要呃呃去完成这样的一个目标，他先要把它做了拆解，其实也就是呃这些角色了，就是 team 模式的角色设计、代码审、测试等， 然后去让这些智能体分工去完成，因为这些东西它是完全可以拆分的，比如说设计它是可以拆分的，代去完成，代码也是可以拆分的，评审也是可以拆分的。去呃分割这些角色的原则就是这些东西是可以模块化的拆分，但是千万不能是 比如说我这个，这个又要做，呃，比如说呃一个功能让多个角色去做，这样是不 ok 的， 因为它上下文无法拆分， 所以说它会消耗掉特别多的上下文，然后智能体和智能体之间的沟通成本也会非常高，并且最大的问题是它们之间沟通是有信息损失的，所以说这样这样这样是不太好的。 ok， 嗯，他们发现人类这个，呃，我们工程师总是介入这样的一个任务，呃，究究竟需要什么样的能力来让这些智能体可以对这个项目进行清晰可读，而且又有一些约束的执行？ 然后，哦，他们基本上是按照这个系统提示词啊这些呃去去给这个系统进行交互，跟这个 codex 进行交互。最开始他们是使用的这个呃这个死循环的方式，但是，呃后面他们慢慢就是采用了这种标准的一些开发的流程， 然后去不需要人工地去介入到这个 c o i， 它们也是使用了这样的一个循环了。嗯，这儿我感觉都有点有点乱，没没必要读得特别详细啊。呃，其实最重要的是后面的这几个要点。首先是要提高这个 cloud code， 呃，不是提高 cloud code， 是 提高这个应用 cloud code 的 可读性，你必须要让这个应用不管是在执行的时候，还是在运行的时候，还是在测试的时候，它都要能详细看到这些。呃，这个应用它的一些内容，像我们之前的一些史山代码，呃，它大多都是， 呃，我们只需要看它结果是什么样，很多日制啊，我们其实是写的不详细的，所以说在现在这个阶段它其实是不 ok 的。 比如说它这个进行测试，它是一个标准的前后端啊。呃，如果大家不是标准的前后端，是比如说一些应用，比如说有些甚至应用都不算，呃，你尽量使用这种打包的方式，直接把这个前端直接打包成应用，或者直接使用这种 c o i 的 方式， 呃，去测试这些嗯功能或者执行你 c o i， 到时候你再打包成一个前端这个不值钱的东西， 这个你到时候去慢慢实现就可以了。你直接把先做 c u i， 不要不要去做什么前前后端一起或者怎么怎么样，把它全部弄好，先做 c u i 功能全部实现了之后你再去实现其他的东西。我们先详细看一下它测试的这个机制是什么样的。 这是 codex， 然后这个是这个浏览器的开发的工具，然后这个是应用，其实是先清除工作台，它会清除一下工作台，然后我去呃，去大概看一下这个的一个状态是什么样，然后去去操纵，呃这个应用， 去操纵了应用之后，他可以看到这个应用的一些内容，日制，然后截图，呃之呃操作之后的截图，然后他拿到这些信息之后就知道哪里出了问题，然后进行修复重启，然后不不停的循环，直到完成任务。其实我们我的这个项目也是这样的一个流程， 然后就是，嗯，他的一些核心点就是必须要有非常详细的日制系统， 可以看到他们是一共用了三个日制系统，因为我对工程经验不是特别足，所以说，呃，他具体的这些系统我可能不是特别了解，大家如果知道的应该还是比较那啥，但是无所谓，你让他写好日制，他自己会给你写好， 就是你哪怕是你之前项目没有写好，你只要把呃这种文档全部构建出来了之后，你就说你给我重构一遍，把这些日制全部加一下，他自己会给你加 我的之前的那个项目也是基本上全部写完了，写完了功能，大部分功能都已经写完了，然后又用的这个呃 team 模式，然后把整个文档，整个这种日制什么基本上像像重构一样把它全部重构了一遍， ok。 第二个就是它的一个记录系统，因为你要让 cloud code 它能 一遍一遍的衔接之前的任务，因为呃模型的上下文是有限的，它清除了上下文之后，它能衔接上之前的这个工作，继续去完成任务。那么你的文件 和文档系统必须要写得非常详细，它们之前是使用把所有东西都塞在这个 id 的 点 m d 里面，当然这个刚才也说了，这个是一个呃非常错误的 思想或者做法，他要的是给 codex 一 张地图常态加载在这个模型上下文里面的是一个地图，不是一个一千页的说明书，这个是毫无意义的， 因为呃，首先就是呃所有都重要的话，那么所有都不重要。哎，这，这不是，这是所有都重要的话，那么所有都不重要。你把所有的条件都写的非常详细，他一次性他是他的那个注意力是没有那么多的，或者说他其实跟我们人一样，你人 能能注意到那么多东西吗？那么多重要的点吗？肯定是不行的。然后就是其实这两个东西是一个东西啊，就是他会错过很多约束条件，他会忽略掉一些东西，其实跟你那个 skills 放多了也是一样的。第二个点就是这个东西会上下文腐烂，然后哦就是很难核实， 这个漂移是无法避免，但是这个东西跟跟他的 md 文档没没太大关系啊。这这两个东西，呃，这个东西核实和这个成就， 你应该是他想要说的是你要做一些维护，可能很难维护，因为这些 edit 点 m d 文档它不是热加载的，它是必须要重启之后它才能去更新这个上这个文档，所以说，呃，你你没办法去动态的更新这个上下文里面的内容，这也是不 ok 的。 然后他们就把这个文档也列了一下啊。呃，首先文档，这个是设计的执行的文档，这个是生成的文档，这个是 对齐的一些文档吧，然后这些参考的，但是我个人感觉它呢，这个设计的并不是特别好，我觉得按照我那个方式可能会好一点，就是按照角色进行划分，然后角色下面它又会划分成这个 每一个任务，一个文件夹，文件夹下面又结合了这个 plan with fields， 它的这个 skills 它有有有进度，然后有发现有这个任务。三个 md 文档，然后它维护这三个 md 文档。虽然工程嗯量工作量是增加了，但是它会更加详细，然后完成一个项目的时候，它也有迹可循。 ok， 但是它有个比较好的点哈，就是它的这些呃文档里面它是有一些标准的，比如说，呃你的一些 接口，你的一些 api 端口是不能进行改变的，如果你要改变，要增加你这个文档必须要呃，改变增加，所以说这是一些规范文档这个东西是不能变的。呃，这个东西应该也要写在这里面，而且对整个项目它的一个大致的介绍，大致的说明 也要有一个这样的文档。我这个也是有这样的一个文档的，就是对专门做了这样的一个文档，但是他不没有像他这样又在里面拆了，因为我在是按照角色进行拆分的，这就没啥。 呃。编，编码和缩影，这些编码和缩影应该放在这个点，这个 a 键的点， md 文档里面，这个文档的一些结构目录都应该放在那个里面。 ok。 然后就是可读性，也是最最重要的，就是你一定要你的代码。呃，和这些反馈是要跟 cloud code 进行。嗯嗯， 强强交互的，所以说一定要有可读性，不要是全部代码，因为代码它的行数和内容都比较大，但是你文档它的内容，嗯的信息密度就会更高一点。呃， 就是可读性啊，他会，如果你的可读性不高的话，他可能就像三个月入职的新员工一样一无所知，所以说你必须要把他写的比较好，然后，哦，你新 新的一个 codex 其实就是一个新的员工，他应该去读哪些文档，他要他要知道，然后他去复回去，去抓到之前的上交文，然后才知道怎么样去继续去完成任务。还有一个点就是规范和架构，这个东西我感觉还是非常重要的，因为光是文档文档他其实只是一个提示词， 但是你想要让他按照提示词的要求来，对于现在模型来讲还是比较难的。那么你应该怎么样去限制？你应该去做一些脚本，去 严格规范一些边界，严格去规范一些内容，比如说你的接口不能有多的接口，你不能有多的一些呃类或者库，你不能引用其他的一些类库，比如说你不能，嗯，去 去调用一些莫名其妙的 api 啊这些，甚至你的这种文件它的长度不能超过八百行，或者不能超过多少行。这个你应该写一个脚本来专门对你项目里面的所有内容进行检查，这个是一个固定的规范，这个是必须要做的， 如果你没有的话，你很容易这个爆炸，你的这个技术债会会会会会越堆越多，只有有了约束之后，你的架构才不会漂移，因为 他很多模型他上下文没有了之后，他通常就会去干一件事情，就是乱编一个新定义，一个变量，新定义一个命令，这，这是非常重要，非常经常的一些事情。经常很多的时候就是， 哎，这个里面有一个变量，那个里面又有一个变量，但是很多时候你你是完全不知道的，他可能报错了之后，他又去修修修修修修改改，然后把两个又又斗起来了。但是他很多一些技术债啊，很多发散的、离散的、漂移的，这种变量还是保留在那。如果你没有一个检测的脚本， 那么让大模型自己去发现，他其实是比较难发现的。嗯，第二个点就是他们的这个代码 不一定是符合人类的偏好的，因为我们人可能会想的是怎么样写出优美的代码，怎么样写的稍微简单一点，能用一些现成的库，我们就用直接用现成的库，但是对他们来讲不是这样的，只要能跑，你就不要管，不要管这么多，而且他会更加习惯去 自己实现一些稍微简单的一些库，没没必要去用一些这种现成的库，因为很多时候一些库他是要更新的，而且很多库他是比较新的，在模型的大脑里面是没有的，他如果能自己实现，你就不要管他，你就让他自己实现就行了。还有一个比较大的 点，也是我觉得很重要，为二重要吧，去吞吐量改变了合并的一个理念或者叫部署的一个理念， 就是由于现在的 ai 整体，他去编程或者说去修复问题，他是很简单很快的。那么你在合并或者说去暴露你的服务，公布你的部署你的服务的时候，你就没有必要像之前一样去做非常非常非常严格的检查。 当然当然这个风险敏感度大家要自己进行评勾评估。而现在要做的是你怎么样让这些报错能快速的反馈回来，这件事情非常重要。 我，我的一个解决方案就是在这个项目里面，我其实是让它一直活活跃着一个智能体的， 他不停的在分析这些用户的一些行为，当然我用的是非常便宜的一些模型啊，呃，甚至我我我我是采用的这个 fork 的 方式，呃，我会在这个用户聊天完了之后，我会 fork 一个分支出去，然后再发一条消息问一下 这个智能体他之之前我们沟通的时候是否有一些不好的点，然后我会把它整理成一个结论或者结果。呃，我觉得要做的一定是 一定是你要快速的拿到这些反馈和结果，而不是说你要让他做到尽善尽美，没有没有那个必要，你要拿到他们对话会画的一些结果，比如说主要的问题是否有研究价值，我现在唯一要做的就是把这个东西测试出来的这些问题，我会让， 嗯，这个智能体去分析一遍，我会把它所所有聊天记录拿到，拿到之后让智能体它自己去分析是否存在一些问题。比如说你的 skills， 比如说你的 skills 要沉淀一些经验，比如说你的 skills 的 脚本是否要改，比如说你的 skills 是 不是要新建一个新的 skills？ 是 这样的， ok， 呃，这个就不继续看了。呃，再就是继续看一下这个项目， 然后智能体生成实际上意味着什么？就是产出就代表着所有的都是由他自己进行产出的，然后代码与测试。 ci 配置，我觉得这个 ci 配置非常重要啊。就是，呃，其实之前，呃如果是小的一些项目可能不需要做这种 ci 的 检查，但是 现在这种 web coding 你 必须要最开始的时候你就要定义好这种检查的这些规范，然后每一次呃去执行出来都要做一次检查。 以前可能需要非常大的项目他才会配置上这个东西。然后内部开发者的一些工具，比如说那个，呃， playwrite 啊，我是用的 playwrite 啊，他是使用的这个，呃，谷歌浏览器的那个开发者模式有一个工具，但是这个这个都差不多了，我用 playwrite 的 用着也 也还算可以的。我之前安装了那个谷歌浏览器的开发者模式的那个 two， 其实没有没有特别大的区别，我，我是这样感觉的。 然后就是不断提高的自主水平，当你全部实现了之后，新提出来一个任务的话，你可能就是一个 hook， 呃，我新提出来一个问题的话，你就是一个 hook， 把它发发给这些团队就可以了， 然后他自己就可以进行执行了，然后我们还是继续，时间也是非常紧了。然后我总结出来的一些经验吧，或者我觉得最重要的几个点。首先第一个点就是他的文件文档，这个文件夹，也就是我刚才给大家看的这个文件夹下面他是一本书， 树状结构的书，最容易发现的东西就是一些摘药并引用细节的这个具体的文档，越容易发现的就是越越是摘药的东西。然后 并且这个文件夹下面他一定是有互相引用的，不能有孤立的这种文档。孤立的文档其实没有特别大的价值，除非你这个孤立的文档，其实其实按理来说这些就不能有孤立的文档，你的 一定是有某一个这个引，所以是引用这个文件的，它一定是有个摘要的，哪怕它这个摘要非常简简单。 呃，还有就是文件的行数不要过多，如果过多的时候，另外一个文档引用的时候一定要标记具体的行号， 包括我的这个智能体这个 team 员工的时候，他下发任务的时候，他很多时候都是直接把具体的行号直接下发了的，要不然的话， 这个子智能体或者 team 呃的成员，他又得去全部读一遍，这样他的上下文也会消耗特别多，而且对之前的一些呃任务内容其实没有没有特别大的帮助，没有没有意义。 然后就是日制尽量要详细，日制一定详细，你把它记录下来，哎，模型它是不会去傻傻的全部读的，它自己会去用正则匹配去搜索的，所以说日制尽量详细，哪怕你就设置一个， 设置一个那个命令开关嘛。呃，你生产的时候你可以关掉，然后你调试的时候把日子尽量且详细，尽量把每一个命令，甚至呃这种模型的 point 都可以把它打印下来。 然后就是小众的一些库，如果工作量不是非常大的，就直接让 ai 自己实现，因为呃你如果需要引用一些 ai 自己完全不知道的库，你还得给它搞一个 skill 或者搞一个文档，它开发起来才不会有问题，要不然很容易就有问题。 然后就是呃不要聚焦于前端和这种尽善尽美。呃，我认为应该聚焦于这种功能的实现以及 coi 化，因为 只有 coi 化了之后它才能被 ai 所调用，那么你才能把它 skill 化，然后 skill 化了之后你才能进行调试和监控，以及呃呃，你怎么样开发起来，这样才能自动化？还有 ui 的 一些细节，细致末节是肯定要被淘汰的。 再就是模型的吐出率让现在的这种项目模式是转变了，一定是上线报错或者说反馈快速迭代， 但是唯一就是你需要收集反馈和优化的这个检测系统要要做的好一点，然后尽量让它存活在你的项目中，让它一直活着，让它自己能能自己做修改。当然你最开始可能是有你人， 但是你的，比如说你的接受率都达到百分之九十以上了，你就可以了，可能你每天 review 一下，或者这样就可以了。 再就是一个补充，呃，想要上下文不丢失文档，尽量做详细。我的那个代码里面我之前 review 了一下，大概是在 呃百分之三十左右的这个文档，但是可能有点多了。呃，但是我个人认为这个代码量和文档量的比例尽量也不要低于百分之二十以下，尽量让他多一点。 ok， 这也时间太长了。接下来就是我开源的这个 team skills， 就是 怎么样去创建这个 team 模式。呃 呃，很多人人用这个，呃这个，这个终端会效果会显示更好一点，但是我是 windows 的 习惯了，然后用这个 shift 上下切换，我觉得也是可以的，没没什么区别。 然后呃第二个点就是角色不是拆，拆的越细越好，要平衡。因为呃，之前 s o p k 他 们也发了一篇文章研究表示，呃，这个上下文它并 不是一定要用这个多多的模型或者多的角色或者多的子智能体去做拆分的，而是呃他一定是工程量或者说上下文可以分开的，你才可以拆分 你。你可以这样讲，如果你是一个智能体，你要做某一件事情，然后另外一个智能体，他要做做另外一件事情，这这两件事情你们之间如果沟通 几句话就能沟通，或者沟通一两次就可以搞定的，那么就可以拆。如果你们之间要协同合作来去完成这个任务，嗯，协同的非常多的话，那，那这个东西就不能拆， ok， 呃，但是也有一个特点啊，就是，呃，这他的这个文档里面其实也写了他的这个上下文， 嗯，这个陀刻消耗用 team 模式会非常多，但是我个人感觉他用 team 模式消耗的反而是比他用子智能体的方式要消耗的更少的，因为子智能体的方式，他每一个子智能体他都是重新去去激活，去拿上下文的，所以说， 呃，它的效果，反而这个托肯消耗会更高，而且，呃，而且它效果不是那么好，因为很多上下文是可以附用的。还有一个点就是用 team 模式的时候，它有一个特点，就是 leader， 它知道了它有这些团队角色了之后，它才会自己主动的去拆分 任务，如果它不知道，你只是一句话告诉它，它是不会主动拆分的。这就是一个潜在的问题。 很多人可能会误解，呃，为为什么这种 team 模式会更好？因为他会主动的去拆分模块，主动的去拆分工作，这个点非常重要，因为大家都知道，呃，我，我要做一个大的项目，要拆分模块，拆分什么什么东西，但是， 呃，你去 web coding 的 时候，往往他就你让他去完成这个任务，他是不会拆的，他是不会拆模块的，是这样的一个逻辑。 ok， 我 们也来再看一下我的这个开源项目，这个开源项目大家如果了解了之后，他可能 不是 cloud code， 它也能做，它也能运运行，因为很快应该 codex 啊这些，呃， open code 啊这些它应该都会支持，支持这种 team 模式。 呃，我们也是在开源一个 team 模式，这个 cloud code， 呃，和这个 codex 还有 gemini 这些，看能不能使用使用这种哦 群聊的方式来进行协助，因为群群他这个 t 模式其实就是一个群聊的方式，然后这个 leader 是 可以看到群聊的所有内容的，你也可以看到群聊的所有内容，你可以直接发消息， leader 也可以直接收到。然后但是员工，嗯，这些子智能体他就只能被艾特的时候才能看到，而且他们互相可以艾特，是大概是这样的一个逻辑， ok， 呃，我们首先来看一下这个项目吧，这个项目大家知道了之后，了解了之后，你们自己就不需要这个 skills， 然后并且想要用好，我 虽然他也可以直接用，但是想要用好的话，一定还是要读一下的，因为 team 的 这些成员啊，他的逻辑啊，这些工作流程啊，还是得自己去了解的。 然后这个 skills 是 一个比较标准的文档，然后有原数据，我这是 review， 呃，这 preview 啊， 呃，原数据可以看到原数据，然后下面就是具体的一些写法了，然后是这个是参考的一些文档，这个是脚本，这个脚本就是 ci 的 一些脚本，就是专门去检测你这个项目里面 的文件内容啊，这些有没有超过什么东西啊，然后命名名啊这些，但是这个也是属于一个模板吧，他不能不能是直接拿去用的， ok， 我 们来详细看一下。首先，呃，这个这个原数据就是什么时候应该触发，但是我是专门去提醒了他一下，要看这个 skills 的 时候必须要自己看，不能起一个子代理来看， 这这个很重要，要不然他用子代理来看，子代理去看一遍这个 skills 的 话，呃，他在告诉这个主智能体的时候，他是有信息损失的。而这里面你要想要做好一个 team 的 话，你这个是要让它全量读的，全量读它细节才知道它才能做好一个比较好的一个 team 的 配置， ok？ 呃，为复杂项目是创建这样的一个 team 团队，首先第一个开始之前必须要直接读取所有的参考文件到上下文中，这个就是我刚才说的这个东西。然后流程，第一个流程是要检查你这个项目里面是否已经有了这样的一个 plan 的 文档， 而这个文档如果有了的话，他就不用继续去创建了，如果没有的话，他就会会去创建这样的一个文档，然后一会会给大家讲一下这个文档里面有哪些角色，角色下面应该是怎么样分布的？呃，首先第一第一个， 呃，应该是按照这个理来，如果存在就读取这个东西，然后获取之前已经有的的，用团队的一些角色定义以及这个项目的一些上下文 扫描，拿到了之后恢复这样的一个上页文。如果有，有之前有这样的 team， 如果你创建了之后是有一个 team 的 配置文件在的，它就可以不用详细的去看这些文档了，这样的话就能节约节约这个 talk 嘛， 然后它也会检查一下，如果这个 skills 它有有更新的话，它也会去更新这个 team 模式，它会去看。 然后第二第一步他就会去问你，你的目标和需求是什么？沟通，跟你对稍微对齐一下，然后给你介绍一下这个的方式是什么？你的团队的成员，然后分工，因为他一共是六个角色，你也可以不用，六个角色也可以，但是我觉得这六个角色不管你在开发什么的时候 都是可以使，都可以使用的，所以说都还是蛮必须的。当然你也可以去借鉴其他的一些。呃，角色，再把它加进来，这些都是可以的，其实都是很简单的，很灵活的。嗯， 是用什么场景？是用这种稍微比较大一点的项目，其实你改小需求用这个方式也很好了，因为，呃，你可以先让这个去解锁一下，去研究一下这个问题怎么样去修复，然后。呃，又可以开发，然后又测试，然后又审查这个东西我觉得不光是大项目，就是小小项目或者一些小 bug 都可以。 呃，我觉得这个，这个这个东西可以直接删掉，因为你只有这样做了之后，呃，你才能把你的文档一直维护着，要不然你不维护你的文档的话，后面就会有这种技术债啊，或者对不起的情况，一定要还是都都得做吧。 然后推荐的一个团队的配置。呃，一共是六六个子智能体，或者叫六个员工，一个是后端开发，前端开发，探索研究，还有代码的审查，一个管家。呃， 这个后端前后端开发就是使用的这种 t d d 的 模式，也就是最近比较火的这种子智能体的一个配置模式嘛。呃，这都是借鉴了一些一些项目的，可以看到。哎，之前这个是直接看 skills 了。呃，我还是觉得还是要 read me 给大家看一下。 呃，我们是借鉴了这个，嗯， plan with 这个 fails， 呃，它是一个文件的形式，但是这个文件的话，它只只有三个，但是我是让每一个，呃，这个子智能体它都有三个这样的文件， 而且每一个这个任务都有这样三个文件，虽然它的工程化会更多，但是我现在目前用起来的话，它效果会更好。因为你稍微大一点的项目，你如果只有这三个的话，它这个文件里面会非常大，非常的恐怖，所以说其实效果是不好的。 ok。 再就是这个 anything cloud code， 这个是黑客松，它的，它这个三个专家，十三个专家智能体是拿来做了借鉴的。还有这个这个 t、 d、 d 的 模式和这这两个结合起来去构建了这样 六个角色。再就是 harness， 再就是 esoteric 的 harness， 它这个 esoteric harness 跟 open code， open ai 的 harness 有 点呃不一样的，重点是在于 它这个更强调的是，呃，去去去，去审核之前的一些内容，审核之前的，呃，这个效果好不好？比如说前端呀？呃，还有就是它希希望的是这些角色 team team 员工和这个 leader 之间有沟通。 之前我是没有没有在其他地方看到这些员工，他会多次沟通对齐需求。不光我们人应该跟这个卡洛德对齐，他员工和这个 leader 之间下发任务的时候，他们也应该多次对齐沟通需求之后再去完成。这个也是一个比较重点，但是这个跟模型还是很大关系啊，我定义了之后，像卡洛德这些卡 洛德的模型效果都不太好，呃，我用用用 g、 p、 e 的 模型，反而效果会更好一点点，然后呃这个工作流程啊， 人搭建，搭建一个团队。呃，他了解了这样的一个内容，然后推荐几个智能体，然后创建这样的一个项目的文档文件，然后会把这些文件放进去，生成一个 cloud 点 m d 的 文件，这个也是弄好 然后就开始并行，其实是串行生成所有的智能体了，因为这个 team team 模式它是串行的，然后要把这些配置的一些内容全部放在一个文件夹下面，下一次的话可以附用。 再就是协助了，就是 leader 和你进行沟通，沟通了之后他通过这样的一个呃 message 去下发任务，首先去探索代码库，或者说去研究，然后出来了过程，呃出来了结果，然后会给这个 leader 看一下，看一下之后他会给出一个方案，方案可以跟你进行对齐沟通，然后他去下发这些任务， 最终完成了之后审查，审查了之后用这个端到端的测试，测试了之后再哎去做部署，或者进行这个管家的收尾。 ok， 下次回来的时候直接读取那个这个 md 的 文档，就可以直接复活之前的一些呃这种角色，并且这些角色他都会自己去看他的这个文档，他对应自己的文档，然后他就知道我应该具体从哪里继续完成，然后我应该具体完成这个任务应该放在哪， 然后实战的一些演示给当年刚才也给大家看了，安装这些都没有啥，这个你自己自己把这个 skills 直接复制，复制到那个，或者你直接把这个项目直接给 cloud code， 它自己去会去去告诉你怎么样去配置， ok， 呃，我看还有什么。呃具具体的还是得给大家讲一讲。呃具体的这几个角色， 然后推荐的原则，角色不是越多越好，这些就是一些原则，应该怎么样去配置这些角色，然后它会通过这些角色去给你推荐。当然我我是推荐大家，如果 token 不是 太紧张的情况下，全部把它加载也好，我觉得效果会更好一点哈。然后就是 非软件标配，呃，我我觉得它这个 team 模式不光是可以用用于这种代码开发， 还可以应用一些正常的，比如说自动化的工作流。我之前也是让他给出来了这样的一个去做了一个工作流，我直接让他读了一下这个 teamwork， 然后他自己首先他会根据这些原则新定义一些角色， 然后这些角色他就不是什么前后端的开发了，他可能就根据你的任务来自定义角色。这个东西我觉得还是非常重要的，而且非常实用的，这个东西他可以可以跨越的，他不不是只能用在这上面。 第二步就是跟你进行决确认，第三步就是创建这个规划文件，跟你确认了之后他叫创建规划文件，首先就是这个项目他应该叫什么？第二个就是呃， 他主智能体 leader 他的一些主计划，然后 found 这个团队级的汇总，然后进程工作日期，然后就是架构的一些描述决策，还有就是这个文档 系统的架构，前后端 api 的 定义，这个非常重要，就是 harness 那 个借鉴的一个东西，然后就是这个导航地图，因为这个导航地图不能全部写在 cloud 的 点 m d 文档里面的原因就是 它是要可以热更新，热加载的，所以说这个所以也是要要要要放在这，放在这种文档里面的，然后由这个管家进行维护，然后就是每一个， 嗯，规规党的历史啊，还有就是爱军的名字，名字下面就是他有自己的几个，呃，工作日期，这三个都是有的，并且每一个任务他下面都有三个， 然后这三个是指向这些任务的，而且是摘药的，所以说这三个就不会过于爆炸。如果说每一个这种角色都只有这三个的话，那么你完成大任务的时候，他就会这种每一个文件，所以说他必须要这种任务文件，这就是为什么要这样设计的一个原因。 然后完整的一个角色设计看见没有，这几乎每一个这个角色它都是有这样的一个内容的， ok， 深层 cloud 点 md， 这个就没有啥了。然后消耗 创建团队和整体，再就是确认加压缩上下文，这个为什么要压缩上下文啊？因为这个 skills 它是要全量去看的， 看了之后他会消耗掉。我，我看了一下大概，如果你之前有项目的话，大概会消耗掉一百 k 的 上下文，如果你完全没有，没有没有，没有之前的这个，呃，配置文件在的话，呃， 那么他是要消耗掉一百 k 的 上下文的，所以说如果新建的时候你完全建立好之后，你可以让他压缩一遍，然后避免你上下文里面有一百 k 的， 其实跟你后面的任务是没有关系的，所以说最后一步可以 压缩一下上下文，但是你已经建立了过后，它会有一个角色的点 m d 文档，你有那个文档来做构建的话，它就消耗不了什么上下文， ok？ 呃，这就是一些规则了。然后 leader 的 一些运营指南其实也有些重复了。呃， 这个是 ci 的， 这个就不说了。然后这是文件的一些模板，然后呃 cloud 点 md 的 模板，然后主的这个 task plan 的 模板， find 的 这些模板，其实就是每一个文件应该要写什么？ cloud 点 md 应该要写什么？首先要写这个，你这个 leader 它主要的工作内容是什么？ 因为像 cloud code 啊，它有一个非常大的问题，就是它会忘记它是一个 leader， 它有团队成员。 然后你必须要提醒他一下，就算我写在这个点 md 文档里面，他都经常忘记。所以说，呃，你压缩了之后，最好要提醒他一下，你有哪些角色，你的任务是什么？你的任务是协调他们去完成任务，然后你再给他具体的任务，他可能会效果会好一点。然后下面的 那这个，呃 cloud 的 点 md， 我 估计都还要做一些优化，要不然上下文有点长。 嗯，但是这个，这个不是啊，这个不是 cloud 的 点 md 是 在这上面，但是 cloud 的 点 md 的 文档估计还是要优化的，因为 cloud 的 点 md 它不光是加载到了 leader 上下文，它还加载到了所有模型的上下文，所有子智能体的上下文的，所以说这个东西还是在还要做优化的。还有就是这这些东西了， 还有就是 plan 啊，主主的 plan 点 m d 的 内容，比如说项目名、状态、日期，更新，角色列表，然后一到几句，然后详细的产品定义，再引引导他的一个一个具体的详细文档，然后文档的缩影， 看这这些就没有没有什么了。然后这个是团队的角色参考，这些角色都是借鉴的这个，呃， everything cloud code， 它们里面的这种子智能体的一个提示词的设计方式，然后角色第一后端的开发， 他们都是用的这个 t d d 的 方式啊。 t d d， 大家可以可以搜一下，它就是先先写测试输入和输出，然后再按记，再一点一点的丰富里面的内容。还有这个 review 啊，这个研究者，还有这种 端到端的测试，然后 review， 端到端的测试用的 playwrite。 当然如果你用其他的这种网页控制工具也是可以的。这个是没有没有太大关系，大家也可以详细看一下这个角色定义啊。详，角色定义倒是没有特别特别详细的大，大家可以借鉴其他的一些角色定义，然后去补充这个 skills 也是 ok 的。 还有就是整体入职的一些。呃，模板，就是 prompt 模板，你可以可以可以进行它，它可以按照这个模板进行这个员工的角色的一些定义， 这个就没有什么了，就大概是这样录了整整一百分钟。嗯，总结一下。呃，这个， 呃，我，我开开源的这个 skills 自卖自夸一下，它效果还蛮不错的，就是我，我用着还是效果很好的。呃，而且基本上我我认为是赋现了这个 harness engineering， 嗯，他们提到的应该百分之六十到七十应该是完全赋现掉了，现在可能没有没有办法完全的自动化，但是， 呃，但是想要自动化，你其实就是加一些这种好呃 hock 的 钩子的脚本啊，其实没有没有特别大的问题，然后只要把它上线，上线了之后进行更新，多更新几次，然后验证一下他呃被人工接接受的一个比例就可以了。嗯， ok。 最后最后大家也是这个模型的问题，之前也跟大家讲过，我们有个中转站，但是，呃目前目前是账号，账号效账号还比较少，因为我们自己的好像都不太够用。呃，我最近也是在解决这个问题，大家也可以 呃，也也可以关注我一下吧，关注我一下，那可以可以到我主页去看一下，然后如果能解决的话也可以给大家公布一下，因为像现在的中转战非非常离谱，他们完全不不给你 kuv 的 命中率，或者说完全不给你考虑， kuv 其实用不了，你再便宜都用不了， 而且大概率都是比较贵的，像二十 x 现在能用的应该是在三千美金到五千美金一个月左右。所以说 其实现在的这种偷看的呃率啊，这些还挺高的，就是价格还是挺高的，不管是一比几的比例，他都都还是蛮高的，所以说这也是比较大的一个问题。行吧，那今天就到这。

如果你用 cloud code 写代码修 bug， 可能遇到两类问题，一是不够顺手，如启动慢，重复确认，常用命令来回敲。二是不够稳定，会跑偏，看起来对，但没跑测试常会话越聊越糊。 本文章五十条技巧，按更快和更稳，整理成速查卡，可收藏备用转账。先介绍三条新手友好且立刻见效的技巧， 一、所有任务写清验证方式，如改完后跑测试失败，先修到全率才算完成， 可提升结果质量。二、切换任务，先 clear 清空上下文，给新指令干净绘画加明确目标，处理更快更准。三、 学会回滚，再尝试按一次 esc 停止当前动作，连按两次 esc 或用斜杠复位，回到检查点警号目录。零一，启动更快，少敲命令，少点确认。 零二、终端更顺手，像写代码一样用零三，质量更稳定，装上验证回路。零四、插件与工具，让看起来对并真的对。五、上下文管理干净比常更重要。 零六、并行与分身 work tree sub agent team 零七、自动化越安全，放开手脚要用刹车。零八、提示技巧，把话说到位，少走弯路。 零九、速查清单五十条一句话动作具体技巧，启动更快。一、给 c s h r c 或斜杠点 b a s h r c 中写 l e s c c 等于 cloud dangerously skip permissions， 但要慎用 dangerously skip permissions 二、用康金妮康婷 resume 接着上次进入肯亲女继续最近绘画。 resume 从列表选绘画继续井号井号井号，中端更顺手。三、命令全家内敛跑命令， 如 get status， 按 pm test 命令和输出，直接进上下文。四、 s e c 停止双 s q 或斜杠 win 回滚，但外部操作不一定能完整回滚。五、 control 叉 s 暂存没写完的提示词，插问后草稿自动恢复。 六、 ctrl 加 b， 把耗时任务扔后台，可继续做其他事。减耗减耗减耗质量更稳定。七、指令写清完成标准，如把 a 重构成 b 改完运行测试套件失败先修复，全律完成。 八、直接贴原始数据，如报错、日制 ci 输出等，避免转述丢细节。九、同意问题究竟两次没好，可以重开绘画 井号井号井号插件与工具。十、优先装 lsp 类插件，如 plug in install t y p e， s c r i p t dash lsp at cold dash plugins dash official eleven。 多用 c l i 工具，可先叉叉叉 help 学用法再完成任务。井号井号井号上下文管理 任务切换，先克里尔新绘画加清晰提示更有效。十三、复杂任务用 plan mode 小 任务直接做。十四、 compact 时说明保留内容，如保留 api 变更点，加修改过的文件清单，加当前测试状态。 十五、生成 cloud 点 md 后删掉一半，判断标准是没这行是否会犯错。十六、犯错后让它更新 cloud md。 十七、用 itunes 把按需内容拆到独立文档，井号井号井号井号并行与分身。十八、 worktree 隔离分支并行做事建议并行二到三个绘画，避免同时改同一文件。十九、 用 sub agents 隔离调查研究主会话接收总结，二十多人协同，先从研究评审开始，稳定后再并行，实现。警号警号警号自动化与安全。二十一、 permissions 白名单常用安全命令。 二十二、斜杠三 box 给自动执行，加护栏控制写操作和网络访问范围。二十三、用 hux 自动格式化和拦截危险命令。 二四、认证支付等关键区域人工复合提示技巧。二十五、用爱的文件路径指路，如 srcoslash m i d d l e w a r e 到 t s。 二十六、 需求不清，让他采访你写 s p e c。 cloud code 拉开差距在于建立验证。一个绘画实现另一个绘画 review、 速查清单、设置 cc 别名、 内联跑命令、 esp、 停止、双 esp、 鬼滚等五十条技巧可收藏备用。 cloud code 拉开差距在于建立验证。清理回滚写作习惯， 想更快就减少重复动作和无效上下文，想更稳就写清验证方式，并保留刹车回滚能力。先用最适合的五条体验回不同。

你可能听说过 cloud code， 但觉得它跟你没关系，因为名字里面带一个 code， 感觉像是给程序员用的。其实不是。 cloud code 是 一个通用的 ai agent， 它能操作你电脑上的文件，能运行命令，能上网搜索，能一步步地帮你把事情做完。写代码只是它能干的事情 之一。比如我最近用它做了一个 ai 资讯日报系统，每天早上它会自动去抓取各个渠道的 ai 新闻，筛选、整理深层记，要最后输出一份排版好的日报，整个过程不用我动手，它自己跑完。这还只是其中一个例子， 整理文件、处理数据、批量改图、自动化那些重复的工作，只要你能用文字描述清楚，他就能帮你干。本期视频会教你如何安装并使用 cloud code， 不 需要任何技术背景，跟着做就行。如果你用过科室，可能会问， cloud code 的 和科室有什么区别？核心区别就一个，协助方式不同科室是对话式协助，你说一句，他做一步，每一步都要你确认，你得全程盯着向待一个实习生。 cloud code 的是任务式协助，你把需求说清楚，就可以去干别的事情了。 他自己执行完，你回来看结果就行。向交代任务给一个靠谱的员工。接下来我们来讲具体怎么安装，分成两步。第一步，先安装 cloud code。 对 新手来说，最简单的方式就是用 tree 来装。 tree 本身也是一个 ai agent， 可以 帮你处理那些烦人的依赖和环境配置，而且可以免费使用。我们 来到官网，先点击这里下载安装 tree， 装好以后打开它，在对话框输入帮我安装 cloud code。 tree 接着会自动帮你装好，中间可能会弹出一些确认弹窗，点击确认就行。怎么验证安装好了呢？打开终端，输入 cloud 杠 version， 如果能显示版本号就说明安装成功了，然后再输入 cloud， 能看到主界面就对了。第二步，装一个格式化界面，原生的 cloud code 是 在终端里面用的，对新手不太友好，推荐在 vs code 的 里面装一个插件界面，会友好很多。具体步骤，先下载 vs code， 然后打开它，点击左边的扩展图标，搜索 cloud code， 点击安装，装好后点击 cloud code 的 操作界面了。接下来我们来讲怎么配置 cloud code 的 ai 模型。 cloud 的 扣就像一双手，它需要一个大脑，这个大脑就是大圆模型，所以装好之后你得给它配一个模型才能用。有两种方案， 第一种方式是订阅制，直接订阅 cloud 的 官方会员有三个档位，二十美元一个月，一百美元一个月和两百美元一个月，主要区别就是使用量，订阅之后登录账号就能用。不过最近 cloud 的 订阅分号比较多，如果不想折腾的话，可以考虑下面这种 a p i 模式。 a p i 的 来源有两种渠道， 第一种渠道是官方 a p i， 比如国外的就像 cloud openai， 国内的就像智普 mini max， 去官网注册充值就能拿到。第二种就是第三方中转一个账号，能用多种模型，支付方便，有些比官方还要便宜，但稳定性就具体看平台了。购买 a p i 后，你会获得 a p i key。 p i p 就是 一长串字母，你在平台充了钱，平台给你一串 p， 你 填写了 p 以后，它就知道该找谁扣费了，用多少花多少更灵活。那么怎么配置呢？推荐使用 c c switch 来管理 github 上面搜 c c switch， 拖到底部，点击 release， 找到适合你的版本， 然后下载，打开后可以添加多个 a p i p， 点击右上角加号。如果你选的是官方 a p i， 比如像是 g o m， 那 么你就在这里 直接填写你的 api key 就 可以了，其他信息都已经自动填好了。如果你选择的是第三方中转站，就选择自定义配置，然后这里需要填写，嗯，供应商名称，供应商名称你就自己去写一个你自己能记住的就好了。然后这里要写 api key， 还有默认的模型。具体怎么填写呢？一般 api 中转站都会有一个开发者说明文档，你直接把这个链接丢给你的 ai， 然后告诉 ai 你 要在 cc switch 里面配一个 api， 然后让他给你对应要填写的信息就可以了。配置好后，点旁边的魔术棒图标测试一下，显示运行正常就说明成功了，点起用就可以。现在你可以打开 cloud code， 输入你好，你是什么模型， 他会回复你，能正常对话就说明一切配置完成了。接下来你可以试着给他一个简单任务，比如帮我看看当前文件夹有哪些文件，按列表列 行，给我一个清单，他会真的去执行，然后把结果告诉你。到这里你已经装好了 cloud code， 配好了格式化界面，接好了模型。下一步建议从简单的任务开始，比如整理文件，总结文档，过程中遇到报错也不用慌，截图丢给任意一个 ai 聊天工具问基本都能解决，慢慢熟悉以后再尝试更复杂的任务。 这是 cloud code 系列的第一篇，后面我会继续讲如何用它来做更复杂的事情。有哪些进阶功能。我是阿西，我们下期见。