推文

MedGemma 1.5 是我们为医疗开发者打造的开源模型的重大升级。

全新的 40 亿参数模型让开发者能够构建应用程序，原生且高效地解读完整的 3D 扫描（如 CT、MRI）。我们相信，这在开源医疗通用模型中尚属首次。MedGemma 1.5 还能与 MedASR 良好协同，后者是我们专为高精度医疗听写微调的语音转文本模型。

现在，开发者可以利用这些多模态能力，构建能够服务更广泛地区患者的医疗应用。

Claude 的新功能 Cowork：让 AI 真正帮你干活

Claude Code 本来是给程序员写代码用的，结果大家发现它整理文件、做表格、写报告也很顺手。Anthropic 索性把这套能力包装成了 Cowork，让不会写代码的人也能用上。

【1】Cowork 到底能干啥

你选一个电脑上的文件夹，Claude 就能在里面读文件、改文件、创建新文件。

听起来简单，用起来挺香。比如你下载文件夹乱成一锅粥，让它帮你分类重命名。或者你有一堆消费截图，它能整理成一张 Excel 表。再比如你写了几页凌乱的笔记，它能帮你理顺思路、输出初稿。

和普通对话不一样的是，Cowork 模式下 Claude 更像个真正的助手。你布置任务，它自己规划步骤、一步步执行，中间会告诉你进度。如果你用过 Claude Code，这感觉会很熟悉，因为底层技术是同一套。

【2】还能更强

基础功能只是起点。Cowork 可以接上你已有的连接器，比如 Google Drive、Slack。它还内置了一批技能，能更好地生成文档、PPT 之类的文件。再配上 Chrome 浏览器插件，Claude 甚至能帮你操作网页。

这套设计让工作流变得很丝滑。你不用反复给 Claude 喂上下文，也不用手动把输出转成正确格式。甚至不用等它做完一件事再布置下一件，可以连续丢任务让它并行处理。用 Anthropic 的话说，这感觉不像你一句我一句地聊天，更像给同事留便签。

【3】和 Claude Code 共享技能生态

对 Claude Code 用户来说有个好消息：Cowork 能读取你本地的 CLAUDE.md 文件和自定义 Skills。

我测试了一下，选择工作文件夹后，Cowork 能看到里面的 CLAUDE.md 并按指令执行。我在 Claude Code 里配置的写作风格技能，Cowork 里也能直接调用。技能分两类：Anthropic 官方提供的（docx、pptx、pdf 这些）和用户自己创建的，两类都能用。

换句话说，你在 Claude Code 里攒下的工作流配置可以直接迁移过来。Cowork 不是另起炉灶，是同一套体系的图形化入口。

有个坑要注意：Cowork 跑在 Linux 虚拟机里，而你的 Mac 是 ARM 架构。如果技能依赖 node_modules 或本地特定环境（比如浏览器 cookies、特定架构的二进制文件），就跑不了。我试着调用一个需要运行 nodejs 脚本的图片生成技能，报错了——架构不兼容。纯文本类的配置（CLAUDE.md、写作规范）没问题，涉及本地脚本的技能可能需要额外适配。

【4】安全边界在哪里

Claude 只能访问你明确授权的文件夹和连接器，动作比较大的时候会先问你。但有几件事得提前知道：Claude 可能会误解你的指令，如果你说"清理一下这个文件夹"，它可能真的把文件删了。指令要说清楚。

另一个风险是提示词注入，就是攻击者在网页内容里藏一些指令，试图劫持 Claude 的行为。Anthropic 说他们做了防护，但这个领域整个行业都还在摸索。

这些风险不是 Cowork 特有的，只是很多人可能是第一次用这种更自主的 AI 工具。官方建议：刚开始用的时候谨慎点，别一上来就让它处理重要文件。

【5】现在能用吗

Cowork 目前是研究预览版，只对 Mac 上的 Claude Max 订阅用户开放。Anthropic 想先看看大家怎么用、有什么反馈，然后快速迭代。后面会加跨设备同步，也会出 Windows 版。

这一步到是意料之中，因为 Claude Code 现在已经被用在很多编程意外的领域，但是门槛略高，限制了使用群体是程序员或者懂点技术的用户，而且脚本执行权限会有很多安全上的隐患。Cowork 一下子降低了使用的门槛，通过图形化界面就可以操作，并且也让使用更安全。

现在还是早期版本，能做的事有限，安全机制也在完善中。但如果你是 Max + Mac 用户，值得一试。

MIT 研究人员提出了递归语言模型。

请记住，到 2026 年，你会频繁听到它的名字。

这有什么意义呢？

试想一下，如果大语言模型能处理的输入长度，是其上下文窗口的 100 倍，会怎样？

上下文长度是一个硬性约束。

