乐于分享
好东西不私藏

从卖软件到亲自交付:AI SaaS 如何走进服务现场?

从卖软件到亲自交付:AI SaaS 如何走进服务现场?

     最近看了 Y Combinator 的视频《How to Build an AI-Native Services Company》。YC 提出,未来一些重要的 AI 公司,可能不再只是向税务、审计、保险、法律、抵押贷款等行业出售软件,而是直接进入这些市场,为客户提供最终服务。   

这让我产生了一个更具体的问题:

一家已经在做 AI SaaS 的公司,怎样才能跨过那条线,开始亲自提供服务?   

从 SaaS 到服务,不是增加一个代办套餐

SaaS 的产品是软件。

客户购买软件,再由自己的员工使用它、作出判断、处理异常,并对最终结果负责。

AI 原生服务公司出售的则是结果。客户提交需求,公司内部使用 AI、软件和专业人员完成任务,并承担最终交付责任。

     原来卖给客户的软件,变成公司的内部生产系统;     原来使用软件的客户,只需要购买最终结果。   

所以,从 SaaS 进入服务,并不是在软件旁边增加一个“人工代办”选项,而是反转产品关系。

这一步看似简单,实际上意味着公司需要跨过几条完全不同的边界。

服务的产品,不是某个自动化环节,而是完整交付链条。

第一条边界:从完成环节,到完成整件事

AI SaaS 通常解决流程中的某个环节,例如读取材料、提取信息、生成文件或辅助判断。

但服务不能停在中间。

公司必须接管从信息收集、方案判断、任务执行、质量检查到最终交付的完整链条。

很多系统看上去已经完成了 90% 的工作,但剩下的 10% 可能分散在多个无法省略的环节中。真正的问题不是 AI 已经做了多少,而是公司能否把整件事情完成。

第二条边界:从提供建议,到承担判断

软件可以告诉用户:“系统建议这样处理,请自行确认。”

服务公司却不能把所有关键决定重新退回给客户。

它必须明确:哪些情况可以自动执行,哪些需要补充信息,哪些需要专业人员介入,以及哪些案例根本不应该接受。

这意味着公司需要建立案例分级、风险识别、结果检查和人工升级机制。标准案例自动化并不难,真正决定服务能否成立的,是异常案例会消耗多少人工,以及系统能不能提前识别它们。

第三条边界:从软件指标,到服务经济模型

SaaS 关心订阅收入、用户数量、续费率和软件毛利。

服务公司更需要关注每个案例用了多少人工时间、多少任务需要专家接管、返工率是多少,以及随着订单增加,人工成本是否同步增长。

所谓 AI 带来的经营杠杆,并不是简单地减少几个岗位,而是让单位服务所需要的人工持续下降。否则,公司表面上使用了大量 AI,实际上仍然只是把传统服务流程隐藏在软件后面。

服务化之后,建议重点追踪:

单件人工分钟数 · 专家接管率 · 首次交付通过率 · 返工率 · 周期时间 · 单件 COGS · 毛利趋势

第四条边界:从工具可靠,到结果负责

这是最难跨越的一条边界。

软件出现错误,用户通常还有机会检查;服务出现错误,责任首先属于服务提供者。

因此,从 SaaS 进入服务,真正需要验证的不是模型准确率是否足够高,而是:

     公司能否发现错误、阻止错误,并妥善处理自己无法完成的案例?   

高平均成功率不是终点;异常识别和升级能力才是责任边界。

95% 的自动化意味着什么?

在我们一个高监管、材料密集型项目的内部测试中,按照既定测试口径,系统已经可以在几个集中场景里达到约 95% 的任务成功率。

需要说明的是:这是特定项目、特定场景下的内部数据,不是行业基准,也不等同于端到端服务交付准确率。

越接近真实交付,越会发现剩下的部分才是关键。它们通常涉及材料冲突、信息缺失、规则解释、方案选择和风险判断。

这并不意味着系统必须达到 100% 自动化后才能提供服务。更重要的是,系统是否知道自己什么时候无法完成任务,并能准确地将案例升级给专业人员。

如果剩余异常可以被稳定识别、分类和处理,那么服务化就具备了基础。相反,如果系统不知道自己错了,即使平均准确率更高,也很难真正对结果负责。

一条更现实的转型路径

从 SaaS 进入服务,可能不应该一开始就覆盖完整行业。

更现实的路径,是选择一个足够狭窄的服务单元:结果明确、需求重复、输入相对可控、可以按件收费,而且异常情况能够被识别和升级。

然后只服务少量真实客户,记录每一次人工介入的原因:

哪些任务可以完全自动完成?

哪些需要补充信息?

哪些必须由专业人员判断?

人工究竟花了多少时间?

同一种异常是否会重复出现?

当这些经验不断被写回系统,原来的 SaaS 才会逐渐变成内部的服务生产平台。

跨越的不是技术,而是责任

YC 解释了为什么 AI 公司可以不再只卖软件,而是直接进入服务市场。

但对于已经在做 SaaS 的团队来说,真正困难的问题是:是否愿意从“帮助客户完成工作”,走向“由自己把工作完成”。

一旦开始对结果负责,原来的产品边界、团队分工、经营指标和责任体系都会发生变化。

公司也会因此从一个软件提供商,逐渐变成一种新的组织:

     对外,它仍然是一家服务公司;     对内,则是由 AI 承担标准生产,人类负责规则、风险、异常和最终责任。   

所以,从 SaaS 到 AI 原生服务公司,真正需要跨越的从来不只是技术门槛。

而是责任边界。

资料与核查说明

本文主要参考 Y Combinator 于 2026 年 6 月发布的《How to Build an AI-Native Services Company》,并结合实践作进一步分析。文中约 95% 的数据来自特定项目内部测试,公开来源无法独立验证。