垂直SaaS与AI原生公司正围绕任务闭环控制权展开竞争。本文从B端记录系统向行动系统的转变、C端上下文飞轮的构建，以及Genspark的混合路径切入，拆解AI产品壁垒的真正来源：有效上下文、工作流位置、执行权限与信任治理的乘积。

最近入职一家垂直行业 SaaS 公司之后，我开始从企业内部观察 AI 产品化

公司原来的产品已经承载了客户、流程和业务数据，也形成了相对稳定的用户习惯。现在要做的，是让 AI 进入这些系统，理解用户正在处理的工作，并把原来需要人推动的环节继续向前推进

这让我最先想到一个判断：垂直 SaaS 公司拥有多年积累的业务数据，理应比新进入者更容易建立 AI 产品壁垒

同期，我看到了 Founder Park 关于 Genspark 和 GenOffice 的两篇文章。它们呈现了另一条路径：先把产品快速做出来，尽早交给市场，让用户带着真实任务进入产品，再用使用上下文和反馈不断修正

2026 年，AI 产品的竞争正在从功能竞争转向任务闭环控制权的竞争

谁能持续获得合法且相关的上下文，把上下文转化为行动，看见行动结果，再用结果改善下一次判断，谁才可能形成长期壁垒

01 先拆掉两个误区：B 端靠数据，C 端靠速度

第一个误区，是把历史数据直接等同于 B 端壁垒

历史记录只有进入当前任务，才能产生产品价值。如果数据分散在不同系统里，业务口径相互冲突，缺少结果标签，或者厂商没有获得对应的使用授权，数据越多只会让治理成本越高

第二个误区，是把发布速度直接等同于 C 端壁垒

快速发布只能帮助团队更早接触真实用户。一次更新如果没有明确假设，也没有观察留存、修改、任务结果和错误的方法，只会增加版本记录，不会自动增加产品认知

麦肯锡 2025 年的调查显示，88％ 的受访企业已经在至少一个职能中经常使用 AI，但接近三分之二还没有进入组织级规模化。在任何一个具体职能中，规模化 Agent 的企业占比都不超过 10％，工作流重构则是与较高价值表现关联最强的因素之一

消费端也存在类似问题。Menlo Ventures 对美国成年用户的调查显示，91％ 的 AI 用户面对新任务时，会先尝试自己熟悉的通用助手。新产品发布得再快，如果没有明显优于默认入口的结果，也很难获得持续使用

02 B 端变化：从记录系统走向行动系统

传统 SaaS 最核心的能力，是把分散在表格、电话和个人经验里的业务变成结构化记录。它知道客户是谁、工单到了哪一步、谁修改过一条数据，但下一步做什么，通常还要人判断和推动

AI 正在改变 B 端产品的基本单元。用户不再只需要系统告诉他发生了什么，还希望系统理解当前任务、找到相关信息、执行下一步动作，并在结果偏离时提醒或修正

传统 SaaS 是记录系统，AI SaaS 正在向行动系统移动

垂直 SaaS 更难被复制的优势，不是数据库里存了多少旧记录，而是它占据了业务发生的位置。它理解工单、设备、审批和结算的行业语义，知道当前状态，也拥有把判断写回流程的权限

ServiceTitan 在 2025 年发布的 Atlas 可以运行报表、派遣技师并根据需求变化调整营销投入，需要同时结合工单量、技师状态、预约窗口和营销归因。Veeva 的 AI Agents 则直接在生命科学行业的数据、文档和工作流中运行，同时遵循原有权限和审计轨迹

但存量 SaaS 并没有稳操胜券。Abridge 进入临床场景的公开路径，不是先证明自己拥有更多医院历史数据，而是从当前医患对话切入，实时生成结构化、可审计的临床记录，再把结果返回 Epic 的临床工作流

这意味着 AI 原生公司仍然可以从现有 SaaS 没有解决好的高成本任务切入。历史数据不是进入垂直行业的唯一入口，离任务更近的实时上下文同样可以成为入口

对正在推进 AI 产品化的垂直 SaaS 来说，第一张需求清单不该是接入多少张数据表，而是 AI 要推进哪个任务，在什么时间需要哪些上下文，能够执行到哪一步，谁负责审批，结果如何回到系统

03 C 端变化：从快速发布走向上下文飞轮

大多数新 C 端 AI 产品在用户第一次打开时，几乎没有可用的个人上下文。它不知道用户过去做过什么、偏好什么，也不知道这一次任务和之前的任务有什么关系

B 端通过系统部署获得工作流位置，C 端则要靠一次次有效使用，逐步换取用户的上下文

快速发布的真正价值，是缩短产品学习周期。产品越早进入真实场景，团队就越早知道用户会在什么情况下使用、哪些结果值得保留、哪些信息愿意授权

