一个完美的 Demo 和热烈的早期反响，为何最终却可能导致 AI 产品上线后问题频发、信任流失 ？传统软件开发的最佳实践在 AI 时代可能已经不再适用。

基于在 OpenAI、Google 等公司主导 50 多个 AI 项目的经验，Aishwarya Reganti 和 Kiriti Badam 提出了一套全新的开发框架：持续校准/持续开发 (CC/CD)。

本文将深入剖析 AI 产品开发的两个根本性挑战：其内在的“非确定性”，以及“代理权”与“控制权”之间不可避免的权衡。同时详细解读 CC/CD 框架如何帮助团队应对这些独特挑战，从而构建出更稳定、更值得信赖的 AI 产品。希望能为大家带来帮助，Enjoy！

一、什么是持续校准/持续开发 (CC/CD) 框架

公司要启动一个 AI 项目，想法听起来前景不错。团队做出的 Demo 堪称完美，早期评价很好，利益相关者也满心欢喜。于是，团队上下一心，使劲把项目推向了生产环境。

然而，问题开始浮现了。当团队深入细节试图找出症结时，却发现这些问题个个错综复杂，难以追踪，也找不到单一的解决办法。突然之间，整个产品的方向都变得摇摆不定。

这种情况并不少见。在过去几年里，本文作者 Aishwarya 和 Kiriti 帮助超过 50 家公司设计、发布并扩展了 AI 自主系统，服务了成千上万的客户。基于这些经验，他们发现了一个常见的陷阱：人们忽视了一点，AI 系统的底层逻辑，已经从根本上颠覆了传统软件的那些基本假设。

AI 产品的打造方式之所以如此不同，主要有两个原因：

1. AI 产品本质上是非确定性的。
2. 每个 AI 产品都必须在代理权 (Agency) 和控制权 (Control) 之间做出权衡。

如果公司认识不到这些差异，AI 产品就可能出现一连串意想不到的故障和糟糕决策。太多团队都经历过这个痛苦的过程：Demo 看着很惊艳，但系统一上线就无法扩展，或者根本跑不起来。而就在这个过程中，用户对产品的信任也一点点流失了。

在多次目睹这种模式后，他们基于成功部署的经验，设计出了一个专为 AI 产品开发生命周期服务的新框架。这个框架旨在帮助团队正视 AI 系统的独特性，从而构建出目标更明确、运行更稳定、也更值得信赖的产品。

1. AI 产品本质上是非确定性的

传统软件的行为，大体上可以预测。因为用户的交互方式是已知的：比如点击按钮、提交表单，或是触发 API 调用。开发者会编写逻辑，让这些输入对应到确定的输出上。就算出了问题，通常也是代码 Bug，并且也能追溯到源头。

AI 系统的行为方式则有所不同。它在输入和输出两端，都带来了非确定性。换句话说，无论是用户的交互方式，还是系统的响应，都存在不可预测性。

首先，用户交互界面就远不如传统产品那么确定。用户不是通过点击按钮这类结构化的方式来触发，而是通过开放式的 Prompt、语音命令或其他自然语言来输入。这些输入不仅更难验证、更容易被误解，而且用户表达意图的方式也千差万别。

其次，系统行为本身也是非确定性的。AI 模型接受训练，是为了根据模式生成合理的响应，而不是去遵循固定的规则。同一个请求，可能因为措辞、上下文、甚至模型的不同，而产生不同的结果。

这从根本上改变了产品的构建和发布方式。产品设计不再是只针对可预测的用户流程，而是必须考虑各种可能的行为——这些行为既来自用户，也来自产品本身。因此，开发流程必须从一开始就把这种不确定性考虑进来，并持续地去校准预期与现实之间的差距。

2. 每个 AI 产品都权衡代理权和控制权

AI 系统还有一个独特性，就是它的代理权 (Agency)。这是传统软件产品很少需要考虑的因素。

这里说的代理权，是指 AI 系统能代表用户采取行动、做出决策或执行任务（“AI agent” 这个术语也是这么来的）。比如：预订机票、执行代码、从头到尾处理一张支持工单等等。

和传统工具不一样，AI 系统在执行任务时，通常带有不同程度的自主性。但这里有一个常常被忽视的关键点：

每当你给 AI 系统更多代理权，就意味着你放弃了一些控制权。

因此，代理权和控制权之间总是需要权衡。这种权衡至关重要。打个比方，如果系统只是建议一个回复，用户依旧可以否决它；但如果系统会自动发出回复，那最好得保证它万无一失。

