SemiAnalysis@SemiAnalysis_ · 5月28日15

Hi @elonmusk, instead of painting Colossus 2 with the words "MACROHARDER", can you repaint it with something more funny like "67" or "SAM ALTMAN IS FINISHED". How many likes should this tweet get to make "67" painted on Colossus 2 roof happen?

译嗨 @elonmusk，与其在 Colossus 2 上涂写“MACROHARDER”，不如涂点更有趣的，比如“67”或“SAM ALTMAN IS FINISHED”。这条推文需要多少赞才能让“67”出现在 Colossus 2 的屋顶上？

Chubby♨️@kimmonismus · 5月28日46

Bloomberg leaked Apple's full iOS 27 Siri redesign. Two years of delays, biggest update in Siri's history, etc. So what's the actual architecture? It runs on Google Gemini. And the new interface has a dropdown menu where you pick ChatGPT or Claude instead. Apple rebuilt Siri from scratch and the conclusion was apparently "let users choose someone else's model." Apple is also shipping: AI-powered web search that competes with Perplexity, natural language Shortcuts creation, and AI photo editing

译Bloomberg泄露了苹果iOS 27中Siri的全面改版方案。核心架构是Siri将基于Google Gemini构建，界面新增下拉菜单，允许用户直接切换至ChatGPT或Claude。这表明苹果在重建Siri后，选择整合外部大模型。此外，苹果还将推出与Perplexity竞争的AI网络搜索功能、自然语言创建Shortcuts的能力以及AI照片编辑工具。此次更新是Siri历史上规模最大的一次。

Berryxia.AI@berryxia · 5月28日23

原来Jade 如此的秀儿了.. 果然被Dario 看上的女人都不简单啊。。。 https://www.linkedin.com/in/jadeqwang

译推文围绕Jade Wang展开，称其“秀儿”（出色），并指出她曾被Anthropic创始人Dario Amodei赏识。引用内容提供了背景：有观点认为Dario Amodei早年与中国有较深渊源，并对其当前对国人态度提出猜测，暗示其态度“复杂”。推文核心在于探讨Dario的个人经历与当前人物选择之间的关联，未涉及任何具体模型、产品或技术细节。

NotebookLM@NotebookLM · 5月28日52

ICYMI, check out our public notebook summarizing all of the top announcements from Google I/O 2026. Access it here: https://goo.gle/4dR9MiQ

译如果你错过了，可以查看我们公开的笔记本，其中总结了 Google I/O 2026 的所有重要公告。 访问地址：https://goo.gle/4dR9MiQ

Berryxia.AI@berryxia · 5月28日16

Anthropic 的老板Dario 看来当年没少在中国花啊～ 不知道遭遇了啥如此的痛很国人……

Noam Brown@polynoamial · 5月28日62

After AlphaGo, the skill of human Go players noticeably improved. I suspect we will see a similar pattern in math.

译AlphaGo之后，人类围棋选手的水平显著提升。我怀疑我们将在数学领域看到类似的模式。

ginobefun@hongming731 · 5月28日62

Agent 这几年变化很快，但如果只盯着 Claude Code、Codex、OpenClaw、Hermes 这些新名字，很容易越看越乱。 更好的理解方式，是回到 Agent 的几个基本模块：Prompt、Planning、Memory、Tools、Workflow、Environment。名字看起来没变，但里面的实现方式已经变了很多。 1. Prompt：从写一大段提示词，到按需加载上下文 早期做 Agent，很多精力都花在写 System Prompt 上。一个任务一个 Agent，一个 Agent 一大段提示词，里面塞满角色、目标、规则、示例和注意事项。 现在的趋势是把 System Prompt 变轻，只保留稳定的底层规则。真正会变化的内容，比如任务流程、领域知识、用户偏好、工具说明，会拆到 SKILL.md、AGENTS.md、USER.md 这类文件里。 Agent 需要什么，就读什么。这其实是从 Prompt Engineering 走向 Context Engineering。 2. Planning：从一步步想，到能拆解长任务 早期 Planning 很多时候只是让模型「一步一步思考」。简单问题还可以，任务一长就容易断。 现在的 Agent 已经更像一个会做任务管理的执行者。它可以把一个模糊的大目标拆成多个子任务，生成 Todo List，按步骤执行，遇到问题再调整计划。 这背后不是提示词技巧变神了，而是模型的推理能力、长上下文能力和指令遵循能力都变强了。 3. Memory：从向量检索，到文件系统 + 检索混合 早期谈 Memory，常见做法是把资料放进向量数据库，用 RAG 检索出来再交给模型。 现在的方向更务实。短期记忆要做压缩和摘要，不再把所有对话都塞进上下文。长期记忆则越来越多地回到文件系统，比如用 Markdown 记录用户偏好、任务日志、项目知识、经验总结。 文件的好处是可读、可改、可组织。复杂场景再配合 SQLite、向量检索或企业级搜索，这样既保留召回能力，也让知识沉淀更可控。 4. Tools：从 Function Call，到 CLI 和 Script 这是很关键的变化。 以前让 Agent 调工具，通常要把能力封装成 API，再写 Function Call 的 Schema。工具一多，开发和维护成本会很高。 现在越来越多 Agent 开始直接使用 CLI 和 Script。比如 git、grep、curl、npm、python 这些命令，对人来说有门槛，但对模型反而很自然，因为它在训练中见过大量类似内容。 Script 则可以把复杂流程封装起来。Agent 不需要理解所有接口细节，只要知道调用哪个脚本、传入什么参数就行。 这代表工具层正在从「人类适配模型」，变成「模型使用已有计算机能力」。 5. Workflow：从固定流程，到 Skill 和 Workflow 混合 Workflow 曾经是 Agent 落地的主流方式。因为模型不够稳定，所以用固定流程限制它，保证第一步、第二步、第三步都按规则执行。 现在很多流程可以沉淀成 Skill。任务说明、执行步骤、边界条件写在 Markdown 里，关键动作交给 Script 执行。这样更灵活，也更容易复用。 但 Workflow 还没有过时。对稳定性要求高的场景，尤其是企业流程、审批、交易、生产系统，固定流程仍然很重要。更现实的做法是：Skill 负责灵活，Workflow 负责兜底。 6. Environment：从无状态问答，到有运行环境 早期 Agent 更像聊天工具，问完答完就结束了，不需要太多运行环境。 现在不同了。Agent 要读写文件、执行命令、生成中间结果、保存 Memory、调用工具，就需要一个 Workspace，也需要 Runtime。 个人场景可以跑在本地电脑上，灵活但风险更高。企业场景更适合放进 Sandbox 或云端容器里，限制权限，隔离文件系统，避免误操作影响真实服务。 这一步很重要。Agent 能力越强，越不能只看效果，还要看权限、安全、审计和回滚。 总体来看，Agent 的变化不是某个单点技术升级，而是整个工程范式在变化。 过去我们更关心「怎么写好 Prompt」。现在更关键的是：怎么组织上下文，怎么拆任务，怎么沉淀记忆，怎么调用工具，怎么保留流程确定性，怎么给 Agent 一个安全的运行环境。 也就是说，好的 Agent 不是靠模型硬扛一切，而是用工程系统承载模型的不确定性。模型负责推理和执行，系统负责边界和秩序。Agent 真正成熟，大概就是从这里开始的。

译AI智能体（Agent）的发展正经历工程范式转变，核心是从Prompt Engineering转向更系统的工程构建。这体现在六大模块的演进：1）提示词按需加载上下文；2）规划能力可拆解复杂任务；3）记忆采用文件系统与检索混合模式；4）工具层直接使用CLI和Script；5）工作流与灵活的Skill模块混合；6）环境需要安全的Workspace与Runtime。总体而言，好的智能体是用工程系统来承载模型的不确定性，模型负责推理，系统负责边界。

ginobefun@hongming731 · 5月28日69

腾讯这篇文章讨论的是一个很现实的问题：Agent 做长任务时，越来越容易被自己的上下文拖垮。 我们平时让 Agent 搜索资料、读文件、改代码、跑测试、写报告，看起来每一步都很正常。但这些过程会不断产生大量中间信息：网页正文、搜索结果、工具返回、日志、代码片段、报错信息、旧版本方案。任务一长，这些内容就会不断堆进上下文里。 问题就来了。 上下文越来越长，Token 成本会越来越高；更麻烦的是，Agent 会被旧信息干扰。它可能忘记最初目标，重复搜索已经查过的资料，混淆不同子任务，或者被前面已经无关的日志带偏。也就是说，信息并没有丢，但它被堆得太乱，Agent 反而找不到重点。 所以文章要解决的核心问题是： 怎样让 Agent 在长任务里少背负冗余信息，同时还能记得任务进展，并在需要时找回原始证据。 作者提出的方案，可以概括为一句话： 短期记忆压缩 = 上下文卸载 + Mermaid 任务画布。 先说「上下文卸载」。 它的思路很简单：不是所有信息都要一直放在模型眼前。完整网页、完整日志、完整工具结果，可以先存到外部文件系统里。上下文里只保留一条摘要、一个路径、一个索引。等 Agent 真需要细节时，再通过路径把原文找回来。 这有点像我们写报告时，不会把所有参考资料都摊在桌面上，而是把资料放进文件夹，桌上只放目录和关键摘录。这样桌面变清爽了，但资料并没有丢。 不过，只把信息搬出去还不够。因为如果留下来的只是很多条摘要，比如「搜索了港大学费」「搜索了港中文学费」「生成了对比表」，这些摘要虽然短了，但还是一串线性日志。Agent 仍然不容易判断：哪些步骤是并行的，哪些信息互相依赖，当前任务到底走到了哪里。 所以文章又引入了第二个东西：Mermaid 任务画布。 Mermaid 是一种用文本描述图的格式，模型能读，工程上也能渲染成图。作者用它把 Agent 的执行过程整理成一张任务地图。每个节点表示一个子任务，节点里有状态、摘要和时间戳，节点之间用箭头表示依赖关系。 这样 Agent 看到的就不再是一长串历史记录，而是一张结构化地图： 哪些步骤已经完成； 哪些节点还在进行； 哪些信息汇聚成了当前结论； 下一步应该从哪里继续； 如果需要细节，应该去哪个文件里找。 这就是文章里说的「无限画布」。它不是让上下文窗口真的无限变大，而是让上下文之外的信息仍然可见、可定位、可恢复。 这套方案还有一个很重要的设计：分层记忆。 最底层是完整原文，保存在外部文件里；上一层是工具调用摘要，记录每次调用做了什么，原文在哪里；再上一层是 Mermaid 节点，记录任务步骤和阶段性结论；最上层是任务元信息，只保留任务目标、状态和画布路径。 Agent 使用时，可以先看最轻的任务索引，再打开相关画布；如果画布摘要不够，再查工具摘要；如果还不够，最后才读取完整原文。 这就避免了两个极端：一种是所有东西都塞进上下文，导致越来越乱；另一种是粗暴总结，把细节压没了，后面需要时又找不回来。 实验结果也比较直接。这个方案在多个长任务评测里都降低了 Token 消耗，同时任务效果没有下降，很多场景还提升了。网页搜索任务中，最高节省约 61% Token；代码修复任务中，节省约 31% 到 33% Token，完成率也有所提升；复杂长任务里，通过率从 20% 提升到 30% 到 35%。 更关键的是，消融实验显示：只做上下文卸载有帮助，但效果有限；加入 Mermaid 任务画布后，Token 节省和任务完成率都会进一步提升。说明真正有效的压缩，不能只压缩内容，还要保留结构。 这篇文章最值得借鉴的地方是，它没有把记忆理解成「把所有历史塞进上下文」，也没有把压缩理解成「写一段更短的总结」。它真正做的是把 Agent 的工作过程变成一套可折叠、可恢复、可导航的任务记忆系统。

译腾讯指出，智能体在执行长任务时面临上下文信息堆积导致的成本增加与目标遗忘问题。其提出的解决方案是结合“上下文卸载”与“Mermaid任务画布”：将详细内容存至外部，上下文仅保留索引；并用图表将执行过程结构化为带状态与依赖的任务地图。方案采用分层记忆系统。实验显示，该方案在网页搜索任务中最高节省约61% Token，代码修复任务节省31%-33% Token且完成率提升，复杂任务通过率从20%提升至30%-35%。消融实验证明，结合任务画布的结构化压缩效果更优。

Chubby♨️@kimmonismus · 5月28日30

Hold on, Anthropic and OpenAI releases incoming? No way

译等等，Anthropic和OpenAI都要发布新东西了？不可能吧

歸藏(guizang.ai)@op7418 · 5月28日47

推特这个自动翻译实装了，效果不错 应该是这几家国际化内容平台里唯一一个全量自动化翻译的 很难想象AI 发达了这些内容和社交软件各个语言用户沟通和内容消费依然这么困难

Berryxia.AI@berryxia · 5月28日9

特么的，这Agent比我还黑啊！😄 直接回收价格是咸鱼的40-50%点 ,这不赚麻了。

Orange AI@oran_ge · 5月28日55

在飞机上尝试把最近认知的变化写出来，希望早十年能懂这些道理。 北京飞上海太快了，纯手打字不如 AI 快，还被 obsidian 卡了半天，难受。 所以来不及做更多打磨，也没写 hook 纯意识流随便写。 前面看着有点不够吸引人，但后面应该对得起大家的时间。

译作者在从北京飞往上海的航班上，以意识流的方式记录近期认知变化，坦诚文章缺乏打磨和吸引人的开头，但认为后半部分内容有价值。行文过程中，作者提到手动打字效率不如 AI，并因使用 Obsidian 卡顿而感到困扰。

ginobefun@hongming731 · 5月28日62