你可以通过修改模型架构来扩展它，但总有一个上限。大多数现有方法要么试图在有限窗口内塞入更多信息，要么对超出的部分进行压缩。

这项新研究另辟蹊径。与其正面硬刚上下文限制，不如通过巧妙的程序逻辑来绕过它。

递归语言模型将超长提示词视为一个外部环境。模型可以审视整个提示，将其分解为多个部分，然后在各个片段上递归地调用自身进行处理。这实质上是在推理阶段，通过递归来实现对超长上下文的处理能力扩展。

其核心思想是：不必强求一次性通过注意力机制处理所有信息，而是让模型通过多次递归调用，策略性地对信息进行分区和处理。

结果令人印象深刻。RLMs 成功处理了超出模型原始上下文窗口两个数量级的输入。一个仅有 8K 上下文窗口的模型，可以有效应对长达 800K 标记的内容。

但真正令人惊讶的是：即使对于那些原本就能放入上下文窗口的较短提示词，RLMs 在四项不同的任务上也显著优于基础 LLM 和常见的其他长上下文处理方案。

这暗示了一个有趣的可能性：

也许，即使技术条件允许，对整个输入进行顺序注意力计算也并非总是最佳策略。对于某些任务而言，程序化的分解和递归处理可能在本质上更为优越。

与其他的长上下文处理方法相比，该方法的单次查询成本相当甚至更低。

上下文长度的限制约束了智能体的能力边界。要处理整个代码库、长篇文档或冗长的对话历史，通常需要额外的变通方案。RLMs 提供了一种通用的推理策略，有望将上下文限制从一个“硬约束”转变为“软约束”。

昨晚社团全球首次线下聚会，在深圳

从长沙飞来的、从江门开200公里赶来、从广州、东莞、香港过来的。
30个陌生人，热情洋溢的谈论AI编程。

没一个人会写代码。

卖手机壳的、做跨境电商的、金融to B的、待业带娃的产品经理、香港私募的投资经理……

我建的AI编程社团第一次线下聚会，来的人比我想象的更杂，也更狠。

做手机壳的哥们说，有个电商老板问他：“Claude Skills能帮我干什么？”
他答不上来，但“感受到了巨大的机会”。

机会还没被定义清楚，所以才是真机会。

做金融to B的大哥更直接。
他已经在研究怎么把skills固化成解决方案，
“这东西能卖给客户啊，金融机构太需要这种能力了。”
他说得特笃定，像是已经看到了订单。

香港私募女生一个人负责9个国家的投研，
天天被投资人追着问各种问题。
现在用Skill大幅减轻工作量，
聊到兴奋处直接问我：
“你能不能跟我一起推？金融领域遍地都是这种需求。”

我说，不止金融。
各行各业都在涌现，拿着前沿技术，结合你的专业能力，机会会找上门。

聚餐到一半，有人喊“跟老师合个影”。
然后一桌一桌的人起身，端着酒杯过来：“我们这桌一起合个照。”

那一刻我突然意识到：
他们之间已经自发形成了连接。

桌与桌之间，思考在流动，灵感在碰撞，小团队在自然涌现。

小米当年的崛起，就是让米粉参与产品开发，
让信息、资源、创意在社群横向交互中被激发。

而我看到的是：所有人都不会写代码，所有人都在用AI解决问题。

AI编程不是工具，是武器。

据预测，2026年50%的知识工作者会用AI处理30%的日常工作。

但我觉得
当卖手机壳的开始感受到“巨大机会”，
当金融to B的开始琢磨“怎么卖给客户”，
真正的变革才刚刚开始。

散场时已经晚上0点40。
我站在餐厅门口，看着一群一群的人边走边聊，消失在深圳的夜色里。

想起一句话：

人民群众是汪洋大海。我们要做的，就是投身其中。

欢迎加入人民群众！

Midjourney v8 的训练已完成约 50%，预计本月交付，并将与网页应用的一次重大重新设计一同到来。

本次更新将带来以下提升：更快的创作速度、风格改进、增强的编辑功能、全新的简化界面等。

具体预期如下：
> 提示词准确性大幅提高
> 身体和手部渲染效果显著改进
> 比 v7 更灵活且更容易迭代
> 改进的图像引用（OREF）与编辑功能
> 文本渲染：短文本已解决，段落级渲染正在开发中
> SREF 与个性化代码将保持兼容
> 风格创建器，支持动态渲染与色彩分离
> 全新的增强编辑功能将在 v8 发布后不久推出

设计改进方面：
> 与 v8 同步推出的重大重新设计
> 功能更强大、界面更简化
> 创作工作流程显著提速
> 将提供强大的移动端体验

备注：
v8 将是 Midjourney 历史上生命周期最短的模型。新的简化架构将支持更快的迭代速度，后续模型（v9）预计在 v8 发布后的 1 至 4 个月内推出。

