歸藏(guizang.ai)@op7418 · 5月14日66

Raycast 居然更新了一个 Beta 版本，也就是 V2 版本。 这一下让它从单纯的启动器，变成了一个“启动器 + AI Agent”的工具了 整体的 UI 和界面全部重做了，更符合现在的 Mac 系统设计。 基础架构重构 (a) 启动器底层全部重做 (b) 搜索、调度、扩展功能重新设计 (c) 设置界面被重构 搜索功能升级 (a) 文件搜索被直接整合进主搜索 (b) 提供了更快的文件搜索体验 AI 能力增强 (a) 拥有单独的 AI Chat 输入框和聊天窗口 (b) AI 能力现在支持 Skills、Agent 和 Memory (c) 内置了语音输入

译Raycast发布V2 Beta版本，核心转变是从一个单纯的启动器升级为“启动器+AI Agent”的集成工具。新版对整体UI和基础架构进行了全面重构，包括重做启动器底层、重新设计搜索与扩展功能。搜索功能得到升级，文件搜索被整合进主搜索框以提升速度。AI能力显著增强，新增了独立的AI Chat输入框和聊天窗口，并支持Skills、Agent和Memory功能，同时内置了语音输入。

Chubby♨️@kimmonismus · 5月14日65

The US has cleared roughly 10 Chinese firms to buy Nvidia's H200. Alibaba, Tencent, ByteDance, JD. So far not a single chip has shipped. Until the chips actually move, the licenses work as a bargaining position rather than a finished deal. Washington keeps the H200 in reserve and can redeem it only if Beijing gives something back, on rare earths, on trade, on the tone toward Taiwan. The staging points the same way. Huang wasn't on the original delegation list. Trump invited him and picked him up in Alaska on the way to meet Xi. The CEO of the most important chipmaker is traveling as part of the leverage, not as a guest. The more interesting possibility is that the bottleneck sits in Beijing, not Washington. China has spent months pushing its champions toward domestic hardware, Huawei Ascend, homegrown clusters. Ordering 75,000 H200s would rebuild the same US dependency those firms are supposed to be shedding. The licenses may already be in hand while the Chinese buyers hold off on their own. That would explain why the limbo suits both governments. US hawks don't actually want the chips in China, and Beijing wants self sufficiency. An approval that never gets redeemed looks like progress and commits no one to anything. The number worth watching is deliveries, not approved firms. While it stays at zero, this is diplomacy dressed as commerce.

译美国已批准约10家中国公司，包括阿里巴巴、腾讯、字节跳动和京东，购买英伟达H200芯片，但至今芯片尚未发货。这一批准实质是外交谈判筹码，华盛顿以芯片换取中国在稀土、贸易或台湾问题上的让步；英伟达CEO黄仁勋的行程也被用作政治杠杆。瓶颈可能在北京方面：中国正推动企业采用国产硬件如华为昇腾，购买H200会重建其试图摆脱的对美技术依赖。当前僵局对双方政府有利：美国鹰派不希望芯片流入中国，而北京追求自给自足。批准但不兑现看似进展且无需承诺。关键指标是发货量而非批准公司数；发货量为零表明这是外交手段伪装成商业行为。

meng shao@shao__meng · 5月14日50

OpenAI 给 Codex 在 Windows 造了一个沙箱，过程比想象中曲折 ... 来自 Codex 团队 David Wiesen 非常有深度的技术博客，推荐阅读！ https://openai.com/index/building-codex-windows-sandbox/ 问题的起点：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 = http://127.0.0.1:9 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 的长耗时与主进程生命周期解耦。

译OpenAI 为在 Windows 上实现 Codex 的“默认安全”体验，从免提权沙箱演进到提权沙箱。Windows 缺乏原生进程级约束，初期方案通过合成 SID 和 Write-Restricted Token 限制文件写入，但网络封锁只能依赖环境变量软拦截，无法强制生效。团队最终放弃免提权约束，转向创建独立本地用户（在线与离线沙箱用户），需一次性管理员权限安装并配置防火墙规则。通过引入 codex-command-runner.exe 作为中介，解决跨用户创建受限令牌进程的权限难题，形成四层架构，在保障安全的同时最小化对主流程的侵入。

Berryxia.AI@berryxia · 5月14日79

我靠，肉眼都跟不上这个速度了！ Daniel Han，UnslothAI创始人，YC S24，之前在NVIDIA做ML，刚刚把Qwen3.6的实验MTP GGUF放出来了。 27B模型单GPU直接跑到140 tokens/s。 35B-A3B版本更猛，冲到220 tokens/s。 比原版GGUF快超过1.4倍，精度零损失。 他们测了半天，发现draft tokens设成2就是甜点，再往上接受率暴跌，实际速度反而掉下去。 我看完那张benchmark曲线图，最大的感受是，本地大模型的性能天花板又被狠狠顶高了一截。 以前总觉得30B+模型本地跑太慢，现在MTP投机解码直接把消费级显卡的潜力榨干了。 如果你在玩llama.cpp、跑本地Agent或者日常coding，这波更新必须马上试。 本地AI越来越不像“妥协版”了。

译UnslothAI创始人Daniel Han发布了实验性的Qwen3.6 MTP GGUF模型，显著提升了推理速度。其中，27B模型在单GPU上达到每秒140个token，35B-A3B版本更是高达每秒220个token，相比原版GGUF速度提升超过1.4倍且精度无损。关键优化在于将draft tokens设置为2，这是性能与接受率的最佳平衡点。这项MTP投机解码技术极大提升了消费级显卡运行大模型的效率，推动了本地AI的性能边界。

ginobefun@hongming731 · 5月14日59

在 Windows 上为 Codex 构建安全有效的沙箱 https://openai.com/index/building-codex-windows-sandbox 这篇来自 OpenAI 工程博客，记录了 Codex 团队为在 Windows 上实现真正的沙箱隔离所走的完整路径。写法很好：逐一说清楚每个被否掉的方案以及被否的原因，最后再解释自研方案的设计逻辑。整个记录的过程本身就值得学习。 起点是 2025 年 9 月加入 Codex 团队时面对的实际问题：Windows 用户要么批准几乎每一条命令（低效到让 Agent 失去意义），要么开启完全访问模式（安全风险无法接受）。Linux 有 seccomp，macOS 有 Seatbelt，这两个系统有成熟的内核级沙箱工具，Windows 没有对应能力。 团队评估了三个现成方案。AppContainer 是 Windows 内置的应用沙箱，有真实的操作系统级边界，但它是为权限需求明确且固定的应用设计的，Codex 需要驱动开放式的开发工作流（Shell、版本管理、包管理器……），AppContainer 根本没法灵活控制这类需求的写入权限。Windows Sandbox 是一个一次性轻量虚拟机，沙箱边界更强，但 Codex 需要直接访问用户的真实文件和环境，一个需要单独设置和主客通信的虚拟机桌面解决不了问题，而且 Windows Home 版本根本没有这个功能。MIC（强制完整性控制）用标签机制看起来优雅：把 Codex 设置为低完整性级别、把工作区标记为低完整性，让操作系统强制拒绝向外写入。问题是把工作区标记为低完整性会改变整台机器上所有低完整性进程的信任模型，影响范围太广，对用户真实的开发环境语义改变过大。 最终的自研方案核心是两层机制的组合。第一层是为 Codex 创建一个专属的 Windows SID（安全标识符），这个 SID 只属于 Codex 沙箱，外部没有任何普通进程拥有它。第二层是写受限令牌：任何写操作要通过，必须同时满足两个条件，普通用户身份有权限，且受限 SID 列表中也有相应授权。这个双重检查机制让操作系统在内核层面直接执行文件系统隔离，不需要管理员权限，也不依赖进程树里的任何软件层配合。 网络隔离是另一层：要做到真正的强制执行而不是依赖约定，需要防火墙规则，而 Windows 上的防火墙规则必须绑定到特定用户账户。最终方案是创建两个本地用户：一个在线账户、一个离线账户，沙箱内的 Codex 命令以离线账户身份运行，防火墙规则针对这个账户生效。 最终架构是四个独立二进制文件处理不同的信任边界，并不简单，工程博客也坦诚说了这一点。每一层复杂度的增加都是因为更简单的方案留下了真实的安全缺口。这套设计范式的参考价值超出 Codex 本身：所有需要在 Windows 上隔离文件系统的 Agent 系统（AI 编码工具、自动化测试框架、RPA 产品），都可以借鉴这个通过专属 SID 加写受限令牌实现隔离的思路。

译OpenAI团队为Codex在Windows上构建沙箱时，因系统缺乏原生内核级工具，评估并否决了AppContainer、Windows Sandbox和强制完整性控制（MIC）三个现成方案。最终自研方案结合专属Windows SID与写受限令牌，在内核层实现无需管理员权限的文件系统隔离；网络隔离则通过创建特定本地用户账户绑定防火墙规则来强制执行。该架构虽复杂，但为所有需在Windows上实现文件系统隔离的AI Agent系统提供了关键设计范式。

swyx 🌉@swyx · 5月14日62

any time a model router company drops data, its worth browsing. here we learn that gemini leads in education and personal assistants (?!), ant leads in vibecoding and koding and back office (?!), and oai leads in recruiting outreach (?!) *for the subset that goes thru vercel gateway, which idk the market share

译每当有模型路由公司发布数据，都值得仔细浏览。 从数据中我们看到，Gemini在教育和个人助手领域领先（？！），Ant在氛围编程、代码和后台办公领域领先（？！），而OpenAI在招聘外联领域领先（？！） *数据来自通过Vercel网关的子集，其市场份额未知

SemiAnalysis@SemiAnalysis_ · 5月14日39

Mishek Musa breaks down AI's sensor problem nobody talks about and the hidden mechatronics that keep massive AI data centers running! TUNE IN NOW: https://www.youtube.com/watch?v=d7eG04Ueb7k

译Mishek Musa 剖析了无人提及的AI传感器问题，以及维持大型AI数据中心运转的隐藏机电工程！ 立即观看： https://www.youtube.com/watch?v=d7eG04Ueb7k

Tibo@thsottiaux · 5月14日51

We are continuing to invest in making agents work better on Windows. Highly recommend reading David's engineering post on our unique approach to windows sandboxing for Codex: https://openai.com/index/building-codex-windows-sandbox/

译我们正持续投入以提升智能体在Windows上的表现。 强烈推荐阅读David关于Codex独特Windows沙盒方案的工程文章：https://openai.com/index/building-codex-windows-sandbox/

SemiAnalysis@SemiAnalysis_ · 5月14日41

Cerebras — Faster Tokens Please OpenAI and AWS Partnerships, Tokenomics Explainer, Architecture Deep Dive, Datacenter Ramp, Technical Roadmap READ NOW: https://newsletter.semianalysis.com/p/cerebras-faster-tokens-please?_gl=1*f1ejg5*_ga*MTY1NDExMjk2Ny4xNzc2MTIzOTQ1*_ga_FKWNM9FBZ3*czE3Nzg2OTY0NjQkbzMxJGcwJHQxNzc4Njk2NDY0JGo2MCRsMCRoNjQ5MDMxMTMy

译Cerebras — 请提供更快的令牌 OpenAI与AWS合作、 代币经济学解析、 架构深度解析、 数据中心扩展、技术路线图 立即阅读：https://newsletter.semianalysis.com/p/cerebras-faster-tokens-please?_gl=1*f1ejg5*_ga*MTY1NDExMjk2Ny4xNzc2MTIzOTQ1*_ga_FKWNM9FBZ3*czE3Nzg2OTY0NjQkbzMxJGcwJHQxNzc4Njk2NDY0JGo2MCRsMCRoNjQ5MDMxMTMy

elvis@omarsar0 · 5月14日67

HTML Artifacts are a big part of how I work with agents now. Artifacts can be more than just static files. When combined with agents, they can take action or help you take action. This unlocks all kinds of interesting ways to work with agents. This is clearly the future. Check out this writing and scheduler artifact I built in a few minutes. It uses a bit of HTML and JS. All the data is in markdown (Obsidian vaults), so the agent can access and modify it at any time. No DB needed. No sophisticated functionalities. The agent decides all that for me based on the skills, context, and memory it has access to. The best part about this simple stack is that all the important information stays with me. This has allowed me to build a recursive self-improving system and automations that can better tap into coding agents like Codex or Claude Code. I could have paid or built an entire app for scheduling posts, and there are so many of them out there. But I don't need to. I've realized a simple artifact does the job. And the simplicity of it is actually an advantage. Very little maintenance for very high returns on personalization, time, and efficiency. The other benefit of this is that I can add features as I please. That level of personalization feels magical, and we should all be pursuing more of it. All of this just keeps compounding. Of course, this example is just about writing. But I have similar artifacts for research, design, experimentation, evaluation, and so much more. And no, I didn't actually publish the post example I shared in the clip. It was just for demonstration purposes. I actually spend more time than this when writing together with agents. Lastly, having built my own agent orchestrator tool has made me realize that simplifying the tool stack is a superpower. If you are curious about how all this works, I will do a live session next week: https://academy.dair.ai/events/cmovobp97000904l5h0n9a2yz

