可劳斯扣的核心成员最近发了一篇文章,主题呢,很直接。怎么正确使用一百万的上下文窗口?很多人看到这件事情,都以为上下文越大,模型就越强。但真正值得关注的,不是他能够塞进去多少内容,而是当上下文变得足够长之后,管理上下文本身 开始变成了 agent 的 核心能力。为什么我这么说?因为很多人对上下文窗口的理解还是偏向于聊天记录,觉得窗口更大, ai 就 能够记住更多。 但如果你真从系统角度看的话,上下文根本不只是聊天记录,它里面还有什么呢?包括系统提示词和模型的对话、历史工具调用,甚至他做过的错事注意。这些东西呢,全都会放在上下文里面,影响着他下一步。怎么判断 上下文越长,不代表系统就越轻松,很多时候恰恰相反,越长呢,越容易分散,越容易迟钝。这就是硅谷反复提到的概念, context rot。 上下文退化,你可以把它理解成上下文越来越大以后啊,模型的注意力被摊薄了, 不是他完全忘了,而是信息太多之后,重点被噪音给稀释掉了。说白了,就是你看的东西越多,不一定判断的越准。所以第一个真正该看的点呢,不是一百万上下文很大,而是怎么处理好上下文污染这个事情。 第二个点,我觉得是对 session 的 理解,很多人还是把 session 当成一个持续聊天的地方。但真正做 agent, 你 会发现, session 更像是一个运行时的工作区,只要任务发生变化,哪怕上下文还没吃满,也最好不要一直跑下去, 因为你关心的不是上下文还能不能装下,而是这些信息啊,还值不值得继续留在上下文里面。 那第三个点我觉得特别关键,就是 rewind 的 功能。很多人发现 ai 做错了,第一个反应是补一句,哎,这个不对,你换个方法。但从系统角度看呢,这种修正方式其实很贵,因为很多发生过的错误啊,还是留在的上下文里面, 那就变成了在一个被弄脏的上下纹呢,继续错下去。而 rewind 的 价值就在于,它不是纠正,而是去做减脂,直接回到了更早的节点,把失败的分支呢砍掉,然后即有效的信息重新开始。这个差别非常大,前者呢是人工补丁的修复,后者才是真正的上下纹治理。 那第四个点是 compet 和 clea 的 区别。很多人觉得这两个差不多,反正都是清一清嘛,再继续。但实际上完全不是一回事。 compet 是 让 模型自己总结刚才的历史,然后拿着摘药呢。继续跑下去。好处呢是审视,坏处是他有一定的损耗,因为你在相信模型,自己判断什么重要什么不重要,可立则不一样,可立是你自己写一份新的 brief, 告诉他呢,当前的任务是什么,约束是什么? 哪些文件相关,哪些错误路径已经排除。一个是模型替你压缩上下文,然后另一个是你自己重建上下文,这背后的控制权完全不同。 而且最麻烦的地方在于,坏的 compact 往往呢不是随机出现的,它最容易发生在任务方向还不稳定的时候。因为模型刚刚经历了很长的调试,排错试错, 注意力本来已经被严重的拉散了,但这时候你再让它去做总结,它很可能把接下来真正有用的东西给丢掉了。 第五个点是 subagent。 subagent 真正值钱的地方呢,不是并行,而是隔离。也就是说呢,有些任务会产生大量的中间输出,这些过程本身是没有必要回到主上下文的, 你真正需要的只是最后那个结论。那最好的方法呢,就是让它留在独立的上下文里头,跑完再把结果带回来。 所以这不是一个小技巧,这是 agent 系统里面非常核心的架构能力,所以你会发现一个更底层的趋势上下。我们窗口变大了,不代表 agent 系统变强,真正让 agent 变强的是你有没有能力治理好它的工作记忆。
粉丝5946获赞2.5万

好,大家好,我是小刘。呃,今天我们一起来聊一下在 codex 中上下文管理的一些技巧,那这里呢,我会讲我平时在使用 codex 当中,我是怎样进行上下文管理的。那我们先说一下背景, 什么上下文管理呢?就是我们知道我们在一次对话的过程当中,它的绘画窗口是有限的,可以看到这里是共二百五十八 k, 那 已经使用了三十二 k, 当这个上下文满的时候呢,扣代码,它会自动的压缩这个背景,这样呢我们的这个整个上下文会失真。什么是压缩背景呢?比如说猫和老鼠四个字,那就是我们绘画的主要内容,他会把它压缩一下变成猫老鼠,你看是不是压缩了,对不对? 但这样就会产生一个通病,就是产生 ai 幻觉,那也就是我们的功能开发会越用越不好用,你会发现你跟他说一个点,他就是不明白,然后呢会导致我们很崩溃。 那我们来看一下这个网友是怎么解决的,然后我再讲我自己的方案,他的方案就非常的简洁易懂,就我们都知道每一次对话呢,它会产生一个绘画的 id, 那 我们这次绘画它是存储到我们本地内存当中或者数据当中,这时候我们可以选择复制这绘画 id, 那 这个绘画 id 呢?本身上是一堆的这种字母,就我们扣带子可以根据这个字母找到我们当前上下我们所有对话, 他拿到绘画呢,可能是压缩库的,可能是不准确的,所以呢他就遇到了这个情况,他就把他哎复制到一个新的窗口当中,比如说新对话,这时候你看跟他说对吧?请你帮我进行这个功能继续开发是不是?那这个时候是不是就拿到了我们的青山崖纹?这个也可以,只是说开发的时候,那他需要去浪费更多的图层,因为他需要加载数据库,加一个内存,对吧? 好,首先我先说一下我的方案,就是这里呢,我会回顾一个上下文的文档,进行定期的总结。举个例子,比如说像这个绘画呢,他都满了,那我就跟他说,请你帮我根据当前这一次的绘画呢进行总结出一个 markdown 文件,这个 markdown 文件呢是包含了这一次的一些所有的关键信息,那你可以看我思路这样的,请你帮助我, 请你总结当前项目的关键决策已经完成的部分和代办事项,便于我下次听话加的一定要加这句话,如果说你不加这句话,他给你的可能就是一个总结性的文档,如果说你加这句话的话,他会按照 call 代词能够处理的绘画格式给你一个哎,一个合理的 bug 档,所以就相当于固定的一个格式给他。那如果说,哎,我这时候跟他说这句话对不对? 尽量用五点五模型,用最好的模型实现的效果可能是最好的。然后你比如说用五点五超高你发送一下,那这时候呢,他就会根据你当前的这个项目进行总结一个 bug 大 文件,那收下一次开启的时候呢,你就可以把这个 bug 大 文件哎给他 就是丢进去,然后这个时候呢,他就可以直接的进行上一次上下文的复用,而且呢失真不会失的很严重,那最起码会比直接使用 codex 压缩的方式会好一点,那这是我的第一种方法。第二个呢,就是使用这 codex 内置的压缩功能呢,这个我刚刚说过了,对吧?我们 正常来说 codex 也会进行自动压缩,但是它会进行四帧,但是进阶技巧就是我们可以直接让 codex 呢,每次都生成这个 prompt, 就是 给它设定一个这个啊, ajax, ajax, markdown, 这种,对吧?让它自动生成,而不是让我们手动去指定它。 那这里呢,再分享一下我自己的这个 codex 技巧,因为有小伙伴他会问我说,你视频当中平时使用 codex, 那 我先说我怎么使用呢?首先我不会把一个项目 丢到一个上下绘画里面,一个上下文绘画里面我会把它拆成多个小的功能,在每一个小的功能对应一个绘画,这样呢,我这个绘画可以赞成很大,并且呢它总结出一个 markdown 文件,再把这个 markdown 文件丢给一个新的绘画,这样呢,我们就基于这个功能在进行优化,不会去影响整个的大局。啊,能懂我意思吧? 那第三种就是我们可以使用外部的持久化工具,那这个外部持久化工具有很多,比如像我们之前说的 context 上来说,就是把原先我们的 markdown 给它缔造了外部的这种 社区部里面去,你可以这么去理解,然后通过一些更好的方式去把它读取到这个 collect。 那 每一个开源项目都有自己的方式,大家可以自行研究,因为篇幅有限,所以我这里呢就讲这几种,好吧。 然后呢?呃,这种方式呢?其实我还是建议大家使用 bit 进行管理起来,因为当我们用 bit 进行管理起来之后,我们整个上下文呢,能够更加有链路的去回溯,就是每一个版本都有对应的回溯, 我们能够很清晰的看到,对吧?这是我们整个流程,你可以看到通过这样的方式,那就是像上下文的这个管理,好吧,这呢是。呃,好了,那以上就是本期视频的全部了呢,我是小刘,我们下期再见。

