claude怎么保存记忆

三分钟让龙虾成为你的私人秘书，帮你提炼聊天记录里的所有重要内容。我翻了最近泄露的 cloud 代码，发现它的记忆整理能力真的越来越趋近于人的大脑。于是我干了三天，把它印象成了 open cloud 可用的 skill， 可以 让你的龙虾记忆原地升级，十个版本 教程全部免费送给大家。目前我翻阅到的有以下几个方向，今天先从最核心的记忆套件下手，这里面就包括大名鼎鼎的梦境。第一层叫提炼，你每次聊完天，它自动在后台跑一遍， 把对话里这样的东西全部提炼出来。比如你说过选方案 b， 比如你提过某 api 不 稳定，踩过坑，他全部记住，下次打开他直接读答案， 不用你重复说半个字。第二层叫整合记忆一多就开始打架，这个文件说用 a 方案，那个文件说用 b 方案，你到底听谁的存在？文件说法矛盾了，有内容重复了，过时了，他全部给你标出来，生成清单， 审批了他才改。第三层最重磅的叫梦境，有没有想过你睡着的时候大脑在干什么？在 r e m 阶段，他在整理白天的碎片记忆， 该归类的归类，该扔的扔，所以我把这个技能叫做 r e m。 每隔二十四小时以上或者新增五次对话，他就自动跑一遍，给你的记忆库减脂，越用越聪明，而不是越来越繁重，这就是梦境的核心逻辑。以上就是记忆套件的内容，三层合力，自我净化。 另外几个方向我也在持续尝试印象城 skill， 后续会继续免费分享给大家，如果你觉得有用的话，欢迎点赞、收藏、关注，我们下期再见！

你有没有发现， i 工具一换，绘画就像什么都没发生过。偏好要重新说一遍，项目背景要重新讲一遍，之前的决策也要重新解释。真正的问题不是模型不够聪明，而是你没有给他一个稳定的外部记忆库。 长期记忆不要只放在某个模型内置的 memory 里。更稳的做法是用 obsidian 这类本地阿东库作原文件，这样记忆属于你，可以审计，可以迁移，也可以同时给 old 和牢的使用。 这个记忆库建议放在一个单独目录，比如零 i m 里，入口事务的它只负责导航。偏好放到 broccoli， 项目背景放到 britt， 重要决策放到的 gcn， 固定流程放到 workflows。 不要把所有内容塞进一个大文件。 接入方式很简单， o p d n。 负责保存长期记忆 o d。 何老的通过自己的指令文件读取它和向量剪索只是增强访问方式，真正的原文件仍然是这些可读的耳洞。 在 audit 里，关键入口是 ed 局文件写长期规则，比如复杂任务先读 audit 项目及文件，再指向当前项目的 memoinald， 这样 audit 每次开始工作前就知道该先读什么。 在 lydia 的 里，用 aud 指向同一个 lydia。 lydia 可以 有自己的 auto memory， 但真正重要需要长期保存的偏好项目状态和架构。决策最好还是写回 o p c。 店。 实际工作流势四步，先读总所引，再读相关项目笔记，然后执行任务，最后只在必要时写回记忆。注意，不是每次都把全部记忆塞进 boom， 而是按任务需要精准读取。 最后记住一个原则，长期记忆的价值不是记录更多，而是可审计、可迁移、可控制。只有明确要求记住反复出现的偏好，关键决策可附用流程和项目状态。摘药材值得进入长期记忆库。

cloud 再次抄了 open ai 的 家，它最新发布了一个功能叫 memory import， 不 用装插件，只需要三步复制 cloud 给你的提示词，然后再发送给你的 chat gpt， 然后再把 text gt 返回的结果发回给你的 cloud， 你 的 cloud 就 拥有了和 text gt 一 样的灵魂。因为现在我们去训练我们的 ai， 需要大量的去让 ai 记住我们的一些关键信息， 如果你要去利用另外一个 ai 的 话，那这个信息是很难转移的。 cloud 现在做的这个 memory import 就是 解决这个问题的，那 ai 对 用户的记忆其实也是 open ai 的 护城河，因为 大量的用户还是比较熟悉使用嵌的 gpt 的。 那现在 cloud 发布这样一个功能之后，可以说是直接超了 open ai 的 加。其实我们每个人把自己的数据喂给 ai， 其实就是把一种资产投资在了 openai 这上面，现在这个资产不是固定的了，它变成可携带可转移的了。那从今天起的话，带着你的数字灵魂，哪个 ai 好 用，你就可以去用哪个 ai 了，但是对于 openai 来说可能有点难受。

我让 cologod 长出了记忆，新开一个窗口，上一轮干了什么，聊到哪，他自动就接上了。 cologod 是 一个叫 cologod 插件， excel 上已经快七万颗星了。他干的事情呢，非常简单。 你用 cologod 的 时候，他在后台自动记录了用了哪些工具，做了什么操作。在每一轮对话结束之后，他用 ai 把这些记录压缩成一份，精简的摘下来。 再一次，你开新的对话，他自动把这些相关的历史上下文注入进去。等于呢，我们给卡拉扣的封装了一块外置的硬盘，安装其实也不复杂， 一条命令就搞定，重启下卡拉扣的就能用。我觉得呢，这个插件解决了一个非常核心的一个痛点，很多人觉得 ai 不 够好用，其实不是 ai 不 聪明，是你每次都得重新教他一遍，我们的项目背景是什么？ 你的偏好是什么？之前踩了哪些坑，有了记忆之后就会越用越深。那除了 cloud code、 cursor codex、 open cloud 这些主流的工具，它基本都支持。好了，今天的分享就到这里，欢迎大家在评论区交流，关注松哥，一起少加班！