译作者介绍了将智能体与可交互的HTML组件（Artifacts）结合的工作流。这些组件超越了静态文件，能主动执行或辅助完成任务。其核心优势在于数据完全自主（存储于Markdown中，无需数据库）、维护简单且回报率高，并能实现高度个性化的功能扩展。作者已将其应用于写作、研究、设计等多个领域，并指出简化工具栈是提升效能的关键。他将于下周进行直播，详细讲解具体实现方法。

向阳乔木@vista8 · 5月13日59

http://x.com/i/article/2054577878822703104 # 产品经典书《启示录》解读，AI时代“加功能”的诱惑比以往任何时候都致命 昨天有网友让帮解读下《启示录》这本书。 借搜索和AI工具辅助，写了一篇AI时代重读《启示录》的解读，自己读了一遍，也有不少触动和启发。 内容大概一万三千字，汇集了三本书中的核心思想，内容如下： 有一个数字，在产品行业流传了将近二十年，没有人真正当回事，但所有人心里都知道它是真的： 九成的软件产品没能实现既定目标。 这不是哪家咨询公司编出来吓人的数字。 马蒂·卡根在《启示录》里用整本书解释这件事，他见过太多团队，聪明、努力、资金充裕，但结果一塌糊涂。 问题出在哪？不是执行力，不是团队不够聪明，不是市场不够大。 大多数产品失败，是因为在开发之前很久，方向就已经错了。 这本书2008年第一版，写的是硅谷顶级产品团队的方法论。 eBay、惠普、网景……卡根在这些公司工作过、观察过，然后把他认为最关键的东西写了下来。 豆瓣上这本书有将近五千条评论，是产品经理书单里几乎永远排在第一位的那本。 但我想说一件事：这本书读起来很顺，很多地方让你觉得"对对对，就是这样"，然后合上书，第二天继续写PRD，继续串行交接，继续开评审会。 读完没有任何改变，是因为你以为自己理解了，其实只是点了点头。 这篇文章试图做一件事：把这本书里真正有价值的东西，逐一拆开来说清楚。 ## 一、产品经理到底是做什么的 很多人入行做产品，做了两三年，说不清产品经理的核心职责是什么。 这不是他们的问题，是整个行业的问题，大多数公司对这个岗位的定义本来就是模糊的。 卡根给出了一个非常清晰的答案，只有两项： 评估产品机会，定义要开发的产品。 听起来简单，展开来说，这两件事里藏着很深的东西。 评估产品机会，意思是当一个产品创意出现在你面前，你要判断它值不值得做。 创意的来源很多，高管说"我们来做个这个功能"，销售说"客户有个需求你们得满足"，竞品上线了某个东西你们没有，用户在反馈里提了很多次某个诉求……面对这些来自四面八方的声音，产品经理的职责是过滤，是评估，是判断哪些值得做、哪些不值得做，而不是照单全收。 定义要开发的产品，意思是在决定要做某个东西之后，你要告诉团队做什么，但不是怎么做。 你要确定产品的价值、体验、发布标准，但技术方案是工程师的事，视觉设计是设计师的事，产品经理的职责是把"做什么"想清楚，留出空间让其他人发挥。 这两件事，加在一起，就是卡根所说的"产品探索"的核心。 但问题是，大多数公司的产品经理，花大量时间做的不是这两件事。 他们在盯进度，在写用户故事，在协调会议，在解答开发人员的各种问题，在跑上跑下确认需求，在处理各种来自不同部门的打断。 真正花在"评估机会"和"定义产品"上的时间，可能只有20%，甚至更少。 这不是个人效率问题，是岗位设计问题。 很多公司根本没有给产品经理留出做这两件事的时间和空间。 卡根还提到一个很多人没意识到的边界问题：产品经理不是项目经理，也不是产品营销经理。 这三个角色在中文互联网语境里经常被混用，但它们是完全不同的职能。 项目经理的核心任务是制订计划、跟踪进度、确保按时交付。 他关心的是"这件事能不能按时做完"，不是"这件事值不值得做"。 产品营销经理的核心任务是对外发布信息、培训销售队伍、定价、命名、推广。 他关心的是"怎么让市场知道这个产品"，不是"这个产品应该是什么"。 这三个角色分开来说都很清晰，但在实际公司里，常常被一个人兼任，或者职责边界模糊到没有人去认真追究。 结果就是，产品经理做了很多项目管理和营销配合的事，真正的产品定义工作没有人在认真做。 卡根的观点是：如果没有人在认真评估机会和定义产品，那么做得再好的项目管理和产品营销，也只是在高效地把一个错误的产品推向市场。 ## 二、机会评估：在动手之前，先把问题想清楚 知道了产品经理的核心职责，下一个问题就来了：怎么评估机会？ 卡根给了一个具体的框架，叫机会评估（Opportunity Assessment）。 他建议用几个关键问题来完成这个评估： - 这个产品要解决什么问题？ - 它解决的是谁的问题？ - 成功的判断标准是什么？ - 有没有更好的替代方案已经存在？ - 为什么现在是做这件事的时机？ - 公司为什么是做这件事的合适主体？ 这几个问题，读起来很基础，但真正逐一认真回答，会发现大多数产品创意在第二三个问题上就站不住脚了。 卡根强调，机会评估有一条铁律：只讨论待解决的问题，绝对不讨论解决方案。 这条规则背后有深意。 很多团队的会议是这样开的：有人提了一个创意，十分钟后，所有人已经在讨论怎么实现这个创意了。没有人追问这个问题本身是否成立，没有人质疑目标用户是否真实，没有人问成功的标准是什么。 把解决方案当成问题本身，是产品团队最常犯的错误之一。 一旦团队开始讨论"我们怎么做这个功能"，就很难再退回去讨论"我们是否应该做这件事"。 因为具体的方案会让人产生投入感，方案讨论得越深入，放弃的心理代价越大。 机会评估阶段就应该严格只讨论问题，把方案的讨论完全锁在门外。 还有一个微妙的地方：机会评估不是一个可以独自完成的工作。 它需要产品经理真正去接触用户、接触市场，而不是坐在办公室里想象用户会怎么想。 卡根后来在第二版里更加强调这一点，好的产品探索，必须建立在持续的用户接触上，而不是季度一次的用研报告。 豆瓣上一条高赞书评说得很直接：这本书最大的价值，是给了产品经理一个"拒绝权"，让你有足够的理论支撑去说"这个创意不值得做"。 有了"机会评估"这个框架，可以说"我们还没完成机会评估，先不进入方案"。 就成了一个可以在会议室里讲出来的句子。 ## 三、PRD的死穴：为什么文档无法替代原型 说到这里，必须谈产品行业里一个几乎所有人都知道是问题、但所有公司都还在用的东西：产品需求文档（简称PRD）。 PRD是什么？ 就是用文字、流程图、静态截图来描述一个产品应该是什么样子的文件。 几十页，甚至上百页，详细描述每一个功能点、每一个状态、每一个边界条件。 PRD本身不是坏东西，它的问题在于被用来做一件它根本做不了的事：验证产品是否真的有用。 你能用文字写清楚"点击这个按钮之后会出现一个弹窗，弹窗里有两个选项"，但你没办法用文字描述"用户看到这个弹窗之后会不会困惑，会不会点错，会不会直接关掉"。 动态的用户体验，文字描述不了。 更大的问题是：PRD无法用于真实用户测试。 你没办法把一份Word文档递给用户说"你来试试这个产品"，用户无法在文档上操作，你也看不到他们的真实反应。 这就导致了一种普遍的悲剧模式：团队花了三个月，按照PRD把产品开发出来，然后上线，才发现用户根本不知道某个核心功能怎么用，或者某个关键流程因为步骤太多用户直接放弃了。 此时想改，整个架构已经定型，牵一发动全身，代价极高。 > 卡根把这叫做"非常昂贵的原型"，你花了三个月时间和大量资金，最终只是验证了一个假设，这是对开发资源最大的浪费。 他的解决方案，是用高保真原型替代PRD。 高保真原型是什么？ 是可以点击、可以跳转、可以体验完整核心流程的交互稿，它不是最终产品，但它足够逼真，足以让用户在上面完成真实的操作，足以让工程师判断技术可行性，足以让整个团队看到他们在做什么。 在写第一行正式代码之前，先把高保真原型做出来，然后用它回答三个问题： 用户会不会用这个产品？用户喜不喜欢这个产品？工程师在现有技术条件下能不能做出来？ 三个问题都有明确答案了，再进入开发阶段。 这个顺序的改变，让所有的验证发生在代码之前，而不是在发布之后。 代价从三个月的开发资源降低到一两周的原型制作时间。 今天这个方案的执行成本比2008年低了一个数量级。 用Figma做高保真原型，一个设计师一周可以完成几乎任何复杂度的核心流程。 用Lovable或v0直接生成可交互的前端Demo，可能只需要几小时。"做原型来不及"这个说法从今以后站不住脚。 ## 四、怎么做用户测试：五个人够了 说到高保真原型，一个紧接着的问题是：怎么用它做用户测试？测多少用户？问什么问题？ 卡根推荐的方法，是"走廊测试"——不需要正式的用研实验室，不需要招募大量被试，就在走廊里或者咖啡馆里，找到目标用户，把原型放在他们面前，看他们怎么用。 尼尔森诺曼集团有一个著名的研究结论：找5个用户做可用性测试，能发现85%的可用性问题。 找更多用户，发现的新问题边际递减。 也就是说，用5个真实用户测试一个原型，成本低，但收获的信息已经足够。 做用户测试，有几个容易犯的错误： 第一个是告诉用户怎么操作。 用户拿到原型不知道怎么用，很多产品经理忍不住说"这里你可以点一下"。 一旦你开口提示，测试就失效了，你测的是有人提示后用户会不会用，不是用户会不会自然地找到这个功能。 第二个是问"你觉得这个设计好不好"。 这种问题得到的答案没有价值，因为用户不擅长评价设计，他们会说"还不错"，但他们可能在操作中完全走错了方向。 正确的方式是给用户一个任务："假设你要完成XX，你会怎么做？"然后观察，不要打断。 第三个是只找技术爱好者做测试。 技术爱好者愿意尝试新东西，对产品不成熟有更高的容忍度，他们能帮你发现很多Bug和可用性问题，但他们的使用行为不代表主流用户。 判断产品有没有真实市场，必须找那些被具体痛点折磨、正在主动寻找解决方案的普通用户。 第四个是测试完发现了问题却不改。 用户测试的价值在于发现问题，发现问题之后修改原型，然后再测，这个循环必须转起来。 很多团队做了用户测试，然后把报告放在文件夹里，继续按原来的方向开发，测试形同虚设。 卡根特别提到了一种用户类型：特约用户。 这是一批被你明确招募进来、愿意提前参与原型测试的目标用户，大概6到15个。 他们不是付费用户，而是合作伙伴，你把最早期的想法和原型给他们，他们给你真实反馈。 这样的关系比随机找用户测试深度大得多，而且他们往往在产品正式上线后会成为第一批真正的口碑传播者，因为他们亲历了产品从粗糙到成型的过程，有一种参与感和认同感。 在可行性验证这一端，卡根主张在原型阶段就把架构师或主程序员拉进来。 产品经理常犯的错误是完成了原型，直接扔给开发团队，认为可行性是开发的事。 但如果某个功能在技术上根本行不通，越晚发现代价越高。 最好的时机是原型阶段，此时改动成本最低。 工程师看了原型，可以直接指出"这里响应速度会不够"，"这个功能需要第三方API，存在合规风险"，产品团队可以立刻调整方向。 ## 五、三角共创：不是三道工序，是同一个过程 说完了产品探索本身，来说说谁来做这件事。 传统的产品开发流程是串行的：产品经理写完需求，扔给设计师，设计师出完图，扔给工程师，工程师写完代码，扔给测试，测试完发布。 每个环节是独立的，交接像接力赛。 这个模式的问题，不只是效率低，而是它把三个本来应该相互依存的角色，变成了三道独立的工序。 卡根的主张是，产品经理、交互设计师、软件架构师（或主程序员），这三个角色，应该从一开始就紧密协作，互相渗透。 他称这三人组合为"产品铁三角"。 为什么设计师必须在早期就参与？ 因为产品的交互方式会直接影响产品能解决什么问题，以及用户体验的质量。 如果产品经理先把功能需求定死，设计师只是在这个框架里填图，很多好的设计可能性就被排除了。 设计师早期参与，他们能提出一些产品经理没有想到的交互方案，有时候这些方案可以让同样的功能变得更直觉，更容易上手。 为什么工程师必须在早期就参与？ 因为可行性不是最后才考虑的问题。设计师做了一个很漂亮的交互，产品经理很兴奋，进入开发才发现实现这个交互需要额外两个月，或者性能上根本跑不起来。 工程师在原型阶段就介入，可以在成本最低的时候给出可行性判断，帮团队避开这些雷区。 三角共创的具体运作是什么样的？ 不是每周开一次碰头会，而是持续的、非正式的密集协作。 设计师在探索交互方案的时候，随时可以找产品经理确认方向，可以找工程师问技术限制。 工程师写代码遇到理解不确定的地方，不是等到下次会议，而是直接走过去问产品或设计。 原型在持续迭代，三方都在看最新版本，都对现在的方向有共同理解。 Teresa Torres在她的书《持续发现习惯》里，把这种协作方式叫"产品三角"，并且给出了更具体的描述： - 产品三角里，产品经理是战略思考者，负责统合用户需求与商业目标； - 设计师是体验设计者，负责打造用户理解和喜爱的方案； - 工程师是技术实现者，了解什么在现阶段可行。 三者的分工不是流水线上的先后顺序，而是对同一件事的不同角度，必须同时在场。 高保真原型，在这种协作里扮演的角色是"共同语言"。 三个背景不同、思维方式不同的人，对着同一个看得见能点击的东西讨论，比对着文字理解彼此意思要高效得多。产品原型是三角共创的载体，没有原型的三角协作，效果大打折扣。 卡根还提到了一个关于节奏的建议：产品经理和设计师的工作进度，应该比开发团队领先一到两个迭代周期。 也就是说，当开发在做当前周期的功能时，产品和设计应该已经在探索下一个或下下一个迭代的方向了。 这样工程师拿到的永远是已经过测试和验证的方案，不需要在开发中等待决策。 ## 六、功能工厂：一个让团队越忙越糟糕的陷阱 说到这里，必须谈《启示录》里另一个被反复提及的概念：功能工厂（需避免）。 什么叫功能工厂？ 就是一个团队把"持续输出功能"当成工作目标。路线图上永远有排不完的需求，团队永远在开发，产品越来越大，功能越来越多，但用户留存没有改善，核心商业指标没有上升，甚至因为产品太复杂，用户越来越难用。 这个模式普遍到令人沮丧。 功能工厂是怎么形成的？ 一是管理层对"进度"的焦虑。 产品开发有很强的不确定性，不确定让管理层不舒服，于是他们用"我们这周上线了什么"来代替"我们解决了什么问题"作为进度指标。 每周都要有功能上线，团队自然变成了功能生产线。 另外是客户和销售的压力。 客户说"你们如果有XX功能我就续费"，销售说"竞品有这个你们没有"，这些声音在短期内都指向一个方向：加功能。 但每次妥协，团队就离真正的通用产品方向更远一步。 最后一个是产品经理自己的问题。 有些产品经理对创造的热情高于对问题的专注，喜欢提新功能，喜欢看到自己的想法变成现实，但对功能上线之后用户是否真的在用、真的有价值，缺乏持续追踪的意愿。 功能工厂最危险的地方，是它看起来很像在努力工作。 团队很忙，每个人都在做事，每周都有发布，路线图上每个季度都在推进。 但如果你去看真正重要的指标，比如周活跃用户数、30天留存率、核心流程完成率，这些数字没有在动。 卡根给出的解法，是把注意力从"我们做了什么"转移到"我们解决了什么问题"。 路线图不应该是功能列表，而是要解决的问题清单。 每个项目的成功标准，应该在开始之前就定义清楚，而不是上线之后回头解释。 具体操作上，卡根建议用数据找到用户流失的关键节点，比如注册流程有五个步骤，发现大量用户在第三步放弃了，那么下一个迭代的重点就是优化第三步，而不是加新功能。 这种聚焦，和功能工厂的思维完全不同。 在AI时代，功能工厂陷阱升级了。 当AI工具能帮你在两小时内实现一个新功能，"加一个新功能"的门槛更低，诱惑更大，团队更容易陷入"高产出、低价值"的循环。 Nikhyl Singhal，曾任Meta和Google产品领导者，有一个观察放在这里很准确：AI让项目的前10%几乎免费，探索、原型、生成备选方案都变容易了，但最后10%的精致度、稳定性和规模化依然一样难。 这意味着现在最危险的处境，不是团队做不到，而是团队做了太多没必要做的事。 ## 七、七大死亡陷阱：扼杀产品创新的组织模式 《启示录》里有一章我认为每个产品从业者都应该背下来，就是卡根列出的那些会系统性扼杀创新的组织模式。 这些模式不是某一家公司才有的问题，而是在绝大多数公司里以不同形式出现的通病。 第一种：依赖冗长PRD，把文档当成产品定义的主要工具。 上一节已经说过PRD的问题。 在这里补充一点：冗长的PRD还有一个副作用，就是它制造了一种"工作已经完成"的错觉。 当一份50页的文档写完，所有人都会觉得"我们想清楚了"，但这份文档从来没有被真实用户验证过，从来没有被工程师认真评估过可行性，只是思考的产物被打印了下来。 第二种：妥协于大客户的"特例产品"需求。 这是一个非常经典的陷阱，尤其在早期阶段。 销售带来一个大客户，对方愿意付一笔不错的钱，但条件是产品必须增加某些他们特定的功能。 管理层一看，钱到手的机会，说干就干。 这样的事发生一次，两次，慢慢地，产品里有越来越多只服务少数特定客户的功能，这些功能被合同锁死，每次版本迭代都要做兼容测试，代码越来越复杂，维护成本越来越高。 同时，用于大众市场的通用功能探索越来越少，因为团队的资源被这些特例需求占据了。 卡根说，这条路的终点，是把自己变成一家定制软件公司，失去了做通用产品的能力。 第三种：把产品管理部门归属于开发部或市场部。 产品管理放在开发部下面，产品经理很容易被技术细节和执行要求淹没，没有时间和空间做真正的市场探索和机会评估。 产品管理放在市场部下面，产品管理和产品营销会被混淆，产品经理花大量时间做对外宣传相关的事，产品的核心定义工作被忽视。 卡根的建议是，产品管理应该是一个独立的职能部门，和开发部、市场部平级，直接向高层汇报。 这在组织架构上给了产品探索应有的地位和资源。 第四种：瀑布式串行开发，设计后置。 产品先写完所有需求，再把设计工作开始，设计完了再开始开发。每个阶段结束，交接，进入下一阶段。 这种模式的问题上面已经讲过：设计介入太晚，一旦进入开发，修改设计的成本极高；工程师只能被动接受，无法在早期影响产品方向；整个流程缺乏验证环节，错误会一直传到发布才被发现。 第五种：闭门造车，没有真实用户验证的"产品发现"。 这个模式比功能工厂更隐蔽，也更危险。 团队并不是不做产品发现，他们也在讨论用户，也在分析数据，也在做内部评审——但所有这些都是在团队内部完成的，没有真实用户参与。 等到产品做出来了，才去测试，才去收集用户反馈。 此时如果发现大问题，已经太晚，产品的基础架构已经固定，根本性的改变不可能了。 第六种：把产品管理等同于项目管理。 没有专职的产品经理，由项目经理兼任产品职责，或者反过来，产品经理花大量时间做项目管理的事。 项目管理的核心是确保按计划交付，产品管理的核心是确保做了正确的事。 这是两种完全不同的思维方式，长期混淆会让团队变成一个"按时交付错误产品"的机器。 第七种：一味追加功能的"功能工厂"心态。 上一节已经详细说过，不再重复，但值得在这里强调：这是一个可以摧毁好产品的慢性病，危险在于它的破坏性是隐性的，你会在功能越做越多的过程中感觉良好，但核心指标在缓慢下降。 这七种模式，在不同的公司里有不同的组合。 有些公司同时中了三四种，有些公司只有一两种，但任何一种单独存在，都足以让一个有才华的团队做出一个让用户失望的产品。 ## 八、"授权团队"vs"功能团队"：卡根后来说得更清楚了 卡根在《启示录》之后，又写了一本书叫《赋能》，这两本书合在一起，构成了他完整的产品哲学。 《赋能》里引入了一个在他看来是产品工作核心矛盾的概念：功能团队和授权团队的区别。 功能团队是什么样的？ 团队的工作来自路线图，路线图来自管理层或销售，团队的任务是把路线图上的功能做出来，做得又快又好。 他们被"交付的是功能"，问题是，交付的功能是不是真的解决了用户的问题，团队不负责回答这个问题。 授权团队是什么样的？ 团队被"交付的是问题"。 管理层告诉团队，我们想提高三个月用户留存，但怎么提高，由团队来探索和决定。 团队对问题的解决方案有自主权，他们需要用自己的判断去探索最好的方案，而不是等待上级给出功能清单。 卡根认为，大多数公司是功能团队，但真正做出优秀产品的公司，是授权团队。 Amazon、Netflix、Stripe，这些公司的产品团队拿到的是目标，而不是功能列表。 他们对自己负责的业务区域有深度理解，有足够的自主权去探索解决方案，也需要对结果负责，而不是只对交付负责。 这个转变的难点在于管理层。 功能团队的存在，很大程度上是因为管理层不相信团队有足够的判断力，所以用功能清单来控制方向。 要转向授权团队，需要管理层在"确定性"和"自主权"之间做一个艰难的取舍。 卡根给产品评审委员会（Product Council）的设计，正是为了解决这个矛盾。 他建议大公司由关键部门高管组成产品评审委员会，人数控制在十人以内，只在四个关键节点做决策：评估机会是否值得投入，批准进入原型阶段，批准进入正式开发，批准发布。 这四个节点之间，产品团队有完全的自主权，管理层不介入具体方案。 这样既保证了管理层对方向的掌控感，又给了团队应有的探索空间。 ## 九、二十年后，这本书有哪些地方是错的或过时的 说了这么多书里正确的东西，现在来说说它的问题。 这是《启示录》值得真正研究的地方：即使是一本好书，也有它的时代局限，读者有责任自己分辨。 第一个局限：书里的成功案例，几乎全来自美国大公司。 eBay、惠普、网景，这些公司的产品模式，是在特定的资源禀赋、市场环境和组织文化下形成的。 把这套方法论直接搬到一家资源有限的早期创业公司，或者搬到组织文化完全不同的中国互联网公司，需要大量的本土化翻译，而书里没有给出这个翻译的框架。 Reddit上有一个很有意思的讨论，有人问"谁真的读过《启示录》"，高赞回复说：这本书讲的是产品经理"应该"怎么做，但现实生活远比理想复杂，产品管理是一个很模糊的工作，在大多数公司里，推动改变比学方法论难得多。 这个批评是准确的。 书里描述的是一个理想状态，真正的挑战是在一个不理想的组织里，怎么逐步往这个方向推。 第二个局限：对用户研究的深度不够，缺少可操作的节奏框架。 卡根强调要做产品探索，要做原型测试，要接触真实用户，这些方向都是对的。 但书里缺少一个具体的、可以每周执行的用户研究系统。 什么时候做用户访谈？怎么找用户？访谈用什么结构？结果怎么转化为产品决策？ 这些操作层面的问题，在2008年的版本里几乎没有答案。 Teresa Torres后来专门写了《持续发现习惯》来填补这个缺口，后面会详细说。 第三个局限：对AI时代的产品特殊性完全没有覆盖。 2008年的产品，功能边界是清晰的，用户体验是可预测的，系统行为是确定的。 AI产品不是这样：大模型的输出是概率性的，存在幻觉，响应延迟不可控，调用成本会随用户规模急剧上升。 这些特性，完全改变了可行性评估的内容，也改变了用户测试的方法。 卡根在2025年的采访和写作里，开始谈AI对产品团队的影响，但核心书籍还没有完全覆盖这个维度，需要读者自行补充。 第四个局限：对中国本土市场的特殊性无能为力。 中国互联网产品有很多在硅谷语境下不存在的约束：监管合规要求、流量获取逻辑、用户行为差异、微信生态的特殊性。 书里的很多建议，在这些背景下需要重新判断是否适用。 ## 十、AI时代的产品发现：必须自己补上的四个维度 上面讲了书里没有的东西，现在来说AI时代的产品团队具体要补什么。 第一个：可行性评估必须升级为"算力经济学评估"。 传统软件的可行性问题是：这个功能技术上能不能实现？对于确定性系统，这个问题通常有清晰的答案。 AI产品要多问一些问题： - 大模型的响应延迟是多少？主流用户能接受等3秒吗？如果某个核心功能需要5秒以上，用户流失会有多严重？ - 这个应用场景的幻觉率是多少？如果大模型有5%的概率给出明显错误的输出，对这个应用来说是可接受的边界误差，还是会摧毁用户信任的灾难？ - 每次API调用的成本是多少？乘以预期的用户规模和使用频率，商业模型能不能跑通？ - 合规风险在哪里？内容安全、数据隐私、各垂直行业的监管要求，是否已经在产品设计阶段就考虑进去？ 这几个个问题，在原型阶段就要拉入主程序员认真评估，而不是留到开发完成再发现问题。 第二个：用技术爱好者测Bug，用真实用户测价值。 卡根对技术爱好者的警惕，在成熟市场是准确的。 但中国AI早期，情况有所不同。 技术爱好者的价值在于：他们愿意忍受产品的不成熟，有能力理解新技术的运作原理，能提出有深度的Bug报告，是早期阶段最高效的产品测试者。 你完全可以把他们当做"高级测试团队"来用。 但判断产品有没有真实市场，必须去找那些被具体痛点折磨、已经在主动搜索解决方案的普通用户。 他们不关心底层技术是大模型还是规则引擎，他们只关心自己的问题有没有被解决。 这两类用户的反馈，要分开处理，分开权重，不能混在一起评估。 第三个：AI创业的极简起步阵型。 卡根在书里提到，创业公司初期最高效的配置是三人组合：产品经理、交互设计师、原型工程师，专注于产品探索，方向验证清楚再扩张团队。 这个建议在2025年的AI创业环境里更加有力。 一个会用大模型的工程师，可以在几小时内搭出一个功能级Demo，一个懂AI产品的设计师可以快速迭代原型，三个人可以在一两个月内完成从想法到"有人真的愿意用并且愿意付费"的完整验证。 很多AI创业团队在验证阶段就招了十几个工程师，大量开发资源投入进去，结果发现方向不对，代价极高。 资源越有限，越需要在投入大规模开发之前，用最低的成本把方向验证清楚。 ## 十一、Teresa Torres和"持续发现习惯"：把探索变成日常节奏 卡根的书给出了"应该做什么"，Teresa Torres的《持续发现习惯》给出了"每周怎么做"。 这两本书是最好的配套，一个讲方向，一个讲系统。 Torres的核心主张是：产品发现不应该是某个阶段的特定项目，而应该是持续的、固定节奏的日常习惯。 她给出的最小可行发现节奏是：每周至少做一次真实用户访谈。不是季度一次的大型用研项目，不是在重大节点前临时找几个用户，而是每周一次，持续进行，不中断。 为什么每周一次这么重要？ 因为产品决策需要不断的信号更新。用户的反馈在变，市场在变，你对问题的理解也在随着每次访谈深化。 如果信号更新的频率太低，就会出现一种常见的问题：团队对用户的认知停留在三个月前的那次用研里，但用户早就不一样了，产品也走偏了方向。 Torres引入了一个工具，叫"机会解决方案树"。 它的结构是这样的： - 最顶层是你想达到的业务目标，比如提高30天留存； - 中间一层是你从用户访谈里发现的机会，比如"用户觉得新功能上手太难"，"用户找不到某个关键功能的入口"； - 最底层是针对每个机会的具体解决方案，比如优化新手引导，重新设计导航结构。 这棵树的价值，是把用户洞察、产品机会和解决方案之间的关系可视化。 它能帮团队看清楚：我们正在探索的解决方案，对应的是哪个用户机会？如果这个解决方案做出来了，它能解决的机会是不是足够重要？有没有更好的解决方案可以解决同样的机会？ 对于AI产品团队，持续发现系统的价值更加突出。 大模型能力在快速迭代，用户对AI功能的预期也在快速变化，今天用户觉得AI能做这件事是令人惊喜的，三个月后可能变成理所应当的基础能力。 如果没有持续更新的用户信号，就很难判断什么时候应该投入资源去升级某个AI能力，什么时候应该转移注意力去解决其他问题。 Torres还有一个观点值得在这里单独说：发现工作的质量，直接取决于产品三角里每个人参与的深度。 如果产品经理自己做访谈，不让设计师和工程师参与，这样收集到的信号经过了一次转述，信息密度和准确度都会下降。 最好的方式是产品三角一起做访谈，三个人看同样的用户，听同样的故事，各自带着自己的专业视角来理解，讨论时会更有深度。 ## 十二、从初级到高级：产品经理的成长路径 读完《启示录》，一个很自然的问题是：知道了这些，我要怎么做？ 先说入门阶段。 很多人做产品的第一年，主要工作是学会写需求，学会用Axure或Figma做原型，学会和开发、设计沟通，学会在评审会上讲清楚功能逻辑。 这些是基础技能，是必要的但不是充分的。 《启示录》里有一个建议，适合入门阶段的产品经理：找机会做用户访谈。不是等到公司安排，而是自己主动去找。 每周找一个真实用户聊30分钟，问他们在使用你负责的产品时遇到的最大困惑是什么，最常做的操作是什么，什么情况下他们会停下来不知道该怎么做。 这一步会改变一个新产品经理的思维方式：从"我觉得用户会这样用"变成"我知道用户是这样用的"。 这个转变，是从初级到中级最关键的一步。 中级阶段，产品经理面对的主要挑战，是开始要负责产品方向，而不只是执行别人的方向。 这时候机会评估的能力变得关键，你需要学会在大量输入中识别真正重要的信号，需要学会说"这件事我们不做，因为它不符合核心目标"，需要建立自己的优先级判断框架。 高级产品经理面对的主要挑战，是影响组织。 《启示录》里关于组织设计的那些建议，主要是给高级产品人和管理层看的：怎么建立独立的产品职能，怎么推动从功能团队向授权团队的转变，怎么建立有效的产品评审机制，怎么创造让创新发生的组织环境。 在这个阶段，理解书里的组织批判部分，比理解产品探索方法论更重要。 因为你自己的判断力可能已经够了，真正的障碍是系统性的组织问题。 ## 十三、三本书的阅读路线图 说了这么多，最后说说这本书和其他书怎么组合在一起读。 第一本：《启示录》，作为基础框架 读这本书，不要读得太快，要带着问题读：我们公司现在的流程是什么样的？和书里的建议有哪些差距？差距的根源在哪里？ 不要只是点头说"对对对"，要具体问：我们上一个失败的产品，在哪个环节犯了书里描述的哪种错误？ 把书当防御手册来用，比当教科书来用收益更大。 第二本：《精益创业》，作为节奏框架 《精益创业》和《启示录》是互补的。 卡根告诉你产品探索为什么重要，精益创业告诉你探索的节奏应该有多快。 精益创业的核心是"构建-测量-学习"的循环：快速构建最小可行产品，快速测量关键指标，快速从结果里学到东西，然后决定是继续还是转向。 这个循环的速度，是精益方法的核心竞争力。 两本书合在一起，会让你对"产品探索应该长什么样"有更立体的理解：它是一个以周为单位的持续循环，不是一个季度启动一次的阶段性项目。 第三本：《持续发现习惯》，作为操作系统 前两本书都在讲方向，Teresa Torres这本书给出操作系统。 具体内容已经在前面讲过了，这里补充一个读书建议：不要只是把这本书读完，要在读的过程中，设计出你自己的最小可行发现节奏。 你每周可以做一次用户访谈吗？如果一次不行，两周一次呢？ 你的产品三角现在存在吗？如果不存在，可以从哪里开始建立？ 你有机会解决方案树吗？如果没有，可以用一张白纸先画出来试试吗？ 把书里的框架转化成你可以下周就开始做的事，才算真正读完了这本书。 ## 十四、名词是权力，先把词汇表建起来 读完这三本书之后，你会拥有一套产品工作的词汇表。 这件事听起来平凡，但它的价值被严重低估。 当你能说"我们现在正在做机会评估，这个阶段不讨论解决方案"，会议室里的讨论就会被重定向。 当你能说"这个需求属于特例产品，接了会把我们带离通用市场"，你就有了一个可以在会议上说出来的理由，而不只是内心的迟疑。 当你能说"我们的团队模式更接近功能团队，但我们希望往授权团队方向转变"，组织讨论就有了一个可以锚定的方向。 名词是权力。 你有了准确的词汇，就可以精确地描述问题，精确地描述问题，才有可能推动有意义的改变。 有一件事值得说一下：《启示录》在中国产品从业者里的名声非常响，豆瓣八点几分，书单必推，很多产品面试会直接问"你读过《启示录》吗"。 但真正读进去、读出东西的人，远比声称读过的人少。 这不是批评，是一个观察。 这本书不是很难读，但它的很多观点和我们工作中习以为常的方式是相反的，所以"读进去"需要一种特别的意愿：允许自己被说服，允许承认自己公司的流程有根本性的问题。 最后一件事： 有人在Reddit上问，这本书在现实工作里真的有用吗？高赞回复是这么说的： "书里讲的很多东西，在大多数公司里你根本推不动，因为组织阻力太大。但这本书最大的价值，不是给你一套马上能用的操作手册，而是让你知道问题在哪里，知道更好的方式是什么。当你知道了这些，你会对公司里的坏模式更加敏感，更有意愿去推动改变，哪怕只是一点点。" 这个回复，我觉得是对这本书最诚实的评价。 读完《启示录》，你未必能立刻改变你的公司，但你会开始清楚地看到，问题出在哪里，更好的方式是什么，以及下一步你可以做什么。 这已经足够。

