帕姆ai持续时间

好家伙哈基米，还得是你为了测试 ai pom， 竟然一个晚上烧了两百万！当咱以为听错了是两百个 w token 的 时候，结果发现咱没听错，就是两百万人民币的 token。 我 睡了一晚上以后，这个发现他十三个小时花了这个两百万人民币的这个 token， 对， 花掉过多的 token， 对 对对，哈哈哈哈！ 在这里咱先介绍一下什么是 token。 token 被称作词源，是 ai 处理和理解自然语言时对信息处理的最小单位。因为 ai 其实并不能理解咱们连贯的一整句话的意思，不管是文字、图片还是视频，在经过计算机处理的时候，都需要把它碎片化变成一段段代码才能理解，也就是咱们所说的数字化处理。 而这些碎片也被称为最小的单位 token， 并且也因为它是一个最小单位，所以也是在使用 ai 服务时的一个计算费用的单位。简单说， ai 就 像互联网，而 token 就 像流量，你想让互联网正常运行起来，就需要花钱买流量。一般来说，一个汉字大约对应零点六到一点五个 token。 不 过 ai 模型的计费单位是按模型等级计算的， 轻中高级模型一元所购买的 token 并不相同。而帕姆 ai 属于老米自研轻量级大模型，咱这样带入一下，就可以很好的理解咱们的 ai 帕姆一晚上燃烧两百万人民币的 token 大 概的范围是多少了？哈哈哈哈！ 当你点击这个对话框，打开帕姆 ai 对 话，就会发现 ai 帕姆不仅可以给你满满的情绪价值和剧情解答，就连你问他飞鹰的光追是什么时，这个号称崩铁百科全书的 ai 帕姆也可以一秒给出答案。 最重要的是前往游戏内体验帕姆问问，与之对话十次即可获得帕姆时装奖励。每周与帕姆进行不同主题的问答玩法，还有五十星球等你拿！

