过去十年,SaaS 厂商与客户之间一直存在一条看不见的边界:客户提需求,厂商排进需求池,等排期,等上线,等客户流失。这是 SaaS 经济学的基本结构,也是产品团队的长期痛点。2026 年 YC 夏季批次的 Vendo 与同期出现的 Gigacatalyst,把这条边界直接撕开,让客户用自己的语言,在厂商产品内部自己造功能。 一、SaaS 的需求池困局 几乎所有做 SaaS 的团队,都被同一类问题压
过去十年,SaaS 厂商与客户之间一直存在一条看不见的边界:客户提需求,厂商排进需求池,等排期,等上线,等客户流失。这是 SaaS 经济学的基本结构,也是产品团队的长期痛点。2026 年 YC 夏季批次的 Vendo 与同期出现的 Gigacatalyst,把这条边界直接撕开,让客户用自己的语言,在厂商产品内部自己造功能。
一、SaaS 的需求池困局
几乎所有做 SaaS 的团队,都被同一类问题压着:feature backlog 永远清不完。每一个客户的业务都不一样,但你不可能为一千个客户做一千个版本。多数请求在需求池里躺几个月,真正等不到上线就默默流失的,恰好是那些最在意"你的产品能不能为我多做一件事"的客户。
AI 浪潮出现后,这个矛盾没有变好,反而被放大。所有人都知道产品应该 agent-native,但造一个真正能干的 agent——能调用接口、能生成界面、能记忆上下文、能始终待在你的安全护栏里——背后是大量工程时间和持续维护成本。现实是大多数团队只塞了个聊天机器人挂在屏幕角落,管它叫 AI。客户不要聊天机器人,客户要的是"你的产品能不能恰好做我需要的那一件事"。
二、Vendo 怎么解这道题
Vendo 给出的答案是:把 agent 直接装进你的产品内部,让客户自己造功能。它的安装方式只有一条命令;装上之后,系统会自动读取你的主题、组件库、API 表层。从此客户用自然语言描述"我想要什么",Vendo 在你的应用里实时把它造出来:
- 把产品按客户自己的工作流做深度个性化,沿用你自己的设计系统。
- 搭建按计划运行的自动化,在你的产品里真正执行动作。
- 接入数百个外部工具,让工作流不停在你应用的边界。
所有这一切都跑在沙箱里、沿用你已有的安全护栏。agent 拥有的权限始终等同于客户自己的权限,它做不到客户本身做不到的事,你的源代码也不会被触碰。
厂商可以把自己已有的 agent 接进来,也可以直接用 Vendo 自带的、生产可用的 agent——自带动作调用、界面生成、知识库。开源,一条命令安装,直接推送给终端用户使用。
创始团队来自 Stanford 和 Berkeley,创始人 Nour Zahzah 之前为零售商做过店内 AI 购物助理,CTO Yousef Helal 曾在 Apple 做过 FPGA 基础设施、在 AMD 做过芯片设计。这是一支把"零售一线 + 大厂底层"两段经验缝合在一起的工程化团队。
三、同方向的另一条路:Gigacatalyst
在 Vendo 之外,Gigacatalyst(2026 年 5 月登陆 Hacker News,获 61 分、27 条讨论)走了几乎相同的命题:把嵌入式 AI 构建器塞进 SaaS,让客户自己在平台上造功能。两条路径在产品意图上高度同源,但工程落地完全不同。
Gigacatalyst 的真实运行数据:已上线 5 家企业,2000+ 日活用户,客户累计造出 900+ 应用,30 天留存率 70%。它的工程栈被切成四层:
- Agentic API 发现:agent 自动遍历你的应用,解析所有 endpoint、查询参数、请求/响应结构、样本数据,搭出基底层。
- 生成与校验:用户描述需求后,AI 生成应用。中间嵌入多层校验:静态检查、运行时错误分析、LLM-as-a-judge。
- 沙箱与编译:自研的编译与沙箱框架,目的是在速度与成本上做到极致——用户可以在秒级与生成的应用交互。
- 代理层:所有 API 走一层代理,统一处理鉴权、租户隔离、限速。agent 能访问什么、被记了什么日志、谁在观测、版本如何管控,全部在这一层收敛。
Gigacatalyst 创始人在 HN 回复中提了一个关键观察:客户自建应用的 80% 是新的前端功能,后端能力只在极严密的护栏下被放开。这与 Vendo 的"agent 权限始终不超出用户自身权限"是同一条设计哲学的两个侧面——把高风险操作锁在受控范围内,把低风险操作彻底开放。
四、为什么这是 SaaS 的新契约
Vendo 与 Gigacatalyst 同时出现,意味着 SaaS 与客户的关系正在被改写。旧的契约是:厂商定义功能,客户在功能列表里选。新的契约是:厂商提供平台,客户在平台上自建。
这条新契约的底层假设变了。当开发成本趋近于零,过去必须靠"插件审核 + 第三方扩展"才能实现的客户定制,现在可以直接交给客户自己写。Gigacatalyst 创始人在 HN 讨论中直白地说:SaaS 的未来看起来更像一个"系统记录"(system of record),AI 在它之上根据客户当下需要,按需提供。
对厂商来说,这套契约意味着三件事。
第一,产品团队不再陷在需求池里。客户能自己造的功能,根本不需要排进产品团队的迭代节奏。Gigacatalyst 的真实案例里,有个客户用平台搭了一个"维修工单优先级矩阵":"步入式冷柜不制冷"自动路由为 CRITICAL,"餐厅灯闪烁"自动路由为 LOW。过去这种业务定制只能靠厂商二次开发,现在客户当周搞定。
第二,产品需要重新设计"被扩展"的接口。Vendo 的做法是单命令安装后自动读取你的主题、组件、API;Gigacatalyst 的做法是 agent 自动遍历并解析你的 endpoint、查询参数、响应结构——殊途同归,前提都是产品本身的 API 与组件必须稳定且文档化。一个没有清晰 API 表层的 SaaS,装上这类 agent 后只会暴露自己的混乱。
第三,护栏的边界比功能更重要。Vendo 的所有动作都在沙箱内、沿用既有安全护栏;Gigacatalyst 在代理层统一处理鉴权、租户隔离、限速、版本管理。两家都在用同一条工程纪律:让客户自建,但不让他们能越权。Gigacatalyst 的回复者里,技术债是被反复追问的问题——客户不理解底层数据模型,不理解鉴权,怎么办?Gigacatalyst 的回答是:每个功能都是一个独立的、被沙箱隔离的、单独版本控制的"app";不推送到生产,不并入主仓库;API 版本被代理层钉住,即使底层契约变了,历史 app 仍能运行;鉴权沿用 SaaS 自身的 RBAC 与 token。
五、对国内 SaaS 厂商的现实意义
国内 SaaS 市场长期被"大客户定制"和"小客户标准化"两端拉扯:大客户要的是贴身定制,小客户要的是开箱即用。这两端在过去互斥,做定制就难以规模化,做标准就难以攻大单。Vendo 与 Gigacatalyst 给出的范式,把"定制"这一动作的下放给了客户自己——厂商提供平台,客户在平台上自建。
这套范式落地的三个前置条件:
- API 与组件必须文档化、可发现。没有稳定 API 的 SaaS,装上嵌入式 agent 只会加速自身的混乱。
- 护栏必须工程化,不是文档化。权限边界、租户隔离、限速、版本管理,要落在代理层与沙箱里,不能停在白皮书里。
- 团队必须接受"客户造的东西会丑"。Gigacatalyst 创始人在 HN 里说,客户自建的应用"80% 是新的前端功能"——这部分代码永远不可能像产品团队自己写的那样精致。如果团队对此 0 容忍,这套范式就无法落地。
Vendo 与 Gigacatalyst 都是开源的。Vendo 单命令安装,Gigacatalyst 公开了 demo(输入你的 SaaS API URL 或首页就能开始 prompt)。对于国内正在做 SaaS 平台化的团队,这不再是"该不该做"的判断题,而是"什么时候接入"的执行题——客户已经在别处看到了这种能力,等不到你慢慢做需求池。
六、结尾
SaaS 平台层正在出现新契约:厂商提供底层能力与安全护栏,客户在产品内部自建功能。Vendo(YC S26)与 Gigacatalyst 用不同的工程路径同时证明这件事可行。剩下的问题是,国内哪一家 SaaS 厂商会率先把自己的产品设计成"可被嵌入式 agent 扩展"的形态。