ihower { blogging }

(整理分享一些關於 Spec-Driven Development (SDD) 的看法和內容)

Spec-Driven Development (SDD) 是什麼? 簡單說講就是在用 AI 寫程式之前，先讓 LLM 生成一大堆規格文件: 產品需求 → 技術設計 → 任務清單，然後才交給 coding agent 執行。目前有幾個工具在推這套流程: GitHub 的 Spec-Kit、AWS 的 Kiro、還有 Tessl。

社群討論其實非常兩極。正面看法認為遠比 vibe coding 可靠、適合要上線維護的真實專案、開發速度中期來看其實更快。負面看法則認為這就是 Waterfall 2.0、過度工程化、扼殺創造力。我自己從一開始就不太看好，最近看到幾篇深度分析文章，更加印證了我的看法。

閱讀全文〈Spec-Driven Development(SDD) 的美好願景與殘酷現實〉

為什麼選這台?

能在本地自家跑 LLM 大模型，應該是 AI 工程師的夢想之一。

閱讀全文〈Framework Desktop (AMD Ryzen AI Max+395) 開箱〉

看到 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

為什麼需要官方 Registry？

官方 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 訪談引發的反思〉