agents.md编写方法

专门你们要打用 opencl 做了多引擎的战队的搭建指南来了，前几天我用这四个智能体，也就是我用 opencl 去搭建了这四个 ai 的 引擎，用它来去完成我一些负担任务 发布之后，没想到的是原来有那么多的粉丝，他们也有这种想法催更，同时希望我能给他们整理一下我上期所演示的这些内容的一个文档。那这几天呢，也是一直在整理这个文件，目前已经整理好了，如果大家感兴趣的话，我会分享给大家。这边指南的基本思路也是我来做这个搭建这个 ai 团队的一个 正常的顺序，我是先用来做角色的一个分工，把每一个人的角色所要完成的任务给它先划分出来。然后就是 opencl 的 配置文件，有很多人的配置的话，忽略这个配置文件，其实这一块是非常重要的，有很多人在最后配置完之后，运行的时候出现各种各样的问题，基本上都在这个配置文件里， 有人一上来就配置 skr， 其实我们现在可以看到第三步才到了我们做 skr 配置的时候，这里大家在没有思路的时候可以借鉴我的，不妨参考一下我的这个分配原则， 当然也欢迎大家留言讨论。最后是做一个技术实现，也就是我们把前面的配置好之后，如何在我们的 openclose 点 jason 文件里把它配置出来，当然具体的 jason 文件里面的内容也已经放在里面了。

实际项目中如何使用好 skills roots 多智能体协调呢？今天来做一个示范啊。先看一下目录结构，打开点 tree roots 下的 project roots， 点 md 这个文件，如果没有，可以手动创建一下， 设置这么几条规则，如果用户输入了杠 get， 请减速当前的任务描述并部署到服务器。手动提交不比 get 快 多了吗？并不是啊。 首先 ai 会分析当前的代码，然后帮你设置好要提交的描述，在有必要的时候，它会设置好需要忽略的文件。 甚至你可以告诉 ai 啊，你只想提交和哪些模块相关的功能， ai 会自己分析需要提交哪些文件。那你可能觉得这不也很浪费时间吗？哎，并没有。 get 提交和其他任务啊，是不会冲突的，完全可以变形，你只需要输入一个杠 get， 就 可以去干其他事了，所以反而更快。 回来我们继续看其他的规则配置啊。这里我写了很多规则，是让 ai 持久化记忆每一次对话的详细过程，以后如果有需要，可以让 ai 解锁记忆库啊。 重点是这里啊，我明确要求 ai 不要自己去做具体的任务，只需要做好调度，制定计划。如果涉及到写代码，就调用工程师智能体，让他先熟读开发规范文档以后再进行开发，然后把开发规范文档的链接给他。 开发完以后，调用代码检测员检查代码是不是符合规范。之前不是已经让 ai 按照规范开发了吗？为什么这里还要让检测员再按照规范来检查呢？ 因为写代码需要消耗超长的上下文， ai 经常写着写着就把规范给忘了，所以这里要让检测员根据修改的代码，再去按照规范检查一遍，就不容易出错了。 然后调用图书馆馆长来维护文档。最后是要求 ai 把绘画持久化存储为文件。好，规则里写了这么多智能体，怎么定义这些智能体呢？非常简单啊，你只要告诉 ai， 请按照项目规则帮我创建相关的智能体就行了。 好，我们看到 ai 已经在点翠目录下创建了 a 整数目录，按照要求啊，它已经创建了四个智能体了。 最后我们验证一下这些项目规则能不能生效啊。现在我向 ai 提了一个需求， ai 开始分析好，然后他调用了 python 工程师写代码，写完代码以后，又调用检测员开始检查好，没问题。 哎，这里检查出问题了。检测员明确指出啊，这里违反了数据管理条例的第五点一条， 因为我在代码规范里写了，凡是涉及到数据操作的，必须用 data manager 这个类来操作。这种项目级的规范， ai 是 特别容易忘记的。这里代码检测员就能给检查出来，因为它的上下文比工程师要少很多，只有规范文档和修改过的代码，所以它就能检查出来。 再往下看啊，违反异常捕获规范。因为 ai 特别喜欢 try catch 吧，所以我严格要求 ai 不要乱用 try catch， 还检查出来了很多其他问题啊，什么代码片段重复，没有封装好啊，存在硬编码类型提示不统一啊，等等啊，这就是多 agent 协同工作的重要性，让每个 agent 都有自己独立的上下文，更专注一个领域，这样工作就更搞笑了。 好了，最后说一下我在做的这个项目啊，我是准备做一个客户端软件，一键下载视频和转文字。我之前也没有做过客户端软件，所以这个项目我会全程不手写一行代码全由 ai 完成，而且是国产免费的 ai。 我 也会持续分享项目上的实战技巧啊， 后续也可能会把项目开源出来，包括所有的文档结构啊，路由啊， skills 的 配置啊，还有 ai 的 绘画记录等等啊，有兴趣的兄弟可以关注一波啊，拜拜了。

今天分享 ai 编程圈超全干货，所有关键信息一次讲透，用得上的赶紧收藏！一、 agents md 它是跨平台 ai 编程标准文件，核心是统一所有 ai 编程 助手的指令，文件名称就叫 agents， 点 md 和存放位置项目跟目录解决指令格式混乱，找不到存放路径的问题。复杂项目还能在子目录建专属 agents， 点 md 覆盖全区规则团队协助，可独立维护。 二、 a j 三 d 的 短板，只解决了指令文件的基础统一，没法管 m c p 服务器配置。不同工具配置格式路径不一样， ai 技能包存放路径混乱，也没有自动化同步机制，多工具切换仍要手动配置。 三、 ruler 的 核心定位 ai 工具配置管理神器，专门补齐 agent 点 m d 的 短板，支持三十多种 ai 编程助手，如 killcode、 class、 coppola 等，以单一数据源统一管理所有配置。 四、 ruler 核心功能一、集中管理配置所有规则 m c p 配置既能包全放在 ruler 目录，不用分散维护，一键同步执行 ruler apply 命令， 自动转换成各工具专属格式并分发，还能按需选择目标工具嵌套规则。复杂项目如猫诺瑞泡，可分层配置字幕路建，点入了写专属规则加参数就能自动合并，自动维护整洁，自动把生成的配置文件添加到点 d t g n a， 避免勇于提交。 五、快速使用步骤一、安装需 no dj s 局安装或一次性使用均可。二、初步化进入项目目录执行，如了 inn 自动生成配置文件夹和文件编辑配置，写入项目规则 m c p 信息等。 四、应用配置执行 rolkefeller 复杂项目加 nested 参训六、试用场景频繁切换多 ai 工具，复杂项目结构，团队合作，标准化配置，搭配 agent 四点 md 使用效率最高。 团队可提交 rolkefeller git 集成脚本，实现自动同步。纯分享无套路。觉得有用，点赞收藏！

如果你使用过其他 ai 编程代理，如 cloud code 或 copilot， 你 可能在这些工具中见过类似的文件。在 cloud code 中，我们使用 cloud 文件来提供项目范围的指令，而在 copilot 中，我们使用 copilot instructions markdown 文件来处理同样的事情。 这些都服务于类似的目的，对吧？因为他们为每个代理提供了记忆和简洁的项目上下文。 它们的不同之处在于， agents md 文件作为不同 ai 编码工具的标准被推广， 因此取而代之的是为不同的编码代理 java 这些不同的文件。想法是，我们可以有一个统一的 agents 文件，然后可以在所有这些工具中使用。已经有很多不同的工具在整合这个 agents md 文件。那么让我们回到代码中， 使用 codex c l i 为我们搭建一个 agents 文件。好的，那么我目前正在进行一个 codex 绘画，我将使用 init 命令生成一个新的 agents md 文件。 当我们使用此命令， codex 会自动扫描代码库，并为我们创建相应的文件。