跟着 Anthropic 博客和文档，学习「Agent Skills」构建的最佳实践

重新阅读了 Anthropic 工程博客和 Agent Skills 文档：
1. anthropic.com/engineering/eq…
2. platform.claude.com/docs/en/agents…

在这两篇文章中，找到了 Agent Skills 构建的这几个关键原则和最佳实践，咱们是基于 Claude 来解读的，但同样适用于其他 AI Agents，咱们一起看看。

先说结论：一个优秀 Skill 的“标准画像”
· 名字（Name）：使用动名词（如 processing-pdfs），清晰明确。
· 描述（Description）：用第三人称（如 "Processes Excel files..." 而不是 "I can help you..."），并包含具体的触发关键词。
· 核心文件：一个精炼的 SKILL. md 作为“中控台”，若干个 .md 作为“专业手册”，以及一组 .py 或 .sh 脚本作为“精密工具”。

1. “极简主义”：只提供 Claude 不知道的信息
Claude 本身已经拥有庞大的知识库，上下文窗口是昂贵的公共资源。
· 不要过度解释：如果 Claude 已经知道什么是 PDF 或 Git，不要在技能中解释这些基础概念。
· 挑战每一行文字：问自己：“Claude 真的需要这段解释吗？”、“这段话的 Token 成本是否换回了足够的价值？”
· 对比示例：
  · 反面（啰嗦）：“PDF 是一种便携式文档格式，要提取它，你需要安装 pdfplumber 库...”
  · 正面（专业）：直接给出代码示例 import pdfplumber; ...。

2. 动态调节“自由度”：给 Claude 合适的约束
根据任务的性质，决定给 Claude 多少发挥空间。
· 高自由度（文字指令）：适用于有多种路径可通向成功、需要根据上下文做决策的任务（如：代码审查、内容润色）。
· 中自由度（带参数的脚本）：适用于有固定模式但需要灵活配置的任务（如：生成周报、数据分析）。
· 低自由度（固定脚本）：适用于极度脆弱、不容出错的任务（如：数据库迁移、系统部署）。
  · 金句：像对待机器人一样——在悬崖边的窄桥上，给它死指令（低自由度）；在开阔的草原上，给它大方向（高自由度）。

3. 利用“渐进式披露”结构化你的文件夹
不要把所有东西都塞进一个 SKILL. md，这会迅速耗尽 Token。
· 保持扁平化：官方建议参考链接只保留一层深度。即 SKILL. md 直接指向 reference. md，不要出现 SKILL. md -> A. md -> B. md 的深层嵌套。
· 模块化拆分：
  · 如果技能涉及多个领域（如财务、销售），将它们拆分为 finance. md 和 sales. md。
  · 在 SKILL. md 中做一个“目录”，Claude 只有在处理财务问题时才会去读取财务相关的详细文档。
· 长文档技巧：如果一个参考文件超过 100 行，务必在顶部加一个目录。这能确保 Claude 即使只是部分预览文件，也能看到全貌。

4. 强制执行“验证循环”
这是提升 Agent 成功率最有效的工程手段。
· Checklist 模式：让 Claude 在执行复杂任务前，先拷贝一份清单到回复中，每完成一步打一个钩。这能防止 Claude “偷懒”跳过关键步骤。
· “运行 -> 校验 -> 修正”：在技能中包含验证脚本。
  · 示例：修改 XML 文件后，强制 Claude 运行一个 validate. py。如果报错，Claude 必须根据错误信息自我修正，而不是直接报错退出。
· 让 Claude 互检：如果不用代码，也可以让 Claude 根据 STYLE_GUIDE.md 来自我审计。

5. 评价驱动开发：先写测试，再写技能
不要凭空想象 Claude 需要什么，要从失败中学习。
· 识别差距：先让 Claude 在没有技能的情况下执行任务，记录它在哪里跌倒了（例如：不知道公司的特定 API 格式）。
· 最小化补足：只编写刚好能让它通过测试的那部分技能描述。
· 模型差异化测试：
  · Haiku：需要更详细、直白的引导。
  · Sonnet：需要高效、平衡的指令。
  · Opus/4.5：非常聪明，要避免过度解释，否则它会觉得你太啰嗦而忽略重点。

AI 不会让编程消失，但会让不用 AI 的程序员消失

Redis 的作者antirez，一个对代码有洁癖的人。

他的职业生涯就是在追求"人的痕迹"，每一行代码都要优雅、简洁。

但现在他说：写代码这件事，大部分情况下已经没必要了。

一小时前，他写了一篇博客，分享了自己的想法。

他给了四个例子，都是过去要花几周的活，现在几小时就搞定：

