从 Prompt Engineering 到 AI Engineering：构建可靠 AI 功能的工程范式
一位开发者在 Dev.to 上发表文章，探讨了 AI 应用开发正在经历的范式转变：从单纯的 Prompt Engineering（提示词工程）转向 AI Engineering（AI 工程）。文章指出，几年前构建一个 AI 功能看起来很简单——写一个提示词，发给模型，看看回复，改进提示词，重复。但当 AI 功能进入生产环境，一系列工程问题浮现出来，这些问题不是提示词能解决的。
背景：提示词工程的局限
提示词工程能做什么
提示词工程在以下场景中仍然有效：
- 简单任务：文本摘要、翻译、分类等简单任务
- 低风险场景：后果不严重、有人工审核的场景
- 人类负责最终结果：AI 生成内容后由人类确认和修改
- 原型验证：快速验证一个想法是否可行
在这些场景中，写好提示词、迭代优化，确实可以得到足够好的结果。
生产环境的工程问题
但当 AI 功能进入生产环境，问题变得复杂：
- 上下文管理：模型应该接收什么上下文？哪些数据可以访问？
- 工具使用：模型可以使用哪些工具？选错工具怎么办？
- 变更验证：如何知道模型或提示词的变更没有让系统变差？
- 故障调试：如何调试只发生过一次的失败？
- 输出验证：模型生成了格式正确的 JSON，但包含了错误的业务决策，怎么办？
- 自主权边界：对于一个行为是概率性的系统，应该给它多大的自主权？
这些都不是提示词工程问题，而是工程问题。
什么是 AI Engineering
定义
AI Engineering 不是一个全新的学科，而是多个已有领域的组合：
- 软件工程：系统设计、代码质量、测试、部署
- MLOps / LLMOps：模型管理、数据管道、实验跟踪
- 分布式系统：并发、容错、可扩展性
- 安全：访问控制、数据隐私、注入防护
- 测试：单元测试、集成测试、评估框架
- 平台工程：开发者体验、自助服务、黄金路径
变化的是组合方式：模型已经成为一种新的软件组件——一个能够解释自然语言、进行推理、调用工具，但行为是概率性的组件。
与传统软件工程的区别
| 维度 | 传统软件工程 | AI Engineering |
|---|---|---|
| 行为确定性 | 确定性，相同输入产生相同输出 | 概率性，相同输入可能产生不同输出 |
| 测试方式 | 断言输出等于期望值 | 评估输出的质量分布、边界情况 |
| 调试方式 | 断点、日志、堆栈跟踪 | 追踪、评估、回放、提示词版本 |
| 变更管理 | 代码审查、CI/CD | 模型版本、提示词版本、评估集 |
| 错误处理 | 异常捕获、重试、降级 | 输出验证、人工审核、回退策略 |
| 性能指标 | 延迟、吞吐量、错误率 | 准确率、相关性、一致性、幻觉率 |
AI Engineering 的核心实践
1. 上下文工程（Context Engineering）
上下文比提示词更重要。模型的输出质量很大程度上取决于它接收到的上下文：
- 上下文选择：哪些信息应该放入上下文？哪些应该排除？
- 上下文排序：信息的排列顺序影响模型的注意力（"中间迷失"问题）
- 上下文压缩：长上下文需要摘要、检索、分层管理
- 上下文更新：对话过程中如何动态更新上下文？
- 上下文安全：防止提示词注入、数据泄露
传统方式：提示词 + 用户输入 → 模型
AI Engineering：系统提示词 + 检索到的相关文档 + 对话历史摘要 +
工具结果 + 用户输入 + 输出格式约束 → 模型 → 输出验证 → 后处理
2. 评估框架（Evaluation）
没有评估就没有工程。AI 系统需要多层评估：
- 单元评估：单个提示词、单个工具调用的输出质量
- 集成评估：多步骤流程的端到端质量
- 回归评估：变更前后的对比，确保没有退化
- 在线评估：生产环境中的 A/B 测试、用户反馈
- 对抗评估：边界情况、恶意输入、失败模式
评估集的构建是关键：需要覆盖典型场景、边界情况、已知失败模式，并且持续更新。
3. 可观测性（Observability）
AI 系统的可观测性比传统系统更复杂：
- 追踪（Tracing）：记录每次模型调用的输入、输出、延迟、token 用量
- 评估（Evaluation）：自动评估每次输出的质量
- 回放（Replay）：能够回放历史调用，复现问题
- 提示词版本管理：记录使用的提示词版本，支持回滚
- 模型版本管理：记录使用的模型版本，跟踪模型变更的影响
4. 输出验证（Output Validation）
模型的输出不能直接信任，需要验证：
- 格式验证：JSON 结构、字段类型、枚举值
- 业务规则验证：输出是否符合业务逻辑和约束？
- 安全验证：是否包含注入攻击、敏感信息泄露？
- 质量评估：输出的相关性、准确性、一致性如何？
- 人工审核：高风险操作需要人工确认
5. 容错与降级（Resilience）
AI 系统需要设计容错机制：
- 重试策略：模型调用失败时的重试（指数退避、抖动）
- 回退模型：主模型失败时切换到备用模型
- 回退逻辑：AI 路径失败时回退到传统规则逻辑
- 超时控制：防止模型调用阻塞整个系统
- 限流保护：防止模型 API 被过度调用
6. 安全与治理（Security & Governance）
- 访问控制：模型可以访问哪些数据和工具？
- 数据隐私：用户数据是否被发送到第三方模型？
- 提示词注入防护：防止用户输入操纵系统行为
- 内容安全：防止生成有害、违规内容
- 审计日志：记录所有模型调用，支持审计和合规
架构模式
1. RAG（检索增强生成）
RAG 是 AI Engineering 中最常见的架构模式：
- 检索层：从向量数据库、搜索引擎、知识库中检索相关信息
- 排序层：对检索结果进行相关性排序和去重
- 上下文构建：将检索到的信息组织成模型可用的上下文
- 生成层：模型基于上下文生成回答
- 验证层：验证回答是否基于检索到的信息（防止幻觉）
2. Agent 架构
更复杂的 AI 系统采用 Agent 架构：
- 规划器（Planner）：将任务分解为子任务，制定执行计划
- 工具集（Tools）：模型可以调用的外部工具（搜索、计算、API 调用）
- 执行器（Executor）：执行计划中的每个步骤，调用工具
- 记忆（Memory）：短期记忆（对话历史）和长期记忆（知识库）
- 反思（Reflection）：评估执行结果，调整计划
3. 流水线架构
对于结构化的 AI 工作流，流水线架构更可靠：
- 固定步骤：流程是预定义的，每一步有明确的输入输出
- 每步验证：每一步的输出都经过验证，错误不会传播
- 人工检查点：关键步骤设置人工审核
- 可回滚：任何一步失败都可以回滚到之前的状态
团队与组织
角色变化
AI Engineering 需要新的角色和技能组合：
- AI 工程师：兼具软件工程和 AI/ML 知识，负责 AI 系统的设计和实现
- 提示词工程师：专注于提示词设计和优化，但需要理解工程约束
- 评估工程师：负责构建评估框架、评估集、质量指标
- AI 产品经理：理解 AI 能力和局限，定义产品需求和成功标准
- AI 安全工程师：负责 AI 系统的安全、隐私、合规
协作模式
- 跨职能团队：软件工程师、AI 工程师、产品经理、领域专家紧密协作
- 评估驱动开发：先定义评估标准和评估集，再开发功能
- 持续评估：每次变更都运行评估集，确保质量不退化
- 知识共享：提示词、评估集、最佳实践在团队内共享和复用
实践建议
对于刚开始的团队
- 从简单开始：先用提示词工程验证想法，再逐步引入工程实践
- 建立评估集：尽早建立评估集，即使很小，也要有
- 添加追踪：记录每次模型调用的输入输出，便于调试
- 输出验证：至少验证输出格式，防止格式错误导致系统崩溃
- 人工审核：高风险操作保留人工审核
对于已经有 AI 功能的团队
- 建立评估框架：系统化的评估流程，覆盖单元、集成、回归
- 完善可观测性：追踪、评估、回放、版本管理
- 引入容错机制：重试、回退、降级、超时、限流
- 安全审计：定期进行安全审计，检查注入防护、数据隐私
- 成本优化：监控 token 用量，优化上下文大小，选择合适的模型
常见陷阱
- 过度依赖提示词：试图用提示词解决所有问题，忽视工程实践
- 缺乏评估：没有评估集，无法判断变更的影响
- 直接信任输出：不验证模型输出，直接用于生产
- 忽视可观测性：出了问题无法复现和调试
- 给模型过多自主权：在高风险场景中让模型自主决策，没有人工审核
- 忽视成本：不监控 token 用量，导致成本失控
未来展望
AI Engineering 正在快速发展，未来的方向包括：
- 更成熟的工具链：专门的 AI 开发框架、评估平台、可观测性工具
- 标准化实践：行业标准和最佳实践的形成
- 自动化评估：AI 辅助的评估集构建和质量评估
- 自治系统：更高级的 Agent 能够自主完成复杂任务，但需要更严格的安全和治理
- AI 原生开发：从一开始就以 AI 为核心设计系统，而不是在传统系统上添加 AI 功能
总结
从 Prompt Engineering 到 AI Engineering 的转变，反映了 AI 应用从原型到生产的成熟过程。
核心要点：
- 提示词工程的局限：在简单、低风险、有人工审核的场景中有效，但生产环境需要更多
- AI Engineering 的定义：软件工程、MLOps、分布式系统、安全、测试、平台工程的组合
- 核心实践：上下文工程、评估框架、可观测性、输出验证、容错与降级、安全与治理
- 架构模式：RAG、Agent 架构、流水线架构
- 团队与组织：新角色（AI 工程师、评估工程师）、跨职能协作、评估驱动开发
- 实践建议：从简单开始、建立评估集、添加追踪、输出验证、人工审核
- 常见陷阱：过度依赖提示词、缺乏评估、直接信任输出、忽视可观测性
对于正在构建 AI 功能的团队来说，理解这个转变至关重要。写好提示词只是开始，构建可靠、可维护、可观测的 AI 系统才是真正的挑战。AI Engineering 不是要取代提示词工程，而是在其基础上构建完整的工程体系，让 AI 功能能够在生产环境中稳定、安全、高效地运行。
正如文章所暗示的，模型已经成为一种新的软件组件。就像我们不会在没有测试、没有监控、没有错误处理的情况下部署传统软件一样，我们也不应该在没有工程保障的情况下部署 AI 功能。
原文链接：https://dev.to/ikilic/from-prompt-engineering-to-ai-engineering-3onh