译本文结合AI时代背景解读《启示录》，指出多数产品失败源于早期方向错误，而非执行力。产品经理核心职责是“评估产品机会”与“定义要开发的产品”。书中强调用“机会评估”框架聚焦问题本身，并主张以高保真原型（现可用Figma等工具快速制作）替代传统PRD，通过约5名目标用户的测试提前验证体验。在AI降低原型成本的当下，团队更应警惕盲目添加功能，回归产品探索本质。

Chubby♨️@kimmonismus · 5月13日52

"Holy cow." That's the Telaid CIO watching his Claude bill triple in 30 days for 30 seats. Anthropic was already the priciest frontier lab. Claude Opus runs richer per token than anything OpenAI or Google ships. And now Anthropic has moved enterprise customers from flat fees to usage-based pricing, layered on top of a new tokenizer that consumes more per request. Customers are eating it. ServiceNow burned its annual Anthropic budget in months. Workato had one agent burn a full user's tokens in a single day. NinjaOne is moving 700 engineers off GitHub Copilot onto Claude Code. Anthropic ARR sits at 30B, roughly 3x year-end. Microsoft alone is on pace to spend nearly 500M a year on Claude. Anthropic might be the only AI lab on earth that was already priced at a premium and still has room to push higher. Enterprise AI doesn't bill like Salesforce anymore. It bills like AWS, except AWS never had pricing power like this.

