试用 DSPy 前，先证明你的 LLM 流程有"合同"
DSPy 很容易被讲薄。
如果只说它是"更高级的 prompt 写法"，第一轮试用大概率会跑偏。更合适的问题是：你的语言模型流程能不能被表达成一个小程序，里面有明确输入、明确输出、固定样例、可查看 trace，并且允许优化器调整提示词，但不改变业务边界？
到了这个点，DSPy 才开始有意义。
我今天复核的来源包括 Doramagic 的 DSPy 项目页、说明书、PROJECT_PACK，上游 README、`pyproject.toml` 和 GitHub API 快照。官方入口仍是 `pip install dspy`；包元数据声明 `name="dspy"`、版本 `3.3.0b1`、Python 范围 `>=3.10,<3.15`。GitHub API 显示仓库在 2026-07-05 仍有 push，近期 PR 涉及 empty devset 的错误提示、Document 格式化、GEPA trace attribution 等细节。
这些信息说明项目活跃，但不等于你该直接引入。真正的采用判断要看三条分界线。
1. 先把任务合同和提示词分开
DSPy 里最值得先看的不是某段 prompt，而是 Signature。
Signature 声明输入和输出字段。Module 把这个合同包成可调用的计算单元。Adapter 再把合同转成模型实际消费的格式，并把模型输出解析回结构化字段。
这会带来一个很实用的评审问题：
团队能不能在调 prompt 之前，说清楚输出字段是什么？
如果不能，DSPy 暂时救不了这个流程。你们还在定义任务本身。第一轮应该只做一个很小的合同：输入文本、检索上下文、答案、引用、置信度，或者产品真实需要的几个字段。不要一上来就做 agent、工具调用、多阶段流水线。
2. 把编译优化和运行正确性分开
DSPy 的优化器可以为模块改进 prompt 或权重。这很有用，但失败模式也变了。
危险用法是："优化器找到了更好的 prompt，发版。"
更稳的用法是："优化器产出一个候选版本，再用固定 devset 对比，检查 trace，保留回滚路径。"
上游最近的改动正好暴露了这个边界。比如 empty devset 不应该悄悄变成除零错误，而应该给出明确 ValueError；GEPA trace attribution 也要按 predictor identity 归因。这里的重点不是某个 PR 本身，而是 DSPy 的真实操作面：优化必须依赖样例、trace 和归因。没有这些，你只是用更复杂的方式移动 prompt 文本。
我的最小验收路径会很朴素：
-
新建 Python 3.10+ 隔离环境；
-
配置一个便宜模型；
-
定义一个 Signature 和一个 Module；
-
跑一个很小但固定的 devset；
-
打印 compiled program 和 history / trace；
-
保存优化前后结果，让人看行为差异，而不是只看分数。
如果这套流程已经嫌重，DSPy 可能不是当前任务的第一抽象。
3. 把检索质量和答案质量分开
DSPy 经常会被放到 RAG 场景里，但 RAG 的问题很少只发生在最终答案。更常见的是 chunk、retrieval、metadata、文档格式、负例样本先出了问题。
所以我不会只用"它能不能回答问题"来评估 DSPy。
我会先看：
-
Module 收到的 retrieved records 是否正确；
-
生成前能不能检查检索结果；
-
输出合同里是否强制引用或 evidence 字段；
-
devset 里是否包含"应该检索失败"的样例；
-
优化器能不能提升答案，同时不掩盖检索退化。
Doramagic 的 DSPy 说明书把项目拆成 Signatures、Modules、Adapters、LM clients、Optimization / Compilation、Tools、Streaming、Retrieval 和 Utilities。这个拆法很有价值，因为它迫使你不要把"最后一句答案"当作唯一测试对象。
适合什么时候引入
DSPy 更适合已经有重复 LM 任务的团队：任务边界基本清楚，有样例，有评测，有 trace，想把 prompt 层变成可编程、可检查、可优化的东西。
它不太适合任务还在产品探索期、没有样例、也说不清正确输出是什么的阶段。那时应该先用普通代码、一个小 eval 文件和人工 trace，把合同稳定下来。
我的采用规则很简单：
当"改 prompt"应该被当作"编译程序"处理时，用 DSPy。
当"改 prompt"其实还在做产品定义时，先别引入 DSPy。
来源：Doramagic DSPy 项目页/说明书/PROJECT_PACK，上游 README、`pyproject.toml`、GitHub API 仓库与 release 快照。
标签：DSPy、LLM、RAG、prompt-optimization、agent-engineering、evaluation、Python、open-source、AI-engineering、observability、retrieval、GEPA