大多数团队常犯的一个错误是，在系统出错的后果还没充分测试过之前，就直接给了它完全的代理权。如果一个系统在高度受控环境下的表现都还没有得到验证，那它就没有准备好去获得高度的代理权。

在系统尚未“赢得”高代理权之前就过早交出权限，不仅会搞不清楚系统到底在做什么，还会失去用户的信任。

更严重的是，团队最终会陷进去，不得不去调试一个庞大又复杂的系统。这个系统已经采取了无法追踪的行动，连背后的原因也无从查起，以至于开发者甚至都不知道该从哪里着手修改。

这就引出了为应对这些问题而开发的核心框架。

这个名称借鉴了 CI/CD：持续集成 (Continuous Integration) / 持续部署 (Continuous Deployment)，但又和它不同。CC/CD：持续校准 (Continuous Calibration) / 持续开发 (Continuous Development) 是专为那些行为非确定性、需要逐步赢得代理权的系统而设计的。

二、持续校准/持续开发 (CC/CD) 的具体操作

和传统软件一样，AI 产品也是一步步迭代，最终实现目标的。但打造 AI 产品，必须考虑前面提到的两大核心要素：非确定性，以及代理权与控制权的权衡。

CC/CD 框架的设计，就是为了应对这两个现实情况 ：

1. 通过精心设计或密切监控，来减少系统的非确定性。
2. 确保代理权是逐步“赢得”的，而不是一次性给全。因为每加一个新功能，就等于把一部分控制权从人手里交了出去。

在这个框架里，产品开发者是在一个持续开发 (CD) 和持续校准 (CC) 的循环中工作的：

在开发阶段，团队要先界定问题范围、设计好架构，并建立评估体系，以此来控制非确定性。要从代理权低、控制权高的功能开始做起，等系统逐步证明自己能处理更多场景了，再向上迭代。

接着是部署，但部署并不是结束，只是一个过渡阶段。

部署完成后，就进入了校准循环。这时就要观察系统在真实环境下的行为，找出故障点，然后针对性地改进。每循环一次，系统都会赢得更多代理权。时间久了，这个循环会形成一个飞轮效应，通过紧密的反馈建立起信任，让产品在每个版本迭代中都变得更强。

后文将具体看看 CC/CD 循环的每一个步骤，了解它们的内容、重要性，以及执行方法。

前三个步骤，组成了持续开发 (CD) 这一侧的循环，包括：确定功能范围、设置应用程序和设计评估。

CD 1. 确定功能范围并整理数据

假设有一个宏大的产品想法，并且已经完成了初步研究，明确 AI 是正确的实现路径。在传统软件开发中，通常会根据功能深度或用户需求来规划 v1、v2、v3 版本。

在 AI 系统中，这种版本控制的逻辑依然适用，但视角发生了转变。

在这里，定义一个版本的标准，是看系统拥有多少代理权，以及团队愿意放弃多少控制权。所以，思考方式也必须转变：不再是考虑“功能集”，而是要“界定功能范围”。

首先，要确定一组高控制、低代理权的功能（如图中的第 1 版）。这些功能应该小巧、可测试，并且易于观察。然后，再思考这些功能如何随着时间的推移，一步步增加代理权来演进。目标就是把那个宏大的最终愿景，拆解成一系列可评估、可迭代、也能逐步构建的早期行为。

举个例子，如果最终目标是自动化公司的客户支持流程，那么 v1 版本就可以先从一个高度可控的起点开始，比如把范围限定在“只将工单路由到正确的部门”。到了 v2 版本，系统可以开始建议可能的解决方案。直到 v3 版本，才允许它自动解决问题——但前提是必须带有人工回滚机制。

请记住，这只是一种方法。实际情况会因产品而异，但这个过程往往是一致的：先从那些容易验证、也容易被人工干预的简单决策开始。然后，随着 CC/CD 循环的推进，在每个版本中逐步增加自主性。

在每个版本中要停留多久，取决于观察到的行为信号。优化的目标，就是为了深入理解 AI 在充满噪声和变化的真实世界中，到底表现如何。

来看一些具体例子：

营销助手

• v1：根据 Prompt 起草电子邮件、广告或社交媒体文案。
• v2：构建多步骤的 Campaign 并执行。
• v3：跨渠道启动、进行 A/B 测试并自动优化 Campaign。

编码助手

• v1：建议内联代码补全和样板代码片段。
• v2：为需要人工审核的更大代码块（如测试或重构）生成代码。
• v3：自主应用限定范围内的更改并创建 Pull Request。

