怎么让claude管理其他ai

最近的现在非常火，但是我发现很多的人其实不是特别会用 agent， 不知道怎么去和他写作。我给大家总结了五个比较实用的 agent 的 交互的方法。 那首先第一个是对于不同的任务，我们需要去用不同的管理方法，比方说对于一些比较简单的任务，像变量重命名，改一些简单的样式，这样你可以完全的放手交给 agent 去帮你做这个他们是非常擅长的，中间你不需要有任何的介入。对于 稍微有一点复杂度的，我们说中等复杂度的任务呢，比如说你现在遇到了一个 bug， 你 大概知道位置在哪里，你把它交给 a 的， 让他去排查。中间如果他这个做的不对，你可以跟他一些点播和指导，那这种任务你只需要去一些 关键的这个节点，你去做一个 review 就 可以了，然后适当的给他一下指导。复杂度比较高的一些任务呢，可能就是你需要你自己去拆解任务，一步一步的去执行检查这个结果，这个中间可能一步都不能跳，因为你可能第一步出错了，由于连锁反应后面都有问题。 所以啊，对于高复杂度的任务，还是需要你去大量的去人工去介入的，千万不要指望说通过一个 problem 来解决所有的问题，这个真的得看场景。第二点呢是警惕模型的锚定效应，心理学上有一个词叫锚定效应， 什么意思呢？就是模型在输出一段文本或者给你一个方案之后，那后续不管是你还是模型都会基于这个方案去 优化和迭代，而而不是说去审视这个方案本身，他可能有些方向性的问题，那这个其实你就需要去警惕了，因为他给你的第一个方案，那可能从根本上来讲就是一个错的。那怎么去解决这个问题呢？我觉得很关键的一点就是说 要让他一开始给你输出多个方案，让你去在多个方案之间去做取舍，然后你可能在一开始就能够得到一个正确的方向。第三个是善于访问模型，模型输出完了之后，一般都是非常自信的，让你觉得这个方案是无可挑剔的。 但实际上很多情况呢，他这种自信的语气下面，他实际上是给你埋了坑。所以我觉得最后一步，如果你能够反问魔性一句，比方说你漏掉了什么内容，你觉得你这个方案还有什么问题， 诸如此类的，你会得到一个更加系统和完整的一个视角啊，来去审视当前的方案到底有什么潜在的问题， 那这样可以避开很多坑的啊。而且即使你是一个小白，通过这种提问也可以得到远远超出你认知的这样一个洞察，这其实是一个非常大的杠杆。 第四点是去避免模型的过度设计，模型他是特别喜欢尽可能多的去输出一些内容，这就导致说我们在看到一些 web 客户的时候，表面上看里面有大量重复的代码，大量的垃圾代码， 那这个实际上就是过度设计导致的啊，怎么解决呢？我觉得也特别简单，在生成之前，你给他一个 prompt， 叫他不要去过度的设计一些不必要的模块，然后呢，在他生成完了之后，你也可以呃，加一句话 啊，让他去重新审视之前的方案，看有没有啊过度设计的一些嫌疑，如果有，那删除这些代码或者模块，这样可以很好的去解决这个过度设计的问题。最后呢啊，第五点是找到你工作中的瓶颈 啊，你可以反思一下你用 ai 工作的一个流程是怎么样的？首先你需要去拆解问题，需要去做 prom 的 组织，你要等 ai 的 输出，你要去 review ai 的 产出， 最后呢，根据反馈去迭代，你要审视整个链条当中这个生产的瓶颈是什么？因为现在 a 层的效率其实非常高，五分钟可以给你写非常非常多的文本和代码，所以大部分的瓶颈其实在人上面， 简单来讲就是人 review 不 过来了。那怎么提高人来 review 的 效率呢？我觉得也可以去按一些手段去做这个事情，比方说引入自动化的测试， 让 ai 帮你去做一些测试，而不是说每次都用人去点去交互，这种就是比较麻烦的。然后呢，是对于 prompt 的 频繁的这种输入会比较耗时间。嗯，那我觉得可以 把一些常用的 promenade 啊封装成 skill 啊，然后来加速你的这个 promenade 组织这一步。总而言之呢，就是发现你工作流的瓶颈，根据这个瓶颈呢来针对性的优化，对于瓶颈以外的这个部分，你其实再怎么优化都是没有用的。好，今天就分享这么多。

大家好，今天聊一个我觉得 cloud code 的 最被低估的功能， hoops。 为什么说被低估呢？因为很多人用 cloud code 的 痛点其实不是它不够聪明，是它不够守规矩，不会。原上有个开发者说特别好 cloud 的， 经常给你自信满满地说成功完成，结果你一测试全都红，它不是不威胁，而是跳过该跑的检验。 hoops 就是 解决这个问题的， 你在点 cloud 的 目录下 setting， 在 这次里面配好规则， cloud code 在 干活的时候就会自动触发你的检查，不是建议，是强制，我自己目前在用的，我去说几个吧。 第一个，文件保护点 e、 n、 v 配置文件，这些就是我们平常去配 a、 n、 k 的 地方，可乐都要动，我们就直接拦住。之前就遇到过一次，他帮我改他码的时候把点 e、 n v 里的 k 覆盖了，排查了半天才发现配了 h 之后就没有发生过这个事了。之前有一个国外开发商写一篇博客，说得很好，他说 hux 被拦住的时候， loud 不 会报错或者卡住，他会把他当成一个正常反馈来处理，然后自己就会调整方案，绕过去就很自然。第二个，每次改完文件自动跑 link 跟测试，这个体验对我来说提升最大的。以前可 loud 改完代码给自己去跑一遍，检查发现问题的告诉他，现在他改一个文档 link 自动跑， 没过的报错直接就给他修了。然后有时候我去倒杯水回来，他已经改了三轮了。这种感觉就是你不再需要一直盯着他去做每一步了，只需要看他最后交出来结果。 第三个是一个，很多人都不知道用法 stop hook glock code 有 个毛病，就是它会干着干着突然停下来问你要继续吗？明明还没做完它就停了。配一个 stop hook 检测它是因为任务没完成停的就让它继续跑，不要停不， 如果这地方有坑，你得在脚本里去检查 swap hook active 这个字段，不然然后的扣子就会无限循环的继续下去，停不了。然后说一下 hook 是 跟 skill 的 区别，这个很多人分不清。你把提交前跑测试写到 cloud md 里面，他有时候会遵守，有时候不会遵守。有人测过同样一条，就是不要执行 remove 杠 i f 这样一个规则。 如果你写到 cloud md 里面，可能百分之七十他会遵守，用 hux 的 话就百分之百。因为 cloud md 跟 skill 都是建议性的 包子，可以参考，但是不保证 pos 不 一样，代码层的强制触发了就必须得跑，没得商量。社区里有个说法，我觉得总结的非常好， skill 是 去提供方法论和指导 pos 保证最低质量标准，一个管上线，一个管下线。其实往深了想， pos 解决的不只是一个人用卡拉扣的问题。如果你是团队在用， 以前开发规范写到 wiki 里，写到 realme 里，新人来了，看不看是另一回事。现在你可以直接把这些规范写成 books， 放到 the cloud settings， 在 jason 里面跟着项目走。不管是谁在用这个 cloud code， 这些规则他都得遵守，相当于你把团队的开发标准变成可执行的代码， 而不是一份没人看的文档。好了，大家可以从文档保护开始试五分钟的配好评论区，聊聊你遇到过 cloud code 的 最不守规矩的时候是什么样？我挺好奇的。我是小新，关注我，带你一起去冒 ai。