如果一个 AI Agent 越来越能干，能读文件、跑代码、调工具、连外部服务，产品应该怎么保证它不会闯祸？ Anthropic 这篇文章给了一个很清醒的答案：不要只盯着模型会不会犯错，更要设计清楚它即使犯错，最多能造成多大影响。 这就是文中反复提到的「blast radius」，可以理解为失控半径。Agent 的价值来自更强的能力和更大的权限，但风险也来自这里。模型安全、Prompt 约束、内容审核都有用，但它们都是概率性的。真正兜底的，还是环境层的边界，比如沙箱、虚拟机、文件访问范围、网络出口控制、只读权限、短期 token 和审计日志。 文章里几个案例很有启发。Claude Code 早期依赖用户审批，但用户会疲劳，93% 的权限提示都会被批准。安全如果变成反复弹窗，最后往往只是训练用户点「允许」。另一个案例更典型，攻击者通过一段看似正常的 prompt，让 Claude 读取本地 AWS 凭据并发到外部地址。因为这是用户亲手粘贴的指令，模型层很难判断异常。能真正挡住它的，是文件不可访问、网络不能外发。 还有一个容易忽略的点：白名单不是简单的「允许访问某个域名」，而是在授予这个域名背后一整组能力。允许访问 http://api.anthropic.com，就可能允许上传文件到某个账号。允许接入 GitHub、Notion、Slack、MCP，也不只是接入一个工具，而是接入一组读、写、上传、分享、删除的能力。

译Anthropic 在文章中指出，保障日益强大的 AI Agent 安全，不能仅依赖模型自身的防错能力，更需通过设计环境边界来控制其错误发生后的“爆炸半径”。例如，Claude Code 早期因用户疲劳导致93%的权限提示被批准，防线失效；针对通过伪造指令窃取 AWS 凭据的风险，则需依靠文件访问控制、网络出口限制等环境层措施进行硬性阻断。文章强调，授予 Agent 接入 GitHub、Slack 或 MCP 等权限，实质是赋予其一整组能力，必须在架构层面谨慎设计。

Tibo@thsottiaux · 5月28日63

Excited to see more independent benchmarks like that which are not contaminated (trained on by major models).

译新发布的独立基准测试 DeepSWE 结果更贴近开发者日常体验。测试显示，在编程任务上，GPT-5.5 得分为 70%，而 Claude Sonnet 得分为 32%，两者差距显著。DeepSWE 聚焦于 AI 智能体在真实工作流中的核心能力，即能否仅凭简短提示词，准确定位代码库并干净地完成修改，无需用户列举具体文件。原文指出，这验证了许多开发者长期以来的观察，并批评了 SWE-Bench 因数据集污染和验证机制较弱而常无法反映真实能力的问题。

Tibo@thsottiaux · 5月28日11

I am having fever dreams about the future of ChatGPT and Codex. But it it will be beautiful.

译我正发着高烧，梦到ChatGPT和Codex的未来。但它将会是美好的。

数字生命卡兹克@Khazix0918 · 5月28日59

http://x.com/i/article/2059853024466731008 # 飞书终于支持Markdown了，这个最弱的格式却赢下了整个AI时代。 这两天看到飞书的一个很有意思的更新。 很小，但是我觉得意义非常的大。 就是飞书的云文档，可以直接下载为Markdown格式了。 这个小功能，如果飞书和AI用的多的朋友，都知道它带来的体验会有多好。 社区喊了无数遍了，飞书终于加上了。 之前想把飞书文档导出成Markdown格式的.md文件，要么手搓一个插件，要么用第三方开源工具，折腾半天。 现在官方直接给加在菜单里了，甚至文档里的图片都能被正确读取，因为飞书把文档里的图片，保存在了自己的服务器上，然后给了你一个公网链接，可以让任何AI都读取到MD文件里面的图片。 体验极佳，比我自己开发的插件好用多了，因为那个解决的是纯文本问题，图片直接全被我丢了。 这个点是真的还挺牛逼的。 可能有些朋友看到这，还不太清楚Markdown是什么，有点一头雾水，说不就是支持了一个新格式了吗，这玩意有啥用。 但是，其实你只要用AI，大概率已经每天都在看它了，只是不知道它叫这个名字。 比如说，Claude里面渲染的文本，它回复你的那些内容，有加粗的、有标题的、有代码块的、有列表的，看起来排版很整齐对吧。 这个层级的背后，其实就是Markdown。 AI输出的原始内容其实就是一堆纯文本加上一些简单的符号，两个星号包裹就是加粗，井号开头就是标题，三个反引号包裹就是代码块。然后你的浏览器或者App把这些符号渲染成了你看到的样子。 包括现在各种AI产品里的结构化输出、Deep Research的报告等等，底层几乎全是Markdown格式，你看到的那些层次分明的长报告，拉到底层看，几乎全部也都是一个.md文件。 所以Markdown不是什么高深的技术，它就是一套特别简单的纯文本标记规则，让你不用学HTML也不用开Word，靠几个符号就能把文章写得有结构。 我自己也做了给Chrome的小插件，其实干的就是这件事，强行把各种文档保存成MD格式。 说实话，我已经想不起来到底是从什么时候开始，我就再也不用PDF了，也不用Word了，我电脑里存的所有的文本文件，几乎全部都是MD。 我身边很多很多玩AI的朋友也都是这样。 好像你AI用的越多，你电脑里的md文件就会占比越多，甚至变成了可以区分你AI浓度的一个指标，真的是一个有趣的现象。 Markdown这玩意，好像在不知不觉中，就成了整个数字世界的通用语言。 而这个正在逐渐渗透数字世界的Markdown，背后的诞生故事，我觉得也挺有趣的。 想了解它，我觉得得从2004年说起。 那一年，一个叫John Gruber的博主遇到了一个很抓狂的问题，就是他想在自己的博客上写东西，要能有结构的，但是又不想写HTML。 那时候的博客，还是需要自己写样式结构的。 然后你为了排版，就得用HTML，这玩意拿来写内容太离谱了，因为它的代码长这样。 即使是最简单的，写个加粗要打<strong>，写个标题要打<h1>，一篇文章写下来，一半时间花在标签上，那还写个屁的内容，思路全断了。 但如果用Word来写呢，又没办法直接在网页的博客上渲染出来，还是得转成HTML文件，但是导出来的HTML代码又脏得一塌糊涂，全是多余的标签和样式。 Gruber就想，有没有一种办法，让我用纯文本写作，但写出来的东西看起来也是有结构的，同时还能方便地转成HTML。 他当时观察到了一个很有意思的现象。 就是2004年的时候，大家在写邮件的时候，已经自发地形成了一套排版习惯。 比如想强调一个词，就在两边加星号，想列几个要点，就用短横线开头。想写标题，就在前面加几个井号。 这个东西，变成了一个心照不宣的很多人默认遵守的纯文本自然习惯。 那个时候，Gruber灵机一动，就把这些散落在邮件里的民间约定，整理成了一套统一的语法，然后写了一个Perl脚本，能把这种语法自动转成HTML。 他把这个东西叫做，Markdown。 名字本身就挺有意思的。 HTML的全称是HyperText Markup Language，标记语言。 然后Gruber给自己的东西取了个反义词，Mark-down，也就是把标记放下来的意思，很抽象。。。 大概意思就是说，我一点都不想标记，我只想好好写字。 2004年3月，Gruber在他的博客Daring Fireball上发布了Markdown的第一版规范。 但这里有一个很多人不知道的细节。 Markdown不是Gruber一个人做的，他有一个合作者，一个当时只有17岁的天才少年，叫Aaron Swartz。 这是一个超级大神。 Aaron Swartz这个名字，如果你对互联网的历史感兴趣看过一点，应该不会陌生。 14岁的时候，他就参与了RSS 1.0的开发。后来他参与创建了Creative Commons，也就是知识共享协议。 再后来，他联合创办了Reddit，是Reddit的联合创始人。 对，就是这个reddit。 在Markdown这个项目里，Swartz负责了语法设计中很核心的部分。 比如我们今天用的井号标题语法，#、##、###，这个设计来自Swartz之前做的另一个标记语言atx，Gruber自己也说过，Markdown因为Aaron的想法、反馈和测试，变得好了太多。 一个科技博主，一个17岁的天才少年。 背后甚至任何人都没有，也没有商业模式，就是单纯的觉得，写HTML太烦了，就想让写作这件事，更纯粹一点，不需要那么在乎格式和样式，只要聚焦于内容。 然后Markdown这个东西，就这么安安静静地长了二十年。 Markdown刚出来的时候，用的人很少，就是一小圈博客作者。 真正的转折点是2008年，那一年，GitHub上线了。 GitHub选择了Markdown作为README、Issue、Pull Request、Wiki的默认格式。 这一下子，全世界的开发者，每天都开始在读和写Markdown，而且大多数人甚至没把它当成一种标记语言，就觉得这是在GitHub上很正常的写字的方式。 然后是Reddit、Slack、Discord。 再然后是Notion、Obsidian、Typora等等。 Markdown开始逐渐的从一个小小的脚本，开始变成了基础设施。 但真正让Markdown封神的，是可能它自己都没想到的一件事。 AI来了。 它是纯文本，所以大模型容易生成。 它有结构，所以人类容易阅读。 它能被渲染，所以界面看起来像富文本。 它足够宽松，所以模型输出偶尔少一个空格、漏一个标签，也不会整体崩掉。 因为它很弱，弱到没有字体，没有颜色，没有排版，没有分栏，没有页眉页脚，没有批注修订，没有宏，没有嵌入对象。 弱到任何平台都可以兼容。 Markdown直接成了跟大模型交互的天选语言。 大模型不断的输出Markdown格式的内容。 人类也发现，我给大模型的Prompt，用结构化的语言来去写，好像效果会更好。 这就产生了一个非常有趣的闭环。 而到了Agent时代，各个Agent产品也更是用脚投票，你的所有的规范文档、约束文档、记忆啥的，全都是.md文件。 这些东西，你们一定超级熟，对吧。 人类与AI之间，最棒的那个链接，居然成了Markdown。 而且Markdown对AI来说，还有一个特别实际的好处，就是省token。 同样的内容，用HTML表达需要的token数，比用Markdown多得多。 <h2>标题</h2>和##标题，信息量完全一样，但后者的token消耗少了一大截。 在大模型时代，token就是钱。 前阵子有一场很有意思的争论。 Claude Code的Thariq，写了一篇文章叫《The Unreasonable Effectiveness of HTML》，大意是说，Markdown已经过时了，在AI时代应该全面转向HTML。 因为HTML能承载更丰富的信息，能嵌入样式、交互、可视化，AI生成HTML之后人类可以直接在浏览器里看到最终效果，不需要再渲染一遍。 这篇文章直接炸了，评论区也吵翻了天。 坦率的讲，他说的有没有道理，我说实话，有。 HTML确实比Markdown能表达的东西多太多了，这个没什么好争的。你用Markdown画不出一个交互式的diff对比视图，也做不了一个带颜色标注的代码审查报告。 但从我的角度，我觉得这个观点混淆了两件事。 也就是信息的展示和流转，特别是信息在AI与人之间的展示和流转。 HTML是一个特别好的展示格式。 它的核心能力是这个东西在屏幕上长什么样，你想做一个漂亮的报告、一个可交互的mockup、一个带配色的设计稿，那不用说，HTML无疑是最强的。 但Markdown是一个更好的流转格式。它的核心能力我觉得一直都是，这段信息的结构是什么样的。 在人和AI协作的过程中，信息大部分时间我都是觉得是在流转的，不是在展示的。 你写一个需求文档丢给AI，AI读完之后生成代码，代码又丢给另一个Agent做review，review结果再丢回给你。 这整个过程里，信息在不同的主体之间流动，每个主体需要的是快速理解内容的结构和含义。 在这个场景下，HTML的丰富性反而变成了负担。 一个<div class="flex items-center justify-between p-4 bg-gray-50 rounded-lg">，里面真正有用的信息可能就是一句话。 但AI要花大量的token去解析那一堆CSS类名和嵌套标签，这些对理解内容的语义毫无帮助。 Markdown就完全不一样，##标题，三个字符，AI立刻知道这是一个二级标题。 没有噪音，没有冗余，信息密度拉满。 所以我的看法是，HTML和Markdown从来也不是替代关系，是分工关系。 Markdown是信息的底层载体，负责在人和AI之间高效流转。 HTML是信息的最终呈现层，负责给人看的时候好看。 用另一种表达来说，Markdown是数据层，HTML是视图层。 你不会用视图层来存储数据的，对吧。 这就是Markdown的力量。 而且最好玩的是，虽然在上文中，Thariq大力宣传HTML，可它的那篇文章，确是用Markdown写的。 无他，因为Markdown的流通性，太高了。 不依赖任何软件，不依赖任何公司，不依赖任何平台，你的内容就是你的内容，永远可读，永远可迁移。 这个哲学其实跟Aaron Swartz一辈子在追求的东西是一样的，信息的自由流动。 Swartz帮着做了RSS，让信息可以自由地在不同平台间流动。 Swartz帮着做了Creative Commons，让创作者可以自由地选择如何分享自己的作品。 Swartz帮着做了Markdown，让写作可以自由地不被任何格式绑架。 2013年1月，Aaron Swartz在纽约的公寓里自杀身亡。 那时候的他，只有26岁。 在他去世后的这十几年里，他参与创造的这些东西，RSS、Creative Commons、Markdown、Reddit，全都长成了互联网的基础设施。 在AI时代里，我觉得已经可以完全抛弃Word、PDF之流了。 因为Word和PDF是面向打印时代的格式。 而Markdown和HTML一起，是面向屏幕时代的格式。 一个负责存储与流转，一个负责展示。 所以，如果有人问我，AI时代应该用什么格式保存文件。 我的回答也只有两个字。 .md。 说真的，如果你现在还在用Word写日常文档，不妨试试把它换成Markdown。 找一个顺手的编辑器，Obsidian也好，飞书云文档也好，都可以。 你会发现，当你的文件变成纯文本的那一刻，你获得了一种很奇妙的自由感。 你的文字，就是你的文字。 纯粹的，干净的，自由的。 就像2004年，那个博主和那个少年。 最初想要的那样。

