设计人机协作工作流程：交接、来源和信心的实用UX模式
作者：Wendy Frey
发布AI功能与发布传统软件非常不同。
对于标准产品特性，行为通常是确定性的：相同的输入，相同的输出。AI系统并非如此。它们引入了概率行为、变化的性能以及新的操作风险，这些风险在发布后仍会持续存在。
这就是为什么构建AI功能需要超越模型选择的思考。真正的工作在此之后开始。
一个完整的AI功能生命周期涵盖从选择合适的模型到监控生产行为、处理故障、应对问题的方方面面。
那些将AI视为一个完整生命周期, 而不仅仅是一个发布事件, 的团队，通常会构建出更稳定的产品。
阶段 1：模型选择
每个AI功能都从一个简单的问题开始：
哪个模型应当驱动这个功能？
这个决策会影响后续的所有方面：成本、延迟、质量、安全性和可维护性。
选择模型不仅仅是关于基准分数。在实践中，团队还会评估：
- 推理速度
- 代币成本
- 上下文窗口大小
- 工具使用能力
- 微调支持
- 隐私和合规要求
在基准中表现最佳的模型，如果成本过高或速度过慢，可能并不适合生产环境。
团队在模型选择时的评估内容
| 因素 | 重要性 |
|---|---|
| 精度 | 核心任务质量 |
| 延迟 | 用户体验 |
| 成本 | 生产可扩展性 |
| 上下文窗口 | 复杂任务处理 |
| 可靠性 | 输入一致性 |
| 安全性 | 数据保护与合规 |
这个阶段通常被低估，但错误的模型选择会产生长期的技术债务。
阶段 2：系统设计与集成
一旦选择好模型，下一步是围绕这个模型构建实际的产品。
这通常包括：
- 提示架构
- 检索系统 (RAG)
- 工具集成
- 记忆系统
- 保护措施和政策层
此时，模型成为更大系统的一部分。
这是重要的，因为大多数AI产品的失败并非仅仅源于模型, 而是模型如何与周围环境交互。
良好的系统设计可以限制影响范围并提高可观察性。
阶段 3：发布前评估
在部署之前，团队需要回答：
这个功能在真实环境中真的有效吗？
这里的评估远非简单的测试提示。
强大的AI评估通常包括：
- 基准测试
- 对抗性提示
- 边缘案例模拟
- 人工审查循环
- 误生成测量
- 延迟和成本分析
发布前评估领域
| 评估类型 | 目的 |
|---|---|
| 精度测试 | 验证任务性能 |
| 压力测试 | 测试系统极限 |
| 红队测试 | 模拟恶意输入 |
| 成本测试 | 估算规模经济 |
| 安全评估 | 检测有害输出 |
跳过这个阶段往往会导致生产中的意外情况。
阶段 4：部署
部署是AI功能成为实际产品的时刻。
与传统发布不同，AI部署通常需要额外的控制措施：
- 金丝雀发布
- 流量调控
- 备用模型
- 限流
- 回滚策略
这很重要，因为AI系统可能会以难以预测的方式失败。
一个模型在预发布阶段表现良好，但在真实用户输入下行为可能截然不同。
测试和现实之间的差距是许多事件的开始。
阶段 5：生产监控
在这一阶段，生命周期变成了持续的。
一旦上线，AI功能需要不断监控：
- 输出质量下降
- 模型漂移
- 异常成本激增
- 延迟回归
- 不安全的完成
- 提示注入尝试
传统的可观察性不足以应对这类需求。
AI可观察性必须包括行为信号，而不仅仅是基础设施指标。
生产中需要监控的内容
| 信号 | 重要性 |
|---|---|
| 延迟 | 用户体验健康 |
| 错误率 | 可靠性问题 |
| 请求每单位成本 | 预算稳定性 |
| 安全违规 | 政策执行 |
| 漂移信号 | 性能随时间变化 |
| 用户反馈 | 现实质量信号 |
团队越快检测到变化，修复起来就越容易。
阶段 6：事件响应
没有任何AI系统是永远完美的。
故障会发生：
- 误生成
- 数据泄漏
- 不良工具执行
- 检索腐败
- 提示注入
- 模型回归
这就是为什么事件响应是生命周期的一部分，而不是可选层。
成熟的AI事件工作流程通常如下：
- 检测异常行为
- 控制问题
- 调查根本原因
- 回滚或修补
- 更新保障措施
- 记录教训
这个结构与软件可靠性和AI治理中的更广泛事件生命周期实践相似。
AI功能生命周期概览
| 阶段 | 主要目标 |
|---|---|
| 模型选择 | 选择合适的基础 |
| 系统设计 | 构建周边基础设施 |
| 评估 | 验证性能和安全性 |
| 部署 | 安全发布 |
| 监控 | 观察真实世界行为 |
| 事件响应 | 恢复和改进 |
重要的是这个循环是迭代的。团队在这些阶段之间不断来回移动。
最终启示
AI功能不是静态产品，而是活系统。
团队犯的最大错误就是将发布视为终点线。
实际上：
- 模型选择奠定基础
- 评估减少不确定性
- 监控保持质量稳定
- 事件响应保持风险可控
最强的AI团队清楚理解一件事：交付功能仅仅是生命周期的开始。