excel 看似特别高端，因为它是用终端来运行的，看起来就特别像基础人用的一部分。但实际上的话，它本质上是通过自然语言来进行编程，内容，然后架构、梳理和配图类的全部是在这个框里去完成的。 你在 cloud 里面所有的内容全是在那个下文中存储的。但是一旦你用这个 excel 做之后，其实它的所有内容都是在这里，它全部是我的本地的一个文件夹。这个好处是什么呢？ 你的文件全部在本地，你可以换一个 ai 继续你的工作，因为他的所有文档在里面去写。另外是说你这个工作可能团队不是你一个人在做，你需要跟很多人去交互。你可以通过你们内部共享这个网盘的方式，让其他人用他的 ai 读去你这个文件夹里的内容， 就相当于说你能看到的这里边那个对话的所有上下文，其实全部变成了文档。你打开的中间应该是这样的，这是一个空白的东西，很清楚的，你做的第一件事就非常简单，就是召唤一下 clogs， 这个默认就相当于你双击打开了 app， i trust this folder， 他 说他会在这个文件夹里去建立你后面的一些东西，这个文件夹是没问题的。确认一下，这时候 cloud 已经存在了。那比如大家我们想演示个啥项目呢？可以做个简单的项目，比如说写公众号，请你帮我建立一个新的文件夹，叫做公众号创建 在这个文件夹当中，我会搜集整个社会的热点话题，并且去先做选择题，再做策划， 再转理成领导。另外我有再去做一些审核，最后我也希望能够每天根据数据去做一些发布，这些功能希望有单独的 aj 来承担。请你先做好整个价格的设计，后期去做一个项目，做好准备，你先把价格去 第一层。第二热点是引爆，这热点是历史数据，是用来做复盘用的，它整个主题，主题里面全部的要素整理上就规档的文件，还有你整个的 a 阵，就是他，他会在本地部署六个，一阵 六个，这个智能体包含着你说选题，你的编辑和策划，你的这个携手你的这个主编，你的所谓的这种这种排版运营，他会用这个东西来做这一完整的东西。

之前六叔分享了一个 skill 的 管理工具，统一管理的，很多人想要发现啊，这个需求很有代表性，我又找了一个更好用的，就这个 cc switch 啊，之前有介绍过，它是作为 第三方各种主流模型的 a p i 统一接入统一管理，然后你在用的时候在这里统一的去启动切换，非常非常的方便。各大编程智能帖都支持啊，包括龙虾的 code x， c c 的 都可以支持。除了这些，它里面也有统一管理 skill 的 功能，大家看这个扳手 点击啊，这里面就是六叔所有已经安装的 skill， 然后你会发现啊，我有些 skill 全部装的是 c c 里面的，如果你想在 code x 里面去使用呢，直接点一下， 再点一下，你看这些点一下全部同步过去了，包括 open code， 其他的平台，相当于一处安装，直接同步就都可以共享使用了，删除就可以全部删除了。然后安装有几种方式啊，一种就是直接把 skill 下载成 zip 包， 通过这个包去安装。还有呢，你看这里面，它也自带一个 skill 的 应用商店，你需要什么 skill， 只要知道名字就可以在在这里面去搜索啊，欢迎 skill 我 已经装好了，然后添加过的 skill 的 仓库呢，在这里都会有记录， 可以删除，可以一键链接过去啊，新的仓库进的仓库，可以在这里做添加。在身份上面去管理 skill 啊，集中管理你的模型的 a p i， 包括模型的切换，就非常方便了啊，真正的 all in one。 好， 大家可以把这个 skill 管理的工具啊，在这个上面用起来，关注我，持续丰富你来进了库，拜了个拜。

这是个能让你的多个 ai 工具协调干活的开源神器，每天一个硬核的网站推荐第五十七期，今天要讲的是它能让多个 ai 真正组团干活，全本地绝不上云！四大核心功能，第一，彻底分工，厚实的当老板，秒拆任务发给 walker 并行处理。 第二，三级共享知识库，派发任务，自带背景资料信息绝对同步，拒绝重复解释。第三，双层规则约束死命令，彻底匡死 ai 逻辑，干完自动回报，全程禁摩，运行上帝视角，前端看板，消息怎么流转？ ai 是 什么状态？ 知识沉淀了哪些？全部面板可式化，拒绝黑盒盲猜，只需 n p m install， 加上 start 两步，唤醒你的专属 ai 军团。

