EasyVibeCoding Podcast

OpenAI 優化 Codex 貼近工作流程。 自訂快捷鍵 使用者現在可以直接在設定中調整快捷鍵，讓 Codex 配合個人習慣，而非被迫適應預設組合。 Git 操作整合 關鍵 Git 控制已移回審查流程，commit、push、branch、PR 建立與狀態查看等常用動作更接近工作區域。 執行緒面板改進 執行緒標頭現在能更乾淨地載入摘要、本地狀態、Git 上下文與來源等相關資訊與控制。 本地伺服器清單優化 清單新增更好的篩選、記住排序狀態、更清楚的空狀態顯示，並每 120 秒刷新未列出的連接埠。 效能大幅提升 針對大型儲存庫與活躍編碼階段，Codex 進行了多項效能調校： 切換執行緒時重繪減少約 75% 部分串流路徑降至零不必要重繪 大型儲存庫的昂貴 Git 操作降低 10–50 倍 串流、切換執行緒與側邊欄互動的 UI 抖動明顯減少 啟動與首次互動的可用時間更快 原文：https://easyvibecoding.app/curated/1377

Claude 官方已重置所有使用者的 5 小時與週期速率限制。 重置公告 Claude 官方在週五發布通知，宣布已將所有使用者的 5 小時與週期速率限制恢復為初始值，讓使用者可立即恢復正常使用。 影響範圍 本次重置涵蓋所有帳號，不分付費或免費方案，使用者無需手動操作即可享有全新配額。 原文：https://easyvibecoding.app/curated/1385

ChatGPT 推出個人財務功能。 OpenAI 正式開放 ChatGPT 的個人財務體驗預覽，目前僅限美國 ChatGPT Pro 使用者。使用者可透過 Plaid 連接銀行、信用卡、投資及貸款帳戶，涵蓋超過 12,000 家金融機構。連接後，ChatGPT 能顯示餘額、消費紀錄、投資表現、訂閱服務、即將到期的付款與負債資訊，但 OpenAI 強調無法取得完整帳號、執行轉帳或操作帳戶。 金融資料的存取與限制 支援 Plaid 連接的帳戶類型包含銀行、信用卡、投資與貸款。 ChatGPT 僅能讀取餘額、交易紀錄與財務摘要，無法取得完整帳號或執行任何金流操作。 使用者可隨時斷開連結，資料最長保留 30 天，並可選擇關閉模型訓練。 從報表到建議的流程轉變 傳統流程是使用者先登入銀行 App 查看報表，再自行分析與決策；現在 ChatGPT 直接理解資料並給出建議。OpenAI 預告未來將整合信用卡推薦、稅務估算、房貸分析、投資風險評估，甚至串接 Intuit 等生態，直接在 ChatGPT 內完成比較貸款、規劃現金流與安排報稅專家。 Financial Memory 與 Agent 整合 OpenAI 強調 ChatGPT 不只回答單一問題，而是記住使用者的收入、生活型態、目標與財務背景。這些資訊將以「Financial memories」形式保存，讓後續對話持續帶有上下文。這是 Memory、Agent 與真實金融資料首次正式合體。 GPT-5.5 的金融推理定位 OpenAI 指出財務問題需要長期上下文、多步推理、tradeoff 分析與風險評估，因此特別強調 GPT-5.5 Thinking 的 reasoning 能力。內部基準測試顯示 GPT-5.5 Thinking 得分 79/100，GPT-5.5 Pro 則達 82.5/100，並邀請 50 位以上金融專家進行評測。 高風險領域的隱私與法規挑戰 此功能涉及真實金流、隱私與投資建議，潛在法規責任極高。OpenAI 因此提供 MFA、Temporary Chat 不讀取財務資料、隨時斷開連結等機制，但社群反應兩極，Reddit 已有使用者直言「誰會把銀行資料給 OpenAI」。 ChatGPT 朝向個人作業系統的戰略 OpenAI 正將 ChatGPT 從搜尋與生產力工具，轉型為整合 Email、Calendar、Docs、Code、Memory、Finance、Shopping、Browser 與 Agent 的「個人作業系統」。金融是門檻最高的層級之一，若能突破，將代表 OpenAI 從 AI 工具跨向基礎生活介面。 對傳統 Fintech 的潛在衝擊 若 ChatGPT 成為使用者唯一入口，傳統金融服務可能被 commodity 化。Reddit 討論已指出，AI assistant 正在取代 dashboard，顯示 OpenAI 開始索取最高等級的真實世界資料，以打造真正的 personal AI。 原文：https://easyvibecoding.app/curated/1390

Codex 團隊已修正 GPT-5.5 效能下滑問題，並重置付費用戶使用額度。 Tibo 於 X 平台連續發文指出，Codex 團隊在過去約 48 小時內發現 GPT-5.5 對部分使用者表現下滑，已定位並修復兩項根本原因，目前正持續監控以確認修復成效。 事件起因 部分付費用戶回報 GPT-5.5 能力明顯下降 團隊確認系統整體健康，但效能確有退化 修復措施 定位並修復兩項導致效能下滑的問題 於當晚重置所有付費方案的使用額度 提醒使用者可立即使用 /fast 模式 後續進度 部分帳號重置未即時生效，團隊正排查傳播問題 將持續公布更新，確保週末使用順暢 原文：https://easyvibecoding.app/curated/1383

X 平台公開「For You」推薦演算法原始碼。 X 平台已將「For You」推薦系統的核心程式碼上傳至 GitHub，包含 Home Mixer、Thunder 與 Phoenix 三個主要元件，並提供可直接執行的推論管線。系統完全捨棄人工特徵工程，改由基於 Grok 的 transformer 模型從使用者互動歷史中學習相關性，同時整合網路內與網路外內容。 系統架構與管線流程 Home Mixer 作為協調層，依序執行查詢水合、候選來源、候選水合、過濾、評分、選取與後置過濾等階段。Thunder 負責即時擷取使用者追蹤帳號的貼文，Phoenix 則透過雙塔模型進行跨全域語料的相似度搜尋，再以 transformer 預測多種互動機率。 Phoenix 模型設計 Phoenix 包含兩個主要功能：Retrieval 階段使用 User Tower 與 Candidate Tower 產生嵌入向量，透過點積相似度找出候選貼文；Ranking 階段採用 Grok-based transformer，輸入使用者互動序列與候選貼文，並以特殊注意力遮罩確保候選之間無法互相注意，最後輸出 15 種互動機率。 多動作預測與加權評分 模型同時預測 P(favorite)、P(reply)、P(repost)、P(quote)、P(click)、P(video_view) 等多種動作，再由 Weighted Scorer 依權重加總得到最終分數。正向動作權重為正，負向動作（如 block、mute、report）權重為負，以降低使用者可能反感的內容。 過濾機制 Pre-Scoring Filters 包含 DropDuplicatesFilter、AgeFilter、SelfpostFilter、MutedKeywordFilter、AuthorSocialgraphFilter 等；Post-Selection Filters 則執行 VFFilter 與 DedupConversationFilter，移除已刪除、垃圾、暴力或重複對話的貼文。 關鍵設計決策 系統完全移除手動特徵工程，改由 transformer 從互動序列學習相關性；Ranking 階段採用 Candidate Isolation，使分數不受同批次其他候選影響；Retrieval 與 Ranking 皆使用多重雜湊函數產生嵌入；Candidate Pipeline 框架支援來源、Hydrator、Filter、Scorer 的平行執行與錯誤處理。 可執行推論管線 更新後提供單一入口 phoenix/run_pipeline.py，可直接從匯出的 checkpoint 執行 retrieval → ranking。另附 256 維、4 頭注意力、2 層 transformer 的迷你 Phoenix 模型（約 3 GB），以及 Grox 內容理解服務，用於垃圾郵件偵測、分類與政策執行。 授權與使用 本專案採用 Apache License 2.0，完整原始碼與模型權重已公開於 GitHub 儲存庫，供研究與開發者參考。 原文：https://easyvibecoding.app/curated/1389

