👋 欢迎来到 ✨免费版✨ 周刊。每周我都会解答读者关于产品构建、增长驱动和职业加速的问题。更多内容：Lenny's Podcast | How I AI | Lennybot | Lenny's Reads | 课程**
P.S. 年度订阅用户可免费获得一年期的 15+ 款优质产品：Lovable、Replit、Bolt、n8n、Wispr Flow、Descript、Linear、Gamma、Superhuman、Warp、Granola、Perplexity、Raycast、Magic Patterns、Mobbin 和 ChatPRD（送完即止）。立即订阅。**
在这个 AI 时代，技术领导者需要重新审视构建优秀产品的每一项行业最佳实践。AI 产品的构建方式完全不同。那些意识到这一点并最快做出调整的团队将获得巨大优势。
基于他们在 OpenAI、Google、Amazon、Databricks 和 Kumo 等公司主导 50 多个 AI 项目实施的经验，Aishwarya Reganti 和 Kiriti Badam 开发了持续校准/持续开发（Continuous Calibration/Continuous Development，CC/CD）框架，专门应对交付优秀 AI 产品的独特挑战。在这篇文章中，他们将首次与大家分享这一框架。
想了解更多来自 Aish 和 Kiriti 的内容，请查看他们广受欢迎的 Maven 课程和他们即将举办的免费闪电讲座，深度探讨这一主题。
你也可以通过播客形式收听本文：Spotify / Apple / YouTube
如果你是一名正在交付 AI 功能或产品的产品经理或构建者，你很可能有过这样的感受：
你的公司面临着推出 AI 产品的压力。一个有前景的想法逐渐成形。团队完成了出色的演示，早期反馈看起来不错，利益相关者也充满期待。你全力推进，将其交付到生产环境。
然后问题开始出现。你深陷其中，试图找出哪里出了问题。但问题错综复杂、难以追溯，没有任何线索指向单一的修复方案。突然间，你的整个产品方法都显得摇摇欲坠。
我们一次又一次地目睹这种情形。在过去几年里，我们帮助了 50 多家公司设计、交付和规模化面向数千客户的 AI 自主系统。在所有这些经历中，我们看到了一个共同的陷阱：人们忽视了 AI 系统从根本上打破了传统软件产品的假设这一事实。
你不能像构建其他产品那样构建 AI 产品，原因有两个：
- AI 产品本质上是非确定性（non-deterministic）的
- 每个 AI 产品都必须在自主性（agency）和控制（control）之间做出权衡
当公司没有意识到这些差异时，他们的 AI 产品就会面临连锁反应，比如意外故障和糟糕的决策。我们看到太多团队经历了从令人印象深刻的演示到无法规模化或持续运行的系统之间的痛苦转变。在此过程中，用户对产品的信任也在悄然流失。
在看到这种模式反复上演之后，我们基于成功部署中的经验，为 AI 产品开发生命周期开发了一个新框架。它旨在认识到 AI 系统的独特性，帮助你构建更有意识、更稳定、更值得信赖的产品。读完这篇文章后，你应该能够将自己的产品映射到这个框架上，并更好地理解如何启动、聚焦何处以及如何安全地规模化。
让我们来看看构建 AI 产品与传统软件有哪些不同之处。
1. AI 产品本质上是非确定性的
传统软件的行为或多或少是可预测的。用户以已知的方式交互：点击按钮、提交表单、触发 API 调用。你编写逻辑将这些输入映射到结果。如果出现问题，通常是代码问题，你可以追溯定位。
AI 系统的行为则不同。它们在两端都引入了非确定性：换句话说，用户如何参与以及系统如何响应都存在不可预测性。
首先，用户交互界面远不如传统软件那样确定。用户不是通过按钮点击等结构化触发器进行交互，而是通过开放式提示词、语音命令或其他自然输入进行交互。这些都更难验证、更容易被误解，用户表达意图的方式也千差万别。
其次，系统的行为本质上就是非确定性的。AI 模型经过训练，基于模式生成合理的响应，而不是遵循固定规则。同一个请求可能因为措辞、上下文甚至是不同的模型而产生不同的结果。
这从根本上改变了你构建和交付产品的方式。你不再为可预测的用户流程进行设计。你是在为可能的行为——无论是来自用户还是产品——而设计，而不是为确定的行为而设计。你的开发流程需要从一开始就考虑到这种不确定性，在你期望的结果与真实世界中出现的结果之间持续校准。
2. 每个 AI 产品都在自主性与控制之间做出权衡
还有另一个层面让 AI 系统变得不同，而这在传统软件产品中我们几乎不需要考虑：自主性（agency）。
在这个语境中，自主性是指 AI 系统代表用户采取行动、做出决策或执行任务的能力（这也是"AI Agent（AI 代理）"这个术语的由来）。想想：
- 预订航班
- 执行代码
- 从头到尾处理一张支持工单
与传统工具不同，AI 系统被构建为能够以不同程度的自主性运作。但这里有一个人们经常忽视的部分：
每次你给 AI 系统更多自主性，你就放弃了一些控制。
因此，始终存在一个自主性-控制权衡（agency-control tradeoff）。而这个权衡非常重要！如果你的系统只是建议一个回复，你仍然可以覆盖它。如果它自动发送回复，你最好确保它是正确的。
大多数团队犯的错误是，在测试过系统出错时会发生什么之前，就直接跳到完全自主性。如果你还没有在高度控制下测试系统的行为，你就不应该给它高度自主性。而如果你在系统尚未赢得信任之前就赋予了过多自主性，你可能会失去对系统的可见性，也会失去用户的信任。
更糟的是，你将陷入调试一个庞大复杂系统的困境，这个系统已经采取了无法追溯的行动，原因也失去了洞察，你甚至不知道该改变什么。
这就引出了我们为帮助团队应对这些区别而开发的核心框架。
我们称之为 CC/CD：持续校准/持续开发（Continuous Calibration/Continuous Development）。
这个名字参考了持续集成/持续部署（Continuous Integration/Continuous Deployment，CI/CD），但与它的同名概念不同，CC/CD 是为行为非确定性且自主性需要逐步赢得的系统而设计的。
持续校准/持续开发框架
就像传统软件一样，AI 产品也会经历多个阶段，朝着最终目标前进。但构建 AI 需要你考虑到我们前面提到的两件事：非确定性和自主性-控制权衡。
CC/CD 框架的设计围绕这两个现实展开，通过：
- 通过设计或密切监控来降低系统的非确定性
- 确保自主性是随着时间推移逐步赢得的，而不是一次性授予的，因为每项新能力都会让控制进一步远离人类
在我们的框架中，产品构建者在一个开发（Continuous Development，CD）和校准（Continuous Calibration，CC）的持续循环中工作。在开发阶段，你界定问题范围、设计架构，并设置评估（evaluation）以控制非确定性。你从低自主性、高控制的功能开始，然后随着系统证明自己能够处理更多，逐步向上推进。
然后你进行部署，这不是终点，而是进入下一阶段的过渡。部署之后，你进入校准循环，观察真实行为，找出问题所在，并进行有针对性的改进。
随着每一个循环，系统赢得更多一点的自主性。随着时间的推移，这个循环会变成一个飞轮（flywheel），收紧反馈、建立信任，并使产品在每个版本中变得更强大。
让我们深入探讨 CC/CD 循环的每个步骤，它是什么样子，为什么重要，以及如何做好。前三个步骤构成了循环的持续开发（CD）侧：界定能力范围、搭建应用和设计评估。
CD 1. 界定能力范围并整理数据
假设你有一个宏大的产品想法，并且已经完成了调研。很明显，AI 是正确的路径。在传统软件开发中，你通常会根据功能深度或用户需求来规划新产品的 v1、v2、v3。对于 AI 系统，版本规划依然适用，但视角发生了变化。
在这里，每个版本由系统拥有多少自主性以及你愿意放弃多少控制来定义。因此，你不是从功能集的角度思考，而是界定能力（capability）。从识别一组高控制、低自主性的功能开始（上图中的版本 1）。这些功能应该小巧、可测试且易于观察。然后，思考这些能力如何通过逐步增加自主性来随时间演进，一次一个版本。目标是将高远的最终状态分解为可以评估、迭代并向上构建的早期行为。
例如，如果你的最终目标是在公司实现客户支持自动化，一个高控制的方式是从 v1（版本 1）开始，仅将工单路由到正确的部门，然后发展到 v2，让系统建议可能的解决方案，只有在 v3 才允许它在有人工兜底的情况下自动解决工单。
请记住，这只是一种方法。在实践中，具体形式取决于你的产品，但过程往往是一致的：从简单、易于验证且易于人工覆盖的决策开始。然后，随着你在 CC/CD 循环中推进，每个版本逐步增加更多自主性。
你在每个版本停留多久完全取决于你看到了多少行为信号。你在优化的是理解你的 AI 在真实世界的噪声和变化下如何表现。
以下是更多示例：
营销助手
- v1： 根据提示词撰写邮件、广告或社交媒体文案
- v2： 构建多步骤营销活动并执行
- v3： 跨渠道启动、A/B 测试并自动优化营销活动
编程助手
- v1： 建议行内补全和样板代码片段
- v2： 生成更大的代码块（如测试或重构）供人工审查
- v3： 自主应用限定范围的更改并创建 Pull Request（PR）
如果你关注过像 GitHub Copilot 或 Cursor 这样的工具的演进过程，这正是它们使用的策略。大多数用户只看到当前版本，但底层的系统是逐步攀登这个阶梯的。先是补全，然后是代码块，再然后是 PR，每一步都是通过使用、反馈和迭代赢得的。
现在，由于用户行为是非确定性的，你需要建立一个参考，说明预期行为是什么样子，以及你的 AI 系统应该如何响应。这就是数据发挥作用的地方。数据有助于打破冷启动（cold start），并为你提供具体的评估依据。我们称之为参考数据集（reference dataset）。
在客户支持自动化示例中，对于路由版本（v1），你的参考数据集可能包括：
- 用户查询
- 应该路由到的部门
- 用于做出决策的元数据，如产品类型、用户层级或渠道
你可以从历史日志中提取这些数据（如果有的话），或者基于产品预期的工作方式生成示例。这个数据集帮助你评估系统性能，同时也告诉你你的助手需要什么上下文才能可靠运行。由于大多数产品都是冷启动的，目标是至少收集 20 到 100 个示例。
我们将继续使用客户支持示例来讲解 CC/CD 循环的后续步骤。想象你正在为公司构建一个完全自主的支持系统。以下是我们将参考的各个版本，以及它们对应的自主性和控制级别。我们将在文章后续部分引用 v1、v2 和 v3。
CD 2. 搭建应用
大多数人会跳过第 1 步，过早进入搭建阶段，迷失在实现选择的细节中，过度思考需要哪些组件。但如果你在第 1 步中已经恰当地界定了能力范围，查看了足够的示例，并整理了一个扎实的参考数据集，那么搭建应用应该相当直接。你已经知道系统需要做什么，对用户可能会抛出什么有了感觉，也理解一个好的响应是什么样的。现在只需要把能提供有用信号的最简版本连接起来。
软件领域有一句名言是有道理的："过早优化是万恶之源。" 这在这里同样适用。不要过度工程化。不要过度优化。至少在这个阶段不要。就是不要。只构建当前版本所需的东西。通过设置日志来捕获系统从用户那里看到了什么、返回了什么以及人们如何与之交互，使系统可度量、可迭代。这将构成你实时交互数据集（live interaction dataset）的基础，并帮助你随时间改进系统。我们不会在此深入探讨实现细节，但如果你将其暴露给最终用户，请确保基本的护栏（guardrail）和合规性已经到位。
还有一个重要的点：在搭建应用时，确保在需要时控制可以无缝交还给人类。我们将其称为控制交接（control handoff）。例如，在客户支持 v1 中，如果工单被错误路由，接收方代理（该部门的联系人）应该能够轻松重新路由。由于这次纠正被记录下来，它不仅有助于随时间改进系统，还能保护用户体验。从一开始就考虑控制交接是建立信任和保持可恢复性的关键。
CD 3. 设计评估（eval）
这是通常需要花些心思的部分。在交付任何东西之前，你需要定义如何衡量系统是否按照预期运行，以及是否准备好进入下一步。你通过评估指标（evaluation metrics）（简称 eval）来做到这一点。
那么，什么是 eval？
Eval 是一种评分机制，帮助你评估你的 AI 系统是否正常工作、在哪里表现不足以及需要改进什么。可以将它们视为传统软件中测试的等价物。但不同于典型的单元测试或集成测试——其中的输入和输出是固定的、正确与否是二元的——AI 的 eval 处理的是模糊性。
它们完全针对具体应用，并与你在第 1 步中界定的任务紧密相关。你不仅仅是在检查系统是否能运行——你在检查它做某件本质上非确定性的事情做得有多好，比如总结文档或回答问题。这就是为什么 eval 不是一刀切的。它们作为指导你迭代循环的信号，帮助你随时间调整和优化行为。
例如，在客户支持系统的路由 v1 中，一个简单但强大的 eval 是路由准确率（routing accuracy）——系统路由到正确部门的频率。仅此一项就能告诉你模型是否在学习正确的区分，以及你的设置是否扎实。
在客户支持系统的 v2 中，你需要检索内部标准操作流程（Standard Operating Procedure，SOP）或历史解决方案来协助代理，你的 eval 就会转向检索质量（retrieval quality）。建议是否与工单真正相关？它们是否是人工代理会去查看的内容？
这个阶段的最佳实践之一是针对第 1 步的参考数据集运行 eval。这有助于你评估性能、验证 eval 设计是否良好，并对第 2 步的产品设置进行早期调整。有些团队会等到部署后才进行优化，依赖真实的用户交互。这种方法也可以，取决于系统的风险状况以及你能提前收集多少参考数据。
你不需要在参考数据集上过度优化 eval。目标是关键用例的广泛覆盖，而不是完美。生产行为会有所不同，但一个扎实的 eval 设置会给你一个可靠的起点。
要深入了解 eval 的设计和优化，一个很好的起点是 Aman 的文章。
—
一旦你实现了系统并验证了它已被恰当地界定范围和配备好检测手段，就该部署了。部署是持续开发和持续校准循环之间的过渡阶段。
过渡：部署
部署是最有趣的部分。但你并不是在凭感觉部署（vibe deploying，暂且这么叫 🙂）然后期待最好的结果。你已经建立了让你能够学习和改进的流水线。你在记录交互日志，你内置了人类收回控制的方式，你设置了评估指标来标记异常情况。现在是时候看看系统在真实世界中的表现了。
Boom。你部署到一个小范围用户群，系统开始运行。
从这里开始，你进入持续校准阶段。这是真实世界行为开始显现的地方，也是你开始了解什么在生效、什么在出问题以及下一步需要修复什么的地方。
CC 4. 运行 eval
你在 CD 循环中设计了 eval 指标。现在你已经部署并获得了用户行为日志，是时候评估系统实际表现得如何了。一旦收集了足够有意义的实时交互数据，你就可以开始运行评估了。你可以在数据子集上运行，也可以在全量数据集上运行，具体取决于成本和计算限制。
如果你需要在子集上评估，使用系统的独特属性来决定采样哪些数据点。例如，在客户支持系统 v1 中，你可以使用显示人工代理是否将查询重新路由到不同部门的日志作为路由准确率的代理指标。在更复杂的系统中，你可以查看对话轮次数量、用户是否给出点赞或点踩反馈，或其他会话内信号。
控制交接日志也可以提供有价值的 eval 信号，特别是当它们捕获了人类如何介入或调整结果时。
客户支持系统 v1 的评估示例
根据你的用例，选择最具代表性的实时用户交互样本来运行你的 eval 指标。如果你的交互数据足够小（2,000 到 3,000 条日志），那就直接在全量数据集上运行。
CC 5. 分析行为并发现错误模式
当你查看 eval 结果时，也许它们看起来很扎实，也许不怎么样。如果你在持续开发阶段的第 1 到第 3 步做得很好，你的指标可能处于中间水平，这意味着有优化空间。
现在是时候开始手动审查数据了。这是构建 AI 系统最被低估但又必不可少的环节之一。一个简单的策略是从 eval 指标最弱的地方开始。那里通常是信号最有价值的地方。
例如，在客户支持系统路由 v1 中，你可以：
- 每个部门抽取 20 到 50 个低准确率工单
- 重点关注得分落后的部门（也许退款部门表现不佳，而账单部门看起来没问题）
查看用户说了什么、系统做了什么以及结果是什么。根据你的应用，这可能是单次交互或多轮会话。你的 eval 指标应该帮助你识别问题出在哪里，并引导你找到故障点。
一旦你手动审查了足够多的示例，你就会开始注意到重复出现的错误模式。这时就要开始记录它们了。一个简单的表格格式在这个阶段很有效：
这些模式告诉你系统的逻辑、提示词或输入中需要改变什么。它们也帮助你更有意识地规划下一个版本。
CC 6. 应用修复
一旦你有了可操作的错误模式，你就可以开始列出修复它们的方法。这可能是一次简单的提示词调整，也可能是切换到更好的模型、改进检索质量，或添加新组件来分解任务。你改变什么完全取决于什么出了问题。
还记得在持续开发阶段的第 2 步我们说过不要过度工程化吗？那是因为这一步才是你应该进行更多工程化的时候。演进架构，但要有意识地去做——基于数据，而不是猜测。
这一步本身往往是迭代性的。你应用一个修复，再次运行 eval 指标，然后要么继续优化当前版本，要么循环执行第 2 到第 5 步，直到系统表现得足够好。而且由于你已经有数据，不需要每次都重新部署。
另外，eval 设计本身不完善也并非罕见。这是因为 eval 通常是基于参考数据集设计的，而参考数据集是基于你预期用户会做什么。然而，真实的用户行为可能非常不同。这种非确定性也可能让你的 eval 失准。当你再次执行第 4 和第 5 步时，你可能会发现 eval 持续漏掉问题或给有缺陷的输出打高分的场景。因此，第 6 步也可能涉及重新审视和重建你的 eval——这完全正常。你很可能会运行多轮评估，随着你持续塑造产品……唉，这都是过程的一部分。
—
当你第一次走到第 6 步的终点时，你可能已经逐渐掌握了要领。你将多次经历这个循环，逐步减少控制，让系统变得更加自主，并让产品功能引导你的设计选择。记住，部署只是更大图景的一部分。大部分工作在于把事情设计好。
这引出了一个小小的吐槽：太多人几乎完全专注于实现，追逐最新的工具和框架，但最终却犯下了代价高昂的错误。我们从一个宏大的目标开始，将其分解，只在真正解决实际问题时才使用更复杂的方案。
永远不要以技术为先。让问题、eval 和数据引导下一步该添加什么。这就是在 AI 产品中控制非确定性的方法。
汇总：客户支持的 CC/CD 循环
下面是一个可能的表格，将问题分解为多个版本，每个版本随时间增加更多自主性。它还勾勒了你在每个阶段可以构建的飞轮，使用我们一直在讨论的客户支持示例。每次迭代都为下一次奠定基础。这只是其中一种方法。
以此作为灵感，思考你如何分解自己的产品，以便有意识地构建和规模化。
如果你一开始就交付一个完全自主的支持系统（v3），很多事情可能会迅速出错。举一个简单的例子：退款请求被错误标记为账单问题，系统检索到错误的 SOP 并生成了一个看似合理但实际上不正确的解决方案，最终用户感到困惑并对产品失去信任。
虽然你可能有 eval 来标记出了问题，但你现在陷入了梳理一连串故障的困境。最终的错误表现为生成错误，但它始于路由环节，因缺失上下文而加剧，最终导致了糟糕的结果。这只是一个简单的案例，但你已经可以看到事情会多么迅速地变得复杂。
CC/CD 方法帮助你避免这种恶性循环。在客户支持 v1 中，系统只处理工单路由，为你提供关于用户如何表述问题、哪些部门经常被混淆以及什么元数据真正重要的信号。然后你利用这些来改进路由逻辑并优化提示词，再向前推进。在 v2 中，系统基于 SOP 起草回复，但仍需人工审核。这帮助你理解检索在何处失效以及哪些文档需要更新。到 v3 时，系统已经准备好获得更多自主性，可以自行解决限定范围内的工单。但现在你已经知道哪些查询可以安全自动化，以及哪里需要兜底。
下一步该怎么做
AI 系统拥有以某种程度的自主性运作的惊人潜力，但实现这一目标很少靠堆积复杂工具或粗暴地规模化。也并非靠写出完美的提示词。打造一个通过有效自动化来节省时间、资金和精力的 AI 系统，关键在于通过理解其细微差别，一步步解决真正的问题。
我们经常将使用 AI 比作让一位新同事入职。这位同事可能很出色，但还不了解你的团队是如何运作的。你不会在第一天就把最高风险的项目交给他。你从小处着手，观察，建立信任，随着他展示出自己能处理什么，逐步扩展他的范围。AI 系统需要同样的路径。这就是 CC/CD 框架旨在支持的。
CC/CD 的核心是判断力：那种帮助你决定交付什么、如何在出问题时保护用户、何时交还控制权以及如何定义"足够好"的判断力。
对于每个版本赋予多少能力、收集数据多久再向前推进，或者如何界定范围，并没有一刀切的答案。这取决于你的产品、你的用户和你的时间线。有些产品需要数周的迭代，有些可以更快推进。这时你的判断力就派上了用场。
大多数有价值的产品思维已经存在于成功的产品领导者身上。CC/CD 只是赋予了它结构。这个框架提供了一个循环、一种节奏和一种共享语言，将已经很出色的产品直觉应用到 AI 系统上。
感谢 Aish 和 Kiriti！你可以在 LinkedIn 上关注他们，并查看他们广受欢迎的 Maven 课程和他们即将举办的免费闪电讲座，深度探讨这一主题。
祝你度过充实而高效的一周 🙏
如果你觉得这期 Newsletter 有价值，请分享给朋友，如果还没订阅，可以考虑订阅。有团体折扣、礼品选项和推荐奖励。
真诚地，
Lenny 👋