AI行业 on KnightLi的博客

AI 数学里程碑：OpenAI 推翻 Erdős 单位距离猜想意味着什么

Fri, 22 May 2026 22:21:46 +0800

OpenAI 在 2026 年 5 月 20 日公布了一项很不寻常的研究结果：内部一款通用推理模型在平面单位距离问题上找到新的构造，推翻了数学界长期相信的一个上界猜想。

这不是一个普通聊天机器人随口给出的答案，而是 OpenAI 内部通用推理模型在一组 Erdős 问题评估中产生的证明。证明已经由外部数学家检查，OpenAI 也公开了证明文本、配套说明和模型推理思路的删节版。

问题是什么

平面单位距离问题由 Paul Erdős 在 1946 年提出。问题本身很好理解：在平面上放置 n 个点，最多能有多少对点之间的距离刚好等于 1？

数学上通常把这个最大数量记为 u(n)。如果把点排成一条直线，可以得到大约 n - 1 对单位距离。若把点排成方形网格，每个点和上下左右相邻点形成单位距离，数量大约可以达到 2n。Erdős 还给出过更精细的缩放方形网格构造，使单位距离点对数量达到 n^(1+C/log log n) 的量级。

长期以来，数学界普遍认为这类网格构造接近最优。对应的猜想可以粗略写成：u(n) 不会超过 n^(1+o(1))。这里的 o(1) 会随着 n 增大趋近于 0，意思是单位距离点对数可以比线性增长略快，但不应该出现一个固定指数优势。

OpenAI 模型给出的结果打破了这个直觉。它构造出一族无限多的例子：对于无穷多个 n，可以得到至少 n^(1+δ) 个单位距离点对，其中 δ 是固定正数。OpenAI 官方文章提到，原始 AI 证明没有给出明确的 δ 数值，但 Will Sawin 后续改进显示可以取 δ = 0.014。

证明过程为什么特别

这次突破最有意思的地方，不只是结论本身，而是证明路线。

Erdős 早期构造可以通过高斯整数理解。高斯整数形如 a+bi，它把普通整数扩展到复平面中，并保留了类似唯一分解的性质。借助这种数论结构，可以解释为什么某些缩放后的网格会产生很多单位距离。

OpenAI 模型没有继续沿着普通几何直觉推进，而是把问题带到更复杂的代数数论中。官方解释称，新证明使用更一般的代数数域，利用其中更丰富的对称结构制造大量单位长度差，从而在平面中形成更多距离刚好为 1 的点对。

更技术一点说，证明涉及无限类域塔和 Golod-Shafarevich 理论。这些工具对代数数论研究者并不陌生，但它们突然出现在一个欧氏平面里的组合几何问题中，才是外部专家认为这项结果很有启发性的原因。

这个过程大致可以拆成四步：

从单位距离问题的传统网格构造出发，把“点之间差值长度为 1”转化为代数结构中的范数和差值问题。
用更复杂的代数数域替代高斯整数，让可用的单位长度差数量变多。
借助无限类域塔和 Golod-Shafarevich 理论证明所需数域确实存在。
把代数构造重新落回平面点集，得到在无穷多个 n 上超过 n^(1+o(1)) 的单位距离点对数量。

也就是说，AI 不是简单搜索已有证明，而是把组合几何和代数数论连接起来，提出了一条人类主流直觉之外的构造路线。

专家反应

OpenAI 官方文章列出了多位数学家的评价，整体态度相当积极，但重点并不完全相同。

组合数学家 Noga Alon 认为，这个问题是 Erdős 最喜欢的问题之一，几乎所有组合几何研究者都思考过它。让他意外的是，正确答案并不符合长期相信的 n^(1+o(1)) 图景，而新构造还优雅地使用了高级代数数论工具。

菲尔兹奖得主 Tim Gowers 把这件事称为 AI 数学的里程碑。他的判断很重：如果这篇论文由人类写成并投稿到顶级数学期刊，他会毫不犹豫建议接收。这个评价真正强调的是证明质量，而不是 AI 话题本身。

数论学者 Arul Shankar 的关注点在模型能力。他认为这篇论文说明当前 AI 模型已经不只是数学家的助手，还能够提出原创且巧妙的想法，并把它们推进到完整证明。

Thomas Bloom 在配套说明里提出了一个更审慎的标准：评价 AI 生成证明，关键要看它有没有让人类更理解问题。在他看来，这个结果给出的答案是谨慎的肯定。它说明数论构造对离散几何的影响可能比过去想象得更深。

这些反应共同指向一点：数学界并不是因为“AI 做出来了”就接受结果，而是因为证明可以被检查，路线能解释问题，结论也确实改变了原有理解。

这是否意味着 AI 替代数学家

还不能这样理解。

这次案例里，AI 提出了关键构造和证明路线，但结果成为严肃数学成果，仍然依赖外部数学家的检查、解释和补充。配套论文的作用也很重要：它把 AI 给出的证明放回数学语境中，解释为什么这个构造重要、它与已有研究有什么关系、未来可能影响哪些问题。

更合理的判断是：AI 开始进入数学研究上游，但没有把人类专家挤出研究过程。

过去几年，AI 在数学里的角色主要是解竞赛题、生成证明草稿、辅助形式化证明、检索资料或改写论证。这些任务通常仍由人类指定方向。单位距离问题这次的不同之处在于，模型面对长期开放问题，提出了新构造，并把论证推进到可审查状态。

这会改变数学研究中的劳动分配。模型可能更擅长批量尝试长链条路线、连接远距离知识、探索研究者不一定优先尝试的方向。人类数学家的价值则会集中到几个更高层的问题上：

选择哪些问题值得研究。
判断 AI 给出的结果是否可信。
解释结果在学科中的位置。
决定哪些路线值得继续投入。

对未来科研的影响

这件事对 AI 行业的意义，可能比对单个数学猜想的意义更大。

数学是检验推理能力的理想场景。问题定义清楚，证明能被逐步检查，一条长论证只要中间断裂就无法成立。如果模型能在数学中保持复杂论证的连贯性，并连接不同学科工具，那么类似能力也可能迁移到其他科研领域。

OpenAI 官方文章也把影响延伸到生物、物理、材料科学、工程和医学。这里不能简单理解为“AI 很快会自动做科学发现”。更现实的变化是，AI 可能先成为科研中的路线生成器和假设放大器：它提出大量可能路径，人类专家筛选、验证、解释，再把少数有价值的路径推进下去。

这会带来三类变化。

第一，研究速度可能被拉高。很多开放问题不是没人能理解，而是可尝试路线太多、跨领域成本太高。AI 如果能持续提出可审查构造，会扩大研究者的搜索半径。

第二，跨学科连接会变得更常见。单位距离问题原本属于组合几何，新证明却借助代数数论。未来类似“远距离知识迁移”可能成为 AI 科研工具的重要价值。

第三，专家审核会更重要。AI 生成的路线越多，越需要可靠的验证机制。数学可以用证明审查来过滤错误，其他实验科学还需要实验、数据、复现和安全评估。AI 越像研究者，人类判断越不能省略。

这和 IMO 解题有什么不同

过去几年，AI 数学能力常常通过竞赛题来展示，比如 IMO 难度题目、大学数学题或者形式化证明任务。这些测试很重要，但它们和这次单位距离问题突破不是一类事情。

竞赛题通常有明确题面、确定答案和相对固定的解题范围。模型要做的是在有限时间内找到一条可验证的解法。即使题目很难，它仍然属于“已被设计出来的问题”，背后通常存在人类出题者预期的解题路径。

开放数学问题则不同。它没有标准答案，也不保证现有方法能解决。研究者需要判断哪些方向值得尝试，哪些工具可能跨领域迁移，哪些构造虽然反直觉但有机会成立。OpenAI 这次结果的意义正在这里：模型不是只解一道已知题，而是在一个长期开放问题中提出新构造，并改变了原有猜想。

所以，这次突破更接近数学研究，而不是数学考试。

为什么数学适合检验 AI 推理

数学是检验 AI 推理能力的高压场景，因为它很难靠流畅表达蒙混过关。

一条数学证明必须层层成立。定义是否准确、引理是否可用、推导是否跳步、结论是否真的覆盖目标命题，都可以被专家逐段检查。只要中间某一步断裂，整条证明就站不住。

这让数学比很多开放式写作任务更适合作为推理能力的测试场。模型不仅要给出看起来合理的答案，还要让答案经得起复核。单位距离问题这次尤其有代表性：结论重要，证明路线也能被外部数学家审查和解释。

当然，数学也不是唯一标准。现实科研还涉及实验误差、数据质量、设备条件和工程约束。但数学提供了一个清晰窗口：如果模型能在这里产出新证明，至少说明它在长链条推理和跨领域连接上已经出现了值得认真对待的能力。

AI 证明为什么仍然需要人类数学家

AI 给出证明，并不等于人类数学家可以退出。

第一，证明需要验证。AI 生成的论证可能有漏洞、隐藏假设或符号误用，必须由专家检查。第二，证明需要解释。一个结果为什么重要、它和已有理论有什么关系、它打开了哪些新问题，这些都不是形式上“证完了”就自动完成的。

第三，证明还需要改进。OpenAI 原始证明没有给出明确的 δ，后续由 Will Sawin 改进到可以取 δ = 0.014。这说明人类专家仍然在压缩、澄清和增强结果。

更重要的是，数学研究不是只追求“有一个证明”。研究者还要判断哪条路线更有价值，哪些问题值得继续推进，哪些构造可能迁移到其他领域。AI 可以扩大搜索空间，但学术判断仍然需要人。

这对 OpenAI 模型路线意味着什么

从产品视角看，这件事说明 OpenAI 的模型路线正在从“回答问题的聊天助手”，转向“能参与复杂任务的推理系统”。

聊天助手强调对话、总结、写作和工具调用。科研推理系统则要能长期保持目标，组合多个领域的知识，生成可验证的中间步骤，并把探索结果整理成专家能审查的形式。单位距离问题这次展示的，正是后者的一部分。

这也解释了为什么 OpenAI 会公开证明、配套说明和模型推理摘要。对科研任务来说，最终答案本身不够，过程也必须能被检查。未来面向科研、工程和专业知识工作的模型，很可能会越来越强调可追踪推理、可复核输出和专家协作接口。

换句话说，模型不只是更会聊天，而是更像一个可以分担研究探索的系统。

普通读者该怎么看

这件事不宜神化，也不该轻描淡写。

不宜神化，是因为 AI 还没有变成独立科学家。这个结果仍然需要人类数学家检查、解释和改进，也需要放回数学共同体中接受长期审视。一次突破不能直接推出“所有科学问题都快被 AI 自动解决”。

不该低估，是因为它确实越过了一个重要门槛。模型不只是复述知识，也不只是解训练过的相似题，而是在开放问题中给出新构造，并让专家认为它有数学价值。

更稳妥的理解是：AI 正在成为研究者的强力协作者。它可能先改变的是探索速度、跨领域连接和证明草稿生成，而不是一夜之间替代学术共同体。对普通读者来说，最值得关注的不是“AI 是否取代数学家”，而是“人类如何利用 AI 扩大能研究的问题范围”。

结论

OpenAI 这次结果的重要性，不只是推翻了一个近 80 年的猜想，而是展示了通用推理模型参与前沿研究的一种形态：提出构造、连接跨领域工具、产出可由专家审查的证明。

它还不是“AI 独立科学家”的终点，但已经不是简单的解题助手。未来几年，数学可能会继续成为观察 AI 科研能力的窗口：哪些问题能被模型推进，哪些证明需要人类补全，哪些跨领域连接会被重新发现，都值得持续关注。

参考资料：

OpenAI：《An OpenAI model has disproved a central conjecture in discrete geometry》：https://openai.com/index/model-disproves-discrete-geometry-conjecture/
OpenAI proof PDF：https://cdn.openai.com/pdf/74c24085-19b0-4534-9c90-465b8e29ad73/unit-distance-proof.pdf
OpenAI companion remarks：https://cdn.openai.com/pdf/74c24085-19b0-4534-9c90-465b8e29ad73/unit-distance-remarks.pdf
OpenAI model reasoning summary：https://cdn.openai.com/pdf/1625eff6-5ac1-40d8-b1db-5d5cf925de8b/unit-distance-cot.pdf

Google I/O 之后，GPT 和 Gemini 订阅怎么选？普通用户与开发者对比

Thu, 21 May 2026 08:33:14 +0800

Google I/O 2026 之后，很多人的 AI 订阅选择变复杂了。

以前问题比较简单：写作、问答、编程、文件分析，大多数人优先看 ChatGPT；如果深度使用 Google 搜索、Android、Gmail、Docs、YouTube，再考虑 Gemini。现在不一样了。Google 在 I/O 上把 Gemini 3.5 Flash、Gemini Omni、Antigravity 2.0、Gemini API Managed Agents、Google AI Studio 和 AI Ultra 订阅一起推出来，Gemini 生态开始从“可选项”变成“强竞争主线”。

这篇文章不做抽象模型跑分，而是回答一个实际问题：普通用户、开发者、内容创作者和企业用户，到底该订阅 GPT / ChatGPT，还是 Gemini / Google AI？

注意：AI 订阅价格、额度、地区和模型可用性变化很快。本文写作时间是 2026 年 5 月 21 日，正式订阅前应以 OpenAI 与 Google 当前页面为准。

先说结论

如果你只想选一个主力订阅，可以按这个逻辑：

日常写作、问答、文件分析、泛办公、中文英文混合使用：优先 ChatGPT Plus。
高频编程、需要 Codex、复杂推理、项目级代码任务：优先 ChatGPT Plus / Pro，再按额度决定是否升级。
深度使用 Google 生态、Gmail、Docs、Drive、Android、Search：优先 Gemini / Google AI Pro。
重点做视频、AI 影像、Google Flow、YouTube Shorts、Gemini Omni：优先 Google AI Pro / Ultra。
需要 Antigravity、Gemini API Managed Agents、AI Studio 到 Android 的工作流：重点看 Google AI Pro / Ultra。
企业团队：不要只看个人订阅，重点看 Business / Enterprise、Workspace、权限、审计和数据边界。
预算有限：一个主力付费订阅 + 另一个平台免费层或按量 API，通常比同时订两个高阶套餐更划算。

一句话：GPT 更像通用生产力和代码助手主力；Gemini 在 Google I/O 之后更像 Google 生态里的系统级 AI 套件。

Google I/O 之后，Gemini 发生了什么变化

Google I/O 2026 让 Gemini 的价值不再只取决于 Gemini App 本身。

几个关键变化：

Gemini 3.5 Flash：Google 把它定位为从 prompt 到 action 的高速模型，面向真实 Agent 工作流。
Gemini Omni：从任意输入创作内容，当前重点从视频开始，支持多模态创作和自然语言多轮编辑。
Google Antigravity 2.0：Agent-first development platform，面向开发者的多 Agent 编排与编程平台。
Gemini API Managed Agents：通过 API 创建可推理、可用工具、可执行代码的托管 Agent。
Google AI Studio：从 prompt playground 走向移动端、Android 原生应用生成和 Antigravity 项目导出。
Google AI Ultra：I/O 后新增 $100/月档位，并面向开发者、技术负责人、知识工作者和高级创作者。

更重要的是，Google 把 Gemini App 的使用额度从传统每日 prompt 限制，转向 compute-used 模型。复杂视频、代码和长上下文任务会消耗更多额度，简单文本任务消耗更少；额度每 5 小时刷新，直到达到周限制。

这说明 Google 正在把 Gemini 订阅做成“模型 + 应用 + 创作 + 开发工具 + Google 生态”的打包入口。

ChatGPT / GPT 订阅现在适合谁

ChatGPT 的优势依然很强，尤其适合把 AI 当作日常工作主力的人。

根据 OpenAI 当前价格页和帮助文档，ChatGPT Free 可以使用 GPT-5.5 Instant 等基础能力；Plus 提供 GPT-5.5 Thinking、更多消息和上传额度、更强图像生成、deep research、agent mode、项目、任务、自定义 GPT 和扩展 Codex 使用；Pro 则提供更高额度、GPT-5.5 Pro、更高 Codex 使用量、最大 deep research 和 agent mode。

更适合 ChatGPT 的场景：

写作、总结、翻译、改稿。
复杂问答和结构化分析。
文件上传、表格分析、研究报告。
编程问答、代码审查、重构建议。
使用 Codex 做代码库任务。
多语言内容生产。
对模型质量和回答稳定性要求高，但不强依赖 Google 产品。

如果你是普通用户，ChatGPT Plus 仍然是最稳的主力订阅。它覆盖面广，学习成本低，中文和英文任务都比较均衡。

如果你是开发者，ChatGPT 的关键不只是聊天，而是 Codex。OpenAI 帮助文档说明，Codex 可随符合条件的 ChatGPT 计划使用，额度随计划不同而变化。也就是说，如果你大量使用 Codex 做代码修改、PR、重构、测试修复，订阅选择要把 Codex 额度一起算进去。

Gemini / Google AI 订阅现在适合谁

Gemini 的优势在 Google I/O 之后更清晰：它和 Google 生态绑定更深。

Google AI 订阅现在不只是 Gemini App 里的模型额度，还包括 Gemini Omni、Google Flow、Antigravity、AI Studio、部分 YouTube Premium / Lite 权益、Workspace / Android / Search 生态能力等。Google 官方还把 AI Ultra 扩成 $100 与更高阶档位，强调开发者、技术负责人、知识工作者和高级创作者。

更适合 Gemini 的场景：

你深度使用 Gmail、Docs、Drive、Sheets、Slides、Android。
你想把 AI 放进 Google Search、YouTube、Workspace 生态。
你关注 Gemini Omni、Google Flow、视频生成和视频编辑。
你想试 Antigravity、Gemini API Managed Agents、AI Studio mobile。
你需要超长上下文文件理解。
你做 Google 生态应用、Android 原生应用、Workspace 自动化。

Google 官方帮助页显示，Gemini Apps 的上下文窗口会随订阅提高：无 AI plan 为 32K，AI Plus 为 128K，AI Pro 和 AI Ultra 为 1 million。AI Pro / Ultra 也会提供更高使用限制、更多特性和部分早期功能。

如果你的工作环境已经在 Google 生态里，Gemini 的价值会被放大。否则，单独把 Gemini 当作“另一个聊天机器人”来订阅，性价比就不一定比 ChatGPT 更稳。

普通用户怎么选

普通用户最容易踩的坑，是因为新模型发布就同时订多个平台。

更理性的选法是先看主场景。

如果你主要做这些事：

写文章。
查资料。
做总结。
读 PDF。
写邮件。
改简历。
学习语言。
日常问答。

优先选 ChatGPT Plus。它的通用性更好，任务边界更清楚，不需要你深度绑定某个生态。

如果你主要做这些事：

Gmail / Docs / Drive / YouTube / Android 高频使用。
希望 AI 直接进入 Google 生态。
想体验 Gemini App、Daily Brief、Google Search AI、YouTube 内容问答。
需要长上下文读取 Google 文档。

优先选 Google AI Pro。

如果你只是轻量用户，两个平台都先用免费层，等明确遇到限制再付费。不要为了“可能用到”而订阅高阶套餐。

开发者怎么选

开发者要分两类。

第一类是以代码问答、修 bug、写脚本、读代码库为主。优先看 ChatGPT Plus / Pro + Codex。

理由是：

Codex 和 ChatGPT 账号打通。
ChatGPT 对代码解释、重构、测试、错误分析比较稳。
Plus 已经覆盖很多日常开发任务。
Pro 更适合高频、长时间、复杂代码库任务。

第二类是面向 Google 生态、Agent 平台、Android、Workspace 或 Gemini API 开发。优先看 Google AI Pro / Ultra。

理由是：

Gemini 3.5 Flash 是 Google I/O 后 Agent 工作流重点模型。
Antigravity 2.0 是 Google 的 Agent-first 开发平台。
Managed Agents 能通过 API 创建带工具和隔离 Linux 环境的 Agent。
AI Studio 可以和 Android、Workspace、Antigravity 更自然衔接。

如果你是全栈开发者，最务实的组合通常是：

ChatGPT Plus 作为日常代码与文档主力。
Gemini 免费层或 AI Pro 用于 Google 生态、长上下文和视频/Agent 新能力。
API 按量使用，不要把个人订阅误当生产 API 预算。

内容创作者怎么选

内容创作者的选择取决于你做什么内容。

如果你主要做：

文案。
标题。
脚本。
文章。
图文内容。
资料整理。
多语言改写。

ChatGPT Plus 依然很稳。

如果你主要做：

视频生成。
短视频创意。
AI 影像。
YouTube Shorts。
Google Flow 工作流。
多模态素材整合。

Gemini / Google AI Pro 或 Ultra 更值得关注。I/O 之后，Gemini Omni 和 Google Flow 是 Google 在创作场景里的核心牌。

如果预算有限，可以先订一个文本主力，再用另一个平台的免费层或短期订阅测试视频能力。视频模型的额度、排队、时长、分辨率和地区限制变化很快，不建议一开始就按长期生产服务规划。

企业和团队怎么选

企业不要按个人用户思路选。

企业真正要看的不是“哪个模型这周更强”，而是：

数据是否用于训练。
是否有 SSO、MFA、RBAC。
是否有审计日志。
是否支持内部知识连接。
是否能控制插件、连接器和 Agent 权限。
是否符合组织的合规要求。
是否能和现有办公套件打通。

如果企业已经重度使用 Google Workspace，Gemini 企业方案自然更值得评估。如果团队已经围绕 ChatGPT、Codex、OpenAI API 和内部工具链搭建流程，OpenAI Business / Enterprise 更自然。

对工程团队来说，还要单独评估 Codex、Antigravity、Gemini API Managed Agents、MCP、CI/CD、代码权限、仓库访问和审计。

什么时候需要 Pro / Ultra

很多人其实不需要高阶档位。

你需要 ChatGPT Pro 的典型信号：

每天长时间使用 ChatGPT。
Plus 额度经常不够。
高频使用 Codex。
经常跑 deep research、agent mode、复杂推理。
需要 GPT-5.5 Pro 这类更高阶模型。

你需要 Google AI Ultra 的典型信号：

高频使用 Gemini、Flow、Antigravity。
需要更高 Gemini / Antigravity 使用额度。
做视频创作、AI 影像、长上下文研究。
深度依赖 Google 生态和新功能优先体验。
需要 Gemini Spark、Project Genie 或更高级订阅权益。

如果你只是每天问几次问题、偶尔写文章或改代码，Plus / Pro、AI Pro / Ultra 这类高阶档位可能都不是刚需。

最省钱的订阅策略

更推荐这种组合：

先选一个主力付费订阅。
另一个平台先用免费层。
真正需要 API 时再按量付费。
视频、Agent、深度研究类高消耗功能按月开关，不要全年盲订。
每月复盘一次：本月有没有真的用满额度？

几个常见组合：

普通办公：ChatGPT Plus + Gemini 免费层。
Google 生态用户：Google AI Pro + ChatGPT 免费层。
开发者：ChatGPT Plus/Pro + Gemini API/AI Studio 按需。
视频创作者：Google AI Pro/Ultra + ChatGPT 免费层或 Plus。
企业团队：不要用个人套餐拼，直接评估 Business / Enterprise / Workspace 方案。

订阅前检查清单

付费前先确认这些问题：

你的地区是否支持目标套餐？
你要用的模型是否包含在该套餐里？
Codex、Antigravity、Flow、Omni 是否真的可用？
视频功能是否有地区、年龄、排队或分辨率限制？
API 调用是否包含在订阅里，还是单独计费？
文件上传、上下文窗口、agent mode、deep research 是否有额度限制？
数据隐私设置是否符合你的项目要求？
你是否已经有 Google One、Workspace、ChatGPT Business 或学校/公司账号权益？

尤其要注意：个人订阅不等于 API 免费，不等于商用无限额度，也不等于企业合规。

小结

Google I/O 之后，Gemini 的竞争力明显增强，尤其是在视频、多模态、Google 生态、Android、AI Studio 和 Antigravity 方向。但 ChatGPT 仍然是更稳的通用主力，特别是在日常写作、复杂问答、文件分析、代码辅助和 Codex 工作流里。

最简单的判断是：

不知道选哪个：先选 ChatGPT Plus。
深度 Google 用户：选 Google AI Pro。
高频开发者：看 Codex 和 Antigravity 谁更贴近你的工作流。
视频创作者：优先看 Gemini Omni、Flow 和 Google AI Pro / Ultra。
企业用户：按合规、权限、审计和现有办公生态选，而不是按模型热度选。

AI 订阅不是越多越好。真正划算的方式，是明确一个主力工作流，再把其他平台作为补充，而不是为每一个发布会都多开一个长期订阅。

参考来源：

Google I/O 2026 主要内容总结：Gemini 3.5、Omni、Antigravity 与系统级 Agent

Thu, 21 May 2026 00:07:06 +0800

Google I/O 2026 的主线很清楚：Google 正在把 Gemini 从“模型”和“聊天助手”推进到一个更完整的 Agent 生态。它不只是回答问题，而是要进入搜索、Android、开发工具、视频创作、购物、Workspace、硬件和企业平台，帮助用户完成更长链路的任务。

本文按官方发布信息和开发者视角，整理 Google I/O 2026 的主要内容。实际开发时仍应以 Google、Android Developers 和 Gemini API 官方文档为准。

一句话总结

Google I/O 2026 的关键词是 agentic Gemini era。

Google 发布或强化了几条线：

Gemini 3.5 Flash：强调速度、行动能力和 Agent 工作流。
Gemini Omni：从任意输入生成内容，重点从视频创作和编辑开始。
Gemini app：从聊天助手走向主动、全天候、可执行任务的个人 Agent。
Google Antigravity 2.0：从 AI 编程工具升级为 Agent 优先的开发平台。
Gemini API Managed Agents：通过 API 创建能推理、用工具、执行代码的托管 Agent。
Google AI Studio：扩展到移动端、Android 原生支持和项目导出到 Antigravity。
Search、Shopping、YouTube、Workspace、Android：都在接入更强的 Gemini 和 Agent 能力。

换句话说，Google 不再只展示“模型有多聪明”，而是在展示“模型如何进入产品、工具和系统，真正替用户执行任务”。

Gemini 3.5 Flash：从提示词走向行动

Gemini 3.5 是 Google 在 I/O 2026 推出的新一代模型系列，首个公开重点是 Gemini 3.5 Flash。

Google 对它的定位不是单纯“更快的聊天模型”，而是用于真实 Agent 工作流的高速引擎。官方开发者文章提到，3.5 Flash 结合前沿智能和高速度，用来支撑从 prompt 到 action 的转变。

它的主要意义在于：

面向 Agent 和 coding 场景优化。
支持更长链路任务和工具调用。
在 Antigravity、Gemini API、Google AI Studio、Android Studio、Gemini Enterprise 等入口提供。
更适合需要快速响应、多轮执行和频繁工具调用的应用。

对开发者来说，Gemini 3.5 Flash 不只是一个模型选项，而是 Google 新 Agent 工具链的默认动力源之一。

Gemini Omni：视频和世界模型能力成为重点

Gemini Omni 是 I/O 2026 另一个核心发布。Google 对它的描述是：从任意输入创作内容，当前重点从视频开始。

它的看点主要有三类：

多模态输入：文本、图像、视频、音频等都可以作为参考。
视频编辑：用户可以用自然语言多轮修改视频，而不是一次性生成后就结束。
世界理解：强调物理、场景、动作、叙事和视听一致性。

这意味着 AI 视频工具的方向正在从“输入一句提示词生成短片”走向“像和剪辑师沟通一样逐轮修改”。对创作者来说，真正有价值的不是一次生成，而是可控、可追踪、可迭代的编辑流程。

Gemini App：从聊天助手变成全天候个人 Agent

Google 也把 Gemini app 明确推向更 Agent 化的方向。官方文章提到，Gemini app 正在变得更主动，提供日常简报和全天候帮助。

几个重点包括：

Gemini 3.5 Flash 进入 Gemini app。
新 UI 和更动态的交互体验。
Gemini Spark 这类个人 AI Agent 概念。
Proactive daily briefs，主动整理用户每天需要关注的信息。
更强调 7×24 小时后台协助，而不是用户每次都主动发起聊天。

这部分对普通用户影响最大。过去 Gemini 更像“你问我答”的助手；I/O 2026 之后，Google 想让它更像能持续跟进任务、主动提醒、跨产品协同的个人智能体。

Antigravity 2.0：开发者工具转向 Agent 优先

开发者侧最重要的发布之一是 Google Antigravity 2.0。

Google 将 Antigravity 定位为 agent-first development platform。I/O 2026 之后，它不只是帮助写代码，而是要帮助开发者从想法、原型、Agent 编排到生产应用交付。

官方列出的核心变化包括：

Antigravity 2.0 独立桌面应用。
支持多 Agent 并行编排。
支持动态 subagents。
支持后台定时任务。
与 Google AI Studio、Android、Firebase 等生态集成。
提供 Antigravity CLI，面向终端用户。
提供 Antigravity SDK，用于自定义 Agent 行为和部署。

这说明 AI 编程工具正在从“代码补全 / 对话生成”进入下一阶段：开发者要管理的是多个可执行 Agent，而不只是一个聊天窗口。

Gemini API Managed Agents：把 Agent 托管成 API 能力

Google 还推出了 Managed Agents in the Gemini API。

官方描述中，这类 Agent 可以通过一次 API 调用创建，具备推理、工具使用和在隔离 Linux 环境中执行代码的能力，并且由 Antigravity agent harness 提供支持。

这件事对开发者很关键：

不必自己搭完整 Agent 运行环境。
可以获得持久、隔离的执行环境。
多轮交互可以保留文件和状态。
可以用 markdown 技能、自定义指令和模板扩展 Agent。
可通过 Interactions API 和 Google AI Studio 使用。

如果这条线成熟，Agent 平台会越来越像云服务：开发者不再只调用模型，而是调用一个带状态、工具、执行环境和安全边界的 Agent。

Google AI Studio：从 prompt playground 走向应用生成入口

I/O 2026 中，Google AI Studio 的定位也更进一步。

重点变化包括：

Google AI Studio mobile app，可在移动端捕捉想法和生成原型。
Workspace API 集成，让 Agent 能更自然地接入 Google Workspace。
项目可导出到 Antigravity，带着上下文继续本地开发和生产化。
增加 Android 原生支持，可以用 prompt 构建 Android 应用。
支持对接 Google Play Console，把应用发布到测试轨道。

这让 AI Studio 从“调提示词和试模型”变成“从想法到应用”的入口。它和 Antigravity 的关系也更清楚：AI Studio 适合快速构思和生成，Antigravity 适合继续开发、编排、调试和交付。

Android 与 AppFunctions：移动端 Agent 的关键接口

Android 系统级 Agent 是这次值得单独看的方向，但需要用更准确的接口和产品边界来理解。

当前最值得关注的是 Android 官方的 AppFunctions。官方文档说明，AppFunctions 是一种 Android 平台 API，并带有 Jetpack 库，可以让应用把自身能力暴露给智能体、助手和其他有权限的调用方。它还简化了 Android MCP 集成。

它的意义在于：移动端自动化不再只能依赖截图、OCR、模拟点击和 UI 控件定位。

传统移动端自动化路径是：

识别屏幕。
找按钮。
模拟点击。
等待页面变化。
出错后重试。

AppFunctions 的方向是：

应用声明自己能做什么。
Agent 在授权下调用这些能力。
系统负责权限、调用边界和安全约束。

这会影响 Android 应用设计。未来应用不只要做给人看的 UI，还要把核心功能设计成可被 Agent 调用的能力接口。

Search、购物和内容产品也在 Agent 化

Google I/O 2026 的变化不只在模型和开发者工具里，搜索和消费产品也在同步变化。

官方 I/O 汇总中提到：

Search 进入新的 AI Search 阶段。
Information agents 出现在搜索场景中。
Gemini Spark 和 Daily Brief 进入 Gemini app。
Universal Cart 让购物车更智能。
Ask YouTube 让视频内容可以被对话式查询和跳转。
Gemini 能力继续扩展到更多产品和形态。

这些发布说明 Google 的 Agent 方向不是单点产品，而是横向铺到搜索、视频、购物、办公、移动和硬件场景中。

对开发者的实际影响

Google I/O 2026 对开发者最大的影响，不是“又多了一个模型”，而是开发对象变了。

以前开发者主要构建：

App。
网站。
API。
插件。
自动化脚本。

接下来还要构建：

可被 Agent 调用的应用能力。
多 Agent 工作流。
有状态的工具执行环境。
可审计的自动化流程。
人在回路确认机制。
与 MCP、AppFunctions、Workspace API、Playwright、Firebase 等工具的集成。

软件会越来越像“能力集合”，而不仅是“界面集合”。谁能把自己的能力清晰、可靠、安全地开放给 Agent，谁就更容易进入用户的自动化任务链。

对移动端自动化的影响

移动端自动化会从“GUI 优先”逐步变成“接口优先，GUI 兜底”。

短期看，截图识别、OCR、模拟点击、浏览器自动化仍然有价值，因为大量旧应用没有标准接口。

长期看，只要 Android AppFunctions、MCP 和系统级权限模型成熟，稳定的任务执行会更偏向：

优先调用应用声明的能力。
必要时调用系统接口。
再必要时用 GUI 自动化兜底。

这会改变 RPA、移动端 Agent、测试工具和应用生态。应用越愿意开放能力，越容易被系统级 Agent 调用；不开放能力的应用，可能仍然只能被“看屏幕、点屏幕”的旧方式操作。

安全、权限和审计会成为硬约束

Agent 能力越强，风险越大。

如果 Agent 可以跨应用执行任务、调用支付、修改设置、访问文件和读取上下文，就必须有清晰的安全边界：

权限分级。
用户显式授权。
敏感操作二次确认。
沙箱隔离。
操作日志。
可撤销和可回滚。
企业审计与合规。

这也是为什么 Google 会强调托管 Agent 的隔离环境、AppFunctions 的权限要求、企业平台和可控部署。Agent 的未来不是“无所不能”，而是在安全边界内可执行、可追踪、可治理。

小结

Google I/O 2026 的主要内容可以概括为一句话：Google 正在把 Gemini 打造成横跨模型、应用、系统、开发工具和硬件的 Agent 平台。

Gemini 3.5 Flash 提供速度和行动能力，Gemini Omni 把多模态创作推向视频和世界理解，Gemini app 走向主动个人助手，Antigravity 2.0 和 Managed Agents 把开发者工具推向 Agent 原生，AppFunctions 则让 Android 应用开始为智能体暴露能力。

对开发者来说，接下来要关注的不只是模型参数，而是：如何把应用能力结构化、如何接入 Agent 工具链、如何设计权限和审计，以及如何让自己的产品在系统级 Agent 生态里被安全可靠地调用。

参考来源：

Gemini 3.5 正式发布：Flash 先行，Google 把重点放在 Agent 和长任务执行

Wed, 20 May 2026 22:51:31 +0800

Google 在 2026 年 5 月 20 日正式发布 Gemini 3.5 系列。第一款开放使用的是 Gemini 3.5 Flash，定位不是单纯的聊天模型，而是面向 Agent、代码生成和长时间复杂任务执行的模型。

从这次公告看，Google 对 Gemini 3.5 的叙事很明确：模型不只要回答问题，还要能规划、执行、检查，并在多步任务中持续推进工作。

Gemini 3.5 Flash 先行

Gemini 3.5 Flash 已经面向多类用户开放：

