a16z's latest interview: It's too early to say SaaS is dead; the biggest bottleneck for AI implementation is no longer model intelligence

面对公开市场对 “AI 摧毁 SaaS” 的极度恐慌，a16z 合伙人 Alex Rampell 认为，这种担忧源于脱离现实的静态思维，真正内置了处理现实情况的核心业务流程不仅不会消亡，反而将迎来现金流爆发。

3 月 6 日，知名投资机构 a16z 与软件公司 Atlassian 的 CEO Mike 针对当前公开市场极度关注的 “SaaS 大灾难” 叙事展开了深度对谈。

与会者认为，当前的恐慌有些脱离现实，AI 并非 SaaS 的终结者，而是行业加速分化的催化剂；未来的软件竞争不仅在于模型能力，更在于业务逻辑的壁垒与定价心理学的博弈。

SaaS 估值大分化：谁将归零，谁将迎来现金流暴涨？

当前公开市场投资者往往将所有软件公司混为一谈，但实际上，AI 对不同 SaaS 类别的冲击截然不同。Alex 指出，目前的 SaaS 公司可以大致分为三类，而市场没有区分它们的能力。

第一类是极度危险的 “账号与产出挂钩” 的企业，比如 Zendesk。Alex 说：

“Zendesk 就是这里的 ‘一号病人’。如果 Zendesk 客户现在使用 Sierra、Decagon 或者选择自研方案，他们需要的账号可能就是零。”

对于这类企业，如果不转向基于结果的定价并彻底改变现有模式，“那项收入流百分之百会归零”。

第二类则是具备极强壁垒的核心业务系统，如 Workday。这类系统表面上也是按账号收费，但这只是一种 “聪明的定价策略”，其真正的护城河在于内置了数十年的隐性规则和 “边缘情况（Edge cases）”。Alex 强调：

“许多软件其实是一套经过数十年学习积累而成的确定性规则……如果印第安纳州的那个员工离职了且当时正在休产假呢？除非你亲身遇到过，否则你根本无从知晓这些边缘情况。”

对于这类深入企业骨髓的系统，AI 不仅不会消灭它们，反而会赋予其极大的增量价值。

“真正的核心业务系统、具有粘性、人们所依赖且内置了所有边缘情况的软件将会大有作为……当这一切真正发生时，未来的现金流将会大幅增长，这令我震惊。”

第三类是处于中间状态的产品，比如 Adobe。AI 时代会使这些产品的需求量减少，但情况不像 Zendesk 那样极端，也不像 Workday 那样完全不受影响。受到的冲击介于两者之间。

为何客户讨厌 “按结果和 Token 计费”？

随着 AI 的普及，前端应用与后端数据库逐渐分离，软件定价模式正面临严峻挑战。市场上关于转向 “按消耗计费（Token/积分）” 或 “按结果计费” 的呼声高涨，但实操层面却阻力重重。

Mike 一针见血地指出了客户的抵触心理：

“当你与客户交流时，你会发现他们非常讨厌这种方式，他们真的很反感星号附加条款。”

他解释道，传统的云存储计费是可控的，但 AI Token 的世界对客户来说是黑盒。

“客户会觉得不明白你给我的这种代币或筹码到底是什么……我可以让我客户的额度消耗在一夜之间翻十倍，仅仅通过添加一大堆类似为你生成很棒的摘要这样的功能。客户会觉得我并没有要求做那个。”

此外，按结果（如节省成本）计费在第一年是个好销售说辞，但到了第二年，客户会认为基数已经降低，难以继续衡量 AI 提供的增量价值。因此，Mike 得出结论：

“当你和客户沟通，他们还是想要按账号计费。这可能是因为他们现在更理解这种模式，并且他们被很多按量计费模式坑过。”

Vibe Coding 无法取代核心流程

技术圈目前盛行一种 “替代论”，认为通过 AI 编程（Vibe Coding），企业可以自己写代码替换掉所有传统 SaaS 工具。但 Mike 直言这种想法并不现实。

Mike 表示，知识型企业的核心在于协调成千上万个输入受限（如法务、客服审批）和输出受限（如研发、创意营销）的流程。

“我个人很讨厌 ‘核心业务系统’ 这个说法，因为它听起来就像是一个静态的数据库……对我来说，业务是一套基于流程的系统，而不是记录系统。”

AI 编程带来的真正改变，不是让企业从头重写一个 Workday，而是让企业能够在这些底层巨头系统之上，以极低的成本构建高度定制化的应用。Mike 说到：

“比如我想要一个为迈阿密团队开发的会议室预订 App……过去我肯定负担不起……但现在我也许可以轻松构建它。这个 App 在底层使用了 Workday 在全球的数据和规则。”

这实际上让底层的 SaaS 巨头 “在企业级市场中更具粘性也更有价值”。

AI 落地的最后十公里：不是模型智商而是信任设计

在探讨未来产品的想象空间时，访谈揭示了 AI 软件在真正落地产生收入前必须跨越的体验鸿沟。当前模型的能力已远超实际交付的价值，而瓶颈在于 UI/UX 设计与人类的信任机制。

Mike 指出，将 Agent（智能体）引入复杂业务审批流中，最大的挑战不是底层算力，而是如何消除黑盒感。如果 AI 瞬间处理了十几封邮件，用户的本能是恐慌而非感激。

“盲目承诺 ‘我可以为你做任何事’，只会让用户无所适从。”

未来的软件交互正在经历从 “拟物化（Skeuomorphic）” 向第一性原理的演进。以文档流为例，传统的打字排版正在被 “左边是文档实体，右边是聊天窗口” 的 AI 协作模式所取代。

尽管改变用户几十年的习惯极具挑战，但这不仅是产品设计的范式转移，更是 SaaS 企业将 AI 潜能转化为实实在在订阅收入的必经之路。正如 Mike 所言：

“现实情况是，并非每一家 SaaS 公司都能在未来十年中繁荣发展……但对于我们而言，这是我们业务中发生过的最好的事情。”

访谈原文如下：

