提示词怎样越改越有依据？DSPy 用失败反馈生成下一版指令

修改提示词时，最常见的依据是“这一版看起来更顺”。如果手里已经有一批任务样本，能不能把失败原因交给程序，让下一版修改有迹可循？DSPy 的 GEPA 教程展示了一条具体路径：样本、评价函数、文字反馈，再到被优化的指令。

这不是一段万能提示词。官方教程选择英文俳句生成，把“怎样算通过”写进代码。它更适合已有明确任务、也愿意检查评价规则的开发者。

先定义失败，才能解释为什么要改

教程让生成器根据季节写俳句，其中一个评价函数检查：生成结果是否直接出现输入的季节词。若出现，得分为 0，并返回一条反馈，要求不要逐字引用该季节；没出现则得分为 1。

这条规则很小，却把“哪里没做好”变成了可执行判断。优化器接收到的不只是一个低分，还有指向具体修改方向的文字。开发者也能读懂，下一版提示为何会加入某项要求。

它同时说明了评价的边界：不出现某个词，不代表诗就好。教程进一步讨论音节、第一人称等约束；这些指标依然只是任务定义的一部分，不能把一个通过率当作完整审美判断。

GEPA 使用 reflection_lm 阅读运行反馈并改写指令，执行任务的模型与承担反思的模型可以分别配置。教程用 compile 将原来的 haiku 程序与训练集、验证集交给优化器，尝试形成更合适的提示。

读者可以继续查看优化后的指令：原本简短的写诗要求，变成对形式和表达限制更细的描述。这里有实际可检查的修改对象，而不是只收到一句“性能提升了”。优化程序还能保存成 JSON 文件，供后续载入与版本管理。

教学情境中，若把任务换成客服消息分类，评价就应围绕自己的标签、漏分与误分来写。不能照搬季节词规则，也不能因为某项字符串检查容易实现，就让它代表全部业务质量。

训练样本为优化提供反思材料，验证样本帮助选择候选版本。验证集既然参与了挑选，就还需要一份没参与修改与选择的测试材料，判断最终程序能否处理新输入。

否则，优化器可能只是越来越会应付那一小组题。评价写得再严格，也要回到它覆盖了哪些真实任务，以及未被覆盖的失败会不会漏过去。

DSPy采用 MIT 许可，优化期间会产生模型调用，成本随模型、样本和搜索规模变化。这个案例留下的实用成果，是一版能保存、能解释修改依据的 AI 程序：每次改了什么，试图修复哪类失败，都有材料可以回看。