DSPy：斯坦福「不要写提示词，要写程序」的声明式 LLM 框架

过去两年，「Prompt 工程」在实践里逐渐变成一件很脆弱的事：把几百字的系统提示改来改去，靠人肉试错，换个模型、换个任务就得重写一遍。斯坦福 NLP 团队（Omar Khattab、Matei Zaharia、Christopher Potts 等）的回答是 DSPy——名字取自 Declarative Self-improving Python，它主张把「写提示词」这件事变成「写可编译、可优化的模块化程序」。本文基于其 GitHub 仓库（stanfordnlp/dspy，MIT 协议）与官方文档站 dspy.ai，梳理它的三层抽象、优化器家族，以及它成立的前提条件。

一、背景：手写 Prompt 为什么不可持续

DSPy 的学术源头可以追溯到 2022 年底的 Demonstrate-Search-Predict（DSP）论文，正式框架论文《DSPy: Compiling Declarative Language Model Calls into Self-Improving Pipelines》发表于 ICLR 2024。它瞄准的痛点很明确：当一个 AI 系统由多个 LLM 调用串联（检索、改写、推理、校验、生成），每一环的提示词都是手写且互相耦合时，系统既无法维护、也无法自动优化——你没有一个可以对着评测集「编译」的中间表示。

DSPy 的解法是把 LLM 应用拆成三层：Signature（声明要做什么）、Module（怎么调用 LM）、Optimizer（自动把它变好）。开发者只写结构化的 Python 代码，具体的指令词、few-shot 示例、甚至小模型的权重，都交给优化器在一个评测指标下自动搜索。

二、三层抽象：Signature、Module、Optimizer

根据 dspy.ai 文档，核心概念如下：

• Signature：用输入字段（InputField）/输出字段（OutputField）声明任务语义，例如「把问题转成一条检索查询」或「从段落里抽取事件」。开发者不写「你是一个乐于助人的助手……」，只声明 question -> query 这类类型化签名。
• Module：对 LM 的一次可组合调用。内置模块有 Predict、ChainOfThought、ReAct / ReActV2（带工具调用的 Agent 循环）、MultiChainComparison、ProgramOfThought、CodeAct、Refine 等；可以像搭积木一样把多个 Module 串成 RAG 或 Agent 流水线。
• Optimizer：这是 DSPy 的灵魂。它拿一个 Signature/Module 程序 + 一个评测 metric + 一批带标注（或可自动打分）的样本，自动搜索更好的指令、示例选择，乃至微调小 LM 权重。

优化器家族相当庞大：文档列出 GEPA、MIPROv2、BootstrapFewShot 系列、COPRO、BootstrapFinetune、BootstrapRS、SIMBA、KNNFewShot 等。其中 GEPA（Reflective Prompt Evolution，2025 年 7 月论文） 是当前主推方向，官方论文称「反思式提示进化可以超过强化学习」。

三、关键数据与生态位置

仓库与文档页可核对的工程数字：

需要说明：「38.4k star」「Databricks/Shopify/Dropbox 在用」是社区热度与厂商露出信号，不直接等于效果；真正决定 DSPy 价值的是优化器在你自己任务上能否跑赢手写 prompt。GEPA「超过 RL」的结论来自其论文在特定 benchmark（如数学推理、结构化抽取）上的对比，不是跨任务普适结论。

四、评测方法与成立前提

DSPy 最容易被忽视、却最关键的一点是：优化器的质量完全取决于你喂给它的 metric 与样本。它本质是一个「在评测集上做搜索/进化」的编译器——如果你的 metric 不准、样本太少或分布不覆盖真实流量，优化器会很高效地把程序优化到一个错误目标上（Goodhart 效应）。

由此带来几个必须正视的口径问题：

• 优化是有成本的：每一次优化都要反复调用 LLM（生成候选指令/示例、打分），token 开销和时延不小；BootstrapFinetune 这类还会真正去微调小模型，需要训练资源。
• 「Program, don’t prompt」不是「不用理解 prompt」：它把调参的对象从字符串换成了 Signature/Module 配置与 metric，抽象层更高，但前置学习曲线不低——文档专门有一章《Optimizers: choosing one》，说明选哪个优化器本身就是个难题。
• GEPA > RL 有边界：那是论文在受控 benchmark 上的结论；在你自己的长尾数据上，是否真的更优、是否更省，仍需自测。

五、适用与不适用

适合：

• 要构建多环节 RAG、Agent 循环、结构化抽取等可复用、需长期迭代的 LLM 系统；
• 已经有一批评测样本和一个可自动计算的 metric，想用自动搜索替代手工调 prompt；
• 愿意把 prompt 当「超参数」工程化管理、并跨模型迁移（换 LM 后重新编译即可）。

不适用：

• 一次性脚本、单条提示词就能解决的小任务——上一整套 Signature/Module/Optimizer 是明显过度工程；
• 没有评测集、无法定义 metric 的探索性项目——优化器无处发力；
• 想要开箱即用托管服务的团队——DSPy 是库，你自备模型 key、优化算力与部署。

六、客观分析：优势与局限

优势：它提供了 LLM 应用领域少见的「可编译、可优化」抽象，把 prompt 从手艺活变成了可工程化、可版本化、可跨模型复现的对象；优化器家族（尤其 GEPA）背后有斯坦福的持续研究输出，生态被 vLLM/LangChain 周边广泛引用，38k star 说明社区认可度高。

局限：抽象带来学习成本与调试难度——出问题时栈是「程序 → 编译出的 prompt → LM」，定位比直接看一段 prompt 更绕；优化效果强依赖评测信号，且优化本身烧 token；版本迭代极快（3.x 大版本已到 3.4），API 仍在变动（文档里专门有 BaseLM 接口迁移说明）。

七、它意味着什么

DSPy 代表了一种与「Prompt 工程手工作坊」截然不同的路线：把 LLM 系统当作可被编译器优化的程序来对待。随着模型越来越便宜、可评测数据越来越多，「写声明、让框架自动搜提示词和微调」很可能成为严肃 LLM 应用的主流开发范式之一。对正在从 demo 走向生产、需要持续打磨效果的团队，DSPy 值得评估——但前提是你先把评测集和 metric 建好，否则它只是一个更花哨的 prompt 包装器。

参考来源

• DSPy GitHub 仓库（stanfordnlp/dspy）
• DSPy 官方文档（dspy.ai）
• DSPy 论文：Compiling Declarative LM Calls into Self-Improving Pipelines（ICLR 2024）
• GEPA：Reflective Prompt Evolution Can Outperform Reinforcement Learning（2025-07）