Alex：从 1960 年到 2022 年，软件的全部历史就是把文件柜变成数据库。第一个例子是 1960 年 IBM 与美国航空合作开发的 SABRE 系统。它取代了以前由众多秘书管理、存放在保险柜里的纸质预约系统，将这些数据存入了早期的数据库中。要知道，在那个年代，10MB 的硬盘可能要花费数亿美元。电子健康档案的发展也是如此，马萨诸塞州综合医院（Mass General Hospital）开发了最早的系统 MUMPS。同样地，Salesforce 以及 1987 年成立的第一家 CRM 公司也是如此，它们本质上都是把文件柜变成了数据库。

这种做法确实有好处，但并没有让世界变得多高效。以前如果要找 Eric 的资料，你会让专人去人力资源部的文件柜里调取。现在虽然数据都在 Workday 里了，但你必须设立首席信息安全官以防系统被黑，还需要 IT 人员在单点登录系统中为你配置账号（seats）。只有在跨地区协作时效率才有所体现，人们现在可以协同工作，并在数据库上执行复杂的连接查询，这在纸质文档时代要困难得多。但本质上，从 1960 年到 2022 年的软件依然只是静态的，因为文件柜本身无法思考。

而如今 AI 领域正在发生的最酷的事情，就是文件柜可以自己干活了。比如 QuickBooks 现在实际上可以独立完成某项任务，而不再仅仅依赖人类从系统里检索文件，这就像彻底告别了 16 世纪老派会计部门去档案柜翻找资料的时代，非常有趣。

Erik：这确实是个很好的切入点。大家现在都在讨论 “SaaS 末日” 甚至 “SaaS 大灾难”，这显然是指公开市场上正在发生的事情。关于它的重大意义，很多人都有不同的观点。我想听听你们两位是如何解读的？到底发生了什么？更重要的是，我们该如何理解这一切？为什么大家对此感到如此恐惧？

Mike：我认为，全世界目前都在试图弄清楚，在这个高度颠覆性的阶段，该如何对软件业务进行评级或估值。每个人对未来会是什么样子都有自己犀利的见解。不同的观点描绘出了两种极端的未来：对整个软件行业、某些特定公司或类别而言，要么极好，要么极坏。毫无疑问，目前的风险水平已经上升了。

从投资者的角度来看，SaaS 曾经是一个非常稳定的类别，现在由于风险变高，人们会选择退后一步保持观望。正如我经常说的，投资者并不一定是在试图通过现金流折现模型来计算一家公司历史上所有的利润，他们其实是在揣摩其他投资者会怎么做，或者说，他们押注的是别人眼中的未来走向。

目前的恐慌其实有些脱离现实。大家总是在想：“如果 AI 在两三年内就能实现某个功能，那意味着什么？” 我认为这种担忧源于一种非常静态的思维方式，仿佛人们不会去适应、世界不会改变，就好像只有 AI 这一项技术在变，而其他所有事情都将保持静止。所以现在的局面很有趣：像我们这样的企业依然表现出色，已经连续三个季度业绩优异。尽管我们不是在这里为整个软件行业辩护，但就我们自己的业务而言，我们对当前的机会感到非常乐观，这也是我们不断展示出的数据和结果所证明的。

当然，这并不意味着我们不需要去适应。我们正在像过去几年一样，彻底、迅速地改变我们的工作方式。许多人误以为我们无法改变或应对，这显然是不对的，虽然前路确实有许多战略上的变数。现实情况是，并非每一家 SaaS 公司都能在未来十年中繁荣发展。就像从 Windows 时代跨越到互联网时代，有一大批公司未能成功转型云端一样，不可能 100 家 SaaS 公司都能挺过难关并继续壮大。也有人认为软件在某种程度上会消亡，或者最终只沦为一种现金收入流。但我可以代表我们公司发言：这是我们业务中发生过的最好的事情。我们身处一个知识的世界，拥有利用知识进行探索和行动的工具，以此来完成客户雇佣我们去解决的任务。这在逻辑上是非常完美的，但我们必须在转型过程中将其付诸实践向人们证明，毕竟让市场保持耐心是很困难的。

Erik：Alex，你呢？你对最近发生的事情有什么反应，或者你如何理解正在发生的事情？

Alex：我希望从长远来看我的判断是正确的，因为现在发生的一切实在太疯狂了。几周前我就此发过一条推文，我初步观察发现，目前市面上大概有三种不同类型的 SaaS 公司，但公开市场无法区分它们。其中一种公司的账号（seats）权限是与产出挂钩的，账号（seats）由真正使用系统的人占据，这就好比又回到了刚才那个文件柜的比喻。

在深入探讨之前，我想先退一步回答你的问题。丹·艾瑞里（Dan Ariely）写过一本非常棒的书叫《怪诞行为学》。我以前常把这本书发给公司的所有产品经理，让他们通过学习这本书来搞清楚我们该如何向用户收费。书中有一个很经典的例子：想象一下，半夜 12 点你被锁在公寓外面，你叫了一名锁匠。他 1 分钟就赶到了，花了 30 秒帮你开了门，然后向你收费 500 美元。你心里肯定会想：“就干了 90 秒的活，居然收我 500 美元？搞什么鬼！” 于是你会在 Yelp 上给他留个一星差评，不给小费，甚至可能向信用卡公司申请撤销这笔扣款。

现在想象一下另一个平行时空：锁匠来了，花了 9 个小时尝试帮你开门。他中途回办公室拿了更多工具，折腾到早上 9 点半，终于让你进了家门。此时你会对他花了九个半小时帮你开门感激涕零，不仅给了他 200 美元的小费，还在 Yelp 上留了五星好评。

这个例子基本上说明了，人类在某种程度上能够并且愿意为 “无能” 买单。很多定价策略其实关乎心理上的公平性。我们觉得给那个折腾了一晚上的人多付钱是公平的，哪怕他完全不称职；而面对那个能力极强的同行，我们却因为觉得他收费过高而感到极其愤怒。这在逻辑上毫无道理，但在情感上却让人感觉很公平。

