Rebuilding IT From the Ground Up for the AI Age: Serval's Jake Stauch

你知道，我觉得人们对自己工作会是什么样，总会有一种理想化的想象，而这和工作实际的样子之间始终存在差距。对，我觉得这对任何职业都成立。人会把它理想化，孩子尤其如此，对吧？他们会说自己想当 firefighter、astronaut，会去想象那份工作是什么样子。可等你真的进入那份工作，你就会意识到，哦，原来这里面其实有很多我并不喜欢的东西。

而我们想成为那个真正缩小这道鸿沟的工具，让你以为自己的工作会是什么样，和你的工作实际是什么样之间的差距变小。

好的。我现在和 Serval 的 founder（创始人）兼 CEO 在一起，Jake，欢迎来到节目。

非常感谢，很高兴来到这里。

好，我们先从一个高层次的问题开始。你们正在打造某种下一代的 ServiceNow，可以说是 AI native（AI 原生）的 ServiceNow。没错。为什么这个世界需要一个 AI native 的 ServiceNow？

对，员工在工作中需要帮助。这基本上就是我们的核心想法：我们是一个员工支持平台。技术上的术语叫 enterprise service management，但它真正的意思，其实就是在工作中获得帮助。而在工作中获得帮助的理想方式是：你提出一个请求，然后立刻、自动地得到结果。你不需要等着某个人去跟进一个 ticket，再把这个 ticket 分配给另一个人。

你就是立刻获得帮助。要做到这一点，就需要某种自动化支持，而这种自动化最适合用 AI 来构建。所以我们是从 first principles（第一性原理）来思考这件事的：我们该如何支持员工？就是把所有请求都自动化。

那你要如何把所有这些请求自动化？AI 的确是一个非常好的工具，能够把这种自动化带给员工。

太棒了。我们来把这件事再展开说说。我记得很多年前，我们第一次见到 Fred Luddy——ServiceNow 的创始人——大概是在 2007、2008 年那个时间段。当时，人们觉得 ServiceNow 非常惊艳，因为它相比 Peregrine 和 Remedy 带来了这种大台阶式的跃迁。而他们真正做对的一点是：把 enterprise software（企业软件）这个抽象层理解为，本质上就是建立在 database（数据库）之上的 workflows（工作流），对吧？

所以他们等于是在 database（数据库）之上构建了一个相当灵活的 workflow（工作流）配置引擎。在当时那非常了不起，IT 人员也很喜欢，他们就此一路飞奔向前。你刚才表达的意思，我听下来是：这还不够。有了 AI，现在可以做新一代的 automation（自动化）了。你能不能再多讲讲 ServiceNow 当年构建的东西，以及你们构建的东西，把两者并排比较一下——这一次到底真正不同在哪里？

他们当时的方向是对的。我们也同样是在 database（数据库）之上构建 workflows（工作流），而这确实是正确的 abstraction（抽象），也是正确的 primitives（基础原语）。问题在于，他们的 workflows 和 databases 需要大量人工投入来构建和维护，所以搭建这些 workflows 往往需要专门的开发资源来完成。听起来这似乎也还好：你投入这些资源，最后就能得到一个很漂亮的 automation（自动化）结果，但这通常需要几周到几个月的时间。

而在一个业务流程变化非常快的时代，等你把那个 workflow（工作流）真正落地时，你的需求可能已经变了、已经往前走了，你又想要另一个不同的 workflow。于是你的 automation（自动化）就总是落后于你真正想达到的状态。而这种情况现在比以往任何时候都更严重。database（数据库）也是一样。如果你需要手动更新那些条目，检查你的 IT assets（IT 资产），并确保它们在这些系统中始终是最新的，那你就得请 consultants（顾问）或者内部开发人员来做更新，这会变得非常、非常痛苦。

我们采取了一种独特的方法：保留这些 primitives（基础原语），也就是建立在 database（数据库）之上的 workflows（工作流），但让你可以用 AI 来构建 workflows，并用 AI 来更新 databases。我们实现这一点的方式，是这个 cogen engine：你只需要描述自己想要的 workflow，包括所有不同的步骤、权限、审批和逻辑，我们就把你的 natural language（自然语言）描述转成 code（代码）。这样一来，你的 workflow 几乎会瞬间出现，开发这些 workflows 基本不需要时间。我们的 databases 也是同样的思路。