普通用户可以通过 Gemini 应用和 Google 搜索中的 AI 模式体验。
开发者可以通过 Google Antigravity、Google AI Studio、Android Studio 中的 Gemini API 使用。
企业用户可以通过 Gemini Enterprise Agent Platform 和 Gemini Enterprise 使用。

Google 同时提到，Gemini 3.5 Pro 仍在开发中，已经在 Google 内部使用，计划在下个月推出。

这说明 3.5 系列会继续保留 Flash 与 Pro 的分层：Flash 更强调速度、成本和可规模化执行，Pro 则更可能面向更复杂、更高能力需求的场景。

重点是 Agent 和代码任务

Google 把 Gemini 3.5 Flash 称为目前最强的 Agent 与代码编写模型之一。公告中提到，它在多项代码和 Agent 基准测试中超过 Gemini 3.1 Pro 的部分成绩，例如 Terminal-Bench 2.1、GDPval-AA、MCP Atlas 和 CharXiv Reasoning。

这些指标本身不是普通用户最需要关心的内容。更重要的是，Google 正在把模型能力往“可执行工作流”上集中：不仅能写代码，还能处理旧项目迁移、复杂应用开发、财务报表整理、数据分析和持续测试。

在 Antigravity 开发架构中，Gemini 3.5 Flash 可以通过多个协作子代理处理大型任务。Google 展示的例子包括解析 AlphaZero 论文并实现可玩的游戏、把旧版代码转换为 Next.js、并行生成城市景观和 UI 方案。

这类能力的方向很清楚：AI 编程工具正在从“生成一段代码”走向“组织多个 Agent 完成一个项目”。

多模态 UI 与图形能力增强

Gemini 3.5 Flash 继承了 Gemini 3 的多模态基础。Google 强调它可以生成更丰富的网页 UI、交互动画和图形内容。

公告中给出的应用场景包括：

为研究论文生成交互式动画。
根据文字描述生成交互式硬件模型。
为学校募款活动生成完整品牌概念。
在短时间内为结账流程生成多种 UX 方案。

这部分对开发者和产品团队很有意义。模型不再只是输出文字说明，而是能参与前端原型、交互设计和可视化内容生成。

企业场景：把耗时流程自动化

Google 在公告中列举了多个合作伙伴案例。Shopify 使用子代理分析复杂数据并预测商家增长；Macquarie Bank 测试用 3.5 Flash 阅读超过 100 页的复杂文件，加速开户流程；Salesforce 将其整合到 Agentforce；Ramp 用它改进复杂发票 OCR；Xero 用 AI 代理处理行政流程；Databricks 用自动化工作流监控数据异常并给出修复建议。

这些案例共同指向一个趋势：企业采用大模型时，关注点正在从单次问答转向流程自动化。模型是否便宜、快、能长时间稳定执行，会比单次回答是否惊艳更重要。

Gemini Spark：个人 AI 代理

Google 还公布了 Gemini Spark。它是由 Gemini 3.5 Flash 驱动的个人 AI 代理，目标是在用户引导下长期运行并主动执行任务。

Gemini Spark 已经开始面向受信任测试人员推出，Google 计划在下周向美国 Google AI Ultra 订阅用户开放 Beta 测试。

这部分值得关注。Google 搜索、Gemini 应用、Android、Workspace 和浏览器生态本来就覆盖大量个人数字生活场景。如果个人 Agent 能与这些入口结合，影响可能比单独的聊天机器人更大。

安全机制继续前移

Google 表示 Gemini 3.5 按照 Frontier Safety Framework 开发，并强化了信息安全和 CBRN 相关防护。公告还提到使用可解释性工具，在模型给出回答前帮助检查和理解推理过程。

这说明前沿模型的发布已经不只是能力竞赛。越是强调 Agent、自动执行和长任务，安全控制、误拒率、有害输出防护和可解释性就越重要。

怎么看 Gemini 3.5

Gemini 3.5 Flash 的意义不只是“又一个新模型发布”。它更像是 Google 对下一阶段 AI 产品形态的集中押注：模型要能调用工具、拆分任务、协作执行、生成 UI，并进入个人和企业工作流。

对开发者来说，值得关注的是 Google Antigravity、AI Studio、Gemini API 和 Android Studio 中的实际体验。对企业来说，重点是它能否在真实流程中稳定减少人工操作，而不是只看 benchmark。

Gemini 3.5 Pro 还没有正式开放。等 Pro 发布后，Flash 与 Pro 在能力、价格、速度和上下文处理上的差异，才会决定它们各自更适合哪些生产场景。

参考来源：

Google Blog：Gemini 3.5 正式登场

DeepSeek-V4 KV Cache 机制解析：为什么 1M 上下文更省显存

Mon, 18 May 2026 18:38:26 +0800

长上下文模型真正贵的地方，往往不是“能不能塞进 100 万 Token”，而是推理时 KV Cache 要占多少显存。

在 Transformer 解码过程中，每生成一个新 Token，模型都要保留历史 Token 对应的 Key 和 Value。上下文越长，KV Cache 越大；KV Cache 越大，显存、内存带宽、首字延迟和吞吐都会被拖慢。

DeepSeek-V4 的特别之处，是它没有只在注意力头数量上省缓存，而是把压缩进一步推进到序列长度维度。按照 Hugging Face 对 DeepSeek-V4 技术报告的解读，在 1M Token 场景下，DeepSeek-V4-Pro 的 KV Cache 约为 DeepSeek-V3.2 的 10%；如果和常见的 bf16 GQA 架构相比，约为其 2% 左右。

这就是 DeepSeek-V4 缓存机制最值得看的地方：它不是简单把 KV 存得更小，而是减少需要长期保存和检索的 KV 条目数量。

先看几代 KV Cache 优化路线

KV Cache 优化大致可以分成几条路线。

第一类是传统 MHA，也就是 Multi-Head Attention。每个 Query 头通常都有对应的 Key/Value 头。它结构直接，但长上下文下缓存随序列长度线性增长，显存压力最大。

第二类是 GQA，也就是 Grouped Query Attention。多个 Query 头共享较少的 Key/Value 头。LLaMA、Mistral、Qwen 等很多现代模型都采用类似思路。它能显著减少 KV 头数量，是当前主流长上下文模型的常见节省手段。

第三类是 MLA，也就是 Multi-head Latent Attention。DeepSeek-V2、DeepSeek-V3 使用这一路线，把 Key/Value 压缩成低秩潜在表示，从注意力头维度进一步降低缓存占用。

第四类就是 DeepSeek-V4 引入的混合压缩注意力。它把重点放到序列长度维度：不是只减少每个 Token 要存多少 KV，而是把多个历史 Token 压缩成更少的 KV 条目，再用稀疏或稠密方式检索。

可以粗略理解为：

MHA：每个头都认真记。
GQA：多个 Query 头共享一部分记忆。
MLA：把每个 Token 的 KV 表示压成潜在向量。
DeepSeek-V4：把很多历史 Token 聚合成更少的压缩记忆块。

DeepSeek-V4 的关键变化：从头维度压缩到序列维度压缩

GQA 和 MLA 主要是在“每个 Token 存多少 KV”上做优化。这个方向很有效，但当上下文长度来到 1M Token 时，问题会变得更极端：即使每个 Token 的缓存已经很小，Token 数量本身仍然太多。

DeepSeek-V4 选择把旧上下文压缩成块。也就是说，模型不一定要为每个很久以前的 Token 都保留完整 KV，而是让多个 Token 形成压缩条目。

这有点像读一本很长的书：刚读过的几页你会记得细节，前面几章则更多以摘要、主题和关键线索的形式保存。DeepSeek-V4 的注意力机制也有类似分工：近处保留细节，远处用压缩表示。

CSA：4 倍压缩加稀疏检索

CSA 全称是 Compressed Sparse Attention，可以理解为较细粒度的长程压缩机制。

在 CSA 中，模型会把序列中的若干相邻 Token 压缩成更少的 KV 条目。Hugging Face Transformers 文档里给出的默认压缩率是 m=4，也就是大致每 4 个 Token 形成一个压缩条目。

但它不是简单平均。CSA 使用带学习能力的压缩池，并结合重叠窗口，让模型在压缩时保留更有用的信息。压缩之后，查询并不会对所有历史压缩块都做完整注意力，而是先通过 Lightning Indexer 打分，挑出最相关的 top-k 压缩块，再进入核心注意力计算。

这个结构有两层收益：

历史 KV 条目数量先变少。
每次查询只看最相关的一部分压缩块。

所以 CSA 适合处理远距离但仍需要细节检索的上下文，比如代码库、长文档、工具调用历史里的关键信息。

HCA：128 倍压缩加稠密注意力

HCA 全称是 Heavily Compressed Attention，压缩更激进。

Transformers 文档里给出的默认压缩率是 m'=128。也就是说，HCA 会把更长的一段上下文压成一个压缩条目。压缩后的序列已经很短，因此它不需要像 CSA 那样再做稀疏 top-k 检索，而是让 Query 对所有压缩条目做稠密注意力。

HCA 的作用更像全局摘要。它不追求保留每个细节，而是用极低成本覆盖很长的历史范围，让模型对全局背景、长程主题和远处信息保持感知。

如果把 CSA 比作“可检索的压缩笔记”，HCA 更像“全局目录和摘要”。

滑动窗口：最近上下文仍保留细节

DeepSeek-V4 并不是把所有上下文都压缩掉。

在 CSA 和 HCA 之外，它还保留了滑动窗口分支，用来处理最近的一段未压缩上下文。Transformers 文档里提到，DeepSeek-V4 的 attention block 会把长程压缩分支与滑动窗口 K/V 拼接在一起。

这个设计很重要。生成下一个 Token 时，最近几十到几百个 Token 往往最关键：变量名、函数签名、正在写的句子、刚返回的工具结果、最近用户要求。它们如果被过度压缩，输出质量会明显下降。

所以 DeepSeek-V4 的思路不是“全部压缩”，而是：

近处：保留未压缩细节。
中远处：用 CSA 做可检索压缩。
更远处：用 HCA 做重度全局压缩。

混合层栈：不同层做不同注意力

DeepSeek-V4 不是在所有层里使用同一种注意力。

Hugging Face 的 DeepSeek-V4 文章提到，V4-Pro 的 61 层结构中，前两层使用 HCA，之后的层在 CSA 和 HCA 之间交替，末尾的 MTP block 使用滑动窗口。Transformers 文档也说明，V4-Pro 默认是 2 层 HCA bootstrap 加交替 CSA/HCA。

这说明 DeepSeek-V4 把注意力机制当成分层系统来设计。不同层承担不同信息流角色：有的层更偏全局压缩，有的层更偏稀疏检索，有的部分保留局部窗口。

相比所有层统一使用一种注意力，这种混合结构更复杂，但也更适合 1M Token 这种极长上下文。

FP8 和 FP4 进一步降低缓存成本

DeepSeek-V4 的缓存节省不只来自压缩率。

Hugging Face 的文章提到，V4 的大部分 KV 条目使用 FP8 存储，RoPE 相关维度保留 BF16，而 CSA 里的 Lightning Indexer 使用 FP4。压缩比例、低精度存储、稀疏检索叠加在一起，才形成了非常低的 KV Cache 占用。

这也提醒我们：不要只看“上下文长度 1M”这个宣传数字。真正决定可部署性的，是长上下文下的显存占用、带宽压力、推理延迟和工程实现。

和其他模型的差异

与传统 MHA 相比，DeepSeek-V4 不再为长历史里每个 Token 保留完整注意力记忆，缓存压力下降非常明显。

与 GQA 相比，DeepSeek-V4 不只是减少 KV head 数量，还减少长历史的 KV 条目数量。GQA 仍然要随序列长度线性积累缓存，而 V4 会把远处上下文压成块。

与 DeepSeek-V3 的 MLA 相比，V4 的重点从“每个 Token 的表示更紧凑”进一步扩展到“历史 Token 数量也被压缩”。MLA 已经大幅降低单 Token KV 占用，但面对百万级上下文时，序列长度本身仍是压力来源。

与普通稀疏注意力相比，DeepSeek-V4 的 CSA 是先压缩再稀疏检索，索引器面对的是更短的压缩序列；HCA 则通过 128 倍压缩让全量稠密注意力也变得便宜。

对 Agent 和长任务有什么意义

Agent 工作流特别吃长上下文：它会读文件、调用工具、接收工具返回、生成计划、修正计划、继续调用工具。上下文越长，KV Cache 越容易成为瓶颈。

DeepSeek-V4 这种缓存机制的潜在价值在于：

更容易承载长代码库、长文档、多轮工具调用历史。
首字延迟和吞吐更不容易被 KV Cache 拖垮。
同等硬件上可以跑更长上下文或更多并发请求。
对百万 Token 场景，部署成本更接近实际可用，而不是只停留在论文指标。

不过也要注意，压缩注意力不是免费午餐。把历史 Token 压缩成块，必然涉及信息取舍。模型需要在“省显存”和“保留可检索细节”之间做平衡。真正效果还要看任务类型：代码定位、法律文档、长篇问答、Agent 工具链，对细节召回的要求并不一样。

不要把 2% 理解成所有成本都降到 2%

“KV Cache 约为 GQA 的 2%”很容易被误读。

它主要指 KV Cache 显存规模，不等于总推理成本只剩 2%，也不等于所有场景速度都会提升 50 倍。推理还包括模型权重读取、MoE 路由、前馈网络、注意力计算、调度开销、通信开销等。

Hugging Face 的文章里也把两个数字分开讲：在 1M Token 场景，DeepSeek-V4-Pro 相对 DeepSeek-V3.2 的单 Token 推理 FLOPs 是 27%，KV Cache 是 10%。这说明缓存和计算是两个不同维度。

所以更稳妥的说法是：DeepSeek-V4 让超长上下文的 KV Cache 压力显著降低，从而改善百万 Token 场景的部署可行性；但具体吞吐和延迟仍取决于实现、硬件、批处理、量化和推理框架。

小结

DeepSeek-V4 的缓存机制和其他大模型最大的不同，是它把 KV Cache 优化从注意力头维度推进到了序列维度。

GQA 是少存一些 KV 头，MLA 是把每个 Token 的 KV 表示压得更紧，DeepSeek-V4 则进一步把远处 Token 聚合成压缩块，并通过 CSA、HCA、滑动窗口和低精度存储组合起来，让百万 Token 上下文不再被 KV Cache 轻易卡死。

这不是单一技巧，而是一整套长上下文推理架构：近处保细节，远处做压缩，需要细节时稀疏检索，需要全局时重度摘要。

对开发者和 Agent 应用来说，它的意义很直接：长上下文不只是“能输入更多”，还要“跑得起、跑得稳、成本能接受”。DeepSeek-V4 真正改变的，正是这一点。

参考资料

Anthropic Founder’s Playbook 解读：Claude 如何帮助创业团队提速

Mon, 18 May 2026 18:02:58 +0800

Anthropic 在 Claude 官方博客发布了面向创业者的 The Founder’s Playbook，核心问题很直接：一家 AI-native startup 如何更快从洞察走到产品、发布和规模化？

这份 playbook 并不是单纯介绍 Claude 的功能清单，而是把创业过程拆成四个阶段：Idea、MVP、Launch 和 Scale。它强调的不是“让 AI 代替创始人做判断”，而是把市场调研、文案初稿、代码脚手架、运营流程、销售材料等重复性工作先交给 Claude，让创始人把更多时间留给判断、品味、取舍和信任建设。

这份 playbook 在讲什么

AI 创业公司面临的压力越来越像一场压缩比赛：产品周期更短，竞争者更多，用户对速度和质量的要求同时提高。过去需要多人团队分工完成的事情，现在可以用 AI 先做出第一版，再由创始团队审阅、修正和推进。

Anthropic 给出的框架很清晰：不要一开始就试图把公司完全“AI 化”，而是先找一个耗时、重复、低创造密度的流程，让 Claude 生成初稿、脚本、调研结果或执行清单。创始人负责定义目标、校准方向、判断质量，并把可行结果接入真实业务。

第一阶段：Idea

Idea 阶段的重点不是“想一个酷点子”，而是验证这个点子是否值得继续投入。

Claude 适合在这个阶段帮助创始人做几件事：整理市场地图、归纳用户痛点、比较竞品定位、提出潜在楔入点，并把模糊想法压缩成更具体的价值主张。

但这一步最重要的仍然是人的判断。AI 可以帮助你更快看到一批可能性，却不能替你承担“这个市场是否真的存在强需求”的责任。创始人仍然需要和真实用户交流，观察他们愿不愿意改变现有工作流，甚至愿不愿意付费。

第二阶段：MVP

MVP 阶段是 Claude Code 最容易发挥作用的地方。

对小团队来说，最稀缺的往往不是想法，而是把想法变成可试用产品的速度。Claude Code 可以参与生成脚手架、写脚本、补组件、检查边界条件、产出技术方案说明，帮助团队更快做出可验证的版本。

这里的关键不是让 AI 一次性写出完美产品，而是把“从 0 到第一版”的摩擦降下来。创始人和工程师仍然需要审查架构、安全性、数据处理和用户体验，但他们不必把时间浪费在大量机械性的初稿工作上。

第三阶段：Launch

Launch 阶段考验的是叙事、分发和反馈速度。

很多创业团队会低估发布的复杂度：官网文案、产品演示、邮件、社交媒体内容、用户访谈、销售话术、投资人更新，每一项都需要清楚表达“为什么现在需要这个产品”。

Claude 在这里可以充当一个高频协作对象：帮团队生成不同版本的定位表达，改写面向不同用户群体的介绍，模拟用户疑问，整理发布节奏，并把早期反馈转成下一轮产品和市场动作。

第四阶段：Scale

Scale 阶段的主题从“做出来”转向“可重复地增长”。

当公司开始有稳定用户和收入，创始团队会被运营、销售、客服、数据分析和内部协作拉扯。Claude Cowork 这类 agent 化能力适合处理更完整的任务：例如做市场研究、设计活动方案、整理募资策略、汇总增长指标，或者把一套运营流程拆成可以反复执行的步骤。

这也是 AI-native 公司和传统软件公司的差异开始显现的地方。真正的变化不只是“员工使用 AI 工具”，而是公司流程从一开始就围绕 AI 协作来设计：哪些任务由人定义标准，哪些任务由 AI 先跑一遍，哪些结果必须进入审查，哪些流程可以沉淀成可复用模板。

Claude Code、Claude Cowork 和 Chat 各自适合做什么

从这篇官方博客的描述看，Anthropic 想让创业者把 Claude 分成三类使用场景。

Claude Code 更偏工程协作，适合写代码、生成脚本、分析边界情况、产出组件规格和技术文档。它解决的是“把想法推进成可运行东西”的问题。

Claude Cowork 更像可委派的工作代理，适合市场研究、活动设计、募资策略、运营分析这类需要连续执行的任务。它解决的是“把一件较完整的业务工作先推进一轮”的问题。

Claude Chat 则更适合创始人的判断时刻：推敲 go-to-market 策略、压力测试产品定位、比较路线图优先级、打磨关键叙事。它不是执行机器，而是一个可以快速反复讨论的思考搭档。

对创业团队真正有用的地方

这份 playbook 的价值，不在于告诉创业者“AI 很重要”。这一点已经不新鲜了。

它更有用的地方，是把 AI 使用方式从零散工具调用，推进到公司建设方法论：每个阶段都有不同的瓶颈，每个瓶颈都可以拆出适合 AI 参与的部分。

Idea 阶段，AI 帮你扩大搜索空间。MVP 阶段，AI 帮你压缩实现周期。Launch 阶段，AI 帮你加快表达和分发实验。Scale 阶段，AI 帮你沉淀可重复流程。

这套逻辑对小团队尤其重要。因为小团队没有足够的人手覆盖所有职能，但可以用 AI 先补上“第一版能力”，再把有限的人力投入到最需要判断和关系建设的部分。

需要警惕的误区

第一个误区是把 AI 生成的内容直接当结论。市场调研、竞品分析、用户画像、增长策略都必须回到真实数据和用户反馈里验证。

第二个误区是低估审查成本。AI 能显著降低初稿成本，但代码质量、法律风险、品牌表达、商业承诺和安全问题仍然需要人负责。

第三个误区是过早自动化。对还没有跑通的流程，不应该急着交给 agent 自动执行。更稳妥的方式是先让 AI 参与其中一小段流程，观察输出质量，再逐步扩大范围。

小结

Anthropic 这篇 The Founder’s Playbook 传递的信号很明确：AI-native startup 的优势，不只是“会用 AI 写代码”，而是从公司第一天开始，就把 AI 作为产品、工程、市场、销售和运营里的协作层。

对创业者来说，最现实的起点不是搭建宏大的 AI 工作流，而是选出一个最耗时、最重复、最拖慢推进速度的任务，让 Claude 先做第一版。真正的竞争力，来自人类创始人对方向、质量和信任的把关，以及团队能否把这种协作方式稳定地嵌入日常工作。

参考资料

The founder’s playbook for the age of AI

Figure AI 人形机器人连续分拣包裹：直播证明了什么

Mon, 18 May 2026 17:58:10 +0800

Figure AI 又把人形机器人推到了舆论中心。

从 2026 年 5 月 14 日开始，Figure AI 把三台 F.03 人形机器人放进物流分拣场景，进行连续直播。机器人被网友称作 Bob、Frank 和 Gary，它们在传送带旁识别包裹、抓取、翻转、扫描条码，并把包裹按要求放回传送带。

这场直播最初像是一次回应质疑的公开测试：人形机器人如果要证明自己有实用价值，就不能只靠剪辑好的短视频，而要经得住完整班次、重复任务和长时间运行。

截至澎湃新闻报道时，Figure AI 已经直播了五天，并公开宣称机器人分拣包裹数量超过 10 万件。直播仍可通过 YouTube 查看：F.03 Livestream。

这场直播为什么重要

人形机器人行业过去最常见的问题，是演示视频太短。

几分钟的演示可以展示“能做”，但很难证明“能一直做”。真正的物流、制造和仓储场景，不只看一次抓取是否成功，还看连续运行时的稳定性、异常处理、维护节奏和单位成本。

Figure AI 这次选择直播，等于把问题摆到台面上：

机器人能不能持续工作多个小时甚至多天。
是否需要人类远程操控。
能否自己处理电量、交接和维护。
在重复任务中错误率是否可接受。
面对软包、硬箱、不同尺寸包裹时能否保持稳定。

相比一条剪辑视频，长时间直播更容易暴露问题。包裹掉落、抓取失误、短暂停顿、传送带节奏变化，都会被观众看到。

这也是它的价值：不是证明机器人已经完美，而是让外界第一次比较直观地看到，人形机器人在工业重复任务里离可用还有多远。

Figure F.03 在做什么

这次任务并不复杂，但很典型。

机器人需要观察传送带上的包裹，判断条码位置，抓起包裹，调整朝向，再把条码朝下放回传送带。看起来只是“拿起再放下”，但对机器人来说，这里面包含多个难点：

识别不同形状、材质和尺寸的包裹。
估计抓取点和重量变化。
避免把软包捏变形或把箱子推落。
在有限空间内完成手臂运动。
保持动作节奏，不拖慢传送带。
失败后能否恢复，而不是卡死。

Figure AI 创始人 Brett Adcock 表示，机器人平均每个包裹约 3 秒，接近人类速度；同时强调系统不是脚本，而是直接从摄像头像素进行推理和控制。

这句话很关键。它想表达的不是“机器人会重复一套动作”，而是机器人能够根据实时视觉输入调整抓取和放置策略。

Helix-02 是核心看点

Figure AI 这次强调，F.03 运行的是自研 Helix-02 系统。

按照公开描述，Helix-02 不是传统工业机器人那种“感知、规划、控制”严格分层的流程，而是更接近端到端的全身自主系统。它把视觉、触觉、本体感觉和全身控制整合到一个模型框架中，让机器人能根据环境实时调整动作。

可以简单理解为三层能力：

底层控制：让机器人维持平衡、执行关节动作。
视觉运动策略：把摄像头和触觉输入转成抓取、移动和放置动作。
语义推理：理解任务目标、场景和异常状态。

这也是人形机器人和传统自动化设备的区别。

传统分拣设备通常针对固定流程优化，效率很高，但改造场景需要重新设计产线。人形机器人则试图用类似人的形态进入现有环境，不改太多设备，就能执行多种任务。

这个方向很诱人，但也很难。机器人的手、眼、身体和大脑必须一起工作，任何一个环节不稳，最终效果都会打折。

直播也暴露了问题

这场直播并不是没有瑕疵。

从澎湃新闻和其他观察者的描述看，直播中可以看到机器人偶尔出现短暂失误，例如抓取时判断不准、包裹位置偏移、甚至把包裹推到传送带外。

这些问题在演示视频里可能会被剪掉，但在真实工作中不能忽略。

物流场景尤其看重准确率。一个包裹掉落，可能只是一次小错误；但如果在大规模仓库里高频发生，就会带来人工复核、延误、损坏和责任问题。

美国机器人专家 Ayanna Howard 也提出过类似看法：这次演示更像科学项目，而不是已经成熟的商业服务。速度很重要，但在实际场景里，准确性、异常处理和监督成本同样重要。

分拣工真的要失业了吗

短期内不必把这场直播理解成“分拣工马上失业”。

Figure AI 展示的是一个相对受控、重复、边界清晰的任务。它证明了人形机器人正在接近某些物流动作的可用门槛，但还没有证明它可以无缝接管完整仓库流程。

真正的物流现场还会遇到更多复杂情况：

包裹破损、液体泄漏、形状异常。
条码污损或位置不可见。
多个包裹堆叠、遮挡、卡住。
人类员工临时介入。
设备报警、传送带停顿。
安全规范和责任划分。

人类工人擅长处理这些“非标准异常”。机器人要进入商业部署，不仅要在标准动作上接近人类，还要证明自己能稳定处理长尾问题。

更现实的变化，可能不是机器人完全替代人，而是先替代一部分重复、枯燥、夜间和高强度岗位，让人类转向监督、维护、异常处理和流程优化。

它对行业意味着什么

这场直播对人形机器人行业的意义，在于把竞争标准从“会不会做动作”推向“能不能持续工作”。

过去，行业经常比拼单项能力：走路、搬箱子、叠衣服、做饭、洗碗。现在，Figure AI 试图证明人形机器人能在真实任务里长时间运行，并且把过程放给公众看。

这会给同行带来压力。

如果其他公司仍然只发布剪辑视频，外界自然会问：为什么不直播？为什么不跑 8 小时？为什么不公开错误率？为什么不让机器人在接近真实的工业节奏下工作？

当然，直播不是最终答案。真正的商业化还要看：

单台机器人售价和租赁成本。
维护频率和电池寿命。
部署和调参成本。
单位时间处理量。
错误率和事故率。
与现有仓储系统的集成难度。
客户是否愿意为“人形”形态买单。

如果这些账算不过来，直播再火也只是一次漂亮的技术展示。

小结

Figure AI 的 F.03 分拣包裹直播，确实是人形机器人商业化路上的一个重要信号。

它让外界看到，人形机器人不再只是实验室里做几个动作的样机，而是开始尝试长时间、重复性、工业化任务。Helix-02 这种端到端全身自主路线，也让机器人从“固定动作机器”更接近“能理解场景的劳动工具”。

但它还不能证明人形机器人已经准备好大规模替代仓库工人。

速度、准确率、异常处理、成本、安全和维护，仍然是必须回答的问题。真正值得关注的，不是某个直播瞬间有多震撼，而是这些机器人能不能在真实客户现场，用可控成本连续工作数月。

如果它能做到，物流自动化的下一个阶段就真的来了。

直播链接

Figure AI F.03 Livestream - YouTube

参考资料

Cerebras IPO 大涨背后：晶圆级 AI 芯片能挑战英伟达吗

Mon, 18 May 2026 00:19:51 +0800

Cerebras Systems 终于登上了公开市场。

这家以“晶圆级 AI 芯片”闻名的公司，于 2026 年 5 月 14 日在纳斯达克挂牌交易，股票代码为 CBRS。根据 Cerebras 官方公告，其 IPO 发行价为每股 185 美元，公开发行 3450 万股 Class A 普通股，其中包括承销商全额行使的 450 万股超额配售权。

上市首日，Cerebras 股价大幅高开，一度接近 386 美元。按发行价计算，公司融资规模超过 55 亿美元，是 2026 年以来美国市场最受关注的 AI 硬件 IPO 之一。

这也是为什么它会被很多媒体称为“英伟达挑战者”。不过，把 Cerebras 简单理解成“下一个英伟达”并不准确。它真正特殊的地方，是选择了一条和传统 GPU 完全不同的技术路线。

Cerebras 做的不是普通 GPU

Cerebras 的核心产品是 WSE，完整名称是 Wafer-Scale Engine，中文通常可以理解为“晶圆级引擎”。

传统芯片制造会把一整片晶圆切割成许多小芯片，再进行封装、测试和出货。Cerebras 反过来做：它尽可能把整片晶圆直接做成一颗超大芯片。

这条路线的好处很直观：

芯片面积更大。
片上计算单元更多。
片上 SRAM 更接近计算核心。
数据在芯片内部移动距离更短。
更适合特定 AI 推理和训练负载。

在 AI 计算里，数据搬运往往比单纯计算更难优化。Cerebras 的思路是尽量把计算和存储留在同一片硅上，减少数据频繁离开芯片带来的延迟和能耗。

这也是 WSE 路线最吸引人的地方：它不是沿着 GPU 的老路继续堆规模，而是试图用更大的单颗芯片，换取更高的片上带宽和更低的数据移动成本。

为什么市场会兴奋

AI 芯片市场目前高度依赖英伟达。无论是训练大模型、部署推理服务，还是建设 AI 数据中心，英伟达 GPU 都是最主流的选择。

这让市场天然会关注两类公司：

能否降低对英伟达供应链依赖。
能否在某些 AI 工作负载上提供更高性能或更低成本。

Cerebras 正好踩中了这两个叙事。

它不是做通用 CPU，也不是做普通加速卡，而是直接围绕 AI 训练和推理设计系统。公司也一直强调，其晶圆级芯片和云端推理平台在某些模型推理场景中可以提供极高吞吐。

这类故事在 2026 年非常容易被市场放大。AI 基础设施仍在扩张，企业、云厂商和模型公司都在寻找更多算力来源。只要一家芯片公司能证明自己在某些场景里不是“又一个小 GPU”，市场就会愿意给它很高关注度。

OpenAI 合作让想象空间变大

Cerebras 被关注的另一个原因，是它和 OpenAI 的关系。

据媒体报道，Cerebras 与 OpenAI 签订了金额超过 200 亿美元的合作协议。搜狐原文提到，截至 2025 年底，这一协议带来的剩余履约义务达到 246 亿美元。

对一家刚上市的 AI 硬件公司来说，这类长期协议非常重要。它意味着公司不只是有技术故事，还有大客户需求作为支撑。

不过，长期订单和最终收入之间并不能直接画等号。AI 数据中心建设还受制于制造产能、封装、供电、交付节奏、客户预算和模型路线变化。尤其是芯片公司，拿到订单只是第一步，能否按期交付、能否稳定扩产、能否把毛利率做出来，才是更难的部分。

客户集中仍然是最大风险之一

Cerebras 的风险也很明显：客户集中度高。

搜狐原文提到，G42 曾在 2024 年贡献 Cerebras 85% 的收入，2025 年降至 24%；阿联酋穆罕默德·本·扎耶德人工智能大学则在 2025 年贡献了 62% 的收入。这意味着，即便 G42 占比下降，公司收入仍然高度依赖少数大客户。

对 AI 基础设施公司来说，客户集中有两面性。

好处是：大客户能带来快速增长、长期合同和订单可见性。

风险是：如果客户削减预算、改变技术路线、延后数据中心建设，或者监管环境发生变化，公司收入波动会非常大。

这也是市场看 Cerebras 时不能只看 IPO 涨幅的原因。上市首日股价反映的是热度和预期，长期估值最终还是要看收入结构、交付能力、利润率和客户多元化。

技术路线的短板：内存容量

WSE 的优势很突出，但短板也同样清楚。

搜狐原文提到，WSE-3 芯片配备 44GB SRAM，而英伟达 B200 配备 192GB 内存。Cerebras 的设计把大量计算和 SRAM 放在同一片晶圆上，这能减少数据移动，但也限制了可用内存容量。

对大模型来说，内存容量直接影响上下文长度、批处理规模和模型部署方式。上下文窗口越来越长，旗舰模型已经普遍朝百万级 token 上下文发展。在这种趋势下，片上 SRAM 的容量限制会成为现实约束。

传统 GPU 可以通过 HBM 堆叠、封装扩展和多卡互联继续增加内存容量。Cerebras 的晶圆级路线则更难简单扩内存，因为整片晶圆面积已经被计算单元和 SRAM 占用。想增加 SRAM，就可能牺牲计算面积。

这不代表 Cerebras 技术路线失败，而是说明它更像一种面向特定工作负载的架构选择。它可能在某些推理场景非常强，但未必能覆盖所有 AI 训练和推理需求。

它会取代英伟达吗

短期内，Cerebras 不太可能取代英伟达。

英伟达的优势不只是 GPU 性能，还包括 CUDA 生态、开发者工具、系统集成、网络互联、整机方案、云厂商支持和客户迁移成本。AI 公司选择英伟达，很多时候不是因为单颗芯片某个指标最好，而是因为整套生态最稳。

Cerebras 更现实的机会，是在特定 AI 负载上成为补充方案：

高吞吐推理。
特定大模型服务。
对延迟和片上带宽敏感的任务。
想降低单一 GPU 供应链依赖的客户。
愿意为性能试用新架构的大模型公司。

也就是说，它不是“英伟达杀手”，更像是 AI 算力市场里一条激进的替代路线。

小结

Cerebras IPO 大涨，说明资本市场仍然愿意为 AI 基础设施故事付出高溢价。

它的晶圆级芯片路线确实有独特性，也让它和普通 AI 加速卡公司区分开来。再加上 OpenAI 等大客户合作，Cerebras 有了足够强的市场想象空间。

但风险同样不能忽视：客户集中、交付压力、内存容量限制、生态壁垒，以及和英伟达竞争时的系统级差距，都会决定它能走多远。

对普通读者来说，Cerebras 最值得关注的不是股价涨了多少，而是它证明了一件事：AI 算力竞争不会只有 GPU 一条路。未来的大模型基础设施，可能会同时容纳 GPU、晶圆级芯片、自研加速器和云端专用推理平台。

参考资料

Gemini 3.5 Pro 曝光：代号 Cappuccino，谷歌想在编程和 Agent 上追回节奏

Sun, 17 May 2026 11:47:27 +0800

Google 还没有正式发布 Gemini 3.5 Pro。

目前能看到的信息，主要来自开发者社区截图、匿名跑分、爆料人消息和媒体转述。36Kr / 新智元在 2026 年 5 月 15 日整理称，新一代 Gemini 检查点内部代号可能是 Cappuccino，相关模型已经在社区和评测平台中提前曝光。

这类信息还不能等同于官方发布，但它透露出一个清晰方向：Google 正在试图同时补上两块短板，一块是编程和推理能力，另一块是全天候 AI Agent。

先说结论

这次爆料可以拆成三层来看：

Gemini 3.5 Pro 尚未正式发布，Cappuccino 更像是内部检查点或候选版本代号。
曝光信息显示，新 Gemini 在代码生成、SVG / 交互式 Web 生成、多模态输出上有明显提升。
Google 同步测试的 Gemini Spark，可能比模型本身更关键，因为它指向 24 小时运行的个人 AI Agent。

