提示工程正在成为一门一级工程学科

发生了什么

随着 AI 功能从实验走向生产，团队正在像 API 设计一样对待提示工程：版本化管理、审查和测试。提示工程和评估基准等技能正在填补"在我的聊天中有效"和"在 CI 中有效"之间的差距。

早期 AI 功能开发将提示视为非正式的东西——在聊天界面中输入的几个句子，通过感觉调整，直到输出看起来正确。这种方法对原型有效，但在生产中会崩溃。当驱动一个被数千用户使用的功能的提示时，措辞的小变化会产生不一致的行为。底层模型的更改会悄无声息地降低性能。无法回滚、比较或系统改进。

转向将提示作为工程实践的产物正在改变这一点。团队将提示存储在版本控制中，编写测试用例来验证提示对已知案例的行为，并将提示变更视为代码变更——通过代码审查、CI 检查和发布说明。提示工程正在成为一个有自己工具和"完成定义"的学科。

"在我的聊天会话中有效"和"在生产中可靠地有效"之间的差距比大多数团队预期的要宽。为编写它的工程师产生出色输出的提示可能为其他用户、其他输入格式或模型更新后产生不一致的结果。没有系统评估，团队发布的 AI 功能会悄无声息地降级且难以调试。

将提示视为版本化、测试过的产物可以弥合这个差距。当每个提示变更都经过代码审查时，团队在发布前发现回归。当提示有验证预期行为的测试用例时，在模型更新破坏这些案例时，它们会立即在 CI 中浮现，而不是在用户报告中浮现。

技能维度也很重要。提示工程不仅仅是写清晰的指令——还涉及理解模型如何解释歧义、上下文窗口限制如何影响输出，以及如何构建提示以可靠地提取特定信息。这些是可学习的技能，将有效的 AI 用户与无效的用户区分开来。

作为技能的提示工程与其他 AI 素养主题并列于技能部分。目录读者应该理解提示工程不再是一项软技能——这是一门对 AI 功能质量有直接影响的 기술 学科。

对于构建 AI 功能的团队，目录应在评估和基准测试技能旁边提出提示工程。这三者形成一个链条：你写提示，你评估它们是否有效，你对替代方案或随时间推移进行基准测试。

提示版本控制和测试的工具仍在成熟中。观察与现有 CI 管道良好集成并使提示测试像单元测试一样自动化的解决方案。

还要观察模型提供商关于稳定性的实践。今天通过测试的提示行为可能会在提供商更新模型时明天崩溃。团队需要提供商明确说明基础模型多久更改一次，以及什么信号表明回归。