你可以准确描述你想从哪些 sources（数据源）提取哪些数据，我们的系统会实际生成 code（代码）去抓取这些数据，并在无需你进行任何人工干预的情况下持续保持更新。

我记得几个月前你说过一件事。那是我们刚开始彼此了解时，你说过的一句话，真的一下子激起了我的兴趣。大意是：如果你真想推动 enterprise automation（企业自动化），那你就必须让构建 automation（自动化）的过程，至少和被自动化的 workflow（工作流）一样简单，甚至更简单。

完全正确。

你现在还相信这一点吗？这现在还成立吗？

我现在仍然相信，而这个洞察其实来自于把自己放在 IT 或其他职能部门员工的位置上：当你面前有一个任务，比如有人让你帮他重置密码，你有两个选择。你可以进入 Google Workspace，找到那个用户，点击一个写着 reset password 的按钮。或者你可以打开一个 workflow builder（工作流构建器），拖拽 trigger（触发器）和 response（响应），然后搭建出这个自定义 workflow（工作流）。当你面对这样的选择时，你大概率只会去重置密码。你会选择手动去做。

但如果构建自动化实际上更容易，你就会去做自动化，因为说到底，为什么不呢？我觉得关键就在这里。人们在当下必须做这个决定，而你希望这个决定变得非常、非常容易——让他们轻松选择 automation（自动化），而不是选择手动步骤。

那会不会存在一种情况，就是事情简单到不值得自动化？比如，人们会谈到 vibe coding，以及它带来的那些乱七八糟的东西——那有没有所谓的 slop automation（粗糙自动化）这种现象？

有，确实有。这是真实存在的，而且我们不得不围绕这个问题构建一些非常有意思的东西。因为是的，当你让自动化变得如此容易时，有人这周可能就会做出第 20 个 password reset workflow（密码重置工作流）。而它本质上和前面那 19 个差不多，现在你就会有一堆重复的 workflow（工作流），AI 也会搞不清到底该运行哪一个。

对，那你们是怎么管理这个问题的？

我们在 Serval 之上基本构建了一个新的 agent（智能体），对此我们非常兴奋。它对你以前构建过的所有 workflow（工作流）都具备完整的上下文感知能力，知道它们是怎么工作的、会做什么。所以当你说：“Hey，我想要一个执行 X、Y 和 Z 的 workflow（工作流）”时，它会说：“Hey，其实你已经有 19 个能做这件事了。我可以修改其中一个，但我觉得你应该这样做：实际上你应该先删掉其中 10 个，把剩下这 9 个分到不同类别里，再加上这些 approval steps（审批步骤）。” 于是它会真正带着你梳理整个系统，像一个熟悉我们产品的助手一样，帮助你把 business requirements（业务需求）转换成真正的产品实现。

说到产品，你是个很典型的 product guy（产品人），而且我们从各种渠道一直听到别人对你的评价：你非常以客户为中心，真的很善于倾听客户、弄清他们需要什么。你有没有一个你会依赖的 North Star metric（北极星指标），能直接告诉你产品是不是变得更好了、更有用了？还是说更多是你收集各种 anecdotes（个案反馈），把它们综合起来，然后形成一种直觉判断？比如，有没有哪个数字是你一眼就可以拿来看的？

我觉得是后者。比如，我会尽量深度嵌入客户之中。就像完全沉浸式那样，我在每一个客户的 Slack channel 里。对。我想我们大多数客户每天都会在那个 channel 里收到我发的 Slack 消息。

哇。这确实是一个很大的，也许——而且只是

先补充一下背景，听众可能会想，好的，你可能只有四个客户。你们有多少客户？

不，我们有 100 多个客户。好的。而且其中很多都是大型企业。一直参与所有这些对话有时确实让人应接不暇。有时候我也会觉得，天啊，我是在浪费时间吗？

但我觉得这样能让我真正理解哪些方面进展顺利，哪些方面不顺利。我也确实能时刻掌握脉搏。而这一点是没有任何替代品的，尤其是在很多 implementation（实施）工作已经变得非常快的情况下。对于任何 startup 来说，越来越深的 moat（护城河）其实是客户洞察，是那种真正理解他们想要什么的 empathy（共情能力）。如果我们能在 customer insight（客户洞察）上建立差异化优势，那会比拥有一个一夜之间就可能被复制的产品优势更有价值。