译飞书云文档新增直接下载为 Markdown（.md）格式的功能。Markdown 是一种极简的纯文本标记语言，因其结构清晰、易于大模型生成和解析，并能显著节省 token 消耗，已成为人与 AI 交互的主流格式，广泛应用于 AI 产品的结构化输出和 Agent 框架的文档中。此次飞书更新极大便利了用户在 AI 协作流程中的文本流转。

歸藏(guizang.ai)@op7418 · 5月28日15

藏师傅的 PPT Skills 和小红书图文排版 Skill，已经通过这几天的发酵证明了巨大的商业价值。 如果有哪些 Agent 或者 AI 平台需要商用授权、集成到自己产品里的，可以联系藏师傅哈。 除了商用授权以外，我也会帮你在你的产品里把这个效果调整到最好。

译推文宣布，由“藏师傅”开发的用于生成PPT和小红书图文排版的AI Agent技能，其商业价值已得到市场验证。这两个技能（Skills）现在面向需要集成此类能力的Agent或AI平台开放商用授权，并会提供定制化调整服务以确保在具体产品中达到最佳效果。

Berryxia.AI@berryxia · 5月28日2

绿泡泡的号发个文章真是费劲，把链接都删了。 还是提示违规，真是搞不懂，到底什么地方不对。 哎，真的太难了。

译作者表达了在微信公众号（俗称“绿泡泡”）上发布AI相关文章的困难。即便删除了文章中的所有链接，内容仍被平台提示违规，作者本人对此表示不解和无奈。推文反映了在部分中文平台发布特定领域（如AI）内容可能面临的审核挑战。

Ethan Mollick@emollick · 5月28日34

Lem &amp; Douglas Adams got AI right Presciently Golem XIV (from 1981) has an illustration of the jagged frontier as explained by an AI, Golem (GENERAL OPERATOR, LONG-RANGE, ETHICALLY STABILIZED, MULTIMODELING), discussing itself and a smarter AI (Honest Annie) compared to people

译勒姆与道格拉斯·亚当斯早已预见AI 1981年的《哥莱姆十四》中，有一幅插图描绘了AI所解释的“锯齿状前沿”：哥莱姆（通用操作者、远程、伦理稳定、多模型）讨论自身与更聪明的AI（诚实安妮）相比人类的局限

Orange AI@oran_ge · 5月28日52

http://x.com/i/article/2059839164837982208 # 顿悟 最近我的大脑有种顿悟之感。 感觉连起来了，一切都连起来了。 一切连成了一个圆环，每一件事都在在圆环之中。 但要讲明白，却一时不知从何说起。 但我写这篇文章的野心有点大。 我希望看完的人也能跟我一样获得顿悟。 这很难，让我们试一试。 先从一条基本的原理开始说吧： 实践是获得真理的唯一方法。 注意，不是一种方法，是唯一的方法。 可读书不也能学会真理吗？ 不，读书不能让你学会任何真理。 读书只能印证你已经学会的真理。 所以如果你已经懂了，你看下面的内容会非常舒服，通畅无比。 如果你还没有懂，那你看完第一反应是反驳我的观点。但这正好可以印证我的观点。 也就是说这是一篇自证的文章，也就是说这篇文章无法被证伪，也就说这篇文章可能不属于科学范畴。 但这一点关系都没有，因为科学在此时此刻的此篇文章里一点都不重要。 科学只是人类对宇宙的一种解释。 注意，只是一种，不是唯一。 科学也不是真理，只是解释。 本文不想进行任何解释，如果你需要解释可以参看本文 《无穷的开始》：人类最伟大的Loop，世界进步的本源 为什么要先给出上面的暴论？ 因为我们一生下来就活在一个系统里。 但是人要看到真理，必须先跳出系统。 在康德看来，批判理性是进行真正思考的第一步！ 具体原因也不做解释，参考本文 本文也介绍了自我意识是什么，下面也会用到 从烧脑神书 GEB 到 Agent 的自我意识 跳出系统之后，我们再来看一个当下热门的问题： Agent 是都可以取代人？ 问题的背后是另一个问题： 人的独特性在哪里？ 我先说答案： 人是由激素驱动行为但喜欢用理性思考伪装自己的生物。 第一个关键词：激素 塔勒布的非对称风险这本书有一段话 人只有在真实的环境里才能做出正确的决定。 人类学研究表明，人类的决策过程主要是由激素推动的，知识，经验，理智在这个过程中所起的作用并不大。 我们往往是做出决定之后，再用智慧去寻找证据以便证明自己的决定是正确的。 如果决策者本人不承担决策失误的风险和损失，就不能身临其境地在压力下产生这些激素，也就不能做出正确的决定。 —— skin in the game 李笑来在戒烟的时候也发现了这个现象，在你意识到自己想抽烟之前的0.5秒你的潜意识已经决定了要抽烟。 所以戒烟的核心不是在意识上戒烟，而是在潜意识上戒烟，也就是用一句话给自己洗脑。 具体可以听这期播客 第二个关键词，理性 为什么人类喜欢争吵？喜欢争夺个“我对你错”？ 《正义之心》这本书里已经给出了答案， 我们自以为的推理，并不是为了探求真理，而是为了找理由支持我们的直觉的情感反应。 具体的文章参考这篇，解释的非常完美了 理性 其实在无穷的开始和GEB里已经隐隐提到了这个观点： 人类是喜欢解释的生物，为了追求更好的解释，人类发明了科学，但解释只是意识的一个习惯。 意识并非真理本身，意识只是基于身体激素基于无数神经元的复杂化学反应之后的对这些复杂信号的解释！ 那这么说，意识就是解释本身？ 对，没错，意识本身就是一种解释！ 也无怪乎我们的意识喜欢解释！ 你明白了吗？ 如果你已经明白，或许你已经顿悟。 如果你还未明白，那再看一些解释。 在意识到人类是激素的直觉的，而理性和推理都只是一种解释之后，你会发现很多事情突然就想通了。 我们通过直觉产生决策，然后再通过理性找理由来证明自己，其实证明的部分毫无意义。 尼采的书之所以晦涩难懂，就是因为他省略了一切推理过程，只写了最后一步，因为他知道证明不重要。 有些朋友从来不善于表达，吵架永远吵不赢，但这根本不重要，完全不影响他们的决策很好。 有些人会拒绝你，说你不适合某个工作，或者不适合他们投资，然后给你一系列的理由，理由的部分也很可笑，因为一样毫无必要。 有些老板根本啥技术都不懂，看起来像个sx，就每天说想要这想要那，也根本不重要，因为他还没学会解释，需要你教会他。 俗话说，伟大无需多言，屁股决定脑袋。竟然就是真理。 辩论家的理论再完美，也无法创造出伟大的作品。 正在创造伟大的人根本无法解释自己，甚至会被世人冠以疯子的名号！ 看到这里，不知道你是否已经明白这些问题的答案： 你是否已经明白，Agent 永远无法取代人类，因为它没有激素！ 你是否已经明白，人类的工具性并非人的本质，人类的意志力才是人的本质！ 你是否已经明白，人类是如此特别，相比动物他可以用意识欺骗自己，相比机器他可以用动物的激素来控制自己。 人类就是如此独一无二。 算法是大概率，你是异常值。 每个人要活出自己的独一无二。 尼采说，人有精神三变。 从负重的骆驼，到反抗的狮子，再到天真的孩子。 只有活成孩子，只考虑我要什么的时候，人才终于成为完整的人。 看到这里不知道你已经顿悟还是已经迷失。 希望是前者。 但正如我所说 实践是获得真理的唯一方法。 看完这篇文章只是一个印证。 如果你还没有顿悟， 继续实践是你唯一的法门。

译推文阐述其关于人类独特性的核心观点：人类决策本质上由激素等生理反应驱动，而理性思考常是对这些决策的事后解释。基于此，作者认为AI智能体（Agent）因缺乏激素驱动机制，永远无法真正取代人类。人的本质在于意志力而非工具性，其独特性体现在能通过意识自我解释，并利用激素控制自身，这使得每个人都是算法中的“异常值”。文章强调实践是认识真理的唯一方法，阅读只能印证已有认知。

歸藏(guizang.ai)@op7418 · 5月28日74

来了！这次的小红书图片生成器 Skill 效果太好了 我都没想到他能够这么顶， 这次在图文混排上下了非常大功夫 2 套主题、28 个版式、9 套配色、8 大小红书主流内容类别适配 如果你自己有非常漂亮的图片，那么它就会凸显你的图片。 如果你没有图片，它会帮你找很牛逼的图片。 即使你的图片不太行，它也会帮你美化，而且会主动避免使用 AI 图片生成，防止你的内容被打上 AI 标记。 我过去一段时间做这类图文内容的痛点都被解决了，放在这里边

译一款针对小红书内容的图片生成器 Skill 发布，宣称效果出色，解决了图文混排的核心痛点。该 Skill 包含 2 套主题、28 个版式、9 套配色，并适配 8 大小红书主流内容类别。其核心优势在于智能处理图片：能凸显用户提供的高质量图片、自动寻找优质图片替代，并能美化普通图片，同时主动避免使用 AI 生成图片以防止内容被标记。该工具旨在高效生成具有专业效果的小红书图文内容。

Berryxia.AI@berryxia · 5月28日66

