meng shao (@shao__meng)

v0、lovable 都可以 AI 生成网站，Figma 还活着吗？ Claude Design 这么强，Figma 还活着吗？ 今天 Figma 创始人 @zoink 发布 Q1 2026 财报：还活着！ Figma Q1 2026 财报关键数据来看，增长二次加速： · 营收：$333M，YoY +46%（Q4 为 40%，Q3 为 38%，连续两季加速） · 净美元留存率（NDR，>$10K ARR）：139%，环比 +3pp，两年多以来最高 · 非 GAAP 毛利率：82% · 非 GAAP 经营利润：$52M（16% 利润率） · 自由现金流：$89M（27% 利润率），受年度奖金一次性 $56M 拖累 17pp · 现金及等价物：$1.6B · 国际业务：YoY +48% 客户结构： · 付费客户总数约 69 万（去年同期 45 万，+54%） · ARR > $10K 客户 YoY +37%（环比加速 5pp） · ARR > $100K 客户 YoY +48%（环比加速 2pp） 增长驱动：AI 不再是故事，是收入！ 1. 席位扩张（仍是主引擎） 60% 以上 >$10K ARR 客户在续约时增加 Full Seats。一家超大规模云厂商完成统一签约，3.5 万付费席位，Figma 史上最大单之一。 2. AI Credit 货币化拐点（3 月 18 日启动） 这是本季度最关键的信号： · 此前超出额度的 Org/Enterprise 用户中，75% 在限额生效后继续付费消费 credit，95% 仍活跃——说明 AI 用量是真实需求，非补贴拉动。 · 购买 credit add-on 的 Pro 团队，人均年度支出是普通团队的 3 倍以上。 · Q2 将是首个完整的 credit 货币化季度。 3. AI 产品矩阵深度渗透 · Figma Make：>$100K ARR 客户中约 60% 周活（上季 50%+） · MCP：Figma Design 内 MCP 周活用户环比 5 倍增长；使用 MCP 的大客户 full seat 增速比未使用者快 70% · Figma Weave（原 Weavy）：拓展到产品设计之外的场景（如 NBBJ 建筑事务所用于客户提案渲染） · AI Assistant 处于 Alpha，将很快开始消耗 credit 4. 新付费 Pro 团队转化 YoY +150%——TAM 扩张与长尾变现的领先指标。

Raycast 2.0 @raycast 发布，这是 2020 年首发后最大一次重写，团队写了一篇极有工程价值的技术博客，详细记录了他们如何从纯原生 Swift/AppKit 应用，转向 TypeScript + Swift + C# + Rust + Node + React 的混合架构，实现「在不丢失原生质感的前提下实现跨平台」 为什么要重写？ v1 是基于 AppKit 的纯原生 macOS 应用，几乎所有 UI 组件都自研，没大量使用 SwiftUI（性能与控制力不达标）。但随着产品从 launcher 演化成包含 AI Chat、Notes、扩展、同步、文件搜索的生产力平台，原架构出现三个瓶颈： · 编译时间不断变长 · AppKit 越来越掣肘 · 深耕原生 macOS 的工程师越来越难招 即便不上 Windows，也已经到了必须重构的时间点。Windows 化只是把这件事提前了。 技术选型的取舍 在 Windows 端，原生方案被快速排除：微软 UI 框架历史混乱（WPF→UWP→WinUI 3），WinUI 3 还不够成熟；维护两套独立原生 UI 等于双倍工作。 剩下三选一：Electron / Tauri / 自研混合栈。 · Electron: 成熟稳定，但 Raycast 深度依赖系统能力（全局热键、剪贴板、辅助功能、悬浮面板、半透明等），Web 与原生的边界过于痛苦；且不愿在 macOS 上额外捆绑 Chromium。 · Tauri: 原生侧控制力不足，当时还太年轻。 · 自研混合栈（最终方案）: macOS 用 Xcode + Swift，Windows 用 Visual Studio + C#，各自包一个系统# WebView（WKWebView / WebView2），自行设计 IPC。代价是要自己实现 Electron 免费提供的那一整套基础设施，但换来完全的控制权。 他们也明确表示：这种取舍对绝大多数桌面应用并不成立，Electron 是更理性的选择，只是 Raycast 的特殊性让自研合理。 四层架构 Raycast 2.0 由四个部分组成，跨语言通过统一接口声明 + 类型化客户端代码生成实现编译期安全： 1. Host App：Swift/AppKit (mac), C#/.NET 8/WPF (Win) 2. Web Frontend：React + TypeScript（双端共用一份） 3. Node Backend：单一长驻 Node 进程 4. Rust Core：Rust 产品工程师大多数时间只在 Web + Node 层工作，原生 shell 仅在新增 OS 能力时才动。 自研 Rust 文件索引器值得一提：Windows 上绕过常规 NTFS 遍历，直接读取 Master File Table，实现秒级全盘索引；Rust 的可预测内存与无 GC 暂停在此关键。 让 WebView 感觉像原生 Raycast 的判定标准很简单：用户在不知道实现的情况下，是否会以为这是普通 Mac 应用？ 1. 设计规约层面 · 不用 cursor: pointer · 不用 hover 高亮 · 设置开在独立原生窗口 · Popover/Tooltip 用原生窗口渲染，可超出主窗边界 · macOS Tahoe 上接入 Liquid Glass 材质 · 杜绝任何视图出现/切换时的闪烁 2. 与 WebKit 斗智斗勇 WebKit 是为浏览器设计的，对一个每天显示隐藏几百次的 launcher 来说，很多默认行为是反的： · 节流：requestAnimationFrame、CSS 动画、定时器会在 WebKit 认为视图不可见时被节流。解法：窗口提到最前但 alphaValue=0 保持视觉隐藏，关闭 windowOcclusionDetectionEnabled，显示前用 rAF 触发渲染。 · 被遮挡区域不渲染：从紧凑切换到大尺寸时会有 1–2 帧空白。解法：让 WKWebView 的 frame 始终保持展开后的尺寸，渲染超出可见区域。 · 窗口缩放卡顿：WebKit 在动画 resize 期间暂停绘制。解法：重写 NSWindow.setFrame，用 Core Animation 隐式动画替代。 · 打开闪烁：用 _doAfterNextPresentationUpdate 同步原生呈现与 WebView 绘制完成。 · Emoji 慢：字体回退链每个 glyph 都查找。解法：启动时预热 emoji 字体。 他们还做了一套基础设施，可在运行时切换 WebKit Feature Flags，内部解锁了 60 FPS 上限并启用 requestIdleCallback。 3. Windows 侧 WebView2 基于 Chromium，同样有自己的节流和渲染逻辑。难点包括：自定义标题栏与 acrylic 模糊协调、避免启动时的白屏闪烁、多窗口的 WebView2 环境管理、防止窗口失焦时 Chromium 把 WebView 节流掉（Raycast 经常需要在后台更新）。 内存与性能的平衡 直接面对 Web 桌面应用最常见的批评。 · v1 稳定态 200–300 MB · v2 稳定态 350–450 MB 主窗口隐藏时的分解：WebView ~120–200 MB，Node 后端 ~150–200 MB，Swift 壳 ~40 MB，WebKit GPU ~18 MB，网络进程 ~12 MB。空 WebView 基线就有约 50 MB，空 Node 进程约 12 MB——这是栈本身的固定成本。 他们也在做"如何正确解读内存"的科普：macOS 的压缩内存、clean vs dirty 页、Activity Monitor 会把共享框架内存重复计入每个进程、真正该看的是底部的 Memory Pressure 指示器。但同时强调他们持续追踪 phys_footprint，开发期已大幅压缩，并特别在低内存机器上测试。 博客原文