我们必须要去做的第一件事，朋友们，假如你的 cloud 扣的刚刚安装好，先不要着急跑任务，必须要配置的就是找到官方的学习手册 让他去学习，比如说关于上下文以及日制的分类，还有记忆存储的这些功能，他都会自动去官方找到安装手册里面的内容去自动化去学习的。

quod code 有 记忆功能，但它背后怎么跑的不看源码根本不知道。比如它什么时候写记忆，不是你退出的时候，是你回复完那一刻怎么决定注入哪条，用 sonnet 单独跑一次只给两百五十六个 token。 这些设计细节全在源码里。今天来拆这个系列，讲上下文工程。 context engineering 前几期从外部行为推导，这期直接翻了源码。结论先给你 cloud code 记忆系统的设计哲学只有一句话， 只存不可派生的认知。为了让这一具真正落地，需要三层机制，各司其职，存得准，取得准，不过期。下面从源码拆这三层， 第一层存得准，先看存什么存什么，这个约束是整个系统的基石。源码注是第一行就写得很清楚，记忆只能存，无法从当前项目状态派生出来的上下文代码模式架构、决策， get 历史文件结构 这些随时可以查到的一律不能存，即使用户主动要求记下来也不行。记忆不是全量归档，是只存工具查不到的那部分认知。在这个约束下，源码定义了四种记忆类型。第一种， user， 记的是这个用户是谁， 比如哥老手，初次接触 react， 前端存下来，下次解释就用后端类比。第二种， feedback， 记得是用户给的，纠篇改错要记，被确认的做法也要记，只记错误会让模型越来越保守。第三种， project， 记得是当前项目进行中的事。 ddlance incidents 技术决策背景，注意，相对日期要转成绝对日期，周四要存成具体日期， 否则时间一过，记忆就失效了。第四种， reference， 记得是外部系统指尖 graph， 那 看板在哪？ linear 项目叫什么？跨工具的定位点。第一层存得准，再看怎么存。每一条记忆写成一个独立的 markdown 文件，文件头带 name， description type 三个字段。 description 特别关键，不是给人看的，是给后续召回时做相关性判断用的。描述越精准，召回越准。所有文件的指征汇聚在一个记忆缩影里，原码里叫 memory 点。 md， 这是缩影，不是内容。每行一个条目，严格控制在两百个里，你只够可能比奈，上限不是随便定的。这个记忆缩影会在每次绘画启动时注入镜，系统提示超出就截断，缩影失效。第二层 取得准，区分三个时机，第一个，启动时静态加载，把记忆缩影前两百行塞进系统提示，先交代背景。 第二个，绘画中动态召回，每次对话转折点触发相关记忆查找先并发扫所有记忆文件的前三十行，只读 frontmatter， 依次过，再把这份列表丢给 sonnet 做旁路调用，完全独立于主模型。这个 sonnet 调用只有两百五十六个 token 的 预算， 就是读 description 作匹配。拿到结构化， jason 就 结束了 sonnet， 从里面最多选五个相关文件，注入当前上下文。还有一个反直觉的设计，已经用过的文件 是在 sonnet 调用之前就被过滤掉的， sonnet 根本看不到它们。五个槽位全部留给新文件不浪费。第三个，后台自动提取，触发时机非常精确，是主模型产出，最终留给新文件不浪费。第三个，后台自动提取，触发的完整复刻 共享主代理的 prompt cash 几乎零成本启动，主代理那轮自己写了就跳过，没写才由这个子代理补上。 效率设计是两轮写法，先并行读，再并行写，不允许交错工具权限严格限制在记忆目录内删除命令被明确禁止。前两层管了怎么写怎么读，但这还不够，一个月前写进去的记忆 里面还指着一个已经被删掉的文件，那个 dead link 还在提醒你，但那天早就过了。旧的纠篇还在，但你早已不是当时那个水平的用户了。没有第三层记忆系统就是 一个正在腐烂的时间胶囊。第三层维护不过期，靠三个机制，分别从三个角度主动整合腐化内容，协助隔离，写入污染，读时预警，人工验证。第一个 alter dream 就是 最近网上传的比较火的做梦机制， 对应源码里的 dreampass 扣台子代理周期运行孵化的具体表现有四个，第一，代码库在变，记忆里的文件路径可能已经不存在。第二，项目状态在变，该的烂早就过了。第三，用户在进化， 旧的纠篇在新上下文里可能反而变成错的。第四， topic files 越来越多， description 之间开始重叠，召回精度持续下降。没有 auto， dream 记忆系统只是一个只增不减的日制堆。出发要过三道门。源码注是写得很清楚，先查时间，超过二十四小时再数绘画，累计五个。最后是分布式锁，防止多进城，同时跑 顺序按成本排，最便宜的检查放最前面。四个阶段。第一阶段 orient 定向 l s 整个记忆目录读记忆锁影全书，找孤儿文件，有文件，但锁影里没有，指真的。第二阶段， get 采集， 扫所有文件的文件头和正文标记漂移的记忆。 description 和内容对不上的，相对日期已失效的文件路径。不存在的，这些都标出来。第三阶段， consolidate 整合合并重叠文件，重写 description， project 类过期记忆不直接删，降级标记为历史。 第四阶段， prune 减脂重写记忆，所以去掉过十条目，确保总行数不超过两百行。 常识绘画模式下切成枝追加的日制写法，每天写一个按日期命名的日制文件，由夜间 dream skill 蒸馏。为什么不直接覆盖写常识绘画中主代理还在运行，实时修改 topic files 有 数据竞争风险，追加日制绝对安全，不干扰主流程。 第三层维护不过期。另外两个机制，第二个团队记忆格离开起团队模式后变成双目录。 private 目录只属于当前用户替木子目录跨贡献者共享四种类型的私客服推荐 user 永远 private feedback， 个人纠偏放 private。 团队规范建议 team project reference。 强烈建议 team team 记忆里绝对不能存 a p i t 或凭证。第三个新鲜度警告，超过一天的记忆会自动附上一段提示。原码里的原文是这样写的，这条记忆是若干天前的 记忆，是时间点上的观测，不是实时状态。代码行为的判断，文件行号的引用可能已经过时，用之前先验证当前代码。 记忆里提到某个文件路径不等于这个文件，现在还在记忆里提到某个函数不等于这个函数。现在还有三层都拆完了，这期三个原码细节带走 description 字段是给 sonnet 读的，不是给人看的，它决定了召回质量。 auto dream 是 记忆系统的基 c， 没有它记忆，只是越堆越烂。 ceonis 警告的逻辑，记忆说文件在不等于文件现在还在，不是让模型记住一切，是让模型记对该记的。本期内容就到这里了，现在你知道了，不是模型在随机遗忘， 是系统在精心选择。记忆的质量决定了对话的质量。点个关注不迷路，我们下期见。