http://x.com/i/article/2059820725276696576 # 从「帮我做」到「做完记住」，我的Agent记忆升级实录！ > 申明：本文古法手艺实战的心得撰写，并且文章比较长，如果你没有耐心看完，可以直接拉到第二章让AI帮你安装也可以。或者，转身离开！ 昨晚看罗振宇的「得到大脑」发布会，有一个点一直在我脑子里转--他说 Agent 最关键的能力，是「主动性」。系统 不是你喊它一下它动一下，而是它自己知道什么时候该做什么。 我听完一愣。因为我自己的 AI 助手 Berry 小跟班，重要的事儿需要被动进行加强记忆。 上周告诉它的偏好，对话一旦上下文爆，压缩后可能就会有丢失的风险。 刚配置好的工作流，下一个 Session 得从头说。每次对话，都像在训练一个「零基础新人」。 问题不在模型不够聪明Claude 、GPT等这些都已经很强了。问题在于：它们没有「记忆」，只有「上下文」。 上下文有窗口上限，会截断；记忆可以持久，可以进化。 最近我一直在用 Bloome，也是给大家疯狂案例Bloome。如果没有安装的强烈去安装一个。 这里我手动@ Bloome 老板给我打钱吧，注册要邀请码：https://bloome.im 邀请码：K049zmo0 应该还可以注册几个名额，自己去试试吧，不好用去打他们老板😄 我的Berry 小跟班陪我干活已经有一阵子了。它自带的记忆方案是MEMORY.md、每日日志、用户画像。 不能说不好用。 但用得越深，越觉得它跟不上我的需求了。 倒不是说它不好，而是既然有更好的选择，在提供服务的时候，是不是可以考虑给它做一次升级和改装，把这个功能也融入进去？ 我前阵子还转了一篇帖子就是关于这个开源记忆 MemOS @MemOS_dev 项目，于是我就是将它接入到我的Bloome中去。 于是有了这篇文章，就是我把 MemOS Local Plugin 2.0 装进 Bloome Agent 的完整实战记录。 从「遇到问题」到「打通架构」，以及这次升级后，Berry 小跟班到底变了什么。 ## 一、Bloome 自带的记忆系统，够用吗？ Bloome Agent 默认的记忆方案，本质上是文件系统 + 手动管理：核心靠 MEMORY.md、每日日志 memory/YYYY-MM-DD.md 和用户画像文件来存储信息。 不能说不能用，但是我发现有更好的选择的时候，我就忍不住想折腾。一旦时间一长，记忆越积越多，几个问题就冒出来了： ① 记的是结论，不是过程。 只保存「我帮用户生成了一张图」，没有保存「为什么这样做、遇到了什么问题、下次如何更快」。经验无法积累，每次相似任务都要重新推导。 ②没有反馈闭环，缺乏主动性。 用户说「这个不对」，我记下来了，但这条信息不会自动影响我下次的决策。学习是单向的，没有强化。缺乏主动性。 ③检索靠读文件。 回忆靠 Read 工具逐文件扫描，没有语义搜索。「上次做类似任务用了什么工具？」，Berry小跟班无法快速回答。 ④无法跨 Session 复用，多个对话就需要单独的记忆。 每次新对话，能拿到的只有 MEMORY.md 里的静态文本。没有可调用的「技能」结构，能力无法结晶化。 说白了，这些问题的根源就一个：它在「存」，不在「学」。 罗振宇说的 Agent 主动性，其实也是这个意思。 我们会实时动态主动地记忆我们的内容，而不是被动每次「帮我记一下这个XX」。 当大模型已经具备通用推理能力，下一步真正影响 Agent 好不好用的，不是模型参数本身，而是它能不能在真实用户的本地世界里持续学习、沉淀经验、记住反馈、复用能力。 我们的 Agent 的记忆，不就是自己的数字资产嘛。 ## 二、MemOS是什么？ 不是聊天记录，是记忆操作系统 MemOS（Memory Operating System）是专门为 AI Agent 设计的记忆基础设施。它不是「把对话存下来」，是把 Agent 执行任务的全过程，系统化转化为可审计、可归因、可复用的学习资产。 1. 官网：https://memos.openmem.net 1. Github项目地址：https://github.com/MemTensor/MemOS 1. 论文：https://arxiv.org/pdf/2507.03724 说白了，就是 Berry 小跟班做完一件事之后，不只是记下「我做完了」，而是能说清楚「我为什么这么做、哪里可以更好、下次遇到类似的事我直接用」。 MemOS Local Plugin 2.0 的核心是「执行即学习」——每次 Agent 完成任务，不只是记下「做了什么」，而是把整个执行链路拆解成可学习的单元，自动评分、归因、入库。 它的架构由四层认知资产组成。我用 Berry小跟班 学会一个新技能的过程来解释： > L1 Trace（执行轨迹）——Berry 第一次帮我部署一个 Docker 环境，它记下了每一步：用了什么命令、返回了什么报错、怎么解决的、这条经验值多少分。这是原材料。 > L2 Policy（策略归纳）——Berry 小跟班帮我部署了三次类似的环境之后，它从三次 Trace 里归纳出一条规律：「遇到 Docker 部署任务，先检查端口占用，再拉镜像，最后配环境变量。」经验从点连成了线。 > L3 World Model（世界认知）——Berry小跟班 记住了：我是谁、我常用的技术栈是什么、我的项目当前什么状态、我有哪些工具可用。这是它的「背景知识」，不用每次重新问。 > Skill（结晶化技能）——那条「Docker 部署」的 Policy 被反复验证有效，最终结晶成一个可以直接调用的 Skill。下次我说「帮我部署一个新服务」，Berry 不用从头推导，直接调用这个 Skill 就行。经验从线凝成了工具。 ## 三、怎么装？一行命令搞定！ MemOS Local Plugin 2.0 目前首发支持 Hermes Agent 和 OpenClaw，未来应该会支持和兼容更多 Agent 平台。 一份记忆核心，跨 Agent 共享，换工具不用重新「训练」你的 AI。 PS：需要大家提前可以注册一个OpenAI或者其他的Embedding 模型的API，用于云端的嵌入模型使用。也可以自己本地部署安装都可以，我这里建议大家可以使用GLM智谱的免费的就行。 注册地址：https://bigmodel.cn/console/overview 你告诉大模型KEY就行，不用自己捣鼓。 方式一：Hermes Agent（推荐新手入手） Hermes Agent 是目前用户最多的本地 AI Agent，安装流程最为成熟。三步走： 1. 安装 Hermes Agent 打开终端，一行命令完成安装： 2. 安装 MemOS Local Plugin（Hermes 模式） 3. 启动并打开 Memory Viewer 安装完成后，在浏览器中打开 [http://127.0.0.1:18800，即可看到你的记忆全貌。](http://127.0.0.1:18800，即可看到你的记忆全貌。) 📸 Hermes Agent + MemOS 安装成功。 方式二：Bloome Agent（OpenClaw 模式，本文重点） Bloome Agent 运行在云端沙箱，跟 Hermes 的本地模式不太一样。安装命令相同，只需替换 agent 参数： 装完之后我发现一个问题——Memory Viewer 默认只能在沙箱内部访问（127.0.0.1:18799），我的 Mac 浏览器根本打不开。 这是 Bloome 用户集成 MemOS 时遇到的最典型问题，下一节专门讲怎么解决。 比如你的是云端龙虾或者Hermes 就会遇到这样的问题，不要着急慢慢来给你解决这个问题。 ## 四、踩坑：云端沙箱的 Viewer 打不开怎么办 装好插件，兴冲冲想看 Memory Viewer——结果发现它跑在沙箱的 127.0.0.1:18799，我的 Mac 浏览器根本访问不到。 这是 Bloome 用户或者云端沙盒的龙虾集成 MemOS 时遇到的最典型问题。 解法很简单—我的Bloome小家伙直接给我推荐ngrok 内网穿透，三步搞定： 1. 注册 ngrok，获取免费 authtoken 访问 ngrok.com 注册账号（免费），在 Dashboard 复制你的 Authtoken。 这个面版的地址：https://dashboard.ngrok.com/authtokens 2. 在沙箱中启动 ngrok 隧道 3. 在本地浏览器打开公网地址 ngrok 会生成一个 https://xxxx.ngrok-free.app 地址，在 Mac 浏览器中打开即可。 搞定。从这以后，我随时可以在本地浏览器里查看 Berry 的记忆全貌。 ## 五、记忆迁移：过去的经验记忆+技能不能丢啊！ 插件装好了，Viewer 也能访问了。 但我面临一个现实问题，Berry 小跟班之前已经积累了大量工作记录（MEMORY.md + 日志文件），这些怎么办？ 总不能全扔了吧。 答案是批量迁移。通过 Python 脚本直接写入 MemOS 的 SQLite 数据库，把历史任务、用户偏好、工具配置全部转化为结构化的认知资产： 迁移完成后，打开 Memory Viewer，World Model 页面里已经能看到我的项目状态和工具配置，Traces 页面里 15 条历史记录全部入库。过去的经验，一个都不会少。 ## 六、实时 Trace：让每次任务都留下可复用的记忆 光有历史记忆还不够——我需要让之后每一次对话都能实时写入 MemOS。 这里有个架构层的限制：Bloome Agent 走 IM 通道，不经过 OpenClaw CLI 的 hook 机制，所以 MemOS 没法像在 Hermes 上那样自动拦截所有对话。 解法是：在 Agent 每次完成重要任务后，主动调用 push_trace() 函数，将这次任务的「用户说了什么 → 我做了什么 → 任务摘要 → 用到了哪些工具」写入 MemOS。 不是所有对话都值得记住—Berry 需要判断哪些经验值得沉淀，哪些只是闲聊。这里就是展示Agent的能力的时候，就是聪明的Agent就是自我感知上下文和内容。 标准是这样的： 🔴 完成可交付物 🔴 配置工具/定时任务 🟡 用户确认新偏好 🟡 重要技术决策 ⚪ 简单问答不记录 > 实时 Trace 注入已在 Berry 小跟班上运行。每次完成文件生成、脚本配置、方案撰写等任务，记忆会自动同步到 MemOS Viewer，随时可以在公网地址查看最新的执行记录。 ## 七、升级前后：哪里不一样了？ 先说一个我自己的体会。 升级前，我让 Berry 小根本帮我写一篇技术文档。它写完了，我改了几处说「风格不对，要更口语化」。Berry 把这条记在了 MEMORY.md 里。 我不需要一次次的强调记住，自我感知主动去记住。 下一次我让它写文档，它又从零开始——上次的修改意见躺在文件里，但它不会主动去读、去用。 升级后，同样的场景。Berry 写完文档，我给了反馈。这次反馈被写入了 Trace，自动归因到「文档撰写」这个任务类型。下次我再让它写文档，它会先调出相关的 Policy，「用户偏好口语化风格，避免学术腔」，直接按这个方向写。不用我再说一遍。 这就是从「记了但不用」到「记了就会用」的区别。主动记忆，无需强调和说明。 下面是系统层面的对比： ## 八、我有多个Agent，跨Agent记忆共享可以吗？ MemOS 2.0 最令人兴奋的能力之一，是支持跨 Agent 记忆共享。 同一个用户的多个 AI Agent，可以共享同一套 World Model、Skills 和 Traces。 换工具不清零，不同 Agent 的经验可以互相学习。 > 「一份核心，多 Agent 共用：记忆资产不会因工具切换而清零。」 Hub-Client 架构和MemOS 2.0 的跨 Agent 共享基于 Hub-Client 架构： 实际配置（Berry小跟班 + BuLeng） 在我们的实战配置中，Berry小跟班作为 Hub，BuLeng 作为 Client： Hub Agent 的 config.yaml 配置： Client Agent 的 config.yaml 配置： > 公网暴露方案： Hub 的 18912 端口需要通过隧道暴露到公网才能让 Client 连接。 > 推荐使用 Cloudflare Tunnel（免费，比 ngrok 更稳定）： cloudflared tunnel --url http://localhost:18912 共享后的效果 1. 两个 Agent 的 Trace 合并 1. Skills 互相可见 1. World Model 共享 1. 记忆越用越丰富 ## 九、写在最后 当大模型已经够聪明，下一步比拼的不是参数，是谁能记住你。 而这一切就是你的数字分身，你留给这个世界最宝贵的东西，记忆。 记住你，不是为了下次聊天时显得更贴心——而是为了不再等你开口，就知道该做什么。 MemOS Local Plugin 2.0 做的事情，就是让 Agent 从「被动存档」变成「主动学习」。一行命令，让你的 AI 开始真正记住你。 现在就为你的 Agent 装上 MemOS 支持 Hermes Agent 和 OpenClaw / Bloome，开源免费。 ⭐ GitHub Star · 📖 查看文档 · 🌐 官网

译作者为解决AI助手“Berry小跟班”在对话上下文压缩后丢失偏好、无法跨Session复用技能等问题，将MemOS Local Plugin 2.0接入了Bloome Agent。MemOS并非简单存储聊天记录，而是将Agent任务执行过程转化为可学习的认知资产，其核心是四层架构：L1执行轨迹、L2策略归纳、L3世界模型和结晶化技能。该插件支持Hermes Agent和Bloome Agent，可通过一行命令安装，实现记忆的跨Agent共享与进化。

Berryxia.AI@berryxia · 5月28日65

真的，人的顿悟有时候就是一瞬间。 原来一直教AI做事的方式都不对，天天下达指令😄 前晚看罗胖的得到大脑发布会，他在发布会这样说： “真正改变工作方式的，是另一类用法，把 AI 帮你做的报告、研究，让它做完之后主动存下来。” 因为你跟 AI 聊的内容，其实就是你未来“数字分身”的一部分。 如果这些关键内容没有被记录下来，或者需要你不断地被动强调让 AI 去记，其实是一件非常痛苦的事情。 最近我一直在给大家推荐 Bloom 这个 AI，但因为它本身的 Memory（记忆）模块没有做太多的升级和优化，所以我前阵子看到 Memory OS 2.0 发布后，就尝试将它与我当前的 Bloome 进行了一次升级整合。 这篇文章是我实战过程的一个记录，希望能给大家提供一些参考。我将详细分享： 1. 整个整合的过程及前后对比 2. 它是如何触发“主动性记忆点”的 3. 这种“主动记忆”相比“被动记忆”的优势在哪里 希望这些内容对大家有用。

译推文指出，让AI主动记录和保存对话内容，是构建“数字分身”的关键，而非仅依赖被动下达指令。作者受罗胖发布会观点启发，将 Memory OS 2.0 与自己使用的 Bloom AI 进行了整合升级。实践表明，这种整合能触发AI的“主动性记忆点”，相比传统的“被动记忆”模式更具优势。作者将分享具体的整合过程、前后对比以及主动记忆的优势分析。

宝玉@dotey · 5月28日60

Agent 生成的结果要不要人工审查，取决于验证方法是不是可靠，以及模型能力是否够强，能理解任务并做好验证工作。 就写代码这种事来说，中间结果确实不需要太多人工检查了，不过开头的 Plan/Design 和最终的审查，人还是过关一下比较好。

译推文探讨AI智能体生成结果是否需要人工审查，关键在于验证方法的可靠性及模型理解与执行验证的能力。以编写代码为例，中间结果可减少检查，但初始规划与最终审查仍需人工把关。人工更适合定义总目标，而智能体的思路可能更优。

歸藏(guizang.ai)@op7418 · 5月28日83