如果你回想一下我们是如何演变成 SaaS 模式的，比如按人头每月计费这种。当你免费提供时，很多情况下的数字化配置成本几乎趋近于零。这并非针对所有事物，大家只是觉得这样才公平。比如你有 500 个账号（seats），你支付的费用自然比只有一个账号（seats）时更多，尽管后台运行的机制其实大同小异。

所以我认为 SaaS 公司可以大致分为三类。第一类是你原本需要账号（seats）来产出某些工作要素，但现在不再需要了。Zendesk 就是这里的 “一号病人”。如果 Zendesk 客户现在使用 Sierra、Decagon 或者选择自研方案，他们需要的账号（seats）可能就是零。因此对于 Zendesk 来说，我们谈论的是未来现金流的现值。他们正处于危险之中，因为如果只针对现有产品按每月每账号（seats）收费，永远不对代码或定价做出任何改变，那项收入流百分之百会归零。但另一方面，如果他们转向基于结果的定价并放弃原有模式，收入也可能会翻三倍或四倍。这仍然受制于公平法则和可预测的非理性。像 Zendesk 这样的产品可能上涨也可能下跌，但除非发生改变，否则默认路径就是走向归零。

第二类是按账号（seats）付费的定价，这感觉很公平，但账号（seats）并没有绑定到某个结果上。比如 Workday 有这样一个很棒的定价模型，由于你有 34 万名员工，我就按每人每月向你收费。为什么收费？我不知道，只是觉得这样公平。但是 GE 的那些员工并不是在使用 Workday 来产出成果。我觉得 Workday 挺好的，这其实涉及到你可以用 AI 工具做什么。比如在 GE 招聘员工时，HR 必须去查看 Workday 中的文件并致电那三家前司来进行背景调查，确保候选人的履历真实。但 AI 工具完全可以做到致电公司这一点，前提是你必须是核心业务系统。目前 IT 领域下跌了 45%，但没有人会弃用 QuickBooks。这两个支柱就是按账号（seats）计费且与某种工作量挂钩，账号（seats）只是一种聪明的定价策略。

第三类是处于中间状态的产品，比如 Adobe。你可能需要更多或更少的账号（seats），但情况既不像 Zendesk 那样极端，也不像 Workday 那样脱节。

在这些情况之外还存在一种认为用 AI 能编写所有代码的潜流，作为一名资深软件开发人员，我认为这简直荒谬。我想引用经济学家大卫·李嘉图在 1817 年提出的比较优势理论。比如你可以自己种粮食或焊接铝材，但即使是这些简单的例子也不恰当。这就好比在和你一起录制播客这件事上我拥有比较优势，我做这个能赚得更多，即使我可能比水管工更有生产力，我还是应该专心做播客。

更重要的是那些隐藏在底层的边缘情况。理论上我可以通过 AI 自动编程搞定一些 Workday 的流程，但如果印第安纳州的那个员工离职了且当时正在休产假呢？除非你亲身遇到过，否则你根本无从知晓这些边缘情况。

许多软件其实是一套经过数十年学习积累而成的确定性规则，这些规则并未公开且内嵌其中，你无法直接复制，需要通过经验来复现。如果这是一个非常简单且没有边缘情况的子任务，AI 确实可以胜任。

但我认为真正的核心业务系统、具有粘性、人们所依赖且内置了所有边缘情况的软件将会大有作为。它们将开始增加由 AI 完成工作的功能，比如询问你是否需要进行背景调查或催收逾期的应收账款。你不需要雇佣人工，雇佣你的软件即可完成这些任务。当这一切真正发生时，未来的现金流将会大幅增长，这令我震惊。

许多公开市场投资者无法区分这些不同的范畴，他们对 AI 非常兴奋，却不知道必须通过作为核心业务系统的软件来部署 AI。我认为现在正是每个人回归商业本质第一性原理的迷人时刻。

Mike：我个人很讨厌 “核心业务系统” 这个说法，因为它听起来就像是一个静态的数据库，把东西放进去再取出来。这种将业务视为文件柜归档系统的观点，是处于一种非常工业化的时代背景下，与前工业时代的商业模式截然不同。

我明白为什么会有这个术语，但这感觉有点像我们还在用实体软盘图标作为保存按钮。孩子们根本没见过实体软盘，却一直用着这个图标。我质疑这一点是因为对我来说，业务是一套基于流程的系统，而不是记录系统。

Alex 刚才所说的一切完全正确，企业中存在诸如背景调查或其他类似流程。你能以尽可能低廉、高效且快速的方式协调一系列流程发生，这实际上是知识型业务的核心。在知识时代的业务中，我有上万名每天走进大楼带着大脑工作的员工，下班离开时又带走大脑。我没有任何原子资产、钻头或钢材，甚至连文件柜都没有。我所做的一切都是关于协调那一套套的流程，我认为大多数现代企业可能都是如此。

谈到这一点与 Alex 的评论有什么关系？我认为这完全正确。我们在业务中有不同类型的流程，我喜欢将其称为输入受限型和输出受限型流程。以 Zendesk 的客户服务为例，那就是输入受限。你的客户会提出一定数量的问题，你处理这些问题的速度关系到运行该队列的效率、成本、速度和质量。如果你处理的速度快了 10 倍，你并不会因此得到 10 倍数量的问题，因为客户数量是固定的。你面临的问题是该如何让他们减少提问，或者更快地处理问题。实际上，企业中有很多流程都属于输入受限型。

我总是拿我们的法务团队举例，他们的工作不是去主动创造法务工作，而是去响应和处理这些工作。比如我们有多少份租赁合同？有多少份 NDA 保密协议？有多少份常规合同？这就像是一个固定的总量。为了完成那项工作，我正试着尽可能高效地进行，这部分属于有着完整执行进程的输入受限工作。但随后我也会面临某种输出受限的工作，比如创意、营销甚至是软件开发和技术领域，在这些领域理论上我可以完成无限的任务。

