人工智能 (AI) 产品的开发不能沿用传统软件的生命周期模式，因为它具有两大根本性差异：不确定性和代理权与控制权的权衡。为了应对这些独特的挑战，Aishwarya Naresh Reganti 和 Kiriti Badam 基于他们在 OpenAI、Google、Amazon 等公司领导超过 50 个 AI 项目的经验，首次提出并详细阐述了一个全新的开发框架 - 持续校准/持续开发 (Continuous Calibration/Continuous Development, CC/CD)。
01 AI 产品的根本性挑战——为何传统开发模式不再适用
许多团队在开发 AI 产品时会陷入一个常见陷阱：成功地制作了一个令人印象深刻的演示，获得了认可，但在推进到真正的产品时，系统却开始崩溃，问题盘根错节，难以追溯，最终导致产品无法规模化，用户信任度逐渐流失。这个问题的根源在于，人们忽视了 AI 系统从根本上打破了传统软件产品的基本假设。构建 AI 产品不能像构建其他产品一样，主要有两个核心原因。
AI 产品的固有不确定性 (inherently non-deterministic)
传统软件的行为是高度可预测的。用户通过点击按钮、提交表单等结构化、确定的方式与系统交互。开发者编写的逻辑将这些明确的输入映射到预期的输出。如果出现问题，通常是代码逻辑错误，可以通过追溯代码来定位和修复。
然而，AI 系统在输入和输出两端都引入了不确定性。
用户交互的不确定性：用户不再通过固定的按钮交互，而是使用开放式的自然语言提示 (prompts)、语音命令等。这些输入的验证难度更大，更容易被系统误解，并且不同用户表达相同意图的方式千差万别。
系统响应的不确定性：AI 模型并非基于固定的规则来运行，而是被训练来根据模式生成貌似合理的响应。这意味着，即使用户提出完全相同的请求，系统的回答也可能因为措辞、上下文甚至模型的不同而产生差异。
这种根本性的转变要求开发者改变思维模式。他们不再是为一个可预测的用户流程进行设计，而是为一种可能的行为进行设计，这既包括用户的行为，也包括产品的响应。整个开发过程必须从一开始就考虑到这种不确定性，并持续校准系统的预期行为与现实世界中的实际表现。
AI 产品必须在代理权 (Agency) 和控制权之间进行权衡
代理权 (Agency) 是一个在传统软件中很少被提及的概念。它指的是 AI 系统代表用户采取行动、做出决策或执行任务的能力，这也是AI 代理 (AI agent) 一词的来源。例如，自动预订航班、执行代码或从头到尾处理一个支持工单。
一个至关重要的权衡关系：每当你给予 AI 系统更多的代理权，你必然会放弃一部分控制权。这是一个团队在设计 AI 产品时经常忽视的关键点。如果一个系统只是建议一个回复，用户仍然拥有最终的控制权，可以修改或否决它。但如果系统被授权“自动发送”回复，那么团队必须对它的准确性有极高的信心。
许多团队犯的错误是，在没有充分测试系统在高度受控环境下的行为之前，就直接赋予系统完全的代理权。这种一步到位的做法风险极高。一旦系统出错，团队不仅会失去对系统行为的洞察力，无法进行有效的调试，更重要的是，会彻底摧毁用户的信任。因此，AI 系统的代理权必须是逐步赢得的，而不是一开始就被授予的。
02 解决方案 - 持续校准/持续开发 (CC/CD) 框架详解
为了系统性地解决上述两大挑战，作者提出了 CC/CD (Continuous Calibration/Continuous Development) 框架。这个名字借鉴了软件工程中成熟的 CI/CD (持续集成/持续部署) 概念，但其核心是为不确定性行为和需要赢得代理权的系统而设计的。该框架旨在通过两个相互关联的循环，开发和校准来引导产品开发。
CC/CD 框架的核心目标是通过以下两种方式来应对 AI 的现实挑战：
通过精心的设计和严密的监控来减少系统的不确定性。
确保系统的代理权是随着时间逐步赢得的，而非一次性授予，因为每一个新功能的增加都意味着将更多的控制权从人类手中移交出去。
在部署 (Deploy) 之前，产品开发者处于持续开发 (Continuous Development, CD) 循环中，主要工作是界定问题范围、设计架构和设置评估体系，以控制不确定性。这个阶段从低代理权、高控制权的功能开始，随着系统证明其能力，再逐步向上发展。部署不是终点，而是一个过渡，标志着进入下一个阶段。
部署后，团队进入持续校准 (Continuous Calibration, CC)循环，开始观察真实世界中的用户行为，找出系统的问题所在，并进行有针对性的改进。每一次循环，系统都会赢得更多的代理权，这个过程会形成一个正向的飞轮效应：收紧反馈回路、建立用户信任，并使产品在每个版本中都变得更加强大。
CC/CD 框架的六个核心步骤：
这个框架由一个包含六个步骤的闭环构成，前三步属于 CD 阶段，后三步属于 CC 阶段，中间由“部署”环节连接。
持续开发 (Continuous Development - CD) 阶段
步骤 1: 范围界定与数据策划 (Scope capability and curate data)：从小的、高控制权、低代理权的能力开始。规划如何通过多个版本逐步增加代理权。同时，收集一个参考数据集 (reference dataset)，用于展示“好的行为”是什么样的。
步骤 2: 应用设置 (Set up application)：构建支持当前版本能力所需的最简化架构。避免过度工程化。
步骤 3: 设计评估指标 (Design evals)：创建定制化的评估指标 (evaluation metrics, 简称 evals)，用于追踪系统性能并准确捕捉故障点。
部署 (Deployment) 阶段
将产品部署给一小部分用户群体 (small user cohort)。
持续校准 (Continuous Calibration - CC) 阶段
步骤 4: 运行评估 (Run evals)：将设计好的评估指标应用于真实用户交互产生的日志数据。
步骤 5: 分析行为与发现错误模式 (Analyze behavior and spot error patterns)：分析评估结果，识别反复出现的失败模式和行为模式。
步骤 6: 应用修复 (Apply fixes)：进行有针对性的改动，并利用这些洞察来演进下一个版本。
03 CC/CD 框架的实践应用 - 以客户支持 (Customer support) 自动化为例
步骤 1: 界定能力范围与管理数据 (Scope capability and curate data)
假设你有一个产品创意也已经做好了研究，显然使用 AI 是正确的方法。在传统的软体开发中，你通常会根据功能深度或使用者需求来规划新产品的版本。使用 AI 系统，版本控制仍然适用，但视角会改变。
我们将以客户支持 (Customer support) 为例，讲解 CC/CD 循环的后续步骤。假设您正在为一家公司建立一个完全自主的支援系统。以下是我们将要参考的版本，以及它们对应的代理程式和控制层级。在本文的其余部分，我们将分别引用 v1、v2 和 v3 版本。
v1: 路由 (Routing) - 高控制, 低代理: 仅负责将用户的工单分类并分配到正确的部门。
v2: 助手 (Copilot) - 中等控制, 中等代理: 在路由的基础上，查找相关的标准操作程序 (SOPs) 或过去的解决方案，并为人工客服建议回复草稿。
v3: 解决助理 (Resolution assistant) - 低控制, 高代理: 使用检索到的上下文信息，直接起草或自动解决常见的工单。
在这里，每个版本都由系统拥有的自主权以及你愿意放弃的控制权来定义。因此，与其考虑功能集，不如确定功能范围。首先，确定一组控制力强、自主权低的功能（v1: 路由 (Routing）。这些功能应该规模小、可测试且易于观察。在此基础上，思考如何通过逐步增加自主权（一次一个版本）来演进这些功能。目标是将一个宏伟的最终状态分解成一些早期行为，以便你进行评估、迭代并以此为基础进行建构。
步骤 2: 应用设置
在明确了第一步的范围和数据后，搭建应用的过程应该力求简洁。一个常见的误区是过早地进行过度工程化和优化，即所谓的过早优化是万恶之源。在当前阶段，你应该只构建满足当前版本所需的最简系统，并确保其可衡量、可迭代。
同时，一个至关重要的设计是要确保在需要时，控制权能够无缝地交还给人类。例如，在客户支持的 v1 版本中，如果一个工单被错误地路由，接收该工单的客服人员应该能轻松地重新路由它。这个修正行为不仅能被记录下来用于改进系统，也保障了用户体验，是建立信任和保持系统可恢复性的关键。
步骤 3: 设计评估指标 (Design evals)
在交付任何功能之前，你必须定义如何衡量系统是否达到了预期，以及是否准备好进入下一个阶段。也就是通过评估指标 (evaluation metrics, 简称 evals) 来完成的。评估指标是用于评价 AI 系统工作表现、发现其短板并明确改进方向的评分机制，不同于传统软件中输入输出固定的单元测试，AI 评估需要处理模糊性和不确定性。
例如，对于客户支持的 v1 版本，一个简单而有力的评估指标就是路由准确率 (routing accuracy)，即系统将工单路由到正确部门的频率。对于 v2 版本，评估指标则可能转变为检索质量 (retrieval quality)，即系统建议的解决方案是否与工单相关。在这一阶段，利用第一步中创建的参考数据集来运行评估是一个最佳实践，这有助于衡量初始性能并验证评估指标设计的有效性。
部署
当产品完成了开发循环 (CD) 中的 scoping（范围界定）, setup（应用建立）, 和 evals design（评估设计）之后，便迎来了整个生命周期中的一个关键转折点：部署 (Deploy)。部署不是项目的终点，而是进入持续校准 (Continuous Calibration) 循环的起点。在这个循环中，产品将接受真实世界行为的检验，团队将在此基础上进行学习、分析和迭代。这个循环同样包含三个核心步骤。
步骤 4: 运行评估
部署之后，系统开始与真实用户互动，并产生大量的行为日志。这时，就该运用在开发阶段设计的评估指标来衡量系统的实际表现了。一旦收集到足够有意义的真实交互数据，你就可以开始运行评估。
例如，在客户支持系统的 v1 版本中，你可以分析那些被人工客服重新分配部门的工单日志，这些控制权交接的记录可以作为衡量路由准确率的有力代理指标。在更复杂的系统中，还可以分析对话轮次、用户的点赞或反馈等信号。这些来自真实世界的评估信号，远比基于静态参考数据集的评估更有价值。
步骤 5: 分析行为与发现错误模式
评估结果出来后，无论好坏，都意味着有优化的空间。此时需要进入构建 AI 系统中最被低估但又至关重要的一步：手动审查数据。一个简单的策略是从评估指标最弱的地方入手，因为那里通常隐藏着最有价值的信号。
例如，在客户支持路由系统中，你可以抽取几十个准确率最低的工单进行分析，仔细查看用户说了什么、系统做了什么以及最终结果是什么。当你审查了足够多的案例后，就会开始注意到重复出现的错误模式。例如，密码重置问题总是被错误地路由到账户团队而非技术支持团队，原因可能是系统过度关注账户这个关键词。将这些错误模式、可能的原因和潜在的修复方案记录下来，是进行下一步修复工作的基础。
步骤 6: 应用修复
有了明确的错误模式分析，你就可以开始着手修复。修复措施可能多种多样，从简单的调整提示 (prompt tweak)，到更换更优的模型，再到改进检索质量，甚至增加新的组件来分解任务。这一步应该是有数据支持的、有意识的架构演进，而不是凭空猜测。这个修复过程本身也常常是迭代的。
修复后，需要重新运行评估指标来验证效果，这个过程可能需要反复进行多次。值得注意的是，有时你会发现问题不仅出在系统本身，也出在评估指标的设计上。真实用户的行为可能与你最初的设想大相径庭，导致原有的评估指标无法准确捕捉问题。因此，第六步也可能包括重新审视和构建你的评估体系。这是一个不断塑造产品的过程，通过多次循环，逐步降低系统的控制权，允许其变得更加自主。
04 融会贯通：客户支持系统的 CC/CD 演进之路与核心理念
将 CC/CD 框架付诸实践，意味着将一个宏大的目标分解为多个可管理、可迭代的版本，每个版本都在前一版本学习的基础上增加更多的自主性。以我们一直在讨论的客户支持系统为例，我们可以清晰地勾勒出它的演进蓝图。
在 V1 (路由) 阶段，核心测试目标是“系统能否可靠地对工单进行分类和路由？”。通过这个阶段，我们能学到用户如何描述他们的问题，哪些部门的职责难以区分，以及哪些元数据对路由决策至关重要。这些学习成果，如清理过的路由数据和更清晰的路由决策提示，将直接服务于下一阶段的开发。
进入 V2 (副驾驶) 阶段，测试目标升级为“系统能否检索上下文并起草有用的回复供客服人员审核？”。在这个阶段，我们观察人类客服实际采纳或忽略了哪些建议，检索在哪些环节失败，以及标准操作流程 (SOPs) 中存在哪些差距或不一致。这些观察将帮助我们构建一个精选的文档集，优化检索过滤器和提示格式，并为未来实现更高自主性设置必要的护栏。
最终，在 V3 (自主) 阶段，我们才开始测试系统能否在没有人工介入的情况下完全解决特定范围内的工单？。此时，我们的学习重点转变为自主性在哪些场景下会导致用户信任破裂，哪些任务仍然需要人工介入，以及备用的人工交接机制效果如何。这些反馈将帮助我们定义扩大自主范围的标准，设置更精准的升级触发器，并弥补剩余的功能差距。
这个从 v1 到 v3 的过程清晰地展示了 CC/CD 的核心思想：避免了一开始就构建一个完全自主但问题百出的系统。相反，它从最基础的路由功能入手，收集真实的用户语言信号，然后利用这些信号来改进逻辑和提示，再进入到草拟回复的 v2 阶段。在 v2 中，尽管有人工审核，但我们能准确理解检索系统的短板和需要更新的文档。直到 v3，系统才准备好在已经验证过安全的查询范围内自主解决问题。
05 結論
永远不要以技术为导向，而要让问题、评估和数据来引导你的开发。我们常常看到团队沉迷于追逐最新的工具和框架，结果却犯下代价高昂的错误。
CC/CD 框架的本质，是将开发 AI 系统类比为引导一位新团队成员。即使这位新同事才华横溢，你也不会在第一天就把风险最高的项目交给他。你会从小的任务开始，观察他的表现，建立信任，然后在他证明了自己的能力后，才逐步扩大他的职责范围。AI 系统也需要遵循同样的路径，而 CC/CD 正是为支持这一路径而设计的。它的核心是判断力 - 判断何时发布、如何保护用户、何时交还控制权，以及如何定义足够好。