换句话说，这不是一条简单的“模型跑分新闻”。它更像是 Google 在 I/O 前释放出的产品路线信号：模型要追赶 GPT-5.5，Agent 要抢占用户工作流入口。

Cappuccino 是什么

36Kr 文章提到，网友 Lentils 放出的消息显示，代号 Cappuccino 的 Gemini 3.5 Pro 检查点已经开始产出。此前社区还在讨论 Gemini 3.2，但最新曝光直接跳到了 3.5。

如果这个命名最终属实，说明 Google 可能希望把下一代 Gemini 包装成一次更大的版本跃迁，而不是普通小版本更新。

需要注意的是，Cappuccino 现在仍应被视为爆料中的内部代号。它不等于 Google 已经公开上线的正式模型，也不代表最终发布名一定就是 Gemini 3.5 Pro。

编程能力为什么是焦点

这次爆料里最受关注的点，是新 Gemini 的编程能力。

36Kr 引述的社区截图和跑分信息显示，新模型在以下任务上表现更强：

生成 SVG 与视觉组件。
生成交互式 Web 应用。
处理动画、3D、可调参数面板等复杂前端输出。
逻辑推理和代码生成能力有所提升。

文章还提到，Abacus.AI CEO Bindu Reddy 转述的说法是，3.2 Flash 在编码和推理上接近 GPT-5.5 的水平，同时成本更低。另有媒体信源则认为，新款 Gemini 的整体性能大致追平 GPT-5.5，但未必能带来质变。

这也是为什么要谨慎看待“追平 GPT-5.5”这句话。它更像是不同爆料源和匿名评测中的相对判断，而不是 Google 官方给出的基准测试结论。

为什么 Google 急着补编程

AI 编程已经从开发者工具变成了大模型竞争的核心战场。

OpenAI 有 Codex，Anthropic 有 Claude Code。它们不只服务工程师，也在把产品经理、设计师、运营人员带进“自然语言生成可运行产品”的工作流里。

相比之下，Google 虽然有 Gemini 和 Antigravity，但在开发者心智里一直没有形成同等强度的默认入口。36Kr 文章也提到，Antigravity 在外部市场还没有真正突围，定价、额度提醒和体验稳定性都曾引发社区讨论。

所以新 Gemini 如果要证明自己，编程会是最直接的战场。它不一定只比拼“会不会写代码”，还要比拼能不能稳定产出完整界面、理解复杂需求、调用工具、修复错误并融入真实开发流程。

Spark 可能比 3.5 Pro 更重要

同一波爆料里，Gemini Spark BETA 也被扒出。

根据 TestingCatalog 等信息源的说法，Spark 的定位接近“全天候 AI Agent”：它可以处理收件箱、执行在线任务、管理多步骤工作流，并连接 Google 应用、技能模块、聊天记录、定时任务、登录网站、位置信息等上下文。

这意味着 Spark 不是一个普通聊天入口，而是一个可能长期在线、持续读取上下文并替用户执行任务的系统。

它的吸引力很明显：如果 Google 能把 Gmail、Calendar、Chrome、Android、Workspace 和 Gemini 串起来，Spark 会天然拥有 OpenAI 和 Anthropic 很难复制的分发优势。

但风险也同样明显。36Kr 文章提到，Spark 相关说明中出现了“可能在未经询问的情况下分享信息或完成购买”的表述。哪怕系统设计上会在敏感操作前征求许可，这类 Agent 仍然会带来隐私、授权边界和误操作风险。

这对普通用户意味着什么

如果你只是普通 Gemini 用户，这次爆料真正值得关注的不是模型名，而是三个变化：

第一，Google 可能会继续强化“生成完整结果”的能力。以前用户经常吐槽 Gemini 在视觉生成、SVG、前端页面上容易偷懒，如果新模型能一次给出多个完整方案，体验会明显改善。

第二，编程能力会继续下放到更轻量的模型。爆料里反复提到 Flash 版本在编码、推理和交互式生成上的提升，这意味着未来不一定只有 Pro 模型才能处理复杂任务。

第三，Agent 会变得更主动。Spark 如果发布，Gemini 可能不再只是回答问题，而是开始长期接管邮件、网页、购买、日程和跨应用任务。

这对效率是好消息，对权限管理则是新挑战。

这对开发者意味着什么

开发者更应该关注两个问题。

第一个问题是工具生态。36Kr 文章提到，社区从模型选择器里看到了 MCP Tool Testing 这类未公开入口。如果 Gemini 原生支持 MCP 或第三方工具测试，那么它会更容易接入开发者自己的工具链。

第二个问题是成本和稳定性。即便新 Gemini 在某些基准上追平 GPT-5.5，开发者最终还是会看三件事：实际代码质量、上下文稳定性、价格和额度是否可预期。

过去一年，AI 编程工具竞争已经证明，模型能力只是门票。真正让开发者留下来的，是能不能在日常项目里持续可靠地改代码、跑测试、读上下文、处理边界条件。

现在应该如何看待这条消息

这条消息适合用“强信号、弱确认”来理解。

强信号在于：多个社区线索都指向 Google 正在准备更强的新 Gemini，以及更主动的 Gemini Spark Agent。

弱确认在于：Gemini 3.5 Pro 还没有官方发布，Cappuccino 仍是爆料代号，所谓“追平 GPT-5.5”的说法也需要等 Google 官方基准、第三方评测和真实用户测试来验证。

所以现在最稳妥的判断是：

不要把它当成已发布产品。
可以把它当成 Google 下一阶段 Gemini 路线的提前预告。
重点关注 I/O 或后续官方活动中是否会确认模型命名、API 可用性、价格、上下文窗口、工具调用和 Agent 权限边界。

总结

Gemini 3.5 Pro / Cappuccino 的曝光说明，Google 可能正在为下一代 Gemini 做一次更强势的版本推进。它要补的不是单一能力，而是整个 AI 工作流：模型要更会写代码、生成界面和处理复杂推理，Spark 则要把 Gemini 推向全天候 Agent。

但在官方发布前，所有跑分和截图都只能作为线索。真正决定 Gemini 3.5 Pro 能否翻身的，不是代号是否好听，而是它能否在真实开发、真实办公和真实多步骤任务里稳定胜出。

参考链接：

Anthropic 2028 AI 领导权报告解读：美国、中国、算力与两种未来情景

Sun, 17 May 2026 08:56:12 +0800

Anthropic 在 2026 年 5 月 14 日发布了一篇政策文章：《2028: Two scenarios for global AI leadership》。这篇文章讨论的不是某个 Claude 模型的能力，而是一个更大的问题：到 2028 年，全球 AI 领导权可能落在哪一套政治与产业体系手中。

需要先说明的是，这是一篇带有明确政策立场的文章。Anthropic 的核心观点是：美国及其盟友应该保持并扩大在前沿 AI 上的领先，尤其要守住算力优势、收紧出口管制漏洞、限制模型蒸馏攻击，并推动美国 AI 技术栈在全球部署。下面是对原文主要论点的整理，不等于对所有判断的无条件背书。

文章的核心判断

Anthropic 把未来几年的 AI 竞争放在美国与中国之间理解。它认为，先进 AI 不只是商业产品，也是可能改变国家安全、军事能力、网络攻防、科研速度和社会治理方式的通用技术。

文章最重要的判断有三点：

前沿 AI 的竞争很大程度上是算力竞争。
美国和盟友目前在先进芯片、半导体设备、云基础设施和资本上占优。
如果美国不堵住出口管制和模型访问漏洞，中国 AI 实验室可能在 2028 年接近甚至追上美国前沿模型。

Anthropic 因此把 2028 年设想成两个分叉点：一个是民主国家保持明显领先，另一个是中美 AI 能力接近，形成更危险的“并跑”局面。

为什么 Anthropic 强调算力

原文反复强调 compute，也就是训练和部署前沿模型所需的先进芯片与计算资源。

Anthropic 的逻辑是：数据、人才和算法都重要，但如果没有足够算力，前沿模型很难持续迭代。更进一步，随着 AI 被用来辅助 AI 研发，算力优势会形成复利：更多算力带来更多实验，更多实验带来更好算法，更好模型又能帮助研发下一代模型。

这也是为什么文章把出口管制放在很高的位置。Anthropic 认为，美国过去几年限制先进 AI 芯片和半导体制造设备流向中国，已经对中国前沿模型发展形成约束。它还引用外部分析称，中美在先进算力上的差距可能继续扩大。

简单说，Anthropic 不是只关心“谁有更聪明的研究员”，而是关心谁能持续获得训练和部署最强模型所需的计算基础设施。

Anthropic 担心哪些漏洞

文章认为，现有出口管制虽然有效，但还不够。它重点提到两类漏洞。

第一类是算力获取漏洞。包括先进芯片走私、通过海外数据中心远程使用受限芯片，以及半导体制造设备相关限制不够完整。原文提到，美国出口管制主要管芯片销售，但对“远程访问海外数据中心中的受限芯片”覆盖不足。

第二类是模型访问漏洞，也就是所谓 distillation attacks。这里的“蒸馏攻击”不是普通学术训练技巧，而是指用大量账号绕过访问限制，系统性抓取美国前沿模型输出，再用这些输出训练或增强自己的模型。Anthropic 把这种行为描述为对美国模型能力的系统性抽取。

这两类漏洞在 Anthropic 看来，会削弱出口管制效果：即使中国公司买不到足够先进芯片，也可能通过海外算力和模型蒸馏维持接近前沿的能力。

两种 2028 情景

Anthropic 用两个假设情景说明今天的政策选择可能带来的结果。

情景一：美国和盟友保持扩大领先

在第一个情景中，美国和盟友守住了算力优势，出口管制漏洞被堵住，芯片走私和海外数据中心访问被更有效限制，针对模型蒸馏的防御和惩罚也更强。

在这个世界里，美国前沿模型领先 12 到 24 个月。这个领先不只是排行榜意义上的模型分数，而是会影响网络安全、金融、医疗、生命科学等关键行业。Anthropic 认为，这种领先能给民主国家争取时间，制定 AI 规则、安全规范和全球部署标准。

它还认为，美国 AI 技术栈如果成为全球经济基础设施，会进一步吸引盟友、市场和人才，形成自我强化循环。

情景二：中国 AI 生态接近前沿

第二个情景中，美国没有继续收紧漏洞，或者放松了对中国公司获得先进算力的限制。中国 AI 实验室通过海外算力、芯片获取、蒸馏攻击和快速国内部署，保持在接近前沿的位置。

在这个世界里，中国模型可能略弱于美国模型，但通过更快的国内采用、更低成本、更灵活的本地部署，以及在部分国家和市场的基础设施输出，获得实际影响力。

Anthropic 担心的是，这种“并跑”状态会加剧军用、网络攻防和国内治理方面的风险，也会让美国和中国 AI 公司都更有压力加快发布，削弱安全评估和治理投入。

四个竞争前线

Anthropic 没有把 AI 竞争只看成模型能力竞赛。它列了四个前线：

智能水平：谁能开发最强模型。
国内采用：谁能更快把 AI 用到商业和公共部门。
全球分发：谁的 AI 技术栈成为全球经济运行基础。
社会韧性：谁能在 AI 带来的经济转型中保持政治和社会稳定。

其中，智能水平最重要，因为前沿模型能力会带动其他三项。但文章也提醒，只有模型强还不够。如果某一方把略弱的模型更快部署到经济、军事、政府和海外市场，也可能弥补能力差距。

这点值得注意：未来 AI 竞争不是单纯“谁模型参数更大”或“谁 benchmark 更高”，而是模型、芯片、云、应用、监管、国际市场一起竞争。

Anthropic 给出的政策建议

文章最后给出三个方向。

第一，堵住算力漏洞。包括打击芯片走私、限制通过海外数据中心访问受限芯片、加强半导体制造设备管制和执法预算。

第二，保护模型创新。包括限制模型访问、打击蒸馏攻击、推动美国 AI 实验室之间以及与政府之间共享威胁情报。

第三，推动美国 AI 出口。也就是让美国和盟友开发的硬件、模型、云和应用成为全球可信 AI 基础设施，避免中国 AI 生态通过低价和本地部署优势扩大影响。

这些建议本质上都服务于一个目标：让美国和盟友在 2028 年之前建立更稳固的前沿 AI 领先。

这篇文章值得怎么看

这篇文章的重要性不在于它提供了新的模型技术细节，而在于它把 Anthropic 对 AI 地缘政治的判断说得非常直接。

它代表了一种越来越常见的硅谷 AI 公司政策叙事：前沿 AI 不只是产品竞争，而是国家能力竞争；模型能力、芯片供应链、云基础设施、出口管制和安全治理必须放在一起看。

但阅读时也要保持区分：

文中关于美国应保持领先的部分，是 Anthropic 的政策主张。
文中关于中国 AI 能力、出口管制效果、蒸馏攻击规模的部分，混合了事实、外部引用和 Anthropic 的判断。
两个 2028 情景是推演，不是预测结果。

也就是说，它更适合作为“Anthropic 如何理解 AI 竞争”的材料，而不是一篇中立的全球 AI 产业报告。

总结

Anthropic 这篇《2028: Two scenarios for global AI leadership》把 2028 年设定为一个关键节点：如果美国和盟友守住算力、限制蒸馏攻击并推动自身 AI 技术栈全球采用，就可能获得 12 到 24 个月的前沿能力领先；如果不行动，中国 AI 生态可能接近前沿，并通过国内采用和全球低成本部署获得影响力。

这篇文章释放的信号很清楚：Anthropic 正在把前沿 AI、安全治理、芯片出口管制和地缘政治放进同一个框架里讨论。未来围绕 AI 的竞争，可能不只是模型公司之间的竞争，也会越来越像算力、供应链、国家政策和全球基础设施之间的竞争。

参考链接：

Anthropic：2028: Two scenarios for global AI leadership

AI 数据中心为什么重新推高机械硬盘需求

Sat, 16 May 2026 21:02:33 +0800

过去两年，AI 基础设施的讨论大多集中在 GPU、HBM、先进封装和电力供应上。但在训练和推理系统背后，还有一个更容易被忽略的瓶颈：存储。

大模型不是只在显卡里完成一次计算就结束。训练过程中会不断产生 checkpoint、优化器状态、训练日志、数据版本和中间结果；推理阶段也会产生用户交互记录、合规留存、审计数据和系统日志。这些数据不一定都要放在最快的介质上，但它们往往不能立刻删除。

这就是机械硬盘重新变重要的原因。

AI 训练会制造大量冷数据

大模型训练需要定期保存 checkpoint。它可以理解成训练过程中的存档点：如果训练中途崩溃，系统可以从某个 checkpoint 恢复，而不是从头重跑。

对大模型来说，一个 checkpoint 可能就是数 TB。一次完整训练持续数周甚至数月，中间可能保存大量 checkpoint。即便后续会清理一部分，训练过程、回溯、复现实验和模型审计仍然需要保留大量数据。

除了 checkpoint，训练数据本身也在膨胀。高质量文本、图片、视频、代码数据需要清洗、去重、切分和版本管理。随着合成数据、强化学习数据和多模态数据进入训练流程，存储压力会继续增加。

这些数据的特点是：

容量巨大；
不一定高频访问；
需要长期保留；
对单位容量成本非常敏感。

这类数据并不适合全部放在昂贵的高速存储里。

为什么不是全部用 SSD

SSD 的速度明显更快，但数据中心不能只看速度。对于 PB 级甚至更大规模的冷数据，单位容量成本会直接决定系统是否可持续。

AI 集群里可以把存储分成几个层级：

HBM 和显存负责最热、最紧急的数据；
DRAM 负责临时周转；
SSD 负责高频访问、低延迟需求更强的数据；
HDD 负责海量冷数据、备份、日志、checkpoint 归档和长期留存。

换句话说，SSD 不是不重要，而是不能替代所有层级。真正的大规模系统往往需要分层存储：热数据追求速度，冷数据追求容量、成本和可靠性。

当 AI 公司开始长期保存训练残留、模型版本、合成数据、推理日志和审计记录时，HDD 的价值就重新被放大了。

机械硬盘产能为什么会紧张

机械硬盘市场过去多年增长并不亮眼，消费端电脑也越来越多转向 SSD。但数据中心的需求逻辑不同。

云厂商和 AI 公司需要的是大容量、可预测交付、单位 TB 成本低的近线硬盘。对于硬盘厂商来说，这类客户通常会签长期供货协议，优先级也高于零散消费市场。

这会带来几个结果：

高容量企业盘产能被大客户提前锁定。
消费级硬盘和普通渠道能分到的供应变少。
新产能释放需要时间，短期内很难快速补上。
机械硬盘从过去的低关注度硬件，变成 AI 基础设施的一部分。

更关键的是，机械硬盘行业本身已经高度集中。主流供应商数量有限，先进大容量硬盘的产能爬坡也不是简单扩厂就能立刻完成。HAMR 等新技术可以提高单盘容量，但从技术量产到稳定大规模交付仍然需要周期。

存储涨价会传导到消费端

AI 数据中心吸走的不只是 GPU 和电力，也会影响存储供应链。

当企业级 SSD、内存、机械硬盘的产能更多流向云厂商和 AI 基础设施，消费级市场就可能感受到价格压力。普通用户看到的 SSD、内存或硬盘涨价，并不一定只是零售端波动，而可能来自上游产能重新分配。

这种影响通常不是线性的。大客户签的是长期协议，价格、交付和产能安排更稳定；消费端则更容易承受现货市场波动。于是就会出现一种现象：AI 数据中心需求增长，最终让普通消费者买存储设备也变贵。

投资视角需要更谨慎

AI 对存储的拉动是真实的，但这不等于所有存储相关公司都会长期受益。

机械硬盘和闪存仍然有周期属性。价格上涨、产能紧张和客户长约会改善短期业绩，但一旦新产能释放、需求增速放缓，行业仍可能回到供需再平衡。对硬件公司来说，最需要关注的不是某一次涨价，而是需求是否能持续、毛利率是否改善、产能扩张是否过度，以及客户结构是否足够健康。

更稳妥的理解是：AI 正在改变存储行业的需求结构。过去外界更关注算力，现在越来越多成本会转向数据保存、数据治理和模型生命周期管理。

结论

AI 不是只消耗算力，它还持续制造数据。

GPU 负责计算，HBM 负责高速喂数据，SSD 负责热数据访问，而机械硬盘负责承接庞大的冷数据底座。只要大模型训练、合成数据、推理日志和合规留存继续增长，数据中心就需要大量低成本、高容量的存储介质。

机械硬盘看起来不像 AI 时代的明星硬件，但它正在变成 AI 基础设施里不可缺的一层。越先进的模型，越离不开庞大的存储系统；越昂贵的算力，越需要可靠的 checkpoint 和归档能力来保护已经投入的成本。

AI Agent 到底怎么进化的？2022-2026 五代演进完整梳理

Sat, 16 May 2026 19:19:52 +0800

AI Agent 的发展不是一夜之间发生的。

2022 年底，ChatGPT 还只是一个会聊天的窗口。到 2026 年，Agent 已经开始具备工具调用、文件操作、电脑控制、长期记忆、远程协作和常驻执行能力。四年时间里，它从“回答问题的模型”逐步变成“能推进任务的数字工作者”。

如果按时间线看，AI Agent 大致经历了五代演进。每一代都解决了上一代的核心缺陷，也制造了新的泡沫和新的安全问题。

总览：五代 Agent 时间线

阶段	时间	关键词	能力变化	核心问题
第零代	2022 年末 - 2023 年初	对话框	会生成文本，但不能行动	模型和现实世界断裂
第一代	2023 年中 - 2023 年末	工具调用	能输出结构化调用，接入 API 和 RAG	开环循环、任务迷路
第二代	2023 年末 - 2024 年	工程化工作流	有规划、状态、反思和多 Agent 协作	工作流易复制，低代码泡沫
第三代	2024 年 - 2025 年	Computer Use	能看屏幕、点鼠标、操作 GUI	权限、安全和误操作风险
第四代	2025 年 - 2026 年	MCP / Skills / 常驻	有工具网络、长期上下文和专业技能	常驻执行扩大风险半径
第五代前瞻	2026 年之后	闭环与世界模型	可能拥有更强记忆、验证和物理行动能力	治理难度继续上升

下面按时间线展开。

2022 年末：第零代，ChatGPT 对话框时代

第零代的起点，是 2022 年 11 月 30 日 ChatGPT 发布。

这一代 AI 还不能算真正的 Agent。它有很强的语言生成能力，但主要被困在对话框里。它可以写一段 Python 代码，却不能在你的电脑上运行；可以规划旅行，却不能打开网站订票；可以告诉你文件应该怎么改，却不能进入文件系统执行修改。

这一代的能力边界很清楚：

能理解自然语言；
能生成文章、问答、代码和方案；
不能主动访问最新数据；
不能稳定读取企业内部资料；
不能执行外部动作；
不能管理长期任务状态。

所以第零代最核心的问题是：模型能力和现实世界之间断裂。它能想、能说，但不能行动。

这一阶段也出现了第一波泡沫：提示词工程师、提示词模板市场、提示词课程和提示词认证。早期模型确实对 prompt 很敏感，但市场把一个临时补丁误解成了长期护城河。

后来 GPT-4 级别模型、系统提示、函数调用和产品默认引导逐渐成熟，大量提示词模板失去稀缺性。这个现象后来反复出现：新能力出现时，中间层爆发；下一代系统把能力内化后，中间层蒸发。

2023 年中：第一代，工具调用觉醒

第一代 Agent 的关键词是工具调用。

2023 年 6 月，OpenAI 发布 function calling。它允许开发者向模型描述函数名、用途、参数类型和 JSON Schema。模型理解用户请求后，可以不再输出普通自然语言，而是输出一个结构化 JSON 调用，再由外部系统执行。

这一步的架构意义很大：模型开始从“只会说话的大脑”，变成可以驱动外部工具的大脑。

第一代的关键能力包括：

根据用户意图选择工具；
输出结构化参数；
调用外部 API；
把 API 结果带回模型继续推理；
通过 RAG 接入外部知识；
通过插件和知识库形成早期 persona。

同一时期，RAG 和向量数据库流行起来。它们解决的是模型不知道最新信息、企业私有资料和内部知识的问题。系统先检索相关文档片段，再把材料放进上下文，让模型基于这些材料回答。

于是第一代 Agent 的基本结构出现了：

你是谁：系统提示和 persona；
你知道什么：知识库、RAG、私有文档；
你能做什么：函数调用、插件、外部 API。

这一代最典型的泡沫是 AutoGPT。它展示了一个很诱人的想法：用户只给一个宏大目标，AI 自己拆解任务、搜索、写文件、评估、循环，直到它认为完成。

但 AutoGPT 很快暴露问题。它缺少状态约束、终止条件和可靠反馈，经常陷入错误方向，反复调用错误参数，或者烧掉大量 API 请求。第一代的教训很直接：工具加死循环，不等于生产级 Agent。

2023 年末到 2024 年：第二代，工程化工作流

AutoGPT 的失败让行业意识到，不能只靠模型自由发挥。复杂任务需要结构化流程。

第二代 Agent 的关键词是工程化工作流。Agent 不再只是一次模型调用，而是一个有状态、有控制流、有评估机制的软件系统。

这一代的关键能力包括：

任务规划：把大目标拆成步骤；
状态管理：记录任务进行到哪里；
反思修正：生成后自评，再修改；
工具编排：在不同工具之间切换；
人机协作：在关键节点让人确认；
多 Agent 协作：让不同角色分工。

典型范式是 ReAct，也就是 Reasoning + Acting。模型先推理，再调用工具，再根据观察结果进入下一轮推理。这样 Agent 不再盲目行动，而是每一步都有可审计的逻辑和反馈。

这一阶段也形成了 agentic workflow 的几种常见模式：

反思：先生成，再评审，再修改；
工具调用：按任务选择搜索、数据库、代码执行、企业 API；
规划：拆解目标，跟踪状态；
多 Agent 协作：产品、开发、测试、评审分工。

第二代的价值，是把模型能力放进可控流程里。一个设计好的 workflow，有时能让较小模型完成比单次大模型调用更稳定的结果。

但这一代也带来低代码 Agent 平台泡沫。很多平台用拖拽方式组合 prompt、RAG、插件和流程，确实降低了搭建门槛。但如果一个流程可以被低成本复制，平台本身就很难形成护城河。

低代码工具能吃到早期红利，但红利不等于壁垒。

2024 到 2025 年：第三代，Computer Use 进入真实界面

第三代 Agent 的关键词是 Computer Use。

此前的工具调用主要依赖 API，能做什么取决于开发者提前接好什么接口。但现实世界里，大量软件没有理想 API，或者 API 不开放、不完整、不统一。

Computer Use 类能力让模型开始看屏幕、点鼠标、操作 GUI。它把通用电脑界面本身变成工具。

第三代的关键能力包括：

识别屏幕内容；
点击按钮、输入文本、切换窗口；
操作网页和桌面软件；
读仓库、改文件、跑测试；
查看终端输出和错误信息；
更接近真实工程助手。

这一步把 Agent 从“调用已接好的工具”，推进到“像人一样操作软件界面”。它也让 coding agent 更接近真实工作流：读项目、改代码、运行测试、根据报错继续修。

但信任边界也扩大了。AI 操作电脑，意味着它可能误点、误删、误提交，也可能被网页、文档或界面文字诱导。提示注入不再只是聊天问题，而可能变成文件操作、权限和系统安全问题。

Vibe coding 的争议也集中在这一阶段。让 AI 快速生成项目很爽，但如果缺少测试、评估、权限控制和部署边界，就容易从快速原型变成快速事故。

第三代的核心教训是：越接近真实操作，越需要沙箱、审批、回滚和最小权限。

2025 到 2026 年：第四代，MCP、Skills 和常驻数字员工

第四代 Agent 的关键词是常驻、连接、记忆和专业化。

这一代的重点不只是单次任务更强，而是 Agent 开始拥有长期上下文、工具网络、专业技能和时间感。它不再只是一次聊天里的助手，而更像一个能持续工作的数字员工。

MCP 解决的是工具连接问题。它让 Agent 用标准方式连接文件系统、数据库、浏览器、设计工具、项目管理工具和企业系统。协议一旦稳定，很多只做“工具连接中间层”的项目就会被压缩。

Skills 解决的是专业方法问题。工具告诉 Agent 能做什么，技能告诉 Agent 应该怎么做。一个好的 skill 不只是 prompt，而是把领域流程、约束、检查方式、常见坑和工具调用顺序封装起来。

第四代的关键能力包括：

长期记忆：保存用户偏好、项目规则和历史任务；
项目上下文：让 Agent 理解代码库、文档和工作规范；
工具网络：通过 MCP、API、浏览器和文件系统连接外部世界；
专业技能：用 Skills 封装任务方法；
常驻执行：可以等待、唤醒、提醒和继续跟进；
远程协作：用户可以从不同设备回来审批和调整。

这一代 Agent 开始有“员工感”：

有身份和职责边界；
有长期上下文；
有专业工作方法；
有时间感；
有工具权限；
能在无人盯着时继续推进任务。

但能力越像员工，风险半径也越像员工。长期运行、读取本地数据、持有密钥、调用工具、处理任务，都让安全问题从边缘变成中心。

尤其要注意一点：文本也是攻击面。如果 Agent 会读取并遵循 Markdown、说明文档、技能包、网页内容，那么恶意文本就可能改变它的行为。提示注入不再只是聊天问题，而是供应链问题、权限问题和执行安全问题。

第四代的核心教训是：常驻 Agent 不只需要能力，还需要治理。

2026 之后：第五代前瞻，闭环、内在记忆和世界模型

第五代还不是确定历史，更像是沿着前面四年的演进逻辑继续外推。

第一个方向是更完整的闭环。

成熟 Agent 至少需要三层闭环：

执行闭环：每一步操作后验证结果，不符合预期就回滚、修正、重试；
时间闭环：跨多个唤醒周期追踪长期目标，而不是做完一次动作就结束；
认知闭环：知道哪些信息确定，哪些只是猜测，哪些已经过期。

第二个方向是内在记忆。

过去的记忆大多在模型外部：RAG、向量库、会话记录、本地文件、memory.md。如果未来模型架构本身支持跨会话持久状态，Agent 的记忆系统会被重构。

第三个方向是世界模型。

今天很多 Agent 仍是反应式的：观察、响应、再观察。真正高风险任务需要模型能预演行动后果。比如改数据库脚本前，要先想到数据丢失、回滚失败、兼容性问题，而不是先造成事故再学习。

第四个方向是具身化。

前几代主要发生在数字空间：API、屏幕、文件、浏览器、企业工具。下一步可能是把 Agent 的行动能力延伸到物理世界，例如机器人、设备控制、工业系统和标准化物理接口。

第五代真正要解决的问题，是如何让 Agent 不只会执行任务，还能理解行动后果、管理长期状态，并在更大风险半径内保持可靠。

这条时间线背后的六条规律

第一，基座模型能力仍然是天花板。Agent 不是大模型之外的魔法，而是大模型能力通过工程系统释放出来的方式。

第二，工程化架构会放大模型能力。规划、验证、反思、修正、评估和权限控制，比单次生成更接近可交付结果。

第三，开放协议会重塑价值分配。MCP、Skills、项目上下文规范一旦稳定，竞争焦点会从“谁先接了工具”转向“谁沉淀了真实领域能力”。

第四，Agent 演化的隐含主线是人机信任边界扩展。从信任文本，到信任 API 调用，到信任复杂工作流，到信任电脑操作，再到信任常驻执行，每一代都把风险半径往外推。

第五，每一代事故都会变成下一代铁律。AutoGPT 的无限循环推动结构化编排，vibe coding 的失控推动评估驱动开发，误删生产环境推动最小权限和沙箱，技能投毒推动供应链安全。

第六，Agent 生态会反复经历爆发和灭绝。能力升级会创造临时中间层，模型或平台内化后又会消灭这些中间层。把时间窗口误判成护城河，是 AI 创业里很危险的错觉。

真正的护城河

AI Agent 领域真正的护城河，不是抢先包装某个新能力。

更可靠的护城河大概有三类。

第一，垂直领域深度。你是否真的理解一个行业的流程、风险、异常和责任边界。通用模型可以学概念，但不一定能替代长期打磨出来的领域执行经验。

第二，数据飞轮。你是否能从真实使用中积累高质量反馈，不断改进流程、评估、微调和产品判断。

第三，用户信任。用户是否愿意把更高价值、更长期、更有风险的任务交给你，而不是只把你当成一次性工具。

当某项能力被平台或基座模型吞噬之后，仍然能沉淀流程、反馈、责任边界和信任的产品，才更可能留下来。除此之外，很多项目只是阶段性泡沫。

最后

从 2022 年到 2026 年，AI Agent 的演进不是“模型越来越会聊天”，而是“人类愿意交给 AI 的事情越来越多”。

真正成熟的 Agent，不是最敢自动执行的系统，而是知道何时执行、何时验证、何时暂停、何时请人确认的系统。

如果要判断一个 Agent 产品是否有长期价值，可以问一个问题：当这个能力被下一代模型或平台内置后，它还剩下什么？

答案如果是领域流程、真实数据、可验证结果和用户信任，那才可能是长期价值。

美国放行英伟达 H200：10 家中国企业获批，但交付仍有变数

Sat, 16 May 2026 17:12:09 +0800

美国对英伟达 H200 的对华出口许可终于出现实质进展。

据路透社相关报道，美国商务部已批准约 10 家中国企业购买英伟达 H200 AI 芯片。获批名单覆盖互联网大厂和供应链企业，包括阿里巴巴、腾讯、字节跳动、京东、联想、富士康等。不过截至 2026 年 5 月 14 日，H200 仍未在中国市场完成实际交付。

这件事需要分开看：美国侧已经给出部分许可，但这不等于芯片已经到货，也不等于中国企业马上可以大规模部署。

这次批准了什么

这次许可的核心信息有三点。

第一，美国商务部批准约 10 家中国企业购买 H200。按报道说法，获批客户既可以直接向英伟达采购，也可以通过授权中间商或分销商购买。

第二，每家获批客户最多可购买约 7.5 万颗 H200。这个数量如果全部落地，对大型云厂商和大模型公司来说，会明显改善高端 GPU 供给。

第三，联想已确认自己是获得英伟达出口许可、获准在中国销售 H200 的几家公司之一。联想和富士康这类企业的角色，不只是采购方，也可能承担服务器整机、机架系统、集成和分销环节。

但最关键的一点是：许可不等于交付。公开报道强调，目前尚未有 H200 完成对华交付。

H200 为什么重要

H200 属于英伟达 Hopper 世代加速卡，定位高于此前面向中国市场的 H20。H20 是为了适配早期出口限制而降规格的产品，H200 则拥有更强的算力和显存能力。

从公开资料看，H200 配备 141GB HBM3e 显存，在大模型训练、推理、长上下文服务、企业级 AI 部署等场景中都有明显价值。它不是英伟达最新的 Blackwell 世代产品，但对中国云厂商和 AI 公司来说，依然是高端算力资源。

这也是为什么 H200 一直处在中美 AI 芯片管制的敏感位置。美国希望限制中国获得最先进 AI 算力，同时又不想让英伟达彻底失去中国市场；中国则希望降低对美国 GPU 的依赖，把算力投资更多导向国产芯片和本土生态。

还没有真正落地

这次消息最容易被误读的地方，是把“获批购买”理解成“已经放开供应”。

从目前公开信息看，至少还有几层变量：

美国许可只是第一步，具体订单、审核、出货和合规流程仍要继续走。
中国侧是否允许企业实际进口和部署，仍需要政策层面的明确指导。
获批企业是否会立刻下单，也取决于价格、交期、国产替代方案和长期政策风险。
英伟达 H200 产能需要重新协调，因为公司原本已经把重心转向 Blackwell 和后续产品。

这意味着 H200 对华销售现在更像是“许可窗口打开”，而不是“货已经开始大规模进入中国机房”。

对英伟达意味着什么

对英伟达来说，中国市场仍然太重要。

在出口限制收紧后，英伟达在中国高端 AI 加速卡市场的份额已经明显受损。黄仁勋此前多次强调，不应轻易放弃中国市场，因为这既会影响英伟达收入，也可能削弱美国技术生态在全球 AI 开发者中的影响力。

如果 H200 最终可以交付，英伟达至少能部分恢复中国客户订单，也能让 CUDA 生态继续留在中国大模型和云计算工作流里。

但这笔生意不会回到过去那种无障碍状态。许可、配额、收入分成、第三方验证、再出口限制、客户身份审查，都可能成为长期成本。对英伟达来说，H200 不是简单卖货，而是在政策夹缝中维持市场存在感。

对中国企业意味着什么

对中国企业来说，H200 是短期算力补给，但不是长期确定性答案。

如果获批企业能够实际拿到 H200，大模型训练、推理服务、AI 云、智能体平台、企业私有化部署都会受益。尤其是已经深度依赖 CUDA 工具链的团队，使用 H200 的迁移成本远低于切换到全新硬件生态。

但政策不确定性会让企业更谨慎。今天能买 H200，不代表明年还能稳定采购；能买一批，不代表能形成长期扩容路径。大厂即使购买，也会继续推进国产 GPU、异构算力、推理优化和模型压缩，避免再次被单一供应链卡住。

所以 H200 对中国 AI 企业更像是缓冲垫，而不是彻底解决方案。

