
為什麼選這台?
能在本地自家跑 LLM 大模型,應該是 AI 工程師的夢想之一。
閱讀全文〈Framework Desktop 開箱〉😆 👨🏻💻 ✨ 🚀 💰
Hello! 各位 AI 開發者大家好 👋
變成月刊了,這期內容繼續深入探討 AI 工程的核心: 評估、Context Engineering、Agent 和 RAG。
閱讀全文〈愛好 AI Engineer 電子報 🚀 AI Evals 大辯論和 MCP Registry 發布 #32〉看到 MCP 官方出了一個 Registry [1],GitHub [2] 也出了一個 Registry,這是在打架嗎?
不是的,讓我解釋一下 MCP Registry 的架構。
[1] 官方公告 blog.modelcontextprotocol.io/posts/2025-09-08-mcp-registry-preview/
[2] GitHub MCP Registry github.blog/ai-and-ml/github-copilot/meet-the-github-mcp-registry-the-fastest-way-to-discover-mcp-servers/
[3] 架構圖出自官方文件 Ecosystem Vision,推薦一看: github.com/modelcontextprotocol/registry/blob/main/docs/explanations/ecosystem-vision.md
官方 MCP Registry 是一個統一的 metadata service,解決了幾個關鍵問題:
Server Discovery: 各種 MCP servers 散落在各個 GitHub repo、社群討論串,很難找。現在有了中央目錄,方便找到合適的 MCP server。更重要的是,它提供標準 API,未來 AI agents 可以自動發現和選擇需要的工具。
信任與安全性: 你可以知道這個 MCP server 是誰建立的,是不是官方認證的。這能大幅減少安全風險,避免安裝到惡意或釣魚的 MCP server。Registry 還有社群回報機制,可以標記和移除有問題的 servers。
版本追蹤: 清楚知道你正在使用哪個版本的 MCP server,有沒有更新可用,避免版本混亂的問題。
閱讀全文〈官方 MCP Registry 上線〉最近看到一場關於 AI Evals 的精彩論戰,爭論焦點不在模型訓練層面的評估(這個大家都有共識要做),而是 AI 應用層面到底要做多少評估。這讓我想起自己在軟體開發的經驗: 如何寫測試也是我曾關注的問題,但說實話,我從來不追求 100% test coverage。即使 Ruby 社群也強調每件事都要有測試涵蓋,但我還是比較考量成本效益,自動化測試對我來說是值得做才會做的事。
現在 AI Evals 也處於類似階段。我去年就開始關注並分享如何做評估,但要求每個面向都 100% 有評估其實是不實際的。AI 是機率性軟體,評估難度更高,AI 的輸出好不好也非常有主觀成分,目前怎麼做很依賴實務經驗交流。最近剛上完 AI Evals For Engineers & PMs 課程,有了新的體會。首先,「評估驅動開發」(指先寫評估再開發) 竟然可能是錯的方向 – 對於沒有標準輸出的 AI 任務,你無法無限投資在評估上。
我目前認為評估可分兩種:
Soft preferences (graded helpfulness): 大多數範例用 LLM as Judge 給 1-5 分評估「有多少幫助」、「有多清晰」等,都屬於這類。坦白說,這種評估幫助有限,頂多做相對比較,實際效用不大。
Hard rules (binary guardrails): 這種其實更實用,就是會有標準答案的二元判斷,用 Code-based 或 LLM as Judge 判斷是不是有做到你要求的限制。這門課程重點就是教如何用 LLM 科學地做出對齊後的 binary classifier,老師就是這篇知名 paper: Who Validates the Validators? Aligning LLM-Assisted Evaluation of LLM Outputs with Human Preferences 的第一作者。
沒有標準答案的 LLM 要輸出怎麼做 binary classification 的評估? 我們不做通用的 LLM-as-Judge 評估,而是先人工做錯誤分析,找出真正重要的錯誤模式,然後每個錯誤模式分別做 LLM as Judge 只判斷 Y/N 輸出有沒有犯這個特定錯誤。這個 Judge 需要認真做對齊,得有很高的準確率,因為是 classification 任務所以也相對好做 prompt 最佳化。如此下來,你會得到真正有用的準確指標,能實際用來幫助改進 AI 應用。
就如 Hamel Husain [0] 說的:「Generally no. Eval-driven development (writing evaluators before implementing features) sounds appealing but creates more problems than it solves.」重點是找到真正影響用戶體驗的關鍵指標,而不是為了評估而評估。
[0] x.com/HamelHusain/status/1950247467444031828
那 Soft preferences 怎麼辦?這部分還是得依賴人的判斷,AI Judge 無法完全取代。無論是團隊自己 dogfooding、監控線上指標、收集用戶回饋,或是跑 A/B testing,還是得靠傳統產品開發的方法。AI 應用的評估不是非黑即白的選擇題,得在不同階段不同需求,靈活運用不同工具的智慧。
Hamel Husain 還有一篇 The Mirage of Generic AI Metrics 也指出通用指標的問題,並介紹錯誤分析、建立客製化指標、建立可信的 LLM Judge。
(以下整理整個論戰的精彩內容,透過 Claude 摘要寫成)
閱讀全文〈AI Evals 大辯論: 從 Claude Code 訪談引發的反思〉Hello! 各位 AI 開發者大家好 👋
我是 ihower,這期不小心變成月刊了,暑假真是過太快了。
幫分享今年的 PyCon Taiwan 在臺北文創,總共有 3 種形式的演講與 6 種不同性質的交流活動。
時間是 2025/9/5 – 9/7 👉 活動資訊與購票
Anthropic 最近才釋出了他們在 2025/5/22 開發者大會的完整影片,當時的重頭戲是 Claude 4 模型發布。其中有兩場關於 prompting 教學的演講內容很不錯,這兩場演講從基礎 Prompt 到針對的 Agent 的 prompting ,展現了 prompt engineering 的不同層次,推薦大家一看。以下是我的解讀整理。