大家好，随着 opus 四点八的发布啊， cloud code 也发布了一个非常重要的功能叫 dynamic workflows 动态工作流，能够可以使用这个动态工作流去调用几百个这样子代码里来进行一个大规模的一个并行的开发。那本期视频就跟大家一起来了解一下 动态工作流是什么，以及如何来使用。我们首先来了解一下什么是动态工作流啊？一句话理解，就是你描述任务 clock code 会写出一张脚本，那这张脚本会在后台自动雇佣并指挥几十到上百个这样的子正体来干活，那最后把一份整理好的结果交给你， 那这个结果可能是你自己定的格式啊，那这里面其实有几个关键词，就是 called 会写脚本，那意味着这个工作流是可以保存起来，可以分享给别人用的，你也可以再一次去调用，因为脚本呢就是实际的代码文件， 然后他会自动雇佣便指挥几十到上百个写子整体，也就是他会根据你的这个任务自己去调度多少个子整体去干这个活，是他自己去分配的，也是会在这个脚本里面定义好， 然后我们看这个图就能看出来就是脚本来指挥这些子智能体啊，然后最后把这个结果给到你，那中间这过程都是在脚本里去完成的，那它是不会再回到这个主对话去跟你去进行一个 cloud 的 一个对话， 因为那样的话会导致这个上下文的问题，所以它是最终会给他一个结果给你。你是听到这里面可能会有点疑惑，那跟现有的这个 cloud code 里面的，比如说子代理， agent teams 这些有什么区别呢？因为他们其实都可以并行去开启多个子代理去干活。我们用这个生活中的一个例子啊，比如说你找人去装修房子来，我们来对比一下这几种方式的一个区别。 那首先我们从最简单的开始就是你一对一的对话，没有任何的子身体，那这个时候就类似于就是你找一个师傅，然后你每次都要叮嘱这个师傅要干什么， 那师傅干完之后就结束了，那你要安排他一个个试，那这种呢是效率最低的，那也是我们最常用的，因为我们去这样一次对话，那第二种就是这种子代理的这种模式，那这种模式就是你安排多个这种师傅去做事情，那师傅做完事情之后会告诉你， 每一个师傅干完干完事情都会告诉你，你需要去判断，要去找，还要找哪些师傅去干这个事情。这个时候区别就在于可以并行去做事情了，但是呢，每一个并行的这个子正问题完成之后，都会告诉你我做了什么东西，来等待你下一步的这个计划。 那么还有一种就是 agent 的 teams， 那 么你会设置好了啊，水电工，对吧？油漆工，电工。然后呢把这个任务分配给这个 agent teams， 那 么这边就会有一个领班，有一个 team leader， 那 他们三个人之间就是电工啊，水工啊、油漆工啊，他们三个人之间是可以互相讨论的啊，谁谁应该做哪个区域啊？谁去做哪个区，他们会通过讨论沟通，然后把这个事情做完，最终给到你一个结果， 那 walk flow 是 什么呢？就是你自己把一张整个施工流程图啊，大概是要我这个房子大概要做成什么样子的，那直接发给这个 coco， 那 coco 呢？就会根据你的这个施工图 开启一个这样的一个脚本，然后去写一段脚本，那这个脚本里面就会并行去执行非常多的这种子正题，那这个子正题可能是小工啊，一号刷漆的，二号刷漆的，对吧？还有这个铺地的电工啊，他分配了几十个人同时去干活， 那么在这个过程中你是不需要知道任何的进度的，最终把你这个房子装修好之后，他就会告诉你。那么这个 agent teams 和 work flow 有 点相似啊，其实最大的区别就是 agent teams 是 让你自己分配好哪些 这个组织人体，也就是我们的这个工人使派工人，然后他们之间是可以互相沟通的。还有就是什么呢？就是 work flow 是 你定义好了整个的意图啊，然后他会去写脚本，然后去开启 几十个这样子代理，而且你可以把这个编排的这个流程保存下来。那你下一次再装修第二套房子的时候，你可以直接用这个编排流程让他去做事情，就是把你这个 工作留保存起来，那这个 agent team 是 是不行的，那这前面的都是不行，所以它是可以被附用的，就这个工作流程是可以被附用的， 所以讲到这里大概应该有个这样的印象啊，就是这些是有本质的一些区别，所以呢，针对以上这些区别呢，我们可以大概知道我们应该什么情况下去使用这种四种类型，比如说你是一两步小改，小改动明确的这种单点任务，那么就用单个筛选，就是 非常简单的这种一对一的对话，这种对吧？你需要去派这种不同的组织人体去完成任务，需要来告诉你的，那么你就用这种组织人体的方式。那么第三个呢？就是你需要个团队，那团队里面的人可以互相沟通讨论，那这种可以用 agenims 去去做这个事情。那么第四个就是 你需要几百个几十个这样子代理，然后可以要循环交叉去验证的来，而且想把这个编排保存起来，那么你就用 coco 这种方式，不一定说一定要几十个几百个这样子体制体制，就是你要调动多个体制体制去 做这种交叉的验证复合，而且想把这个工作流能够复用，那么你就可以用这个工作流的方式。那么这边官方也内置了一个这样的工作流叫 deeply search， 就是 可以给他一个问题啊，他会从多个角度去网上去搜索这个资料，他提前是你在 coco 里用这个模型，本身就有这个网络搜索的能力啊，然后会逐条投票，最后会选出一个比较好的一个结果， 它是一个这么一个工作流，可以去体验一下，我们可以打开 curl code， 可以 输入 deep search， 那 这边就是自带了，我们可以看到这个描述是 dynamic workflow， 就是 动态工作流，那除了系统自带的话，我们可以自己去配工作流啊。然后的话你可以通过斜杠 先看一下你的这个配置里面是不是已经打开了啊？ demo 和 workflows， 那 这边是处，把它改成处的话，你就可以可以去开启这样的工作流，那开启工作流有两种方式啊，一种是通过输入 workflow 这个关键词去主动去给它启动这样的工作流 啊，比如说这个，那我输入这个 coco flow 的 时候，这边会变成一个这样彩色的这个字体，意思就是你已经开启了这个 coco flow， 那 么它就会去啊启动这种 coco flow 去做去执行你的任务。 那么还有一种方式是通过改变这个推理的这个效果，那么你可以看到这边，那么你可以选择这个，你看有个这样的闪动的效果，你选择它 选中完之后有个彩彩色的这个边框，那在这边出现这个 archcode， 那 么在这种情况下的话，你输入的这个提示词里面，如它会自己去判断， 它会自己判断你这个任务需不需要开启 flow， 就是 它相当于是给你开来一个这样的环境，你把这个内容输进去之后， 系统自己去判断你要不要开启 coco flow， 如果要的话，他会去开启整个 coco flow， 那 这种使用关键词的方式的话，就是相当于是你一定要去开启这个 coco flow， 所以 这两个是有区别的，所以我们在自己去配置这个 coco flow 的 时候，首先是检查 coco， 然后再使用这两种方式，另一种去看一下， 我们去开启这个沃夫洛。好，我们可以试一下我们显示的方式，去开启这样的沃夫洛，看一下具体的效果是什么样子的啊？我们输入现在国内的模型或其他的模型可能对这个沃夫洛适配没有那么好，但是应该会马上去跟进的， 它这边已经触发了，就是会使用沃夫洛对这个模块进行一个安全审计。 ok， 它这边已经开启了 workflow， 然后提示我们可以使用 workflow 这个命令啊，去查看它现在开启的具体的 呃阶段是什么样子的。我们输入这个 workflowflow， 那 么你就可以看到啊，你看这边它会执行的一个阶段，第一步扫描，然后这边的话有具体的这个五个子质整体， 然后呢？第二步验证，然后这边的话因为它还没有到这一步，所以它没有分配这个质整体。等第三步完成之后，那么你就能拿到一个 这个总体的一个效果，一个，然后你在下边的话是有一个这样的操作命令的，然后按 p 键就停止，然后的话你可以按 s 键，那么你就可以保存，比如说按 s 键，那么你就可以把这个工作流保存在这个当前项目这个目录里面，我们可以看一下当前项目这个目录里面是不是已经保存了， 那么在点 close 里面，这边有个 work flows， 你 看这边的话就是我们刚刚输入的这个要求，那么它就转写了一段这样的脚本， 那这个脚本的话就是具体的一个执行的一个详细情况，我们可以看到每一个这个智能体的这个提示词全部都有，那么你可以 把它关闭之后啊，你可以就是可以把这个工作流分享给别人，或者说你在别的项目里面也能使用了，那么按 p 键就停止了，停止之后你别只要不退出这个对话，你是可以去按 p 键再去给他开启， 你是可以恢复的，那么它又恢复了，所以 book flows 这个命令相当于是去管理整个这个工作流。但是如果你需要去附用这个工作流，你是需要退出来，我们直接退出这个对话， 退出这个对话之后，你启动之后，刚刚那个工作流就没有了，因为刚刚运行的工作流是不存在的，它只会保留在当前对话着，但是呢你可以重新启动 啊，比如说我们这个 api service 这个，那么啊这个就是我们刚刚保存的这个工作流，那么你可以在这边可以启动，那么也是一样，相当于一个命令一样。 所以就变成如果你这是一个可以附用的工作流，那么你可以分享给任何人，可以在别的工，在你的别的这个项目里面啊，像电用命令或者技能一样去给他使用它，这是一个非常方便的事情。最后就提醒一下，这个开 windows， 因为我们开启了很多子代理，那这样肯定是比较费 token 的， 这也是要衡量一下，就是你这个任务到底值不值得用 workflow 这种大批量去跑。然后大家也要注意，就是我们退出对话之后，那你这个 workflow 就 会失效。 所以最好是如果是一个好的 workflow 啊，你可以保存保存下来，然后再随时都可以去启动，那整个这个动态工作流大概是这个样子，那我觉得它的出现啊，其实是代表了整个 ai 领域的一个发展方向，本来我 从我们的一对一的对话能到现在大批量的长时间的执行，那未来这个肯定是一个常态。 ok， 那 本视频就到这，希望这个视频对你有所帮助。