Anthropic 创始人 @DarioAmodei 怕不是真得了什么大病 ？！ 特朗普访华刚刚开始，Anthropic 就发报告，游说美国国会和特朗普政府收紧对华 AI 管制 ？！ 报告说来说去主要是这个： 算力是 AI 竞争的决定性资源，美国目前领先，但领先优势靠政策维持，而非自然存在。 并构造出 2028 年预测，如果按照他们的游说收紧 AI 管制，和放开，是两种全然不同的景象；明确表示，后者会让美国遭受极大威胁？ 还帮中国的 AI Labs 们做了分析： · 中国 AI 实验室在人才、数据、能源、算法上不弱，唯一卡点是算力。 · 中国通过两条路径绕过卡点： · 走私 + 海外数据中心远程使用美国芯片(现行出口管制只管销售,不管远程访问); · 大规模"蒸馏攻击"——批量伪造账号、系统性抓取美国前沿模型的输出来复刻其能力。 · 美国若现在堵上这两个漏洞，可以锁定 12–24 个月的前沿领先优势；若不行动，优势在 2028 年前会被追平。 Anthropic 明确提出了三项具体政策诉求： 1. 堵漏洞：打击芯片走私、限制中国实验室通过东南亚等地数据中心远程使用受管制芯片、扩大对半导体制造设备 (SME) 的管制与售后服务封锁。 2. 保护创新：立法明确蒸馏攻击非法，推动美国实验室之间及与政府的威胁情报共享。 2. 推动美式 AI 出口：在全球(尤其新兴市场)抢先部署"可信"的美国 AI 硬件与模型，挤压华为/阿里的国际空间。

