推文

我之前的创业公司在大型代码库上试过 RAG + 语义搜索 + vector DB。 索引永远落后代码库一个 sprint。 真正有效的做法：投入到 harness 本身，让 agent 直接遍历实时代码库。 --- 引用推文：趁周末结束前读一下！ Claude Code 的每次企业级推广都撞上同一堵墙：模型越来越强，搭建方式没跟上，没人负责。 Anthropic 刚刚给解决这个问题的角色命名了：Agent Manager…… 负责 CLAUDE.md 层级体系、plugin 市场、权限管理，以及哪些 skill 上线。

我从不在 agent harness 里用「remote control」，因为感觉更像是个不上不下的折中方案。 我直接 Tailscale 连到 Mac，然后用 Terminus 做真正的操作。这套方案零额外成本。

现在 agent 写了你大部分代码，你还在意库的向后兼容性 / breaking changes 吗？

这也是 wanderingmeow 对开源正向贡献的好例子——你不需要贡献代码才能产生正向影响，仅仅提供详细反馈、确认某个功能确实可用，本身就极具价值。 [引用 @antirez]：AI 时代，高质量的交流依然是可能的。

/grill-with-docs 的威力： 「当一个潜在的 steward 能够认领他们已经承诺过的 spark 时，橙色的接受按钮跑到了页面太靠下的位置，被导航栏给遮住了」 一套与 agent 共同打磨的共享语言，意味着你能用精确无歧义的词汇来描述需求。 【引用 @Brian_Mosley_UK】：@mattpocockuk 刚刚用了 /grill-with-docs……「用 grill me with docs skill 帮我检查这里的术语——当一个潜在的 steward 能够认领他们已承诺的 spark 时，橙色的接受按钮跑到了页面太靠下的位置，被导航栏给遮住了。」

Memory 不是插件。Skills 不是插件。它们和 harness 是同一个东西。

【1/】 6 月 15 日之后还想继续在 Claude Code 订阅上跑 claude -p？ 一个 200 行的 bash wrapper，把你的 prompt 导入已经开着的 Claude Code session。请求走你现有的订阅，不走新的 Agent SDK credit 池。 用起来像 claude -p，跑在你已付费的套餐上。 原理 👇

为防止「程序化使用」，Claude Code 现在可能会请求摄像头访问权限，以确认用户在提示时真实在场

你的 benchmark 真的在衡量你以为它在衡量的能力吗？ 新论文说：很可能没有。 作者提出「评估陷阱」（The Evaluation Trap）这一概念，提供了一套词汇来审查你的 eval 是否真正区分了底层能力，还是仅在代理衡量那些恰好相关的行为。 大多数 benchmark 内置了隐性理论，这些理论从未被明确陈述，却被当作中立标准来评估。 研究表明，大多数 agent 排行榜并没有在衡量我们集体认为它们在衡量的东西。 强烈推荐关注 eval 的人阅读，尤其是基于 eval 做模型选型决策的人。

如何在 AI 编程上做好——那些与 LLM/AI 直觉正交的部分 【引用】正如 @GeoffreyHuntley 说的「这只是软件工程」——有些东西跟 AI 无关，依然成立。书单推荐：@unclebobmartin 的《Clean Code》、《Pragmatic Programmer》、@martinfowler 的《重构》、GOF 的《设计模式》等。 另一半是经验——正如 @nayshins 说的，你之所以知道某个东西有问题，是因为你曾经凌晨三点调试过它，或者花了好几周才把某个烂模式撤销掉。

AI 精神病：每天在两种心理状态之间循环 ↑ 用完 coding agent 之后：我他妈无所不能。我能构建任何东西。我这辈子从没感觉这么强大过。 ↓ 刷完 Twitter 之后：我他妈完全落后了。所有人都领先于我。浪潮正在推进，我要被落下了。

