# 试用 DSPy 前先证明你的 LLM 流程有“合同”DSPy 很容易被讲薄。如果只说它是“更高级的 prompt 写法”第一轮试用大概率会跑偏。更合适的问题是你的语言模型流程能不能被表达成一个小程序里面有明确输入、明确输出、固定样例、可查看 trace并且允许优化器调整提示词但不改变业务边界到了这个点DSPy 才开始有意义。我今天复核的来源包括 Doramagic 的 DSPy 项目页、说明书、PROJECT_PACK上游 README、pyproject.toml 和 GitHub API 快照。官方入口仍是 pip install dspy包元数据声明 namedspy、版本 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 不应该悄悄变成除零错误而应该给出明确 ValueErrorGEPA 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