Raycast 2.0 @raycast 发布，这是 2020 年首发后最大一次重写，团队写了一篇极有工程价值的技术博客，详细记录了他们如何从纯原生 Swift/AppKit 应用，转向 TypeScript + Swift + C# + Rust + Node + React 的混合架构，实现「在不丢失原生质感的前提下实现跨平台」 为什么要重写？ v1 是基于 AppKit 的纯原生 macOS 应用，几乎所有 UI 组件都自研，没大量使用 SwiftUI（性能与控制力不达标）。但随着产品从 launcher 演化成包含 AI Chat、Notes、扩展、同步、文件搜索的生产力平台，原架构出现三个瓶颈： · 编译时间不断变长 · AppKit 越来越掣肘 · 深耕原生 macOS 的工程师越来越难招 即便不上 Windows，也已经到了必须重构的时间点。Windows 化只是把这件事提前了。 技术选型的取舍 在 Windows 端，原生方案被快速排除：微软 UI 框架历史混乱（WPF→UWP→WinUI 3），WinUI 3 还不够成熟；维护两套独立原生 UI 等于双倍工作。 剩下三选一：Electron / Tauri / 自研混合栈。 · Electron: 成熟稳定，但 Raycast 深度依赖系统能力（全局热键、剪贴板、辅助功能、悬浮面板、半透明等），Web 与原生的边界过于痛苦；且不愿在 macOS 上额外捆绑 Chromium。 · Tauri: 原生侧控制力不足，当时还太年轻。 · 自研混合栈（最终方案）: macOS 用 Xcode + Swift，Windows 用 Visual Studio + C#，各自包一个系统# WebView（WKWebView / WebView2），自行设计 IPC。代价是要自己实现 Electron 免费提供的那一整套基础设施，但换来完全的控制权。 他们也明确表示：这种取舍对绝大多数桌面应用并不成立，Electron 是更理性的选择，只是 Raycast 的特殊性让自研合理。 四层架构 Raycast 2.0 由四个部分组成，跨语言通过统一接口声明 + 类型化客户端代码生成实现编译期安全： 1. Host App：Swift/AppKit (mac), C#/.NET 8/WPF (Win) 2. Web Frontend：React + TypeScript（双端共用一份） 3. Node Backend：单一长驻 Node 进程 4. Rust Core：Rust 产品工程师大多数时间只在 Web + Node 层工作，原生 shell 仅在新增 OS 能力时才动。 自研 Rust 文件索引器值得一提：Windows 上绕过常规 NTFS 遍历，直接读取 Master File Table，实现秒级全盘索引；Rust 的可预测内存与无 GC 暂停在此关键。 让 WebView 感觉像原生 Raycast 的判定标准很简单：用户在不知道实现的情况下，是否会以为这是普通 Mac 应用？ 1. 设计规约层面 · 不用 cursor: pointer · 不用 hover 高亮 · 设置开在独立原生窗口 · Popover/Tooltip 用原生窗口渲染，可超出主窗边界 · macOS Tahoe 上接入 Liquid Glass 材质 · 杜绝任何视图出现/切换时的闪烁 2. 与 WebKit 斗智斗勇 WebKit 是为浏览器设计的，对一个每天显示隐藏几百次的 launcher 来说，很多默认行为是反的： · 节流：requestAnimationFrame、CSS 动画、定时器会在 WebKit 认为视图不可见时被节流。解法：窗口提到最前但 alphaValue=0 保持视觉隐藏，关闭 windowOcclusionDetectionEnabled，显示前用 rAF 触发渲染。 · 被遮挡区域不渲染：从紧凑切换到大尺寸时会有 1–2 帧空白。解法：让 WKWebView 的 frame 始终保持展开后的尺寸，渲染超出可见区域。 · 窗口缩放卡顿：WebKit 在动画 resize 期间暂停绘制。解法：重写 NSWindow.setFrame，用 Core Animation 隐式动画替代。 · 打开闪烁：用 _doAfterNextPresentationUpdate 同步原生呈现与 WebView 绘制完成。 · Emoji 慢：字体回退链每个 glyph 都查找。解法：启动时预热 emoji 字体。 他们还做了一套基础设施，可在运行时切换 WebKit Feature Flags，内部解锁了 60 FPS 上限并启用 requestIdleCallback。 3. Windows 侧 WebView2 基于 Chromium，同样有自己的节流和渲染逻辑。难点包括：自定义标题栏与 acrylic 模糊协调、避免启动时的白屏闪烁、多窗口的 WebView2 环境管理、防止窗口失焦时 Chromium 把 WebView 节流掉（Raycast 经常需要在后台更新）。 内存与性能的平衡 直接面对 Web 桌面应用最常见的批评。 · v1 稳定态 200–300 MB · v2 稳定态 350–450 MB 主窗口隐藏时的分解：WebView ~120–200 MB，Node 后端 ~150–200 MB，Swift 壳 ~40 MB，WebKit GPU ~18 MB，网络进程 ~12 MB。空 WebView 基线就有约 50 MB，空 Node 进程约 12 MB——这是栈本身的固定成本。 他们也在做"如何正确解读内存"的科普：macOS 的压缩内存、clean vs dirty 页、Activity Monitor 会把共享框架内存重复计入每个进程、真正该看的是底部的 Memory Pressure 指示器。但同时强调他们持续追踪 phys_footprint，开发期已大幅压缩，并特别在低内存机器上测试。 博客原文

Codex 进入 ChatGPT mobile App，这回终于能开心的移动办公，随时随地指挥 Codex 工作了（Windows 端还未推出） 新版 ChatGPT mobile App 做了一个完整的 Codex 移动工作面： · 接入用户任意一台运行 Codex 的机器（笔记本、Mac mini、远程开发环境）； · 实时同步所有线程、审批、插件、项目上下文； · 实时回传截图、终端输出、diff、测试结果、审批请求； · 文件、凭证、权限、本地配置始终留在原机器上，不上云。 技术架构：安全中继层 Codex 通过一个安全中继层让可信机器跨设备可达，而不直接暴露到公网；同时把活跃会话状态在所有登录 ChatGPT 的设备间保持同步。 OpenAI 在产品形态上选择了"云端中继 + 本地执行"的混合模型——既保留本地开发环境的安全边界与凭证隔离，又通过云中继获得跨设备的实时同步体验。这是企业级 AI 编程工具一个相对成熟的架构取舍。 OpenAI 演示的四个使用场景 1. 排队买咖啡：启动 bug 调查，Codex 复现、跑测试，需要授权时手机批准 2. 通勤途中：收到 Codex 的方案分叉决策请求，手机上选择路径，任务继续推进 3. 会议间隙：让 Codex 跨 Slack/邮件/文档汇总客户问题，准备 brief 4. 散步、午餐：灵感即时投递到新线程或现有任务，回到工位前已有初步进展