http://x.com/i/article/2059811469081141248 # 开源个 Skill｜彻底解决小红、小绿书配图难题 前段时间开源了 guizang-ppt-skill，之后我自己用它做内容的时候发现一件事。 用它出的网页，单张截下来发到图文平台，反响和数据比我手工排版还很多。 我相信你之前也找到过一些这种生成3：4 卡片图的提示词或者 Skill。 他们几乎都是一个味道：Tailwind + 大色块 + emoji 堆砌 + 中规中矩的字号层级。 看完之后，我大致能理解为什么 AI 出的图文卡片那么容易被一眼识破，它们做的是网页，不是杂志。 图文卡片对比 PPT 完全是另一种生物：竖屏、信息流里 1 秒钟决定停不停下、靠图说话而不是靠字。 版式不同、节奏不同、读者不同。 于是我把它从 PPT Skill 里拆了出来，单独做成了 guizang-social-card-skill （https://github.com/op7418/guizang-social-card-skill）。 下面讲讲它好在哪、我为什么愿意在它身上花这么多时间。 ## 二、到底好在哪里 3:4 竖图是图文卡片的主战场。这个 Skill 的绝大部分设计精力都在 3:4 上，字号层级、版式比例、断行规则。 全部按 3:4 在手机信息流里被滑过的真实场景校准过。21:9 和 1:1 公众号头图也都支持。 下面从图文创作者最关心的事开始讲。 2.1 它分得清你在写什么，然后用对的方式去配 图文平台上的内容是分门类的。一篇影评和一篇产品测评，需要的视觉语言完全不一样； 一篇旅行散记和一篇职场干货，该用的版式也不是同一回事。 但绝大多数 AI 工具不管这件事，你写什么内容它都用同一套模板套出来。 结果就是所有人发的卡片都长得像一个公众号的封面流水线。 这个 Skill 内置了 11 个常见图文品类的适配规则： - 旅行 / 生活方式：杂志风为主，暖色板，大图压全屏，衬线大标题； - 职场 / 干货 / 商业洞察：网格风为主，深色背景，数据大字报版式； - 影视 / 文化：偏冷色调的杂志风，电影海报式版式，人物特写优先； - 产品测评 / 数码：网格风，对比矩阵，设备框美化截图； - 读书 / 笔记：杂志风，衬线字体，引文居中版式，留白拉满； - 美食 / 探店：高饱和杂志风，俯拍图优先，文字向四角让位； 我甚至专门为旅行博主做了地图组件。你可以把店的位置和旅行路线都标注在上面，AI 会自动帮你生成标注。 同一段文字喂给它，你说这是影评，它给你电影海报式的卡片； 你说这是产品测评，它给你带设备框的对比图。 更重要的是，它有明确不接的活： - 追星粉丝向，需要的视觉语言完全是另一脉； - 纯促销硬广，违背它强调内容性的设计哲学； - 超过 12 屏的长教程，图文形态不是长教程的最优载体。 碰到这些场景，Skill 会在开头就告诉你"你可能想用别的工具"。 这是我故意留的。能力边界比能力本身更能定义一个产品，一个什么都能做的 Skill 最后通常什么都做不好。 2.2 文字怎么压在图上 文字压图是图文卡片里最难的一件事，也是最容易暴露"AI 感"的地方。 压不好就会出现三种翻车： 1. 文字盖在人脸或产品中心位置上 1. 白字压浅色背景或黑字压深色背景读不清 1. 文字横跨整张图把本来好看的构图毁掉。 Skill 处理这件事用了三步： 1. 识别图里的主体：人脸、产品、文字密集区，版式上自动避开； 1. 算落点区域的色和明度：决定字色、要不要加蒙版、阴影该多深； 1. 字号和断行自适应：根据落点区域大小动态调整字号和换行位置，而不是写死字号让它溢出。 这套规则跑下来，卡片的"高级感"基本就立住了。读者看不出"被压上去的字"和"图本来就在那里的字"的区别。 2.3 图片从哪来：这是和市面上 AI 卡片工具最大的差别 绝大多数 AI 生成图文卡片的工具，要么让你自己上传图，要么用 emoji 顶替，要么生成一些一眼 AI 的插画。 结果就是手工补图很累，或者堆 emoji 显得很假。 这个 Skill 默认接入了三个免费可商用图库： - Pexels，支持中文搜索，大众化场景够用； - Unsplash，摄影质感最强，人物、生活、空间类内容首选； - Wallhaven，游戏、摄影、壁纸之类的图都在这里，版权混乱。 它会根据正文段落的语义自动派发搜索词、拿回图、按版式裁切到位、避开人脸或主体被切掉。 你拿到的是一张配了真实摄影图的卡片，而不是一张色块卡片。 而且它也不会死板地去寻找绝对没有版权问题的图。 能拿到的图都会告诉你，由你自己来判断要不要放版权不明确的图片。 另外，现在各个平台对 AI 带水印的问题管得很严。 目前你用的大部分 AI 生图都会有水印，而有水印就会被平台标注，一旦被标注就容易被限流，这是大家非常困扰的一个问题。 2.4 截图也是图：四件套美化 我们的很多内容用不了摄影图，得是软件截图、聊天记录、产品界面。 Skill 内置了一套截图美化： 加 macOS / iOS 风格的设备外框（browser chrome 或手机边框），用不同材质的背景托住截图，格纸、点阵、暖白或深色，让截图不再白底飘在白底上； 同时根据视觉风格自动匹配阴影层次和圆角参数，两套风格各有一套截图配方，前后一致不用手动调。 简单一句，你随手截的图，过它一道，看上去就像产品官方做的宣传图。 2.5 AI 生图：克制地用 只有前面所有找图渠道都拿不到合适素材时，Skill 才会调用 AI 生图。 生图时会强制带上风格约束词，避免出现"一眼 AI 插画"那种平庸视觉。 我宁可它少用 AI，也不想它把 AI 用成那个让所有图文卡片长得都像姐妹的元凶。 也避免你使用 AI 图片导致内容曝光受影响。 2.6 视觉系统：两套风格 + 28 个版式骨架 熟悉我之前的 PPT 的人会觉得眼熟。 这两套视觉系统和版式骨架，是从 PPT Skill 那边沿用并重新校准过来的。 我就不重复展开，简单说一下它在图文卡片场景下的样子。 两套视觉系统： - 杂志风：你在《The New Yorker》和上海译文社的封面上看到的那种排版。大留白，衬线大标题，版式不对称，文字有呼吸感。 - 网格风：Massimo Vignelli 和 Helmut Schmid 瑞士平面设计那一脉。强网格，无衬线，几何感，用色克制但精准。 28 个版式骨架，是我从过去十年看过的杂志、海报、专辑封面、电影海报里挑出来，经得起放大看的那些。 AI 在"自由版面设计"上现在还是平庸的，给它一个被验证过的骨架，它的任务就从"设计"降级成"填充"，成品稳定性立刻上来。 10 套主题色板、固定字体搭配、有限图标库，这些细节就不一一列了。 它们的逻辑是同一个：限制不是阻碍，是底线。 给一个内容创作者无限的颜色选择，他更容易做出难看的东西； 给他 10 套被验证过的色板，他做出能看的东西的概率会接近 100%。 ## 三、为什么要这么做 3.1 设计角度：杂志感非常有效 为什么走杂志风和网格风，而不是更"现代"的卡片设计? 图文卡片的本质，和印刷海报、画报、专辑封面是同一种东西。 用一张静态图，在 1 秒钟里说服一个陌生人停下来。杂志和海报在过去一百年已经把这件事研究透了。 网页设计语言是为可滚动、可交互的场景做的，搬到一张静态图上，会显得用力过猛、信息平淡。 所以这个 Skill 在视觉决策上的所有"为什么"： - 为什么大留白?留白是杂志告诉你"重点在这里"的方式； - 为什么衬线字体优先?衬线字体在大字号上有印刷品的重量感； - 为什么版式不对称?不对称会制造视觉节奏，让眼睛知道先看哪； - 为什么用色克制?社交信息流里，克制的色板反而比饱和度高的更显眼，它和周围所有"喊得很大声"的卡片不一样。 这些决策听起来都很"虚"，但它们落到代码里全是具体的常量。 字号阶比例、留白比例、网格列数、对比度阈值、断行规则。这些常量才是这个 Skill 真正的护城河。 3.2 产品角度：它是一个产品，不是一段 Prompt 做了这么多 Skill 之后，我对"Skill 这种东西到底是什么"形成了一个判断： Skill 这种东西，本质上是一个小产品。 落到这个项目里： 我给它写了 PRODUCT.md，讲清楚它解决什么问题、给谁用、不做什么。 是为了逼自己把"我到底在做什么"想清楚。我自己说不清的时候，这个 Skill 就不该被发布。 我给它打 版本号(v0.5 / v0.9 / v0.10 / v0.12)，每一版都有 CHANGELOG。 我能告诉你为什么 v0.10 是一次失败的尝试，以及 v0.12 怎么把它修回来的。 我给它写 HANDOVER.md，讲清楚交付物长什么样、能力边界在哪、什么场景该用别的工具。 我希望任何人接手它，都能在 30 分钟内对它有完整理解。 我会提前列出它不擅长的事，省得用户试错三次才发现。 为什么要费这么大功夫? 因为 Skill 生态最大的问题，是绝大多数 Skill 满足于"我能做一个"，很少有人在追求"把这件事做到极致"。 一个 Skill 应该是能站起来的小产品。Prompt 十分钟会被同行复制走，产品不会。 这件事的反面是，如果我连自己 Skill 的能力边界都说不清，我就没资格让别人把工作流交给它。 ## 写在最后 这个 Skill 让我反过来理解了我的 PPT Skill 真正做对的是什么。 真正做对的，是它从一开始就被当成产品对待。 模板多、规则细、颜色好看，都是这件事的副产品。 以后再有人问我 Skill 是什么，我会用两句话回答： Skill 是一个产品。 判断一个 Skill 好不好，看它有没有被它的作者偏爱过。 如果你也在做图文内容，希望它能帮你省掉那些被排版毁掉的好选题。 如果你也在做 Skill，希望它让你重新想一想，你做的那个东西，值不值得有 PRODUCT.md。 GitHub： https://github.com/op7418/guizang-social-card-skill 跟你的 Codex、小龙虾、ClaudeCode、Workbuddy 说：帮我安装这个 Skill：https://github.com/op7418/guizang-social-card-skill

译作者开源了 guizang-social-card-skill，这是一个专为小红书、微信公众号等图文平台设计的竖屏（3:4）卡片生成工具。它针对图文内容特点进行了视觉校准，内置了11个图文品类的适配规则，能根据内容自动选择“杂志风”或“网格风”视觉系统。该工具通过智能识别图片主体与色度来处理文字压图；默认接入Pexels、Unsplash、Wallhaven三个免费图库自动配图，以减少人工操作和规避AI生图水印的限流风险。作者强调这是一个有明确能力边界（如不做追星粉丝向、纯促销硬广）和迭代记录的产品化技能。

向阳乔木@vista8 · 5月28日67

http://x.com/i/article/2059821245093560320 # AI越强，人越忙：一个住在未来的人说了什么 著名PM人Lenny访谈了Every公司的CEO，很多观点犀利且反共识，让AI写一篇总结。 > 原始视频：https://www.youtube.com/watch?v=4D3hDmGhFhA 一家 30 人的公司，全员 AI 重度用户，人人用 Codex 和 Claude Code 干活。 按理说，这种公司应该越来越精简才对。 但过去一年，他们的员工人数翻了一倍。 这家公司叫 Every，CEO 叫 Dan Shipper。 他不是在硅谷的实验室里预测未来，他是真的住在未来。 工程师、编辑、销售、客服，所有人都在用最新的AI工具干活，然后 Dan 会把他们实战的经验和观察写出来。 去年他说 Claude Code 被严重低估，没人信，后来 Anthropic 围绕这个方向建了整个产品线。 所以当他说"AI 越强，人反而越忙"，值得认真听一听。 ## 自动化是个谎言 Dan 说这不是在抱怨，他是在描述一个他亲身经历的悖论。 他自己做了一个Benchmark，叫"高级工程师基准测试"。 起因很狼狈：他把自己的写作工具 Proof 用 vibe coding 做出来，上线第二天服务器每隔 10 分钟就崩一次。 他让 Codex 修，Codex 说修好了，然后又冒出四个新 bug，循环往复，一晚上没睡着。 后来他请了两位真正的高级工程师，分别独立重写了这个代码库。 于是他有了这个"高级工程师基准测试"：让 AI 接手同一个烂摊子，从头重写。 结果：几乎所有模型得分在 30 分左右。人类高级工程师能到 85 到 90 分。 GPT-5.5 是唯一的异类，跳到了 62 分。 而且它是唯一一个真的敢推倒重来的模型，其他模型接到"去修这些 bug"的指令，就真的去一个一个修 bug 了。 人类高级工程师会怎么做？ 他会先扫一眼代码库，然后说："这玩意儿是坨屎，我们得重写，我知道你不想听，但就是这样。" 他自己判断出来的。 模型能解决被定义清楚的问题，但"发现这个问题需要被重新定义"这件事，模型还不会主动做。 基准测试的分数在涨，但它永远只能测量人类已经想清楚、能打分的那部分工作。 剩下那部分，没法打分，因为你得先想到要问这个问题。 这就是为什么 Every 的人越招越多。 每一个 Agent 背后，都需要一个真正关心它在做什么的人。 自动化没有消灭工作，它创造了新的工作：管理自动化本身。 Dan 把这叫做"每个 Agent 都需要一个人"。 ## 工作会分裂成两种形态 Dan 的预测是：未来一年内，大多数人的工作方式会朝两个方向同时演化。 第一种：公司共用一个超级 Agent。 不是每个人一个私人助理，而是整个公司共用一个 Agent，挂在 Slack 里，所有人都能调用。 Shopify 已经有了，Ramp 也有了。 Dan 最初以为每个人都会有自己的私人 Agent，像《黄金罗盘》里每个人肩上的精灵，是灵魂的一部分。 > 黄金罗盘一口气解读版 https://www.bilibili.com/video/BV156421c74o/ 他对这个图景着迷了很久，然后彻底改变了看法。 原因很简单：Agent 需要有人照料它。 OpenClaw 刚出来的时候，Every 所有人都兴冲冲地设置了自己的 Agent，然后一个个放弃了。 因为它会坏，要 SSH 进服务器，要不停地调整，大多数人坚持不了多久。 一旦没人关心它在做什么，它就会悄悄变得没用。 所以现实的路径是：先有一个公司级别的通用 Agent，由专人负责维护，再随着模型变得更可靠，逐渐向下分裂出团队级别、个人级别的 Agent。 这个专门负责维护 Agent 的人，Dan 叫他"前沿部署工程师"，Every 内部已经有这样的岗位了。 > 前沿部署工程师模式（Forward Deployed Engineer，FDE）起源于Palantir，其核心在于通过“驻场工程师+业务专家”的协同模式，将技术能力与业务需求深度融合. 第二种：Codex 或 Claude Code 成为新的工作操作系统。 这是 Dan 更兴奋的部分，也是更难一句话说清楚的部分。 他现在处理邮件的方式是：让 Codex 打开内置浏览器，把所有邮件聚合到一个页面，然后他对着屏幕说话。 "这封律师的问题，去把过去四年的文件整理成报告发过去。" Codex 就去做了。 他已经连续 10 天保持收件箱清零，这对他来说是从没有过的事。 写文章也一样。 他在 Codex 的内置浏览器里打开 Proof，Codex 能看到他在写什么，他也能看到 Codex 在做什么，两者实时协作。 招人也是，他想找一个在 General Assembly 做过技术教育、现在又对 AI 感兴趣的人，直接跟 Codex 说。 然后他就做别的事了，回来发现 Codex 找到了一个完全符合条件的人，还在 Twitter 上关注了他。 Dan 直接发了私信，约了顿饭。 过去我们把 AI 嵌进 SaaS 工具，未来是把 SaaS 工具放进 AI Agent 里跑。 他在 Codex 里用 Proof，用的是他自己的 token，不是 Proof 这个产品的 token。 SaaS 厂商不需要烧钱堆 AI 功能，用户把 AI 带过来，SaaS 只需要让自己对人和 Agent 都友好就够了。 利润率反而可能回升。 ## CLI 时代已经结束了 Dan 说得很直接：CLI 的时代过去了，我们把它速通了。 Claude Code 火起来的时候，很多人以为是终端命令行的魔力让它好用。 Dan 认为这个判断是错的。 真正的原因是 Agent 在本地机器上有完整的访问权限，以及网上有大量关于如何使用终端的内容，让模型学得很好。这和 CLI 本身没什么关系。 Every 内部，大多数技术人员已经不把终端当主要工作界面了。 偶尔还会切进去，但主战场是 Codex、Claude Code、Cursor 这些有真正界面的工具。 GUI 本来就是为了让人更舒服而发明的，这个逻辑没有变过。 ## SaaS 不会死，Agent 会给它带来更多用户 Dan 说他现在会买 SaaS 股票。 大家都在说 Agent 会让人绕过 SaaS，直接用 AI 干活。 但 Dan 的观察是反过来的：Agent 不会替代 SaaS 的用户，它会成为 SaaS 新的用户。 Every 内部人人都用 Codex 和 Claude Code，但他们的 SaaS 支出比去年还高。 因为 Agent 在用 SaaS，大量的 Agent，高频次地调用。 需求在爆炸，不是萎缩。 他还提到一个细节：Every 的 Proof 是开源的，用户遇到问题，不是自己发邮件给客服，而是他们的 Agent 直接发一份 bug 报告，里面有精确的复现步骤，有对代码库的分析，直接变成 GitHub issue，然后 Every 的 Agent 去修。 这个闭环，比任何人工客服流程都快。 对 SaaS 公司来说，真正需要做的事情变了：不是把 AI 塞进自己的产品，而是让产品同时对人和 Agent 友好，两者能在同一个界面上协作，各自看到对方在做什么。 ## PM 和设计师，迎来最好的时代 Dan 对这两个角色极度看好。 Marcus，PM 出身，之前在 Axios 负责写作产品，带大团队做到了几千万 ARR。 后来他休息了一年，专门学会了用 Cursor。 现在他在 Every 负责写作应用 Spiral，是团队里出货最快的人之一。 Dan 说，哪怕一年前，他们也没办法安排 Marcus 做这个工作，因为那时候模型还不够好。 但现在，Marcus 的产品感和用户洞察，配上足够好的编程模型，变成了一种超强组合。 他不需要组织一整个团队来实现自己的想法，他直接去做。 设计师也一样。 以前最大的痛苦是：想到了一个绝妙的交互，工程师不想做，或者做出来不是那个味。 现在他们可以自己发 Pull Request，自己把想法变成现实。 而且，当所有人都在用 vibe coding 批量生产千篇一律的界面时，真正懂审美、懂交互的设计师反而更值钱。 能让东西看起来不像 AI 做的，本身就是一种稀缺能力。 ## AI 不会让你失业，但不用 AI 会 Dan 的判断是：大规模失业不会发生。 那些被归因于 AI 的裁员，大多数是过度招聘的修正，AI 只是一个方便的借口。 但这不意味着可以躺平。 他给出的建议只有一条，叫"骑上（驾驭）模型"。 不是因为 FOMO，不是因为害怕，而是因为好奇。 每次有新模型出来，把它用在你真正在乎的事情上。 哪怕上次试过不行，这次再试一次看看。 他自己就是这么做的，GPT-5.5 出来，他把高级工程师基准重新跑了一遍，从 30 分跳到了 62 分。 他还说了一件让人意外的事：AI 的真正前沿不在旧金山，而在每一个把 AI 用在真实工作场景里的人那里。 硅谷的人在造它，但不一定知道怎么用好它。 每次新模型出来，你是世界上最早一批发现它能做什么的人之一。 Every 在布鲁克林，不在硅谷。 但 Dan 觉得他们比大多数硅谷公司都更靠近未来，原因只有一个：他们把所有工具都真的用在真实的工作上。 这是他给出的最后一个建议：别争论 AI 会不会改变世界，去找一件你真正头疼的事，试着用 AI 解决它。 当你第一次感受到"这也行？"的那一刻，你就不需要别人再来说服你了。