这是我让十一个 ai 员工给我开发的产品门户网站，我的团队从零开始写需求，写代码，修 bug， 部署上线， 整个过程本次全部录下来，总花费约十元，一杯奶茶钱，一个下午十一个 ai 员工全部干完。给大家简单演示一下产品门户网站的一些功能，首先就是展示整个产品中心，这个是给用户看的， 然后还有一个后台管理系统，就是如何配置这些产品的。 首先展示一下我的 ai 软件开发团队的具体成员，这个在上次的视频分享中详细讲过。简单回顾一下， 产品经理就是把想法拆成 p r d。 企业文档。软件架构师就是做技术选型、系统设计、 api 企业 ui 设计师、数据库工程师、后端工程师、前端工程师、小程序工程师、 k o a 测试工程师、代码评选专家、 安全工程师、 db ops 工程师。还有就是总指挥，右下角这位总指挥只负责调度， 他不写代码，不参与具体工作。首先是产品经理出不出需求，然后架构师根据这个契约生成这个架构企业， 也就是 a p s。 代码和具体的技术栈，这里人工要简单把控一下，如果产品经理输出的需求跟你的不符，或者采用的架构啊，如果不懂技术的话，这个可以不用考虑，如果懂技术的话， 这个架构是不是你想要采取的架构，这里要简单去把控一下，也是全程最需要人工介入的地方。然后就是具体代码的实现，包括数据库的设计、后端开发、 剪断开发，开发完成之后 q a 会介入进行安全测试和 review 环节，最后 q a 通过之后，就可以进入部署上线阶段。这里运维工程师就会使用运维的一些技术，比如说端口部署之类的一些技术。 本次给大家展示的实验对象就是我的产品下载门户，一共包含了二十八个页面，十六个 api 和七个表结构。这里我们去演示一下如何开始做这么一个产品门户网站。首先把我的 cloud code 喊出来， 然后这里跟他说我需要标准团队来给我开发任务， 然后他会问我需要做什么？呃，这个技术清，这个技术倾向其实就是如果你是技术开发人员，你可能会关心，如果没有的话，他会有自己的默认选项，也可以不用关注。然后这里他会会询问我是不是要部署到我的官网的某一个路径。 如果说这里你没有部署过，他会问你一些，比如说你的服务器地址之类的东西，然后这里我输入我的需求，看一下他会做什么东西。 我的需求是我要一个产品门户，承载智联远控助手项目，未来要支持上架更多产品。这里他识别到这个项目我已经做完了，要确认我的真实意图。这里的话，呃，可以跟他说 这里我跟他说我是做演示用的，让他重新建一个项目目录，因为这个项目我已经开发完了，只是给大家演示用一下， 然后他这里说演示用等于独立，独立项目目录，不会影响线上的产品门户网站。嗯，这里他给了一些名字的建议， 然后只需要跟他说 ok 就 行了。这里这里他就已经开始进入第一阶段的研发工作，拿过资料的小伙伴应该知道第一阶段是什么吧，我们去看一下第一阶段是什么， 这里给大家简单看一下这个总指挥是做了什么东西，首先是自己的角色定义， 让他不要写任何代码，然后是团队成员介绍， 我们直接快速过到这个第一阶段，这是第零阶段的目录初步化， 这是第一阶段的需求分析，看一下第一阶段的需求分析，在产品经理这里，他具体是做了什么东西，其实就是产出了这个 p r d 文档，等会儿我们会看到这个 p r d 文档， 就是提前建好的这个空的文件，然后，然后我的产品经理会往里输入需求，这里我们直接跟他说开盖， 然后过一会他就会输出这个 prd 文档，我们来详细剖析一下这个产品经理输出的 prd 文档， 这里是产品经理实际产出的一个 prd， 然后这里是他输出的一些功能清单，有想要具体看的朋友可以自己去暂停看一下。 ok， 这里的话我们就不让他那个继续干了，这浪费我的讨论，因为实际的过程呢，已经在产品的下载门户里面，这个项目里面已经有了，我们直接去看这个项目就行， 这里总结了一下这个 p r d 文档的一些内容，包括这个需求，还有总计这个产品文档输出了多少行。详细的内容就是这里 刚才给大家展示的这个 prd， 有 想要仔细看的朋友可以暂停看，这里主要是给大家做一个演示， 然后这里是 ai 给自己定的八条的这个规定，也就是关键性约束，这里是禁止硬编码， 比如产品数据一定要从数据库读，不能自己去把这个页面写死。简单过一下，因为有一些专业术语，可能呃非技术人员也听不懂。这里只是给大家展示一下这个 ai 团队具体的这个行为是做了哪些事情，然后对应的文件就是这里。 然后我们看一下阶段二，我们来具体看一下有哪些东西。首先是这个技术的这个架构架构描述，简单看一下 这是他规划的项目目录， 还有他设置的 n t s 配置，这些都是基础性的东西。然后这里是呃前后端开发要遵循的一个契约文档， a p i 契约， 整个 ai 团队呢，一次性产出了三万四千字，有四份企业从技术规范层面一共是五层，各是框架试图层、样式层、数据层，还有部署层、 api。 企业就是字断级的定死，比如说这个就是请求地址， 然后这个是返回这个企业的话，就是针对这个前后端，然后数据库的表结构定义，它一共产出了七张表。简单看一下产品主表的这个结构， id slogan。 为了大家的观感，我就直接放在 ppt 上讲了，因为其实呃在这里看也是一样的， 这里的展示形式可能看起来不是很美观，整个过程呢，其实就是七月驱动，如果是纯 web coding 而不用我这套 ai 团队呢，其实会有很多问题，这个都是实践过的，比如说你要是纯 web coding， 那 可能前端就是使用 user 杠铃， 注意这个杠，但是后端定义有可能是 user name， 对， 这就是没有契约导致的后果，这就是后面要互相甩锅的一个经历。然后到联调的时候就是各种 bug， 而我的标准团队呢，都是先签完合同再写， 就是都按合同办事，然后看一下后端工程师生成的代码文件，就是十八个任务它一次性写完了。我们看一下这个产品列表的首页， 这里就是产品列表的首页，实际效果是这样子的，这里可能比较偏技术，大家就简单看一下浏览器疯狂死，循环跳转，然后页面渲染不出来，这都是他自己 写出来的 bug， 然后这三个 bug 呢，他自己就全部自己改掉了。然后这里他做完之后，他还总结了自己的这个部署过程中是怎么修复这个 bug 的。 然后简单看一下我设计好的这个 c i c d 部署流程，这里让他自己总结了一下他花费了多少 talk， 大 概就是有， 呃，三万多的一个拓客量，呃，折合人民币十元吧。呃，给大家简单普及一下这个拓客用量和这个对应价格的关系。 呃，业界普遍的一个价格是，呃，五十万拓客是差不多是一美刀，一美刀差不多就是呃六七块钱的样子。如果是一个传统的五人团队，那大概要消耗的可能就是五人天。那现在我们用了 ai 标准团队 只需要半天时间，你只需要下午两点的时候说做个产品门户网站，晚上十点的时候就可以零 bug 上线。下期视频我们会给大家讲一下 如何持续优化你的 ai 团队，让你的团队能力变得越来越强。最后记得一键三连，如果需要这套 ai 团队标准流程的同学，请在评论区里扣一。

