1.1 从手工提示词到声明式LLM程序
我最早做LLM应用的时候，每天的工作就是和提示词死磕。改一个字，跑一遍测试，看看效果有没有变好；不行就再改，加个“请仔细思考”，删个“务必”，换种措辞再来一轮。这种日子过了大半年，说实话效率低得让人抓狂。手写的提示词像手工艺品，每一件都得靠师傅的手感，换个人来写风格就全变了，更别提换模型、换任务的时候那些提示词基本得推倒重来。
后来接触到DSPy这套东西，我脑子里的第一反应是：终于有人把这事想明白了。它做的事情其实很朴素——你不再告诉模型“怎么说”，而是告诉它“做什么”。比如你写一句“给定一段用户评论，判断情感是正面还是负面”，这就够了，具体怎么组织语言、要不要加示例、选哪些示例，交给框架去搜。这就是所谓声明式编程的味道，和SQL的思路有点像：你声明你要什么结果，执行计划由系统来定。
我印象特别深的是第一次把一段手写的复杂提示词改写成DSPy里的Signature。原来两百多个字的提示词，压缩成了三行代码，跑出来的准确率居然还高了几个点。那一刻我意识到，手工调提示词的天花板其实很低，因为你永远在局部最优里打转，没办法系统性地搜索整个提示词空间。声明式的好处就是把“写提示词”变成了“定义问题”，剩下的交给优化器去折腾。
当然，这也不是说手写提示词就没用了。有些特别讲究语气、风格的场景，人写的东西还是更自然。但如果是分类、抽取、问答这类结构化任务，声明式的方式确实省心太多。我现在做新项目，基本都是先想清楚输入输出是什么，然后写成Signature，跑一轮优化看看基线在哪，再决定要不要手工精调。
1.2 Signature、Module与Optimizer三要素
用DSPy绕不开这三个词，我第一次看文档的时候也有点懵，后来自己上手跑了几遍才慢慢有感觉。Signature说白了就是一份契约，它定义了这个模块吃什么、吐什么，中间的提示词长什么样它不管。比如"question -> answer"，就这么简单，模型输入问题、输出答案。你也可以写得更细，比如"context, question -> answer, confidence"，告诉框架我要两个输出字段。
Module是Signature的容器，同时也是行为的载体。DSPy里内置了Predict、ChainOfThought、ReAct这些模块，区别在于它们内部用什么策略去调模型。Predict就是直接问，ChainOfThought会先让模型展示推理过程再给答案。我个人习惯是先用Predict跑基线，效果不够再换ChainOfThought，成本会高一些，但复杂任务上确实管用。Module可以组合，一个模块的输出可以喂给下一个模块，这样就能搭出多步的管道。
Optimizer是我觉得DSPy最有意思的部分。它负责在给定Signature和Module的前提下，自动去搜最优的提示词配置——包括指令文本、few-shot示例的选择，甚至超参数。我一开始以为这东西就是个自动调参工具，用久了发现它更像是一个“提示词编译器”。你给它一个程序（管道），给它一批训练数据和一个评估指标，它帮你把提示词“编译”成表现最好的形态。BootstrapFewShot、MIPRO这些不同的优化器策略，适用的场景也不太一样，有的擅长选示例，有的擅长生成指令，后面章节我会细讲。
这三个要素的关系我打个比方：Signature是菜谱上写的“原料和成品”，Module是厨房里的锅碗瓢盆和烹饪手法，Optimizer是那个帮你反复试菜、调整火候的厨师。少了哪个都做不出一桌好菜。
1.3 编译式优化与评估驱动开发闭环
DSPy最让我改变工作习惯的，是它把“评估”这件事从可选项变成了必选项。以前做LLM应用，评估往往是事后补的，跑几个case看看差不多就上线了。用DSPy你没法这么干，因为优化器需要评估指标来指导搜索，没有指标它就是个瞎子。这个设计逼着我在动手写代码之前先把“什么叫好”定义清楚，一开始觉得麻烦，做久了发现这才是正道。
编译式优化的流程大概是这样：你定义好程序结构，准备好训练集和验证集，写一个metric函数，然后调用compile。优化器会拿训练集去跑，根据metric的反馈不断调整提示词配置，最后产出一个编译好的程序。你可以把这个产物保存下来，部署的时候直接加载，不需要再跑优化。这个过程其实和传统编译器的思路很像——源码（声明式程序）经过编译（优化）变成可执行文件（优化后的提示词配置）。
我特别喜欢这种闭环带来的可复现性。以前手工调提示词，调好了也说不清楚为什么好，别人想复现你的结果基本靠运气。现在优化过程是代码化的，训练集、metric、优化器配置都在版本控制里，任何人跑一遍都能得到差不多相同的结果。这对团队协作太重要了，新人接手项目不用再对着一段神秘提示词发呆。
不过这里有个坑我得提醒一下：metric的设计比想象中难。你写一个简单的准确率指标，优化器可能会找到钻空子的提示词，比如在所有样本上都输出同一个高频类别。我吃过这个亏，后来学乖了，metric里会加一些约束，或者用多个指标加权。评估驱动开发不是万能药，指标设计不好照样翻车。
1.4 关键词边界：提示词优化框架而非单纯模板库
市面上有不少提示词模板库，收集了几百上千条“经过验证”的提示词，按任务分类，复制粘贴就能用。我一开始也用过这类工具，图个省事。用久了发现一个问题：模板是死的，模型是活的。GPT-4上表现好的模板换到Claude或者开源模型上，效果可能天差地别，甚至同一个模型版本升级一下，原来的模板就不好使了。
DSPy和模板库的本质区别在于，它不给你现成的答案，它给你一套找答案的方法。模板库解决的是“我不知道怎么写提示词”的问题，DSPy解决的是“我怎么系统性地找到好提示词”的问题。前者是鱼，后者是渔。你把DSPy理解成一个模板库，那就用歪了，你会觉得它怎么连个现成的分类提示词都不提供，还得自己写Signature、准备数据、跑优化，太麻烦了。
但如果你把它当成优化框架来用，思路就完全不一样了。你会关注训练数据够不够、metric设计得合不合理、优化器选得对不对，这些才是决定效果的关键。我现在的习惯是，遇到新任务先用最简单的Signature跑一遍，看看基线在哪，然后逐步加复杂度。模板库那套“找个好模板改改就用”的思路，在DSPy里反而会限制你的发挥。
还有一点，DSPy的“优化”不只是找提示词文本，它还包括示例选择、指令生成、甚至模块组合方式的搜索。这个边界比模板库宽得多。模板库的产出是一段文本，DSPy的产出是一整个可执行、可评估、可迭代的程序。你把它当成提示词工程的基础设施来看，很多设计选择就说得通了。我现在跟团队里新人解释DSPy，第一句话就是：别把它当模板库，把它当你提示词工作的编译器和测试框架。
2.1 优化目标：指标定义、训练集与验证集
我刚开始用DSPy跑优化的时候，最不适应的一个环节就是写metric。以前手工调提示词，脑子里有个模糊的“好”的标准就行了，看看输出像不像人话，差不多就过了。DSPy不认这一套，你给它一个模糊的目标，它就在那瞎优化，回头你看结果还纳闷怎么越跑越歪。吃过几次亏之后我才老老实实坐下来，把每个任务到底什么叫“对”写成代码。
metric这个东西写得好不好，直接决定优化能不能收敛到有用的方向。我做过一个信息抽取的任务，一开始就写了个简单的字段匹配准确率，结果优化器找了个偷懒的方案——遇到拿不准的样本就把所有字段填成空字符串，因为我的metric里空字符串匹配空标签也算对。跑出来的指标好看得离谱，上线一测全是空。后来我把metric改成了字段级别的F1，空值倒扣分，才把这个漏洞堵上。这事让我记住一个教训：metric就是优化器的指南针，指南针歪了，走得越快偏得越远。
训练集和验证集的划分也有讲究。我一般习惯按7:2:1来分训练、验证和测试，验证集用来在优化过程中观察效果，测试集留到最后才碰。有段时间我偷懒，训练集和验证集从同一批数据里随机切的，结果优化出来的提示词在验证集上表现很好，换一批真实流量进来就掉好几个点。后来学乖了，数据分布尽量对齐线上场景，验证集还会刻意混一些边界case进去，看看优化器会不会在这些难样本上翻车。数据量不大的时候，我甚至会用交叉验证的方式多切几份，看看优化结果稳不稳定。
2.2 Teleprompter与Optimizer的工作机制
Teleprompter这个词我头一回看到的时候愣了半天，心想这不是提词器吗，跟LLM有什么关系。翻了文档才搞明白，它在DSPy早期版本里就是optimizer的另一个叫法，意思是帮模型“提词”的东西——你给模型搭好台子，它负责把该说的词喂到嘴边。现在社区里两种叫法混着用，优化器这个说法更直白一些，teleprompter听起来更形象，各有各的味道。
工作机制拆开看其实不复杂。你把一个待优化的程序、一个训练集、一个metric交给优化器，它就开始一轮一轮地试。每一轮它会拿当前的提示词配置去跑训练样本，拿到模型输出，用metric打分，再根据分数调整配置。调整的方式取决于具体用哪个优化器，有的只动few-shot示例，有的连指令文本一起改，还有的会去搜模块之间的组合方式。整个过程是迭代的，像剥洋葱一样一层一层往好了调。
我调试的时候喜欢把优化过程中的中间产物打出来看。DSPy会把每一轮的尝试记录在实验日志里，翻一翻就能看到优化器在哪些样本上得分低、下一轮它换了什么策略。有一次我发现某个类别总是被分错，看了日志才知道训练集里这个类别的样本太少，优化器根本没学到有效的示例。把数据补上之后，同样参数跑一遍，那个类别的准确率直接涨了二十多个点。这种可观测性对我来说太重要了，手工调提示词的时候你根本不知道模型为什么错，全是黑箱。
2.3 Few-shot示例选择、指令生成与参数搜索
Few-shot示例的选择是DSPy优化里最直观的一块。你给优化器一批标注好的样本，它自己去挑哪几条塞进提示词里效果最好。我一开始以为这就是随机采样，后来自己跑了几轮对比才发现，差别大得很。Bootstrap那套方法会优先挑选那些模型“做对了但不太确定”的样本，这类样本信息量最大，放进去之后模型学得最快。有些任务上，精心挑的五条示例能顶得上手工写两百字指令。
指令生成这块我研究得比较晚。早期我只用示例优化，觉得指令反正就是那句话，写清楚就行。后来试了一次MIPRO，它会把指令文本也作为搜索空间的一部分，用不同的措辞、不同的粒度去试探。结果挺意外的，同样的Signature，优化出来的指令比我手写的版本简洁不少，效果还更好。我印象最深的是一个情感分类任务，优化器生成的指令里带了一句“注意否定词和反讽语气”，这句话我自己压根没想到要写，但它确实抓住了这个任务的痛点。
参数搜索在DSPy里相对轻量一些，主要涉及示例数量、示例顺序、是否加推理步骤这些维度。我一般不会把搜索空间开得太大，太宽了成本扛不住。实际跑下来，示例数量在3到8之间往往就够用了，再多边际收益递减得厉害。有一回我头铁把示例数量上限开到20，跑出来的配置确实在验证集上高了一个点，但token成本翻了快三倍，上线之后老板看到账单脸都绿了。后来我给自己定了个规矩：优化参数之前先想清楚单次调用的预算上限，超了就砍搜索空间。
2.4 Bootstrap与MIPRO等优化策略的适用差异
BootstrapFewShot是我用得最多的优化器，没有之一。它的逻辑很朴实：拿训练集跑一遍，把模型答对的那些样本和推理过程收集起来，从中挑选高质量的作为few-shot示例。适合什么场景呢，任务比较明确、训练数据有一定量、你只想要示例优化不想动指令文本的时候。我一般新项目上手先用它跑个基线，速度快、成本低、结果也稳定。
MIPRO就重一些了。它把指令和示例放在一起优化，思路更激进，搜的空间也大得多。我在做多步推理任务的时候偏爱用MIPRO，因为这类任务光靠示例不够，指令的措辞对模型行为影响很大。有一次做一个数学应用题管道，BootstrapFewShot怎么调都卡在七十多分，换了MIPRO之后指令被优化成了分步引导的格式，分数直接冲到八十五以上。代价是优化时间长了四五倍，跑一轮要等挺久。
还有BootstrapFewShotWithRandomSearch这种折中方案，在Bootstrap的基础上加随机搜索，适合数据量中等、想多试几组配置的场景。我的经验是按任务复杂度来选：简单分类抽取任务用BootstrapFewShot就够了，复杂推理或者多模块管道上MIPRO更值得投入。有时候我也会混着用，先用Bootstrap快速摸个底，再用MIPRO在好配置附近精调，这样成本和时间都能控制住。选优化器这件事没有标准答案，得多跑几轮才有手感。
2.5 自动优化中的过拟合、成本与可复现性控制
过拟合是DSPy优化里最隐蔽的坑。表面上验证集分数一直在涨，你以为模型越来越强，上线之后才发现那只是对验证集过拟合了。我碰到过一次，优化出来的提示词在验证集上九十二分，换一批新数据掉到七十八。排查下来发现验证集里有一批样本的格式高度相似，优化器把那些格式特征当成了分类依据。后来我在验证集里刻意打散格式分布，又加了一个独立测试集做最终把关，这才把过拟合的问题摁住。
成本控制这件事得从优化开始之前就规划。搜索空间开多大、每轮跑多少样本、迭代几轮，这些都直接烧钱。我的做法是先拿小批量数据试跑，看看优化器几轮能收敛，再决定正式跑的时候给多少预算。还有一个省钱的小技巧：在优化阶段用便宜的小模型跑搜索，找到好配置之后再换大模型验证，两边差异不大的话就用小模型的配置上线。我用这招省过不少token钱，效果损失通常在可接受范围内。
可复现性是我最看重的一点。DSPy的优化过程涉及不少随机因素——示例采样、搜索顺序、模型温度，这些都会影响最终结果。我的习惯是固定随机种子，把训练集、metric代码、优化器配置、模型版本全部写进配置文件，跑优化之前先git commit一下。这样别人拿到同样的仓库，跑出来的结果能对得上，出了问题也能回溯。我踩过没做版本控制的坑，优化出来一个特别好的配置，结果忘了存当时的训练集快照，想复现怎么都复现不了，只能从头再跑一遍。这种事经历一次就长记性了。
3.1 声明式管道构建与模块组合
刚接触DSPy的时候，我最大的困惑是“我该怎么把自己的业务逻辑塞进去”。写惯了传统的if-else再去写声明式代码，脑子里总有个声音在问：这玩意到底执行顺序在哪。后来我逼着自己换了个思路，先不想流程，先想清楚每个环节的输入是什么、输出是什么、要它干什么。把Signature定义好，模块自然就长出来了。
Signature写起来像一份契约。比如做个客服工单分类，我就声明输入是工单正文和用户等级，输出是类别标签和置信度。代码里不写“先判断关键词再判断长度”这种规则，只描述问题和答案的形状。DSPy的Module负责把Signature接起来，一个分类模块接一个抽取模块，再接一个回复生成模块，管道就拼好了。我头一回跑通这种管道的时候觉得挺神奇，全程没写一行流程控制，数据自己往下流。
组合模块这事我踩过一个坑。早期我把三个模块串在一起，每个模块的输入输出字段名起得很随意，结果拼的时候对不上，调试了半天才发现是字段拼写不一致。后来我给自己定了规矩：每个模块的Signature先写好文档注释，输入输出字段统一命名风格，复杂管道先画个字段流转图再动手。管道一长，字段对齐比模型本身更容易出错。现在我做多模块项目，第一件事就是在一张纸上把各模块的输入输出列清楚，写代码只是把这个图翻译成DSPy。
3.2 评估体系、数据标注与指标设计
评估体系这件事，我吃过最大的亏是把评估当成了优化之后才做的收尾工作。实际情况是，评估得先搭起来，优化才有方向。我的习惯是先做一个简陋但完整的评估脚本，能跑通数据加载、模型调用、指标计算、结果导出这四个环节，哪怕一开始指标算得粗糙，也比没有强。
数据标注是评估体系里最耗人力的活。我们团队做过一个法律条款抽取的项目，标注规范改了四版才稳定下来。前两版标注完跑出来的模型总是莫名其妙的错，回头查才发现标注员对“条款主体”这个概念理解不一致，同一个词不同人标成了不同字段。后来我们写了一份带例子的标注手册，每个字段给了正例反例，标注员先做一轮试标，对不齐的地方集中讨论，这之后数据质量才上来。
指标设计要考虑业务结果，不能只看模型自嗨。我做过一个文档摘要任务，一开始用ROUGE算分，分数挺漂亮，业务方一看说这些摘要全是废话。后来改成让业务方自己列几条硬标准，比如必须包含金额、必须包含日期、不能出现推断性语言，把这些标准写成规则加上模型打分，评估结果才跟真实需求对上。指标这玩意，宁可丑一点也要贴业务，漂亮的假指标比没有指标更危险。
3.3 编译产物、版本管理与部署集成
DSPy编译出来的东西我一开始以为是个模型权重，后来发现它就是一堆配置——优化后的指令文本、挑出来的few-shot示例、模块的超参数。这些配置序列化成一个文件，部署的时候加载进去就行。我现在的习惯是把编译产物跟代码仓库分开管理，代码走git，编译产物按版本号存到对象存储里，两边用配置文件里的版本号关联起来。
版本管理这块我吃过一次大亏。有回生产环境的一个抽取任务突然准确率掉了十来个点，排查半天发现是有人重新编译了一版配置直接覆盖上线了，没走review流程。那次之后我们立了个规矩：任何编译产物上线前必须跑固定测试集，指标不能低于上一版的九十五个百分点，不达标打回重来。编译产物的版本号也跟git的commit hash绑定，出了问题能直接回溯到当时的代码和数据。
部署集成比想象中简单。DSPy程序本质就是个Python对象，包一层FastAPI或者塞进现有的服务框架都行。我做过一个方案是把编译好的配置存成JSON，服务启动时加载，换配置只需要重启服务或者热加载。模型本身通过环境变量配置，优化阶段用便宜模型，生产阶段换强模型，代码不用改。这种解耦让运维舒服很多，配置和代码各管各的，出问题定位起来快。
3.4 多阶段RAG、Agent与工具调用场景的扩展
RAG场景是我用DSPy最多的方向。一个典型的RAG管道我拆成四块：查询改写、文档召回、相关性重排、答案生成。每块都是一个独立的Module，各自有Signature。查询改写那块优化出来的指令挺有意思，原本我手写的是“改写成更清晰的问题”，优化器给改成了“补充同义词和限定条件，保留原始意图”，召回率直接涨了八个百分点。这种细节手工真想不到。
Agent场景就复杂多了。我做的一个任务规划Agent，需要根据用户请求决定调哪个工具、传什么参数。DSPy里我用ReAct模式搭了个骨架，把工具描述写成Signature的一部分。难点在于工具调用的错误处理，模型有时候会传错参数类型。我的做法是在工具函数外面包一层校验，参数不对就返回错误信息让模型重试，同时在metric里对重试次数扣分。这样优化出来的配置会更谨慎地选择工具和参数。
多阶段管道的扩展性我特别看重。管道一长，某个环节出问题会连锁影响后面所有环节。我的经验是给每个阶段单独做评估，先保证每个模块在自己的测试集上达标，再拼起来跑端到端。端到端测试集也要单独准备，专门放那些跨环节的难例。有一次我的重排模块召回率不错，但端到端答案质量差，查下来是重排把长文档截断了，答案生成拿不到关键段落。这种问题只有端到端测试才能暴露。
3.5 常见落地误区与调试方法
第一个误区是把DSPy当银弹。我见过团队上来就搭复杂管道，五个模块串一起，优化跑了一整天，结果还不如手工写的一个prompt。后来复盘发现是每个模块的Signature定义得太模糊，模型根本不知道自己该干嘛。我的建议是先用单个模块跑通、评估达标，再逐步加模块，每加一个都重新评估，别一口气吃成胖子。
第二个误区是跳过基线直接优化。我吃过这个亏，优化出来的配置看着指标不错，但不知道比手工版本强多少，也不知道优化器到底贡献了什么。现在我固定先做一个手工提示词基线，记录指标，再跑优化，两者对比着看。有时候优化结果还不如基线，那就得查是metric的问题还是数据的问题，这种对比让我少走了很多弯路。
调试方法我总结了几条实用的。一是把优化过程的实验日志全部存下来，DSPy会记录每轮尝试的配置和分数，翻日志能看出优化器在哪个方向使劲。二是做消融实验，固定其他变量只动一个，比如只改示例数量看指标变化。三是拿失败样本单独跑一遍，看模型输出跟预期差在哪，是理解错了还是格式不对。我常用的一个笨办法是把失败案例打印出来贴墙上，看多了模式自己就浮出来了。调试这事没有捷径，多跑、多看、多记，手感是喂出来的。
4.1 定位差异：优化编译框架 vs 应用编排框架
我一开始把DSPy当成LangChain的平替来用，这个念头害我走了半个月弯路。后来才算想明白，LangChain更像一盒乐高积木，它关心的是你把哪些组件拼起来、怎么拼、拼成什么形状；DSPy关心的是拼好之后每一块的性能能不能被自动调优到最好。一个管的是流程骨架，一个管的是零件质量。
我做过一个小型的合同审查demo。LangChain那版我两天就搭起来了，文档加载器、文本分割器、向量检索、LLM调用，链式串起来跑得挺顺。换成DSPy重写，头一天我连Signature该怎么定义都没想清楚。这种感觉像是从搭积木换成了调发动机，前者看的是结构，后者盯着的是燃烧效率。两边的思考维度根本不在一个层面上。
定位差异带来的直接影响是上手成本。我团队里新来的同学用LangChain半天就能跑出一个可用的问答链，用DSPy第一天基本都在纠结metric怎么写、训练集怎么切。DSPy的前置门槛明显更高，它要求你先把评估体系想清楚才能动手。这件事放在做demo阶段是负担，放在一个要长期迭代的项目里就变成了优势。
4.2 抽象方式：Signature与Module vs Chain与Agent
LangChain的抽象我觉得最直观的就是Chain和Agent。Chain是一根线，把A的输出接到B的输入；Agent是一个调度器，让模型自己决定走哪条路。写代码的时候脑子里有画面，数据怎么流、模型怎么选工具，看得见。
DSPy的抽象是Signature加Module。Signature描述“输入长什么样、输出长什么样”，Module负责把Signature连起来。我刚用的时候总觉得少了点什么，找不到显式的流程控制代码，心里不踏实。用久了才发现，这种声明式的写法逼着我去想清楚每个环节的契约，而不是急着写if-else。
举个具体的。LangChain里做分类，我会写一个prompt模板加上一个Parser，再用Chain串起来。DSPy里我先定义“输入工单内容，输出类别和理由”这个Signature，Module里再用Predict或者ChainOfThought。真正让我适应的是，DSPy不让我在代码里写死提示词，提示词交给优化器去生成。一开始我很不适应，总觉得失去了控制权，后来发现优化出来的指令确实比我手写的更贴合任务。
Agent那块区别更明显。LangChain有个现成的AgentExecutor，我把工具列表塞进去就能跑。DSPy里我用ReAct模块，工具描述要写进Signature里，整个agent的行为也要接受评估和优化。前者像是拿来就能用的成品，后者像是给你一套工具让你自己打造。
4.3 提示词策略：自动优化 vs 手工与模板组合
这是两个框架最本质的分水岭。LangChain的提示词是一条一条手写的，模板、变量、few-shot示例，全靠人往里塞。我做过的项目里，一个中等复杂度的链上有七八个prompt模板，改一处要连带测试一整套，改到后面我自己都记不清哪个版本对应哪套效果。
DSPy的提示词是编译出来的。我给它metric、给数据、给优化器，它自己去找示例、写指令、调参数。第一次跑BootstrapFewShot看到优化出来的指令，我愣了一会。我原本写的是“根据上下文回答用户问题”，它优化成了“仅使用上下文中出现的信息回答，找不到答案时明确说明”。这种细节我手工想不到。
不过这不意味着DSPy的提示词一定比手写的好。我遇到过一个情感分类任务，优化器给出的指令太长太细，模型反而容易分心。后来我把metric改严了一点，优化结果才收敛。LangChain手工提示词的优势在于可控，每一句都是我自己写的，出了问题我能一眼定位。DSPy优化出来的东西如果指标不对，得回头查metric查数据查优化器配置，排查路径长得多。
我现在的做法是两边都用。项目早期用手写prompt快速验证可行性，效果卡在瓶颈了再切到DSPy去做自动优化。手工那版的指标我留着，当作基线，优化结果要跟它对比。
4.4 评估与迭代：指标驱动编译 vs 运行链路编排
LangChain的迭代方式是围绕运行链路展开的。今天是换一个retriever，明天是加一个fallback，后天是调一下temperature。每次改动都要手动跑一批case看效果，评估脚本经常是临时写一段。
DSPy把评估这件事提到了核心位置。没有metric就没法compile，没有训练集就没有优化方向。我一开始觉得这是负担，后来意识到这其实是把评估从“事后检查”变成了“事前约束”。钱花在数据标注和指标设计上，比花在反复手调prompt上回报高得多。
我记得有个抽取项目，LangChain年代我靠肉眼看几十条结果来调prompt，调了一个礼拜 F1 从 0.72 涨到 0.76，再往上就卡住了。换DSPy以后我把那批肉眼过的数据整理成训练集和验证集，写了个字段级别的F1 metric，Bootstrap跑了三轮验证集涨到 0.83。这件事对我的冲击不在于那7个点，而在于迭代方式本身变了——从感觉驱动变成了指标驱动。
LangChain那边我依然会用它做链路编排，包括retriever的切换、工具的分发、多路召回合并，这些编排逻辑跑起来很顺。评估部分我单独抽出来自己写，或者干脆把这部分交给DSPy。两个框架各管一摊，边界清楚。
4.5 选型建议与组合使用方式
我的选型标准挺朴素。如果项目一周内要出demo、流程比效果更重要、链路结构经常变，选LangChain。如果项目要长期跑、指标卡在瓶颈上不去、有稳定的评估数据，上DSPy。这不是非此即彼的事，两个框架完全可以一起用。
组合用的方式我试过几种，最顺手的是用LangChain做外层编排，把DSPy程序当成一个组件塞进去。举例子说，一个多路RAG管道，召回部分我用LangChain的不同retriever组合，每个retriever的答案生成环节换成DSPy编译好的模块。外层管数据流，内层管单点质量，两边各司其职。
还有一种反过来的用法，用DSPy做整体编译，内部某些模块里调用LangChain的agent。这种场景我一般用在需要工具调用的环节，LangChain的agent生态成熟，工具接入方便，外层再用DSPy去优化调度策略和指令。
我踩过的一个坑是早期想用一个框架包打天下，LangChain那边硬塞评估优化逻辑，DSPy那边硬写复杂链路编排，两边都写得很别扭。后来放弃了这种执念，哪个框架擅长什么就让它干什么。工程上没必要追求单一技术栈，技术选型的第一原则是好用，不是纯粹。
给团队新人培训的时候我说过一句话，我现在也常跟自己对一遍：LangChain教你怎么把复杂问题拆成组件，DSPy教你怎么让每个组件自己变好。两件事都是真功夫，谁也替代不了谁。
5.1 典型应用场景：问答、抽取、分类、RAG与多Agent
我把DSPy往几个实际场景里塞过之后，慢慢摸出了一点场景适配的手感。最顺手的是分类和结构化抽取这两类任务，它们的输入输出边界清楚，metric好写，训练数据也容易攒。我之前做过一个工单分类的项目，二十多个类别，人工写prompt怎么写都容易漏掉长尾类别。用DSPy编了一版，few-shot示例由优化器自己挑，长尾类别的召回直接涨了一截。这种“输出空间固定、评估标准客观”的任务，几乎是DSPy的主场。
问答就复杂一些。开放域问答的metric不好定义，答案对不对有时候得靠人判断，光用精确匹配或者语义相似度都会失真。我试过用LLM当裁判去打分，效果可以，成本上去了。后来我把问答拆成“检索段落命中”和“答案抽取”两段分别评估，整体好控制多了。DSPy本身不解决metric难写的问题，它只是把这个问题放大了摆到你面前，逼着你正面处理。
RAG场景我觉得是DSPy最能体现价值的地方之一。链路里检索、重排、答案生成每一环都有可调参数，手工调起来像在黑暗里拧旋钮。用DSPy把生成环节的几个模块编译一遍，再把检索的top-k、chunk大小这些参数一块纳入搜索空间，整体效果比单点手调要稳。多Agent场景我实践得少一些，跑过一个小型的工具调度agent，ReAct模块加上Signature里描述工具契约，能跑通，但优化效果受限于工具调用数据的稀缺。这块我打算后面再深挖。
5.2 团队协作与提示词资产治理
一个人写prompt和一群人写prompt是两码事。我以前待过一个团队，五个人维护同一套问答系统，prompt散落在各个yaml、py文件里，改一处要群里吼一声同步。有人调好了没提交，有人提交了没说明，过两周谁也不知道哪版最好。这种混乱不是人的问题，是工具形态的问题——prompt以字符串形式存在，天然没法版本化、没法对比、没法复用。
DSPy带来的变化挺实质的。Signature变成了一种团队间的契约，输入输出定义清楚，谁负责哪个模块一目了然。优化器的配置、训练集、metric都进了代码仓库，编译产物跟着版本走。我们后来把每个模块的基线指标挂到CI上，谁改了数据或者metric，跑一遍就知道有没有退化。这种治理方式我之前在传统软件工程里见惯了，搬到提示词这块还是第一次。
提示词资产这个概念我觉得会越来越被重视。手写prompt其实是隐性知识，写的人走了，为什么这么写就说不清了。DSPy的编译产物虽然也不能百分百解释，但它至少把“用了哪些示例、指令长什么样、在哪个数据集上达到了什么分数”这几件事记录下来了。团队接手的时候有个抓手，不用从零重来。
5.3 与主流LLM、向量库和观测工具的集成趋势
DSPy对模型的支持目前覆盖了OpenAI、Anthropic、本地vLLM部署这些常见路径，切换起来主要改配置。我用过一段时间本地部署的模型跑优化，速度慢但成本可控，适合在实验阶段反复折腾。这种“编译一次、多处部署”的形态挺符合工程直觉的，优化阶段用强模型，线上跑用便宜模型，DSPy的抽象层把这块隔离开了。
向量库这块DSPy本身不绑定，它更像是通过Retriever模块让你自己接。我接过Chroma、Weaviate和pgvector，写法上没太大差别，无非是封装成统一的接口。我觉得这种“不绑定”是聪明的，向量库这块生态变化太快，绑死了反而是负担。
观测工具是最近我比较关注的方向。DSPy编译出来的程序在线上的表现需要通过trace去观察，哪一步慢、哪一步错、哪一步召回质量差，光看最终答案看不出来。LangSmith、Phoenix这些工具现在对DSPy的支持在慢慢变好，我试过把DSPy的调用链trace到Phoenix里，能看到每个Module的输入输出和耗时。这块生态我觉得还在早期，未来一两年应该会有更原生的集成方案出来，毕竟做LLM应用的人越来越意识到可观测性不是可选项。
5.4 局限、风险与效果评估边界
DSPy不是银弹，我用下来最明显的一个局限是它对数据的要求比想象中高。metric写不好，优化方向就偏；训练集太小或者分布偏，优化出来的指令会过拟合到那几十条样本上。我遇到过一次，训练集只有三十条，优化器给出的指令里塞了一堆奇怪的限定条件，在验证集上还行，上线以后面对真实用户输入就翻车。这件事让我养成了一个习惯：训练集至少过百，验证集跟着真实分布走。
成本也是绕不开的。一次完整的编译要跑很多轮LLM调用，尤其是MIPRO这种策略，烧token的速度挺吓人的。我一般先在便宜模型上做个粗筛，找到大致的优化方向，再切到强模型上精调。这种策略省钱，但试错时间变长了。团队要上DSPy之前，最好先算一下编译成本，别等到账单出来才后悔。
还有一个我觉得要清醒看待的点——DSPy评估的是任务指标，它没法评估“提示词是否合适这个业务场景”。有些任务指标上去了但用户体验变差了，比如答案变短变生硬，或者拒答率莫名升高。这些边界上的问题还得靠人工抽检和线上反馈来兜底。DSPy把优化自动化了，没有把判断自动化，这两件事得分开看。
5.5 从DSPy实践看提示词工程的发展方向
用完DSPy这一圈，我对提示词工程的看法变了不少。以前觉得这是个“巧劲活”，靠灵感靠经验靠反复试。现在我觉得它越来越像传统机器学习的一部分——有数据、有指标、有训练验证集、有编译产物、有版本管理。这种转变对从业者的要求其实更高了，得懂评估、懂数据、懂怎么定义任务，光会写prompt不够用了。
我猜未来的提示词工程会分成两层。一层是偏工程的，负责把复杂任务拆成模块、定义好Signature、设计好metric，这层会越来越标准化。另一层是偏业务的，负责判断“这个任务的指标是不是我们真正想要的”，这层很难被自动化。DSPy这类框架吃掉的是前一层里那些重复劳动，让工程师能把精力放到后一层上去。
我团队里现在的做法是把DSPy当成基础设施的一部分，而不是当成一个玩具项目。新项目立项的时候就把metric和数据集这件事摆上桌，别等到后期再补。这个习惯改起来痛苦，改完以后迭代速度确实快了不少。我也不敢说这条路一定对，毕竟整个生态还年轻，工具在变、模型在变、最佳实践也在变。边走边修，是我目前的态度。