Anthropic 创始人 @DarioAmodei 怕不是真得了什么大病 ？！ 特朗普访华刚刚开始，Anthropic 就发报告，游说美国国会和特朗普政府收紧对华 AI 管制 ？！ 报告说来说去主要是这个： 算力是 AI 竞争的决定性资源，美国目前领先，但领先优势靠政策维持，而非自然存在。 并构造出 2028 年预测，如果按照他们的游说收紧 AI 管制，和放开，是两种全然不同的景象；明确表示，后者会让美国遭受极大威胁？ 还帮中国的 AI Labs 们做了分析： · 中国 AI 实验室在人才、数据、能源、算法上不弱，唯一卡点是算力。 · 中国通过两条路径绕过卡点： · 走私 + 海外数据中心远程使用美国芯片(现行出口管制只管销售,不管远程访问); · 大规模"蒸馏攻击"——批量伪造账号、系统性抓取美国前沿模型的输出来复刻其能力。 · 美国若现在堵上这两个漏洞，可以锁定 12–24 个月的前沿领先优势；若不行动，优势在 2028 年前会被追平。 Anthropic 明确提出了三项具体政策诉求： 1. 堵漏洞：打击芯片走私、限制中国实验室通过东南亚等地数据中心远程使用受管制芯片、扩大对半导体制造设备 (SME) 的管制与售后服务封锁。 2. 保护创新：立法明确蒸馏攻击非法，推动美国实验室之间及与政府的威胁情报共享。 2. 推动美式 AI 出口：在全球(尤其新兴市场)抢先部署"可信"的美国 AI 硬件与模型，挤压华为/阿里的国际空间。

xAI 发布 Grok Build CLI (beta) 面向编码、应用构建与工作流自动化的 Agentic CLI。现在仅向 SuperGrok Heavy 订阅用户开放，xAI 明确表示发布目的是借用户反馈迭代模型与产品本身。 产品地址： 一行 curl 安装 产品定位与关键能力 · Fast & flicker-free CLI — 强调终端渲染性能，针对长会话与并行任务做了优化。 · Plan（计划视图） — 提供可视化的多步计划面板，便于在执行前审阅和调整复杂任务。 · Subagents（子智能体） — 支持并行派生研究、构建、审查角色，最多可同时跑 8 个智能体。 · Skills（技能） — 可装载的工作流偏好与领域知识，让 Agent 适配团队规范。 · Plugins / Marketplaces — 团队间共享能力的市场机制，意在形成生态。 · Q&A 主动澄清 — Agent 会在动手前主动追问细节，而非直接生成。 底层模型为 grok-code-fast-1，公开数据为 SWE-Bench Verified 70.8%，上下文窗口 256K。

v0、lovable 都可以 AI 生成网站，Figma 还活着吗？ Claude Design 这么强，Figma 还活着吗？ 今天 Figma 创始人 @zoink 发布 Q1 2026 财报：还活着！ Figma Q1 2026 财报关键数据来看，增长二次加速： · 营收：$333M，YoY +46%（Q4 为 40%，Q3 为 38%，连续两季加速） · 净美元留存率（NDR，>$10K ARR）：139%，环比 +3pp，两年多以来最高 · 非 GAAP 毛利率：82% · 非 GAAP 经营利润：$52M（16% 利润率） · 自由现金流：$89M（27% 利润率），受年度奖金一次性 $56M 拖累 17pp · 现金及等价物：$1.6B · 国际业务：YoY +48% 客户结构： · 付费客户总数约 69 万（去年同期 45 万，+54%） · ARR > $10K 客户 YoY +37%（环比加速 5pp） · ARR > $100K 客户 YoY +48%（环比加速 2pp） 增长驱动：AI 不再是故事，是收入！ 1. 席位扩张（仍是主引擎） 60% 以上 >$10K ARR 客户在续约时增加 Full Seats。一家超大规模云厂商完成统一签约，3.5 万付费席位，Figma 史上最大单之一。 2. AI Credit 货币化拐点（3 月 18 日启动） 这是本季度最关键的信号： · 此前超出额度的 Org/Enterprise 用户中，75% 在限额生效后继续付费消费 credit，95% 仍活跃——说明 AI 用量是真实需求，非补贴拉动。 · 购买 credit add-on 的 Pro 团队，人均年度支出是普通团队的 3 倍以上。 · Q2 将是首个完整的 credit 货币化季度。 3. AI 产品矩阵深度渗透 · Figma Make：>$100K ARR 客户中约 60% 周活（上季 50%+） · MCP：Figma Design 内 MCP 周活用户环比 5 倍增长；使用 MCP 的大客户 full seat 增速比未使用者快 70% · Figma Weave（原 Weavy）：拓展到产品设计之外的场景（如 NBBJ 建筑事务所用于客户提案渲染） · AI Assistant 处于 Alpha，将很快开始消耗 credit 4. 新付费 Pro 团队转化 YoY +150%——TAM 扩张与长尾变现的领先指标。

