一个 Prompt 的自我修养：用 DSPy 给 AI Agent 的 SQL 提示做“体检”

上周末，知名开发者 Simon Willison 做了一个有趣的实验：用 DSPy 框架给自己开发的 Datasette Agent 的 SQL 提示词做了一次“体检”。结果发现了一个让人哭笑不得的 bug——系统提示里一句“好心”的建议，反而把模型带进了沟里。

起因：从手调到自动化的冲动 Datasette Agent 是 Simon 打造的一个只读 SQL 问答工具，用户用自然语言提问，AI 自动生成 SQL 并执行。这个工具的核心是一个精心设计的系统提示，告诉模型数据库里有哪些表、该怎么用工具。但 Simon 一直有个心结：这个提示到底好不好？有没有隐含的坑？恰好在 AIE 大会上看到 dspy 的演讲，他决定让 AI 自己来调 AI 的提示。

拆解：用 DSPy 搭了一套“提示的 CI” Simon 的做法的确值得借鉴：他搭建了一个评估 harness，让 DSPy 直接调用 Datasette Agent 实际的工具实现和提示，连接一个内存数据库，然后自动生成了一批“黄金问答”作为测试集。关键来了——他定义了自定义指标，比如 SQL 执行成功率、答案准确性，而不是靠肉眼判断。 跑完一轮，问题立刻暴露出来。原提示里有一句：“如果已经通过 schema 获取了信息，就不要调用 describe_table 函数。” 初衷很好：省 token、少调用。但提示里给的 schema 只列了表名，没有列名！于是模型为了“听话”，就开始猜：这个表大概有个叫 page_count 的列？那个表可能有 o.order_id？结果猜错，SQL 报错，然后模型又重试……陷入循环。 这就像你告诉助手：“地图上已经标了路，别老来问我怎么走”，但地图上根本没画路——助手只能瞎走。

趋势洞察：提示工程正在成为一门“硬工程” 这个案例揭示了一个更大的转变：AI 应用的系统提示，再也不是写一次就完事了。它会随着模型升级、数据变化、使用场景漂移而“变质”。过去我们靠经验、靠 trial-and-error，现在可以用 DSPy、LangSmith 这类工具建立起一套评估 pipeline，让每次修改都跑一套回归测试。这其实就是把软件工程里的持续集成（CI）搬到了 prompt 上。而且你会发现，很多所谓“提示技巧”其实经不起测试，只有用数据说话才能真正打磨出可靠的产品。

实用价值：我们可以怎么用？ 如果你的 AI 应用也用到复杂的系统提示，可以借鉴 Simon 的流程：

1. 建测试集：哪怕是手工几条到几十条示例，也比全靠人眼强。
2. 定指标：别只看“像不像人话”，要看任务是否成功、是否重试、是否产生副作用。
3. 做消融实验：把提示里的某句话删掉或改写，看指标变化。比如 Simon 如果把“不要调 describe_table”软化或改成“先查完整 schema”，问题就缓解了。
4. 别迷信“少即是多”：对于结构化信息，给足上下文常常比精巧的指令更有效。列名、类型、说明，该给就给。

反常识：好心的建议可能是个坑 很多人（包括我）写提示时喜欢加一堆“不要这样”“不要那样”的约束，觉得这样能减少错误。但这个案例告诉我们，不完整的上下文 + 强势的否定指令 = 模型被迫胡乱发挥。真不如把信息给全，让模型自己判断。当你要说“别干某件事”时，先检查一下它干这件事所需的前提条件是否清晰。

Simon 最后提到喜欢其中一个发现：“要么在 prompt 的 schema 列表里直接包含列名，要么把那条建议软化。” 这看似简单，但正是这种从“拍脑袋”到“凭数据”的转变，让 AI 产品质量开始有了工程的味道。下一次你的模型又犯傻了，试试给它做一次“提示的 CI”。

原文地址: Using DSPy to evaluate and improve Datasette Agent's SQL system prompts