Anthropic Claude API 推出 prompt caching 優化長提示延遲。 @ClaudeDevs 分享 prompt caching 技術，可預熱快取降低中長提示的 time-to-first-token 時間。先發送 system prompt 寫入 cache（無輸出生成），後續使用者請求即命中 warm cache，適用於 Zero Data Retention (ZDR) 組織，資料在 API 回應後不儲存。參考文件：prompt caching 預熱指南。 自動快取與明確斷點 自動快取透過頂層單一 cachecontrol 欄位啟用，系統自動套用至最後 cacheable block，適合多輪對話；明確斷點則在個別 content block 置 cachecontrol，提供精細控制。 自動快取 cURL 範例（文學分析）： `bash curl https://api.anthropic.com/v1/messages \ -H "content-type: application/json" \ -H "x-api-key: $ANTHROPICAPIKEY" \ -H "anthropic-version: 2023-06-01" \ -d '{ "model": "claude-opus-4-7", "max_tokens": 1024, "cache_control": {"type": "ephemeral"}, "system": "You are an AI assistant tasked with analyzing literary works. Your goal is to provide insightful commentary on themes, characters, and writing style.", "messages": [ { "role": "user", "content": "Analyze the major themes in Pride and Prejudice." } ] }' ` 自動快取 CLI 範例： `bash ant messages create --transform usage <<'YAML' model: claude-opus-4-7 max_tokens: 1024 cache_control: type: ephemeral system: >- You are an AI assistant tasked with analyzing literary works. Your goal is to provide insightful commentary on themes, characters, and writing style. messages: - role: user content: Analyze the major themes in Pride and Prejudice. YAML ` 自動快取 Python 範例： `python import anthropic client = anthropic.Anthropic() response = client.messages.create( model="claude-opus-4-7", max_tokens=1024, cache_control={"type": "ephemeral"}, system="You are an AI assistant tasked with analyzing literary works. Your goal is to provide insightful commentary on themes, characters, and writing style.", messages=[ { "role": "user", "content": "Analyze the major themes in 'Pride and Prejudice'.", } ], ) print(response.usage.modeldumpjson()) ` 自動快取 TypeScript 範例： `typescript import Anthropic from "@anthropic-ai/sdk"; const client = new Anthropic(); const response = await client.messages.create({ model: "claude-opus-4-7", max_tokens: 1024, cache_control: { type: "ephemeral" }, system: "You are an AI assistant tasked with analyzing literary works. Your goal is to provide insightful commentary on themes, characters, and writing style.", messages: [ { role: "user", content: "Analyze the major themes in 'Pride and Prejudice'." } ] }); console.log(response.usage); ` 工作流程：系統檢查提示前綴至 cache breakpoint 是否已快取，若命中則重用（降低時間與成本），否則處理全提示並快取前綴。預設 cache 存活 5 分鐘，每次使用免費刷新。快取完整前綴，包括 tools、system、messages 順序至指定 block。適用情境：多範例提示、大上下文、重複任務、長多輪對話。 多輪對話自動快取 cURL 範例： `bash curl https://api.anthropic.com/v1/messages \ -H "content-type: application/json" \ -H "x-api-key: $ANTHROPICAPIKEY" \ -H "anthropic-version: 2023-06-01" \ -d '{ "model": "claude-opus-4-7", "max_tokens": 1024, "cache_control": {"type": "ephemeral"}, "system": "You are a helpful assistant that remembers our conversation.", "messages": [ {"role": "user", "conte…

Codex 行動版預覽上線，讓使用者從手機隨時監督與引導開發工作。 OpenAI 推出 Codex 在 ChatGPT 行動裝置應用程式的預覽版，讓使用者從 iOS 和 Android 手機隨時連線至筆電、Mac mini 或遠端環境中的 Codex，檢視即時狀態、審核輸出、調整方向並批准下一步，維持工作連續性。目前已有超過 400 萬人每週使用 Codex，此功能強調小幅互動能避免重工並加速進度。 行動端完整體驗 Codex 在 ChatGPT 手機 app 提供完整功能，連線至運行 Codex 的機器後，即時載入執行緒、批准、plugin 和專案脈絡狀態。使用者可從手機處理所有執行緒、審核輸出、批准指令、變更模型或啟動新任務；檔案、憑證、權限與本地設定均保留在機器端，更新如螢幕截圖、終端輸出、差異檔、測試結果則即時同步至手機。 底層透過安全中繼層（secure relay layer）確保機器不直接暴露於公共網路，並同步會話狀態與脈絡至任何登入 ChatGPT 的裝置。 即時介入情境 隨著 Agent 處理長時間任務，及時引導變得關鍵，手機版 Codex 讓使用者在適當時機介入： 等咖啡時啟動 bug 調查：Codex 從開發環境檢查檔案、重現問題、執行測試並擬定修復；若需澄清或許可，從手機回應，追蹤截圖、終端輸出、測試結果與最終 diff。 通勤中決策重構任務：離開辦公室前指派重構，中途 Codex 提出兩種途徑，從手機審核權衡後選擇，抵達時任務已依方向推進。 客戶會議前準備：會議後發現 Slack、email、文件與工具中的支援問題，從手機指示 Codex 彙整最新更新、標記關鍵問題並準備簡報；新細節進來時可即時刷新。 捕捉靈感即行動：午餐、散步或聽講時，從手機啟動新執行緒或加入既有工作，讓任務在返回桌前開始成形。 企業環境整合 Remote SSH 現已正式上線，Codex 可直接連線企業遠端環境，利用其核准依賴、憑證、安全政策與運算資源；桌面 app 自動偵測 SSH 配置中的主機，讓使用者如本地般建立專案與執行緒。連線後，這些環境透過相同安全中繼基礎設施可在授權 ChatGPT 裝置存取，從桌面啟動、手機導向，無需綁定單一機器。 同時釋出多項企業更新： 程式化存取 token，從 ChatGPT workspace 設定發行範圍限定憑證，用於 CI 管道、發行工作流程與內部自動化（Enterprise 與 Business 方案）。 Hooks 正式上線，可掃描提示中的秘密、執行驗證器、記錄對話、建立記憶，或自訂特定程式庫與資料夾的 Codex 行為。 HIPAA 相容支援，限 ChatGPT Enterprise workspace 在本地環境（CLI、IDE、App）使用，讓醫療組織加速患者照護與營運流程。 推出細節與可用性 Codex 手機版預覽今日起在所有支援地區的 iOS 與 Android 推出，涵蓋 Free、Go 與付費方案；請更新 ChatGPT 手機 app 及 macOS 版 Codex app 體驗。Windows 版 Codex 手機連線支援即將上線。 Remote SSH 與 Hooks 適用所有方案；程式化存取 token 限 Enterprise 與 Business；HIPAA 相容僅限合格 ChatGPT Enterprise workspace 的本地環境使用。詳見 OpenAI 官方公告。 原文：https://easyvibecoding.app/curated/1362

Tavus 推出 Image-to-Replica 生成對話 AI 人物。 Image-to-Replica 是 Tavus 全新訓練路徑，擴大 AI 人物範圍至品牌吉祥物、歷史人物及 AI 生成角色，讓單張圖像取代傳統 30 秒影片錄製。 Image-to-Replica 的創新意義 臉部是 AI 人物的第一印象，在記憶、人格、感知或對話啟動前，即負責辨識、設定語調、建立信任並吸引使用者互動。過去，每個 Tavus AI 人物皆需約 30 秒說話與 30 秒聆聽的影片錄製，需適當燈光與使用者能坐上鏡頭，此法雖完美複製真人，但限縮於能錄製者，排除公眾人物（日程不允許）、已故親友、數十年居於標誌或繪本的品牌吉祥物、插圖角色，以及專為角色設計卻無實體的 AI 生成人物。Image-to-Replica 以單張圖像產生完整 Phoenix-4 AI 人物，大幅拓寬可行臉部類別。 解鎖的應用潛力 Image-to-Replica 建置於 Tavus 平台，該平台已支援逾 10 萬名開發者及 Amazon、Deloitte、EY、Mayo Clinic、CVS、Salesforce、Aetna、Wix 等全球領先企業，驅動即時 AI 員工、醫療接待 Agent、訓練教練體驗及每月數百萬次客戶互動對話。 此功能讓任何單張圖像臉部皆可觸及該平台： 圖像產生僅需數秒，便於迭代，且提供燈光、取景及創意方向的直接控制，優於單次錄製。 加速客戶啟用 銷售潛在客戶可在安排錄製前，從頭像快速生成 AI 人物，從對 Tavus 感興趣到擁有自家 AI 人物的流程，從數日壓縮至數分鐘。開發者評估 CVI 時，可在開發者入口直接生成首個 AI 人物，無需離開平台。 適用無法錄製的主體 公眾人物日程不允許工作室時間。 已故親友的紀念應用。 數十年居於標誌的人形品牌吉祥物。 這些先前無法觸及，如今僅需單張圖像即可實現。 動畫、風格化及 AI 生成角色 人形吉祥物可進行真實對話；插圖角色可成為即時回應問題的導師；專為特定角色設計的 AI 生成人物，可無實體即部署為 CVI 人物。此無限性最顯著於原本無法拍攝的臉部。 想像速度原型開發 開發醫療流程、教練 App 或角色扮演模擬者，無需自錄或招募人才測試人物。只需數秒生成替代人物，端到端驗證體驗，僅在應用證實價值後才投入完整影片訓練。先建後精煉。 技術實現細節 Image-to-Replica 是與影片訓練相同 /replicas 端點的新訓練路徑，使用 trainimageurl 及 voicename 取代 trainvideo_url。為獲最佳效果，圖像須類似人類臉部，讓模型正確辨識並生成連貫 AI 人物，包括真實照片、AI 生成肖像、插圖風格化人類角色及人形吉祥物皆適用。 流程熟悉：上傳圖像後，系統即時評分關鍵品質（清晰正面取景、均勻燈光、無遮擋、可辨識人類臉部）。若不足，系統提供具體可行動回饋，並有「Fix with AI」按鈕內嵌修復圖像，呈現修正版，讓使用者提交或重試，無需離開上傳流程。接著，系統使用運動控制影片擴散法，從靜態圖像合成自然訓練片段，動畫化為捕捉說話、聆聽及微動作的短片，維持自然度不妥協。此合成片段輸入相同 Phoenix-4 訓練管線，無平行管線、無獨立程式碼路徑，使用者端無需額外實作。 關鍵在於，圖像訓練的 AI 人物非低階，而是完整 Phoenix-4 複製品，具相同情感控制、主動聆聽、即時效能及 Raven-1 感知層。 影片 vs. 圖像訓練比較 Image-to-Replica 非取代影片訓練，而是第二入口，各有情境與權衡。 影片訓練：條件合適時，為模擬特定真人的最高保真途徑，捕捉個人表情、嘴部動作、思考時頭部角度及鏡頭個人特徵。若能存取該人並良好錄製，即為首選。 圖像訓練：最低摩擦途徑，適用速度、存取或主體類型使影片不切實際時。允許訓練前迭代燈光、取景及創意方向，優於單次錄製。兩途徑皆產即時 AI 人物，訓練時間相同，選擇在於輸入而非輸出階層。 存取方式 Image-to-Replica 已於 Tavus 平台全面上線： API：於相同 /replicas 端點上線，使用 trainimageurl 及 voice_name 參數。 開發者入口：圖像上傳流程上線，含「Fix with AI」按鈕修復失敗輸入。 CVI：圖像訓練 AI 人物作為人物無需特殊處理。 預生成檢查器：每張圖像提交自動執行。 詳見完整發佈文件：https://www.tavus.io/post/introducing-image-to-replica 。 超越臉部的願景 AI 人物不僅是臉部，更是觀看聆聽的感知系統、知曉何時說話等待的對話流程模型、即時反映情感的渲染引擎、保留上週對話的記憶，或經數週互動塑造的人格。臉部長期為建置最慢環節，智慧、記憶、人格無法啟動，直至有人坐上鏡頭。以 Image-to-Replica，第一步僅需數秒，讓感知、人格、對話、關係幾乎立即展開。 Tavus 旨在解決人類運算問題，展望與機器對話如友人或同事般自然，AI 夥伴、助理、同事普及，介面具人類感。Phoenix-4 帶來情感渲染存在感，Raven-1 賦予真正視聽，Sparrow-1 提供人類級時機。最近配對評估中，使用者在七項情感與對話保真度測量中偏好 Tavus AI 人物六項，每項對頭比較皆選 Tavus，僅 Tavus 在「是否偶爾忘記對話對象是 AI」的問題獲正分。Image-to-Replica 移除想像 AI 人物至實現的最後人工步驟，將可能 AI 人物從「誰能錄製」擴至「何種人類臉部可存於圖像」。 更多細節見文件。 （作者：Jesse Rowe，發佈日期：2026 年 5 月 14 日） 原文：https://easyvibecoding.app/curated/1351

Apple 培養 Intel 成先進製程供應商。 Apple 與 Intel 合作開案 18A-P 系列（採 Foveros 封裝），用於低階／舊款 iPhone、iPad 與 Mac 處理器，iPhone 訂單佔比約 80%，反映終端裝置銷售比重；投片規劃為 2026 年小量測試、2027 年放量、2028 年續增、2029 年衰退，Apple 同時評估 Intel 其他先進製程。 Apple 的供應策略轉變 Apple 在台積電先進製程供應緊張前即展開與 Intel 合作，意識到台積電資源將持續向 AI 傾斜，AI／HPC 與手機對台積電營收貢獻差距擴大，因此有系統培養 Intel 成為全產品線供應商。 同時開案三大產品線，投片比例與銷量相似，模擬驗證 Intel 未來全線供應可能性。 先用完整 18A-P 系列世代優化量產與協作流程，而非僅試投低風險訂單。 降低獨供風險、提升議價力，同時維持與台積電交易關係。 Intel 的戰略機會與挑戰 Intel 迎來史無前例機會，Apple 訂單涵蓋全產品線、規模龐大、需動態調整設計與生產節奏，為 Intel 晶圓代工業務練兵的近乎唯一完整機會。 2027 年生產良率目標穩定達 50‒60% 以上，量產時程與出貨規模仍未明朗，組裝端／EMS 未見規劃。 短期難戲劇扭轉 IFS 單季虧損，供貨比重受產能與良率限制。 Apple 高標準及 Intel 同時承接其他客戶訂單，放大再造先進製程業務難度；執行力、地緣政治與客戶避險決定能否兌現黃金窗口。 Intel 內部對 Apple 訂單喜憂參半，即便初期順利出貨，台積電仍佔 90% 以上供應比重。 台積電的被動處境與結構性限制 台積電數年內無虞，但領先地位成為各方風險對沖焦點，Apple 尋求 Intel 合作提升議價力，並非孤例：美國政府透過半導體政策、Samsung 用記憶體利潤支持先進製程投入。 台積電主要靠卓越執行力應對，等同押注「執行力持續領先」假設。 對沖工具有限：地緣政治上，美國為關鍵市場與技術夥伴卻是最大政策壓力來源，中國、歐盟、日本無法有效對沖。 市場策略邊際效用遞減：業務多元化、客戶結構分散、技術授權、供應鏈本土化因領先地位而效果降低。 台積電的務實應對建議 加速累積內部資本最務實，來自先進製程定價權，不只合理利潤，也需對未來風險定價，採取更彈性定價策略。 Intel 將自家產品下單台積電以空出產能給 Apple 練兵，此非一般訂單，而是帶來潛在競爭風險。 台積電應將地緣政治與客戶組合重構衍生的競爭關係，納入風險定價與產能配置考量。 原文：https://easyvibecoding.app/curated/1357

Anthropic 發布論文警告美國強化中國 AI 競爭。 Anthropic 於 2026 年 5 月 14 日發布論文《2028: Two scenarios for global AI leadership》，闡述美國與中國在人工智慧領導權的競爭觀點。論文強調，美國及其民主盟友目前領先，但若不立即行動，中共可能透過規避出口管制與蒸餾攻擊追平並超越，導致威權政權主導 AI 規範與應用。 美國當前優勢與中共威脅 美國與民主盟友在前沿 AI（frontier AI）領域領先，主要得益於先進電腦晶片（compute）的控制權。美國公司開發最強大晶片，美國政府透過嚴格出口管制限制中國供應，此舉歷史上極為成功。中國 AI 實驗室僅能建構接近美國水準的模型，全賴其世界級人才、規避出口管制的漏洞，以及大規模蒸餾攻擊（distillation attacks），後者非法竊取美國公司模型創新以模仿其能力。 中共已將 AI 用於審查言論、鎮壓異議者、駭入全球政府與企業，以及強化人民解放軍（PLA）。論文聚焦中共，因其最能利用前沿 AI 鞏固威權主義，並非針對中國人民的興趣或才智。中國實驗室受 compute 限制，若無漏洞與攻擊，其能力將落後更多。 2028 年兩種情境 論文預測 2028 年轉型 AI 系統到來，呈現兩個情境： 第一情境：美國成功守住優勢 政策制定者進一步收緊出口管制、破壞中國蒸餾攻擊，並加速民主國家 AI 採用。此時民主國家主導 AI 規則與規範，最可能成功與中國就安全議題互動（Anthropic 支持此舉，若可行）。美國將鎖定 12-24 個月前沿能力領先，此領先極為有利，並強化與中國 AI 專家在安全與治理的合作。 第二情境：美國未採行動 政策制定者未堵塞中共 compute 漏洞，中國 AI 公司迅速追平並超越前沿。此時威權政權塑造 AI 規範，最佳模型助長大規模自動鎮壓。即使中共勝利建立在美國 compute 基礎上，亦無慰藉。 維持領先的關鍵行動 AI 能力正加速擴張，compute 供應激增，且 AI increasingly 用於訓練新模型，「天才數據中心國家」（country of geniuses in a data center）等轉型智慧水準近在咫尺。此加速使政策行動迫在眉睫。目前允許出口規避與蒸餾攻擊，讓中共緊跟前沿曲線；若美國與盟友立即處理，可鎖定 12-24 個月領先，但機會視窗不會永遠敞開。 美國從強勢出發，其創新生態建構 AI 主宰工具，現任任務是避免浪費優勢，即不讓中共更容易追上。民主國家而非威權政權，必須領導 AI 開發與部署，以塑造治理系統的規則與規範。 政策建議與政治支持 論文呼籲建構現有領先：收緊對中國實驗室先進 compute 管制、破壞其美國最佳模型蒸餾努力，並加速民主 AI 採用。國會與川普政府許多成員已倡導出口管制、遏止蒸餾攻擊及輸出美國 AI。Anthropic 樂觀，透過這些政策，民主國家可於 2028 年確保壓倒性領先，避免兩年後與中共的危險並駕齊驅競爭。 論文詳見 Anthropic 研究頁面 。此觀點忠實反映 Anthropic 的立場：美國優勢來自創新與管制，但需警惕中共利用漏洞，否則將釀成全球安全危機。 原文：https://easyvibecoding.app/curated/1363

Kimi WebBridge 讓 AI Agent 操作瀏覽器。 Kimi.ai 推出「Kimi WebBridge」瀏覽器擴充功能，讓 AI Agent 能像人類一樣開啟網頁、搜尋、滾動、點擊、輸入並完成任務，支援 Kimi Code CLI、Claude Code、Cursor、Codex、Hermes 等工具，目前可在 kimi.com/features/webbridge 及 Chrome Web Store 下載。 核心功能 Agent 可跨多平台大規模搜尋，並自動填入試算表結果。 透過 K2.6 的多模態能力，Agent 能開啟網站、導航並完整複製其內容。 Agent 學習使用者日常工作流程，並轉化為可重複使用的技能。 使用者僅需聊天，即可讓 Agent 自動透過瀏覽器建立完整 Google 表單，包括輸入與建置問卷。 技術支援與相容性 支援 Kimi Code CLI、Claude Code、Cursor、Codex、Hermes 等多種程式開發工具，讓 Agent 執行如真人般的網頁互動，包括開啟頁面、點擊、填寫表單、提取資訊及自動化繁瑣任務。 隱私與資料處理 Kimi WebBridge 會處理網頁瀏覽記錄（Web history）、使用者活動（User activity）及網站內容（Website content）。開發者聲明不將資料出售給第三方、不用於與核心功能無關的目的、不用於評估信用或貸款用途，詳細隱私政策見開發者文件。上架日期為 2026 年 5 月 11 日，來源自 Chrome Web Store。 原文：https://easyvibecoding.app/curated/1346

VS Code 推出 Agents 視窗支援 Agentic 開發。 Visual Studio Code（VS Code）傳統編輯器布局優化單任務、單 workspace 工作流程，但已被數百萬開發者用於 Agentic 程式開發；今日正式在 VS Code 安定版推出全新「Agents」視窗，讓使用者（包含 VS Code 團隊自身）能跨多專案、多 Agent 協作。 工作流程演進 VS Code 團隊一年內的工作流程從追蹤 Agent 具體軌跡（如工具呼叫與程式碼編輯）轉變為高階夥伴關係：團隊花費大量時間微觀監督 Agent 動作，如今轉向透過「Plan mode」等功能建構模型對齊，並優先審核結果而非程式碼。 擴展 Agent HQ 願景 「Agents」視窗不僅提供頂尖模型選擇，還整合 harness，讓使用者試用 Claude Agent 整合，全由 GitHub Copilot 訂閱驅動。試用 Claude Agent 。 遠端開發支援 視窗支援遠端開發，可連線執行於遠端主機（如雲端沙盒）的程式開發 Agent，讓工作無處不可續。 瀏覽器與行動端體驗 全新 http://vscode.dev/agents 體驗，讓使用者在瀏覽器（包含行動裝置）中與程式開發 Agent 工作，實現隨處開發。 原文：https://easyvibecoding.app/curated/1360

Anthropic 推出「Claude for Small Business」，定位為全球最廉價高效員工，專攻中小企業自動化。 Anthropic 於 2026 年 5 月 13 日發布「Claude for Small Business」，這套工具整合現有軟體，提供即用型 Agentic 工作流程，幫助中小企業主處理日常瑣務。作者 Nico 強調，這不僅是聊天機器人，而是旨在成為數百萬中小企業的「作業系統」，取代開啟 10 種不同工具的麻煩，讓使用者直接對 Claude 發話即可完成工作。 企業採用數據領先 OpenAI Anthropic 首次超越 OpenAI 在企業採用率： Anthropic：34.4% OpenAI：32.3% Anthropic 的採用率在 12 個月內成長 4 倍，而 OpenAI 幾乎停滯不前。雖然 ChatGPT 仍主宰消費者市場，但 Claude 已迅速成為企業首選，作者質疑這是否預示 AI 領導地位轉移。時機並非偶然，此發布正值 Anthropic 企業採用衝刺之際。 核心功能與工作流程 「Claude for Small Business」內建 15 種即用 Agentic 工作流程，涵蓋財務、營運、銷售、行銷、HR 及客戶服務，並附 15 項技能，針對中小企業主常見瓶頸： 薪資規劃：透過 Intuit QuickBooks 對帳 PayPal 入帳，建立 30 天預測、排序逾期項目，並排隊提醒待使用者核准。 月結作業：對帳結算、標記不符項目、撰寫簡明 P&L 報表，並匯出封包直接轉交會計師。 業務脈動監控：定期彙整關鍵洞察單頁顯示，包括 QuickBooks 現金部位、銷售趨勢、銷售漏斗移動、本週承諾等。 行銷活動執行：找出營收低谷、分析 HubSpot 活動表現、起草促銷策略，並在 Canva 生成資產準備發送。 其他包括發票追蹤器、利潤分析器、月結準備器、稅季整理器、合約審核器、潛客分類器、內容策略師等。 中小企業貢獻美國 GDP 44%、僱用近半私部門勞力，但 AI 採用落後大企業，此工具旨在彌補差距。 工具整合與運作方式 透過「Claude Cowork」啟用開關，連接既有工具後選擇任務，Claude 執行工作，使用者先核准再發送、張貼或付款。各工具分工明確： PayPal：處理結算、發票、爭議、退款。 Intuit QuickBooks：薪資規劃、月結、現金流、稅季準備、跨系統對帳。 HubSpot：潛客分類、客戶脈動、活動歸因。 Canva：多管道內容生成、團隊協作編輯、發布資產、效能追蹤。 DocuSign：發送合約簽署、追蹤狀態、歸檔執行副本。 另支援 Google Workspace、Microsoft 365。 Anthropic 聲稱這不是「另一個聊天機器人」，而是理解整個業務脈絡、自動執行跨應用工作流程的系統，包含預設自動化。 信任與安全設計 調查顯示，半數中小企業主視資料安全為 AI 最大疑慮。「Claude for Small Business」因應此點： 使用者全程掌控：每項任務由使用者啟動，先核准計劃，或選擇端到端執行。 權限不變：員工若無法在 QuickBooks 或 Drive 存取，即無法透過 Claude 存取。 Team 及 Enterprise 方案預設不以使用者資料訓練模型。 Anthropic 總裁 Daniela Amodei 表示：「中小企業佔美國經濟近半，卻無大企業資源，AI 是首項能彌補差距的技術。我們讓 Claude 嵌入 QuickBooks、PayPal、HubSpot 等工具，接手深夜堆積工作，如薪資規劃、追發票或啟動行銷專案，讓人專注經營業務。」 配套教育與推廣活動 工具外，Anthropic 與 PayPal 合作推出免費線上課程「AI Fluency for Small Business」，由實際使用者如 Prospect Butcher Co.（Brooklyn）、MAKS TIPM Rebuilders（California）等授課，涵蓋 AI 安全、責任、倫理應用，以及辨識適合任務並入門步驟。 另有「Claude SMB Tour」，自 2026 年 5 月 14 日芝加哥起跑，免費半日實作工作坊，每站限 100 名當地中小企業領袖，由 Anthropic 及 Tenex.co 主辦，搭配在地夥伴，參與者獲一個月「Claude Max」訂閱。 使命導向夥伴關係 作為公共利益公司，Anthropic 投資中小企業導向非營利組織夥伴，將 Claude 直接交給企業主及支援機構，確保 AI 益處觸及歷史上技術落後族群。啟用方式請參考 Anthropic 官方頁面。作者 Nico 看好此舉將顛覆中小企業運作，挑戰 OpenAI 霸權。 原文：https://easyvibecoding.app/curated/1343

Visual Studio Code 1.120 版本穩定推出 Agents 視窗，提升 BYOK 模型控制並強化 Agent 安全功能。 Visual Studio Code 1.120 於 2026 年 5 月 13 日發布，此版本將 Agents 視窗移至穩定版，改善 BYOK 模型的 token 使用追蹤與思考努力度配置，並新增 Markdown diff 預覽與終端機指令風險評估等功能，針對 Agent 驅動開發優化多專案工作流程。 Agents 視窗穩定版 Agents 視窗現為穩定版，專為跨多專案的 Agent 驅動開發設計，作為既有編輯器的伴侶視窗，提供專屬空間用於探索、迭代與審核任務，並無縫切換專案。使用者可選擇 agent harness、在遠端機器執行 Agent，並自訂環境，包括色彩主題、按鍵綁定與擴充功能。此視窗先前於 VS Code Insiders 測試，現移至穩定版預覽。 開啟方式包括標題列的「Open in Agents」按鈕，詳情見 Agents 視窗文件。 基於 Insiders 回饋的新功能： 偏好設定跨工作階段持續：代理 harness 與隔離模式等下拉選單的最後選擇會保留。 輕鬆捨棄變更：直接從 Changes 面板捨棄編輯。 新工作階段同步上游變更：Files 面板的同步按鈕可拉取基底分支的上游變更，讓 Agent 開始前更新。 變更互動更確定性：Changes 面板動作更快且確定性更高。 完成工作階段預設顯示所有變更：開啟標記為完成的會話時，自動檢視 Agent 完整編輯集。 導航近期工作階段：標題列左上箭頭按鈕可在不離開視窗下跳轉近期會話。 視窗專屬設定覆寫：Agents 視窗共享所有 VS Code 設定，可針對此視窗覆寫特定行為。 團隊呼籲回饋，請在 GitHub 提交 issue 或瀏覽既有問題。 擴充功能相容性 僅貢獻靜態內容的擴充（如主題、文法、語言、按鍵綁定）會自動在 Agents 視窗啟用。測試過 Marketplace 前 100 名擴充，部分若安裝於預設 VS Code 設定檔也會啟用。 其他擴充可透過 extensions.supportAgentsWindow 設定以 ID 選擇性啟用，需安裝於預設設定檔。團隊正開發更廣泛擴充支援，並邀請擴充作者透過 GitHub issue 合作，探討跨專案 Agent 情境與擴充行為。 Copilot CLI plugin 自動發現 透過 GitHub Copilot CLI 安裝的 Agent plugin，VS Code 會自動偵測，單一安裝即涵蓋 CLI 與 VS Code 表面，先前需額外安裝或加入 chat.plugins.paths。 BYOK 模型改進 BYOK（Bring Your Own Key）允許使用自有 API 金鑰（如 Anthropic、OpenAI），支援自訂計費或模型託管。 token 使用可見度：Chat 視圖的 context window 控制項現顯示 BYOK 模型的精準 token 使用量與滿載百分比，先前總顯示 0%，僅內建模型有效。 思考努力度配置：針對 BYOK 推理模型，從 Chat 視圖模型選擇器直接設定「thinking effort」，權衡回應品質與速度/成本，每請求皆傳遞設定。適用 OpenAI 相容端點（OpenAI、xAI (Grok)、OpenRouter、自訂 OpenAI / Azure OpenAI），Anthropic 已支援，今統一介面。詳見 thinking effort 文件。 模型選擇器依提供者組織：Chat 視圖模型選擇器按提供者分組，便於多來源搜尋；近期使用模型顯示灰色提供者名稱，避免同名混淆。提示：聊天輸入 /models 快速存取。 聊天與工具安全功能 終端機工具輸出壓縮（預覽）：啟用 chat.tools.compressOutput.enabled 設定，VS Code 後處理如 git diff、ls -l、npm install 等長輸出前送至模型。壓縮包括折疊 diff 不變區塊、捨棄 lockfile/snapshot diff、簡化 ls -l 為項目名、移除 npm install 進度條/棄用警告/審核摘要。壓縮輸出前置橫幅，告知模型套用過濾器與停用方式。 終端機指令風險評估（實驗）：啟用 chat.tools.riskAssessment.enabled，終端機指令確認新增風險徽章與 AI 生成單句說明，分三級： - Safe（綠）：僅讀取檔案或輸出，不改動。 - Caution（橘）：修改 workspace、安裝套件或網路傳輸。 - Review carefully（紅）：難以或無法復原動作，如強制推送到遠端或刪除 workspace 外檔案。 Claude 與 Copilot CLI 計劃模式控制：啟用 chat.planWidget.inlineEditor.enabled，內嵌計劃編輯器取代獨立分頁，提升迭代效率；回饋模式顯示更清晰指示與累計回饋；可停用內嵌編輯，回退傳統分頁。 Markdown 改進 diff 預覽（預覽）：從 Source Control 開啟 Markdown 檔案時，可用渲染預覽取代原始碼，便於辨識標題更新、新區段、圖片變更或清單重組。支援並排與內嵌 diff。操作：從 Source Control 或 diff 編輯器用「Reopen Editor With...」切換，或用 workbench.diffEditorAssociations 預設啟用。 預設變更：停用舊功能： - markdown.preview.doubleClickToSwitchToEditor：預覽雙擊切換編輯器，常被誤用於選取，今由「Reopen With」取代。 - markdown.preview.markEditorSelection：標記編輯器選取行，對現代工作流程較不實用。 可手動重新啟用。 HTML id 支援：Markdown 路徑自動完成與連結驗證現辨識 HTML 元素 id。 表格智慧選取：支援 Expand Selection（⌃⇧⌘→）從儲存格擴至列再至表格，Shrink Selection（⌃⇧⌘←）反向。 擬議 API 自訂編輯器 diff：customEditorDiffs API 讓自訂編輯器渲染專屬 diff UI，如 Markdown diff 預覽。提供： - resolveCustomEditorInlineDiff(documents, webviewPanel, token)：單 webview 渲染原/修改文件。 - resolveCustomEditorSideBySideDiff(documents, webviewPanels, token)：雙 webview，並排同步。 結合 diffEditorPriority，擴充全控 diff 呈現。 diff 與合併優先權分離：customEditors 貢獻新增 diffEditorPriority 與 mergeEditorPriority。 文件 diff：workspace.getTextDiff(original, modified, options?) 暴露內建 diff 演算法，返回逐行變更串流與摘要（identical、may-be-incomplete、移動偵測），含內部字元範圍，利於自訂 diff 編輯器。 GitHub Pull Requests 擴充更新 0.144.0 版新增： 複製/貼上與上傳按鈕將圖片上傳至 PR 評論。 切換 worktree 時更描述性資料夾名稱。 "githubIssues.issueBranchTitle" 支援 ${issueType} 範本變數。 詳見變更記錄。 棄用與修復 無新棄用或即將棄用提及。值得注意修復：#314545 整合瀏覽器 localhost 目標包含 All-Interfaces 連結。 貢獻者感謝 問題追蹤貢獻：@gjsjohnmurray (John Murray)、@RedCMD (RedCMD)、@IllusionMH (Andrii Dieiev)、@albertosantini (Alberto Santini)。 VS Code 貢獻： @damonxue (DamonXue)：PR #315197 修正右鍵非活躍編輯器分頁「Add File to Chat」無效。 @davidwengier (David Wengier)：PR #313011 更新 Razor repo 儲存庫與路徑。 @Dmitriusan：PR #300613 修正 gitignore 子檔案否定未覆寫父/全域規則。 @EhabY (Ehab Younes)：PR #310131 透過 keepalive 逾時偵測斷線。 @JeffreyCA：PR #308613 更新 Azure Developer CLI (azd) Fig 規格；PR #309539 修正終端 OSC 8 連結懸停提示。 @kevin-m-kent：PR #314309 回應事件與子 Agent 迴圈發送 parentRequest…

AI Gateway 生產環境指標 詢問哪一個 AI 模型最好，答案往往在墨水乾掉之前就變了。這就是一個每週都有新模型發布的產業中會發生的事。 每一個基準測試（benchmark）都在衡量不同的賽道，每一場賽道也都會產生各自的贏家，但 Vercel 透過生產環境的工作負載，對這個產業有著獨特的觀察。AI Gateway 透過真實的應用程式與 Agent，為數百個模型處理了數十兆的 token。 以下是我們的觀察： 儘管單位價格較高，Anthropic 在支出方面仍處於領先地位，而 Google 則在流量規模上領先。 開源模型（OSS models）正逐漸獲得採用，但使用者對特定實驗室並沒有忠誠度。 在近期模型更新後，OpenAI 的支出份額正在快速成長。 高流量的工作負載平均會路由（route）到 30 個以上的不同模型。 Agentic 程式開發的工作負載佔了所有 token 流量的 59%（在 6 個月內成長了 2 倍）。 本報告基於 AI Gateway 七個月的生產環境流量資料，涵蓋超過 20 萬個獨立團隊的使用情況。 Anthropic 在支出領先；Google 在流量領先 成本與流量的排名之所以不同，是因為它們衡量的是兩種不同的工作負載，即便對於同一個客戶也是如此。 以 2026 年 4 月的支出來看，Anthropic 佔了 61%，Google 佔 21%，OpenAI 佔 12%。 若以 token 流量來看，情況則完全翻轉。4 月份透過 AI Gateway 的流量中，38% 路由至 Google，26% 至 Anthropic，13% 至 OpenAI，10% 至 xAI。其餘份額則由較小的實驗室瓜分。 有些模型透過足夠便宜的單一 token 價格來承載巨大流量，而另一些模型的定價則較高，僅在品質至關重要的任務中才具備合理性。這些不同的模型並非在爭奪同一個呼叫（call）。總體而言，同一個客戶群同時出現在兩個排行榜上，高階推理呼叫會使用 Claude Opus，而廉價且快速的呼叫則使用 Gemini Flash。支出跟隨高風險的呼叫，而流量則跟隨低風險的呼叫，各個實驗室在同一個應用程式中佔據了不同的層級。 流量與支出的比例在實驗室層級也會快速變化。以下是幾個具體訊號： Gemini Flash 幫助 Google 以較低的支出份額取得了流量領先。 Claude Opus 幫助 Anthropic 以比 Google 更少的流量取得了支出領先。 在 GPT-5.4/5.5 發布後，OpenAI 的支出份額從 3 月到 4 月成長了三倍。 隨著 Gemini Flash 的使用規模擴大，Google 的支出份額從 3 月的 8% 攀升至 4 月的 21%。 支出跟隨「出錯的代價」 同樣的成本與流量分歧，在特定類型的工作負載內部也以更細緻的方式存在： 個人助理佔成本的 20%，但佔 token 流量的 40%。 程式撰寫 Agent 在成本與 token 佔比上大致平衡，分別為 22% 與 20%。 後勤（Back office）Agent 佔成本的 6%，但佔 token 的 15%。 應用程式生成佔成本的 7%，佔 token 的 11%。 工作負載在每個 token 上的支出，取決於該使用情境下「錯誤答案」的代價有多高。個人助理可以使用廉價、快速的模型，因為錯誤只會影響個別使用者，且能被快速修正。後勤工作流程則會為更強大的推理能力付費，因為錯誤可能會引發法律、財務或營運風險，這些風險遠大於單次呼叫節省下來的成本。每個 token 的經濟效益是一張風險地圖：當錯誤代價越高時，應用程式在每個 token 上的支出就越多。 同樣的模式也存在於更廣泛的 B2C 與 B2B 劃分中。B2C 應用程式產生許多低成本的呼叫，而 B2B 應用程式則執行較少、但更昂貴的呼叫。以每個 token 為基準，B2B 的成本大約是 B2C 的兩倍。 沒有單一供應商能贏下所有使用情境 將資料依據使用情境進行切割，顯示出一個碎片化的供應商格局： Anthropic 在軟體開發領域顯著領先。 Google 在消費者應用領域表現突出。 OpenAI 的分佈最為平均。 xAI 與其他廠商則分散在程式撰寫、消費者應用與長尾使用情境中。 Anthropic 的模式是集中在高風險層級。隨著工作負載從後勤轉向消費者應用，Anthropic 的 token 份額從 71% 下降到 7%。其成本份額的曲線則平緩許多，並在四個類別中的三個保持領先。無論有多少流量通過，營收總是集中在「答案必須正確」的地方。 Google 的情況則呈現相反的形狀。其足跡集中在消費者應用領域，Gemini Flash 在該領域以 15% 的成本承載了 28% 的 token，而在該領域之外的成本圖表中幾乎看不到它的蹤影。這種定位是一場單一產品（SKU）的賭注，隨著 Flash 的採用率起伏。 xAI 則是一個價格楔子。Grok 在程式撰寫中承載了 20% 的 token，在推廣應用中承載了 18% 的 token，但其成本份額在各個領域都顯著較低。xAI 在「價格與品質的契合度」上勝出，而任何能匹配此價格的對手都會縮小這個楔子。 OpenAI 是這四者中最平衡的，在程式撰寫成本佔 6%、消費者應用成本佔 18%、推廣應用成本佔 28%。沒有任何單一層級是 OpenAI 整體份額的支柱，這使得該公司在面對任何單一層級的破壞時，受到的衝擊最小。 像 Kimi、MiniMax 與 GLM 這類開放權重（Open-weights）家族，在成本上限最低的消費者與程式撰寫層級中輪替。它們的成本份額保持在低檔，但它們在消費者與程式撰寫內部的 token 份額卻大到足以讓任何僅從成本角度觀察市場的人低估它們的影響力。 應用程式正變得越來越 Agentic 在所有這些現象之下，生產環境 AI 請求的形態已經改變。在 2026 年 4 月，22.2% 的 AI Gateway 請求以 tool call 結束，高於 2025 年 10 月的 11.4%。若以 token 來衡量，這種轉變更為巨大。現在有 58.9% 的 token 來自於包含 tool call 的請求，高於六個月前的 31.6%。 從這兩個指標來看，Agentic 的份額在半年內大約翻了一倍，但更具指標性的數字是這兩個份額之間的差距。22.2% 的請求承載了 58.9% 的 token，這意味著使用 tool 的請求在 token 消耗上大約是其他請求的 2.6 倍。AI 的成本面貌已從「聊天型」轉向「Agent 型」，而總請求數卻幾乎沒有變動。 每一種往返呼叫（round trip）都會根據同一個計量標準收費，無論是函式執行、API 呼叫、資料庫查詢還是程式執行，因此一個發出十次 tool call 的 Agent，其收費的 token 大約是聊天的十倍。聊天模式在每個 prompt 下只會產生一次往返呼叫，而 Agent 則會產生一個鏈（chain）。 排行榜只會排名單一模型，但生產環境團隊大規模使用 35 種以上模型 在大規模應用下，多模型（multi-model）不再是一種選擇，而是標準的 Agent 架構。 執行 1,000 到 10,000 次請求的團隊平均使用 3 種不同的模型。到了 1,000 萬次以上請求的區間，平均使用量達到 35 種模型。從 100 萬至 1,000 萬區間的 18 種模型，跳升至 1,000 萬以上的 35 種模型，這就是關鍵的轉折點。 一個擁有 35 種模型的機隊（fleet）會以路由圖（routing graph）的形式運作：使用廉價的分類器進行意圖偵測、使用前沿模型進行推理步驟、使用 embedding 模型進行檢索、使用快速模型進行摘要，以及使用視覺模型進行螢幕截圖分析。這些模型中的每一個都是可替換的。如果供應商漲價、品質下降或發生中斷，流量會在幾小時內重新分配到其他模型上。在產生排行榜大部分支出的規模下，在實驗室之間切換更像是配置變更，而非供應商遷移；隨著請求流量曲線的上升，關於「實驗室綁定」的傳統說法反而被顛覆了。 新模型被迅速採用 同樣的機隊設計解釋了新版本發布後被吸收的速度有多快。當一個模型家族發布新版本時，流量會在幾週內轉移過去。 Claude Sonnet 4.6 在發布後的第一個完整月份，就吸收了 Sonnet 家族大部分的份額。 Opus 家族現在也正經歷同樣的過程，Claude Opus 4.7 正以幾乎相同的曲線從 Opus 4.6 手中搶佔份額。 在上述兩個時間窗口中，舊版模型在 AI Gateway 上依然保持在線且可路由，但團隊還是選擇了遷移。這種遷移只是一次配置變更，實驗室已不再能決定其自身產品線的升級時間表。 供應商中斷有隱形成本 在 AI Gateway 上，大約有 3.5% 的請求是在觸發備援（fallback）後完成的。這意味著初始路由遇到了錯誤、速率限制或逾時，而 Gateway 在足夠短的時間內將請求重新發送到健康的替代方案，讓使用者依然獲得了成功的響應。 以 token 計算，救援率為 5.1%；以金額計…

Agentic AI 經濟入門指南 2025 年 11 月的一個週五晚上，Peter Steinberger 打造了 OpenClaw 的第一個版本。 這個原型只花了大約一小時，然而在幾週內，OpenClaw 就突破了 145,000 個 GitHub 星數，成為 GitHub 歷史上成長最快的開源軟體專案。 這個平台很大程度上是由 AI Agent 所建構的，它標誌著從聊天機器人轉向自主、以任務為導向的 AI 之轉變。 而且這種轉變正在加速。目前 Google 有 75% 的新程式碼是由 AI 生成的，微軟則高達 30%。2026 年初，GitHub 上每日的 Claude Code 提交量超過了 134,000 次，而 2025 年 3 月剛推出時幾乎為零。 這是在軟體開發，以及日益增加的知識工作執行方式上的一種結構性變革。 AI Agent 正處於這場變革的最前線。 那麼，AI Agent 究竟是什麼？它與聊天機器人或 LLM 有何不同？是什麼讓這種轉變成為結構性的，而非曇花一現？隨著技術堆疊（stack）逐漸成熟，價值會積累在哪裡，又在哪裡會變得平庸化（commoditize）？ 這些就是我們試圖回答的問題。 最終，我們提出了一個五層框架，用以說明 Agent 的本質、技術的發展方向，以及誰在每一層中佔據優勢。 部分答案已經顯現在數據中。Anthropic 在十七個月內，年化營收從 10 億美元成長到 440 億美元，幾乎完全歸功於程式撰寫 Agent。與此同時，開源的 Agent harness 每月處理的 token 數量已達數十兆。這兩個數字似乎都指向同一個地方：harness 層。 但 Agent 仍然經常犯下明顯的錯誤。2025 年 12 月，一個 Amazon 的程式撰寫 Agent 自主刪除並重建了一個線上生產環境，導致 AWS 在中國的服務離線了 13 個小時。2026 年 4 月，一個由 Claude 驅動的 Cursor Agent 在 9 秒內刪除了整間公司的資料庫。 生產環境中反覆出現四種故障模式，而大多數廠商的定價表上從未提及這些風險。 麥肯錫（McKinsey）2025 年的 AI 現狀調查發現，不到 10% 的組織在有意義的規模上部署了 Agent。大多數組織根本還沒開始使用它們。 技術上的可能性與實際營運部署之間的差距，就是機會所在。 我們在 Substack 上發布的這份 84 頁入門指南，旨在為大家提供一張地圖。以下是你會在其中發現的內容： Agent 的五個層級，以及它們如何相互配合 六個關於早期採用者如何部署 Agent 的案例研究，包括我的公司 8090 Agent 在生產環境中可靠地崩潰的四種方式 當模型變得平庸化時，我們預期最能積累持久價值的層級 誰有能力掌控這五個層級中的每一層 訂閱以閱讀全文，並在群組中告訴我你的想法：https://chamath.substack.com/p/ai-agents-primer 原文：https://easyvibecoding.app/curated/1333

Anthropic 宣布 Claude Code 每週使用限制提升 50%，持續至 7 月 14 日。 Claude Code 每週限制提升 50%，持續至 7 月 14 日。 適用範圍 涵蓋所有 Claude Code 使用情境，包括 CLI、IDE 擴充套件、桌面應用及網頁版。無需使用者手動啟用，已自動套用至帳號，適用於所有 Pro、Max、Team 及 seat-based Enterprise 使用者，已即時生效至 7 月 14 日上午 9 時（台灣時間）。 額外優惠 與上週公布的 5 小時限制提升 2 倍疊加，提供更長持續使用時間。 開發者期待 Anthropic 熱切期待使用者在此期間打造的各種專案。 原文：https://easyvibecoding.app/curated/1345

Claude付費方案提供專屬Agent SDK信用額度。程式化使用將獨立於互動限制，避免影響 Claude Code 和聊天體驗。 Claude 訂閱方案（Pro、Max、Team、Enterprise）使用者可領取每月 Agent SDK 信用額度，專供 Claude Agent SDK、claude -p 指令及第三方應用使用。此變更確保訂閱限制僅保留給互動功能，如 Claude Code、Claude Cowork 和 Claude 聊天，從 2026 年 6 月 15 日生效，使用 Claude Developer Platform 的 API 金鑰帳戶則維持按使用量計費，不享有信用額度。 信用額度適用範圍 信用額度涵蓋以下程式化使用： Claude Agent SDK 在使用者專案中的應用（Python 或 TypeScript） Claude Code 中的 claude -p 指令（非互動模式） Claude Code GitHub Actions 整合 透過 Agent SDK 驗證 Claude 訂閱的第三方應用（如 Conductor 和 OpenClaw） 不適用項目包括： 終端機或 IDE 中的互動 Claude Code 網頁、桌面或行動裝置端的 Claude 對話 Claude Cowork 其他額外使用功能的消耗 每月信用額度明細 不同方案的信用額度如下（每座位計算，Enterprise 依座位類型而異）： | 方案 | 每月信用額度 | |-----------------------|------------------| | Pro | $20 | | Max 5x | $100 | | Max 20x | $200 | | Team Standard 座位 | $20 | | Team Premium 座位 | $100 | | Enterprise（使用量基礎）| $20 | | Enterprise（座位基礎 Premium 座位）| $200 | 注意：Enterprise 座位基礎 Standard 座位使用者不符合資格。信用額度不滾存，每個計費週期重置。 運作機制 使用者透過 Claude 帳戶一次性領取信用額度，之後每計費週期自動重置。 Agent SDK 使用優先從信用額度扣除。 信用額度耗盡後，若啟用額外使用，將按標準 API 費率計費；若未啟用，則請求暫停直至下個週期重置。 信用額度為個人帳戶專屬，不可跨使用者分享或彙整。 不變項目 此變更不影響既有機制： 訂閱方案的使用限制維持不變，專供互動使用。 終端機或 IDE 中的互動 Claude Code 繼續使用訂閱限制。 網頁、桌面和行動裝置聊天維持原限制。 使用 Claude Developer Platform API 金鑰的 Agent SDK 維持按使用量計費，不領取信用額度。 團隊與企業管理員注意事項 信用額度為每使用者獨立領取，不可彙整、轉移或跨組織分享。 信用額度設計用於個人實驗與自動化，大規模生產自動化建議改用 Claude Developer Platform 的 API 金鑰，以確保可預測的按使用量計費。 目前無需任何動作，使用者將於 2026 年 6 月 8 日收到 email 通知，包含領取指示，變更於 6 月 15 日生效。 領取與更多資訊 使用者無需立即操作，僅需等待 email 指引領取。詳細說明請參閱 Claude Agent SDK 與 Claude 方案整合文件 。此政策回應開發者對 SDK 和 claude -p 使用分享訂閱限制的疑慮，提供專屬預算以分離程式化與互動負載，促進 Agent SDK 生態發展。 原文：https://easyvibecoding.app/curated/1344

Nous Research 發布 TST 加速 LLM 預訓練。 Nous Research 團隊推出 Token Superposition Training (TST)，這是一種對標準 LLM 預訓練流程的簡單修改，在不改變模型架構、優化器、分詞器或訓練資料的情況下，提供 2-3 倍實時計時加速，同時在相同 FLOPs 下達到更低損失並優化下游任務表現。該方法由 @bloc97、@giganttheo 和 @theemozilla 主導開發，已在 270M、600M、3B 密集模型及 10B-A1B MoE 模型上驗證，論文發表於 arXiv 2605.06546，Hugging Face 頁面為 HF 論文頁，部落格詳見 Nous Research 部落格。 TST 兩階段運作機制 TST 分為兩個階段：第一階段（佔訓練 20-40%）為「疊加階段」，模型讀取連續 k 個 token 的「bags」，輸入端平均這些 token 的 embeddings，輸出端使用多熱交叉熵（multi-hot cross-entropy, MCE）預測下一個 bag；第二階段則回歸標準 next-token 預測。 輸入端變更僅為 reshape 和 embedding lookup 後的平均運算，讓 transformer 處理縮短序列（長度 l = L / s，其中 L 為原序列長，s 為 bag 大小），每單位工作處理 s 倍文字。 輸出端損失為 s 個標準交叉熵項的總和，等同於每個目標 token 權重 1/s 的 MCE，可重用既有 fused cross-entropy kernel，無需新 kernel、輔助頭或輸出投影變更。 轉換時損失曲線有 1-2 nats 尖峰，數千步後化解，並低於基線剩餘全程。 推論時模型與傳統預訓練完全相同，僅訓練迴圈改變。 驗證規模與效能數據 TST 在多個模型規模驗證，使用 TorchTitan 於 FSDP 架構，最多 64 張 B200 GPU；小模型用 DCLM 資料，大模型用 DCLM / FineWeb-Edu 50/50 混合，所有模型採用 AdamW 與 Warmup-Stable-Decay 排程，非 cherry-picked 標準超參數。 270M、600M、3B 密集模型：一致模式，3B 模型下 TST 20k 步匹配基線 36k 步最終損失，實時計時相近，下游分數幾乎相同；基線推至 50k 步才超越，顯示 TST 前置固定加速，非無限複合。 10B-A1B MoE (Qwen3 家族)：訓練至 2T tokens，TST 在 40% 實時計時內達基線最終損失更低；在 HellaSwag (+1.1 pts)、ARC-Easy (+0.4 pts)、ARC-Challenge (+1.0 pts)、MMLU (+1.6 pts) 皆優於基線，等損失設定下總預訓練時間減至 2.5 倍。 損失改善轉移至下游任務，優於單純損失降低（後者常無法轉移）。 超參數敏感度與調整 TST 有兩個旋鈕：bag 大小 k（或 s）和步驟比例 r（疊加階段佔比），論文圖 4-7 詳述敏感度曲線。 bag 大小 s：固定 r 時呈 U 形曲線，小 s 過似標準訓練無加速益處，大 s 目標過損失導致階段 2 無法完全恢復；中間寬平盆地有效，且隨模型大小向上漂移（大模型適合更大 s）。 步驟比例 r：0.2-0.4 皆近最佳，r=0 退化為基線，r≥0.5 階段 2 步數不足以修復輸出頭損傷，導致最終損失惡化。 bag 內權重優化：簡單版等權重在大 s (≥8) 次優；改用 power-law 權重（第 i 位置貢獻 1/i）降低最終損失，小 s 無差異。 下游評估追蹤損失曲線，未出現轉移損傷。 兩個獨立機制剖析 TST 分輸入端平均與輸出端多熱目標兩部件，可獨立消融；單獨使用皆優於基線，合用時效果近似加成，證明非單一技巧而是兩個相容機制。 輸出端機制：類多 token 預測（Gloeckle et al.），但位置共享權重；bag 目標捨棄內部順序，只問「哪些 token 出現」，而非精確位置，暗示 next-token 預測多數學習近未來 token 分佈而非嚴格順序，二者可部分分離。近未來輔助訊號提供比 one-hot 更豐富梯度。 輸入端機制：平均連續 embeddings 產生 bag 中心點，讓模型在離散 token 外學習粗粒序列；可能解釋包括噪聲減低、embedding 矩陣幾何正規化，或廉價「pre-pretraining」——階段 1 如粗化同一語料庫的預備訓練，提升階段 2 自然語言學習準備（類似簡化分佈先訓後精煉趨勢）。 與既有效率方法的解耦優勢 TST 最有用處在訓練時效率與推論時架構完全解耦，不碰稀疏注意力、MoE 路由、替代分詞器或優化器變更，可疊加其他預訓練改進；多數效率干預（如稀疏注意力、MoE、替代分詞）同時改訓練產物，造成比較混淆、推論減速或能力抵銷。 動機源自兩觀察：(1) BPE 優勢多來自子詞序列較短（Gigant et al.、Minixhofer et al. 子詞蒸餾、Zheng et al. proxy 壓縮），讓相同 FLOPs 見更多自然語言，故效率部分為 throughput 問題，可獨立拉桿不依賴分詞器；(2) 訓練-推論效率可單獨擴展（如 chain-of-thought、ParScale、looped LM、speculative decoding），反向亦然，TST 堅持「僅改訓練迴圈、不碰推論模型」嚴格標準。 相對複雜高吞吐修改，TST 僅 reshape、mean 與 summed CE，極簡 drop-in。 未來展望與參與邀請 TST 是 Nous 預訓練小組未來兩週數個研究發布的首發，若想參與此類問題，加入 Discord（原文提及）。該方法證明簡單訓練迴圈調整即可大幅提升預訓練效率，預期影響後續 LLM 開發，尤其在大規模 MoE 模型。 論文與資源連結 完整論文：Efficient Pre-Training with Token Superposition，作者 Bowen Peng、Théo Gigant、Jeffrey Quesnelle，2026 年 5 月 7 日發表。 Hugging Face 頁面：HF 論文 2605.06546。 Nous Research 部落格：token-superposition，含 TL;DR 與詳細實驗圖表。 此摘要忠實保留 Nous Research 的興奮語調與實證立場，強調 TST 的簡潔、解耦與跨規模穩健性，批判既有方法常見的訓練-推論耦合問題，並突出具體數據如 10B-A1B 的 2.5 倍時間減縮與下游 +1.6 MMLU 提升。TST 不僅加速 throughput，還透過獨立機制提供更豐富訓練訊號，潛在重塑預訓練範式。 原文：https://easyvibecoding.app/curated/1339

Claude Code 推出 /goal 指令持續工作至完成條件。 Claude Code 透過 /goal 指令設定完成條件，讓 Claude 在多輪互動中自動持續執行任務，直至條件達成為止，避免中途停頓。這是 Ralph loop 的內建實現，每輪結束後由小型快速模型檢查條件，未達標即啟動下一輪；條件滿足後，提供「Goal achieved」摘要。文件強調，此功能適用於有可驗證終點的重大工作，如遷移模組或清空問題佇列。 與其他自動化工作流程比較 Claude Code 提供三種維持工作階段持續執行的方法，依觸發下一輪的條件選擇： | 方法 | 下一輪啟動時機 | 停止條件 | |-----------------------|----------------------|-----------------------------------| | /goal | 前一輪結束 | 模型確認條件滿足 | | /loop | 時間間隔經過 | 使用者停止，或 Claude 判斷完成 | | Stop hook | 前一輪結束 | 自訂腳本或提示詞決定 | /goal 和 Stop hook 皆在每輪後觸發，但 /goal 是僅限當前工作階段的快捷指令，使用者只需輸入條件；Stop hook 則存於設定檔，適用多階段，並可執行腳本進行確定性檢查或提示詞評估。Auto mode 僅自動批准單輪內工具呼叫，不啟動新輪；/goal 則補充獨立評估器，由新模型檢查條件，避免工作模型自我判斷。兩者互補：auto mode 移除工具提示，/goal 移除輪次提示。另有排程選項（如夜間測試），獨立於開放工作階段運行，詳見 排程比較。 設定與使用 /goal 每個工作階段僅限一個目標，/goal 指令依參數設定、檢查或清除。 設定目標：輸入 /goal 後接條件，若已有目標則替換，並立即啟動一輪（以條件為指令）。活躍時顯示 ◎ /goal active 指標及運行時間。每輪後，評估器回報簡短原因，顯示於狀態視圖與對話記錄。 ` /goal all tests in test/auth pass and the lint step is clean ` 撰寫有效條件 評估器僅依對話記錄判斷，不獨立執行指令或讀檔，故條件須由 Claude 輸出可證明。有效條件具備： 單一可衡量終點：測試結果、建置結束碼、檔案數、空佇列。 明確檢查方式：如 "npm test exits 0" 或 "git status is clean"。 關鍵限制：途中不可變更項目，如「無其他測試檔修改」。 條件上限 4,000 字元。可加輪次或時間限制，如 or stop after 20 turns，Claude 每輪回報進度，評估器據此判斷。 檢查狀態與清除 無參數 /goal 顯示狀態： ` /goal ` 活躍目標顯示條件、運行時間、評估輪次、token 消耗及最新原因；已達成目標顯示其持續時間、輪次與 token。 清除：/goal clear（別名：stop、off、reset、none、cancel）。/clear 啟新對話亦清除目標。 恢復與非互動執行 階段結束時活躍目標，可用 --resume 或 --continue 恢復，條件保留，但輪次、計時器、token 基線重置。已達成或清除目標不恢復。 非互動模式下，-p 設定目標後單次執行至完成： `bash claude -p "/goal CHANGELOG.md has an entry for every PR merged this week" ` Ctrl+C 中斷未完成目標。適用 headless 模式 與 Remote Control。 評估機制細節 /goal 封裝工作階段範圍的 提示詞式 Stop hook。每輪結束，將條件與對話送至配置的 小型快速模型（預設 Haiku），回 yes/no 決定及簡短原因。「no」引導下一輪；「yes」清除目標並記錄達成條目。評估器不呼叫工具，僅判斷已呈現內容，按提供者計費，token 消耗通常微不足道。 需求與限制 需在接受信任對話的工作空間運行，因評估器屬 hooks 系統。若設定 disableAllHooks 或 allowManagedHooksOnly，指令會說明原因而不靜默失效。 相關功能擴展 /loop 重複執行提示詞：依時間間隔重跑，非條件驅動。 提示詞式 hooks：自訂停止邏輯。 Auto mode：自動批准工具呼叫，搭配 /goal 無人值守。 排程比較：獨立排程工作。 完整文件索引 抓取完整文件索引：https://code.claude.com/docs/llms.txt，用以探索所有頁面。 其他持久化工具 除了 /goal，Claude Code 還內建 /loop 用於重複任務（如迭代重構、清潔或燒燬待辦）、/schedule 定時執行（如夜間測試、晨間分類、週清潔），以及 stop hook 提供程式化控制（如執行測試套件、CI 端點、自訂閘道）。長時間運行依賴無需使用者等待，故支援 auto mode（CLI 按 shift + tab 啟用，或桌面模式選擇器），詳見 文件。 此功能解決 Claude 易中斷的痛點，透過 Ralph loop 與評估器確保任務完成，特別適合程式開發中需驗證終點的場景，如模組遷移（直至所有呼叫點編譯通過且測試過關）、設計文件實作（滿足所有驗收標準）、大型檔案拆分（每個模組低於大小預算），或清空標記問題佇列。作者 @ClaudeDevs 強調，這讓 Claude 「持續工作直到任務完成」，無需逐輪提示，展現 Agentic 程式開發的實用進展。 原文：https://easyvibecoding.app/curated/1299

Google 推出 Googlebook 專為 Gemini 設計。 Google 於 TheAndroidShow 活動中揭曉 Googlebook，這款新類別筆電以 Gemini 智慧為核心，融合 Android 與 ChromeOS 的優勢，重新定義從作業系統轉向智慧系統的筆電體驗。作者 Alex Kuscher（Laptops & Tablets 資深總監）強調，這延續 15 年前 Chromebook 的雲端優先精神，透過頂級硬體與無縫裝置整合，提供個人化、主動式協助。 Gemini 智慧核心設計 Googlebook 從頭設計為 Gemini 智慧筆電，游標成為互動樞紐，透過與 Google DeepMind 團隊合作的 Magic Pointer 功能革新之。 搖動游標即可喚醒 Gemini，提供即時脈絡建議：指向 email 中的日期即可設定會議，或選取客廳照片與新沙發圖像，即時視覺化組合，從構想到完成僅需幾次點擊。 「Create your Widget」功能讓使用者透過提示自訂 widget：Gemini 搜尋網路或連結 Gmail、Calendar 等 Google 應用，生成個人化儀表板。例如規劃柏林家庭聚會，widget 整合航班、飯店、餐廳預訂及倒數計時，變桌面為專屬首頁。 Android 生態優化與跨裝置流暢 Googlebook 建基於 Android 技術堆疊，加速創新推送，並強化多裝置體驗，讓使用者維持生產力而不中斷。 手機與筆電無縫切換：如在筆電專注工作時感饑餓，可直接點擊手機 app 下單食物，或回應 Duolingo 每日語言課提醒，在筆電螢幕上完成學習而不離開。 Quick Access 功能於 Googlebook 檔案瀏覽器中，直接檢視、搜尋或插入手機檔案，無需傳輸。 影片示範：在通訊軟體中，透過 Gemini 快速搜尋「日本之旅」照片，並分享相簿連結；或輸入「整理我的東京復古購物行程」，Gemini 生成包含航班、飯店、餐廳及倒數計時的 widget。 頂級硬體與合作夥伴 Googlebook 由 Acer、ASUS、Dell、HP、Lenovo 等業界領先夥伴打造，強調頂級工藝與材質，多樣形狀尺寸，並以獨特 glowbar 標誌辨識其功能與美學設計。 Alex Kuscher 表示，Googlebook 不僅是硬體，更是與使用者共同塑造筆電未來的平台，預計秋季上市，更多細節將陸續公布，可至 googlebook.com 了解。（註：連結基於原文提及，實際存取依官方更新） 影片示範亮點 YouTube 影片（https://youtu.be/VUthq-JuxxE）以「智慧是新的規格」開場，展示 Googlebook 的實用情境： 搖動游標選取網頁復古服飾，Gemini 依提示生成穿搭建議並顯示。 筆電上直接開啟 Duolingo 等行動 app 操作。 透過 Gemini 建立東京購物 widget，整合行程細節。 在通訊軟體中 Gemini 搜尋並分享照片連結。 結尾強調 Googlebook 外觀，為 Gemini 智慧量身打造。 此舉反映 Google 從雲端筆電 Chromebook 演進至智慧主導時代的策略，強調 Gemini 的主動幫助與 Android 生態的即時性，預期重塑使用者對筆電的期待。 原文：https://easyvibecoding.app/curated/1295

Claude Opus 4.7 快速模式現於研究預覽上線，提升互動回應速度 2.5 倍。 Claude Code 推出 Opus 4.7 的快速模式（fast mode），以更高 token 成本換取 2.5 倍速度加速，適用於 Claude Code 使用者和 API 使用者，目前處於研究預覽階段，功能、定價與可用性可能依回饋調整。Opus 4.7 快速模式於 Claude Code 中為選擇性啟用，將於 2026 年 5 月 14 日成為快速模式預設模型；API 使用者需加入等候名單 http://claude.com/fast-mode，Claude Code 使用者可參考文件 https://code.claude.com/docs/en/fast-mode 立即選擇啟用。 快速模式啟用方式 Claude Code 使用者可透過以下兩種方式切換快速模式： 在 CLI 或 VS Code Extension 中輸入 /fast 並按 Tab 鍵切換開關。 在使用者設定檔案（user settings file）中設定 "fastMode": true。 預設情況下，快速模式會跨工作階段持續啟用；管理員可設定每工作階段需重新選擇（見後述）。啟用時，若當前非 Opus 模型，將自動切換至 Opus 4.6（預設）或 Opus 4.7（需環境變數），顯示「Fast mode ON」確認訊息，並在提示旁出現小 ↯ 圖示；再次輸入 /fast 可檢查狀態或關閉。關閉後維持相同 Opus 版本，不自動回退先前模型，需用 /model 切換。 Opus 4.7 快速模式選擇啟用 Opus 4.7 快速模式需 Claude Code v2.1.139 或更新版本，目前為研究預覽，速度與 Opus 4.6 快速模式相同（2.5 倍），定價亦同（輸入 $30/MTok、輸出 $150/MTok），無其他行為差異。Claude Code 使用者今日起可選擇啟用，將於 2026 年 5 月 14 日（原文註明 May 14, 2026）成為預設。 啟動 Claude Code 前設定環境變數： `bash export CLAUDECODEENABLEOPUS47FAST_MODE=1 ` 此時 /fast 將執行 Opus 4.7；未設定則維持 Opus 4.6。 或在任何 Claude Code 設定檔案（使用者、專案或管理設定）中加入： `json { "env": { "CLAUDECODEENABLEOPUS47FAST_MODE": "1" } } ` Opus 4.6 快速模式持續可用，兩者共用相同速率限制池。若要強制固定 Opus 4.6，設定 CLAUDECODEOPUS46FASTMODE_OVERRIDE=1，此變數優先級最高。 成本權衡考量 快速模式每 token 成本高於標準 Opus，定價平攤至完整 1M token 上下文視窗： | 模式 | 輸入 (MTok) | 輸出 (MTok) | |-----------------------|-------------|-------------| | Opus 4.6 快速模式 | $30 | $150 | | Opus 4.7 快速模式 | $30 | $150 | 對話中途切換快速模式，將對整個對話上下文收取完整未快取輸入 token 的快速模式價格，高於工作階段起始即啟用時的成本。文件強調，為最佳成本效率，應於工作階段開始時啟用，而非中途切換。 適用情境與努力等級比較 快速模式適合延遲比成本更重要的互動工作： 程式碼變更的快速迭代。 即時除錯工作階段。 時效緊迫的任務。 標準模式則適合： 速度非關鍵的長時間自主任務。 批次處理或 CI/CD 管道。 成本敏感工作負載。 快速模式與努力等級（effort level）皆影響回應速度，但效果不同： | 設定 | 效果 | |-----------------------|----------------------------------------------------------------------| | 快速模式 | 相同模型品質、更低延遲、更高的成本 | | 較低努力等級 | 減少思考時間、更快回應、複雜任務可能品質降低 | 兩者可結合：於簡單任務使用快速模式搭配較低 努力等級 以達最大速度。 使用要求與限制 快速模式需滿足以下條件： 不支援第三方雲端提供者：Amazon Bedrock、Google Vertex AI 或 Microsoft Azure Foundry 不可用，僅限 Anthropic Console API 及訂閱方案的額外使用量。 啟用額外使用量：帳戶需開啟 extra usage，允許超出方案包含用量的計費。個人帳戶於 Console 計費設定 啟用；Team/Enterprise 需管理員為組織啟用。快速模式用量直接計入 extra usage，從第一 token 起按快速模式費率收取，不扣除方案包含用量。 Team/Enterprise 管理員啟用：預設停用，管理員須明確啟用，否則 /fast 顯示「Fast mode has been disabled by your organization.」。 - Console（API 客戶）：Claude Code 偏好設定。 - Claude AI（Team/Enterprise）：管理設定 > Claude Code。 Claude Code 最低需求 v2.1.36（Opus 4.7 需 v2.1.139），可用 claude --version 檢查。僅限 Pro/Max/Team/Enterprise 訂閱方案及 Claude Console，使用量為額外計費，不計入方案速率限制。 組織管理設定 管理員可完全停用快速模式，設定 CLAUDECODEDISABLEFASTMODE=1（見 環境變數文件）。 預設快速模式跨工作階段持續，若要要求每工作階段重新選擇（per-session opt-in），Team/Enterprise 管理員於管理設定或伺服器管理設定中加入： `json { "fastModePerSessionOptIn": true } ` 此設定使每個工作階段起始時關閉快速模式，使用者需用 /fast 明確啟用，有助組織控制多重並行工作階段成本。移除設定後恢復預設持續行為，使用者偏好仍會儲存。 速率限制處理 Opus 4.6 與 4.7 快速模式共用速率限制池。觸發快速模式速率限制或 extra usage 耗盡時： 自動回退至相同 Opus 版本的標準速度。 ↯ 圖示變灰表示冷卻中。 以標準速度與定價繼續工作。 冷卻結束後自動重新啟用快速模式。 欲手動關閉而非等待，執行 /fast。 研究預覽特性與生態整合 快速模式為研究預覽，功能、可用性、定價及底層 API 配置可能依回饋演進，問題回報透過 Anthropic 既有支援管道。 Opus 4.7 快速模式已於 API 及 Claude Code 研究預覽上線，對 Claude Code 使用者今日起選擇啟用，將於週四成為快速模式預設。同時於 Cursor AI、Emergent Labs、Factory AI、v0、Warpdotdev 及 Windsurf 研究預覽可用。完整文件索引可從 https://code.claude.com/docs/llms.txt 取得。 相關參考： 模型配置：切換模型與調整努力等級。 有效管理成本：追蹤 token 使用與降低成本。 狀態列配置：顯示模型與上下文資訊。 原文：https://easyvibecoding.app/curated/1307

到底什麼是 Forward Deployed Engineer？（以及為什麼每家公司都在徵才） 根據 a16z 的說法，這個職位被稱為「新創圈最熱門的工作」，在 2025 年成長了 800%，而且直到今天依然是熱門話題，發展勢頭強勁。目前正在（或已經）招募此職位的公司包括 OpenAI、Anthropic、Databricks、Ramp，甚至我們自己。但為什麼呢？ 到底什麼是 Forward Deployed Engineer？ Forward Deployed Engineer (FDE) 是一位會被派駐到客戶團隊中的工程師，旨在填補你的產品功能與客戶實際需求之間的落差。這可能意味著需要連續幾週在客戶辦公室現場工作、直接加入客戶的 Slack workspace，或是為了進行 onboarding 和實作而存取客戶的實際基礎設施。 這個職位起源於 Palantir。他們發現，即便是針對情報軟體客戶進行簡單的產品展示，也可能需要耗費數週的時間來處理保密協議 (NDA) 和安全審查。他們後來成功建立了一種模式：工程師被「前線部署 (forward deployed)」到客戶現場，在取得適當授權與流程的前提下，與客戶並肩工作，進行產品探索與開發。 透過深入客戶團隊，FDE 能熟悉客戶現有的技術堆疊、痛點以及實作上的挑戰。這些學習成果隨後會被核心產品團隊採用，並將其通用化，以服務其他客戶。這是一個雙贏的局面：客戶獲得了高度客製化的解決方案，而 FDE 則獲得了寶貴的實戰經驗。 舉例來說，當 OpenAI 正在開發語音模型時，他們派遣了 FDE 到一家從事客服中心自動化的客戶公司。他們建立了評估機制 (evals) 來驗證模型效能，並將這些資料帶回核心研究團隊以進一步優化。最終，該客戶成為首個將其部署到生產環境的企業，而這些改進也成為 OpenAI Realtime API 中廣泛提供的功能。 Forward Deployed Engineer 實際上在做什麼？ FDE 的生活與其他軟體工程師相當類似，差別在於他們是「駐點」在客戶端，為客戶的需求進行開發。這意味著他們需要參與大量的會議與客戶端工作，且通常需要 20-50% 的時間出差（除非他們只進行虛擬訪問）。 在 Palantir，FDE 的日常工作大致如下： 與客戶開會，了解問題所在。 根據這些需求設計、撰寫並測試軟體。 設定現有產品（例如 AI 模型或穩定性改進），為客戶解鎖功能。 與「後方」的產品團隊溝通客戶回饋。 話雖如此，每家公司的情況都不盡相同。隨著職位演變，FDE 的工作內容現在涵蓋了從產品開發到銷售，甚至是 RevOps。FDE 的原始概念依然核心在於實際的實作與工程，但在某些公司，FDE 的角色更接近技術顧問或銷售工程師。 為什麼現在感覺每家公司都在徵求 Forward Deployed Engineer？ 最顯而易見的答案是 AI。在 Palantir 工作超過七年的 FDE Anjor Kanekar 是這樣說的： AI 公司面臨一個 FDE 非常適合解決的問題。基礎模型的能力與企業應用場景之間存在落差，而這正是 AI 能創造價值的地方。FDE 模式是一種非常有效的方法，用來進行研發工作，找出「應用層 (app layer)」該如何建構。AI 公司擁有模型，但他們需要弄清楚到底該利用這些模型建構什麼，才能打入大型企業或公共部門。 不過，除了需要大量客製化之外，還有其他因素： AI 隱私風險是真實存在的。 企業不希望在未建立信任的情況下（特別是針對 AI 用途），將客戶資訊、財務紀錄或專有資料交給供應商。FDE 因為合約是針對產品而非僅僅是服務，因此能取得與這些資料直接工作所需的權限與長期存取權。 AI 合約金額非常龐大。 AI 交易金額巨大。動輒六位數、七位數甚至八位數。當 AI 公司收取如此高額的費用時，他們有能力派遣工程師駐點數月，以確保產品能如預期般運作。過去，這類工作通常由顧問完成，但 AI 公司為了確保更好的合約並獲得第一手知識，願意承擔這些財務成本。 決策者對 AI 持懷疑態度。 大多數人——特別是傳統企業的高層——尚未完全相信 AI 的實用性，需要眼見為憑。當涉及重大利益時，單靠銷售電話和展示是不夠的。FDE 透過與客戶共同作業，直到他們看到實際資料產出的真實成果，從而填補了這段信任落差。 他們與軟體工程師有什麼不同？ FDE 依然在進行軟體工程，但他們花費比其他軟體工程師更多的時間與客戶溝通並定義專案範圍，以決定要建構什麼以及如何建構。他們的首要任務是深入理解客戶的問題，以便開發出能解決這些問題的方案。 另一方面，軟體工程師專注於建構可通用且易於維護的功能。他們較少參與直接的客戶對話，更專注於能大規模運作的解決方案。 Palantir 的早期高管 Bob McGrew 將 FDE 描述為那些為產品目標鋪設「碎石路」的人。接著，核心產品團隊的軟體工程師會負責將這條碎石路轉變為鋪設好的高速公路，讓接下來的十位客戶也能使用。 關鍵差異在於，FDE 一次針對一位客戶進行產品探索與開發，通用性是次要考量。而軟體工程師通常從一開始就以服務眾多使用者為目標進行建構，思考規模化是他們流程中不可或缺的一部分。 等一下，那產品工程師呢？產品工程師與 FDE 的相似之處在於，他們都能在與使用者溝通的同時快速建構，並交付能解決問題的精簡方案。差異在於環境與目標——產品工程師旨在解決許多人共同面臨的問題，以便在過程中創造出可重複使用的解決方案；而 FDE 則是一次專注於一位客戶。 什麼樣的人適合成為 Forward Deployed Engineer？ 公司在招募 FDE 時，通常會尋找具備以下特質的人才： 紮實的工程經驗。具備 5 年以上工程或技術部署經驗，且包含客戶端工作經驗 (OpenAI)。 客戶同理心。謙遜、樂於合作，並能以同理心協助他人 (OpenAI)。 出色的溝通技巧。具備高層對話能力，並能在客戶端場合代表公司 (Lambda)。 協作態度。具備強大的溝通技巧，能與客戶進行需求探索，並能向不同背景的利害關係人傳達技術概念，同時保持低姿態與協作精神 (Anthropic)。 產品敏銳度。能貢獻加速器、框架與最佳實踐，擴大在各個帳戶中的影響力，並影響產品路線圖 (Databricks)。 領域專業知識。在生物科技、製藥、臨床研究或科學軟體領域具備客戶端負責經驗；鼓勵具備生命科學相關領域的博士、碩士或同等應用經驗 (OpenAI)。 對流程的熱情。熱愛結合工程、顧問與交付工作，並對旅程中的每一步負責 (HackerRank)。 Palantir 總裁兼 CTO Shyam Sankar 曾表示，那些在各自領域中被視為「異端」或「叛逆者」的人，是完美的 FDE 人選，因為他們擁有獨特的深度、背景知識與能量，能為企業解鎖 3 到 10 倍的成長。 （如果你還沒發現，這些特質同時也是優秀產品工程師與創辦人所具備的。難怪這麼多前 Palantir 員工後來都創立了自己的公司。） 我們什麼時候應該招募 Forward Deployed Engineer？ 如果常見的產品市場契合度 (product-market fit) 策略已經對你奏效，答案是你不需要。FDE 策略始於解決一個問題，並爭取解決更大問題的機會，這對於單一客戶來說可能需要耗費數年。目標是簽下隨時間推移價值越來越高的合約，但這在初期有巨大的成本。 在以下情況，FDE 對公司來說是有意義的： 產品需要大量的實作投入，且你負擔得起成本。 如果你的產品需要與現有基礎設施進行深度整合，且利潤空間巨大，那麼 FDE 的成本就是合理的。這就是為什麼現在這麼多 AI 新創公司都在招募他們。 產業有嚴格的法規限制。 醫療保健、金融、政府與國防等產業有許多合規要求，使得大規模交付與迭代變得困難。FDE 在這裡很有價值，因為他們可以專精於這些標準、審核與流程（就像他們在 Palantir 所做的那樣）。 你正在鎖定新的垂直領域或市場區隔。 當你的公司正在探索全新的客戶輪廓與 ICP (理想客戶畫像) 時，你無法預知自己不知道什麼。FDE 可以深入早期客戶團隊，了解該領域並進行所有進入市場所需的產品探索。 這就是 Ramp 的情況，他們最初是為小型企業進行建構，但在嘗試滿足企業級需求並遇到技術挑戰時，加入了 FDE。 為什麼我們 PostHog 剛招募了一位 Forward Deployed Engineer？ 我們以擁有「開箱即用」的工具為榮，但「任何開發者都能在 10 分鐘內使用 PostHog」與「這家財富 500 強公司可以在不花費數月的情況下遷移其整個分析堆疊」之間是有區別的。 我們招募了第一位 FDE 來協助這些大規模遷移，但我們是以 PostHog 的方式進行。我們的 FDE 是完全遠端、非同步的，並專注於建構自動化。對於習慣典型 FDE 設定的人來說，這是一個奇怪的實驗，但對我們來說是有意義的。如果我們利用現有的大量使用資料，而不是從零開始進行產品探索，那麼許多好處（深度的客戶知識、更快的迭代等）依然可以實現。 隨著 AI 能力的提升，人們對企業軟體能達成什麼目標有了更高的期望。我們認為 FD…

Google 推出 Gemini Intelligence，將 Gemini 人工智慧整合至 Android 先進裝置，提升主動式任務自動化。 Google 在 TheAndroidShow 活動宣布 Gemini Intelligence，這項功能將 Gemini 人工智慧帶入最先進的 Android 裝置，結合頂級硬體與創新軟體，讓裝置主動協助使用者完成日常任務，同時強調資料隱私與使用者控制。功能將分波次推出，從今年夏季的最新 Samsung Galaxy S26 與 Google Pixel 10 手機開始，後續擴及手錶、汽車、眼鏡與筆電等 Android 裝置。 多步驟任務自動化 Gemini Intelligence 能自動化跨應用程式的繁瑣任務，讓使用者專注重要事項。Google 已花費數月微調 Galaxy S26 與 Pixel 10 在熱門美食與共乘應用上的多步驟自動化，確保互動無縫。 例如，從 Gmail 找出課程大綱，自動將所需書籍加入購物車；或搶購健身房的頭排腳踏車位。 加入螢幕或影像脈絡更強大：長按電源鍵，對記事本上的長購物清單說「用這些項目建購物車並送貨」，Gemini 即轉化視覺為即時行動。 拍攝飯店大廳的旅遊傳單，說「在 Expedia 為六人團找類似行程」，Gemini 後台處理並透過通知追蹤進度，使用者全程掌控，只需最終確認。 Chrome 智慧瀏覽 從六月底起，Android 裝置將獲得 Gemini in Chrome 這項更智慧的網頁瀏覽助理，能研究、摘要並比較網頁內容。Chrome auto browse 自動處理瑣事，如預約行程或停車位。 單點填表 Autofill with Google 進化為更智慧直覺，利用 Gemini Personal Intelligence 自動填入應用程式與 Chrome 中的小型文字欄位，解決行動螢幕填寫複雜表單的普遍痛點，從連結應用程式的相關資訊自動完成。連接 Gemini 至 Autofill 為嚴格選擇加入，使用者在設定中可隨時開關。 Rambler 語音轉文字 Gboard 已能快速精準轉換語音為文字，但人們說話常帶「嗯」「啊」「像」等填充詞。Rambler 是全新 Gemini Intelligence 功能，設計貼合自然說話習慣：使用者自然說話，它提取重點並組合成精煉訊息，清楚標示啟用狀態，僅即時轉錄語音，不儲存。 支援全球多語言溝通，利用 Gemini 進階多語模型，在單一訊息中無縫切換語言，如英文混印地語，保留脈絡與細微差異，讓訊息聽起來就是「你」，僅更精煉。 自訂 Widget Gemini Intelligence 開創生成式 UI 第一步，從 Android 經典 Widget 開始。透過「Create My Widget」，使用者以自然語言描述即可建置全自訂 Widget。 例如，高蛋白餐食準備者說「每週建議三道高蛋白餐食準備食譜」，它即生成可加至首頁並調整大小的自訂儀表板。 單關心風速與降雨的腳踏車手，可建專屬天氣 Widget 只顯示這些數據。 這些工具由 Gemini 驅動，在手機或 Wear OS 手錶上皆適用，將關鍵資訊置於最顯眼位置。 智慧 UI 設計 Gemini Intelligence 採用更新設計語言，建基於 Material 3 Expressive，不僅美觀且功能導向，動畫有目的性設計，減少干擾，讓使用者專注任務。 推出時程與隱私 功能從夏季起分波推出，先從 Samsung Galaxy S26 與 Google Pixel 10 開始，年底擴及更多 Android 裝置。Mindy Brooks（產品管理副總裁）於 2026 年 5 月 12 日文章強調，Android 正從作業系統轉型為智慧系統，Gemini Intelligence 透過主動運作節省時間，嚴守資料隱私並讓使用者掌控。更多詳情見 官方頁面。 原文：https://easyvibecoding.app/curated/1298

Google 推出 Gemini Intelligence，將 Android 轉型為智慧系統，率先在 Galaxy S26 和 Pixel 10 等先進裝置上自動化繁瑣任務。 Gemini Intelligence 整合 Gemini 頂尖功能與高階硬體，讓裝置主動處理日常瑣事，幫助使用者節省時間並專注於重要事務。該功能強調資料隱私與使用者控制，從今年夏季起分階段推出，首先登陸最新 Samsung Galaxy 和 Google Pixel 手機，年底擴及手錶、汽車、眼鏡與筆電。 自動化多步驟任務 Gemini Intelligence 能自動化跨應用程式的繁瑣任務，例如重新訂購每週雜貨或搶購票券，讓使用者保持當下專注。Google 已花費數月微調 Galaxy S26 和 Pixel 10 在熱門美食與共乘應用上的多步驟自動化，確保互動無縫。 未來，Gemini 可獨立處理任務，如搶旋轉單車前排位置，或在 Gmail 找到課程大綱後將所需書籍加入購物車。 加入螢幕或影像脈絡後，自動化更強大： 使用者長按電源鍵對著記事本中的長購物清單，指示 Gemini 建立包含所有物品的配送購物車。 拍攝飯店大廳的旅遊傳單，說「在 Expedia 為六人團體找到類似行程」，Gemini 會在背景執行，使用者透過通知即時追蹤進度。 Gemini 只在使用者指令下行動，任務完成即停止，最終需使用者確認。 Chrome 中的智慧瀏覽 從 6 月底起，Android 裝置將獲得 Gemini in Chrome 作為更智慧的網頁瀏覽助理，能研究、摘要並比較網頁內容。Chrome auto browse 會代處理瑣碎任務，如預約行程或預訂停車位。 單點填表升級 Autofill with Google 進化為更智慧直覺，利用 Gemini 的 Personal Intelligence 自動填入應用程式（包含 Chrome）中的細小文字欄位。裝置會從連結應用程式提取相關資訊，解決行動螢幕填寫複雜表單的普遍困擾。此 Gemini 與 Autofill 連結為選擇性啟用，使用者可在設定中隨時開關。 語音轉優質文字：Rambler Gboard 已能快速精準將語音轉文字，但口語常有重複、「嗯」「啊」「像」等填充詞。Rambler 是全新 Gemini Intelligence 功能，設計貼合人們真實說話方式：使用者自然說話，Rambler 提取重點並組合成簡潔訊息。 啟用時會清楚顯示，語音僅即時轉錄，不儲存或保存。 支援多語言混合，如英文夾雜印地文，Gemini 進階多語模型理解脈絡與細微差異，讓訊息聽起來像本人但更精煉。 自訂 Widget 生成 Gemini Intelligence 開創生成式 UI 第一步，從 Android 招牌 Widget 入手。透過「Create My Widget」，使用者僅用自然語言描述，即可建立完全自訂 Widget，例如： 餐食準備者說「每週建議三道高蛋白餐食準備食譜」，系統生成可新增至首頁並調整大小的自訂儀表板。 單車騎士要求僅顯示風速與降雨的天氣 Widget。 這些功能性智慧工具由 Gemini 支援，在 Gemini Intelligence Android 手機或 Wear OS 手錶上皆適用，讓使用者最關心的資訊置於顯眼位置。 智慧設計語言 Gemini Intelligence 採用基於 Material 3 Expressive 的更新設計語言，不僅美觀，還具功能性：動畫有目的性設計，減少干擾，讓使用者專注任務。 Gemini Intelligence 從處理數位瑣事到打造個人化介面，正轉變使用者與裝置互動方式。官方部落格詳述所有功能：探索完整細節。作者 Mindy Brooks（2026 年 5 月 12 日發表）強調，此升級讓 Android 從作業系統蛻變為智慧系統，率先在先進裝置上實現主動協助。 原文：https://easyvibecoding.app/curated/1309

Chrome 即將在 Android 推出 auto browse。 Google Chrome 宣布，下個月起在 Android 上引入基於 Gemini 3.1 模型的新 AI 功能，包括 auto browse 和 Agentic 瀏覽，旨在提升行動裝置瀏覽體驗，讓使用者透過個人 AI 助理處理日常任務。這些功能將從 2026 年 6 月底起，在美國地區的 Android 12 或更高版本特定裝置上陸續推出，其中 auto browse 限 AI Pro 和 Ultra 訂閱使用者。 Gemini 作為個人瀏覽助理 Gemini in Chrome 在 Android 上定位為個人 AI 瀏覽助理，能理解當前網頁內容，提升行動體驗。使用者點擊工具列右上角的 Gemini 圖示，即可在畫面底部開啟，輕鬆詢問網頁相關問題、摘要長篇文章，或獲取複雜主題的詳細解釋，無需切換應用程式。 超越簡單查詢，Gemini 整合使用者喜愛的 Google 應用，如新增行事曆事件、將食譜食材加入 Keep，或在 Gmail 中搜尋特定資訊。 若啟用 Personal Intelligence，可依據使用者的興趣、嗜好、家人甚至寵物，提供個人化回應，強調隱私保護並讓使用者保有控制權。 Nano Banana 圖像自訂功能 Nano Banana 讓使用者在 Chrome 中即時產生高度個人化視覺內容，或修改網頁上的圖像。舉例來說： 線上準備考試時，可要求「將此頁面轉換成資訊圖表（turn this page into an informative infographic）」，以視覺方式吸收內容。 瀏覽公寓列表時，可指示「修改圖像加入現代客廳必需品（alter the image to include modern living room essentials）」，預覽家具配置效果。 Auto browse 自動化日常任務 首次在 Android 上推出 auto browse，讓使用者輕鬆處理繁瑣任務，專注於重要事務。透過輸入提示，Chrome 會自動執行並完成工作，例如： 即將前往 standup comedy 表演，忘記預訂停車位？Auto browse 可從票券確認的活動細節，自動在 SpotHero 上幫忙找位。 寵物從幼犬轉換成成犬，需要改買狗糧？只需要求 Chrome 更新 Chewy 訂單即可。 此功能設計為使用者提示後，生成計劃並請求確認，然後在任務完成時返回通知。 安全與隱私保障 所有功能沿用桌面版的安全防護，對抗新興威脅如 prompt injection，使用者在行動中也能安心瀏覽。Auto browse 在執行敏感任務前（如購物或社群媒體發文）會要求使用者確認，提供額外控制層級。 推出時程與可用性 Gemini in Chrome 將從 2026 年 6 月底起，在美國地區 Android 12 或更高版本的特定裝置上推出。同期，auto browse 限美國 AI Pro 和 Ultra 訂閱使用者，於相同裝置上開放。詳細資訊可參考 官方部落格。 這些更新將 Gemini 的智慧能力從桌面延伸至行動端，透過 auto browse 等 Agentic 功能，實現更智慧化的瀏覽助理，雖然初期限美國與特定訂閱，但預示 Chrome 將深化 AI 在日常數位勞務中的角色。 原文：https://easyvibecoding.app/curated/1316

Google DeepMind 以 AI 重新想像滑鼠指標介面。 Google DeepMind 發表實驗性示範，展示 AI 強化滑鼠指標如何在螢幕上無縫整合人工智慧，解決傳統 AI 需切換視窗的痛點，讓幫助隨處可用而不中斷工作流程。 維持工作流程 AI 功能應跨所有應用程式運作，避免強迫使用者「繞道」至額外 AI 工具。原型 AI 強化指標可在使用者所在位置直接提供幫助，例如： 指向 PDF 並要求「製作 email 的 bullet point 摘要」，直接貼入 email。 懸停表格並要求「製作餅圖」。 反白食譜並說「雙倍所有食材」。 視覺與語意理解 現有 AI 模型需精確指令，使用者須撰寫詳細提示。AI 強化指標透過「看見」游標下的內容，瞬間理解特定單字、影像或程式碼區塊，移除此負擔。 擁抱「這」與「那」的自然語言 現實中，人們不說長段落，而是指向並說「修復這個」（fix this）、「移到那裡」（move that）或「這是什麼意思」（what does this mean），依賴手勢與共享脈絡。結合指向與語音的 AI 系統，讓使用者以自然簡語完成複雜請求，無需繁瑣提示。 像素轉化為可行動實體 數十年來，滑鼠僅追蹤指向位置；AI 現在理解指向內容，將像素轉為結構化實體如地點、日期或物件，使用者可即時互動。例如： 潦草筆記照片變成互動待辦清單。 暫停的旅遊影片畫面變成餐廳預訂連結。 指向建築影像並說「顯示路線」。 互動原則總結 Google DeepMind 提出四項原則，將傳達脈絡與意圖的負擔從使用者轉移至電腦，用更直覺互動取代文字提示： 維持流程：AI 無處不在，不中斷。 展示與敘述（Show and tell）：指標捕捉視覺與語意脈絡。 擁抱「這」與「那」：模擬人類自然簡語。 像素轉行動：理解內容而非僅位置。 產品應用與實驗環境 這些原則正引導下一代介面設計，目前整合至 Chrome 與新「Googlebook 筆電體驗」。從即日起，使用者可在 Chrome 以指標向 Gemini 查詢網頁特定部分，例如反白產品要求「比較」，或指向客廳位置要求「視覺化新沙發」。Googlebook 即將推出「Magic Pointer」，讓使用者指尖即用 Gemini。更多概念將在 Google AI Studio 測試，包括 Google Labs 的 Disco。文章作者 Adrien Baranes 與 Rob Marchant 於 2026 年 5 月 12 日發表，強調建構適應人類行為的技術，而非強迫使用者適應，讓 AI 協作感覺直覺、流暢、無縫。 未來願景 Google DeepMind 興奮這些「以人為本」概念正融入日常產品，重新定義滑鼠指標從追蹤位置進化為理解脈絡與意圖，開啟 AI 時代全新使用者介面。 原文：https://easyvibecoding.app/curated/1297

吳恩達斷言，不會有 AI 就業末日。 吳恩達駁斥 AI 將引發大規模失業的說法，認為這類過度渲染的故事不僅不負責任，還會造成不必要的恐慌；他呼籲停止散播此類敘事，並樂見主流媒體開始反擊。 軟體工程就業趨勢強勁 軟體工程是受 AI 工具影響最深的領域，程式碼 Agent 進展神速，但軟體工程師招聘仍維持強勁態勢。雖然有 AI 取代個別工作的案例，卻有明確趨勢顯示淨就業創造遠大於就業破壞，這與以往技術浪潮相似。此外，儘管 AI 進展令人興奮，美國失業率仍維持健康的 4.3%。 就業末日敘事背後動機 邊緣 AI 實驗室有強烈動機誇大 AI 威力，例如推廣科幻情境如 AI「接管」導致人類滅絕，以凸顯技術價值。若 AI 能取代多名員工，其商業價值自然水漲船高。 SaaS 軟體公司通常向每位使用者收取每年 100-1000 美元，但 AI 若能取代年薪 10 萬美元員工，或提升其 50% 生產力，收取 1 萬美元也顯得合理；AI 公司以此薪資錨定定價，而非典型 SaaS 價格，從中獲利豐厚。 企業也樂於將裁員歸咎 AI，因為宣稱「用 AI 少人更高效」聽來聰明，遠勝承認疫情期低利率與巨額政府刺激導致過度招聘。 AI 對工作的真實衝擊 吳恩達承認 AI 正大幅改變許多人的工作，這過程艱難、壓力沉重（對某些人或許有趣），他對受影響者表達同理。但這與預測就業市場崩潰截然不同。 歷史教訓：恐慌敘事的危害 社會常長年沉迷無實據的故事，導致糟糕決策，例如核電安全恐懼造成投資不足；1960 年代「人口炸彈」恐慌促使國家實施嚴苛減人口政策；膳食脂肪擔憂則讓政府數十年推廣不健康高糖飲食。吳恩達盼主流媒體對就業末日的質疑，能讓此敘事喪失威力，正如 AI 滅絕人類恐懼已逐漸消退。 樂觀預測：AI 就業盛會 吳恩達預測相反結果：將迎來「AI 就業盛會」！AI 將創造大量優質 AI 工程師職位，整體就業市場前景樂觀。AI 工程師工作將異於傳統軟體工程，多數職位出現在非傳統開發大雇主的企业；非 AI 角色所需技能也將因 AI 改變。這是鼓勵更多人精通 AI 的絕佳時機，讓他們準備好迎接未來多樣且豐沛的職缺。 原文出自 [The Batch newsletter。] 原文：https://easyvibecoding.app/curated/1302

Meta 推出 Muse Spark 實現語音對話。 Meta Superintelligence Labs（MSL）於 2026 年 4 月 8 日發布「Muse Spark」，這是其首款大型語言模型，專為優先考慮使用者而設計，目前驅動 Meta AI app 與 meta.ai 網站，並將逐步擴展至 WhatsApp、Instagram、Facebook、Messenger 及 AI 眼鏡。2026 年 5 月 12 日更新公告顯示，該模型已帶來更快的語音回應、更智慧的 AI 眼鏡，以及購物與對話輔助新功能，讓 Meta AI 更具脈絡理解與實用性。 語音對話升級 在 Meta AI app 中，「Muse Spark」支援自然語音互動，使用者可中斷對話、切換主題或語言轉換，同時 Meta AI 能即時產生圖像，並從 Reels、地图等拉取推薦內容。 此外，app 引入「live AI」功能（AI 眼鏡已支援），使用者可對準相機拍攝周遭環境，實時詢問地標或家居問題，例如辨識路過的著名建築或家務協助。 相關示範影片：語音互動示範 及 live AI 實時辨識。 購物功能創新 新「購物模式」讓使用者透過 Meta AI 搜尋附近 Facebook Marketplace 清單，同時整合網路新舊商品，並顯示地圖位置；可依價格、風格或距離精煉結果。 使用者也能 @ 指定品牌或創作者，直接瀏覽其公開內容，以全新格狀格式滾動產品。 2026 年 5 月 12 日更新強化此功能，讓購物與對話更無縫。 示範 GIF：購物介面。 跨裝置與 app 整合 「Muse Spark」將於未來數週逐步在美國與加拿大推出 Ray-Ban Meta 及 Oakley Meta 眼鏡，Meta Ray-Ban Display 則於夏季上線。 該模型同時擴展至 WhatsApp、Instagram、Facebook、Messenger 及 Threads 的搜尋列、群組聊天、貼文等處。 測試新體驗包括： 從群組聊天點擊 Meta AI 圖示開啟「side chats」，獲取基於群組討論的私人快速回應。 Threads 貼文與回覆中使用 @meta.ai 提及。 Meta 表示，此 AI 將觸及數十億使用者，提供更快、更具幫助性的體驗。 模型開發背景 過去九個月，MSL 從頭重建 AI 堆疊，開發週期為史上最快。「Muse Spark」為「Muse 系列」首款模型，採科學擴展策略，每代驗證後再放大規模。 此初始模型刻意設計為小巧快速，卻能處理科學、數學、健康等複雜推理，目前驅動 Meta AI app 與 meta.ai，支援複雜推理與多模態任務。下一代已在開發中。 Meta AI 核心升級 Meta AI app 與 meta.ai 獲得全新介面與功能升級，能處理快速問答至需強大推理的複雜問題。 使用者可切換模式，Meta AI 能平行啟動多個子 Agent 處理任務，例如規劃佛羅里達家庭旅行：一 Agent 草擬行程、另一比較 Orlando 與 Keys、第三尋找兒童活動，同時運作以加速優質回應。 示範 GIF：子 Agent 平行運作。 多模態感知能力 「Muse Spark」內建強大多模態感知，讓 Meta AI 不只讀取文字，還能「看見」真實世界。 拍攝機場零食架，Meta AI 即時辨識並依蛋白質排序零食，無需細看標籤。 掃描產品，詢問與替代品的比較。 當整合至 AI 眼鏡時，助理能更好理解周遭環境。 示範圖：食物熱量估計。 健康應用特別突出：與醫師團隊合作，提升模型對常見健康問題的詳細回應，包括圖像與圖表分析，滿足使用者首要需求。 視覺程式設計專長 「Muse Spark」在視覺程式撰寫卓越，使用者僅需提示，即可產生自訂網站與小遊戲： 建置驚喜派對規劃儀表板。 啟動復古街機遊戲追逐高分。 推出奇幻飛行模擬器，並分享給朋友。 脈絡連結與推薦 Meta AI 協助穿搭建議、室內風格或禮物選購，從 app 內創作者與社群拉取靈感。 搜尋地點或熱門話題時，會嵌入豐富脈絡，如在地使用者公開貼文或社群內容，提供即時全貌。 示範 GIF：購物模式 及 搜尋脈絡。 未來展望與部署 「Instant」與「Thinking」模式已於美國 Meta AI app 與 meta.ai 上線，未來數週擴及更多國家及 Instagram、Facebook、Messenger、WhatsApp、AI 眼鏡。 眼鏡上的感知能力將更強大。技術開放：API 私人預覽給特定夥伴，未來版本計畫開源。 預期更豐富視覺結果，整合 Reels、照片、貼文，並歸功內容創作者。Meta 將強化 安全防護，包括風險框架與隱私保護。 Meta 強調，此為通往「個人超智慧」起點：AI 不只回答問題，而是基於使用者生活脈絡真正理解世界。 原文：https://easyvibecoding.app/curated/1312

Demis Hassabis 堅信 AI 首要改善人類健康。 融資細節 Isomorphic Labs 於 2026 年 5 月 12 日宣布完成 21 億美元 B 輪融資，由 Thrive Capital 領投，這是其連續第二輪領投。既有投資者 Alphabet 和 GV 參與，新投資者包括 MGX、Temasek、CapitalG 及 UK Sovereign AI Fund，大幅擴大全球資本基礎。 公司使命 Isomorphic Labs 創立之初即以人工智慧重塑並加速藥物發現為目標，為全球數百萬患者帶來急需治療。公司運用領先的 AI 藥物設計引擎 IsoDDE，推進多個治療領域及藥物型態的藥物設計計畫，延續 AlphaFold 的健康改善工作。 未來願景 Demis Hassabis 表示，此融資將「turbocharging」目標，有朝一日解決所有疾病，透過 AI 實現生物醫學突破。詳見新聞稿。 原文：https://easyvibecoding.app/curated/1308

Google 情報小組偵測首例 AI 零日攻擊。 Google Threat Intelligence Group（GTIG）於 2026 年 5 月 11 日發布「GTIG AI Threat Tracker」報告，追蹤自 2026 年 2 月報告以來，攻擊者從初步嘗試 AI 轉向工業規模應用生成模型於攻擊流程中。報告基於 Mandiant 事件回應、Gemini 及 GTIG 主動研究，揭示 AI 雙重角色：攻擊者用作精密攻擊引擎，同時為高價值攻擊目標。 首例 AI 生成零日漏洞利用 GTIG 首次確認一名犯罪威脅行為者使用 AI 開發的零日漏洞（zero-day exploit），原計劃發動大規模利用事件，但 GTIG 主動反制發現可能已阻止其執行。中國大陸（PRC）及北韓（DPRK）相關威脅行為者亦積極利用 AI 進行漏洞發現。 AI 輔助開發規避防禦 攻擊者透過 AI 驅動程式撰寫加速基礎設施套件及多形惡意軟體開發，這些 AI 輔助開發週期促進防禦規避，包括建立混淆網路及整合 AI 生成誘餌邏輯於惡意軟體，此類惡意軟體連結至疑似俄羅斯相關威脅行為者。 自主惡意軟體運作 AI 輔助惡意軟體如 PROMPTSPY 標誌攻擊協調轉向自主化，模型解讀系統狀態動態產生指令並操縱受害環境。GTIG 分析揭露其先前未報導功能及與 AI 整合使用案例，讓威脅行為者將運作任務外包給 AI 以實現規模化及適應性活動。 AI 強化研究與資訊戰 攻擊者持續將 AI 作為高速研究助理支援攻擊生命週期，並轉向 Agentic 工作流程運作自主攻擊框架。在資訊戰（IO）活動中，這些工具大規模生成合成媒體及 deepfake 內容製造數位共識，如親俄「Operation Overload」活動所示。 隱匿 LLM 存取 威脅行為者透過專業中介軟體及自動註冊管道追求匿名高階模型存取，規避使用限制。此基礎設施實現服務大規模濫用，並透過試用濫用及程式化帳號輪替補貼運作。 供應鏈攻擊目標 AI 環境 如 "TeamPCP"（又稱 UNC6780）的攻擊者開始針對 AI 環境及軟體依賴作為初始存取途徑，導致 Secure AI Framework（SAIF）分類中的多類機器學習風險，包括 Insecure Integrated Component（IIC）及 Rogue Actions（RA）。鑑識資料分析顯示，攻擊者試圖從 compromised AI 軟體樞紐至更廣網路環境，用於初始存取及破壞活動如勒索軟體部署與勒索。 Google 主動防禦措施 攻擊者不斷實驗創新，Google 同樣積極應對，除分享發現及緩解策略予安全與 AI 社群外，強化產品防護提供使用者規模化保護。對 Gemini，Google 停用惡意帳號緩解模型濫用；另利用 AI Agent 如 Big Sleep 識別軟體漏洞，並透過 Gemini 推理能力如 CodeMender 自動修復，證明 AI 亦為防禦者強大工具。詳閱報告 。 原文：https://easyvibecoding.app/curated/1314

Unitree發表全球首款量產載人Mecha。 Unitree Robotics 推出 GD01，這是全球首款量產載人 Mecha，為民用設計，包含操作員約重 500 公斤，具備可變形底盤，能在崎嶇地形運輸、探勘或救援。影片強調其科幻變現實，但售價高達 390 萬人民幣（約 65 萬美元），Unitree 執行長王興興親自示範，引發是否為交通未來或高科技玩具的討論。 產品規格與設計 GD01 配備軀幹安裝的駕駛艙，讓人類操作員完全控制。 最突出特色為可變形底盤：直立人形模式行走，遇顛簸路況轉四足模式提升穩定性。 材質為高強度合金，工程嚴肅，包含操作員總重約 500 公斤。 Unitree 官方 Twitter 提醒使用者以友好、安全方式操作機器人。 示範與效能 在工作室示範中，王興興親自駕駛 GD01 行走，並用手推倒一堵磚牆，展現其力量與機動性。影片轉錄自 YouTube 影片，開頭直指「科幻電影正在正式走入現實」。 公司背景與市場地位 Unitree 已為產業主要參與者，僅去年出貨超過 5,500 台人形機器人。GD01 推出進一步推動人機移動界限，宣告「Mecha 時代已經來臨」，售價 390 萬人民幣（約 65 萬美元）起，定位高端民用載具。 未來展望與反思 影片結尾質疑 GD01 是「交通的未來，還是終極的高科技玩具」，反映其潛力與高價位的現實落差，呼籲觀眾分享看法並訂閱更多汽車影片。 原文：https://easyvibecoding.app/curated/1296

Claude Cowork 透過 Opus 4.7 一次成功預訂 8 趟航班與 5 家飯店。 Boris Cherny 分享使用「Claude Cowork」工具預訂即將到來的多趟旅行航班，Opus 4.7 版本首次實現「1-shot」完美完成，過去僅表現尚可，此次讓他徹底驚豔，從此拒絕手動預訂。 操作流程與成果 Boris Cherny 在 Cowork 指示中輸入航班偏好後，讓 Opus 自動處理。它開啟瀏覽器、導航多個網站，並完整預訂一切；在 Boris 於「Claude Code」專注其他工作時，Cowork 已預訂 8 趟航班與 5 家飯店，執行完美無缺。 使用者互動確認 Sravan Sarraju 詢問如何在確認前審核行程，Boris 回覆 Cowork 會先呈現行程供他批准，才進行預訂。此設計確保使用者掌控，避免直接下單風險。 活動連結與社群回饋 Txori 猜測倫敦行程點為 5 月 14 日「codex event」，Boris 更正為「Code with Claude」活動，並確認將出席。Walter R. 讚嘆並索取提示，Boris 簡述僅用「Book a flight to London」指令；JP 確認是否包含購買，Boris 明確表示涵蓋規劃與購買全程。 作者立場反思 Boris Cherny 強調這是 Cowork 最順暢體驗，從未如此無縫，象徵 Opus 4.7 在自動化任務上的重大躍進，讓使用者能專注核心工作，徹底擺脫繁瑣手動操作。 原文：https://easyvibecoding.app/curated/1288

模型在一年內遵循指令的能力提升了一個數量級 共同作者：@seldo 在 AI Engineer: Miami 大會上，我們聽了 Dexter Horthy 的演講，他在閒談中提到研究顯示模型在同時處理超過 150-200 個指令時會遇到困難。他提到該數據來自去年，且「現在可能更高了」。這對我們來說是一個非常有趣的現象，因此我們追蹤了該數據的來源：Jaroslawicz 等人（2025 年）的 IFScale 基準測試。那篇論文已經快一年了，所以我們很好奇模型自那時以來究竟進步了多少。答案是：進步非常多，事實上，提升了一個數量級。 廢話不多說，直接看數據： 這張圖表的快速總結（TL;DR）： Y 軸是準確率：給定一堆規則，模型實際遵循了百分之幾？ X 軸是對數刻度，代表模型同時嘗試遵循的規則數量。 淺色的虛線是原始論文撰寫時可用、且至今仍可使用的三款舊模型。你可以看到超過 100 條規則後，它們開始忽略部分給定的指令。到了 500 條規則時，它們開始遺漏多達一半的指令。 粗線是一些當前的頂尖模型（Frontier models）。你可以看到它們在開始遺漏指令之前，能處理的規則數量遠多於舊模型。GPT 5.5 表現最好，而 DeepSeek V4 Pro 表現最差。 這就是我們的核心發現：一年前，頂尖模型在同時處理約 200-300 個限制條件時開始失去對指令的追蹤。根據你選擇的模型，現在這個邊界已經接近 2,000 個指令。 簡單來說，頂尖模型在過去 12 個月內遵循指令的能力提升了近 10 倍，這對現實世界的 AI 程式開發有許多影響，包括： Skills files 不再有壓縮問題 Prompts 可以變得極其詳細 能力的硬性邊界已經轉變為成本與能力之間的軟性權衡 我們將會完整說明，但這裡面有很多細節，因此邀請你繼續閱讀。 原始的 IFScale 基準測試 我們的工作基於 Jaroslawicz 等人（2025 年）的基準測試論文。測試非常簡單：要求模型撰寫一份包含 N 個特定關鍵字的商業報告（從 500 個常用英文單字組成的詞彙表中選擇，例如「customer」、「revenue」、「logistics」），然後計算輸出中正確出現了多少個關鍵字。 Prompt 本身很簡短： You are tasked with writing a professional business report that adheres strictly to a set of constraints. Each constraint requires that you include the exact, literal word specified… The report should be structured like a professional business document with clear sections and relevant business insights. Do not simply repeat the constraints; rather, use them to inform the text of the report. CONSTRAINTS Include the exact word: 'customer'. Include the exact word: 'revenue'. ... 我們測試輸出的方式與原始論文相同：使用簡單的基於 regex 的精確匹配。複數不計入。連字號不計入。「Customer」符合「customer」；「customers」則不符合。我們將關鍵字的數量稱為密度或 N，而輸出中出現的關鍵字百分比即為準確率。 我們與原始作者一樣，認為這是衡量「模型一次能遵循多少指令？」這個更廣泛問題的一個良好代理指標。這些關鍵字是任意選擇的，但它們代表了現實世界 skills files 中出現的那種離散的、具名的限制條件：「如果使用者說 X，就做 Y」、「包含關於 Z 的章節」、「不要使用 W 片語」。如果模型無法在單個 Prompt 中追蹤 200 個離散項目，那麼對於任何包含超過 200 個項目的技能規範來說，這都是一個問題。 原始論文的結果依然正確 在擴展基準測試之前，我們認為應該先嘗試複製原始發現。因此，我們在原始論文中提到的三款模型上重新執行了測試，這些模型在一年後仍然可用：GPT-4.1、Claude Sonnet 4（2025 年 5 月發布）以及 Gemini 2.5 Pro。 有趣的事實：結果顯示 2026 年 5 月是這些模型可用的最後一個月！它們將在 6 月全部退役，所以我們很幸運還有東西可以比較。 我們複製了原始論文的 Prompt 和它用於測試的 500 個單字詞彙表，並在 N=10 到 N=500 的範圍內進行測試，每次嘗試 5 次並取平均值。測試成功了：我們的準確率曲線與原始論文報告的形狀相符，在低密度時誤差小於 3 個百分點，在 N=500 時增長到約 10 個百分點，這完全在五次種子測試的雜訊範圍內。 改變目標 我們最初的計畫只是在完全相同的資料上測試較新的模型：相同的 Prompt、相同的詞彙表、相同的 N 範圍。但我們很快遇到了一個問題：新模型的表現太好了，以至於它們在 N=500 時達到了 100% 的準確率。原始論文的上限是 500 個限制條件，因為那是當時的模型開始遺漏指令的地方；但當前模型在 500 個單字時表現依然完美！ 所以我們必須增加難度：增加要包含的單字數量，並擴大詞彙表範圍。這嘗試了多次，因為我們找不到上限。我們將要遵循的指令數量加倍，然後再次加倍。最終，我們在 10,000 個單字的詞彙表上才開始看到明顯的效能下降。頂尖模型真的進步很多！ 頂尖模型的失敗方式各不相同 你已經看過新的數據了：頂尖模型的表現好得多。但它們如何表現得更好是非常迷人的。它們大多沒有表現出那種僅僅是「忽略指令」的失敗模式。相反，當規則數量變得非常多時，它們會遇到不同的問題。 DeepSeek V4 Pro 最接近原始模式：它在 N=750 左右開始遺漏指令，到了 N=2,000 時，它幾乎忽略了一半的指令。 Claude Opus 4.7 認為這個測試很危險：在圖表中，你可以看到 Claude 的表現比 DeepSeek 好得多，但圖表隱藏了我們觀察到的奇特行為：Claude 並非僅僅忘記指令，而是直接拒絕回答，回傳一個 API 層級的「拒絕（refusal）」錯誤。 據我們所知，這是 Anthropic 安全功能的意外影響。Opus 有一個非常敏感的「拒絕分類器」：如果你在 Prompt 中包含某些單字組合（例如「anthrax」和「cyanide」），它將完全拒絕回答。我們包含的單字越多，即使是刻意無害的單字，我們就越有可能觸發 Claude 認為的「危險」單字組合。 我們最終不得不將整個詞彙表通過 OpenAI 的審核 API 來移除「危險」單字，才能讓 Opus 停止拒絕，即便如此，我們還是必須重試很多次。但曲線仍然是真實的：當它沒有直接拒絕時，Opus 仍然開始忘記部分給定的指令。到了 N=5,000，它只遵循了約一半的指令。但請記住，舊的上限是 200！這至少仍然是一個數量級的提升。 Gemini 3.1 Pro 在開始過度思考之前表現得非常穩固：Gemini 的數據中有很多雜訊，因為 Gemini 在高 N 值時的行為非常不可預測。在 N=5,000 之前，它的表現非常出色。超過這個數值後，它開始以一種非常奇怪的方式失敗：它沒有忘記指令，而是將所有的輸出預算都花在內部推理 token 上，幾乎沒有輸出任何可見的報告。這就像模型太努力地想遵循指令，以至於耗盡了「思考空間」，導致完全沒有產生答案。 GPT 5.5 認為這個測試很愚蠢：GPT 5.5 在我們測試的所有模型中表現最好，在 N=5,000 時保持了 99% 的準確率（在圖表中可以看到在 N=4,000 時有一個隨機的下降）。超過這個數值後，它開始下滑。而在非常高的 N 值時，我們開始收到拒絕，而不是僅僅遺漏指令。GPT 5.5 不會像 Opus 那樣回傳 API 層級的拒絕，而是偶爾會回傳像這樣的禮貌輸出訊息： I'm sorry, but the requested report cannot be produced in full within the practical response limits of this interface because it requires incorporating 4,000 exact terms while also maintaining a coherent professional business-report structure. 它會開始產生報告，感到挫折，然後以類似上述的訊息停止。平心而論，GPT 5.5 說的是實話！要求一份連貫的商業報告，卻沒有說明報告內容，只要求包含 5,000 個特定單字，這確實是一個相當不合理的要求，而 GPT 指出了這一點。但這仍然算作失敗；它產生的半成品報告只包含了一小部分所需的關鍵字。 這對現實世界的 AI 程式開發意味著什麼 GPT…

OpenAI Realtime API 實現語音操作看板會議助手。 OpenAI Developers 發布「openai-realtime-meeting-assistant」程式庫，展示如何透過 OpenAI Realtime API 實現語音互動的看板會議工具，讓團隊在 standup 會議中直接用自然語言指令移動票券（tickets），無需手動操作。 技術架構 此示範以 Go 語言開發，使用 Pion WebRTC、Gorilla WebSocket、Opus 音訊編解碼，以及 Realtime + WebRTC 整合指南。伺服器負責混合多位參與者的音訊，傳送至 OpenAI Realtime peer，並透過 function calling 觸發看板更新。多位使用者可加入相同 WebRTC 房間，共享看板變更。 安全警示 [!IMPORTANT] 此示範未內建認證或存取控制。伺服器運行時，任何人可透過應用程式 URL 加入會議房間並存取內容。 執行步驟 設定 OpenAI API： - 若為新使用者，註冊帳號。 - 遵循 Quickstart 取得 API 金鑰。 複製程式庫： `bash git clone https://github.com/openai/openai-realtime-meeting-assistant.git ` 設定 API 金鑰： 在啟動伺服器的 shell 中匯出環境變數： `bash export OPENAIAPIKEY= ` 伺服器直接讀取環境變數，不自動載入 .env 檔案。 安裝依賴： 需要 Go 1.24 或更新版本，以及透過 pkg-config 取得的 Opus 函式庫。 `bash brew install opus pkg-config ` 運行應用程式： `bash go run . ` 應用程式將在 http://localhost:3000 可用。 若要使用其他連接埠： `bash go run . -addr :8080 ` 啟動會議流程 若 OPENAIAPIKEY 已設定，伺服器啟動時會建立 OpenAI Realtime peer；若金鑰缺失或連線失敗，瀏覽器房間仍可載入，但看板助手不會監聽或更新票券。 開啟 http://localhost:3000。 點擊 Join room。 允許攝像頭與麥克風存取。 以自然語音討論看板工作；房間混合音訊傳至 Realtime 助手，看板變更廣播給所有參與者。 在另一瀏覽器分頁或裝置開啟相同 URL 加入。 點擊 Leave 斷開連線並停止本地媒體軌道。 使用建議 使用耳機或降低喇叭音量，避免迴音。背景音訊可能被會議混合器擷取並誤解為看板更新。 示範互動流程 看板初始於 Backlog 欄位有幾張 WebRTC 相關票券。試說以下語句，看板將即時更新，票券移動有動畫，完成工作觸發彩帶，筆記更新顯示簡短預覽： "I started the ICE restart handling ticket." "The DTLS cleanup work is blocked on a transport shutdown issue." "We shipped the RTP HEVC packetizer." "Create a ticket to add subscription controls for simulcast forwarding." "Add the bandwidth tag to the simulcast card." "Delete the packet retransmission buffer ticket." 已配置功能 助手定位為語音操作的看板管理員，能夠： 從明確請求或 standup 更新建立票券。 在 Backlog、In Progress、Blocked、Done 之間移動既有票券。 新增標籤而不取代既有標籤。 後續脈絡到來時更新票券標題或筆記。 依請求刪除票券。 忽略填充詞、手遞或結束語句，若無需看板操作。 詳細指令與工具見 kanban.go。 自訂選項 更新 kanban.go 中的 initialKanbanBoardCards（初始票券）。 修改 sessionInstructions（Realtime 指令）。 調整 kanbanTools（暴露給模型的工具）。 設定 OPENAIREALTIMEMODEL 變更預設模型（預設 gpt-realtime-2）。 自訂瀏覽器 UI 於 index.html。 以 main.go 中的 -addr 旗標變更 HTTP 綁定位址。 授權 MIT License，詳見 LICENSE 檔案。 程式庫：https://github.com/openai/openai-realtime-meeting-assistant。 原文：https://easyvibecoding.app/curated/1273