🌟Introducing🎻Violin — an Open-source Video Translation Skill. 📹Video is the dominant medium on the internet, yet most high-quality content (lecture, talk, podcast) is locked behind a single language, leaving global audiences behind. So we built Violin: a video skill that combines speech recognition, LLM translation, and speech synthesis into one seamless pipeline. 🌐 Demo: 📝 Blog: 🔗 GitHub: ✨Key Features: 🎙️High-quality multilingual ASR & Translation & TTS. 🗣️Personalize translation & voice (turn an academic talk into something children can follow). 💬Chat with the video — ask any questions grounded in the video. 🧩Support Web app, CLI, and Agent skill 🍃Fully open-source under MIT. ❤️Built with the wonderful @ShangZhu18 and advised by @james_y_zou ! All features powered by @togethercompute . Try it and let us know what you think! 🎻

Cline SDK 终于发布了，同时发布的还有以 Cline SDK 为基础的 Cline CLI 和 Skills @cline 是最早一批 Agentic Coding 工具了，之前主要以 IDE 插件的形式存在，Cline 的实际表现一直都很强，而且团队有很多技术工程实践，都早于 Claude Code 等团队，技术博客价值很高！后来经历了一些变动，工程团队很多人都去了 Codex，现在重新看到 Cline 的最新进展，还是很期待实际表现。 最新发布的 Cline CLI 在 Terminal Benchmark 上多项第一，超过 Claude Code、Codex 和 Droid 等 Agent，咱们一起看看它在 Harness 方面的重要实践。 Cline 在 Harness 方面的升级 Cline 2.0 重写了 prompts、简化 loop、收紧上下文管理、改进反馈与错误处理、重新设计了工具如何暴露给模型。官方公布的 Terminal-Bench 2.0 成绩： 1. 前沿模型上 Cline CLI 的表现： · claude-opus-4.7：74.2%（Claude Code 同模型 69.4%） · claude-opus-4.6：71.9%（Claude Code 65.4%，Droid 69.9%） · gpt-5.3-codex：73.0%（Codex CLI 75.1%、Droid 77.3% 略高） 2. 开源权重模型上更明显的领先： · kimi-k2.6：Cline 55.1% vs OpenCode 37.1% / Pi-Code 45.5% · deepseek-v4-pro：53.9% vs 51.7% / 52.9% 值得关注的能力点 1. Plugin 层：可注册工具、监听生命周期、加规则与命令、塑造 agent 视野。可从单个 .ts 文件起步，逐步演进为带 cline.plugins manifest 的包。 2. Provider 开放性：@ cline/llms 把模型目录与 provider 配置从 agent loop 中剥离，支持 Anthropic / OpenAI / Google / Bedrock / Mistral / LiteLLM / vLLM / Together / Fireworks。新 provider 只需实现 ApiHandler 并 registerHandler。 3. 原生 Agent Teams / Subagents：子 agent 有自己的模型、工具、prompt，bundled plugin 提供启动、消息、状态、handoff notes 等工具——不需要自己写 orchestration。 4. 开箱即用：CRON、checkpointing、Web search、MCP connector 全部原生。 5. CLI Connectors（实验性）：cline connect 向导可把 agent 接入 Telegram / WhatsApp / Slack。

Kimi 发布了浏览器扩展 ~ Kimi Web Bridge Kimi Web Bridge 把已有的编码型 / 通用型 Agent 接入到用户本地的 Chrome / Edge 浏览器里，使其具备真实的网页操作能力（点击、滚动、输入、抓取、截图）。 关键设计取舍 1. 复用用户的真实浏览器，而不开新沙箱 2. 完全本地化执行 3. 开放接入而非闭环产品 官方四个案例参考 1. 跨平台批量搜索 → 写表格 2. 看一个网站 → 复刻一个 3. 从日常操作学 Skills 4. 自动填 Google Form

Meta 收购 Manus 时，第一反应是： Microsoft 要收购 GenSpark 了吧，这可能是 Microsoft 唯一的选择 但后来 OpenClaw 很快就横空出世，Manus 的产品形态变得更普遍甚至被超越，Meta 一时间变成了“冤大头”，随即后面商务部叫停了收购，Meta 也算是意外免去了损失 在 Hermes Agent 等一众 OpenClaw 接替产品，和 Codex、Claude Code 等不断变成通用 Agent 的时间点，留给 GenSpark 和 Manus 的方向是什么呢？

