粉丝49获赞1044




大家好,我是世锦然,今天这期视频我想和大家分享一个我最近曲折的学习故事。 作为一个零代码基础的小白,我为了做游戏,几乎把市面上热门的低代码工具都试了一遍。 我的起点其实并不是游戏引擎,我之前在用 tree, 这是一个很顺手的工具,我用它成功开发了一个政教试验育种的网页,对于逻辑性强的网页应用,它真的很棒, 因为现在不是说 ai 编程很火吗?然后我看了他的宣广的那个材料之后,我就选择了下载吹来使用,我发现他对于这种前端的小网页的开发还是非非常成熟的。 然后游戏的话,因为游戏的交互太多了,我感觉它还不是特别趁手,因为我不太会拆解里面的 部部件,然后让它变得简单起来,所以说对于我来说,我并不是一个很有条理的人。嗯,所以用着 tree 就 有那么一点点的不顺手,就开发小游戏的时候嘛。 嗯,然后现在这个界面就是 tree 帮我生成的一个网页, 然后它就有这个正交的一个基本的操作的流程,然后这里是可以选的一个 一个东西可以选,比如说选咖啡,然后还是写因素名称嘛,就是第一个因素,对吧?是什么?光照, 然后就是水平一是强光,然后弱光, 然后再选一个,嗯,温度 选十,选二十或和三十五摄氏度,对吧? 二十摄氏度,三十五摄氏度 啊,然后咱们就生成一个实验方案,还是最简单的一个正交表, 然后就点开始,这样他就会出来,就会出来一个, 他都是模拟的一个极差吗?到到你自己做的时候,你肯定这个结果和这上面不一样,你就自己线下自己算算极差就可以了, 所以还是比较方方便的。它就是一个模拟的一个小 tips, 也不是也不是很准确,它肯定和真实的实验结果有出入,但是方法它是达到了的。 好了, play 的 部分就到这里,用它做网页应用,我确实觉得得心应手,但是做游戏一直是我的梦想,我觉得是时候挑战一下自己了。 于是我满怀信心的冲向了游戏开发的世界。我听说有一款引擎做小游戏特别快,甚至我还花了钱。 但是等待我的并不是顺利的开发,而是有一些看不懂的部分,以及浏览器出现闪退的情况。下一期我将揭开这段踩坑的经历,看看我是如何差点放弃做游戏的。 如果你也好奇我是怎么从网页开发掉进游戏开发的坑里的,记得关注订阅,我们下期不见不散!