这是个能让 cloud code 的 一句话，读懂你百万行代码库， token 直降百分之四十的开源神器。每天一个硬核的网站推荐第三十九期。今天要讲的是这个项目叫 cloud context github 已经飙到十 k star。 它做的事只有一个，给所有 ai 编程助手装上一颗代码大脑，一次缩影，全项目语域搜索。 什么意思呢？以前用 cloud 写代码， i 看不到你的完整项目，你得一个文件，一个文件复制粘贴位给他，又慢又费。 token 装了这个之后，你 直接用大白话问他，自己从整个代码库里把相关代码拎出来，精准又省钱。三个核心功能，语义代码搜索、增量锁影、 a s 智能分块、官方实测。同等解锁质量下， token 消耗直降百分之四十。有了它，恭喜你离下一个赛博精英又近了一步。

cloud code 最近发布了全新的实战使用指南，我觉得对于新手小白来说非常的友好，因为它是从 cloud code 的 安装配置到记忆的管理，到如何添加记忆，到如何 呃使用它的记忆文档，然后到上下文的优化管理，以及对于呃 hux 就是 它的工具，使用前使用后的整体的定义的使用流程，还有常用的常见的坑点，全部用实战案例给我们介绍了一遍，以及 m c p 服务对于可洛德在可洛克的整体的生态， 生态中的作用，然后等等等等。包括使用 cologne code 的 五五大使用原则，还有一些非常实用的小技巧，比如 cologne code 在 在进行页面设计或者 ui 设计的时候，最关键的最有效的沟通点其实是用截图来跟它沟通，这个 cologne code 官方教程中都有非常明确的介绍，然后我也是基于他的官方的文档和他的具体的视频介绍，把它沉淀成了一份非书的原文档。然后这里面详细介绍了可拉可拉的 code 的 架构，包括用很多流程图和 图像，非常给大家生动的说明了这个可拉的 code 的 使用过程，我看完其实受益匪浅的。如果大家需要这个非书文档，可以关注我，然后私信我给大家发一下这个非书文档非常有用。