OpenAI 在 2025 年上线学习模式时，选择先通过自定义系统指令实现。官方解释是，这种方式可以更快地从真实学生反馈中学习和调整，等找到更有效的行为后，再把它融入核心模型

上下文飞轮需要完成一条完整链路：真实任务带来经授权的上下文，上下文改善结果，结果促使用户重复使用，新的使用又带来更完整且可纠错的上下文

Gemini 的个性化能力提供了一个参照。Google 在 2025 年开始允许用户主动授权 Gemini 使用搜索历史，并展示回答使用了哪些数据源；到 2026 年 7 月，Gemini 又增加了保存个人形象和连接更多应用的能力

但拥有上下文不等于形成壁垒。低频场景无法持续积累信息，授权成本过高会阻止用户连接数据，错误偏好无法纠正会让个性化越来越差；当同一份数据也能授权给其他助手，真正难复制的是上下文结构、调用准确度和用户信任

04 Genspark：B 端和 C 端正在互相借用对方的优势

单看发布方式，GenOffice 很像一个典型的 C 端产品。它面向 Windows 和 Mac 提供本地客户端，覆盖文档、表格、幻灯片和 PDF，下载和基础使用免费，没有广告，产品主体采用开源许可

它还处于 Alpha 阶段，官方直接邀请用户进入社区提供反馈。先把第一版交给市场，再根据真实文件和真实任务补齐能力，这与 C 端产品的学习方式一致

但 GenOffice 不是一个纯 C 端产品，而是个人入口加企业扩展的混合型产品

免费、无广告、开源和熟悉的 Office 界面降低了第一次尝试的成本，这是 C 端分发逻辑。AI 直接进入文档区块、表格状态、幻灯片和 PDF 的编辑过程，目标是交付能够继续修改和使用的文件，这是工作流逻辑

GenOffice 的开源主体采用 Apache 2.0，预留的企业模块使用单独许可。基础工具可以服务个人用户，团队协作、企业治理和更高阶 Agent 能力则保留了商业化空间

Founder Park 的两篇文章都提到，一名工程师用一周完成了 GenOffice Alpha，发布前几天每天迭代十几次。这些数字来自 Genspark 的披露，两篇文章又来自同一场活动和同一家媒体；第一版也复用了已有的文档生成、Agent、模型服务和开源组件，不能理解为一周从零造出完整 Office

这个案例更值得关注的，不是第一版做得有多快，而是它如何把低成本开发、用户反馈和工作入口连接起来。B 端正在借用 C 端的产品学习方式，C 端则开始借用 B 端的工作流和结果交付思维

进入办公界面，也不等于自动获得用户的工作上下文。本地文件和编辑行为能否被使用，仍然取决于用户授权、数据用途和隐私边界

05 共同的竞争单元：谁控制了任务闭环

前面的案例产品形态不同，争夺的却是同一个位置：用户完成一项任务时，主要通过谁来理解问题、调用信息、执行动作和确认结果

这就是任务闭环控制权

控制权不是要求产品独占用户数据，也不是让 AI 替用户做出所有决定。它指的是产品能够持续参与任务从开始到结束的关键步骤，并成为连接上下文、动作与结果的主要协调者

AI 产品壁垒＝有效上下文 × 工作流位置 × 执行权限 × 可观测结果 × 信任与治理

这不是用来计算分数的数学公式，而是一组相互依赖的产品条件。只有上下文，没有执行权限，产品只能给建议；能够执行，却看不见结果，产品无法判断动作是否有效；拥有数据和权限，却得不到信任，用户不会把重要任务交给它

以客户报修为例，一个 AI 如果只能根据历史工单生成回复，它控制的仍然只是问答环节。完整闭环需要继续读取设备记录和当前状态，判断优先级，匹配可用技师，在权限范围内完成派工，并在服务结束后看到维修结果、客户反馈和费用变化

闭环控制权也不等于追求百分之百自动化。产品应该根据任务风险采用渐进式授权：先提供建议，再生成草稿，接着在用户确认后执行，最后只在预设金额、对象、时间和风险范围内自动行动

医疗诊断、资金支付和合规审批不应该因为模型能力提高，就取消必要的人类责任。产品需要让用户知道 AI 使用了什么信息、准备执行什么动作，并支持人工接管、撤回和审计

模型可以被替换，单点功能也容易被复制。已经嵌入真实任务的上下文结构、权限设计、异常处理、结果反馈和用户信任，需要在长期使用中一起建立

06 2026 年真正值得关注的机会

判断 AI 产品机会，不应该从模型新增了什么能力开始，而应该先找到一个高价值任务，看它今天在哪里中断

对垂直 SaaS 公司，最直接的机会是把现有系统里的建议变成行动。产品已经拥有业务对象、实时状态和用户权限，只需要找到仍由人手动衔接的关键步骤，把发现问题、准备方案、发起审批、执行动作和记录结果连接起来