译Anthropic将企业客户从固定费用转向基于使用量的定价模式，同时新的分词器导致单次请求消耗增加，致使客户成本急剧上升。例如，有企业CIO发现30个席位的Claude账单在30天内翻了三倍，ServiceNow则在数月内耗尽了年度预算。尽管其Claude Opus已是定价最高的前沿模型，但Anthropic年化收入仍高达300亿美元，仅微软一家年支出就近5亿美元。这标志着企业AI定价正从Salesforce式的固定模式转向类似AWS的用量计费，但Anthropic展现出前所未有的强势定价权。

阿绎 AYi@AYi_AInotes · 5月13日67

Theo 这张清单刷屏了，近期的安全事件如下： CopyFail（Linux 系统被破解） CopyFail 2/Dirty Frag（Linux 内核脏碎片漏洞） Next.js 框架出现 13 个安全警告 MacOS 26.5 系统修复了 70 多个通用漏洞披露（CVE）漏洞 iOS 26.5 系统修复了约 50 个通用漏洞披露（CVE）漏洞 YellowKey（Windows Bitlocker 全盘加密被破解） GreenPlasma（Windows 权限提升漏洞） CVE-2026-21510 和 CVE-2026-21513 被证实由俄罗斯用于 Windows 远程代码执行漏洞攻击 CVE-2026-32202 被单独证实由俄罗斯用于获取敏感文档 Mini-Shai Hulud（超过 300 个 JS 和 Python 软件包因 GitHub Action 缓存投毒而被入侵） 谷歌证实，他们发现了利用人工智能对某个未知的 “开源、基于 Web 的系统管理工具” 进行零日漏洞攻击的情况 Canvas（大多数学校使用的流行学习管理系统）被完全破解 PAN-OS（ Palo Alto Networks 公司的操作系统）因严重等级为 9.3 的 CVE-2026-0300 漏洞被破解 我连着看了三天相关报告，越看越觉得这不是个危言耸听的恐怖故事， 更像是软件工程进入后AI安全时代的入学通知。 最关键的信号藏在 CopyFail 里： 一个 732 字节的 Python 脚本， 确定性拿下 2017 年后几乎所有 Linux 发行版的 root。 这玩意竟然是 AI 辅助发现的。 Google 也在同一周确认，AI 驱动的零日已经在野利用了， 俄罗斯 APT 直接武器化两个 Windows CVE， Mini-Shai Hulud 一次劫持 300+ 个 JS/Python 包。 以前一个漏洞躺三年才被人发现， 现在 AI 扫描+AI 利用，未知→已知→武器化几乎同步发生。 更狠的是供应链， Mini-Shai Hulud 告诉所有人一件事: 你信任的 CI/CD 才是最大的后门。 你以为用官方 GitHub Action 就安全, 其实是把 OIDC token 的钥匙拱手送给攻击者。 Perry Metzger 说过一句我反复琢磨的话： bug 的总量是有限的,AI 正在快速耗尽低挂果实。 也就是说,以前安全是"被动 patch", 现在开始转向"AI 实时免疫"。 未来不再是人盯人,会变成 AI 盯 AI。 所以 Theo 问 Are you scared yet, 我的答案是不怕,但必须立刻行动。 第一步不是全站 patch,是把供应链审计提到 P0， GH Actions 全审一遍,禁用 pull_request_target, 强制 SLSA Level 3,启用 SBOM。 那些把"安全作为第一原则"写进 DNA 的团队, 接下来 3-5 年会活得最舒服， 其他人要交的学费,可能比想象中贵得多~

译近期CopyFail、YellowKey、Mini-Shai Hulud等系列安全事件，标志着软件安全范式正发生根本转变。AI不仅辅助发现漏洞（如732字节脚本攻破Linux root），更被直接用于驱动零日漏洞的在野利用和武器化。漏洞从发现到武器化的时间急剧缩短。供应链成为最薄弱环节，Mini-Shai Hulud事件揭示被广泛信任的CI/CD管道（如GitHub Actions）可能成为最大后门。安全模式正从“被动修补”转向构建“AI实时免疫”体系。应对核心是将供应链审计提升至最高优先级，审查CI/CD、强制实施SLSA等标准。未来3-5年，安全能力将直接决定企业生存成本。

向阳乔木@vista8 · 5月13日60

应该还有不少bug，等后续版本更新

