AI Engineer onepage/ DSPy
Maxime Rivest, DSPy · 17:11
這支影片在講：先定義任務，再決定用哪個模型
DSPy 的主張不是再發明一種 prompt 寫法，而是把 AI 系統的穩定邊界放在「任務的輸入與輸出」。模型、設定、模板、權重，甚至底層是否由模型寫程式，都應是可替換的執行策略。
Published: 2026-07-23Video ID: GgLQ02aO-hs
01 / 問題
Prompt 綁住了實作
若 workflow 直接依附某個 provider、模型特性或 prompt template，每次換模型都可能變成重寫應用行為。
02 / 反轉
Signature 先行
先宣告任務真正需要的 inputs 與 outputs，不要預設模型能力或提示詞形狀，讓任務意圖成為穩定 API。
03 / 解法
執行層持續演進
在同一份 contract 下實驗模型、參數、weights、templates 與 output format；DSPy 4.0 更預告模型可在底下寫 code。
Signals
影片最值得抓的四個訊號
Stable boundary
I/O
Signature 把任務縮成明確輸入與輸出，而非綁定某套 prompt。
Version path
3.5 → 4.0
從模組化的程式化 LLM，到預告模型能在 contract 底下產生程式。
Change surface
可替換
模型、settings、weights、templates、輸出格式都可在實作層調整。
Learning loop
互動回饋
程式能直接從使用者互動學習，同時仍受 task I/O 邊界約束。
Core story
把任務與模型分開的三個工程取捨
01
把「任務」當成產品合約
例如摘要系統的合約應描述輸入文件與所需摘要，不應把「使用某個模型、某句 system prompt」當成業務邏輯。這讓上層 workflow 對供應商與模型迭代更不敏感。
02
把「執行」當成可實驗空間
模型選擇、推理設定、模板與輸出格式可隨成本、品質、延遲或新能力調整。代價是 contract 必須寫得足夠清楚，並用 evals 驗證替換沒有破壞結果。
03
讓學習發生在邊界之內
影片把 tools、RLMs 與 skills 視為同一個問題：實作可以越來越聰明，但它仍須尊重已宣告的 inputs 與 outputs，避免自我優化悄悄改掉產品承諾。
Practical implication
對 agent／AI 產品團隊的實務啟發
將 signature 當成介面設計先問：使用者與下游系統真正需要哪些欄位？可驗證的輸出長什麼樣？這會比先挑模型更早排除模糊需求。
把模型切換變成設定變更只要 contract 穩定，routing、fallback、模型升級與成本優化不必滲進每個 workflow；但要保留品質與延遲的回歸測試。
不要把 prompt 當唯一資產prompt 可以是執行策略之一；真正值得 versioning 的還有 input schema、output schema、評估資料與失敗案例。
學習迴圈需有治理從互動更新程式或策略之前，先定義可接受的指標、資料使用邊界與 rollout 機制，否則「自我改進」也會放大未知偏移。
Checklist
如果要把這個觀念帶回產品，先做這五件事
為一個 workflow 寫出模型無關的 I/O contract只保留任務意圖、必要輸入、成功輸出與失敗方式；暫時拿掉 provider 與 prompt 細節。
為 contract 建立少量但真實的 eval cases沒有驗證集，就無法知道「可替換」是工程事實還是抽象承諾。
把品質、成本、延遲分開量測模型與策略替換應依工作負載作取捨，而不是只看單一 benchmark 或 token 單價。
明確記錄輸出 schema 的演進任務契約是穩定邊界，但不是永遠不變；schema 更新需要版本、相容性與 migration 計畫。
將使用者回饋接到受控的改善迴圈先用回饋找出失敗模式，再決定是否調整資料、策略或程式；不要讓線上互動直接改寫產品行為。
Source video