① 给 linenoise 库加 UTF-8 支持，还做了个测试框架
② 修 Redis 测试里那些烦人的时序 bug
③ 用纯 C 写了个 BERT 推理库，700 行，速度只比 PyTorch 慢 15%
④ 让 AI 按照设计文档重做了他对 Redis Streams 的改动，20 分钟

你可能会说，这都是他熟悉的领域啊。

对，但这恰恰是重点。

那些真正厉害的程序员，价值从来不是打字快，而是：
① 能看出问题的本质
② 知道什么方案行得通
④ 懂得在复杂系统里找到平衡点

AI 只是把那些"翻译工作"接过去了，你的大脑可以专注在更重要的事情上。

antirez 很诚实，说自己担心那些会被裁掉的人。

他的想法是，投票给那些认识到这个变化、愿意保护失业者的政府。

很欧洲式的思路，但问题的核心是对的：技术变革带来的阵痛，不能只让个人承担。

antirez 也给很实在的建议：别拒绝正在发生的事。

一定要用"用 AI"，不是试五分钟就下结论的态度。

而是：
① 花几周时间真正去用
② 找到它能让你效率翻倍的场景
③ 如果暂时不行，过几个月再试

AI 在进化，你的使用方式也需要进化。

这是一位创始人的分享。

最近涌现出许多 @stanine 的新粉丝。这完全在情理之中。

Apple 🤝 Gemini 

> Apple 与 Google 已达成一项多年合作，下一代 Apple 基础模型将基于 Google 的 Gemini 模型和云技术构建。这些模型将用于驱动未来的 Apple Intelligence 功能，包括将于今年晚些时候推出的、更个性化的 Siri。

上下文是下一代数据平台：为何“上下文图谱”是理解企业流程的关键

来自 Glean 创始人兼 CEO Arvind Jain 的文章。作为企业搜索和 AI 领域的领军人物，他认为：智能体若想在企业中真正落地并实现自动化，不能仅靠单纯的“数据”，必须依赖“上下文图谱”来理解业务流程的真实全貌。

核心观点：什么是“上下文图谱”？
Arvind 指出，企业数字化已经进入了一个新阶段。过去，我们关注的是存储在系统中的结构化数据（如 Salesforce 中的客户记录）；现在，我们需要关注工作是如何实际发生的。
· 现状：大部分工作流程分散在通讯工具（Slack/Teams）、文档（Docs）、代码库和各种碎片化操作中。这些通常被称为“部落知识”，难以被记录。
· 定义：“上下文图谱”不仅仅是对数据的索引，它是对企业人、事、物之间关系的映射。它能理解谁负责什么账户、谁批准合同、哪个团队在处理突发事件。
· 价值： 它是 AI Agent 的导航地图。只有拥有这种上下文，AI 才能在复杂的企业环境中进行推理和行动。

Glean 的独特哲学：捕捉 “How” 而非 “Why”
Arvind 提出了 Glean 构建上下文图谱的方法论：
“你无法可靠地捕捉‘为什么（Why）’，但你可以捕捉‘如何（How）’。”
· Why（意图）难捕捉：意图往往存在于人的脑海中，或者隐含在零散的对话里，很难直接建模。
· How（过程）有迹可循：每一个操作都会留下数字足迹——文档的编辑、字段的更新、审批的流转。
· 通过 How 推导 Why：通过长期观察大量的“How”（操作模式和流程轨迹），系统可以反向推导出“Why”（业务逻辑和意图）。这就是 AI Agent 学习如何像员工一样处理工作的路径。

技术壁垒：构建上下文图谱为何困难？
Arvind 强调，这不仅仅是一个概念，而是一项高门槛的技术投资。要实现它，必须解决三个层次的难题：
· 全链路的可观测性：不能只看结果（如交易完成），要看过程。需要深度的连接器去捕捉跨应用的操作——比如在 Salesforce 更新交易前，员工在 Google Docs 改了什么，在 Slack 聊了什么。
· 原子级的活动数据：系统必须记录带时间戳的微小动作（编辑、评论、发送消息），并按时间顺序排列，以此作为原始素材。
· 从噪点中提取信号：这是最难的一步。系统需要从海量的碎片操作中，自动识别出“这是一个客户上线项目”或“这是一次产品发布”。

终局思维：下一代数据平台
Arvind 认为，“上下文图谱”只是拼图的一部分。为了支撑 智能体自动化，我们需要一个新的技术栈，这构成了一个全新的数据平台：
· 连接器 (Connectors)： 用于观察。
· 索引 (Indexes)： 用于快速检索。
· 图谱 (Graphs)： 用于理解结构和关系。
· 记忆 (Memory)： 用于记录 Agent 的执行轨迹和结果。

这个平台不是为了做报表或分析，而是为了作为智能体的脊梁，支撑它们在企业中可靠地执行任务。