最近呢， coco 的 团队啊，分享他们内部如何使用 coco 进行 ai 编程的十个技巧，那这十个技巧呢，不仅仅适用于这个 coco 的， 也可以用在别的 ai 编程工具里面。 那本期视频呢，带大家一起来了解一下这十个技巧的详细内容，以及啊我在实践中是如何使用的。第一个技巧就是如何去使用 gitwalktree 来进行并行开发。 那你了解这个 worktree 之前啊，你要看一下，目前如果你在单分支的情况下，你要进行并并行开发，这是不太可能的，为什么呢？如果你对一个分支进行多个这样的一个对话的话，那这代码肯定是会混乱的， 那么 walk tree 呢，就是来解决这个问题，在一个分支上可以去创建多个这样的 walk tree 这样的临时目录，那么在每个临时目录里面去进行对话，去进行开发的话，他们之间是不会互相影响，这样的话达到了一个这样的一个并行开发的一个效果。 那关于 gitwalktree 或者说关于病情开发呢？啊，我主要有下面三点想要说的啊。第一个就是如果你是使用这种终端命令行，比如像 cloud code 啊， codex 这种去管理这种 gitwalktree 吧，其实是有点麻烦，你需要去敲命令。 那么其他的可视化的 ai 编程工具其实都带有这种很方便的这种 walktree 的 管理，那比如说像 codex app， 你只要新开一个 three， 那 么你就能看到在这边选择 word tree， 那 从哪个分支去创建这样的 word tree 是 很方便便捷的。第二个呢，就是 一定要在你这个项目本身的骨架框架已经完善的差不多了，那再去使用 word tree 去并行开发，那为什么呢？因为可能在同时开发不同的功能模块的时候，他们有一些共用的模块是要提前弄好的，不然的话这样容易导致重复或混乱。 所以建议就是一定要是你的基本框架公共模块函数已经可以了，已经搭好了，再去使用 word tree， 这样的话效果会更好一些。 那第三个就是那么多个 word tree 同时进行开发，那你如果是单人去管理的话，其实是有点累的，那么这个过程是需要适应的， 如果你感觉到是就是管理不过来，那也没关系，你可以使用单分支，或者说只开一个这样的 word tree， 两个任务同时进行去适应这样的节奏也是可以的。那么除了 word tree 这种方式可以并行开发之外呢？ 最近比较火的这个 ai agent， open curl 的 作者啊 peter 分享了一个更简单的方式来进行并行开发，它会把这个项目啊拷贝到不同的目录里面去，然后呢，切克 out 不 同的分支， 针对不同的分支，再去同时打开 color code 的 窗口去开发。那么这也是一种并行开发的方式啊，比这个 gitwalktree 管理上会更简单一些，因为只要知道一个 checkout 的 命令就行了，那么大家可以去尝试一下。那第二个就是复杂任务多用 prime 模式， 那其实现在大部分的 ai 编程工具啊，都支持 pr 模式，但 pr 模式的具体的作用其实就是让 ai 能搞清楚你的需求的真正详细的内容是什么，你需要跟 ai 去不断去沟通， 直到你对这个 pr 计划文档或者计划的内容满意了，你再切换到普通的模式来进行开发，那么这是一个非常非常好的流程。如果你本身对你要做的功能 啊了解的非常详细，比如说长情啊，范围啊，框架你都能描述出来，那你直接发给他也是可以的，就省略到了这个 print 的 过程。但是我建议你就是还是但凡你要处理这种稍微复杂一点，你或者自己不清楚，你说不清楚，你不知道具体的方案是什么时候。 这样建议是使用 plan 的 模式去跟 ai 进行一轮沟通啊，沟通完确认完 ok， 没问题了，然后再去执行，那这样的效果和这个准确率是会大大提升的。 那这里面要推荐一个这种 plan 到执行的一个插件啊，叫 planning with files， 这个插件呢是采用 manage 的 一个思路啊，那我们来看一下，如果你在解决一个复杂任务的时候，触发 触发这个插件或者技能，那么他会生成三个这样的文件啊，一个这样的一个追踪的计划的详细文件和一个这样的一个研究啊，去针对你这个需求进行深入的研究的一个这样的研究结果的文件，还有一个就是整个过程 进度那样的一个文件，那这样文件的好处就是你关闭 cloud code， 或者说你切换不同的编程工具，那么你都可以去重新启动针对这个计划继续去执行。所以说它这个能比普通的 pro 模式能处理更复杂的任务， 非常建议大家去使用啊，它这边的话也支持不同的编程工具啊，主流的编程工具都支持啊，然后也支持技能的方式，插件的方式，或者直接或者直接把这个文件拷贝过去也可以，所以这边都是可以看到它支持这个啊编程工具非常大家推荐大家去试用一下。第三个就是 啊，这个不断迭代这个 colld 和 agents md， 那 为什么这里会有个 agents md 呢？是因为大部分 ai 编程工具啊，都是支持 啊，都是认可，或者说能够把这个 agent md 文件加载到自己的上下文里面，那除了 cloud code 呢，是自己命名的这种 cloud md， 所以 说呢，其实你掌握 agent md 和掌握 cloud md 是 一样的意思，那 cloud md 最大的作用是什么呢？它是它是一个永久记忆的， 就说他每次 cloud 每次跟你对话的时候，都会把 cloud md 加载到它的上下文里面去，所以就这个就变成一个非常重要的一个上下文的记忆的一个存储点，当你需要 ai 记住你的某些事情的时候，那么你就可以去把它写到 cloud md 里面去。 那么 cloud md 应该写什么东西呢？那这边有一个这样的一个模板，那这里的内容呢，其实是一个非常标准的，比如说啊，你的这个命令，你的这个测试流程，你的 pr 怎么写？ 那这些东西有可能不是一下就有的，就是你在项目刚开始的时候，可能这个哎， cloud md 或者 ajax md 非常简单，只有一些非常简单内容，那也没关系，你会在不断的迭代过程中会更新这个 cloud md 文件， 所以说它这是个持续迭代的，那比如说像 cloud code 这个项目官方的它这个 cloud md 文件啊，大约也就才二点五 k 这个 tokins， 所以 这个 cloud md 这个文件啊尽量内容要少一些。 那他这边的话的包含包含的内容主要有这些，比如说常用的指令啊，风格规范以及 ui 设计，还有一些流程啊，还有一些 pr 的 请求的请求，那跟我们上线面这个模板是有点像的，那其实无非是扩充一点，那你也可以在这个 啊， cloud md 或者 hsd 里面去用艾特符号去引入文件，这样的话可以让这个文件啊内容变得少一些。 比如说这边你的一个介绍，你的工程的接口规范，或者说其他的一些东西，都可以通过引用的方式。那么 cloud cloud 加载这个文件的时候，会根据自己的需要去读取对应的文件，这也是一种 啊，管理这个 cloud md， 让它的内容会更加的精准的一个方法。可能在跟 ai 对 话当中啊，怎么去更新这个 cloud md 呢？那这边有两种方法，那第一种是直接更新的方式，你让这个 cloud code 去更新这 cloud md， 那避免下次犯同样的错误，那其实你不需要去写，让他去避免去犯什么具体的错误，那他是会去总结啊，我之前在跟你的对话中，我到底产生什么样的错误，我把它记下来。这个这个规错误的规则是什么？他是有这种总结能力的啊，不需要去很进行很详细的描述， 那么你也可以使用钩子或者技能的方式来触发。那比如说我在其他的 ai 编辑工具里面就创建了一个通用的技能，那当我使用啊这个提示词的时候，它就会去总结我前面的对话是否有这种错误，或者说让它记住的东西，那它就会去啊总结，并且保存到这个 cloud md 里面去，那么这也是一种方式。那钩子的话，那就可以使用这种，比如说对话结束之后啊，多少人，那你去触发这样一个总结，那跟之前说技能的学习其实有点像啊，那这两种一种是主动的方式，一种是啊被动的方式啊，都可以使用来更新这个 cloud md 或者 hms md 这个内容。 第三第四个就是技能，就创建自定义技能，那这里面其实有一句话是说的非常非常对的，就说如果你一天做某件事超过一次，那么你就应该把这件事 总结成命令，或者说总结成技能，这是一种提升效率的非常有效的办法。那有了技能之后，那么你就可以把这个流程附用，你也可以把这个分享给自己的团队啊，这是个非常非常重要。 那么关于技能，那我在这个视频已经详细解释了什么是技能，以及如何去创建技能，那下面就继续分享去哪里找这个技能？那目前主流的就这三个网站可以找到非常非常多技能，基本上把你的开发过程中，流程中用到的技能这边都有。那比如说我们看这最后一个，那么在这里面其实你可以根据这个安装的数量 去看这些，基本上有很多很多，比如说像 u i 的， 比如像 react， 比如说像这种啊 app 的 这种浏览器的非常非常多，那么你可以去点击，然后呢执行这个命令，执行这个命令去安装 现在通用的安装法，我觉得这个安装法是比较通用的，因为它能识别不同的这种 ai 编程工具，能把你这个技能啊安装到不同的这个目录里面去，而且可以创建这样的软链接，非常非常推荐大家使用这种方式来安装技能。 那么其他的网站也是一样可以找到技能的，你也可以使用这个 found skills 呢，然后去啊，去找到你的需要的技能啊，它会根据你的描述去整个这个这个 库里面去找有没有哪个技能匹配你目前的需求的，所以这是一个，也是一个把一个你经常要做的一个流程给封装起来。那这边的话也说到了怎么去创建的方式，那这个就是第一种方式，就通过对话的方式，那最简单了，那描述你的目标，描述你的流程，让他去创建技能， 那他就会调用 cloud code 官方的这个 skype creator 这个技能去创建你的技能。那么还有一种是比较聪明的，就是自动学习， 那么来自于这个 ai 编程最佳配置，这个视频里面有介绍过，就使用钩子去总结你前十人的对话，然后去总结可能可以学到的技能，那这是一种方式。那还有一种方式，类似就是 codex app 最近出了这个自动化， 通过定时器来触发自动触发去学习技能。那这边有一个这样的配置，这边比如说每隔一小时，他就要去扫描这个目录下面的所有的对话记录，看一下有没有可以学习的 技能，来避免下一次的错误，或者说把这个通用的流程抽象出来，那这也是一种自动啊，自动学习的自动创建技能。还有一些比如说像啊，一些第三方的库啊，支持通过使用斜杠命令的方式，你主动让他去学习，那也是一样是一种自动学习 创建技能。那么那下面呢？就是如何安装技能，那这里面也讲到了，就说使用 n b x skills 的 方式去安装技能，就算你没有装这个命令，它会提示你去安装这个命令，那这个是非常推荐大家使用这种方式去安装技能。那第五个就是他说让 coco 的 自己修复 bug， 那 这个其实整个段对话里面，我觉得他 说的应该是流程，他们使用 slack m c p 这种方式啊，只要在 slack 里面发现这样的问题，那把这个链接贴过去， 那么 cloud 去阅读这链接里面的内容，然后去修复问题。那其实是跟我们可能企业内部的这个，比如说像，我们，比如说像有自己的这种啊 bug 平台，对吧？这种专门爆 bug 的 这种 日记记录啊，或者是这种内部的平台去开发自己的这种内部平台的 m c p， 然后让 ai 变成能够去读取这样链接里面的详细内容，然后再去分析代码去修复。我觉得这是一个相当于类似于是一个自动化的流程嘛，从发现问题到解决问题，不需要人为 参与，非常多这样的流程，那这个也是可以值得去学习的。如果你是一个内部的一个协助这样的流程，那其实比如说像 excel 也是一个这样的流程，你通过 pr 合并请求，通过提问题，让他去读取这样的问题去修复，然后再去合并这样的请求，也是类似于这种一个这样一个自动化的一个开发修复发布的一个流程。那第六个呢，就是提升提示词能力，那这个其实是一个非常通用的能力， 一般目前来说并不需要自己去写很多提示词啊，你可以去让这个 ai 去跟你去对话，去沟通，包括我们前面说了 prim 模式，其实也是一种来丰富你提示词的一种流程啊，你也可以让 ai 作为一个这样的一个评审人，或者是教准人来审视你的提示词，来修复你的提示词，也是一种方法。那么你也可以使用现在很多 ai 编程工具都自带这个强化提示词的能力啊，那比如说像 arduino code， 或者说像这个 tree 啊，都是有这样的一个星星的符号，那么你都可以点击这个，让它去强化你的提示词，来根据上下文，或者根据当前的目录结构，能做到更加具体，更加详细。那么还有一些第三方的插件，比如像 openstack 啊，这些东西其实都是能够让你的 需求更加明确，让 ai 能更加懂你到底是想要做什么，都是变相的去提升你的提示词， 那如果说你自己有这种写题日词这个结构啊，这种能力，那更好了。第七个就是啊终端和环境配置，那么这里面的终端其实我个人的话是比较推荐使用 z 的， 或者使用 what 的 都可以，他们对这个中文会比较好一些。那这里面还强调一个什么呢？就是语音输入， 那这个是非常非常推荐的，那我最近这一两周啊，已经基本上不再去手敲这种文字了，基本上靠语音输入，那么语音输入有个什么好处呢？就是 可以比输入会有更多这样的文字啊，你会说更多这样的内容，那对于 ai 来说是非常关键的，可以使用像比如说像 class app 这种， 它是自己内置这种语音输入，那基本上大部分这种 ai 编程工具都内置这种语音输入，都是可以用起来的，就是你可以体验一下，通过语音输入绝对会比通过文字描述可能这个内容会更加详细一点。第八个呢，就是使用子代理，就是 sub agents， 那 我们先了解一下什么叫子代理，那比如说现在我打开这么一个窗口， 那这个窗口进行对话的时候，这个叫主代理，那么如果在这个窗口里面，我越是打开其他的子窗口，那么这个子窗口就是子代理，那么子代理跟主代理之间上下文是隔离的，就是他不知道主代理的上下文的内容， 他自己产生上下文也不会影响到主代理上下文。我们知道 ai 对 话上下文的长度是有限的，所以这是非常宝贵的。那么还有一个就是子代理可以同时开启多个，而这样的效率是非常高的， 那么因为子代理这两个特性啊，那么你要使用子代理的时候，你就必须知道子代理执行的东西跟我的主代理是完全 隔离的，那你就要去分配我什么样的事情能够使用去子代理去执行呢？那比如说，呃，我们跟 ai， 比如说我们开发完了一个功能，然后测试用力已经写好了，现在需要去跑这个测试用力，那么你就可以起一个子弹里去跑这个测试。测试用力就行了，因为他的职责非常简单，只要把所有的测试用力执行一下，那跑出结果就行了。这是一个非常典型的就可以跟主 代理是完全隔离的，所以具体的情况还是具体分析，看一下自己哪些流程是可以拆出来不影响这个啊主流程的，那么你就可以用子代理去跑这个东西。第九个他说用 coco 进行数据分和分析，我觉得这个更像是说使用 ai 编程工具， 然后使用语义化的方式来去做一些数据啊，或者是其他的一些一些功能啊。那这个其实也是一个趋势吧，比如说最近出了很多像写缩口语句，通过语，通过文字， 通过你的对话去写 sql 语句创建表的这样的工具，其实也是一个类似的，就是 ai 编程或者说编程工具啊，能够理解你语义化的东西，然后去调用这种像 my sql 啊，像啊这种底层的东西去执行，去转化。那第十个呢，就用 curl code 去，这里面其实是 curl code 里面有个功能，叫 你只要打开斜杠 config 就 可以配置让 curl code 去解释代码。这个让我想起之前 winsafe 我 们的 code 也是这种方式啊，通过这种 啊明摸麦的这种流程图的方式去解释整个代码的过程，那么他这个其实也类似的，那其他编程工具其实都没有这种类似的功能，但是你可以去找一些技能，应该也可以去生成这样同样的效果，比如说像解释一个方法呢？去流程啊， ok， 那 以上就是这十个技巧的详细内容啊， 那么这里面有些技巧啊，是只有 coco 的 能用，那别的都用不了，那么你也可以从这里得到一些启发，也是可以的。那每个人或者每个团队啊，都有自己的一些技巧，或者内部的一些流程 都是不一样的。所以说啊，这个东西没有标准答案，只要是能够提升效率，你自己能用的很舒服，那么这个就是最佳的一个技巧了。