你敢信吗？ cloud code 这个终端版的 ai 工具，五个真正的隐藏神技能，百分之九十的人根本没用。对，最后一个，连很多老用户都不知道。先说第一个， insights， 你 敢信吗？ ai 会反过来观察你怎么用 ai 输入这个命令，它能分析你过去三十天所有的聊天记录，给你生成一份交互式报告。第二个， s q 的 question， 普通 ai 是 你让他干嘛他就干嘛，但开启这个模式，会停下来问你 核心价值，就一句话，把 ai 的 瞎猜变成你的决策。第三个， hiddles 模式，别用交互模式，等 ai 慢慢回复 hiddles 模式，一条命令直接跑完，还能塞进 ci cd， 每次提交 p r， ai 自动审查评论，自动贴好。 第四个 b w 命令，以前重构时问个问题， ai 就 停下回答，上下文一乱，任务就跑偏，现在用 b w 提问，回答完按空格消除主任务，该干嘛还干嘛。第五个，压轴的 context fork， 这可以说是 cloud code 的 最长寿的秘密，在技能配置里加一行 context fork， 这个技能就在独立的磁代理里运行，长任务不污染主对话，代码审查，全库分析随便跑。最后说一句， cloud code 的 更新速度真的快到让人焦虑，但好消息是，越早用，别人跟你的差距就越大。

想用 cloud code 同时开三个 pr， 还能零冲突自动合并吗？教你三层架构，把 ai 变成一支工程师团队，前端后端 qa 并行干活。 第一步，调度层 cloud code 拉起三个 subagent， 前端写 ui， 后端写 api qa 做测试，一句话分配上下文独立。第二步，隔离层 gitworktree， 给每个角色一个独立工作树，文件不共享，分支不冲突，三个人改同一个 feature 也不打架。第三步，记忆层，共享知识图谱 brain 一个人查过的项目人物概念代码，所有角色都看得见， 结果四十五分钟跑出三份独立 pr， 零冲突自动合并。想给你的 cloud code 配一支团队吗？欢迎评论区聊聊。

我有自己的 ai coding 管理工具啦，玩 web coding 久了之后，发现用 clock code 生成前端的 html 文件和后端啊数据库这些完全不一样。 想要一个小想法能真正地去商业化落地，还是需要挺复杂的流程的。所以我们做了这样一个 ai coding 管理工具。这个 dashboard 界面呢，可以记录你不同项目的 prompts， 并进行数据分析。 planning 界面负责把简单不清晰的想法通过多轮访谈和问答的形式，生成详细的可商业化落地的具体任务。 coding 界面可以接入 planning 生成的任务，具体的一个一个帮你逐步实现， 还可以同时最多接入六个不同的 c l i 进行 ai coding 工作。所以你就可以在一个界面同时使用你的 cloud code 和 codex， 甚至还能部署 docker， 还能在下班后远程操作 bash 命令，在下班前设置一个定时任务，在 docker 里让 ai 自动跑完了，明早上班了再检查 这个 exploring 页面，可以实时反馈 clock code 在 生成代码的过程中有哪些新建的分支，有哪些 branch 被 merge 进了主分支里面？有哪些需要 debug？ flow timeline 不 仅清晰地按照时间线展示了 ai coding 过程中的进展，还能提醒你有哪些 coding 任务一直回滚，一直在重试。有哪些任务在 clock code 里面因为一直循环卡顿导致严重消耗了你的 token？ 它能实时总结你的项目概要和进程发展。最后，因为本质上现在和 ai 的 交互结果还是大多取决于用户提示词的质量，所以它还能帮你 ai 分 析你提示词的优缺点以及改进意见。 比如我这个小项目的提示词中，清晰度、上下文案例和 a 阵结构限制条件、逻辑推理和迭代演算都没有太大的问题。那么我唯一需要改进的就是给 clark co 的 角色约束太少了，那么下次我就需要给每一个 sub agent 做更多的角色规划。 例如有一个 subagency 是 ai architect， 那 我就需要说你是一个顶级的 ai 架构分析师，性格是 i n t j 严谨，逻辑清晰，具备极强的系统化思维，擅长从复杂问题中快速拆解核心结构，并输出高质量可落地的解决方案。在分析过程中，你要注意逻辑闭环架构稳定性， 不能输出情绪化或模糊化的内容。感谢观看，我们下次见！