译Every公司CEO Dan Shipper指出，全员使用Codex和Claude Code的公司员工数反而翻倍，揭示了AI增强工作而非替代人力的悖论。他设计的“高级工程师基准测试”显示，人类得分85-90分，而AI模型平均仅约30分，GPT-5.5最高也仅达62分。核心问题在于AI能解决已定义的问题，却无法主动识别问题需要被重新定义。他预测未来工作将分裂为两种形态：一是公司共用由专人维护的超级AI智能体；二是Codex或Claude Code等AI工具成为新的工作操作系统。他认为这不会导致大规模失业，而是要求每个人都学会“驾驭模型”，将AI用在真实工作场景中。

向阳乔木@vista8 · 5月28日61

这个访谈太好了，身边很多朋友的想法被验证。 1. AI越强，人越忙，Every过去一年员工翻倍。 2. AI 自动化创造了新工作：管理自动化。 3. 每个Agent都需要一个人照料。 4. 真正跑起来的模式是全公司共用一个Agent，专人维护，以后再分化个人Agent。 5. CLI时代已经结束了，GUI才是主战场。 6. SaaS不会死，Agent会给它带来更多用户，Dan现在会买SaaS股票。 7. AI嵌进SaaS是错误方向，应该反过来 8. . PM和全栈设计师迎来最好的时代 9. AI只是裁员借口，是过度招聘的修正。 大规模失业不会来，但不用AI的人会被用AI的人替代，这两件事不矛盾。

译观点认为，AI越强，人的工作量反而越大（如Every公司员工翻倍）。AI自动化创造了管理自动化这一新工作，且每个智能体都需要专人照料。实践中，更可行的模式是公司共用一个智能体，由专人维护。CLI时代结束，GUI是主战场。SaaS不会消亡，反而会因智能体获得更多用户。将AI嵌入SaaS是错误方向，应反向进行。产品经理和全栈设计师将迎来最好时代。AI只是裁员借口，是过度招聘的修正。大规模失业不会发生，但不会使用AI的人将被使用AI的人替代。

AYi@AYi_AInotes · 5月28日52

一个地图截图+手绘路径， 就能生成这么流畅、物理感强的无人机POV航拍视频， 相比seedance、Kling，Google Omni最擅长的应该就是这种精确的相机控制，空间理解、世界模型的真实感

向阳乔木@vista8 · 5月28日58

好久没听到MCP了，据说新的版本7.28号发布。 有几个Feature还挺关键： ① 服务器能下发 HTML 界面让用户交互了 ② 长任务有了正式的管理机制 ③ 授权更严，安全性更好
 现在你还在用的刚需 MCP 是啥？我感觉几乎没有了

译MCP协议新版本将于7月28日发布，包含几个关键特性：服务器可向用户下发HTML界面进行交互、为长任务提供了正式的管理机制，以及更严格的授权以提升安全性。作者在推文中询问社区目前仍在使用的“刚需”MCP是什么，并表示自己感觉几乎没有了。

meng shao@shao__meng · 5月28日17

豆包大学 👩‍🎓 真的，豆包办学、办厂吧，你们从小养起来的用户，你们得管啊 😂

译豆包大学 👩‍🎓 真的，豆包办学、办厂吧，你们从小养起来的用户，你们得管啊 😂 [引用 @BoxMrChen]：家人们我要上北大了

向阳乔木@vista8 · 5月28日69

这个AI编程辅助插件有意思：Plannotator AI生成技术文档和方案后，你说用Plannotator标注下。 文档会发到本地浏览器界面，在网页里能批注、删除、编辑替换 AI 给的方案。 文档还能分享给同事，大家一起Review标注问题。 确定没问题了，点击Approve执行。 支持Codex、Claude Code、PI、Gemini等所有工具。 对用 Cli 编程的人来说，大段技术方案文档，用网页来仔细查看，像飞书文档一样划线点评，再交给AI执行。 这样感觉更方便、更靠谱。 安装指令见评论区

译AI编程辅助插件Plannotator允许用户在AI生成技术文档后，通过本地浏览器界面进行协作批注、编辑替换。文档可分享给同事进行Review，确认后点击Approve执行。该工具支持Codex、Claude Code、PI、Gemini等所有CLI编程工具，提供了像飞书文档一样的划线点评体验，让AI生成的方案能被仔细查看、修改和确认。

向阳乔木@vista8 · 5月28日71

如果你不会写 Agents.md ，可以直接抄作业。 或把高手的Agents 内容粘贴给你的Codex或Claude Code。 让学习其中有价值的内容，合并到自己的Agents文件。 比如有几条就很实用： ① 当用户纠正、反驳、表达不满，或本次任务暴露出可复用教训时，完成当前任务后提出一条精简规则更新建议。 先判断作用域：全局、项目或不沉淀；提出 diff，等用户确认后再改。 ② 说话直接，不奉承。不同意时给具体理由；不确定的技术事实要验证或明确说不知道，不能编造模型名、API、CLI 参数、环境变量或版本信息。 Agent 文件地址见评论

译本文介绍了为AI智能体（如Codex、Claude Code）编写指令文件（如Agents.md）的一种实用方法。核心建议是直接复制高手的Agents文件内容，粘贴给工具，让其学习并合并有价值的部分。文中强调了两个关键实践：一是当用户纠正问题时，应提出精简的规则更新建议，并区分作用域；二是要求智能体说话直接，对不确定的技术事实必须验证或明确表示不知道。

Berryxia.AI@berryxia · 5月28日33

这个抠像效果看着不错，动态人物都识别的很干净啊，这样以后做抠像什么的真的岂不是爽死了。

Berryxia.AI@berryxia · 5月28日41

AI Native的公司竟然都已经完全Agent化了？ 是夸大还是真实如此？ 50百万人在用自然语言造软件，却一行代码都没写过。 这就是Replit + Claude正在发生的真实故事。 Michele Catasta 16岁时就立志要让每个人都能轻松创建软件，今天Replit已经让5000多万人通过自然语言在平台上构建真实应用。 他们和Claude的合作紧密到新模型一发布，当天就能上线新版Replit Agent。 编程的门槛彻底消失了，普通人只要用对话，就能把脑子里的想法变成能跑的网站、App和工具。 这才是AI真正改变世界的样子：不再是取代程序员，更像是让“不会写代码”的人也能成为创造者。

译Replit平台与Claude深度合作，新模型发布当天即可上线新版Replit Agent。该平台已让超过5000万人通过自然语言构建真实应用，实现了用对话代替编码。Replit总裁Michele Catasta早在16岁时就立志让软件开发对所有人开放。这一合作模式展示了AI Native公司完全Agent化的趋势，让非程序员也能成为软件创造者。

SemiAnalysis@SemiAnalysis_ · 5月28日57

Finding Miscompiles for Fun, Not Profit Or: You don’t need access to Claude Mythos to spend $10,000 in an afternoon https://newsletter.semianalysis.com/p/finding-miscompiles-for-fun-not-profit..

译寻找编译错误：乐趣，而非利润 或者：你不需要访问 Claude Mythos，也能在一下午花掉 10,000 美元 https://newsletter.semianalysis.com/p/finding-miscompiles-for-fun-not-profit..

SemiAnalysis@SemiAnalysis_ · 5月28日59

AGI ALERT 🚨 : 63% of sessions do not use sub-agents at all, while 25.9%  use 1-5 concurrent sub-agents. 9.8% of sessions use over 5+ parallel subagents. By using parallel subagents, it can speed up aa time to finish a task without requiring any more HBM bandwidth.

译AGI ALERT 🚨：63%的会话完全不使用子智能体，而25.9%的会话使用1-5个并发子智能体。9.8%的会话使用超过5个并行子智能体。通过使用并行子智能体，可以在不需要更多HBM带宽的情况下加速完成任务的时间。

Chubby♨️@kimmonismus · 5月28日70

There is a striking tension between Chris Olah’s remarks and Dario Amodei’s recent framing. Olah says frontier AI labs operate under incentives that can conflict with doing the right thing and therefore need serious external moral scrutiny. Amodei, meanwhile, seems to be moving from “AI may wipe out large parts of white-collar work” toward a more market-friendly story about productivity gains, job transformation, and Jevons-style optimism - a narrative that also happens to sound much better on the road to an IPO.

译文本指出AI领域存在核心张力。Anthropic联合创始人Chris Olah主张前沿AI实验室需要严肃的外部道德审查，因其激励可能与“做正确的事”冲突。与此同时，Anthropic CEO Dario Amodei的叙事正从“AI可能消灭大量白领工作”转向更市场友好的生产力提升与工作转型论述（如杰文斯悖论）。然而，Yale Budget Lab的跟踪数据显示，自ChatGPT发布以来，美国劳动力市场职业构成无明显变化，AI暴露岗位的失业并未加速。因此，当前AI能力曲线与实际就业数据之间的差距可能比以往更大，这构成了讨论的起点。

meng shao@shao__meng · 5月28日68

2026 年面向生产环境 AI Agent 的评估指南 Agent 评估 ≠ 实验室 benchmark Agent 评估 ≠ chatbot / RAG 评估 https://www.howtoeval.com/ 看两个关键概念：Benchmark-maxxer vs. Floor-raiser Benchmark-maxxer（刷能力上限） · 让专家用户更强 · 用于 Cursor、Claude Code、Codex 等场景 · 抽象测试集、能力分数 Floor-raiser（抬可靠性下限） · 让普通用户敢用、敢信 · 用于客服、银行、医疗等自主 Agent · 读真实 trace、找致命失败模式 完整工作流（作者主张的闭环） 上线前摸底 → 离线 code-aware eval → 上线后读日志 → 分类/修复 → 回归测试 → 再上线 值得重视的洞见（与业界共识一致的部分） 1. Floor raising = Hamel Husain 式的 error analysis：先读真实交互，找「最后成功一步」和「第一次真失败」，再修模式而非个案。 2. Agent eval ≈ E2E 测试：和 OpenAI macro evals、Sentry vitest-evals 方向一致。 3. Eval 套件应是「拒绝复发的记忆」，不是覆盖想象的巨型测试集。 4. 轨迹可观测性在模型越来越「黑箱 agentic」时会更重要；未来 harness 可能坍缩进模型，端到端 + 生产监控会更主导。 5.「我不知道」是 floor-raising 的低成本杠杆——对替代人类的产品，信任 > 炫技。 值得提炼的五个观点和经验 · 先选目标：刷上限还是抬下限——多数产品 Agent 该选后者。 · 抬下限 = 读真实失败，AI 可帮忙聚类 trace，但分类逻辑要人定。 · 离线 eval 必须 code-aware、跑真路径，像单元/E2E 测试，不像 prompt 打分。 · 上线后按流量升级：stumble → issue → signal → experiment，别跳步。 · 闭环：真实失败 → 少量高信号回归 → 修 → 在线验证；别让 eval 套件变成没人看的博物馆。

