在过去一年里，无论是企业还是独立开发者，都在“做 AI”。
但真正把 AI 产品稳定推向生产环境、并且持续产生价值的，依然是少数。
前 Amazon Alexa、Microsoft 的 AI 研究员 Aishwarya Reganti 和 OpenAI Codex 工程师 Kiriti Badam 长期站在企业 AI 产品“能不能真正跑起来”的第一线。
更重要的是，他们的经验并不来自单一组织内部，而是横跨不同类型的公司与阶段。在过去几年里，两人直接或间接参与并支持了 50 多个企业级 AI 产品 的设计、上线与复盘，合作对象包括 OpenAI、Google、Amazon、Databricks，以及大量正在尝试把 AI 推向生产环境的初创公司和传统企业。
也正因为这种“反复下场”的经历，他们看到了一种高度一致却常被忽视的现象：
AI 产品失败，往往不是因为模型不够强，而是因为它们仍然在用「非 AI 产品的方式」被构建。
右上角是 Aishwarya Reganti，Kiriti Badam 在右下角。
随着企业对 AI 的怀疑期明显消退，越来越多团队开始重构真实工作流、尝试 agent 化系统，问题也随之变得更加尖锐：
为什么同样的模型，有的团队可以稳步推进，有的却在几次事故后被迫回滚？
为什么“全自动 agent”在 demo 里看起来惊艳，却在生产环境中频频失控？
这篇文章并不是一次对采访内容的复述，而是试图围绕一个更基础、也更困难的判断展开：
Building AI products right，意味着你必须接受 AI 产品在本质上不同于传统软件，并据此重构你的产品方法、节奏与控制方式。
如果你正在从 0 到 1 构建 AI 产品，这个判断，几乎决定了你接下来一年是在加速，还是在原地打转。
——接下来，我们将从他们的实际经验出发，一层层拆解：
AI 产品究竟“不同”在哪里，以及为什么大多数失败，早在第一步就已经注定。
01
｜AI 产品与传统软件的根本差异，在于你面对的是一个不可预测的输入–输出系统，而不是一个可控流程。
Q：你们为什么强调“AI 产品”和“非 AI 产品”不是同一种东西的延伸，而是需要换一套建法？
Aishwarya：我想先澄清一点：我们并不是说做 AI 产品就要把过去的软件工程经验全部推翻。相反，很多原则仍然适用。但确实存在一些会根本改变你如何构建产品的差异，而其中最关键的一点是：你在和一个非确定性的 API打交道。传统软件里，你的系统更像一个清晰的决策引擎——路径被你定义、分支被你枚举、结果高度可预期。到了 AI 产品里，这个前提不成立了，你得从“设计流程”转向“校准行为”。
Q：你说的“非确定性”听起来很抽象，它到底具体发生在什么地方？
Aishwarya：它其实同时发生在输入端和输出端。输入端来自用户：过去像 booking.com 这种产品，你基本可以预设用户的意图会被产品引导成一套固定动作——点按钮、选项、填表单，最后实现“订两晚旧金山的酒店”这样的目标。产品把意图拆成可控步骤。
但 AI 产品把这层“步骤引导”替换成更流动的界面，尤其是自然语言。于是用户表达意图的方式会爆炸式变多——同一个需求，有的人一句话说完，有的人绕很久，有的人先给限制条件，有的人最后才补充关键背景。你很难预先穷举。
输出端来自模型：LLM 是概率系统，对 prompt 的措辞很敏感，而且它是黑箱。你不光不知道它这一次会怎么答，你也不容易解释它为什么这么答。于是你会发现，你在同时面对“用户会怎么说”和“模型会怎么回”这两个不稳定变量。
Q：所以它带来的挑战只是“结果会飘”，还是更深的东西？
Kiriti：更深。因为你现在等于是在处理一个你并不完全理解的“输入—处理—输出”链条：
- 输入端，你不确定用户会如何表达意图；
- 处理中间层，你不确定模型如何解释意图、如何利用上下文；
- 输出端，你不确定它最终会呈现出什么样的答案或行动。
- 传统软件里，你可以通过流程设计把“可能性空间”压得很窄；AI 产品里，可能性空间天然更大。你要做的就不是把路径写死，而是学会提前预判行为、容错、约束、以及在必要时把系统拉回到你能掌控的轨道。
Q：听起来像是在说 AI 产品更难做。但你们也提到，它“美”在这里——为什么？
Kiriti：对，它的美也恰恰在这里。人类本来就更擅长用语言沟通，而不是学习一套按钮和流程。自然语言把使用门槛降得很低，你可以像跟人说话一样跟产品说话——这会让更多人愿意尝试，也让交互更自然。
但问题是，很多企业系统、业务流程、底层逻辑依然是确定性的：你最终希望的是一个稳定结果，比如正确分类、正确处理、正确触发动作。于是就出现了一个张力：你用非确定性的技术去实现确定性的业务目标。如果你不承认这个张力，你就会用传统软件的办法去“写流程、补规则”，最后发现怎么补都补不完。
Q：当你把产品从“对话式助手”推进到 agent 时，这个差异会怎么变化？
Kiriti：会更难，因为 agent 不只是“说”，它开始“做”。当系统具备更多自治能力，它不仅生成回答，还会做决策、调用工具、跨步骤推进任务。你能预见的行为边界会变得更模糊：用户输入更开放，模型输出更开放，系统能采取的动作也更开放。
这就是为什么我们说：理解“非确定性”不是概念层面的讨论，而是你在开始构建之前必须先在脑子里建立的前提——否则你会用错误的预期进入开发，然后在上线后被现实反复教育。
02
｜一旦你开始构建 agent，产品问题就不再只是“功能是否正确”，而是“你愿意在多大程度上放弃控制”。
Q：你们提出“agency–control trade-off”，为什么认为这是很多团队忽视、但又极其关键的一个问题？
Aishwarya：让我有点意外的是，这个问题其实很少被认真讨论。现在大家对 agent 非常着迷，讨论的重点往往是“系统能不能更自动”“能不能端到端完成任务”。但每一次你把决策能力交给系统，本质上都是在减少你对系统行为的直接控制。这不是一个技术细节，而是一个产品层面的取舍。
你不可能同时拥有“高度自治”和“完全可控”，你只能在两者之间做选择。
Q：很多人会觉得，只要模型足够强，控制权自然就不是问题了，这种想法哪里出了偏差？
Aishwarya：问题在于，信任不是凭空产生的。即使模型能力在提升，它依然是一个概率系统，你无法保证它在所有边缘情况下都做出你期望的选择。
所以真正的问题不是“它会不会犯错”，而是当它犯错时，后果有多严重。如果你的系统只是给出建议，那犯错的成本相对可控；但如果它已经可以自己采取行动，比如修改数据、发消息、触发流程，那同样的错误就会变成高风险事件。
因此，每一次增加自治能力，都必须建立在“它是否已经赢得足够信任”的基础上，而不是建立在“它看起来已经很聪明了”的直觉上。
Q：那“信任”在 AI 产品中具体意味着什么？怎么判断系统是否“值得放权”？
Kiriti：信任不是一个抽象感受，而是来自你对系统行为的理解程度。你是否知道它在什么情况下会失败？你是否知道它在哪些场景下表现稳定？你是否已经见过足够多真实使用中的行为，而不是只在 demo 或理想测试里看过它？
如果这些问题你都答不上来，那你其实并不具备把控制权交出去的条件。很多团队的问题在于，他们先做了一个高度自治的系统，然后才开始理解它的行为，这会让修正成本变得极高。
Q：这是不是意味着，一开始就做“全自动 agent”在现实中几乎不可行？
Kiriti：在我们看到的大多数真实场景里，是的。不是因为模型不够好，而是因为你在一开始就让系统承担了它还没准备好的责任。
当一个 agent 同时处理多步决策、跨多个系统、面对真实用户输入时，任何一个小的误判都会被放大。而当问题发生时，你很难定位是输入理解错了、推理过程偏了，还是工具调用出了问题。这就是为什么很多团队在上线全自动 agent 后，发现自己只是在不停“救火”和打补丁。
Q：所以你们更倾向的做法是什么？
Kiriti：我们更倾向于把“自治能力”看成一种需要逐步赢得的权限，而不是一开始就给到系统的默认配置。
在早期阶段，人应该牢牢掌握最终决定权，让系统先在低风险环境中展示它的可靠性。随着你对它行为的理解加深、失败模式逐渐清晰，你再慢慢放权。这种节奏听起来慢，但在现实中反而更快，因为你不会在错误的抽象上反复返工。
03
｜很多 AI 产品失败，并不是因为模型不够强，而是团队过早沉迷于“能做什么”，忘了自己一开始想解决什么问题。
Q：你们为什么反复强调“problem-first”，而且觉得它在 AI 时代反而更难做到？
Aishwarya：在传统软件里，problem-first 往往是一种“默认姿势”，因为实现成本高，你不得不先想清楚要解决什么，再去写流程、搭系统。
但到了 AI 时代，情况变了：你每天都能看到新的模型能力、越来越炫的 agent demo、越来越低的开发门槛。于是人很容易被“解决方案的想象力”牵着走——先开始讨论用哪个模型、要不要多代理、怎么接工具、能不能端到端自动化。
问题在于，当你一开始就从“能力”出发，你其实是在用技术去倒推需求。很多团队会在方案层面迅速走得很远，但回头一看，对“我们到底要解决哪个用户痛点”这件事，反而没有形成稳定共识。我们见过太多这样的场景：系统很复杂，讲起来很强，但用户使用时依然不知道它到底替自己解决了什么。
Q：在你们接触的 0 到 1 创业者或团队里，这种偏离通常会表现成什么具体症状？
Aishwarya：最典型的症状就是：一开始就想做一个“完整的 agent”。大家会说，我们要让它能理解所有上下文、接入所有工具、执行完整流程——仿佛第一天上线就应该是 V3。
但当你追求这种端到端自治时，你会把所有难题一次性引入：可靠性、权限、异常处理、评估、数据质量、组织协作……每一个都足以让产品在早期陷入泥潭。更糟的是，一旦你从这个起点开始构建，后面你会发现“修正”非常昂贵，因为你已经在一个高度耦合的系统里调参、热修、救火。
而这些成本，本来是可以通过更小的切口避免的。
Q：你们为什么说“限制自治、从小做起”不是保守，而是能逼迫团队回到问题本身？
Kiriti：因为当你故意从“低自治、低风险”的版本开始，你会被迫回答一个很具体的问题：我现在到底要解决什么？
如果你的第一版只是“辅助”而不是“替代”，你就必须把用户工作流拆开：哪些步骤是明确且可复用的？哪些环节需要人判断？哪些地方一旦出错代价很高？
这种拆解本身会把讨论从“解决方案有多酷”拉回到“问题是否被更好解决”。而且它还能让你在早期就建立一些关键事实：系统在哪些输入分布下表现稳定、在哪些场景会偏航、数据或流程里有哪些隐性规则。你不是在抽象层面讨论产品，而是在真实约束里做产品判断。
Q：很多创业者会说：我不做全自动，竞品会先做，我会不会错过窗口？
Kiriti：这种焦虑非常真实，但它往往来自一个误解——把“看起来更自动化”当成领先。
我们更倾向的判断是：领先不在于你第一天是不是有一个 agent，而在于你是否建立了能持续改进的基础。你当然可以追求更高自治，但前提是你对系统行为已经有足够理解，你知道它在哪些地方会失败，你也知道失败的代价是什么。
否则你做出来的“全自动”，可能只是一个不可维护的复杂体：上线之后每天都在热修，最后不得不回退，甚至直接关掉。这不是错过窗口，这是用更快的速度跑进返工。
Q：从你们的观察来看，坚持 problem-first 的团队，长期差异在哪里？
Kiriti：他们会更克制，也更可持续。每次想增加复杂度之前，他们会问：这是否真的服务于我们最初要解决的那个痛点？如果不是，那它只是“能力展示”。
与此同时，他们也更容易判断什么时候该推进到下一阶段——因为他们不是在追逐一个抽象的“更像 agent 的形态”，而是在追逐一个非常具体的目标：在不破坏用户体验和信任的前提下，让系统在某个环节稳定地产生价值。一旦这个目标达成，再放权才有意义。
04
｜真正能跑起来的 AI 产品，几乎都不是“一步到位”的，而是沿着“高控制 → 高自治”的路径逐步演进。
Q：你们为什么认为，大多数成功的 AI 产品都会经历“从高控制到高自治”的过程，而不是直接奔向全自动？
Kiriti：因为你几乎不可能在一开始就预测清楚系统的行为。AI 系统本质上是行为驱动的，而不是规则驱动的。你只有在真实使用中，才能看到它是如何理解输入、如何做决策、以及在哪些地方会偏离预期。
如果你一开始就给它很高的自治能力，那么这些“你还没理解的行为”会直接影响用户和业务。一旦出问题，修复成本会非常高。相反，从高控制开始，你是在一个低风险环境中观察和校准行为，这会让后续每一次放权都更有依据。
Q：你们能不能用一个具体的例子，说明这种“分阶段演进”在现实中是怎么发生的？
Aishwarya：客户支持是一个非常典型的例子。很多公司一开始会想：既然有 LLM，为什么不直接做一个能自动解决所有工单的 agent？
但在实践中，更合理的第一步通常只是建议。系统先基于已有的帮助文档或 SOP，给人工客服生成回复草稿。人仍然掌握最终决定权，可以修改、拒绝或重写。
这个阶段看起来“很保守”，但它给了你极其宝贵的信息：哪些建议经常被接受，哪些总是被改动，哪些问题模型根本理解不了。你不是在猜系统行不行，而是在真实数据中看到它的能力边界。
Q：那什么时候才是“可以再放一点权”的信号？
Aishwarya：当你发现，系统在某一类场景里已经表现得非常稳定，人工几乎不再需要频繁介入，这就是一个信号。
比如在客服场景中，你可能会发现：针对某一类标准化问题，草稿几乎总是被原样使用。那下一步就可以考虑让系统直接向用户展示答案，而不是先给人工看。这时自治能力增加了，但你并不是盲目放权，而是基于已有行为做出的判断。
关键在于，每一步的自治提升，都应该建立在你已经“看过足够多系统行为”的基础上。
Q：这种路径是不是只适用于客服这类场景？
Kiriti：不是。我们在编程、营销、运营等场景中看到的模式非常相似。
比如编程助手，一开始只是补全几行代码或生成样板；接下来可以生成更大块的代码供人 review；再往后，才是自动提交 PR。
营销也是一样：先生成文案草稿，再运行多步活动，最后才是自动 A/B 测试和优化。
这些成功的路径有一个共同点：系统先学会在人的监督下表现稳定，再逐步承担更大的责任。
Q：为什么你们会把这个过程看成是“学习路径”，而不仅仅是产品版本迭代？
Aishwarya：因为真正发生变化的，不只是产品功能，而是你对系统的理解程度。
在高控制阶段，你其实是在为系统“收集行为数据”：用户怎么用它？人类在什么地方介入？介入的原因是什么？这些信息会反过来告诉你，哪些决策是可以安全交给系统的，哪些永远不应该。
如果你跳过这个阶段，直接进入高自治，你就失去了这层学习机会。那时你面对的不是一个可以逐步校准的系统，而是一个你只能被动应对的复杂体。
05
｜AI 产品的护城河，不是你今天用了多强的模型，而是你是否建立了一套能持续学习和修正的飞轮
Q：你们为什么会对“one-click agent”“开箱即用自动化”这类说法保持高度警惕？
Kiriti：因为它往往低估了现实世界的复杂度。我们接触的企业环境里，数据是脏的、流程是断裂的、命名和分类是混乱的，而且充满了没有被文档化的隐性规则。
在这样的环境中，一个号称“接上就能跑”的 agent，几乎不可能真正理解上下文，更谈不上稳定地产生价值。你可能在 demo 里看到它跑通了一条理想路径，但一旦进入真实系统，它会立刻暴露出大量你事先无法预料的问题。
Q：这些问题为什么不能通过“更强的模型”来解决？
Aishwarya：因为很多问题根本不是模型能力的问题，而是系统和组织的问题。
比如企业内部存在大量技术债：相似但不一致的接口、历史遗留的字段、彼此冲突的业务规则。模型并不知道哪些规则“已经废弃但还在系统里”，也不知道哪些字段“看起来一样但语义不同”。
如果你不花时间理解这些结构，只是指望模型“聪明一点”，那你得到的只会是一个在错误假设之上运行得更快的系统。
Q：那你们所说的“飞轮”，具体指的是什么？
Kiriti：我们指的是一套持续获取反馈、理解行为、并据此改进系统的机制。
当你的产品从高控制开始时，你其实已经在悄悄构建这个飞轮：
- 人在什么时候介入？
- 为什么要介入？
- 哪些输出被接受，哪些被拒绝？
这些都是极其有价值的信号。它们不是评测基准上的分数，而是真实世界告诉你的“系统应该怎么长大”。
Q：这和传统软件里的迭代，有什么本质不同？
Aishwarya：传统软件更多是在修 bug、加功能；而 AI 产品的迭代，更多是在校准行为。
你不是在问“功能有没有实现”，而是在问“系统在这种情境下的反应是否符合预期”。这就决定了，你需要持续地观察真实使用、不断发现新的失败模式、再反过来调整产品设计、提示、工具边界或自治范围。
这个过程如果不存在，你的产品就会停留在“看起来很智能，但不可靠”的状态。
Q：为什么你们会说，“是不是第一个上线 agent”几乎不重要？
Aishwarya：因为领先并不是一次性的事件，而是一个长期过程。
如果你只是更早上线了一个高度自治的 agent，但没有建立反馈和修正机制，那你很可能在几个月后被迫回退，甚至关停。相反，那些看起来走得慢一点的团队，如果早早搭建起学习飞轮，反而会在后续迭代中不断拉开差距。
AI 产品的竞争不是短跑，而更像是一场耐力赛。模型会变，能力会扩散，但你在实践中积累的理解、数据和判断，很难被复制。
Building AI products right，本质上不是一场速度竞赛，而是一场关于耐心、判断力与组织学习能力的长期战。
Q：你们反复提到“痛苦”，甚至说“pain is the new moat”，为什么在 AI 产品里，痛苦反而成了一种优势？
Kiriti：因为现在没有教材，也没有成熟范式。你正在进入的是一个三年左右的新领域，几乎所有成功的团队，都是通过反复试错走到今天的。
那些痛苦并不是无意义的——比如系统在某个边缘场景里反复失败、用户行为和你预期完全不同、上线后才发现评估指标根本不够用。这些经历会迫使你理解：哪些事情是绝对不能妥协的，哪些地方必须接受现实约束，再在约束中寻找解法。
这种理解，是无法通过看 demo、读论文、或者复制架构获得的，只能通过“做错—修正—再做”的过程积累。
Q：这是不是意味着，AI 产品的护城河更多来自经验，而不是技术领先？
Aishwarya：是的，而且这一点在 2025 年之后会变得越来越明显。模型能力正在快速商品化，今天的领先很快会被抹平。
真正难以复制的，是你在构建产品过程中形成的判断力：你知道在什么地方必须有人在环、在哪些场景可以逐步放权；你知道哪些失败模式是暂时的，哪些是结构性的；你也知道该在什么时候停下来校准，而不是一味加速。
这些判断，来自长期和复杂现实的摩擦，而不是来自一次“聪明的设计”。
Q：从更大的时间尺度看，你们觉得接下来一两年，AI 产品会发生什么变化？
Kiriti：我们会看到更多“背景型”“主动型”的系统出现——它们不再等你下指令，而是开始理解你正在做什么、关心什么，并提前介入。
但要实现这一点，系统必须真正理解上下文，而这只有在它被深度嵌入真实工作流之后才可能发生。这也意味着，那些已经经历过早期痛苦、理解自己数据和流程的团队，会比后来者走得更快。
所以从这个角度看，2026 年确实会是 agent 更广泛落地的一年，但前提是：你已经为此付出过足够多的“校准成本”。
Q：对正在从 0 到 1 构建 AI 产品的创业者来说，最重要的提醒是什么？
Aishwarya：不要把“自动化程度”当成成功的代名词。真正重要的是：你是否在一个具体问题上，持续、稳定地为用户创造了价值，同时没有破坏信任。
如果你发现自己每天都在救火、回退、打补丁，那不是因为你不够努力，而很可能是你一开始站错了抽象层级。慢一点、低一点开始，把系统放在可理解、可修正的范围内，反而更快。
Q：如果要用一句话总结你们关于“Building AI products right”的判断，会是什么？
Kiriti：AI 产品的竞争，不是模型能力的竞赛，而是谁更早接受不确定性，并愿意围绕它重构产品、组织和学习方式。
那些愿意走过痛苦、把痛苦转化为结构性理解的团队，最终会拥有真正的护城河。
文章来自于“AISecret出海报告”，作者 “Ben”。