hello， 各位，我相信大家呢，和大魔星对话的时候都会有这样的体验，花了四个小时呢，和 cloud 调试了一个 bug， 好 不容易解决了，第二天早上再打开这个新的对话，那 cloud 呢？对昨天的事情，哎，可以说是一无所知啊，你得从头去解释你自己的项目结构，从头去提醒它，再去构建命令， 这个体验呢，真的是烂透了，那二月二十七号呢， ansotek 在 cloud code v 二点一点五九里面，这个版本啊，正是上线的一个功能，叫做 auto memory， 就是 为了解决这个遗忘的问题。但是呢，它解决得好还是不好，有没有新的坑？值不值得大家现在就去打开 这个，大家可能都是诚意的，所以今天我就来深度拆解这个 auto memory 自动记忆这个机制， 把这些问题给大家去说清楚。首先我先给大家去讲清楚这个核心概念， what memory 到底是一个什么东西？那首先呢， cloud code， 它里面的记忆啊，它不是一个东西，而是两个，你看记忆系统呢，其实分了两个，第一个叫做 cloud 点 md 啊，这个是 我们写的，那里面包含了我们之前有写过的，像编码规范，像构建的命令，像一些团队约定。那还有一个板块呢，就是 osm memory 呢，它这个是 cloud 自己写的，那这里呢，就包含了像调试经验，项目模式以及工作习惯， 比如呢，项目用了什么构建命令，测试怎么去跑，你踩过什么坑，包括你填好什么风格 cloud 呢，都会把这些笔记写进本地的一个 markdown 文件，那下次开新的对话的时候，它就会自动加载这个文件，这里呢，一定要注意我刚说的那个词叫做自动，也就是 auto， 你不需要告诉他，哎，你把这个给记住了，然后你也不需要去手动维护这个 mac 档的文件，你只需要正常工作，他自己呢，会决定什么值得去记，怎么去记？这个就是 auto memory 的 一个核心的卖点，也是他最大的一个争议来源啊，那为什么会有争议呢？我们后面再讲，我们先讲他怎么去运作的。 首先我们先搞清楚这个 cloud md 啊，到底是存在哪里，它其实存的呢，是在你的这个点 cloud 的 根目录下，然后 projects 里面可能是你的某个项目里面的 memory 这文件夹， memory 里面呢，也包含了四个标准的一个 markdown 的 文件啊。首先就是 memory 点 md， 这个呢就是主入口，它主要做的是一些缩写文件。 那第二个就是 bug 点 md 啊，这个顾名思义就是一些调试的笔记。另外呢还有 api 杠 conventions， md， 这个呢就是 api 的 设计决策，包括 build patterns， 这个呢是构建模式， 每个项目呢都有自己的这个独立的记忆目录，这个路径呢，是从你的 get 仓库的根目录去推导出来的。 ok， 那 重点来了，同一个仓库的所有子目录都共享的是同一份记忆，那 memory 点 md， 它就是 核心，每次你去启动这个新的对话，他要扣的会自动加载这个文件的前面的两百行啊，然后呢，加载到你的这个系统提示词里面。 另外呢一定要注意，就是两百行，他是一个硬的上限，超出的部分也不会去加载。 ok， 那 他可能会有些好奇，为什么会是两百行？其实我自己一开始呢也比较好奇， 大致看了一下，它其实就是一个 cloud 的 设计，它逼着这个 cloud 的 这个模型把这个 memory 点 md 啊，保持得很精简，像一个目录，而不是一个百科全书。 那详细的内容呢？会拆到了像 debugging 点 md， 包括 api convention 点 md 这样的一个主题文件里面，那 cloud 的 需要的时候再去按需提取，前提是它知道自己是需要的。 ok， 接下来我们再去讲 auto memory 的 一个三种的管理方式。第一种呢，就是被动模式，什么都不用做，你正常的去写代码，那 cloud 就 会在工作中列出，自己去判断这个是不是值得记，然后呢去把它给写进去，你甚至都不用去注意到。 ok， 这个呢，我觉得是最轻的一种模式。第二种呢，就是主动指示你直接去跟 cloud 说，你要记住我们要用什么，不要用什么，然后记住呢，每次去提代码之前要去跑一次 m p， m test， 他 呢就会把这些也写进 memory 点 n d， 我 觉得这是一个比较中度的一个管理。那第三种呢，手动管理，你直接在 cloud 里面去 加上这样的一个命令， memory， ok， 那 cloud 呢，它就会弹出一个文件选择器，你可以直接打开任何的记忆文件去做一个编辑，里 面还有个开关，可以键去关闭或者打开 auto memory。 主动管理也定义成一个更重度的一个记忆管理啊，有点像去 hack 这个代码一样。 ok， 我 觉得 auto memory 呢，它不是凭空冒出来的，那在它上线之前的开发者社区其实已经喊了很久了， 所以呢，我给大家去整理梳理一下这个需求的演变，那在二零二五年十二月的时候就有一个意思，又说希望不要让 cloud 每次启动都去从零开始。你看它说 persistent memory between hello code session， 然后到二零二六年一月呢，又有个意思，又说 add automatic memories like chad dt。 哎，关键词呢，就是 automatic。 然后在二零二六年二月啊，他提出在 context window 里面去压缩前啊，主动去保存研究成果。 所以如果把这三个要素给拼在一起，你就能看到一条完整的进化线。第一个就是需要先记住，然后呢再去自动记住加自动化，那自动记住以后呢？在关键的时候自动记住。 而现在呢，奥特曼目前走到了第二步，就是能够自动记住，但是第三步我觉得还没完全到，但是呢，已经在路上了。 好，那到这里，整个奥特 memory 的 这个原理和概念都介绍完了，所以你看呢？其实这么看下来啊，从技术到智能技术，到关键时刻智能技术，这个大家都能想的到， 他也不是一个很革命的突破，但解决的确实就是一个本来就不应该存在的问题。 ai 助手呢，不应该每次对这个对话都失忆，所以从这个角度来说，他只是把一个严重的体验缺陷修补到了及格线。 那他修补的方式是很聪明的，通过成本，通过完全的透明，通过分层架构，再通过多级的控制。这些设计决策表明了 snoop 至少想清楚一件事情，记忆系统最大的问题不是遗忘， 是失控。所以我的建议很简单，就三句话，第一个，哎，打开 cloud 让他跑。第二个，每周花十分钟去审查你自己记录好的这个 memory。 第三个，像对待一个记忆力忠于不为零的新同事一样去对待他。 另外还有个关键就是你需要主动的去管理 memory， 而不是每次都是被动的让 cloud 去自己去写，被动的去接受。 好，那今天的这个 auto memory 这个介绍啊就到这里，然后大家如果有什么其他问题呢，也可以随时去在评论区进行交流，觉得是有价值的人呢，也欢迎点赞关注收藏一下。

