构建AI产品的全新范式:非确定性、代理控制权与持续校准
摘要
本期嘉宾是Aishwarya Naresh Reganti(Ash)与Kiriti Badam——一对既是夫妻又是合作伙伴的AI产品实战专家。Kiriti在OpenAI负责Kodex,此前在Google和Kumo深耕AI/ML基础设施十年;Ash曾是Alexa和Microsoft的早期AI研究员,发表过35篇以上研究论文。两人共同领导和支持了超过50个AI产品部署项目,横跨Amazon、Databricks、OpenAI、Google等公司,并在Maven上教授排名第一的AI课程。他们带来一个核心洞察:构建AI产品与构建传统软件存在根本性差异——非确定性(non-determinism)和代理控制权权衡(agency-control trade-off)彻底改变了产品开发范式。对话涵盖了从"问题优先"思维、逐步释放自主权的渐进策略、领导者角色转变、CCC-D(持续校准持续开发)框架,到评估(evals)与生产监控的平衡之道。"痛苦是新护城河"(Pain is the new moat)——他们强调,真正成功的AI产品不是靠一次性的"一键部署"实现的,而是通过持续迭代、理解用户行为、建立反馈飞轮(flywheel)打磨出来的。
正文
一、AI产品与传统软件的两大根本差异
Ash一针见血地指出,虽然AI系统与传统软件有许多相似之处,但有两点从根本上改变了构建方式。第一个差异是非确定性(non-determinism)。在传统软件中——比如Booking.com——用户意图通过点击按钮、填写表单等确定性路径被转化为行动。而AI产品用自然语言界面替代了这一层,用户可以用无数种方式表达意图。同时,系统底层是一个非确定性的概率API——大语言模型(LLM,Large Language Model)。LLM对提示词措辞极其敏感且本质上是黑箱。这意味着:你既不知道用户会如何与你的产品互动,也不知道LLM会如何响应。 你同时在输入、输出和处理过程三个维度上试图预测行为并为之构建。
第二个差异是代理控制权权衡(agency-control trade-off)。Ash观察到,业界对构建能自主完成工作的智能体(agent)极度痴迷,但很少有人讨论一个根本问题:每一次将决策能力或自主权交给智能体系统,你都在某种程度上放弃了对系统的控制。当你交出控制权时,必须确保智能体已经获得了你的信任,或者说它已经足够可靠,可以被允许做出决策。因此,如果你给AI系统更多代理权(agency,即做出决策的能力),你也在失去一定的控制权,你需要确保智能体已经通过时间的沉淀赢得了这一能力。
Kiriti用一个比喻来阐释这一理念:如果你的目标是攀登优胜美地的半圆顶(Half Dome),你不会每天去爬它,而是从局部训练开始,逐步提升,最终达成目标。构建AI产品同理——不要第一天就部署一个拥有全部工具和上下文的智能体并期望其正常工作。从影响最小、人工控制最多的地方着手,理解当前的能力边界,然后逐步向更高的代理权、更低的控制权迈进。
二、从低自主权起步:代理控制权的渐进梯度
Lenny将这一策略概括为"从高控制、低代理权开始,随着信心积累逐步增加代理权、减少人工控制"。Kiriti以客户支持(customer support)为例展示了这一路径:第一阶段——AI向人工客服提供建议,但不直接面对客户,人工客服从中获得参考并给出反馈,团队据此了解盲点和改进方向;第二阶段——AI直接将答案呈现给客户,但仍限于基于帮助中心文章的问答;第三阶段——增加更复杂的功能,如自动退款、向工程团队提交功能需求等。
Ash补充了保险预授权(insurance pre-authorization)的例子:MRI和血液检测等低风险场景可以由AI自主批准,而侵入性手术等高风险场景必须经过人工审核层。关键是在不破坏客户体验的前提下约束自主权,同时记录人工行为以构建持续改进的飞轮。
Lenny进一步列举了其他领域的渐进迭代:编程助手(coding assistant)——V1仅建议内联补全和样板代码片段,V2生成更大的代码块(如测试或重构)供人工审核,V3自主应用更改并创建PR;营销助手(marketing assistant)——V1草拟邮件或社交媒体文案,V2构建多步骤营销活动并执行,V3自主推出A/B测试、跨渠道自动优化。
Kiriti强调,这种渐进方式还有一个根本性好处:"问题优先"(problem first)思维。当你从较小的自主权范围起步时,你被迫思考真正要解决的问题是什么、如何将其分解为不同自主权等级的迭代。在AI狂飙突进的时代,一个容易滑入的陷阱是不断沉迷于方案的复杂性而忘记最初要解决的问题。
Ash引用了一篇来自UC Berkeley Matei Zaharia团队和Databricks的论文——约74%~75%的受访企业表示可靠性(reliability)是其最大障碍,这也是许多公司不敢部署面向终端用户的AI产品的原因。这也是为什么当前大多数AI产品集中在生产力工具领域(低自主权),而非端到端替代工作流的智能体。
三、AI产品成功的三角模型
Ash将成功构建AI产品的公司特征概括为三个维度——"每一项技术问题首先都是人的问题"。
第一,领导力(Leadership)。许多领导者凭借过去10~15年积累的直觉受到高度尊重,但在AI时代,这些直觉需要被重新学习。领导者必须具备放下身段、承认"我可能是房间里最愚蠢的人"的谦逊。Ash分享了一个案例:她曾合作过的Rackspace CEO每天早晨4:00到6:00有一个固定的时间段叫"跟进AI"(Catching up with AI),不看邮件、不接受会议,专门学习最新的AI资讯,周末还有"氛围编码"(vibe coding)环节。"这并不因为领导者需要亲自实施,而是重建直觉——你必须接受自己的直觉可能不对,并愿意向每个人学习。"Ash指出,成功的AI转型几乎不可能是自下而上的——如果领导者不信任技术或对技术有错位的期望,一群工程师不可能获得推动力。
第二,文化(Culture)。许多企业弥漫着FOMO和被替代的恐惧,导致主题专家(SME,Subject Matter Expert)不愿合作——他们认为自己的工作将被取代。而实际上,主题专家是构建有效AI产品的关键,因为需要他们的判断来评估AI行为是否正确。"你需要建立一种赋能文化(empowerment culture),让人工智能增强(augment)你的工作流,让你实现10倍效率,而不是用'不采用AI就会被替代'来恐吓员工。"
第三,技术能力(Technical Prowess)。成功的团队极度痴迷于理解自己的工作流,识别哪些环节适合AI增强、哪些需要人工参与。"当你试图自动化工作流的某个部分时,从来不是一个AI智能体解决所有问题——你可能需要机器学习模型处理一部分,确定性代码处理另一部分。你必须痴迷于理解工作流本身,以便为问题选择合适的工具,而不是痴迷于技术本身。"另一个关键模式是理解非确定性API的工作特点——快速迭代,在不破坏客户体验的前提下获取足够数据来评估行为,建立反馈飞轮。
Ash特别警告:如果有人向你推销"一键部署智能体"(one-click agent),那纯粹是营销,不要买账。 "即使拥有最好的数据层和基础设施层,要替代任何关键工作流或产生显著ROI,通常需要四到六个月的工作。"
四、CCC-D:持续校准持续开发框架
面对"竞争对手都在构建全自主智能体"的压力,Ash和Kiriti在经历了多次"一次性构建端到端智能体→无限debug→热修复→最终被迫关闭产品"的痛苦后,提出了CCC-D(持续校准持续开发,Continuous Calibration Continuous Development)框架。其命名致敬了CI/CD(持续集成持续部署),但专为AI产品生命周期设计。
框架分为左右两侧循环:
右侧:持续开发(Continuous Development)——确定能力范围(scope capability),整理预期输入输出数据集。这一阶段的关键价值在于:在动手构建前就能暴露团队内部对产品行为的分歧,让PM和主题专家充分参与。然后搭建应用、设计评估指标(evaluation metrics),部署并运行评估。
左侧:持续校准(Continuous Calibration)——部署后观察未曾预期的行为模式。初始数据集永远不够全面,用户会以你未能预测的方式与系统互动。评估指标也许会给你一些洞察,但有时你发现这些指标也不够——新的错误模式出现了。此时你需要分析行为、识別错误模式,为常见问题应用修复,为新兴模式设计新的评估指标。并非所有错误都需要建立评估指标——比如一次性的工具调用错误只需修复即可。
CCC-D的一个核心原则是在整个迭代中以低代理权起步:在早期版本中约束AI系统的决策数量,确保始终有人参与(human in the loop),然后再随时间逐步放开。
客户支持智能体的三阶段示例:
V1:路由(Routing)。仅将工单分类并路由到正确部门。Ash强调,即便是路由也不是看起来那么简单——大型零售企业的分类体系往往极度混乱:同一层级同时存在"鞋"、"女鞋"、"男鞋",还有一些2019年后再未更新过的死节点(dead node)。人类客服知道检查最后更新时间来判断是否应忽略某个节点,而智能体需要获取所有这些未成文的上下文。V1的代理权极低——即使路由错误,人类可以撤销。此阶段产出的核心资产是高质量路由数据和提示词工程的结构。
V2:辅助建议(Copilot)。在路由稳定后,智能体基于标准操作流程向人工客服生成草稿建议。人工客服可以修改,而被记录下的修改行为(哪些被采用、哪些被删除)构成了免费的"错误分析"(error analysis)数据,直接反馈回飞轮。
V3:端到端解决方案(End-to-end Resolution)。当人类对草稿的修改越来越少时,进入全自动模式——智能体直接起草解决方案并关闭工单。
Ash提醒两个关键点:一是即使走完了V3,新的数据分布也可能突然出现导致重新校准——例如GPT-4o的API即将下线,切换到GPT-5会带来截然不同的特性,需要从头来过;二是用户行为会随时间演变——他们使用ChatGPT的方式与两年前完全不同,因为能力边界感知已经改变。她分享了一个核保(underwriting)案例:系统在头三四个月表现优异,核保员报告了大量时间节省,但随后他们开始提系统从未设计应对的深层问题——"类似这样的案例,前任核保员是怎么处理的?"对用户而言这只是自然延伸,但对产品构建者来说需要完全重构背后的检索和分析逻辑。
如何判断是否可以推进到下一阶段?"最小化意外"(minimizing surprise):当你每校准一两天后不再看到新的数据分布模式、用户行为趋于一致时,说明获取的信息增量已经很低,可以进入下一阶段。
五、评估(Evals)的迷思:不是选边站,而是理解各自的边界
关于评估,Kiriti直指核心:社区中存在一种错误二分法——要么"evals解决一切",要么"在线监控(production monitoring)解决一切",两个极端都不值得信任。 他从定义入手澄清:Evals是将你对产品的理解和信任转化为数据集——明确"什么不该出错";生产监控则是部署后通过关键指标(如用户点赞/点踩、重新生成等隐式信号)了解客户如何使用产品。
Kiriti将二者的关系描述为互补而非互斥:"没人会在不测试的情况下部署应用。测试可以是直觉(vibes),也可以是一组'无论做什么改动都不能出错'的问题——这就是评估数据集。"部署后,高吞吐量场景不可能人工检查所有追踪(traces),需要生产监控来指示哪些追踪值得关注。当发现某类失败模式频繁出现时,再为该模式构建评估数据集。下一次部署新版本后,生产监控依然不可或缺——因为没人事先能预测所有问题。
Ash则指出了一个更深层的问题——"evals"这个词已经遭遇了语义扩散(semantic diffusion):数据标注公司说"我们的专家在写evals",这其实是误差分析(error analysis);有人说"PM应该写evals,evals是新的PRD",这也不意味着PM需要构建足以用于生产的LLM裁判(LLM judge);还有人把查看LMSys Chatbot Arena排行榜称为"做evals",而那是模型评估而非产品评估。"但如果让一群实践者坐在一起问他们——'为AI产品建立可行动的反馈循环重不重要?',我想所有人都会同意。重要的是如何做到——这完全取决于你的应用场景。"
关于Cloud Code引发争议的"all vibes, no evals"立场,Kiriti介绍了Kodex的平衡做法:既要evals,也要倾听客户。编码智能体与其它领域的智能体有一个根本区别——它是为可定制性构建的,客户会以千万种不同的集成和工具组合使用它,几乎不可能为所有交互场景构建评估数据集。"但我们确保——当做一个改动时,至少不会破坏产品的核心体验。我们有evals来覆盖这一点。与此同时,我们极度关注客户行为信号:比如Code Review产品,如果客户觉得不正确会直接关掉产品——这是你必须关注的信号。"每次新模型发布时,团队会聚在一起各负责不同方向的测试,各自有一组"难题列表"扔给模型观察进展。
六、多智能体的迷思与被低估的编码智能体
当被问及AI领域什么被过度炒作、什么被低估时,Kiriti直言:多智能体(multi-agent)的概念被严重误解。许多人的想象是"我有一个复杂问题,将其分解成多个智能体——你做这个、你做那个——然后用某种八卦协议(gossip protocol)连接它们,就到达了智能体乌托邦"。但现实是,让智能体以点对点协议互相通信,尤其是在客户支持等场景中,几乎无法控制哪个智能体会回复客户。与之相比,监督者-子智能体模式(supervisor-subagent pattern)——一个主智能体协调、子智能体执行——才是目前更成熟的范式。
而最被低估的是编码智能体(coding agents)。尽管Twitter和Reddit上讨论热烈,但Kiriti指出,在硅谷以外的普通公司里,编码智能体的渗透率仍然极低,而其能够创造的影响是巨大的。"2025和2026年将是优化这些流程的爆发年。"
Ash认为evals被过度炒作(更准确说是被误解),而真正被低估的是对业务问题的痴迷和对产品设计的深度思考。"今天构建(building)的成本极低,设计(design)才是真正昂贵的——真正思考你的产品要解决什么痛点,这比以往任何时候都更有价值,而且未来只会更加如此。"
七、2026展望:后台智能体、多模态与"痛苦是新护城河"
Kiriti的核心预测:后台智能体/主动智能体(background agents / proactive agents) 将在2026年取得重大突破。当前AI未能创造价值的根源在于缺乏上下文——智能体没有被接入真正发生工作的环节。一旦接入,智能体将开始"看到你的世界"——理解你正在优化的指标、你正在进行的活动,然后主动提示你。ChatGPT Tasks已经展示了这种能力的雏形,扩展到更复杂场景后——比如编码智能体在你开始一天工作前告诉你:"我已经修复了五个Linear工单,这里是补丁,请审核。"——将产生巨大价值。
Ash的核心预测:多模态体验(multimodal experiences) 将成为2026年的主旋律。"语言很可能是人类进化的最后一种形式。我们三人对话时,我不断接收信号——Lenny在点头,我可以往这个方向深入;Lenny看起来无聊了,我该停止说话。这是一层思维链(chain of thought)背后的思维链,而纯语言尚未触达这一维度的丰富性。"更实际的意义是,如果多模态理解能力提升,海量手写文档和混乱的PDF将变得可被AI处理——"这将是巨大的数据金矿。"
在给建设者的终极建议中,Kiriti提出了本期最令人难忘的观点——"痛苦是新护城河"(Pain is the new moat)。当下的成功公司并非只因率先进入市场或某个炫目功能而成功,而是因为他们经历了理解"不可妥协之事"与"可被模型能力解决的特性"之间权衡的阵痛。没有教科书、没有既定路径,只有"试这个,不行,换那个"的反复迭代——这些组织或个人积累的切身体验,最终转化为真正的护城河。Ash呼应道:80%所谓的"AI工程师"和"AI PM"其实不是在构建最炫酷的模型或工作流,而是在泥地里理解客户行为和数据的细节。"看你的数据"(look at your data)这个建议对从未做过AI的软件工程师来说可能是巨大启示,但一直是真理。
书影音推荐
-
Ash推荐书籍:When Breath Becomes Air(《当呼吸化为空气》),Paul Kalanithi著。一位37岁被诊断肺癌的神经外科医生的回忆录。"如果你过于执着于'审视生活',是否忘记了真正的生活本身?在AI时代不断重塑自我的人们,需要停下来,不要'评估'(evaling)人生太多。"
-
Kiriti推荐书籍:三体三部曲。"它涵盖了超越科幻的宏大主题,关于地球外生命和人类决策过程,也关于抽象科学对人类进步的重要性——当科学进步停滞时,日常生活中不可见,但可能造成毁灭性影响。"
-
Ash推荐产品:Whisper Flow——一种概念转录工具,能智能识别代码变量、在"添加三个感叹号"和实际添加"!!!"之间无缝切换。
-
Kiriti推荐产品:Raycast(效率启动器)和Caffeinate(防止Mac在长时间Kodex任务中休眠的工具)。
-
Ash人生格言:"他们说过不可能,但那个傻瓜不知道,于是他还是做成了。"——拥抱"愚蠢",相信自己可以做成任何事,尤其在总有数据告诉你"你不会成功"的时代。
-
Kiriti人生格言:Steve Jobs的"你只能在回头看时才能把点连起来"——面对无数选择时不要纠结最优解,持续向前,持续实验。
觉得有用?分享给一个需要的朋友 🙏