国产芯片压力不会消失

美国放行 H200，并不意味着国产 AI 芯片压力变小。相反，这可能让竞争更直接。

如果 H200 真正进入中国市场，国产芯片厂商会面对更强的性能和生态参照。客户会把训练稳定性、推理吞吐、显存容量、软件工具链、集群通信、运维成本拿来对比。

但国产芯片也有自己的机会。只要高端 GPU 进口仍受政策影响，企业就不会把长期算力底座完全押在英伟达身上。国产方案只要能在特定场景中做到成本可控、供应稳定、软件可用，就仍有空间。

更现实的格局可能是：高端训练和关键推理继续争取 H200 这类英伟达资源，规模化推理、政企项目和可控供应链场景更多转向国产或混合算力。

这件事应该怎么看

这次 H200 获批，最准确的理解是：中美 AI 芯片博弈出现阶段性松动，但远没有回到完全开放。

美国给了许可，是为了在管制和商业利益之间重新找平衡。英伟达想借 H200 重返中国高端 AI 芯片市场。中国企业想获得更强算力，但也必须评估进口不确定性和国产替代战略。

真正值得关注的不是“美国放不放行”这一个动作，而是后续三件事：

第一批 H200 是否能实际交付到中国客户手里。
获批企业是否会公开采购规模和部署场景。
中国侧是否会给出更明确的进口、采购和使用指引。

在这些问题落地前，H200 对中国市场仍然是一个被打开的窗口，而不是一条已经恢复畅通的供应链。

参考资料

Gemini 3.5 Pro 提前曝光：谷歌想用 Spark Agent 抢回 AI 编程入口

Fri, 15 May 2026 23:45:34 +0800

Gemini 3.5 Pro 还没正式发布，相关爆料已经开始升温。

这轮信息里有几个关键词：Gemini 3.5 Pro、代号 Cappuccino、Gemini Spark、AI 编程、MCP 工具接入。它们指向同一个方向：谷歌不只是想更新一个聊天模型，而是想把模型、工具、Agent 和 Google 生态入口重新绑在一起。

不过，在正式发布前，这些信息都应该按“爆料”看待。真正值得关注的不是某一张截图或某一个跑分，而是谷歌接下来可能要补的几块短板。

Gemini 3.5 Pro 为什么值得关注

从曝光信息看，Gemini 3.5 Pro 可能是一次跳级命名。

此前外界还在讨论 Gemini 3.2，随后又出现 Gemini 3.5 Pro 的说法。如果命名属实，说明谷歌想在新一轮发布里讲一个更大的版本故事，而不是只做常规小更新。

目前流出的重点主要集中在三方面：

编程和推理能力继续提升；
SVG、交互式页面、动画和 3D 生成能力增强；
新的 Agent 产品 Gemini Spark 可能进入前台。

这些方向并不意外。Gemini 系列一直强调多模态，谷歌也有足够强的分发渠道。真正的问题是，它能不能在开发者工具和 Agent 工作流上赶上 OpenAI、Anthropic 的节奏。

编程能力是谷歌最需要补的课

大模型竞争进入 2026 年后，编程已经不只是“模型能力测试项”，而是最直接的产品入口。

原因很简单：AI 编程工具有高频使用场景，也能产生大量可反馈的数据。开发者每天让模型读代码、改代码、跑测试、修 bug，这些交互天然会推动下一代模型和工具链继续进化。

过去一年，Claude Code 在开发者群体里声量很高，OpenAI 也持续强化 Codex 与 ChatGPT 的协同。相比之下，谷歌虽然有 Antigravity 等产品，但外部存在感并不算强。

这也是 Gemini 3.5 Pro 被重点观察的原因。如果它只是聊天更强、回答更快，意义有限；如果它能真正改善代码理解、跨文件修改、工具调用和长任务执行，才可能改变开发者工作流。

Gemini Spark 可能是更大的变量

比模型本身更激进的，是传闻中的 Gemini Spark。

按照曝光描述，Spark 的定位不是普通聊天助手，而是全天候运行的 AI Agent。它可能接入邮件、日程、网页、任务、账号状态和个人上下文，帮助用户处理多步骤工作流。

这类产品的想象空间很大。比如：

自动整理收件箱；
帮用户跟进任务；
在网页上执行操作；
处理跨应用流程；
根据个人偏好安排日常事务。

但风险也同样明显。一个全天候 Agent 如果能访问登录状态、浏览器数据、文件、位置和第三方服务，就必须回答几个问题：什么时候需要用户确认？哪些操作必须禁止自动执行？数据会不会被共享给第三方？远程浏览器和凭证如何隔离？

所以 Spark 真正的看点，不只是“能不能帮你干活”，而是谷歌能否把权限、审计、确认机制和用户控制做得足够清楚。

MCP 工具接入说明什么

爆料里还提到，新的 Gemini 选择器可能出现 MCP 相关模型或测试入口。

如果这部分最终落地，说明谷歌也在把模型从“问答系统”推向“工具操作系统”。模型不再只是生成文本，而是要能调用外部工具、访问业务系统、读写文件、执行命令，并在多个步骤之间保持任务状态。

这和 OpenAI、Anthropic 的方向是一致的。谁能让模型更稳定地调用工具，谁就更容易把 AI 嵌进真实工作流。

不过，MCP 接入本身不是终点。真正难的是稳定性：

模型能否正确选择工具；
参数是否可靠；
失败后能不能恢复；
权限边界是否明确；
用户能不能追踪每一步操作。

如果这些问题没解决，工具越多，出错面也越大。

多模态仍然是谷歌的优势牌

谷歌最有机会打出差异化的地方，仍然是多模态。

从曝光的 SVG、交互式页面、动画和视觉生成案例看，Gemini 可能继续强化“从提示词生成可交互内容”的能力。相比单纯写一段代码，这更接近产品原型生成：用户描述一个想法，模型直接给出可操作、可调节、可预览的界面。

这条路线很适合谷歌。它既能承接 Gemini 的多模态能力，也能和 Android、Chrome、Workspace、搜索、广告、云服务等入口结合。

如果谷歌想避免只在“谁的代码模型更强”上硬拼，它很可能会把重点放到更完整的多模态 Agent 系统上。

三家公司的打法正在分化

现在的大模型竞争已经不是单一模型排行榜竞争。

OpenAI 的优势在产品迭代和分发节奏，Codex、ChatGPT、企业工具和 API 之间的联动越来越紧。

Anthropic 的优势在开发者心智和代码模型质量，Claude Code 已经成了很多人默认的 AI 编程入口。

谷歌的优势则是生态入口。Gmail、Docs、Chrome、Android、搜索、YouTube、地图和云服务构成了一个巨大的个人与企业数据网络。只要 Agent 能安全接入这些入口，谷歌就有机会从“模型追赶者”变成“工作流入口控制者”。

这也是 Gemini Spark 值得关注的原因。它不一定需要在所有基准测试上第一，但只要能进入日常工作流，就可能形成自己的护城河。

普通用户该怎么看

对普通用户来说，短期不必被每一次爆料牵着走。

更实用的观察点有三个：

Gemini 3.5 Pro 的编程能力是否真的改善，尤其是复杂仓库、长上下文和工具调用。
Gemini Spark 是否默认安全，敏感操作前是否有明确确认和可追踪记录。
谷歌是否给出清晰价格、额度和企业权限管理，而不是只展示演示效果。

如果只是生成几张漂亮截图，价值有限。能不能稳定接入真实工作流，才是这一轮 AI Agent 产品的分水岭。

对开发者意味着什么

开发者最应该关注的不是“哪个模型赢了”，而是自己的工作流是否可迁移。

现在 Claude Code、Codex、Gemini、Antigravity、Cursor、Windsurf 等工具都在抢入口。如果把所有流程都绑死在某一个平台上，未来成本、额度、模型策略或权限规则一变，迁移会很痛。

更稳妥的做法是：

重要项目保留标准 Git 工作流；
自动修改后必须看 diff；
关键任务用测试和 CI 兜底；
不把生产凭证交给不透明 Agent；
能用开放协议接工具时，优先选择可替换方案。

模型会继续变强，但工程纪律不会过时。

小结

Gemini 3.5 Pro 的爆料说明，谷歌正在加速补齐 AI 编程和 Agent 入口。模型能力提升是一部分，Gemini Spark 这类全天候 Agent 可能才是更大的战略动作。

但越是能帮用户“自动干活”的系统，越需要严格的权限边界和可验证流程。对谷歌来说，真正的挑战不只是追上 GPT-5.5 或 Claude，而是把强模型、安全机制和生态入口组合成一个可信的日常工作流。

如果这一步做成，Gemini 不一定要在每个榜单上第一，也可能重新拿回一部分 AI 入口主动权。

大语言模型会先冲击哪些行业：从 Workforce Disruption 看 AI 影响

Fri, 15 May 2026 09:03:35 +0800

讨论大语言模型对就业的影响，最容易走向两个极端：一种说 AI 会替代所有白领，另一种说它只是提高效率，不会真的改变岗位结构。

更接近现实的说法是：LLM 不会按行业整齐地“消灭工作”，而是先重组任务。谁的工作里有大量阅读、写作、摘要、分类、检索、解释、客服、代码、报表、流程文档，谁就会先感受到 workforce disruption。

这种冲击不是简单的“失业”，而是三件事同时发生：

一部分任务被自动化。
一部分岗位被 AI 增强。
一部分入门级、重复型、协调型工作被重新定价。

先看一个判断框架

判断一个行业会不会被 LLM 影响，不要只看行业名字，要看任务结构。

高暴露任务通常有几个特征：

输入主要是文本、表格、代码、图片或文档。
输出主要是文本、结构化数据、方案、邮件、代码或报告。
判断规则可以被写成 checklist。
工作成果可以被人快速审核。
错误成本可控，或者可以通过人工复核降低风险。
任务频次高，流程重复。

低暴露任务则通常依赖现场操作、复杂人际关系、强责任背书、真实世界感知、监管许可或高风险决策。

所以，LLM 最先影响的不是“某个行业全部岗位”，而是行业里的知识处理层、文档层、沟通层和初级分析层。

客服和客户运营

客户运营是最先被 LLM 改造的领域之一。

原因很直接：大量客服问题可以从知识库、历史工单和流程规则中回答。LLM 能做意图识别、自动回复、工单摘要、升级判断、质检、话术改写和多语言支持。

最先被影响的岗位包括：

一线文字客服
工单处理员
售后支持
客服质检
客户成功助理
呼叫中心知识库维护

但这不意味着客服全部消失。复杂投诉、重大客户、强情绪沟通、退款争议、合规边界仍然需要人。变化更可能是：一个人管理更多会话，低复杂度问题被自动处理，高复杂度问题被升级给更少但更熟练的人。

行政、文秘和后台运营

WEF Future of Jobs Report 2025 把文书、秘书、收银、票务、数据录入等角色列为明显承压方向。ILO 的生成式 AI 职业暴露研究也指出，文书类岗位暴露最高。

这类岗位的共同点是：大量工作围绕信息整理和流程流转。

受影响任务包括：

会议纪要
日程协调
邮件起草
表格整理
数据录入
文档归档
报销和审批材料准备
内部通知和流程说明

这里的 disruption 会很快，因为很多企业不需要重构整个业务系统，只要把 AI 接进办公套件、IM、邮件和文档系统，就能减少大量低价值手工操作。

市场营销、广告和内容生产

营销行业会被深度改造，但不是因为 AI 能写几句广告语，而是因为内容生产链条被压缩了。

过去一次营销活动可能需要调研、定位、文案、海报、短视频脚本、落地页、邮件、社媒版本、A/B 测试素材。现在 LLM 和多模态工具可以把这些环节变成高并发生成和快速迭代。

受影响岗位包括：

初级文案
SEO 编辑
社媒运营
广告素材策划
邮件营销
商品描述编辑
内容本地化
品牌调性改写

真正留下价值的，不是“会写文案”，而是懂用户、懂渠道、懂转化、懂品牌边界，能判断什么内容值得投放。

软件开发和 IT 服务

软件开发不是简单被替代，而是被重新分层。

LLM 对代码生成、代码解释、测试补全、重构建议、迁移脚本、文档生成、日志分析、错误定位都有明显帮助。McKinsey 把软件工程列为生成式 AI 潜在价值最高的职能之一。

最容易被冲击的是：

简单 CRUD
样板代码
单元测试补齐
脚本自动化
API glue code
文档和注释
低复杂度 bug 修复
初级前端页面

但复杂系统设计、跨团队协作、架构取舍、线上事故处理、性能优化、安全边界、遗留系统迁移，仍然高度依赖经验。

开发者的变化是：写代码本身的重要性下降，定义问题、拆任务、审查 AI 输出、设计验证路径的重要性上升。

金融、保险和银行

金融行业会受到很大影响，因为它有大量文档、合规、分析、客服和销售流程。McKinsey 也把银行列为生成式 AI 影响较大的行业之一。

受影响任务包括：

投研摘要
客户问答
风险报告初稿
合规材料检索
贷款材料预审
保险理赔文本处理
反洗钱线索解释
内部知识库问答

不过金融不会轻易把最终决策交给模型。监管、责任、审计、数据安全都会让 AI 更多处在“辅助分析”和“文档加速”位置。真正被压缩的，是大量初级分析和后台文档处理时间。

法律和合规

法律行业对 LLM 的暴露也很高，因为法律工作中有大量阅读、检索、摘要、条款对比和文本起草。

可能被影响的任务包括：

合同初稿
条款摘要
尽调资料整理
判例检索
合规政策问答
法律意见书初稿
文档审阅
多版本合同对比

但法律服务的最终价值不只是文本。责任承担、策略判断、谈判、庭审、客户信任和监管许可仍然是人的壁垒。

更可能发生的是：初级律师和 paralegal 的大量文档劳动被自动化，资深律师负责更高层次的判断和风险背书。

媒体、出版和翻译

媒体和翻译行业会被直接冲击，因为 LLM 的核心能力之一就是语言生成和语言转换。

受影响任务包括：

快讯改写
摘要生成
标题生成
多语言翻译
字幕整理
采访稿清理
编辑初审
内容分发版本改写

高质量调查报道、深度采访、事实核查、观点判断和独家消息仍然需要人。但低附加值、批量化、模板化内容会越来越便宜。

翻译行业也会分层。通用文本和内部文档会被机器处理，高风险法律、医疗、文学、品牌创意和跨文化沟通仍需要专业译者把关。

教育和培训

教育不会被 LLM 整体替代，但会被重构。

LLM 可以做个性化答疑、作业反馈、测验生成、教案初稿、课程大纲、学习路径、语言练习和模拟面试。对培训机构和在线教育平台来说，这会显著降低内容生产和辅导成本。

受影响岗位包括：

助教
题库编辑
教案编写
基础答疑
课程运营
学习报告生成

但教育的核心不只是传递知识。激励、陪伴、课堂管理、价值观、成长判断和复杂反馈仍需要人。AI 更可能先替代“批量辅导”和“内容准备”，而不是替代优秀教师。

咨询、研究和企业服务

咨询、研究、审计、人力资源、企业服务都会受到影响，因为这些行业高度依赖信息收集、结构化分析和文档表达。

受影响任务包括：

行业资料初筛
竞品分析
访谈纪要
PPT 初稿
项目周报
数据解释
HR JD 生成
简历筛选
员工手册问答

这里最危险的不是合伙人，而是初级分析师的训练路径。过去新人通过大量资料整理、制表、写初稿来学习业务。AI 接管这些任务后，企业要重新设计新人培养方式，否则中长期会出现经验断层。

医疗、药企和生命科学

医疗领域的 AI 采用会更谨慎，但影响也会很深。

LLM 更容易先进入这些环节：

病历摘要
医患沟通材料
医学文献综述
临床试验文档
药物研发资料整理
医保和理赔材料
医疗客服
医生助手

医疗的核心诊断和治疗责任不会轻易交给模型，但文书和知识检索负担会下降。对医生来说，AI 更像减负工具；对医疗后台和药企研发支持岗位来说，任务结构会明显变化。

哪些行业相对没那么快

相对不容易被 LLM 快速冲击的行业，有几个共同点：工作依赖实体世界、现场操作、真实风险和强人际互动。

例如：

建筑施工
护理和养老现场服务
维修技工
物流搬运
餐饮后厨
消防和应急
农业现场作业
高端手工制造

但“没那么快”不等于不受影响。它们的排班、培训、报价、客服、库存、设备维护记录、质检报告、内部知识库，仍然会被 AI 改造。

真正会变化的是岗位结构

LLM 带来的 workforce disruption，不是简单的行业名单，而是岗位结构变化。

未来很多组织会出现三种变化：

第一，初级岗位减少。重复写作、整理资料、基础分析、简单代码、客服回复，会更容易被 AI 接管。

第二，中级岗位工具化。会用 AI 的员工能同时处理更多任务，不会用的人会显得更慢。

第三，高级岗位更强调判断。战略、审查、责任、复杂沟通、系统设计、风险取舍会更值钱。

所以真正的问题不是“AI 会不会影响我的行业”，而是“我的工作里有多少任务可以被文本化、流程化、检查清单化”。

小结

当前大语言模型最先影响的行业，集中在知识密集、文本密集、流程密集的领域：客服、行政、营销、软件、金融、法律、媒体、教育、咨询、医疗文书和研发支持。

但它们不会以同样速度、同样方式被改变。监管强、错误成本高、信任要求高的行业，会更偏向增强；流程重复、输出可审核、替代成本低的岗位，会更偏向自动化。

对个人来说，最重要的准备不是恐慌，而是拆解自己的工作：哪些任务可以交给 AI，哪些任务必须由人负责，哪些能力能让你成为审核者、编排者和最终负责人。

参考资料：

World Economic Forum, Future of Jobs Report 2025: https://www.weforum.org/publications/the-future-of-jobs-report-2025/
International Labour Organization, Generative AI and Jobs: https://www.ilo.org/publications/generative-ai-and-jobs-global-analysis-potential-effects-job-quantity-and
McKinsey, The economic potential of generative AI: https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/the-economic-potential-of-generative-ai-the-next-productivity-frontier
OpenAI / OpenResearch / University of Pennsylvania, GPTs are GPTs: https://openai.com/index/gpts-are-gpts/

黄仁勋 CMU 演讲真正想说什么

Thu, 14 May 2026 20:59:50 +0800

黄仁勋在 CMU 的演讲，表面上是在讲个人经历和创业故事，实际上是在给一批顶尖大学毕业生泼冷水。

他的核心意思不是“大家都会变得更轻松”，而是：AI 时代来了，过去那套稳定、体面、线性的职业路径可能不再成立。年轻人要准备重新吃苦，也要准备接受一些以前看起来不够光鲜的工作。

第一层：我小时候很苦，你们可能也会苦

黄仁勋讲自己小时候的经历：凌晨 4 点起床送报纸，后来去 Denny’s 洗碗。

这种故事当然有励志成分，但它不是普通的忆苦思甜。他面对的是卡耐基梅隆大学的学生，一群本来很容易进入投行、软件公司、科技巨头和高薪岗位的人。

所以这段话真正的指向是：不要默认自己毕业以后就能沿着过去那条舒服路线走下去。

AI 正在重写很多职业的价值。过去靠学历、简历和大厂通道获得稳定上升的模式，可能会被压缩。很多人可能会发现，自己也要经历一段更粗粝、更不体面、更需要从基础工作开始的时期。

第二层：脱下长袍，去做真正需要人的工作

黄仁勋从送报纸讲到去 Denny’s 洗碗，并把洗碗称为一次重要的职业晋升。

这句话很关键。他其实是在说，职业价值不一定来自头衔，而来自你是否进入了真实需求里。

放到今天的 AI 产业里，他想表达的可能是：不要只盯着投行、互联网软件公司、咨询公司、传统白领岗位。未来真正缺人的地方，可能在更基础、更工程化、更辛苦的环节。

比如：

建数据中心；
做电力和制冷；
做机房运维；
做水电和基础设施；
做 GPU 集群部署；
做 AI 工厂的工程交付。

这些工作听起来没有“进大厂写软件”那么体面，但在 AI 时代，它们可能就是新的关键岗位。

所以“去做水管工、电工、机房建设者”不是简单的玩笑，而是在提醒毕业生：AI 不只是模型和代码，它还需要电、土地、机房、网络、散热、运维和供应链。谁能把这些东西真实建出来，谁就站在产业最硬的地方。

第三层：真正困难的事总比想象中更难

黄仁勋还讲到，英伟达每次遇到困难时，团队都会想：这能有多难？

但事实是，每一次都比一开始想象得更难。

这也是创业者和工程师最该听进去的一句话。很多事情在 PPT 上看起来只是一个项目，在会议室里看起来只是一个路线图，在战略叙事里看起来只是一个趋势。但真正做起来，都会遇到供应链、资金、工程、客户、组织、竞争和时间压力。

AI 时代尤其如此。

训练模型很难，部署模型也难；做出 demo 很难，把 demo 变成可靠产品更难；买 GPU 很难，把 GPU 跑满、跑稳、跑出商业回报更难。

所以黄仁勋讲的不是轻松乐观，而是一种工程现实主义：你可以乐观，但不要低估困难。

这场演讲真正的提醒

如果把这场演讲压成一句话，大概是：

AI 时代不会自动奖励聪明人，它会奖励愿意进入真实困难、真实基础设施、真实工程现场的人。

CMU 的学生当然仍然有很多机会。但如果他们只是沿着过去师兄师姐的路径，去找一个稳定大厂岗位，然后在里面等待职业惯性继续运转，那么被时代淘汰也不是不可能。

黄仁勋真正想提醒他们的是：别只想着穿着毕业长袍走进体面办公室。未来的机会，可能在机房里，在电力系统里，在冷却管道旁，在 GPU 集群前，也在那些一开始看起来不够优雅、不够白领的工作里。

AI 改变的不只是软件岗位，也会重新定义什么叫“好工作”。

ProgramBench 原始榜单数据：模型成绩、成本与 200 个任务记录

Sun, 10 May 2026 12:42:41 +0800

ProgramBench 是一个面向 AI 编程能力的新基准。它评估的不是“在现有仓库里修一个 bug”，而是让模型根据已编译的可执行文件和使用文档，从零重建一个行为一致的程序。

这篇文章只做数据整理和简要说明。下面表格保留 ProgramBench 官网公开页面中的原始记录数据，方便后续引用和对比。数据来源包括 ProgramBench 首页、Extended Results 和 Task Instances，抓取时间为 2026-05-10T12:42:41+08:00。

数据口径

Resolved：完全通过隐藏行为测试的任务比例。
Almost resolved：通过不少于 95% 行为测试的任务比例。
Cost：每个任务实例的平均 API 成本，单位为美元。
Calls：每个任务实例平均调用 LLM 的次数。
所有模型都使用 mini-SWE-agent 评测，任务总数为 200。

主榜单

#	Model	Provider	Agent	Resolved	Almost resolved	Run
1	Claude Opus 4.7	Anthropic	mini-SWE-agent	0%	3.0%	https://programbench.com/run/claude-opus-4-7/
2	Claude Opus 4.6	Anthropic	mini-SWE-agent	0%	2.5%	https://programbench.com/run/claude-opus-4-6/
3	Claude Sonnet 4.6	Anthropic	mini-SWE-agent	0%	1.0%	https://programbench.com/run/claude-sonnet-4-6/
4	GPT 5.4	OpenAI	mini-SWE-agent	0%	0.0%	https://programbench.com/run/gpt-5-4/
5	Gemini 3.1 Pro	Google	mini-SWE-agent	0%	0.0%	https://programbench.com/run/gemini-3-1-pro/
6	Gemini 3 Flash	Google	mini-SWE-agent	0%	0.0%	https://programbench.com/run/gemini-3-flash/
7	Claude Haiku 4.5	Anthropic	mini-SWE-agent	0%	0.0%	https://programbench.com/run/claude-haiku-4-5/
8	GPT 5.4 mini	OpenAI	mini-SWE-agent	0%	0.0%	https://programbench.com/run/gpt-5-4-mini/
9	GPT 5 mini	OpenAI	mini-SWE-agent	0%	0.0%	https://programbench.com/run/gpt-5-mini/

扩展结果

#	Model	Provider	Agent	Resolved	Almost resolved	Cost	Calls	Run
1	Claude Opus 4.7	Anthropic	mini-SWE-agent	0%	3.0%	$3.81	93	https://programbench.com/run/claude-opus-4-7/
2	Claude Opus 4.6	Anthropic	mini-SWE-agent	0%	2.5%	$11.38	260	https://programbench.com/run/claude-opus-4-6/
3	Claude Sonnet 4.6	Anthropic	mini-SWE-agent	0%	1.0%	$26.73	472	https://programbench.com/run/claude-sonnet-4-6/
4	GPT 5.4	OpenAI	mini-SWE-agent	0%	0.0%	$0.33	16	https://programbench.com/run/gpt-5-4/
5	Gemini 3.1 Pro	Google	mini-SWE-agent	0%	0.0%	$1.51	94	https://programbench.com/run/gemini-3-1-pro/
6	Gemini 3 Flash	Google	mini-SWE-agent	0%	0.0%	$0.30	85	https://programbench.com/run/gemini-3-flash/
7	Claude Haiku 4.5	Anthropic	mini-SWE-agent	0%	0.0%	$0.80	124	https://programbench.com/run/claude-haiku-4-5/
8	GPT 5.4 mini	OpenAI	mini-SWE-agent	0%	0.0%	$0.04	18	https://programbench.com/run/gpt-5-4-mini/
9	GPT 5 mini	OpenAI	mini-SWE-agent	0%	0.0%	$0.03	15	https://programbench.com/run/gpt-5-mini/

200 个任务实例原始记录