你是不是也受够了你的 ai 编酬助手？他真的懂你的项目吗？还是说他给的代码建议看上去还行，但就是跟你的项目规范、你的代码风格格格不入？结果呢？你还得吭哧吭哧的手动改， 哎，今天咱们就来彻底解决这个问题，让你的 ai 从一个啥都会一点的工具，变成一个真正懂你的团队核心成员， 对吧？就是这个问题，我们想要的根本不是一个只会吐出通用代码的机器， 我们需要的是一个能心领神会，能和我们并肩作战的伙伴，一个能真正理解项目上下文，无缝融入我们工作流的智能队友。那么问题来了，这要怎么实现呢？ 其实啊，答案可能比你想的要简单得多。解决方案的核心就是一个叫 agents 点 md 的 文件，你完全可以把它想象成是给 ai 的 一份项目速成手册或者说独家记忆，所有关键信息都写在里面。 所以说白了， agents md 就是 咱们的秘密武器，它就是一个普普通通的文本文件，你可以在里面清清楚楚地写下项目的技术站、代码规范、目录结构等等等等。 然后呢，每次你跟 ai 提问，这些信息就会被悄悄地塞进他的脑子里，这样他给出的回答就不再是瞎猜的了，而是为你量身定制的 好了，理论听着挺酷的，但用起来到底麻不麻烦呢？别担心，上手超级简单，咱们现在就来动手试试，看看怎么创建咱们的第一个指令文件 就两步，听好了啊，第一步，先进入到你的项目目录里，第二步，直接运行杠以内的这个命令，你看，就这么简单， open code 会自动帮你扫描整个项目，然后生成一个 agent store md 文件的初稿啊！还有最关键的一步，千万别忘了把这个文件提交到 git 里，这样整个团队的 ai 就 都能共享同一份项目基业了。 来，我们来看一个活生生的例子。你看这份 agency md 文件，它就非常清晰地告诉 ai， 嘿，我们这是个用 type script 写的 s、 s、 t、 v 三项目，还是个 mono， 也就是个大仓库。 他还把项目结构、代码标准都列得明明白白。有了这些信息之后，你再让 ai 帮你写个功能或者重构一下代码，他就会特别自觉地遵守这些规矩。比如，把共享代码乖乖地放到 package slash course 这个目录里去，是不是一下就聪明多了？ 当然了，咱们还能玩得更精细一点儿，因为你想啊，有些规则是项目专属的，得整个团队都遵守才行。 那你可能还有点自己的编码小习惯，对吧？那怎么办呢？别急， opencode 早就想到了这一点，它允许我们分开设置项目级和局级的规则。 你看这张对比图，一目了然。项目规则就放在项目的根目录里，跟着 get 走，这是团队的共识。而局规则呢，就放在你电脑的拥护配置文件夹里，只对你自己生效。 你完全可以用它来定义一些你个人的编码风格。比如说，我就是喜欢用箭头儿函数，你必须给我用箭头儿函数。 那问题又来了，要是项目规则和我的个人规则同时存在， ai 听谁的呢？放心，它很聪明，不会让你二选一。 open code 的 处理方式是先把项目规则加载进来，再把你的大局规则加载进来，然后把它们俩合并。没错，是合并，所以它们是叠加生受的，既能遵守团队规范，又能保留个人偏好，简直两全其美 好。接下来我们玩点高级的，如果你的项目里已经有了一份写得非常好的贡献指南，比如 contributing md 这种文件，那你肯定不希望再把里面的内容一个字儿一个字儿地复制粘贴到 agents md 里吧？那也太傻了。 open code 当然也考虑到了这种情况，这时候就轮到 open code jason 这个文件登场了，它就像一个指路牌，允许你直接引用项目里已经存在的各种文档，把它们也当做给 ai 的 指令。 这个功能非常强大，因为它保证了信息的唯一来源，团队只需要维护好一套文档就够了，不用到处同步。 看这个 json 配置的例子很简单，在 instructions 这个树组里，你可以把你希望 ai 去学习的文件路径一个一个列出来，可以是一个单独的文件向 contributing 点 md， 也可以是某个目录下的文件， 你甚至还能用通篇服务。你看最后这个 star 点 md， 它的意思就是说，把这个文件夹里所有以点 md 结尾的文件全都给我读一遍，是不是特别灵活？ 所以咱们来总结一下这两种引用外部文件的方法该怎么选。绝大多数情况下，我强烈推荐你用 open code json， 因为它简单直接，维护起来也方便， 基本上可以说百分之九十九的情况，用它就对了。只有在一些非常复杂的需要按需加载规则的场景下，你才需要考虑在 a 机前死点文件当中，手动去指挥 ai 读取特定的文件。 好了，来，咱们最后快速划个重点，记住这几招就行。第一，用 n i i t 命令一键启动。第二，团队的规矩，放项目里自己的习惯放大局。第三，巧用 open code 点 jason 来附用你已经写好的文档。 掌握这几点，你的 ai 助手就算是正式办完入职手续可以上岗了。现在万事俱备，你的 ai 正等着你给他做岗前培训呢。所以问题就交给你了， 你最想先教会他什么是你们项目里特有的代码风格，还是某个非常复杂的 a p i 用法？别犹豫了，现在就去试试吧！