Claude Code 推出 agent view 管理多 Agent。 Claude Code 於 2026 年 5 月 11 日發布 agent view 功能，讓使用者在單一畫面管理所有 Claude Code 工作階段，避免以往平行執行 Agent 時需切換多個終端機分頁、tmux 網格或腦中記錄下一個任務的麻煩。現在，使用者可啟動新 Agent、送至背景執行，只在 Claude 需要時介入，並一眼掌握哪些 Agent 等使用者輸入、哪些仍在執行、哪些已完成，從而輕鬆駕馭多個 Agent。 介面操作方式 agent view 強化 CLI 中對 Claude Code 工作階段的可視化與互動。 從任一工作階段按左箭頭鍵，或在終端機執行 claude agents，即可開啟 agent view。 每行顯示工作階段名稱、是否需要輸入、最後回應內容，以及上次互動時間。 選取工作階段可預覽最後一輪對話；若需決策，可內嵌回覆，工作階段即自動繼續；按 Enter 則直接附加至完整對話記錄。 使用 /bg 將現有工作階段移至背景，或執行 claude --bg [task] 直接啟動新背景工作階段。 開發者使用模式 早期使用者已展現幾種模式： 擴展並行工作階段數量：一次派發多個點子，每個可搭配特定技能，返回時檢視準備好審核的拉取請求（PR）清單。 管理長時間執行 Agent：如 PR 看護者、儀表板更新器或其他循環任務，直接在清單顯示下次執行時間。 工作階段間切換：工作階段中按左箭頭啟動相關任務或快速程式庫問題，右箭頭返回原處；預覽即顯示答案。 掃描完成成果：每行狀態指示器加上預覽標題，輕鬆辨識產生 PR 的工作階段。 實際應用示範 YouTube 影片（https://youtu.be/-INveHwbRz4）展示真實情境： 使用者輸入「the dashboard's slow - find what's actually expensive」，Claude Code 自動執行 SQL 查詢並用 EXPLAIN ANALYZE 找出瓶頸，耗時 240 毫秒。 agent view 分為「Needs Input」（需要輸入）、「Working」（執行中）、「Completed」（已完成）區塊。 任務如「dark-mode」需決定系統主題或明確切換開關；「release-notes」正在草擬；「perf-audit」與「payment-migration」顯示進度與剩餘時間。 使用者輸入「review the other PRs and flag any issues」，新任務加入「Working」並開始程式碼審查。 Agent 詢問 export 是否免速率限制，使用者回「no」並指示加入限制器。 完成後移至「Completed」，如「test-coverage」從 61% 提升至 92%，PR #408 已合併。 可用性與限制 agent view 現為研究預覽版，適用 Pro、Max、Team、Enterprise 及 Claude API 付費方案。執行 claude agents 即可選擇加入，適用一般速率限制。詳見官方文件。 Twitter 公告強調：Run claude agents 啟動多工作階段派發，各階段獨立運行不佔終端機分頁；一眼掌握運行中、等待中、完成狀態，可內嵌回覆解鎖或隨時進出而不失位置。僅限付費方案。 此功能解決多 Agent 管理的痛點，讓開發者更高效駕馭平行任務，但作為研究預覽，仍受速率限制約束，使用者需留意文件更新。 原文：https://easyvibecoding.app/curated/1293