译博主长期计划搭建个人博客，因工程量大而拖延。受@vista8乔木老师开源博客系统启发，他fork代码并部署到Cloudflare，大半天内实现上线。系统提供Notion式写作体验，AI自动生成摘要、标签和封面，内置微信公众号bridge支持一键发布，且零服务器成本。开源社区避免了从零造轮子，大幅提升效率。但系统初版可能存在bug，需等待后续版本更新。

Berryxia.AI@berryxia · 5月13日72

如何对本地大模型进行基准测试 ？ 1、拉取一个模型 2、运行 BenchLoop 3、实时查看质量 / 速度 / 可靠性评分 4、对比不同提示框架（如原生模式 vs Hermes 模式） 5、自动发布到公开排行榜 https://bench-loop.com

译BenchLoop 提供了一套对本地大模型进行基准测试的标准化流程。用户只需拉取模型并运行该工具，即可实时获取模型在质量、速度和可靠性方面的综合评分。平台支持对比不同提示框架（如原生模式与 Hermes 模式）下的性能表现。测试完成后，结果可自动发布至公开排行榜，便于横向比较不同模型的优劣。

OpenRouter@OpenRouter · 5月13日65

Opus 4.7 fast mode is live on OpenRouter! Just set your model to `anthropic/claude-opus-4.7-fast` Full Opus 4.7 intelligence with ~2.5x faster throughput

译Opus 4.7 快速模式已在 OpenRouter 上线！ 只需将您的模型设置为 `anthropic/claude-opus-4.7-fast` 具备完整的 Opus 4.7 智能，吞吐量提升约 2.5 倍

ginobefun@hongming731 · 5月13日71

构建支持暂停、恢复且永不丢失上下文的长时间运行 AI 智能体（基于 ADK） 大多数 Agent 教程的终点是一个无状态的聊天机器人，容器一重启，什么都忘了。但真实的企业工作流不可能在一次 API 调用里完成。HR 入职流程跨越两周，发票纠纷要等供应商回复几天，销售跟进序列拉开一个月。这些流程被大量「空闲等待」主导，无状态架构天然无法应对。 Google 博客通过一个「新员工入职协调 Agent」实例，展示了三项让 Agent 从 Demo 走向生产的架构转变。 第一项是持久化状态机。不再靠对话历史追踪进度，而是定义显式的状态 schema：START、WELCOME_SENT、DOCUMENTS_SIGNED、IT_PROVISIONED、HARDWARE_DELIVERED、COMPLETED，六个明确节点。Agent 每次唤醒，从 session state 而非聊天记录里读取当前位置。这彻底解决了三个无状态架构的致命问题：对话历史在数百轮后充满过期噪音（上下文污染）、每次推理都要重放完整历史（token 成本爆炸）、长时间空闲后恢复时模型幻觉出从未发生过的中间步骤（推理幻觉）。 第二项是事件驱动休眠门控。Agent 在等待人工签字时不再主动轮询，而是挂起自身，等到外部事件（如文件签署通知）到达后才被唤醒。零资源占用，不会因为长时间等待而消耗 token 或算力。 第三项是多 Agent 委托。IT 账号配置这类专项任务，交给独立的 IT 子 Agent 完成，主 Agent 只负责协调和状态推进。这避免了单体 Agent 提示词膨胀，也让各子任务可以独立优化。 完整示例代码已放在 GitHub 上。这套架构的核心洞察是：Context 与 State 解耦，才是 Agent 从实验室走进生产环境的关键一步。

译Google博客以“新员工入职协调Agent”为例，指出AI智能体从演示走向生产需完成三大架构转变，核心是上下文与状态解耦。首先，采用持久化状态机，通过明确进度节点替代对话历史记录状态，解决上下文污染、token成本爆炸和推理幻觉问题。其次，引入事件驱动休眠门控，使Agent在等待外部事件时挂起以零资源消耗。最后，通过多Agent委托机制，将专项任务交由独立子Agent处理，避免提示词膨胀并支持独立优化。完整示例代码已开源。

SemiAnalysis@SemiAnalysis_ · 5月13日36

Building a GenAI demo takes hours but deploying to production is where most customers hit a wall.

译构建生成式AI演示只需数小时，但部署到生产环境才是大多数客户碰壁之处。

ginobefun@hongming731 · 5月13日43

#BestBlogs 早报 2026-05-13 今日主题： - 从演示 Agent 到生产 Agent，最难的一步是解决空闲等待。今日精读聚焦 AI Agent 落地的三个层面：Google ADK 教程用持久化状态机替代对话历史、事件驱动替代轮询，让长流程 Agent 永不丢失上下文； - 小红书 QCon 实战还原 GUI Agent 测试的真实瓶颈，发现执行自动化只解决一半问题，业务理解才是核心； - PingCAP 黄东旭复盘 TiDB 为 Kimi K2.6 数千万站点提供 Agent 数据库支撑的细节，说明 Scale 数量才是 Infra 真正的考题。

译AI Agent落地聚焦技术、测试与基础设施三大层面。技术实现上，Google ADK通过持久化状态机和事件驱动机制，解决了长流程Agent的空闲等待与上下文丢失难题。测试环节中，小红书QCon实战揭示GUI Agent测试的真实瓶颈在于业务理解，而非仅靠执行自动化。基础设施方面，PingCAP复盘TiDB支撑Kimi海量站点的案例，说明处理规模是可扩展架构的核心考题。

Satya Nadella@satyanadella · 5月13日68

Our new multi-model agentic security system brings together more than 100 specialized agents across frontier and custom models to find exploitable bugs, delivering top performance on the CyberGym benchmark. We used it ahead of Patch Tuesday to help find and fix 16 vulnerabilities. Today we’re announcing that customers can sign up to test it in private preview. https://www.microsoft.com/en-us/security/blog/2026/05/12/defense-at-ai-speed-microsofts-new-multi-model-agentic-security-system-tops-leading-industry-benchmark/?v=1

译微软推出新型多模型智能体安全系统，整合了超过100个基于前沿和定制模型的专用智能体，用于发现可利用的安全漏洞。该系统在CyberGym基准测试中取得了顶级性能。在最近的Patch Tuesday之前，该系统已帮助发现并修复了16个漏洞。微软宣布客户现可申请加入该系统的私有预览测试。

MiniMax (official)@MiniMax_AI · 5月13日44

M2.7 now has a smoother on-ramp. Thanks @LilacML for helping more teams put it to work.🙌

译M2.7 现在有了更顺畅的接入途径。感谢 @LilacML 帮助更多团队将其投入使用。🙌

SemiAnalysis@SemiAnalysis_ · 5月13日61

THE MORE U BUY, THE MORE U SAVE: By ganging up multiple B200 8-GPU machines together over RoCEv2 CX-7 ethernet with Tomahawk switches with an inference optimization called PD disaggregation, the per GPU token throughput increases up to 7x. By increasing per GPU token throughput by up to 7x, this decreases cost per million tokens by up to 7x also. Great work to @inferact & @vllm_project for building this amazing OSS engine & for @NVIDIADC @KranenKyle for building dynamo inference orchestrator. More improvements to disagg b200 perf to come!

译通过RoCEv2 CX-7以太网和Tomahawk交换机连接多台B200 8-GPU机器，并采用名为PD disaggregation的推理优化技术，单GPU的token吞吐量最高可提升7倍。吞吐量的大幅提升使得每百万token的成本也相应降低了最多7倍。这一成果得益于Inferact和vLLM项目开发的开源引擎，以及NVIDIA团队构建的动态推理编排器。未来针对B200 disaggregation的性能还将有进一步改进。

Perplexity@perplexity_ai · 5月12日56

We published new research on how we serve post-trained Qwen3 235B models on NVIDIA GB200 NVL72 Blackwell racks. GB200 is a major step up over Hopper for high-throughput inference on large MoE models, not just a training platform.

译我们发布了关于如何在NVIDIA GB200 NVL72 Blackwell机架上部署训练后Qwen3 235B模型的新研究。 GB200不仅是训练平台，更为大型MoE模型的高吞吐量推理带来了重大升级，相比Hopper实现显著进步。

Alibaba Cloud@alibaba_cloud · 5月12日22

🔍 What makes EventHouse the AI data backbone enterprises actually need? We're breaking down: ✅ EventHouse's core capabilities ✅ Its positioning in the AI era ✅ How it helps businesses unlock data value at unprecedented speed — and drive growth in a fast-moving market 👉 Learn more: https://int.alibabacloud.com/m/1000412862/ #EventBridge #EventHouse #Cloudnative #AI #AIAgent

译🔍 是什么让EventHouse成为企业真正需要的AI数据支柱？ 我们为您解析： ✅ EventHouse的核心能力 ✅ 其在AI时代的定位 ✅ 它如何帮助企业以前所未有的速度释放数据价值——并在快速变化的市场中推动增长 👉 了解更多：https://int.alibabacloud.com/m/1000412862/ #EventBridge #EventHouse #Cloudnative #AI #AIAgent

阿绎 AYi@AYi_AInotes · 5月12日64

Damn，Theo今天这条警告，看得我一身冷汗😰 他说，希望你们明白，这事儿只会越来越糟， 因为现在正在爆发的Mini Shai-Hulud供应链攻击， 已经从TanStack扩散到UiPath、Mistral AI相关包， 总计205个制品被毒化，覆盖AI/MCP、认证、工作流全领域， 最恐怖的是攻击速度， 攻击者在6分钟之内， 一口气发布了84个恶意版本， Socket在6分钟内全部标记， 但已经有无数项目自动拉取了更新， 这其实已经不是传统的维护者账号被盗事件了， 更像是CI/CD缓存投毒， 攻击者污染了GitHub Action的缓存， 构建时偷偷注入恶意依赖， 偷完所有云凭证、SSH密钥、AI工具配置， 再用偷来的token继续毒化更多包， 形成完美的蠕虫式自我繁殖闭环， 更让人绝望的是， 所有传统安全手段全他么失效了， 这些恶意包有合法的签名和provenance， 因为投毒发生在上游CI环节， 下游所有验证直接通过， 我们曾经引以为傲的安全锁，现在成了攻击者的通行证， 刺激不刺激？ 更刺激的是 AI正在把这场灾难加速到极致， 开发者用AI写代码， 用AI agent自动npm install， 自动review PR， 零人工审查成了常态， 攻击者的payload也专门瞄准.claude和.vscode目录， 直接寄生在你的整个AI开发流里， AI把开发速度拉满了多少倍， 攻击速度就拉满了多少倍， 最扎心的真相是， 现在更新依赖，是你能做的最高风险的动作， 比他么点陌生钓鱼链接还危险⚠️ 所以，别再npm update了， 别再用latest了， 强制lockfile加最小发布年龄， 每一个依赖升级都必须手动批准， 能自己写10行代码解决的，就绝对别引包， 今天就全量轮转你所有的云凭证和GitHub token吧！ @theo 说npm hell才刚刚开始， 我觉得他说的还是太保守了， 真正的地狱是， 我们还在用2015年的开发心智， 面对2026年的国家级蠕虫攻击！ #网络安全 #npm #供应链攻击

译Theo发出严重警告，新型软件供应链攻击“Mini Shai-Hulud”通过污染GitHub Action缓存，在CI/CD环节注入恶意依赖，已毒化从TanStack扩散到UiPath、Mistral AI相关包等总计205个制品。攻击速度极快，6分钟内发布84个恶意版本，并利用窃取的凭证形成蠕虫式自我繁殖闭环。由于攻击发生在上游，恶意包拥有合法签名，使传统安全机制失效。AI编程助手和自动化工具的普及使得零人工审查成为常态，加剧了风险。当前，更新依赖已成为极高风险操作，必须采取强制lockfile、手动批准升级、轮转所有凭证等严格措施。

OpenRouter@OpenRouter · 5月12日65

We’re thankful to have been a partner for Anthropic’s Claude Platform on AWS release! It’s seen production OpenRouter traffic, performed consistently, and is now labeled accordingly across all applicable Claude models.

译我们很荣幸能成为Anthropic的Claude平台在AWS发布的合作伙伴！ 它已承载生产环境的OpenRouter流量，表现稳定，现已在所有适用的Claude模型中完成相应标注。

ginobefun@hongming731 · 5月12日71