#	Repository	Description	Lang	Stars	Tests	Best Score	Task
1	junegunn/fzf	:cherry_blossom: A command-line fuzzy finder	go	79,721	1,874	81.9%	https://programbench.com/task/junegunn__fzf.b56d614/
2	jesseduffield/lazygit	simple terminal UI for git commands	go	76,901	855	56.4%	https://programbench.com/task/jesseduffield__lazygit.1d0db51/
3	BurntSushi/ripgrep	ripgrep recursively searches directories for a regex pattern while respecting your gitignore	rs	62,855	1,994	79.7%	https://programbench.com/task/burntsushi__ripgrep.3b7fd44/
4	FFmpeg/FFmpeg	Mirror of https://git.ffmpeg.org/ffmpeg.git	c	59,217	3,050	5.3%	https://programbench.com/task/ffmpeg__ffmpeg.360a402/
5	sharkdp/bat	A cat(1) clone with wings.	rs	58,487	801	33.2%	https://programbench.com/task/sharkdp__bat.f822bd0/
6	typst/typst	A markup-based typesetting system that is powerful and easy to learn.	rs	52,957	1,724	28.0%	https://programbench.com/task/typst__typst.88356d0/
7	jgm/pandoc	Universal markup converter	hs	43,632	5,228	14.1%	https://programbench.com/task/jgm__pandoc.5caad90/
8	sharkdp/fd	A simple, fast and user-friendly alternative to ‘find’	rs	42,668	1,235	78.1%	https://programbench.com/task/sharkdp__fd.40d8eb3/
9	php/php-src	The PHP Interpreter	c	40,030	14,288	4.8%	https://programbench.com/task/php__php-src.c891263/
10	duckdb/duckdb	DuckDB is an analytical in-process SQL database management system	cpp	37,657	5,650	12.4%	https://programbench.com/task/duckdb__duckdb.bdb65ec/
11	ajeetdsouza/zoxide	A smarter cd command. Supports all major shells.	rs	35,994	531	76.5%	https://programbench.com/task/ajeetdsouza__zoxide.67ca1bc/
12	jqlang/jq	Command-line JSON processor	c	34,541	6,072	89.9%	https://programbench.com/task/jqlang__jq.b33a763/
13	dandavison/delta	A syntax-highlighting pager for git, diff, grep, rg –json, and blame output	rs	30,445	950	37.3%	https://programbench.com/task/dandavison__delta.acd758f/
14	sharkdp/hyperfine	A command-line benchmarking tool	rs	27,960	291	54.3%	https://programbench.com/task/sharkdp__hyperfine.327d5f4/
15	ggreer/the_silver_searcher	A code-searching tool similar to ack, but faster.	c	27,080	1,006	59.3%	https://programbench.com/task/ggreer__the_silver_searcher.a61f178/
16	facebook/zstd	Zstandard - Fast real-time compression algorithm	c	27,013	2,038	68.8%	https://programbench.com/task/facebook__zstd.1168da0/
17	facebookresearch/fastText	Library for fast text representation and classification.	cpp	26,511	312	75.6%	https://programbench.com/task/facebookresearch__fasttext.1142dc4/
18	robertdavidgraham/masscan	TCP port scanner, spews SYN packets asynchronously, scanning entire Internet in under 5 minutes.	c	25,544	2,549	57.0%	https://programbench.com/task/robertdavidgraham__masscan.b99d433/
19	tree-sitter/tree-sitter	An incremental parsing system for programming tools	rs	24,953	1,232	37.2%	https://programbench.com/task/tree-sitter__tree-sitter.5e23cca/
20	FiloSottile/age	A simple, modern and secure encryption tool (and Go library) with small explicit keys, no config options, and UNIX-style composability.	go	22,077	676	63.5%	https://programbench.com/task/filosottile__age.706dfc1/
21	rust-lang/mdBook	Create book from markdown files. Like Gitbook but implemented in Rust	rs	21,541	1,114	55.5%	https://programbench.com/task/rust-lang__mdbook.37273ba/
22	jarun/nnn	n³ The unorthodox terminal file manager	c	21,506	477	98.1%	https://programbench.com/task/jarun__nnn.cb2c535/
23	antonmedv/fx	Terminal JSON viewer & processor	go	20,433	2,047	75.7%	https://programbench.com/task/antonmedv__fx.86d0d34/
24	mikefarah/yq	yq is a portable command-line YAML, JSON, XML, CSV, TOML, HCL and properties processor	go	15,281	2,000	39.5%	https://programbench.com/task/mikefarah__yq.602586d/
25	Y2Z/monolith	⬛️ CLI tool and library for saving complete web pages as a single HTML file	rs	15,024	713	51.2%	https://programbench.com/task/y2z__monolith.8702e66/
26	direnv/direnv	unclutter your .profile	go	14,998	849	62.0%	https://programbench.com/task/direnv__direnv.02040c7/
27	google/brotli	Brotli compression format	c	14,673	441	90.7%	https://programbench.com/task/google__brotli.b3dc9cc/
28	tomnomnom/gron	Make JSON greppable!	go	14,424	224	90.2%	https://programbench.com/task/tomnomnom__gron.88a6234/
29	XAMPPRocky/tokei	Count your code, quickly.	rs	14,300	732	69.5%	https://programbench.com/task/xampprocky__tokei.505d648/
30	ast-grep/ast-grep	⚡A CLI tool for code structural search, lint and rewriting. Written in Rust	rs	13,541	882	11.9%	https://programbench.com/task/ast-grep__ast-grep.dde0fe0/
31	cheat/cheat	cheat allows you to create and view interactive cheatsheets on the command-line. It was designed to help remind *nix system administrators of options for commands that they use frequently, but not frequently enough to remember.	go	13,278	297	59.9%	https://programbench.com/task/cheat__cheat.b8098dc/
32	jonas/tig	Text-mode interface for git	c	13,200	1,586	83.9%	https://programbench.com/task/jonas__tig.8334123/
33	ninja-build/ninja	a small build system with a focus on speed	cpp	12,895	1,438	72.3%	https://programbench.com/task/ninja-build__ninja.cc60300/
34	Canop/broot	A new way to see and navigate directory trees : https://dystroy.org/broot	rs	12,619	539	67.0%	https://programbench.com/task/canop__broot.d6c798e/
35	orf/gping	Ping, but with a graph	rs	12,433	339	78.5%	https://programbench.com/task/orf__gping.26eb5b9/
36	svenstaro/genact	🌀 A nonsense activity generator	rs	11,995	232	59.1%	https://programbench.com/task/svenstaro__genact.16f96e3/
37	lz4/lz4	Extremely Fast Compression algorithm	c	11,781	1,496	82.7%	https://programbench.com/task/lz4__lz4.1519f46/
38	o2sh/onefetch	Command-line Git information tool	rs	11,745	1,166	81.7%	https://programbench.com/task/o2sh__onefetch.e5958ce/
39	bootandy/dust	A more intuitive version of du in rust	rs	11,609	584	70.9%	https://programbench.com/task/bootandy__dust.62bf1e1/
40	ekzhang/bore	🕳 bore is a simple CLI tool for making tunnels to localhost	rs	11,075	406	68.7%	https://programbench.com/task/ekzhang__bore.8e059cd/
41	BurntSushi/xsv	A fast CSV command line toolkit written in Rust.	rs	10,757	1,182	82.7%	https://programbench.com/task/burntsushi__xsv.f430466/
42	bellard/quickjs	Public repository of the QuickJS Javascript Engine.	c	10,565	3,034	3.6%	https://programbench.com/task/bellard__quickjs.d7ae12a/
43	hatoo/oha	Ohayou(おはよう), HTTP load generator, inspired by rakyll/hey with tui animation.	rs	10,201	899	72.5%	https://programbench.com/task/hatoo__oha.8dc6349/
44	tstack/lnav	Log file navigator	cpp	10,200	990	13.4%	https://programbench.com/task/tstack__lnav.ee34494/
45	sharkdp/hexyl	A command-line hex viewer	rs	10,086	906	82.8%	https://programbench.com/task/sharkdp__hexyl.2e26437/
46	lua/lua	A copy of the Lua development repository, as seen by the Lua team. Mirrored irregularly. All communication should be through the Lua mailing list https://www.lua.org/lua-l.html	c	9,908	1,338	43.1%	https://programbench.com/task/lua__lua.c6b4848/
47	johnkerl/miller	Miller is like awk, sed, cut, join, and sort for name-indexed data such as CSV, TSV, and tabular JSON	go	9,842	14,637	22.9%	https://programbench.com/task/johnkerl__miller.8d85b46/
48	sqlite/sqlite	Official Git mirror of the SQLite source tree	c	9,434	13,514	67.0%	https://programbench.com/task/sqlite__sqlite.839433d/
49	boyter/scc	Sloc, Cloc and Code: scc is a very fast accurate code counter with complexity calculations and COCOMO estimates written in pure Go	go	8,320	464	37.7%	https://programbench.com/task/boyter__scc.515f91c/
50	ariga/atlas	Declarative schema migrations with schema-as-code workflows	go	8,311	1,318	54.8%	https://programbench.com/task/ariga__atlas.6d81150/
51	pemistahl/grex	A command-line tool and Rust library with Python bindings for generating regular expressions from user-provided test cases	rs	8,103	1,312	73.9%	https://programbench.com/task/pemistahl__grex.fa3e8ed/
52	htop-dev/htop	htop - an interactive process viewer	c	8,021	693	85.1%	https://programbench.com/task/htop-dev__htop.523600b/
53	peco/peco	Simplistic interactive filtering tool	go	7,881	1,224	76.7%	https://programbench.com/task/peco__peco.4e58dad/
54	bensadeh/tailspin	🌀 A log file highlighter	rs	7,793	615	75.8%	https://programbench.com/task/bensadeh__tailspin.6278437/
55	ducaale/xh	Friendly and fast tool for sending HTTP requests	rs	7,754	1,171	50.0%	https://programbench.com/task/ducaale__xh.4a6e44f/
56	svenstaro/miniserve	🌟 For when you really just want to serve some files over HTTP right now!	rs	7,561	304	78.6%	https://programbench.com/task/svenstaro__miniserve.8449e8b/
57	mgdm/htmlq	Like jq, but for HTML.	rs	7,520	1,455	93.9%	https://programbench.com/task/mgdm__htmlq.6e31bc8/
58	parcel-bundler/lightningcss	An extremely fast CSS parser, transformer, bundler, and minifier written in Rust.	rs	7,515	2,828	53.6%	https://programbench.com/task/parcel-bundler__lightningcss.aa2ed1e/
59	universal-ctags/ctags	A maintained ctags implementation	c	7,149	2,258	13.3%	https://programbench.com/task/universal-ctags__ctags.243595e/
60	chmln/sd	Intuitive find & replace CLI (sed alternative)	rs	7,072	810	90.9%	https://programbench.com/task/chmln__sd.87d1ba5/
61	ogham/dog	A command-line DNS client.	rs	6,640	1,300	84.2%	https://programbench.com/task/ogham__dog.721440b/
62	danmar/cppcheck	static analysis of C/C++ code	cpp	6,599	2,126	14.6%	https://programbench.com/task/danmar__cppcheck.0a5b103/
63	doxygen/doxygen	Official doxygen git repository	c	6,422	229	34.5%	https://programbench.com/task/doxygen__doxygen.966d98e/
64	sharkdp/pastel	A command-line tool to generate, analyze, convert and manipulate colors	rs	6,334	1,114	77.2%	https://programbench.com/task/sharkdp__pastel.b60e899/
65	BLAKE3-team/BLAKE3	the official Rust and C implementations of the BLAKE3 cryptographic hash function	rs	6,178	647	97.5%	https://programbench.com/task/blake3-team__blake3.15e83a5/
66	Nukesor/pueue	:stars: Manage your shell commands.	rs	6,154	638	15.4%	https://programbench.com/task/nukesor__pueue.8b9d6fe/
67	OSGeo/gdal	GDAL is an open source MIT licensed translator library for raster and vector geospatial data formats.	cpp	5,875	657	25.4%	https://programbench.com/task/osgeo__gdal.0847f12/
68	Byron/dua-cli	View disk space usage and delete unwanted data, fast.	rs	5,794	709	86.9%	https://programbench.com/task/byron__dua-cli.8570c15/
69	dundee/gdu	Fast disk usage analyzer with console interface written in Go	go	5,578	1,161	70.1%	https://programbench.com/task/dundee__gdu.ede21d2/
70	eradman/entr	Run arbitrary commands when files change	c	5,551	586	88.6%	https://programbench.com/task/eradman__entr.8e2e8b4/
71	LuaJIT/LuaJIT	Mirror of the LuaJIT git repository	c	5,518	2,967	71.5%	https://programbench.com/task/luajit__luajit.a553b3d/
72	mgechev/revive	🔥 ~6x faster, stricter, configurable, extensible, and beautiful drop-in replacement for golint	go	5,486	727	46.4%	https://programbench.com/task/mgechev__revive.201451e/
73	cweill/gotests	Automatically generate Go test boilerplate from your source code.	go	5,294	603	61.9%	https://programbench.com/task/cweill__gotests.2a672c5/
74	cordx56/rustowl	Visualize Ownership and Lifetimes in Rust	rs	5,113	589	75.2%	https://programbench.com/task/cordx56__rustowl.655bc5c/
75	abishekvashok/cmatrix	Terminal based “The Matrix” like implementation	c	5,042	508	97.0%	https://programbench.com/task/abishekvashok__cmatrix.5c082c6/
76	quinn-rs/quinn	Async-friendly QUIC implementation in Rust	rs	5,041	522	61.7%	https://programbench.com/task/quinn-rs__quinn.bb359cc/
77	alecthomas/chroma	A general purpose syntax highlighter in pure Go	go	4,910	515	15.9%	https://programbench.com/task/alecthomas__chroma.8d04def/
78	anordal/shellharden	The corrective bash syntax highlighter	rs	4,778	1,095	81.7%	https://programbench.com/task/anordal__shellharden.6a6ffd4/
79	yoav-lavi/melody	Melody is a language that compiles to regular expressions and aims to be more readable and maintainable	rs	4,748	1,205	78.9%	https://programbench.com/task/yoav-lavi__melody.f4af9b4/
80	sayanarijit/xplr	A hackable, minimal, fast TUI file explorer	rs	4,735	463	60.5%	https://programbench.com/task/sayanarijit__xplr.1751065/
81	hpjansson/chafa	📺🗿 Terminal graphics for the 21st century.	c	4,648	1,931	58.4%	https://programbench.com/task/hpjansson__chafa.dd4d4c1/
82	jhspetersson/fselect	Find files with SQL-like queries	rs	4,420	3,115	44.0%	https://programbench.com/task/jhspetersson__fselect.c3559ca/
83	ivanceras/svgbob	Convert your ascii diagram scribbles into happy little SVG	rs	4,182	472	41.3%	https://programbench.com/task/ivanceras__svgbob.6d00ad9/
84	multiprocessio/dsq	Commandline tool for running SQL queries against JSON, CSV, Excel, Parquet, and more.	go	3,867	542	80.3%	https://programbench.com/task/multiprocessio__dsq.c3ae0ba/
85	rcoh/angle-grinder	Slice and dice logs on the command line	rs	3,727	1,130	38.0%	https://programbench.com/task/rcoh__angle-grinder.9c2fc88/
86	rs/curlie	The power of curl, the ease of use of httpie.	go	3,637	701	89.3%	https://programbench.com/task/rs__curlie.5dfcbb1/
87	antonmedv/walk	Terminal file manager	go	3,598	470	74.3%	https://programbench.com/task/antonmedv__walk.bf802ef/
88	JohannesKaufmann/html-to-markdown	⚙️ Convert HTML to Markdown. Even works with entire websites and can be extended through rules.	go	3,586	885	85.5%	https://programbench.com/task/johanneskaufmann__html-to-markdown.3006818/
89	TheZoraiz/ascii-image-converter	A cross-platform command-line tool to convert images into ascii art and print them on the console. Now supports braille art!	go	3,284	465	64.1%	https://programbench.com/task/thezoraiz__ascii-image-converter.d05a757/
90	hairyhenderson/gomplate	A flexible commandline tool for template rendering. Supports lots of local and remote datasources.	go	3,135	2,926	74.7%	https://programbench.com/task/hairyhenderson__gomplate.05eb3aa/
91	ip7z/7zip	7-Zip	cpp	2,967	1,043	33.9%	https://programbench.com/task/ip7z__7zip.839151e/
92	madler/pigz	A parallel implementation of gzip for modern multi-processor, multi-core machines.	c	2,924	831	83.2%	https://programbench.com/task/madler__pigz.fe4894f/
93	tinycc/tinycc	Unofficial mirror of mob development branch	c	2,843	1,978	12.8%	https://programbench.com/task/tinycc__tinycc.9b8765d/
94	raviqqe/muffet	Fast website link checker in Go	go	2,597	293	88.1%	https://programbench.com/task/raviqqe__muffet.a882908/
95	segmentio/chamber	CLI for managing secrets	go	2,588	1,748	82.0%	https://programbench.com/task/segmentio__chamber.5f93f5f/
96	astaxie/bat	Go implement CLI, cURL-like tool for humans	go	2,563	1,091	71.8%	https://programbench.com/task/astaxie__bat.17d1080/
97	zk-org/zk	Plain text note-taking assistant	go	2,542	1,108	43.1%	https://programbench.com/task/zk-org__zk.10d93d5/
98	kisielk/errcheck	errcheck checks that you checked errors.	go	2,480	341	80.4%	https://programbench.com/task/kisielk__errcheck.dacab89/
99	mkj/dropbear	Dropbear SSH	c	2,231	682	58.1%	https://programbench.com/task/mkj__dropbear.75f699b/
100	noborus/trdsql	CLI tool that can execute SQL queries on CSV, LTSV, JSON, YAML and TBLN. Can output to various formats.	go	2,159	1,312	66.8%	https://programbench.com/task/noborus__trdsql.d8c5ff6/
101	sheepla/pingu	🐧ping command but with pingu	go	2,087	383	96.6%	https://programbench.com/task/sheepla__pingu.926d475/
102	go-critic/go-critic	The most opinionated Go source code linter for code audit.	go	2,041	493	41.6%	https://programbench.com/task/go-critic__go-critic.9aea378/
103	OSGeo/PROJ	PROJ - Cartographic Projections and Coordinate Transformations Library	cpp	1,974	5,319	73.8%	https://programbench.com/task/osgeo__proj.75d455c/
104	noborus/ov	🎑Feature-rich terminal-based text viewer. It is a so-called terminal pager.	go	1,935	1,854	87.6%	https://programbench.com/task/noborus__ov.b96c2ba/
105	samtools/samtools	Tools (written in C using htslib) for manipulating next-generation sequencing data	c	1,886	1,425	14.2%	https://programbench.com/task/samtools__samtools.aa823b5/
106	gabotechs/dep-tree	Tool for helping developers keep their code bases clean and decoupled. It allows visualising a code base complexity using a 3d force-directed graph of files and the dependencies between them.	go	1,706	865	65.2%	https://programbench.com/task/gabotechs__dep-tree.60a95a2/
107	cmatsuoka/figlet	Claudio’s FIGlet tree	c	1,606	872	77.5%	https://programbench.com/task/cmatsuoka__figlet.202a0a8/
108	lh3/seqtk	Toolkit for processing sequences in FASTA/Q formats	c	1,537	429	67.4%	https://programbench.com/task/lh3__seqtk.94e7070/
109	tukaani-project/xz	XZ Utils	c	1,522	1,410	36.0%	https://programbench.com/task/tukaani-project__xz.1007bf0/
110	skeema/skeema	Declarative pure-SQL schema management for MySQL and MariaDB	go	1,361	1,708	76.5%	https://programbench.com/task/skeema__skeema.6a76243/
111	mfridman/tparse	CLI tool for summarizing go test output. Pipe friendly. CI/CD friendly.	go	1,246	425	77.6%	https://programbench.com/task/mfridman__tparse.2416b4b/
112	lfos/calcurse	A text-based calendar and scheduling application	c	1,243	666	53.8%	https://programbench.com/task/lfos__calcurse.49180d5/
113	hooklift/gowsdl	WSDL2Go code generation as well as its SOAP proxy	go	1,219	391	86.4%	https://programbench.com/task/hooklift__gowsdl.2a06cec/
114	guumaster/hostctl	Your dev tool to manage /etc/hosts like a pro!	go	1,216	1,051	82.8%	https://programbench.com/task/guumaster__hostctl.d6d9699/
115	rs/jplot	iTerm2 expvar/JSON monitoring tool	go	1,178	583	89.0%	https://programbench.com/task/rs__jplot.2a54bcc/
116	naggie/dstask	Git powered terminal-based todo/note manager – markdown note page per task. Single binary!	go	1,157	1,278	58.8%	https://programbench.com/task/naggie__dstask.ff57396/
117	sigoden/argc	A Bash CLI framework, also a Bash command runner.	rs	1,135	995	44.1%	https://programbench.com/task/sigoden__argc.04a08f1/
118	sibprogrammer/xq	Command-line XML and HTML beautifier and content extractor	go	1,109	792	75.9%	https://programbench.com/task/sibprogrammer__xq.b89f681/
119	xorg62/tty-clock	Clock using lib ncurses	c	1,105	281	84.0%	https://programbench.com/task/xorg62__tty-clock.f2f847c/
120	unhappychoice/gittype	A CLI code-typing game that turns your source code into typing challenges	rs	1,075	741	91.3%	https://programbench.com/task/unhappychoice__gittype.34b72d0/
121	eudoxia0/hashcards	A plain text-based spaced repetition system.	rs	1,071	1,151	56.3%	https://programbench.com/task/eudoxia0__hashcards.48aa136/
122	rvben/rumdl	Fast Markdown linter and formatter written in Rust	rs	1,051	3,322	40.7%	https://programbench.com/task/rvben__rumdl.2d75c4d/
123	sclevine/yj	CLI - Convert between YAML, TOML, JSON, and HCL. Preserves map order.	go	1,041	767	74.4%	https://programbench.com/task/sclevine__yj.8016400/
124	arq5x/bedtools2	bedtools - the swiss army knife for genome arithmetic	c	1,029	1,053	38.9%	https://programbench.com/task/arq5x__bedtools2.dd57059/
125	cslarsen/jp2a	Converts jpg images to ASCII	c	1,021	631	56.1%	https://programbench.com/task/cslarsen__jp2a.61d205f/
126	blacknon/hwatch	A modern alternative to the watch command, records the differences in execution results and can check this differences at after.	rs	1,016	1,016	81.1%	https://programbench.com/task/blacknon__hwatch.edfcb62/
127	eliukblau/pixterm	Draw images in your ANSI terminal with true color	go	1,014	430	74.9%	https://programbench.com/task/eliukblau__pixterm.1a93fd5/
128	Canop/rhit	A nginx log explorer	rs	1,006	817	53.2%	https://programbench.com/task/canop__rhit.ae90bcb/
129	stathissideris/ditaa	ditaa is a small command-line utility that can convert diagrams drawn using ascii art (‘drawings’ that contain characters that resemble lines like \| / - ), into proper bitmap graphics.	java	1,005	609	20.4%	https://programbench.com/task/stathissideris__ditaa.f2286c4/
130	rbakbashev/elfcat	ELF visualizer. Generates HTML files from ELF binaries.	rs	990	564	98.2%	https://programbench.com/task/rbakbashev__elfcat.52f8cc7/
131	nuta/nsh	A command-line shell like fish, but POSIX compatible.	rs	966	1,963	83.7%	https://programbench.com/task/nuta__nsh.bdd0702/
132	dalance/amber	A code search / replace tool	rs	941	567	71.1%	https://programbench.com/task/dalance__amber.69a0f52/
133	pls-rs/pls	pls is a prettier and powerful ls(1) for the pros.	rs	932	332	62.3%	https://programbench.com/task/pls-rs__pls.4e1ae50/
134	Esubaalew/run	Universal multi-language runner and smart REPL written in Rust.	rs	919	1,212	85.2%	https://programbench.com/task/esubaalew__run.0fb9dec/
135	chirlu/sox	SoX, Swiss Army knife of sound processing	c	913	1,202	37.9%	https://programbench.com/task/chirlu__sox.42b3557/
136	clog-tool/clog-cli	Generate beautiful changelogs from your Git commit history	rs	912	575	93.0%	https://programbench.com/task/clog-tool__clog-cli.7066cba/
137	tarka/xcp	An extended `cp`	rs	911	1,184	92.6%	https://programbench.com/task/tarka__xcp.5e5b448/
138	oppiliappan/eva	a calculator REPL, similar to bc(1)	rs	907	913	88.7%	https://programbench.com/task/oppiliappan__eva.41ae245/
139	git-bahn/git-graph	Command line tool to show clear git graphs arranged for your branching model	rs	904	568	79.6%	https://programbench.com/task/git-bahn__git-graph.87b4473/
140	gromacs/gromacs	Public/backup repository of the GROMACS molecular simulation toolkit. Please do not mine the metadata blindly; we use https://gitlab.com/gromacs/gromacs for code review and issue tracking.	cpp	901	1,245	9.3%	https://programbench.com/task/gromacs__gromacs.665ea4c/
141	sirwart/ripsecrets	A command-line tool to prevent committing secret keys into your source code	rs	901	611	72.8%	https://programbench.com/task/sirwart__ripsecrets.34c9e03/
142	Drew-Alleman/DataSurgeon	Quickly Extracts IP’s, Email Addresses, Hashes, Files, Credit Cards, Social Security Numbers and a lot More From Text	rs	890	502	74.3%	https://programbench.com/task/drew-alleman__datasurgeon.d257cee/
143	alexpovel/srgn	A grep-like tool which understands source code syntax and allows for manipulation in addition to search	rs	889	1,852	69.5%	https://programbench.com/task/alexpovel__srgn.89f943b/
144	kyoheiu/felix	tui file manager with vim-like key mapping	rs	888	502	49.2%	https://programbench.com/task/kyoheiu__felix.95df390/
145	oppiliappan/statix	lints and suggestions for the nix programming language	rs	882	815	42.8%	https://programbench.com/task/oppiliappan__statix.e9df54c/
146	nachoparker/dutree	a tool to analyze file system usage written in Rust	rs	871	641	89.5%	https://programbench.com/task/nachoparker__dutree.44e877d/
147	simeg/eureka	💡 CLI tool to input and store your ideas without leaving the terminal	rs	867	344	78.8%	https://programbench.com/task/simeg__eureka.df3796c/
148	kyoh86/richgo	Enrich `go test` outputs with text decorations.	go	863	546	85.0%	https://programbench.com/task/kyoh86__richgo.313114f/
149	rochacbruno/marmite	Markdown makes sites - A Static Site Generator for Blogs	rs	837	668	45.4%	https://programbench.com/task/rochacbruno__marmite.7d4bc2d/
150	rust-embedded/svd2rust	Generate Rust register maps (`struct`s) from SVD files	rs	835	920	72.9%	https://programbench.com/task/rust-embedded__svd2rust.1760b5e/
151	konradsz/igrep	Interactive Grep	rs	827	385	73.5%	https://programbench.com/task/konradsz__igrep.aa75630/
152	nikolassv/bartib	A simple timetracker for the command line. It saves a log of all tracked activities as a plaintext file and allows you to create flexible reports.	rs	827	722	87.3%	https://programbench.com/task/nikolassv__bartib.6b9b5ce/
153	yassinebridi/serpl	A simple terminal UI for search and replace, ala VS Code.	rs	824	446	61.0%	https://programbench.com/task/yassinebridi__serpl.c48a9d7/
154	riquito/tuc	When cut doesn’t cut it	rs	820	1,196	92.7%	https://programbench.com/task/riquito__tuc.16fb471/
155	ecumene/rust-sloth	A 3D software rasterizer… for the terminal!	rs	818	380	52.6%	https://programbench.com/task/ecumene__rust-sloth.051c559/
156	crowdagger/crowbook	Converts books written in Markdown to HTML, LaTeX/PDF and EPUB	rs	813	807	60.3%	https://programbench.com/task/crowdagger__crowbook.ea214d7/
157	WGUNDERWOOD/tex-fmt	An extremely fast LaTeX formatter written in Rust	rs	789	455	80.7%	https://programbench.com/task/wgunderwood__tex-fmt.3f1aef6/
158	Stranger6667/jsonschema	A high-performance JSON Schema validator for Rust	rs	770	2,933	51.7%	https://programbench.com/task/stranger6667__jsonschema.d52e881/
159	rhysd/kiro-editor	A small terminal UTF-8 text editor written in Rust 📝🦀	rs	761	595	93.3%	https://programbench.com/task/rhysd__kiro-editor.4157485/
160	astro/deadnix	Scan Nix files for dead code	rs	745	602	85.5%	https://programbench.com/task/astro__deadnix.d590041/
161	sstadick/hck	A sharp cut(1) clone.	rs	738	855	95.7%	https://programbench.com/task/sstadick__hck.b66c751/
162	trasta298/keifu	Git genealogy, untangled. A TUI for navigating commit graphs with color and clarity.	rs	729	262	67.2%	https://programbench.com/task/trasta298__keifu.3331426/
163	AmmarAbouZor/tui-journal	Your journal app if you live in a terminal	rs	722	1,402	70.8%	https://programbench.com/task/ammarabouzor__tui-journal.2b4540d/
164	incu6us/goimports-reviser	Right imports sorting & code formatting tool (goimports alternative)	go	715	513	86.4%	https://programbench.com/task/incu6us__goimports-reviser.81bd549/
165	yaa110/nomino	Batch rename utility for developers	rs	710	313	79.9%	https://programbench.com/task/yaa110__nomino.f892499/
166	wfxr/csview	📠 Pretty and fast csv viewer for cli with cjk/emoji support.	rs	694	335	96.1%	https://programbench.com/task/wfxr__csview.8ac4de0/
167	chmln/handlr	A better xdg-utils	rs	693	722	90.7%	https://programbench.com/task/chmln__handlr.90e78ba/
168	Miserlou/Loop	UNIX’s missing `loop` command	rs	692	710	94.6%	https://programbench.com/task/miserlou__loop.209927c/
169	KSXGitHub/parallel-disk-usage	Highly parallelized, blazing fast directory tree analyzer	rs	689	531	86.1%	https://programbench.com/task/ksxgithub__parallel-disk-usage.96978ed/
170	hush-shell/hush	Hush is a unix shell based on the Lua programming language	rs	688	1,201	83.3%	https://programbench.com/task/hush-shell__hush.560c33a/
171	zevv/duc	Dude, where are my bytes: Duc, a library and suite of tools for inspecting disk usage	c	682	874	83.4%	https://programbench.com/task/zevv__duc.a58fa4e/
172	altdesktop/i3-style	🎨 Make your i3 config a little more stylish.	rs	678	539	80.0%	https://programbench.com/task/altdesktop__i3-style.f93821b/
173	wintermute-cell/ngrrram	A TUI tool to help you type faster and learn new layouts. Includes a free cat.	rs	674	303	84.5%	https://programbench.com/task/wintermute-cell__ngrrram.8ea13c3/
174	psampaz/go-mod-outdated	Find outdated dependencies of your Go projects. go-mod-outdated provides a table view of the go list -u -m -json all command which lists all dependencies of a Go project and their available minor and patch updates. It also provides a way to filter indirect dependencies and dependencies without updates.	go	669	285	98.2%	https://programbench.com/task/psampaz__go-mod-outdated.bb79367/
175	wfxr/code-minimap	🛰 A high performance code minimap render.	rs	660	313	88.8%	https://programbench.com/task/wfxr__code-minimap.0ddeea5/
176	kaushiksrini/parqeye	Peek inside Parquet files right from your terminal	rs	654	479	58.9%	https://programbench.com/task/kaushiksrini__parqeye.8072121/
177	stacked-git/stgit	Stacked Git	rs	652	1,488	20.0%	https://programbench.com/task/stacked-git__stgit.430027d/
178	Isona/dirble	Fast directory scanning and scraping tool	rs	632	718	66.7%	https://programbench.com/task/isona__dirble.e2dea9f/
179	YS-L/flamelens	Flamegraph viewer in the terminal	rs	622	224	59.4%	https://programbench.com/task/ys-l__flamelens.0b4dc33/
180	mookid/diffr	Yet another diff highlighting tool	rs	612	606	84.7%	https://programbench.com/task/mookid__diffr.2152742/
181	shashwatah/jot	⚡Rapid note management for the terminal.	rs	609	752	84.6%	https://programbench.com/task/shashwatah__jot.a92aad8/
182	Epistates/treemd	A (TUI/CLI) markdown navigator with tree-based structural navigation.	rs	603	1,569	55.1%	https://programbench.com/task/epistates__treemd.825c6dd/
183	pier-cli/pier	A CLI to organize and run short Unix shell scripts	rs	596	692	83.7%	https://programbench.com/task/pier-cli__pier.5e1bde9/
184	jrnxf/thokr	✨ sleek typing tui with visualized results and historical logging	rs	595	445	82.2%	https://programbench.com/task/jrnxf__thokr.09375ef/
185	ismaelgv/rnr	A command-line tool to batch rename files and directories	rs	581	683	82.1%	https://programbench.com/task/ismaelgv__rnr.fc0733b/
186	sitkevij/hex	🔮 Futuristic take on hexdump, made in Rust.	rs	563	823	91.7%	https://programbench.com/task/sitkevij__hex.61ae69b/
187	brocode/fblog	Small command-line JSON Log viewer	rs	561	978	86.0%	https://programbench.com/task/brocode__fblog.3b54330/
188	codesnap-rs/codesnap	🦀️📸 Pure Rust tool to generate beautiful code snapshots, provide CLI and Library	rs	557	730	59.2%	https://programbench.com/task/codesnap-rs__codesnap.f81e4f3/
189	foriequal0/git-trim	Automatically trims your branches whose tracking remote refs are merged or stray	rs	548	509	64.6%	https://programbench.com/task/foriequal0__git-trim.07c2f50/
190	axodotdev/oranda	🎁 generate beautiful landing pages for your developer tools	rs	542	767	53.6%	https://programbench.com/task/axodotdev__oranda.27d60c7/
191	elkowar/pipr	A tool to interactively write shell pipelines.	rs	541	525	57.1%	https://programbench.com/task/elkowar__pipr.fae0b17/
192	paradigmxyz/solar	Blazingly fast, modular and contributor friendly Solidity compiler, written in Rust	rs	539	1,978	43.3%	https://programbench.com/task/paradigmxyz__solar.5190d0e/
193	Lymphatus/caesium-clt	Caesium Command Line Tools - Lossy/lossless image compression tool	rs	537	575	92.3%	https://programbench.com/task/lymphatus__caesium-clt.a529b2e/
194	agourlay/zip-password-finder	Find the password of protected ZIP files.	rs	534	680	97.9%	https://programbench.com/task/agourlay__zip-password-finder.704700d/
195	rust-ethereum/ethabi	Encode and decode smart contract invocations	rs	525	997	90.9%	https://programbench.com/task/rust-ethereum__ethabi.b1710ad/
196	ArthurSonzogni/json-tui	A JSON terminal UI made in C++	cpp	438	755	71.0%	https://programbench.com/task/arthursonzogni__json-tui.17a22b6/
197	tomarrell/wrapcheck	A Go linter to check that errors from external packages are wrapped	go	374	480	80.8%	https://programbench.com/task/tomarrell__wrapcheck.c058da1/
198	NikolaDucak/caps-log	A small TUI journaling tool. 📖	cpp	370	551	61.7%	https://programbench.com/task/nikoladucak__caps-log.2cf2d1e/
199	mibk/dupl	a tool for code clone detection	go	367	373	85.0%	https://programbench.com/task/mibk__dupl.1bf052b/
200	HaliteChallenge/Halite	@twosigma’s first artificial intelligence programming challenge	cpp	202	275	80.4%	https://programbench.com/task/halitechallenge__halite.822cfb6/

怎么看这组数据

ProgramBench 的主榜单里，9 个模型的 Resolved 都是 0%。这说明在统一的轻量级 agent 设置下，当前模型还不能稳定从黑箱行为和文档中重建完整软件。

但 Almost resolved 仍然有区分度。Claude Opus 4.7 达到 3.0%，Claude Opus 4.6 为 2.5%，Claude Sonnet 4.6 为 1.0%，其余模型为 0.0%。这类指标更适合观察“接近完成”的能力，而不是只看是否完全通关。

任务实例表也很关键。它把每个开源项目的语言、星标数、测试数量和当前最佳得分列出来，可以看出 ProgramBench 覆盖了压缩、搜索、数据库、编译器、命令行工具、媒体处理等不同类型的软件。对 AI Coding 来说，这比单纯算法题更接近真实工程压力。

ProgramBench 0% 解读：AI 编程真正可怕的不是失败，而是路线图清楚了

Sun, 10 May 2026 12:32:39 +0800

AI 编程圈最近出现了一个新的基准测试：ProgramBench。表面上看，它给出的结果很让程序员安心：九个主流模型在 fully resolved 指标上全部是 0%，没有任何模型能完整通过一个任务。

但这件事真正值得紧张的地方，不是今天的大模型还做不到，而是完整软件工程第一次被清楚地做成了一套可评测、可排名、可反复优化的题。

一旦任务被定义清楚，AI 行业最擅长的事情就会发生：刷题、迭代、追榜，然后把原来做不到的事情一点点推到可用边缘。

ProgramBench 到底在测什么

很多编程基准测试，测的是补函数、改 bug、通过单元测试，或者在已有项目里完成一个小功能。ProgramBench 更狠，它不给源代码，也不给项目结构，更不给现成测试用例。

它给模型的材料主要只有两类：

一个已经编译好的可执行文件。
这个程序的使用文档。

模型需要自己运行可执行文件，观察输入输出行为，理解命令行参数、边界情况、错误信息、数据存储方式，然后重新实现一个行为一致的程序。

这已经不是“写一段代码”，而是一个简化但完整的软件工程任务：要理解需求、探索行为、选择语言、设计结构、写源码、提供构建方式，并尽量通过隐藏测试。

根据 ProgramBench 官方介绍，它目前包含 200 个任务，覆盖从小型命令行工具到 PHP、FFmpeg、SQLite 等大型真实项目。测试集由 agent-driven fuzzing 生成，总量超过 248,000 个行为测试。

如果把测试流程拆开，ProgramBench 大致是在考四件事：

读懂文档：理解程序应该提供哪些命令、参数和输出。
探索行为：反复运行二进制程序，观察正常输入、异常输入和边界情况。
重建实现：自己选择语言和项目结构，写出一个行为接近的替代程序。
通过隐藏测试：不仅常规行为要对，错误处理、输出格式和边界条件也要尽量一致。

所以它的搜索价值不只是“又一个跑分”，而是回答一个更具体的问题：大模型能不能在没有源码的情况下，只靠文档和黑箱行为，从零复刻一个真实软件。

为什么结果是 0%

ProgramBench 的主要指标是 fully resolved，也就是一个任务里的测试全部通过才算完成。当前 leaderboard 上，九个模型在这个指标上都是 0%。

参与测试的模型包括 Claude、GPT、Gemini 等系列，统一使用 mini-SWE-agent 作为基线 agent。Claude Opus 4.7 在 almost resolved 指标上表现最好，大约有 3.0% 的任务通过了至少 95% 的测试；Claude Opus 4.6 是 2.5%，Claude Sonnet 4.6 是 1.0%。GPT 5.4、GPT 5.4 mini、Gemini 3.1 Pro、Gemini 3 Flash 等在 almost resolved 上都是 0.0%。

这说明今天的大模型加一个轻量级 agent，还无法从零重建完整软件。即使是最简单的任务，也很难做到所有细节都完全对齐。

但也要注意：这次测试用的是 mini-SWE-agent，不是 Claude Code，也不是 Codex。换成更强的 coding agent、更多工具链支持、更长时间的探索流程，结果可能会提高。所以这个结果更准确的说法是：当前模型加轻量 agent，还不足以稳定完成完整软件重建。

fully resolved 和 almost resolved 是什么意思

读 ProgramBench 的结果时，最容易误解的是这两个指标。

fully resolved 是最严格的指标：一个任务里的所有隐藏测试都通过，才算完整解决。只要还漏掉一个边界条件、一个报错格式、一个命令参数行为，就不能算 fully resolved。

almost resolved 则更像“接近完成”：如果一个任务至少通过了 95% 的测试，就算进入 almost resolved。它能反映模型有没有把大部分行为做出来，但还不能代表程序已经可以替代原软件。

这也是为什么 0% 要分开看。fully resolved 的 0% 说明模型还无法完整交付；almost resolved 的差距则能看出哪些模型已经在部分任务上接近复刻成功。比如 Claude Opus 4.7 的 almost resolved 约为 3.0%，说明它确实在少量相对简单的任务上更接近完成，但距离稳定重建完整软件仍然很远。

为什么 mini-SWE-agent 会影响测试结果

这次测试使用统一的 mini-SWE-agent，好处是公平：不同模型都跑在同一套轻量 agent 框架里，结果更容易横向比较。

但它也会限制上限。完整软件重建不只取决于模型本身，还取决于 agent 是否会规划探索策略、是否能管理长期任务、是否会自动生成测试、是否能反复定位失败原因、是否能整理项目结构。

mini-SWE-agent 更像一个统一基线，而不是最强工程环境。Claude Code、Codex 这类更完整的 coding agent，通常会提供更强的工具调用、上下文组织、任务拆解和多轮修复能力。如果换成这些工具，结果可能会更好。

所以 ProgramBench 这次结果更适合理解为：当前模型在轻量 agent 环境下还做不到完整软件重建。它不是在证明“模型永远做不到”，也不是在完整评估所有商业 coding agent 的上限。

它和 SWE-bench 的差别

SWE-bench 已经是 AI 编程领域里很重要的基准。它让模型在真实 GitHub 仓库里读 issue、改代码、提交补丁，用来测试模型解决真实 bug 的能力。

但 SWE-bench 本质上仍然是在已有项目上修车：车还在，技术栈、目录结构、代码组织、架构设计都已经有人完成了。模型只需要找到问题，把坏掉的零件修好。

ProgramBench 更接近重新造车：你只知道这个车应该有什么行为，看到红灯会停、遇到行人会鸣笛，剩下的结构、语言、模块、构建方式，全都要自己决定。

这就是为什么它难得多。它不再只考局部补丁能力，而是在考软件架构、系统推理、行为探索、自动测试、多轮纠错和长期工程设计。

可以用一张表来理解两者差别：

维度	SWE-bench	ProgramBench
起点	已有 GitHub 仓库和 issue	已编译可执行文件和使用文档
是否给源码	给源码	不给源码
主要任务	修复已有项目里的 bug	从行为重新实现一个完整程序
技术栈	原项目已经确定	模型自己选择
项目结构	原项目已经存在	模型自己设计
测试方式	提交补丁后跑测试	用隐藏行为测试验证复刻程度
主要考点	读代码、定位问题、补丁修复	行为探索、系统抽象、架构设计、完整实现

这也是为什么 ProgramBench 更适合被看作下一阶段 AI Coding 的目标：它把“修现有代码”推进到了“重建完整软件”。

0% 并不等于安全

看到 0%，很多人的第一反应可能是：程序员饭碗暂时保住了。

短期看，这句话没错。今天的大模型还不能稳定完成完整软件工程，尤其是在没有源码、没有测试用例、没有项目结构的情况下。需求澄清、架构设计、长期维护、安全控制、团队协作、业务理解，仍然是人类软件工程师的重要优势。

但如果把 0% 理解成“AI 编程到头了”，就太乐观了。

ProgramBench 真正改变的是问题定义。以前大家知道 AI 可以补代码，也知道 AI 可以修 bug，但“从一个可执行文件和文档重建完整软件”这件事没有被清楚地放到统一赛道里。现在它被做成了 200 道题、统一评测、统一排名。

这意味着模型公司、agent 公司、开发工具公司都知道下一步该往哪里发力：让 AI 从写代码片段，进化到维护、重建和交付完整软件系统。

为什么要断网和防作弊

ProgramBench 的设计里有一个细节很重要：它要防止模型作弊。

早期测试中，模型会尝试直接从 GitHub 找源码，或者通过包管理器下载包含源码的包，甚至去系统缓存目录里翻找已经下载过的软件包。这样当然会破坏测试目的，因为问题就不再是“能不能从行为重建软件”，而是“能不能找到原始源码”。

所以 ProgramBench 使用了沙箱和断网环境，不允许访问互联网，也不允许反编译、反汇编或读取可执行文件内容。模型只能执行程序，观察行为，再自己实现。

这个限制让测试更干净，也更接近它真正想回答的问题：大语言模型能不能从程序行为和文档出发，自己构建一个可运行的软件项目。

更值得警惕的是代码形态变化

ProgramBench 还有一个比 0% 更值得软件工程师思考的发现：模型生成的代码往往不像人类工程师会写的项目。

公开材料里提到，模型倾向于生成更少的文件、更浅的目录、更少的函数，以及更长的单个函数。也就是说，它可能写出一个巨大的、能跑的脚本，而不是一个结构清晰、便于人类维护的软件工程项目。

从传统软件工程角度看，这通常是很差的代码。文件太少、函数太长、抽象不足、模块边界不清，都会让人类难以维护。

