ihower { blogging }

看到 MCP 官方出了一個 Registry [1]，GitHub [2] 也出了一個 Registry，這是在打架嗎？

不是的，讓我解釋一下 MCP Registry 的架構。

閱讀全文〈官方 MCP Registry 上線〉

最近看到一場關於 AI Evals 的精彩論戰，爭論焦點不在模型訓練層面的評估(這個大家都有共識要做)，而是 AI 應用層面到底要做多少評估。這讓我想起自己在軟體開發的經驗: 如何寫測試也是我曾關注的問題，但說實話，我從來不追求 100% test coverage。即使 Ruby 社群也強調每件事都要有測試涵蓋，但我還是比較考量成本效益，自動化測試對我來說是值得做才會做的事。

現在 AI Evals 也處於類似階段。我去年就開始關注並分享如何做評估，但要求每個面向都 100% 有評估其實是不實際的。AI 是機率性軟體，評估難度更高，AI 的輸出好不好也非常有主觀成分，目前怎麼做很依賴實務經驗交流。最近剛上完 AI Evals For Engineers & PMs 課程，有了新的體會。首先，「評估驅動開發」(指先寫評估再開發) 竟然可能是錯的方向 – 對於沒有標準輸出的 AI 任務，你無法無限投資在評估上。

閱讀全文〈AI Evals 大辯論: 從 Claude Code 訪談引發的反思〉

Anthropic 最近才釋出了他們在 2025/5/22 開發者大會的完整影片，當時的重頭戲是 Claude 4 模型發布。其中有兩場關於 prompting 教學的演講內容很不錯，這兩場演講從基礎 Prompt 到針對的 Agent 的 prompting ，展現了 prompt engineering 的不同層次，推薦大家一看。以下是我的解讀整理。

第一場: Prompting 101

閱讀全文〈從 Prompting 基本結構到 Agent Prompting 設計原則〉

OpenAI 於 2025/8/7 推出 GPT-5，包括 ChatGPT 和 API 都同時上線，這裡針對 AI 開發者快速解惑與整理重點。

ChatGPT != API 平台的模型

首先，ChatGPT App 的模型與 API 平台上的模型，並非一一對應，這點常讓開發者搞混。讓我說清楚。在 ChatGPT App 裡，其實是一個系統，包含:

1. GPT-5 模型 (這沒有 thinking)
2. GPT-5 Thinking 模型
3. 內部的 Router 路由模型，會依據用戶問題動態切換不同模型與推理程度

閱讀全文〈OpenAI GPT-5 API 更新重點整理〉

看了一場 Augment Code (也是一家做 AI IDE 的廠商) 來講 “Agentic 檢索” 對比 “傳統 RAG 檢索” 的演講，蠻有啟發的。
在 AI Coding 領域，簡單的工具正在擊敗複雜的 RAG 系統。

AI Coding 的演進歷程

AI Coding 的演進是這樣:

• 2023: Code completion 補全時代，例如 Github Copilot
• 2024: 出現側欄 chatbot 來寫這個檔案的 code
• 2025: 進到 Agent 時代，例如 Claude Code 可以跨多個檔案寫 code

隨著每次演進，IDE 底層檢索的複雜度越來越高。我們知道 LLM 需要正確的 context 才能良好運作(也就是 context engineering)，因為需要設計一套檢索系統，找出當下模型所需要參考的程式碼。
像 code completion 只需要超低延遲的簡單檢索即可，chatbot 時代需要理解更複雜的抽象問題，而 agent 就必須理解整個專案的許多不同部分。

他們對 AI Coding 領域的驚人發現是: 簡單的工具就夠了，Augment 團隊在 SWE-Bench 拿下第一名，論文中寫道:「我們探索了新增各種基於嵌入的檢索工具，但發現對於 SWE-Bench 任務來說，這並不是瓶頸。用 grep 和 find 工具就足夠了」。

近期很夯的 Claude Code、OpenAI Codex、Gemini CLI 也通通沒有用 embedding 模型來做檢索。
程式碼檢索為什麼 grep/find 就夠用? 因為程式碼有很多高訊號的關鍵字詞彙，這些結構化的關鍵字讓 grep 搜尋變得非常有效。

閱讀全文〈Agent 讓 RAG 過時了嗎? 談 AI Coding 的檢索策略〉