如果你每天都在用 codex, 真正麻烦的不是花了多少 cking, 而是很难知道这些 tiroki 到底花到哪里了。 codex scope 做的事很窄,扫描你本机的 codex 绘画预制,然后生成一个可以直接打开的本地用量面板。 它不是一个 a c s, 也不需要账号接入页面是静态 html 页面,真实数据指导出到本地的 data j s 和 data roi j s 默认不会提交到 git 面板。最先解决的是可见性 curl 趋势调用分布、绘画排行、模型排行、额度、风险和费用估算都放在同一个界面里。 你可以快速判断 curl 什么时候涨得最快,哪个项目最好,哪个模型占比最高,以及什么时候接近额度压力。 数据流也很透明。 codex 把绘画日记写到本地 sessions 目录生成器,只提取用量元数据,再交给浏览器渲染。 dashboard 隐私边界是它最重要的设计之一。它会导出绘画 id、 目录名、模型名、 t o 梗数量和 read limit 原数据, 但它不会导出提示词就手回复工具输出或文件内容,也就是说它看用量不搬走对话内容, 普通用户不用自己编辑去 git up readies 下载 macos 或 windows 平台包,解压后双击启动脚本就能打开真实用量面板。 所以 codex scope 的 价值不是做一个复杂平台,而是把你本季已有的 codex 用量数据变成一个可信清量、能马上打开的观察窗口。

很多人最近在用 gpt 五点五 cortex 或咳嗽的时候,都会有一种感觉, token 消耗特别离谱, 甚至一次任务几十万 token 就 没有了,复杂一点,直接上百万。呃,很多人会疑惑,我明明只问了一句话,为什么会这么贵?其实你看到的只是表面回复,那真正消耗 token 的 东西在后面, 我积累咳嗽某一个时间段使用的用量,有些任务的话是几十万, 有些任务的话就是上百万了。可以从这张图看出来,就是一次任务耗费的头肯还是蛮多的。 那以前的大模型更像 chatbot, 你 问一句,他答一句。但现在的 ai 编程模型,尤其是 g b t 五点五啊, cloud code 啊, course 啊,已经越来越像 agentic workflow。 呃,也就是它不只是直接回答,而是在后面 有思考,有扫描工程,调工具,写代码,呃,有测试,有反思,有重试,最后才给你结果,这是完整的一个流程。 呃,我们先来说第一个吧。嗯, reasoning。 很多人低估了 reasoning 的 token 消耗,因为你看到的是一句回复,但模型内部可能已经思考了很多轮。比如 你让它修复一个复杂的 bug, 它会分析日制,猜测原因,排除错误路径,对比多个方案,规划修改步骤,这些过程都会消耗 token。 而且,而 reid 零越强, token 往往越贵,这也是为什么 gpt 五点五比传统的叉模型贵很多的 原因。第二个核心就是呃工具的调用。呃,现在很多 ai 编程工具已经不是单纯聊天了,他们会呃读取文件,搜索代码、 grip diff, 跑测试,看日制。呃,你以为只是帮我修一个 bug, 实际上后面已经扫描了几十个文件,而且这些都会进入上下文。这是 ai 工具调用的一个 workflow, 可能是长这样子的。 嗯,还有一个很多人没有意识到的东西, hide and context。 很多 ai 工具会偷偷塞大量上下文,比如,嗯, system prompt, roles agents, reporters, summary 文件加载历史对话工具的输出, 虽然你没有看到,但模型其实全看到了。所以真正进入模型的 context, 呃,可能远远比你想象的要大得多。 所以 ai 编程可能会越来越贵。并不是因为模型回答字数变多,而是 ai 正从 chat 变成真正的 工程执行系统,它开始主动分析,主动规划,主动调用工具。呃,主动执行流程。本质上,你不是再买一次回答,而是再买一次工具执行过程。 最后做个总结吧,就是真正废 token 的 地方不是回复本身,而是 reasoning planning to use context engineering agent workflow。 未来 ai 编程一定会越来越强, 但同时 token 的 成本也会越来越重要。如何控制 context? 如何拆任务?如何减少无效推理,会变成新的工程能力?嗯, ok, 这里是 context 的 工程实践。下一期我们继续聊,为什么大仓库加全量上下文会让 ai 编程直接失控?