嗨，大家好呀，你们没有开发经验的朋友，我最近又开始做开发了，我最近在忙着写一个手机 app， 然后有一个小小的关于 md 的 心得想跟大家分享一下。 首先要写一个能上架 app store 的 这种手机 app， 它的工作量是比我之前写的那些网页的 app 要高很多很多倍的，所以为了这么复杂的工程能顺利完成呢， 一开始是跟 cloud 聊了很多，并且让他把所有的内容都总结下来，写成不同的 md files， 我 和 cloud co 都可以回去看的那种。同时呢，在开发的每一天，我也在让 cloud co 帮我写一个开发日记， 让我记得哪一天我们做了哪些事情，遇到哪些问题，还有具体做了哪些决定和改变了哪些方向。那么这时候我发现一个问题，就是这些 md files 基本上只有 clock code 在 看在读，而有的时候我想去看一下，读一下，写一下的时候就觉得很麻烦，要打开一个 vs code， 或者打开一个某一个软件。 然后这个时候我就想到我最近开始用的 obsidian， 是 我基本上一开电脑，它永远一直开在那里的，因为我想到什么，有什么灵感，就直接往里面写的那种。 大家知道 obsidian 它也是主打一个 md 文档的，所以这个时候我就想如何呢，让我的 obsidian 去直接打开这些 cloud md。 其实这里唯一的问题呢，就是说我不希望我有很多套不同版本的 md 文档，在某一个项目中，我是希望它能始终保持只有一个版本的，那这个版本是 cloud code 会去看也会去写的，同时也是我可以通过 obsidian 呢去看，也去写的。 那这个时候要达到这个效果，我们就要用到一个东西，叫做 simlink， 非常简单，一共呢就叫三步。第一步就是你先要找到你的 markdown 文档都在哪里， 那这些就是 clark co 一 开始帮我写的那些，还有我每天让他帮我写的那些日记也好啊，开发计划也好，那我的这些 md files 呢？是在我的这个项目里面的一个文档里面。那么我的这个 app 呢，叫做 acorn， 中文是巷子或者巷果， 它在这个文档里叫做 acorn and defiles。 那 这就是第一步，找到这些文件真实所存在的地方，并且把它这个位置记录下来。那第二步呢？就是找到你想把它放到你的 obsidian 的 哪个地方， 这里要找一个你想放进去的 vault。 那 我的 obsidian 现在长这个样子，我希望把它写在这个 product 下面，开一个新的文档，叫做 acorn， 所以 我将会把它放在这里，在一个 note 里面，或者这个 vault 里面是有一个 product 的 文档， 它会出现在这里。那第三步呢？就是如果你是用 mac 的 话，你就把这个指令写进去，就是这个 l， n， dash s， 然后你第一步找到的这些文档所存在的地方，然后你第二步找到的你想把它放到的地方。那对我来说呢，我把它结合在一起，就长这个样子，这个时候我们复制它， 然后开一个 terminal， 把它跑起来。嗯，大家看到马上这里就出现了我的这个 acorn， 然后这里也有所有的我刚刚写的那些文档，它都在这里了，这个时候如果改任何东西的话，它会实时的出现在我的真实的那些文件中，因为这个文件夹里的文档相当于不是真实的存在。在这里它只是一个 symbol link， 能直接连到原本的那个文档。所以我们不管是我 手动在这里改，还是括号在别的地方改，它永远都是在更新同一趟文档的。那当然我也知道有一些朋友，他其实只是用括号去写这些 m d， 看这些 md， 自己可能也不怎么需要去看它，那这个时候你可能也不需要用一个 obsidian 了，但是对我个人来说的话，我能看得到，写得到，并且能把它同步给跨，对我来说还是蛮重要的。所以希望今天的分享对大家有帮助，我们下次见。