Stop testing and rewriting prompts manually! Most teams run evals, look at failures, guess what's wrong, rewrite the prompt, then repeat. It's slow and you never know if your rewrite actually fixes the root issue. The better way is evolutionary optimization. Instead of manual rewrites, you use genetic algorithms to analyze eval feedback and rewrite prompts automatically. The algorithm maintains diverse prompt candidates that excel at different problem types, not just one "best" version. DeepEval does this using GEPA - Genetic Evolution with Pareto Selection. You provide a prompt template, test cases, and metrics to optimize for. The optimizer handles the rest. Here's how it works: It splits your test cases into validation and feedback sets. The validation set scores every prompt fairly. The feedback set provides training signals for mutations. Then it starts evolving. It selects a parent prompt, runs it on a minibatch of test cases, collects metric feedback on what failed, and uses an LLM to rewrite the prompt addressing those issues. If the rewritten prompt scores better, it gets added to the candidate pool. After several iterations, it returns the highest-scoring prompt. Key capabilities: • Works with 50+ built-in metrics - answer relevancy, hallucination, bias, task completion, and more. • Supports multi-objective optimization - optimize for multiple metrics simultaneously without forcing tradeoffs. • Configurable iterations and minibatch sizes - control search thoroughness and compute cost. The best part? It's 100% open source. Link to DeepEval in the comments!

Kimi 发布了浏览器扩展 ~ Kimi Web Bridge Kimi Web Bridge 把已有的编码型 / 通用型 Agent 接入到用户本地的 Chrome / Edge 浏览器里，使其具备真实的网页操作能力（点击、滚动、输入、抓取、截图）。 关键设计取舍 1. 复用用户的真实浏览器，而不开新沙箱 2. 完全本地化执行 3. 开放接入而非闭环产品 官方四个案例参考 1. 跨平台批量搜索 → 写表格 2. 看一个网站 → 复刻一个 3. 从日常操作学 Skills 4. 自动填 Google Form

Cline SDK 终于发布了，同时发布的还有以 Cline SDK 为基础的 Cline CLI 和 Skills @cline 是最早一批 Agentic Coding 工具了，之前主要以 IDE 插件的形式存在，Cline 的实际表现一直都很强，而且团队有很多技术工程实践，都早于 Claude Code 等团队，技术博客价值很高！后来经历了一些变动，工程团队很多人都去了 Codex，现在重新看到 Cline 的最新进展，还是很期待实际表现。 最新发布的 Cline CLI 在 Terminal Benchmark 上多项第一，超过 Claude Code、Codex 和 Droid 等 Agent，咱们一起看看它在 Harness 方面的重要实践。 Cline 在 Harness 方面的升级 Cline 2.0 重写了 prompts、简化 loop、收紧上下文管理、改进反馈与错误处理、重新设计了工具如何暴露给模型。官方公布的 Terminal-Bench 2.0 成绩： 1. 前沿模型上 Cline CLI 的表现： · claude-opus-4.7：74.2%（Claude Code 同模型 69.4%） · claude-opus-4.6：71.9%（Claude Code 65.4%，Droid 69.9%） · gpt-5.3-codex：73.0%（Codex CLI 75.1%、Droid 77.3% 略高） 2. 开源权重模型上更明显的领先： · kimi-k2.6：Cline 55.1% vs OpenCode 37.1% / Pi-Code 45.5% · deepseek-v4-pro：53.9% vs 51.7% / 52.9% 值得关注的能力点 1. Plugin 层：可注册工具、监听生命周期、加规则与命令、塑造 agent 视野。可从单个 .ts 文件起步，逐步演进为带 cline.plugins manifest 的包。 2. Provider 开放性：@ cline/llms 把模型目录与 provider 配置从 agent loop 中剥离，支持 Anthropic / OpenAI / Google / Bedrock / Mistral / LiteLLM / vLLM / Together / Fireworks。新 provider 只需实现 ApiHandler 并 registerHandler。 3. 原生 Agent Teams / Subagents：子 agent 有自己的模型、工具、prompt，bundled plugin 提供启动、消息、状态、handoff notes 等工具——不需要自己写 orchestration。 4. 开箱即用：CRON、checkpointing、Web search、MCP connector 全部原生。 5. CLI Connectors（实验性）：cline connect 向导可把 agent 接入 Telegram / WhatsApp / Slack。