哎,大家好啊,你有没有觉得让一个 ai 助手干所有活,就跟让一个实习生去管整个公司一样,有点力不从心? 没错,所以今天呢,咱们就要聊点不一样的,咱们要超越单个 ai 的 限制,自己动手组建一个真正的 ai 专家团队,让他们各司其职,协同作战。 好,咱们就先从一个大家可能都遇到过的烦恼开始说吧。就是当你的项目越来越复杂的时候,那个号称什么都能干的 ai 助手是不是也开始有点跟不上了,感觉有点吃力了? 你看啊,这些痛点是不是特别熟悉?就比如说你跟他聊着聊着,哎,他突然就忘了你一开始要干嘛了。或者呢,因为他不是某个领域的专家,知识深度不够。 最要命的是什么呢?就是那种需要好几个步骤的工作流,比如先分析需求,再做设计,最后写代码,它很容易就把这些事全搅合在一起,结果呢,出来的东西简直一团糟。 不过别担心,今天咱们就是来解决这个问题的,我们会用一个叫 cloud code 的 荒甲,分四步走,一步步地搭建一个超高效的 ai 协助团队。 你看,咱们会先讲行动手册和工具箱,然后组建专家团队,接着看看他们怎么实战。最后呢,也是最关键的,给这个团队装上一个记忆。 好,咱们就这开始。第一部分,打好地基。你想想,任何一个厉害的团队,都得有明确的计划和趁手的工具,对吧? ai 团队也一样,所以咱们的行动手册和工具箱就要登场了。 首先来看技能这个东西,你就把它当成是团队的行动手串,或者说游戏攻略,他用特别清楚的指令,一步一步告诉 ai 要完成一个任务,具体该怎么走流程。光说可能有点抽象,咱们来看个具体的例子。 就拿生成文章封面图这个技能来说吧,你看他的流程写的明明白白的,第一步,分析文章内容,第二步,想一个有创意的手绘风格的提示词。第三步,调用工具去生成图片, 最后一步,保存图片,顺便总结一下任务干的怎么样,整个过程一步扣一步,特别清楚。 当然了,光有行动手册还不行啊,你得有工具去干活才行。这时候 m c p。 工具就派上用场了,你可以把它们理解成一个个现成的能力插件,比如说一个专门生成图片的工具,或者一个能调用数据库的接口, 有了它们, ai 才能真正地动手干活。所以你看这个关系就很清楚了。如果说技能是那本详细的菜谱,告诉你做菜的每一个步骤,那么 m c p 工具就是你的锅碗瓢盆、炉子烤箱,是真正让你能把菜做出来的家伙事儿。 一个是指南,一个是工具,行动手册赔上工具箱,两者缺一不可,这才是一个完整的体系。 好了,现在咱们的流程和工具都齐了,万事俱备,只见东风了。这个东风啊,就是我们的团队成员来,让我们来见见这些 ai 专家们,这些专家成员呢,我们管它们叫紫代理。 你可以这么想,每一个子代理都像是你专门招来的一个领域专家,而且关键是他有自己独立的办公室,也就是一个完全隔离的上下文框架,在这个子办公室里,他能百分之百的专注于自己的任务,完全不会被团队里其他人的工作所干扰。好, 来看看我们团队的第一位专家,产品经理,也就是 pm, 他的活是什么呢?就是搞清楚用户到底想要什么,然后把这些需求分析透彻,最后写成一份特别详细的产品需求文档,也就是我们常说的 prd。 产品经理搞定需求之后,就轮到我们的设计师上场了,设计师会拿着那份 p r d, 把它从文字变成看得到的设计蓝图。你想想网站的布局应该怎么样啊?用什么颜色搭配啊?字体选哪种啊,整个视觉感觉是什么样的,这些都归他管。 最后当然就是我们的前端开发者了,他的任务也特别直接,就是把前面产品经理的需求和设计师的蓝图,真正的变成一个活生生的用户能点能用的产品。说白了就是把想法变成现实,动手写代码的那个人。 好,现在最有意思的地方来了,你看这种专家分工的模式,听起来是不是特别棒?确实他非常强大,但他也是有代价的, 这个代价就是 token 消耗会比较大。为什么呢?因为每个专家,也就是子代理开始工作前都得把相关的资料重新看一遍,这就要消耗掉大量的 tokens。 你 可以把 token 理解成是 ai 的 脑力或者工作经历, 所以说这其实是一个权衡,你愿意花更多的脑力成本来换取每个专家极高的专注度和最终产出的高质量吗?值不值得看你的项目需不需要这种精度了? 说了这么多,那在实际操作中,这个团队到底是怎么一起工作的呢?好,现在我们就来看看,由一个主代理,也就是咱们的项目总监来指挥的完整工作流程是什么样的?从一个想法一直到代码原型出来, 你看这个流程就特别能说明问题,整个过程就像接力赛一样。首先,用户有个想法,比如我想做个个人网站主代理,也就是那个项目总监,先来跟你聊,把初步需求搞清楚, 然后他就开始召唤专家了,他会先叫产品经理来分询需求,写出 p r d, 点 m d。 搞定之后,再叫设计师,让他看着这份文档,做出 designs back, 点 m d。 最后把这两份文档一起交给开发者,让他写代码儿。 你看,每个人都在最合适的时间点出现,干自己最擅长的事儿,然后把成果交接给下一个人,整个过程井井有条。 嗯,听起来很完美,对吧?但这里还有一个问题,就算是最牛的团队,如果一个项目要坐上好几个小时,甚至是好几天,难免会忘掉一些关键的细节。 这就引出了我们今天最后一个,但也是最关键的一个挑战,怎么才能给我们的 ai 团队装上一个长期记忆呢? 是啊,到底要怎么做,才能保证这个团队在长时间工作之后,还能清清楚楚地记得我们最开始的目标是什么?中间又有哪些重要的发现不会走着走着就跑偏了呢? 答案来了,靠的就是一个非常强大的插件,叫做 planning with files, 你 可以把它想象成是整个团队共享的一个大脑,或者是一个项目管理看板。 它的原理其实很简单,就是把所有的计划、发现和进度都老老实实地写在文件里,这样就不会丢了,用这种方式就完美解决了长期记忆的问题。 具体来说呢,它其实就用了三个特别简单的 markdown 文件来把所有事情都记下来。你看, task planner md, 这就是总计划和代办事项,保证大家知道接下来该干嘛。 finding sphere md, 这里面记录了所有研究过程中的重要发现。最后是 progress sphere md, 它详细记录了团队的每一步操作,做的测试,甚至是犯过的错。有了这三份文件,整个项目的所有信息就都有据可查,什么都丢不了。 好了,到这里我们来快速总结一下,要想打造你自己的 ai 梦之队,其实就是把这四个模块拼起来, 首先用技能作为行动首特定好流程,然后用 m c p 工具作为工具箱提供能力。接着用子代理来扮演你的专家团队成员。最后别忘了用插件给团队装上一个共享记忆,也就是项目计划,就这么简单。 所以说啊,这真的代表了我们跟 ai 写作方式的一个根本性的转变。过去我们是找一个什么都会一点的 ai 助手,而现在呢,我们是去指挥一支各有所长的 ai 专家军队。那么最后留给大家一个问题, 当你可以组建任何你想要的 ai 专家团队时,你最想用它来创造点什么呢?我想这真的就看你的想象力了。