真正在做 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 亦改編自該專案。上面每一則都連結到原始出處。
摘要由程式自動生成。據此判斷前請先看原文。