如果你熟悉 GitHub Copilot 或 Cursor 的发展历程，就会发现，它们走的正是这条路。

大多数用户只看到当前版本，但它们的底层系统，就是这样一步步迭代上来的。 从代码补全开始，到代码块生成，再到创建 PR，每一步都是靠着用户的使用、反馈和迭代才“赢得”的。

好了，既然用户行为具有非确定性，我们就需要建立一个基准，用来理解哪些是预期行为，以及 AI 系统应该如何响应。 这正是数据发挥作用的地方。 数据能帮我们解决冷启动的问题，并提供评估时能用到的具体依据。 这个基准，就称为“参考数据集”。

拿客户支持自动化的例子来说，对于路由版本 (v1)，参考数据集里可能包括：

• 用户查询
• 应路由到的部门
• 用于决策的元数据，如产品类型、用户层级或来源渠道

这些数据可以从历史日志里提取，也可以根据产品应该如何工作，来手动构造一批样本。 这个数据集不仅能帮我们评估系统性能，还能帮我们看清楚，这个助手到底需要哪些上下文信息，才能跑得更可靠。 大多数产品都是从零开始的，所以目标是先收集至少 20 到 100 个样本。

在接下来的 CC/CD 循环步骤中，会继续使用客户支持这个例子：

假设我们正在为一家公司构建一个完全自主的支持系统。 下面是我们将要用的版本划分，以及它们对应的代理权和控制权级别。 接下来都用 v1、v2 和 v3 来指代这些版本。

CD 2. 设置应用程序

很多团队会跳过第一步，过早地进入设置阶段。结果就是一头扎进各种实现细节里，过度纠结于需要哪些组件。但如果你在第一步正确界定了功能范围，看过了足够的样本，也整理好了可靠的参考数据集，那么设置应用程序这一步就会非常直接。

这时候，你已经清楚系统要做什么，对用户可能提的问题有了初步了解，也明白了什么样的响应才算好。现在，只需要先把最精简的版本搭起来，用来获取有用的信号就行了。

软件行业有句名言：“过早优化是万恶之源”，这句话在这里同样适用。

不要过度设计，也不要过度优化，至少在现阶段不要这么做。只构建当前版本需要的功能就好。需要设置好日志，用来捕获用户输入、系统返回以及用户的交互方式等信息，这样才能让系统变得可测量、可迭代。

这会为将来的实时交互数据集打下基础，也能帮助系统在日后不断改进。这里不会深入探讨实现细节，但有一点，如果产品要开放给最终用户，请一定确保“护栏”和“合规性”这些基础措施都已到位。

还有一个要点：在设置应用程序时，要确保控制权在需要时，能无缝地交还给人类。这些机制，就称为“控制移交” (control handoffs)。举个例子，在客户支持 v1 中，如果一个工单被错误地路由了，那么接到这个工单的专员应该能很轻松地把它重新路由到别处。这个更正行为会被记录下来，这样不仅能帮系统在日后改进，也能维护良好的用户体验。

从一开始就考虑好控制移交，是建立信任和保持系统可恢复性的关键。

CD 3. 设计评估

这一步通常需要深思熟虑。

在发布任何功能前，都得先定义好：如何衡量系统是否达到了预期效果？它是否已准备好进入下一阶段？这就要用到评估指标 (Evals)。

那么，什么是 Evals？

Evals 是一种评分机制，用来评估 AI 系统是否正常工作，在哪些方面有不足，以及需要改进什么。可以把它们看作传统软件里的“测试”。但它和单元或集成测试不同，那些测试的输入输出是固定的，正确性非黑即白，而 AI evals 处理的是模糊性。

Evals 完全是“应用特定”的，和第一步确定的任务紧密相关。它评估的重点，不只是系统“是否在运行”，更是它在执行那些本质上非确定性的任务（比如总结文档或回答问题）时，表现得如何。这就是为什么 evals 没有统一的标准。它们就像信号一样，引导着迭代循环，帮助团队随时间调整和优化系统行为。

举个例子，在客户支持系统的路由 v1 中，一个简单却很强大的 Eval 就是“路由准确性” —— 也就是看系统将工单正确路由到相应部门的频率。单单这一个指标，就能反映出模型是否在学习正确的区分方式，以及系统设置是否稳固。

到了客户支持系统的 v2 阶段，系统开始检索内部 SOP 或历史解决方案来辅助人工客服。

这时，Evals 的重心就转到了检索质量上。我们需要看：系统建议的内容是否和工单相关？这些建议是人工客服会参考的吗？