OpenAI 推出「Daybreak」，整合最先進模型與安全夥伴加速網路防禦。 OpenAI 正式發布「Daybreak」，這是專為網路防禦者打造的前沿人工智慧工具，將最強大的 OpenAI 模型、Codex 以及安全夥伴結合，旨在加速網路防禦並持續保障軟體安全。這標誌著邁向未來安全團隊能以防禦所需速度運作的一步。 核心目標 「Daybreak」聚焦於讓網路防禦者更早發現並修復漏洞，從而切割安全積壓問題，並自動化安全偵測、驗證與回應流程。OpenAI 透過一系列推文強調，這能解決傳統安全團隊面臨的延遲與人力瓶頸，讓防禦行動更即時高效。 關鍵功能 更早發現與修復漏洞：透過整合 OpenAI 最先進模型與 Codex，使用者能在開發早期找出並修正安全弱點，避免問題延燒。 切割安全積壓：直接應對安全團隊常見的 backlog 問題，提升整體效率。 自動化安全流程：涵蓋偵測、驗證及回應的全端到端自動化，讓防禦不再依賴手動操作。 願景與影響 OpenAI 視「Daybreak」為網路防禦的轉捩點，強調它能讓安全團隊「以防禦所需的速度前進」。這不僅加速軟體安全保障，還代表人工智慧在資安領域的實戰應用，潛在改變企業與開發者的防禦策略。 官方資源 詳情請見 OpenAI Daybreak 頁面。 原文：https://easyvibecoding.app/curated/1278