我的瓶颈在于我的创造力，或者说取决于我能想到多少可以做的事情，以及我能为客户交付多少价值。这些才是我获取效率提升并且产出更多内容的地方，而不是仅仅在范围内限制输入来让公司盈利。

关于印第安纳州的说法完全正确，因为有些流程必然受到外部规则的约束，比如法律、治理和合规性要求。在印第安纳州我必须为员工履行某些特定程序，这些流程既是我希望业务运行的方式，也是它必须运行的方式，企业实际上就是所有这些流程组合在一起的集合。从某种角度来看，我们拥有记录系统和执行系统。我的想法是大多数企业的实际运作方式并非如此，但我们通常是这么理解它的。

Alex：我完全同意，我认为这是一个非常棒的框架。我很喜欢 Intuit 就像 TurboTax 那样，既然税法是公开出版的你完全可以去下载所有规则，它具有高度的确定性，你可以让报税和那些乱糟糟的下载文件夹同时处理。在这种情况下一切规则都是透明的，但我认为边缘案例被公开发布出来其实是一种相当罕见的情况。

企业是有价值的，理论上有很多偏向知识经济的企业，他们所有的资产每天晚上都会乘电梯下楼回家，但这些业务确实具有核心价值。比如 McKinsey 在脱离所有员工之后是否还具有价值？因为那是一家靠知识经济产出成果的业务，它与劳动力深度挂钩而不像实体产品那样。尽管如此，他们可能拥有一本绝密的内部手册，规定了如何运作、如何招聘解雇员工以及如何为客户带来成果。我还没见过这种手册，正因为没见过所以也无法复制，而它可能已经建立并延续了一百多年。

非数字、非软件公司的产品是什么？他们的产品可能就是长达几个世纪或几十年的知识积累。我喜欢去日本，你会看到有些面馆大约从 1587 年就开了，能传承这么久肯定是有名堂的。这是一种长期积累而成的文化、知识和技能诀窍，当然也会有一份制作面条的食谱清单。做面条可能稍微简单些没有那么多边缘情况，但也可能会遇到极端情况。比如如果面粉用完了你会怎么做？面馆是如何在 1623 年的大面粉饥荒中幸存下来的？他们必然采取了某些措施，而这些经验就这样积累在那本秘而不宣的诀窍之书中，而不是去复制那些已经向公众公开的东西。

Mike：这就是我认为它如此迷人的地方，它迫使我们重新思考自己的业务。真的是 Intuit 在为你填写税法吗？还是说 Intuit 对税法的了解程度已经达到了无人能及的地步？。他们所提供的核心价值是帮助你处理生活数据并梳理你的理解，向你提出正确的问题，从这点来看 Intuit 现在更像是一家 McKinsey。这是他们的特殊能力，即如何向你提出正确的问题来填写税务表格，而不是单纯地去填表。

现在所有企业都不得不重新审视自己，也许我内部有 50 个流程曾被我认为是独一无二的核心秘诀，但实际上只有 20 个是真正的核心。我现在必须认真考虑在这些流程中哪些确实是独特的而哪些不是，因为我们以前从未需要以这种方式进行思考。

Alex：我认为这在某种程度上是一个关于如何平衡的问题。关于这是否值得亲力亲为，如果你采用第三方工具，它不是不可触碰的红线而更像是一种独立的变量。我现在应该用 Claude Code 自己写代码吗？如果某家公司对软件收费过高甚至会导致我的业务失败，且自己开发已经能完成 99% 的需求并覆盖成本，那么自己写代码就是有意义的。但如果那个软件每年只需一美元那自己开发就没有意义了。

而且并非所有的记录系统价值都是相等的。我倾向于将记录系统看作是某种业务的原子单位。比如日历是时间的记录系统，ERP 是库存的记录系统，你拥有所有这些不同维度的记录系统。我给别人举过一个例子，比如我在迈阿密有一个不经常去的办公室，那里有一套像 Google Calendar 一样的会议室登记系统，我是否愿意花精力去更改那个系统？显然愿意，因为那个办公室一年才去一次谁在乎它稳不稳定呢？

相比之下有些系统可是会直接影响我收入的，而且它们本身并不昂贵。我真的要为了吃饭自己去种粮食吗？采用农业隐喻的话去餐厅吃饭其实要便宜得多。如果我只是想要一个汉堡，肯定没必要自己去买一头牛然后喂养等待，由于比较优势和规模经济的作用在餐厅消费大量的食物实际上成本更低。

所以存在一些记录系统更容易受到影响，仅仅是因为它们的定价过高，或者就其存储和记录的内容而言它们的价值并没有那么高。Carta 为很多公司追踪管理股权结构表，你多久查看一次股权结构表？虽然不怎么频繁但它非常重要绝对不能搞砸。所以我很可能愿意继续使用 Carta 因为他们收费并不高，而且它不是那种日常高频使用的产品，所以它甚至不在被替代的考虑维度上。

Mike：我觉得 vibe coding 这件事太迷人了，作为软件圈子里的人，感觉人们以后直接靠氛围写代码 vibe code 就能把那些传统工具全替换掉。但转念一想如果我靠氛围写代码来搞定一整天的工作然后直接运行它，那简直太可怕了。这背后依然得有一些真正聪明的工程师兜底才行，首先我有其他更重要的事情要让他们去做，其次我觉得彻底依赖这种方式目前对我来说弊大于利。然而这就是所谓的替代论趋势。

不可否认的是，我们看到内部在软件的可扩展性方面通过使用 AI coding 等方式获得了巨大的提升。大多数此类应用程序都具有高度的可配置性和可定制性，在我们的案例中甚至实现了真正的可扩展性。你可以编写运行在平台之上的、涵盖各种不同领域的软件应用程序片段，许多客户也确实是这么做的，但以前他们需要投入一支庞大的技术团队来完成这项工作。