我们再多聊聊这个，因为这几年来这一直是个热门话题。你知道，ChatGeebD 在 2022 年 11 月出来后，人们立刻开始嘲讽 application layer companies（应用层公司）只是套在 foundation model（基础模型）之上的 wrappers（封装壳）。对吧？而你刚才说的话，其实正好切中了这个主题：总有一种观点认为，foundation model 终将把所有事情都做了。然后也总有另一种观点认为，当然没错，但你仍然可以在其之上建立一家公司，去弥合原始能力与真实客户问题之间的差距。

你如何看待自己经营一家 application layer company（应用层公司）的角色，以及 foundation models（基础模型）的角色？比如，你认为随着时间推移，你们业务周围的 moats（护城河）会形成在哪里？基本上，对于某个正在听的人来说，如果他感兴趣的是，在这个时代该如何打造一家 application layer company（应用层公司）？你对此有什么看法？

我觉得，当新模型出来时，你必须为此感到高兴。而这某种程度上也是我们的指导原则：我们如何确保我们正在构建的东西，不会因为 labs 和 hyperscalers 推出的任何新东西而过时，反而会因此变得更好？

有什么好的例子吗？

对我们来说，我们认为 product 就是边界。product 就是控制。product 实际上就是用来限制 model 能力的东西。因为现在的问题已经不是 Opus、GPT five point five 能不能做这些惊人的事情，而是它们能不能在我的 enterprise 环境里做我想做的事。它们的能力实际上几乎是无限的。

现在的限制在于：作为一家重视 security、想要在全公司范围内部署这类能力的大型 enterprise，我怎样才能在不提高自身安全风险的前提下，放心使用它？所以我们是从边界这个角度来思考的，这也就意味着那些非常无聊、很老派的 enterprise software 事务：permissions（权限）、approvals（审批）、限制你的 API 集成范围，以及对这些有可见性；还有 audits（审计）、reporting（报告）、logs（日志）、alerts（告警），以及所有能让你放心让 models 在你的环境里尽情运行的东西。对。所以从 architecture 的角度看，我们做的一项根本性设计，就是把 agents 分成两部分。所以我们的客户在体验 Servo 时，实际上会接触到两个 agent。

一个是 admin agent，它帮助构建所有这些 tools 和 skills，用来配置 help desk，也就是规定 helpdesk agent 能做什么、知道什么。这部分是由 admins 来搭建的。另一个是 end users 会与之对话的 helpdesk agent，由它来解决用户的问题。helpdesk agent 只能使用那些由 admins 明确构建、发布，并经过 approvals、permissions 等流程的 tools 和 skills。而这种 architecture，这种双管齐下的 architecture，最终会变得非常非常强大，因为你可以让 help desk agent 尽情发挥，对吧？

因为 end user 可以问它任何问题，它也可以运用自己的 reasoning（推理）能力和完整智能去解决用户问题，但它只能使用那些 IT admin 明确认定可以使用的 tools。没错，而且这些 tools 可能还附带 approvals，以及限制某些用户执行某些操作的 permissions。所有这些都是在 admin 这一侧完成的，但与此同时，你又能获得 help desk agent 使用这些 tools 时几乎完整的能力和智能。

底层是怎么实现的？你们能不能谈谈，目前在哪些 models 上效果比较好，以及这种情况可能是如何随着时间演变的？

可以。我们目前使用 OpenAI 和 Anthropic 的 models，也一直在尝试所有提供方的最新 models，以确保自己处在 cutting edge，并且会对我们做的每件事运行 eval suites（评测套件）。到今天为止，主要还是 OpenAI 和 Anthropic 的 models。我们发现，不同 models 更适合不同应用场景。所以在与 end user 的交互上，我们目前在 OpenAI models 上最成功，而且这一点已经稳定持续了很长时间——无论是正确调用 tools，还是以恰当方式回应用户，我们在各种 GPT models 上仍然取得了很多成功，并且会根据最新发布持续更新。但在 automation 这一侧，主要是 cogen automation，我们目前在 Anthropic model 上最成功。

所以我们还在继续使用这些模型，比如 Sonnet、Opus。不同 models 之间存在大量 trade-offs（权衡），而我觉得最近比较有意思的一点是，新发布的版本往往并不是即插即用的。有时候你会获得一些优势，但与此同时，一些原本运行得非常好的东西反而没那么好用了，所以随着事情发展，这已经成了一个很有意思的挑战。