OpenAI 给 Codex 在 Windows 造了一个沙箱，过程比想象中曲折 ... 来自 Codex 团队 David Wiesen 非常有深度的技术博客，推荐阅读！ 问题的起点：Windows 上的 Codex 没有沙箱 Codex 运行在开发者本地（CLI / IDE 扩展 / App），默认以当前用户身份执行命令——既能读写文件、跑测试、操作 Git，也意味着潜在风险。 macOS 有 Seatbelt，Linux 有 seccomp/bubblewrap，Windows 原生缺乏这种"按进程做强约束"的能力。结果 Windows 用户只能在两个糟糕方案中二选一： · 每条命令都审批（甚至读操作），打断流畅性； · 开启 Full Access，放弃所有约束。 团队的目标，是把 Codex 在 macOS/Linux 已有的"默认安全"体验搬到 Windows：只能在工作区内写、默认无网络访问，且全程不需要用户介入。 现成 Windows 方案为什么都不够用？ · AppContainer：是为"功能边界清晰的应用"设计的；Codex 要驱动 shell、Git、Python、构建工具等任意二进制，形状不对 · Windows Sandbox：它是隔离的"另一个桌面"，无法直接作用于用户的真实仓库；且 Windows Home 版根本没有 · Mandatory Integrity Control：把工作区标成 Low，等于让所有 Low 进程都能写入，宿主信任模型被破坏，副作用太大 第一版原型：「免提权沙箱」（Unelevated Sandbox） 设计原则：不弹 UAC、不要求管理员。需要解决两件事：限制文件写入 + 限制网络。 1. 文件写入：靠 SID + Write-Restricted Token 真正落地 · 合成 SID：Windows 允许创建一个不绑定真实用户、却能出现在 ACL 中的身份。Codex 为此造了一个专属的 sandbox-write SID。 · Write-Restricted Token：一种特殊进程令牌，写操作要双重放行——token 的真实用户身份有权限； token 的"受限 SID 列表"中至少一个 SID 也被授权。 把 sandbox-write SID 通过 ACL 授予： · 当前工作目录 · config.toml 里配置的 writable_roots 并显式拒绝其写入 .git / .codex / .agents。 → 这是真正的 OS 级写边界。 2. 网络访问：只能"劝退"，无法强制 Windows Firewall 必须管理员权限，于是只能做环境层面的软封锁： HTTPS_PROXY / ALL_PROXY / GIT_HTTPS_PROXY = GIT_SSH_COMMAND = cmd /c exit 1 外加在 PATH 前塞 denybin，让假的 ssh/scp 先被解析到。 效果：拦得住行为良好的工具；但凡自己实现网络栈、绕过 PATH、或直接开 socket 的程序——一律失效。仅是 advisory，挡不住对抗性代码。 改版关键：为什么必须接受"需要提权" 要让 Windows Firewall 真正生效，必须按"身份"匹配规则。但： · 防火墙规则不能匹配 restricted token 中的合成 SID； · 按 codex.exe 路径匹配，覆盖不到它派生的 Git/Python 等子进程； · 按用户匹配又会误伤真实用户本人； · 按端口/地址匹配是错的策略——目标不是封 443，而是封这一棵受限进程树的所有出站流量。 唯一的出路：让沙箱命令以"另一个 Windows 用户"的身份运行。这就必须放弃"免提权"约束。 最终方案：「提权沙箱」（Elevated Sandbox） 1. 引入两个本地用户 Codex 在安装时创建： · CodexSandboxOffline —— 防火墙规则全封； · CodexSandboxOnline —— 不被防火墙规则覆盖。 子进程依旧跑在带 [Everyone, Logon, Synthetic] 受限 SID 列表的 write-restricted token 下，但 token 的主体（principal）换成了沙箱用户，而不是真实用户。 5.2 一次性 setup 步骤（需要管理员） · 创建合成 SID； · 创建在线 / 离线沙箱用户； · 凭据用 DPAPI 加密存储，沙箱用户自己读不到； · 为 CodexSandboxOffline 创建"封禁所有出站"的防火墙规则； · 给沙箱用户补 读 ACL——因为新用户默认读不到其他用户的 profile、C:\Users、C:\Program Files 等常用目录。这一步耗时，异步执行，不阻塞用户。 5.3 为什么需要 codex-command-runner.exe 直觉的流程是： codex.exe → LogonUserW → CreateRestrictedToken → CreateProcessAsUserW(child) 但在 CreateProcessAsUserW 这一步存在特权墙：以"真实用户"身份是无法可靠地把进程以另一个用户的受限 token 拉起来的。 解法是把流程切成两段： Part 1（在真实用户侧） · codex.exe 用 CreateProcessWithLogonW 把 codex-command-runner.exe 以沙箱用户身份拉起（此时还不是受限 token）。 Part 2（已经在沙箱用户侧） · runner 用 OpenProcessToken 拿到自己的 token； · GetTokenInformation 取出 logon SID； · CreateRestrictedToken 构造最终受限 token； · CreateProcessAsUserW 拉起真正的子进程。 5.4 最终四层架构 · codex.exe —— 普通非提权的 harness； · codex-windows-sandbox-setup.exe —— 一次性的提权安装； · codex-command-runner.exe —— 在沙箱用户内造受限 token 并起子进程； · child process —— 真正受约束的命令。 拆成独立二进制的好处：codex.exe 在其他平台不被 Windows 专属逻辑污染；UAC 边界只在必要时跨越；setup 的长耗时与主进程生命周期解耦。

田渊栋 (前 Meta FAIR Director) 以联合创始人身份正式官宣新公司：Recursive @Recursive_SI Recursive 的使命是构建递归自改进超智能 (Recursive Self-Improving Superintelligence)，让 AI 自动发现知识、自我迭代，形成开放式循环，从根本上改变科学与技术进步的方式。核心思路是“AI 即代码，AI 现在也能写代码”，闭合自改进环路，取代人类手动设计 AI 的过程。 公司全称 Recursive Superintelligence，获超 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 等顶尖人才）