现在他们利用 vibe code 的能力，就可以针对特定用例去扩展和高度定制应用程序。比如我想要一个为迈阿密 Miami 团队开发的会议室预订 App，由于迈阿密有一些奇怪的 HR 政策，所以那个供 20 人使用的 App 需要随时查看 Workday 以及其他各种系统。过去我肯定负担不起让内部团队投入 IT 资源构建它的成本，因为账单金额会太高，但现在我也许可以轻松构建它。这个 App 在底层使用了 Workday 在全球的数据和规则，但它给了我一个非常定制化的 interface，去为迈阿密前台完成一些非常针对他们需求的特定工作。这非常强大，但它并不能完全取代人类的工作。

说起来可怜的 Workday，我觉得 Aneel 就像是这些概念性示例中经常被调侃的对象。但这其实真的很强大，它实际上让 Workday 在企业级市场中更具粘性也更有价值，因为你可以基于它构建所有这些定制应用程序，这就是 AI、Vibe Coding 和创造力的力量，使底层系统能更贴合我的具体需求。

但我们必须非常谨慎地处理稳定性、规则流程与高度定制化之间的平衡。你甚至可以认为像 openclaw 之类的例子就是为了给个人量身定制非常私人化的 App。构建这些应用的人大多数并不是软件开发人员，他们只是在 Gmail 之上构建仅供自己使用的 App 或者其他小工具。但这仍然是将 Gmail 作为轨道，他们依然需要去 Gmail 阅读和处理邮件，只不过他们为自己构建了一些特定的东西来解决只有自己才会遇到的问题。其中有几个项目可能会演变成公司，但大多数仅仅是在解决他们自己需要处理的事情，这确实非常强大。

Alex：这就是为什么我对前端与后端不一致带来的定价公平性感到好奇。以 Salesforce 为例他们是按许可证收费的，我想我们公司大概有 600 人，可能就买了 600 个 Salesforce 许可证。我其实从没登录过 Salesforce 但我敢打赌公司也为我付了费，然而我有时确实会使用它的输出，因为它实际上是我们的记录系统。不想过度使用这个词但它确实存储了我们所有的业务关系，而我就像是关系型数据库表 table 里的一部分，比如我是 422 号 userid。

每当我与一家公司对接时就像在另一个数据库中匹配上了，但我们其实只想为一个底层数据库付费。现在就像是在一个前端与后端逐渐分离的世界里，事实就是这样。我觉得 Workday 想出了一个非常聪明的定价策略，这是一种强大且让人感觉公平的定价范式。你的员工越多付费就越多，为什么那样才公平？因为 GE 的利润显然比一家 10 人的公司要多，GE 理应为此支付更多的费用，而这笔钱对他们来说仍然只是九牛一毛。它的定价完全处于最理想的黄金区间，我认为没有人会对此产生异议。他们未来将增加大量 AI 营收，但最重要的是他们的底座定价让人感觉很公平。

然而对于这些前端与后端在某种程度上已经分离的产品，我不知道什么是公平的定价模式，也不确定未来的软件定价会发生什么变化。显而易见如果没有人愿意买账，大家都去编写自己的代码而不再有任何竞争，那么定价逻辑将保持不变，但你可以想象未来人们都在定制化的前端上构建东西然后直接从底层数据库中读取数据。因为所有的记录系统都有一个数据库代表了底层的一切抽象层，那么这些类别中的任何一个是否会面临价格压力？

对我来说如果前端不再等同于后端，它会比紧密交织在一起的情况面临更大的易感性和冲击。比如 QuickBooks 是由小微企业使用的，他们没有账号（seats）概念，企业主直接登录 QuickBooks 即可，所以它的前端在某种程度上就是后端。相反就像 Salesforce 你可以想象虽然没有人会彻底弃用它，但他们可能会大幅减少账号（seats）数量，因为底层的后端依然必不可少但对昂贵前端的需求减少了。他们不会消除或者对后端做任何改动，只会优化前端的成本。

Mike：我一直认为定价的公平性和客户观感非常重要，人们需要理解他们为何付费，并觉得他们所支付的费用在某种程度上与其真实的使用情况相关联。一家拥有 1 万名员工的公司在购买 Workday 时很可能要支付两倍以上的费用，外加一些批量折扣，因为他们购买的量更大且业务具有两倍的复杂度，他们自己也认为这很公平。这里看起来合理的原则就是：我愿意按员工人数为我的 HR 系统付费。

我认为这类事情的核心问题在于它不仅仅是一个数据库，它是一个数据库加上一组复杂的进程，在我成长的那个年代我们管这叫业务逻辑。这些业务逻辑绝非无关紧要，为什么企业会有这些逻辑？因为企业本身就是作为一系列流程的集合来运行的，而且管理者追求标准化以在某种程度上实现流程化。这是为了让不同的团队以同样的方式工作，以便有人可以管理、理解他们并精准追踪输出。

就像如果我拥有一堆汽车工厂，我想要持续跨越它们去追踪进出的汽车总数，业务逻辑被嵌入其中的地方在某种程度上就是护城河和价值所在。就传统方式而言那里的销售额实际上非常巨大，你为销售团队制定的那些流程对你来说极具价值，而且你会认为这是一种公平的付费方式。但问题在于你的销售协作团队即那些协作者而非核心用户，他们究竟有多大程度需要这些流程又在多大程度上不需要？

我假设 Salesforce Sales Cloud 有一个 MCP server，那个 MCP server 并不直接访问数据库，它主要涉及你的业务流程以及执行过程中的规则。现在的争议点是某些销售相关人员如果在市场部门或客户成功职能，他们是否需要那些沉重的流程、治理、控制和规则。比如系统规定我们在日本只为客户提供 X 服务、为该地区的客户提供 Y 服务之类的事情，甚至连他们的 MCP server 都需要专门开一个账号（seats）。至于客户是否认为这种捆绑收费公平，那就是另一个悬而未决的问题了。

没错，挑战在于这该如何定价。我想告诉你，在讨论消费型定价或按需计费定价时，基于结果的定价在很多领域都是合理的，但我绝对不认为它会成为主流的软件定价方式，或者说不适用于所有的 SaaS 软件。