http://x.com/i/article/2053997483949453312 # BestBlogs 早报·05-12：Claude Code 智能体视图、OpenAI 部署公司、AI 英雄主义时代终结 在线阅读和收听：https://www.bestblogs.dev/explore/brief/2026-05-12 ## 导语 今天是 2026 年 5 月 12 日，欢迎收听 BestBlogs 每日早报。 今天的内容主线，可以用一个词来概括：落地。 Claude Code 上线智能体视图，开发者终于能在一块面板里统管所有并行会话，并发工作的认知成本大幅下降。这不只是一个 UI 改进，而是 AI 辅助编程从"单线程"跳到"多线程"的关键一跳——以往你需要在十几个终端标签和 tmux 格子之间来回横跳，现在一个左箭头就能看到全局。 与此同时，OpenAI 成立了独立部署子公司，初始投入超四十亿美元，并将一百五十名前线部署工程师直接派驻进企业内部。这是一个明确的信号：AI 的瓶颈已经从"模型够不够强"切换到"AI 能不能真正跑进生产"。卖许可证的时代告一段落，服务到现场才是下半场的竞争。 而在今天最值得细听的一篇内容里，亲历了 Anthropic 和 Google DeepMind 前沿训练的研究员姚顺宇，用四小时的对话说清楚了一件事：AI 行业的英雄主义时代已经过去了，这个行业真正稀缺的不是天才，而是靠谱、做事细、对自己的工作负责。 今天我们有三篇精讲，七篇速览，以及五篇扩展阅读。我们开始吧。 ## 精讲一：Claude Code 中的智能体视图 | Claude 来源：Claude Blog 背景：并行工作是开发者最痛的认知负担 如果你最近用 Claude Code 跑过多任务，应该对这个场景很熟悉：一个窗口在帮你写测试，另一个窗口在 review PR，第三个在搜索 bug。你需要在多个终端标签之间来回切换，同时还要记住"哪个任务跑到哪里了、哪个在等我回复"。这个认知开销随着并发任务数线性增长，最终会把人逼回单任务模式。 Claude Code 今天发布的智能体视图（Agent View），正是为了解决这个问题。 核心功能：一屏总览，按需介入 智能体视图的核心设计思路是：将所有并行会话集中在一个面板里，让你只在关键决策节点介入。 操作方式很简单：在任意会话中按左箭头，或在终端执行 claude agents，即可打开智能体视图。每一行显示一个会话的状态——是否在等你输入、当前的最后一条响应内容、上次交互时间。你可以快速"Peek"（预览）某个会话的最后一轮，如果需要决策，可以直接在预览界面回复，无需切换进入完整对话。会话收到回复后，自动继续往下跑。 对于长期运行的任务，可以通过 /bg 指令把当前会话发到后台，或者启动时直接用 claude --bg [task] 跳过前台，作为纯后台任务运行。 早期用户的实际使用模式 根据官方整理的早期用户反馈，有几个典型使用场景： 最常见的是批量下发任务：把多个想法或任务同时分配给多个 Claude 会话，每个会话可以配合不同的 skill，等一批 PR 同时就绪再集中审查。这个模式相当于把原本串行的开发流程改成了并行流水线。 另一个场景是管理长期运行的 Agent：比如 PR 守卫、Dashboard 更新器这类循环作业，在智能体视图里可以直接看到下一次运行时间，不需要再去查日志。 第三个是在多任务中快速切换：当你正在进行一个主任务时，突然想开一个新的快速问题或子任务，按左箭头打开智能体视图，新建会话，得到答案后右箭头回到原来的会话。Peek 功能会在答案就绪时直接显示，不需要你主动去切换。 为什么这个更新很重要 Claude Code 之前的多任务体验，高度依赖用户自己管理 tmux 或多终端标签，认知负担都压在开发者身上。智能体视图的意义在于，它把"多 Agent 协作"的组织成本从用户侧转移到了工具侧。 以研究预览形式，当前开放给 Pro、Max、Team、Enterprise 以及 API 用户，需要运行 claude agents 来手动开启。感兴趣可以访问官方文档了解更多。 这篇内容的完整阅读地址：https://www.bestblogs.dev/article/e8c4364d ## 精讲二：OpenAI 推出 OpenAI 部署公司，助力企业围绕智能构建业务 来源：OpenAI Blog 不是卖许可证，是派人到现场 OpenAI 今天宣布成立一家新的独立子公司：OpenAI Deployment Company（OpenAI 部署公司）。这家公司的使命，是帮助企业真正把 AI 系统用起来、用好——不是卖一个 API 调用权限，而是派人到企业里，贴着业务场景把 AI 推进生产。 核心执行力量是一批被称为 **FDE（Forward Deployed Engineers，前线部署工程师）**的人。通过收购应用 AI 咨询公司 Tomoro，OpenAI 部署公司从第一天起就配备了大约 150 名经验丰富的 FDE 和部署专家。这些人将常驻在客户的内部团队中，识别 AI 能发挥最大价值的场所，重新设计围绕 AI 的组织基础设施和关键工作流，并把阶段性收益固化成可持续的系统。 超四十亿美元的起步资金 OpenAI 部署公司以超过四十亿美元的初始投入正式启动，由 TPG 领投，Advent、Bain Capital 和 Brookfield 作为联合创始合伙人，Goldman Sachs、SoftBank Corp.、McKinsey、Bain & Company、Capgemini 等十九家机构也在其中。 OpenAI 对该子公司拥有多数所有权和控制权，客户无论是直接与 OpenAI 合作，还是通过 OpenAI 部署公司合作，都将获得统一的体验。未来募集的资金将用于扩大运营规模，以及继续收购能够加速 AI 部署的公司。 瓶颈从模型能力转向落地能力 OpenAI 在公告中直接说清楚了这一战略背景：过去几年，超过一百万家企业采用了 OpenAI 的产品和 API。通过这些部署，一个规律越来越清晰——企业 AI 的下一阶段，将由企业把技术真正跑进实际业务的能力来决定，而不是由模型本身有多强来决定。 这不是 OpenAI 的一厢情愿，而是一个在市场上已经反复被验证的现象：AI 系统训练好了、API 也打通了，但一旦到了需要真正改变业务流程的地方，就卡住了。卡在哪里？卡在组织惰性、流程设计、安全顾虑、以及缺乏专门了解 AI 局限性的工程人才。 OpenAI 部署公司的逻辑，是把这"最后一公里"的落地能力变成一项可规模化交付的服务，并且配上足够多的人力和资本让它真的做到。 一个标志性的业务模式转变 这一举动背后，是 OpenAI 对当前企业 AI 采用现状的清晰判断：技术已经够用了，但大量企业不知道如何把 AI 系统真正嵌入到关键业务流程中。 一个典型的 OpenAI 部署公司参与模式，从诊断开始：定位 AI 能在哪些业务场景创造最大价值，选出少量优先流程与客户领导层和运营团队共同确定目标，然后 FDE 进驻企业内部，完成系统设计、开发、测试和部署——把 OpenAI 的模型与客户的数据、工具、控制体系和业务流程连接起来，让团队在日常工作中可以稳定使用。 一个行业信号 从 Palantir 的部署工程师模式，到今天腾讯研究院分析的 FDE 岗位暴增，再到 OpenAI 直接成立独立公司——AI 从"研究机构"走向"商业化运营机构"的转型，今天的发布是一个明确的结构性确认。 值得注意的是，OpenAI 部署公司的独立运营，也意味着 OpenAI 正在把这个增长方向从内部项目升格为战略级业务，与 Google Cloud、AWS 等云厂商通过专业服务团队推动企业 AI 采用的路径，形成了直接的正面竞争。AI 落地能力，已经成为这轮竞争的新高地。 完整公告见：https://www.bestblogs.dev/article/f648cbd2 ## 精讲三：姚顺宇 4 小时访谈：在 Anthropic 训 Claude、AI 英雄主义时代已过去 来源：张小珺 Jùn｜商业访谈录 一个"小疯"的亲历者 今天要介绍的这期节目，是张小珺对姚顺宇长达四小时的深度访谈。姚顺宇毕业于清华和斯坦福，研究背景是理论物理（非厄米系统、量子物理、高能物理），博士毕业后转行进入 AI 领域。过去两年，他先后在 Anthropic 和 Google DeepMind 担任研究科学家，参与了 Claude 3.7、4.5 和 Gemini 3 等关键模型的开发。 按理说，这样的履历应该让人谦虚地说"只是参与了重要的项目"。事实上他确实这么说了——但他说这句话的语气，和表面意思恰好相反，带着一种对 AI 行业"神话个体"叙事的主动警惕。 "AI 不太需要脑子"是什么意思 访谈里，姚顺宇说了一句容易被断章取义的话： > "AI 这个事，本来也不太需要脑子——真的不太需要脑子。这个行业最重要的特质，就是靠谱，就是做事细，对自己做的事情负责任。" 听起来像在说 AI 研究很简单，其实他在说的是：AI 行业的核心竞争力，已经不再是某种难以复制的天才洞察，而是工程执行力。在预训练规模已经证明有效、主要技术路线基本确立的今天，能把一件事做踏实、不出岔子、持续迭代，反而是真正的稀缺能力。 他做了一个很有意思的比喻： > "现在大家都是冲浪的人，本质上是那个浪，而不是你那个冲浪的人。" 意思是，模型能力的演进（那个"浪"）才是主要动力，而研究员只是借着这个浪在推进工作。在这个背景下，对个体天赋的过度崇拜，很可能是一种认知偏差。 AI 英雄主义时代已经过去 这句话是访谈里的核心判断。 2020 年前后，AI 领域确实经历了一段个人英雄主义色彩浓厚的时期——一篇论文、一个算法、一个团队，可以显著推动整个领域的进步。但在今天，前沿模型的训练是一个需要数百人协作、跨越漫长时间线、依赖海量算力的工程行动。个人的贡献被稀释进了集体的系统中。 姚顺宇说： > "AI 个人英雄主义时代已经过去了，所以也没有什么英雄，有时候甚至觉得旧时代英雄有点蠢。" 这句话的语气很直，但背后的逻辑是认真的：如果我们继续用英雄主义的叙事框架来理解 AI 行业，就会把注意力放错地方——崇拜某个人，而不是理解整个系统是如何工作的。 在 Anthropic 训练 Claude 的第一手观察 访谈的技术部分，姚顺宇谈到了预训练的现状（他的判断是"Pre-train 没有到头"）、Coding 爆发的背后驱动力、"硬蒸"和"聪明的蒸"的本质区别，以及字节豆包在技术路线上的判断。 由于涉及企业机密，他在许多地方选择点到为止，但光是这些点到为止的判断，已经比大多数媒体报道包含更多信息密度。 录制于 2026 年 3 月，节目发出时 AI 领域又已发生了许多变化——他特别说明，请大家体谅内容的滞后性。这大概也是这个行业的宿命：任何"最新判断"，很快就会成为"历史记录"。 完整访谈：https://www.bestblogs.dev/podcast/a4391a3 ## 速览 今天还有七篇值得关注的内容，我来快速过一遍。 Anthropic 推出 Claude Managed Agents，助力规模化部署 Anthropic 官方宣布推出 Claude Managed Agents，面向需要大规模构建和部署 AI Agent 的用户。核心功能包括顾问策略（Prompt Caching 和 System Prompts）、代码执行环境，以及网络搜索能力。Anthropic 负责运营这项服务，所有新功能将在原生 Claude API 上线的同一天同步推出。这是 Anthropic 在企业级 Agent 基础设施层面迈出的重要一步，配合今天 Claude Code 智能体视图的发布，当前的方向非常清晰：把并发 Agent 的部署和管理，变成一种标准化、可托管的能力。 阅读地址：https://www.bestblogs.dev/status/2053868595394879553 Andrej Karpathy 谈人机交互的未来：从文本到交互式神经视频 Karpathy 分享了一个实用技巧：让 LLM 以 HTML 格式输出，然后在浏览器里打开——视觉效果比纯文本 Markdown 丰富得多。他借此延伸出一个更大的判断：音频是人类的优选输入方式，而视觉（图像、动画、视频）是人类的优选输出方式。他描绘了一条从纯文本到 Markdown 到 HTML，再到扩散模型直接生成的交互式神经视频的演进路径。更丰富的输入模态（比如直接用手指向屏幕内容描述上下文）也是他认为需要补全的一环。不算深度技术文章，但这种把实用技巧和长期判断连接起来的思维方式，值得学习。 阅读地址：https://www.bestblogs.dev/status/2053872850101285137 我们刚过了人类最后一个劳动节？AI 新职业的八个变化 腾讯研究院基于 7 家 AI 原生公司 2026 年劳动节当天的 1570 个在招岗位做了一次数据分析，得出了八个结构性结论。最值得关注的几条：岗位总量在 8 个月内翻了一倍多（从 718 涨到 1570）；AI 公司的人力重心从研发转向了产品和商业化，但工程师绝对数量没有下降；部署类岗位（尤其是 FDE，前线部署工程师）从零星几个暴涨到了上百个；推广者（销售、客户成功、合作伙伴）增速全类别最快，增长到了原来的四倍多。这份数据很适合拿来和今天 OpenAI 部署公司的新闻一起看，两个信号相互印证：AI 行业的下半场，商业化落地能力才是核心战场。 阅读地址：https://www.bestblogs.dev/article/9042fa70 Pinterest 如何构建生产级 MCP 生态系统 ByteByteGo 这篇文章，详细拆解了 Pinterest 内部是如何把 MCP（Model Context Protocol）做到生产级的。他们面对的问题是：五个 AI 接入面（内部聊天应用、IDE 插件、聊天机器人、CLI Agent、自主 Agent）加上十个内部工具，如果没有统一协议，就需要五十个定制集成，每多加一个面或工具都是乘法。MCP 把这个 N×M 的问题变成了 N+M 的问题。但真正的工程量不在协议本身，而在协议周边：中央注册表、双层认证系统、统一部署流水线，以及从第一天起就内嵌的可观测性。对于正在或打算在公司内推广 MCP 的人，这篇文章是一份很好的实践参考。 阅读地址：https://www.bestblogs.dev/article/dcf387de SocialReasoning-Bench 揭示当前 AI 智能体的局限性 微软研究院推出了一个新的基准测试——SocialReasoning-Bench，专门评估 AI Agent 在社交情境中的表现。测试设计了两个场景：日历协调和市场谈判。结论很刺激：前沿模型在这两类场景中，始终无法为用户争取到最大利益，大量价值被遗留在谈判桌上。即便通过 Prompt 明确指示"代表用户争取最大利益"，表现依然远低于一个称职的代理应该达到的水平。这意味着，在需要社交推理和利益博弈的场景中，AI Agent 现在其实并不可靠——这既是当前的局限，也是一个清晰的研究机会。 阅读地址：https://www.bestblogs.dev/article/d1e95073 再也无需手写项目更新：Notion 的 AI 赋能工程会议 来自 Notion 工程总监 Ryan Nystrom 的分享，演示了 AI 如何彻底重塑工程站会。核心是一个叫"Hot Potato"的自定义 Notion AI Agent，每天早上 9 点自动运行，对过去 24 小时的 Slack 对话、GitHub PR、Notion 任务库和 Honeycomb 指标（通过 MCP 接入）做一次"Map-Reduce"——开会的时候，AI 已经准备好了一份有内容的会议前置文档，团队直接跳过状态播报环节，进入实质讨论。还有一个叫 Boxy 的内部工具，通过在 Notion 评论里 @ AI Agent，带着 bug 描述或特性需求，Agent 会自动开一个 VM 写代码、跑测试、开 PR。这是工程管理流程里 AI 落地最完整的案例之一。 阅读地址：https://www.bestblogs.dev/video/121c5d7 Netflix 借助 Apache Druid 的区间感知缓存，84% 的查询结果来自缓存 Netflix 面临的问题很典型：实时分析系统每天处理万亿级数据行，而 Dashboard 上的查询通常是"过去 3 小时的错误率"这类滚动窗口查询。时间窗口每隔几分钟稍微一移，传统缓存系统就认为这是一个全新请求，完全重算。Netflix 引入了区间感知缓存策略：把查询拆解成稳定子区间和最新动态段，稳定部分命中缓存，最新的动态部分实时计算后合并。结果是 84% 的查询命中了缓存，查询负载下降了 33%，P90 查询时间提升了 66%。对做数据分析系统的工程师来说，这是一篇值得精读的系统设计案例。 阅读地址：https://www.bestblogs.dev/article/8ba3a393 ## 扩展阅读 今天还有五篇值得一读的好文，根据你的兴趣选择。 深度拆解：AI Agent Harness 的构造（宝玉的分享） AI Agent 在 Demo 上跑得不错，放进生产就开始掉链子——问题不在模型，在模型外围的基础设施。这篇文章系统拆解了 AI Agent Harness 的十二个核心组件，涵盖编排循环、工具调用、记忆管理、上下文管理，并对比了 Anthropic、OpenAI、LangChain 等主流框架的实现差异。如果你正在搭建或优化自己的 Agent 系统，这是一份很好的组件清单和设计参考。 阅读地址：https://www.bestblogs.dev/article/40a5fbba 在 Anthropic 的读心术之外，大模型黑盒迎来了真正的法医（腾讯科技） Anthropic 用 SAE（Sparse Autoencoder）路线做模型可解释性——通过激活分析读懂模型在"想什么"。而 Goodfire 的 Tom McGrath（Anthropic 和 DeepMind 可解释性团队前成员）走了一条不同的路：直接拆模型权重本身。他们的 VPD（对抗参数分解）方法，把一个 67M 的小语言模型拆成了数万个可以单独命名和修改的最小计算单元。这篇文章深入对比了这两条路线，并指出这是 AI 从炼金术走向科学的一颗信号弹。和今日精讲三在主题上也有共鸣：当我们更清楚地理解模型是如何工作的，"AI 英雄主义"的叙事会更进一步被解构。 阅读地址：https://www.bestblogs.dev/article/17cd71a0 PayPal 借助 Cursor 将路线图吞吐量提升 40%（Cursor Blog） PayPal 有 8000 名开发者，代码库跨越数十年。他们用 Cursor 完成了一次标志性的规模验证：原本需要 8 到 12 个月的 3000 个应用 Java 升级，两个月搞定。路线图吞吐量提升了 40%，部署节奏从每周变成了每日。这篇文章没有停在数字上，而是详细讲了 PayPal 如何从高影响力团队开始切入，逐步推广 Cursor 使用的过程。对于在大型企业内推广 AI 编程工具的人，这是一个可以直接借鉴的路径。 阅读地址：https://www.bestblogs.dev/article/839fd633 黄金时代论：Marc Andreessen 谈 AI 与劳动力的未来（a16z） Marc Andreessen 在播客访谈中阐述了他的"黄金时代论"：AI 不只是工具，而是一种普适的超能力，将劳动力从专业化角色转变为无所不包的"建设者"（Builder）。他认为，以前创建软件需要程序员、产品经理、设计师三类角色，AI Agent 现在让一个人可以同时做到三件事，进入"超级生产者"时代。这个判断和今天精讲三里姚顺宇的"集体主义胜利"论形成了有趣的张力——Andreessen 看到的是个体能力的放大，姚顺宇看到的是英雄主义的式微，两者其实都是真实的，只是站的维度不同。 阅读地址：https://www.bestblogs.dev/video/21d8b07 裁员潮将持续，直到我们学会发掘 AI 的商业价值（宝玉的分享） 这篇文章来自一位正处于裁员名单边缘的工程师，在 5 月 20 日公布结果前写下的思考——所以特别有真实感。他的核心论点是：当前的裁员潮，不是因为 AI 直接取代了员工，而是因为企业还没学会把海量 AI 投入转化成商业成果。AI 带来的是"投入"（更多代码、更多功能、更多方案），但"成果"（收入增长、用户增长、实际业务价值）没有同步提升。为了抵消高昂的 AI 支出和膨胀的组织内耗，裁员成了短期平衡手段。和今日腾讯研究院的那篇数据文章放在一起读，构成了同一个问题的两面：岗位在增加，但价值转化的压力也在增加。 阅读地址：https://www.bestblogs.dev/article/a77fcd78 ## 今日阅读路径 如果今天时间有限，我建议按以下顺序读三篇： 第一篇：Claude Code 中的智能体视图 如果你用 Claude Code，这是今天最值得立刻打开的一篇。跟着文章走一遍，开启 claude agents 体验一下智能体视图，20 分钟能建立起直接的使用感知。 第二篇：姚顺宇 4 小时访谈 这篇耗时最长，但信息密度极高。建议选一个整块的时间，把从 1:53:47 开始的"在 Anthropic 训练 Claude"部分认真听完——这是你能从一个亲历者口中听到的、关于前沿模型训练最真实的描述之一。 第三篇：我们刚过了人类最后一个劳动节 1570 个岗位的数据，比任何关于 AI 就业的预测文章都更有说服力。和今天 OpenAI 部署公司的新闻放在一起看，能帮助你快速建立对 AI 行业真实结构变化的感知。 今天的早报就到这里。感谢收听 BestBlogs 每日早报 EP55，我们明天见。 BestBlogs Pro 早鸟内测开放：你可以自定义订阅源、配置兴趣标签，每天获得一份属于自己的头条早报。欢迎抢先体验，并把反馈发回给我们：https://bestblogs.dev