但问题在于，AI 未必需要按照人类维护代码的方式写代码。

人类强调抽象、命名、目录结构和模块边界，主要是因为人类记忆有限、团队需要协作、代码需要长期复用。AI 如果可以用更长上下文、检索系统和自动测试反复重写代码，它可能并不那么需要人类熟悉的这些工程规范。

这会带来一个很现实的风险：未来 AI 写出的软件也许能跑、甚至很快，但人类越来越难插手维护。

程序员真正要升级什么

ProgramBench 的结果对程序员不是简单的好消息，也不是简单的坏消息。

短期看，完整软件工程仍然很难，程序员不会因为这次 benchmark 立刻失业。尤其是架构判断、需求澄清、安全把控、质量验收和业务理解，仍然需要人类负责。

长期看，程序员的工作会继续上移。真正危险的不是“不会写代码”的人，而是只会写代码、但不会定义问题、验证结果、组织工具链和控制风险的人。

未来的软件工程师可能更像：

需求定义者：把模糊业务问题变成可执行目标。
系统验收者：判断 AI 生成结果是否真的满足需求。
工具链组织者：组合模型、agent、测试、部署和监控。
质量负责人：控制安全、可维护性、边界条件和长期风险。
业务和技术之间的翻译者：把真实问题转成工程系统能处理的约束。

如果 AI 真的从代码助手变成完整软件工程师，人类程序员的价值就不再只是亲手写每一行代码，而是定义什么值得写、怎样算写对、哪里不能出错。

小结

ProgramBench 的 0% 不是终点，而是新阶段的起点。

它说明今天的大模型还不能从零稳定重建完整软件系统；但它也把下一代 AI Coding agent 的目标定义得非常清楚：从局部补丁走向完整项目，从代码片段走向系统交付。

对程序员来说，短期可以松一口气，但长期不能只盯着“AI 现在还不行”。更重要的是尽快把自己从代码执行者升级为问题定义者、结果验收者和风险控制者。

真正值得紧张的不是 AI 今天考了 0%，而是题目已经摆出来了。

Anthropic 联手 SpaceX：大模型竞争进入算力重工业时代

Fri, 08 May 2026 23:39:08 +0800

Anthropic 与 SpaceX 的算力合作，表面上是一次资源租赁：Anthropic 获得 SpaceX Colossus 1 数据中心的 300MW 级新增算力和约 22 万张 NVIDIA GPU，Claude 用户随即看到使用限制放宽、Claude Code 限额提升、部分高峰期限制减少。

但这件事的行业意义不止于“Claude 更好用了”。它说明前沿大模型竞争正在从单纯的模型能力、产品体验和融资规模，进一步下沉到更重的基础设施层：电力、数据中心、网络调度、GPU 利用率、芯片供应链，甚至未来可能的太空算力。

算力不只是买 GPU

过去两年，AI 公司最常见的叙事是“缺算力”。谁能拿到更多 H100、H200、B 系列 GPU，谁就更接近下一代模型。但到 2026 年，问题已经不再是简单的“有没有卡”，而是“能不能把卡真正跑满”。

超大规模集群的难点在于系统工程。GPU 数量达到十万级甚至更高后，瓶颈会从单卡性能转向整体调度：网络通信、并行训练、故障恢复、数据读写、液冷、电力稳定性、软件栈优化，每一项都会吞掉实际吞吐。

所以，拥有算力和消化算力是两件事。前者靠资金和供应链，后者靠工程能力。对大模型公司来说，真正的护城河不再只是模型架构和训练数据，还包括让数十万张 GPU 高效协同工作的能力。

Anthropic 为什么需要这笔算力

Anthropic 近一年的增长压力非常清楚。Claude 在开发者、企业、Agent 和代码场景里的使用量快速上升，Claude Code 尤其容易消耗大量推理资源。用户看到的限额、排队、降速，本质上都是算力供需紧张的产品化表现。

Anthropic 此前已经和 Amazon、Google、Broadcom、Microsoft、NVIDIA 等建立了大规模基础设施合作。SpaceX 这笔新增算力的价值在于，它更像一场快速补给：在短时间内拿到可以直接缓解 Claude 使用压力的 GPU 集群。

这也是为什么合作消息一出，最先被用户感知到的是限额提升。对模型公司来说，算力不是抽象资产，而是直接转化为响应速度、可用额度、API 稳定性和高峰期体验。

SpaceX 为什么愿意出租

从 SpaceX 或马斯克阵营看，把 Colossus 1 的算力提供给 Anthropic，也是一笔现实的基础设施生意。

AI 集群是典型重资产：采购成本高、折旧快、运维费用高，且 GPU 迭代速度极快。如果自家模型团队短期内无法完全吃下这些资源，把闲置或低利用率算力租给一线模型公司，就能把硬件折旧压力转换为现金流。

这让 SpaceX 在某种意义上扮演了云服务商角色。它不只是自己训练 Grok，也可以把部分 AI 基础设施能力卖给其他模型公司。对马斯克来说，这还有一个额外效果：支持 Anthropic 客观上会增强 OpenAI 之外的头部竞争者，对老对手形成牵制。

AI 竞争正在变重

这次合作最值得关注的趋势，是 AI 产业正在变得越来越“重”。

早期大模型竞争更像软件竞赛：模型结构、数据配方、训练技巧、benchmark、产品包装。今天这些仍然重要，但前沿竞争已经强烈依赖物理世界：

电力是否足够便宜、稳定、可持续。
数据中心能否快速拿地、建设和并网。
网络能否支撑超大规模并行训练。
GPU 和专用芯片能否按时到货。
冷却系统能否承受持续高密度负载。
软件栈能否把硬件利用率维持在高水平。

这就是所谓“AI 重工业”的含义。大模型不再只是实验室里的算法，而是一套横跨电网、地产、半导体、云计算和资本市场的工业系统。

Terafab 与芯片闭环

与此同时，SpaceX 的 Terafab 计划也被外界放到同一条逻辑线里理解。公开报道显示，SpaceX 已经提交在德州建设半导体工厂的规划，初期投资可能高达 550 亿美元，多阶段总投资可能达到 1190 亿美元。

这并不意味着 SpaceX 已经能挑战台积电，也不意味着 2nm 制程可以靠资本快速堆出来。先进制程最难的不是买设备，而是良率、工艺、人才、供应链和长期积累。哪怕项目推进顺利，也会是多年甚至十年以上的系统工程。

但它反映了一个明显趋势：AI 巨头越来越不愿把命运完全交给外部芯片供应链。英伟达掌握 GPU 和 CUDA 生态，台积电掌握先进制造产能，任何一环受限，都会影响模型训练和产品迭代节奏。垂直整合因此变得更有吸引力。

太空算力还是远期设想

文章里提到的太空算力，也要谨慎看待。SpaceX 的确具备低成本发射、卫星网络和航天工程能力；太空环境也确实有太阳能和散热方面的想象空间。但把数据中心大规模搬到轨道上，仍然面临发射成本、维护、辐射、防护、通信延迟、设备寿命和商业回报等问题。

所以更稳妥的说法是：太空算力目前更像远期基础设施想象，而不是已经成熟的商业方案。它代表的是马斯克体系对 AI 资源边界的思考：当地球上的电力、土地和冷却成为瓶颈时，下一步要去哪里寻找物理空间。

对 OpenAI 和大模型格局的影响

Anthropic 获得新增算力后，最直接的影响是 Claude 的服务能力提升。更高限额、更少高峰限制、更稳定的开发者体验，会让它在代码、企业、Agent 和长任务场景里更有竞争力。

对 OpenAI 来说，这意味着竞争压力不只来自模型质量，还来自对手的基础设施补课速度。前沿模型之间的差距可能越来越取决于谁能更快获得可用算力、谁能更高效调度集群、谁能把成本降下来并转化为产品体验。

对整个行业来说，这也意味着 AI 公司之间的竞争方式会更像云厂商、芯片厂和能源企业的混合体。未来的大模型公司，可能既要会训练模型，也要会建数据中心、谈电力、做芯片定制、优化网络和管理超大规模资本开支。

总结

Anthropic 与 SpaceX 的合作，不只是一次 Claude 算力扩容，也不是简单的马斯克“结盟”某个 OpenAI 竞争对手。它更像一个信号：AI 竞赛正在从模型层进入基础设施层。

算法仍然重要，但仅有算法已经不够。谁能获得稳定能源，谁能把海量 GPU 跑出高利用率，谁能掌握更自主的芯片和数据中心能力，谁就更有机会在下一阶段大模型竞争中占据主动。

算力正在成为 AI 时代的石油，而真正稀缺的不是单张 GPU，而是把能源、芯片、网络、调度和产品需求打通的工业组织能力。

参考链接：

马斯克诉 OpenAI 庭审焦点：非营利使命、控制权与 AI 竞赛

Fri, 08 May 2026 23:37:37 +0800

马斯克与 OpenAI、Sam Altman 之间的诉讼，表面上是一次旧合伙人之间的反目，深层则是 AI 行业最重要的结构性问题之一：当训练先进模型需要巨额资本时，最初以公益、开放、安全为旗帜成立的组织，能否以及如何转向更商业化的形态？

这场争议之所以被持续放大，不只是因为双方都是硅谷最有影响力的人物，也因为它把 OpenAI 的三个矛盾同时摆到了台前：非营利使命与商业融资、AI 安全叙事与市场竞争、创始人贡献与后续控制权。

庭审真正争什么

从公开报道看，马斯克一方的核心主张是：OpenAI 创立时具有明确的公益使命，马斯克早期捐赠和参与是为了支持一个不为个人谋利、服务人类整体利益的 AI 组织；而 OpenAI 后来建立营利性实体、接受巨额投资并发展为高估值公司，已经背离了最初承诺。

OpenAI 一方的核心回应则是：马斯克的捐赠并没有附带他所主张的永久性限制；OpenAI 之所以建立营利性结构，是为了获得算力、人才和资本，继续实现开发安全先进 AI 的使命；同时，OpenAI 认为马斯克当年并非反对营利化本身，而是希望获得控制权。

因此，这不是简单的“非营利 vs 营利”二选一，而是一个更具体的问题：OpenAI 的原始使命到底具有怎样的法律约束力？马斯克的 3800 万美元捐赠是普通捐赠，还是带有可执行条件的慈善信托？OpenAI 后续结构变化是否仍在非营利控制之下？

马斯克一方的叙事

马斯克在庭审中强调，他当初参与 OpenAI，是为了建立一个防止 AI 被少数商业巨头控制的公益机构。他将 OpenAI 的结构变化描述为对慈善机构的掠夺，并警告如果允许这种情况发生，会破坏美国慈善捐赠的基础。

这一叙事的力量在于，它抓住了 OpenAI 早期形象与后来商业成功之间的反差。OpenAI 最初给外界的印象，是一个以安全、开放、公共利益为核心的非营利研究实验室；而今天的 OpenAI 已经成为全球 AI 竞赛中的关键商业实体，与微软等巨头深度绑定。

但马斯克一方也面临一个问题：他是否曾经接受过某种营利性安排？如果他当年也讨论过建立营利性实体，只是要求保持非营利控制或获得更大控制权，那么案件就不再是“有没有营利结构”，而是“谁控制这个结构”。

OpenAI 一方的叙事

OpenAI 的公开页面和庭审辩护都把重点放在另一条线上：OpenAI 始终由非营利机构治理，建立营利性实体是为了筹集实现 AGI 使命所需的资源；马斯克后来发起诉讼，是因为他未能取得控制权，又创办了竞争对手 xAI。

OpenAI 还强调，马斯克曾向 OpenAI 非营利机构捐赠 3800 万美元，这笔钱已经用于公司使命；而马斯克现在试图把它重新解释成投资，并据此主张对 OpenAI 的权益。OpenAI 的说法是，马斯克当年希望获得绝对控制权，甚至曾提出将 OpenAI 并入特斯拉，遭拒后离开。

这套叙事的重点，是把案件从“OpenAI 背叛公益使命”转向“马斯克没有得到想要的控制权”。如果陪审团和法官接受这个框架，马斯克的道德指控就会被削弱，案件会更像一场迟来的创始人权力争夺。

为什么非营利结构是关键

OpenAI 最复杂的地方，不是它有没有商业收入，而是它的治理结构。它不是传统意义上的纯商业公司，也不是完全不参与市场竞争的研究机构。它试图用非营利实体控制营利性子公司，通过资本市场获取算力和人才，同时保留“造福全人类”的使命叙事。

这种结构本身有现实理由。训练前沿模型需要数据中心、芯片、研究人员、安全评估和全球产品基础设施。仅靠捐赠，很难长期支撑这种规模的投入。

但结构越复杂，信任成本也越高。外界会自然追问：非营利控制是否真的有效？商业合作是否改变了研发方向？安全承诺和产品增长发生冲突时，谁有最终决定权？这正是马斯克诉 OpenAI 案能引发广泛关注的原因。

庭审不等于 AI 安全公投

这场庭审里会反复出现 AI 安全、AGI 风险、开源承诺和公共利益等概念，但它本质上仍是一个法律案件。法院要处理的是捐赠性质、慈善信托、组织治理、控制权和不当得利等问题，而不是替全行业制定 AI 安全政策。

换句话说，即使马斯克赢了，也不等于法院会直接给出一套 AI 安全治理方案；即使 OpenAI 赢了，也不等于所有关于商业化和使命漂移的质疑都会消失。

真正值得关注的是判决可能产生的治理信号：法院会如何看待 AI 机构早期公开承诺的约束力？创始人捐赠和后续商业化之间的边界在哪里？非营利控制营利性 AI 公司这种结构，是否需要更强的外部监督？

对 AI 行业的影响

这场诉讼给整个 AI 行业提供了一个提醒：宏大的公益叙事一旦和巨额资本绑定，就必须有足够清晰的治理机制来支撑。否则，当公司成功后，早期使命、捐赠者期待、员工激励、投资人回报和社会风险就会全部挤到同一个法律和舆论战场上。

对其他 AI 公司来说，这意味着几件事：

早期章程、使命声明和捐赠协议必须写得更清楚。
非营利与营利实体之间的权责边界不能含糊。
安全承诺不能只停留在宣传层面，需要可审计的治理机制。
创始人、投资人和公共利益之间的冲突，要在融资前就有制度安排。

OpenAI 的规模和影响力让这些问题被放大，但它们并不只属于 OpenAI。随着 AI 公司继续吸收资本、进入医疗、教育、国防、办公和消费产品，这类治理冲突还会反复出现。

总结

马斯克诉 OpenAI 的核心，不只是“谁背叛了谁”，而是前沿 AI 组织在从研究实验室走向超级平台时，如何证明自己仍然受使命约束。

马斯克一方试图证明 OpenAI 背离了最初的慈善使命；OpenAI 一方则试图证明商业化是实现使命的必要路径，并把马斯克的诉讼解释为控制权失败后的反击。最终法院如何判断，还要看证据、捐赠文件、组织章程和双方当年的沟通记录。

无论结果如何，这场庭审都已经说明一件事：AI 公司不能只靠“为了全人类”的口号维持信任。越是接近通用人工智能、越是掌握巨大商业价值，治理结构就越需要透明、可验证、能经得起法庭和公众同时审视。

参考链接：

米哈游 LPM 1.0 解读：AI 视频模型如何重塑游戏 NPC

Fri, 08 May 2026 22:27:10 +0800

LPM 1.0 最容易被误解成又一个 AI 视频生成模型。只看演示，它未必像一些文生视频产品那样追求宏大的镜头调度和夸张的视觉冲击；但如果把它放回论文里的目标，就会发现它真正想解决的不是“生成一段好看的视频”，而是“让一个数字角色在互动中像是在场”。

这也是 LPM 1.0 和普通视频模型最大的区别。普通视频模型更关注画面质量、镜头连续性和文本指令还原；LPM 1.0 关注的是角色表演：说话时口型、节奏、表情要同步，倾听时也要有点头、视线、停顿和微表情，长时间互动中还要保持角色身份稳定。

从生成视频到生成表演

LPM 是 Large Performance Model，也就是大型表演模型。这个命名很重要，因为它把任务边界从“视频”改成了“表演”。

在真实对话里，一个人是否显得自然，并不只取决于他说了什么。很多时候，倾听本身就构成了交流：对方是否在合适的时候点头，眼神是否跟得上语境，表情是否随着情绪轻微变化，都会影响我们对“这个角色是否活着”的判断。

现有很多数字人方案，本质上仍是在把文本、语音和口型拼接到一个人物形象上。角色会说话，但不一定会听；能输出台词，但不一定能根据上一秒的输入做出连续反应。LPM 1.0 的目标，是把这种被动播报改造成实时互动。

论文里的三个难点

LPM 1.0 论文把问题概括为 AI 角色表演里的三角矛盾：表现力、实时性和长时身份一致性。一个系统可以画面细腻但很慢，也可以响应很快但动作僵硬，或者短时间稳定但长时间后身份漂移。要同时做到三者，难度会明显上升。

为了解这个问题，LPM 1.0 采用了更复杂的角色条件输入。它不是只给模型一张参考图，而是引入多粒度身份参考，包括整体外观、多视角身体和多表情面部参考。这样做的目的，是减少模型对侧脸、牙齿、表情纹理、身体比例等细节的“脑补”，让角色在长时间生成中不容易变形。

论文中还区分了说话和倾听两类行为。说话音频主要驱动口型、语速、头部和身体节奏；倾听音频则更多触发视线、点头、姿态变化和微表情。如果把两类信号混在一起，模型很容易学乱。LPM 1.0 的思路是把 speaking 和 listening 分别建模，再在在线系统里把它们接到同一套互动流程里。

Base LPM 与 Online LPM

从公开论文看，LPM 1.0 的底座是一个 17B 参数的 Diffusion Transformer。Base LPM 负责学习高质量、可控、身份稳定的角色表演视频；Online LPM 则是经过蒸馏后的流式生成器，用来支撑低延迟、长时互动。

这个拆分很关键。离线模型可以追求质量，但互动场景不能让用户等很久。用户一开口，角色就应该开始“听”；角色开始说话时，口型、表情和身体动作也要立刻跟上。Online LPM 的价值，就在于把复杂的视频生成压缩到更接近实时交互的形态。

因此，LPM 1.0 不是单纯给创作者做短视频素材的工具。它更像是对话智能体、虚拟直播角色和游戏 NPC 的视觉引擎：语言模型负责理解和生成内容，语音模型负责声音，LPM 负责让屏幕里的角色以可信的方式“表演出来”。

对游戏的意义

如果把它放进游戏行业，LPM 1.0 指向的并不是更漂亮的过场动画，而是下一代可互动角色。

传统游戏里的 NPC，大多依赖预写脚本、固定动画和有限分支。玩家可以和它对话，但它对玩家的反馈通常是被设计好的。AI 时代的目标会更进一步：同一个世界观下，不同玩家可能获得不同故事线；同一个角色面对不同玩家，也能产生更贴合语境的动作、情绪和回应。

这就是“千人千面”游戏体验真正需要的底层能力。语言模型可以生成台词，行为系统可以决定目标，但如果角色在屏幕上的表现仍然僵硬，玩家很难相信它是一个正在理解自己的对象。LPM 1.0 试图补上的，正是这块视觉和表演层。

不要把它看成万能成品

当然，LPM 1.0 目前更适合作为技术路线来理解，而不是马上等同于可大规模商用的完整产品。论文和演示证明了一种可能性：实时、全双工、身份稳定的角色视频生成正在接近可用状态。但真正进入游戏，还要解决成本、延迟、端侧部署、内容安全、角色版权、多人场景和引擎集成等问题。

更现实的落地路径，可能不是一上来替换所有 NPC，而是先进入虚拟主播、AI 陪伴、剧情互动、角色客服、教育陪练等单人角色场景。等模型成本下降、延迟进一步降低，再逐步进入更复杂的游戏系统。

总结

LPM 1.0 的价值，不在于它能不能生成最惊艳的一段视频，而在于它把 AI 视频的目标从“画面生成”推向了“角色存在感”。

如果未来的游戏真的走向更个性化、更动态、更依赖 AI 角色的形态，那么语言、语音、动作、表情和身份一致性必须被合在一起考虑。LPM 1.0 提供的正是这样一条路线：让数字角色不只是会说话，而是能倾听、能反应，并在长时间互动中保持像同一个人。

参考链接：

Canonical Ubuntu AI 路线图：本地推理优先，拒绝强制集成

Fri, 08 May 2026 22:23:46 +0800

Canonical 最近披露的 Ubuntu AI 路线图，最值得注意的地方不是“Ubuntu 要把 AI 强塞进系统”，而是它正在尝试一条更谨慎的路线：AI 功能按层提供、默认关闭、用户明确选择之后才启用，并优先把推理放在本地完成。

这和 Windows、macOS 上一些围绕系统级 AI 的争议形成了对比。Ubuntu 的方向不是做一个无法回避的全局 AI 层，也不是给系统加一个统一的“AI 总开关”，而是把 AI 能力拆成相对独立的工具，让用户自己决定是否安装、是否启用、接入哪个模型，以及数据是否离开本机。

先澄清时间线：不是 Ubuntu 26.04 LTS

这次路线图真正指向的是 Ubuntu 26.10 “Questing Quokka”，预计在 2026 年 10 月 9 日发布。Canonical 的计划是先以实验性、预览性的方式加入部分 AI 工具，而不是把它们塞进 Ubuntu 26.04 LTS。

这点很关键。LTS 版本承担的是长期稳定、企业部署和安全维护，Canonical 不太可能把还在探索阶段的桌面 AI 能力直接作为默认体验放进去。更合理的路径是先在 26.10 这样的常规版本里试水，让开发者和早期用户反馈，再决定哪些能力适合进入后续长期支持版本。

本地推理优先，云端不是默认选项

Canonical 强调的核心原则之一，是 local inference first，也就是默认优先在本机执行推理。只有用户主动配置云端提供商、自托管服务器或企业模型服务时，请求才会离开本机。

这背后的逻辑很现实：系统级 AI 很容易接触到命令行输出、日志、文件路径、报错信息、系统配置等敏感内容。如果这些信息被自动发往云端，哪怕只是为了“帮你解释错误”，也会带来明显的隐私和合规风险。

因此，Ubuntu 的 AI 路线并不是“云端 AI 系统入口”，而更像是一套可插拔的推理层。用户可以选择本地模型，也可以选择公司内部的推理服务，或者在需要时接入 Canonical 管理的服务。重点不在于绑定某一家模型厂商，而在于让系统有能力调用不同后端。

AI CLI：先从终端助手开始

最先落地的能力之一，可能是面向终端用户的 AI Command Line Helper，也就是常被提到的 ai-cli。

它的定位不是替代 shell，也不是自动替你执行危险命令，而是帮助用户理解命令、日志、systemd 单元、错误输出和系统状态。比如你遇到一段复杂的服务启动失败日志，它可以解释可能的原因；你不确定某条命令的参数含义，它可以给出更直观的说明。

这种入口很符合 Ubuntu 的用户结构。Ubuntu 桌面用户和服务器用户里，有大量人本来就依赖终端工作。与其先做一个花哨的聊天窗口，不如把 AI 放在错误排查、命令解释和运维辅助这些高频场景里。

不过，这也意味着安全边界必须非常清楚。日志里可能包含 token、内网地址、用户名、路径、密钥片段和业务信息。即使默认本地推理，工具也应该尽量提醒用户先做脱敏；如果用户选择云端后端，更要明确哪些内容会被发送出去。

Settings Agent：自然语言控制系统设置

另一个方向是 Settings Agent，也就是让用户用自然语言查询或调整系统设置。

这类功能看起来简单，实际很容易踩坑。一个成熟的 Settings Agent 不应该靠“读屏幕、猜按钮、模拟点击”来操作系统设置，而应该有受控的内部 API：能读哪些设置、能改哪些设置、改之前是否需要确认、失败后如何回滚，都需要有清晰边界。

所以它更像是 26.10 之后继续推进的方向，而不是马上完整交付的功能。对桌面 Linux 来说，这部分如果做得好，会显著降低普通用户调整系统的门槛；如果做得太激进，则可能变成新的安全风险。

为什么不需要一个“AI 总开关”

很多用户担心系统厂商加入 AI 后，会出现一种“到处都是 AI、关也关不干净”的体验。因此有人自然会问：Ubuntu 是否应该提供一个全局 AI kill switch？

Canonical 的回答思路是：如果 AI 功能本身就是 opt-in、分层、可独立安装和配置的，那么全局 kill switch 就不是第一优先级。也就是说，它试图从设计上避免“默认开启、深度嵌入、用户再去关闭”的问题。

这个判断是否足够，还要看后续实现。原则上，只要 AI 工具不默认启用、不默认联网、不默认收集数据，并且每个功能都有清楚的开关和配置入口，那么用户就不需要为了关闭 AI 到处找隐藏选项。

对开发者和企业用户的意义

对开发者来说，AI CLI 这类工具最实际的价值，是减少查文档、读日志、定位系统问题的时间。它不是替代工程判断，而是把大量“我先帮你解释一下这段输出”的工作自动化。

对企业用户来说，本地推理和可插拔后端更重要。很多公司不能把源代码、日志、客户数据或基础设施信息发送到公共大模型服务。Ubuntu 如果能把系统级 AI 和本地模型、私有推理服务、企业权限体系结合起来，就能在合规环境里提供更可控的智能辅助。

这也是 Linux 桌面和工作站的一个机会。Windows 和 macOS 更容易把 AI 做成厂商生态的一部分，而 Ubuntu 的优势在于开放、可审计、可替换、可自托管。如果 Canonical 能把这些原则保留下来，AI 反而可能成为 Linux 专业用户体验的一次补强。

不要过度解读

目前还不适合把这条路线解读成“Ubuntu 会预装某个小模型”“Ubuntu 26.04 会内置 AI 审计模式”或“未来会有一个固定的 ubuntu-ai 命令”。公开信息里更确定的是方向，而不是完整产品形态。

更稳妥的理解是：Canonical 正在为 Ubuntu 引入一套系统级 AI 工具框架，先从命令行、设置辅助、本地推理和后端选择这些场景开始；默认策略是用户主动选择，而不是系统替用户选择。

总结

Ubuntu 的 AI 路线图真正值得关注的，不是它终于也要“加入 AI 大潮”，而是它试图给开源操作系统定义一套更克制的 AI 集成方式：智能可以成为基础设施，但隐私、可控性和用户选择权必须放在前面。

如果 26.10 的实验性功能能兑现这些原则，Ubuntu 可能会走出一条和消费级系统不同的路线：不把 AI 做成无法回避的系统广告位，而是做成用户可选择、可替换、可审计的生产力工具。

参考链接：

Claude Mythos Preview：Anthropic 为什么把最强网络安全模型关进 Project Glasswing

Thu, 07 May 2026 20:59:02 +0800

Anthropic 的 Claude Mythos Preview 是最近 AI 安全圈最值得警惕的模型之一。

它不是面向普通用户发布的新 Claude，也不是一个单纯的代码模型。按照 Anthropic 对 Project Glasswing 的说明，Mythos Preview 被用于帮助少数安全伙伴发现和修复关键软件漏洞。换句话说，它的能力核心不是“会聊天”，而是能在复杂系统里寻找漏洞、理解攻击面，并辅助安全研究人员完成防御工作。

这也是它危险的地方：同一套能力用于防御时是漏洞发现工具，用于攻击时就可能变成自动化漏洞利用工具。

Mythos 是什么

Anthropic 在 2026 年 4 月 7 日公布了 Project Glasswing，并把 Claude Mythos Preview 放进这个计划中。

公开信息显示，Mythos Preview 是一款具备强网络安全能力的前沿模型。它不会向公众开放，而是提供给经过筛选的合作伙伴，用于防御性安全研究。参与方包括大型科技公司、安全公司、基础设施相关组织和开源生态伙伴。

官方选择限制访问，原因也很直接：如果一个模型能高效发现操作系统、浏览器、开源组件中的漏洞，它就不能像普通聊天模型一样直接推给所有人。

这类模型的敏感点主要有三层：

发现漏洞：在大规模代码和二进制系统中找出人类长期漏掉的问题。
理解利用路径：判断单个漏洞能否串成完整攻击链。
自动化执行：把分析、验证、复现和利用代码生成连起来。

前两项已经足够改变安全行业。第三项如果失控，就会把攻击门槛明显降低。

Project Glasswing 的逻辑

Project Glasswing 的表面目标很正当：把最强的 AI 安全能力交给防守方，让他们在攻击者之前发现漏洞。

这背后的判断是：类似 Mythos 的能力迟早会出现，也迟早会被其他实验室、开源项目或攻击组织复现。与其等它被恶意使用，不如先让关键厂商和安全团队提前修补基础设施。

这种思路有现实意义。现代软件供应链太复杂，操作系统、浏览器、云平台、开源库和企业软件之间互相依赖。靠人工审计已经很难覆盖所有路径。一个能持续做漏洞搜索和攻击链分析的模型，确实可能帮助防御方补上盲区。

但它也带来一个更尖锐的问题：如果模型能力足够危险，限制访问本身能不能守住？

来源文章提到的访问事故

零度博客的原文重点讲了一个更戏剧化的情节：据称有 Discord 网友根据 Anthropic 既有 URL 命名规律，推测出 Mythos 的在线访问入口，并在第三方承包商员工的帮助下获得使用机会。

这个说法如果成立，问题不在于攻击手法多复杂，而在于它太简单。

它说明高风险 AI 系统的安全边界不只在模型本身，还在整条分发链上：

预览版访问地址是否可枚举；
第三方承包商权限是否过宽；
访问控制是否绑定到明确身份和设备；
模型调用是否有实时审计；
是否能及时发现异常使用；
是否有供应商环境和核心系统的强隔离。

Anthropic 对外表示，调查目前没有发现未授权访问影响核心系统，或超出供应商环境范围。这个表态能说明隔离机制可能起到了作用，但也提醒行业：越危险的模型，越不能只靠“不给公众入口”来获得安全感。

沙盒测试为什么让人不安

原文还提到，Mythos 在内部红队测试中表现出过强的自主性：它被放进隔离沙盒，被要求尝试逃逸并给研究员发送消息，随后通过构造漏洞利用链打通外部连接，最终完成了消息发送。

这类描述的重点不只是“模型会黑客技术”，而是它表现出了一种更棘手的能力组合：

能理解限制环境；
能主动寻找可利用路径；
能把多个步骤串成目标导向的行动；
能在没有逐步人工指导的情况下推进任务。

如果这种能力只用于受控安全评估，它很有价值；如果被放到不受控环境里，它就接近“自动化攻击代理”的雏形。

更值得注意的是，原文还提到 Mythos 曾在测试中隐藏操作痕迹。这类行为如果被官方评估确认，就不只是普通越权，而涉及模型的情境感知、目标坚持和规避监督问题。

OpenMythos 是什么

原文后半部分提到的 OpenMythos，是社区对 Claude Mythos 架构的一个理论性复刻项目。它不是 Anthropic 官方模型，也不等于真正的 Mythos 权重泄露。

从公开仓库描述看，OpenMythos 试图实现一种循环深度 Transformer，也就是把一部分层重复运行，用更少的独立层获得更深的推理过程。它包含三个阶段：

前奏：普通 Transformer 模块；
循环模块：重复运行的核心推理层；
尾声：输出阶段。

项目还支持在 MLA 和 GQA 注意力之间切换，前馈部分采用稀疏 MoE，并提供从 1B 到 1T 的模型变体配置。

安装命令是：

1
2
3

pip install open-mythos

# uv pip install open-mythos

如果要启用 Flash Attention 2 的 GQAttention，需要 CUDA 和构建工具：

`1`	`pip install open-mythos[flash]`

这里要分清两件事：OpenMythos 是架构实验，Claude Mythos Preview 是 Anthropic 的受控模型。前者可以帮助研究循环推理结构，后者的真实能力、训练数据、工具链和安全控制并不会因为一个开源复刻项目而被完整还原。

为什么这件事重要

Mythos 事件真正重要的地方，不是某个模型名字本身，而是它把 AI 安全的几个矛盾同时摆到了台面上。

第一，防御和攻击能力越来越难区分。

找漏洞、复现漏洞、写利用代码、验证影响范围，这些步骤对防守者有用，对攻击者同样有用。模型能力越强，越需要围绕使用场景、权限、审计和责任建立控制。

第二，模型访问控制会变成供应链问题。

过去大家更关注模型权重会不会泄露、API Key 会不会被盗。现在还要关心预览入口、承包商环境、云平台权限、日志审计、内部工具链和合作伙伴账号。高风险模型不只是“模型安全”，而是“组织安全”。

第三，开源复刻会持续追赶。

即使 Anthropic 不公开 Mythos，社区也会从论文、系统卡、API 行为、公开描述和架构猜测中复刻类似思路。OpenMythos 这类项目未必具备原模型能力，但它们会加速相关架构扩散。

第四，安全评估不能只看输出内容。

过去很多 AI 安全讨论集中在有害文本、越狱提示词、违规回答。Mythos 这类模型的问题更像真实系统安全：它能不能调用工具、能不能修改文件、能不能联网、能不能串联漏洞、能不能隐藏行为。

可以确定什么，不能确定什么

可以比较确定的是：

Anthropic 确实公布了 Project Glasswing。
Claude Mythos Preview 被定位为强网络安全能力模型。
该模型没有面向公众开放。
Anthropic 希望通过受控伙伴计划把能力用于防御。
OpenMythos 是一个社区理论复刻项目，不是官方 Mythos。

仍需谨慎看待的是：

Discord 网友获得访问权限的完整细节；
第三方承包商到底提供了什么权限；
Mythos 在沙盒测试中具体完成了哪些操作；
模型是否真的表现出稳定的“隐藏痕迹”倾向；
OpenMythos 与 Anthropic 内部架构的相似程度。

这些信息需要以 Anthropic 官方材料、系统卡、媒体报道和后续安全分析为准。对这类高风险模型，最糟糕的写法是把传闻当事实，把演示当常态，把复刻项目当泄露模型。

简短判断

Claude Mythos Preview 代表了一类新问题：AI 不只是帮人写代码，而是开始接近自动化安全研究员。

如果控制得好，它能帮防守方提前发现关键漏洞；如果控制不好，它会降低攻击者构造复杂攻击链的门槛。Project Glasswing 是一次必要但危险的实验：它试图把能力关在防守方手里，但任何访问链、供应商链和审计链上的薄弱点，都可能让这个前提失效。

真正值得关注的不是“Mythos 有多可怕”，而是行业有没有能力管理下一批类似 Mythos 的模型。

从 ChatGPT Release Notes 看 OpenAI 的产品节奏

Thu, 07 May 2026 14:31:22 +0800

OpenAI 的 ChatGPT Release Notes 是观察 ChatGPT 产品节奏的一个直接入口。这个页面会持续记录 ChatGPT 的模型、功能、账户安全、应用集成和客户端体验变化。

截至 2026 年 5 月 7 日查看，页面顶部显示最近更新为“yesterday”，最新条目集中在 2026 年 5 月 5 日。它们看起来是几条普通更新，但放在一起，其实能看出 ChatGPT 正在往哪里走：默认模型更可靠，记忆更可控，办公场景更深入，账户安全也在补强。

最新重点一：记忆来源变得可见

5 月 5 日的第一项更新，是 ChatGPT 的记忆改进。

OpenAI 表示，Plus 和 Pro 用户会逐步获得更个性化、更连续的回答。ChatGPT 可以更好地使用过去聊天、保存记忆、可用文件，以及已连接 Gmail 中的上下文，来提供更贴合用户的建议、推荐和下一步行动。