因为当你与客户交流时，你会发现他们非常讨厌这种方式，他们真的很反感星号附加条款。这与他们认为自己投入的价值无关。比如我对 Splunk 采用的是按量计费，如果我发送给他们的日志量翻倍，我就得付更多的钱。我明白这个逻辑，但日志记录是由我决定的。我可以多记一些，也可以少记一些。我可以对团队说，你们为什么记录这么多日志，这太贵了，而且你们真的在用这些日志吗？我是可以控制我投入的数据量的。这与存储和 S3 或其他典型服务的模式相同。我存入 1GB 或 2GB 都没问题。问题在于，这些对于我作为客户来说是相对可转移且可控的。

但人们给出的许多关于基于结果或基于消耗定价的例子，作为客户我是无法控制的，而且它们也是不可兑换的。所以 AI Token 的世界和 AI 积分的世界，对客户来说真的非常困难。他们会觉得不明白你给我的这种代币或筹码到底是什么。

我可以从 AWS 获取 1GB 的存储空间并将其部署到 Azure，而且我知道他们会收我多少钱，因为每 GB 的费用基本上是固定的。但当我拥有这些 AI 额度时，我不知道你的额度是否和别人的一样。供应商一直在增加新功能，我的用户在使用这些功能，所以消耗了我的额度。但我不知道他们用这些额度做了什么。

这并不是公司主动选择去使用它们，而是供应商在添加那些让软件变得更好的功能，而这些改进似乎是自然而然发生的。我可以让我客户的额度消耗在一夜之间翻十倍，仅仅通过添加一大堆类似为你生成很棒的摘要这样的功能。客户会觉得我并没有要求做那个。

所以我觉得在谈论基于成果的使用计费时，当你和客户沟通，他们还是想要按账号（seats）计费。这可能是因为他们现在更理解这种模式，并且他们被很多按量计费模式坑过，这种模式会导致账单金额大幅飙升，他们会不知道该如何控制。

是的，这需要一些时间来适应。它肯定会出现在很多类别中。我们在 Atlassian 的业务涵盖了很多领域，你可以称之为基于用量的定价，或者字面意义上的按需计费。但我们尽量专注于那些客户业务量翻倍时，他们能获得两倍的价值同时也支付两倍费用的领域，而且这一切都在他们的控制之下。许多其他定价模式并不在客户的控制范围内。

基于结果定价的最后一个例子是，这些结果也是动态的。比如在客户服务方面，我为你节省了成本。你过去在客服上花 20 块，使用我们的工具你只需要花 10 块。在第一年这是一个非常棒的销售说辞。但到了第二年，客户会说我只花了 10 块，现在我想花 5 块，否则你没有提供任何价值。而供应商回答说如果把我踢出局，你得花 20 块。客户就会觉得但我现在只花 10 块。所以每年能为客户省钱的能力从结果的角度来看很难衡量，即使我正在消除一些繁琐的任务。

Alex：我认为从销售的角度来看也是如此。我创办过两家支付公司。我非常羡慕 Workday，我常会和我的销售团队谈起 Workday，因为他们对外部情况了如指掌。他们知道能从 GE 赚多少钱。他们会说 GE 有 33 万名员工，也许我们每个月向他们收取每位员工 5 美元，这就是能从该账户中赚到的钱。

如果你在销售一款软件产品，这样去规模化组建销售团队要容易得多。因为你知道那家公司会付给我们 300 万美元。相比之下，当我们刚创办公司时，签约了 1800 个公司，我们完全不知道能从他们身上赚多少钱。结果真正让业务运转起来的是 Casper 这家床垫公司。你根本无法预测。你以为拿下了沃尔玛这样的大客户，但刚开始进展得并不顺利，反而是签下 Casper 后业绩惊人。

Workday 具有这种双向的可预测性，对于出资方的客户而言是可预测的，对于管理团队来说也是可预测的。你能明确应该把时间花在争取签下 GE 这样的客户上，而不是签约一家 10 人的公司，因为 GE 规模更大。但在互联网世界里情况却非常疯狂，Stripe 从一家 10 人公司赚到的钱可能比从 GE 赚到的还要多。在那种模式下你可以获得更高水平的可预测性。

但采用基于结果的定价或者基于消耗的定价，虽然基于消耗的定价本身并不坏，但如果你无法从外部了解一个账号（seats）能赚多少钱，扩展销售和营销团队就会变得呈指数级困难。

Eric：作为一名企业家，我想回到的一点是，在这个时代，你能分享一下这对你来说最主要的体现方式是什么吗？以及它是如何让你改变业务的？

Mike：我们的看法是，我们销售的是解决人类协作问题的协作工具。在许多不同的领域，包括服务团队、广泛的业务团队、人力资源、财务、软件团队等，许多不同类型的团队通过我们购买不同的应用套件和组合。从根本上说这些都是涉及大量文本的协作问题。这对我们非常有利。那些人在做什么才是最重要的部分。

技术世界往往趋向于重塑一切，并认为这是未来的方向。从中长期的视角来看这通常是正确的。但我们面临的挑战始终是，我们拥有大量以现有方式工作的客户，如今各种 App 中的工作流其实并不怎么智能。他们想要迈向未来，但同时也必须带动大量的用户。所以当我们构建 AI 功能时，首先考虑的是我们需要理解这项技术是什么，以及它能如何帮助我们。其次，我们需要构建什么样的基础平台组件来应对未来的变化，因为这些技术的发展速度实在太快了。

这就是我们开发 AI Gateway、团队协作图谱以及企业级合规性与控制功能的初衷。你必须将这些内容与你在特定 App 中为客户构建的功能区分开来。那么你把这些功能放在哪里？这些功能具体是什么？其中很大一部分存在于现有的工作流中，旨在帮助客户更快、更好、更高质量、更高效地完成现有的工作流。这些功能往往非常平淡无奇，这就像 X 平台上那段 30 秒的动画 GIF 走红一样。但这对于客户来说非常令人兴奋，因为他们现在就可以使用，他们现有的工作方式变得更出色了，他们会觉得这太棒了。在 AI 世界里我却觉得那其实挺简单的，而且这在今天确实能给他们带来巨大的帮助。