其实，对，你们是怎么管理这件事的？比如，把新模型整合进你们产品的 production 版本，通常要多久？这个过程里有多少是以某种方式自动化完成的？又有多少是必须有人坐下来自己摸索、搞清楚的？你们具体是怎么做这件事的？

它还没有我希望的那么自动化。我们的 evals（评估）是自动化的，但每一次测试新模型时，都会出现一些地方变好了、另一些地方变差了。很多变差的地方，也不一定是模型本身变差了，而是我们围绕这个模型已知的怪癖或行为模式，做了大量的 prompt tuning（提示词调优）和很多基础设施建设。等新模型出来，或者你在切换模型时，这些东西就会越来越不适用。所以，大量需要调整的地方其实都在这里。

然后你会先把它跑过一遍 evals，再在客户中做一个比较慢的渐进式发布。我们在这方面做得越来越好了，但我觉得有些情况下，这种权衡并不划算——我们确实有过先升级模型、后来又降级回去的时候，然后说，你知道吗？老模型也许还更快一点。或者它们在某些方面比新模型更可靠，所以新模型可能是更聪明一点，但它们出问题的方式更难预测，而我们用来防止这些问题的 guardrails（护栏机制）也就没那么可预测。所以我们会想，嘿，这个模型可能没那么聪明，但我们知道它会以适合这些客户的方式正确运行。所以，这一直是个很有意思的挑战，而且它也一直在变化。

你们现在会在多大程度上把成本因素纳入考量？因为我觉得，你知道，第一步是先确保产品能做出一些很神奇的事。对。第二步才是，好，现在我们得确保这是一门生意。没错。

而且我们还能从这项功能中提取出合理程度的价值。你们现阶段会经常考虑成本吗？还是说我们大致知道这件事长期会怎么发展，所以先确保产品足够神奇，成本问题以后再解决？

是后者。我觉得我们之所以有这种灵活性，其中一个原因是，我们的 unit economics（单位经济模型）最终看起来比很多 AI 公司好得多，因为我们不是做 reselling tokens（转售 token）这门生意的。我们产品的工作方式是：你会构建这些 automations（自动化流程），它们本质上就是 TypeScripts。一旦构建好，你就不用反复重建它。所以每次终端用户请求 password reset（密码重置）时，系统并不会重新生成一段用于重置密码的代码，而只是运行那段已经生成好的代码。

随着时间推移，用户需要实际生成的新代码会越来越少，因为我们有一个不断增长的 automations（自动化流程）库，能够覆盖你可能想做的那些非常长尾的需求。所以实际消耗并没有你想象的那么多，尤其是在那种非常昂贵的 cogen token 消耗上，并没有那么夸张。因此我们的 unit economics 非常强，尽管我们在这方面其实还没做很多优化。所以我总是跟团队说，多花点钱。用最好的产品。

我们知道从长期来看这件事会走向哪里。我们也知道，后面有各种各样的优化都可以做。所以到目前为止，这一直是我们的重点。不过我觉得，事情开始变得更有意思的地方在于：当我们探索越来越多这类 background agents（后台 agent）、long running agents（长时运行的 agent）的应用时，它们不只是响应 help desk 请求，也不只是为你快速写点脚本，而是去调查你所有的历史工单，或者分析设备日志，在后台完成所有这些工作，甚至可能生成一些你原本都不知道自己存在的问题的解决方案——到了这个阶段，情况就会变得更有意思一些，因为这时成本也许就会变得更相关。所以我们大概会在更早的阶段开始考虑成本，因为如果你不盯着它，这类东西的成本很可能会很快失控。

嗯，这很有道理。假设 OpenAI 或 Anthropic 里有人明天一觉醒来，心想，等等，我发现了一家叫 ServiceNow 的公司，它看起来像是企业内部一个重要的 system of record（记录系统），也是一个重要的重心。我觉得我们应该做一个 first party product（第一方产品），比如 OpenAI ServiceNow，或者 Anthropic ServiceNow。如果他们盯上了你们，直接来和你们竞争，或者直接冲着你们这个品类来，这对 Serval 意味着什么？