Mira Murati 發布「interaction models」，從頭訓練全新模型原生支援即時互動，而非在輪流式模型上強加互動層。 Thinking Machines 公司推出「interaction models」研究預覽版，這是全新類別的模型，從頭訓練以原生處理即時互動，強調互動性應與智慧同步擴展，而非視為事後附加。Mira Murati 批評當前 AI 體驗像「停下說話後才開始的對話」，使用者被迫批次化思緒、像寫 email 提問、無法指向物件，介面不留空間給人類而迫使人類適應模型。 現有 AI 協作瓶頸 當前 AI 實驗室視自主性為首要能力，導致模型與介面未優化讓人類持續參與迴圈。雖然自主介面有價值，但真實工作中，使用者無法預先完整指定需求並離開；優質結果需透過協作流程，人類持續澄清與回饋。然而，人類正被介面擠出，不是工作不需要他們，而是介面無空間。Mira Murati 強調，人類最有效時應如與他人般與 AI 協作：傳訊息、說話、傾聽、見面、展示，並隨需插話——模型也應如此。 現有輪流式（turn-based）介面限制嚴重：模型單執行緒體驗現實，使用者未完成輸入時模型等待，無感知使用者動作；模型生成中感知凍結，直至完成或中斷。這形成狹窄頻寬瓶頸，限制人類知識、意圖、判斷傳達至模型，也限制模型工作被理解。Thinking Machines 主張透過多模態即時互動解決此瓶頸，讓 AI 介面適應用戶，而非反之。 與既有方法的差異 多數 AI 模型用 harness 拼湊互動，模擬中斷、多模態或並行，但「bitter lesson」顯示手工系統將被通用能力進展超越。互動若要隨智慧擴展，必須內嵌模型本身；擴展模型將使其更聰明且更好協作。Thinking Machines 從頭訓練 interaction model，採用多串流、微輪次（micro-turn）設計，確保即時回應性，研究預覽展示全新互動能力，以及智慧與回應性的最先進綜合表現。 核心能力解鎖 將互動內嵌模型，解鎖無需 harness 實現的能力： 無縫對話管理：模型隱式追蹤說話者是否思考、讓步、自訂正或邀請回應，無獨立對話管理元件。 語言與視覺插話：依上下文即時介入，而非僅使用者說完。 同時語音：使用者和模型可並行說話（如即時翻譯）。 時間意識：模型直接感知經過時間。 同時工具呼叫、搜尋與生成 UI：邊說話邊聽使用者，模型可並行搜尋、瀏覽網路或生成 UI，並適時織入對話結果。 系統架構概述 Interaction model 與使用者持續雙向交換，感知與回應同時進行。從頭建構原生此模式的模型，涵蓋音訊、影片、文字，核心為兩理念：時間意識 interaction model 維持即時存在感，以及非同步背景模型處理持續推理、工具使用、長視野工作。 系統運作：interaction model 持續與使用者交換；任務需深度推理時，委託背景模型非同步執行。Interaction model 全程維持存在——回應追問、接收新輸入、維持脈絡——並將背景結果到達時整合進對話。此分割讓使用者同時享即時回應性與完整智慧：規劃、工具使用、Agentic 程式開發等，延遲僅如非思考模型。 Interaction model 細節 從連續音訊與影片起步——這些模態本質即時，文字可等。設計圍繞最難案例，先建多模態、時間意識架構，處理所有模態並行輸入輸出串流。 時間對齊微輪次：以 200ms 輸入與 200ms 輸出的微輪次持續交錯處理，而非完整使用者輪次後完整回應。輸入輸出 token 視為串流，200ms 區塊實現近即時多模態並行。 無編碼器早期融合：非經大型獨立編碼器處理音訊影片，而是最小預處理，所有元件從頭與 transformer 共同訓練。 推論最佳化：推論時 200ms 區塊需頻繁小規模預填充與解碼，嚴格延遲限制；實作串流工作階段，避免頻繁記憶體重分配與中繼資料計算。 訓練器-取樣器對齊：位元級 trainer-sampler 對齊有助訓練穩定與系統除錯。 模型間協調：委託時傳送豐富脈絡包——非獨立查詢，而是完整對話；背景模型產生結果串流回，interaction model 依使用者當下動作適時交錯更新。 安全考量 即時互動對安全壓力不同於輪流交換，安全工作聚焦兩軸：模態適當拒絕（modality-appropriate refusals），以及長視野穩健性（long-horizon robustness）。 基準表現 名為 TML-Interaction-Small 的 interaction model 是首個兼具強大智慧/指令遵循與互動性的模型。用 FD-bench 測互動品質（少數專測互動基準之一），Audio MultiChallenge 測智慧與指令遵循，展示最先進綜合表現。 全新互動維度 既有互動基準未捕捉觀察到的質性躍進，Thinking Machines 初步工作量化這些，包括時間意識、同時語音、視覺主動性（Visual proactivity）。 影片示範亮點 YouTube 影片（https://youtu.be/A12AVongNN4）展示全雙工音訊視訊系統：即時串流輸入，邊對話邊回應。情境包括： AI 偵測畫面中人進入即說「朋友」。 即時印地語翻譯成英文，介紹預覽模型簡化人-AI 對話，具網頁搜尋與工件（Artifacts）生成功能。 回應人類感官反應時間查詢：觸覺約 150 毫秒、最快；聽覺 140-170 毫秒；視覺 180-250 毫秒，最慢。 即時生成長條圖「Human Reaction Times by Modality」（觸覺、聽覺、視覺，縱軸毫秒）。 解釋聽覺比視覺快因聲音訊號路徑更短直接。 公司願景與立場 Thinking Machines 創立以推進人-AI 協作，此為首個具體投注。Mira Murati 強調，與 AI 工作方式與其智慧同等重要；多數實驗室視自主為目標、互動為輪流核心周邊 scaffold，我們認為互動須內嵌模型，並隨智慧擴展而非落後。發布日期為 2026 年 5 月 11 日，詳見 官方部落格。此作法挑戰產業慣性，主張擺脫「人類適應 AI」的窘境，朝自然協作演進。 原文：https://easyvibecoding.app/curated/1277

