EasyVibeCoding Podcast

EasyVibeCoding
  • 0.0（0則評分）
  • 科技
  • 每日更新

輕鬆Vibe Coding — 每日策展的 X 技術社群精選、AI 趨勢分析與 Claude 實作心得的中文音訊版。

  1. 11 小時前

    Cognition 完成 Series E 融資逾 20 億美元，估值達 480 億美元

    Cognition 完成 Series E 融資逾 20 億美元，估值達 480 億美元。 Cognition 的融資、主動工作與模型選擇。 Cognition 表示，自五月上一輪融資以來，年化營收推估（run-rate revenue）由 4.92 億美元增至近 9 億美元。這些融資、估值與營收數字均來自公司公告；其中 run-rate revenue 並非已入帳的全年營收，公告也未提供會計認列基礎，融資與估值本身不代表已實現營收。 剪貼畫風的拼貼圖中，中央為由多個黑色六邊形組成的蜂巢狀圖形，左側帶有長條圖與折線圖的灰色背景，右側則有藍色電腦打孔卡紙圖樣。 Devin 的主動化能力 Cognition 表示，Devin 現在能採取更具指向性、也更主動的行動： Devin Auto-Triage 可先行調查事件。 Devin Security Swarm 可找出並分流漏洞。 Devin Automations 讓團隊設定由 Slack、GitHub、Linear 等系統的事件觸發工作，不必為每項工作逐一開啟對話。 企業部署 Cognition 稱，Devin 已支援 NVIDIA 的晶片設計、GE Aerospace 的航空業務、Citi 的金融服務、Mercedes-Benz 的汽車業務，以及 Modal 的 AI 基礎設施工程團隊。公司將這些採用情況描述為客戶持續擴大使用 Devin 的一部分，但公告未提供獨立的採用量或效能評測證據。 產品路線與組織策略 Cognition 認為產業仍處於「自駕軟體時代」初期，未來 Agent 將預設具備主動性，軟體可自我改善，運算預算也會依高影響力用途自動分配；人類工程師則更偏向設定目標與優先順序的架構師。為支撐這項方向，公司正在打造獨立的 agent lab，計畫依工作需求選擇並組合最合適的模型，包括自研模型，而不是讓客戶綁定單一供應商。 作者觀點與解讀範圍 Cognition 團隊成員 MattSchrage 表示，在 Cognition 的經歷讓他得到的其中一項體會是：「未來已經到來，只是分布得不平均」，並稱自己很興奮也很謙卑，能與團隊共同打造軟體工程的未來。這是第一方團隊成員的熱情表態，不是對融資、營收、客戶採用或產品主張的獨立驗證；本篇提供的來源未包含對融資與 run-rate revenue 數字的獨立核實。 原文：https://easyvibecoding.app/curated/3297-cognition-completes-series-e-funding-valuation-reaches-48

  2. 11 小時前

    Inception Labs 發布 Mercury 2.5，官方稱推理速度達每秒 1,107 tokens

    Inception Labs 發布 Mercury 2.5，官方稱推理速度達每秒 1,107 tokens。 規格、價格與聲稱的提升。 十項 benchmark 與 production 工作負載。 官方公告可參閱〈Introducing Mercury 2.5〉。 規格與定價 Mercury 2.5 的主要規格如下： 速度：在廣泛可取得的 NVIDIA GPU 上達到 1,107 tokens/sec。 context：260K tokens。 標準價格：每百萬 input tokens $0.20、每百萬 output tokens $0.75。 上線優惠：80% 折扣後為每百萬 input tokens $0.04、每百萬 output tokens $0.15。 能力：可調整 reasoning、平行 tool calls，以及 schema-aligned JSON。 公告將 Mercury 2.5 的品質與成本最佳化的 frontier models 相比，包括 GPT-5.6 Luna (Low)、Gemini 3.5 Flash-Lite 與 Claude Haiku 4.5。不過，40% 的提升是對「intelligence」的描述，原文沒有定義單一整體指標或評測方法；1,107 tokens/sec 也只註明使用廣泛可取得的 NVIDIA GPU，未提供硬體型號、服務設定、並行數或測量方法。 Mercury 2.5 宣傳短片開場以打字機排列文字點出 LLM 效能瓶頸，隨後展示其具備高推理速度與平行 token 處理能力 速度與評測 官方速度圖表列出 Mercury 2.5 為 1,107 tokens/sec，對比 Gemini 3.5 Flash Lite 的 321、Claude Haiku 4.5 的 127，以及 GPT-5.6 Luna (Low) 的 99。與 Mercury 2 的比較圖則顯示： Tau3Bench Telecom：96% 對 65% GPQA Diamond：79% 對 74% IFBench：77% 對 69% AA-LCR：68% 對 41% SciCode：38% 對 37% TerminalBench：37% 對 25% DSQA（10 次 tool calls）：34% 對 15% Omniscience Non-Hallucination：33% 對 18% Omniscience Accuracy：22% 對 24% GDPval（Elo）：21% 對 13% 因此，圖表中的 Mercury 2.5 並非在每一項指標都高於 Mercury 2；Omniscience Accuracy 反而由 24% 降至 22%。 Mercury 2.5 在速度 Benchmark 中以每秒 1,107 個 token 領先 Gemini 3.5 Flash Lite（321 tokens/sec）、Claude Haiku 4.5（127 tokens/sec）及 GPT-5.6 Luna (Low)（99 tokens/sec）。 Production 案例 Inception Labs 表示，自 Mercury 2 發布後，已有數千名開發者採用、數十家企業投入 production，使用量成長超過一個數量級。這些搜尋、voice 與 coding 工作負載的回饋和 production failure cases，被用來調整 evals 與訓練方向。 OpenCall 將 Mercury 用於 AI 電話 Agent；公告稱其 production 工作負載的模型回應中位延遲接近 170 毫秒。OpenCall 另稱，P99 回應時間從數分鐘降至 1 秒，P50 則由 0.4 秒降至低於 0.2 秒。 Augment Code 將 Mercury 用於上下文壓縮（context compaction）、模型路由與 MCP 工具搜尋。改用 Mercury 後，compaction 延遲從約 150 秒降至 27 秒，降低 82%；成本降低 90%，並維持品質，tool-search 摘要則在 1 秒內回傳。 OpenCall 與 Augment Code 的數據屬公告引用的客戶報告，提供的資料沒有包含各自的測試設定。 Mercury 2.5 在 Tau3Bench Telecom、GPQA Diamond、IFBench、AA-LCR、SciCode、TerminalBench、DSQA (@10 tool calls)、Omniscience Non-Hallucination 與 GDPval (Elo) 基準上領先 Mercury 2，但在 Omniscience Accuracy 以 22% 落後於 Mercury 2 的 24%。 新功能與取得方式 Inception Labs 同步預覽 Mercury Voice 與 Mercury Router。Mercury Voice 是針對極低延遲 voice Agent 設計的 dLLM，time-to-first-token（TTFT）低於 170 毫秒；Mercury Router 會理解輸入 prompt，再在 open 與 closed models 之間選擇品質、速度與成本組合最合適的模型。 Mercury models 已可透過 Inception API、Baseten 與 OpenRouter 使用；目前提供的資料僅證實 OpenRouter 是取得管道，沒有提供 OpenRouter 的公開 benchmark。企業部署則支援專用容量、自動擴縮、合規控管與可設定的資料保留。Inception Labs 也表示已開始訓練下一個、規模更大的模型，目標在未來數個月發布。 Mercury 2.5 宣傳短片開場以打字機排列文字點出 LLM 效能瓶頸，隨後展示其具備高推理速度與平行 token 處理能力 影片中的 Prompt 與操作： Prompt（00:17）： 用 HTML-5 產生西洋棋遊戲 原文：Generate the game of chess in HTML-5 原文：https://easyvibecoding.app/curated/3298-inception-labs-releases-mercury-2-5-hits-1107-tokens-per

  3. 11 小時前

    Magic 稱新預訓練方法以約 1/50 計算量達到 DeepSeek V4 Pro Base 水準

    Magic 稱新預訓練方法以約 1/50 計算量達到 DeepSeek V4 Pro Base 水準。 算力效率與不同規模的成本。 Base model 評測不等於後訓練產品。 成本效率 Magic 表示，這套預訓練方法以約 1/50 的 FLOPs，達到 DeepSeek V4 Pro Base 的水準，在 GB200 上的成本估算約為 50 萬美元（$0.5M），約是 GPT-3 預訓練計算量的一半。團隊再把規模擴大至 10 倍，成本約 400 萬美元（$4M），在 perplexity 評估中勝過所有公開可取得的 open base models。 Magic 的最新模型在 heldout 程式碼的 bits per byte 評測中，達到與 DeepSeek V4 Pro 相同效能時所需預訓練計算量約為其 1/48（48x less compute）。 比較方法 研究以留出的評估資料測量 bits-per-byte loss；Magic 只能對自家模型排除評估資料混入訓練的情況，無法替其他開放權重模型做同樣檢查。部分網路評估資料可能已出現在對手的訓練資料中，Magic 指出這種污染會讓比較偏向對手。這項指標能降低不同 tokenizer 對結果造成的影響，數值越低越好。Magic 再依據 scaling laws，估算模型要達到特定能力需要多少計算量，藉此比較不同訓練 recipe 的效率。評估涵蓋私有程式庫、其他新創公司取得的程式庫、研究論文，以及保留的數學推理題；公開模型的 logprobs 則以 vLLM 和 SGLang 在 GB200、GB300 上測試，並與 Fireworks 的內部推理引擎交叉確認部分基準結果。 V5 (e24) 在留出競賽數學測試集的正確率達到 72%，高於 V5 (e23) 的 31% 與 DeepSeek V4 Pro 的 65%。 成本推估限制 Magic 依 DeepSeek V4 Pro 的 recipe 推算，若要訓練出同等能力的模型，成本將超過 1 億美元（>$100M）。這是 scaling-law estimate，且來源明確說明沒有納入可取得資料量的影響，因此它描述的是計算量推估，不是實際已支付的訓練費用。研究也以 6·N·D 代表訓練 FLOPs，而非精確值；其中 N 是啟用的參數數量，D 是預訓練 token 數量。Magic 選用這個近似式，是因為部分公開模型缺少完整序列長度等資訊，不希望自行猜測。 Magic 的預訓練計算效率自 2024 年底的 V2 至 2026 年 9 月的 V5 累計提升超過 500 倍。 Base model 範圍 本文比較的對象是 base models，也就是尚未接受強化學習、監督式微調（SFT）或其他後訓練的預訓練模型。由於這些模型對 prompt 高度敏感，Magic 認為以抽樣產生答案的評估不可靠，因此改用 heldout data 的 loss 進行比較。團隊另外執行低計算量的數學 RL，並讓所有 RL 直接從 base model 開始，不使用 SFT 或 distillation；這些結果用來檢查預訓練 loss 是否能反映 post-RL 表現。 研究方法 Magic 將效率提升歸因於模型架構、優化器、訓練目標與資料整理等面向的數十項變更，並指出修正小型 bug 也能成為計算效率倍增器。團隊用 NanoGPT speedruns 快速篩選想法，但發現許多能改善小模型的做法，無法改善大型模型；相反地，一些多數大型語言模型都具備的功能，也能在不損害大規模表現下刪除。每項變更會以跨越兩個數量級計算量的 3 個模型測試，只有 power law fit 顯示可在大規模有效，才會保留。 Magic 在 167 個領域評測的算力效率相較競爭模型最佳表現各有高低，於 Inference systems 達到最高 123 倍，而在 Hindi local news 則低至 0.002 倍。 後續方向 Magic 表示，預訓練與 long-context 研究已相當成熟，下一步將擴大 long-horizon RL，讓 Agent 在部署後透過 long-context 持續學習，同時研究具備穩健理論性質的 alignment training，以及預訓練的進一步改良。團隊宣稱其目標是打造超越人類能力的 coding agents、實現 AI R&D 自動化，並表示「期待釋出這個成果」；因此本次來源呈現的是 base-model 預訓練研究，並非已發布的 posttrained 產品。 原文：https://easyvibecoding.app/curated/3301-magic-pretraining-recipe-hits-deepseek-v4-pro-base-level

  4. 11 小時前

    OpenAI 稱內部系統用 88 小時找到 Navier–Stokes 解答，再花 17 小時形式化與驗證

    OpenAI 稱內部系統用 88 小時找到 Navier–Stokes 解答，再花 17 小時形式化與驗證。 核心宣布 OpenAI 在 官方文章 中表示，內部系統產出 Navier–Stokes 存在性與光滑性問題的分析證明和 Lean formalization，主張三維流體的 Navier–Stokes 動力學能在有限時間內形成奇異點。這個問題自 1930 年代以來未解，並在 2000 年被 Clay Mathematics Institute 列為七大 Millennium Prize Problems 之一。 來源所述的情境是：一個起初靜止且光滑的流體，在施加光滑外力後，流體內部形成速度於有限時間內無界的奇異點；其能量從靜止狀態到奇異點形成的整個過程都維持有限。解答以漩渦為核心，流體旋轉並向內螺旋，中央區域逐漸拉長、收縮與加速，形狀被比喻為愈拉愈長的義大利麵。OpenAI 表示，這項結果建立了官方 Millennium Prize formulation 中的「C」及「D」敘述，並稱其解決 Navier–Stokes Millennium Prize 問題。 顯示 Navier-Stokes 相關旋渦動態的 3D 流體模擬視覺化圖形，主體由中央向上延伸的軸向軸心、呈藍色與橘色交織的細長流線組成，左側標示 inward spiral，右上方標示 axial stretching。 計算規模 OpenAI 表示，團隊在 88 小時內找到 Navier–Stokes 解答，事件時間點落在 2026 年 9 月 5 日星期六；之後又透過 GPT-6 Astra 花費 17 小時完成 Lean formalization 與驗證。整體工作使用約 10,000 個互相協作的 AI Agent，並維持前沿模型評估所採用的監控與隔離安全措施。 所有嘗試的問題合計傳送 490 萬則訊息，使用約 3,000 億個輸出 token。 Navier–Stokes 部分傳送 270 萬則訊息，使用約 1,300 億個輸出 token。 團隊先讓不同 Agent 群組處理問題的 A、B、C、D 版本，再以 Codex 整合各群組的中間成果，讓後續 Agent 探索不同方向。 一項相關的 Euler 方程式正則性問題則由近 100 個 Agent 協作約 50 小時完成反例；該問題採用的是「無外力」版本。 Navier–Stokes 的流體具有光滑外力，Euler 的結果則明確是無外力條件，兩者不能視為同一個問題或同一組假設。 模型與評測 OpenAI 表示，這次證明使用的下一代模型能力明顯高於 GPT-6 Astra；另一則公告稱，該模型在許多 benchmark 上呈現「階躍式」進步，但模型訓練仍在進行。官方圖表列出了精選未解數學問題集的通過率與測試時計算量，顯示內部模型高於 GPT-6 Astra；這是 OpenAI 的內部評測，不能據此推論所有 benchmark 的表現或外部驗證結果。 Internal Model 在精選未解數學問題集上的 Pass rate 隨 Test-time compute 增加而上升，且持續領先 GPT-6 Astra。 研究影響 社群帳號 @gdb 將這項宣布形容為 AI 與數學的重要里程碑，並期待模型產生的知識協助研究非線性 PDE；這類方程式用於描述大量物理世界現象。這是對研究用途的期待與解讀，提供的公告沒有進一步列出能直接推進非線性 PDE 研究的具體方法或成果。 安全與進展解讀 Sam Altman 表示，過去一週看著事件發生，是他在 OpenAI 歷史中最驚人的時刻之一；他認為世界已經擁有能力極強的模型，且沒預期這麼快會出現如此大規模的成果。他認為，這是迄今最能凸顯調整 AI 進展步調、確保安全之迫切性的證據。這些內容是個人反應，不是對數學證明的獨立評估。 團隊爭議 Altman 另述，OpenAI 起初以為另一組團隊也解出了 Navier–Stokes，因此希望合作發布；得知對方處理的是 Euler 而非 Navier–Stokes 後，OpenAI 表示曾提議讓對方先發布、承認其優先權，也曾提出由 Tristan 擔任 OpenAI 證明改寫版本的第一作者。Altman 說，OpenAI 偏好協調，沒有在對方未回應時立即發布，但對方以毫無根據的抄襲指控相威脅；他也表示，看過對方公開成果後，兩種方法似乎不同，且網路上流傳 Anthropic 模型解出 Millennium problem 的傳聞，是 OpenAI 嘗試這項工作的動機之一。 上述合作、溝通、抄襲指控與方法差異，都是 Altman 的第一人稱敘述，提供的資料沒有裁定抄襲是否發生，也沒有獨立比較兩套方法。 OpenAI 的官方說明另稱，研究人員與 Agent 在對方公開成果前沒有看過其工作，也未為解這道題存取特定使用者資料；但官方認為機率雖低，仍無法排除對方使用 OpenAI 產品所衍生的去識別化資料曾有助於改善模型。這是官方保留的可能性，並非已證實曾使用相關資料。 驗證邊界 目前資料呈現的是 OpenAI 內部系統的證明、證明文件與 Lean formalization；來源沒有提到數學家進行的外部同儕審查，也沒有 Clay Mathematics Institute 接受該結果。OpenAI 明確表示，不打算以這項成果申請 Millennium Prize，因此「OpenAI 宣布解答」與「數學界正式接受並授予獎項」是不同層次的主張。 原文：https://easyvibecoding.app/curated/3296-openai-internal-system-navier-stokes-solution-verified-ai

  5. 18 小時前

    Claude Code 的 prompt-audit 在 Opus 5 客服測試中降低成本 14.6%，準確率提高 5.3 個百分點

    Claude Code 的 prompt-audit 在 Opus 5 客服測試中降低成本 14.6%，準確率提高 5.3 個百分點。 三個優化方向 ClaudeDevs 在 2026 年 9 月 8 日的文章指出，降低成本不必直接犧牲結果品質，重點包括： 提高 prompt cache 命中率，避免重複計算輸入內容。 升級至 frontier Claude models 時，移除不再適用的 prompt anti-pattern。 依任務難度校準 effort，不把「更高 effort」一律視為更好。 Prompt caching 機制 Claude 會先把 prompt 預填充成內部工作狀態，也就是 key-value（KV）快取；後續請求若從相同前綴開始，就能讀取既有狀態，而不必重新計算完整輸入，快取讀取的計價也低於完整輸入。這套機制有三項關鍵限制：快取綁定特定 model、前綴內容必須逐 byte 完全一致，而且 TTL 有限；文章特別指出，5 分鐘 TTL 是從請求開始時起算。 實務上，effort 設定會寫入內容前方，因此在對話中途改變 effort 可能破壞快取；只有包括 Opus 5 與 Fable 5.1 在內的部分 Claude models，才支援不中斷快取地更新。系統提示中的動態時間戳或 ID、重新排序的工具定義，以及分支或子 Agent 的非完全相同前綴，也都可能造成 cache miss。Claude Console 與 cache diagnostics API 可顯示未命中的原因及兩次請求開始分歧的位置。 Claude Opus 5 在 prompt 快取監控面板中展現 71.3% 的快取讀取比例（較前 7 天提升 8.2%）與 12.4B 快取讀取 token 量（較前 7 天提升 11.4%），同時統計 1.2B 快取未命中 token 的原因歸因。 prompt-audit 清理結果 從舊版 Claude 遷移至 frontier models 時，原本有效的提示可能反而增加 token 消耗或導致錯誤。文章列出的常見問題包括「double-check your work」等重複驗證要求、要求模型極度詳盡的強調語、固定的 scratchpad 與逐步推理模板、過時的 few-shot 範例、互相矛盾的規則，以及較舊 Claude 世代使用的手動 thinking 設定。 顯示 Claude 平台快取層級的架構圖，從上到下依序為全域快取的 System instructions 與 Tools、專案快取的 CLAUDE.md memory、工作階段快取的 Session state，以及每回合遞增的 Messages Claude Code 可執行 /claude-api prompt-audit，掃描工作目錄中的提示詞、skills 與工具描述、呼叫 Claude API 的應用程式碼，以及 CLAUDE.md 等 Claude Code 設定。文章以 customer-support benchmark 測試 Opus 4.8 遷移至 Opus 5：六組舊 prompt 各自植入一種 anti-pattern，先只替換 model ID，再執行一次 prompt-audit。清理後平均成本降低 14.6%，準確率從 91.7% 提高至 97.0%，增加 5.3 個百分點。成本下降來自移除多餘工具呼叫與重複推理；準確率提升則包括修正已退役的 thinking 設定、消除矛盾退款規則，以及避免手動 scratchpad 與 Opus 5 內建 thinking 衝突。 經過 /claude-api prompt-audit 處理後，Opus 5 audited 以 2.93¢ 的成本達到 97.0% 的正確率，相較於 Opus 5 unaudited 提升了 5.3 個百分點並降低 0.49¢ 成本。 Effort 的成本取捨 effort 代表 Claude 願意投入多少推理、驗證與替代方案探索。不同任務的最佳點差異很大： 在 FrontierCode Diamond 最難的 50 項任務中，Claude Fable 5 以 low effort 得分 11.5%，每項任務 $5.35；max effort 得分 30.9%，每項 $19.00。得分成長為約 2.7 倍，成本則成長為約 3.5 倍。 在不使用工具的 Humanity's Last Exam 中，Claude Fable 5.1 從 low effort 的約 53%、每題約 $0.30，提升到 max effort 的約 61%、每題約 $2.23；最後增加的約半個百分點落在 benchmark 每次執行的雜訊範圍內，卻增加 46% 成本。 高 effort 可能造成過度思考、增加延遲與成本，甚至降低品質；low effort 則可能在蒐集足夠證據前停止，少做工具呼叫與必要檢查，讓答案建立在不完整資訊上。 Claude Fable 5 在 FrontierCode Diamond 上的表現隨著 effort 調高而提升，從 low effort 下每任務 $5.35 取得 11.5% 分數，增加至 max effort 下每任務 $19.00 取得 30.9% 分數（分數提升 19.4 個百分點，成本約為原本的 3.5 倍）。 hillclimb 搜尋配置 /claude-api hillclimb 會把 evaluation 拆成 train 與 test，提出設定變更，並讀取 train 中失敗的案例來修正 prompt。文章在 customer-support benchmark 從 Opus 4.8 的預設 high effort 開始，先改用 Opus 5 low effort 並套用 prompt-audit，使 train 準確率達到 98.9%，每張 ticket 成本降至 2.6 美分；接著測試 Sonnet 5 low effort，成本降至每張 1 美分，但準確率跌至 88.9%。系統根據失敗案例加入 routing 規則與退款上限交叉參照後，Sonnet 5 以相同成本回到 98.9%。 在 CursorBench 3.2 中，Claude Fable 5.1 在不同 effort 設定下的每任務成本與分數權衡表現領先 Claude Fable 5。 在未被搜尋流程看過的 14 張 held-out customer-support tickets 上，最終配置準確率為 90.5%，原始設定為 78.6%，成本約為原設定的五分之一。這項結果限定於 14 張 held-out tickets 與特定原始設定。 這張圖呈現訓練集上的工單成本與決策準確率：Opus 4.8 high effort 的起始準確率為 74.4%；切換模型並調整提示詞後，Sonnet 5 low effort 在約 1¢ 的工單成本下取得更高準確率。 cost-optimize 與基準結果 /claude-api cost-optimize 會分析 token 消耗來源，套用降低成本的調整；若提供 evaluation，還會比較不同 effort 與 model 選擇下的成本／效能。文章以 Sonnet 5 為基準，在四個公開 benchmark 報告： LegalBench：成本降低約 58%，透過共享前綴快取、low effort 與 Batch API，thinking tokens 從 102,779 降至 8,284，pass rate 維持在雜訊範圍內。 tau2-bench retail：明確放置快取 breakpoint 後，成本降低 72%，pass rate 維持平坦。 OfficeQA Pro：加入批次處理與文件快取，成本從 $136.20 降至 $64.87，約降低 52%。 SWE-bench Verified：預設設定原本已正確使用快取，改用 medium effort 並限制 Agent 只輸出幾句精簡文字後，成本降低約 55%；每項任務中位步驟數從 29 降至 17，prompt tokens 從 75.2M 降至 33.7M。 上述節省數字都對應具名 workload 與特定設定，文章未主張能套用至每個應用程式。 tau2-bench (retail)、LegalBench、OfficeQA Pro 與 SWE-bench Verified 在成本優化後，每次執行成本降低 52.4% 至 72.7%，分數變動則介於 -3.3pp 至 +4.5pp 之間。 建議使用順序 已遷移至 frontier Claude model 時，先執行 /claude-api prompt-audit 檢查既有提示詞、skills 與工具描述；需要完整成本盤點時使用 /claude-api cost-optimize；若有 evaluation 並希望搜尋成本與效能配置，則使用 /claude-api…

  6. 18 小時前

    Claude Tag：Anthropic CI/CD 故障初步分析中位數為 14 分鐘

    Claude Tag：Anthropic CI/CD 故障初步分析中位數為 14 分鐘。 核心定位 Anthropic 工程師 Sachin Malhotra 在 2026 年 8 月 18 日發布的文章中介紹，Claude Tag 已連續數月擔任 Anthropic CI/CD 故障的第一回應者；近期每起有撰寫情況報告的事件，第一份 SITREP 都由 Claude 產出，通常在 15 分鐘內完成初步分析。ClaudeDevs 於 2026 年 9 月 8 日補充，Claude Tag 會讀取 警示、metrics 與 logs，持續維護 lessons.md，讓下一次事件能參考過往經驗。 事件處理結果 Anthropic 表示，Claude 在事件開啟後產出第一份有證據支持的分析，中位數為 14 分鐘；最快的案例能在第一份報告中於 4 分鐘內指出根因。文章舉例，一項新服務約 44 個測試停止觸發，Claude 找到原因是當天早上啟用的 feature flag，並判斷回復該設定是安全的；工程師執行回復後，Claude 在 3 分鐘後確認 skip rules 已移除，錯誤率也回到基準。 setup kit Anthropic 同步分享 GitHub 上的 oncall-kit，將團隊既有的 警示討論串、pager history 與 postmortems 轉成 triage playbooks。每個 skill 都是描述單一工作的 Markdown 指令檔，例如如何分類警示或撰寫交接報告；團隊可像管理程式碼一樣審查、修改並提交這些檔案。產出的 Claude 在 incident channel 中以 read-only 方式運作，負責診斷、升級、提出修復方案與學習，不直接部署修復。 不過，oncall-kit 明確標示為 reference implementation，目前不維護，也不接受貢獻。其 10 分鐘示範使用零個連線與虛構團隊的 48 起事件歷史，只能展示設定流程與驗證機制，不能建立正式環境行為的證據。 Alert 與升級流程 Claude 並不是 detector。既有 alerting 仍負責發出警示，Claude 觀察指定的 alert channels、分類觸發的事件，並跨通道合併相關警示；repository 指出，五個 警示 常常其實屬於同一個 incident。新服務開始運作的前幾天，Claude 可分析資料與進來的警示，提出額外規則並微調過寬或過窄的規則。若新服務尚無警示，oncall-kit 則可先草擬較保守的起始規則，供人類在上線前安裝。 Alerting 本身採 deterministic 路徑，但 on-call escalation 同時具備 deterministic 與 agentic 路徑。Claude 可依 ONCALL.md 或 root oncall.md 中的條件判斷是否立即 page on-call，或只寫入早上的摘要。例如錯誤率超過 2% 且持續 5 分鐘、同時不在已知 deploy window 時，才觸發 page；其他情況則記錄到 lessons.md。Alert-watch routine 會先在 shadow 狀態運作，必須等證據達到門檻；兩週後觸發強制審查，不會自動轉為正式上線，paging 也要另行作出 go/no-go 決定。 平行調查架構 事件升級後，Claude Tag 會啟動 orchestration workflow，由 orchestration agent 建立 executor subagents，平行調查各個依賴與事實來源。Anthropic 的範例透過 MCP Connectors 連接 Grafana、日誌儲存系統、PagerDuty、GitHub、Kubernetes 與 Slack incident channels；各 executor 回報結果後，再由 orchestrator 彙整成可閱讀的 SITREP，以縮短 MTTR。 調查不只是自由搜尋。Claude 會先載入對應的 investigation skill、參考 Markdown 檔案與 lessons.md。例如，處理 shadow divergence bugs 的 investigation skill 有 617 行，記錄工程師平時逐步排查的方法；重複出現的處理模式，則可從 lessons.md 提升為正式的 investigation skill。 人類控制邊界 repository 將分工定義為：Claude 負責蒐集證據、提出方案、驗證結果與溝通；人類決定要如何、何時進行 mitigation。Claude 可提出包含 feature flag、百分比步驟、每階段等待時間與中止指標的 canary ramp plan，但不會直接碰觸 flag。人類或受控的 gated automation 才能部署修復，Claude 只持續觀察 metrics 是否回到基準，並在事件結束後把經驗追加至 lessons.md；事件始終由人類關閉。 設定前提 要部署 Anthropic 文章描述的版本，流程包括： 使用 Claude Team 或 Claude Enterprise 方案。 由 organization owner 透過 Claude Tag 將 Claude 加入 on-call Slack channel。 由 organization owner 在該頻道連接適當的 連接器、GitHub repo，並設定 Claude Code Remote。 將 Claude 加入 incident channel，要求它監控事件並立即進行 triage。 Claude Tag 需要獨立的 service account、可讀取 metrics 與 logs 的權限，以及跨 on-call channel 保存的記憶。排程可在 Slack channel 以自然語言設定，例如要求每週一美東時間上午 9 點執行 CI handoff；相關 instructions 則放在 GitHub repo 的 skills 中。 畫面示範 輔助畫面展示了一次 Slack 中的 payments-svc 測試事件： Marchfell 團隊的 Slack 介面截圖，顯示 #ci-oncall 頻道內一則由 Priya 標註 @oncall、指出 payments-svc 約 44 個測試停止觸發，部署日誌中未見相關紀錄的訊息，頻道標題列並顯示本週當值為 @Sachin 且 Claude 在此頻道中。 Claude 找出一項使 44 個測試被靜音的 filter 變更；在人類要求確認重新命名的三個測試後，畫面顯示 Claude 以新限制各執行十次，共三十次測試，接著提出 PR #2213。Priya 核准並合併後，畫面顯示 build 4473 重新執行全部 44 個測試、錯誤率維持基準，Claude 再將結果寫入 lessons.md。這是示範流程中的畫面觀察，不是該 repository 對正式部署成效的獨立評估。 Claude 在 Slack 通道中自動響應 on-call 警示並與團隊協同排查與合併 PR 的交談記錄 成效缺口 目前資料只提供 Anthropic 自行報告的 14 分鐘中位數與 4 分鐘最快根因分析，沒有獨立評估 setup 在其他團隊的 operational outcomes 或 error rates；實際部署所需的完整 連接器 與 permissions、未維護 reference implementation 的後續適配方式，以及 proposed fixes 與 gated automation 在正式環境中的安全措施，來源也沒有進一步說明。 原文：https://easyvibecoding.app/curated/3291-claude-tag-anthropic-cicd-failure-analysis-14-minutes

  7. 18 小時前

    Google DeepMind 發布 AlphaGenome Atlas，預測全人類基因組 90 億種變異的分子影響

    Google DeepMind 發布 AlphaGenome Atlas，預測全人類基因組 90 億種變異的分子影響。 一名留著鬍子、頭戴藍色頭巾的男士坐在室內窗前，身穿白色襯衫，前方桌面放著筆記型電腦與紙張，畫面頂端疊加顯示藍色標題與「AlphaGenome Atlas Mapping every possible DNA letter change to understand biology」字樣。 核心定位 AlphaGenome Atlas 是一個可搜尋的 AI 資料庫，收錄人類基因組全部 90 億種單核苷酸變異的預測結果，目標是讓研究人員從全基因組尺度理解遺傳變化如何影響分子生物學。Google DeepMind 表示，逐一在實驗室測試這些變異並不可行，因此先以 AlphaGenome 大規模預先計算分子效果，建立一個可供研究使用的全基因組資源。官方於 AlphaGenome Atlas 公告 中將它定位為研究基線，而非最終版本；隨著 AlphaGenome 等 AI 模型改進，這份基因組地圖也會持續更新。 資料與解讀架構 Atlas 被描述為 1 PB 的資料集，規模超過 AlphaFold Database 的 30 倍；每個變異包含數千項分子效果預測，涵蓋數百種人類與小鼠細胞類型及組織。平台把多層資訊連結起來，讓研究者能從變異追查受影響的功能性 DNA 序列： Molecular effect predictions：提供基因調控等多個面向的全基因組分子效果預測。 AlphaGenome Variant Impact（AVI）score：把 AlphaGenome 與 AlphaMissense 的預測濃縮成單一分數，用於快速排序變異並協助解讀其影響。 AVI feature attributions：將 AVI score 拆解成可理解的特徵貢獻，例如染色質可及性、RNA 剪接、基因表現與保守性。 DNA sequence motifs：收錄超過 2,500 種反覆出現的 DNA 序列 motif，以及它們在基因組中的位置，協助研究者尋找轉錄因子結合位置與非編碼變異的功能線索。 AVI score 同時涵蓋編碼區與非編碼區：前者約占基因組 2%，後者約占 98%，並負責調控基因活動及承載多數與性狀相關的變異。 研究案例 Google DeepMind 引述外部合作研究，說明 Atlas 如何縮小候選變異範圍。在 GREGoR Consortium 合作的未解罕見疾病研究中，Laura Covill、Anne O’Donnell-Luria 與 Broad Institute 團隊利用 AVI score 優先排序候選變異，找出影響 DNM1 的變異。AlphaGenome 預測該變異會形成錯誤的剪接位置，導致產生異常延長的蛋白質；後續實驗篩選驗證了這項預測，也發現鄰近變異具有相似效果。 在族群遺傳研究中，Gareth Hawkes 使用超過 54,000 名 UK Biobank 參與者的全基因組資料，依預測分子效果分組罕見非編碼變異，找出多 22% 的非編碼遺傳關聯，並定位與 PLA2G7、EGLN1 蛋白質含量相關的調控變異。針對身體質量指數，研究再聚焦於 Atlas 預測影響最大的 1% 非編碼變異，找出 19 個遺傳區域，作為後續研究方向。 AlphaGenome Atlas 影片展示基因組變異瀏覽介面、蛋白質結構視覺化與實驗室畫面。 存取方式與適用範圍 AlphaGenome Atlas 目前可透過網站入口、AlphaGenome API，以及 Google Antigravity 中的 skill 使用。Atlas 網站入口可免費供學術研究與非商業用途使用；Google Cloud 的商業存取預計稍後提供；公告未說明商業方案的上線時間、價格或配額。Google 另指出，AlphaGenome 基礎模型已可供學術使用，並可透過 GitHub 與 AlphaGenome API 存取，也能在 Cloud 的 Model Garden 用於商業用途，但這些條件不應與 Atlas 網站目前的非商業範圍混為一談。 性能主張與限制 官方表示，AVI score 在多項變異致病性與罕見疾病 benchmark 中達到 best-in-class 表現，但這是 Google DeepMind 的第一方測試主張；公告沒有提供完整 benchmark 對照矩陣、資料集、評估指標或比較基準，因此無法從原文重建這項排名的具體依據。來源也未說明使用者實際需要的運算資源、API 配額、儲存空間、資料授權條款或存取要求。 最重要的適用限制是，AlphaGenome 尚未經過臨床用途驗證，也未獲准用於任何臨床用途。AlphaGenome Atlas 提供的是研究用預測與排序工具，不可取代專業醫療建議、診斷或治療；如何在非臨床研究中校準預測結果及其不確定性，仍取決於後續方法文件與實驗驗證。 原文：https://easyvibecoding.app/curated/3290-google-deepmind-alphagenome-atlas-predicts-genome-variant

  8. 1 天前

    把圖片串成動畫：GPT-Image 2.5 的三個創作實例

    把圖片串成動畫：GPT-Image 2.5 的三個創作實例。 黏土小龍破殼、蠟筆人物側手翻、像素角色踢腿，三位創作者都用 GPT-Image 2.5 產生圖片，再把影格串成動畫。以下整理他們公開的作品與做法；步驟來自作者自述，並非本站重做的測試。 Ivana：36 張圖片交給 Codex 串接 Ivana 說，她先生成 36 張圖片，再用 Codex 拼成短片，過程沒有使用影片生成模型。成品是一隻藍綠色黏土風格小龍從蛋中探頭、破殼，再噴出小火苗。 Ivana 的定格動畫：藍綠色黏土風格小龍從斑點蛋中孵化。 Michael Wall：從一張火柴人圖接出側手翻 Michael Wall 先要求一張火柴人圖，接著要求再畫九張側手翻的動作，最後請模型把十張圖串成 GIF，但作者沒有交代實際的串接工具。成品保留蠟筆畫的筆觸與遊樂場背景，人物則逐格翻轉。 來源：@sound4movement｜Michael Wall 展示的翻頁動畫：蠟筆風格人物在草地上做側手翻。 來源：@sound4movement｜Michael Wall 貼文附上的蠟筆風格靜態圖，背景包含樹木、鞦韆與溜滑梯。 所附的這兩則貼文未提供完整提示詞。 852話：先做動作圖集，再處理切格與位置對齊 852話（hakoniwa，@8co28） 用角色參考圖生成 4×4、共 16 格的戰鬥動作圖集（sprite sheet）。這種圖集把不同姿勢排在同一張圖片上，後續再切成個別影格。 來源：@8co28｜852話使用的角色參考圖。 來源：@8co28｜4×4、共 16 格的像素角色動作圖集，包含預備、出拳與踢腿姿勢。 作者說，第一次去背失敗，因此另開對話，要求先讓背景透明，再以 4×4 切格、對齊角色位置，最後做成 GIF。這裡多了一道切格與對齊的處理，公開動畫中可看到角色預備與踢腿的動作。 來源：@8co28｜852話展示的像素角色 GIF，可見預備姿勢與踢腿動作。 來源：@8co28｜角色參考、4×4 動作圖集與對話回覆；回覆也說明每格尺寸與真正透明背景尚未符合要求。 另開對話是作者的補救做法，是否成功去背仍不能只靠這則貼文確認。公開截圖中的回覆列出尺寸與透明背景未符合要求；圖上的棋盤格也不等於檔案具有透明通道。想把素材放進遊戲，還需檢查實際輸出。 Arena 三張榜單怎麼看 Arena 的公告 提供另一種觀察角度：GPT-Image 2.5 的 Sunburst 與 Flare 兩個版本，在文生圖、單圖編輯、多圖編輯三項榜單中分居前兩名。下表依 2026 年 9 月 9 日上午（台灣時間）讀取的公告圖整理，分數比較對象均為 GPT Image 2（medium）。 | 項目 | Sunburst | Flare | GPT Image 2（medium） | 分數差：Sunburst／Flare | | --- | ---: | ---: | ---: | ---: | | 文生圖 | 1,421 | 1,399 | 1,381 | +40／+18 | | 單圖編輯 | 1,520 | 1,491 | 1,461 | +59／+30 | | 多圖編輯 | 1,535 | 1,501 | 1,454 | +81／+47 | Arena 的方法說明 是先呈現兩個匿名模型的回應，讓使用者投票選出偏好的結果，之後才揭露模型身分。這些是偏好評測分數，差 40 分不等於品質提升 40%；榜單也沒有驗證上述三位作者的動畫流程。 Arena 文生圖榜：Sunburst 1,421 分、Flare 1,399 分，GPT Image 2（medium）1,381 分。 Arena 單圖編輯榜：Sunburst 1,520 分、Flare 1,491 分，GPT Image 2（medium）1,461 分。 Arena 多圖編輯榜：Sunburst 1,535 分、Flare 1,501 分，GPT Image 2（medium）1,454 分。 三個案例提供了兩種可以參考的做法：連續產圖後拼接，或先做動作圖集再切格。前者已有作者交代張數，後者也公開了去背失敗與補救步驟；實際嘗試時，可以先從一個短動作開始，檢查相鄰影格與角色位置是否接得起來。 原文：https://easyvibecoding.app/curated/3289-gpt-image-2-5-codex-create-stop-motion

顯示全部 (204)

簡介

輕鬆Vibe Coding — 每日策展的 X 技術社群精選、AI 趨勢分析與 Claude 實作心得的中文音訊版。

資訊

  • 創作者
    EasyVibeCoding
  • 活躍年代
    2026年
  • 集數
    204
  • 年齡分級
    兒少適宜
  • 版權
    © 2026 EasyVibeCoding. 翻譯文章版權歸原作者所有；策展精選僅作摘要與評註，原始內容版權歸原推主。
  • 節目網站
    EasyVibeCoding Podcast