因为有被网友问到如何解决 a a 整的记忆问题，那我就用小白能听懂的方式详细讲一下所谓的记忆到底是什么，以及你们该如何处理这个问题。首先我觉得记忆这个词有点过于拟人化，你们可以暂时不用管这个词， 你可以把你和 calco 里面的对话比喻成你和 calco 大 模型三方之间的一个会议，那会你们日常中是如何让开会的人进这个会议的内容呢？ 没错，就是会议纪要。 ai 一 整中的记忆，你其实可以简单理解为它就是一个会议纪要，这不，瞬间思路就打开了，聪明的小伙伴已经知道该怎么解决了。我们真正要理解和解决的是，当 a 一 整接到一个新的任务的时候， 他能不能把过往会议中提到的跟这件事相关的关键性提取出来，作为这次回答的依据。比如你说用我的风格来改一下这文案，那他怎么知道什么是你风格？因为你之前说过，我的风格是这样的， 之前说过的内容就叫做上下文，而上下文还包括 ai 之前的回答以及一些其他东西，这你先不用管，而所谓的记忆解决的就是我之前说过的事情，他知道并能够参考，这样我就不用重复再说了， 能理解吗？现在其实我们有三个角色，一个是你，一个是 coco， 一个是大模型，在上下文的处理中，这三者到底什么关系？ 你在一个项目中打开 coco 跟他聊的时候，理想情况下，你们前面聊的内容，包括你发的，包括大魔星回的，都会成为后面继续聊天时的上下文。也就是说，当你发一个新问题的时候， coco 会把你新发的内容加上以前相关的上下文，一起发给大魔星， 所以大模型才能整体性的回答你。好，说到这里就出现了我们要处理记忆的第一个问题。当对话聊太久，内容太多，接近大模型能处理的上限时超过，会做一个压缩的动作。你可以理解为把前面的很长的上下文整理成一个摘药。这就好像开会开了很久， 会记录记得太久，最后有人把它压缩成了一页的会记药。这个动作本身是没问题，但是你要知道，摘药他不是原文，他会尽量保留重点，但有一些细节可能会丢。这就是我们要讨论的第一个记忆问题。聊太久之后，重要的细节 可能在压缩过程中变弱，甚至被遗忘。这就好比假如你和同事开会开的太永常，可能会忘掉一些会议细节。关于记忆的第二个问题是什么呢？每次对话，聊天内容更多是一种临时的现场记忆，你下次重新打开一个对话，他不会自动完整带上上一次的所有的上下文，也就是 ai， 他 不知道上一次发生了什么。 那怎么办？这就是我们要解决的问题。开会的时候，上下文就像是会议现场的信息和长期记忆。 其实就是会议啊，最简单的方法就是在拷扣里面做会议胶。这么简单，那最原始、最简单也最费劲的方式是什么？就是你手动作，如果你特别在乎拷扣、压缩上下文时会丢失信息，那你可以在关键对话，甚至在每轮对话的时候，问他这轮对话有哪些长期有价值的信息， 把它记录到什么文件中，然后在下次开会前让 ai 再读一遍。如果你不太在乎中间过程，只在乎这次任务结束后能不能接上，那你也可以在关闭这次对话之前问他我们这次所有的对话中有哪些长期有价值的信息，把它记录到什么什么文件中，下次开会前再让 ai 重新读一遍。这动作呢，就等于你把会议要发给同事， 那你们在下次开会的时候就有了统一的背景信息。同理，对于我们和大模型的第二次会议，每一轮的对话的内容都应该关联到上次会议纪要的某一些特定的内容。包括我刚刚说的，在在你下次开会的时候，让大模型读一遍上次会议纪要，是非常浪费上下文，浪费 talk 的 会议纪要。如果太多太杂、不分类，参会人员看起来会很费劲的。比如说我是只能 a 的 人，你让我看一堆只能 b 的 会议札要，那我看他来干嘛？同理，你下次再跟大模型聊天的时候，只需要关联上一次会议札里的某一段的特定内容。 如果你每次都让大模型读完整个绘剂，要非常浪费上下文，也非常浪费头更。所以这里涉及到绘剂要需要分类管理，你的绘剂要需要有个大纲目录， 这个大纲告诉 ai 在 处理什么任务时读哪些内容。接着说下一个问题，刚才我说每次都要手动总结一遍，你肯定会觉得很费劲，那有没有自动总结的办法？说到这里呢？很多博主都会提到长期记忆的一些解决方法可能都是可以解决的， 但对于小蛙来说，真的理解起来很费劲。我刚开始接触小龙虾的时候也这样子，从安装过程就开始看教程，装完之后呢，这个博主说要装，那个博主说要解决记忆问题。而且有一些人上来就说， 每次打开卡拉扣的新对话框，他就像失忆了一样，所以看的我真的是又焦虑又懵，无脑照着做又不知道原理，结果做了很多无谓的工作。我可以这么说，我现在用卡拉扣和扣带丝， 外面别人分享的 skill 我 其实没用，一个都没用。不是说 skill 没用，而是对小白来说，先理解原理，比无脑照着别人装一堆东西更重要， ok？ 再说回自动做会议架的方法，你其实不需要一上来就参考别人的复杂方案，你可以直接让人家帮你做。比如说你对着人家说，我希望每次对话结束后，你能帮我提炼这段对话中有长期价值的信息，然后把它分类记录下来。我希望这个过程尽量的自动化，不要我每次都提醒你， 请你根据我的项目帮我制定一个实施的方案给你方做，你看不懂你就继续问他，叫他解释就完了，哪里不合理你再叫他调整，最后让他按着方案去操作。对 ai 整的记忆问题，说到底他不是一个记忆问题，而是一个记录的问题，你要给他建立一套 清楚的记录和整理的机制。当然这个记录啊，整理的事情其实还没有结束。还有一些别的问题，比如说每次开会都记录，那所有的历史记录是不是都放在一个文件里？你新开会的内容和很久以前开会的内容， 他们的关联度高吗？需不需要删除掉一些历史内容？如何定期清除无用的内容，从而减少上下文中无意义的信息，减少做客的消耗？这些又是另外一个话题。

