Prompt Engineering 是一项临时技能
Source: Dev.to
大多数开发者最初注意不到的问题
大多数开发者通过聊天窗口接触 AI。
你输入一些内容。
起初，这种感觉很有力量。通过精心编写提示，你可以**“塑造”输出。经过足够的迭代，你甚至可以得到出乎意料的好结果。许多团队就在这里止步，认为他们已经学会了“使用 AI”**。
问题随后出现
- 在提示编写几周或几个月后，有人尝试复用它。
- 输出会出现细微变化。
- 出现新的边缘案例。
- 同事为了“修复”一个问题而改写提示的某部分，却不小心破坏了另一个功能。
- 提示变得越来越长。
- 上下文被重复。
没有人再完全确定哪些部分是关键的。
最终，提示变成了一个脆弱的工件——它能用就能用，不能用时就失效。
这不是工具的问题，而是一个系统问题。
为什么提示工程在真实系统中会失效
- 提出问题
- 观察响应
- 优化措辞
- 重复
这在一次性任务、研究、头脑风暴和学习中效果良好。
但它并不能清晰地映射到生产软件的构建方式。
生产系统由以下约束定义：可预测性、可复用性、所有权以及随时间的变化。在聊天窗口中编写的提示默认不具备这些属性。
核心不匹配
| 基于聊天的 AI | 生产软件 |
|---|---|
| 鼓励实验 | 需要稳定性 |
| 目标：本次得到一个好答案 | 目标：保证长期行为 |
提示工程优化的是局部成功。软件工程优化的是长期行为。两者的目标不同。
Source: …
提示不是接口
在软件中，接口是你依赖的东西。它有明确的期望：
- 输入内容
- 输出内容
- 不会发生的情况
提示 并不 自然地编码这些保证。
- 两个看起来相似的提示可能表现截然不同。
- 一点文字的改动就可能改变语气、结构，甚至任务的解释。
- 模型没有向后兼容性的概念。
- 除非你自行构建，否则没有模式（schema）强制。
- 唯一的“契约”是“上次似乎能工作”。
团队中常见的失败模式
- 一位开发者编写了一个对其使用场景有效的提示。
- 另一位开发者将其复制到稍有不同的上下文中。
- 随着时间推移，出现了各种变体。
- 通过添加更多指令来修复 bug。
- 该提示变成了 用自然语言编写的、未文档化的微型程序。
此时，团队正在 在没有专门用于维护的工具 的情况下维护逻辑。
为什么系统规模扩大时情况会更糟
- 小系统可以容忍脆弱的组件。
- 大系统则不能。
一旦 AI 在多个地方使用——面向用户的功能、后台任务、内部工具——不一致的代价就会提升。在某个上下文中“基本可以接受”的回复，在另一个上下文中可能是不可接受的。
团队通过在提示中添加更多约束来应对：格式、语气、排除项、回退方案、示例、警告。
讽刺的是，这常被描述为 “更好的提示工程”。
实际上发生的情况是，提示被 推到超出其擅长的范围——它们被用作设计的替代品。
在大规模下，这会导致三个可预见的问题
- 认知负荷
- 隐藏耦合
- 变更瘫痪
这些并非 AI 问题，而是经典的软件维护问题。
更好的思维模型：从提示到用例
帮助的转变 不是 一个新模型或更好的措辞技巧，而是你对 AI 使用方式的概念化改变。
不要从提示的角度思考，而要从 可调用任务 的角度思考
可调用任务拥有一个可以 独立于其实现方式 命名的目的。它回答的问题类似于：
“这个 AI 组件在系统中执行的工作是什么？”
示例用例
- “为 Google 搜索广告生成高意图标题。”
- “将支持工单摘要为面向客户的解释。”
- “将技术文档改写为适合新用户入职的语言。”
这些 不是提示，而是 用例。
一旦你命名了任务，就可以像对待其他系统组件一样对其进行推理。
Source: …
AI 作为基础设施，而非对话
在生产系统中，AI 应该更像 基础设施，而不是协作者。
- 基础设施本质上是 刻意无聊 的。
- 它是 可预测 的。
- 它只 做一件事。
- 它是 可调用 的。
你不需要每次使用它时都与之协商。
- 数据库查询不会因为有人用不同的方式表达而改变行为。
- 支付 API 不会重新解释意图。
接口定义了允许的操作。
AI 组件不必完全确定性，但它们 必须具备有界行为。目标不是产生相同的输出，而是 保持意图一致。
这正是提示（prompts）不足之处。它们太贴近模型的原始行为，向调用者暴露了过多的表面区域。
将 AI 逻辑封装在 稳定的任务边界 后面，可减少这种表面区域。
什么是 AI 包装器
概念上，AI 包装器是一个具名、可复用的任务定义，位于你的系统和模型之间。它编码了：
- AI 预期执行的任务
- 它运行的约束条件
- 输出的结构
- 系统其余部分可以安全假设的前提
重要的不是措辞，而是抽象。
这呼应了数十年前软件工程的转变：
- 从内联逻辑 → 函数
- 从脚本 → 服务
一个具体示例：从提示到可调用任务
基于提示的方法
“生成多个高转化率的 Google 广告标题。关注意图。避免使用通用短语。遵守字符限制。”
此提示已复制、调整并在临时使用中重复使用。
基于任务的方法
任务： GenerateGoogleRSAHighIntentHeadlines
- 只定义一次，拥有明确的契约（输入模式、输出格式、约束条件）。
- 在代码库中可复用。
- 集中改进；系统其余部分依赖 任务名称，而不是脆弱的提示字符串。
要点
- 将 AI 组件视为基础设施——稳定、可调用且有界。
- 定义可复用的任务，而不是散落的原始提示。
- 在包装器后封装提示，以强制执行契约、模式和版本控制。
- 采用与其他服务相同的工程纪律：测试、监控、文档编写和演进。
通过将“提示工程”转变为 任务工程，你可以把 AI 从脆弱的实验性产物，变成生产系统中可靠且可维护的一部分。
Prompt Engineering 与 Wrapped Tasks
以 Prompt 为中心的开发问题
- 不稳定性： 模型可能会变化，内部指令也会演进，但任务边界保持不变。
- 认知负荷： 当 Prompt 直接嵌入代码或配置中时，每个调用点都必须同时理解 它在调用什么 以及 如何向模型提问。
包装任务的优势
采用包装任务的方式，责任转移到 任务定义 本身，开发者可以在更高的抽象层次上思考：
“这个组件需要广告标题。”
“这个服务提供广告标题。”
开发者不再需要在每次调用时考虑语气、排除项或格式化——这些关注点在 一次、单一位置 处理。这就是成熟系统的扩展方式：将复杂性移动到定义明确的边界上。
Prompt Engineering 仍然适用的场景
Prompt Engineering 并非毫无用处；当它被当作最终架构时，只是 误用。
- 探索工具：
- 探索模型能做什么。
- 理解边缘案例。
- 原型化行为。
这类似于在正式化 API 之前编写探索性脚本。错误在于把探索阶段当作生产解决方案。
长期技能胜过 Prompt 小技巧
- 确定稳定的使用场景。
- 定义清晰的任务边界。
- 设计系统可以依赖的输出。
- 在不破坏调用方的前提下演进行为。
这些是 系统设计 能力，而不是 Prompt 编写技巧。
简要介绍 Zywrap
一旦采用基于包装器的模型，接下来要考虑的就是 实现。
- Zywrap 是一个基础设施层，将 AI 用例形式化为可复用、可调用的包装器。
- 它将真实世界的任务捕获为 稳定的系统组件，而不是临时的提示。
- Zywrap 不是 聊天式 AI 的替代方案；它实现了另一种思维模型：AI 作为生产基础设施。
无论是自行构建这样的层，还是采用已有的实现，架构上的转变都是关键所在。
未来：更少提示，更多系统
- 提示工程仍将在探索、教育和实验方面保持价值。
- 它不会成为定义可靠 AI 系统的技能。
长寿系统建立在抽象之上，而非巧妙的措辞。
长期在 AI 领域取得成功的团队，将不再问“我们如何写出更好的提示？”，而是开始问“我们的系统依赖的稳定任务是什么？”
这个问题引导出可维护的设计，这是一项永不过时的技能。