那本期给大家分享一下我是如何用 codex 实现用 ai 来去做一个账号自动化运营的这个过程。除了录视频这个事情以外,那其实还有很多的 运营的一些琐碎的事情,比如说我要去看我的账号数据,视频录完了我还要写封面标题等等,这些琐碎的工作其实很多,它不是光是录制一个这么简单的事情, 现在我的流程是可以这么做的。我现在是用 ai 的 这个 computer use 这个功能,直接去我的创作者中心帮我去把所有的账号拉出来,在本地上分析,分析完以后它会沉淀出几个特定的文档,这个文档呢就是我的这个 粉丝的文档,账号定位的文档,内容策略的文档。那基于这几个文档, ai 就 会去读取了这几个固定的文档以后,去帮我搜索相关的同行的一些对标的文档以后,去帮我搜索相关的内容, ai 就 会一个一个介绍一下。 每一次我视频拍完结束以后导出字幕,它就可以基于我的这套方法论,帮我批量的自动化的把我的视频的封面标题、描述标签全部搞出来。那也就说现在的主要是它在于你 内容我们已经拍摄好以后的那些环节,那内容的生产前面还是主要是由你自己来想的,不是内容生产前面数据分析它会给我选 dj, 它会跟根据你的账号定位去帮我们来看一下实际的效果就好。那你看 在这里我跟他讲我用了那个 codex 里面 computer use, 他 可以操纵我的浏览器嘛?然后去访问我的这些账户,我让他去分析一下,呃,跟我相关的一些对标账号,然后他是优先读取了我四个 m d 的 文档,嗯,这个文档里面是有我的粉丝画像的,呃,有我的所有的账号的策略定位,我的爆款的复盘, 以及我的选题方向的这几个定位,这是我之前就会有一个引导对话,我这边就跟他讲,我说我发现这些内容太过时了, 你要去重新帮我把这些内容梳理出来,他本来已经准备在做了,最后发现他读的内容太旧了,你就改了他的方向。对,我先去帮你更新你的这些账号定位,对,我要去更新,这个时候我就跟他说,我说你去读去账号吧,你看他在这里面先读了五十一条小红书的内容, 又去读了所有抖音的数据内容,那小红书的所有的明细,然后抖音的所有明细他自己全部读完了以后存在本地,基于这些内容 他开始来做重要的判断,他这几个判断内容是自己判断的,还是你给他自己判断?他根据我的数据分析了我的账号内容,爆款的内容梳理出来的, 那他总结了以后,我说好,那你居然已经调研完了。我说你去把我之前的粉丝画像,账号策略,你去更新一轮,他就叭叭叭叭叭叭更新了一轮最新的内容,所以这是他最后给我的一批我的一些材料,基于这些材料以后,他才会帮我去做这件事情,根据我账号的策略定位, 去帮我寻找跟我匹配的账号的数据。好,注意到小细节,这边这个选题推荐这个 skill 是 你自己写的还是你外面找一个?是我跟他之前合作沟通出来,就是你刚才这生成的一些整套 skill 形容一个,对,是的, 这个里面他就会拿了我很拿到了很多的标题数据。嗯,然后他就给出了所有我这个像内容的爆款的一些封面的建议,然后包括他还给我了一些我能做的选举的建议,都是爆款的选举建议。嗯,好。然后这些内容我跟他讲,我说你要去思考一下你怎么样去更新到现有的 skills 里面。对, 你看他就告诉我直接可以写进 skills 里面的一些规则。好,然后我们看一下我怎么使用的。嗯,然后当我这边输入案例包装,它就自动去调用我的 skills, 然后它的 skills 都是关联在一起的,然后当我把我的字幕给他以后,它就会自动唤起它的一个写作的一个 skills, 然后来去把我这个整个包装发布的内容给它写出来啊,包括标签,包括里面的封面。然后呢?有了封面以后,这个时候他会说他去调用封面 skills 来处理这个图,他就做了好多,你俩玩起来啊,然后他就做了很多不同的图,它还会自动去生成, 因为我还有别的平台,所以它就会生成不同尺寸的图片,你看生成各种尺寸的这个图片给我,生成完了以后,它其实是标题描述标签都是有的,我直接复制就结束了。对,这就是一个全的流程,其实这套方法论 就是最重要的,其实它是不断进化,不断迭代之后。现在不是有那个 codex, 不是 有那个定时功能吗?比如说每个礼拜五去 check 我 所有的视频数据,然后去自动化更新我的相关的一些策略。写作啊,对,写作 skill 更更新过去以后,我每次用到都是新的,就它可以跟着我的账号一同成长,我觉得这个是很牛的。然后再比如说你看这这次的内容生成完了以后,我发现有些过程是可以调优的啊,这个时候我就跟让它去 思思考一下他学到了哪些经验,然后将这些经验告诉我,然后我来判断这哪些经验可以沉淀为 skills, 然后这样的话他下一次就不需要我再教他了,你看他会整理出一批,然后呢?我确认过了以后,他会说他更新了 skills, 他 整理了哪一节步骤,所以我的 skills 是 越来越能够符合我的要求的, 而且再加上 image two 这个深普能力来了以后,封面指出的概率非常高了,我几乎很少去调了。那现在你的就是整个工作流程里面,哪些是 ai 帮你做,哪些还需要你人来做?呃,现在目前我在坚持真人拍摄,然后包括其实选集主要还是我们自己来,就是视频剪辑完了以后,我们直接字幕出来了以后, 视频的封面啊,描述、包装、标签,各个平台的封面的差异,全部都是 ai 在 做的啊,你就露了一个前面就是拍摄前面的啊,就说选题的大纲的准备,嗯,对,选举其实我们自己在准备,但是选题大纲我们会让它来梳理 一下。对,其实我先把我自己,因为我们有的时候内容会需要很多配套的一些材料,比如说我今天要讲 q d s, 嗯, q d s 背后很多一些功能背景,它会帮我收集很多资料。准备好或者这样子,然后呢继续接资料,然后一个大纲, 然后呢?大纲我确认好后再去输出一个 ppt 大 纲, ppt 大 纲里每一页需要画什么,嗯,然后时候再用,再用 ppt skill, 它会帮我做 ppt, ok, 这样子。 嗯,所以这是我们拍摄之前的一些准备。对,其实下次我们可以分享一下拍摄前的一些内容准备,对,这个是我们拍摄完以后数据输出,对,运营数据输出盘,对对对,是,然后最后一个想讲的就是我的整套方法论并不能让我的所有的内容都成为爆款, 是因为去不断地才根据我现有的数据去给我提供建议,也就说他其实是跟我一起成长的。嗯,所以他并不能让我一个 偏账号小白的人立刻成为一个每天爆款的大牛,他只是能不断地基于我现在的重复工作帮我去减少跟我的工作量,就是他没办法取代你的经验。对,他也可以取代你的流程。对,是的,所以他不能让我立刻就变成一个大牛啊。对, ai, 现在时代就是这样,就是成为你能力的杠杆。 对,他是我能力的最上限,所以这个就是我们今天想要分享的,然后包括这一期准备了哪些 skills, 到时候我会变成一个文件,然后放在我们的那个群文件里,大家可以去参考一下。好,那本期视频就这样,拜拜。

