DSPy 是史丹佛大學自然語言處理團隊主導的開源框架，在 GitHub 累積 38,813 顆星標、3,455 個分支與 411 位貢獻者，採 MIT 授權。它主張以 Python 程式碼取代手寫提示詞，透過編譯與優化演算法自動改寫指令與示例，最新版本為十月十二日發布的 3.4.1。
DSPy 是什麼？
DSPy 是史丹佛團隊開源的提示詞編程框架，以 Python 宣告輸入與輸出欄位，再由優化器自動生成並持續改進提示詞。
官方把定位寫得直接：程式設計而非提示詞設計。開發者定義簽章（Signature）描述任務的輸入與輸出欄位，再以模組組合流程，最後交由優化器產生對應的指令與示例。
這種分工改變了工作重心。工程師不再逐字調整措辭，而是定義評估指標與資料樣本，把調整交給演算法反覆試探。專案自二零二三年一月建立，至今累積四千七百九十八次提交。
倉庫主體為 Python 程式碼，約五百三十四萬位元組，JavaScript 部分僅約一萬四千位元組，主要用於文件網站。這種比例反映它是一個純函式庫，而非附帶完整介面的應用。
為何它主張用程式取代提示詞？
手寫提示詞難以跨模型移植，換版本就可能失效。以程式宣告任務後，優化器可依評估指標自動重寫指令，同一份程式碼能在不同模型上重新編譯。
提示詞的脆弱性來自耦合。一段針對特定模型調校的文字，往往暗含該模型的格式偏好與推理習慣，換到另一個供應商就需要重寫。DSPy 把這層知識抽離成可重新計算的部分。
代價是前期成本。開發者需要準備具代表性的樣本與明確的評分函式，否則優化器沒有方向。對只做單次問答的場景，這套流程顯得過重；對需要長期維護的多步驟流程，它反而降低反覆調校的時間。
學術脈絡亦支持這種取向。專案附帶的論文清單由二零二二年的檢索與語言模型組合研究開始，逐步延伸到把宣告式呼叫編譯為自我改進流程，路線相當連貫。
3.4 與 3.4.1 版本帶來哪些關鍵變化？
3.4.1 把 GEPA 的結構化指令生成器設為預設，並讓子代理可在解譯器內建立。3.4.0 則加入型別化決策、原生模型引擎與非同步代理流程。
三月版本的更新集中在優化器。舊版把反思示例拼成單一原文提示，再從反引號中抽取新指令；新版改以結構化輸出呼叫反思模型，讓歷史紀錄、工具軌跡與影像型別以原始結構送入。
子代理的改動影響成本計算。每一次子代理呼叫現在都計入呼叫上限，原本只計算主流程的預算估算因此需要調整。
九月發布的 3.4.0 範圍更大。它引入型別化決策，把機率與信心值附在判斷結果上，並加入原生模型引擎、可在受信任程式碼中執行的本機解譯器，以及非同步版本的代理流程。
GEPA 與 MIPROv2 如何自動優化提示詞？
GEPA 以反思方式演化指令，透過評估結果回饋改寫措辭。MIPROv2 同時搜尋指令與示例組合，兩者都需搭配評分函式，優化結果與種子設定相關。
GEPA 的核心是反思迴圈。系統先執行現有程式，取得分數與失敗案例，再要求反思模型針對失敗原因提出修改，並保留表現較好的版本。
指令生成器可調整的參數值得一提。開發者可提供技能檔案作為參考材料，設定字數上限，或替換反思提示但保留原有輸入輸出欄位。這些設定讓優化結果較易落在可預期的範圍。
MIPROv2 走的是另一條路。它把指令與示例視為兩組超參數，以搜尋策略組合出候選方案，再依評估指標排序。
兩者的共同前提是評估品質。指標設計含糊時，優化器只會放大偏差。官方文件把這點列為使用門檻，而非可選項。
它的安全與相容性設計有何調整？
近期提交把受限的序列化載入設為預設，降低快取被濫用的風險，並將 XML 轉接器改為預設格式，同時修正整數精度在資料載入時的流失問題。
序列化載入的調整屬於安全加固。快取機制需要還原先前儲存的物件，而通用的還原流程本身帶有風險，改為受限模式後可執行的型別受到約束。
轉接器的預設值亦已更換。XML 成為預設格式後，既有程式的輸出格式可能改變，若下游有解析邏輯，需要重新確認。
資料處理方面，團隊修正了整數精度問題。以資料表載入整數欄位時，原本可能被轉為浮點數而失去精度，這對需要精確數值的評估流程影響明顯。
專案數據與社群活躍度呈現什麼訊號？
專案累積 38,813 顆星標、3,455 個分支與 411 位貢獻者，提交次數達 4,798 次。近三個月的每週提交量維持穩定，十月更出現密集的修正與功能合併。
星標對分支比約為十一比一，落在工具型函式庫的常見區間。這個比例代表多數採用者直接安裝使用，而非複製原始碼另行維護。
未結問題為 825 項，對四萬星等級的專案屬於偏高水位。問題數量與框架抽象程度相關，越貼近研究前沿的專案，使用者提出的邊界情境越多。
貢獻者結構值得留意。四百一十一人分佈在四百一十一頁的分頁清單中，前段以核心團隊為主，後段則是單次修正的參與者，這種長尾分佈在新興框架中相當常見。
導入前要注意哪些遷移風險？
官方把 3.5 定為舊介面的最後期限，自訂模型的舊方法、舊引擎包裝與相容式呼叫都會移除。升級前需改用新型介面，並重新驗證優化結果。
遷移範圍比版本號看起來更廣。舊版的自訂模型需要改寫為新介面，原本的引擎包裝與相容方法不再支援，僅保留最簡單的字串呼叫形式。
優化結果亦可能改變。指令生成器的預設值更換後，即使種子與資料完全相同，產出的指令也會不同。把分數寫進報表的團隊需要重新建立基準。
保存的程式亦有相容問題。三月版本存檔中評分層級為空的紀錄，在新版本無法載入，需要重新編譯或轉換。
授權為 MIT，商用限制相對寬鬆。專案文件另外提醒評估資料的處理責任，涉及敏感內容時需自行安排去識別化與存放位置。
出處連結有哪些？
本文資訊整理自專案官方倉庫的說明文件、版本紀錄與統計頁面，原始碼、評估範例與問題追蹤都在 GitHub 公開，讀者可自行核對細節與最新版本。
專案原始碼位於 https://github.com/stanfordnlp/dspy，官方文件站為 https://dspy.ai。相關論文涵蓋 GEPA 的反思式指令演化與多階段程式的指令優化，兩者都可在 arXiv 找到公開版本。
總結：哪些團隊適合採用 DSPy？
需要長期維護多步驟流程、且已有評估資料與指標的團隊最適合。若只是單次問答或格式固定的輸出，直接撰寫提示詞的維護成本更低。
框架的價值在於把提示詞從手工藝變成可重複的流程。評估指標一旦建立，換模型與改需求都能用同一套方法重新驗證。
代價是抽象層的重量。簽章、模組、優化器與轉接器構成四層概念，新加入的成員需要時間適應，小規模專案容易在這一層流失效率。
值得觀察的是版本節奏。官方已明確劃出 3.5 的介面期限，這種帶時間表的收斂通常在專案從研究走向工程時出現。對正在選型的團隊而言，接下來兩季的遷移公告比當前的功能清單更具參考價值。
