很多 AI 團隊現在最常見的誤會，不是以為模型不夠強，而是以為 prompt 只要多改幾版，品質自然會慢慢變好。

真進到產品裡，很快就會發現事情不是這樣。今天客服分類調準了一點，明天知識庫問答又退步。換一個模型，原本能用的 prompt 開始飄。多加一段 system message，看起來有改善，但你其實不知道到底是運氣、樣本偏差，還是真的比較好。更麻煩的是，功能一多之後，整個專案會變成一堆 prompt、few-shot 範例、parser、routing 規則和評測腳本散落在不同地方，誰也說不準現在這條 AI pipeline 到底是靠什麼撐住。

DSPy 值得看的地方，就在它不是教你怎麼把 prompt 寫得更花，而是想把這件事從手工試誤，拉回比較像工程系統的狀態。

先講結論，DSPy 很值得現在看，特別是你已經不是在做單一聊天介面，而是在做會持續迭代、需要評估、需要優化、會被拿來接真實流程的 AI 功能。 它真正有價值的地方，不是「幫你寫 prompt」，而是把 LLM 呼叫變成帶有輸入輸出契約、評估指標、可優化空間的 program。 但另一面也要先講清楚，它不適合所有人。 如果你只是做一個簡單聊天機器人、單步內容生成，或團隊根本沒有資料與評測習慣，DSPy 很可能太重。

English TL;DR:

• DSPy is an open-source framework for programming, evaluating, and optimizing LLM systems rather than manually tweaking prompts.
• Its real value is not better prompt syntax, but turning AI features into measurable programs with signatures, metrics, modules, and optimizers.
• It is especially useful for multi-step RAG, classification and routing, and production AI workflows that need continuous quality improvement.
• But it is not a free shortcut. You need metrics, example data, and enough engineering discipline to benefit from it.
• In short, DSPy matters when your AI feature is no longer a demo, but a system you must keep improving without guessing.

DSPy 是什麼，先講人話

如果只用一句話講，DSPy 是一個把 LLM 功能寫成可組合程式，並且能用資料和評測去優化它的開源框架。

它最核心的做法不是叫你把 prompt 越寫越長，而是先把任務描述成一個比較清楚的結構，例如：

• 輸入是什麼
• 輸出是什麼
• 這一步要用哪種推理策略
• 整條流程要怎麼被評估
• 有沒有辦法根據 metric 自動找到更好的 prompt 或 few-shot 示範

在 DSPy 裡，這些東西會落在幾個核心概念上：

• Signatures: 定義輸入與輸出行為
• Modules: 像 Predict、ChainOfThought、ReAct 這類可組合的 LM 模組
• Metrics: 你怎麼判斷結果好不好
• Optimizers: 根據 metric 和資料，自動幫你調 prompt、few-shot，甚至延伸到 finetune

它的語氣其實很直接，官方一直在講的就是那句，programming, not prompting。這不是修辭而已，它想推的真的是一種工作方式轉變。

它真正解的痛，不是 prompt 難寫，而是你根本不知道怎樣算變好

很多 AI 專案卡住，不是因為團隊不努力，而是因為整個改進流程太靠感覺。

常見場景大概是這樣：

• PM 說最近答案比較不穩
• 工程師調了一版 prompt
• 幾個人手測覺得好像有改善
• 上線後某些 case 變好，某些 case 又壞掉
• 團隊開始繼續疊規則、補例外、加幾段示範
• 三週後沒有人敢碰這條 prompt，因為一改就不知道哪裡會炸

真正麻煩的不是 prompt 不會寫，而是 你沒有一個比較像樣的方式，去定義品質、追蹤回歸、做系統化優化。

DSPy 切的就是這個點。

它把 LLM 功能視為一種可以被編排、被評估、被優化的 program。這件事的價值，在 demo 階段不一定很明顯，但一旦進入多步流程、RAG、分類路由、抽取審核這些任務，就會很有感。因為那時候你需要的已經不是一段漂亮 prompt，而是一種 能持續把品質往上推、而且知道自己為什麼往上推 的工程方式。

為什麼它現在值得看

截至 2026-04-21 前後，DSPy GitHub 約有 33.8k stars、2.8k forks，repo 在 2026-04-20 仍有 commit，最近正式 release 3.1.3 則發在 2026-02-05。這個狀態很重要，因為它說明 DSPy 不是停在學術概念展示，而是仍在快速維護與迭代。

更關鍵的是，它的文件不是只有講理念。官方 docs 已經把 signatures、modules、evaluation、optimizers、fine-tuning、RAG 與 agent 範例鋪得相當完整。這代表它已經從「值得知道的研究方向」進一步變成「值得團隊認真評估的工具」。