今天是我们 codex 的 第一讲 codex, 它到底解决什么问题呢?其实 codex 最值得讲的地方就是它把 ai 写代码拆成了四种工作方式, c l i、 ide、 桌面 app 和 cloud。 你 可以在终端里面慢慢改,也可以把它 交给 cloud, 在 云端上慢慢跑。那接下来我就带大家一起来看一下这四种形态。好,我们先来看 c l i, c l i 适合及时的迭代,然后来读代码、改文件、跑测试、解释、报错,你坐在旁边验收它,一步一步来推进 c l i, 你 可以在终端里面直接去输入 codex, ok, 当你看到 openai codex 以及它的 model 显示的时候,就代表你已经进入到 c l i 里面了。接下去你就可以直接跟它去进行一个交流,比如说我现在可以切换对目前最高的,它就指到 g p d 五点四, codex 的 桌面板目前已经支持 windows 和 mac, 这里你看到的就是 codex 的 一个桌面版的一个页面,它就比较适合多任务并行。你看我在一个界面里面,这里就打开了深图的,然后打开了很多做课件的,对吧?以前还有一些做项目的,它是完全都可以并行的,包括这里会展示一个自动化的一个入口,就我配置了一个日报和 ai 日报的一个素材沉淀, 还有一些插件。啊,这个我们在后面再去细聊。那接下去我们来看它的第三种形态,是 ide, ide 的 话,你可以在 vs code 或者是 codex 里面都能够看到它的一个 codex 的 面板。我现在点击 codex, 在 codex 里面,我们在左侧面板的上方点击这个下滑箭头,看到这个 codex 就 可以进入了, 那这里恰巧是我用的比较少的地方,像 ide 呢,它比较适合你,左侧就是派发任务,右侧来看代码,比较适合已经习惯在编辑器里面工作的朋友。 好,那最后我们来看一个云端的入口,可以打开你的浏览器啊,上面就会有啊, g p t 点 com code 在 这里呢。云端的入口呢,比较适合后台的任务,你可以把你的仓库和任务交给他,他会在一个隔离环境里面跑,最终给到你一个可 review 的 一个结果,这里你就会可以选择你的一个 github 的 一个远程仓库了。今天这一节呢,我们主要来认识一下 codex 的 四种工作方式。 ok 啊,今天我们就先分享到这里,拜拜。

code s 又更新了一个功能,而且这次更新很关键,以前它更多是帮你写代码、改代码、分析项目。现在它开始进入谷歌浏览器,直接处理真实网页任务。第一步,只需要在 code s 桌面版里面安装谷歌浏览器插件, 然后在谷歌里也安装 codex 插件。安装完成后, codex 就 可以和 chrome 配合工作,它能做的不只是打开网页。像这种重复性的浏览器工作,比如看页面、整理信息、填写表单、录入数据,它都可以一步一步帮你完成。你可以看到,它不是只在聊天框里给建议,而是真的进入网页流程里面执行。 重点是,它不是机械地点来点去,它会读取页面内容,然后再一步一步完成操作。对普通人来说,这 就像多了一个真正会干活的网页助理。更厉害的是,如果一个任务需要多个工具,勾代斯会自己选择更合适的方法,需要浏览器他就用 chrome, 需要代码他就写代码,需要多个页面配合,他也可以跨标签页完成。所以这次更新的重点不只是多了一个插件, 而是 ai 开始从回答问题变成真正执行任务。整理资料、检查后台、填写表格、处理重复网页操作以后,都可能交给这种 ai 助手。简单讲, ai 不 只是告诉你怎么做,它开始进入浏览器,真的帮你干活了。

你的 codex 压缩上下文的时候是不是经常卡死?教你一招,用五点三来压缩,然后再切回五点五, ok。

codex 用了三个月栽过的坑里有一个让我直接反攻三次。今天把五个最容易踩的坑全告诉你,别走我的老路。第一个坑,不写 a 整数的 md 就 开干 codex 没有约束的时候,他会自作主张,你让他修一个 bug, 他 顺手把整个文件重购了。 agent 打 n b, n b 不是 文档,是给 ai 划禁区的法律。第二个坑, sandbox, 用默认配置默认一下。 codex 的 可读范围比你想的大,生产仓库一定要加上 codex vgr write, 把它锁在工作目录里 这一行参数,避免后患。第三个坑,也是让我反攻三次的那个 context 不 清场,跨任务污染。我连续让 codex 干两个不相关的功能,中间没清空上下文, 结果他把昨天 a 功能与 user id 字段的命名规则和今天 b 功能的订单接口混在一起,代码看上去能跑, review 时才发现命名整个对不上,我重写了三遍才理顺。后来我每开新任务 b clear 这一个习惯救了半条命。 第四个坑,审批模式直接开全自动,听起来爽,实际上 codex 偶尔一冲动就把你的依赖所文件删了,或者把分支 force push 掉。全自动模式只在一次性沙盒目录里用真实项目永远开人工确认或者 on failure。 第五个坑,验收只看 codex 自己的输出,他说测试过了你就信,他说 build 通过了你就信。永远自己跑一遍, codex 偶尔会在脑子里跑测试,然后告诉你都过了,命令根本没执行, 一人公司最贵的就是返工时间。这五个坑你只要避开任何三个,效率立刻翻一倍。你踩过哪个坑?评论区聊聊。

