标题够挑衅:《Fuck You, Show Me The Prompt》。2024年2月,机器学习工程师Hamel Husain发了这篇博客,理由很朴素——市面上一堆LLM框架都在抢着帮你"写好prompt",可你根本看不到它们最终发给模型的是什么。
他给的解法也很朴素:装一个开源HTTPS代理mitmproxy,把Python程序发出去的所有请求截下来看。不用啃源码,不用翻文档,原始请求一目了然。
抓包这件事,原理不复杂
mitmproxy的用法说白了三步:启动代理监听本地端口,把系统或Python环境变量指向这个端口,再装一张证书解密HTTPS流量。装好之后,任何框架不管封装得多花哨,发给OpenAI、Anthropic接口的原始请求都会原样出现在日志里。
这套东西不挑框架,因为它拦的是网络层,不是某个库的内部实现。谁在用requests或httpx发请求,谁就跑不掉。
同一件事,调用次数差几十倍
Husain把当时几个热门框架挨个跑了一遍,结果很扎眼。
Guardrails做结构化输出校验,靠塞一大段XML说明书当prompt,遇到JSON解析失败还要再发一次"修复"请求,一次任务至少两次调用。Guidance演示的一个规划工作流,实测打了7次API调用,其中5次只是为了生成候选方案。LangChain的SmartLLMChain模式更直白:生成多个答案、互相批评、再合成最终答案,一套流程4次调用。DSPy走得最远——它的优化器为了从候选池里挑出验证集上表现最好的few-shot示例,一次优化能发出数百次调用。
数字放在一起看,差距不是量的问题,是量级的问题。Guardrails和LangChain的开销还在"多花点钱"的范围内,DSPy这一步的开销已经是另一种成本结构。
自动化的代价,是知情权
DSPy自己的说法是"prompt退居幕后,系统会替你编译出有效提示词"。guidance的说法是"这套编程范式比传统prompting更可控、更高效"。这些话没说错,但都绕开了一个问题:为了拿到这份"自动优化",你要多付出多少次调用、多少延迟、多少美元。
框架越自动化,你越该问它替你多打了几次电话
Husain在文章里提的四个问题,现在看依然是好用的清单:这个框架真的必要吗？能不能把它吐出来的最终prompt偷出来,直接弃用框架？我能不能写出更短更贴合意图的prompt？这堆调用次数,合理吗？
这四问背后是软件工程的老话题——essential complexity和accidental complexity的区分。LLM抽象的特殊之处在于,它经常把"用自然语言表达意图"这件本该最直接的事,重新包装成写代码、学术语、啃文档。这和费曼那句"不能造出来,就是没真正理解"是一个道理:如果你说不清框架替你构造了什么prompt,你也谈不上真正理解你的应用在做什么。
- 风险.调用次数不透明,意味着延迟和账单也不透明,尤其是DSPy式的优化阶段,成本可能是应用运行成本的数倍。
一年多过去,LangSmith之类的调用追踪工具确实在补这块空白,但"默认可见"和"需要额外配置才能看见"完全是两种产品哲学。多数框架选的还是后者——不是做不到,是没有动力主动摊开给你看。
Husain的文章标题很冲,内容却克制:他不是让你弃用框架,是让你在按下"compile"之前,先看清框架替你打了几次电话,再决定这笔钱花得值不值。这件事从2024年到现在,答案没有变得更乐观。