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 的架構。

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

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

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

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