真正在做 AI 的人今天说了什么。一页读完，约 3 分钟。
今天 Claude 进了 Apple 的端侧技术栈，Swift 开发者可以带着类型信息，把活儿从本地模型交接给前沿模型。更热闹的话题是成本和评测：Guillermo Rauch 认为 inference 价格下降正在催生爆发式的弹性需求；另外两条独立的讨论则都在戳同一件事，团队评测 agent 的方式还是很糟。与此同时，OpenAI 用整个周末在公开场合修补用量限制。
Claude 通过一个新的 Swift package 接入 Apple 的 Foundation Models 框架
Anthropic 发布了一个 Swift package，让 Apple 开发者可以在 Apple 的 Foundation Models 框架内部调用 Claude，明天随 iOS 27、iPadOS 27、macOS 27、visionOS 27 和 watchOS 27 一起上线。这个分工是刻意设计的：端侧模型处理摘要、抽取这类又快又本地的活儿，遇到需要多步推理、代码生成、联网搜索或代码执行的请求，再交接给 Claude。因为 @Generable 注解返回的是带类型的 Swift 值，Claude 收到的是干净的结构化输入，而不是原始的用户文本。这个 package 负责流式输出、tool call 和结构化响应，把结果送回同一个 SwiftUI 视图，所以在用户看来就是一次连贯的体验。
便宜的 inference 正在证明，智能的需求弹性极高
OpenAI Sol 在 Vercel AI Gateway 上的降价和折扣，让它成了 Vercel 上增长最快的前沿模型。Rauch 由此判断，成本一降，智能的需求就会迅速膨胀。他的第二个说法更锋利：如果你没走 gateway，等于白白放过了价格波动，而这种波动现在是一根利润杠杆。他说，难怪路由这块突然热了起来，gateway 是必然的。他还讲了 fx 接下来怎么扩展：开放协议（MCP、Skills、Plugins），加上 Unix 那套小而可组合的程序思路，再配一个 libfx，让你把它嵌进自己的 CLI、后台 agent 或者软件工厂里。
给 agent 的每个环节打分，不要只看最终答案
最常见的 eval 错误，是攒一套标准最终输出的黄金集，然后检查 agent 有没有答到那儿。拿一个金融分析 agent 来说，给建议是四项工作中的最后一项：先理解客户，再收集证据，然后分析数据，最后才是给建议。每个环节都有自己的中间产物，也都值得单独做一套 eval。这样一来，建议出错就能落成一份诊断（客户理解 92%、证据抽取 92%、数据分析 70%、建议 75%），而不是两手一摊。这里的 Goldilocks 原则是：不要太细，也不要太粗，细到刚好够你拿结果去做事就行。
限额被投诉后，OpenAI 推送用量重置并上线修复
重置已经推到各个账号，前一天被反映的用量问题也修好了一批，明天还会有更多修复上线，并承诺会持续沟通。用户应该能感觉到明显好转。除了这次事故本身，还有一个更大的判断：2026 年会是各家公司开始认真在意模型效率和可靠性的一年，因为模型已经成了关键基础设施。
Claude 写自上而下的 eval 很行，写自下而上的很不行
eval 分两种，模型只在其中一种上帮得上忙。Shreya Shankar 的说法是：自上而下的 eval，是你光看任务描述、在真空里就能想出来的那些，Claude 在这上面帮助很大。自下而上的 eval 来自盯着成堆的样例输出，把你的直觉反应外化成一条检查。“Claude 想自下而上的 eval 非常非常差。那部分全得靠你自己。”
源数据来自 zarazhangrui 的开源项目 follow-builders，以 MIT 许可发布。摘要由 LLM 基于该项目的公开 feed 生成，摘要 prompt 亦改编自该项目。上面每一条都链接到原始出处。
摘要由程序自动生成。据此做判断前请先看原文。