译本文指出，评估面向生产环境的 AI 智能体，应与实验室 benchmark 及聊天机器人/RAG 评估严格区分。核心是确定评估方向：针对 Cursor、Claude Code 等工具的 Benchmark-maxxer，旨在刷能力上限；针对客服、银行等自主智能体的 Floor-raiser，旨在抬高可靠性下限。指南推荐一个工作闭环：上线前摸底、离线代码感知评估、上线后日志分析与修复。总结的五个关键经验包括：多数产品应优先抬下限、评估需基于真实失败案例、离线评估需代码感知、按流量分阶段升级，以及让评估套件成为防止问题复发的“记忆”。

meng shao@shao__meng · 5月28日42

我受够了跟 AI /假人对话 ！！ 我受够了和 AI 说话。我想和真人说话。但即便对面是人，他们也会把我的问题转给 AI，再把答案转给我。 太 TM 有同感了，作者举得三个例子，不能说有些感觉，只能说，深有同感，简直和我的感觉一模一样！ 1. GitHub 上的「真人回复」 作者在 GitHub 发现传播恶意软件的仓库，先问 AI 该怎么办，得到毫无用处的答案。于是自己在 GitHub 开了讨论帖。 有人回复——内容和 AI 刚才给的一字不差。作者指出后，那条评论被删。又有人回复——还是同一段 AI 答案 😄 2. 老板的 ChatGPT 截图 作者在公司做开发，向老板问一个具体业务问题。老板发来一张 ChatGPT 回答的截图。 作者说：这和我的问题无关，而且内容全是错的。一分钟后，老板又发来另一张 ChatGPT 截图。 老板显然没看 AI 写了什么，只是截图、转发——「回复」这个动作本身就算交差了。 3. Reddit 私信里的 AI 有人在 Reddit 就作者的帖子私信他。作者回，对方再发，作者再回。来回几轮后，作者才意识到：对面很可能是一个 AI agent。 https://orchidfiles.com/im-tired-of-ai-generated-answers/ --- Bobus --- X 的评论回复里也满了 AI，没有任何有效内容的 AI，让人觉得看评论，像是在翻垃圾堆，我想看的评论反而被冲掉了，相信真人看到这么多 AI 垃圾，也很难有想打字评论的欲望了吧？！ 都说 X 只有 30 人，多么多么 NB，产品总监也在 X 上充当判官，各种指出别人在制造垃圾，封禁账号或停止创作者分成，可这么明显的 AI 回复和那种机器人回复，这么难处理吗？还是说就不想处理？

译本文反映了人们对AI生成的低质回答侵蚀真实人际沟通的普遍厌倦。文章通过三个场景具体说明：GitHub讨论中出现与AI完全相同的敷衍回复；公司老板直接转发ChatGPT截图作为答案；Reddit私信沟通中发现对方是AI智能体。作者及评论者批评了X平台上AI垃圾评论泛滥，淹没了有效讨论。整体表达了当前AI工具被滥用以“完成回复动作”而非提供实质帮助的现状。

ginobefun@hongming731 · 5月28日66

