Prompt Engineering 的本质与实践意义

或者说：如果你像一名工程师而不是魔术师一样阅读这本书

在我上一篇文章《Prompt Engineering 无法修复你的架构》发表之后，有些人用各种方式回复：

"好吧，聪明人，但 Prompt Engineering 确实是一项真实的技能。"

是的。编写补偿坏模式的 SQL 也是一项真实的技能。

但这不意味着我们应该以此为职业。

最近我读了《Prompt Engineering》（Lee Boonstra，2025年2月）——那本包含 Chain of Thought、Tree of Thoughts、ReAct、温度参数，以及足够多图表让你在什么都没发货的情况下感觉有生产力的书。

这篇文章不是对这本书的批评。

它是为那些在生产系统中吃过亏的人准备的阅读指南。

这本书真正做对的东西（出人意料地好）

这本书诚实地揭示了大多数 AI 炒作忽视的事实：

LLM 是预测引擎，不是思想。它们猜测下一个 token。反复地。礼貌地。

其他一切——"推理""思考""决策"——都是我们在顶部附加的脚手架。

它描述的技术呢？

这些不是"AI 魔法技巧"。

它们是控制系统。

用重试包装了一个不稳定的 API

添加了幂等性密钥

将响应强制转换为模式，以防止后续崩溃

恭喜。你已经理解了 Prompt Engineering。

你只是没有这样称呼它。

Prompt Engineering 是中间件，只是温度更高

以下是让这本书对我有启发的重新认识：

Prompt Engineering 是概率系统的中间件。

就是这样。

书中的每一项技术都存在于解决这些问题之一：

不可预测的重试

你没有请求的副作用

分布式系统问题。

但你得到的不是日志，而是段落。你得到的不是堆栈跟踪，而是置信度。

为什么 Prompt Engineering 感觉如此强大

因为这是许多团队第一次被迫直面自己的模糊性。

"如果价值观冲突，选择最合理的那个"

模型并不是在变聪明。

它在问你为什么首先存在这种冲突。

这本书花费了数百页来展示如何应对模糊性。

它从不声称要消除模糊性。

这不是一个缺陷。这是一个意外的真理。

书中隐藏的课程（没人转发这部分）

书中最好的 prompt 都有共同之处：

职责范围狭窄

确定的期望

这意味着真正的教训不是：

"成为 prompt 向导"

而是：

"你的系统最终需要边界，而 AI 不会再让你伪造它们。"

Prompt Engineering 不能替代架构。

它强迫你设计一个架构，无论你是否愿意。

Prompt Engineering 实际上正确的用场景

Prompt Engineering 在以下情况下表现出色：

任务本身就是模糊的（语言、摘要、分类）

犯错的成本很低

输出是咨询性的，而非权威性的

你不假装它是确定的

如果你用它来：

强制执行业务规则

做出财务决策

改变生产状态

那么你没有发现智能。

你发现了能说话的技术债。

不要把它当作咒语书。不要把它当作快捷方式。不要把它当作职业身份。

像一名系统工程师那样阅读它，观察一个新的故障模式正在诞生。

Prompt Engineering 不会拯救你的架构。

但它会做一些更好的事情：

它会阻止你继续忽视问题。

这可能就是为什么它感觉如此强大。

一些评论可能仅对已登录用户可见。登录以查看所有评论。

如需进一步操作，你可以考虑屏蔽该用户和/或报告滥用行为。