对。我是说，这一直都是个很难回答的问题，因为一方面，面对这种情况——一家拥有无限资金、最强工程人才和 AGI 的公司，想做你正在做的事情，你凭什么比它更强？——任何回答听起来都会有点天真，好像在说，嗯，我们就是会打败他们。但我觉得，startup（初创公司）的历史告诉我们，小公司其实经常能赢。OpenAI 和 Anthropic 的存在，本身某种程度上就是证明：你是可以击败那些资源无限、根基深厚的 incumbent（现有巨头）的。

我觉得这归根结底可能是因为，某种“天意”偏爱 startup，或者也可能是因为，缺乏聚焦往往正是导致执行困难的原因。所以，当年我创办第一家公司时，几乎每个 VC 都会问我：Google 难道不会直接做这个吗？答案是，会，Google 的确会做很多这类事情，但实际上，要把很多不同的事情都做得非常非常好，是很难的；而且要把注意力分散到这么多品类里，也很难。我不觉得 ITSM 会是他们最合理的聚焦方向。原因之一是，我认为过去几个月里，Anthropic 新增的 ARR 已经超过了 ServiceNow 过去二十年的总和。

很有道理。

所以，他们真的有必要把自己最优秀的人才投入到这个问题上吗？即便他们做得非常成功，这件事带来的回报，其实也未必值得——因为要达到同样的成果，他们在现有产品组合的其他部分可能几个月就能做到，而在这里却要花上好几年。所以我不觉得他们会——他们大概会看看这个品类。我不会惊讶，如果他们做出某种简单版本，也许是更偏向 mid-market 或 SMB 的版本。但如果要真正投入时间和精力，去掌握 enterprise service management 的复杂性，不是说他们做不到，只是我认为，这所需要的聚焦，会是一种对他们资源的低效使用和糟糕的优先级安排，我不认为这会

对，我觉得你说得对。我们来聊聊你们的客户。你们已经有不少很不错的 AI native 客户标志，同时也开始拿下一些大型 enterprise（企业）客户。这两类客户的需求有什么不同？

如果让你分别从这两类客户中各挑一句，他们对你们最好的评价会是什么？你知道的，“Servile 很棒，因为……”他们会怎么说？

对。我觉得最大的一个收获是：和它们的差异相比，它们的相似性更大。我原本以为它们会非常不同，但最终从 AI native 公司到大型 enterprise，它们的痛点和问题看起来惊人地相似。我们的客户里，小的有几百名员工，大的有几十万名员工。最终的区别在于，需要多少人参与决策。

而真正让事情变得非常有挑战性的，恰恰就是这一点，因为

这更像是一个 go to market（市场进入）层面的事情。它是一个

go to market（市场进入）的问题。与其说是别的，不如说更是一个实施层面的事情。对。所以当你在和一家只有几百名员工的公司合作时，很可能会有一位 IT 负责人可以说，我们就要这样做事，onboarding（入职接入）流程就是这样运作的。

我们会这样重置密码。如果你合作的是一家有几十万员工的公司，甚至没人知道那个人是谁，前提是那个人真的存在。于是你最后就会陷入各种各样的委员会里，试图弄清楚这里我们到底该怎么做。而这其实正是它变得非常、非常有挑战性的原因。我觉得你也能在这些 labs 里看到这一点：他们在建立咨询业务，增加越来越多的服务和部署资源，因为在 adoption（采用）过程中，真正的 rate limiting step（速率限制步骤 / 瓶颈）最后其实就是协调所有这些人。

所以，他们对我、或者对 Serval，说过哪些好话呢？在 AI native（AI 原生）的早期公司里，我们会找一个对技术充满热情的 IT 人员，然后让他们把时间花在构建上。他们进入 IT 行业，本来就是因为他们热爱技术。而在 Serval 出现之前，他们工作中的很大一部分，其实并没有真正让他们体验到技术。我最喜欢的一个例子是，有个客户一天里很大一部分时间都花在处理 ServiceNow 请求上，只是为了给别人开通使用 Cursor 的权限。

对。

而这种并置感实在太让人难受了。就像，我正在这个古老的工单系统里，帮助公司里的另一个人获得一个非常酷的 AI 工具的使用权限，可我自己的工具却还停留在过去，我自己反而用不上这些酷东西。而有了 Servo，他们就能用上这些酷东西了。比如，真的会有一个专为 IT 打造、属于他们的 AI 工具。所以我觉得，这就是我们在 AI native（AI 原生）这一侧看到的情况。