OpenAI 给 Codex 在 Windows 造了一个沙箱，过程比想象中曲折 ... 来自 Codex 团队 David Wiesen 非常有深度的技术博客，推荐阅读！ 问题的起点：Windows 上的 Codex 没有沙箱 Codex 运行在开发者本地（CLI / IDE 扩展 / App），默认以当前用户身份执行命令——既能读写文件、跑测试、操作 Git，也意味着潜在风险。 macOS 有 Seatbelt，Linux 有 seccomp/bubblewrap，Windows 原生缺乏这种"按进程做强约束"的能力。结果 Windows 用户只能在两个糟糕方案中二选一： · 每条命令都审批（甚至读操作），打断流畅性； · 开启 Full Access，放弃所有约束。 团队的目标，是把 Codex 在 macOS/Linux 已有的"默认安全"体验搬到 Windows：只能在工作区内写、默认无网络访问，且全程不需要用户介入。 现成 Windows 方案为什么都不够用？ · AppContainer：是为"功能边界清晰的应用"设计的；Codex 要驱动 shell、Git、Python、构建工具等任意二进制，形状不对 · Windows Sandbox：它是隔离的"另一个桌面"，无法直接作用于用户的真实仓库；且 Windows Home 版根本没有 · Mandatory Integrity Control：把工作区标成 Low，等于让所有 Low 进程都能写入，宿主信任模型被破坏，副作用太大 第一版原型：「免提权沙箱」（Unelevated Sandbox） 设计原则：不弹 UAC、不要求管理员。需要解决两件事：限制文件写入 + 限制网络。 1. 文件写入：靠 SID + Write-Restricted Token 真正落地 · 合成 SID：Windows 允许创建一个不绑定真实用户、却能出现在 ACL 中的身份。Codex 为此造了一个专属的 sandbox-write SID。 · Write-Restricted Token：一种特殊进程令牌，写操作要双重放行——token 的真实用户身份有权限； token 的"受限 SID 列表"中至少一个 SID 也被授权。 把 sandbox-write SID 通过 ACL 授予： · 当前工作目录 · config.toml 里配置的 writable_roots 并显式拒绝其写入 .git / .codex / .agents。 → 这是真正的 OS 级写边界。 2. 网络访问：只能"劝退"，无法强制 Windows Firewall 必须管理员权限，于是只能做环境层面的软封锁： HTTPS_PROXY / ALL_PROXY / GIT_HTTPS_PROXY = GIT_SSH_COMMAND = cmd /c exit 1 外加在 PATH 前塞 denybin，让假的 ssh/scp 先被解析到。 效果：拦得住行为良好的工具；但凡自己实现网络栈、绕过 PATH、或直接开 socket 的程序——一律失效。仅是 advisory，挡不住对抗性代码。 改版关键：为什么必须接受"需要提权" 要让 Windows Firewall 真正生效，必须按"身份"匹配规则。但： · 防火墙规则不能匹配 restricted token 中的合成 SID； · 按 codex.exe 路径匹配，覆盖不到它派生的 Git/Python 等子进程； · 按用户匹配又会误伤真实用户本人； · 按端口/地址匹配是错的策略——目标不是封 443，而是封这一棵受限进程树的所有出站流量。 唯一的出路：让沙箱命令以"另一个 Windows 用户"的身份运行。这就必须放弃"免提权"约束。 最终方案：「提权沙箱」（Elevated Sandbox） 1. 引入两个本地用户 Codex 在安装时创建： · CodexSandboxOffline —— 防火墙规则全封； · CodexSandboxOnline —— 不被防火墙规则覆盖。 子进程依旧跑在带 [Everyone, Logon, Synthetic] 受限 SID 列表的 write-restricted token 下，但 token 的主体（principal）换成了沙箱用户，而不是真实用户。 5.2 一次性 setup 步骤（需要管理员） · 创建合成 SID； · 创建在线 / 离线沙箱用户； · 凭据用 DPAPI 加密存储，沙箱用户自己读不到； · 为 CodexSandboxOffline 创建"封禁所有出站"的防火墙规则； · 给沙箱用户补 读 ACL——因为新用户默认读不到其他用户的 profile、C:\Users、C:\Program Files 等常用目录。这一步耗时，异步执行，不阻塞用户。 5.3 为什么需要 codex-command-runner.exe 直觉的流程是： codex.exe → LogonUserW → CreateRestrictedToken → CreateProcessAsUserW(child) 但在 CreateProcessAsUserW 这一步存在特权墙：以"真实用户"身份是无法可靠地把进程以另一个用户的受限 token 拉起来的。 解法是把流程切成两段： Part 1（在真实用户侧） · codex.exe 用 CreateProcessWithLogonW 把 codex-command-runner.exe 以沙箱用户身份拉起（此时还不是受限 token）。 Part 2（已经在沙箱用户侧） · runner 用 OpenProcessToken 拿到自己的 token； · GetTokenInformation 取出 logon SID； · CreateRestrictedToken 构造最终受限 token； · CreateProcessAsUserW 拉起真正的子进程。 5.4 最终四层架构 · codex.exe —— 普通非提权的 harness； · codex-windows-sandbox-setup.exe —— 一次性的提权安装； · codex-command-runner.exe —— 在沙箱用户内造受限 token 并起子进程； · child process —— 真正受约束的命令。 拆成独立二进制的好处：codex.exe 在其他平台不被 Windows 专属逻辑污染；UAC 边界只在必要时跨越；setup 的长耗时与主进程生命周期解耦。

田渊栋 (前 Meta FAIR Director) 以联合创始人身份正式官宣新公司：Recursive @Recursive_SI Recursive 的使命是构建递归自改进超智能 (Recursive Self-Improving Superintelligence)，让 AI 自动发现知识、自我迭代，形成开放式循环，从根本上改变科学与技术进步的方式。核心思路是“AI 即代码，AI 现在也能写代码”，闭合自改进环路，取代人类手动设计 AI 的过程。 公司全称 Recursive Superintelligence，获超 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 等顶尖人才）