六月 AI 模型大戰前夕：GPT-5.6、Gemini 3.5 Pro、Claude Mythos 同時壓境，開發者怎麼準備？
2026 年 5 月最後一週，GPT-5.6 在 Codex 後端日誌裡被挖出來、Anthropic 的 Mythos 推翻了一個近 80 年的數學猜想、WWDC 很可能揭露 Gemini 驅動的新 Siri。如果這些消息有一半成真，六月的模型名稱、API 規格、token 單價會同時變動，留給開發者的切換視窗很短。 我三月寫過一篇模型大亂鬥，當時的結論是「沒有全能冠軍」——這句話到現在還適用。這次要聊的不是跑分比較，而是一個更實際的問題：你的系統架構裡，模型名稱寫死了幾處？錯誤碼寫死了幾處？stream chunk 格式寫死了幾處？ 備戰清單放前面，後面的情報分析都服務這份清單。 開發者備戰清單（六月前完成）1. 把 LLM 呼叫抽象出來 如果你的程式碼裡直接寫死 openai.chat.completions.create()，六月切模型會很痛苦。不需要複雜框架，一個 adapter 層就夠。核心是把模型選擇和業務邏輯分開。 1234567891011121314151617181920212223242526272829// 這是整理過的示意，實際版本會更簡單interfa...
跟 AI 說「這對我很重要」讓它表現提升 115%——論文怎麼解釋這件事
那個 115% 是怎麼來的我第一次看到這個數字的時候反應是「不可能吧」。 論文叫 Large Language Models Understand and Can be Enhanced by Emotional Stimuli，2023 年由 Microsoft、中科院、威廉與瑪麗學院等機構合作發表。研究方法很簡單：在 prompt 末尾加上一句情緒話語，例如「這對我的職涯非常重要」「我相信你可以做得很好」，然後看模型表現會不會變化。 結果是： 自動評測涵蓋 45 個任務（Instruction Induction + BIG-Bench），多個模型上都看到改善 另有 106 位受試者評估 30 個生成問題，EmotionPrompt 在 performance、truthfulness、responsibility 三項平均相對提升 10.9% 在 BIG-Bench 某些子任務上，相對改善飆到 115%（注意這是 relative improvement，在原始低基準任務上會被放大） 在 Flan-T5、Vicuna、Llama 2、BLOOM、ChatGPT、GPT-4...
AI Agent 不寫程式了——2026 年 Agent 生態從寫 Code 走向裝 Skill
上個月我盯 GitHub Trending 的時候，發現一個微妙的轉變：排行榜上最火的 AI 專案，不再是「更好的模型」或「更快的推理引擎」。而是一堆教 Agent 怎麼裝外掛、怎麼組合技能的框架。 OpenClaw 60 天內從 9,000 顆星飆到 250,000 顆。Obra/superpowers 緊隨其後，定位自己是「Agent 的 App Store」。ByteDance 的 DeerFlow v2 上線當天就衝上 Trending 第一。Karpathy 的 autoresearch 三天拿了 23,000 顆星。 這幾個專案各做各的，但拼在一起看，指向同一件事：Agent 的核心能力正從「寫程式碼」轉移到「組合技能」。 從「什麼都自己幹」到「會裝外掛就好」2024 年的 AI Agent 長這樣：給它一個任務，它會嘗試用程式碼從零搭出解決方案。寫 API 呼叫、處理 JSON、做錯誤處理——全部即時生成。 問題很明顯。每次執行同樣的任務，Agent 可能生出完全不同的程式碼。有時候能跑，有時候炸掉。更糟的是，它不會從上一次的錯誤中學到教訓，因為那些程式碼是用完即棄...
當你的 AI Agent 有 500 個工具：從 GPT-5.4 的 Tool Search 看工具管理的正確姿勢
上週我在幫公司的 AI Agent 接上第 47 個 MCP server 時，API 帳單跳了一個數字讓我差點從椅子上摔下來。 不是因為用量暴增。是因為每一次 API 呼叫，光是把 36 個 MCP server 的工具定義塞進 context，就吃掉了將近 40,000 tokens。模型還沒開始思考，錢已經燒了一半。 3 月 5 日 OpenAI 發佈 GPT-5.4 時，benchmark 數字和 Computer Use 搶走了所有目光。但對我來說，最值得注意的功能只有一個——Tool Search。 工具爆炸問題：你可能已經踩到了先說個數字。一個標準的 function calling 工具定義，包含名稱、描述、參數 schema，平均佔 200-500 tokens。聽起來不多？ 算一下： 10 個工具 → ~3,000 tokens（還好） 50 個工具 → ~15,000 tokens（開始痛） 200 個工具 → ~60,000 tokens（每次呼叫都在燒錢） 500 個工具 → ~150,000 tokens（恭喜，光工具定義就用掉一般模型 contex...
你的 CLAUDE.md 寫太多了：7,308 次實驗證明 AI Agent 指令 2-3 條就好
上週我在整理自己的 CLAUDE.md 時，發現它已經膨脹到快 800 行。規則疊規則、範例套範例，像一本員工手冊。直覺告訴我這樣「比較完整」，但實際體感是——Claude Code 有時會忽略我寫在後半段的指令，偶爾還會把兩條規則搞混。 然後我讀到 SkillsBench 這篇論文，它用 7,308 條執行軌跡和 84 個任務做了一件事：測量「給 AI Agent 的操作指引（Skills）」到底給多少、寫多長才有效。 結論讓我重新打開編輯器，把那 800 行砍掉一半。 先講數字研究團隊在 Claude Code、Codex CLI、Gemini CLI 三個平台上，測試了七種模型配置。每個任務跑五次，用程式化斷言判定通過與否——不是讓另一個 LLM 當裁判，是寫死的測試。 整體結論：精心撰寫的 Skills 平均提升 16.2 個百分點。這個數字本身不意外，有指引當然比沒有好。 意外的是拆開來看的時候。 2-3 條指引是甜蜜點，4 條以上開始拖後腿 Skills 數量 有 Skills 無 Skills 差距 1 條 42.2% 24.4% +17.8pp 2-...
三月AI模型大亂鬥：GPT-5.4、Gemini 3.1 Pro、Claude Opus 4.6 到底誰贏了
3 月 5 日，OpenAI 丟出 GPT-5.4。兩週前，Google 才發了 Gemini 3.1 Pro。Anthropic 的 Claude Opus 4.6 也在持續迭代。三家模型同時站在擂台上，跑分互有勝負，開發者選擇困難症大爆發。 我花了幾天把三家的 benchmark 資料、定價和實際使用場景整理了一遍。結論先說：沒有全能冠軍，但各有各的殺手鐧。 GPT-5.4：第一個真正會用電腦的 AIOpenAI 這次最大的賣點不是跑分——是 Computer Use。 GPT-5.4 能直接操作桌面應用程式：看螢幕截圖、移動滑鼠、敲鍵盤。在 OSWorld 測試中，它拿到 75% 的成功率，超越人類的 72.4%。這不是小數字的進步，GPT-5.2 在同一個測試只有 47.3%。 另一個重點是「統合模型」架構。OpenAI 把之前分散在不同模型的能力——Codex 的寫程式、推理模型的思考鏈、Agent 的自主操作——塞進同一個模型裡。不用再煩惱「這個任務該叫哪個模型」。 硬指標 項目 GPT-5.4 跟 GPT-5.2 相比 GDPval（知識工作） 83% 7...
100 兆 tokens 告訴你：為什麼降價 10% 也救不了你的 LLM 產品
你以為 AI 模型競爭就是打價格戰？ OpenRouter 剛發佈的報告分析了 100 兆 tokens 的真實使用資料，發現一個驚人事實：**降價 10%，使用量只增加 0.5-0.7%**。 更扯的是，Claude 價格最貴，卻占了編程市場 60%。 到底發生什麼事？ 為什麼這份報告值得關注？這不是又一份「AI 趨勢預測」報告。 OpenRouter 是全球最大的 LLM API 聚合平台： 支援 300+ 模型 60+ 供應商（OpenAI、Anthropic、Google、DeepSeek...） 100 兆 tokens 真實使用資料（2024/11 - 2025/11） 這份報告揭露了三個開發者必須知道的反直覺發現。 發現 1：價格戰是假議題資料打臉時刻 策略 實際結果 降價 10% 使用量 ↑ 0.5-0.7% Claude（最貴） 編程市場占 60% DeepSeek（便宜） 使用者流失後又回流 報告原話： "需求缺乏價格彈性，使用者優先考慮品質和可靠性而非價格。" 為什麼會這樣？工程師選模型的真實決策流程：...
Context7mcp：為你的 AI 開發助手注入最新文件庫的即時知識
Github頁面：Context7mcp問題：AI 助手的知識截止日「這段程式碼有問題，Upstash Redis 的連線方式好像不對...」 即使是最新的 LLM，處理快速迭代的函式庫時都有同樣的罩門：訓練資料有截止日，新的 API 或 breaking change 根本不在它的知識範圍內。你貼給它的是 Next.js 14 的問題，它給你的可能是 Next.js 12 的寫法。 這正是 Upstash 團隊開發 Context7 要解決的事。 Context7 怎麼運作Context7 是一個 MCP 伺服器（Model Context Protocol server）。它不是靠爬蟲快取一份舊文件，而是在 AI 助手提出請求時，即時從官方文件與原始碼庫抽取相關片段，組成 AI 可直接讀取的上下文，再送回對話。 整個流程對使用者是透明的：你問問題，AI 在背景呼叫 Context7 的工具取回文件，然後根據真實文件回答。和直接問 AI 的差別是 — 它參考的是你指定版本的官方說明，不是兩年前訓練進去的印象。 Context7 的核心設計有幾點值得注意： 文件來源直接指向原始碼...
在本機免費運行 AI 大模型的開源神器 Ollama
把一個大型語言模型跑在自己的筆電上，過去要先搞定 CUDA、PyTorch、各種 Python 依賴，光環境就能耗掉一個下午。Ollama 把這整段流程收成一個安裝檔加一行指令：ollama run，模型就在本機跑起來，資料不出機器，也不用付 API 費用。 這篇談 Ollama 的安裝、常用指令、API 整合，以及最容易踩的兩個雷：API 回應解析和模型自訂檔的格式。 Ollama 是什麼它是一個用 Go 寫的開源工具，把模型下載、權重管理、推論伺服器這幾件事包在一起。核心特點： 一個指令下載模型、開始對話，不用手動處理權重檔 內建一個跑在 localhost:11434 的 HTTP 伺服器，提供 REST API 同一份指令在 Windows、macOS、Linux 都通用 模型庫涵蓋 Llama、Gemma、Qwen、DeepSeek 等主流開源模型 要留意的是它走的是量化模型路線（預設多為 Q4 量化），換來的是更低的記憶體門檻，代價是輸出品質略低於原始全精度權重。對本機實驗、開發測試夠用；要追求極致品質得另尋方案。 安裝系統需求 作業系統：Windows、macO...