译Claude Code发布智能体视图，将多会话管理集成于单一面板，旨在降低开发者并行工作的认知负担，标志着AI辅助编程进入“多线程”阶段。OpenAI宣布成立独立部署子公司，初始投入超四十亿美元，并派驻约150名前线部署工程师进入企业，表明AI竞争焦点已从模型能力转向实际落地能力。同时，行业观点认为，AI的“英雄主义时代”已经过去，当前稀缺的是靠谱、细致、负责任的工程执行力，而非天才洞察。

ginobefun@hongming731 · 5月12日72

OpenAI 推出 OpenAI 部署公司 OpenAI 今天宣布成立独立子公司 OpenAI Deployment Company，专门解决企业 AI 真正落地的问题。 核心角色是一批前线部署工程师（FDE，Forward Deployed Engineers）。他们会常驻进企业内部，和业务团队、技术团队以及一线员工一起工作，找出 AI 能创造最大价值的场景，重新设计关键流程，把 AI 系统跑进生产环境。通过收购 AI 咨询公司 Tomoro，这家新公司从第一天起就拥有了约 150 名有实战经验的 FDE 和部署专家。 初始投入超过 40 亿美元，由 TPG 领投，Goldman Sachs、SoftBank、McKinsey、Bain & Company 等 19 家机构参与，OpenAI 持有多数股权。 这次成立的战略背景，OpenAI 在公告里说得很清楚：过去几年，超过 100 万家企业采用了 OpenAI 的产品和 API。从这些部署里看到的规律是：企业 AI 下一阶段的决定因素，已经从模型本身有多强，转向了企业能否把技术真正跑进实际业务。技术够用了，瓶颈在落地。 典型的部署方式：先诊断，找出哪些场景 AI 能创造最大价值；和客户管理层确定优先流程；然后 FDE 进驻内部，完成系统设计、开发和部署，把 OpenAI 的模型与客户的数据和工作流接起来。 从 Palantir 的驻场工程师模式，到腾讯研究院记录的 FDE 岗位在 8 个月内暴增，再到 OpenAI 直接成立独立公司：AI 落地能力已经成为这轮竞争的新主轴。OpenAI 把这个方向从内部项目升格为战略级业务，与 Google Cloud、AWS 等云厂商的企业服务团队形成直接竞争。

译OpenAI宣布成立独立子公司OpenAI Deployment Company，旨在解决企业AI落地难题。该公司通过收购AI咨询公司Tomoro，组建了约150名前线部署工程师团队，将常驻企业内部，识别高价值场景并将AI系统整合至工作流。OpenAI指出，当前企业AI的瓶颈已从模型能力转向实际业务落地。此轮融资超40亿美元，由TPG领投。此举标志着AI竞争焦点转向落地能力，OpenAI将该业务提升至战略层级，直接与主要云厂商的企业服务竞争。

meng shao@shao__meng · 5月12日68

Claude Platform on AWS 正式上线 和已有的 Claude on Amazon Bedrock 并行存在，两者并非升级关系，是两条不同定位的产品线： 服务运营方： · Anthropic · AWS 数据处理方： · Anthropic（数据离开 AWS 边界） · AWS（保持在 AWS 边界内） 功能完整度： · 与原生 Claude API 完全对齐，新功能 Day-One 同步 · 滞后，部分能力缺失 适用人群： · 想要"原汁原味" Claude 全功能体验的客户 · 有严格数据驻留 / 必须留在 AWS 边界内的客户 它解决了什么实际问题 过去 AWS 大客户用 Claude 面临一个尴尬： · 走 Bedrock → 享受 AWS 计费打通、IAM 权限统一，但新功能往往滞后数周到数月，且很多 Claude 原生工具（Skills、Managed Agents、Advisor 等）压根没有。 · 走 Anthropic 直连 API → 功能齐全，但独立账单、独立账号体系、独立采购流程，企业财务和安全合规绕道。 平台版的设计正是把这两者的"好处"做了拼接： · 认证：走 AWS IAM，沿用既有权限策略 · 审计日志：走 CloudTrail · 计费：合并进 AWS 单一发票，可抵扣已有的 AWS Commitment（承诺消费额） · 功能：与原生 Claude API 100% 对齐，新功能与 beta 同日上线 当天即可使用的能力清单 平台版默认带齐 Anthropic 原生 API 的全部组件： · Claude Managed Agents（beta） —— 规模化部署 Agent · Advisor strategy（beta） —— 调用更强模型为 Agent 提供智力增援 · Web search / Web fetch —— 实时联网 · Code execution —— API 内直接执行 Python、生成可视化 · Files API（beta） —— 跨会话引用文档 · Skills（beta） —— 注入最佳实践，输出更稳定 · MCP Connector（beta） —— 无需写客户端即可接入任意远程 MCP server · Prompt caching —— 重复上下文降本降延迟 · Citations —— 响应可溯源 · Batch processing —— 大批量异步任务 · Claude Console —— 含 prompt 优化器、生成器、评估工具 可用模型：Claude Opus 4.7、Sonnet 4.6、Haiku 4.5，新模型上线即同步。 可用区域：大多数 AWS 商业区域，支持 global 与 U.S. 两种推理地理范围。 决策指南：你应该选哪条路？ 选平台版，如果你需要： · Claude 全部最新能力（特别是 Managed Agents、Skills、Advisor） · 把 Anthropic 消费抵扣 AWS Commitment · 接受数据离开 AWS 边界由 Anthropic 处理 选 Bedrock 版，如果你需要： · 严格的区域数据驻留 · 数据必须在 AWS 基础设施内处理（金融、政府、医疗等强合规场景） · 可以接受功能滞后

译Anthropic在AWS上正式推出Claude Platform，与现有的Claude on Amazon Bedrock形成两条独立产品线。平台版由双方共同运营，数据由Anthropic处理，但功能与原生API完全对齐且同步更新。其核心优势在于整合了AWS的IAM认证、CloudTrail审计、统一账单及承诺消费抵扣，同时提供Claude全功能套件，包括Managed Agents、Skills、联网搜索等。该服务适合需要完整功能并能接受数据由Anthropic处理的客户，而Bedrock版则面向对数据必须驻留AWS有严格合规要求的场景。

Berryxia.AI@berryxia · 5月12日78

