Memory is what allows Claude to learn from experience. In a new Engineering Blog post, we share how “dreaming” helps Claude organize what it’s learned, correct its mistakes, and find what it needs more easily the next time.

以前我团队有个员工做事比较粗心，也比较懒，每次让别人 Review PR 都不自己测，一审查就发现很多问题，后来我就让他提交 PR 的时候必须要带上相关功能修改的截屏，这样效果很好，至少去截图的时候得测试一遍。 现在我也把这一套应用在 AI 身上了，每次 Agent 任务完成，让它自己测试验证后，生成效果截图，让我看看效果。很多时候它自己截图的时候就发现问题，能顺手修复一下。

Anthropic's valuation has now been roughly cut in half from the lofty $2 trillion heights that were being spoken of in financial circles only a month ago. On the plus side, if you are a believer, you can now get in for about half price. The IPO media blitz is starting Monday.

感谢分享，我说一下我在上一个版本 baocut 用 GPUI 踩的坑。 GPUI 挺好的，性能好，跨平台，AI 友好，但也有坑： 1. UI 复杂一点的话大概率你要 fork 一份改一下，有些功能原生支持不了，但也不是大问题 2. Accessibility 支持不太好，要支持一些键盘操作会比较麻烦（也可能我用法不对） 3. Rust 编译资源消耗很大 每次编译，无论是 CPU 占用还是磁盘占用，都巨大，对于我这样用 Mac Mini M4 16G + 1T 硬盘的来说简直太痛苦了，不敢并行多开编译任务，磁盘空间永远不够用（后来我把编译结果默认放到移动硬盘缓解了一点） 4. 编译时间很长，不支持热更新。 这点很要命，这意味着你如果改一点 UI 代码，要重新编译，然后要等少则几分钟多则十几分钟，这时间无论对于 agent 还是对于人来说都是很大的时间成本，加上不能随便多任务，会拖慢你的开发速度 5. agent 验证 UI 不算太友好 codex、claude code 都可以借助 computer use 去验证 GPUI 的结果，但一个是慢，另一个相对成本也不低。 --- 后来我之所以换回 Electron，就是因为 Electron App 对于 Agent 相对友好，编译快、热更新，UI 改动很快看到效果，然后 Electron App 还能跑到 agent 内置的浏览器中，agent 验证起来很快，都不需要用 computer use 去打开 electron app。 至于网页渲染性能不够好的问题，我把原来一些需要复杂渲染的部分，都用 rust 编译成了 wasm，这样在浏览器运行也可以保证高性能。 以前 rust 做的转录、tts 模块也都以 worker 进程的形式保留下来了，electron 需要用到的时候可以直接起 rust 编译出来的进程（Codex 也是类似），和这些进程通信，后台的性能也比纯 TypeScript + Node 要好不少。 有兴趣的话可以看代码库：

更新了 Baoyu Design Skill 的 DeepSeek Harness 插件，现在可以有统一的入口，看到所有生成的 Slides、Design、Dashboard、Motion 的结果，也方便发起相应的会话。 更新地址：