cloud 正在测试双模记忆系统，新增 memory files 文件记忆，还为七 x 二十四小时长驻 agent com 铺路。这个变化最直接的影响是， ai 不 再只靠一段会被覆盖的聊天摘要记住你， 而是开始像一个长期工作的助理一样，把项目偏好、决策上下文分文别类存起来。过去， cloud 的 记忆更像一张不断滚动的便签，它会把了解过的用户信息压缩成一条摘要，短期使用很方便，但信息一多就会出问题。 你昨天说过的咖啡口味可能还在，他却可能忘掉你上个月花几个小时讨论过的产品架构。因为单一摘药天然有长度限制，新内容会挤掉旧内容，琐碎信息也可能盖过真正重要的决定。这次被 testing catalog 发现的新方案，核心叫 memory files， 也就是文件记忆。你可以把它理解成 cloud 内置了一个个人 wiki， 它在对话过程中不只是回答问题，还会按话题、项目和上下文自动整理成结构化文件。以后你再聊相关内容时， cloud 不 用把所有记忆一股脑塞进上下文窗口，而是按需读取对应文件。聊代码就调技术文档，聊旅行就调出行偏好，聊某个长期项目就翻这个项目的决策记录。 这个架构真正厉害的地方，不只是记得更多，而是记忆的使用方式变了，容量不再被一条干扰卡住，理论上可以随着文件系统扩展，准确性也会更高，因为它不是全量记忆暴力贯入，而是只取当前任务需要的部分。 对用户来说，控制权也更明确。资料里提到，用户可以像编辑 wiki 词条一样查看、修改、删除 cloud 的 记忆文件，不想让他记住某件事，删掉对应文件就可以，不过记下来只是第一步。真正让这套系统变得有意思的是另一个功能， dreamsanthropic 在 旧金山的 coldwave cloud 开发者大会上展示过这个概念，名字叫做梦，本质是一种异步后台记忆整合机制。它借鉴的是人类快速眼动睡眠的逻辑， 白天经历很多信息，睡眠时大脑会回放筛选、强化重要连接，把短期记忆整理成长期记忆，放到 cloud 的 身上，就是智能体。在两次工作绘画之间闲下来时， dreams 会自动整理 memory files， 重复的内容会合并，过时的条目会更新，冲突的信息会重新判断可信，甚至可能发现对话当时没有注意到的隐藏模式。比如昨天我们决定用 readis 这种临时描述，可能会被整理成待日期的项目决策记录。 说得直白一点， code 白天干活，后台复盘，下一次继续工作时不再向重新开局。目前 dreams 已经在 code code 里以 auto dream 的 形式出现， 资料里给到的触发条件也很具体，至少累积五次对话，或者距离上次整理超过二十四小时，也可以手动输入住 em 出发首批接入的企业案例包括 netflix recutin west docs。 材料中提到，首首次处理错误率下降百分之九十七，文档验证速度提升百分之三十。 这些数字如果放在企业工作流里，意义非常直接。 ai 少犯错少返工，才能真正进入长期生产系统。更大的主角是 conway， 三月底 antropic 意外泄露的五十一点二万行 cloud code 原码让外界第一次看到这个项目的影子。 随后 testing titlelog 也确认 conway 是 一个永不下线的 ai 智能体平台，它不是更聪明的聊天框，而更像一个常驻后台的工作环境。现有 ai 助手大多是被动式的，你发提示词，他给答案，对话结束，任务也就停了。 conway 瞄准的是另一种模式， 你不在的时候，他仍然可以运行。资料里提到， com 会在 cloud 现有界面侧边栏里作为独立入口出现，并且有搜索、对话系统三个核心功能区。他能够监听外部事件，主动触发任务，通过 webhook 接收信号，操控浏览器运行 cloud code， 甚至支持 c n w c i p 这种自定义扩展包格式。换句话说，他想做的不是陪你聊天，而是持续接收信息、判断状态，执行任务。 这也解释了为什么文件记忆和 dreams 会在这个时间点变得关键。一个七 x 二十四小时运行的 agent， 最怕的不是单次回答不够聪明，而是没有长期上下文。他 必须知道以前做过什么，为什么这么做。哪些决定已经被推翻，哪些偏好不能忘，哪些系统权限可以用 memory files 提供存储结构， dreams 负责清理和维护， com 负责持续行动。三者连起来才像一个从记忆到反思再到执行的闭环。安全性也是这件事里的关键变量材料把 com 和 openclaw 做了对比。如果我的视频对您有帮助，请点赞加关注，感谢您的观看。

