claude桌面端怎么设置上下文
现在的模型基本上都是两百 k， 但是你在编程的时候到底用了多少？这个你有仔细去看过吗？今天我给大家分享一个怎么样去设置 cloud code 的 一个上下文查看窗口，这个不像 code x 它会显示这个上下文， cloud code 它是没有默认显示上下文的，只有到最后的百分之十的时候它才会显示。 第二个点就是给大家分享一下我今天踩的一个坑，因为我总感觉做一些稍微大型一点的项目的时候，他的上下文窗口特别的窄，因为我可能做一些稍微大型的项目的测试啊，或者说修改的时候，我想要去拿到足够的上下文，可能就是五轮对话或者十轮对话，他就要压缩上下文了。所以说我就详细的看了一下他的 contacts， 给我震惊到了， 可以看到我这是一个新的对话，他两百 k 的 上下文，我有效的使用空间只有百分之六十四点五不到， 而且是我优化过后的，我把 mcp 删到只剩下了一个 playwrite 的 mcp， 因为我要做这个端到端的测试，所以说留下了这个 mcp。 在 我没有进行优化的时候，比如说在它这个 memory fails， 它里面包含了很多这种嗯规则的文件夹，因为我之前安装了蛮多的黑客松他分享的 cloud code 配置的项目， 所以说我可能就安装了很多这种东西，大家一定安装的，一定要删掉，不要堆很多。我之前启动的时候， 新对话它的这个自由空间就只剩下了百分之四十多，相当于我只有九十多 k 是 有效的空间，其他的全被什么 m c p 记忆文件塞满了，并且它这个记忆文件还跟那个记忆文件还不一样，它其实就是你的一些命令行的一些东西，它会全量的加载。 我们来详细看一下，它的系统提示词包含了四 k， 然后系统的工具就包含了二十二 k， 然后它还要保留三十三 k 的 百分之百分之十六点五的不能侵犯的空间，因为它要做这种上下文压缩，所以说这一部分空间它是直接给你砍掉了的，所以说不管你做什么，它至少有五十多 k 的 上下文是你完全用不了的。 所以说这个点大家还是要知道一下，特别是你的 m c p， 你 的工具，你的这种规则记忆不要写太多，写太多会影响你的上下文，这都是我优化过后的，它有百分之六十四的上下文还可以用，这个是一个特别巨大的坑，特别是 m c p， 别堆一大堆 m c p 上去，你的 contacts 打开来一看， 你这个个 m c p 如果说上了两三个，肯定你这个 m c p 在 十 k 以上了。 ok， 我 们今天还是给大家分享一下这个看上下文的一个项目，但是它这个是到百分之八十二的时候，就基本上是到了它要压缩的上下文，它是按照两百 k 来计算的，不是看按照这个有效上下文来计算的。 所以说大家看在七十的时候，其实就要思考把现在的任务做一个归档和这个总结了。你可以直接告诉他，你的上下文不够了，我准备要压缩你上下文，你有没有什么需要记忆的或者收藏起来的东西，因为我是用的 team 模式，我会专门去给他创建很多，比如说这个是后端的，然后我会让他去把这些文档给记录下来， 然后这个这种一二一的测试的，这种是代码的主要 leader 成员的，然后我会让它记下来，所以说我到七十五 k 的 时候，我基本上就会让它做收尾了，因为你如果不收尾的话，你上下文压缩了之后，它很多信息就丢失了，下一次执行的任务它效果就非常的差。这个就是那个项目 cloud h， 它其实就很简单，首先是你的项目，然后它是什么模型，然后对应用量的上下文调用的工具调用了哪些也有，然后使用了哪些子智能体也有，但是它对这个 team 模式是支持的比较少的， 同时它这个用了哪些 team 它也没有显示，但是它可能后面就慢慢会更新，然后代办事项这种 task 和 to do list 它都会去写下来。 然后安装也是很简单，直接安装这三个，如果说有问题的就可以直接把这个文档发给他，让 cloud code 去给你做安装。但是它有一个比较好的一个点哈，就是它这个是热启动的，只要你安装好了之后，你所有的都不需要什么重启啊这些它直接就可以完全显示。 然后配置的时候，大家也可以把它这个功能全部配置上，因为它这个并不会增加这种托管的消耗，所以说它都是按照钩子这种脚本的方式来做的，做的这种总结，所以说不用担心，直接使用就可以了。 ok， 最后也可以说一下，或者打一个广告，我们几个朋友去做了这样的一个中转，可以大家一起去拼这种二十 x 的 账号，这样的话基本上就不会有被封的风险。如果说大家有用量用的比较多的，也可以点我主页沟通一下，但是如果只能用这种 二十美金的，这种一个月只能做二十美金，其实就完全没必要哈，你如果能用掉这种五 x 的 以上的，可以可以联系我。 其实就是我们几个朋友去搭了这样的一个类似于中转站吧，因为现在很多中转我们自己使用的时候发现反正他有点掺水，然后又不是 cloud code， 所以 说还是蛮大的问题的，而且很容易封号。如果你在国内用的话，你只有去搞个云服务器，在国外这样会稍微好一点，并且他这个 cloud code 是 真的有点痛苦，他还要 连做机制，就是你一个 ip 搞爆了的话，其实你上面的所有账号都废了，它基本上都会给你连连做全部封掉。呃，这也是现在给大家很大的诟病的，但是从实际使用下来还是 cloud code 的 效果会更好，像欧帕这些再多智能体啊，这种使用其实都是 cloud code 的， 会效果好很多， 这也是很痛苦的一个点。但是国内的一些小模型，它模型的性能还是不够的，特别是你在调用一些子智能体，或者说 skills 的 触发上面还是国外的 opus， 它的效果要好很。
粉丝1.8万获赞20.5万
相关视频
02:18查看AI文稿AI文稿我之前 cloud code 订阅的是 pro， 一 不小心就把限额用超了，所以特别焦虑，隔一会儿就强迫症一样用 slash usage 去查限额，现在还剩多少。直到有一次我看到朋友的 cloud 终端底下直接显示了这些信息， 我立马就问他装了什么，拿过来就用上了。这个插件的名字叫 cloud hard， 是 一个澳洲的开发者叫 grog watts 写的， github 上已经现在有四千多个 star 了。装上以后， cloud 的 底部会多一条状态栏。 就拿刚才说的限额焦虑来说吧，用 pro 或者 max 的 人应该都被限速过对吧？写到一半突然告诉你，请稍等几分钟，节奏全断了。装完这个插件，状态栏会直接显示你限额还剩多少，然后什么时候刷新， 快到上线的时候，你可以缓一缓，也不至于直接被卡住了。所以再也不用强迫症一样切出去用 slash usage 了。限额的问题解决了，但还有一个更隐秘的坑，上下文窗口。你跟 cloud 的 所有对话，他读的文件，跑的命令，全都挤在一个上下文窗口里，满了大模型会自动压缩，但压缩是有损的，之前你们聊好的设计决定具体的文件路径， 报错信息都可能被模型直接丢掉。而且很多大佬测过 cloud 的 回答质量，其实从上下文用到百分之三十到四十的时候就开始下降了，不是等满了才出问题了。所以最好的做法是，当你看到这个进度条过半了， 那么做完手头这个功能，或者修完这个 bug， 直接用 slash clear 清空上下文，比主动压缩或者被动压缩都要好得多，因为你能挑一个干净的时间点来做状态栏，还会显示你现在用的是哪个模型。 这个为什么重要？我个人的工作流程是这样的，在一开始的项目规划阶段，我会无脑一直用 opus。 这个阶段目的就一个，把项目所有的需求落实到文档里面，比如产品的需求文档、技术架构文档、测试文档、部署文档等等。然后用其他的模型，比如 codex 或者 gemini， 让他们来评估文档里是不是有些不清楚的逻辑不通，或者不符合最佳实践的地方。然后继续让 opus 迭代， 直到这些文档里其他文模型提不出任何问题。那么继续到项目实施阶段，那么我会就用 slash model 切换到 sonet， 那 么它只要按照写好的文档去执行就行了，不需要考虑太复杂的情况和特别深的推理。状态栏上一眼就看到自己现在挂的模型是哪个。不用猜，这个插件的安装也非常简单，你只要跟着 github 上这个 install， 三步直接就装完了，我就不赘述了。所以总结一下，这个插件就干了三件事情，限额快到了，提前预订，上下文快满了，提前知道当前的模型，一眼就看到三条命令，装完零配置。 其实这期内容是因为之前好多粉丝在问我 cloud 底下那个状态栏是什么，所以我才想起来专门介绍一下。所以以后你们如果看到了我用什么东西，感兴趣的工具或者配置，直接留言告诉我，我都可以出一期讲一讲。
1.2万张司机在路上
05:03查看AI文稿AI文稿今天啊，我会用一个视频给大家讲明白什么是 cloud 点 md， 以及你应该如何使用它。首先我们来看一看什么是 cloud 点 md。 首先 cloud 点 md 是 一种规定、约法或者是原则，它 可以避免 ai 健忘或者是跑偏。第二， cloud 点 md 是 用于补充上下文的，那我们知道模型的上下文会有哪些内容啊？首先会有你跟他的聊天记录，过往的聊天的历史以及调用各种工具的输入，还有缓存。 cloud 点 m d 补充是什么？上新闻呢？它补充的是那些仅凭项目内容本身无法被 ai 准确推断的信息，比如说你的使用习惯，你的工作流程以及你的代码规范等等。 第三， cloud 点 m d 也是属于按需下载的，它有自己的层级结构，非常类似于公司的组织架构。那我们来对比一下公司的组织架构是什么样的？假如你入职了一家公司，那这家公司一定会有自己的规章制度、章程和文化。 一个公司下面通常会有非常多的部门，比如说有开发部、市场部、产品部、运营部等等。那比如说如果你在开发部门，那开发部门会有自己的技术架构、代码风格以及写作的方式， 市场部门他也会有自己的品牌的定位，受众的群体。那如果我们把这个公司的组织架构放在 cloud dmd 这个层级架构上，你就很清晰的明白了，根目录的 cloud dmd， 它就相当于公司的规章制度、章程和文化，是所有项目都应该遵循的基本的规范和准则。 下面这些部门其实就类似于你电脑上的某一个开发项目，那这个项目会有自己特定的需要被约束的规章制度、规范流程等等。那 给大家看一个括号点 md 呢？它就包含了有代码风格，那你应该使用 e s 的 语法，不要使用 com g s， 那 有可能情况下你先使用结构导入，那以及他都有他的工作流程，比如说在完成一系列代码修改后，务必进行类型的检查，那这就是一种约束和规范。 那我们知道了 colldmd 是 什么，它有层级结构，那我给大家演示一下我本地的 colldmd 是 什么样的。首先我们看看我们根目录的 colldmd 到底是什么样子的， 那我的根目录就要求，比如第一个默认进入 play 模式，第二个是用子代理策略，第三个要做自我的循环的改进，它是一些总体的约束规范，是每个项目都必须遵守的。那我们再看一看一个项目级别的 colldmd 是 什么样的，那比如说这个项目就是我用来把 md 的 文本转成图片的一个项目，那我们看看它的 colldmd 是 什么样子的。 那这个刻到点 m d 呢？就是 ai 来帮我生成的，不是我手工编辑的。每次在我发现 ai 的 输出不准确或反复的犯一些错误的时候呢，我就会让 ai 总结，把这些案例经验都写到这个刻到点 m d 里面。比如说这里的一个案例是说图片高度计算的问题，他反复的出错，那我就会让他把整个的过程给我描述出来，以及说最终 怎么才把这个问题给修复掉的经验全部都总结在这里，以及说一些没有一开始发现的错误，到后期如何去发现它的这个过程，经验教训都放在这里面， 我们可以清晰的感觉到不同层级目录架构的 copy md 内容是不一样的，那在根目录下的它更多的是总体的所有项目都应该遵循的规范和约束。而项目项目的 copy md 更多是和这个项目本身有很大关系的，比如说这个项目的技术架构规范，它的一些经验教学总结等等，也是可以放在项目维度的 copy md 里面的。 那第三，我们如何创建 collude md 文件呢？那创建 collude md 呢？有两种方式，第一种方式就是你手动到项目下面去创建一个 collude md 文件，然后手工去编辑它，那这种方式肯定是比较麻烦的。还有一种方式啊，是 collude code 给我们提供一个很方便的命令，可以让我们一键的生成 collude md。 我 给大家演示一下，首先我们进入 collude， 开启一个绘画，然后斜杠调起一粒的命令，然后回车， 这个时候啊这个命令就会自动的帮助我们去读取当前整个项目的结构规范等等文件，那这个过程会需要一些时间。 好了，那这个时候我们的 cloud dmd 已经创建好了，让我们来看一看它的内容。那首先它这里面有整个项目的概述介绍，这个项目是干嘛的，以及常用的一些命令部署方式以及 它的架构、核心服务，这些全部都给生成出来了。那你之后在迭代过程中，那你的 cloud 就 会去遵循这个 cloud 里面的一些背景信息，然后能够更好的帮助你去迭代。那第四， cloud dmd 的 最佳实践是什么？ 经过过去一段时间的使用啊，我总结大概这四点的 color d m d 的 最佳实践，第一点是要保持 color d m d 的 简洁易读和清晰。第二个你需要定期去维护啊，你可以让 ai 帮你去做总结，去写 color d m d， 但是你还是需要定期的去人工 re view 去删除那些可能不太合适的，或者是说非常繁杂庸俗的。第三个呢，是你需要反 反复去测试，如果效果不好，你再去修改，然后再去测试，经过一段时间打磨啊，你会找到一个非常适合你的长期用的 color d m d 文件呢。第三个团队协助。那如果你是存在多个人一起开发一个项目嘛，我建议你把 color d m d 提交到代码仓库里面，这样相当于大家都会遵循同样的一份 color d m d 的 规范去做开发。第四个是本地多项目， 那如果你本地有多个项目需要开发，那我建议你使用拷好点 md， 你 可以把你的工作流程，你的代码规范等等东西都写在拷好点 md 里面，那你这个多个项目都会遵循同样的这个工作流程和风格去开发。那如果你本地只有一个项目，你要不要在公众下面创建？拷好点 md 其实没有那么重要，你可以不用创建。 第五个拷好点 md 的 模板参考，那在这里呢，我整理了两份拷好的点 md 的 模板，一份是简单版本的，你可以直接拿去用的。拷好点 md， 这个我自己用了一段时间之后，我发现效果非常的棒啊，很推荐你来试一下。那如果你还有任何不明白的地方，欢迎你在评论区跟我留言。那我是新起，每天分享一个外包固定的小技巧。
453起哥的AI实战
01:07查看AI文稿AI文稿分享一个 kol 的 小技巧，在你这个 kol 的 code 里面，使用第三方模型的时候，比如说 deepink 四 v 四 pro， 它明明是有一千个 k 的 上下文，但实际上这里它只会写成两百，为什么？因为 你的这些第三方模型的 kol 它不认识，它并不知道你的上下文是多大，所以它默认都是给两百，直接切成两百，这样的话你问一个问题就能耗掉接近五十，你这个一个对话 基本上四五个问题，他就要被墙压住了，那肯定是很不爽的，那怎么办？有个小技巧，其实就是你要选择模型的时候， 你要跟他讲你的上下文长度是多少，那怎么讲呢？他是这么约定的，你后面跟个中括号就这样子， 如果你是要改成三百 k， 你 就改成这样子，如果你要一千个 k， 你 就直接写成一个 m 就 行，这样子他就会被识别的一千个 k 就是 一个 m 的 上下文， 这样的话，你记在这个里面，可以完整的问他几十次问题，五十次问题，他才会触发上下往下缩，这样的话你的这个使用的会很舒服。对，就这么一个小技巧，一分钟教给大家。
02:47查看AI文稿AI文稿cloud 的 一百万头梗上下文正式开放了，很多朋友在问，这到底有什么用呢？那么今天就从一个每天用 cloud code 写代码的开发者视角聊聊我的理解。先说一下问题，那么用 ai 写代码最大的痛点不是说他写的不好，而是他容易忘记。 比如说你跟他聊了很多龙之后，前面定好的架构决策讨论过的边界条件他全部都忘了， 那么因为上下文窗口就那么大，满了之后就会自动压缩，压缩就是有损的，就像把一份详细的会议基要压缩成几句话的摘要，那么信息在这个过程中必然会丢失。 一百万 token 本质上就是把这个工作记忆扩大了五倍。以前二十万 token 大 概可以放一万五千行代码一个小项目的量，但是现在一百万 token 大 约可以放七万五千行，中大型项目都可以基本完整的放进去。 对我们来说，最直观的变化是，我不再需要替 ai 来管理记忆了，以前得精心来设计哪些的时候需要去压缩上下文，什么时候该 clear 一下，重新开始 怎么分批去投喂信息，现在这些心智负担会大幅的减少。那么大家最关心的问题是，装得下这么多的东西，就意味着它可以快速的找得到这些东西吗？在 cloud 官方中有一个数据， 他们做了一个叫 m r c r 的 测试，在一百万 token 的 文本里面顶藏八条关键信息，看模型能不能全部找到。那么 opus 四点六的准确率是百分之七十八点三，上一代 solo 四点五只有百分之十八点五， 那么这不是说上下文变大了，但是变得笨了，而是上下文变大了，并且还变得更准。最后说一个很多人都关心的是， 就是它的费用有没有贵，那么我用的是 maxplus， 每个月一百美元的这样的一个费用，包含 cloud code 的 使用的额度，那么这次更新之后，一百万上下文自动开启，不需要加任何的配置，也没有额外的费用。 之前 api 用户超过二十万的话， token 要付双倍的价格，那么现在这个溢价也取消了。 总结下来就是一句话，一百万上下文不是一个你需要去刻意去用码的功能，他是让一个你不需要再去操心上下文够不够的保障， 当你需要的时候他在那里，当你不需要的时候他不碍事，这就是体验上的一个质变好的。那么本期视频就到这里了，关注我以后为大家带来更多的 ai 的 编码的教程，我们下期视频再见。
01:50查看AI文稿AI文稿绘画管理做不好，再大的上下文，真的就能一路聊到底吗？很多人一看到一百万上下文，第一反应就是终于可以一路聊到底。但绘画管理这件事，反而更容易被忽略。但 cloud code 核心开发者那张绘画管理图，反而是在给大家泼冷水。 窗口越大，不一定越强。很多时候， ai 不是 越聊越聪明，而是越聊越糊涂。上下文拉太长，就像桌子，越堆越乱，文件还在眼前，你反而更难一眼抓住重点。 他也像人脑进了脑雾，前面说过的话没真消失，但线索馋成一锅汤，都快糊了。所以问题不只是能装多少，而是上下文一藏模型就会越聊越糊，这才麻烦。 那张图最重要的不是教你背五个按钮，而是把每次输出后的分叉口直接摊给你看。截图里五个选项并排放着，就是在提醒你，默认继续只是其中一条路，不是唯一答案。 继续硬聊最省事，走歪了就回退垃圾先清掉，压成提纲再上路，杂活分出去它真正要你学会的，不是按钮名字，而是绘画异常时，先判断，再选更干净的路。 同样用 cloud code， 有 的人一路越聊越顺，有的人十分钟后就开始重复跑偏，自己打自己脸。 差别通常不在模型大不大，而在你会不会主动停一下，决定该继续回退、清空、压缩还是分工。真正拉开差距的，不是模型有多大，而是你会不会管理上下文，差别往往就出在这里。 所以，别再把大上下文想成护身符，它更像一个更大的工作台。台子再大，东西乱堆，最后也只是更乱，不会自己变聪明。真正拉开差距的是你会不会管理上下文。
140大力AI
01:00查看AI文稿AI文稿我相信很多非技术背景的朋友啊，一看到可乐扣的界面，黑乎乎的一个框，立马就打退堂鼓了。那今天我会给大家分享四个使用技巧，教你不再害怕他。第一个，拖动图片，很多新手一上来就会卡在一个问题，这图片怎么上传？那其实根本不用上传， 直接把截图拖到中端窗口就可以了。第二个，引用文件，没有了界面的编辑器，这文件怎么找？直接打一个艾特，输入文件路径前缀，然后选择你想要的。第三个， shift 加 table 切换模式，那在终端中按 shift 加 table， 可以 在正常模式、自动编辑模式和规划模式之间循环切换，那终端下方也会有提示啊。 第四个，斜杠命令， class code， 通过斜杠命令来快速调用各种功能。这种设计啊，其实在很多应用中我们都会可以看到，比如说豆包，它也是支持斜杠命令的。如果你不知道怎么用的时候，就直接斜杠 help 就 可以找到官方说明书，那 只要掌握以上四个小技巧，就能帮你顺利用上 cloud code。 你 还有哪些使用 cloud code 的 疑问？欢迎在评论区告诉我，我是新起，关注我，每天学习一个 web coding 的 小知识。
220起哥的AI实战
12:401140AI超元域
01:59查看AI文稿AI文稿ai 写代码最大的敌人不是 bug， 是 失忆。你跟 ai 聊了半小时，前面说了什么他已经忘了。上下文越来越长，回答越来越烂，最后只能重来。这个问题叫上下文腐烂，所有用 ai 写代码的人都遇到过，今天介绍一个工具，叫 g s d get shit down get hop 上热度很高的 ai 编程框架之一。他干了一件事，把大项目拆成小任务，每个任务给 ai 一个全新的干净的上下文窗口。 先说 gsd 为什么牛，第一，上下文工程，每个原子任务都有两百 k token 的 干净上下文，不串台，不污染。第二，多智能体编排，四个研究员并行调研 planner， 制定计划， checker， 交叉验证一整套流水线。第三，多次执行独立的任务并行跑，有依赖的排好队依次来，不浪费一秒钟。第四，原子 get， 提交一个任务，一个 commit， 出了问题精准回滚，不用整个项目重来。 第五，持久化记忆，所有知识存在 planning 目录里，关掉电脑，下次打开，记忆还在。好原理讲完，接下来上手小白最容易犯的错就是让 ai 直接帮我写个项目，用 gsd 记住这几个斜杠命令就够了。第一步， gsd new project， 输入项目描述， ai 变身需求分析师帮你把模糊的想法拆成清晰的阶段。第二步， gsd discuss face 一， 跟 ai 聊需求细节，确认方向没问题了再动手。聊完了 gsd plan face 一， ai 生成详细执行计划，每一步做什么，什么顺序全列出来， 计划确认了， gsd execute face 一， ai 开始写代码，一个任务一个 commit， 写完了别急， gsd verify work 一， 自动验证刚才的代码有没有问题，有问题当场修。还有一个懒人法宝， gsd next， 不知道下一步该干嘛输这个 gsd 自动推进到下一个最合理的步骤，一路 next 就 能把项目推进下去。讨论、规划、执行、验证四步骤，这就是 gsd 的 核心流程。这几个命令掌握了，日常开发完全够用 下来。是高手怎么用 gsd？ 第一招， gsd discuss face 一 千讨论完自动进 plan， plan 完自动 xp， 一 条龙跑完。高手不会一个命令一个命令敲，而是让系统自己流转。第二招， gsd set profile， 高手会根据任务难度切换模型，配置 简单任务用八 g， 省资源，核心架构用 quality， 求稳，不是一刀切，是按需分配。第三招， gsd quick four， 遇到临时任务又不想丢质量，用它自动走完。讨论、研究，验证全流程。第四招， gsd map code base 已有项目享用 gsd 管理， 先用这个扫描整个代码库，建锁影，有了锁影， ai 才知道你的项目长什么样。高手用 gsd 的 秘诀就三个字，节奏感。先讨论清楚再动手。先精简需求再扩展，先验证再交付。 gsd 不是 替你写代码，是帮你管好写代码的节奏。我把 gsd 的 核心命令整理成了这张树，查表， ai 不 失意，项目不失控。用好 gsd， 一个人就是一只工程团队。
381土木AI提效大古
01:03查看AI文稿AI文稿用可乐的扣子写项目，聊着聊着就会蹦出来一句话，提示你上下文窗口快满了，一旦压到上下文， ai 就 开始抽风，出现上下文腐烂的问题。问题是在命令行里边，你压根看不到上下文用了多少，等提示的时候就晚了，尤其是你在这个绘画里面已经取得了一些项目进展的时候。 如果你有这个痛点，强烈建议安装可乐的哈的这个插件，执行三条命令就能用了。装上之后，在终端底部会出现一个实时的状态栏， 以进度条的形式显示当前窗口的上下文使用情况，还会显示 ai 正在调用什么工具，跑什么 a d 的。 当可乐的卡住不动的时候，一眼就知道它是在思考还是在调用工具，还有显示当前项目的 get 分 值，任务代办进度。 这种感觉就像给开车从没有用过仪表盘的人突然撞上了仪表盘。使用可乐的扣子，心里面就有数了，可以很清楚的看到可乐的在做什么，剩余的上下文有多少，哪些工具处于活动状态。当你管理多个变形的可乐的绘画的时候，会非常有用。点赞关注，每天获取一个新知识！
195程序员小江
02:29查看AI文稿AI文稿今天这期视频用最高效的方式教你如何在 cloud 桌面端中调用 deepstack v 四系列 demo v 二点五系列这种性价比极高的国产大模型。首先我们打开 cloud 桌面端软件，在 help troubleshooting 这里有一个 enable developer mode， 就是 开启开发者模式， 点击 enable cloud 的 桌面端会重启，重启之后我们点击菜单栏的 develop， 这里有一个 configure party inference， 选择 gateway 模式，在这里需要输入 gateway base url。 这个 base url 大家应该不陌生，我之前教学如何在 cloud code 中接入第三方模型的视频里 多次提及这个 base url， 它本质上就是各家大模型厂商都可以按照 ansrv 公司提供的标准设置自己的 base url， 这样就能在 ansrv 公司的产品里面 使用第三方的大模型。下方这个 api key 呢，就是我们需要去你想用的第三方大模型厂商那里开通的，比如 deepseek、 mimo v 二点五 pro deepseek 如何获取 basic url 和 api key？ 之前的视频教程里也有，我这里以 mimo v 二点五 pro 距离 我们在小米 mimo 的 控制台里创建 api key 啊，我这里开通的是 pro 的 月度套餐啊，其实是 mimo 的 百万亿 token 计划赠送的，如何通过这个计划领取？之前的视频教程也有介绍，在这里创建 api key key， 填到 getaway api key 里面。至于这个 base url， 我 们可以看到控制台也写明了，你要选择的是兼容 astonopy 接口协议的这一行， 复制之后在 cloud 桌面端里面粘贴，之后在 model 类似的这里添加一行，把 model id 写成订阅的这个 api key 能调用的 model id， 注意这里模型的名称一定要按照第三方大模型厂商的文档里写的标准来，比如说有一些是必须要求小写。 如果这个模型支持百万上下文，也可以打开这个 offer one m context variant， 最后点击 apply locally 就是 应用需要重启 cloud 桌面端，可以看到这里模型已经切换成功了，我们选择这个 mimo v 二点五 pro 百万上下文。到这一步还不算完，我们怎么把模型提供商从第三方改为 ansible 官方订阅呢？在主界面点击左下角的这个 takeaway， 点击 signout 退出， cloud 的 桌面端会重启。重启之后你就可以看到两种登录方式，一种就是我们刚刚自己设置的第三方提供商，另一种就是 signing to asterisk。 如果你订阅了 cloud 的 官方的套餐，我们就可以使用 cloud 的 账号来登录。 我们看到已经切换成了 cloud 的 官方的订阅。 deepsea 微四系列的缓存命中率非常可怕，占到了百分之九十以上，再加上 deepsea 现在缓存命中的 a p i 调用成本打了一折，这使得它的调用成本几乎达到了 g p t 五点五， oppo 的 四点七的八十分之一。
13王行知
03:57查看AI文稿AI文稿可劳斯扣的核心成员最近发了一篇文章，主题呢，很直接。怎么正确使用一百万的上下文窗口？很多人看到这件事情，都以为上下文越大，模型就越强。但真正值得关注的，不是他能够塞进去多少内容，而是当上下文变得足够长之后，管理上下文本身 开始变成了 agent 的 核心能力。为什么我这么说？因为很多人对上下文窗口的理解还是偏向于聊天记录，觉得窗口更大， ai 就 能够记住更多。 但如果你真从系统角度看的话，上下文根本不只是聊天记录，它里面还有什么呢？包括系统提示词和模型的对话、历史工具调用，甚至他做过的错事注意。这些东西呢，全都会放在上下文里面，影响着他下一步。怎么判断 上下文越长，不代表系统就越轻松，很多时候恰恰相反，越长呢，越容易分散，越容易迟钝。这就是硅谷反复提到的概念， context rot。 上下文退化，你可以把它理解成上下文越来越大以后啊，模型的注意力被摊薄了， 不是他完全忘了，而是信息太多之后，重点被噪音给稀释掉了。说白了，就是你看的东西越多，不一定判断的越准。所以第一个真正该看的点呢，不是一百万上下文很大，而是怎么处理好上下文污染这个事情。 第二个点，我觉得是对 session 的 理解，很多人还是把 session 当成一个持续聊天的地方。但真正做 agent， 你 会发现， session 更像是一个运行时的工作区，只要任务发生变化，哪怕上下文还没吃满，也最好不要一直跑下去， 因为你关心的不是上下文还能不能装下，而是这些信息啊，还值不值得继续留在上下文里面。 那第三个点我觉得特别关键，就是 rewind 的 功能。很多人发现 ai 做错了，第一个反应是补一句，哎，这个不对，你换个方法。但从系统角度看呢，这种修正方式其实很贵，因为很多发生过的错误啊，还是留在的上下文里面， 那就变成了在一个被弄脏的上下纹呢，继续错下去。而 rewind 的 价值就在于，它不是纠正，而是去做减脂，直接回到了更早的节点，把失败的分支呢砍掉，然后即有效的信息重新开始。这个差别非常大，前者呢是人工补丁的修复，后者才是真正的上下纹治理。 那第四个点是 compet 和 clea 的 区别。很多人觉得这两个差不多，反正都是清一清嘛，再继续。但实际上完全不是一回事。 compet 是 让 模型自己总结刚才的历史，然后拿着摘药呢。继续跑下去。好处呢是审视，坏处是他有一定的损耗，因为你在相信模型，自己判断什么重要什么不重要，可立则不一样，可立是你自己写一份新的 brief， 告诉他呢，当前的任务是什么，约束是什么？ 哪些文件相关，哪些错误路径已经排除。一个是模型替你压缩上下文，然后另一个是你自己重建上下文，这背后的控制权完全不同。 而且最麻烦的地方在于，坏的 compact 往往呢不是随机出现的，它最容易发生在任务方向还不稳定的时候。因为模型刚刚经历了很长的调试，排错试错， 注意力本来已经被严重的拉散了，但这时候你再让它去做总结，它很可能把接下来真正有用的东西给丢掉了。 第五个点是 subagent。 subagent 真正值钱的地方呢，不是并行，而是隔离。也就是说呢，有些任务会产生大量的中间输出，这些过程本身是没有必要回到主上下文的， 你真正需要的只是最后那个结论。那最好的方法呢，就是让它留在独立的上下文里头，跑完再把结果带回来。 所以这不是一个小技巧，这是 agent 系统里面非常核心的架构能力，所以你会发现一个更底层的趋势上下。我们窗口变大了，不代表 agent 系统变强，真正让 agent 变强的是你有没有能力治理好它的工作记忆。
548姜无维 AI
01:18查看AI文稿AI文稿用可乐的扣子写项目有个痛点，复杂的点任务。一个绘画里面聊了三五十轮之后，他就开始抽风，原始目标会被遗忘。还有你半个小时前定的规则，他要么是忘了，要么是弄混了， 你还得再提醒一下他才能想起来。如果你有这个痛点，强烈建议安装普兰蒂威 feel， 这个是 q， 这个是 q， 完美复刻的麦纳斯的上下文管理方法，装上之后会在你的项目里面自动创建三个 markdown 文件， 这三个文件并不是让 ai 变得更聪明，而是让 ai 学会积累经验。第一个用来存储计划任务，相当于任务清单， ai 必须看完这个再干活。当前的进度在哪，最终目标是什么？ 第二个用来存储调研结果与关键发现，相当于 ai 的 笔记本，比如发现了某个库的 bug， 或者是某个 api 接口变了，都会记录到这里。假设再遇到类似的问题， ai 会直接从这个文档调取记录，避免再次犯错。第三个用来存储操作过程的详细日子，相当于流水账，记录所有尝试的结果。 刚才跑测试挂了。挂在哪一行代码？上一次尝试修改了哪个函数，这主要是为了防止 ai 陷入死循环。有时候 ai 会反复的尝试同一个错误的修复方案。安装方法很简单，执行两条命令就能用了。 这个时刻就是对麦纳斯上下文管理哲学的完整复刻，简单但非常有效。点赞关注，每天获取一个新知识！
97程序员小江
04:56查看AI文稿AI文稿大家好，我是迪迪，那今天想跟大家分享几个 close code 的 平时用的比较多的一些小技巧，我是分成了安装与设置里面的一些部分，以及上下文与提示管理里面几个，所以一共当前是有十个小技巧，今天就对着这个 close code 一 起跟大家演示一下， 我觉得都是非常实操的一些能够提高工作效率的一些技巧。那首先我们就进入 cloud， 进入 cloud 里面呢？这个是我放在第一条，我觉得非常的有用，如果用 cloud code 比较多的一些小伙伴会发现经常我们需要去确认 yes 或者 no， 那 么在这个情况下，如果我们当前的这个文件夹下面的文件，我们都是可以放心让 cloud code 去做一些操作和动作的话，我们就可以去使用这个命令行，这样的话相当于 cloud code 到了任何一个阶段，它都可以去 撕掉他的一些问题，所以是这样的一个命名号，我觉得是第一个非常有用的。第二个可以看到 如果注意到的小伙伴可以看到我这边有一些模型以及他的一个位置，以及他当前的一个花费，那么有这样的一个进度条，而且它是可以实时的去更新的。在这个情况下，如果大家想要这样的一个的话，那就可以用这个 status line， 这样的话他就可以去触发这个更新镜调了。 第三个可以看到它是把上下文的内容扩展到一米六，那么这个时候我们就可以去扩展这个 model， 我 们来看一下，比如说我选择 opus， 它后面都会把这个模型设成了四点七，另外你也可以加上上下文扩展到 em， 但是如果说是一些比较复杂的或者简单的，你都可以根据不同的任务难易程度去换这个模型的类型。接下来是在配置的地地方推后一个我觉得非常有用的就是这个 config， 那 config 里面呢？有非常多的这些选项，你可以一个个去进行选择，比如说像一些 show tips， reduce， motion， 也可以去设置你的一些语言 rewind code 啊，对，每一个你都可以进去。首先注意的是你按空格键可以去改变，按这个回车键是可以去保存，退出就直接退出，所以这个也是一个非常有用的一些 tips。 所以以上是我觉得我在使用过程中四个常用的一些小技巧。那接下来就是一些关于我在跟 cloudco 的 对话中可以用到的一些指令行，那么其中有一个呢？可以看一下。 第一个叫 clear， 我 遇到了非常多的一些任务，我想把这个任务给 close， 因为我觉得这个跟我当前是没有任何关系的，我这个时候就可以按照 clear， 它就会重新启动一个新的设置，那么这个就是一个非常好用的，我也不用再开一个新的一个 terminal 去去开，所以这个我觉得挺有用的。 第二个，如果说我让他两次 prompt 或者三次 prompt， 他 都是没有办法达到我要的一个目的，那么这个时候我们就可以重新来，重新来，我们就可以 clear， 加上你后面想要的这个 prompt， 比如说帮我重新写这个东西，把整个步骤可以给他再具体的说一遍，这样呢就可以做一个重启的一个动作， 所以这个是一个小技巧，有 shift 加 tab， 你 按上电脑上的 shift 键和 tab 键，可以看到这边它可以自动的 mode 就 会改变。那我强烈推荐大家可以在做自己的一个 project 之前开启这个 plan mode， 否则它的指令还没有明确的情况下，它就开始在执行。做一些操作的话 就会非常的费 token， 你 想达到的程度和他要执行的程度，他不在一个统一的境界上面，所以完全建议大家可以去开启这个 play mode。 对， 这边就是用 shift 加 tab 键，可以看到 shift。 好， 接下来用这个 at， 这个也是我非常常用的一个指令，我如果想要去指令某一个文件，因为我这边真的非常多的文件，那么我可以就去 at 某一个文件，那这个时候我就可以，比如说我就 copy 它的一个 parts， at 这个它就可以自动的去调用这个文件了。另外其实我们在完成一个任务的时候，我不断的提问，让他不断的回答，整个上下文就会非常的长。那这个时候有一些没用的一些信息，其实我就是想把它进行压缩，但是有些有用的信息呢，我又想让它留下来， 这个时候就可以让它 compact 一下，但是引号之间呢，让它保留某些事情，这个也是我觉得非常好的，就 compact， 然后里面加上我想保留这样的一个情况，这样的一个格式，你也可以去进行操作。另外一个我觉得非常好用的，在我需要让他帮我去想一些大的复杂的 架构的时候，我就会加上这个 archer sync， 就是 让他开启他的硬核模式，帮我去一块去思考去看，所以这个的话我觉得也是一个非常有用的小 tips， 所以今天会跟大家分享的就是这十个，涉及到了你在安装和设置的时候遇到的一些指令行，以及你在上下文在整个对话过程中你可能会使用到的一些命令行，我觉得都是非常有用的啊，所以今天把这个分享给大家。
178迪迪碎碎念
05:17查看AI文稿AI文稿现在啊，可以不用被可拉扣的拒之门外了，桌面版可拉扣的直接搭配 deepsea 为四，不用再看命令窗了，今天这条视频把完整配置流程全给你扒出来，手残党也能一次成功。没耐心的我已经整理好文字版教程了，大家按需参考。 首先啊，我们要先去安装 cloud 的 桌面版本，打开 cloud 以后啊，我们可以看到 getstart login 之类的页面，先不要进行登录操作 这一步啊，我们先开启 cloud 桌面端的开发者模式，开启之后呢，菜单里才会出现第三方推理配置的，介入 macos 顶部菜单栏操作，点击最上方菜单里的 help， 点击这个 trouble shooting， 再点击 enable 开发者模式。 弹窗出现后啊，我们直接点击 enable， 这时啊， cloud 会自动重启。重启完之后啊，我们再看顶部栏，这里啊会多出一个 develop 的 入口。 ok， 我 们继续来啊，下一步我们就点这个 develop， 进入这个 configure third party inference。 先别着急填内容啊，把这个配置窗口打开。 首先 inference provider， 这里我们选择 getaway base url 呢，就根据你想接入的大模型来填写，一般的官方接口文档里面都有，我们呢就以最新 deepsec 为例了。 然后 apikey 呢，就写你的 deepsea 的 apikey 就 行，下面这一项啊，可以先不用改，默认的即可。 接着下面这里 modellist， 我 们点击这个 add 加号，加两个模型，第一个填 deepsea v 四 pro， 第二个呢，填 deepsea v 四 flash 这里为什么我填两个是因为我把 pro 放在第一位，这样呢，它就会成为默认模型， 再加一个 flash 呢，作为更轻量级的备用模型。提个醒啊啊，如果你想让上下文火力全开的话呢，可以在名称后面加上， 然后下面这个 organization u i d 这里呢，可以先留空，这个呢是不影响你去接模型的。然后 credentials 这里呢，也是给企业做动态凭证用的，你也用不上。 然后这里啊 skip 这个出错，这里要选择打开这一步呢，是很重要的，这样重启以后呢，就不会再走 cloud 的 登录流程。 好，全部设置完，我们点击这个 apply locally 本地话，这时客户端就会重启。 如果配置生效呢，就不会再要求你登录 cloud 的 账号了，而是直接进入第三方推定模式。 我们来看一下啊，这里是没有登录 cloud 账号的啊，它已经进入三方模式了。看到左下角这里显示 cowalk 三 party getaway。 右下角这里的模型呢，也默认的变成了 deepsea 四 pro。 好， 那我们来验证一下，看它是不是能够直接调用 v 四。 现在我们切到 cloud code 的 工作区看一下啊，右下角这里它显示的模型依然是 deep seek 四 pro， 左下角呢，也仍然是 cooke 私人 party getaway。 这说明呢， cloud code 的 桌面版现在已经是在不登录 cloud 的 情况下通过第三方网关调用了 deep seek 的 大模型 啊，那我们为了验证他不只是界面切过去，而是他真的能工作。我现在呢，给克拉克挂一个本地测试目录。好，首先先关联我在桌面新建的测试文件夹，现在我给他一个非常简单的测试任务， 只允许他操作当前项目目录，先读取目录，再创建一个 hello 点 txt 的 文件，这样呢，我们就能验证克拉扣的是真的，通过 deepsea 完成了本地的代码和文件操作。 那这里第一次让克拉扣的操作本地目录的时候，会弹出一个工作区确认确认，因为他之后要读取写入甚至执行这个目录里的内容。这里啊，所以我们需要手动信任一次。 好，挺快的啊。这里他已经有完整的反馈了，我们去看一下这个文件夹里面是不是已经有输出了。 ok， 看到他的输出了，搞定。 好。那总的来说啊， cloud code 呢，一直是页内标杆类的存在，只是以前很多人卡在账号这一关用不上。现在啊， dbc 维斯出来以后啊，通过第三方网关接入，我们就可以实现强强联合。 前端呢，用的是 cloud 的 桌面端和 cloud code 的 交互体验。底层呢，代用的是 deepstack v 四的模型，能力对很多没有 cloud 的 账号或者是想灵活使用模型的人来说，还是很值得尝试的。 至于说 deepstack v 四能不能和 opps 四点七一战，你们呢，自己动手试一下，有结果的话也来告诉我。好，本期视频就到这里，希望能够对你有所帮助。我是阿月，我们下期再见。
1262阿悦很严格
04:16查看AI文稿AI文稿来喽来喽，很多粉丝问我这个 cloud code 状态栏是怎么设置的，今天就分享给大家，顺便给大家普及一些关于 cloud code 少为人知的知识，让你可以更了解 cloud code。 我 这个 cloud code 增强状态栏脚本经过我的多人改造之后，所显示的信息能让我对当前工作状态一目了然。 下面我给大家逐个解释一下所显示的信息。首先第一行显示的是当前 get 仓库的相关信息，这个 m 是 modified， 表示已经修改的文件数 d。 deleted， 表示已经删除的文件数 s 是 stat， 表示已经 get at 等待提交的文件数 u 是 on track， 表示未被 get 追踪的文件数 a 就是 ahead， 表示本地比远程多多少个 commit b behind， 表示本地比远程落后多少个 commit v divergent， 表示本地和远程各有对方没有的 commit 数 c。 complex， 表示合并冲突的文件数。 第二行是模型信息，这里表示当前所使用的模型是 solid。 四点六，上下文窗口是一百万 talking， 目前已经使用了百分之十六。可能有些人不理解这里的上下文窗口是什么来的？ part 在 工作的时候呢，是不是给你一种感觉，它是否能记住你们之间的对话信息？其实呢，它并不是真正地记住了之前的对话，它实际上是把当前对话的全部内容打包成一个巨大的文本，一次性推送给模型处理。这个打包文本的容量上限 就是上下文窗口。 java 的 四点六，它的上下文窗口上线是一百万 talking， 大 约相当于七十五万个英文单词或者是几千页的文档。我们这里 context 百分之十六的意思是，你现在这个 session 已经积累的对话内容占这个一百万 talking 的 百分之十六。这样说你应该就明白了吧。我们继续看。 第三行是 cloud code 当前的工作目录。第四行是你 cloud 订阅的配额使用率。这里的问号表示本次 session 还没有收到配额数据，它通常在发送几条消息之后才会出现具体的百分比。这里的五 h 表示过去五小时滚动窗口的配额使用率，七 d 表示七天滚动窗口的配额使用率。 第五行是本次 session， 也就是从打开 cloud code 到现在累计的 talk 数据。 in 表示你发送给模型的 talk 数据。 out 表示模型生成并回复的 talk 数据。第一个 cash 表示从缓存提取的 talk 数据。第二个 cash 是 表示写入缓存的 talk 数据。这里是指 talk 的 费用。 要注意的是，这里是按照算法的 api 定价折算的定价费用，并不是实际的扣费。这里表示本次 session 已经持续的时长。有朋友可能要问呐，怎么写入缓存还有 talking 数啊？没错没错，新时代的开发，一切都是 talking。 写入缓存不但要钱，而且比普通输入还要贵呢。 比如在 entropic 定价中，普通输入的基本价格是三块，写入缓存的价格要贵百分之二十五，也就是三点七五。不过读取缓存呢，就非常便宜，它比普通输入要便宜百分之九十，只要零点三。 要注意的是哦，这里说的写入缓存，读取缓存并不是在你本地写入和读取，而是 entropic 服务器会把你发送过去的上下文缓存起来，下次处理的时候呢？如果开头部分完全一样，就直接附用缓存。 特别特别注意了， antropic 的 缓存只有五分钟时间，如果超过五分钟没有新的请求，缓存就失效了。好，我们继续看。第六行是当前项目目录历史所有的 session 累计的 talking 消耗，它和当前 session 的 数据一样，也包括 in， out 以及 cache 的 数据。 在下边一行呢，就是今天所有项目累计的 talking 消耗。再往下边一行，就是历史所有时间，所有项目的累计 talking 消耗。 再往下面看，这是当前 session 的 唯一 id。 最后一行里面，前面是当前 u t c 的 时间，后面这个是 c s t 的 时间。 c s t 的 全称是 china standard time， 中国标准时间。 最后这个是当前安装的 cloud code 的 版本号，这些信息已经完整地显示了我们平时频繁要关注的 cloud code 的 运行信息，把这些信息显示在状态栏上，方便我们随时关注。现在这幅脚本我已经开用到 get up 上了，大家可以随便拿来用。 脚本的安装方式也很简单，首先克隆这个仓库，然后进入到这个仓库目录，在目录中启动 cloud。 进入 cloud code 后，输入 install， 它就会自动完成所有的配置。如果你想要卸载脚本，那么就在 cloud code 中输入 uninstall 就 可以了。目前它支持 windows、 powershell、 mac os 和 linux。
93程序员说
01:51查看AI文稿AI文稿让 cloud 做一个稍微复杂的任务，他做到一半会忘了自己在干嘛。不是 ai 笨，是上下文窗口就那么大，塞满了就开始丢东西。 planning with files， 把文件系统当 ai 的 外部记忆，做完的状态不会丢。 上下文窗口是 r a m， 文件系统是硬盘， r a m 会丢数据，硬盘不会。 minus 就是 用这个模式做到被收购的，把任务状态全部持久化到，文件不留在上下文里。 planning with files， 把这个模式打包成 scale， 装上就能用，不用自己配。装完以后，每次多步骤任务它先创建三个 markdown 文件，再开始干活。 卡斯特下划线 plan， 点 m d 是 任务计划目标，拆成可勾选步骤，每步有验证标准，做完打勾。 findings， 点 m d， 即分析过程中发现的信息不会被上下文压缩挤掉，随时可查。 progress， 点 m d 是 进度日制。 clear 之后读一遍，三十秒恢复上下文，接着干 光写文件不够， cloud 不 主动读文件，写了也白写。 hooks， 解决这个 pre to use hook， 每次执行工具前自动重读 task。 下划线 plan， 点 md， 防止跑偏。 post to use hook， 提醒更新进度。 stop hook， 验证所有步骤完成才允许停止。还有 action rule， 每两次浏览操作后，必须把发现写到 fiddings。 点 md 适合用的场景，三步以上的任务，研究型任务，需要大量工具调用的任务。简单问答单文件编辑不用装，创建三个文件的开销比直接做还大。判断标准就一句话，任务复杂到 cloud 可能会忘记目标，就该用。
279大力AI
