介绍持续校准/持续开发 (CC/CD) 框架
作者：AISHWARYA NARESH REGANTI 和 KIRITI BADAM
日期：2025 年 8 月 19 日
如果你是一位负责发布人工智能 (AI) 功能或产品的产品经理或开发人员，你很可能经历过这样的场景：
你的公司面临着推出 AI 相关产品的巨大压力。一个充满前景的想法应运而生，团队成功完成了演示，早期反馈看起来不错，利益相关者们也都兴奋不已。于是，你全力以赴地将它推向生产环境。
然而，各种问题开始接踵而至。你陷入了困境，拼命想弄清楚哪里出了错。但这些问题盘根错节，难以追溯，而且似乎没有任何一个单一的解决方案。突然之间，你感觉整个产品的开发方法都变得岌岌可危。
我们一次又一次地目睹这种情况的发生。在过去几年里，我们帮助了超过 50 家公司设计、发布并扩展了为成千上万客户服务的、由 AI 驱动的自主系统。在所有这些经历中，我们发现了一个常见的陷阱：
“人们忽视了 AI 系统从根本上颠覆了传统软件产品基本假设这一事实。
你不能像开发其他产品一样去构建 AI 产品，原因有二：
AI 产品本质上是非确定性的。 每个 AI 产品都必须在智能体能力与控制之间进行权衡。
当公司没有认识到这些差异时，他们的 AI 产品就会面临意想不到的故障和糟糕决策等连锁反应。
我们见过太多团队经历从一个令人印象深刻的演示到一个无法扩展或维持的系统之间的痛苦转变。而在此过程中，用户对产品的信任也在悄然流失。
在多次看到这种模式上演后，我们根据成功部署的案例，为 AI 产品开发生命周期开发了一个新的框架。该框架旨在识别 AI 系统的独特性，帮助你构建更具目的性、更稳定、更值得信赖的产品。
读完这篇文章后，你应该能将自己的产品映射到这个框架中，并更好地了解如何开始、重点关注哪里以及如何安全地扩展。
让我们来深入探讨一下，构建 AI 产品与传统软件究竟有何不同。
1. AI 产品本质上是非确定性的
传统软件的行为或多或少是可预测的。用户的交互方式是已知的：点击按钮、提交表单、触发 API 调用。你编写的逻辑将这些输入映射到对应的输出。如果出现问题，通常是代码缺陷，并且可以追溯到源头。
AI 系统的行为则截然不同。它们在两端都引入了非确定性。换句话说，无论是在用户参与方式还是在系统响应方式上，都存在不可预测性。
首先，用户交互界面远非确定性。用户不再通过点击按钮等结构化触发器进行交互，而是通过开放式提示、语音命令或其他自然输入方式。这些输入更难验证，更容易被误解，并且用户表达意图的方式也千差万别。
其次，系统自身的行为本质上也是非确定性的。AI 模型被训练来基于模式生成看似合理的响应，而不是遵循固定的规则。同一个请求，可能会因为措辞、上下文甚至模型的不同而产生不同的结果。
这从根本上改变了你的构建和发布方式。你不再是为可预测的用户流程进行设计，而是为可能的行为——无论是来自用户还是产品——进行设计，而非保证的行为。
你的开发过程需要从一开始就考虑到这种不确定性，并在你的预期与现实世界中出现的情况之间进行持续校准。
2. 每个 AI 产品都需要在代理能力与控制之间进行权衡
还有一个层面让 AI 系统与众不同，这是我们在传统软件产品中很少需要考虑的：代理能力。
在此背景下，代理能力是指 AI 系统代表用户采取行动、做出决策或执行任务的能力（这也是术语 “AI 智能体 (AI agent)” 的由来）。例如：
预订航班 执行代码 从头到尾处理一张支持工单
与传统工具不同，AI 系统被设计为可以具备不同程度的自主性。但这里有一个人们常常忽视的部分：
“每当你赋予 AI 系统更多的代理能力时，你就在放弃一部分的控制权。
因此，代理能力与控制之间的权衡始终存在。并且这种权衡至关重要（非常重要！）。如果你的系统只是建议一个回复，你仍然可以否决它。但如果它自动发送回复，你最好确保它是正确的。
大多数团队犯的错误是，在没有测试过系统出错时会发生什么的情况下，就直接跳到完全的代理能力。如果你没有在高控制下测试过系统的行为，你就没有准备好赋予它高代理能力。如果你在系统尚未赢得信任之前就赋予过多的代理能力，你可能会失去对系统的可见性，并失去用户的信任。
更糟糕的是，你将不得不调试一个庞大而复杂的系统。这个系统所采取的行动你无法追踪，其背后的原因你已无法洞察，因此你甚至不知道该修改什么。
这就引出了我们为帮助团队应对这些差异而开发的核心框架。
我们称之为 CC/CD：持续校准/持续开发。
这个名字参考了持续集成/持续部署 (CI/CD)，但与后者不同，它适用于行为非确定性且代理能力需要逐步赢得的系统。
持续校准/持续开发框架
就像传统软件一样，AI 产品也会经历多个阶段以实现最终目标。但构建 AI 需要你考虑我们前面提到的两件事：非确定性和代理能力与控制的权衡。
CC/CD 框架旨在通过以下方式来应对这两个现实：
通过设计或密切监控来减少系统的非确定性。 确保代理能力是随着时间的推移逐步赢得的，而不是一次性授予的，因为每一个新功能都会将控制权进一步从人类手中转移。
在我们的框架中，产品构建者在一个由开发 (CD) 和校准 (CC) 组成的持续循环中工作。在开发阶段，你界定问题范围、设计架构并设置评估，以控制非确定性。你从低代理能力和高控制的特性开始，然后随着系统证明其能处理更多任务而逐步提升。
然后你进行部署，但这并不是终点，而是进入下一阶段的过渡。一旦部署，你就进入了校准循环，在这里你观察真实的行为，找出问题所在，并进行有针对性的改进。
每经过一个周期，系统就会赢得更多的代理能力。随着时间的推移，这个循环会变成一个飞轮，收紧反馈、建立信任，并使产品在每个版本中都变得更强大。
让我们更深入地探讨 CC/CD 循环的每一步，了解它的具体内容、重要性以及如何做好。前三个步骤构成了循环的持续开发部分：界定能力、设置应用程序和设计评估。
CD 1. 界定能力和整理数据
假设你有一个宏大的产品构想，并且已经完成了研究。很明显，AI 是正确的实现路径。在传统的软件开发中，你通常会根据功能的深度或用户需求来规划产品的 v1、v2、v3 版本。对于 AI 系统，版本划分仍然适用，但视角发生了变化。
在这里，每个版本都由系统拥有的代理能力和你愿意放弃的控制程度来定义。因此，你不再从功能集的角度思考，而是从能力的角度来界定范围。
首先，确定一组高控制和低代理能力的特性（如上图中的版本 1）。这些特性应该是小型的、可测试的并且易于观察的。然后，思考这些能力如何通过一次一个版本地逐步增加代理能力来随时间演进。目标是将一个宏伟的最终状态分解为可以评估、迭代并在此基础上逐步构建的早期行为。
例如，如果你的最终目标是实现公司客户支持的自动化，一个高控制的起点是将 v1 (版本 1) 界定为仅仅将工单路由到正确的部门。然后发展到 v2，系统可以建议可能的解决方案。最后在 v3 才允许它在有人工后备的情况下自动解决问题。
请记住，这只是一种方法。具体实践会因你的产品而异，但过程往往是一致的：从易于验证且易于人类干预的简单决策开始。然后，随着你在 CC/CD 循环中前进，每个版本都逐步增加更多的自主性。
你在每个版本中停留多久，完全取决于你观察到的行为信号有多少。你的优化目标是理解你的 AI 在真实世界的噪音和变化下的行为。
这里还有几个例子：
营销助理
v1: 根据提示起草电子邮件、广告或社交媒体文案。 v2: 构建多步骤的营销活动并执行它们。 v3: 跨渠道启动、进行 A/B 测试并自动优化营销活动。
编码助理
v1: 建议内联代码补全和样板代码片段。 v2: 生成更大的代码块（如测试或重构）供人类审查。 v3: 自主应用范围内的更改并开启拉取请求。
如果你关注过像 GitHub Copilot 或 Cursor 这类工具的演进，就会发现它们使用的正是这套 playbook。大多数用户只看到当前版本，但其底层系统是逐步攀登这个阶梯的。先是补全，然后是代码块，再然后是 拉取请求，每一步都是通过使用、反馈和迭代赢得的。
现在，因为用户行为是非确定性的，你需要为预期行为的样子以及你的 AI 系统应如何响应建立一个参照。这就是数据发挥作用的地方。数据有助于打破冷启动的僵局，并为你提供一些可以进行评估的具体依据。我们称之为参考数据集。
在客户支持自动化的例子中，对于路由版本 (v1)，你的参考数据集可能包括：
用户查询 应该路由到的部门 用于做决策的元数据，如产品类型、用户等级或渠道
如果可用，你可以从过去的日志中提取这些数据，或者根据产品的预期工作方式生成示例。这个数据集帮助你评估系统性能，并告诉你助理需要什么上下文才能可靠地执行任务。由于大多数产品都是从零开始，目标是预先收集至少 20 到 100 个示例。
我们将继续使用客户支持的例子来讲解 CC/CD 循环的后续步骤。想象你正在为一家公司构建一个完全自主的支持系统。下面是我们将引用的版本，以及它们对应的代理能力和控制级别。在本文的其余部分，我们将一直使用 v1、v2 和 v3。
CD 2. 设置应用程序
大多数人会跳过第 1 步，过早地进入设置阶段，结果迷失在实现选择中，并过度思考需要哪些组件。但是，如果你在第 1 步中恰当地界定了能力范围，查看了足够多的示例，并整理了一个坚实的参考数据集，那么设置应用程序应该会相当直接。
你已经知道系统需要做什么，对用户可能提出的问题有了感觉，并了解了好的响应是什么样的。现在，只需将最简单的版本连接起来，以获得有用的信号。
软件界有一句名言，是有其道理的：“过早的优化是万恶之源”。这句话在这里同样适用。不要过度设计，不要过度优化。至少在这个阶段不要。只构建当前版本所需的东西。
通过设置日志来捕获系统从用户那里看到的内容、它返回了什么以及人们如何与之交互，从而使系统变得可衡量和可迭代。这将构成你的实时交互数据集的基础，并帮助你随着时间的推移改进系统。
我们在这里不会深入探讨实现细节，但如果你要将此功能暴露给最终用户，请确保像防护机制和合规性这样的基础工作已经到位。
还有一点很重要：在设置应用程序时，确保在需要时可以将控制权无缝地交还给人类。我们将这些称为控制权交接。例如，在客户支持 v1 中，如果一个工单被错误路由，接收代理（该部门的联系人）应该能够轻松地重新路由它。由于这种更正被记录下来，它不仅有助于随时间改进系统，还保护了用户体验。从一开始就考虑控制权交接是建立信任和保持事物可恢复的关键。
CD 3. 设计评估
这部分通常需要一些思考。在发布任何东西之前，你需要定义如何衡量系统是否达到了你的预期，以及它是否为下一步做好了准备。你可以使用评估指标（简称 evals）来做到这一点。
那么，什么是 evals 呢？
Evals 是一种评分机制，可以帮助你评估你的 AI 系统是否正常工作、它在哪些方面存在不足以及需要改进什么。
你可以将它们视为传统软件中测试的等价物。但与典型的单元测试或集成测试不同（在那些测试中，输入和输出是固定的，正确性是二元的），AI 的 evals 需要处理模糊性。
它们完全是特定于应用程序的，并与你在第 1 步中界定的任务相关联。你不仅仅是检查系统是否能运行——你是在检查它在执行像总结文档或回答问题这样本质上非确定性的任务时做得有多好。这就是为什么 evals 不是一刀切的。它们作为指导你迭代循环的信号，帮助你随时间调整和优化行为。
例如，在客户支持系统的路由 v1 中，一个简单但强有力的 eval 将是路由准确性——系统将工单路由到正确部门的频率。仅凭这一点就可以告诉你模型是否在学习正确的区分，以及你的设置是否稳固。
在客户支持系统的 v2 中，当你检索内部的标准操作程序 (SOPs) 或过去的解决方案来协助代理时，你的 evals 会转向检索质量。建议是否真的与工单相关？它们是人类代理会查看的内容吗？
这个阶段的最佳实践之一是，针对第 1 步中的参考数据集运行 evals。这可以帮助你衡量性能，验证你的 evals 设计是否良好，并对第 2 步的产品设置进行早期调整。一些团队等到部署后才进行优化，依赖于真实的用户交互。这种方法也可能有效，具体取决于系统的风险状况以及你前期能收集多少参考数据。
你不需要在参考数据集上过度优化 evals。目标是对关键用例进行广泛覆盖，而不是追求完美。生产环境中的行为会有所不同，但一个强大的 eval 设置能为你提供一个可靠的起点。
一旦你实现了系统，并验证了其范围界定和工具配置都已妥当，就该部署了。部署是持续开发和持续校准循环之间的过渡阶段。
过渡：部署
部署是令人兴奋的部分。但你不能只是凭感觉部署（找不到更好的词了），然后祈祷一切顺利。你已经建立了一个能让你学习和改进的流程。你记录了交互，你内置了让人类收回控制权的方式，并且你设置了评估指标来标记异常情况。现在是你观察系统在真实世界中表现的机会了。
你向一小部分用户部署了系统，系统开始运行。
从这里开始，你进入了持续校准阶段。这是真实世界的行为开始显现的地方，也是你开始了解什么在起作用、什么出了问题以及接下来需要修复什么的地方。
CC 4. 运行评估
你在 CD 循环中设计了评估指标。现在你已经部署并拥有了用户行为日志，是时候评估系统实际表现如何了。一旦你收集到足够数量的实时交互数据，就可以开始运行你的评估。你可以根据成本和计算资源的限制，在数据的子集或整个数据集上运行它们。
如果需要在子集上进行评估，请利用系统的独有属性来决定抽样哪些数据点。例如，在客户支持系统的 v1 中，你可以使用显示人类代理是否将查询重新路由到不同部门的日志，作为路由准确性的代理指标。在更复杂的系统中，你可以关注对话轮数、用户是否给出「赞」或「踩」的反馈，或其他会话内信号。
控制权交接日志也可以提供有价值的评估信号，特别是当它们捕获了人类会如何介入或调整结果时。
客户支持系统 v1 的评估示例
这里的路由准确率将是 ⅗ (60%)。
根据你的用例，选择最具代表性的实时用户交互样本来运行你的评估指标。如果你的交互数据量足够小（2,000 到 3,000 条日志），那么就在整个数据集上运行它们。
CC 5. 分析行为并发现错误模式
当你查看你的 evals 结果时，它们可能看起来不错，也可能不怎么样。如果你已经很好地完成了持续开发阶段的第 1 到 3 步，你的指标可能处于中间水平，这意味着有优化的空间。
现在是时候开始手动审查你的数据了。这是构建 AI 系统中最被低估但又最必要的部分之一。一个简单的策略是从你的评估指标最薄弱的地方开始。那里通常包含最有价值的信号。
例如，在客户支持系统路由 v1 中，你可以：
每个部门提取 20 到 50 个低准确率的工单。 更关注得分落后的部门（也许退款部门表现不佳，而账单部门看起来不错）。 查看用户说了什么，系统做了什么，以及结果是什么。根据你的应用程序，这可能是一次单一的交互，也可能是一次多轮会话。你的评估指标应该能帮助你识别出问题所在，并引导你找到故障点。
一旦你手动审查了足够多的例子，你就会开始注意到重复的错误模式。这时你就可以开始记录它们了。在这个阶段，一个简单的表格格式就很好用：
这些模式向你展示了系统逻辑、提示或输入中需要改变的地方。它们还帮助你更有目的地界定下一个版本的范围。
CC 6. 应用修复
一旦你有了可操作的错误模式，你就可以开始规划修复它们的方法。这可以是从简单的提示调整，到更换更好的模型，提高检索质量，或添加新组件来分解任务的任何事情。你改变什么完全取决于哪里出了问题。
还记得在持续开发阶段的第 2 步我们说不要过度设计吗？那是因为这一步才是你应该投入更多工程资源的时候。有意识地演进架构——以数据为依据，而不是凭空猜测。
这一步本身通常是迭代的。你应用一个修复，再次运行你的评估指标，然后要么继续优化当前版本，要么循环执行第 2 到 5 步，直到系统表现足够好。而且因为你已经有了数据，所以你不需要每次都重新部署。
此外，评估设计本身存在不足的情况也并不少见。这是因为 evals 通常是使用参考数据集设计的，而参考数据集是基于你期望用户会做什么。然而，真实的用户行为可能大相径庭。这种非确定性也可能扰乱你的 evals。当你再次经历第 4 步和第 5 步时，你可能会发现 evals 遗漏了问题或给有缺陷的输出打了高分的一致性问题。因此，第 6 步也可能涉及重新审视和重建你的 evals——这完全正常。在持续塑造产品的过程中，你很可能会进行多轮评估。唉……这都是过程的一部分。
当你第一次完成第 6 步时，你可能已经掌握了要领。你会多次经历这个循环，逐步减少控制，让系统变得更加自主，并让产品特性引导你的设计选择。请记住，部署只是大局的一部分。大部分工作在于做好设计。
这让我们想发点牢骚：太多人几乎把所有精力都集中在实现上，追逐最新的工具和框架，结果却犯下了代价高昂的错误。我们从一个宏大的目标开始，将其分解，并且只有在复杂解决方案能真正解决实际问题时才使用它们。
永远不要让技术主导。让问题、评估和数据来指导下一步该添加什么。这就是你在 AI 产品中控制非确定性的方式。
总结：一个用于客户支持的 CC/CD 循环
这里有一个可能的表格，它将问题分解为多个版本，每个版本随着时间的推移增加更多的代理能力。它还概述了你在每个阶段可以构建的飞轮，使用了我们一直在讨论的客户支持示例。每一次迭代都为下一次迭代奠定了基础。这只是一种方法。
以此为灵感，思考你如何分解自己的产品，以实现有目的的构建和扩展。
如果你直接发布一个完全自主的支持系统 (v3)，很多事情可能会迅速出错。举一个简单的例子：一个退款请求被错误地标记为账单问题，系统提取了错误的 SOP 并生成了一个看似合理但错误的解决方案，最终用户感到困惑并对产品失去信任。
虽然你可能有 evals 来标记问题，但你现在却陷入了理清一连串故障的困境。最终的错误表现为生成错误，但它始于路由，因缺少上下文而加剧，并导致了糟糕的结果。这只是一个简单的案例，但你已经可以看到事情会变得多么复杂。
CC/CD 方法可以帮助你避免这种恶性循环。在客户支持的 v1 中，系统只处理工单路由，为你提供关于用户如何描述问题、哪些部门经常被混淆以及哪些元数据真正重要的信号。然后你利用这些信息来改进路由逻辑和优化提示，再进入下一步。在 v2 中，系统根据 SOPs 起草回复，但仍由人工审核。这有助于你了解检索在何处失败，以及哪些文档需要更新。到了 v3，系统准备好承担更多的代理能力，自主解决范围内的工单。但现在你已经知道哪些查询可以安全地自动化，以及在何处需要人工后备。
何去何从
AI 系统拥有以一定程度的代理能力运行的巨大潜力，但实现这一目标很少是通过堆砌复杂工具或用蛮力扩展来实现的。这也不是关于编写完美的提示。创建一个能通过有效自动化来节省时间、金钱和精力的 AI 系统，关键在于通过理解其细微差别，一步一步地解决实际问题。
我们经常将与 AI 合作比作 onboarding 一位新同事。这位同事可能非常聪明，但他们还不知道你的团队是如何运作的。你不会在第一天就把风险最高的项目交给他们。你会从小处着手，观察，建立信任，然后当他们展示出自己能处理什么时，你再逐步扩大他们的工作范围。AI 系统需要同样的路径。这正是 CC/CD 框架旨在支持的。
CC/CD 的核心是判断力：那种能帮助你决定发布什么、在出错时如何保护用户、何时交还控制权，以及如何定义什么是「足够好」的判断力。
对于每个版本应该赋予多少能力、在进入下一阶段前应该收集多长时间的数据，或者范围应该界定得多紧，没有一刀切的答案。这取决于你的产品、你的用户和你的时间表。有些产品需要数周的迭代，而其他产品可以更快。这就是你的判断力发挥作用的地方。
大多数这种有价值的产品思维已经存在于成功的产品负责人心中。CC/CD 只是为其提供了结构。该框架提供了一个循环、一个节奏和一种共享的语言，以便将那些已经非常出色的产品直觉应用到 AI 系统中。
原文地址：https://substack.com/inbox/post/170720848
一键三连「点赞」「转发」「小心心」
欢迎在评论区留下你的想法！