我觉得在大型 enterprise（企业）里，你知道，他们通常是在一个更高层次的 business transformation（业务转型）框架下来思考这件事。我们也更多听到关于终端员工体验的话题，因为在小公司里，即便你的 IT 流程不完美，也不会有人要等上几周才收到 IT 的回复。但在大型组织里，你把一张工单发出去，就像是把它扔进了深渊。对。然后你完全不知道它现在在哪里，是否有人在处理。

所以接着你又会再发一张工单，于是另一边就会开始混乱，因为现在同一个人发来了两张工单，而且现实中确实会有人因此被卡上好几周，没法回到他们原本想做的事情上。所以我觉得，在更大的 enterprise（企业）里，我们实际上改变的是员工体验，以及作为员工会有什么样的感受，并带来更广泛的影响，因为那些大组织里的问题其实要深得多。

在 Serval，Serval 有什么令人愉快或让人惊讶的用法？你们是怎么用它的？

哦，天哪。我强制团队什么事都用它。所以每次我——

那他们真正把边界推进到什么程度，体现在哪些地方？

对，比如，他们的意思显然是，像办公室申请、零食之类的，这一切都必须通过 Serval。但我觉得我们在 Serval 上做的最酷的事情之一是，第一，我们有一个叫 Dream Team Draft 的频道。我们在招聘上采取一种非常以人为先的方法：我们想识别出世界上最好的人，并把他们带到 CERVL，而不是单纯撒一个很大的漏斗，办一场公开选拔，然后看看谁能留下来。所以大家会把自己合作过的最优秀的人发到这个频道里，也会发到 LinkedIn。那是一个 Serval 频道。

然后 Serval 会接收那个 profile（个人资料），再运行一系列 automations（自动化）。第一，它会把这个人纳入我们所有的 outbounding campaigns（外联活动）和 nurture campaigns（培育活动）。它还会做很多我家 marketing team（市场团队）不让我细说的事情，比如确保他们走到哪里都能看到 Serval，让 Serval 在他们脑海里始终处于非常靠前的位置。我们基本上是在预热这批受众，确保他们知道 Servo，而且我们是在打长期战，因为这些人通常不是明天就会离职的人，而是那些我们希望有一天能一起工作的人。所以我很喜欢这样一种方式：作为员工，我唯一要做的就是说一句，“我很喜欢这个人，他很棒”，然后我就完成了。接着 talent team（人才团队）就能通过 Serval，用所有这些 automations 把他们逐步纳入系统。

这非常酷。那在 Serval 工作最好的理由是什么？比如，人们为什么会加入你们团队？

我觉得，这是我合作过的最棒的一群人。我觉得当你走进我们的办公室、见到我们的团队时，你会发现这就是一群——怎么说呢——非常友善、非常有才华，而且相处起来特别有趣的人。我认为这才是真正独特的地方：公司刚开始时，我甚至没意识到自己在筛选这种特质，但 Candid 开始跟我说，“哇，你们团队的人太好了，而且和他们待在一起特别开心。” 我走进办公室时，能量感是会传染的，我会想在那里工作。当然，这里也有非常有意思的技术问题，比如构建这些非常复杂的 enterprise automations（企业自动化），还能接触 HR、legal、finance、IT、security。

这里某种程度上像一个训练场。我们经常把这里看作一个训练场，适合任何想在 AI 领域做任何事情的人。你可以接触所有这些不同的部门，搭建各种很酷的 workflows（工作流）。但我觉得——如果我说实话的话——你加入 Servo 的原因，是因为你见到了这个团队，然后你会意识到，这里就是适合你的地方。

对，很酷。我们听到你用了一些词来形容你们的文化，比如有趣、友善、充满活力的人。那它不是什么样的呢？

我会说，这里并不是一个很适合接受大量 training（培训）或 mentorship（指导）的地方。大家都很友善，但每个人都在忙自己的工作。这里没有太多那种“嘿，你会通过这个项目完成 onboarding（入职），你会学会怎么做这些事，我们会把你训练得很好，还会给你配一些资源、coaching（辅导）和 mentorship”的安排。有些很棒的公司非常擅长做这些事。我们不是其中之一。