在这个阶段，一个好的做法是，先在参考数据集上运行 Evals。这能帮我们评估性能，验证 Evals 的设计是不是合理，还能对第二步的产品设置做些早期调整。有些团队会等到部署后，再靠真实的用户交互数据来优化。这种方法行不行，要看系统的风险水平，以及能提前收集到多少参考数据。

不用在参考数据集上过度优化 Evals。我们的目标是广泛覆盖关键的 Use Case，而不是追求完美。生产环境里的行为总会不一样的，但一个强大的 Eval 设置能提供一个可靠的起点。

一旦系统实现了，也验证了范围界定正确、监测手段完善，就可以部署了。部署，就是持续开发和持续校准这两个循环之间的一个过渡阶段。

过渡阶段：部署

部署是个令人兴奋的环节。但部署可不能凭感觉，更不能指望一切顺利。

经过 CD 1 到 CD 3，一个用于学习和改进的管道已经建立起来了：交互会被记录，人工接管的机制已经就位，评估指标也已设好用来标记问题。现在，终于有机会在真实环境中观察系统的运行情况了。

一旦系统面向一小部分用户部署，它就正式开始运行。

从这里开始，就进入了持续校准 (CC) 阶段。真实世界的行为开始显露出来，团队也开始弄明白：哪些功能有效、哪些存在问题，以及下一步需要修复什么。

CC 4. 运行评估

在 CD 循环中，Eval 指标已经设计好了。部署后，有了用户行为日志，就可以评估系统的实际表现了。一旦收集到足够多的实时交互数据，就可以开始运行评估。根据成本和计算资源的限制，评估可以在数据子集或整个数据集上运行。

如果需要在子集上评估，可以利用系统的独有属性，来决定采样哪些数据点。例如，在客户支持系统 v1 中，日志会显示人工客服是否将查询重新路由到了不同部门。这个记录就可以拿来，作为衡量路由准确性的一个代理指标。在更复杂的系统中，可以关注对话轮次、用户是否给出了正面或负面反馈，或是其他会话中的信号。

“控制移交”的日志也能提供有价值的 Eval 信号，特别是当这些日志记录下了人类是如何干预或调整系统结果的时候。

客户支持系统 v1 评估示例

此处的路由准确性为 ⅗ (60%)。根据具体的 Use Case，选择最具代表性的实时用户交互样本来运行 Eval 指标。如果交互数据量较小（2,000 到 3,000 条日志），可以直接在整个数据集上运行。

CC 5. 分析行为并识别错误模式

查看 Evals 的结果时，可能看起来不错，也可能不尽人意。如果持续开发的前三个步骤做得扎实，指标得分通常会处在中间水平，这意味着还有优化的空间。

接下来，就需要手动审查数据了。在构建 AI 系统的过程中，这是个至关重要、却又常常被低估的环节。一个简单的策略，就是从 Eval 指标表现最差的地方入手，那里通常藏着最有价值的信号。

例如，在客户支持系统路由 v1 中，可以：

• 为每个部门找出 20 到 50 个准确性低的工单。
• 重点关注那些得分落后的部门（比如退款部门表现不佳，而账单部门表现尚可）。
• 查看用户说了什么、系统做了什么，以及最终结果是什么。根据应用的不同，这可能是一次交互，也可能是多轮会话。Eval 指标应该能帮你识别出问题所在，并定位到故障点。

一旦手动看过了足够多的样本，就会开始注意到一些重复出现的错误模式。这时要把它们记录下来。一个简单的表格格式在这个阶段就非常有效：

这些模式能揭示出系统逻辑、Prompt 或输入中需要调整的地方，同时也能帮你更有针对性地规划下一个版本的范围。

CC 6. 应用修复

一旦识别出可以着手解决的错误模式，就可以开始规划修复方案了。可能是简单的 Prompt 微调，也可能是更换更好的模型、改进检索质量，或是添加新组件来分解任务。具体要改什么，完全取决于问题出在哪里。

前面提到“不要过度设计”，是因为这一步才是真正该投入工程精力的地方。要在数据的支持下，有意识地去演进系统架构，而不是凭空猜测。

这一步本身也常常需要迭代。可能应用一个修复，再跑一遍 Eval 指标，然后要么继续完善当前版本，要么就回到第 2 步到第 5 步再走一遍，直到系统表现足够好。而且，因为已经有了数据，你不需要每次都重新部署。