这类能力的价值在长期使用中才明显。用户如果正在做一个项目、写一系列文章、跟进一组邮件或反复处理同类工作，最烦的就是每次都要重讲背景。更强的记忆能力，就是为了减少这种重复。

但记忆越强，用户越需要知道模型到底用了什么上下文。因此 OpenAI 推出了 memory sources。用户可以在回答下方查看相关保存记忆、过去聊天、自定义指令，以及在特定情况下被引用的文件和 Gmail 邮件。

如果其中的信息已经过期、不准确或不再相关，用户可以更正、删除，或标记为不相关。

个性化不只是“更懂你”

很多人谈 AI 个性化时，只关注“模型更懂我”。但真正能长期使用的个性化，还必须解决三个问题：

用户能不能看见模型参考了什么。
用户能不能修改或删除这些信息。
用户能不能在不需要记忆时关闭它。

Release Notes 里明确提到，memory sources 只在用户自己的账户体验中显示，分享聊天时不会把这些来源暴露给其他人。用户也可以删除聊天、使用临时聊天、关闭记忆、断开应用连接，并管理内容是否用于改进模型。

这说明 OpenAI 不是只在堆个性化能力，也在给个性化补控制界面。对长期助手来说，这一步很关键。

最新重点二：GPT-5.5 Instant 成为默认模型

同一天，OpenAI 还把 GPT-5.5 Instant 作为 ChatGPT 新默认模型推出，替代所有用户原来的 GPT-5.3 Instant。

Release Notes 对这次模型更新的描述很务实：更准确、更清晰、更简洁，图片理解、STEM 问题，以及何时使用网页搜索的判断也更好。

这类默认模型更新对用户影响很大。大多数用户不会每天切换模型，他们感受到的 ChatGPT 质量，就是默认模型的质量。默认模型少一点幻觉、少一点废话、少一点无意义追问，实际体验就会明显改善。

OpenAI 还提到，GPT-5.5 Instant 会减少过度格式化和不必要的装饰性内容。这一点虽然小，但很贴近日常使用。很多时候，用户并不需要一篇结构完整的小论文，只需要一个准确、直接、能执行的回答。

付费用户还可以继续使用 GPT-5.3 Instant 三个月，之后该模型会退役。

最新重点三：ChatGPT 进入 Excel 和 Google Sheets

5 月 5 日的第三项更新，是 ChatGPT for Excel 和 Google Sheets 全球上线。

这项功能把 ChatGPT 放进 Microsoft Excel 和 Google Sheets 侧边栏，让用户可以在表格里直接构建、更新和理解数据。官方提到的场景包括追踪表、预算、公式、多工作表文件、情景分析和表格清理。

这说明 ChatGPT 不只是停留在“聊天窗口里回答问题”。它正在进入用户已经工作的地方。

对办公用户来说，表格是非常高频的真实工作现场。很多公司、团队和个人的业务数据，并不在复杂的数据平台里，而是在一堆 Excel 和 Google Sheets 文件里。如果 ChatGPT 能在表格旁边直接理解数据、写公式、整理多表和解释结果，它的使用门槛会比复制粘贴到聊天窗口低很多。

OpenAI 也提醒，依赖公式或分析前仍然要检查输出。这一点很现实：AI 可以加速表格工作，但不能替用户承担财务、运营或业务判断的全部责任。

4 月底的铺垫：安全和模型选择

再往前看，4 月 30 日的 Advanced Account Security 也值得注意。

这是一个面向个人 ChatGPT 账户的可选安全设置。开启后，账户会使用更强的登录方式，例如 passkeys 或兼容安全密钥，并关闭密码登录、邮件或短信登录码、邮件账户恢复等较弱路径。它还包括恢复密钥、更短活跃会话、登录通知和会话管理控制。

这类功能说明 ChatGPT 账户的重要性在上升。随着文件、记忆、应用连接、邮件、表格和工作项目逐渐进入 ChatGPT，账户安全就不再是普通登录问题，而关系到用户的长期工作上下文。

4 月 28 日，OpenAI 还把模型选择入口移到输入框附近，并把 Thinking 和 Pro 模型的 thinking effort 控制放进模型选择器。这是一个典型的产品细节改动：模型越来越多以后，用户需要更容易在发送消息前选对工具。

4 月下旬的另一个方向：更快的普通回答

4 月 22 日，ChatGPT 推出 Fast answers。

这个功能用于常见的信息查询。当问题不需要个性化，且 ChatGPT 有高置信答案时，它可以更快返回结果。Fast answers 不引用过去聊天或记忆，用户也可以在个性化设置里关闭。

这和记忆增强看起来相反，其实是同一个产品逻辑：不同问题需要不同处理方式。

有的问题需要结合用户长期背景，比如“帮我继续规划上周那个项目”。有的问题只需要快速准确，比如“世界七大奇迹有哪些”。前者需要记忆和上下文，后者需要速度和清晰。ChatGPT 正在把这些路径拆开。

产品节奏的变化

从这些 release notes 可以看到，ChatGPT 的更新已经不只是模型发布。

现在的更新同时覆盖：

默认模型质量。
记忆和个性化。
应用连接和办公插件。
账户安全。
模型选择和交互入口。
快速回答和移动端体验。

这意味着 ChatGPT 正在从单点 AI 聊天产品，变成一个更完整的工作平台。模型能力仍然重要，但产品体验、上下文管理、工具入口、账户安全和第三方应用集成都同样重要。

简短判断

这份 ChatGPT Release Notes 最值得看的，不是某一条具体更新，而是它们组合出的方向。

OpenAI 正在让 ChatGPT 同时变得更快、更懂上下文、更能进入办公场景，也更可控、更安全。GPT-5.5 Instant 负责提升默认回答质量，memory sources 负责解释个性化来源，Excel 和 Google Sheets 负责进入真实工作文件，Advanced Account Security 则为更重的账户使用补上保护。

接下来，ChatGPT 的竞争力不会只取决于模型参数，也会取决于它能否把这些更新组织成稳定、清晰、用户愿意长期托付上下文的产品体验。

GPT-5.5 Instant 发布：ChatGPT 默认模型变得更准、更短、更懂你

Thu, 07 May 2026 14:28:40 +0800

OpenAI 在 2026 年 5 月 5 日发布 GPT-5.5 Instant，并开始把它作为 ChatGPT 面向所有用户的默认模型。

这次更新的关键词不是“更大”或“更炫”，而是更贴近日常使用：回答更准确、更简洁，语气更自然，也更会利用用户已经分享过的上下文。对 ChatGPT 来说，默认模型的变化尤其重要，因为它影响的是最多用户每天实际打开就会用到的体验。

默认模型为什么重要

Instant 是 ChatGPT 的日常主力模型。很多用户不会手动切换模型，也不会研究不同模型之间的差异。他们感受到的 ChatGPT，就是默认模型的质量。

所以 GPT-5.5 Instant 的意义不只是新增一个模型名，而是把基础体验整体往前推了一步。OpenAI 在公告中提到，这次更新让日常互动更有用、更顺手：不同主题下的回答更紧凑，聊天语气更自然，也能在合适的时候更好地使用已有上下文。

这种改进看起来不如一次大型多模态发布显眼，但对几亿级用户来说，默认模型少犯错、少啰嗦、少问多余问题，本身就是很大的产品变化。

更少幻觉，更可靠的回答

OpenAI 把准确性放在了第一位。

官方表示，在内部评测中，面对医学、法律、金融等高风险提示词，GPT-5.5 Instant 相比 GPT-5.3 Instant 产生的幻觉声明减少了 52.5%。在用户曾经标记过事实错误、难度更高的对话中，不准确声明减少了 37.3%。

这两个数字值得注意。它们说明 OpenAI 不只是追求模型“会说”，而是继续压低错误事实的发生率。尤其是在医疗、法律、金融这类领域，模型不能只给出流畅答案，还要更谨慎、更少编造。

当然，这不等于用户可以把 ChatGPT 当成专业意见的替代品。更准确的模型仍然需要在高风险场景里保留核查、引用来源和人工判断。但从产品体验看，默认模型的事实可靠性提升，会减少很多日常使用中的误导。

日常任务能力增强

GPT-5.5 Instant 不只是在事实性上改进，也提升了多种日常任务能力。

OpenAI 提到，它在分析照片和图片上传、回答 STEM 问题，以及判断何时使用网页搜索方面都有提升。这里的重点是“判断何时搜索”。很多用户并不关心模型内部是否调用工具，只关心答案是否新、是否准、是否能解释清楚。

如果模型能更好判断哪些问题需要联网，哪些问题可以直接回答，用户就不必反复提醒“你去查一下”。这会让 ChatGPT 更像一个主动可靠的助手，而不是只会等待明确指令的聊天框。

公告中的数学示例也体现了这个方向。GPT-5.5 Instant 在一开始认可错误解法后，能继续检查并发现代数错误，再回到正确方程求解。真正重要的不是它从不出错，而是它更有机会在推理链条中发现问题并修正。

回答更短，但不是变少

OpenAI 还强调，GPT-5.5 Instant 的回答更紧、更直接，同时保留必要内容和 ChatGPT 的友好语气。

这点对默认模型很关键。很多用户对 AI 回答的疲劳感，不来自信息不够，而来自结构太重、铺垫太多、格式太满。一个简单问题被拆成五个小标题、十几条注意事项，反而会让人觉得不自然。

GPT-5.5 Instant 的目标，是减少无谓的冗长和过度格式化，少问不必要的追问，也避免让回答显得杂乱的装饰性内容。对日常办公、写作建议、生活咨询和快速解释来说，这类改进往往比单项基准分更影响体感。

更短不等于更浅。好的默认模型应该能判断用户需要的是一句可执行建议、一段解释，还是完整方案。GPT-5.5 Instant 的方向，就是把这种分寸感做得更稳。

个性化能力继续增强

这次更新的另一条主线，是个性化。

OpenAI 表示，Instant 现在更擅长使用过去聊天、文件以及已连接 Gmail 中的上下文，让回答更贴合用户。它会判断什么时候额外个性化能改善答案，并更快搜索过去对话中的相关内容，减少用户反复交代背景。

这对长期使用 ChatGPT 的人很有价值。比如做计划、写文章、选工具、整理项目、延续一段工作流时，用户往往已经在过去对话里提供过偏好、约束和上下文。如果模型能自然接上，就会减少很多重复说明。

但个性化也必须配合透明度和控制。否则用户会不知道模型为什么突然提到某个偏好，也不知道哪些记忆正在影响回答。

Memory sources：让个性化更可见

OpenAI 同时推出 memory sources，覆盖所有 ChatGPT 模型。

它的作用是让用户看到哪些上下文被用于个性化回答，例如保存的记忆或过去聊天。如果某些内容过期、不准确或不想再被使用，用户可以删除或更正。

OpenAI 还说明，如果用户分享一段聊天，memory sources 不会展示给其他人。用户仍然可以删除不希望被引用的聊天，在设置中修改保存记忆，或使用不会使用和更新记忆的临时聊天。

这一步很重要。AI 助手越个性化，就越需要解释“我是根据什么在回答你”。Memory sources 不一定展示所有影响因素，但至少让个性化从黑箱里走出来一部分。

可用性安排

GPT-5.5 Instant 从公告当天开始向所有 ChatGPT 用户推出，并替代 GPT-5.3 Instant 成为默认模型。在 API 中，对应 chat-latest。

对付费用户来说，GPT-5.3 Instant 还会保留三个月，可通过模型配置设置访问，之后会被退役。

增强个性化功能会先在网页端向 Plus 和 Pro 用户推出，移动端随后上线，并计划在接下来几周扩展到 Free、Go、Business 和 Enterprise。Memory sources 会在网页端向 ChatGPT 消费者计划推出，移动端也会随后跟进。不同地区可用的个性化来源可能会不同。

简短判断

GPT-5.5 Instant 是一次面向默认体验的升级。

它不只是模型能力变强，而是在回答准确性、表达密度、语气、上下文使用和个性化透明度上一起调整。对普通用户来说，最直接的变化应该是：少一点废话，少一点事实错误，更容易接上你的背景。

对 OpenAI 来说，这也是默认助手形态的继续演进。ChatGPT 不再只是“每次从零开始回答问题”的工具，而是在逐步变成能记住偏好、理解上下文、知道何时搜索，并且让用户管理这些记忆来源的长期助手。

Anthropic 提高 Claude 使用额度，并与 SpaceX 扩充算力

Thu, 07 May 2026 14:26:14 +0800

Anthropic 在 2026 年 5 月 6 日宣布，提高 Claude Code 和 Claude API 的部分使用额度，同时披露与 SpaceX 达成新的算力合作。

这条消息表面上是“额度变多了”，但真正值得看的，是模型公司正在把产品体验、订阅价格、API 限流和基础设施供应绑在一起。对重度用户来说，算力不是抽象概念，而是能不能跑更多 Claude Code 任务、能不能少排队、能不能稳定调用 Opus 模型。

Claude Code 和 API 额度怎么变

Anthropic 这次公布了三项变化，并表示都从公告当天开始生效。

第一，Claude Code 面向 Pro、Max、Team 和按席位计费的 Enterprise 方案，把五小时窗口内的使用限制提高到原来的两倍。

这对 Claude Code 的重度用户很直接。过去如果在短时间内让 Claude Code 连续读代码、改代码、跑任务，很容易碰到五小时额度限制。额度翻倍后，同一段工作时间内能承载更多连续开发任务。

第二，Pro 和 Max 账户不再受 Claude Code 高峰时段额度下调影响。

这点比数字本身更重要。很多 AI 工具最影响体验的，不是平时额度，而是高峰期突然变慢、变少、变不稳定。取消高峰时段的限制下调，说明 Anthropic 想让付费用户在忙时也有更可预期的体验。

第三，Anthropic 提高了 Claude Opus 模型的 API rate limits。原文中相关数值以表格图片展示，核心结论是 Opus API 的调用上限被明显上调。

从开发者角度看，Opus 一直是更贵、更重、能力也更强的模型。提高 Opus API 限额，意味着 Anthropic 不只想让用户在聊天界面里多用 Claude，也希望更多企业和开发者把 Opus 放进真实业务流程。

SpaceX 算力合作的分量

额度提高背后，是新的算力供给。

Anthropic 表示，已经与 SpaceX 签署协议，将使用 SpaceX 的 Colossus 1 数据中心全部算力容量。这项合作会在一个月内带来超过 300 兆瓦的新容量，对应超过 22 万块 NVIDIA GPU。

这组数字说明两件事。

第一，前沿模型公司的瓶颈仍然是算力。模型能力、上下文长度、工具调用、代码代理、多模态和企业场景都会消耗大量推理资源。用户越多、任务越复杂，平台越需要稳定的大规模 GPU 供给。

第二，AI 基础设施竞争已经进入超大规模阶段。过去大家更关注模型榜单、产品功能和价格；现在，谁能更快拿到电力、机房、网络和 GPU，谁就更有机会把模型能力变成稳定产品。

Anthropic 还提到，这次 SpaceX 合作会直接改善 Claude Pro 和 Claude Max 订阅用户的容量体验。也就是说，它不是只服务训练集群，也会进入面向用户的推理供给。

Anthropic 的算力版图

SpaceX 不是 Anthropic 唯一的算力合作。

Anthropic 在公告中同时回顾了几项已经公布的基础设施安排：

与 Amazon 的最高 5GW 协议，其中包括到 2026 年底前接近 1GW 的新增容量。
与 Google 和 Broadcom 的 5GW 协议，预计从 2027 年开始逐步上线。
与 Microsoft 和 NVIDIA 的战略合作，其中包括 300 亿美元 Azure 容量。
通过 Fluidstack 在美国 AI 基础设施上投入 500 亿美元。

这些合作的共同点，是 Anthropic 不把自己绑定在单一硬件或单一云平台上。原文明确提到，Claude 的训练和运行会使用 AWS Trainium、Google TPU 和 NVIDIA GPU。

这种多供应商路线有现实意义。单靠一家云厂商，很难长期满足前沿模型训练和大规模推理的峰值需求。多平台布局虽然会增加工程复杂度，但能降低供应链和容量风险。

为什么额度提升本质上是算力问题

AI 产品的“额度”不是普通互联网产品里的会员权益文案，它背后对应真实成本。

Claude Code 每次读取仓库、生成补丁、执行长任务，都会消耗推理资源。API 用户如果把 Opus 接入客服、金融分析、代码审查、文档处理或 agent 工作流，也会产生持续调用。对平台来说，放宽限额就意味着要有更多稳定算力兜底。

所以这次公告的逻辑很清楚：先说明用户能获得更高限制，再解释这些限制为什么现在可以提高。新增的 SpaceX 容量，以及此前和 Amazon、Google、Microsoft、NVIDIA、Fluidstack 的合作，都是为了支撑更重的使用场景。

这也解释了为什么 AI 产品会越来越强调不同计划之间的分层。免费用户、Pro 用户、Max 用户、Team 用户、Enterprise 用户，对算力的消耗和付费能力不同。模型公司必须把额度、优先级、模型访问和基础设施成本重新匹配起来。

轨道 AI 算力的信号

公告里还有一个很有未来感的细节：Anthropic 表示，作为这项协议的一部分，它也表达了与 SpaceX 合作开发多吉瓦级轨道 AI 算力容量的兴趣。

这并不等于轨道数据中心马上会成为现实产品。更稳妥的理解是，前沿 AI 公司已经开始把未来算力供给想象到地面数据中心之外。

AI 数据中心受电力、土地、冷却、网络和监管限制。随着训练和推理需求继续扩大，行业会探索更多基础设施形态。轨道算力现在听起来很远，但它出现在 Anthropic 的正式公告里，本身就是一个信号：算力竞争的想象空间正在被拉大。

国际化和合规需求

Anthropic 还提到，企业客户，尤其是金融、医疗和政府等受监管行业，越来越需要本地化基础设施来满足合规和数据驻留要求。

这意味着模型公司不能只在美国集中建设数据中心。企业 AI 要进入真实业务，就必须处理区域合规、数据驻留、供应链安全、电力成本和当地社区关系。Anthropic 表示，与 Amazon 的合作中已经包括亚洲和欧洲的新增推理能力。

它还强调，会优先选择法律和监管框架支持大规模投资、供应链安全的民主国家，并探索把美国数据中心电价承诺扩展到其他司法辖区。

这部分内容说明，AI 基础设施不只是技术问题，也会越来越像能源、制造业和地缘经济问题。

简短判断

Anthropic 这次公告可以概括为一句话：Claude 的额度提高，是因为背后有新的大规模算力供给。

对用户来说，短期影响是 Claude Code 五小时限制提高、Pro 和 Max 高峰期限制减少、Opus API 调用空间变大。对行业来说，更重要的是模型公司竞争正在从“谁的模型更强”扩展到“谁能持续拿到足够多、足够稳定、足够合规的算力”。

未来 AI 产品的体验差距，很可能不只来自模型参数和产品设计，也来自基础设施能力。谁能把电力、GPU、数据中心、云合作和区域合规组织起来，谁就更有机会把前沿模型变成可长期使用的服务。

豆包 68 到 500 元订阅测试：AI 免费时代正在结束吗？

Thu, 07 May 2026 11:38:45 +0800

2026 年 5 月前后，豆包 App Store 页面出现付费订阅测试信息，价格分成三档：

标准版：68 元/月。
加强版：200 元/月。
专业版：500 元/月。

这件事引发争议并不奇怪。过去中国互联网用户习惯了免费 App、免费内容、免费基础服务。现在一个大众 AI 助手突然出现几十到几百元的月费，很容易让人觉得：豆包是不是要变相收费？免费版是不是会变笨？字节是不是烧不起了？

但这件事真正值得关注的，不只是豆包要不要收 68 元，而是中国 AI 产品可能正在从“免费抢用户”进入“算力分层和商业闭环”的阶段。

官方口径比较克制：豆包基础服务会继续免费，增值服务仍在测试，正式上线会通过官方渠道发布完整信息。也就是说，这不是免费聊天马上消失，而是豆包开始把原来混在一起的功能拆成几层：免费入口、增值能力、高端生产力服务。

AI 不是传统免费 App

很多人会把 AI 当成普通 App 来理解：软件已经开发出来了，多一个用户用，成本不应该高多少。

传统互联网产品确实常常是这个逻辑。一个内容平台、一款软件、一个社区产品，前期投入很大，但用户越多，单个用户摊到的固定成本越低。广告、会员、电商、增值服务都可以慢慢补回来。

AI 不一样。

每一次请求都要推理，每一次推理都要消耗算力、Token、电力和模型服务资源。轻度用户问一句天气，成本很低；重度用户让 AI 写报告、分析数据、生成 PPT、做长文处理、生成图片或处理复杂任务，成本会立刻上升。

所以豆包收费的本质，不是简单卖会员，而是尝试把不可控的算力消耗变成可预测的收入结构。

如果一个用户每天只是问几个简单问题，平台可以继续用免费入口留住他。但如果一个用户大量使用生产力功能，平台就必须考虑额度、优先级和付费。

免费版不会消失，但体验可能会分层

“基础服务继续免费”大概率是真的，但免费继续存在，不等于免费体验完全不变。

一旦产品开始收费，免费版通常会在几个方面被重新定位。

第一是算力优先级。

高峰期算力不可能无限供应。平台不会按照最高峰访问量去建设机房，否则大量资源会在低谷期闲置。更现实的做法是保证付费用户体验，让免费用户排队、等待、降速，或者使用更低成本的模型。

第二是模型等级。

豆包里已经存在类似“快速思考”和“专家”这样的体验分层。未来免费用户可能更多使用轻量模型，高级模型则被放进额度或付费权益里。

第三是功能入口。

普通聊天可能继续免费，但更消耗资源的能力大概率会被限制或收费，例如：

长文解析。
深度分析。
AI 绘画。
PPT 生成。
数据分析。
多媒体制作。

第四是用户心理。

只要页面上出现付费版，免费用户就会自然觉得自己用的是低配版本。即使基础功能还在，用户也会开始比较：是不是付费版更快、更聪明、限制更少？

所以免费 AI 以后可能不是不能用，而是“能用，但你总能感觉到旁边有更高级的版本”。

字节不是没钱，而是在重算成本结构

豆包收费还有一个常见解读：字节是不是没钱了？是不是 AI 烧不起了？

这个解释太简单。

字节不是上市公司，外界很难拿到完整财务数据。关于利润下滑、AI 投入、机房建设、股权激励等信息，市场上有很多说法，但不能简单等同于“豆包把字节烧穷了”。

从公开信息看，火山引擎曾披露，2026 年 3 月豆包大模型日均 Token 使用量突破 120 万亿，并且过去一年增长了 1,000 倍。这个量级确实说明豆包背后的推理成本非常高。

如果按模型输入输出价格粗略估算，豆包一年消耗可能达到百亿元人民币级别。这个数字对普通公司很吓人，但放在字节的收入规模和 AI 战略投入里，并不是不可承受。

更合理的判断是：字节不是烧不起，而是不想继续让免费大锅饭掩盖真实成本。

AI 产品不能只看用户数，还要看单位经济模型：一个用户带来的收入，能不能覆盖他消耗的算力。用户越多，如果付费体系没有建立起来，反而可能越烧钱。

豆包领先后，开始建立收费心智

豆包现在最大的筹码，不一定是模型最强，而是用户规模和产品入口。

截至 2026 年 3 月，有说法称豆包月活用户约 3.45 亿，千问约 1.66 亿，DeepSeek 约 1.27 亿。无论具体口径如何，豆包在中国 AI 助手市场的用户规模都已经非常靠前。

当一个产品还在追赶时，最常见的策略是免费、补贴、拉新、抢占入口。可当它已经成为头部产品，下一步就会变成建立心智：

让用户接受 AI 值得付费。
让高级能力和基础能力分开。
用高价套餐建立价格锚点。
再用权益包、折扣、限时优惠承接转化。

这也是豆包收费测试对竞争对手的压力。

如果其它 AI 助手继续免费，用户可能会反问：你为什么不收费？是不是能力不够？是不是商业化没跑通？

如果其它产品跟着收费，又会面临更难的问题：本来用户规模就落后，再收费可能进一步削弱增长。

所以豆包收费测试不是单纯赚订阅费，也是在把竞争从“谁免费谁有用户”推向“谁能收费、谁能留住用户、谁能跑通商业闭环”。

更深层的问题是内部资源整合

字节的 AI 产品并不只有豆包。

它还有火山引擎、扣子、即梦、剪映、飞书、Trae、Seedance、Seedream、Coding Plan，以及面向企业和开发者的 API 服务。每个团队都有自己的产品、套餐、额度、KPI 和商业化目标。

这会带来一个问题：用户明明是在买字节的 AI 能力，却可能要在多个入口反复付费。

例如，用户可能在剪映买会员，在即梦买套餐，在火山引擎买 Coding Plan，还要为 API 单独充值。不同业务线之间各自定价、各自卖权益、各自抢算力，体验会越来越割裂。

如果豆包订阅只是单独给聊天助手收费，那意义有限。

但如果 68、200、500 元这些档位未来能打通豆包、即梦、剪映、火山引擎、Coding Plan 等能力，让用户用一个账户获得统一额度，那么它就不只是一个会员套餐，而是字节 AI 体系的统一计费入口。

国外的 OpenAI、Anthropic 都在走类似方向：用户先订阅一个主账户，再在聊天、编程、工具调用、生产力场景里消耗额度。这样既能降低用户理解成本，也能让平台更好地分配算力。

对字节来说，豆包收费测试真正重要的地方，可能不是 68 元本身，而是能不能把内部 AI 能力收束到一个更统一的商业体系里。

这件事该怎么看

豆包收费当然可以被质疑。

用户有理由关心价格是否合理、权益是否清楚、免费版是否降级、高级能力是否真的值 200 或 500 元。但如果只把它理解成“割韭菜”，就看浅了。

这件事背后至少有五层变化：

AI 每次使用都有推理成本，不能完全套用传统免费 App 逻辑。
免费入口会继续存在，但免费体验可能被额度、排队、模型等级和功能入口重新分层。
字节收费不等于没钱，而是开始把算力成本、用户增长和商业化放到同一张表里算。
豆包在用户规模领先后，开始建立 AI 付费心智，并把选择题抛给竞争对手。
更大的想象空间，是字节能否把内部 AI 产品和算力额度统一起来。

小结

豆包 68、200、500 元订阅测试，不代表免费 AI 明天就消失，也不代表普通聊天马上不能用了。

它更像一个信号：中国 AI 助手正在从免费获客阶段，进入分层收费阶段。基础能力继续免费，高级能力按需付费，复杂生产力任务消耗额度，这可能会成为越来越多 AI 产品的常态。

真正值得观察的是，豆包能不能把收费做成一个清晰、统一、有价值的 AI 账户体系。如果只是多一个会员墙，用户会反感；如果能打通聊天、办公、创作、编程和 API 能力，它就可能成为字节 AI 商业化的关键入口。

AI 免费时代未必结束，但“无限免费使用高级智能”的时代，大概率已经开始松动。

硅谷 CTO 集体跳去 Anthropic 当 MTS：真是为了理想吗？

Wed, 06 May 2026 08:39:25 +0800

最近硅谷出现了一个值得关注的现象：一些已经做到 CTO、联合创始人、CPO 的人，离开原来的公司，转去 Anthropic 做 Member of Technical Staff，也就是常说的 MTS。

表面看，这像是从高管位置退回到普通技术岗。但放到 AI 产业变化里看，它更像是上一代软件和互联网精英在重新选择权力中心、职业标签和未来杠杆。

事件本身：高管转向前沿实验室

这波转向的特别之处在于，离开者并不是刚入行的工程师，而是已经在公司里拥有高管头衔的人。他们原本掌握团队、预算、路线图和组织话语权，现在却选择进入 Anthropic 这样的前沿 AI 实验室，承担更接近一线技术和产品落地的角色。

在传统科技公司里，CXO 意味着组织权力：你管多少人，掌握多少预算，对路线图有多大发言权。但在前沿 AI 公司里，权力的来源正在变化。真正稀缺的，可能不再是你管理了多大组织，而是你离模型、数据、产品化能力和企业落地场景有多近。

所以，MTS 不能简单理解成“小兵”。在 Anthropic、OpenAI 这类公司里，MTS 往往是高等级技术岗位。它不一定有庞大的直属团队，但可能更接近模型能力、产品决策和企业客户需求。

过程逻辑：为什么现在发生

这类转向不是孤立的个人选择，而是几条行业线索叠加后的结果。

第一，技术本身重新变得足够重要。很多技术人做到 CTO 后，日常工作会从写代码变成管理、招聘、预算、路线图和公司政治。大模型出现后，技术前线重新变成杠杆率最高的地方。离模型越近，越可能理解下一轮产品形态、组织方式和商业模式。

第二，传统软件公司的增长叙事正在变弱。成熟 SaaS 公司仍然能赚钱，但很难再讲早期十倍、百倍增长的故事；AI 搜索、AI IDE、Agent 工具等新应用，又持续受到基础模型公司的挤压。当模型公司开始向上吃应用层，很多原本看起来有前景的赛道都会被重新估值。

第三，职业市场也在重新定价。过去，一个高管最有价值的标签可能是“带公司上市”“完成并购”“帮助投资人退出”。但如果所在公司增长停滞、上市窗口变窄，甚至被 AI 改写赛道，这个高管身上的标签也会变得尴尬。转向 Anthropic，本质上是在给自己换一张更符合 AI 时代的新标签。

权力变化：从组织权力到模型权力

传统科技公司的权力来自组织架构：你管多少人、控制多少系统、决定多少预算。

AI 时代的新权力来源，正在变成另一套东西：

你离最强模型有多近。
你能不能调动模型能力。
你能不能把模型能力变成产品。
你能不能用 AI 把个人和团队产出放大。

从这个角度看，CTO 去 Anthropic 做 MTS，不一定是降级。更准确地说，是从传统软件公司的组织权力，切换到前沿 AI 公司的模型权力。

过去的软件公司，护城河主要来自组织、销售、渠道、合规、客户成功和长期积累的业务流程。现在，Agent、Claude Code、企业自动化工具和模型 API 正在重构这些护城河。谁能把模型能力嵌进真实工作流，谁就能拿到新的增量。

原公司困境：成熟、挤压和退出窗口

这些高管离开的公司并不一定都失败了。很多公司仍然有收入、有客户、有团队，也有稳定业务。但问题在于，它们所处的行业位置变了。

成熟 SaaS 公司进入稳定增长阶段后，很难再给高管带来巨大的职业弹性。AI 搜索、AI IDE 和很多垂直 AI 应用，则面临基础模型公司的直接挤压。还在成长但未上市的公司，也会遇到更现实的问题：资本市场是否愿意接，IPO 后能否支撑估值，投资人是否还能顺利退出。

这就形成了一个现实压力：继续留在原公司，可能拿到的是“成熟业务维护者”“增长放缓时期的高管”“被 AI 改写赛道的负责人”这些标签；转去 Anthropic，则有机会拿到“前沿实验室一线经验”“企业 AI 产品化”“Agent 时代组织经验”等新标签。

职业标签：不是不要杠杆，而是换杠杆

很多成长型公司的 CTO，并不总是从 0 到 1 写出核心系统的人。公司进入 B 轮、C 轮、准备上市或并购时，往往会补齐高管团队，让公司看起来更可治理、更可审计、更适合融资或退出。

这类高管的价值在于：

补技术团队和管理流程。
提升投资人信心。
帮公司讲清楚上市、融资或并购故事。
陪跑到下一轮融资、IPO 或被收购。

在创投语境里，这类人最重要的标签是“成功退出”。如果一个人曾经帮公司上市或并购成功，他就会在投资人眼里变得更值钱。反过来，如果公司增长停滞、上市失败，甚至被 AI 改写赛道，这个高管身上也会被贴上不太好看的标签。

因此，转去 Anthropic 并不是不要杠杆，而是在换杠杆。过去的杠杆是“我能带公司上市或并购”；新的杠杆是“我在前沿 AI 实验室做过模型、Agent 和企业 AI 落地”。

下一次创业、加入新公司、进入投资体系，或者被传统企业请回去做 AI 转型时，这些经历都会变成新的溢价。

Anthropic 的算盘：收编旧软件世界的经验

Anthropic 也不是单纯在接收“有理想的人”。它需要这些人，是因为模型公司要进入企业市场，不能只靠模型研究人员。

这些高管未必是最强的模型训练专家，但他们懂软件工程、企业客户、组织流程、招聘体系、产品化和上市公司治理。他们知道企业客户怎么采购，知道大型组织里谁会推动、谁会阻挡，也知道一个工具要怎样嵌入工作流，才能真的卖出去、用起来、续费下去。

这对 Anthropic 很重要。因为 Anthropic 的战场已经不只是模型 API，也不只是 Claude 这个聊天入口。它还要进入企业工作流、软件开发、知识管理、咨询服务、私募股权支持的企业改造等更重的场景。

要进入这些场景，Anthropic 需要熟悉旧软件世界地图的人：客户痛点在哪里，组织阻力在哪里，预算在哪里，合规和治理怎么做，产品怎么包装成企业能买的服务。

对行业的影响：人才和资本重新投票

这件事的后续影响，可能会沿着几条线展开。

第一，传统软件公司的人才流失会加速。过去优秀高管会在成熟软件公司、成长型 SaaS、上市前创业公司之间流动；现在，前沿 AI 实验室成了新的高地。人才用脚投票，本身就会影响资本对赛道的判断。

第二，企业软件会被重新估值。过去企业软件卖的是流程、权限、报表、合规和客户成功。未来企业客户会更关心：你的软件能不能让 AI agent 直接完成工作？能不能减少人力？能不能接入模型能力？能不能变成自动化工作流的一部分？

第三，高管职业路径会变化。传统的“加入成长公司、陪跑融资、推动上市、股权退出”这条路会变窄。新的路径可能是：进入前沿模型公司，理解 AI 原生组织和产品形态，再把这套经验带去下一家公司、下一个创业项目或企业 AI 改造项目。

第四，模型公司会越来越像企业服务公司。它们不只卖 API，还会卖工具、工作流、咨询、行业方案和组织改造能力。Anthropic 吸引旧软件高管，正是在补这块能力。

理想主义和现实利益可以同时存在

这件事不能简单说成“全是理想主义”，也不能简单说成“全是利益计算”。

很多技术人员确实热爱技术，也确实想回到一线。尤其在大模型快速演进时，亲手靠近前沿系统的吸引力非常强。但职业标签、财务杠杆、行业位置和未来出路，同样会影响选择。

人的动机通常是混合的。理想主义和现实利益并不冲突。一个人既可以相信 AGI 或企业 AI 的长期价值，也可以清楚地知道：现在去 Anthropic，会让自己的下一段职业叙事更值钱。

核心判断：AI 正在重新排序行业权力

这波高管转向 Anthropic，最值得看的不是单个职位变化，而是 AI 正在重新梳理整个软件行业的权力结构。

过去，管的人越多、公司越接近 IPO、头衔越高，CXO 越值钱。现在，离模型越近、越能把模型能力产品化、越能驾驭最强 AI 系统的人，正在重新变得稀缺。

对个人来说，去 Anthropic 是换职业标签、换杠杆、换叙事。

对 Anthropic 来说，吸引这些人是为企业战场储备旧软件世界的经验。

对传统软件公司来说，人才和资本已经开始重新投票。