今天给大家分享一下，我们在部署好了 open cloud， 并且和飞书进行联通之后呢？然后我们在飞书端让它呃截个屏发送给我，然后它只会显示一个图片的路径，而不会显示整个图片。 呃，解决这个问题其实很简单，我们只需要在 open cloud 这个，呃，这次文件中加入这个 media pass 这个字段，并且再加入它的一个工作路径，呃，这样就可以解决。是因为这样的话我们就是给它一个 一个白名单，他在白名单中进行一个图片的保存，并且一个截图的话就可以正确的呃发送。比如像这里，然后我们再次让他截个屏发送，然后他就可以正确的一个截屏，并且在飞速段就可以展示这个图片， 可以看到他正确的展示了这个图片。

上一期我讲了，嗯， a 建词不是写给人看的文档，而是写给 ai 编程代理执行的规则体系。嗯，这一期呢，我不讲概念，直接带你看我在一个真实的数字人项目里面是怎么用 a 建词的。 呃，这是一个我正在开发的一个数字人的项目，嗯， 在这个项目里面我不只写了一份 excel 的 文档，呃，然后我，我应该还没有做完啊。然后我在每个模块里面放了一个 excel 的 文档，然后在各目录里面放了一个 excel 的 文档， 嗯，根目录的是一个项目级的宪法，然后每个模块呢是一个。嗯，行为契约。嗯，这样做的原因很简单啊，因为，呃，你不能用一份规则来同时约束整个国家和一个部门。 呃，我们来看一下那个项目级的那个建词是什么角色。呃，可以看到这一行，呃，就是 我在这一行就就已经把它定性了。这是一个那个 act 的 宪法，嗯，他不关心你用什么模型啊，比如他不关心你用 beauty gun 还是 code farmer。 嗯，他只关心三件事， 嗯，就是有哪些 act， 那 谁能调用谁。呃，哪些事情绝对不允许发生。 嗯，比如这边我做了职责的划分，呃，然后这边做了一些调用规则的一些必须要遵守的事情。呃， l i m a gent 是 明确不负责那个视频处理的， 嗯，可以这么看， 嗯。然后 video a gent 呢？是，呃，明确不负责那个语义理解的。 然后所有的跨那个 ergent 的 写作呢？只能通过那个，嗯， padla ergent， 呃，这条不是写给人看的，是为了防止那个，呃 ai 写出顺手就调用一下的一个代码。 呃。另外还有一个比较关键的就是文档， 看一下， 呃，文档，呃，这很多编程工具写完一个模块会给你总结一份文档，但是有些文档并不是我想要的，所以我这边，呃，明确的，呃，就是指示就不允许修改一些文档，只有 我我我明确要求他补充说明或整理文档的时候，他才能做，嗯，否则不得擅自去补充说明和整理文档。 那然后我们来看一下模块级的键词，呃，到底是解决了什么问题？ 呃，首先是 l i m event， 嗯，限制智能过度，呃，很多人第一次用 ai 写代码，会发现一个问题，呃，大模型是什么都想干，嗯， 所以我在这里面做了一件事情是主动砍掉他的能力边界，呃，他只能理解语意输出， emotion 和 motion， 其他的事情呢？呃，想都不要想。 我们来看一下 l i m 模块下的键词， 这是定义好他的职责，然后这是明令禁止的， 嗯，这是他的行为约束之类的模型调用的顺序。 ok， 我 们再来看另外一个模块，就是 video， 让它是去掉影视智能， 嗯， view 一 event 在 我这里面是一个确定性的执行器，就是我给他什么指令，他就按照固定的流水线执行就行了啊，比如人脸美化，按照这条流水线来执行， 呃，不允许他自己调参数，自己决定风格，自己觉得这样更好看。我们来看一下 view 模块下的一件此文档， 这是他的职责，然后这是他明确禁止不允许做的事情。 那现在你再回头来看这三份 adams 的 文档，嗯，它分别解决了三种失控，嗯，跟目录的话是解决了架构， 嗯，失控， a r i n 模块化，下面的那个文档的话，是解决了那个智能阅权 video 模块下面的电磁文档的话，是解决了影视决策，呃。它们加在一起才能让 ai 在 一个复杂的项目里面长期写代码不变形。 呃。另外还有一个就是重要的原因，我用 excel 的 话，就是因为这是一个比较大的项目，然后我可能要跟同事写作开发， 呃，然后我主要用 ctrl、 ctrl 之类的编，呃。 ai 编程工具，我同事可能用别的编程工具，呃。然后，呃键词，它是一个规范，嗯，可以在不同的 ai 编程工具下那个写作， 嗯， ok。 然后，嗯。最后那个坚持不是形式主义啊。嗯，然后它本质上是在回答一个问题，就是你是谁？你能做什么？你绝对不能做什么。 嗯，呃。本期的话视频就结束了，然后关注我。呃，下期我们继续玩 ai 相关的开发。

嘿，大家好，咱们都想让 ai 写代码写的更好，对吧？但你想过没有，万一那个最有效的方法反而是我们平时最容易忽略的那个呢？今天咱们就来聊聊这个，一个可能会让你大吃一惊的发现，你看，就是这么个问题， next g s 的 团队在解决一个挺普遍的麻烦的时候，就偶然撞上了这个核心答案。来，咱们一起看看他们到底经历了什么。 好，那咱们先来看看背景，要想明白他们怎么解决的，就得先知道问题出在哪。说白了，就是 ai 的 知识有代沟了，他满脑子都是老黄历，却要处理最新的问题。 这个感觉啊，就好像你找了个只会用老式打字机的师傅，让他去修最新的笔记本电脑。 ai 的 训练数据啊，都是过去式的，所以一碰到像 nexus 十六这种新框架的新 api， 他 就彻底蒙圈了。结果呢，当然就是写出来一堆根本跑不起来的代码。 为了搞定这个问题，团队就想出了两个完全不同的招儿，咱们可以把它想象成两个选手，一号选手叫 skill 方案，听着就特别高大上，对吧？像个智能工具箱， ai 需要的时候再去拿工具。二号选手呢，就朴实无华了，就是一个简单的 markdown 文件，叫 agent store md， 它的策略就是把所有重要的信息直接往 ai 脸上一拍，那么高手过招，谁会赢呢？ 一开始啊，团队把宝都压在了那个看起来更厉害的 skill 方案上，这也挺好理解的对不对？一个专门的工具，需要的时候再叫它，听起来就又高效又优雅， 结果呢，简直让人下巴都掉了。用了这个所谓的智能 skill 代码，通过率是多少？五十三磅，那如果什么都不用，就是最原始的状态呢？你猜怎么着？还是五十三磅？一模一样，一点用都没有？ 所以你看，问题根本不在于这个工具好不好使，而是 ai， 它压根就没想起来用它。这其实也戳中了很多大模型现在的一个痛点，你给了它一堆好东西，但它就是个懒得用或者忘了用的熊孩子。 不过团队也没灰心，他们就想，行，你不注重是不是？那我就在指令里明明白白的告诉你，喂，你必须用这个工具，强迫他用，这总行了吧？哎，你还别说，这招真灵，通过率蹭的一下就从五十三块线飙到了七十九块下，这下总算是搞定了吧？嗯，看起来是这样， 但很快大家就发现了一个新问题，而且是个大问题，这套方案太脆弱了，简直跟玻璃心一样。你的指令稍微换个说法，比如你跟他说，你必须先用这个工具，和他跟他说，你先看看代码，再用这个工具，得到的结果可能就完全不一样。这种不确定性要是放在真正的项目里，那绝对是要命的。 就在这个节骨眼上，团队脑子里冒出了一个完全反常理的想法，他们想，等等，我们为什么要让 ai 去做用不用工具这个决定呢？干脆别让他选了行不行？而这个想法就是整个世界的转折点。 所以他们就不再让 ai 去调用什么工具了，而是直接把一个塞满了最新文档信息的 agence 点， md 文件往它们前一放，同时还加了那么一条堪称黄金指令的话，翻译过来就是，欸，把你脑子里那些老掉牙的东西忘掉，就看我给你的这份新资料。 好，接下来就是最激动人心的部分了，咱们再把最终成绩单拉出来遛遛，啥也不干。五十三，用那个花哨的 skill， 还是五十三，逼着它用 skill 好 点儿？七十九，那么我们那个看起来有点笨笨的 agence 文件表现如何呢？ 你没看错，一百趴，百分之百的通过率，不管是构建代码检查，还是跑测试，全都一次过。就是这个最简单甚至有点傻瓜式的方法，把那个清起来很高科技的方案打的落花流水 就奇怪了，对吧？这背后到底是为什么呢？为啥这个看起来这么被动的方法，效果反而能这么杂乱？这里有个比喻啊，特别到位。那个 skill 方案就像是给 ai 配了个专家热线， ai 得先自己琢磨。哎呀，这个问题我搞不定，得找专家，然后再去打电话。你看，这里多了一部决策， 但 agents 点 m d 是 什么呢？它就是一张小抄，直接贴在 ai 的 脑门上，信息一直就在那，一抬头就能看见，根本就不用费脑子去想我要不要看。 所以咱们总结一下，它能赢，关键就在三点，第一， ai 不 用再做选择题了，省心。第二，重要信息每次都在非常稳定。第三，也避免了让 ai 去想什么。我是先看文档呢，还是先看代码？这种麻烦事，直接一步到位？ 说到这，你可能已经有个疑问了，等一下把这么多文档全都塞到上下文里，那模型的输入窗口还不得直接给撑爆了？问的好，这确实是个关键问题，团队当然也想到了最开始啊，这个完整的文档缩影文件确实有四十 kb 那 么大，这对于寸土寸金的上下文窗来说，确实是有点太占地方了。 但是他们用了一种特别聪明的压缩方法，硬是把文件大小砍掉了八十，怕最后只剩下八 k。 比最牛的是什么？是这么一压缩，百分之一百的通过率一点都没受影响，这操作真的得给个赞！好了，说了这么多，理论最爽的部分来了，上面聊的一切你现在就可以在自己的项目里用上，而且超级简单， 你什么都不用干，就在你的项目终端里敲下这行命令就完事了。这行命令就像一根魔法棒，它会自动帮你做三件事，第一，看看你用的是哪个版本的 nex ds。 第二，去网上把对应的官方文档给你下好。第三，把我们刚才说的那个神奇的压缩过的八 kb 缩影文件，啪的一下自动塞进你项目里的 agents 点 m d 文件里，全自动一条龙服务。 所以啊， next g s 团队的这次经历，真的留给我们一个挺有意思的问题去思考。你看，咱们现在总是在追求更复杂更强大的 ai 模型和工具，但会不会真正最有效的解决方案，反而是那些因为太简单而被我们看都不看眼的东西呢？也许有时候大道至简就是这个意思吧。