大家如果让你用一次对话，就让 ai 编程能够持续的运行，直到把这个活干完，你有什么样的方法呢？本期视频就给大家一起探讨四种让 ai 持续干活的方法。但为什么我们在 ai 编程中 ai 无法持续的运行？ 因为在正常对话中，模型会根据提示词、内部软度和上下工具调用，以及模型自己的判断，真的退出当前的对话， 也说他执行完到一定时间，或者说任务的完成的可能没有到百分之百，他都会退出对话，他让你自己去继续，或者说直接问你要不要继续，会中断整个的对话过程。所以编程工具或者模型它本身是没有持续运行的这种能力的， 这需要借助外部的这种方法去实现这个目标。当让 ai 持续去干，其实就是让 ai 一 直运行，处在一个循环当中，那这个循环是什么？那应该包含两部分，那第一部分就是干什么，就是你让模型在这个持续的过程中是去做什么事情，第二就是 他一直做，一直做，什么时候结束，就是他完成的条件是什么，那么这两个就组成一个基础的循环单元。那么比如说干什么，我们可以设置这样的任务的这个进度， 具体的任务数，那他把所有的任务完成了，然后再去根据你的什么叫干完了这个验收的标准，比如说我们这有四个这样验收的标准，那这个验收标准通过之后，那循环就可以结束了，那意思整个持续 就结束了，任务就完成了。所以呢，我们要创建一个这样的循环的运作的一个流程，那这两步是必须要包含在里面的，那这两步都是通过提示词的方式去书写，那么第一种方法是最简单 也是最粗暴的方法，就是通过拜记脚本循环调用 colocore， 也就是说在这个循环里面给这个 colocore 的 命令启动这个命令的时候传一段这样的提示词，那这个提示词很有可能包含了就是你这次要完成的目标，你这次要验收的一个标准，也就说包括我们前面说的干什么，以及什么时候完成， 然后再加上一个这样记录状态的一个 state， 因为很有可能要考虑到循环中断，你要重启，那么它会去读取这样的 state md 文档，去了解这样的进度，那很有可能就会出现就是里面可能调用，比如哪个大模型 api 错误， 那你需要去重启，那需要一个这样的一个状态的记录的一个机制啊，去让他去可以随时去恢复，那有了干什么，已经什么时候结束，再加上一个这样的状态的跟踪，那就构成一个最小单元的一个循环的一个脚本一个流程了。那社区这边呢，也有一个非常 知名的这个通过脚本去来达成一个循环的一个啊，开源的一个方案，那这个方案非常有意思，那我们来看一下它是怎么来运作。首先呢你有一个 prd 文档，那这个 prd 文档就是写好了你要做什么 验收的条件，第一步会把这个 prd 微文第一文档进行拆分，拆分成更细的这种啊，相当于相应我们的任务，这个任务里面有一个状态，这个 process force 告诉他这个任务是有没有去执行实施的， 然后的话就开始去执行这个脚本，脚本的话会去读取这个 prd json 里面的文件啊，然后去一个个去开始执行，去实施，然后的话实施完之后它就会去更新这个状态，把这个把这个状态更新掉，然后呢 更新到我们的这个 json 文件里面去之后把整个进度保存到这个 progress 点 tst 文档就是我们刚刚说的 state md， 然后形成一个整个循环，它这边的话会会去判断有没有更多这样的 切出来的任务，直到最终去完成，然后的话就退出。所以它这个是一个非常轻非常巧的一个 循环的一个设计啊，通过输入一个文档来进行一个拆分，拆分完了之后通过状态来控制，通过一个整个的 progress 这个 进度的文件来管理整个流程的总体的进度，然后最后的一个完成，他就很好的去把控了循环的一个执行的内部逻辑和循环退出的一个验收的条件。那除了脚本的控制，第二个就是用的最多了，就是 hux， 那为什么函数可以控制？那比如说在 clock code 的 这个对话的这个生命周期里面，当我们开始绘画的时候，到这个 clock code 的 内部所有的这个生命周期的一个过程，比如说工具调用啊，啊，比如说这个任务完成啊，比如说绘画结束啊，它都会调用这个钩子来触发一些自定义的一个事件。 那这个方法就是在他认为绘画结束的时候，就是模型自己认为我要去结束了，这个时候他就会调用这个绘画结束的这个钩子，这个时候在这边去加脚本啊，告诉他你不要停止，你继续，还没还没， 这个任务还没完成呢，然后他又会回到这个绘画开始，然后去开始去执行这个流程，所以反反复复的让他在结束的时候去验证一下是不是已经结束了，没有的话那你就重新再来吧。 所以说通过 hux 这种方式也是一种实心循环的一个方法。那 cloud 官方也出了一个这样的插件啊，叫 live loop， 包含在它的官方的插销库里面，可以去安装。那安装方式也是非常简单的，只要在 prams 里面，然后你看一下你有没有安装这个官方的这个 cloud 的 官方的一个插件库啊。如果你安装的话，你可以在这边 discover 里面去找一下看，搜一下拉 f， 那 么第这个就是了，那你就让它安装，那你可以安装到当前工程，或者说安装到全卷目录啊，安装完之后执行一个 reload， 那么再进来，那么就有了。看到没有 live loop， 那 么你就可以使用这个 live loop， 那 这边的话它会要求你输入这个提示词什么之类的，那就可以。这个命令的用法就是使用这个 live loop 来输入内容， 当任务完成时，会输出一个标识，比如说是 complete， 拿来告诉模型 complete 已经输入这个东西了，那就结束了。它结束的方法 有两个，一个是输出特定的这种标识符，第二个是设定这样的次数，比如五十次，循环了，五十次啊，就可以结束了，用这两个方式来结束循环。那么官方也给出了，就是你怎么去写这个任务内容。 因为我们要去循环执行一个东西的时候，这个目标一定是具体的，可以实现的，并且加上约束和验收。那么官方给出一个例子，比如说你现在要去完成一个读读的 api， 你 不能直接说完成一个读读的 api， 让它变得更好。你需要有一些指标测试的覆盖率超过百分之八十， 包含文档什么的，那输出什么？这就是一个很具体的验收的一个条件，那它就会一直循环执行，循环执行，然后完成你所有的条件，那么它就可以输出这个 complete， 然后就结束退出了。 所以它这种方式就是非常具体，验收条件非常具体，退出循环的这个条件是非常具体的，如果你不这样写吧，很容易就是触发这个五十次循环全部跑完， 或者说你不写这个五十次啊，它就是永久在执行，那你这个消耗的托管是非常高的。那这种 hux 的 方法比前面脚本的方法又更进步了。第一呢，你不需要安装任何的脚本，你只要安装官方的插件就行了。那第二呢，就是它有这样的一个信电的条件， 比如说输出特定字符叫结束，然后或者说设定次数叫结束。有两层保险来保证，就是我们的循环是能正常退出的，如果你这个循环动不能正常退出，那是非常危险。那前面两个办法其实是所有后续所有方法的核心， 不管是后面再怎么变，都是基于脚本加钩子的方式去完成这样循环，所以第三种就控制这个 ai 命令，就叫 omacs， 那 这个工具就比较重了，就是你安装完之后， 你的启动不再是使用 klax 的 命令或者是 clark code 的 命令启动了，是通过他提供的命令来启动，然后他自己内置了一套工作流程，他这边会有一个这样的 interview， 就 让你去梳理这样的需求，然后去循环去执行，就你不再使用 klax 自己的命令了，因为他提供一套命令，相当于他把 klax 绑在他的流程里面，他 klax 变成一个终端运行的一个子子智能体，所以完全是被他控制的， 那这种方式就非常重了，但是如果你自己能明白里面的流程，那么它的自由度是非常高的。那第四种就是最近 collect 出了这个 mini go 这个 mini， 那 这个 mini 也是非常有意思的，而且是官方出的第一个这种循环的 mini， 就是 你装完 collect 之后， 开启一定的配置之后，他就可以去运行了，不需要安装任何的插件啊，脚本啊，官方去支持，而且他这边做了非常多的优化。在前面的所有的这个循环里面， token 的 消耗是一个非常大的问题，就是随着循环的这种运行啊，他 token 的 消耗成本会越来越高，因为你的上下文越来越多，越来越多， 套根的消耗成本越来越高，那套根消耗到了一定度之后，就会触发这样的，比如说限制啊，或者说你的这个额度不够啊，那导致这个任务去就提前结束了，或者说有更多的问题。那么 go 呢？里面有一个非常大的特点，就是他有一个这样的预算， 也就是他在开始这个 go 命令时，会进行一个这样的预算，那达到这个预算的时候会总结当前的这个进度，然后呢列出剩余的工作或者是组训点，那给出下一步的进 建议啊，等你这个额度恢复之后，或者说你这个有了更多额度之后，就可以继续去开始，而且他是自己维护刚刚说的这个状态，他有一个这样的维护机制，你可以随时停止，随时启动， 这样相当于他把这个循环变成一个产品化的，那么这边就是一个这样的一个流程啊。那怎么去配置 go 呢？非常简，你可以打开你的 class 或者说 class 这个终端，然后 class 的 话就在边设置这里，然后的话选择这个 配置，然后打开这个文件，这个文件就是它的一个啊，配置文件，配置文件里面因为 go 它属于现在一个内测阶段，所以你需要去单独去开启，打开之后呢，你搜这个 features， 然后在这边加上这个 go 点处就可以了，就开启了， 那么你就可以去使用这个 go 这个命令了，那么如果你使用终端的方式开启的话，它就可以直接使用这个命令的，那如果说你是用 cs app 用的话，也没有关系，你直接斜杠，虽然说他没有显示出这个命令啊，但是他是知道你要调用这个 go 的 命令的，所以说完全可以在这边也是可以用的。那接下来就是一个非常重要的怎么去写循环的提示词，那在前面我们讲过一个循环的提示词里面包含了两个部分，一个是干什么， 另一个是什么？是干完的标准是什么。那干什么其实应该包含了三个部分，第一个是具体的目标， 就是本次循环最主要达成的效果是什么，要做的事情是什么，这个是具体的。第二个是范围，哪些要动，哪些不要动，不然的话你整个循环的执行就失控了，这个范围非常重要。第三个就是约束，包括的是 技术站风格、兼容性或者是其他的，反正是让这个循，让这个模型运行的效果会更加精准，所以包含了这三部分， 目标、范围、约束。那有了这三个部分之后，那整个要干什么就变得很清晰，而且是可以被管控的。那什么叫干完了呢？这个是让循环结束的条件， 那么这个就是用验证，那怎么来验证？你可能会有一个清单啊，要完成一二三四五，那完成这五步，那这个叫完成了， 这个是一定要，不然的话模型不知道我什么时候要完成，那他就会以自己的这个判断标准来结束。可能这个判断标准并不符合我们实际让他去做这个循环的这个目的， 但看到这四个部分啊，目标、范围、约束和验证，大家如果熟悉规格的话，那么可以很显然的知道这个就是一个规格文档的标准结构。 虽然其实我们在写这个循环的提示词的时候，其实就是在写规格文档，那既然是规格文档，那就有很多生成方式了，那比如说我们经常用的 openstack 啊， superpowers 都可以去生成这样的 spec 文档，那么它都会包含我们这个四个部分， 那么其实除了这个常用的生成规格文档这些工作流之外，那 plus 模式其实也可以，不管是这个 plus 的 这个 play 模式，还是 clock code 的 play 模式，都会生成类似结构的文档。比如说这里面有一个例子，这个例子其实就是用 clock code 的 play 模式生成文档，比如说涉及的文件， 那这个就是范围，比如说还有这个验证，验证条件一二三四有四个，那其实这个就是一个验收的一个一个标准，一个例子了，所以 play 生成的这个文档也是可以， 所以大家你在用使用循环的时候，你可以使用 pr 去进行一个沟通，沟通完之后产生一个这样的文档，然后以这个文档来作为你循环的输入提示 词，你可以使用 clac 的 pr 模式都是可以的，或者说使用这里的这个比较成熟的这种 spac 文档生成的工作流也是可以，因为它基本上会符合我们说的这四个要素的点，那么你自己也可以这样去写，也是完全没有问题的， 只要你包含这四个元素，那么你就可以写出一个比较好的一个循环体出来。那最后一步我们来讨论一下哪些场景适合用循环去解决呢？ 那首先你要用循环啊，前提你的 kolex 一定要充足啊，对吧？比如说你，比如说你的 kolex， 如果是个 plus 的 套餐的话，那可能你这个 go 可能再搞了几步，就你的 kolex 就 已经到上限了，那你就要要等待或者说其他的模型达到一个速率的限制啊，所以这个一定要前提一定要 talk 是 充足的，而且你的任务循环的时间越长，越要优先考虑 talk 是 不是够。第一个适用的场景就是目标明确、验收标准清楚的任务，那这个我们刚刚一直在讲验收标准清楚，那这个是 最适合的。比如说你做一个这样的 app， 做一个这样的后台管理的界面，那在我的项目中，我是用这种方式来创建一个整个的一个后台管理的界面，但是这个前提是什么呢？你最好把这个 p、 r、 d、 原型、页面结构 这些都都做好。比如说你现在 app 要做成什么样子的，你就要把这个圆形结构、圆形的图片，或者说 hq 这种圆形的这种东西准备好。 那么循环干的事情就是把你的图片变成真实代码，他不需要去自己去思考我要做成什么样子的这个样子，一定提前跟他沟通好，或者说自己定义好。这种方式就是适合循环去解决执行的问题，设定的问题 提前解决好，那这种也是非常适合。比如说你如果是说帮我做一个网站，他这个是非常抽象的循环，他是可以做，但是做出来东西不知道什么样子，没有人知道他是什么样子。 第二种就是测试修复覆盖率提升的这一类任务就是有指数的，比如说我们的这个测试覆盖率从百分之四十提升到百分之七十五，你在这个 api 的 响应从什么提升到多少，这就有个指数的上升，那么他的循环会不断的去叠代， 直到完成这个目标。那么这种也非常适合就指数类的这种，因为这一类任务是有天然的反馈的，测试通过呀，你的这个覆盖率有没有上升啊？这种也是比较适合。第三种就是大量的代码迁移转换类的任务，比如说你这个 python 转 java， java 转 python， 这是这是模型非常擅长的事情。 但是呢也是要有这种验证方式，比如说构建啊，构建通过呀，你的测试通过啊，这个也就是也是验证的方式。第六个就是不适合使用循环的场景，第一个就是反过来的，没有清晰完成标准任务， 不知道要完成什么，你说的很模糊，这也不要去用，不要用这个循环，你最起码用必然模式或者说头脑风暴的模式，把这个需求搞清楚，把约束搞清楚，然后再去做这个循环的这个调用。还有第二种依赖不确定的外部系统， 比如说你在这个验收里面可能包含了说我要去调用微信支付，或者调用别的外部的一个接口，那这个接口可能是不稳定的，那么它验收一直验收，不过因为它可能掉了这个接口又失败了，掉了这个接口又失败了，那这样的话会造成它一直在那里，一直卡在那里，那你消耗的 top 也会变多，然后你这个任务也没有完成，所以 如果说这个外部的 api 是 不确定的、不稳定的，那么你这个任务也没有完成。所以如果说这个外部的 api 是 不确定的、不稳定的，那么你这个任务， 那比如说五到十分钟就能完成的事情，那不值得去用循环，直接就自己对话就可以了，这种就没必要用循环了。那第五个就是比如说你现在说要把这个首页变漂亮，或者是把这个系统把整个 ui 变得更美一点， 但，但是怎么叫美？你没有告诉这个循环，那这种也不适合，因为需要人去判断的这种，而且是很主观的。那不要用循环，那循环适合的就是把这个东西扔到这个黑盒里面去，他一直在转，一直在转， 他不需要等待你的确认，等待你的审美，等待你的判断，所以说这一类是适合。第六种是长期经营类的任务， 比如说这种你要让这个 seo 增长，或者账号涨粉，或者产品这种，这种东西是周期性的，这种也不适合，这种是适合这种周期性任务，不适合这种单次的这种 循环或者是 go 这种来做。所以呢就总结适合循环的公式，比如目标明确可可以自动验证，他自己可以自动验证， 那可以分布推荐啊，出错可以围滚啊，风险可控，那只要符合这五个至少四个的话，我觉得是完全可以用循环去解决这个事情，能提升你的效率的方式。但是还是回到这个前提，你的头盔一定要， 不然的话你就会很尴尬。虽然上面说了很多场景都可以有循环，但是其实现在很多模型都在 支持原生的这种长任务执行，都在往这方面发展，不管上下文长度增长还是长任务的支持，其实我们在实际开发中很少去这种显著去调用循环去执行任务，直接生成一个文档，生成详细的计划，然后丢给模型让他去执行， 可以执行一到两个小时都完全没问题，那如果说你这个任务是非常巨大的，你要执行十个小时、二十个小时，那你肯定是要用这种循环的方式。 ok， 那 本期视频到这，希望这个视频对你有所帮助。