Prompt Engineering 无法修复你的架构

Source: Dev.to

每隔几年，我们的行业就会重新发现一个古老的真理，并假装它是全新的。

• 干净的代码。
• 微服务。
• DevOps。
• 现在：提示工程。

突然之间，2019 年只交付过单个 CRUD 应用的人开始在推特上发文：

“The problem isn’t your system. It’s your prompts.”

不。问题仍然是你的系统。提示工程并不是灵丹妙药；它只是对已经感染的架构创口进行的非常昂贵的临时处理。

幻想

幻想是这样的：

• 你的后端很混乱
• API 不一致
• 没有真正的领域边界
• 业务逻辑散布在控制器、定时任务和 Slack 消息中

但随后…

✨ 你加入了 AI ✨
✨ 你优化了提示 ✨
✨ 你在开头加上 “You are a senior engineer” ✨

…于是，智能像电流一样在你的系统中流动，宛如魔法。

但事实并非如此。软件不是这么运作的，任何事物也不是这么运作的。

现实检查：AI 进入你的系统

大语言模型看不到你的产品。它看到的是：

• 你记得传递的任何 JSON
• 能装入 token 窗口的任何上下文
• 某人在凌晨 2 点添加的任何半成品模式

因此，当你的 AI “做出错误决策” 时，它通常正是在执行你所要求的——只是在一个破碎的抽象层中。

那不是幻觉，而是服从。

Prompt Engineering vs. Structural Problems

• ❌ 缺少领域边界 – “请仔细推断用户的意图。”
• ❌ 数据模型不一致 – “如果字段缺失，请自行判断。”
• ❌ 没有真实来源 – “如果多个值冲突，选择最合理的那个。”
• ❌ 业务逻辑分散在五个地方 – “遵循公司政策（如下文 800 个 token 中描述）。”

这并不是 AI 智能，而是把架构决策外包给自动补全。

分布式系统的笑话（其实不笑）

当你构建 AI 代理时，你会很快意识到一些令人不舒服的事实：

AI agents are just distributed systems that can talk back.

它们拥有：

• 状态（而你却假装它是无状态的）
• 延迟（而你却忽视它）
• 故障模式（日志无法解释的）
• 副作用（会发生两次）

因此，当你的代理：

• 对用户双重收费
• 错误地重试操作
• 或者自信地做错事

这并不是“AI 不可预测”。而是经典的分布式系统行为，只是用自然语言来叙述而已。

“但我们有护栏”

大家都这么说。护栏固然好，安全带也是如此。但安全带并不能解决：

• 缺失的方向盘
• 用 YAML 粘合在一起的引擎
• 或者凭感觉决定的路线图

如今的大多数护栏其实只是：

• 更多的提示
• 更多的条件语句
• 更多的 “如果不确定，就询问用户”

到了一定程度，你已经不是在构建系统，而是在与它谈判。

不受欢迎的真相

AI 并不取代架构，它放大了架构的作用。

良好的架构 让 AI 变得乏味、可预测、可靠。
糟糕的架构 让 AI 看起来神奇——直到投入生产、规模化、成本考量、用户真正使用时。

这就是为什么 AI 演示看起来惊艳，而 AI 产品却显得……脆弱。

为什么会一直发生

因为提示工程是：

• 快速
• 可见
• 可推特化

架构是：

• 缓慢
• 不可见
• 只有在失败时才被注意

所以我们优化提示。我们忽视边界。我们在熵之上“intelligence”。然后我们把责任推给模型。

高级开发者观点

• 一个 2,000 令牌的提示，用于解释业务规则
• 不断重试以“做到正确”
• 对每个重要决策进行人工审查

你并没有 AI 问题，而是一个现在说英语的架构问题。

最终思考

提示工程并不能修复你的架构。但它会将其暴露出来——在生产环境中大声、充满信心地展示。说实话？这可能是迄今为止人工智能为我们做的最有用的事。