经常用 cloud code 或者 codex 这类 coding agent 的 朋友,应该都会挺关心 token 消耗和上下文管理这两件事情,但我发现哪怕用了一段时间的人,对于让 agent 做什么事情会消耗 token 这件事认知偏差还是挺大的。所以今天这条视频就给大家讲清楚两个事情,第一个是 token 和上下文 context 到底是什么意思。 第二个也是最重要的,让 agent 做什么事情是会消耗 token 的, 而哪些其实根本就不消耗,也不占用上下文。刚好 cloud code 的 官方其实做了这样一个特别直观的交互式的界面,把你从打开 cloud code 跟它进行多轮对话的整个过程中,它的 上下文是如何累积的,然后每条指令它消耗多少 token 全都非常清晰地画了出来。下面我们就顺着这个界面把这件事情讲明 来。首先就是在我们输入第一条消息之前, agent 它的上下文里面其实就已经被装进去一堆东西了,这里就包括系统的提示词,这个是 histogram 官方写的用来约束 cloud code 行为的一些固定指令。然后是 memory 文件,是之前你看 cloud code 的 绘画里面 agent 自动记下来的一些 笔记和记忆。然后第三个就是环境信息,包括当前的目录、操作系统 get 状态这些,还有 m c p, 还有就是我们非常熟悉的 skill, 还有 cloud 点 m d 这些 map down 文件, 这些都是固定成本,只要你打开一个 cloud 的 绘画,哪怕你一个字都还没有说,这些出土化的上下文就已经加载好了。那从我们发送第一条消息开始,托管是怎么一步步消耗的?这件事情我们站在 agent 的 工作流程的角度来看,就会特别的清楚,你 输入一个任务, agent 会首先理解你的指令,你的提示词本身就成了上下文的一部分,然后他会,然后他会触发绿的命令去读上下文的一些文件,读完他可能会做一些思考,思考完之后可能又会调用一些工具去读一些新的文件,或者跑一些命令去拿输出, 然后再基于得到的结果继续去做思考,这样进行反复多轮,最终他判断任务完成的差不多了,需要你的介入了,就会给你输出一条摘药返回给 给你。把这个流程总结一下,其实 agent 在 你输入完之后干活的其实就这四件事情,第一个就是去读你项目里面的一些文件,第二个去跑一些命令 或者执行一些工具来拿到一些对应的输出,第三个是进行一些思考和推理,第四步就是把摘要总结输出给你,这四件事情产生的所有的内容都会消耗 token, 然后进入到 agent 的 上下文里面。 那么讲到这里有两个事情是我觉得新手比较容易去误解或者搞混的点,这里需要重点去讲一下。首先第一个点就是跑命令本身是不消耗 token 的, 举个例子,你让 agent 把一条两个小时的音频转成文字,或者让他跑爬虫去抓取各个社交媒体上的数据,只要你有现成的脚本或者写好的 skill 让他去执行。这个执行过程中用的是你电脑的算力, agent 本身并没有去参与,所以这个过程哪怕很复杂,跑了一两个小时才跑出一个结果,也不消耗任何的 token。 只有当这个脚本命令执行完之后, agent 真正开始要去读这份结果文件,比如说你让他翻译这份文字稿,或者是基于爬虫的数据去提取观点等等,他必须读完这个原始内容才能开始干活,这个时候才会真正地去消耗 toker。 单纯的脚本执行过程中,无论跑了多久,他都是零 toker 消耗的。 toker 消耗只发生在 a 件的, 去读你的执行日制或者结果,这是我觉得新手最容易搞错的地方。那第二个点就是说,我们去在任务过程中去挤起用子代理的一个情况下,也就是 sub agent 子代理他执行的过程中,我们可以看到他本身是会消耗各种 token 的, 但他消耗的 token 是 累积在子代理自己独立的上下文里面的,不会污染到我们这个主体制。等子代理只是读到这样一份招标文件是消耗 token 的, 所 所以此代理是一种隔离消耗的方式,你让他干一堆需要读大量内容的活,但是主代理的上下文并不会因此受到污染。总结来看,我觉得官方的这个交互式页面真的非常的直观,浅显易懂。如果你对于 cloud code 的 上下文机制还不是特 特别清楚,我非常强烈建议大家去这个页面玩一下,你能够非常清晰的看到 agent 的 上下文是怎么加载的,然后 token 是 在哪些环节去消耗的。有了这个直观感受之后,以后你跟 agent 的 对话,让他干活的时候,就能比较准确的判断哪些事情真的会在消耗你的 token, 而哪些事情看起来可能很复杂,但因为只是脚本 或者命令在跑,其实根本不会消耗多少 token。 ok, 这期视频就讲到这里,如果大家觉得有帮助的话,帮我点个赞,我们下期再见!

大,真的是一个头两个大呀。大周末的,刚起床跑了一下任务,五月六号买的 plus 会员到现在就只剩下百分之三十四了, plus 是 完全不够用。 我这边找了一篇文章,几个技巧能够彻底解决扣袋子跑久了会越来越笨,越来越慢,还能省掉百分之四十上下文的一些技巧给大家分享一下。这篇文章说一下我的理解。第一个,扣袋子跑久了之后会越来越笨, 越来越慢,这个是基本成立的,但是其实逻辑上不是因为模型真的变笨了,其实绘画的上下文越来越长,旧的一些信息,过激的计划, 一些失败的尝试,都混在一起,就会让我们体感上觉得迟钝。判断是对的,如果是有效,上下文的质量下降了,就会导致整个推理和执行的质量下降。第二点,关掉 process location 方向是对的,但不是万能的。减少输出规划的趋势确实能够减少偷客的消耗和噪音,但是问题是,如果你不让 agent 去汇报他这个过程,你也是很难发现他是不是走偏的。尤其是像我们做一些比较复杂的产品架构,涉及到一些复杂的 bug 解决,那适度的汇报还是要看的。 所以并不是说你在那里一直执行你就该干嘛去了,这是非常不合适的。所以更合理的做法就是简单的任务让他少说那长任务,保留一些关键的进展,就不要去输出这种长的身体活动,不要把每一步的工具调用都解释一遍, 这招是有用的,但是全部是被 token 这件事情是说的绝对。第三点是让 code 子当协调者都用 sub agent, 这个是部分对,但是不能滥用。 sub agent 确实能够把一些探索性的任务分散出去,但是主要是你的目的是为了减少上下文的污染,但是只有那种多模块变形调查 架构,审查大代码库的一个区域分析,要变形解读很多的文件,这这一类才是比较适合的。 但是他也会有一些问题,那指 a 诊呢,也会犯错,而且主 a 诊呢还要去汇总他的结果,所以如果本身的任务是限性的,那你多开 a 诊的反倒会增加他协调成本。那么你们讲到的同时开五个,就相当于五个上下文的并行。 这个方向是对的,但是很容易让别人误解,开的越多越好,那实际上只有那种并行边界清晰的任务才值得猜好。第四个是先列他这个例子的 再动手。这个建议其实是很实用的,特别是在一些大大的一个项目里面,你的 prd 原型在任务池并存的一些项目里面,先列任务就能够防止它改错文件,越界重构,甚至是忘记同步相关的一些文件,做到一半就偏题了。特别是像 有时候网络还不稳定,但是小人物就不需要复杂的计划了,比如改一个方案,一个就直接改就好了, ok。 第五个是禁止在代码库里留垃圾,对,而且非常重要。现在 ai 的 一个常见问题就是说它生成的临时脚本,它不删留 delete 文件, 复制旧版的一些文件,乱建一些草稿,把 etc 的 分析结果写进仓库里面,这都是它的问题,会让这个项目越来越乱,也会让后续的 a 制误读项目的状态, 不过这里要区分不是所有的 m g 啊,后缀的文件都是垃圾,那有些是长期的,一个上下文的资产就不是污染好。第六个就是规划,用高推理的模型,执行用快速的模型,这个策略比较合理。 我最早去考虑这个事情的时候,就是因为价格的问题,比如说好的模型,贵的模型去做推理,你把他执行的要求给到一些 poke, 比较便宜的模型去做执行, 也对,看有没有这个必要了。总之一点,如果你的执行模型能力不够,那你就可能把你的规划 在外,所以在切换模型的时候就要把边界写的很清楚。我个人理解,除非你的后坑消耗是巨大的,不然我就觉得没有必要折腾。其实这就是在解决上下文丢失和重复犯错的问题。最终的结论就是,整个他的博主分享的这个文章核心方向都是对的。 后段时长时间的工作质量下降,主要来自于上下文的污染。项目状态不清,无纪律和无记录的写作大概就是这样子的。确实, 连续二十八天都是在每天早上七点钟起床,无论前一天晚上几点睡都是这样子。晚,对,非常晚,四五点才睡,今天睡到大概十点多,整个脑子居然会比较清醒啊。 今天就分享到这里,后续会继续去分享一些 holddance 的 使用体验吧。