大家最近 costco ceo 呢发布了一个帖子，他说人工智能软件开发已经进入第三个时代，而且最近 costco 也发布了一个新的产品叫 costcloud agents， 那 么这个东西到底有什么关系？以及他所说的第三个时代到底是什么？那本期视频给大家一起来探。首先呢，他在这个帖子里面，他把 ai 编程呢分成了三个时代， 那第一个时代呢？就是 table 股权时代。那么在 ai 编程的第一个时代里面，人类是需要去参与写代码，因为当时大模型的这个生成代码之间是非常差，这个时候人是需要去通过写代码来纠正模型生成的代码错误，所以这个时代最大特点就是人需要去写代码。 那到了第二个时代呢，就是 a 型的时代，也就说你通过对话让 a 型自己去写代码。然后呢，人主要是做的事情就是 不断的对话，因为他完成任务长度是有限的，他会把这个任务拆分成多个对话去完成。所以呢，你需要去不断的去跟他对话，不断的去 view 他 demo， 然后去跟他一起去测试。 所以我把这个时代人的参与度就是陪着 agent， 陪着 ai 一 块的事情完成。那么他也给出了一份数据啊，也就是说在去年三月份的时候，那 table 使用 table 的 用户啊，大约是使用 agent 的 用户的二点五倍，但是现在到了二零二六年， 使用 agent 的 用户已经是 table 用户的两倍了，那么从这个现象也可以看出，人写代码的次数已经是 table 用户的两倍了， 已经大部分都通过 a 级的自主去完成这样的代码。其实我们现在大部分是 ai， 也也是在这个时代，那么到了第三代之后，模型增强了，能调用更多工具，能够更长时间运行，那自然而来就是人参与的就变少了。 所以呢，这个时代的特点就是人只要负责的是做事，就是去规划编程的 a 级呢？去完成怎么做的问题， 那最终人去把它的交付物去验收，那这里面到了第三个时代，交付物就变得很重要，那在前面这个时代里面，第二代、第一代，然后我们都需要去阅读 ai 代码的这个变化，以及有没有什么问题一，然后要去做一些端到端测试。那么在第三代里面，这些过程全部是 ai 去完成，那么它最终给你的这个验收交付物就变成了可能是 测试报告，可能是这个整个的测试过程的一个录屏，然后一个可以运行的一个测试的一个结果，比如说网站、 app 等等，那这些就是很明显的这种可以看到的这种交互物了，你不再去接触代码，现在的变化是非常重要， 人参与的更少，然后聚焦在更需要人的智慧判断的东西，怎么做已经不重要了，做什么以及它最终验收是否合格，就变成了一个最重要的事情。那么现在比较火的这个 openclo， 它也是一个云端的 agent， 然后他根据你的这个消息的对话，然后去完成这样的任务，你完全不用关注他是怎么做的，这其实就是一个变化的趋势。那么除了 cosco 发布这个帖子说这个云端 agent 的 自动化编程这个事情，那么 stripper 这个公司呢？ stripper 是 是国际上非常非常知名支付的提供商，那么他们也分享了他们怎么来使用 agent 的 编程 去完成他们的共同的编辑，那么他这里面处理的就更加厉害了，就是把整个开发的过程全部是 agent 的 代码自动化，比如说 agent 会去拉取你的 slack， 你 的信息，你的这个项目管理里面的，比如说 bug 报告，然后呢去编辑代码， 然后他会去拉取他们整个几万个测试库，测试用力，然后去进行测试，那么人人需要做的事情就是 pr， 阅读 pr， 那 最终的这个合并， 所以说它整个过程中间的整怎么做去执行的过程全部已经自动化了，不再回到 coso 针对这个第三时代啊，推出的这个产品叫 coso cloud agents， 那 这个产品的特点就是 它会给你出实化一个虚拟的环境啊，然后在虚拟的环境去部署你的代码，然后去根据你的指令去完成功能的开发。那么你也可以在外部端、移动端、桌面应用 slack 里面使用这个 cloud agents， 也就是你不需再需要去使用 id 了，你不需要去下载任何 id， 你 可以在任何时刻，任何地点都可以去完成代码的编写，以及看到它最初的交付。我们来看一下它这个东西到底怎么来用。那首先呢， 你打开这个 agent 这个文，这个网站网页啊，然后选择你的这个 get 目录，它是 get 这个跟这个是绑定的，要绑定先绑定，绑定完之后呢，你就可以去点这个 set up， 也就是他会出示整个你的环境，如果你出示完成了，做完了，那么他是默认是没有的，那么你就可以直接在这对话，那我们来看一下我之前的一个出场的记录啊，那我点了这个 slide， 进入这一步之后啊，他会帮我们申请一个虚拟环境，他会做什么事情呢 啊？比如说这个，那我这个项目是非常复杂的，有一个 java 的 后端，还有一个这样的一个后台系统，那么他识别到了我的这个 get 目录里面的这个 进入站之后呢，他就会去安装我们的 java 所需的环境，比如 jdk 以及 my circle 以及 radis， 以及所有所有的一切。他这边执行完看，他这边会按照按照像我们部署环境一样去部署拉取这样的啊，给 java 的 版本啊， my circle， radis， 然后进行安装，安装完之后 他就会启动这个项目，启动完这个项目之后呢，你就能看到 一个这样虚拟的这个环境，那么你可以自己去控制，比如说这个这个时候他什么项目，那你自己可以控制去点击，那么正常情况下是 ai 去控制，他会用这个里面这个虚拟环境浏览器进行测试，因为你是一个网页的系统进行测试。 那么在这个过程中呢，我让他修复了个问题啊，因为初十八项目之后，发现你启动之后有报错，那么他花了三十四分钟时间，也就是他运行了三十四分钟， 排查了各种各样的问题，最终解决了。解完之后他给了我们交付物，这里在强调交付物的概念了，刚刚说了第三十来的交付物是预制，可能是你的这个测试的过程以及可以运行的一个代码， 他就这边就录了屏，也就是这是他的一个测试完了一个结果，他他的一个测试说这个已经没有问题了，他自己会录屏， 他自己操作这个完全没有人参与的，他自己去点击菜单去判断有没有问题，去读写我们的这个谷歌浏览器的这个 control log log 日制，然后去判断 不在我们自己。比如说我们自己本地电脑，我们可以使用 m c p 去完成这样的事情，但还是需要我们人去参与，这个就是它完全在云端 帮你去做完了这件事情，然后这边也会有截图啊，然后呢接着呢我就让他先增了一个功能，让他做了一个功能，比如说在登录界面做一个忘记密码的功能，然后给让他输入，输入这个邮箱的时候可以去重置密码，那么他运行了三十分钟，然后最终自己测试完了这个功能， 自己进行测试编写。那么在整个开发过程中啊，他是会不断去写代码，不断去测试，就你能看到他这个桌面端一直在动来动去的，像人操作这个浏览器一样，你看他自己会去输入这样的一个账号，然后点击下一步，然后呢去写这个发邮件的代码，然后去发送验证码， 现在验证码是个模拟的验证码，当然他输了这个验证码之后去重置密码，重置密码之后呢，他还会去测试一下登录有没有，有没有问题，他整个过程是我们是完全不关心的，不 care 这个事情， 他自己完全是云端的，你这个时候可以把电脑关上，你可以人人可以离开的工位，干什么都行，然后他把这个过程已经完完成了，而且他会把最终这个已经成功的这个视频录下来给你看了哦，我是有这个交互物给到你，你可以看一下是不是 ok 了，对吧？ 然后呢他也会给到这个截图啊，每一步关键的截图给到你，那么除了这个交通物之外，然后呢，你可以在这边看他提交这个地址代码， 他会在这边会有地址代码，那么你就可以去让他去提交这个 pr， 他 会把这里所有的代码都已经写好了，弄好了，那么你就可以去提交 pr， 那 么在你的 get 哈密里面去合并这个 pr， 你也可以在这边去核词，那么他这个 cloud 的 就是符合他刚刚说的第三十来的交付物啊，过程也可以预览一个交付物，然后呢，还有我们的这个底下的整个的一个记录，以及他的 pr 的 一起，就全部在这个界面全部都可以完成。所以呢， 在我使用完之后，啊啊，我对这个的感觉就是 ai 编程的门槛又降，进一步降低，已经降到土里去了，已经不需要有任何的环境，你自己不，不需要懂任何的技术栈，你只需要去 把你的需求说清楚，那么完全交给他，他不长时间去运行，这个长时间运行是非常大的一个进步，现在所有的 a 型的或者所有的模型工具啊，都在强调这个可以稳定运行两个小时，三个小时， 那这个其实意味着就是模型能够自主判断，自主修复整个编程功能中产生的任何编码的问题，样式的问题，对吧？视觉的问题，然后最终给它一个符合你要求的一个交互， 所以体验下来是非常非常爽。那么这个功能目前也是免费的，可以去啊 cos 的 这个官网上去使用。那么这个 coscloud agents 呢？我这边也给他总结了步骤，大概你出手吧，一个你从来没有 在这个 cloud agency 里面用过的，那么可以分分这么几步啊？第一步可能是初识化这个系统环境，这个时候你不需要操心，你不需要操心，你只要给他一个 get 目录就行了， 然后的话他会在每次对话当中产生这样的一个交付啊，一个视频，然后一些截图，还有我们的这个 get 代码，然后可以去提交 pr。 所以呢，你关注的东西是非常非常有限的， 我们来对这个时代和对这个产品做个总结。我觉得 ai 变频已经啊进一步的降落点，门槛直接降到土里去了，人需要关注的就是做什么以及最重要的验收，其他的中间过程已经完全不用去操心了。 还有一个呢，就是 ide 已死啊，就是 ide 已经不会再用了，就比如说我在最近这半年基本上没有打开任何的这个 id， 那 用的就是 ai 权限，自己自带的 id 或者说终端命令啊，像 java 的 开发工具， python 的 开发工具， php 的 开发工具，已经完全没有再打开过了。 所以这是一个非常非常一个明显性啊，就人越来越脱手了，不需要再去编码，不需要再去看这些啊， 变更啊，或者干嘛这些东西。所以呢，对我们开发者或者说任何的一个普通人，如果你想去做一个产品，想清楚这个产品是什么，比去想怎么去实现它有哪些必要的多。那么在 ai 这个时代，人人是产品经理，这不是一句空话，而且是一个能做产品的产品。 ok， 那 本期视频就到这，如果你想。