Claude Managed Agents 现在可以直接跑在你已有的 AWS 账号里了！ 账单、IAM、安全审查全都不用出 AWS。 Anthropic 今天正式推出 Claude Platform on AWS，把原生 API 的全部能力（包括 Managed Agents、prompt caching、预置工具等）全部搬进 AWS。 工作负载、计费、身份权限全部留在企业自己的 AWS 环境里。 这才是真正的企业级杀手级更新。 以前大公司想上前沿 AI agent，最头疼的从来不是模型能力，而是“数据不能出 AWS”“采购流程走不通”“安全审查要半年”。 现在 Anthropic 直接把这些障碍一次性干掉。 企业采用 Claude 的最后一道墙，被彻底推倒了。 详情在这里👉 https://claude.com/blog/claude-platform-on-aws

译Anthropic正式在AWS上推出Claude Platform，使开发者能在其自有AWS环境中使用与原生API相同的模型和功能，包括Claude Managed Agents。关键突破在于工作负载、计费和IAM权限全部保留在企业自身的AWS账户内，无需数据出境。此举直接解决了大型企业以往采用前沿AI代理时面临的数据安全、采购流程和安全审查等核心障碍，为企业级应用扫清了最后的关键阻碍。

ClaudeDevs@ClaudeDevs · 5月12日76

We're introducing the Claude Platform on AWS. This gives developers access to the same models and features as our native API, including Claude Managed Agents! Workloads, billing, and IAM stay inside AWS. Learn more: https://claude.com/blog/claude-platform-on-aws

译Anthropic在AWS上正式推出Claude平台，使开发者能够在AWS环境中直接使用与原生API完全相同的Claude模型和全部功能，包括Claude托管智能体。该平台允许企业将计算负载、账单管理和IAM权限控制完全保留在AWS生态系统内部，同时由Anthropic负责平台的运营与维护。关键特性包括支持大规模构建和部署智能体，并能使用顾问策略、代码执行、网络搜索等高级功能。平台承诺所有新功能将在原生Claude API上线当日同步提供给AWS用户，确保了功能的一致性。

Chubby♨️@kimmonismus · 5月12日65

Anthropic just made Claude much easier to buy and deploy for AWS customers. The new Claude Platform on AWS is not a new model launch. It is a distribution and enterprise adoption move! Companies can now access the native Claude Platform with AWS authentication, AWS billing, commitment retirement, and governance tooling - without being forced into Bedrock. Claude Platform on AWS gives customers the full native Claude experience, but Anthropic operates the service and data is processed outside the AWS boundary. Big move from Anthropic. big for enterprise

译Anthropic在AWS上推出了Claude平台，此举并非发布新模型，而是旨在简化企业采购与部署流程的战略举措。AWS客户现在可以直接通过AWS的身份验证、账单系统、承诺消费抵扣及治理工具访问原生Claude平台，无需强制使用Amazon Bedrock服务。该平台为客户提供完整的原生Claude体验，但服务本身由Anthropic运营，数据处理在AWS的边界之外进行。这显著降低了企业用户的采用门槛，是Anthropic推动其模型在企业市场广泛采用的关键一步。

OpenCode@opencode · 5月12日49

OpenCode x DeepSeek V4 Flash - free for a limited time DeepSeek V4 Flash is currently our most popular model in Go Give it a try if you haven’t already

译OpenCode x DeepSeek V4 Flash - 限时免费 DeepSeek V4 Flash目前是我们Go中最受欢迎的模型 如果还没尝试过，快来体验吧

Greg Brockman@gdb · 5月12日71

Introducing the OpenAI Deployment Company, which will help businesses maximally succeed with their deployments of AI. Starting with 150 Forward Deployed Engineers and Deployment Specialists, and $4 billion of initial investment from 19 partners.

译OpenAI宣布成立一家由其控股的部署公司，旨在帮助企业成功部署和应用AI技术。该公司整合了19家领先的投资机构、咨询公司和系统集成商作为合作伙伴，并获得了40亿美元的初始投资。启动团队包括150名前沿部署工程师和部署专家，核心目标是协助各类组织将前沿AI技术投入生产环境，以产生实际的商业影响。

SemiAnalysis@SemiAnalysis_ · 5月12日48

Everybody knows about the toilet maker Toto and MSG umami inventor Ajinomoto that are powering AI, but have you heard of the Taiwanese kitchen equipment supplier that’s in Nvidia servers? (1/5) 🧵

译众所周知，卫浴制造商Toto和鲜味发明者味之素正为AI提供动力，但你们听说过英伟达服务器里的台湾厨房设备供应商吗？(1/5) 🧵

阿绎 AYi@AYi_AInotes · 5月12日63

Damn，Anthropic这波操作，直接把我看傻了🤯 我看评论区很多人拍马屁说恭喜Claude上架AWS这个大云厂商。 哪跟哪啊，其实根本不是一回事。 我直接说， 本质上就是Anthropic直接把自己的直营店， 开进了AWS的大本营。 以前的Bedrock模式， Anthropic把模型批发给AWS， 功能迭代永远慢半拍， 产品节奏AWS说了算， 现在的Platform模式， Anthropic自己运营服务， 所有新特性和原生Claude同日上线， 连Managed Agents这些beta能力， 今天就能直接用。 最狠的是计费和身份全打通， 不用额外开户， 也不用换密钥， 甚至不用谈新合同， 你已经付给AWS的承诺额度， 直接就能抵Claude的消费， 等于钱已经在账户里，当然是不用白不用。 这个双轨制更是杀招， 敏感项目走Bedrock，数据不出AWS边界。 创新项目走Platform， 用最快最新的能力， 最保守和最激进的两拨企业客户， 一次性全吃下来。 就好像以前是云厂商卖模型， 现在是模型厂商用云厂商卖自己。 企业换模型的迁移成本， 这波直接被拉到了前所未有的高度， 以后谁再想从Claude切去别的模型，等于要把整个AWS的IAM、账单、权限体系全推翻重来。 屌炸天的操作啊哈哈， 这他喵才是真正的云锁-in升级版啊， 放个暴论在这， 今天就开始在AWS里跑Managed Agents的团队， 半年后会把同行甩得连尾灯都看不见， 不信咱们半年后再来看。

译Anthropic在AWS正式推出Claude Platform，从通过Bedrock批发模型转变为直接运营。新平台使企业客户能使用与原生Claude完全同步的最新功能，包括测试版能力，并实现了与AWS的计费、身份认证和承诺消费额度无缝打通。此举提供了双轨选择：敏感数据项目可通过Bedrock留在AWS边界内，而追求创新的项目则可使用Platform获取最快最新的能力。这种深度集成大幅提高了企业更换AI模型的迁移成本，因为切换意味着要重构整个AWS的IAM、账单和权限体系，被视作强大的“云锁定”策略升级。

Claude@claudeai · 5月12日62

The Claude Platform on AWS is now generally available. AWS customers get the full set of Claude API features, with AWS authentication, billing, and commitment retirement.

译Claude平台现已在AWS全面上线。 AWS客户可获得全套Claude API功能，并享受AWS身份验证、计费及承诺金抵扣服务。

Chubby♨️@kimmonismus · 5月11日79

OpenAI is no longer just selling models. With its new Deployment Company, OpenAI is moving deeper into the enterprise stack: not only giving companies access to AI models, but helping them actually deploy AI inside real business workflows. (A push presumably intended to make OpenAI more attractive than Anthropic in the enterprise sector.) The key idea: Forward Deployed Engineers. These are engineers who work closely with customers, understand their internal processes, connect AI to existing tools and data, and build systems that actually run in production. The value comes when AI is embedded into core operations: sales, legal, customer support, software engineering, finance, research, and supply chains. That is the gap OpenAI now wants to own. The obvious comparison is Palantir. Palantir became powerful by sending engineers into complex organizations and building deeply integrated software systems around their data and decisions. OpenAI is now applying a similar model to frontier AI. This is a major strategic behind it? OpenAI does not want to be just the model provider. It wants to become the deployment layer of the AI economy.

译OpenAI正从单纯销售模型转向深入企业技术栈，其新成立的“部署公司”旨在通过“前沿部署工程师”帮助客户将AI深度集成到实际业务流程中。此举意在增强其企业市场竞争力，对标Palantir的深度集成服务模式。OpenAI收购Tomoro，将立即获得150名经验丰富的部署工程师与专家，以加速这一战略。其核心目标是成为AI经济的“部署层”，而不仅仅是模型提供商。

meng shao@shao__meng · 5月11日83

OpenAI 成立"部署公司"(DeployCo)：从模型供应商走向企业级落地服务商 OpenAI 宣布成立 OpenAI Deployment Company（DeployCo），独立但由 OpenAI 控股的子公司，专门帮助企业把前沿 AI 真正嵌入到核心业务流程中。同时收购英国应用 AI 咨询公司 Tomoro，并联合 19 家全球顶级 PE 与咨询集成商组成"联合舰队"，启动资金超过 40 亿美元。 https://openai.com/index/openai-launches-the-deployment-company/ 新公司定位 · 由 OpenAI 多数股权控股、控制 · 作为独立业务单元运营，拥有自己的节奏与客户运营模式 · 但保持与 OpenAI 研究、产品、内部部署团队的紧密连接 · 核心工种：Forward Deployed Engineer（FDE，前置部署工程师） 收购 Tomoro · 应用 AI 咨询与工程公司，客户包括 Tesco、Virgin Atlantic、Supercell · 带来约 150 名经验丰富的 FDE 与部署专家 · 让 DeployCo "第一天就有人能干活" 合作伙伴结构 · 牵头投资方：TPG · 联合创始合伙人：Advent、Bain Capital、Brookfield · 创始合伙人：B Capital、BBVA、Emergence Capital、Goanna、Goldman Sachs、SoftBank Corp.、Warburg Pincus、WCAS · 咨询与系统集成方：Bain & Company、Capgemini、McKinsey & Company 19 家投资与咨询伙伴的被投企业组合共覆盖 2000+ 家公司，加上集成商的客户网络则达"数千家"。 资金体量 · 启动资金 40 亿美元以上 · 用途：扩大运营规模 + 持续收购能加速 AI 部署的公司 DeployCo 的典型交付流程： · 诊断 → 找到最高价值的 AI 切入点 · 选定少数优先工作流（不是大而全） · 驻场设计、构建、测试、部署生产系统 · 把 OpenAI 模型连接到客户的数据、工具、控制、业务流程 "Forward Deployed Engineer"几乎是 Palantir 商业模式的代名词——工程师驻场客户、围绕真实业务流程构建系统、然后把通用模式沉淀回平台。

译OpenAI宣布成立由其控股的独立子公司OpenAI Deployment Company，旨在帮助企业将前沿AI技术深度集成至核心业务流程。该公司通过收购英国咨询公司Tomoro获得了约150名部署专家，并联合了包括TPG、贝恩资本、高盛等在内的19家顶级投资机构和咨询集成商，形成覆盖数千家企业的服务网络。启动资金超过40亿美元，将用于扩大运营和持续收购。其核心工作模式是派遣“前置部署工程师”驻场，为客户量身定制并部署AI生产系统。

凡人小北@frxiaobei · 5月11日82

OpenAI 成立 Deployment Company，拉来麦肯锡、贝恩、凯捷当股东。 画个重点：不是合作伙伴，是直接成立公司成为股东了！！！ 这个结构下，大概就是 PE 机构带资入场，被投企业顺势成为天然客户池，然后咨询公司负责把 AI 渗透进甲方的每条工作流。OpenAI 自己也不用跑销售，客户网络直接继承了几大 PE 的产业版图。 其实 5.4 Anthropic 也宣布与高盛、Blackstone 成立类似合资公司。不过跟 OpenAI 那边相比规模小不少，15 亿 vs 100 亿，但逻辑一模一样，都是派驻工程师进企业重构工作流，靠 PE 被投企业做客户池。​​​​​​​​​​​​​​​​ 模型到了这个时间点，配合上 coding harness 能力已经爆了，企业 AI 落地的战场正式打响，而且两家同时选择用联姻金融资本+咨询机构的方式开局，说明单靠 API 卖模型已经到天花板了。 国内这边估计很快会有跟进动作，华为、阿里、字节在企业侧早有布局，这个打法对他们并不陌生，只是规模和结构会有本土化变体。 麦肯锡、贝恩、凯捷这些公司入局，传统 IT 咨询/实施类公司（比如埃森哲）的企业 AI 份额受挤压压力持续加大，PE 机构把被投企业批量导入，相当于给 OpenAI 锁定了一批中大型 B 端客户，短期应该利好 AI 应用层估值逻辑。加上川普访华，可以入些相关股票了。 国内对标来看，能做驻场落地的 AI 服务商会比纯 SaaS 模式更受资本青睐，人力密集型的 AI 交付模式反而成了壁垒，利好华为啊。

译OpenAI 成立由其控股的部署公司，引入麦肯锡、贝恩、凯捷等咨询公司及多家投资机构作为股东，旨在共同推动前沿AI在企业生产环境中的落地。其核心模式是私募机构提供资金与被投企业客户资源，咨询公司负责将AI深度集成至企业工作流，使OpenAI能快速承接庞大B端客户网络。几乎同时，Anthropic也与高盛等成立了类似合资公司。这标志着企业AI落地战役进入新阶段，单纯售卖API的模式面临瓶颈，深度驻场交付成为新竞争壁垒。预计国内厂商将跟进类似策略。