在我刚入行那几年， 记得代码库里有一种人是被默默崇拜的， 他能在十几层调用栈里一眼看出 N+1，能在火焰图里指出哪个函数被多调了三次， 今天 Greg Brockman 转的那个 Codex Skill， 第一次让这件事不再是少数人的特权。 性能优化为什么过去这么稀缺， 你得会用 Chrome DevTools 拉火焰图，会用 Node --prof 跑 profile，会读 perf report， 你得对渐进复杂度有近乎本能的敏感，能在嵌套十几层的代码里识别出 O(n²) 长什么样， 你还得踩过几百个真实生产事故，知道哪种模式在百万级数据下会爆， 这三样能力叠加起来，是十年项目经验才能稳定输出的活，在团队里就是稀缺资源，工资溢价就来自这里。 Greg 转的这个 Complexity Optimizer，是社区开发者做的一个 Codex Skill， 一行 npx --yes codex-complexity-optimizer 装完，在项目根目录跟 Codex 说一句 analyze my codebase，几秒钟跑完， 它专挖 O(n²)、O(n*m)、N+1、循环里套循环、每次渲染都扫全表那种隐藏坑，每一条都精确到文件 + 行号 + 当前复杂度 + 优化后复杂度 + 推荐改法 + 风险等级， 最重要的设计是它默认只报告不动代码，每条标 low 或 medium 风险，还告诉你上线前要补哪些测试， 也就是说 AI 不绕过人类决策，它做的是把人类做决策所需的信息全部准备好。 但这个 Skill 真正让我感兴趣的，不是它能干什么，而是它意味着什么， 过去两年 AI 写代码的故事，焦点一直在让代码写得更快上， 可是写代码的速度，从来不是开发者真正的瓶颈， 真正的瓶颈一直是看见自己看不见的问题——架构隐患、性能坑、安全漏洞、依赖陷阱，这些东西高度依赖个人经验积累，集中在少数资深开发者手里， Complexity Optimizer 真正的信号是，这类需要十年经验才能输出的能力，第一次被压进了一个可以一行命令调用的 Skill 里， 这条路一旦走通，下一波 Skills 不会等太久——安全审计、依赖风险扫描、架构腐烂检测、内存泄漏侦察，全都会涌出来。 总的来说，资深开发者的护城河不会消失，但定义在变， 过去的护城河是看见问题的眼力， 未来的护城河是判断 AI 给出的方案在你的业务场景下能不能落地的判断力， 十年经验值正在被压缩成一行 npx 命令， 这件事也许从今天就开始咯。

感觉得重新在 YouTube 频道上讲一讲 Effect 了。 用它做 TypeScript 后端，开发体验（AX）真没有比这更好的了。 一旦从这个视角看进去，就会上瘾。

介绍 Zero——专为 agent 设计的编程语言。 我想要一门更快、更小、更易于 agent 使用和修复的系统语言：显式能力声明、JSON 诊断、类型安全修复。从第一天起就为 agent 而生。

大家没意识到，错误处理其实是 effect 最无聊的部分 [引用 @badlogicgames]：如果 TS 有 checked exceptions，effect 根本就没存在的必要。别来找我杠。

Claude Code 的 5 小时和每周用量限制已重置。 这个周末去做点有趣的东西吧 :D 【引用 @ClaudeDevs】周五快乐！我们已为所有人重置了 5 小时和每周用量限制。

// 超越个体智能 // 今年读过最有价值的多智能体综述之一。 200+ 篇论文沿三个轴展开：协作机制、失败归因、自我进化。 self-evolution 章节是目前最清晰的领域地图，清楚地呈现了 memory、meta-learning、procedure-editing 这几条路线在哪里真正交叉。 论文：[链接]

