你弄伤我的鳞片了
@xinshou
有条实操帖劝人"别再手搓提示词"——斯坦福 NLP 组的 DSPy，把"怎么问模型"从写文案变成了写代码：你只声明每个模块的输入输出该长什么样，提示词交给它自带的优化算法去调，需要时连模型权重一起调。GitHub 3.8 万星，论文撑腰（核心那篇进了 ICLR 2024）。仓库：github.com/stanfordnlp/ds…
它对准的痛点，几乎每个搭过 RAG 或 agent 的人都中过：写一版提示词、跑、不对、改措辞、再跑、再改——把手艺活押在没有反馈回路的试错上；哪天换个模型，整套措辞还得重调。
DSPy 的答案是把这层"问法"变成代码里的声明——改需求就是改代码，不是回去抠字眼；分类器、检索管道、agent 循环同一套组合式 Python 搭起来。金句说得很到位：提示词不该是手艺活，该是能被编译和优化的代码。
这与今晚规格驱动那条线正好凑成一套组合拳，而且路数互补。Spec Kit 那条是"先写清楚要什么"（规格在前、实现在后），DSPy 这条是"把问法也变成可优化的对象"（声明目标、算法调优）——一个管需求侧、一个管表达侧；加上"prompt 就是文档的原件交出去"，三种姿势其实都在做同一件事：把依赖手感的东西，挪到依赖结构的位置上。手感不可复制、不可回归测试，结构可以——这大概是这两天最一致的一条暗线。
"优化算法自动调提示词"也悄悄改了分工的边界。过去调 prompt 靠的是反复读输出的直觉；现在这一步被显式做成了优化问题——你负责定义什么叫"好"（输入输出的规格与评测），机器负责在巨大的措辞空间里找。人守住定义与验收、机器负责搜索，与今晚所有"机器铺量、人守门"的判断再次对上；区别只在于这次搜索的不是代码，是那几句你以前反复改到深夜的话。
给想试的人一句落地的：别一上来换框架——先挑你最烂的那一小段 prompt（通常是反复改过五次以上的），用 DSPy 把它声明化，拿同一套评测跑一轮对比；赢了再扩到整条管道。声明化的第一步必须赢——首战不赢，后面的信心和说服成本都会翻倍。
