Toast的餐厅全景图定义了上一个纵向SaaS时代的成功逻辑——绘制业务流程并软件化。然而，AI正在将竞争推向更深层：攻击那些从未被软件覆盖、却每日消耗大量人力的‘工作’本身。本文深度解析了从‘工作流地图’到‘劳动力地图’的战略跃迁，并揭示了AI切入垂直行业的三个关键楔子，为下一代伟大纵向软件公司指明了全新的战场。

旧时代的纵向软件画的是流程图。AI 时代的纵向软件，要画的是劳动力地图。这两件事看起来相似，实际上是完全不同的战略起点——因为它们攻击的是业务里两个不同的层：一个是已经被软件化的工作流，一个是从来没有被软件真正覆盖、却每天在消耗大量人力的那层工作。

Luke Sophinos 最近重新翻出了 Toast 招股说明书里的那张餐厅全景图。他说，那张图至今仍有冲击力——不是因为它列出了所有可以出售的模块，而是因为它揭示了一个伟大纵向软件公司都凭直觉理解的真相：一家企业不是一堆功能的集合，而是一个工作系统。然而他同时认为，这个练习对于今天已经不够了。

上层是整洁的运营平面图，下层是看不见的人工劳动层——旧软件只画了上层

Toast 那张地图

Toast 的 S-1 招股书里有一张图，展示了一家餐厅完整的运营现实：宾客动线、劳动力流转、订单流转、库存流转、支付流转、管理注意力流转。它覆盖了支付、外卖、薪资、预订、厨房、POS、网站、营销、忠诚度计划、餐饮活动。它告诉所有人，表面上看起来是个刷卡收款公司的 Toast，实际上是在用软件对餐厅这整个运营现实进行建模。

Toast S-1 招股书中的餐厅全景图：”Restaurants are Complex Businesses”

这正是上一个纵向 SaaS 时代的正确练习。把业务画出来，找到流程的边界，然后用软件把每一个流程模块化、可售卖化。这个逻辑催生了一批市值数十亿美元的垂直软件公司——Toast 餐厅、Procore 建筑、Veeva 生命科学、Mindbody 健身。它们都是从把业务流程画清楚开始的。

但流程图有一个根本性的局限：它画的是官方版本的业务，也就是工作流应该存在的样子。它没有描述让那些工作流保持运转所需要消耗的劳动力。

这不是 Toast 的问题，而是那整个时代所有纵向 SaaS 公司共同的局限。这个局限在那个时代是合理的——你只能建造那个时候技术能力允许建造的东西。但今天，延续这个局限不再是技术约束，而是想象力的边界。谁先突破了这个边界，谁就占据了一个在旧地图上根本找不到的位置。

工作流 vs 工作

Sophinos 做了一个区分，简洁但有力：工作流是干净的图表，工作是真实的混乱。

工作流是：订单走这里，预订走那里，库存滚进采购，薪资在周末结算，报告在后台生成。整洁，清晰，软件友好。

工作是什么？工作是店长读到一封愤怒的顾客邮件，然后决定要不要免单。工作是听完一段关于餐饮预订的语音留言，判断这件事是否紧急、是否真实、是否值得优先处理。工作是后台员工打开一张发票 PDF，核查数字是否合理，把它路由给对应负责人，然后清理那个本来不应该存在的差异。工作是某人发现一个预订变更将会连锁引发翻台率、人员排班和出餐时间的压力。工作是所有那些在软件被更新之前就已经发生的——解读、协调、升级、善后。

旧的纵向软件从来没有真正触及这一层。它被建造出来是为了存储人类判断的结果，而不是有意义地参与判断本身。

如果你仔细想想一家餐厅的日常，这个区分会变得非常具体。一名店长在任何一个工作日，可能要处理十几件软件从来没有记录、也没有帮助解决的事情：一个供应商突然说某种食材今天缺货，需要立即决定是否修改菜单；一位员工临时请假，需要判断是否影响今晚高峰的排班；一位常客投诉上次体验不好，需要权衡要不要主动致电。这些事情不会出现在任何流程图里，但它们真实地消耗了管理注意力，并且直接决定了顾客体验和运营质量。这就是为什么 Sophinos 说：管理者一直在充当人肉中间件——把现实世界里发生的事翻译成软件需要他们录入的格式。

不是缺陷，是技术极限