同样，Eval 的设计本身也可能存在不足。Evals 毕竟通常是基于参考数据集设计的，而参考数据集反映的是预期的用户行为。然而，真实用户的行为可能大相径庭。

这种非确定性也可能让 Evals 失效。回过头去看第 4 和第 5 步时，可能会发现 Evals 漏掉了一些问题，或者给有缺陷的输出打了高分。因此，第 6 步也可能包括回头去重新审视和重建 Evals，这完全正常。随着产品不断迭代，可能会经历好几轮评估。这都是过程的一部分。

第一次完成第 6 步时，可能已经逐渐适应了这个节奏。团队会多次经历这个循环，一步步减少控制，允许系统变得更加自主，并让产品功能来引导设计上的选择。请记住，部署只是整个蓝图的一部分，大部分的工作都在于精心的设计。

这就引出了一个常见的误区：很多人几乎只关注“实现”，忙着追逐最新的工具和框架，最终却犯了代价高昂的错误。要从一个宏大的目标开始，把它分解开，只有当那些更复杂的解决方案能真正解决实际问题时，才去用它们。

永远不要以技术为起点。要让问题、Evals 和数据来指导你下一步该做什么。 这就是用 AI 产品来驾驭非确定性的方式。

三、客户支持的 CC/CD 循环

下面的表格，展示了一种把问题分解为多个版本的方法，每个版本的代理权会随时间推移而增加。表格也概述了在每个阶段可以构建的飞轮。还是继续用客户支持这个例子来说明。每一次迭代，都是在为下一次迭代铺路。这只是一种可行的处理方式而不是唯一方式。

可以把它当作一个启发，来思考如何分解自己的产品，从而有目的地去构建和扩展。

如果直接发布一个完全自主的支持系统 (v3)，很多事情可能很快就会出错。

举一个简单的例子：一个退款请求，被错误地标记成了账单问题。系统因此拉取了错误的 SOP，并生成了一个看似合理但不正确的解决方案。最终，用户会感到困惑，并对产品失去信任。

虽然可能有 Evals 来标记问题，但这时已经陷入了困境，不得不去解开这一连串的故障。这个错误，最终表现为生成了错误内容。但它的根源其实始于路由问题，又因为缺少上下文而加剧，最终导致了糟糕的结果。这只是一个简单的例子，但已足以说明情况会变得多么复杂。

CC/CD 方法有助于避免这种恶性循环。

在客户支持 v1 中，系统只处理工单路由。这能提供一些信号，让你了解用户是如何表述问题的、哪些部门常常被搞混，以及哪些元数据至关重要。然后，你就可以利用这些信息来改进路由逻辑、优化 Prompt，再进入下一阶段。

在 v2 中，系统基于 SOP 起草响应，但人类仍然会进行审查。这有助于理解，检索到底在哪些地方失败了，以及哪些文档需要更新。

到了 v3，系统就准备好通过解决特定范围内的工单，来承担更多代理权了。但到了此时，你已经很清楚：哪些查询可以安全地自动化，以及在哪些地方需要设置回滚机制。

四、CC/CD 的核心：回归判断力

AI 系统的潜力巨大，能以强大的代理权运行。但要实现这个目标，很少是靠堆砌复杂的工具或用蛮力来扩展。这也不是编写一个完美的 Prompt 就能解决的。

想创建一个能通过有效自动化来节省时间、金钱和精力的 AI 系统，关键在于要理解它的细微差别，并且一步一个脚印地去解决实际问题。

可以把使用 AI 想象成团队里来了一位新成员。这位成员也许非常聪明，但他还不知道团队的工作方式。你不会在第一天就把风险最高的项目交给他。你会让他从小事做起，观察他的表现，和他建立信任。当他证明了自己能胜任时，再逐步扩大他的职责范围。

AI 系统也需要走过同样的路。这正是 CC/CD 框架想要支持的路径。

CC/CD 的核心就是判断力。

这种判断力，能帮你决定该发布什么、在出错时如何保护用户、什么时候该把控制权交还，以及如何定义“足够好”。

每个版本该包含多少功能？收集数据后多久才能推进？范围要界定得多窄？对于这些问题，并没有放之四海而皆准的答案。这取决于你的产品、用户和时间表。有些产品需要花数周时间来迭代，而其他产品则可以推进得更快。这，正是判断力的价值所在。

这种宝贵的产品思维，大部分早已存在于成功的产品领导者心中。CC/CD 只是为这种思维提供了一个结构。这个框架提供了一个循环、一个节奏和一种共通的语言，好让团队能把那些优秀的产品本能，应用到 AI 系统上。