AI News｜2026-06-12

今日目录

• Fable 直接把发布视频做完了，而且几乎没进传统剪辑软件
• Box 用企业文档 Agent 实测 Fable，称复杂知识工作准确率明显抬升
• Codex 在没发新功能时 token 消耗突增，说明需求是自发长出来的
• Claude Platform 补上定时部署和 vault 环境变量，开始照顾团队运行面
• Mike Krieger 谈 Fable 5：真正的能力判断往往要用几周才看得出来
• 企业做新 AI 应用时先上最强模型，再回头压成本，这个建议依然成立

今日判断

我今天更关注两类信号：一类是模型能力开始被具体工作流吃进去，另一类是开发平台在补齐团队级落地的基础设施。前者不是再看跑分截图，而是看它到底能不能把一段真实流程串起来。像 Fable 被拿去做企业文档 Agent 评测，也被直接拿去剪自己的发布视频，这两条放在一起看，比单独一句“模型更强了”有意义得多。一个说明复杂知识工作里，多步推理和稳定性开始影响业务结果；另一个说明只要工具调用链顺，模型已经能吞掉过去必须手工切换软件的一整段生产流程。

我看下来，最近 builder 的真实分水岭不是谁先接了最新模型，而是谁先把上下文、工具、部署和评估这些脏活连起来。Codex token 消耗突然上冲，而且是在没有发布新功能的情况下发生，这种信号比很多宣传更诚实：说明一线开发者会在能力跨过某个阈值后，自发把更多任务交出去。Claude Platform 上线定时部署和 vault 环境变量，看起来不起眼，但它恰好在补 Agent 从 demo 走向团队运行时最容易卡住的地方。

我的判断是，接下来一段时间最值得追的不是“下一个最强模型”，而是谁能把模型能力变成稳定可复用的工作单元：有评测、有工具链、有部署边界、有跨团队可交接的上下文。真正会留下来的产品，不是让人惊叹一次，而是让团队每周少开几次会、少切几次软件、少返工几轮。

快讯

1. Fable 直接把发布视频做完了，而且几乎没进传统剪辑软件

查看原文 · 来源：Thariq (@trq212)

Thariq 公开了自己如何用 Fable 完成发布视频制作：模型不仅写代码，还串起 transcription、ffmpeg、color grading、Figma MCP、Remotion UI 和渲染流程，他自己没有手动进视频编辑器。这条信息重要，不在于又多了一个 demo，而在于它给了一个很具体的 Agent 工作流样板：模型不只是生成内容，而是在多个专业工具之间做编排。我今天更看重这类案例，因为它说明只要工具接口足够标准，很多过去靠熟练工手动串联的软件流程，已经开始变成可重复执行的自动化生产线。我的判断是，下一批有壁垒的 Agent，不会停留在聊天框里，而会吃掉完整工序。

2. Box 用企业文档 Agent 实测 Fable，称复杂知识工作准确率明显抬升

查看原文 · 来源：Aaron Levie (@levie)

Aaron Levie 披露了 Box AI Complex Work Eval 的一组结果：在企业文档相关的复杂知识工作中，Fable 相比 Opus 4.8 在多个行业都有明显提升，尤其强调它在多步计算、复杂推理时更少走捷径，跨次运行也更稳定。我觉得这条值得看，不是因为它证明某个模型“赢了”，而是因为它把评测场景放在了真实企业任务里，比如法务、金融、医疗这类对文档理解和步骤严谨性要求很高的工作。我的判断是，企业 Agent 的下一轮竞争会越来越看重稳定性和过程正确性，而不是单次答案够不够像人。

3. Codex 在没发新功能时 token 消耗突增，说明需求是自发长出来的

查看原文 · 来源：Thibault Sottiaux (@thsottiaux)

Thibault 说，过去 48 小时 Codex 的 token 消耗出现明显增长，而且这次增长发生在没有新发布的情况下。我会把这看成一个很有价值的行为信号：很多时候产品真正跨过门槛，不是靠发布会，而是用户突然开始把更多任务交给它，导致使用深度自然上升。对做 coding agent 或 AI infra 的团队来说，这比单纯看 DAU 更有参考价值，因为 token 消耗上升通常意味着任务复杂度和依赖度都在变高。我的判断是，coding agent 现在更像进入了使用习惯重构期，一旦用户发现它能接住更大的任务，请求规模会自己膨胀。

4. Claude Platform 补上定时部署和 vault 环境变量，开始照顾团队运行面

查看原文 · 来源：Claude (@claudeai)

Claude Platform 上线了 scheduled deployments 和 vaults 中的环境变量管理。这不是最容易被转发的更新，但我反而觉得它更重要，因为它打到的是团队实际把 AI 应用跑起来时最常见的两个问题：怎么安全管配置，怎么按节奏把版本部署出去。很多 AI 工具卡住，并不是模型不够强，而是上线后没人敢把密钥、环境、发布流程交给一套临时脚本继续撑着。我的判断是，今年平台层最有价值的更新往往不会很性感，但会直接决定 Builder 能不能把 Agent 放进正式工作流。

5. Mike Krieger 谈 Fable 5：真正的能力判断往往要用几周才看得出来

查看原文 · 来源：AI & I by Every

在这期访谈里，Mike Krieger 讨论的重点不是 Fable 5 首日有多惊艳，而是模型真正进入日常使用几周后，用户才会慢慢发现原来自己之前根本没有把它推到极限。这种判断我很认同，因为很多模型发布后的噪音都来自 day-one 体验，真正决定产品设计的反而是两三周后的任务扩张：用户会不会开始改工作方式，会不会把更长链路交给它。我的判断是，Builder 现在评估新模型，应该把时间窗口拉长，至少观察一轮真实项目中的任务升级，而不是只看第一天的 demo 热度。

6. 企业做新 AI 应用时先上最强模型，再回头压成本，这个建议依然成立

查看原文 · 来源：Madhu Guru (@realmadhuguru)

Madhu Guru 分享了一个很实用的企业经验：如果只是把传统 ML 替换成 LLM，可以先从小模型开始；但如果是在构建全新应用，最好先用最强模型把能力边界跑出来，等确认什么体验是成立的，再往下压到更小更便宜的模型。我今天把它选进来，是因为这条建议虽然不新，但太多人还是反着做：一开始就为了成本选最弱模型，结果把本来可能成立的产品直接试死。我的判断是，早期团队最该节省的不是推理费，而是错误方向上的试错时间。