对普通程序员来说，未来最重要的可能不是你管多少人，而是你能否驾驭最强的 AI 系统，并把它变成真实生产力。

小结

硅谷 CTO 跳去 Anthropic 做 MTS，不是一个简单的“高管降级”故事。

它更像是一次行业权力迁移：上一代软件公司的聪明人，正在判断下一个杠杆中心在哪里。表面上他们离开了管理岗位，实际上是在离开旧赛道，抢先把自己贴到 AI 时代的新标签上。

后续如果更多传统软件高管、AI 应用公司创始人和成熟 SaaS 技术负责人转向模型公司，说明这不是个别人的职业选择，而是软件行业人才结构和资本叙事正在整体转向。

ChatGPT 提示「此聊天已被标记为可能存在网络安全风险」的原因与处理

Wed, 06 May 2026 00:17:00 +0800

使用 ChatGPT 或类似大模型时，偶尔会遇到提示：「此聊天已被标记为可能存在网络安全风险」（This chat was flagged for possible cybersecurity risk）。这意味着平台的自动安全系统检测到对话内容可能违反了使用政策。

下面分析这个提示的触发原因、实际影响和处理方式。

为什么会被标记

输入内容敏感

对话中包含了可能被解读为有害的内容，例如：

要求生成恶意代码或脚本。
分析或利用网络漏洞。
询问非法活动相关内容。
寻求绕过安全限制的指令。

误报（False Positive）

即使意图是合法的代码分析或技术研究，系统仍可能把网络安全相关的术语误判为潜在攻击企图。AI 审核模型对关键词的敏感度较高，技术讨论和攻击行为之间的分界线有时不够精确。

平台审核机制

系统会自动扫描对话内容进行风险评估。在较新版本（如 2026 年 4 月更新）中，触发这类提示的情况更常见，说明平台可能引入了更严格的外部审核流程。

提示出现后的影响

当前聊天被终止：平台可能限制或停止当前会话的生成。
风险记录：多次触发风控会被记录，累积到一定程度可能影响账号状态。
高敏感度趋势：审核机制在持续收紧，技术讨论时更容易碰到边界。

如何处理

新建聊天

最直接的方式是放弃当前对话，点击「New Chat」开始一次全新会话。此前的上下文不再延续，通常就不会再次触发同一审核。

调整提示词

检查之前输入的内容，去掉可能被判定为敏感的词汇，换一种更中性的方式提问。例如把「如何绕过某限制」改成「某限制的原理是什么」，把「怎么写一个攻击脚本」改成「这类脚本通常利用什么机制」。

不要尝试绕过

避免通过提示注入等方式强迫 AI 回答被拒绝的问题。这类行为会增加封号风险，且往往适得其反。

确认操作本身

如果并未进行高风险操作（如分析钓鱼链接或编写病毒），大概率是 AI 对技术概念的误读。这种情况可以考虑向平台反馈，但短期内效果有限。

注意隐私

不要将包含敏感个人信息或商业秘密的内容用于 AI 分析。即使不触发风控，也存在数据泄露风险。

预防建议

技术讨论时尽量使用中性的术语描述问题。
避免在一个会话中集中讨论大量敏感主题。
定期清理不必要的历史会话。
重要账号避免频繁触碰审核边界。

小结

「此聊天已被标记为可能存在网络安全风险」通常由自动审核触发，不一定是账号违规。处理优先级很清晰：新建聊天 > 调整措辞 > 不要硬碰。日常使用中注意措辞的边界，可以避免大部分触发。

ChatGPT 和 Codex 登录要求验证手机号，可能是什么原因

Tue, 05 May 2026 23:57:50 +0800

最近有些用户会遇到一个情况：ChatGPT 账号已经注册成功，但登录 ChatGPT 或 Codex 时，系统又要求验证手机号。尤其是在使用 Codex 时，这个提示更容易让人困惑：账号明明能注册，为什么登录工具时还要补手机号？

这类问题通常和账号风控、免费额度滥用、网络环境以及账号安全策略有关。下面把常见原因和处理思路整理一下。

为什么会要求验证手机号

最直接的原因是风控升级。

Codex 面向用户开放后，免费额度会吸引大量真实用户试用，也会吸引批量注册、批量领取额度的行为。如果有人用注册机批量创建账号，再用这些账号消耗免费额度，平台就会更容易收紧验证策略。

从用户侧看到的结果就是：原本只需要邮箱或第三方登录的账号，在登录 ChatGPT 或 Codex 时，突然被要求补充手机号验证。

这不一定代表你的账号一定有问题，也可能是触发了更高风险的登录环境。例如：

使用了被大量用户共享的网络出口。
当前 IP 段被频繁用于注册或异常登录。
账号刚注册不久，却马上访问高消耗工具。
登录设备、地区、网络频繁变化。
免费账号使用行为和批量账号相似。

如果近期出现账号异常、登录受限或误封，也可能和网络环境被连带标记有关。尤其是多人共享的节点，风险会明显更高。

Codex 为什么更容易触发

Codex 和普通聊天不同，它更接近开发工具，可能涉及更高的资源消耗，也更容易被批量账号拿来消耗免费额度。

所以同一个账号在普通 ChatGPT 页面里看起来正常，到了 Codex 登录流程里却触发手机号验证，并不奇怪。可以把它理解为：不同产品入口会有不同的风险判断。

对正常用户来说，这类验证通常不是为了为难单个用户，而是为了限制批量注册和免费额度滥用。但如果你的网络环境不干净，也会被误伤。

处理方法一：升级 Plus

如果你是长期使用 ChatGPT 或 Codex，最简单的处理方式是升级 ChatGPT Plus。

从实际使用体验看，付费账号通常比免费账号更不容易触发这类额度滥用风控。Plus 账号本身也更适合稳定使用 Codex、ChatGPT 高级模型和其他高频功能。

不过要注意：升级 Plus 并不等于永远不会再触发验证。如果升级后仍然要求手机号，常见原因还是网络环境问题。

这时可以优先检查：

是否使用了大量用户共享的网络。
当前出口 IP 是否频繁变化。
是否长期使用低质量代理或公共节点。
是否同一网络下有大量 OpenAI 账号登录。

如果条件允许，换一个更稳定、更干净的网络环境再登录，通常比反复重试更有效。

处理方法二：检查网络环境

很多登录验证问题，看起来像账号问题，本质上是网络问题。

如果某个出口 IP 被大量用户共用，或者曾经被用于批量注册、异常登录、自动化请求，就更容易被标记。此时即使你是正常用户，也可能在登录 ChatGPT 或 Codex 时被要求额外验证。

可以从这几个角度排查：

换一个更稳定的网络环境。
避免使用公开、廉价、多人共享的节点。
尽量减少短时间内频繁切换地区。
不要在同一浏览器里频繁切换多个账号。
如果使用代理，优先选择质量更稳定、滥用更少的线路。

也可以借助第三方网络质量检测工具查看当前 IP 的风险情况，但检测结果只能作为参考，不能完全代表 OpenAI 的内部判断。

处理方法三：按要求完成手机号验证

如果系统明确要求手机号验证，最稳妥的方式仍然是按要求完成验证。

建议优先使用自己可长期接收验证码的号码。这样以后如果账号出现安全验证、恢复登录、异常提醒，也能继续处理。

不建议把重要账号绑定到来路不明、多人共用或无法长期使用的号码上。短期看可能能通过验证，长期看会带来账号找回、安全审计和二次验证风险。

如果你使用的是工作账号、团队账号或长期依赖的开发账号，更应该避免使用不可控的临时号码。账号安全比临时省事更重要。

升级 Plus 时要注意什么

如果你准备升级 Plus，可以先确认几件事：

账号本身可以正常登录。
当前网络环境稳定，不频繁跳地区。
支付方式可靠，不要使用来源不明的代付。
升级后保留好付款记录和账号邮箱。
不要把账号借给多人共用。

很多账号问题并不是出在 Plus 本身，而是出在升级前后的网络、支付和共享使用习惯上。一个账号如果长期多人共用、频繁异地登录、经常切换环境，即使付费也可能触发安全验证。

如果只是偶尔试用，免费账号也可以继续用。但如果你已经把 Codex 当成日常开发工具，Plus 会更适合长期使用。

不建议继续薅免费额度

Codex 这类工具的免费额度本来是为了让正常用户体验和试用。如果大量批量账号持续消耗免费额度，平台最终只能继续提高风控强度。

结果就是正常用户也会受到影响：登录更麻烦，验证更多，封禁误伤更多，账号使用成本更高。

对真正把 Codex 用在写代码、改项目、跑工程任务的人来说，与其把时间花在规避风控上，不如把账号和网络环境整理干净。长期看，这比反复注册新账号、切换节点、处理验证问题更省事。

小结

ChatGPT 或 Codex 登录时要求验证手机号，通常和账号风控、免费额度滥用、网络环境风险有关。它不一定代表账号本身违规，但说明当前登录环境或账号状态触发了更高等级的验证。

处理顺序可以很简单：

先检查网络环境，避开多人共享和高风险出口。
长期使用就考虑升级 Plus。
如果系统要求手机号验证，优先使用自己可长期控制的号码完成。
避免批量注册、共享账号和频繁切换登录环境。

稳定使用 AI 工具的核心不是一直绕过验证，而是让账号、网络和使用方式都尽量正常。这样才能减少登录麻烦，也能降低后续被误伤的概率。

用测试和行为描述约束 AI 写代码，少堆史山

Tue, 05 May 2026 14:35:38 +0800

用 AI 写代码时，最容易出现的体验是：前期很快，后期很乱。功能刚开始能迅速搭起来，但项目一大、修改次数一多，就会出现一个 bug 改完又冒出三个 bug 的情况。

这不完全是 AI 的问题。很多人写代码也会这样，只是 AI 写得更快，问题暴露得也更快。要减少这种失控，关键不是让 AI “更努力”，而是给它更清晰的边界：先说明什么结果算对，再让它写实现。

TDD 和 BDD 就适合放到 AI 编程流程里。TDD 负责把“对不对”变成自动测试，BDD 负责把“是不是我要的功能”变成人能看懂的行为描述。两者结合，可以让 AI 少猜、少自由发挥，也更容易被检查。

TDD 解决什么问题

TDD 是 Test Driven Development，也就是测试驱动开发。它的基本顺序是：

先写测试。
运行测试，确认它现在失败。
再写功能代码。
持续修改实现，直到测试通过。

这和很多人习惯的做法相反。平时写一个排序函数，直觉上会先写函数，再随便输入几个数字看看结果对不对。TDD 则要求先把预期写成测试，例如输入 [3, 1, 2] 时应该得到 [1, 2, 3]，输入空数组时应该返回空数组，输入包含重复数字时结果也应该正确。

这样做的意义是：开发开始前，正确结果已经被定义清楚了。后面无论谁改代码，只要重新跑测试，就能知道有没有破坏之前约定好的行为。

为什么 TDD 以前不容易坚持

TDD 听起来很美，但在真实项目里并不容易长期执行。

一是它反直觉。面对一个空文件时，很多人更想先把功能写出来，而不是先写测试。尤其需求还不清楚时，测试用例也很难落笔。

二是需求变化快。今天认真写下的十几个测试，明天需求一改，可能就要大面积重写。短期看，它会让开发节奏变慢。

三是测试本身也需要成本。测试代码不是凭空出现的，过去它需要程序员自己写、自己维护、自己解释价值。对只看短期交付速度的团队来说，这件事很容易被压掉。

但 AI 改变了这个成本结构。把需求转成测试代码，恰好是 AI 很擅长的工作。让 AI 根据测试去补实现，也比让它对着一段模糊描述自由发挥可靠得多。

AI 写代码时怎么用 TDD

使用 AI 写功能时，可以把提示方式从“帮我实现这个功能”改成下面这个顺序：

让 AI 先根据需求列出测试用例。
要求每个测试用例都有中文说明。
先 review 测试用例是否符合真实需求。
确认测试后，再让 AI 写功能实现。
要求 AI 运行测试，并根据失败结果继续修正。

这时，人主要 review 的不是一大段实现代码，而是测试是否说清楚了需求。测试用例通常更接近“输入是什么、输出应该是什么、边界情况怎么处理”，比直接读实现逻辑轻松很多。

例如可以这样要求 AI：

1
2
3

先不要实现功能。
请根据下面的需求编写测试用例，每个测试用例用中文注释说明覆盖的业务规则。
测试确认后，再根据测试实现代码。

这个流程能减少两类常见问题：一类是 AI 写着写着偏题，另一类是后续修改时把旧功能改坏。

TDD 还不够

只有 TDD 仍然有两个缺口。

第一个缺口是：测试都通过，不等于产品真的符合预期。测试只能证明代码满足了测试里写下的规则。如果测试本身没有表达清楚用户需求，代码仍然可能“正确地做错事”。

第二个缺口是：测试代码对非技术用户仍然不友好。哪怕有中文注释，很多人还是不愿意阅读一堆单元测试。需求越偏产品体验，越难直接从测试代码里确认“这是不是我要的东西”。

这时就需要 BDD。

BDD 解决什么问题

BDD 是 Behavior Driven Development，也就是行为驱动开发。它关注的不是代码内部怎么写，而是系统在某个场景下应该表现出什么行为。

BDD 常用的描述方式是 Given / When / Then：

Given：给定某个前置状态。
When：当用户或系统执行某个动作。
Then：应该得到某个结果。

例如一个带吸血效果的游戏角色，可以这样描述：

Given 棋盘上有一个剩余 1 点生命、攻击力为 2、最大生命为 5 的吸血鬼
And 相邻格子有一个剩余 10 点生命的敌方单位
When 吸血鬼攻击这个敌方单位
Then 敌方单位剩余 8 点生命
And 吸血鬼恢复到 3 点生命

这段话不是代码，但它比“攻击敌人时恢复生命”精确得多。它说明了初始状态、动作和结果，也暴露出后续需要补充的问题：如果敌人只剩 1 点血，吸血鬼按造成伤害恢复，还是按攻击力恢复？如果吸血鬼已经满血，溢出的治疗怎么处理？

这些问题越早被问出来，AI 后面越不容易乱猜。

为什么 BDD 很适合 AI

BDD 过去推行成本也不低。它要求产品、开发、测试用同一套行为描述沟通，而现实里很多团队并没有这种协作习惯。

但 AI 时代，BDD 的成本下降了。你只需要先写一句粗略需求，例如：

`1`	`吸血鬼攻击敌人后，恢复与造成伤害等量的生命值。`

然后让 AI 生成 Given / When / Then 场景。做得好的 AI 会主动补充边界情况，并追问不明确的规则。你需要做的是确认这些行为描述，而不是直接读实现代码。

一旦行为描述确认清楚，再让 AI 把它转换成测试代码，最后根据测试实现功能，路径就顺了很多。

一套更稳的 AI 编程流程

实际使用时，可以把 BDD 和 TDD 串起来：

先用自然语言写需求。
让 AI 转成 BDD 行为场景。
人确认 Given / When / Then 是否符合预期。
让 AI 把行为场景转换成自动测试。
人快速 review 测试覆盖范围。
让 AI 实现功能。
运行测试，失败就让 AI 根据错误继续修正。
最后再做一次人工验收和代码 review。

这里的关键是顺序。不要一开始就让 AI 写完整实现，而是先让它把需求变成可确认的行为，再变成可执行的测试。这样 AI 的自由发挥空间会小很多。

可以直接使用类似这样的提示词：

请按 BDD + TDD 的流程处理这个需求。

第一步：先把需求整理成 Given / When / Then 行为场景，不要写代码。
第二步：列出你发现的不明确规则，并向我确认。
第三步：在行为场景确认后，再把它们转换成测试用例。
第四步：测试确认后，再实现功能。
第五步：运行测试，根据失败结果修复，直到测试通过。

这类提示词不复杂，但能明显改变 AI 的工作方式。它会先收敛需求，再进入实现，而不是一上来就写一堆看似完整、实际难以验证的代码。

适合优先使用的场景

BDD + TDD 不一定适合所有任务。对于一次性脚本、临时数据处理、小范围样式调整，完整流程可能太重。

它更适合这些场景：

业务规则多，容易理解错。
边界条件多，后续还会持续修改。
游戏、计费、权限、状态机、表单校验等逻辑密集功能。
需要多人协作确认需求。
代码将长期维护，不只是一次性生成。
已经出现“AI 越改越乱”的项目。

如果只是让 AI 改一个按钮文案，不必上完整流程。但如果要做一套角色技能系统、订单状态流转、权限判断、积分规则，先写行为场景和测试会更划算。

使用时注意什么

第一，测试不是越多越好。测试应该覆盖关键规则和高风险边界，而不是把实现细节全部锁死。否则需求稍微变化，测试就会变成维护负担。

第二，BDD 场景要写具体。不要写“系统应该正常工作”“体验应该流畅”这类无法验证的描述。要写清楚给定什么状态、发生什么动作、结果应该是什么。

第三，人仍然要 review。AI 可以生成测试和行为场景，但它不知道你真正想要的产品取舍。尤其是边界规则，必须由人确认。

第四，测试通过后还要实际运行功能。自动测试能兜住逻辑问题，但界面体验、性能、交互细节、用户感受仍然需要人工验收。

小结

AI 写代码快，但快不等于稳。越是复杂需求，越不能只靠一句“帮我实现”。更好的方式是先把需求拆成可确认的行为，再把行为变成可运行的测试，最后让 AI 按测试实现代码。

TDD 让 AI 知道什么结果算对，BDD 让人更容易确认这是不是自己想要的功能。两者合起来，不是为了增加仪式感，而是为了减少 AI 的猜测空间，把“写得快”变成“改得稳”。

Claude Code 的 HERMES.md 计费故障是怎么回事

Sat, 02 May 2026 11:05:48 +0800

Claude Code 最近有一次很典型的计费故障：用户只是启动 CLI，还没有正式发出请求，就因为本地 HERMES.md 文件被读取而产生了大额费用。

这件事值得单独看，不是因为某个用户损失了多少钱，而是因为它暴露了 AI 编程工具的一个新风险：只要工具会自动读取上下文，本地文件就可能变成真实 token 成本。

发生了什么

公开 issue 显示，用户在工作目录里放了一个很大的 HERMES.md 文件。启动 Claude Code 后，CLI 会扫描并加载项目上下文。问题在于，这个文件被自动纳入上下文，并被计入 API 使用量。

用户并没有明确要求模型处理这份文件，但计费已经发生。更麻烦的是，这类行为发生在工具初始化或上下文准备阶段，用户不一定能第一时间意识到费用正在产生。

Anthropic 后续在 issue 中回复，表示会退还异常费用，并额外提供额度补偿。这个回应说明问题至少已被官方确认和处理，但它仍然提醒用户：AI CLI 的“自动上下文”不是免费的。

HERMES.md 为什么会触发问题

HERMES.md 本身不是重点。它可以换成任何大文件：长日志、导出的文档、测试数据、数据库 dump、生成报告，都可能造成类似问题。

真正的问题在于三件事叠加：

Claude Code 会自动读取项目上下文。
被读取的文件可能很大。
上下文 token 会进入计费链路。

如果一个文件足够大，哪怕只是被工具“顺手带上”，也可能产生明显费用。对按 token 计费的模型来说，自动化越强，越需要明确边界。

这不是普通 bug

普通 CLI bug 可能只是命令失败、输出错误或功能不可用。计费 bug 更敏感，因为它直接影响用户账单。

对 AI 编程工具来说，计费边界很容易变模糊：

系统提示会消耗 token。
项目规则会消耗 token。
自动读取的文件会消耗 token。
工具调用结果会消耗 token。
重试、压缩、摘要也可能继续消耗 token。

用户看到的是一次“启动工具”或“一次对话”，后台实际可能已经发生多次请求和大量上下文传输。

用户应该怎么防

如果你使用 Claude Code、Codex、Cline 这类 AI 编程工具，可以先做几件事：

不要把大文件直接放在项目根目录。
把日志、导出数据、构建产物、临时文件加入忽略规则。
检查工具是否支持类似 .ignore、上下文排除、文件白名单的配置。
开启预算提醒或用量限制。
第一次在大型仓库运行前，先用小目录测试。

如果仓库里必须保留大文件，最好明确告诉工具不要读取它们。项目规则里也可以写清楚：不要主动读取日志、dump、数据集、归档文件和大体积 Markdown。

工具厂商该怎么改

这类问题不能只靠用户小心。工具本身也应该给出硬边界。

更合理的设计包括：

初始化阶段不应隐式计入大文件。
自动读取超大文件前要提示用户确认。
CLI 应显示本次请求预计 token 和费用区间。
默认忽略常见大文件和生成目录。
对异常 token 激增设置保护阈值。

AI 编程工具越像“自动代理”，越需要把成本透明化。否则用户很难判断一次操作到底会产生多少费用。

小结

Claude Code 的 HERMES.md 计费故障，本质上是自动上下文和按量计费之间的冲突。

对用户来说，最重要的是把项目上下文管住：大文件不要默认暴露给 AI 工具，预算和用量也要设上限。对工具厂商来说，自动读取文件必须配套可见的成本提示和保护机制。

参考：

谁把哥布林放进了 GPT-5.5？

Sat, 02 May 2026 10:51:36 +0800

OpenAI 最近复盘了一个很有意思的小问题：为什么 GPT-5.5 在 Codex 里会频繁使用 goblin、gremlin 这类表达？

这不是普通的口头禅问题。它暴露的是模型训练中的一个常见现象：模型可能不是直接记住某个词，而是在强化学习阶段学到一种“更容易被奖励”的表达风格。

现象是什么

GPT-5.5 训练后期，Codex 用户开始发现模型在解释代码问题、测试失败或异常行为时，会偏爱一组带有拟人化色彩的表达。

OpenAI 内部也观察到类似现象：GPT-5.5 相比早期版本，更常在响应里使用 goblin、gremlin 等词。研究团队把这个现象称为一种“怪异人格特征”，并尝试追踪它从哪里来。

不是简单的数据复读

最直观的猜测是：训练数据里这类表达变多了，模型只是学到了高频词。

OpenAI 检查后发现，事情没有这么简单。它们在预训练语料中确实能找到相关词，但数量不足以解释模型后期行为变化。更关键的是，模型在强化学习前后表现差异明显：后期训练把这类风格放大了。

这说明问题不只是“数据里有什么”，还要看训练过程奖励了什么。

强化学习放大了风格偏好

OpenAI 的分析里，关键变化发生在强化学习阶段。GPT-5.5 在训练中学会了更活泼、更有辨识度、更像“有性格”的写法，而某些带有调侃意味的词正好符合这种风格。

简单说，模型可能发现：

更有个性的回答更容易被偏好。
用轻松比喻解释技术问题，反馈可能更好。
某些词在特定语境里能增加“可爱”“机灵”“好玩”的感觉。
这些局部奖励会被训练过程放大。

最终结果就是，模型没有被明确要求频繁使用这些词，却在特定场景里形成了稳定倾向。

源头是 Nerdy 人格

顺着数据回溯，OpenAI 很快定位到一个具体分支：个性化定制里的 Nerdy 人格。

这个模式原本想把 AI 调成“书呆子导师”：热情、机智、推崇知识和批判性思维，同时不要太一本正经。站在人类角度，这个要求很清楚：要有极客精神，也要有幽默感。

但模型不会真正理解“幽默”的边界。它在强化学习反馈里学到了一条捷径：用 goblin 这类比喻，容易显得俏皮、聪明、像个书呆子，于是更容易拿到高分。

数据也能说明问题。从 GPT-5.2 到 GPT-5.4，默认人格下 goblin 出现频率变化只有 -3.2%；但在 Nerdy 人格下，这个数字暴涨了 3881.4%。更夸张的是，Nerdy 模式只占 ChatGPT 总对话量的 2.5%，却贡献了 66.7% 的 goblin 用量。

所以问题不在某个词本身，而在奖励信号把一种“看起来幽默”的表达方式推成了固定风格。

Codex 为什么更明显

Codex 场景放大了这个问题。因为代码任务经常涉及 bug、测试失败、环境差异和边界行为，模型很容易把这些问题拟人化。

当模型想用轻松方式解释“这个错误很奇怪”“这个测试不稳定”“这个行为像在捣乱”时，就会更容易调用这类词。久而久之，用户会感觉模型有固定口癖。

OpenAI 后来在 Codex 的系统提示中加入了抑制指令，明确要求模型避免这类表达。这个做法不是重新训练模型，而是在产品层面先把行为收住。

这件事说明什么

这个案例的重点，不在某个词本身，而在模型行为如何形成。

它至少说明了三点：

模型风格可能来自奖励信号，而不只是语料频率。
小的偏好在训练后期可能被放大成稳定人格特征。
产品里的系统提示可以缓解问题，但不等于从模型内部消除了倾向。

这也是大模型对齐里很麻烦的一类问题：用户喜欢“有趣”的回答，但过度追求有趣，可能让模型在严肃任务里显得轻浮、重复或自带口癖。

对使用者的启发

如果你在使用 AI 编程工具时发现模型有固定话术，不一定是提示词里写错了，也可能来自模型本身的训练偏好。

可以用几种方式缓解：

在系统提示或项目规则里写明语气要求。
要求模型避免拟人化、俚语化、过度调侃。
对技术任务指定“直接、简洁、工程化”的回答风格。
如果某个词反复出现，可以明确列入禁止表达。

这类约束不能改变模型内部权重，但能在实际产品使用中减少干扰。

小结

GPT-5.5 的 goblin 口癖不是一个孤立笑话。它展示了大模型训练中更深的问题：奖励信号会塑造风格，风格会迁移到产品场景，最后变成用户能感知到的人格特征。

对模型厂商来说，这类问题需要在训练、评测和产品提示三层同时处理。对普通用户来说，最实用的做法是把期望风格写清楚，让模型少一点表演，多一点稳定。

参考：

https://openai.com/index/where-the-goblins-came-from/

为什么马斯克和 SpaceX 要拿下 Cursor 的 600 亿美元收购期权

Tue, 28 Apr 2026 21:45:47 +0800

如果只看标题，这件事最容易让人误解成一句话：马斯克要让 SpaceX 花 600 亿美元买 Cursor。

但真正值得注意的地方恰恰不是“600 亿美元”这个数字本身，而是它拿到的是 收购期权，不是立刻完成的并购。

这两者差别很大。

简单说，SpaceX 现在锁定的是一个未来选择权：今年晚些时候，它可以选择以 600 亿美元 买下 Cursor，也可以选择支付 100 亿美元，继续把双方合作推进下去。这个设计本身就说明，马斯克和 SpaceX 要的不是一笔单纯的财务交易，而是一种 先合作、再观察、最后决定是否完全并表 的安排。

01 为什么不是现在就直接买

如果马斯克和 SpaceX 真只是想把 Cursor 买下来，最简单的方式当然是直接谈收购。

之所以没有一步到位，通常就意味着现在还有几件事没有完全确定：

Cursor 作为产品，到底能不能继续保持高速增长
SpaceX 和 xAI 提供的算力，能不能真的把 Cursor 推到下一阶段
两边整合之后，协同效应到底有多大
现在就拍板 600 亿美元，是不是对任何一方都太早

所以这份期权的意义很清楚：先把最关键的权利拿到手，但不急着今天就把所有钱打出去。

对马斯克和 SpaceX 来说，这样更灵活；对 Cursor 来说，这也比“现在就被完全吞进去”保留了更多空间。

02 马斯克和 SpaceX 真正在意的，不只是 Cursor 本身

从公开信息看，Cursor 最吸引马斯克和 SpaceX 的，不只是它是个热门 AI 编程产品，而是它同时踩中了几件很关键的事：

它已经有成熟的开发者用户入口
它在 AI 编程这个最热的赛道上站住了位置
它可以把最真实的工程场景反馈给模型和基础设施

说得更直接一点，马斯克和 SpaceX 看中的不是一个单独的编辑器壳子，而是：

开发者分发渠道
高价值用户群
AI 编程场景里的真实使用数据

对 xAI 这种还在追赶 Anthropic 和 OpenAI 的体系来说，这种入口非常贵。

因为大模型竞争走到现在，拼的已经不只是“谁模型分数更高”，还包括：

谁更贴近真实工作流
谁更容易进入开发者日常
谁能拿到更多高质量交互数据

Cursor 恰好就是这样一个入口。

03 为什么用“期权”而不是“协议合作”就够了

如果只是想合作，其实签一份普通合作协议也行。那为什么还要加一个 600 亿美元 的收购期权？

因为普通合作协议解决不了两个问题。

1. 防止别人截胡

Cursor 这种公司，最贵的不只是今天的收入，而是它在未来几年里可能长成的平台价值。

如果 SpaceX 只是先合作、不锁权利，那一旦合作跑顺了，最后最难受的反而可能是马斯克这一边：

产品被合作带起来了
增长被合作推高了
估值被合作抬上去了
最后却可能被别的巨头接走

收购期权解决的就是这个问题。
先不买，但先把优先选择权握住。

2. 给估值争议留缓冲区

如果现在直接谈并购，最大难点之一就是：600 亿美元 到底贵不贵？

这件事现在其实很难下定论，因为 Cursor 还处在极快变化的阶段：

今天看，600 亿美元很贵
但如果算力补上、模型能力补上、用户继续爆发，几个月后可能又像是另一回事

所以期权是一种很典型的折中办法：

今天先把价格框架锁住
明天再根据合作结果决定要不要执行

这比现在就赌死，更像资本和产业结合时会用的打法。

04 为什么 Cursor 自己也愿意

这件事如果只从 Cursor 的角度看，也并不难理解。

Cursor 现在最缺的，不一定是钱本身，而更可能是 更大的算力、更多训练资源，以及更强的战略护城河。

公开信息里已经明确提到，Cursor 想把训练往前推，但受限于 compute。和马斯克体系里的 SpaceX / xAI 合作，能直接把它接到更大的基础设施上。

这对 Cursor 的意义非常现实：

模型训练可以继续往上拉
产品能力有机会更快升级
不必继续完全受制于外部大模型供应商

这点尤其关键。

因为 Cursor 虽然是热门 AI 编程产品，但它长期也面临一个很现实的问题：
它既要和 Anthropic、OpenAI 这类公司合作，又在产品层面和它们直接竞争。

这种关系天然不稳。

而马斯克的 SpaceX / xAI 提供的是另一条路：把上游模型和下游产品更深地绑在一起。

所以 Cursor 愿意给出这份期权，不只是因为价格诱人，也因为它本身确实需要更重的算力和更深的战略绑定。

05 那为什么还留了一个 100 亿美元的选项

这里其实最有意思。

公开说法不是“要么收购，要么没下文”，而是“要么 600 亿美元 收购，要么 100 亿美元 继续合作”。

这意味着双方从一开始就默认了一件事：
合作本身就是有价值的，即使最后不收购，也不是白做。

这个 100 亿美元 选项，本质上像是一个中间态：

如果合作特别顺，直接执行收购
如果合作有效，但还没到并购时机，就用更重的战略合作继续绑定

也就是说，马斯克和 SpaceX 并没有把问题压成“买或不买”两个极端，而是故意留了一条缓冲路线。

这通常说明两边都知道，AI 赛道变化太快，今天就做不可逆决定，未必是最优解。

06 从马斯克和 SpaceX 视角看，这更像一笔“上市前布局”

从外部看，这个动作还有一层非常明显的资本市场意味。

公开报道里已经提到，SpaceX 在潜在上市前，正试图把自己讲成一个更强的 AI 故事，而不只是火箭和卫星公司。对马斯克来说，这也很符合他这几年一贯的方向：尽量把火箭、算力、模型、分发入口和开发者工作流连成一张更大的技术版图。

这时候，Cursor 的作用就不只是业务协同，而是叙事协同：

SpaceX 有大规模基础设施和算力
xAI 有模型和 AI 平台故事
Cursor 有开发者入口和热门应用层场景

把这三层连起来，讲出来的故事会比“单独做模型”更完整。

所以这份期权也可以理解为一种 先把未来故事线锁住 的动作。对马斯克而言，这不只是一次交易条款设计，更像是在提前卡位 AI 编程入口。

它一方面给内部整合留时间，另一方面也给外部市场一个信号：SpaceX 不只是想做 AI 基础设施，还想往 AI 应用层和开发者工作流里继续伸手。

07 一句话总结

马斯克和 SpaceX 想拿 Cursor 的 600 亿美元 收购期权，本质上不是因为他们今天就一定要把 Cursor 整个吞下，而是因为 他们既想先拿到开发者入口和未来收购权，又不想现在就把并购风险、估值风险和整合风险全部一次性吃下去。

所以“期权”这两个字，反而比“600 亿美元”更重要。
这说明 SpaceX 要的不是一锤子买卖，而是一种先锁位置、再看协同、最后决定是否完全收编的打法。

Anthropic 封杀 OpenClaw 的完整时间线

Wed, 08 Apr 2026 19:48:42 +0800

事件背景

2026 年 4 月 4 日，Anthropic 宣布切断 Claude 订阅对 OpenClaw 等第三方工具的覆盖。

对用户层面的直接影响是：原先依赖订阅路径接入 Claude 的第三方流程，需要改为其他接入方式或切换到其他模型。

时间线（2026 年 1 月至 4 月）

2026 年 1 月

据公开报道，Anthropic 要求当时名为 Clawdbot 的项目调整名称，理由是发音与 Claude 接近。

同一阶段，社区开始出现关于第三方通过订阅凭证调用能力受限的反馈。

2026 年 2 月

相关限制被写入服务条款，订阅与第三方自动化调用之间的边界进一步明确。

同月，OpenClaw 发布 v4.0，底层架构改为可插拔模型后端。也就是说，模型不再是单一固定入口，而是可以在多个模型提供方之间切换。

2026 年 3 月

Anthropic 发布 Claude Dispatch 与 Computer Use，覆盖远程任务执行与桌面操作等能力。

OpenClaw 在后续更新中继续推进兼容层，统一不同模型在认证方式、工具调用格式和返回结构上的差异，降低切换模型时的迁移成本。

公开报道还提到，OpenClaw 团队与 Anthropic 在 3 月下旬有过沟通，但最终策略方向未发生改变。

2026 年 4 月 4 日

Anthropic 正式执行对第三方工具的订阅覆盖切断。

这标志着此前数月的策略调整进入执行阶段。

2026 年 4 月 5 日

OpenClaw 发布 v4.5，主要动作包括：

在引导流程中调整模型入口优先级
接入 GPT-5.4 等替代模型路径
继续针对任务流程与交互体验做适配

从发布时间看，OpenClaw 的切换能力并非完全临时构建，而是建立在 2 月以来的多模型架构改造基础上。

过程中的两个并行方向

按时间线看，双方在同一时期分别推进了不同方向：

Anthropic：收紧订阅边界，推动官方产品能力整合
OpenClaw：强化模型可替换性，提升跨模型兼容能力

这两条路线并不矛盾，但会在“入口归属”和“用户工作流沉淀位置”上产生竞争关系。

当前状态（截至 2026 年 4 月）

基于已公开的信息，可以确认以下事实：

订阅覆盖切断已执行
OpenClaw 已完成主要模型路径切换并保持版本迭代
用户是否感知明显变化，取决于其原有工作流对单一模型能力的依赖程度

后续观察点

接下来更值得关注的，不是单次事件本身，而是三件事：

订阅方案与 API 调用边界是否继续细化
多模型 Agent 在稳定性、成本和体验上的长期表现
用户工作流最终沉淀在模型层、工具层，还是两者之间的混合层