对 AI 原生公司，机会存在于现有 SaaS 没有完整覆盖的实时任务。电话、现场照片、合同、录音和即时沟通里仍有大量未被结构化的上下文，新产品可以从一个高成本、重复发生的任务切入，再把结果写回原有系统

企业端还有一个容易被低估的位置：与具体工作流绑定的权限和异常治理。当 Agent 能够派工、改价格、提交审批和操作业务数据时，人工确认、异常回滚、来源追溯和责任记录本身就是产品

C 端更现实的机会，是围绕一个重复发生的长期任务建立个人上下文。学习、内容创作、日常信息处理和长期计划都可能产生持续的进度、偏好、修改和结果，让产品逐步减少下一次输入成本

另一个机会在建议之后的执行环节。产品可以先准备完整方案，让用户确认关键条件，再完成预约、购买、日程同步或表单提交，并继续处理取消、变更和提醒

B 端与 C 端之间还存在一条混合路径：个人用户决定产品是否好用，团队和企业为协作、权限、合规和管理能力付费。文档、设计、销售准备、研究和知识管理产品都可能沿这条路径发展

相反，通用的企业知识问答、没有即时收益的长期记忆，以及责任和异常处理都不清楚的全自动 Agent，很难单独形成长期壁垒

07 给产品经理的判断框架

面对一个 AI 需求，产品经理可以按照八个问题依次检查。它们不是加分项，而是任务闭环必须经过的八道关口

1．用户要完成的任务是什么

不要把使用 AI 当成任务，也不要把生成内容当成任务结果。用户不是要生成客户总结，而是要确定下一步跟进动作

2．这个任务今天怎样完成

还原没有 AI 时的完整过程，找到最耗时、最容易出错、最依赖经验的环节。如果团队说不清当前流程，就很难判断 AI 解决了什么问题

3．AI 需要哪些最小上下文

明确哪些信息与当前判断直接相关，是否足够新，是否具有统一语义，是否获得合法授权。减少无关上下文可以同时降低成本、错误和隐私风险

4．产品能够把任务推进到哪一步

AI 可以提供建议、生成草稿、发起审批、等待确认后执行，也可以在明确边界内自动行动。只能生成内容的需求更接近辅助功能，能够调用工具并写回系统才开始接近 Agent

5．任务结果能否被观察

系统需要知道建议是否被采用、动作是否成功、业务结果是否变化。把生成完成当成任务完成，会让产品高估自己的价值

6．错误发生后能否恢复

产品需要提前定义错误成本和恢复方式。风险越高，人工确认越应该靠近执行动作，撤回、回滚和人工接管不应该成为上线后的补丁

7．这次使用能否改善下一次任务

用户的修改、拒绝和最终选择，能否成为下一次任务的有效上下文。如果每次都要重新解释背景，产品只是一个调用模型的界面

8．为什么不用通用助手或原有 SaaS

新产品至少要在一个维度上形成明显差异：更接近任务现场，掌握更相关的上下文，能够执行更多步骤，结果更容易验证，或者在隐私和责任边界上更值得信任

前两个问题说不清，这只是技术想法；上下文和执行问题没有解决，它更适合被定义为 AI 功能；结果和风险问题没有解决，它只能进入小范围试点；无法改善下一次任务，产品能够创造价值，但还没有形成积累效应

真正进入开发前，产品指标也需要从功能使用转向任务结果。除了使用人数和调用次数，团队还应该观察任务完成率、完成时间、人工修改比例、异常撤回比例，以及第二次完成同类任务时是否减少了输入

对产品经理来说，AI 产品设计的起点不是选择模型，而是画出一项任务从发生到结束的完整路径。模型、数据、交互和 Agent 都只是推进这条路径的手段

回到任务本身

一家垂直行业 SaaS 公司，让我第一次从企业内部观察一款成熟产品如何推进 AI 化。模型怎么选、数据怎么接、功能从哪里开始，最后都会回到同一个问题：AI 究竟能不能把用户的工作向前推进

现在再看，数据和速度都只是起点。数据需要进入真实任务，速度需要转化为有效学习，产品还要获得合适的权限、完成具体动作、看见最终结果，并在错误发生时把控制权交还给用户

2026 年，B 端和 C 端 AI 产品的边界正在变得模糊。B 端从业务系统和组织流程进入，C 端从使用频率和个人信任进入，两条路径最终都在争夺任务闭环中的关键位置

真正值得长期使用的 AI 产品，不是展示能力最多的产品。它应该让用户少解释一次背景，少切换一个系统，少返工一次结果，同时清楚知道 AI 使用了什么信息、完成了什么动作

愿我们永远对世界保持好奇