我常对内部人员说，光举一个服务方面的例子还不够，你需要利用他们现有的工作流程，结合新应用或者查看新的工作流来处理问题。所以我们必须完成所有这些。如果你看 Jira 这个典型的例子，在我们的 HR 和 IT 服务管理产品的服务集合中，正在进行工单总结。这是我们可以做得比以往任何时候都好得多的事情。

内部大概有四五个人在处理同一个工单，试图解决一个问题。当第四个人介入时，已经有了大量的附件和对话记录。通常情况下他们可能需要花费 30 分钟才能读完所有内容并理解到底发生了什么，这样才能发挥专业知识来解决问题。总结并不只是简单地将内容输入到 LLM 中然后获取摘要。上下文对模型来说非常强大，但客户的工作流程却没发生哪怕一点点改变。它仍然是 Alex 对 Eric 说你能来帮我处理一下这张工单吗？Eric 走过来必须先将大脑中所有的相关信息进行加载。这就像是一个现有的工作流，我们可以利用 LLM 让客户体验变得更好，而且他们非常喜欢，对这类功能赞不绝口。但这些功能通常不具备智能体特性。

那么我们可以说，对于那个服务工作流，我们需要在各个环节中加入智能体。大多数人正在处理一个工作流，然后发现这一步经常让人栽跟头，耗费大量时间。我们能让这一步变得更快吗？这绝对是我们必须亲自为智能体框架提供的功能。

我们有一个非常棒的智能体框架供整个团队使用，结合图谱和你已经拥有的所有上下文。这非常简单，价格也非常亲民。或者你也可以自带智能体框架。我认为大多数企业内部都会运行三到五个大型智能体平台。他们可能会说我用 Agentforce 来处理这个，或者我用 Gemini 来处理那个。把那个智能体带过来，我们会把它放入工作流中让它运行起来。我们必须能够做到这一点。

但你仍然完全处于现有的工作流世界中，只是在现有的工作流中执行一种新的高效的任务。接着你会遇到这样的人，他们会问如果服务工单根本不存在会怎样？所以你正在重新构思整类软件到新的工作流。我们必须帮助客户跨越这一鸿沟，因为他们通常不只有一个服务团队，他们有数百个。如果他们运行着数百个不同的服务台，他们可能会说这 20 个将以新方式工作，但他们必须对所有这些进行管理。所以我们正尝试将团队协作图谱中的数据与此结合起来，并且是从客户驱动的角度出发。这一点经常被忽略，我们正试图带他们走向 5 年后的未来，但我们的职责是切实带他们走向 1 年后、2 年后以及 5 年后的未来。

最后我想说的是，我们在设计方面投入了大量精力。在任何对话中这一点总是被忽略，因为在它的运作机制中有很多基础性的设计工作要做。如果回顾移动互联网时代，第一批应用基本上只是将桌面端或网页端的内容直接搬到手机上，然后我们才演进出了新的交互模式和体验。

不仅仅是视觉层面的演进，还包括我们该如何使用这些东西。推送通知最初是用来做什么的？下拉刷新是一个非常显而易见且简单的例子，它是一个非常经典的设计模式。整个过程就像是我该如何让移动端和桌面端协同工作，该如何来回切换。我们有如此多的设计挑战需要解决。这实际上是帮助普通用户理解其中的内容。他们并不想深究，如果 AI 对他们来说不存在也无所谓，他们想要的是 AI 带来的结果，不需要了解所有的技术细节。我们的工作就是隐藏这些细节，直接把结果交给他们，或者使任务更有效、更高效。在技术领域，有时我们太痴迷于模型质量之类的东西了。

现在说模型已经远远领先于实际交付的价值几乎成了陈词滥调。未被充分利用的潜能是如此巨大。这其中的一部分实际上在于设计和体验。我该如何获得这个？给人们一个拥有无限能力的聊天框，他们却只会说给我讲个冷笑话。这就像是拥有无限的力量，但很难帮助他们利用这种力量。这也是我们面临巨大挑战的地方，即如何将智能体及其所有能力引入工作流和协作循环中，并让人类与智能体协同工作。

Alex：我喜欢拟物化设计 (skeuomorphic)。早期 Web 的形态就像你拥有几张实体纸一样，这也是它被称为网页 (web page) 的原因，就好比一张 8.5x11 英寸的纸。后来到了移动端，大家最初的设想只是做一个微缩版的网页。但事实证明，如果你不局限于拟物化思维，而是基于第一性原理进行思考并充分利用设备的性能，你就能创造出全新的交互方式。比如下拉刷新，这就是伴随移动端诞生的新概念。我前几天还在琢磨这件事。你试过 Nano Banana 2 吗？

Mike：试过。

Alex：没错。我的一位同事刚跟我说，他用它为去日本旅游的美国游客做了一份关于注意事项的信息图表。那种一键生成 (one-shot) 的效果简直令人惊叹。但这引出了一个问题：你该如何编辑这些输出结果？现在的编辑方式感觉非常拟物化，依然是那种经典的 GUI 操作逻辑，比如点一下这里，再修改一下那里。所以我想问你，关于编辑 AI 输出的内容，你认为目前业界的最高水是什么样的？或者说理想状态应该是什么样的？既然你提到了设计，最近你在这方面有什么深层思考？

Mike：这是一个非常棒的问题，我想先退两步来回答它。首先，在 AI 领域建立客户信任是非常困难的。我们在做用户调研时发现，人们害怕 AI 并不是因为它的能力有多强，而是因为它的运作像个黑盒。比如你的 AI 助手瞬间清理了收件箱、发了十几封邮件，用户的第一反应往往是：“我怎么知道它做对了没有？” 为了赢得信任，AI 必须向用户及时反馈它的意图并请求确认，但同时又不能频繁到让人觉得烦躁，否则用户会觉得还不如自己动手。所以交互频率和信任机制本身就是一个完整的系统设计问题。

