Prompt Engineering 是一种症状（这没关系）

Source: Dev.to

Overview

Or: what this book actually teaches if you read it like an engineer, not a magician.

在我上一次的帖子之后，有几个人回复了类似的内容：

“好吧，聪明的家伙，但提示工程是一项真正的技能。”

是的。

写出能够弥补糟糕模式的 SQL 也是如此。

但这并不意味着我们应该把职业建立在上面。

最近我阅读了《Prompt Engineering》（Lee Boonstra，2025 年 2 月）——这本书里有 Chain of Thought、Tree of Thoughts、ReAct、温度调节旋钮，以及足够多的图表，让你在什么都没有交付的情况下也觉得自己很有生产力。

这篇文章并不是在抨击这本书。
它是给那些在生产环境中被坑过的人的阅读指南。

What the Book Gets Right (Surprisingly Well)

这本书诚实地指出了大多数 AI 炒作忽视的一点：

LLM 是预测引擎，而不是大脑。
它们一次又一次地礼貌地猜测下一个 token。

其他所有的“推理”“思考”“决策”都是我们在其之上加的脚手架。

它描述的技术？

• Chain of Thought
• Step‑back prompting
• Self‑consistency
• ReAct
• JSON schemas
• Output constraints

这些都不是“AI 魔法”。它们是 控制系统。

如果你曾经：

• 用重试包装过不可靠的 API
• 添加幂等键
• 强制响应符合某个 schema，以免后续崩溃

恭喜你。你已经懂得提示工程，只是没有叫它这个名字。

Prompt Engineering Is Middleware With Vibes

下面这个重新框定的观点让我对这本书产生共鸣：

提示工程是概率系统的中间件。

就是这么简单。就是那条推文的内容。

书中的每一种技术都是为了解决以下问题：

• 非确定性
• 缺乏结构
• 合同缺失
• 不可预测的重试
• 你未请求的副作用

换句话说：分布式系统的问题。
但日志换成了段落。
堆栈跟踪换成了置信度。

Why Prompt Engineering Feels So Powerful

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

当你写下：

“如果数值冲突，选择最合理的那个”

模型并没有变聪明。它在问你，冲突本身为什么会出现。

全书用了数百页来展示如何应对模糊性。它从不声称可以消除模糊。这不是缺陷，而是意外的真相。

The Hidden Lesson in the Book (Nobody Tweets This Part)

书中最好的提示都有一个共同点：

• 清晰的输入格式
• 明确的 schema
• 窄化的职责
• 确定性的期望
• 乏味的输出

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

“成为提示巫师”

而是：

“你的系统终于需要边界，而 AI 再也不会让你假装有边界。”

提示工程并不取代架构。它迫使你去设计架构，无论你愿不愿意。

When Prompt Engineering Actually Is the Right Tool

提示工程在以下情况下表现出色：

• 任务本身模糊（语言、摘要、分类）
• 错误成本低
• 输出是建议性的，而非权威性的
• 你可以安全重试
• 你不把它当作确定性的工具

如果你用它来：

• 强制业务规则
• 做出金融决策
• 改变生产状态
• 替代领域逻辑

那么你发现的不是智能，而是会说话的技术债务。

The Takeaway

读这本书。

• 不要把它当成咒语书。
• 不要把它当成捷径。
• 不要把它当成职业身份。

像系统工程师一样阅读，观察一种新的故障模式是如何诞生的。

提示工程不会拯救你的架构，但它会做得更好：它会阻止你继续忽视它。

说实话？这大概就是它让人感觉如此强大的原因。 😎