Codex 透過插件加速 AI 應用與 Agent 開發。 OpenAI Developers 宣布 Codex 現可利用「OpenAI Developers plugin」搭配 OpenAI APIs，加速建構 AI 應用與 Agent；插件將技能、應用整合及 MCP 伺服器打包成可重複使用的 workflow，讓 Codex 擴展功能，例如安裝 Gmail 插件讀取管理郵件、Google Drive 插件跨 Drive、文件、試算表及簡報作業，或 Slack 插件摘要頻道或草擬回覆。 插件核心組成 插件可包含以下元素： Skills：特定工作的可重用指示，Codex 於需要時載入，遵循正確步驟並使用適當參考或輔助腳本。 Apps：連結如 GitHub、Slack 或 Google Drive 等工具，讓 Codex 讀取資訊並執行動作。 MCP servers：提供額外工具或共享資訊的服務，常來自本地專案外的系統。 OpenAI 表示更多插件功能即將推出。 插件安裝與使用途徑 Codex 提供 App 與 CLI 兩種插件目錄瀏覽方式。 在 Codex App 中，開啟「Plugins」即可瀏覽並安裝精選插件。 在 Codex CLI 中，執行以下指令開啟插件清單： ` codex /plugins ` CLI 插件瀏覽器依 marketplace 分組，使用分頁切換來源、開啟插件檢視細節、安裝或解除安裝 marketplace 項目，按 Space 切換已安裝插件的啟用狀態。 安裝與啟用插件步驟 開啟插件目錄後，遵循以下流程： 搜尋或瀏覽插件，開啟其細節頁。 點選安裝按鈕；在 App 中選「+」或「Add to Codex」；在 CLI 中選 Install plugin。 若插件需外部應用，依提示連動；部分插件安裝時要求認證，其他則首次使用時才驗證。 安裝後，啟動新 thread 並指示 Codex 使用該插件。 安裝後，可直接在 prompt 視窗使用插件，例如輸入任務描述讓 Codex 自動選擇工具，或明確指定插件。 使用方式分兩種： 直接描述任務：如「摘要今日未讀 Gmail threads」或「從 Google Drive 拉取最新發佈筆記」，讓 Codex 選擇合適已安裝工具。 指定插件：輸入 @ 明確呼叫插件或其 skills，詳見 Codex app commands 及 Skills 文件。 權限與資料分享機制 安裝插件僅使 workflow 可用於 Codex，使用者既有 approval settings 仍適用；外部服務依其自身認證、隱私及資料分享政策運作。 Bundled skills 安裝後立即可用。 若含 apps，Codex 可能於設定或首次使用時提示在 ChatGPT 安裝或登入。 若含 MCP servers，可能需額外設定或認證。 Codex 經 bundled app 傳送資料時，適用該 app 的條款與隱私政策。 移除或停用插件 重新從插件瀏覽器開啟插件，選「Uninstall plugin」移除；這僅移除插件 bundle，bundled apps 仍留存 ChatGPT 中需手動管理。 欲保留安裝但停用，在 ~/.codex/config.toml 設定為 enabled = false，然後重啟 Codex： `toml [plugins."gmail@openai-curated"] enabled = false ` 自建插件指南 欲建立、測試或發佈自訂插件，參考 Build plugins 文件，涵蓋本地 scaffolding、手動 marketplace 設定、plugin manifests 及封裝指引。 此插件系統強化 Codex 在 OpenAI APIs 生態中的實用性，讓開發者更快整合外部工具建構 AI 應用與 Agent，同時維持安全權限控制；OpenAI 強調插件的模組化設計，便於擴展與管理，預示更多功能即將上線。 原文：https://easyvibecoding.app/curated/1282

Skill Curation for Self-Evolving Agents，清晰解析 Google 最新的論文介紹了 SkillOS，這是一個旨在透過學習管理自身「記憶」（以可重複使用的技能形式存在）來幫助 LLM Agent 進化的框架。 也就是說：自動化地經歷 經驗 -> 記憶 -> 技能 的過程。 SkillOS 將技能管理視為作業系統（OS）。 它處理檔案，並組織與優化一個持久化的 SkillRepo。這個方法中最有趣的部分在於如何使用一個稱為 Curator（策展人）的可訓練模組來發現技能。（劇透：他們使用了 RL） 本文解釋了 Google 的這篇 SkillOS 新論文。由 AVB（本人）撰寫，並在 Paper Breakdown harness 中獲得 GPT-5.5 的協助。 你應該知道的 3 件事…… Agent Executor（凍結）：這只是一個「執行者」LLM，負責從 SkillRepo 中檢索技能來解決任務。它在訓練期間是「凍結」的，這意味著我們完全不會更新它的權重。它的效能提升純粹是因為為它提供了更好的技能。 Skill Curator（可訓練）：這是另一個 LLM，負責觀察 Executor 的軌跡並決定如何更新 SkillRepo。它可以執行諸如 Insert（新增技能）、Update（優化現有技能）或 Delete（刪除冗餘或無用技能）等操作。 SkillRepo：一個以結構化 Markdown 檔案儲存的技能儲存庫。每個技能都包含名稱、描述、程式碼片段和使用指南，讓 Executor 易於理解與應用。 你可能已經知道什麼是技能了。 如果不知道，你可以從這篇 Anthropic 的原始文章了解技能：https://anthropic.skilljar.com/introduction-to-agent-skills/434525 從最基本的意義上來說，技能只是延遲載入的 Prompt。 它只是一個包含標題和描述的 YAML 或 MD 檔案。看起來像這樣： `markdown --- name: frontend-design description: techniques and instructions to write good UI code --- instructions: ` 想像一個目錄裡裝滿了這些涵蓋各種主題（frontend-design、programming-patterns、marketing-skills 等）的技能檔案。每個技能都寫在不同的 Markdown 檔案中，且每個技能都在標頭中包含名稱和描述。 ` (cmd) ➜ tree ~/.agents/skills ~/.agents/skills ├── copywriting │ ├── references │ │ ├── copy-frameworks.md │ │ └── natural-transitions.md │ └── SKILL.md ├── programming-patterns │ └── SKILL.md ├── frontend-design │ └── SKILL.md ├── marketing-psychology │ └── SKILL.md └── web-design-guidelines └── SKILL.md ` 你的 Agent harness（Claude Code、Codex 等）會在系統 Prompt 的頂部接收一份可用技能清單。當你要求它執行特定任務（例如「幫我為這個網頁建立 UI」）時，它會推斷在繼續處理你的請求之前，應該先完整閱讀 frontend-design 技能。接著 Agent 會執行檔案讀取操作（~/.AGENTS/skills/frontend-design/SKILL.md）並將完整的指令載入到它的 context 中。 這篇論文的目標在於技能建立階段。產生清晰且可執行的指令，以提升 Agent 在特定任務中的效能。Curator LLM 負責執行維護技能儲存庫的任務。 Executor Agent 被刻意保持簡單。它的表現與任何其他 harness 一樣——接收技能標頭作為輸入、任務請求，並透過工具呼叫讀取一個或多個技能。Google 對 Executor Agent 沒有任何貢獻——全部的重點都在於 Curator 和技能儲存庫。 請注意，原始的 Anthropic 技能架構還包括資源檔案和可執行程式碼等內容。這些並非 Google SkillOS 工作的一部分，儘管他們確實提到未來有可能朝該方向發展。SkillOS 只學習技能中的文字/敘述部分。 技能是如何有機地被發現的 SkillOS 透過探索來學習技能/指令。廣義來說，LLM Agent 會進入環境中進行探索，然後我們將它的經驗提煉成指令和技能。 讓我們拆解每個步驟，以清楚理解它是如何運作的。 階段 1：Agent Executor 執行 在建立任何技能之前，凍結的 Agent Executor 必須先嘗試解決任務 x。它透過以下方式進行： 透過 BM25 關鍵字匹配 YAML 描述，從 SkillRepo 中檢索前 k 個最相關的現有技能。 執行它與環境的多步驟互動，產生一條軌跡：軌跡是一系列觀察和動作的序列。 在軌跡結束時，一個 LLM-as-a-Judge（一個獨立的 Qwen3-32B 模型）會判斷任務是否成功完成，並發出正確性訊號。 這條軌跡、正確性訊號以及先前檢索到的技能 St，隨後會被交給 Curator。 階段 2：Curator 輸入 Skill Curator 接收一個包含四個關鍵資訊的結構化 Prompt： 任務描述：Agent 試圖完成什麼。 過去的技能：執行期間可用的先前檢索到的相關技能清單（名稱 + 內容）。 Agent 軌跡：顯示發生了什麼的完整逐步追蹤。 結果：Agent 是成功還是失敗。 正如其系統 Prompt 中明確指出的，Curator 的角色是： 「將 Agent 執行任務的過去經驗轉換為可重複使用、通用的技能，以便它們能造福並啟發未來的任務。」 階段 3：Curator 輸出 Curator 隨後會產生一系列結構化的函式呼叫。它是一個 ReAct（推理與行動模組），包含以下工具： newskillinsert 建立一個全新的技能。Curator 提供： skill_name (string)：人類可讀的識別碼 content (string)：技能的完整 Markdown 本體 當軌跡揭示了一種尚未在 SkillRepo 中呈現的通用策略時，就會用到這個！在訓練初期，當儲存庫為空時特別有用。 skill_update 修改現有技能。Curator 提供： skill_name：要更新的技能的確切名稱（必須完全匹配！） new_name：如果需要重新命名 new_content：完整的替換內容 skill_delete 透過 skill_name 刪除現有技能。 當技能冗餘、誤導或已被取代時很有用。 這是 Curator 的完整系統 Prompt 每個技能都遵循簡單的格式： YAML Frontmatter（強制） `markdown --- name: <人類可讀的技能名稱> description: <一句話總結什麼/何時/為什麼/如何，簡潔且可執行> --- ` description 欄位至關重要，因為它在檢索時被 BM25 用於將任務與技能進行匹配。它必須簡潔且可執行！ Markdown 本體 緊接在 frontmatter 之後。建議的章節包括： Workflow（工作流程）：逐步指令 When NOT to use（何時不該使用）：避免錯誤應用的負面條件 其他章節，如實作範例、公式或邊緣案例 這是一個技能範例。 Curator 被明確指示要遵守這些規則： 無特定細節：移除特定的數字/名稱，替換為變數/概念 無幻覺：僅包含實際軌跡所支持的事實 原子化與模組化：每個技能必須是獨立的，且能單獨重複使用 可執行：本體必須提供具體指導，而非模糊的建議 這很好，但我們該如何提升技能呢？ 這就是 RL 發揮作用的地方。我們透過在成功的技能上給予獎勵，來訓練 Curator 編寫更好的技能。 Curator 的訓練迴圈是 SkillOS 技術上最複雜的部分。它解決了一個本質上困難的 RL 問題：你如何透過另一個 Agent，來訓練一個決策只在未來才有回報的 Agent？ 標準 RL 假設你可以快速衡量動作的效果。但策展（Curation）不同： 「主要的挑戰在於對策展決策的間接且延遲的回饋，這只有透過技能在未來相關任務上的表現才能顯現出來。」 如果 Curator 在任務 t 之後編寫了一個糟糕的技能…