所以我们招的人，基本上是那种第一天来就能开始产出的人，而且他们喜欢那种模糊性：我得先出现，自己弄清楚我该做什么，然后把它做得非常、非常好。所以这里不是一个适合 coaching 或 mentorship 的地方，也不是一个有非常清晰 career path（职业路径）的地方。我们并不知道很多职能之后会往哪里发展，所以不会有那种沿着 org chart（组织架构图）清晰晋升的路径。事实上，这里几乎都没有真正意义上的 org chart。

其实我都不知道公司里谁向我汇报。说真的，我几乎是非常“幸福地无知”——技术上到底是谁向我汇报、谁向别人汇报，我并不在意，因为我们会尽量让一切保持扁平化。所以如果你想要那种比较自然的晋升路径，那这里就不太适合你。

对。最近我们和很多 founders（创始人）以及业内人士聊得很多的一个大话题，就是“活在未来”这个概念。不只是你打造的产品需要是 AI native（AI 原生）的，你构建产品的方式、管理组织的方式，也都需要是 AI native，而不只是使用 Servo 本身。对你们来说，这意味着什么？这一次你们的运营方式，相比 Vercada 或你之前的公司，发生了哪些变化？

变化非常多。首先一点是，我们在重新审视每个人的角色、每一个部门。我们会想，这个岗位或这个部门是否还有存在的必要，是否依然合理；很多时候答案是有必要、也合理。我们也重新认识到一些部门的必要性——这些部门我们原本还以为也许不需要了。但我们的出发假设是：也许这件事已经不再需要一个人来做了。

也许这可以交给 AI。所以 AI 几乎像是对每一份工作、每一个部门都拥有“right of first refusal（优先承接权）”——也就是先问一句：“也许我们根本不需要这个了？”又或者，“也许这个团队可以比现在小得多？”

有没有什么很好的例子，是某项工作已经完全交给 AI 了？

Solutions engineering。我们没有 SE（solution engineers，解决方案工程师）。我们也没有 SDRs，不过我觉得过去几年里，这一点反而没那么有争议了。但我们的确没有 SDRs，也没有 solution engineers。我们的销售 reps（销售代表）不一定比上一代的 reps 更懂技术，但他们可以使用 Servo。

对，所以无论他们对产品如何运作有什么问题，还是客户或潜在客户提出了什么问题，Servo 都会立刻给出答案。Servo 甚至还能在通话过程中现场帮他们做 decks（演示文档）、one pagers（单页资料）、快速 battle cards（竞品应对卡）和 comparison sheets（对比表），这些都可以即时生成。所以我们对 AE（Account Executives，客户经理）的要求更高，而他们也不会有 SE 这种资源支持。我们确实有四位 deployed engineers，负责协助实际的 pilot implementation（试点实施），但这是一个我们本来并不需要设这个岗位的例子。

我们也推迟了很多领域的招聘，有时候并不是主动选择，而只是因为招聘进展太慢；但这也让我们发现，原来不用那么多人也能走得很远。在 enablement（赋能）这边，我们有一位 product marketing 的同事，非常出色地搭建了 enablement 体系和各种自动化资源，而且已经把这套体系扩展得相当远了；当然，我们肯定还是需要更多支持。但很多时候，有了这些 AI 工具，你能做到的比自己想象的更多。RevOps 也是一个例子，我们在没有 RevOps 招聘的情况下也推进了很多工作，但后来也发现，确实最终还是需要有人来专门负责。所以这里面有很多事情都是这样：你先把招聘往后拖一拖，然后发现，确实还是需要这个人，但也许这个部门并没有我们原先以为的那么大。

公司成立大概两年半了？其实刚满两年。两年。好吧。而且在这期间，你们的发展速度非常惊人。

人更多了，客户更多了，各种好事都是。那在过去两年里，你的工作发生了什么变化？

在最早期的时候，说实话，我觉得自己很没用。我的 CTO 在搭产品，而我们要做什么其实非常清楚；要做的东西又特别多。我这边则在拼命招聘、安排客户电话，也许还试着把这个东西卖出去，但就是不太奏效。所以我觉得，在早期更像是在摸索：当我们其实还没有真正形成一个 business（业务）的时候，我怎样才能发挥最大作用。然后随着时间推移，它慢慢变成了一个真正的 business，不再是我一个人在把巨石往山上推，而更像是业务本身在拖着我往前走。我想没变的是，我到现在还是非常深入地参与客户相关工作，不仅是销售端，也包括长期成功这部分，而且我每天都在和客户交流。