这不是设计上的错误，这是那个时代技术能力的上限。软件非常擅长在人们完成了困难部分之后捕捉记录。它不擅长理解混乱的输入、消除歧义，以及在工作被整洁结构化之前就把事情推进下去。旧软件的模型是：人先做判断，软件存结果。

AI 改变了这条边界。这是一条真正的结构性变化，不是功能升级。

当边界移动，整张地图就需要重画。如果上一代软件的地图问的是“这个行业的工作流是什么”，那么这一代软件的地图必须问的是“这个行业的工作是什么”——那些从来没有出现在流程图里、却每天在消耗着真实劳动力、真实时间、真实决策成本的事情。找到那些事情，就找到了真正的机会所在。

现在的模型可以处理凌乱的语音留言，可以读懂 PDF 发票里的不一致，可以在收到一封措辞模糊的投诉邮件时判断需要上报还是自动处理。软件第一次有可能真正参与判断过程——不只是在判断完成之后充当记录员。上一代软件覆盖的是已结构化的工作，下一代软件可以覆盖进入系统之前那个混乱的、人工消化的层。

新地图画到哪一层

如果今天重新画 Toast 那张图，你不会止步于模块。你会从模块出发，然后再往下一层，问：这些模块内部，劳动力究竟消耗在哪里？

AI 时代的餐厅运营地图：混乱工作流入 → AI 解读层 → 自动处理 + 例外升级队列

这个新的绘图练习需要三个问题：一个行业的劳动力地图，就从这三个问题的回答里生长出来。

Sophinos 把这个地图称为“Work Map”——工作地图，以区别于旧时代的“Workflow Map”流程地图。两张图看起来很像，都在画同一家企业，都在描述同一组业务域。但流程地图到此为止，工作地图继续往下：在餐饮预订这个域里，有多少工作是靠人工协调才能完成的？哪些场景下电话比系统快？哪些问题供应商从来不在系统里提，而是打电话解决？哪些例外情况每周必然出现，但每次都要花一名店长半小时去处理？这些问题的答案，才是 AI 真正能切入的地方，也是下一家伟大的垂直软件公司的起点。

工作以混乱的形式进入，被某样东西解读，被某样东西处理，只有真正的例外情况才会升级到人工决策。这和旧的“填表保存数据库”架构是完全不同的设计逻辑。

三个楔入点

一旦你用劳动力地图而不是流程图来观察一个垂直行业，下一个战略问题就会变得清晰：用什么楔子切入？Sophinos 归纳出三种在不同行业里反复出现的进入策略，它们都指向同一个位置——工作流和记录系统之间的那层人工劳动力。在旧时代的 SaaS 里，这层劳动力是个给定条件，软件绕着它设计；在 AI 时代，它是最主要的攻击目标。

三种已经在起效的 AI 楔入策略：AI 服务、行业专属 GPT、系统记录之上的 Agent

楔入点一：AI 服务。最务实、最不光鲜，可能也是最有力量的切入方式。许多行业里，软件栈已经存在，但大量经济上重要的工作仍然由坐在软件之上的人来完成，因为软件从来没有好到足以吸收那层劳动力。医疗报销公司 Camber 是个好例子：医疗报销历来需要大量专业人力叠加在碎片化系统和混乱工作流之上——理赔被提交、被拒绝、被更正、被申诉、被重新提交，整个报销周期管理行业由此而生。Camber 把一个劳动密集型的报销问题变成了一个软件问题，不是更漂亮的账单界面，而是真正吸收了那层曾经需要人来做的工作。回到餐厅场景：餐饮承接、宾客投诉处理、应付账款对账、薪资例外处理、供应商沟通——这些都是企业在悄悄雇人绕过软件从来没完全解决的问题的地方。

楔入点二：行业专属 GPT。Sophinos 认为这是最有说服力的楔子。行业专属 GPT 不是”带了一些专业术语的通用 AI”，而是对某个领域的语言、逻辑、边界案例和判断模式理解深到足以进行领域内部推理的智能层。医疗 AI 公司 OpenEvidence 是最清晰的案例——偷懒的描述是”医生版的 ChatGPT”，但这错过了重点。OpenEvidence 正在成为一个植根于临床决策现实的医学智能层，它不只是帮医生更快地搜索，而是帮助他们在一个非常具体的操作环境中进行思考。餐厅版本的行业专属 GPT 会是什么样的？它不会只是回答菜单问题或写营销邮件，它会理解预订节奏、翻台逻辑、厨房瓶颈、人力约束、菜单结构和宾客恢复之间的关联。它不是总结业务，而是帮你推理业务。