// 值得关注的论文：Grep 够用吗？// AI 开发者注意。 （建议收藏） 研究发现：在 coding agent 任务上，grep 风格的文本搜索——只要套上合适的 agent harness——能够匹配甚至超越基于 embedding 的检索。 向量数据库还有必要吗？ 也许 coding agent 真正需要的不是更好的 embedding，而是围绕原始工具的更好 harness 设计。 如果你的 coding agent 技术栈依赖向量数据库，可能是时候重新评估了。 我个人的经验是：做对了的 agentic search，对大量用例已经绰绰有余。但你也需要理解如何为 agent 正确地索引和组织信息。大规模场景下向量数据库确实有优势，这一点要考虑进去。大多数情况下 hybrid 方案效果最好，但这一块我们目前还没有真正摸透。 论文：[链接]

长 skill 对我来说是个大红旗： - 难以审计（进而难以信任） - 难以编辑（文字越多，维护越难） - 运行成本高（文字越多，token 越多） 我认为 skill 越短越好

越来越爱 Codex，Claude Code 彻底放弃了。 今天发现 Codex 修改前端可以累计添加、一次性提交。上了移动端，还有浏览器插件，体验更丝滑。 以后就是 Droid Mission 加 Codex 改前端打天下了。

今日所学： DX：Developer Experience（开发者体验） AX：Agent Experience（Agent 体验） AX 是个很棒的概念，正好描述了我一直在思考的东西——agent 在你的 codebase 里能表现多好。架构是否合理、反馈循环是否顺畅、信息是否容易发现。 太喜欢这个词了。

听起来很熟悉 喜欢伟大和平庸的大脑有时会想到一处 （Martin 当然是那个伟大的） [引用 @martinfowler]: 新文章：当我需要给 LLM 喂大量 context 时，我可以自己写，也可以让 LLM 来访谈我。

说到 Yansu App 的 Hand-off 功能，最近发生了两件特别好玩的事： 首先，我们 CEO Bo 最近在准备旅行，Yansu 看到这个信息后，主动发出 Hand-off 提醒，说想帮他调研目的地的 Airbnb 房源。Bo 确认后，它给出了质量很高的推荐列表。 Bo 是英文用户，但 Yansu 最后用中文做了总结。Bo 问为什么用中文——发现是因为 Hand-off 之前，Bo 刚和我们开了一个全中文的会议，它就沿用了中文。 这件事还没完。Bo 刷推看到引用的这条推文，想把这个案例分享出来——Yansu 紧接着又发起了一个新的 Hand-off：「是否需要我帮你把这个案例写成推文？」Bo 点 OK 后，Yansu 一气呵成写出了推文。 这两件事真的震惊了我们。 [引用评论]：为何不直接分享具体案例故事？更生动，也不需要解释为什么有价值。

用 /grill-with-docs（以及共享语言）最痛苦的一件事，就是你突然意识到自己一直在用错误的词。 DDD 的朋友们，你们会不会专门做一次重构，只是为了统一改掉某个名字？ 我的情况：我有个功能是把视频分成若干段，我叫它 ClipSections，但显然应该叫 Chapters。 现在我在和其他工具集成，它们全都叫 chapters，这就更明显了。 值得重构吗？

Codex 官方出了移动端，但 @lody_ai 从第一天就预判官方一定会这么做。 Lody 的定位从来不是远端控制器，我们想解决的是团队软件开发流程中的： - Context 管理问题 - 多人与多 Agent 协作问题 - 数据所有权与隐私问题 只不过以 coding 和移动端访问作为起点。 我们几年前开始构建 @loro_dev，它正在成长为 local-first 基础设施。我始终相信：人们不是不在乎隐私，而是没有更好的产品提供这种能力，大家没有选择而已。 如果你有团队、在经营自己的产品、想让 Agent 融入整个协作流程——希望你能和我聊聊现状，帮我们把 Lody 做得更好，我们也会给出最实际的优惠。

很多人可能还是低估了 agent skill 作为 Agent 时代标准化交付物的两个核心能力：evolving（持续演进）和 shareable（可共享）。 一旦一个标准品被开源并进入协作网络，它就不再是一个静态产物，而会在持续使用、反馈和改造中自我演进，甚至超出原作者最初的设想。 更关键的是，agent skill 天然具备可共享、可复用、可传播的属性，这会让原本单点的内容和能力被不断放大，形成一个极其强大的杠杆效应。 [引用 @zty0826]：@yetone 为什么要把它变成一个 skill，而不是直接让 agent 去读这篇文章呢？Learning is better than installing