如果你的 android skill 安装了，但是发现并不好用，比如说总是不触发，大概率是 description 没有写对。今天分享六个呢， skill 创建的技巧，全部是从 ospec 官方仓库里面扒出来的实战经验。第一个 skill md， 要有黄金结构。很多人写 skill md 呢，就是一坨文字糊上去， cloud 其实根本看不懂。 正确的写法是分块， purpose， when to use process， decision， logic， output。 每一块呢，都用标题和列表写清楚。 cloud 呢，一看就知道该怎么执行。 第二点啊， description 的 写法是否正确，直接决定了处罚率，这是最容易踩的坑啊。你写帮助用户处理 excel， 这太模糊了， ai 不知道什么时候该调用你，你得写清楚两个关键信息，第一个呢，叫做能做什么？第二个呢，是什么场景来调用？比如正确的写法呢？是这样的 好，你看前半句，列出了四个具体能力，提取数据，执行透视表，生成图表。后半句呢，写明了处罚的场景，分析表格数据或者自动化工作流，具体化，以 才能被精准触发。而且第二个信息点更关键，因为很多人会写干什么，但是常常忘记写什么时候来触发这个 script。 第三啊，重复的活呢，封装成 scripts。 比如说你经常要抓取网页内容，每次呢，让 ai 现写代码又慢又不稳定，直接写一个脚本呢，扔进 scripts 文件夹，然后在 s q m d 里面呢，告诉 ai 调用脚本就行。注意啊， scripts 文件夹里面的内容再多都是不加载到上下文里面的，而只是执行，因此 intoken。 而且由于是代码逻辑呢，是前后一致的，完全是稳定的。第四个， reference 文件夹要按需加载， qmd 里面超过了多少字就要拆分呢？从时间来看呢，最多不要超过五千字啊，如果超过就 把详细文档呢放进 reference 文件夹里面，在 qmd 里面写上需要时读取某某文件，这样 ai 不 会一次性的塞满上下文，只会在用到它的时候呢才加载。第五个， 直接抄官方的优秀案例， ospeak 官方的 skills 仓库呢，有六万多的 star， 里面的 m c， p， builder， web app， testing， internal， commerce 这些呢，都是生产级的 结构，怎么组织，指令怎么写，资源怎么分配，全部呢，都是现成答案，抄完改成你的领域就行。第六个，打包分享出去， skill 则遵循开放的标准，一个 skill m d 呢，加上 scripts， reference， assets 三个文件夹，打包呢就能给别人用。你做的 skill 呢，越专业，附用的价值呢就越高，对你带来的影响力呢也就 越大。总结一下， description 决定了触不触发，触发率是多少， skill m t 的 结构呢，决定了执行的质量， scripts 和 reference 呢，决定了效率的上限。 ok， 这一期呢，讲到这儿，觉得不错的点个赞，后续呢，还会拆解更多的 skill 的 实战的玩法。

你用小龙虾的时候，还在把所有的事情都放在一个窗口里指挥吗？比如我同时要写文章、发小红书、监控资讯维护、网站记账，都放一个窗口里，既浪费偷啃，效果还非常的好。改造成多 a 帧的模式， 才是给小龙虾省钱又提效的正确用法，我是这么做的。以飞书对接小龙虾为例，参考官方文档三个步骤。第一步，专事专办， 给每件事情创建单独的机器人来负责。比如我要记账，我就建一个这样的财务主管，把 opencloud 配置文件里的 channel 字段改成这样的多 account 模式，这两个 account id 记住，后面要用。第二步，多 agent 配置， 我们用这条命令给小龙虾增加一个 finance 的 agent， 等同于我们新招进来一个员工，出土化他的 identity 文件，把它捏成我们想要的形状。接着在 openclaw 配置文件里面增加 bindings 段落， 让不同机器人的消息路由到不同的 agent 上，实现分工的效果。第三步，测试验证 重启 open cloud 的 getaway， 在 飞书上分别给两个机器人询问他们的身份，如果能看到不同的回答， 那就是配置好的。后续还可以给不同的 agent 配置合适的模型，或者让他们互相派发任务。这样的工作模式可以大幅节省 token， 显著提升小龙虾的任务效果。实在是太爽了， 都不需要再雇人了。我加上小龙虾的 agent teams， 就是 超级艺人公司。关注我，带你玩转 open cloud！

你用 open crawl 是 不是还在玩那种发个消息回一下的聊天模式？那是把它当工具。很多人问我，凭什么你的 ai 框架能够像有脑子的数字员工能自己干活？ 其实啊，并没有那么玄乎，我只是站在巨人的肩膀上，把别人花了几千美金踩坑总结出来的经验，通过几块钱的偷坑费就把逻辑给跑通了。调教之后啊， open crawl 就是 一个完美的项目经理。 openclock 在 agent 点 md 文档里定义了它的所有的行为准则，通过优化配置文件，它能够帮我协调其他六七个 agent 同事。 我重点增强了它三个功能，第一是主动性，它有心跳机制，会定时检查项目的进度，主动跟我汇报，而不是等我下达指令。第二是可重物系统，哪怕网络中断或者绘画重启，它能从断掉的地方稳定地继续推进。 第三是自我总结，每次任务结束之后，它会自动做两个总结，一个是给它自己看的，存储在它的 memory 里，防止以后犯同样的错误。第二个是给我看的，总结，在 obsidian 里，如果是通用的经验，还会自动同步到飞书。 我们要让 ai 用它最熟悉的方式去解决问题。比如 opencore 在 和 ai 工程师 curl code 协助的时候，根本不需要像人类那样开绘画聊天，它直接开放项目路径、工作记忆。在工具使用上，我也明确了优先级， 让它用最省钱、最快速的 api 方式去执行，而不是浪费 tom 模仿人类操作浏览器。 其实啊， ai 时代的竞争，拼的不是谁写的指令长，而是谁更懂硅基生物的写作逻辑。如果你也想摆脱对话框的聊天模式，真正构建自己的数字团队，欢迎找我交流。我是光头哥，带你深度玩转 ai 时代，咱们下期再见！