hollyx 的 官方文档我翻了三遍,还是有几个特别好用的斜杠命令,没系统讲过,今天一次讲完,每一个都是日常高频记下来,今天就能用少一个,少一半效率。第一个 slash fork, 从历史的任意一部分叉出新绘画, 特别适合我,想试个不同方案,但又不想丢掉现在进度的场景,试错成本直接归零。这一个命令顶半个分支管理工具,做实验探索的时候必备。第二个 slash compact, 绘画太长,上下文塞不下的时候,它会自动把前面的内容总结压缩成经典版本, 比你重开绘画再黏贴一遍快得多,关键是不丢上下文,长任务的救命稻草。第三个 slash mansion, 显示,把某个文件加进上下文,比让 codex 自己去搜文件效率高十倍,特别适合你。已经明确知道要改哪个文件的时候,省下的 token 都能用来干正事,不浪费在乱搜上。 第四个 slash review, 让 codex 审查他自己刚刚写的代码,听起来很奇怪对吧,但实际效果非常好,因为换了个角色,他就会发现之前写代码时没注意的问题。自审一遍 bug 率直接降一半,这个技巧大部分人都不知道。 第五个 slash status, 实时查看当前绘画用了多少 token, 上下文还剩多少空间长任务必须时刻盯着,看到快满了立刻 compact, 这是不掉智商的关键,盲跑就是慢性自杀。第六个 slash feedback, 直接在 tui 里给 openai 团队提反馈,我提过的两个问题后来都修了,说明真的有人在看,遇到 bug 或者想要的功能别憋着提了,说不定下个版本就有了。六个命令全是日常高频,每一个都能在关键时刻救命。记下来,下次开 codex 直接用,效率不止翻倍。

哈喽朋友们,我是阿水,今天给大家介绍一下,我用 codex 微博抠定了一个可以代替我干活的小插件,从设计稿的生成再到切图交付, u i 设计师必看的这一期,如何一分钟看完别人一整天的活,那这个插件呢?纹身图和图身图 目前都是支持的,首先是在这里可以选择纹身图,那这里呢,我们输入简单的提示层描述就可以,然后要做移动端的话,直接选择九比十六,那或者需要根据自己的需求我们自定义尺寸也是 ok 的, 那图片数量呢?这个就没有啥要求了,好了之后呢,我们就直接点击生成设计稿按钮, 这个速度大概是在一分钟左右就可以完成,好了之后呢,我们就可以选择要切图的图片,点击切图按钮,然后用鼠标直接框选就可以。鼠标拖动的方法切图可以说是非常的方便,我们只需要在页面上点击鼠标 画一个句型就可以选中切图,无论是大一点的 icon 还是按钮,以及我们在底部的这种 tab, 还有页面上的这种小箭头主标题也可以用这个方法来切出来。当然如果我们想要把 icon 的 背景给它变成透明的,我们只需要点击透明的按钮 就可以了,正好的一点就是针对单个的按钮可以自己自定义设置。那切图好了之后呢,我们就可以导进 figma 里面,可以看到刚才切好的图片,它已经单独帮我们进行了图片分层,而且有一个特别好的点是 我们把单独的 icon 切出来之后,它原图的背景上面的 icon 就 会没有,就会消失,并且呢,它填充的颜色也和我们的背景特别的相似,几乎看不出来有颜色填充的痕迹。那其实到这一步呢,完全可以是一个可交付的一个状态了, 因为我们的图已经切好了,只需要交付给开发就 ok 了。那除了纹身图,其实图生图的方法也是一样的,必要是我们手动设计的环节,全程都是由 ai 去工作,而且呢,大家可以看到切完图之后,它的原始背景上面,你当前切图的这个 icon, 其实它已经从背景上面消失了,并且呢,它用了一个色块填充,而且呢,它填充的这个色块也是很好的,而且呢,对于透明的这一点,它做的也非常的好,就是呢,它把你的 icon 主体给你留下了,但是背景呢,它真的是透明了,这个真的是特别的方便。我做这个插件呢,其实 初心是因为我没有飞格玛的教育版,也没有飞格玛的会员,那所以呢,我没有办法去使用 m c p。 然后呢,这个插件就诞生了,这个也是一种 没有会员,没有教育版的一种解决方案。那如果大家对这个插件有什么要求或者建议更好的功能点,那大家可以在评论区和我讨论,而且想拥有这个插件的也可以直接在评论区找我来拿,我是阿水,大家记得点赞关注评论哟,我们下期再见,拜拜。