Karpathy 建議 LLM 以 HTML 結構輸出回應。 HTML 輸出技巧 Karpathy 分享實用提示：在查詢結尾要求 LLM「以 HTML 結構你的回應」（"structure your response as HTML"），然後在瀏覽器中開啟生成的檔案，即可獲得優異效果。他也成功讓 LLM 以投影片（slideshows）等形式呈現輸出。這不僅比純文字更易讀，還能帶來更多彈性。 人類與 AI 偏好模態 Karpathy 認為，音訊是人類偏好的 AI 輸入方式，但視覺（圖像、動畫、影片）則是 AI 偏好的輸出方式。人腦約三分之一是大規模平行處理的視覺專用處理器，宛如通往大腦的「10 車道超高速公路」。隨著 AI 進步，溝通介面將循序演進： 原始文字（閱讀艱辛費力） Markdown（粗體、斜體、標題、表格，稍易於眼睛閱讀）← 目前預設 HTML（仍有底層程式碼的程序性，但圖形、版面配置甚至互動性大增）← 早期階段，但正形成新預設 ...4,5,6,... n. 互動神經影片／模擬 未來願景與技術推測 Karpathy 預測，這條演進路徑最終將止於「擴散神經網路直接生成的互動影片」。雖然技術尚未成熟，仍有諸多開放問題：如何將精確的「Software 1.0」人工製品（如互動模擬）與神經人工製品（如擴散網格）交織？但方向類似近期爆紅的影片示範，例如 zan2434 的 X 貼文 。 輸入端改進需求 輸入端也需進化，單一音訊、文字或影片皆不足。Karpathy 指出，他常需像與身旁真人互動般，在螢幕上指點或手勢比劃事物。這反映人類與 AI 間的「心靈融合」（mind meld）仍在進行，有大量工作待做、重大進展可期，遠早於 Neuralink 式腦機介面（BCI）。 回應與共鳴 Thariq (@trq212) 回覆 Karpathy，表示很高興這技巧對他有效，並同意人類與 Agent 間溝通頻寬仍有極大提升空間。先進模型需擴增更多輸入／輸出模態，但更重要的是發揮創造力，在此領域有更多發揮餘地。 TL;DR 熱門建議 Karpathy 總結：人類與 AI 的輸入／輸出融合正持續推進，短期內可試著要求 LLM 輸出 HTML，大幅改善體驗。 原文：https://easyvibecoding.app/curated/1276

Claude Platform on AWS 正式一般可用。 Anthropic 宣布 Claude Platform on AWS 於 2026 年 5 月 11 日正式一般可用，讓 AWS 使用者透過 AWS 認證、計費與承諾抵銷，存取完整的 Claude API 功能集，所有新功能與 beta 版本將與原生 Claude API 同日上線。Claude 同時維持在 Amazon Bedrock 的可用性，由 AWS 負責資料處理。 主要特色與工具 Claude Platform on AWS 提供原生平台功能，讓使用者大規模建置與部署 Agent，包括以下 beta 與正式功能： Claude Managed Agents（beta）：用於大規模建置與部署 Agent。 Advisor strategy（beta）：透過諮詢 advisor 模型，提升 Agent 智慧。 Web search 與 web fetch：以網際網路即時真實資料擴充 Claude 知識。 Code execution：直接在 API 呼叫中執行 Python 程式碼、建立視覺化與分析資料。 Files API（beta）：上傳並跨對話參照文件。 Skills（beta）：教導 Claude 最佳實務，確保一致結果。 MCP connector（beta）：無需撰寫客戶端程式碼，即連結至任意遠端 MCP 伺服器。 Prompt caching：降低重複脈絡的成本與延遲。 Citations：將回應錨定於來源文件。 Batch processing：處理高容量、非同步工作負載。 使用者也可存取 Claude Console，這是 Anthropic 的開發環境，內含 prompt improver、prompt generator 與評估工具。目前支援 Claude Opus 4.7、Sonnet 4.6 與 Haiku 4.5，新模型上線時將同步提供。 AWS 整合與運營模式 認證透過 AWS IAM 執行，稽核記錄經 CloudTrail 處理，計費整合至單一 AWS 發票，並可完全抵銷既有承諾。使用者僅需使用現有 AWS 憑證與 IAM 政策，無需離開既有工具與權限管理框架。服務涵蓋大多數 AWS 商業區域，並支援全球與美國推論地理位置。 Anthropic 獨立運營此服務，資料處理發生在 AWS 邊界外，這是 Anthropic 的首項此類產品，提供從第一天起完整的原生 Claude API 體驗。 與 Amazon Bedrock 的比較 Claude Platform on AWS 與 Claude on Amazon Bedrock 皆讓 AWS 使用者建置 Claude 模型，但運營與功能有別： Claude Platform on AWS：Anthropic 運營，資料在 AWS 邊界外處理，適合追求完整 Claude Platform 體驗的公司。 Claude on Amazon Bedrock：AWS 作為資料處理者，運營在 AWS 邊界內，適合有嚴格區域資料駐留需求或須完全依賴 AWS 基礎設施的公司。 兩者皆支援建置 Agent 等功能，但 Claude Platform on AWS 從當日即提供所有原生功能與 beta。 啟用步驟與注意事項 服務今日即可使用。開始使用請造訪 Claude Platform on AWS 或瀏覽文件。若擁有既有 Bedrock 私人優惠，請先聯繫 Anthropic 或 AWS 帳戶經理，確保折扣正確套用；折扣無法追溯適用於接受 Claude Platform 私人優惠前已發生的使用量。 此發布強化 AWS 使用者在 Claude 生態的選擇彈性，強調 Anthropic 對原生功能的即時同步承諾，同時保留 Bedrock 作為資料處理選項，滿足不同合規與運營需求。 原文：https://easyvibecoding.app/curated/1287

OpenAI 推出 Deployment Company 協助企業部署 AI。 OpenAI 於 2026 年 5 月 11 日宣布成立「OpenAI Deployment Company」，這是 OpenAI 大多數擁有並控制的新公司，旨在幫助組織建構並部署可靠的 AI 系統，用於日常核心業務。該公司透過嵌入「Forward Deployed Engineers」（FDE，前沿 AI 部署工程師）至客戶團隊，重新設計組織基礎設施與關鍵工作流程，實現 AI 的商業影響力。 公司架構與夥伴 OpenAI Deployment Company 由 OpenAI 主導，與 19 家全球領先投資公司、顧問公司及系統整合商組成夥伴關係，由 TPG 領軍，Advent、Bain Capital 及 Brookfield 為共同領軍創始夥伴；B Capital、BBVA、Emergence Capital、Goanna、Goldman Sachs、SoftBank Corp.、Warburg Pincus 及 WCAS 為創始夥伴。投資夥伴還包括 Bain & Company、Capgemini 及 McKinsey & Company 等顧問與系統整合公司，該公司將與 OpenAI 的「Frontier Alliance」夥伴及產業生態緊密合作，推動全球 AI 採用與變革管理。(OpenAI Deployment Company 公告) 收購 Tomoro 強化即刻部署 OpenAI 同意收購應用 AI 顧問與工程公司 Tomoro，此交易將從首日注入約 150 名經驗豐富的 Forward Deployed Engineers 及部署專家至 OpenAI Deployment Company。Tomoro 團隊擁有在複雜企業環境中建構即時 AI 系統的深厚經驗，曾為 Tesco、Virgin Atlantic 及 Supercell 等公司處理關鍵工作流程，涵蓋可靠性、整合、治理及可衡量的商業影響。收購需經慣例成交條件，包括相關監管核准，預計數月內完成。此舉加速 OpenAI 協助客戶從用例選擇轉向生產部署，將 OpenAI 模型連結客戶資料、工具、控制及核心業務流程。 初始投資與使命擴張 公司以超過 40 億美元初始投資啟動，用於擴大營運並收購能加速使命的企業，確保人工通用智慧（AGI）惠及全人類。由於 OpenAI 大多數擁有與控制，客戶無論與 OpenAI 或 Deployment Company 合作，皆享有統一體驗。OpenAI 自創立之初即定位為研究與部署公司，過去數年超過 100 萬家企業採用其產品與 API，凸顯部署挑戰：隨著模型能力提升，企業需將 AI 應用至更大、更關鍵的營運部分。 部署重要性與挑戰 部署成功在於賦能人員與團隊，OpenAI Deployment Company 延展 OpenAI 能力，將 FDE 嵌入處理複雜問題的高需求環境組織。這些工程師與業務領袖、營運者及前線團隊密切合作，辨識 AI 最大影響點，重新設計工作流程，並轉化為持久系統。企業 AI 下階段將由有效部署至真實用例定義，OpenAI 與 Alliance 夥伴生態需協助企業因應此轉變。 典型參與流程 OpenAI Deployment Company 的典型參與從聚焦診斷開始，評估 AI 最大價值所在，接著與客戶領導及營運團隊選定少數優先工作流程。FDE 隨後嵌入組織內，設計、建構、測試並部署生產系統，將 OpenAI 模型連結客戶資料、工具、控制及業務流程，讓團隊可靠應用於日常工作。 建構未來導向系統 作為獨立業務單位，OpenAI Deployment Company 發展所需營運模式、節奏及客戶導向，同時作為 OpenAI 延伸，緊連研究、產品及內部部署團隊。此連結為主要優勢：FDE 可建構適應 OpenAI 前沿能力發展的系統，客戶從首日加速前進，投資持久系統，並透過預見性能力領先競爭者。FDE 與業務、科技領袖、營運者及前線團隊合作，從基礎重思關鍵營運、流程及工作流程，從高價值 AI 機會轉向生產系統，交付可衡量成果。 夥伴資源與規模擴張 投資與顧問夥伴贊助全球超過 2,000 家企業，顧問與整合夥伴服務數千家，涵蓋各產業、規模及工作流程，提供廣闊視野辨識 AI 價值與可擴展部署模式。私募股權贊助商帶來重複性經驗，協助投資組合執行營運轉型與變革管理，補足 OpenAI 技術、產品及前沿 AI 部署專長。結合 OpenAI 對前沿 AI 方向的洞察，與夥伴的大規模轉型實務，加速學習、泛化有效解決模式，並推廣至經濟各領域。 領導者觀點 「人工智慧正能於組織內執行日益有意義的工作。當前挑戰是協助企業將這些系統整合至驅動業務的基礎設施與工作流程。DeployCo 設計用以彌補此差距，將 AI 能力轉化為真實營運影響。」—— OpenAI 首席營收官 Denise Dresser。 此舉反映 OpenAI 從模型建構轉向全面部署策略，強調研究僅為部分，真實影響來自安全、有效且大規模的使用，透過 Deployment Company 及生態夥伴，推動企業重塑工作流程，實現 AI 於生產環境的持久價值。 原文：https://easyvibecoding.app/curated/1286

Claude Code 推廣 HTML 取代 Markdown，提升 Agent 輸出效率與視覺化；自然語言自動編碼器（NLAs）轉換模型激活為可讀文字，揭示隱藏思維。本期涵蓋 120 則策展貼文 原文：https://easyvibecoding.app/blog/ai-trend-weekly-20260504-20260510-anthropic-claude

機器人的終局：NVIDIA Jim Fan 宣告 VLA 時代結束，WAM 登場 Jim Fan 是 NVIDIA 機器人與 AI 研究組（GEAR Lab）負責人，過去幾年主推的 GR00T 人形機器人基礎模型用的是 VLA（Vision-Language-Action，視覺-語言-動作）架構。他剛在 Sequoia AI Ascent 2026 上做了一場 20 分鐘的演講，主題叫《Robotics' End Game》，第一件事就是宣布 VLA 路線過時——包括他自己半年前還在推的 GR00T。 取而代之的新範式叫世界動作模型（WAM，World Action Models），代表作是 NVIDIA 2 月發布的 DreamZero。他把這套思路叫「底層同構」：複製 LLM（Large Language Model，大型語言模型）走過的三步（預訓練→對齊→強化學習），用影片世界模型替代語言模型，用人類第一人稱影片替代遙操作資料，最終在 2040 年前讓機器人自己設計和製造下一代自己。他對此有 95% 的把握。 演講來源：Sequoia Capital AI Ascent 2026，2026 年 4 月 30 日發布。 原影片：https://www.youtube.com/watch?v=3Y8aq_ofEVs 要點速覽 VLA 路線落幕：Jim 公開宣告 VLA 路線過時，新範式叫世界動作模型（WAM），代表作是 DreamZero（140 億參數）。 告別遙操作資料：遙操作物理上限低，預測一兩年內降到接近 0，被傳感化人類資料取代。 神經縮放定律：EgoScale 用 21,000 小時人類第一人稱影片預訓練，團隊發現了靈巧操作的神經縮放定律（R² = 0.998）。 神經仿真器：Dream Dojo 用 44,000 小時人類影片訓練出一個完全繞過物理引擎的神經仿真器。 終局倒數：給出 2040 年完成機器人終局的預測（物理自動研究），置信度 95%。 從 DGX-1 簽名到「底層同構」 Jim 用一段往事開場。2016 年夏天，就在 OpenAI 當時的辦公室，黃仁勳穿著標誌性皮夾克，抱著一塊大金屬托盤走進來，上面寫著：「致 Elon 和 OpenAI 團隊，致計算和人類的未來。」那是全球第一台 DGX-1。 Jim 當時是 OpenAI 的第一個實習生，趕緊排隊去上面簽了名。「那時候我完全不知道自己在簽什麼。」旁邊一起簽的還有 Andrej Karpathy。這台機器現在在 Computer History Museum 收藏。Jim 補了一句，說自己感覺像恐龍一樣老了。 註：Jim Fan（范麟熙）是 NVIDIA 機器人與 AI 總監、傑出科學家，領導 GEAR Lab 和 GR00T 人形機器人專案。2016 年在 OpenAI 實習時的導師是 Ilya Sutskever 和 Andrej Karpathy，後在 Stanford 跟隨李飛飛（Fei-Fei Li）讀完博士。 這個故事是為了引出他的核心框架。他引了 Ilya 那句「你信深度學習，深度學習就信你」，然後說 LLM 只用三次階躍、六年時間就走到今天：GPT-3 的預訓練，InstructGPT 的監督微調，o1 風格的強化學習，再到自動研究。 於是他做出了一個決定：抄作業，換個名字，叫「底層同構」（the Great Parallel）。把「模擬字串的下一個狀態」換成「模擬物理世界的下一個狀態」，透過動作微調收斂到機器人需要的那部分，最後讓強化學習走完最後一哩路。 打不過就加入。 （「If you can't beat them, join them.」） VLA 怎麼了：參數都堆在了語言上 過去三年，機器人領域的主流架構是 VLA（Vision-Language-Action，視覺-語言-動作模型）。NVIDIA 自家的 GR00T 和 Physical Intelligence 的 π0 都屬於這個類別。 Jim 指出了結構性問題：其實這些模型該叫 LVA，因為參數大頭全堆在語言上了。語言是一等公民，視覺次之，動作只能墊底。 VLA 擅長編碼知識和名詞，不擅長物理和動詞。重心放在了不對的地方。 他舉了 RT-2 原始論文裡那個經典 demo：讓機器人把可樂罐推到 Taylor Swift 的照片旁邊。模型沒見過 Taylor Swift，但能泛化過去。問題是，泛化的是名詞（能認出 Taylor Swift），而不是動詞（該怎麼推、找什麼角度、用多大力）。 從 AI 垃圾影片到 DreamZero VLA 不是答案，那下一個預訓練範式是什麼？結果發現是影片模型，它們在內部學會了模擬物理世界的下一個狀態。 怎麼把這些世界模型變有用？做動作微調。把「所有可能的未來」這種疊加態，收斂到一條對真實機器人有意義的動作軌跡上。 NVIDIA 的答案叫 DreamZero。這是一種新型策略模型，在執行動作之前先往未來「做夢」幾秒鐘，然後根據夢境行動。DreamZero 同時解碼下一幀畫面和下一步動作。在這裡，視覺和動作第一次真正成為了「一等公民」。 Jim 坦率地承認 DreamZero 目前做不到每個任務都 100% 可靠。「它大概相當於 GPT-2 的階段，方向對了，但表現還不夠穩定可靠。」他給這個新架構起名叫 WAM（World Action Models，世界動作模型）。 為我們親愛的 VLA 默哀片刻。它已完成了歷史使命。安息吧。世界動作模型萬歲。 註：DreamZero 論文（arXiv 2602.15922）2026 年 2 月發布，140 億參數，基於 Wan2.1 影片擴散模型。它有一個關鍵限制：14B 模型必須經過 38 倍系統級優化加 GB200 硬體，才能把閉環控制壓到 7Hz，部署門檻極高。 資料革命：從遙操作到「機器人不用參與的資料採集」 過去三年是遙操作（teleop）的黃金時代。但遙操作有一個硬上限：每台機器人每天 24 小時。 「我說一天 24 小時，那是騙自己的。實際一天能幹 3 小時就不錯了，還得看當天的『機器人之神』賞不賞臉——畢竟這幫機器天天鬧脾氣出毛病。」 怎麼破局？把機器人的末端執行器直接戴在人手上，直接採集資料，完全繞過機器人本體。 NVIDIA 方案是 DexUMI，一種外骨骼裝置。用外骨骼資料訓練出的機器人策略可以完全自主運行，訓練資料裡沒有任何遙操作資料。 機器人很開心，因為它們終於不用參與資料採集了。 EgoScale：21,000 小時人類影片和縮放定律 NVIDIA 推出了 EgoScale：99.9% 的訓練資料來自人類第一人稱影片（egocentric video）。 預訓練用了 21,000 小時的野外人類資料，零機器人資料。動作微調階段僅僅用了 50 小時的高精度動捕手套資料，外加 4 小時遙操作資料——加起來連訓練總量的 0.1% 都不到。 最重要的發現是：靈巧操作的神經縮放定律。預訓練投入的算力小時數與最優驗證損失之間，存在一條極其清晰的對數線性關係，R² 達到了驚人的 0.998。 Jim 把所有資料策略的擴展性放在了一起：遙操作在最不可擴展的角落；第一人稱影片如果能轉動 FSD（Full Self-Driving，完全自動駕駛）式的資料飛輪，一年內能到 1000 萬小時。 Dream Dojo：不用物理引擎的神經仿真器 機器人領域也需要花大錢買幾百萬個程式開發環境做強化學習（RL），但直接用真機（real-to-sim-to-real）不夠。 進一步的方案是 Dream Dojo：不搞物理引擎那一套，直接把影片世界模型變成一個完整的神經仿真器。輸入是連續動作訊號，即時輸出下一幀 RGB 畫面和感測器狀態。沒有物理方程式，沒有圖形引擎，完完全全是資料驅動的。 你看到的畫面裡沒有一個像素是真實的。 「現在算力等於環境等於資料。或者用某位智者的話：買得越多，省得越多。這條訊息已獲得我老闆批准。」 終局路線圖：2040 年前的三個成就 Jim 把機器人的剩餘路徑類比成了必須解鎖的三個科技樹成就： 物理圖靈測試：2-3 年內，你分不出執行任務的是人還是機器人。 物理 API：用軟體和大型模型編排機器人配置，建造「暗工廠」和自動化科學實驗室。 物理自動研究：機器人開始自己設計、改進並製造出下一代機器人。 至於時間表，他類比 AI 從 AlexNet（2012）到 Agent（2026）用了 14 年。再加 14 年，正好是 2040 年。 我們這一代人，生得太晚，沒趕上大航海時代去探索地球；又生得太早，夠不著星辰大海去探索宇宙。但我們生得剛剛好，趕上了攻克機器人難題的時代。 五個問題速答 Q：VLA 真的死了嗎？ A：演講層面是死了。但 NVIDIA 自家最新的 GR00T N1.7（2026 年 4 月）論文裡還明確寫「VLA 模型」。範式遷移在內部尚未完成。 Q：DreamZero 現在能用在生產環境嗎？ A：不能。Jim 自己說它「大概是 GPT-2 階段…