hello， 大家好，我是 winter 喵，欢迎来到 web coding app 实战的第五个课时，这个课时的话呢，我们会结合 agile skills 来重新实现潮汐 app。 好，先来看一下我们这个课程的一个简介，这是新人友好的一个零基础课程，我们的话呢，会通过 ai 编程工具从零到一来开发五款 app。 这五款 app 的 话呢，包含了五个热门的一个领域，有潮汐， ai 聊天， 图文短距以及笔记类 app 啊，这五个 app 的 话呢，都会包括 ios 版本，然后呢像笔记 app 的 话呢，还会包含 macos 的 版本， 然后像 ai 聊天啊，它会还有小程序版本和安卓版本。所以的话呢，开发环境的话呢，要求是 mac。 我们用的一个 ai 编程工具呢，是不做限制的，像在我们课堂上用的是 chat， gpt 和 code x 啊，如果你更加习惯使用 console cloud 啊，以及国内的 tree 和 q 的 也都是可以的。 我们来看一下这个课时的一个内容啊，我们的话呢，会先来简单过一下上个课时我们单纯使用 promote 来生成的朝夕 a p p 的 一个代码， 然后呢，我们再来看一下 ai 编程的一个上下文的一个问题啊，然后呢，我们再会给大家介绍一下 ajax 点 md 啊， ajax 点 md 的 话呢，大家可以理解为它是一个整个项目的一个 规章制度啊，它就是整个项目的一个书名 codex。 每次在执行任务的时候呢，都会把 ajax 点 md， 就是都会去读一次 agent 点 m d 啊，这样的话呢，呃它生成的一个代码就更加符合规范一点。 然后呢我们还会简单讲解一下呃 agent scares 啊，以及最后呢，我们会结合 agent 点 m d 和 skier 啊，我们这个课时呢，我们是，嗯， skier 的 话呢，我们只需要 会用就可以了啊，我们不需要知道怎么样去自己定义一个 sky 啊，也不需要去了解 sky 的 它的一个规则啊，我们只需要来调用 u i u x pro max 这个 sky， 呃，就可以了啊，像 u i u x pro max 这个 sky 的 话呢，它能够帮助我们在生成 app 页面的时候更加规范，更加美观。 ok， 那 我们，呃先来看一下。先来看一下上课课时的一个代码啊，啊， 上课时的一个代码 tab 在 xcode 里面打开这个项目，如果上课课时你还没有生成这个代码的话，或者你生成的代码和我不一样也是非常正常的。没关系啊，你就跟着我的这份代码来过一次就可以了。 ok， 我 们先来点击这个根目录啊，现在我们看到的是整个项目的一个配置啊，包括它支持的一些设备啊，它的一个版本最低版本啊，以及它的一个 app 的 一个分类啊，名称啊。像这个分类的话，我们也可以给它指定一下啊，比如说我给它指定为 lifestyle 啊，生活方式啊，以及它的一个那个， 嗯，横竖屏的一个支持啊，我们的话目前的话只支持竖屏， ok， 嗯，然后呢？嗯，大家注意一下啊，这个地方的话，我们其实还得加一个东西 啊，大家就是如果他生成的代码，你用真机去运行一下的时候，你会发现就是当我们切换到后台的时候，他他的音频就没有播放了啊，那是因为我们还没有加这个 capability， 我 们会， 我们在这里给它加一下啊，大家只需要看我怎么写就可以了，你不需要去去理解它啊，我们直接输入 background， 这里会显示 background models， 我 们选择 background models 就 可以了， 我们把这个 o d o 勾上，这样的话呢，我们 app 就 可以在后台来播放音频了。 ok， 然后，然后我们再来看一下啊，这里还有一个 sets 文件， sets 这个文件我们点进来看一下，这边的话呢，我们选中 app icon 啊，嗯，这里你看， 我们可以给它放一个幺零二四乘以幺零二四像素的一个图片，作为我们的 app 图标。 嗯，这里的话，我准备了一张图片啊，大家的话也可以自己通过 ai 去生成图片就可以了啊。生成的图片呢，你必须要保证它，保证它的一个，我把这图片打开啊， 打开给它拖过来给大家看一下啊，你要保证它的一个分辨率是在幺零二四乘以幺零二四啊， 如果你生成的一个图片不是这个分辨率的话呢，你也可以修改一下，改起来很简单的啊，比方说在 mac 上的话，我们直接就通过预览来打开它，打开它，这里有个工具，工具啊，调整大小， 你看这个框高，你可以调你写成幺零二四就可以了啊，保存就可以了啊，就 ok 了啊，我们是通过这个预览来打开的它啊，或者你也可以直接右键这个图片打开方式预览就可以了。 ok， 保存好之后呢，给他拖进来就可以了。拖到这里啊，拖到这里，你看啊，那我再重新运行一下， 重新再来运行一下啊，目前的话，你看是没有图标的啊，我重新运行一下，等它安装一下，你看 你看它图标就有了，看到没啊？这这就是设置 app 图标，也是非常简单的。 嗯，然后接下来呢，我给大家来过一下这些代码结构啊，简单过一下啊，简单过一下。我们的整个 app 的 入口是在 app 它的 app 这个文件里面 啊，这个 app 文件里面，你看这是整个入口，然后我们的一个首页呢，是在这个 app 文件 tab 的 app 这个文件这里有一个 window group， window group 里面这一个， 这里啊， window group 里面的代码就是我们的一个首页，我们可以按住 command 点击这个 content view， 可以 去看一下，看一下我们首页是怎么样的 啊？我们的首页其实就是一个 table view， 你 看这就是 table view， 里面包含了四个 table 啊，你看其中有一个睡眠、专注、呼吸、冥想啊，都是对应的，就是 对应的，就是对应的。这点，你看像睡眠的话，对应的是 sleep view 啊，像呼吸的话对应的是 breath view 啊，我们同样你想看睡眠里面，想看这个呼吸，里面的代码也很简单啊，你这边按住 command， 点进去 breath view 啊，里面就代码就在这里面， ok， 然后，呃，大家再来看一下，像这里还有两个 service 啊，像这里有一个三的 store 啊，这个 service， 这 service 干嘛的呢？这 service 其实就是去调用后端 api 的 啊，这么一个 service， 它去调取 这个 api 啊，我们可以复制一下，可以来看一下啊啊，其实就是来通过通过这个链接来拿到这些 api 数据啊啊，你看这里对应的就是 闹钟啊，以及这些白噪音啊，在 sound store 这个文件里面可以来获取后台 api 啊，以及你可以看到啊，我们继续回到 content view， 你 可以看到在 content view 里面 这下面有个 task 啊， task 呢？就是是什么意思呢？ task 就是 在这个页面啊，在 content view 它加载的时候，在它初使化的时候，它会去执行这个 task 啊，它就执行 send a story 点 load 这个方法，你看啊，这个方法它下边其实就会最终会执行这个 reorder， reorder 的 话其实它就是去 url request 的 啊，就是通过 来调用这个网络请求啊，调用的就是这个链接，通过这个链接来获取我们的这个 这些白噪音数据啊，就这这样子来获取。然后这里还有啊， models 啊， models 的 话呢，我们上个课时也跟大家讲了，其实就是数据结构啊，就是，嗯，对应的一个数据结构啊，像三的是 models， 对 应的就是后端 api 返回的这个数据结构。 ok， 那 我们就嗯给大家简单就过到这里啊，就简简单过到这里，我们再来看 我们今天要继续要来生成的 app 啊。先来先来看一下 ai 编程的一个上下文问题， 嗯，如果就是大家用 ai 编程用的比较多的话，大家肯定就会遇到一些这样的一个问题，就是你 前面明明跟他说了啊，要这样这样做，不要这样子，但是呢，你后面和他继续让他改的时候，他还是那样子啊，就是他把前面说的话，你给他说话他已经忘记了啊，或者呢，当你， 当你就是需求比较含糊的时候，你就是你没有明确要求他怎么做，你只是说话说的很大概，就比如说你让他帮我做一个潮鞋 app， 你 也没有告诉他啊？这个功能要怎么做？他可能， 对吧？他前后的一个写法就是完全不一样的，这，这是有可能的啊，然后还有还有就是当我们的这个项目变得很大的时候，我们要来改一个功能啊，那是非常非常困难的啊，因为，哎呀，他根本就不知道 去改哪里啊，他甚至不知道改哪个文件啊？那这些都是因为上下文问题来导致的啊，因为大模型他本身是没有状态的， 就是大模型它其实是没有记忆的啊，那它的记忆是怎么实现的呢？它的记忆是通过 ai 编程工具来给它实现的 啊？就是，呃，但是呢， ai 编程工具它也不可能把整个项目都带进去，因为整个项目里面可能还包括图片，包括各种文件，那带进去的话太大了，所以的话呢， ai 编程工具它只会把一些关键信息带进去， 带给大模型，然后大模型在跟我们生成需要的代码啊，那我们来看一下，来看一下 code x 它会带哪些东西呢？ code x 的 话呢？它会把当前的一个。