Anthropic 的 Addy Osmani：一天合并三万次代码变更，人看的是 AI 交上来的证据 Anthropic 今年 5 月每天往代码库里合并大约 2500 次代码变更，到 9 月已经超过 3 万次，涨了十几倍。这么多改动，显然不可能每一行都有人看过。那他们凭什么敢合并？ 负责 Claude Code 开发者体验的 Addy Osmani 在这场对谈里讲了他们的做法：每个改动先由 Claude 像真实用户一样实际用一遍、审一遍，发现问题自动修；人不再逐行读代码，而是去看 AI 交上来的证据，比如它在浏览器里点来点去的录屏、在手机和电脑上的截图。 在他看来，写代码已经不是难点，接下来能不能再快一截，取决于能不能把“验证”做扎实。给 AI 一个检查自己做得对不对的办法，产出的质量能好两到三倍。如果你也在用 AI 写代码，又拿不准哪些改动敢直接合并，这期给了一份大公司内部的参考答案。 这是 AI Engineer 大会上一场 18 分钟的台上对谈。Addy Osmani 在 Google 工作了大约 14 年，长期负责 Chrome 的开发者体验，写过大量面向开发者的文章，今年 9 月加入 Anthropic。提问的 Manish Kapur 在 Sonar 负责产品和开发者关系，Sonar 是做代码质量和安全检查工具的公司，旗下的 SonarQube 用来自动扫描代码里的漏洞和问题。 【Anthropic 的做法：Claude 先审一遍，人看证据】 Manish 提到，他前一晚刚读了 Anthropic 发的一篇文章，里面说 Anthropic 现在每天合并约 3 万次代码变更。Addy 补充了两个数字：5 月的时候每天大约 2500 次；最近 网页版重做，性能提到了原来的三倍左右，这次重做在很短时间里合并了大约 3000 个 PR（代码合并请求），参与的不只有工程师，还有产品设计师和其他岗位的人。 他说他们的审查流程分几步。第一步是让 Claude 先审一遍，关键在于要让它能像真实用户一样把功能实际用一遍：跑端到端测试（从头到尾模拟用户操作的自动化测试），在浏览器里打开页面检查，运行各种工具和代码规范检查，凡是能建立信心的检查都做。 发现 bug 或者功能缺口怎么办？他们设置了 Hook（一种在特定时机自动触发的脚本），每次代码有改动就自动运行，检查这次改了什么，这样 PR 里的问题能尽快被改掉。Anthropic 还有一个代码审查产品，他们自己也在用。整体思路是尽可能把代码审查自动化。 第二步是把团队的“品味”写下来。Addy 说现在大家常讲品味和判断力，团队应该把自己认为的最佳实践和品味写进共享的 CLAUDE.md、AGENTS.md 这类文件（放在项目里、专门写给 AI 看的说明文档），AI 审代码时会去参考。 第三步才轮到人，人负责检查 AI 给出的证据。他举的例子是：做一个用户在浏览器里用的界面，就要确认它在浏览器里测过，最好让 AI 生成一段它点来点去的录屏，看完你就有信心说“这个能用”；在意手机或桌面端的体验，就让它给出这些设备上的截图或录屏。他说目标是让 AI 尽可能多地提供验证证据。 【瓶颈从写代码转到了验证】 Manish 给了几组数字说明问题。持续集成服务 CircleCI（代码提交后自动构建、测试的云服务）今年分析了 2800 万次自动化流程，发现代码产出量涨了 59%，但每 10 次往生产环境合并的尝试里有 3 次失败。Sonar 即将发布的一份调查里，76% 用 AI 生成代码的开发者说，代码产出的速度快到他们根本来不及验证。 Addy 说，现在技术负责人最关心的是怎么在保证有信心的前提下更快上线。过去我们说一段代码质量高，依据是好的测试、性能基准、需求规格，这些能给人信心的东西现在都可以让 AI 便宜又快地生成出来，人再去修改完善。他认为工程师现在最该花时间的就是这些检查。 至于下一步的提升从哪来，他说模型质量已经相当不错了，他举了 Opus 5.5 为例。更大的空间在验证，而且要讲具体。你跟人说“验证一下”，对方下一个问题就是“验证到底指什么”。所以讨论应该落到哪些测试真正有用上。Anthropic 用得最多的是三类：端到端测试；属性测试，也就是不写一个个具体例子，而是写一条规则（比如“排序后列表长度不变”），让程序自动生成大量随机输入去验证；还有视觉验证测试，通过截图对比检查界面有没有变样。目标是有足够的信心让这些改动自动合并。 Manish 从 Sonar 的角度补充了一个“多层验证”的框架，主张零信任，在每个环节都验证。第一层是规则固定的自动扫描，查 SQL 注入这类安全漏洞和常见 bug；第二层是 AI 审查，查规则扫不出来的逻辑问题，以及代码是否符合本来的意图；第三层是软件供应链检查，看项目依赖的第三方代码包里有没有已知漏洞或恶意代码。每一层专门抓一类问题。 【从“亮灯工厂”到“熄灯工厂”，自主权要一步步挣】 对谈的标题里有个说法叫“软件工厂”，来自 Addy 今年写的一篇文章，他的定义是“把循环规模化”：让 AI 一遍又一遍地规划、编写、检查、上线代码。他把软件工厂分成两种。亮灯工厂里，AI 承担这些步骤，但人还在里面，用自己的判断和品味把关。熄灯工厂更像全自动的汽车厂，机器人一直在干活，人退到更上游，只负责定方向，只有遇到最特殊的例外情况才被叫进来。 他说大多数团队处在两者之间，都在摸索怎么在信得过的前提下一步步提高自动化程度。AI 能给出的验证越多、越让人有信心，就越能往熄灯的方向走。Sonar 的调查显示，目前只有 5% 的公司在用软件工厂，预计会涨到 34%，金融行业是 39%。被问到 2027 年底大多数团队会是哪种工厂，Addy 的判断是：亮灯工厂为主，带着一些熄灯的角落。 自动化程度高了，管控就成了企业的难题。Addy 说，几个月前他接触过的很多公司都在担心同一件事：放手让工程团队用 AI 智能体，结果冒出了几百甚至几千个智能体，谁也不知道它们在干什么，它们访问各种系统和数据，可能还在往生产环境部署。他总结企业最关心三件事：怎么控制、怎么分配权限、怎么用沙箱（隔离的运行环境）保证智能体不越界。 AI 写的代码要不要在 PR 里标出来？Addy 认为应该。过去工程师对自己写的代码有很强的归属感，在 Anthropic 大家没那么在意 Claude 被署名为作者，更看重给用户交付的东西对不对。标出来还有一个用处：知道是 AI 写的，就能决定要加哪些额外的约束和检查。Manish 也同意，他认为至少未来半年到九个月里应该标注，对金融客户来说还关系到审计。两人都强调责任归属不变。Addy 说，就算这次是我让 Claude 去干的活，出了问题还是我负责，还得我去修。 那 AI 开的 PR 什么时候能放心合并？Addy 的回答是：你有充分的信心不会出问题，或者已经尽可能把风险降下来的时候。 快问快答里，Addy 还给了两条建议。对技术负责人，要推着团队想清楚“验证”具体指什么，现在的测试做到了哪一步，离“AI 自己判断代码可以合并、你也放心”还差什么。对刚入行的开发者，多积累各种测试的经验，端到端测试、属性测试都要会。 【不逐行看代码，和不验证是两回事】 Anthropic 一天三万次合并，人显然也没有逐行看，但按 Addy 的说法，每次合并之前 AI 都得先把功能实际跑一遍，再把证据交给人看。省掉的是读代码的时间，验证一步都没少。 他们能这样做是有前提的。 一是模型，Addy 自己提到 Opus 5.5 这一代已经够好，我也是用上 Fable 和 Opus 5.5 之后才放心不怎么 Review。 二是验证的基础设施：端到端测试、自动录屏、每次改动都触发的检查，这些都得先搭好。 为了扛住这个量，据 Anthropic 10 月发的工程博客，他们连 Git 都换成了自己开发的版本管理系统。这样的投入，大多数团队一时做不到。 所以我的建议是，想少看代码，别先急着把 Review 关掉，先补上 Addy 说的那一步：让 AI 交活的时候附上证据。如果不知道从哪里下手的话，可以从最容易出问题的界面开始，要求它在浏览器里实际操作一遍，给你截图或录屏。证据还是要你自己看，只是看录屏比读几百行代码快得多。 另外，Manish 讲的三层验证框架可以参考，不过 Sonar 本身就是卖代码检查工具的，听这部分时心里有个数就行。 视频来源：