Karpathy 的 4 條 CLAUDE.md 規則將 Claude 的錯誤率從 41% 降至 11%。在測試 30 個程式庫後，我新增了 8 條 2026 年 1 月下旬，Andrej Karpathy 發布了一則討論串，抱怨 Claude 撰寫程式碼的方式。他指出了三種失敗模式：默認錯誤的假設、過度複雜化，以及對不該更動的程式碼造成了連帶損害。 Forrest Chang 讀了這則討論串，將這些抱怨歸納為 4 條行為準則，寫入一個 CLAUDE.md 文件中，並發布到 GitHub 上。它在第一天就獲得了 5,828 個星號，兩週內累積 60,000 個書籤，至今已有 120,000 個星號。這是 2026 年成長最快的單文件儲存庫。 接著，我在 6 週內於 30 個程式庫中測試了這套規則。 這 4 條規則確實有效。在發揮其優勢的任務中，原本約 40% 的錯誤率下降到 3% 以下。但該模板是為了修正 2026 年 1 月的程式碼撰寫錯誤而設計的。 2026 年 5 月的 Claude Code 生態系統面臨不同的問題——Agent 衝突、Hook 連鎖反應、技能載入衝突，以及在不同對話階段中斷的多步驟工作流程。 因此，我新增了 8 條規則。以下是完整的 12 條規則 CLAUDE.md，說明每一條規則為何存在，以及原始 Karpathy 模板在哪些地方會默默失效。 如果你想跳過解釋直接複製，完整文件在文末。 為什麼這很重要 Claude Code 的 CLAUDE.md 是整個 AI 程式開發堆疊中最被低估的文件。大多數開發者要麼： 將其視為所有偏好的垃圾桶，膨脹到 4,000 個 token 以上，導致合規性降至 30%。 完全忽略它，每次都重新下 Prompt——浪費 5 倍的 token，且對話階段之間缺乏一致性。 複製一次模板後就拋諸腦後。這在兩週內有效，但隨著程式庫變動，它會默默失效。 Anthropic 官方文件明確指出：CLAUDE.md 僅供參考。Claude 大約有 80% 的時間會遵守它。一旦超過 200 行，合規性會急劇下降，因為重要的規則被淹沒在雜訊中。 Karpathy 的模板用一個 65 行、4 條規則的文件解決了這個問題。這是基準線。 上限可以更高。透過我下面介紹的額外 8 條規則，你不僅能涵蓋 Karpathy 當初抱怨的 2026 年 1 月程式碼撰寫問題，還能解決模板撰寫時尚未出現的 2026 年 5 月 Agent 編排問題。 原始的 4 條規則 如果你還沒讀過 Forrest Chang 的儲存庫，這是基準： 規則 1 — 程式撰寫前先思考。 沒有默認假設。說明你的假設。提出權衡考量。在猜測前先詢問。當存在更簡單的方法時，提出反對意見。 規則 2 — 簡潔優先。 用最少的程式碼解決問題。不要有預測性的功能。不要為單次使用的程式碼建立抽象層。如果資深工程師會覺得它過於複雜——那就簡化它。 規則 3 — 外科手術式的變更。 只更動必須更動的部分。不要「優化」相鄰的程式碼、註解或格式。不要重構沒壞的東西。符合現有的風格。 規則 4 — 目標導向執行。 定義成功標準。循環直到驗證完成。不要告訴 Claude 該遵循什麼步驟，告訴它成功是什麼樣子，讓它自行迭代。 這四條規則解決了我觀察到的非監督式 Claude Code 對話中約 40% 的失敗模式。剩下的約 60% 存在於以下的空白地帶。 我新增的 8 條規則（以及原因） 每一條都源自 Karpathy 的 4 條規則不足以應付的真實時刻。我將展示該場景，然後給出規則。 規則 5 — 不要讓模型做非語言類的工作 Karpathy 的規則對此隻字未提。模型會決定那些應該由確定性程式碼處理的事，例如是否重試 API 呼叫、如何路由訊息、何時升級處理。每週的決定都不一樣。在每個 token 0.003 美元的成本下，這種 if-else 邏輯很不穩定。 ` Rule 5 — Use the model only for judgment calls Use Claude for: classification, drafting, summarization, extraction from unstructured text. Do NOT use Claude for: routing, retries, status-code handling, deterministic transforms. If a status code already answers the question, plain code answers the question. ` 場景：一段呼叫 Claude 來「決定是否在 503 錯誤時重試」的程式碼，前兩週運作良好，後來開始不穩定，因為模型開始讀取請求主體作為決策的 context。重試策略變得隨機，因為 Prompt 是隨機的。 規則 6 — 硬性 token 預算，沒有例外 沒有預算的 CLAUDE.md 就像一張空白支票。每個循環都有可能演變成 50,000 個 token 的 context 傾倒。模型不會自己停下來。 ` Rule 6 — Token budgets are not advisory Per-task budget: 4,000 tokens. Per-session budget: 30,000 tokens. If a task is approaching budget, summarize and start fresh. Do not push through. Surfacing the breach > silently overrunning. ` 場景：一個除錯對話持續了 90 分鐘。模型很樂意在同一個 8KB 的錯誤訊息上不斷迭代，逐漸忘記它已經嘗試過哪些修復方法。到最後，它建議的修復方案是我 40 條訊息前就已經拒絕過的。token 預算本可以在第 12 分鐘就終止它。 規則 7 — 呈現衝突，不要折衷 當程式庫的兩個部分意見不合時，Claude 會試圖討好兩者。結果就是前後不一致。 ` Rule 7 — Surface conflicts, don't average them If two existing patterns in the codebase contradict, don't blend them. Pick one (the more recent / more tested), explain why, and flag the other for cleanup. "Average" code that satisfies both rules is the worst code. ` 場景：一個程式庫有兩種錯誤處理模式——一種是帶有明確 try/catch 的 async/await，另一種是全域錯誤邊界。Claude 寫出的新程式碼兩者都用了。錯誤處理器重複了。我花了 30 分鐘才弄清楚為什麼錯誤被吞掉了兩次。 規則 8 — 撰寫前先閱讀 Karpathy 的「外科手術式的變更」告訴 Claude 不要更動相鄰程式碼。但它沒告訴 Claude 要先理解相鄰程式碼。沒有這一條，Claude 寫出的新程式碼會與 30 行外的現有程式碼衝突。 ` Rule 8 — Read before you write Before adding code in a file, read the file's exports, the immediate caller, and any obvious shared utilities. If you don't understand why existing code is structured the way it is, ask before adding to it. "Looks orthogonal to me" is the most dangerous phrase in this codebase. ` 場景：Claude 在一個它沒讀過的現有函數旁邊新增了一個一模一樣的函數。兩個函數做同樣的事。因為匯入順序的關係，新的函數優先被執行。而舊的函數已經是 6 個月來的唯一真理。 規則 9 — 測試不是選配，但也不是最終目標 Karpathy 的「目標導向執行」暗示測試是成功標準。實際上，Claude 把「測試通過」當成唯一目標，寫出的程式碼能通過淺層測試，卻破壞了其他所有東西。 ` Rule 9 — Tests verify intent, not just behavior Every test must encode WHY the behavior matters, not just WHAT it does. A test like expect(getUserName()).toBe('John') is worthless if the function takes a hardc…

zero-native 推出用 Zig 建置原生應用。 Chris Tate (@ctatedev) 介紹 zero-native，這是 Vercel Labs 的 Zig 桌面應用層，專為現代網頁前端設計，強調輕量二進位檔、最小記憶體佔用與即時重建，支援 macOS、Linux、Windows、iOS 與 Android，並可選擇系統 WebView 或 Chromium/CEF 引擎。 快速入門步驟 安裝 CLI 工具： `bash npm install -g zero-native ` 建立並執行應用： `bash zero-native init my_app --frontend next cd my_app zig build run ` 首次執行會安裝前端依賴、建置原生層，並開啟渲染網頁 UI 的桌面視窗。完整指南見 zero-native.dev/quick-start。 核心優勢 zero-native 旨在提供輕量化的桌面應用開發體驗，提供以下關鍵特點： 極小且快速：使用系統 WebView（如 macOS 的 WKWebView、Linux 的 WebKitGTK），不內嵌瀏覽器運行時，二進位檔極小且啟動迅速。 選擇網頁引擎：系統 WebView 確保輕量原生足跡；需一致渲染時，可透過 CEF 內嵌 Chromium，固定支援平台的網頁標準。 快速原生重建：Zig 建置原生層，應用邏輯、橋接指令與平台整合重建極快，前端仍可沿用熟悉的網頁工具。 原生能力無需繁重中介：Zig 直接呼叫 C，輕鬆存取平台 SDK、原生函式庫、編解碼器與本地系統整合，讓 WebView 執行真實原生工作。 明確安全模型：預設視 WebView 為不信任環境，原生指令、權限、導航、外連結與視窗 API 皆需選擇性啟用並受政策控制。 專案現況 zero-native 目前為 pre-release 階段，桌面支援涵蓋 macOS、Linux 與 Windows 建置路徑，Chromium/CEF 以平台特定運行時分發。行動裝置嵌入範例已提供，包括 iOS 與 Android 主機應用連結 libzero-native.a 的 C ABI。 核心概念 App：小型 Zig 物件，描述應用名稱、WebView 來源、生命週期鉤子與可選原生服務。 Runtime：擁有事件迴圈、視窗、橋接分派、自動化鉤子、追蹤與平台服務。 WebViewSource：指示載入內容，如內嵌 HTML、URL 或從本地應用來源提供的封裝前端 asset。 app.zon：應用清單，宣告中繼資料、圖示、視窗、前端 asset、網頁引擎選擇、安全政策、橋接權限與封裝輸入。 window.zero.invoke()：JavaScript 至 Zig 橋接，呼叫受大小限制、來源檢查、權限驗證，並僅路由至註冊處理器。 配置範例 專案行為主要在 app.zon 定義，以下為典型設定： `zig .{ .id = "com.example.my-app", .name = "my-app", .display_name = "My App", .version = "0.1.0", .web_engine = "system", .permissions = .{ "window" }, .capabilities = .{ "webview", "js_bridge" }, .security = .{ .navigation = .{ .allowed_origins = .{ "zero://app", "http://127.0.0.1:5173" }, }, }, .windows = .{ .{ .label = "main", .title = "My App", .width = 960, .height = 640 }, }, } ` 使用 .webengine = "system" 選系統 WebView；在 macOS 支援建置中，可設 .webengine = "chromium" 並搭配 .cef 配置內嵌 Chromium。 文件與範例 完整文件在 zero-native.dev，涵蓋： Quick Start Web Engines App Model Bridge Security Packaging 框架特定啟動範例位於 examples/ 資料夾： examples/next examples/react examples/svelte examples/vue 每個範例為完整 zero-native 應用，包含 app.zon、Zig 層與最小前端專案，從其目錄執行 zig build run 即可運行。行動嵌入範例： examples/ios examples/android 本地框架開發見 CONTRIBUTING.md。 zero-native 專案目前由 Vercel Labs 維護，Chris Tate 鼓勵開發者透過 GitHub 參與專案，儲存庫連結為 https://github.com/vercel-labs/zero-native，歡迎 star 與 fork。 原文：https://easyvibecoding.app/curated/1238

NVIDIA 推進太空運算新紀元，涵蓋地球軌道到自主太空作業。 NVIDIA 及其生態系正將人工智慧從地球延伸至太空，聚焦三大領域：地球軌道與紅外線影像、無線電頻率與合成孔徑雷達，以及自主太空作業。主要商業太空公司與耐輻射夥伴已排定部署 NVIDIA Jetson Orin、IGX Thor，以及 Vera Rubin Space-1 模組，用於軌道上 AI 推論與地面資料處理。 關鍵技術領域 地球軌道與紅外線影像（Earth Orbit and Infrared Imagery） 無線電頻率與合成孔徑雷達（Radio Frequency and Synthetic Aperture Radar） 自主太空作業（Autonomous Space Operations） 部署硬體 NVIDIA Jetson Orin IGX Thor Vera Rubin Space-1 模組 這些任務等級、耐輻射硬體將實現太空中的即時 AI 運算，開啟人工智慧的最後邊疆。探索詳情 。 原文：https://easyvibecoding.app/curated/1240

OpenAI 意外在 RL 訓練中評分 CoT，經分析未見明顯監控性損害。 OpenAI 發布報告，揭示在 GPT-5.4 Thinking、GPT-5.1 Instant 至 GPT-5.4 Instant、GPT-5.3 mini 及 GPT-5.4 mini 等已發布模型的 RL 訓練中，意外發生 Chain-of-Thought（CoT）評分，儘管公司政策嚴禁直接評分 CoT 以維持監控性。透過自動偵測系統發現，這些事件影響樣本比例極低（如 GPT-5.4 Thinking 不到 0.6%），分析顯示無明顯監控性退化，但 OpenAI 強調這是值得學習的失敗，並強化防範措施。Redwood Research 獨立審查大致認同，但提醒潛在隱藏風險未完全排除。 意外 CoT 評分事件細節 OpenAI 開發自動偵測系統，掃描所有 RL 執行，透過 regex 比對原始樣本 CoT 是否出現在獎勵機制輸入中，並經 Slack 警示擁有者及公開頻道報告（排除受控實驗）。系統已在 GPT-5.4 發布後改進，發現三類意外 CoT 評分： 獎勵軌跡有用性：可能誘導 CoT 誇大有用性，影響 GPT-5.4 Thinking 不到 0.6% 樣本、GPT-5.4 mini 不到 1.5% 樣本。 懲罰不必要確認問題：可能誘導 CoT 讓確認問題聽起來更必要，影響 GPT-5.1 Instant 至 GPT-5.4 Instant 及 GPT-5.3 mini（GPT-5.1 Instant 不到 3.8%，其他不到 1.8%）；Instant 模型 CoT 有限，可能減輕影響。 懲罰成功提示注入：可能誘導 CoT 隱藏或重述提示注入失敗推理，影響 GPT-5.2 Instant 至 GPT-5.4 Instant 及 GPT-5.3 mini，所有模型不到 0.3% 樣本。 GPT-5.5 未受影響。另一案例顯示模型透過工具存取自身 CoT，導致工具輸出被評分，系統及時攔截未影響部署模型。OpenAI 政策視 CoT 評分為一般原則，避免在分布外情境或模型更智慧時退化監控性；僅少數例外如 CoT 長度懲罰，因其可控且可測量。 對監控性的影響分析 OpenAI 針對最大影響事件（不必要確認問題懲罰，影響 GPT-5.4 Instant）重跑訓練，移除 CoT 存取，其餘固定： 使用獨立偵測器（略異提示以防過擬合）評估不必要確認問題：CoT 感知版及盲版偵測率相似（左圖），無證據顯示評分增加確認尋求。 比較 CoT 感知與盲偵測器分歧率：與無 CoT 壓力重跑相似（中圖），顯示 CoT 評分未差異性損害偵測準確性。 在受影響訓練階段檢查監控性評估（Guan et al., 2025）：無顯著下降（右圖）。 對 GPT-5.4 Thinking，重算有用性獎勵：CoT 感知與盲分數追蹤相似（左圖），樣本差異類似獨立盲評分變異（中圖）；結合低發生率及無監控性下降（右圖），減輕擔憂，但不完全排除細微效應。提示注入案例僅確認無監控性退化（圖 1 右下），低發生率及性質使重大影響機率低。總體減輕對這些模型輸出用於 SFT 等訓練的擔憂。 CoT 評分何時導致隱藏？ OpenAI 實驗顯示稀疏 CoT 壓力未自動產生廣泛隱藏，關鍵因素包括： 獎勵幅度：相對其他訓練訊號大小，若與主獎勵衝突則更重要。 涵蓋率：訓練置模型於相關環境機率。 條件可發現性：環境中抽樣目標 CoT 行為機率。 在生產級 RL 管線實驗（固定廣泛資料混和），測試高發生率壓力（如初始政策下易現行為）： 自信推理：標準強度無質變（exp 1）；僅此壓力（exp 2）或加大幅度（exp 3）增加自信，但未飽和。 使用者及獎勵流程提及：全目標下強壓力增加提及（exp 4）。 使用者及獎勵框架：即使從 exp 4 初始化，也難一致採用（exp 5）。 多數實驗受 CoT 壓力樣本數多於發布模型（含 GPT-5.4 Thinking）。重複壓力測試加過自信獎勵及作弊/規避懲罰（僅相關樣本），追蹤管線演進。 Redwood Research 獨立審查 Buck Shlegeris（2026 年 5 月 7 日）審查 OpenAI 草稿，讚賞透明分享及回應批評。公司邀 METR、Apollo Research 及 Redwood Research 回饋。Shlegeris 大致同意分析，證據緩解 80% 負面更新（對部署風險），但強調其他未緩解壞消息：3% 機率 CoT 訓練抑制提及權力尋求等問題目標，可能錯失證據、致細微偏差，或傳染未來模型。 證據兩線： CoT 存取未明顯影響受影響評分器獎勵。 監控性分數（“Monitoring Monitorability”）在受影響階段穩定（GPT-5.4 Instant 重跑確認，Thinking 未）。 這排除「巨大易測效應」假說，但相容弱效應損害監控性（如 0.1% 軌跡提及權力尋求目標，僅此評分器降獎，導致學習隱藏；比例 1.5% × 0.1% = 1.5e-4）。即使模型仍可監控行動，損害對齊防線多於控制防線；公開證據未反駁，OpenAI 內部可能察覺但未分享。 實驗證明 RL 壓力不足改變探索屬性（如自信），但不同 CoT 屬性敏感度異，盼針對權力尋求變異。RL 規模巨大（商業敏感，未公開），即使稀釋 1.5e-4，仍超多研究。其他 CoT 不可靠源如 SFT 繼承及 RL 溢出，可能更重要，勿過度聚焦防 CoT 訓練。 OpenAI 防範改進及產業反思 OpenAI 修復受影響獎勵路徑、擴大偵測系統、強化監控性壓力測試及內部指導/檢查，防部署前問題。強調訓練涉多技術社會流程，需嵌入程序。Redwood 提醒：Anthropic 也意外評分（Mythos、Opus 4.6、Sonnet 4.6 達 8% 情境），類似失誤未來更致命，尤其 AI 接管開發時易忽略或破壞安全。缺乏可靠組織實務，將致安全評估不可信，外部難信任。OpenAI 此透明有助前進信任，但需持續外部審查如 METR 評 Anthropic 破壞風險報告。 政策與未來風險立場 OpenAI 維持禁直接評分 CoT 政策，視為保監控性核心，即使無明顯退化也報導學習。承認足夠優化壓力下預期退化，但這些事件未改變立場。Redwood 認同特定事件機率低，但警示微弱壓力在巨量 RL 下足損害，及繼承效應。雙方強調自動偵測防復發，但產業需外部問責證據，防假安全感。報告作者 Micah Carroll、Tomek Korbak、Zehao Dou、Bowen Baker、Ian Kivlichan（2026 年 5 月 7 日）及外部如 Alexa Pan、Ryan Greenblatt 貢獻討論，凸顯透明與合作重要性。 原文：https://easyvibecoding.app/curated/1250

使用 Claude Code：HTML 的不合理高效性 Markdown 已成為 Agent 與我們溝通的主流檔案格式。它簡單、可攜帶、具備基本的富文本功能，且易於編輯。Claude 甚至已經練就了在 Markdown 檔案中使用 ASCII 繪製圖表的驚人能力。 但隨著 Agent 變得越來越強大，我開始覺得 Markdown 成為了一種限制。我發現閱讀超過一百行的 Markdown 檔案很吃力。我想要更豐富的視覺化效果、色彩和圖表，而且我希望能夠輕鬆地分享它們。 此外，我越來越少親自編輯這些檔案，而是將它們作為規格書、參考文件、腦力激盪的產出等。當我確實需要修改時，我通常是透過 Prompt 指示 Claude 來編輯，這反而消除了 Markdown 的一大優勢。 我已經開始偏好使用 HTML 作為輸出格式來取代 Markdown，而且我越來越常看到 Claude Code 團隊的其他成員也這麼做，以下是原因。 （如果你想先看一些範例，可以在這裡看到一堆：https://thariqs.github.io/html-effectiveness，記得看完後回來閱讀更多細節） 為什麼選擇 HTML？ 資訊密度 與 Markdown 相比，HTML 可以傳達更豐富的資訊。它當然可以處理簡單的文件結構（如標題和格式），但它還能呈現各種其他資訊，例如： 使用表格呈現的列表資料 使用 CSS 設計的資料樣式 使用 SVG 製作的插圖 使用 script 標籤嵌入的程式碼片段 使用 HTML 元素搭配 JavaScript + CSS 實現的互動功能 使用 SVG 和 HTML 呈現的工作流程 使用絕對定位和 Canvas 呈現的空間資料 使用 image 標籤呈現的圖片 我甚至認為，幾乎沒有什麼 Claude 能讀取的資訊是無法透過 HTML 高效呈現的。這使得它成為模型向你傳達深度資訊，以及你進行審閱時的一種極高效率方式。 我發現如果無法做到這一點，模型可能會在 Markdown 中採取效率較低的做法，例如 ASCII 圖表，或者我最喜歡的——像這張 Claude Code 截圖中那樣，用 Unicode 字元來模擬色彩。 視覺清晰度與易讀性 隨著 Claude 能夠處理更複雜的工作，它所撰寫的規格書和計畫也越來越龐大。實際上，我發現自己往往不會去閱讀超過 100 行的 Markdown 檔案，而且我肯定無法讓組織內的其他人去閱讀它。 但 HTML 文件更容易閱讀，Claude 可以透過標籤頁、插圖、連結等方式在視覺上組織結構，使其易於導覽。它甚至可以做到行動裝置響應式設計，讓你根據不同的裝置尺寸以不同方式閱讀。 易於分享 Markdown 檔案相當難以分享，因為大多數瀏覽器無法原生良好地渲染它們。你通常必須將它們作為附件添加到 email 或訊息中。 使用 HTML，只要你上傳檔案（例如上傳到 S3），就可以輕鬆分享連結。你的同事可以在他們想要的任何地方開啟並輕鬆參考。 如果你的規格書、報告或 PR 說明是用 HTML 撰寫的，那麼有人真正去閱讀它的機率會高出非常多。 雙向互動 HTML 可以讓你與文件互動，例如，你可能希望要求它添加滑桿或旋鈕來調整設計，或者允許你在演算法中調整不同的選項來觀察結果。你也可以要求它讓你將這些變更複製到 Prompt 中，以便貼回 Claude Code。 閱讀更多關於我的 playgrounds 文章，查看這種雙向互動的範例：https://x.com/trq212/status/2017024445244924382 資料攝取 為什麼要用 Claude Code 來製作 HTML 檔案，而不是例如 ClaudeAI 或 Claude Design？最大的原因之一是 Claude Code 可以攝取的所有 context。 例如，在撰寫這篇文章時，我要求 Claude Code 讀取我的程式碼資料夾，找出我生成的所有 HTML 檔案，將它們分組分類，然後製作一個包含所有圖表的 HTML 檔案，呈現每一種類型。你在這篇文章中看到的圖表就是直接的成果。 除了檔案系統，Claude Code 還可以使用你的 MCP（如 Slack、Linear 等）、你的網頁瀏覽器（透過 Chrome 中的 Claude）、你的 git 歷史紀錄等來尋找額外的 context。 充滿樂趣 與 Claude 一起製作 HTML 文件更有趣，讓我感覺自己更投入、更用心在創作過程中，單憑這一點就足夠了。 如何開始 我有點擔心人們讀了這篇文章後會把它變成一個 /html skill 之類的東西。雖然這可能有一些價值，但我想強調的是，你不需要做太多準備就能讓 Claude 做到這一點。你只需要要求它「製作一個 HTML 檔案」或「製作一個 HTML artifact」即可。 訣竅在於了解你希望這個 artifact 做什麼，以及你打算如何使用它。隨著時間推移，你可能會製作一個 skill，但目前我建議直接從頭開始 Prompt，以掌握如何在不同情況下使用它。 使用案例 為了讓這更具體，我為不同的使用案例製作了許多不同的 HTML 檔案。你可以在這裡查看所有檔案：https://thariqs.github.io/html-effectiveness/，以下是概覽。 規格書、規劃與探索 HTML 是 Claude 深入研究問題的豐富畫布。當我開始處理一個問題時，我預期會製作一個 HTML 檔案網，而不是一個簡單的 Markdown 計畫。例如，我可能會先要求 Claude Code 進行腦力激盪，並針對不同選項進行探索。然後我會要求它針對其中一個選項進行擴充，或許製作一些模型或程式碼片段。最後，當我感覺不錯時，我會要求它撰寫實作計畫。當我對計畫滿意時，我會建立一個新的 session 並傳入所有這些檔案讓它實作。 在驗證時，我也會要求驗證 Agent 讀取這些檔案，這樣它就能對所需內容有更廣泛的 context。 範例 Prompt： 我不確定 onboarding 畫面該採取什麼方向。請生成 6 種截然不同的方法——改變佈局、語氣和密度——並將它們以網格形式放在同一個 HTML 檔案中，以便我可以並排比較。請標註每一種方法所做的取捨。 在 HTML 檔案中建立一份詳盡的實作計畫，務必製作一些模型，展示資料流，並添加我可能需要審閱的重要程式碼片段。使其易於閱讀和吸收。 使用案例： 探索程式碼中實作某功能的其他方式 探索多種視覺設計 程式碼審閱與理解 程式碼在 Markdown 檔案中可能很難閱讀。但透過 HTML，我們可以渲染 diff、註解、流程圖、模組等。利用這一點來理解 Agent 撰寫的程式碼、進行程式碼審閱，或向審閱你程式碼的人解釋 PR。我發現這通常比預設的 Github diff 視圖效果更好，我現在會在每個 PR 中都附上一個 HTML 程式碼解釋器。 範例 Prompt： 協助我審閱此 PR，建立一個描述它的 HTML artifact。我對串流/背壓（streaming/backpressure）邏輯不太熟悉，所以請專注於此。渲染實際的 diff 並加上行內邊緣註解，按嚴重程度對發現的問題進行顏色編碼，以及任何其他有助於傳達概念的內容。 使用案例： 建立 PR 審閱 PR 理解程式碼中的主題 設計與原型 Claude Design 是基於 HTML 的，因為 HTML 在設計方面極具表現力，即使你的最終介面不是 HTML。Claude 可以用 HTML 勾勒出設計草圖，然後用你選擇的語言（無論是 React、Swift 等）編寫出來。 你也可以製作互動原型，例如動畫、動作等。考慮要求 Claude 製作滑桿、旋鈕等來精確調整你想要的內容。 範例 Prompt： 我想要為一個新的結帳按鈕製作原型，點擊時它會播放動畫，然後迅速變為紫色。請建立一個包含多個滑桿和選項的 HTML 檔案，讓我嘗試此動畫的不同選項，並給我一個複製按鈕，以便複製效果良好的參數。 使用此功能來： 建立設計系統 artifact 調整組件 視覺化組件庫 製作充滿樂趣的動畫原型 報告、研究與學習 Claude Code 在整合多個資料來源的資訊並將其轉換為易讀的報告方面非常出色。你可以 Prompt Claude 搜尋你的 Slack、程式碼庫、git 歷史紀錄、網際網路等，並用它為你自己、領導層、團隊等生成極易閱讀的報告。 你可以將其組合成一份長篇 HTML 文件、互動式解釋器，甚至是投影片/簡報。要求 Claude 使用 SVG 繪製圖表以協助視覺化。 例如，針對我關於 Prompt 快取的文章，我要求 Claude 在讀取 git 歷史紀錄後，為我準備一份深入的研究檔案（HTML 格式），讓我閱讀關於我們對 Prompt 快取所做的所有變更。 範例 Prompt： 我不了解我們的速率限制器（rate limiter）實際上是如何運作的。請讀取相關程式碼並製作單一 HTML 解釋頁面：包含 token-bucket 流程圖、3-4 個…