既然 DSPy 這麼出色，為什麼沒什麼人在用？

背景

DSPy 是一個旨在將大型語言模型（LLM）開發流程從脆弱的提示詞工程轉向程式化、模組化架構的框架。儘管它承諾能解決 AI 系統在擴展時面臨的維護與優化難題，且已有 Databricks 和 Sephora 等知名企業採用，但在開發者社群中的普及速度卻顯得遲緩。本文探討了為何許多工程師最終會自行開發出一套功能殘缺的類 DSPy 系統，而非直接採用該框架。

社群觀點

Hacker News 的討論揭示了 DSPy 面對的現實困境，其中最核心的障礙在於其極高的學習曲線與不夠直觀的抽象化設計。許多開發者指出，DSPy 強制要求使用者將提示詞視為可編譯的參數，這種做法雖然在理論上非常優雅，但在實務中卻讓習慣於直接操控提示詞的工程師感到不安。部分評論者提到，一旦進入 DSPy 的生態系，產出的優化提示詞往往像是一個黑盒子，難以提取或在其他框架中復用，這種「供應商鎖定」的恐懼讓許多團隊在評估初期就選擇退縮。

此外，開發者對於 DSPy 的人體工學設計也頗有微詞。在一個高度依賴型別檢查的現代開發環境中，DSPy 頻繁使用的動態型別與複雜的輸入輸出簽名顯得格格不入，甚至被批評為不夠直覺。對於那些不使用 Python 的團隊來說，DSPy 的吸引力更是大打折扣，因為這意味著必須為了單一工具而維護一套全新的技術棧。

另一個關鍵的爭論點在於「評估指標」的建立。社群普遍達成共識：DSPy 的真正威力在於自動化優化，而這必須建立在高品質的測試資料集與評估指標之上。然而，對於許多正處於快速迭代階段的 AI 產品而言，定義什麼是「正確答案」本身就是一項艱鉅的挑戰。當團隊還在摸索產品方向時，投入大量精力去構建評估體系反而會拖慢開發速度。這導致了一個弔詭的現象：開發者雖然認同 DSPy 提倡的軟體工程原則，如關注點分離與模組化，但在面臨交付壓力時，往往會選擇先用硬編碼的提示詞與簡單的 Pydantic 驗證來解決問題，最終在不知不覺中走上了自行開發「低配版 DSPy」的道路。

最後，有觀點認為 DSPy 可能過度神化了提示詞優化的重要性。一些資深開發者指出，如果一個系統需要如此複雜的框架來微調提示詞，或許問題出在底層模型的能力不足，或者是應該轉向強化學習等更深層的優化手段。儘管如此，社群中仍有支持者認為，DSPy 至少為 AI 開發提供了一套正確的思考框架，即便不直接使用該工具，學習其背後的設計哲學對於構建穩健的 AI 系統依然大有裨益。

延伸閱讀

在討論中，開發者們推薦了幾個與 DSPy 理念相似但側重點不同的工具。例如 BAML 被提及作為一種能更快速迭代提示詞的選擇；Pydantic-AI 則在型別安全與開發體驗上獲得好評。針對 DSPy 提示詞難以提取的問題，有開發者推薦了 dspy-template-adapter 插件來橋接落差。此外，對於不希望受限於 Python 環境的團隊，TensorZero 與 Google 的 ADK 也被視為值得關注的替代方案。