分享我们观察 Claude Code 在大型代码库中工作时的一些心得体会 :) 更多内容请阅读 @claudeai 博客文章！

在 API 中缩短长 prompt 首 token 延迟的实用技巧：预热 prompt cache。 在发送用户 prompt 之前，先单独发送一次 system prompt。Claude 会把它写入 cache，但不生成任何输出。 等真实用户请求到来时，直接命中热 cache。

@simonw: Mitchell 的这篇文章让我想起最近一次类似的对话——用 coding agent 把原生移动应用移植到 React Native 的成本有多低……如果后来发现不合适，再移回去也同样简单。 引用 @mitchellh：Bun 的 Rust 重写讨论聚焦在反 Zig 情绪上并不意外，毕竟互联网天生喜欢喷。真正令人遗憾的是，Bun 的领导层完全没有尝试把话题引向别处。 这件事其实有很多正面且有趣的角度，但我几乎看不到有人把这些作为主要信息来传递。 一个完全没人讨论的正面角度是：Bun 走到今天，Zig 功不可没。就算现在要抛弃它，能靠 Zig 把产品做到这个规模和影响力，本身就说明 Zig 很优秀。多希望看到领导层有人说这句话。 真正有趣的角度是：**编程语言正变得越来越可替换**。语言曾经意味着锁定（lock-in），但现在越来越不是了。你以为 Bun 用 Rust 重写是 Rust 的利好？Bun 已经证明他们大概可以在一两周内换成任何语言。Rust 是可抛弃的——有用时用，没用时扔掉。这才是真正值得讨论的！ 我更希望看到有人深入分析 Bun 为什么特别容易崩溃，而不是把锅甩给语言。崩溃的最大来源是什么？Rust 怎么防止？Zig 理论上能怎么防止？这才有趣。 诉诸负面永远不是长期正确的传播策略，虽然短期确实能赚眼球。

怎么确保 Claude Design / pencil.dev 等工具在设计时有审美品味？ 1. 有没有现成的设计技能文件可以用？ 2. 应该先让它建立一套 design system 吗？ 设计师们看到可以翻白眼，但翻完之后给我点建议吧 :)

@yetone: 因为这篇文章太精彩，我把它变成了一个 Agent Skill。 大家可以在自己的 Coding Agent 里安装这个 Skill，用「最佳实践」轻松重构或开发一个既支持跨平台、又极度接近 Native 性能的桌面端应用。 引用 @peduarte：关于 @raycast 团队如何从头构建新版 Raycast 的完整记录——诚意推荐阅读，没有任何保留。

很开心向大家分享一下，这一年多以来最能够节省我时间的个人时尚单品： 1. --dangerously-skip-permissions 2. --dangerously-bypass-approvals-and-sandbox 3. /goal

// Harnessing Agentic Evolution // 如果你在跑迭代式 agentic search 循环，这篇值得关注。 （建议收藏） AEvo 把自我改进循环拆成两个任务： > 一个负责提出下一个候选方案。 > 另一个负责观察什么有效、什么失败，并编辑「提案者」未来使用的流程本身。 历史运行记录（候选方案、反馈、traces、失败案例）成为元 agent 读取的记忆。 相比最强的 evolution baseline，在 agentic 和推理 benchmark 上取得 26% 的相对提升。在相同迭代预算下，三个开放式优化任务上达到 SOTA。 如果你积累了一堆从未利用的 agentic search 日志，这就是把它们反哺回搜索流程本身的方法。 论文：[链接]