codex、 cloud code、 gemini、 openclaw, 这四个工具究竟在什么场景下是适合的?在什么场景下又需要互相串联起来?今天这个视频不废话呃, 我将会带着大家去看一下我日常是怎么去使用的,把这些经验也分享给大家。首先呢,我们可以看到啊,这四个工具呢,其实有各自适合的场景,比如说 codex, 它其实适合去抓取一些信息,去做一些批处理和定时任务 啊,或者说去要逐步推进一些步骤的时候,它可以开启这个全自动化的流程。那么 cloud code 呢,它可能会更加偏向于去写一些底层的代码,或者是去编写一些 skill 啊,尤其去适合去做一些打底层的一些能力。 那么呃,这个 openclaw 呢,它更加适合去把人啊,还有设备以及我们自己的这些 agent 和 skill 串联起来,可以在一些出差路上,或者说你在不方便去使用电脑的时候, 采用这个 openclaw 去把一些任务推送到对应的我们这个手机的飞书啊,钉钉啊,或者是用这些外部的这个沟通工具去给你的这些智能体去下一些这种指令。那么 germina 呢,其实它会在文本转 啊,这个图片或者图片转文本的这个方面会比较强,所以说呢,他可能会适合去生成一些图片,或者去生成一些设计稿。好,那以上呢,我们简单的做了一个了解,包括我现在的这张屏幕,其实也是用 啊这个 codex 帮我写的啊。那么 codex 呢,其实在这方面抓取信息,输出一些网页其实也还是非常强的,最关键的是它的这个费用也比较便宜,所以那我们用一个案例来看一下,举个例子 啊,比如说我们要去看生成一个这个 ppt 啊,生成一个 ppt, 那 么一共呢会分为五个步骤,第一个步骤呢,可能要去做一些信息的抓取,是吧?然后去做一些定时任务,那这个时候呢,可能会是要需要用到就是 codex。 举个例子,比如说啊,我现在这里呢,就会有一些定时任务啊,给大家看一下。比如说呢,我会去抓取每天的一些早报,比如,比如说在这里 啊,每天都要去按照我自己定的这个标准去执行这些,去抓取一些早报。那早报的这个啊,效果呢?给大家看一下啊,举个例子,比如说啊,这些,呃, 这个每一天的这些新型的科创版的一些这种,呃,关于 ai, 关于人工智能、关于商业航天的一些新闻或直接推送过来。那么后续呢,还会有一些 github 的 一些项目,那它的这个任务呢,是完全自动化的再去做的啊,完全自动化, 也就说首先我们可以用这个,我们可以用这个,呃呃 codex 去做一些自动化的任务啊, 其实这样,那么除此之外呢啊,本身啊,就这些 skill 啊,这些 skill 可以 用 cloud code 直接进行编辑啊,直接进行编辑, 或者说我们打底的去做一些这种小的网页,或者是去做一些这种生产化系统的时候,可以用 cloud code 来去完成,因为它呢本身也可以去支持一些啊, s d d 就是 spot coding 啊,不像是原本完全之前的 web coding 这种方式。那第三个呢?是 codex 啊,第三个是 这个 codex 呢,它其实可以将前面的这两个东西串联起来,举个例子,比如说我们之前的一些这个网页的一些输出,还有一些文章或者是一些早报,其实它可以把这些 skill 和我们前面抓取到的信息做一个串联。那第四步呢, 可以根据这些早报和抓取到的信息,去让 notebook lm 去帮我们生成一些 ppt 啊,然后举个例子,比如说我们做到的一些 ppt, 大家可以看一下 啊,比如说这个也是我们之前做的啊,这个一些 ppt 的 一些啊,效果对吧?啊,它的这个效果还是非常不错的, 给大家看个大概啊。那么最后呢,就是如果你正好也是在出差途中啊,那么这个时候你可以用这个 open club 去接入到你的个人微信,飞书钉钉、企业微信等等,然后去把这个信息给你推送过去,或者说你不太方便查看电脑的文件,那你就直接让这个 啊,你的这个龙虾去帮你把这部分内容抓过来。所以以上呢,就是呃,我在使用了这么长时间,这个这几个工具给大家去做的一些总结啊,如果说有问题或者是想要去交流的话,也欢迎大家在评论区或者私信啊,谢谢,拜拜。

你以为你会用 codex 吗?这条视频给你看七个真正的高级命令。第五个,百分之九十的人都没用过,少一个少一半效率。第一个 codex 空格双横杠, full auto。 这是日常开发的甜蜜点,自动批准读和写,但敏感操作还会问你, 你直接优了安全比默认模式快,是写代码的标准启动姿势,每天开工第一行命令就用它。第二个 codex 空格, resume 绘画被打断了,不要慌,敲这个命令直接恢复上次的进度,上下文一点不丢。我每天早上开工的第二个命令就是它,比重新解释一遍项目背景快得多。第三个 codex 空格双横杠。三 dbox 空格 read only, 专门给探索代码用了止读模式,读老项目,查依赖看历史,写文档不会误。改一行代码,安全感拉满,做代码考古的时候必用。第四个 codex 空格双横杠。 profile 加名字,给不同场景配不同的 profile, 比如 review 的 profile, 用更强的模型止读跑 c i 的 profile, 跑非交互模式,不用任何确认,切换一行命令搞定,不用每次手动调参数。第五个,敲 codex 空格 m c p。 这是真正的杀手锏,让 codex 把自己暴露成一个 m c p server, 其他 agent 比如 cloud, code, cursor 都能调用它干活。 一个工具变成所有 agent 的 能力扩展,百分之九十的人都不知道,还能这么玩?知道的人已经在搭多 agent 写作了。第六个 codex 空格双横杠。 s d r 授权额外的可写目录。 比如你要让 codex 同时改前端和后端两个仓库,加这个参数就能跨目录工作,不用来回切目录切上下文。第七个 codex 空格 exact 空格双横杠 jason 加一句话,非交互模式加接送流式输出,专门给自动化脚本用。我的视频生产 pipeline 就是 用这个调度 codex 的, 能嵌入任何工作流。

很多人第一次用 cortex, 都会经历一个阶段,一开始觉得这东西太强,但后面又觉得怎么越来越难用了?最后很多人得出一个结论,模型不行。但其实很多时候,问题不一定是模型, 而是你的 ai 工作流有问题。呃,很多人现在怎么用 cortex 呢?其实非常简单粗暴打开,嗯,直接开聊,然后,嗯,加功能,改 bug。 patch, patch, patch。 整个 session 一 路硬写,看起来很高效,但实际上这个过程非常容易失控,因为 ai 并不擅长无限持续混乱开发。核心问题有几个? 第一个是没有 task boundary, 很多人什么都在一个 c 型里做,嗯,比如修 bug, 改架构,做 ui, 写测试,调 prompt, 全部混合在一起,结果上下文越来越乱,最后 ai 根本不知道当前真正目标是什么。 第二点是没有 plan。 很多人想到什么就直接让 ai 改,但在复杂的工程里,嗯,没有 plan 其实特别危险, 因为 ai 会不断局部修复,最后派去越来越多,整个系统越来越不可控。 三、没有状态管理这是很多人忽略的问题。 ai 本身其实没有真正长期稳定状态, 它只能依赖当前上下文。所以如果你不主动管理当前目标,当前阶段、当前约束, ai 很 容易把旧信息、错误方案、历史 patch 全部混合在一起。 真正长期使用 context 的 人,其实已经开始管理工作流了。比如 task allocation, 一个任务一个 session, 不要无限续聊, step execution, 先规划,再分步骤执行,而不是一一口气让 ai 改整个系统。 summary 阶段完成后,主动总结,重新开始新的上下文 plan 复杂任务,先让 ai 做 plan, 确定没有问题, 再开始写代码,这其实已经非常接近真正的软件工程,这就是普通用户和工程化用户的一个区别。 呃,在往后呢,很多,嗯,长期使用 cortex 的 人,甚至,呃,还会管理项目上下文工作目录 roles 呢?忽略文件, a j s 文件,呃,因为他们已经意识到 ai 编程不是聊天,而是 cortex engineering。 我 们来展示一下忽略文件吧。 嗯,这就是 cortex 的 一个忽略文件,其实跟 get 的 忽略文件意思是一样的。 呃,然后还有一个 excel 的 文件, excel, 嗯,这是 excel 的 文件。如果你的项目很复杂,呃,有很多模块的话,也可以在模块下面放一个 类似的一个文件,用来管理当前的模块,然后根目录下面的这个文件呢,是管理整个项目的, 呃,所以很多人用不好 cortex。 问题不一定是模型,而是还在用聊天的方式做工程。真正重要的能力其实是 ai 工作流管理。这里是 cortex 工程实践。 下一期,我们继续聊,为什么大仓库加全量上下文会让 ai 编程直接崩掉?