其次，AI 的训练和应用离不开大量数据与不断的迭代。现在社交媒体上充斥着关于神级提示词的炒作，仿佛念一句哈利波特的咒语就能让 AI 自动帮你经营一家十亿美元的公司，这太离谱了。一键到位固然有用，但在现实业务中，你通常需要不断去修改输入和输出。比如你让大语言模型 (LLM) 写篇论文，生成后你发现方向不对，这就需要通过改变输入来进行迭代。但如果你曾尝试通过纯聊天的方式来迭代编辑图像，你会发现体验非常令人沮丧，因为你很难精准控制 AI 不擅自改动其他部分。这本质上也是一个关于输入的体验设计问题。

以我们公司的产品为例，我们的团队协作图谱拥有海量的组织知识和极高的准确度，甚至能记住我十几年前写过的代码。但如果因为 AI 知道我有计算机科学背景，就自动用极其硬核的技术语言回答我的所有问题，这其实是没用的。如果我们在界面上设置一堆勾选框，让用户自己决定 “是否搜索网络” 或 “是否搜索组织数据”，这也完全违背了设计初衷。

AI 应该具备主动预判的能力。你在 Deep Research 等工具中能看到一些这类尝试，但有时也很让人沮丧。这就好比你手下有 50 个实习生，虽然能干很多活，但他们每分钟会问你 50 个问题，导致你整天什么也干不成，全在回答问题了。

此外，在企业环境中实现工作流的迭代要困难得多。比如头脑风暴通常需要团队协作，在我们的 Whiteboard 和 Confluence 中，你可以引入智能体来辅助。它们非常擅长从组织内部提取知识并生成优秀的方案。但如果没有任何人工干预直接让 AI 包办一切，就会失去团队的信任。正常的流程应该是我们先开会收集想法，加入人类的直觉判断，筛选出有用的部分，然后再把这些反馈给另一个智能循环。因为 AI 的输出质量具有很强的非确定性，这就注定了系统必须包含一个人工介入循环。没错，如何把握这个人工介入的度是个极大的设计考验。循环确认的步骤太多会让人感到沮丧，步骤太少又会失去用户的信任。

我们刚在 Jira 中发布了 Agent 功能。当你把任务分配给 Agent 时，它就会去执行。但用户往往会问：“它现在到底在干什么？” 如果你给他们展示上千个底层执行步骤，他们又会觉得你在给他们塞废话。所以仅仅是将 AI 引入工作流，就面临着海量的设计挑战。

回到实际的业务审批流程上来，比如一项交易需要经过安全、会计、财务和销售等多个部门的审核，你该如何用 AI 优化这个工作流？当你将任务分配给 Agent 时，你需要非常小心地设计用户体验：它什么时候返回结果？以什么方式返回？用户能否在它工作时主动询问进度？

我们相信，允许用户随时查看进度有助于在短期内建立信任感。但从长期来看，如果这个 Agent 连续二十次都出色地完成了任务，用户最终会选择完全放权。这些全都是根本性的基础设计与体验问题，而不是纯粹的技术问题。核心挑战在于如何让每天使用 App 的数百万用户对产品产生信任，并消除那种黑盒感。盲目承诺 “我可以为你做任何事”，只会让用户无所适从。

Alex：这确实还是一个悬而未决的问题。因为未来的理想交互方式显然既不像过去那样单纯地点击鼠标，也不像现在这样只是不断地重新输入提示词，它更像是两者的结合。

只要工具是为人类服务的，就一定离不开人类的参与。你需要让用户能够直观地深入理解模型内部的运作逻辑，无论是出于建立信任的目的，还是为了方便后续的修改迭代。这本质上是一个设计问题，而且我认为目前业界可能还没有人完美解决它，我们正处于这一探索过程的最早期阶段，大家都在为如何更好地调整和编辑那些一键生成的内容寻找最优的设计方案。

Mike：我想举一个文档编写的例子。知识工作者几十年来都习惯了以固定的模式写文档：打开一个空白页面，输入标题、打字、列出符号或者插入表格。现在我们推出了 Create with Rovo 功能，你完全可以从一个提示词开始，让 AI 根据模板生成内容，甚至让它先去调研各个维度的信息并整合带回。

但要改变用户根深蒂固的习惯是非常困难的。现在界面变成了左右两部分，左边是文档实体，右边是聊天窗口。想象一下这是一个没有任何工具栏、只能通过对话来排版的 Word。我们需要鼓励用户：“你可以直接在左边修改任何文本，也可以在右边输入指令，比如让它添加一个新章节、去研究其他资料并补充到摘要后面。”

当我们观察那些高级用户时，发现他们非常享受这种模式，他们能熟练地在两种操作间来回切换，领会了这种全新的范式。他们可以下达贯穿整篇文档的全局指令，比如 “把所有标题变成蓝色”，这在传统编辑器里是很难一键做到的。他们甚至可以要求 AI 从董事会成员的视角来重新评估并精简这份文档。

但对于普通的商务用户来说，他们的第一反应往往是困惑：“所以我只需要在左边打字就行了？” 这实际上是一场深刻的范式转移。我怀疑随着 AI 工具的普及，就像移动互联网时代刚到来时那样，大概两到五年后，这种全新的交互方式会变得非常普遍。这就好比大家第一次看到 Excel 时，也会茫然地问 “我该在哪里输入段落”，但现在所有人都知道 Excel 是怎么运作的了。

我们面临的最大挑战，就是如何将所有这些强大的 AI 能力自然地融入到极简的界面中，去协助人们真正调用整个组织的知识来生成文档。我知道这在底层算法和数学逻辑上是完全可行的，但要通过优秀的体验设计来引导用户接受并掌握它，依然充满挑战，同时也令人无比兴奋。我们需要花费大量时间来不断完善这些体验。

Eric：这是一个非常适合作为结尾的话题。Mike，非常感谢你参加我们的播客，这是一次非常精彩的讨论。

Mike：好的，没问题，伙计们。希望这些分享能对大家有所帮助。