它也剛好踩在一個越來越重要的時間點上。現在很多公司不是沒有接上 LLM，而是 接上之後開始不知道怎麼把品質穩定地變好。這會讓 DSPy 這類框架的價值，比一年半前更容易被看懂。

三個很具體的適用場景

場景一，客服分類與工單路由，不想再靠人工猜哪版 prompt 比較準

這是 DSPy 很容易打出價值的地方。

例如你在做客服訊息分流，要判斷工單屬於退款、物流、帳單、惡意內容，還可能要一起產出優先級、摘要、風險標記。這種任務一開始常常看起來很簡單，因為它不像聊天那麼花俏，但真的進系統後，需求通常變動很快。

你今天多了一個類別，明天改了優先級規則，後天要兼容兩種模型。這時如果還是只靠手調 prompt，團隊很容易陷入「覺得這版比較好，但說不出好在哪」的循環。

DSPy 在這種場景的價值有幾個：

• 可以把任務先定義成清楚的 input/output signature
• 可以設 metric，看分類準確率、重要欄位是否命中
• 可以把分類與摘要拆成模組，而不是全塞在一個 prompt
• 可以用 optimizer 去找更好的 few-shot 與 instruction 組合

對客服平台、SaaS 後台、自動審核流程來說，這種可評估性比 prompt 本身更重要。因為你真正需要的是一條能穩定迭代的品質曲線，而不是一版「今天看起來不錯」的神奇字串。

場景二，RAG 問答系統，不只是要回答，還要知道哪個環節在拖累品質

很多團隊做知識庫問答時，最常見的問題不是模型答不出來，而是 你不知道是檢索有問題、上下文組裝有問題，還是回答階段有問題。

這就是多步 AI 系統最煩的地方。整條 pipeline 裡可能有：

1. query rewrite
2. retrieval
3. rerank
4. context selection
5. answer generation
6. citation 檢查

如果這些步驟全部混在一起，你最後只能看到「回答品質不好」，卻很難知道哪一步該調。

DSPy 的模組化很適合處理這種情境。你可以把不同步驟寫成不同 module，再用 metric 去判斷回答是否正確、引用是否合理、是否來自檢索內容。這樣做的好處不是架構比較漂亮，而是 你終於有機會把問題拆開看。

對內部知識助理、法務問答、技術文件搜尋、研究助理這類應用來說，這點很實際。因為 RAG 真正的難，不在於做出第一版，而在於資料一變、模型一換、流量一上來之後，整體品質怎麼持續維持。

場景三，抽取加審核的工作流，輸出不只要像樣，還要符合規格

還有一類場景很適合 DSPy，就是 不是單步抽取，而是抽取之後還要再過一層判斷或驗證。

例如：

• 從履歷中抽技能、年資、職稱，再做候選人排序
• 從合約抽關鍵條款，再標示風險等級
• 從醫療文件抽欄位，再判斷是否缺件或需要人工覆核

這類任務最常見的問題，不是模型完全答錯，而是它交出一個 看起來差不多、其實不能直接進系統 的結果。欄位少一個、依據不完整、格式稍微偏掉，都可能讓下游流程開始失真。

DSPy 在這裡的吸引力不是單純結構化輸出，而是你可以把整體任務拆成幾步，然後對每一步定義比較明確的評估方式。這讓 LLM 不只是生成器，而更像 pipeline 裡可觀測的一個元件。

它底層在做什麼，為什麼很多工程團隊會買單

DSPy 之所以吸引人，不是因為它又發明了一種 prompt 寫法，而是它把幾件原本分散的事情收斂起來了。

第一層，先把任務寫成結構，而不是直接堆字串

你先定義 signature，例如 question -> answer、context, question -> response、ticket -> category, priority。 這件事看起來很小，但它會逼團隊先想清楚，輸入輸出到底是什麼。

很多 prompt 之所以越改越亂，根本原因就是一開始沒有把介面定義清楚。

第二層，把不同 prompting 策略抽成 module

你可以選 Predict、ChainOfThought、ReAct 等不同 module。 這表示你在調整的，不只是 prompt 內容，而是整種 LM 呼叫策略。這比手工維護一堆 prompt 片段穩定得多。

第三層，用 metric 取代「憑感覺比較好」

這是 DSPy 最關鍵的一步。

沒有 metric，DSPy 的很多優勢都出不來。因為它的核心假設就是，如果你能定義什麼叫做好結果，那系統就有機會幫你往那個方向優化。

這個 metric 可以很簡單，像分類正確率；也可以更複雜，例如回答正確、引用正確、格式正確各占不同權重。

第四層，用 optimizer 去自動找更好的 prompt 與示範

像 BootstrapFewShot、MIPROv2、GEPA 這些 optimizer，本質上都在做同一件事，根據你的 metric 和資料，去搜尋更好的 instruction、few-shot 或優化方式。