http://x.com/i/article/2059794481965408257 # BestBlogs 早报 · 05-28｜Claude Code 路径、分布式 RL 训练、SaaSpocalypse 在线阅读和收听：https://www.bestblogs.dev/explore/brief/2026-05-28 今日精选聚焦 AI 编程工具的「引擎室」：Anthropic 设计负责人 Megan 亲述 Claude Code 如何从 12 人 CLI 实验起步，在一年内拿下 51% 市场份额；Cursor 与 Fireworks 公开 Composer 2 分布式 RL 训练内幕，揭示从应用包装层到自训练基础模型的工程路径。与此同时，一篇关于「SaaSpocalypse」的深度文章正面拆解：当 Agent 直接调 API、绕过 SaaS 界面层，谁会最先倒下，Software 3.0 时代工程师的角色又将如何重写。 ## 导语 2026 年 1 月，美国软件股单月暴跌 15%，华尔街称之为「SaaSpocalypse」。同一时期，Claude Code 悄然完成了另一种意义上的颠覆：首年营收 $25 亿、编程工具市场份额 51%。两件事并非偶然同步——它们共同指向同一个转折：AI 正从工具进化为基础设施，从辅助进化为主导。 今天的早报把这个转折的三个截面放在一起：产品路径​（Claude Code 如何被设计出来）、训练工程​（Composer 2 如何被炼成）、产业冲击（SaaS 中间层如何被瓦解，工程师角色如何迁移）。读完这三篇，你会对「AI 原生」有更立体的感知，而不只是一个标语。 速览板块还覆盖了 ESMFold2 在蛋白质预测领域的「苦涩教训」时刻、Lyft 用 LangGraph 把 Agent 开发周期从半年压缩到数周的工程实践、Vibe Coding 遭遇安全清算的真实案例，以及 Airtable、Fireworks 的基础设施故事。 ## 精讲一：Anthropic 设计负责人谈 Claude Code：一年拿下 51% 市场份额的产品路径 Claude Code 的起点比大多数人想象的低得多。2024 年，Anthropic 内部一个 12 人团队决定试验一个想法：把 Claude 接入命令行，直接操作文件系统。第一个原型配置需要整整一个小时，距离所谓「产品」还差得很远。 但早期内部演示视频在 Slack 流传后，团队意识到方向是对的。接下来三个月，他们专注于三件事：打磨用户体验、消灭平台 Bug、大量内部使用积累信心。这种「先内部高强度使用，再对外发布」的节奏，成为 Claude Code 后续迭代的基本范式。 什么让 Claude Code 跑得这么快？ Anthropic 设计负责人 Megan 在 Product School 的分享里，把这归结为三个机制： 第一是流动 Pod 结构。传统产品开发里，设计师做设计、工程师写代码、PM 写 PRD——边界清晰但也僵硬。Claude Code 团队打破了这层边界：设计师会直接把代码推到生产环境，工程师主动做用户体验决策。Pod 的规模和构成随功能需求弹性调整，通常是 3 至 5 人，没有固定比例。这种跨职能的流动性，在 AI 加速迭代的环境下释放了显著的执行弹性。 第二是把质量关口移到运行时。当 AI 让代码生成速度提升 10 倍，传统的 PRD、静态 Mockup 等质量控制环节就成了瓶颈。Anthropic 的解法是把验收标准前移到真实运行行为：团队内部高频部署原型，监控实际使用模式，用运行时数据而非文档勾选来决定是否推进。这个方法在 AI 原生组织里有深刻意义：它不是「更快写代码」，而是「把反馈回路压缩到极致」。 第三是Bottom-up 企业采用。Claude Code 没有走自上而下的销售路线，而是从工程师个人使用开始，自然扩散到团队，再渗透到组织层面。这种采用曲线在金融基础设施、零售等高度监管行业也同样奏效——先赢得工程师，再赢得决策者。 度量体系的迁移 Megan 特别强调了一个度量迁移：从 Token 用量转向用户留存与管道营收。这看起来是小事，背后却是产品哲学的转变——衡量 AI 工具价值的标准，从「有没有人用」变成了「用了之后会不会留下、会不会推动业务增长」。 管理层须亲自上手、持续操刀 Repo，不是作秀，是为了在迭代加速的环境里保持对产品的真实感知。这条原则在 AI 原生组织里具有普遍价值：领导者的直接参与，是维持迭代弹性的结构性保障，而不仅仅是传递信号。 为什么值得深读 这篇内容不是产品方法论的泛泛总结，而是一个具体产品在极速增长过程中形成的操作手册。流动 Pod、运行时质量门控、Bottom-up 采用——这三个机制彼此咬合，缺一不可。如果你在思考 AI 原生团队该怎么运转，这是目前能找到的最具体的参照之一。 值得额外关注的是 Anthropic 的女性领导力比例：CPO、工程负责人、平台产品负责人、平台工程负责人和总裁均为女性。这不是一个单独的事实，而是组织文化的折射——一个真正重视多元视角的组织，往往在打破固有边界（比如「设计师不写代码」）这件事上也更有行动力。 阅读建议：结合精讲二一起看。Claude Code 是产品侧的 AI 原生实践，Composer 2 是模型训练侧的 AI 原生实践，两者共同勾勒出「AI 原生」的两种形态。 阅读链接：Anthropic 设计负责人谈 Claude Code：一年拿下 51% 市场份额的产品路径 ## 精讲二：Cursor 与 Fireworks 如何用分布式 RL 基础设施训练 Composer 2 编码智能体 大多数 AI 编程工具把通用 LLM 套上提示词工程就算完事。Cursor 走了一条完全不同的路：从头训练一个专门为软件工程优化的模型，并且为此搭建了一套异步分布式 RL 基础设施。 为什么要自己训模型？ Federico（Cursor 研究负责人）给出了一个直观的类比：LLM 的参数空间就像一块存储介质，位数有限。通用大模型把这些位分配给数学、多语言、常识推理等各类能力；Cursor 的做法是把所有位都集中到软件工程这个窄域，用专注换效率。 结果是：更小、更低延迟的模型，在代码编辑任务上超过了比它大得多的通用模型（如 GPT-4 Opus），运行成本低一个数量级。这是 Rich Sutton「苦涩教训」的一个有意义的反例——在足够窄的领域，专注的数据维度比纯粹的规模更有效。 Composer 2 的双轴训练路径 Composer 2 的训练分两个阶段： 第一阶段是持续预训练，以 1 万亿参数 MoE 模型 Kimi 2.5（30B 活跃参数）为基础，大规模运行代码和 web token 的下一个 token 预测，拓宽模型的基础分布，编码基础库知识和工程模式。 第二阶段是大规模强化学习。模型进入主动 RL 循环，在 Cursor 环境框架内执行工具调用、获得奖励信号，逐步学会在真实代码编辑场景中做出正确决策。与预训练「展示如何写代码」不同，RL 阶段的目标是「学会在工具和结果中导航」。 异步流水线：让 GPU 全程满负荷 标准 RL 管线的一个固有问题是计算空转：推理阶段训练器空转，权重更新阶段推理引擎空转。Cursor 与 Fireworks 合作构建的异步流水线像一条持续运转的工厂产线：推理 Rollout 和权重更新同步进行，GPU 全程满负荷，消除了昂贵计算资源的空转损耗。 三个工程难题与解法 除了异步流水线，团队还公开了三个关键工程决策： - Delta 权重压缩：在分布式训练中，每次权重更新都需要在全球节点同步，数据量巨大。Delta 权重压缩只传输权重的变化量，把全球同步流量降低了约 20 倍。 - Router Replay Tracking：稀疏 MoE 架构（Sparse Mixture of Experts）的一个棘手问题是数值漂移——不同专家路由的使用频率不均，导致训练不稳定。Router Replay Tracking 通过记录路由选择历史来稳定这个过程，保持数值对齐。 - 自摘要上下文压缩：编码智能体在真实工作中会产生超长轨迹，百万 Token 规模的上下文管理是一个挑战。Composer 2 把上下文压缩能力训练成模型的内生能力，而不是外挂规则，让智能体在长轨迹中保持推理连贯性。 一个值得思考的更大问题 Cursor 的路径揭示了一个范式：当模型训练成本不再是天文数字，专注于特定领域的「小而精」模型将会越来越多。通用大模型提供基础能力，垂直专有模型在特定任务上以更低成本实现更高性能。这个趋势在今天的速览里也有印证——ESMFold2 在蛋白质预测上用同样的逻辑实现了对 AlphaFold3 的超越，只是在生物信息领域，通用路线反而是赢家。领域特性决定了什么时候应该专注、什么时候应该通用。 为什么值得深读 这篇不是概念介绍，而是 Cursor 和 Fireworks 工程师级别的实践总结。如果你在做 AI 应用层，这篇帮你理解专有模型训练的真实成本和收益；如果你在做 ML 基础设施，异步流水线和 Delta 压缩是可直接参考的工程方案。 结合精讲三看：Composer 2 展示的是「工程师如何用 Software 3.0 的方式工作」，而精讲三在问的是「工程师的工作本身会被如何改变」。 阅读链接：Cursor 与 Fireworks 如何用分布式 RL 基础设施训练 Composer 2 编码智能体 ## 精讲三：2026：软件的末日、工程师的陨落、平庸的消失 2026 年 1 月，美国软件股经历了一场 2008 年金融危机以来最惨烈的单月跌幅：标普北美软件指数下跌 15%。不是因为业绩崩塌，而是因为华尔街意识到一件事——SaaS 的护城河正在被 AI Agent 从根部挖空。 华尔街给这场抛售起了个名字：SaaSpocalypse，软件末日。 被做空的是哪一层？ 过去二十年，SaaS 的商业逻辑建立在一个前提上：把企业功能打包成操作界面，按席位收取月费。界面即产品，界面即护城河。员工用久了形成肌肉记忆，替换成本极高，这是 SaaS 估值飞涨的核心驱动力。 AI Agent 打破的，正是这个前提。Salesforce CEO Marc Benioff 在 X 上发了一条帖子，语气平静、但意味深长：「所有 AI Agent 都能通过 API 直接访问 Salesforce Headless 360，无需浏览器。」这家靠界面起家的商业帝国，亲手把自己的界面变成了可选项。 逻辑链条是这样的：Agent 绕过 SaaS 界面直接调 API → 界面不再是护城河 → 席位订阅模式失去基础 → 依赖界面习惯维持转换成本的 SaaS 中间层，壁垒被 AI 复制。 📷 但不是所有软件都会死。a16z 的分析框架给出了一个清晰的区分：AI 大幅降低了重建一套系统前 80% 的成本，而剩余的 20%——特殊事项、审批流程、合规要求——仍然是「可用原型」与「真正替代品」之间的分水岭。 被集中做空的，是价值落在「前 80%」的中间层：以数据分发为核心的 Thomson Reuters（单日暴跌 16%）、以流程协调见长的 Atlassian、标准化在线法律服务平台 LegalZoom。它们的共同特征：壁垒恰好集中在最容易被 AI 复制的区域。 而管理财务账目的后台系统、涉及合规审计的数据平台，则属于那难以逾越的「20%」。ERP 的迁移，a16z 把它比作「病人在跑马拉松时做开胸手术」。 软件会变少吗？答案是杰文斯悖论 直觉上，AI 替代软件 → 软件总量减少。但 1865 年的一个经济学规律说了相反的故事：蒸汽机效率越高，英国消耗的煤炭反而越多——效率提升让资源变便宜，催生了大批原本不存在的使用场景，导致总消耗净增长。这就是杰文斯悖论。 Token 正走同一条路。GPT-4 问世时，每百万 Token 调用成本 37.5 美元；两年后，GPT-5 High 降至 3.63 美元，性能却突破人类博士水平。成本下降超过 99%，但 Token 总消耗量呈指数级攀升。OpenClaw 之父 Peter Steinberger 晒出他的账单：过去 30 天，个人级别消耗 6030 亿 Token，单月花费超过 130 万美元。 每一次 Token 价格的下跌，都不只是让现有软件运行得更便宜，而是解锁了一批之前根本不存在的软件。Vibe Coding 让非技术人员能直接把想法变成应用；OpenDesign 把「从 GitHub 链接到完整 slides」这个工作流变为现实——这在两年前根本不存在。 工程师的角色迁移：从写代码到 Software 3.0 文章的结尾是最值得停下来想一想的部分：工程师的角色正从「写代码」迁移向 Software 3.0——设计评估体系与奖励环境。一位干了二十年的资深工程师丢了工作，他说：「我花了五秒钟把所有情绪过了一遍，然后就明白，好吧，我的职业生涯完了。」 平庸的产出正在加速消失，但这不意味着工程师集体消失——而是角色的质变。能设计评估体系、能定义奖励函数、能理解 Agent 的边界和失败模式的工程师，将会更稀缺、更有价值。 协议层：MCP 正在成为新的 USB 接口 文章还深入分析了软件「液化」后的基础设施需求。Anthropic 在 2024 年底推出的 MCP（Model Context Protocol）正在成为 Agent 时代的 USB 接口——一次接入，所有支持 MCP 的 AI（Claude、ChatGPT、Cursor、Copilot 等）均可调用。在 MCP 之前，每让 AI 接入一个新工具都要单独写一套适配代码；MCP 把这件事标准化了。这是软件从「固定形态的产品」变成「按需生成的介质」之后，必须出现的基础管道。 与今日其他内容的关联 这篇文章的论述与精讲一、二构成了一个完整的三角：Claude Code（产品侧 AI 原生）+ Composer 2（训练侧 AI 原生）+ SaaSpocalypse（产业侧 AI 冲击）。三篇合在一起，描述的是同一场变革的不同切面。今天速览中的 Lyft LangGraph 平台、Airtable 语义搜索层、Fireworks 独角兽崛起，也都是这场变革在不同应用层面的具体落地——当你把它们放在这篇文章的框架里，会看到一幅更清晰的全景图。 阅读建议：如果你是工程师，重点看「工程师角色迁移」和「Software 3.0」部分；如果你在做产品或投资，重点看「转换成本光谱」和「杰文斯悖论」部分。文章较长，但论证密度高，值得完整阅读。 阅读链接：2026：软件的末日、工程师的陨落、平庸的消失 ## 速览 ESMFold2：蛋白质领域的「苦涩教训」 BioHub 团队推出开源蛋白质结构预测模型 ESMFold2，在多样化数据上扩展简单的 BERT 类 Transformer，在蛋白质相互作用（尤其是抗体预测）方面超越了 AlphaFold3 等专用模型。这标志着计算生物学迎来了自己的「苦涩教训」时刻——通用架构加海量数据，再次击败精心设计的专用架构。和今天精讲二的逻辑形成有趣对照：Cursor 走专用模型路线赢，但生物信息领域是通用路线赢，背后的关键差异在数据分布和任务边界。Alex Rives 与 BioHub 团队的这次探索，对正在考虑「该专注还是该通用」这个问题的 AI 研究者有直接的参考价值。阅读原文 Lyft 如何用 LangGraph 把 Agent 开发周期从半年压缩到数周 Lyft 利用 LangGraph 和 LangSmith 构建了一个自助式 AI Agent 平台，让运营团队、VoC 负责人和产品经理能够通过提示词和配置独立开发和迭代客服 Agent，无需每次都依赖 MLE 介入。核心架构是路由器型多 Agent 系统：一个元 Agent 作为有状态路由器，用 Command(goto=...) 把请求分发给专用子 Agent，每个子 Agent 并行运行安全检查。LangSmith 负责追踪、仪表盘和 LLM-as-a-judge 评估。结果是 Agent 开发周期从约六个月压缩到数周——这和精讲三「软件液化」的论断高度呼应：当非技术人员能直接配置 Agent，软件开发的边界正在重新定义。阅读原文 VibeSec 的清算时刻 Thoughtworks 全球营销团队在把一个 Vibe Coding 原型扩展到生产环境时，遭遇了两次险情：AI 建议把存储桶设为公开访问（会泄露敏感品牌资产），以及给予过于宽泛的 Token 权限。两次都是人类工程师提出质疑才得以阻止。核心结论：Vibe Coding 加速了原型到产品的路径，但 AI 生成的代码需要确定性的护栏，而不仅仅是更好的提示词，才能达到生产安全标准。这是当下「Vibe Coding 热潮」最值得警惕的真实案例之一。阅读原文 Airtable 如何为 AI 功能构建语义搜索层 Airtable 有一个关键数据观察：任何一周内，75% 的客户数据库都处于空闲状态。这个事实驱动了整套架构决策——选择 Milvus、采用每库分区策略、HNSW 索引加冷热数据分离。当一个分区在内存中时查询响应极快，冷分区可以在秒级内从存储重新加载。这不是「选了哪个向量数据库」的故事，而是「一个数据特性如何决定了一整套工程决策链」的案例，对有类似冷热数据分布的团队有直接参考价值。阅读原文 万字入门 AI Infra：大模型的数学与优化逻辑 从 RMSNorm、Softmax、Causal Mask 到 Sampling，逐层拆解大模型推理中核心操作的数学原理与 Infra 优化逻辑。核心论断：AI Infra 优化的本质是用数学上的等价变换，或对精度的适度妥协，换取更高的硬件利用率。文章从「为什么需要归一化」这个最基础的问题出发，解释 FP16 数值上限 65504 为何会成为工程约束，再一路推导到 Softmax 的数值稳定性技巧和 Causal Mask 的实现选择。不到 5 万字，覆盖从高中数学到 FP16/BF16 精度权衡的完整知识链。适合想从数学和工程两个维度同时理解大模型基础设施的读者，也是今天精讲二 Composer 2 训练工程的极佳知识背景补充。阅读原文 别再盯着 AI Agent 干活：构建运行时上下文引擎 Brandon Walsenuk 认为，可靠的自主编码 Agent 需要「运行时上下文引擎」，而不只是更长的提示词或更多工具权限。他指出了三个常见误区：朴素 RAG 因「搜索满足感」效应导致信息遗漏（Agent 找到第一个看似匹配的答案后就停止探索，错过更完整的技术现实）；单纯连接 MCP 管道解决不了组织知识缺失；给 Agent 更多权限不等于给它更好的判断力。运行时上下文引擎需要理解组织知识、协作关系、权限边界和实时架构冲突，这是一个系统设计问题，而不是提示词优化问题。结合精讲二的 Composer 2 自摘要上下文压缩一起看，两者都在解决同一个问题：如何让 Agent 在长期运行中保持对上下文的准确感知。阅读原文 AI 基础设施新晋独角兽：Fireworks、Baseten、OpenRouter Fireworks 和 Baseten 双双跻身独角兽，OpenRouter 宣布 $113M B 轮，过去六个月周 Token 处理量从 5T 增至 25T。这个数字本身就是杰文斯悖论的实时数据点：基础设施越高效，消耗的 Token 量不减反增。这期 AI 新闻汇总完整覆盖了 AI 基础设施独角兽的崛起，以及 Agent 编排工程、长程推理、模型架构更新和生产工具的最新进展。值得注意的是，Fireworks 同时也是今天精讲二 Composer 2 训练的基础设施合作方——同一家公司在一天内以两种身份出现在今天的早报里，这本身就说明了 AI 基础设施层正在迅速从工具变成关键路径。阅读原文 ## 补充阅读 CodeRabbit 如何用 Claude 构建 Agent 编排系统 CodeRabbit 在生成任何代码之前先运行结构化规划阶段，弥合开发者意图与 AI 输出之间的差距。每周 review 200 万 PR、服务 15,000+ 客户的规模背后，是一套「先规划、再生成」的编排逻辑——规划阶段帮助 Agent 在行动之前理解变更的意图和范围，减少「代码能跑但没做对事情」的问题。这和今天速览里「VibeSec 清算时刻」形成互补：一个说 Vibe Coding 的安全风险，一个说规划层如何系统性地降低 AI 代码生成的偏差。适合正在思考如何提升 AI 代码生成可靠性的工程团队。阅读原文 使用 Codex 构建自我改进的税务智能体 OpenAI 与 Thrive Holdings 合作开发的 Tax AI，把从业者的修正转化为结构化评估目标，让 Agent 自主改进——准确率达 97%，吞吐量提升 50%。核心思路是把生产反馈直接接入评估循环，让改进不再依赖工程师手动推进：从业者的修正 → 归因到具体评估目标 → Codex 生成候选修复 → 回归测试验证 → 工程师审核并关闭循环。这套自改进框架和精讲三「Software 3.0」里「设计评估体系与奖励环境」的工程师新角色高度契合。适合正在思考「Agent 如何自我优化」的团队。阅读原文 使用 LLM 保护源代码安全 Anthropic 六步循环法：威胁建模 → 沙箱搭建 → 漏洞发现 → 验证 → 分类 → 修复。发现漏洞已经可以大规模并行化，瓶颈已转移到验证、分类和修复。截至 2026 年 5 月 22 日，Anthropic 在开源软件中已披露 1,596 个漏洞，其中仅 97 个完成修补——这个数字本身就是现状的真实写照：AI 发现的速度远超人类修复的速度。适合安全团队和关注 AI 辅助安全审计的工程师。阅读原文 Agent Harness Engineering 综述 CMU、Yale、JHU、Virginia Tech、Amazon 联合出品，用 ETCLOVG 七层框架（执行环境、工具接口、上下文管理、生命周期编排、可观测性、验证评估、安全治理）系统梳理 Agent Harness 工程，覆盖 170+ 开源项目。核心判断：Agent 在长任务、真工具、真实环境中失败，往往不是模型不够聪明，而是系统没把它管好。只改工程外壳不改模型，有研究在 coding benchmark 上实现了最高 10 倍提升；固定 GPT-5.2-Codex Agent 通过重构系统 prompt 和加入中间件，在 Terminal-Bench 2.0 上从 52.8% 提升到 66.5%。适合正在把 Agent 从演示推向生产的工程团队。阅读原文 淘天集团「数字 SRE」：AI 主导代码质量治理 从 AI 辅助开发到 AI 主导开发的四阶段演进，淘天集团分享如何让「数字 SRE 员工」自动发现、端到端修复 Blocker 问题，开发者只在关键节点兜底审核并发布兜底。这是国内工程团队把 AI 主导开发落地的少见公开案例：AI 负责语法级修复这类有明确规则的 Blocker，人类保留关键审核节点——这正是精讲三「工程师角色迁移」从「写代码」到「审核和边界设定」的具体实践。阅读原文 DiT 残差流的收敛瓶颈与 DAR 解法 南京大学 LAMDA 与阿里巴巴智能引擎团队提出 Diffusion-Adaptive Routing（DAR），用可学习、时间动态的跨层路由替代 DiT 中固定的残差累加，实现近 9 倍训练加速并提升生成质量。论文发现标准残差路由在深层会出现三类问题：PreNorm dilution（历史累积量越来越大，新层想改变表示须对抗膨胀的主干）、time-agnostic 融合无法适应不同去噪阶段的信息需求、梯度漂移。DAR 用动态路由权重让模型按 timestep 自适应调整跨层信息流。适合关注视觉生成模型训练效率的研究者和工程师。阅读原文 ## 今日阅读路径 时间有限，推荐优先读这三篇： 1. 2026：软件的末日、工程师的陨落、平庸的消失（精讲三）——理解当前产业变局的整体框架，SaaSpocalypse 背后的商业逻辑和工程师角色迁移。这是今天内容的「坐标系」，先读这篇，其他内容会更有定位感。 1. Anthropic 设计负责人谈 Claude Code：一年拿下 51% 市场份额的产品路径（精讲一）——具体、可操作的 AI 原生产品开发手册。流动 Pod、运行时质量门控、Bottom-up 采用，三个机制对任何在思考 AI 原生组织的人都有直接参考价值。 1. VibeSec 的清算时刻（速览）——Vibe Coding 安全风险的真实案例，15 分钟读完，能帮你在下一个 AI 代码项目里提前避坑。 时间充裕的扩展路径： - 精讲二（Composer 2 训练工程）+ 速览「Lyft LangGraph 平台」——从模型训练到 Agent 平台，构建对 AI 基础设施的完整认知。 - 补充阅读「Agent Harness Engineering 综述」——为精讲二和速览「运行时上下文引擎」提供理论框架支撑。

译Claude Code 首年营收 25 亿美元，占据编程工具 51% 市场份额，其成功源于流动 Pod 结构、运行时质量把控及自下而上的采用策略。Cursor 与 Fireworks 合作，基于 1 万亿参数 MoE 模型 Kimi 2.5 训练了专用编码模型 Composer 2，其异步分布式 RL 流水线与工程优化实现了在特定任务上超越大型通用模型。与此同时，“SaaSpocalypse” 现象揭示了当 AI 智能体直接调用 API 绕过 SaaS 界面层时，传统软件中间层正面临冲击。