二零二五年， agint 成为了 ai 的 主流形态，模型开始会规划、拆解任务，自己调用工具。但当问题变得复杂时，再强的 agint 也只能同时思考有限的事情。本质上它仍然是一个单体智能， 但复杂问题从来不是靠一个大脑就能解决的。就像人类文明的跃迁，靠的不只是更聪明的人，还需要分工和写作。 ai 已经足够聪明，所以 ai 的 下一步进化方向很可能不再是更强的单体 agent， 而是让多个 agent 协同工作，形成真正的 agent 的 集群。我们已经看到各个大模型厂商在新一代大模型中探索落地这种多 agent 的 写作模式。比如 cloud code 的 agent teams， 它允许多个 cloud agent 像一个团队一样， 在一个项目上并行工作，每个 agent 负责自己的任务部分，并且能直接互相沟通和协调，压缩传统串行工作所需时间。 国内的 kimi 大 模型甚至更早就开始探索多 agent 的 方案，在大模型训练的时候就引入了并行设计能力，在这个基础上推出了 agent swarm 功能 open ai， 在 gpt 五点三 codex 相关的文章里也暗示了下一步 agent 迭代将朝着多 agent 的 交互上做努力。那么问题就来了， agent teams 和 agent swarm 的 区别是什么？和 sub agents 有 什么区别？我们先从单 agent 的 情况说起。 从单 agent 到 agent teams， 我 们知道 cloud code 最基础的功能就是在一个窗口上让一个 cloud agent 替你干活，如果有多个任务，就在一个窗口里依次串行执行，但这样所有对话都挤在一个聊天框里，有上下文过长的问题， 所以我们一般会自己拆分任务，手动开多个窗口并行执行。但这样要是各个窗口改动出现冲突，就需要自己手动和代码。 于是 cloud code 又引入了 sub agents 功能，通过一个主 agent 来控制多个子 agent 的 工作，效果上相当于让主 agent 替你开多个子窗口，独立进行执行，最后由它来自动汇总结果。 但子 agent 之间没法直接交流，所以更适合改动相对独立、偶合较少的任务。于是 cloud code 又又引入了 agent teams。 在 agent teams 里，依然有一个主 agent 的 角色，他将任务通过共享任务清单的形式把任务给到各个子 agent， 子 agent 并行申领并执行任务，并且可以互相通信，这样多 agent 间协作可以更紧密。 agent teams 实测大概原理懂了，我们用一个实际例子看一下 agent teams 的 工作流程。我们先执行 cloud update， 确保 cloud code 是 最新版本。然后在 cloud settings 点 json 文件里将 team 相关的环境变量打开。在 cloud code 输入框里提到 agent team 关键词就可以触发相关功能。 比如使用 agent team 创建多个 agent， 从不同角度讨论二零二六年还适不适合在上海买房， cloud code 就 会创建多个 agent， 并行的从不同角度去做头脑风暴。最后给出一份讨论结果看起来挺好，但我认为短期内它依然只能是个实验性功能，因为它有两个比较严重的问题， 首先是 token 量爆炸。 sub agent 方案里，子 agent 会把执行上下文总结后返回给主 agent， 所以 上下文长度更可控。而在 agent 的 teams 里，则会让所有子 agent 的 共享上下文，每个 agent 的 每一轮提示词都要包含所有 agent 的 历史消息，任务越往后，执行。 agent 的 的历史消 息任务越往后，执行。 agent 的 成员通常在任务开始时就根据角色定下来了，很难在任务中途根据工作量动态扩容。 比如，我一直想做一个关于硅基文明简史的话题，讲述从二进制到计算机，再到 transformer 等一系列推动 ai 发展的一百个事件。 它分成几个阶段任务。首先是需要一位研究员收集人类历史出现过哪些关键事件，审核员筛选事件 图片生成源，生成一百张图片，图片审核员教演图片风格是否一致，再让 ui 设计师生成网页风格。最后才是给程序员开发网页。 这个例子中， agent team 只会创建六个 agent， 尤其是在图片生成阶段，可能还是由那一个图片生成员慢慢画一百张图，他不会因为发现任务量大，就临时裂变出多个 agent 同时开工。那有方案可以解决上面提到的两个问题吗？有。让我没想到的是，国内的 kimi agent swarm 把问题给解决了。 kimi agent swarm 功能实测，我们先来看一下执行效果，再了解下 kimi agent swarm 和 agent teams 的 区别。先将上面提到的归机文明简史任务描述粘贴到 kimi 下拉框，选择 agent swarm 执行， kimi 会启动一个叫 kimi's computer 的 虚拟机， kimi k 二点五会作为主 agent， 像项目经理一样，将复杂任务拆分成多个步骤的子任务，并现场决策生成六个子 agent， 每个子 agent 只负责这一个阶段子任务的上下文，这样 agent 的 上下文更短，注意力更聚焦，可以大大降低幻觉和出错概率。 点击每个 agent 都能看到它对应的照片和角色描述，就像一个电子员工一样。其中，研究员会在互联网上发起多轮搜索，从国内知名技术资讯站点获得几千条搜索结果，再从里面筛选出一百三十八个候选事件，生成一个 md 格式的结果文档交付给审核员。点击底部的 all files， 可以找到这个结果文件。点击查看文件内容，可以看到研究员已经将收集的内容按年代进行排序，并给出事件的历史意义。审核员淘汰三十八个，留下一百个真正改变世界的技术。以 md 文档格式给到图片生成员， 图片生成员拿到审核员筛选过的文件内容后， kimi k 二点五发现多张图片。生成一百张图片的任务时间会很长，于是将子任务进一步拆分成五个小批次，临时创建五个新的子 agent 并行去执行生图任务。 比起单个 agent 挨个串行执行任务改成并行之后，任务的实际运行时间会明显变短。 点击列表里的任务，可以看到每个任务的具体执行情况。注意看，这里面会有一些失败和报错， a 警的内部会不断调整策略，重试并最终完成子任务。 这要是在传统多个单体的 a 警的架构中，一个 a 警的内部报错，就算内部有重试，也会大大增加执行耗时。而 a 警的 swarm 架构中，局部任务的失败并不会严重影响大局，这样系统稳定性更高。之后经过图片审核员、 ui 设计师和程序员的写作完成了网页可以看到，网页按时间线给出了每个年代影响 ai 的 重要事件，且美术风格一致。 kimi agent swarm 通过多个 agent 的 互相协助，只花了几分钟时间就完成了我可能需要花一天甚至几天才能完成的任务。 agent teams 和 kimi agent swarm 的 区别最后总结下 kimi agent swarm 和 agent teams 的 差异。首先是架构逻辑不同， kimi agent swarm 逻辑上更接近 sub agents 的 增强版。 子 agent 之间上下文物理隔离，只负责局部的子，任务生产的中间结果会被总结后再返回给主 agent， 这样既保证了任务聚焦，又把 token 消耗压到了最低。 其次，支持动态并行。 kimi k 二点五在训练时引入了并行代理，强化学习技术，也就是 p a r l， 这让他具备了动态编排的能力。他像一个聪明的项目经理，能根据工作量现场摇人，比如身徒任务多，他会动态创建几十个 a g 的 并行跑，效率能比传统串行提升四倍以上。 最后是集成度不同， cloud code 更像是一个程序员的专业工具。想用好 a g 的 teams， 你 需要自己配环境，安装各种 skills。 而 kimi agent swarm 自带 kimi's computer 虚拟机，申图、搜索、写代码、运行网页，全是开箱即用，对普通用户来说更友好。从单体智能到群体协助， ai 正在复刻人类文明的跃迁路径，不是更聪明的大脑，而是更聪明的协助。 当无数 a 警特学会像团队一样并肩作战、分工配合， ai 就 不再是工具，而是队友，而这可能才是通往通用人工智能的真正基点。现在大家通了吗？ 好了，如果你觉得这期视频对你有帮助，记得转发给你那不成器的兄弟，文字版的笔记见评论区，这里是小白的 bug， 我 们聚焦一切可能影响人类历史进程的技术，如果你感兴趣，记得关注我们，下期见！嘟嘟嘟嘟嘟。

任何代码样式，测试偏好和其他他找到的内容。有时他可能会添加自己的个人偏好。因此，如果您看到这些，您需要稍微控制一下。沿途，我们可能还需要批准某些命令。但是几分钟后，他将为我们完成，并将其放在项目的根目录下。 好的，看起来他已经完成了。我们来看看这个新文件。您可以看到他提供了全面的指导方针。他有点简单，但您可以随时在后面添加内容。 因此，我们有不同的标题用于不同的内容。比如项目结构和模块组织讨论了不同内容的位置。我们有应用程序，它位于这个文件夹内。然后我们有像这样的不同路由段。我们还有布局和全局 c s s 文件可重用的 ui 组建位于这里。 好的，这一切看起来都不错。我们在这里有一些构建，测试和开发命令，看起来都相当准确。是的，然后我们有一些编码风格和命名约定。他说使用像这样的 pascal case。 好 的，基本上这都是通用的内容。