很多人不是不会用克劳德抠门,而是根本不会管他的上下文。你有没有发现,跟克劳德抠俄或扣 ducks 聊到后面,他经常不是更聪明了,反而越来越飘? 很多人会怪模型不稳定,但说白了,更大的概率是你把它的 context 对 坏了。我今天在 x 上看到克劳德扣团队塔里克写的一篇帖子,看完我就一个感受,这篇讲得很透,他讲的不是模型有多强,而是一个更实际的问题,为什么 e m context 很 强,但也很容易把自己聊废? 先说人话,什么叫 context? 上下文就是模型这一轮能同时看到的全部信息。 这里面不只是你的最后一句话,还包括系统提示词、聊天记录工具调用工具输出,还有他读过的文件, 这些东西加起来才叫 context pane, 也就是他当前脑子里真正装着的东西。克劳德扣的现在有一百万托肯,也就是一爱姆康泰克斯特,听起来很棒,对吧? 但这篇文章最值钱的一点就在这,大不代表你可以乱塞,更不代表他会一直保持同样聪明。 因为上下文一旦越来越长,模型的注意力就会被贪薄纠信息、杂信息、无关信息会开始干扰当前任务。 作者用了一个很关键的词叫 context, 你 可以把它理解成上下文开始变质,开始腐烂。它不是突然不会了,而是它脑子里垃圾越来越多,真正关键的信息被你自己埋掉了。文章里提到它们观察到大概在三百 k 到四百 k 头坑左右,就可能出现一定程度的 context 了。 这个不是死规则,但已经足够说明一个问题,上下文窗口大,是让你更从容,不是让你更放飞。这个是我自己特别有共鸣,因为平时开发太容易这样一个绘画里,查接口、翻日制、改 s q l, 顺手修握拧,你以为这是高校附庸,其实很多时候, 这叫把四件事塞进同一个脑子里,然后指望它一直判断精准。所以这篇文章里有一句,我特别认同, 每一轮对话结束都是一个分叉口,你不是只能继续聊,你每次都得做选择,是继续还是瑞恩德?还是克尔,还是康派克特?还是紫黛丽? 先记住最重要的一条,你开始一个新任务,最好就开一个新绘画,别老想着在旧绘画上,你刚刚还在修登陆,下一秒又去搞导出报表,这已经不是连续工作了,这是两个任务,别装作他们是一件事。然后是因为你。很多人喜欢在后面补一句,你错了。 但更好的做法,往往是退回到他还没走外的那个节点,因为源于外内的价值。不是纠正一句话, 而是把错误分支整个从上下纹理砍掉,别让它继续污染后面的推理。再说 come park 这个功能很多人知道,但你一定要记住,它本质上就是摘药,而且还是有损,有损压缩,也就是说哪些内容保留,哪些内容丢掉, 不是你说了算,是模型替你做选择,所以他有时候会要爱。最后一个特别好用的是紫代理,别什么中间过程都往主绘画里灌,能外包的就外包给全新 comtex 的 新 a j 项链,结果读别的代码库总结实现方式,或者根据归片更写文章这种任务,你最后其实只想要坑 q 村结论。 所以看完整篇文章,我自己的结论就一句, e m context 不是 让你无限续杯的,它是给会管理的人用的。以后你再觉得 ai 越聊越笨,先别急着怪模型,先看看是不是你自己先把它的上下文位坏了。

全部给我去用扣袋子,太香了。我昨天研究到凌晨四点搞我那个电商的全自动化商品工具,就自动选品,自动采集自动商家,包括自动合价。我给你们看一下我的进度, 目前是已经完成差不多五分之一了吧。选品自动商家,话不多说,我给你们演示一下吧,好吧。 然后上架时间跳一个月内,一个月内商家的新品,然后点一下来,自动跳到对应的,对吧选品工具,然后筛一个月啊,自动筛,然后自动 获取,比如第一页这二十个所有的产品主图,加上商品 id, 看,现在正在跑了,已经看到没在跑,在跑了,自己在跑。来,我们点一下, 你看一下扣带子界面就很简单,对话就行了,你会提词就可以了,全程不需要自己懂代码,不需要自己写,他帮你写好,帮你做个网页出来。 等一下,因为这一页的话有二十个屏,我们等下把这二十个屏跑完。好吧,我现在是全程没动,我没动鼠标的,你看没自己来跑的。 ok, 搞定,看一下来,现在没有数据吗?对吧?好了,刷新一下,看到没?出来了,呃,产品的品名缩写了对吧?标题以及主图一张,对吧?为什么只需要主图?因为后面会拿这个品去 幺六八八去识别,找同款链接,然后来比价,来筛侵权,来改图, ai 改图,然后再来去用妙手来去,对吧?上架去发布, 所以现在只完成了五分之一,所以只需要主图,然后对应的啊,比如上面 id, 我 点一下,点击之后自动跳转到这个平台,自动输入这个商品 id, 自动搜索,自动到对应这个产品链接,就如果你们想看的话点一下对吧?你看信息有了吗?对不对?比如说 想不想听啊?这是它工具自带的,只说你正常的话你得手动输在 id, 还还那啥自动啊,自动化了回来有人说你这个工具对吧?它本来就自带可以上架的呀,为什么说还要做这个东西呢? 因为听好了。举个例子,我们 y r 选品的话,不光是从,比如不光是从云集看,我们还会看 t k 的 数据,看亚马逊的数据,看店铺前端的数据,看什么各种数据,所以 如果云起这个工具他只是一个来源而已,懂 𠲎? 应该干过,应该懂我意思吧,所以全资的话,对 𠲎。