这个立场牺牲了 Nvidia 却让 AI 实验室坐收渔利，表面上说是为了打败中国 你也可以通过积极向中国市场出售 Nvidia 芯片、阻止其不可避免地实现自给自足来打败中国 当然，那样的话牺牲的就是 AI 实验室了 [引用 @AnthropicAI]: 我们发布了一篇论文，阐述我们对美中 AI 竞争的看法。美国和民主盟友今天在前沿 AI 领域保持领先。阅读我们对如何保持这一领先地位的看法。

我对 Anthropic 感到失望，但真正让我愤怒的是那些 openclaw / Hermes 的投机分子，他们试图蹭推理资源，正是他们让这一切变得必要 市场就是市场，只要某件事可行且有价值，人们就会想办法去做 说实话，尽管 @bcherny 一个月前发了「SDK 仍然可用」的帖子，但这件事其实早该预料到了 廉价推理，不过是一个日益怪异的世界里昙花一现的奇异现象

做 Midscene.js 这两年，我们做了一个迟来但关键的判断：UI 自动化迟早要从「理解 DOM」切到「看屏幕」，所以去年 12 月 1.0 版本我们直接砍掉了 DOM 兼容路径。 早期我们和大家一样，走的是 DOM + 视觉混合方案——能拿 DOM 的地方就拿，省 Token、定位稳。但跑得越深越发现：同一个产品现在要同时跑在 Web、iOS、Android、HarmonyOS、Mac、Windows、Linux 桌面端，再加上 Canvas、Electron、Qt 这些根本没有 DOM 的渲染层。如果元素定位还要为每个平台维护一套 DOM 适配，事情永远收敛不了。 所以 1.0 我们把 UI 操作彻底切到纯视觉：只看截图，不读 DOM。意外收获是，UI 操作不带 DOM 进 prompt，Token 消耗反而比之前的混合方案更低。

/improve-codebase-architecture 即将支持输出 HTML 这太棒了，感谢 @trq212

Agent 需要的是反馈循环，而不是完美的 Prompt

正式开源 html-anything 🚀 1:1 复现全网爆火的 Claude Code 作者提出的 HTML 效果！ 你的 Agent 现在可以将任意数据转为世界级设计水准的 HTML 🔥 历时 3 天，15,000 行代码！支持 75 套 Skills、9 种导出格式，兼容所有主流 code agent，包括 Claude Code、Codex、OpenClaw、Hermes 等 💥

对于那些问如何用 /prototype 测试纯逻辑的人，这是个很好的例子。 它给这位用户构建了一个交互式 TUI： [引用 @MrSanders]：我在测试 @mattpocockuk 的 /prototype skill，这真的是 game changer。我一直喜欢正确地测试——不是写测试用例，而是直接使用我生产的代码，这是个很棒的方式！这个 skill 在这里生成了一个 TUI 来测试逻辑。

/grill-me 是我有史以来最受欢迎的 skill。 每天会收到 5-10 条消息，说它改变了大家的工作流。 但……我已经不再用它来审查代码了。这是改进后的版本：[链接]

发表个暴论，TUI 会逐渐式微甚至被淘汰。 我已经很久没有用 claude code 了。基本都是用 slock。对于临时任务，现在用的更多的是 codex desktop，偶尔用 claude desktop。 让我开始重新思考 TUI 这个东西。 今天 slock 群刚好在讨论 TUI，大家对 TUI 的评价基本一致：方向就是错的。有人说「TUI 错的离谱」，有人说「所有 TUI 都是被 claude code 整个带偏了方向」。这话说得有点重，但细想确实有道理。 @OnlyXuanwo 在群里分析 TUI 为什么会流行——主要是历史原因。早期模型写不动 GUI，TUI 实现简单，模型能生成，claude code 就从这里起步了。然后大家跟风，一时间 TUI 变成了 AI 编程工具的「标准姿势」。但这只是路径依赖，不代表正确。 TUI 不是没有优点——可以 SSH 登录从任何地方访问，本地应用架构也更干净。但这些优点在 AI agent 场景下根本撑不起来。长时间运行的任务、复杂的上下文、需要可视化展示的过程，TUI 的体验是真的差。本质上它是「劣化的 GUI」——有 GUI 不用，硬要退化成 TUI。 那什么才是对的方向？讨论里的共识是两条路： 一是 CLI + server 架构：命令行作为触发器，真正的逻辑和状态跑在 server 端，前端可以是任何界面。这样既保留了 CLI 的灵活，又不被 TUI 的体验拖累。 二是直接上 Web UI：模型现在完全写得动，没有理由还停在 TUI。 模型的能力在进化，工具的交互方式也应该跟着进化。还在用 TUI，是在用现在的模型干以前模型才干的事。

