为什么你的AI产品需要不同的开发生命周期
摘要
AI产品与传统软件有着根本性的不同：AI系统本质上是非确定性的（non-deterministic），且每个AI产品都必须在自主性（Agency）与控制力（Control）之间做出权衡。基于在 OpenAI、Google、Amazon、Databricks 等公司领导50多个AI实施的经验，作者 Aishwarya Reganti 和 Kiriti Badam 提出了 CC/CD（持续校准/持续开发，Continuous Calibration/Continuous Development）框架。该框架通过逐步赋予系统自主性、持续观察实际行为并定向改进，帮助团队更稳定、更值得信赖地构建AI产品。本文提供了一个完整的六步闭环方法，并用客户支持自动化作为贯穿案例进行说明。
AI产品为何不同
如果你正在发布AI功能或产品，你可能经历过这种场景：演示效果惊艳，早期反馈不错，所有人都很兴奋。但一旦推向生产环境，问题开始层出不穷。这些故障相互纠缠，难以追溯，你的整个产品方法突然显得摇摇欲坠。
AI产品之所以不能像构建其他产品那样构建，有两个原因：
- AI产品本质上是非确定性的
- 每个AI产品都必须在自主性和控制力之间做出权衡
1. AI的非确定性本质
传统软件大致是可预测的——用户通过点击按钮、提交表单、触发API调用等已知方式交互。如果出现问题，通常是代码问题，可以追溯。
AI系统则不同：它们在两端都引入了非确定性——用户如何参与和系统如何响应都是不可预测的。
首先，用户交互界面远不那么确定。用户通过开放式提示、语音命令等自然输入进行交互，更难验证、更容易被误解。
其次，系统行为本身是非确定性的。AI模型基于模式生成看似合理的响应，而非遵循固定规则。同一个请求可以因措辞、上下文甚至模型版本的不同而产生不同结果。
这从根本上改变了你构建和发布的方式。你不再为可预测的用户流程设计——你是在为可能的行为设计。
2. 自主性与控制力的权衡
AI系统有另一个传统软件产品很少需要考虑的层面：自主性（Agency）。在这里，自主性指的是AI系统代表用户采取行动、做出决策或执行任务的能力——比如预订航班、执行代码、从头到尾处理支持工单。
每当你给AI系统更多自主性，你就放弃了一些控制力。 因此，总是存在一个自主性-控制力权衡（Agency-Control Tradeoff）。
大多数团队犯的错误是在未测试系统出错时会发生什么之前，就直接跳到完全自主。如果你在系统尚未经过验证时就赋予过高自主性，你可能会失去对系统的可见性以及用户的信任。
CC/CD 框架：持续校准/持续开发
CC/CD 的名称参考了 CI/CD（持续集成/持续部署，Continuous Integration/Continuous Deployment），但它专为非确定性行为和需要逐步赢得的自主性而设计。
在CC/CD框架中，产品构建者在一个开发（CD）和校准（CC）的持续循环中工作。开发阶段界定问题、设计架构、设置评估；部署后进入校准阶段，观察实际行为、找出故障并进行定向改进。每经过一个循环，系统就可以被赋予多一点自主性，形成飞轮效应。
附注：文中包含 CC/CD 循环流程图，展示开发（CD）三步与校准（CC）三步形成的闭环。
CD 第1步：界定能力（Scope Capability）并整理数据
与传统软件按功能深度规划 v1、v2、v3 不同，AI产品的版本划分取决于系统有多少自主性、你愿意放弃多少控制力。不要从功能集来思考，而是界定能力（Capabilities）：从高控制力、低自主性的功能开始，随着版本迭代逐步增加自主性。
以客户支持自动化为例：
- v1： 仅将工单路由到正确部门
- v2： 系统建议可能的解决方案
- v3： 自动解决并留有人工后备
你还需要构建参考数据集（Reference Dataset）：至少20到100个示例，包含用户查询、期望结果和相关元数据。
附注：文中包含版本与自主性/控制力关系的图表。
CD 第2步：搭建应用（Set Up Application）
有了清晰的能力界定和参考数据集后，搭建应用就相对直接了。关键原则：
- 不要过度设计。 "过早优化是万恶之源"在这里同样适用。
- 只构建当前版本所需的东西。
- 设置日志来捕获系统从用户那里看到的内容、返回的内容以及人们如何与之交互——这将构成你的实时交互数据集（Live Interaction Dataset）。
- 从一开始就考虑控制权移交（Control Handoffs）：确保必要时控制权可以无缝归还给人类。
CD 第3步：设计评估指标（Design Evals）
在发布任何东西之前，你需要定义如何衡量系统是否按预期工作。评估指标（Evals） 相当于传统软件中的测试，但不同的是，AI评估处理的是模糊性——你不仅在检查系统是否运行，还在检查它做得有多好。
Evals 是特定于应用的，与你在第1步中界定的任务紧密相关。对于客户支持路由 v1，一个简单但强大的 eval 是路由准确率（Routing Accuracy）。对于 v2，eval 转向检索质量（Retrieval Quality）。
最佳实践：基于参考数据集运行 evals，而非等到部署后才用真实用户交互来优化。
过渡：部署（Deploy）
部署到一个小范围用户群后，系统开始运行，你进入持续校准（Continuous Calibration）阶段。
CC 第4步：运行评估（Run Evals）
收集到足够多的实时交互数据后，开始运行你在 CD 阶段设计的评估指标。可以基于子集或全量数据运行，取决于成本和计算约束。控制权移交日志（Control Handoff Logs） 也可以提供有价值的 eval 信号。
CC 第5步：分析行为并发现错误模式（Analyze Behavior & Spot Error Patterns）
这是构建AI系统中最被低估但必不可少的环节：手动审查数据。从 eval 指标最弱的地方开始，拉取20到50个低准确率案例，逐一审查用户输入、系统行为和结果。一旦积累了足够的案例审查，你就会开始注意到重复的错误模式，并开始记录它们。
附注：文中包含错误模式记录表示例，包含错误类型、频率、示例和可能原因。
CC 第6步：应用修复（Apply Fixes）
有了可操作的错误模式后，你可以开始制定修复方案——从简单的提示调整，到切换到更好的模型、提高检索质量，或者添加新组件来拆分任务。记住：在CD第2步不要过度设计，因为第6步才是你应该做更多工程的时机——但要基于数据而非猜测。
这一步本身也常常是迭代的：应用修复、重新运行 eval、继续优化。在这个过程中，你很可能还需要重新审视和改进 eval 设计本身——这完全正常。
汇总：客户支持CC/CD循环示例
附注：文中包含一张综合表格，将客户支持自动化的 v1 到 v3 每个阶段的 eval、数据需求、错误模式和修复策略一一对应列出。
CC/CD 方法帮助你避免"一步到位部署完全自主系统"的螺旋式失败。通过逐步提升自主性，你可以在每个版本中积累关于用户行为、系统弱点和所需改进的知识。
核心要点
AI产品构建的核心不是堆叠复杂工具或暴力扩展，也不是写出完美的提示词。它是通过理解问题的细微差别，一步步解决实际问题。CC/CD 提供的是一种结构化的节奏和共同语言，帮助产品领导者将已有的优秀产品直觉应用于AI系统。