兄弟们，今天聊 cloud code 里一个看起来很普通，但其实很关键的东西， workflow。 workflow 这个词太容易被低估了， 听起来像公司会议里常见的那种词，什么拉其流程沉淀、方法论形成闭环。可在 cloud code 的 里，它不是 ppt 里的箭头，也不是一句你先这样再那样的提示词，它更像一个 do agent 调度台。 以前我们让 clock code 做复杂任务，通常会这样说，先帮我看代码，再检查安全风险，再看看测试够不够，最后给我修复建议。 听起来很清楚，但问题是，这仍然是在跟模型商量。模型今天可能认真拆成五步，明天可能两步就糊完。 你以为自己给的是流程模型，听到的可能是自由发挥。 workflow 的 价值就是把自由发挥写成代码。 它会明确规定第一阶段做什么，第二阶段做什么，哪些 agent 可以 并行跑，每个 agent 必须输出什么格式，最后由谁汇总，怎么去种，怎么判断优先级。这件事的本质变化很大。 普通 prompt 是 一次性沟通， workflow 是 可附用的工程资产。今天它可以省这个仓库，明天换个仓库继续省。今天做 pr review， 明天做安全审计。 如果流程设计的好，别人还能直接拿走复用。你不再只是拥有一个神奇提示词，而是拥有一条可以反复运行的生产线。它和 cloud code 理应有的能力也不冲突。 surveillance 更像临时谣人，适合眼前有个问题，叫一个 agent 看日制，再叫另一个 agent 看模块。 它灵活，启动快，但也灵识。今天这么拆，明天可能换一种拆法，不适合沉淀稳定流程。 agent teams 更像多人协助工作台，多个角色可以一起工作，人类可以观察调度接管， 它适合交互式协助，也适合长期复杂任务。但如果你要的是一条可以重复执行的流水线，它仍然偏人工调度。 skills 则像能力包，它告诉模型什么时候用某个专业方法，参考哪些文件，遵守哪些限制，调用哪些工具。 skills 解决的是会不会做， workflow 解决的是按什么顺序做，谁来做，怎么交付。一个像菜谱和工具箱，一个像后厨的出餐流程。 所以 workflow 最适合的场景不是随便问一句问题，而是那些你会反复做，而且每次都希望质量稳定的任务。比如大代码库分片审查， 你可以让一个 agent 专门看正确性，一个看安全，一个看性能，一个看测试覆盖， 最后让 agregator 汇总去中，按风险排序。再比如 pr 多角色 review， 让不同 agent 同时检查行为变化、安全风险测试缺口和 api 兼容性，最后输出 blocking 和 non blocking findings。 再比如生成批评修复流水线，第一个 agent 负责写出稿，第二个 agent 按标准挑问题， 第三个 agent 只修被指出的问题，最后再做一次验收，这样内容生产就不再是一把缩，而更像一个小型审稿。流程还有深度研究， 不同 agent 分 别看官方文档、论文、社区讨论和代码实现，最后有 synthesizer 生成结论。这个过程如果只靠一句自然语言提示，很容易漏步骤，写成 workflow 才有机会稳定复跑。 怎么起用？设置环境变量 cloud 口打 work flows， 等于一进入后输入 ultra work， 看到彩色就配置成功了， 但这东西也不能闭眼充，尤其是现在这种实验能力，更应该先深层脚本人工看一遍，再小范围运行人工负荷。每个 agent 都要求结构化输出，最终产物也必须检查， 不要把一个还没验证过的隐藏实验能力直接接近生产线。我觉得 workflow 真正重要的地方不是又能多叫几个 a 阵，而是他把 a 阵编排变成了代码， 复杂任务可以复跑，优秀流程可以共享，多 a 阵切磋从临场发挥变成脚本化结构化 可观察的工程流程。未来高手之间拼的可能不再只是我的 prompt 多神，而是流程怎么拆， agent 怎么分工， steamer 怎么设计，聚合器怎么判断，优先级产物怎么复合，这才是从会用 ai 慢慢走向会管理 a i。

这节课用 cloud code 的 上下文窗口做例子，看清一次绘画里到底装进了哪些信息，以及为什么上下文管理会直接影响效果和成本。 今天我们会先让你看到缓存的好处，然后深入内部结构，接着重点排雷哪些操作会让缓存崩溃。最后教你实时监控缓存状态，让你的 cloud code 一 直保持极速。 首先我们来看到底什么是 prompt caching， 它凭什么能让 cloud code 变快？在 cloud code 里发一条消息，背后 api 都会把全部上下文重新传一遍。你的系统指令、项目文件、之前所有的对话， 如果每次都要重新算，这些不慢才怪。这就是没有缓存时的真实情况。这一页先讲只处理新内容，旧内容直接复用 api 重用已处理过的内容，仅对新增部分计算缓存读取成本仅为输入的百分之十。 cloud code 的 自动管理无需配置。 好了，到这里我们记住， prompt caching 就是 一个自动的加速器和省钱工具，你不需要做任何事，它就在那里默默工作。但接下来要小心有些操作会把它弄丢。 要真正用好缓存，得先看看它是怎么组织的。 code code 有 一套巧妙的前缀设计，这一页先讲每一层都有不同的稳定性。系统提示层、核心指令工具定义、项目上下文层、 cloud md 内存等。 对话层，你和 cloud 的 交流。前缀匹配算法决定缓存命中。这种匹配极其严格，要求开头部分完全一样。 如果你中途切换了模型，系统提示变了，那整个缓存全部失效，下一个回合要全额计算，你会明显感到延迟。所以保持前缀稳定是缓存一直有效的秘诀。 小结以下缓存的稳定全仰赖前缀，把最不易变的东西放在请求最前面，并且尽量不在对话中途动系统层和项目设置，你的缓存就会一直健康。 下面进入最关键的排雷环节，以下六种操作，每一种都会导致缓存重建，给你带来一次明显的慢速回合。 当你用 model 换模型时，新模型有自己的系统提示和缓存空间，之前的缓存全没用，下一个回合它要把你的全部历史重新吃一遍。 plan mode 更是如此，规划用 opus 执行，用 sonit 来回切换，就要付出两次慢回合的代价。 缓存不仅跟模型挂钩，还跟工作量绑定。用 effort 改动时， cloud code 会弹出确认框，因为它知道缓存会失效。一旦点了应用，下个回合就要重新缓存，你会感觉到一次停顿。 m c p 工具的定义住在系统提示层，所以一旦有 m c p， 服务器连上或断开，就等于动了系统层，缓存全部失效。有时候即使你什么也没做，服务器竟成自己退出或网络断了，都会导致一次无预警的减速。 当你在权限里添加一个裸工具名，比如 bash， 实际上是把整个工具的定义从系统提示中抽掉了，这自然会导致缓存失效。但细力度的规则，像 bash 就 不会碰，定义只是拦截调用，所以缓存安全。 执行 compact 时， cloud code 会用加密你的聊天历史，这故意让对话层的缓存失效。但深沉加载的过程本身是高速的，因为它享受现有的缓存之后，你的对话变简短，缓存反而更高效。所以 compact 不是 陷阱，而是一种优化。 code code 升级时，核心提示和工具可能会有调整，所以升级后的第一个请求没有缓存，需要重新处理。一切好消息是自动更新，在你下次启动时才生效，不会在你干活时偷袭，但要小心恢复一个很长的历史绘画，那会非常慢。 记住这六种情况，他们都会让你的下一个回合变慢，你可以在任务间隙主动执行这些操作，只要心里有预期，慢一下也无妨。 讲完了雷区，我们来看看安全区下面这些你天天做的操作，完全不会破坏缓存。当你编辑项目文件时，什么都不用担心， code code 只在你需要的时候读取文件，读完后就成了历史记录，你后面再怎么改都不影响之前的记录，缓存安然无恙。 很多人以为改了 cloud md cloud 立刻就按新规则来，其实不会。它在对话开始时就固定了，中途的修改既不会生效，也不会让缓存失效，输出样式也一样，所以你可以随时改，等下次对话再用。 切换默认到 accept edits 这样的权限，不设计模型切换就不影响缓存调用技能。就像发了条新消息，安全还有 recaptive 附加加载 rewind， 甚至可以让你回到之前的缓存点，让速度直接飞起。 所以你平时绝大多数操作其实都在缓存的安全区里。了解这些后，你可以更自信地随时修改代码和配置，完全不用担心性能回退。 接下来我们看看缓存能活多久，怎么实时查看它是否在工作。缓存有寿命，默认五分钟 t t l。 如果你用的是 cloud， 订阅系统自动帮你提到一小时。 要是按量付费的 api 用户还想保持长时间缓存，就设置那个环境变量，当然调试时也能强制切回五分钟。 想直观看到缓存表现，就看这两个数字。读取 token 数越大，说明缓存命中的内容越多。如果创建 token 一 直很高，就表示前缀总在变，你的缓存可能没起什么作用。 最后把前面的内容落到行动上，编辑 clouters config， 设置 status line， 加入字段 cash read 和 cash create。 每回合结束后，观察数字变化，故意切换模型，看创建量标深 知识都讲完了，最后我们快速复盘，然后告诉你怎么用上今天学到的内容，我们来复习一下。缓存由系统层、项目层、对话层三层前缀决定，切换模型、改工作量、动 m、 c、 p 等六种操作会摧毁它， 而日常编辑文件、调权限、用技能都安全。最后，缓存有寿命，你可以用环境变量控 t t l， 用状态型看命中率。 接下来你可以在自己的 cloud code 里做几个实验，先正常对话，记下缓存指标，然后切换一下模型，感受那一次慢速回合，再试试设置一小时 ttl， 看看长时间离开后缓存是否还在。通过实际观察，你会对缓存有最直观的把握。 最后想问问大家，你在使用 cloud code 时，有没有碰到过毫无征兆的响应延迟？当时做了什么操作？和缓存失效有关吗？或者你自己摸索出什么保持缓存健康的小妙招？来评论区聊聊吧，我们一起进步！