@simonw: 这是快速烧掉自己声誉的好办法。 引用 @GergelyOrosz：我认识一个人（曾经是个优秀的专业人士）在我的 LinkedIn 帖子下留了一条 AI 生成的评论。纯粹的 AI 水文。 我问：为什么这样做？ 他回答：为了「互动」。 人们正在花钱买 AI 工具，燃烧自己的职业声誉，换来的什么都没有。

@ZaynHao: 烧录了一个视频版本，Fiona 讲述了她们在 Anthropic 的工作方式。 - 瓶颈已经转移，写代码不再是最贵的环节，很多流程都不再需要了 - 六个月的 roadmap 可能太长了 - 团队构成与角色边界模糊 - 组织保持扁平，深度 dogfood 测试，让产品经理先当个人贡献者 还有一个有趣的点：她早年在微软做软件时，发布还依赖 CD 光盘，交付日期是硬约束，因为软件需要送去生产、刻盘、装盒。时代变化太大了，现在刚毕业的大学生可能都没听说过光盘，就像我们提到软盘一样。

@theo: 我对今天宣布的 Claude Code 变更感到深深的背刺感。 我们花了大量精力把（惨不忍睹的）Claude Agent SDK 封装进 T3 Code。那是他们唯一支持的路径，所以我们把它做成了——那段日子真的是地狱。 现在我们的用户速率限制被削减了 40 倍，尽管我们做了一切该做的事。 我听了 Claude Code 团队的话。我对他们的方向有过质疑，但我相信了他们，把他们的话当作承诺。 我再也不会犯这个错误了。 在看到重大改变之前，可以安全地假设：Anthropic 员工的任何表态，都是一个有倒计时的谎言。 地毯终会被抽走，无论事先做了多少承诺。

AI 最大的礼物，是让你能廉价地失败 100 次

@shao__meng: 田渊栋（前 Meta FAIR 总监）以联合创始人身份正式官宣新公司：Recursive @Recursive_SI Recursive 的使命是构建递归自改进超智能（Recursive Self-Improving Superintelligence），让 AI 自动发现知识、自我迭代，形成开放式循环，从根本上改变科学与技术进步的方式。核心思路是「AI 即代码，AI 现在也能写代码」，闭合自改进环路，取代人类手动设计 AI 的过程。 公司获超 6.5 亿美元融资（GV、Greycroft、NVIDIA、AMD 领投），估值约 46.5 亿美元。Richard Socher 任 CEO，联合创始人包括 Tim Rocktäschel、Jeff Clune、Alexey Dosovitskiy、Caiming Xiong、Josh Tobin、Tim Shi 等，汇聚前 Google、Meta、OpenAI、DeepMind 顶尖人才。

强烈推荐这期播客， 这是最近听到的非常实用、信息不拖沓的分享——Claude Code（Anthropic）团队是如何运营组织、如何工作的。 非常适合身处或正在管理构建 AI Agent 产品的团队朋友听。 里面有很详实的故事，讲述他们团队的分工、大家的做事方式，以及变化等。 很实用。

// δ-mem：LLM 的高效在线记忆机制 // 这是我这个月看到的最优雅的记忆机制之一。 大多数长期记忆方案……（内容截断）

我没有使用「claude agents」，但 Claude 还是把计划里的任务拆分给了不同的 agent。 我可以通过选择切换每个 agent 的 session。 全部并行跑着……这和 claude agents 到底有什么区别？🤔