call 的 call 上下文爆了反不出错，不是他不行，是你没有配置正确百分之九十的人第一步就错了。今天这九个基础技巧学会，直接让你的 call 的 效率翻倍！点赞关注加收藏，防止以后找不到哦！ 大家好，我是 win 好！ 技巧一，斜杠 in it 项目的记忆注入打开任何一个已有的项目，第一件事，输入斜杠 in it， call 会扫描你整个代码库，文件夹结构、文件内容、代码规范，然后生成一个 call 点 md 文件。这个文件相当于给你的 call 植入一份项目记忆，以后每次新对话，它都会自动读取这个文件，直接知道你的项目长成什么样子。 没有这个文件，每次都要重新解释一遍你的项目有了它，开局就省掉十几条消息。如果你是全新的项目的话，也可以直接告诉 call， 帮我创建一个 cloud m d 项目，目标是什么，技术栈是什么，它会帮你从零写好这个文件。技巧二， status live 实时监控仪表盘输入斜杠 status live， 告诉他你想在底部显示什么模型名称，上下文百分比花费。 它会在你的终端底部生成一个状态栏，每次对话都能看到你当前使用的一个开源库 cloud dashboard。 为什么这很重要呢？因为上下纹一旦超过百分之六十到七十，就会出现上下纹腐坏， call 的 call 的 回答质量就会有明显的下降。 有了这个状态栏，你能提前知道什么时候该压缩，什么时候该清理。技巧三，保持你的上下纹清爽这条听起来好像是句废话，但是大部分人都在犯这个错误， 把整个代码库丢给 cloud， 然后说帮我改个 bug 吧。正确的做法是什么呢？只给当前任务需要的文件或者上下文。大问题拆成一个个小步骤，一步一步来，上下文窗口里面的噪音越少， cloud 的 扣它的表现越好。记住这个原则，少即是多。技巧是斜杠 contest 找到 token 的 杀手。如果你觉得当前的对话变慢，回答变差，输入斜杠 contest， 它会列出到底怎么再吃掉你的 token。 系统提示词占多少，文件内容占多少？ m c p 服务器又占多少？全部都按百分比拆解。我之前有一次发现一个 m c p 服务器吃掉了我百分之三十的上下文，关掉之后，体验直接拉满了。技巧五，斜杠 compass 还有斜杠 clear 对 你的上下文进行管理。这两个命令一定要记住。 第一个，当上下文达到百分之六十或七十上下文腐块的时候，输入斜杠 compact called 会压缩你的对话历史，释放空间。高级用法就是你可以指定保留什么，比如斜杠 compact， 但保留数据库 scammer 和 api 设计决策，它会智能压缩，只留你想要的。 第二个就是，任务做完要切换方向了，你就直接斜杠 clear 清空对话重新开始，不用担心你的靠点。 m d 还在，项目文件还在，只是对话历史清掉了 一个，压缩一个，清空，上下文管理就靠这两招了。技巧六， plan 模式，让 cloud 先想清楚再动手，按 cf 加 tab 切到 plan 模式。在这个模式下， cloud 可以 读取你的代码做研究，但不修改任何的文件。它会先列步骤问你问题，规划方案， 等你确定计划没有问题了，再切出 plan 模式让他执行。这一步能够减少百分之五十以上的反攻。因为靠的在没有计划的情况下直接写代码的话很容易走偏。先规划再执行，这是最基本的工程思维。技巧七，给问题而不是给指令 不要说写一个函数去做什么，而是说我们应该怎么去处理这个问题。让靠的先思考再输出， 质量明显会更高。这也是 mflopik 官方推荐的用法，把它当成一个初级开发者来带，而不是一个指令执行器。技巧吧，让 call 的 主动问你问题， 你可以在每次提示词的最后加一句魔法 pro 持续向我提问，直到你有百分之九十五的信息理解我的需求， call 的 就会反过来问你各种澄清的问题。用什么框架？要不要兼容移动端？数据从哪里来？ 前期多对齐一分钟，后期少改半小时的代码。技巧，就代办列表里面塞自检的步骤。靠的执行任务时会自动创建一个代办列表，你可以在列表里面 插入验证的步骤，比如第一步，构建页面，第二步，截图检查布局。第三步，打开浏览器测试功能，再加一条，每个步骤做到百分之九十五满意了再进行下一步。这样靠的不是做完自查确认再交付， ve 的 质量直接提升一个档次。这九个技巧就是 card 扣的地基，地基打好了，后面的进阶操作才有意义。下一期我会继续讲 card 的 他的进阶操作，教你把 card 扣当成一个开发团队来用。关注我，不迷路，我们下期见！