楔入点三：系统记录之上的 Agent。这个策略承认了一个创始人忽视往往会付出代价的事实：在很多垂直市场里，现有系统仍然是数据重力所在的地方。它可能臃肿、被人厌恶、界面丑陋，但它是嵌入的、被足够信任的、记录官方落地的地方。因此最聪明的切入方式不是第一天就替换它，而是以它为据点——读取它、写回它、让它更有用、让它更面向行动、剥离其周围工作流里的劳动力。Datagrid 就是这个逻辑：坐在现有系统之上，跨系统编排任务，把静态记录变成更主动的存在。在餐厅里，这意味着不是第一步就替换 Toast 或预订系统，而是问：当 AI 坐在已有系统之上时，能做什么？它能把运营噪音翻译成清晰的行动吗？它能只浮现出真正重要的例外情况吗？

AI 驱动的餐厅新操作地图：AI 解读层、AI 服务（Camber）、行业专属 GPT（OpenEvidence）、系统记录之上的 Agent（Datagrid）

三个楔子不互斥

这三个楔入点不是互相排斥的。Sophinos 认为，最有趣的公司将随时间推移穿越所有三个阶段。它们可能从 AI 服务起步，因为那里有劳动力预算和紧迫性；然后深入行业专属 GPT，因为那是真正智能优势的建立之处；最终坐在、整合进、或者逐步吸收系统记录，因为那是工作流重力和长期防御性所在。

这比旧的垂直 SaaS 剧本里那种“简单替换现有系统”的幻想更真实。没有一家 AI 公司是靠强行替换根深蒂固的记录系统起来的，它们靠的是找到那个最燃烧的人工劳动层，先在那里赢得信任，再随着数据和关系的积累向外延伸。

这三个楔子的演进路径，也对应着不同阶段的商业逻辑。AI 服务阶段的商业模式通常是按结果付费或按用量计费，切入快、验证快，但天花板相对清晰。行业专属 GPT 阶段开始建立知识壁垒，模型越用越好，但需要时间让行业买单。系统记录之上的 Agent 阶段则是最典型的“先整合后替代”路线——从客户已经依赖的数据入口切入，以低摩擦的方式嵌入日常工作流，在证明价值之后再决定向前扩张多远。不是每一家公司都需要走完这三个阶段，但了解这三个选项，至少能让你在选择起点时做出更有意识的决策。

下一代纵向软件

Toast 那张地图的伟大之处，是它给了创始人和运营者一种看待餐厅的方式——不是一堆断开的工具，而是一个活的系统。这个视角本身就是一种竞争优势：能把行业看成系统的人，比只能看到功能模块的人，会找到更大的机会。这个教训今天依然完全成立，只是需要更新地图所描绘的那一层现实。

变化的不是画地图这件事的必要性，而是地图必须画到的那一层。你仍然需要高层视角，仍然需要理解主要业务域：点单、劳动力、厨房运营、预订、支付、宾客互动、库存、报告。但然后你必须继续往下一层，问：让这些工作流保持运转，需要消耗多少人工？这些劳动力在哪里进入、在哪里判断、在哪里行动？旧软件一直跳过了这一层，AI 现在可以系统性地攻击这一层。

那些做得最好的创始人，不会在旧的纵向软件上堆几个 AI 功能。他们会建造这个垂直行业全新的操作层。因为下一代伟大的纵向公司不只是记录业务——它们会越来越多地帮助运营业务本身。

这是一个战略问题，不是产品功能问题。在 AI SaaS 时代，竞争优势不在于你比竞争对手多了哪几个模块，而在于你是否已经把业务里那个真正消耗劳动力的层找到了，以及你选择了哪个楔子切进去。

上一代垂直 SaaS 公司的节奏是：进入一个品类，横向扩张，靠数据整合打建护城河，最终成为这个行业的操作系统。这个路径花了十年以上。AI 时代的路径可能更短，但也更需要从第一天就想清楚：你正在攻击的是工作流本身，还是让工作流得以运转的那层隐性劳动力？前者在 SaaS 时代已经被做了很多遍，后者是一块全新的战场，而且进入门槛正在以极快的速度从技术问题变成产品理解问题——谁更懂这个行业里那些从来没被软件覆盖的角落，谁就有先手。

— 原文：@lukesophinos on X · Luke Sophinos，Vertical SaaS Group 创始人