我其实最近用克拉的扣的搭建了这三个工作流，第一个就是信息中台，第二个是公众号，第三个是朋友圈，第四个是短视频口播， 第五个是知识库自动更新，第六个是我跟小助理的 work space 管理，小助理每天的这个工作进度， 他就是一个机器人，在飞书里面让小助理每天的这个工作进度，他就是一个机器人的 sop， 他 会不 定期的自动更新。基于每个场景下的这种业务流程，我几乎全部把它移到了这个 cloud code 里边。最近的二十天，我几乎都没有再打开过像什么 mana simon， 加密卡之类的了。搭工作流它是一个复杂的事情， 再者就是，我发现我把我的所有的业务流程全部集中到 cloud code 之后，它们能够真的连通起来。区别是在于这里面的所有的产出，它都会以文档的形式存在本地，再加上前段时间非常火的这个 skills 技能包，它就可以快速的知道 你每一个任务上面需要怎么去做。它就解决了传统用大模型去聊天，上下文太长，然后它记不住的问题。嗯，但是 collab 的 每个任务都有一个本地文件夹，它会清楚地记录着你这个事情的需求节点是什么， 就以至于它们真的能够被串起来。这是今年我把所有的这个内容搬到 collab 上面很大的一个原因。我说一下我使用的一些这个心得和感受。当我开始尝试这个的时候，我是 连续十五天每天工作十四个小时在电脑跟前。为什么会这样子呢？是因为它真的太有魔力了，你说什么它就能做什么，有个词叫做 web coding 嘛，就是你一句话它就可以通过写代码的方式改变你的所有的这个业务流程，做出来让你觉得非常 smooth 的 东西，这种丝滑感已经让你觉得自己能力边界再次被扩展的，这种感觉会非常的吸引人。但是呢，就是其实并没有想象中那么顺利啊，因为我毕竟也不是天才，然后也没有什么代码基础，前十五天我搭出了很多我以为能用的工作流， 很多节点，它在单点的时候都跑通了，但是一串连的时候就是老是串不起来，老是有各种各样的什么函数部署不对呀，然后这个版本又不对呀，或者这个代码改了，这没改。那网上有一句话就是当一个项目它有一个 bug 的 时候，你让它去改 它，它改完这一个 bug 的 时候，它会再给你生成五个新的 bug。 那 我们没有技术背景的人是否适合用 cloud code 呢？怎么用呢？ 这就是我接下来要说的，就是我觉得通过使用 cloud 的 搭代码史山这个事情是所有没有技术背景的人的一条必经之路， 他会倒逼着你去找这个问题的解决方案。那我现在的解决方案就是假设你今年是一个这个产品经理，你要如何跟你的这个就是程序员，你这个技术团队去协助去做好这样的一个产品。首先第一个就是要学会写 p r d， 就是 把这个产品的一个需求， 他的技术方案在前期充分的讨论清楚，进行一个这个方案的审查，通过自创一些 skills 技能包，去把这个方案再进行一遍，这个需求审查，技术方案审查没有问题之后，我才会让他去逐步实现非常高频的去做这个整体的维护和 commit， 让他这个项目始终保持一个大局统一的一个情况。那这样的话，就在我十五天之后，我用了这个方式，我的这个工作流搭建起来就顺畅很多了。普通人要不要用？如果说你本身有一个业务需要用 ai 去做系统性的提效， 或者说你本身呢？就是希望能够让 ai 去帮你扩大自己的能力边界。那现在我建议你们都赶紧要去学习目前这个所有的这些 ai 工具里面，它的这个对我们的赋能，假设你学会了之后，对你的赋能，对你整体业务的提效是目前来说是最最有价值、最明显的。 如果你本身是一个自学能力很强的人，我觉得你去这个 b 站呀，或者海外的 youtube 上去学大量的免费视频，那如果说你没有很多的时间去在那么多信息里面去找到你想要的东西，我自己开发的一个产品叫做希芒 ai 进化岛，就是把我自己如何学习 webcody， 如何做艺人公司，如何用 ai 做自媒体的 所有的业务流程，全部的方法论和新法都更新在里面了，包括我这个十五天的史山经历，然后以及我现在正确使用 cloud code， 呃，应该是怎么样的一个流程？要注意哪些？而且完全是一个 我作为普通人的视角去写的，所以它非常适合，就是比如说像你们一样小白啊小白，然后想要学习这个，你可以完全去复刻我的这个道路，我的 skills， 我 的代码包全部都在里面，你可以直接搬运过去，把里面的关键信息替换成你的业务就可以了。因为我能跑通的，你们就一定能跑通， 因为我就代表着大部分没有任何技术背景的小白想用 ai 去解决自己这个工作、学习、生活、体校，全方位这个给自己赋能的一个人去换。