這裡才是 DSPy 跟很多一般框架真正拉開差距的地方。因為多數框架幫你的是「更方便調 prompt」，DSPy 想做的是「讓 prompt 優化這件事本身比較像一個可重複流程」。

它跟其他工具差在哪

這題很值得先講，因為 DSPy 很容易被誤會成另一種萬用框架。

如果你只需要單次呼叫，直接用 SDK 可能更務實

如果你的需求只是：

• 一次摘要
• 一次改寫
• 一次結構化輸出
• 小型內部工具

那直接用 OpenAI、Anthropic、Gemini SDK，再配 Pydantic 或 schema 驗證，通常更快。 DSPy 不會在這種場景自動讓你更省事，反而可能增加抽象層。

如果你最在意的是 schema、型別與應用整合，BAML 或 PydanticAI 可能更直覺

BAML、PydanticAI 這一類工具，重點比較偏向把 LLM 輸出跟應用程式的型別、結構化回傳、工具調用整合好。 DSPy 的核心則更偏向 優化與評估流程。 兩邊不是互斥，但切入點很不一樣。

如果你在解的是長流程 agent orchestration，LangGraph 那類框架更對位

LangGraph 更擅長處理狀態流轉、節點編排、長流程控制。 DSPy 不是不能做 agent loop，但它更強的地方不是流程圖，而是 把每個 LM 步驟變成可優化的 program。

所以比較務實的看法是，DSPy 不一定取代別人，它比較像是在補一塊很多團隊其實缺很久的能力：AI 系統的優化方法學。

但它的限制也很直接，甚至應該先知道

1. 沒有 metric、沒有資料，DSPy 很容易變成空轉

這點一定要先講，不然很容易把它想成萬能加速器。

DSPy 最大的前提是，你至少要能拿出一點像樣的資料，或至少能定義出一個比較合理的評估函式。 如果團隊現在的狀態是：

• 沒有標註資料
• 沒有測試集
• 不知道什麼叫成功
• 也沒有時間整理失敗案例

那 DSPy 的 optimizer 再強，也很難真的幫上忙。因為它沒有目標函數可以追。

2. 抽象層變高了，除錯不一定比手改 prompt 更直覺

DSPy 的優點是抽象化，但抽象化也有代價。

你最後看到的結果，可能是某個 optimizer 幫你找到一組更好的 instruction 和 demonstrations。這很好，但當你想問「到底是什麼改變讓它變好」時，答案不一定像手寫 prompt 那麼直觀。

對成熟團隊來說，這是可以接受的工程取捨。 但對還在建立 AI 開發習慣的小團隊來說，這可能反而增加理解門檻。

3. 優化會花 token、時間和試驗成本

這類框架很容易讓人忽略一個現實，自動優化不是免費的。

你要跑評估、要試 candidate programs、要做 bootstrapping，這些都會消耗 token 和開發時間。 如果你的功能還停在「先做出來看看有沒有人用」，過早導入這種優化流程，不一定划算。

4. 不適合非常簡單、一次性的 AI 功能

如果你只是要做：

• 行銷文案生成
• 單次摘要
• 個人助理聊天
• 低頻內部查詢工具

那 DSPy 大機率不是最好的起手式。 它的價值通常出現在 功能要長期維護、品質要持續調、回歸風險不能靠感覺扛 的地方。

先看一眼這條曲線，DSPy 已經不是只有研究圈在談

如果只看 GitHub star，當然不能直接等於成熟度，但它至少能幫你判斷這件事是不是還停在少數人自嗨。DSPy 的成長曲線已經很明顯超過「只有論文讀者在討論」的範圍，開始進入真正做 AI 產品與平台的團隊視野。這通常代表它解的不是漂亮概念，而是越來越多人都在撞到的真問題。

結論，不是所有人都該上 DSPy，但很多團隊確實該開始研究它了

比較務實的採用判斷是這樣：

如果你的 AI 功能還只是單點實驗，DSPy 不一定是最該先上的工具。 你先把需求做實、把失敗案例收集起來、把輸入輸出定義清楚，通常更重要。

但如果你已經進到下面這些狀態：

• LLM 功能不只一個
• prompt 一改就怕回歸
• 團隊開始需要比較不同版本品質
• RAG、分類、抽取、路由已經變成產品核心
• 想把模型升級或切換做得更有方法

那 DSPy 就非常值得看。因為它代表的不是另一個 AI 框架選項，而是一種比較成熟的想法：把 AI 功能從手工玄學，拉回可評估、可優化、可維護的工程系統。

結論不是「所有 AI 專案都要用 DSPy」，而是 只要你的問題已經從怎麼接上模型，進展到怎麼持續把品質變好，DSPy 這條路就很值得提早研究。