cloud code 的 绘画每次都是从全新上下文开始的，那它是怎么记住你项目的呢？靠两套互补的记忆系统，你手写的 cloud md 文件和 cloud 自己记笔记的自动记忆。今天我们就先从这两个系统的分工说起， 然后逐层深入文件位置、编写技巧、规则，组织自动记忆的工作原理，最后聊故障排除。 cloud code 有 两套记忆系统，各司其职。左边是 cloud mb， 你 手写指令，每个绘画完整加载， 覆盖项目级、用户级、组织级范围，用来定编码标准和工作流。右边是自动记忆， cloud 自己写笔记，只加在前两百行或二十五 kb， 用来存构建命令、调试心得这类他自己发现的东西， 一个你主动写规则，一个他自动学模式，两套一起用效果最好。 cloud md 有 五个层级，从最广到最具体 层级。一是 it 部署的托管策略，全公司强制层级。二是用户级存在 cloud 下，你的个人偏好放这层级。三是项目级，存在仓库，跟目录团队共享是最推荐的方式。层级四是 cloud 点 local 点 mb 以 g t n o 只属于你层级。五是子目录里的嵌套文件， cloud 用到时才加载。 注意，所有层级是连接加载，不是覆盖。越具体的指令越厚读优先级其实更高。 写好 cloud md 就 四个原则，第一，两百行以内抄了分到路径规则里。第二，用标题和列表组织，别写长篇大论。第三，指令必须具体到能验证。不要说格式化好代码，要说用二空格缩进。 第四，定期检查冲突。比如一个文件说用 tab， 另一个说用空格， cloud 会随机选一个。记住， cloud md 是 上下文，不是配置，它引导行为，不是强制执行。 项目大了以后，把所有指令塞一个 cloud md 里就乱了。 cloud rules 目录让你按主题拆分成多个文件， 每个文件只负责一件事，比如 code style md， testing md， security md 还可以用 frontmatter 的 patch 字段写路径范围规则，只有处理 typescript 文件时才加载 api 规则，省上下文 符号链接，可以跨项目共享规则，用户及规则放 clod rules， 个人偏好和工作流放纳。自动记忆是 clod 自己写的笔记系统， 他在工作时自主记录，构建命令，调试心得，架构信息，这些他觉得以后有用的内容。存储位置在 cloud projects 下。每个项目一个目录核 心文件是 memory mb， 每次绘画只加在前两百行或二十五 kb， 超出的拆到 debugging mb 这些主题文件里，需要时按需读取，默认开启，可以用 memory 命令管理，或者设环境变量关掉 记忆系统出问题一般就四种情况，第一， cloud 不 听话，先跑 memory， 看文件加载没检查指令够不够具体。 第二，不知道自动记忆记了什么， memory 里直接打开文件夹，全是铭文 markdown。 第三， cloud md 太大，超两百行了就拆到路径规则里。 第四， compaq 之后指令不见了，跟目录的 cloud md 会自动重载，但子目录的不会对话里的指令你得手动加进文件里。 需要记住的是，第一排查永远是跑 memory。 最后来个总结，第一， cloud md 和自动记忆是互补的，一个你写规则一个 cloud 自动学别只用一个。第二，指令要短于两百行，写得具体没有自相矛盾。 第三，用 cloud rules 按主题拆分规则，路径范围，控制加载时机。第四，遇到问题先跑 memory， 这是最好的诊断工具。 核心原则是 cloud md 是 上下文，不是配置它引导行为，而不是强制。用好这套记忆系统， cloud 就 能越来越懂你的项目。

用 cloud code 做开发的人，应该都有一个特别烦的痛点，每次关掉会话，重新打开窗口，都要反反复复介绍一遍项目架构，用的什么技术栈、代码、命名规范，还有自己的开发习惯，一遍又一遍重复交代，既浪费时间，还特别影响开发效率。其实根本没必要这么麻烦， cloud code 自带一个超强隐藏功能，项目记忆 cloud md， 而且重点是不用你手动建文件，不用自己手写配置，你只需要直接跟他口述指令，把我这个项目的技术栈、目录、规范、代码风格、开发习惯全部写入项目记忆，它就会自动在项目根目录生成并更新 cloud md 专属记忆档案， 全程不用你动手写一个字， ai 全自动帮你整理存档，里面会自动记录好项目整体架构、所用技术栈、文件夹、命名规则、 代码、书写风格、注视习惯，还有你平时的开发要求，也都会记录进去。只要设置一次，永久生效，以后不管新开多少次绘画换多少个窗口， cloud code 都会自动读取这份项目记忆。不用你再重复介绍任何背景信息， 它会完全按照你的编码习惯、你的项目规则去写代码、改 bug、 做功能、重构，写出来的风格跟你完全契合，不用反复磨合。 新手也可以直接输入斜杠命令 init， 一 键自动生成标准 cloud md 模板，稍微微调一下就能直接用。学会用好项目记忆， cloud md 彻底告别重复交代项目的麻烦，让 cloud code 越用越懂你，开发效率直接拉满！关注我，带你了解更多 ai 知识！

这是个能让 cloud code 的 长期记忆，就算关机重启进度也不丢的强大工具，每天一个硬核的网站推荐第三十八期。今天要讲的是这个项目叫 beats， github 上已经狂揽了二十二 k 的 star。 核心就解决一件事，给你的 ai agent 装上一颗长期记忆的大脑， 底层用的是 dos 数据库，数据全存你电脑硬盘上，它有什么优势呢？第一，零内存占用，不污染 agent 上下文。第二，就算关机重启， agent 关 大了，任务状态全都在。第三，像 get 一 样，有版本控制，能回滚，能分支，能合并。第四，查询速度极快，一万条任务查询只要三十毫秒，哈西 id 冲突概率极低，多 agent 并行，互不干扰。 cloud cortex gemini 开箱即用。有了它，恭喜你离异人公司又近了一步。