跳转至

李正韬:把语音 AI 做成企业愿意使用的产品

月球大叔、李正韬 · 月球大叔 · 2026-08-09

观看视频 · 备用 PDF · LaTeX 源码

视频封面

导读

将前沿语音 AI 模型转化为大型企业愿意付费并替换原有呼叫中心的生产系统,中间横亘着从技术演示到工程交付的巨大鸿沟。本文基于 Retell AI 联合创始人李正韬(Todd Li)的深度访谈,完整复盘这支五人团队从大厂工程师业余试错、两次申请进入 Y Combinator,到切入企业级语音客服并实现自述约 8,000 万美元年收入的演进过程。全篇围绕六个核心问题展开:早期如何靠高频项目练习沉淀执行力、如何顺着需求链条从单点语音工具走向完整业务任务、为何在孵化器建议下先克制扩招并攻坚大客户、五位联合创始人如何分工制衡、如何借自然传播破圈并完成合规与集成交付,以及如何用贴近实战的招聘和激励机制支撑长期产品质量。

执行力来自反复完成真实项目

很多工程师把创业起点理解为等待一个完美点子或攒够启动资金。李正韬在访谈前半段(01:16–18:25;35:55–37:59)回顾了自己从职场开发、业余试错到进入孵化器的过程:真正让团队抓住大模型机会窗口的,不是一次猜中方向,而是反复把想法做成可用产品的执行能力。

工程工作怎样变成创业训练

在 2024 年 1 月离开 Google 全职投入创业之前,李正韬先后在网络安全公司 Fortinet 和 Google 广告团队担任软件工程师(01:16–02:20)。在 Google 期间,他的核心任务是开发广告分配算法,即在海量流量中平衡客户帮助与平台商业回报。回看这两段职场经历,他认为它们并非全职创业前单纯的过渡,而是直接构成了底层的能力训练:他感觉在 Fortinet 的开发历练让自己的工程能力相比刚毕业时提升了好几个数量级;Google 的工程体系、企业文化与严格的代码质量标准,则让他建立起把产品细节打磨到极致的参照系。

在完成本职工作以及早年个人自愿高强度投入(如 996 节奏)的同时,他和合伙人一直利用业余时间开发自己的小项目。虽然这些早期尝试均以失败告终,但团队在反复构建、发布和推倒重来的过程中,把单纯写代码的能力延伸到了产品实现与市场拓展(Go-to-Market,简称 GTM,指把产品推向客户并实现商业转化的过程)的配合上。

到了大模型兴起后,他们之所以能在没有多少金钱投入的情况下持续试错,也得益于当下的创业基础设施(36:08–37:56)。李正韬对比说,早期创业者试错往往要承担刷爆信用卡的财务风险,而在今天的硅谷生态里,工程师可以在保留全职工作的情况下利用业余时间做小项目验证想法。这种探索大幅降低了辞职与大额个人资金投入的压力,但依然要付出实打实的时间与精力成本;能否在业余时间持续把项目做出来,本身就是对团队热情与执行速度的锻炼和证明。

家庭、导师与自己的判断

除了工程基本功,创业还需要战略认知。李正韬来自创业家庭,父母早年共同创业并在他七八岁时带领公司上市(03:27–07:26)。这种成长环境给他带来了双重影响:一方面,儿时旁听父亲开会、听父亲复盘经营风险与大多数创业公司都会失败的现实,让他很早就相信“创业虽然成功率低,但确实可能做成”;另一方面,由于记事起看到的更多是公司上市后的物质改善,他对创业过程的残酷性曾抱有美化滤镜,也坦言优渥环境让自己的忍耐力起初不如经历过更多苦难的人,直到亲自下场才体会到真实的煎熬。

为了弥补年轻团队在商业经验上的空白,他将自己创业路上的认知来源归纳为三批导师(07:58–09:00):

  1. 父母:常与他探讨行业风口、哪些产品可能成功以及成功需要具备的要素;
  2. YouTube 上的公开访谈与分享者:让他在性格与专业背景上找到共鸣并汲取经验;
  3. YC(Y Combinator,硅谷知名创业加速器)的合伙人、Twitch 联合创始人 Michael Seibel。

李正韬在访谈中强调,年轻团队缺乏认知和战略很正常,学校也不教这些内容,因此导师的作用是提供战略经验、帮团队及时否定走不通的想法(16:01;32:50–34:53),但没有任何导师能替团队完成日常执行。

这种对“能力与外部条件”的区分,也体现在他对待启动资金的选择上(09:01–11:20)。当他决定离开 Google 创业时,父母曾准备像祖母当年支持父亲几万元那样提供一笔启动资金,但他没有接受。在他个人的感受里,如今硅谷的投资人与孵化支持已经非常充沛,创业越来越看重个人能力。他用了一个假设性的思想实验来表达这一看法:假如把 Elon Musk 的记忆和能力放进一个毫无资金与人脉(Network)的普通路人身体里,他相信对方在硅谷几年内依然能把事情做大。基于这种信念,他认为资金、资源与人脉关系最终是个人能力与时间共同作用下的折现。

从业余试错到全职承诺

团队从兼职试错迈向全职创业的转折点,发生在两次申请 YC 的过程中(13:41–16:05)。第一次申请时,他们做了一款批改托福作文的应用,虽然拿到了面试机会,但开场就被导师反问“你们还有没有别的想法”,因为商业方向不被认可而落选。第二次申请时,他们提交了一款延迟约 8 秒的中译英直播翻译软件。面试官 Michael Seibel 结合自己在直播行业的经验,依然直接否定了这个点子,但因为看到他们每次都能把具体产品扎实做出来,认可了团队的执行力与工程能力,于是提出:先加入 YC,进来之后再换方向。

之所以在此时果断辞职、接受 YC 要求的全职承诺,还源于团队对技术周期的调研与判断(14:50–15:48)。ChatGPT 出现后,他们回顾了互联网、移动互联网与云计算的历史规律,认为一项新技术出现后的机会窗口通常只有两到三年,大多数最终跑出来的公司都诞生在这个窗口期内。与此同时,李正韬认为大模型出现后,每个人都更容易提供基础价值,此时竞争比拼的是谁能提供更多价值或拥有独特优势,就像踢世界杯一样,往往只有排在前面的队伍才能真正拿到回报(12:20–13:40)。因此,2024 年 1 月他从 Google 辞职当天,Retell AI 这个具体产品其实还不存在,他们是带着已被验证的团队能力,跳进时间窗口去寻找具有市场验证(Traction,指产品获得真实用户使用或需求反馈)的方向。

基于这段经历,李正韬与主持人在节目中总结了一套早期探索的工作方法(16:32–18:05):在认知有限的初期,与其耗费时间空想“选哪个完美赛道”,不如先选定一个具体项目拼命做出原型;通过接触真实用户拿到最新鲜的一手信息,发现走不通就立刻复盘并切换方向。正是靠着在语音相关领域连续推翻口音消除、文本转语音(TTS)等过渡想法,这支五人团队才最终收敛到了企业级语音 AI 客服这一核心业务。

早期创业的“认知—执行”互补机制

在李正韬的创业框架中,创始团队的能力由“战略认知”与“执行力”两部分构成。认知高度依赖行业经验,年轻团队初期往往存在盲区,需要借助有过实战结果的导师(如成功创业者或孵化器合伙人)提供参考,及时筛掉走不通的想法;而执行力则是把想法变成可用产品、推向市场拿回反馈的速度与工程质量。外部导师可以补充认知,但只有团队自身的执行力才能把认知转化为真实的产品迭代。

误区:把“业余低风险试错”当成“零成本投入”

借助云服务商的初创扶持与现代开发工具,工程师在业余时间开发原型确实不再需要像早年那样动用大额个人储蓄或承担高昂硬件负债。但低财务风险并不意味着没有门槛:一方面,业余开发需要持续投入大量个人时间与精力;另一方面,当项目进入像 YC 这样要求全天候投入的阶段、需要抢占两三年的技术窗口期时,团队依然要做出辞去高薪工作、全身心承压的正式承诺。

阶段与载体 核心行动 沉淀下的结果
Fortinet 与 Google 任职 系统开发与广告流量分配算法研发 提升工程开发速度,建立高标准代码与产品质量参照
业余时间独立项目 与合伙人反复开发不同小产品并推向市场 项目虽均未成功,但磨合了团队协作与产品落地能力
第一次申请 YC 开发批改托福作文的应用并参加面试 商业方向被当场否定,意识到选品与商业认知不足
第二次申请 YC 开发约 8 秒延迟的中译英直播翻译软件 点子再被否,但凭产品完成度与团队能力获准入选
Retell AI 团队全职创业前的能力积累与方向探索

为什么团队在还没有 Retell AI 这个产品时就敢辞职全职创业?这源于他们在长期业余试错中已经养成了一套靠行动获取反馈的工作方式。

执行力来自反复完成真实项目(依据节目口述整理 · 01:16–18:25;35:55–37:59)
执行力来自反复完成真实项目(依据节目口述整理 · 01:16–18:25;35:55–37:59) 下载 PDF 原图

读图:执行力来自反复完成真实项目

如图所示,上方主链路展示了团队的四个核心动作:首先通过“做小项目”去验证具体想法,哪怕是早期的作文批改或直播翻译;接着通过“接触用户”取得真实市场的一手信息,观察是否存在有效反馈;当发现方向走不通时,迅速“复盘失败”并修正产品方向;随后立即投入“再次执行”,在多轮循环中沉淀出把技术做成产品的团队能力。下方底座则表明,导师在其中提供判断参考,而全职承诺正是建立在过往项目和团队实践之上。

这套流程说明,早期创业不必等待完美方案,先通过高频执行拿到反馈并持续修正,才能在新技术窗口期到来时抓住真正的市场机会。

本章小结

  1. 职场积累:在 Fortinet 和 Google 的工程实践,为李正韬提供了扎实的开发速度与极致的代码质量标准。
  2. 导师价值:家庭、公开访谈与 YC 导师提供了战略认知参考,帮助年轻团队快速否定错误方向,但无法替代团队亲自执行。
  3. 迭代闭环:团队通过多次业余项目证明了工程与协作能力,在两次申请 YC 后果断全职投入,以高频试错抢占大模型两三年的技术窗口期。

从语音技术走到客户真正购买的任务

在明确了依靠高频执行探索方向后,下一个问题随之而来:进入 YC 的五人团队把目光锁定在语音技术上,但做得出语音工具,为什么不等于能做成企业买单的生意?他们又是如何跨过实时通话的工程门槛、在与大厂的竞争中找到落脚点的?

配音、口音与客服之间的选择

全职进入 YC 后,团队每次都会与导师聊一两个小时,围绕语音技术推介(Pitch)不同想法(18:24)。他们曾尝试做直播实时配音和翻译,也设想过帮客服中心的工作人员“去掉口音”。但结合用户反馈与导师讨论后,他们注意到一个问题:用户用完实时配音后会问,既然都有 AI 了,为什么还要真人先说话再翻译,不直接让 AI 替人说话(28:37)?同样,如果团队判断未来是让不需要真人的 AI 直接接打电话,“帮真人去口音”对他们而言就成了一个过去式的需求,不如直接去做用 AI 替代人工的产品。

团队随后又尝试开发 TTS(Text-to-Speech,文本转语音,即把文字合成为语音的模型)。但他们很快进一步追问:做这个底层语音模型的最终目的,到底是为了解决什么问题?答案依然是让 AI 替代人工来做客服。既然如此,与其停留在中间层模型,不如直接切入最深入、最接近客户的那一层。据李正韬自述,此前做的几个产品推广一个月也拿不到什么市场验证(Traction),而把新的语音产品做出来后,第一个星期就有几万名用户(29:10)。

顺着这个信号,Retell AI 明确了产品定位:为企业提供语音 AI 客服呼叫中心方案。比如拥有数百万乃至上亿消费者的 B2C(面向消费者)企业,往往需要几千甚至几万人的团队 24 小时接听电话;平台不仅能承接这类日常客服,还能覆盖销售、回款催收以及偏营销类的不同使用场景(19:37)。据李正韬在节目中介绍,当时公司年收入约为 8,000 万美元,客户超过 3,000 家,涵盖 OpenTable、Opendoor、Mercury、Anker(安克)、Lenovo(联想)以及 CVS 等企业(20:14)。

语音通话为何比文本更挑剔

确定赛道后,外部最常见的疑问是:OpenAI、Anthropic、ElevenLabs 等知名公司也在涉足语音或客服,初创团队凭什么拿到重量级客户?李正韬在实践中体会到,语音是一个非常深的领域,比文字客服难得多(20:53)。他对比说,在文字客服场景下,无论是模型生成还是检索知识库(Knowledge Base),各个环节哪怕有 10 秒甚至更长的运算缓冲时间(Buffer),系统也还能运转;但换成实时语音,模型推理(Inference)、服务器响应以及每一个网络连接(Connection)的表现都会直接影响通话体验,必须专门针对这些环节做深度优化。

更关键的差距在于从演示版本(Demo)到真正投入运营的客服系统之间的距离。录一段 AI 打电话的演示视频发到网上很容易让人觉得效果不错,但要让一家企业真正接受并用来替代原有的客服中心,中间需要走一条很长的路,解决大量具体问题。据李正韬介绍,在客户做采购测试与尽职调查(Due Diligence,采购方对供应商产品与资质的评估)时,测试结果让他们认为 Retell AI 的产品表现最好,因此团队是靠把语音通话这一件事做深而获选,而非依赖大厂般的名气(21:50–22:05)。

此外,这还涉及大厂与初创公司资源分配的差异。李正韬分析说,如果初创公司去和 OpenAI 正面比拼通用大模型,或是去拼对方重点投入的编程智能体(Coding Agent),几乎不可能打得过;但在语音客服这个方向上,语音并非大厂的核心大业务,初创公司是全公司对阵大厂里的某一位总监(Director)及其分支团队(23:25)。在他看来,双方在这件事上的投入程度(Dedication)与整体认知并不在同一个水平线上。

平台能力与最后一公里交付

看清了与大厂的错位竞争关系,接下来的问题是如何把技术真正装进大客户的业务里。服务大型企业是一个复杂的过程。李正韬提到,有些大客户从签单到真正完全取代原有的客服中心,中间可能要经过差不多一年的时间(24:15)。在这期间,团队需要不断构建、反复测试产品的稳定性与通话相关功能,并把客户现有的通话流程一步步迁移过来。

这种重度迁移需求,直接决定了产品的形态边界。如果只做一个纯标准化的 SaaS(软件即服务)工具,里面大部分通用功能大企业未必用得上,而企业真正卡壳的内部系统对接它又解决不了,产品价值就会大打折扣。反过来,如果为每家客户从零定制全套代码,公司又无法规模化。

为此,Retell AI 采用了混合模式(Hybrid):一方面,所有与语音相关的通用功能都可以在其标准化平台上实现;另一方面,在“最后一公里交付”(Last-mile Delivery)上,配合前线部署工程师(Forward Deployed Engineer,简称 FDE,指深入客户业务现场协助完成系统集成与定制落地的工程师),针对每家企业的具体需求,帮他们搭建相应的工作流(Workflow)(24:42–25:58)。

实时语音交互的延迟账本(教学抽象)

为什么实时语音通话比文本聊天难做得多?在工程教学上,我们可以把一次语音交互抽象为几个紧密衔接的环节(注:此处为通用教学拆解,不代表 Retell AI 内部固定采用某种单一串联架构,实际系统也可能结合端到端语音模型等多种方案):首先是听清并判断用户是否说完,接着是模型推理与业务知识库检索,最后是生成语音并通过通信线路传回。与文字聊天可以容忍数秒缓冲不同,语音对话中推理、服务器与每个网络连接的延迟都会直接影响交互体验,因此需要在基础设施、模型调用与长时运行服务上做专门优化。

误区:把“最后一公里交付”当成纯外包重做

听到“为每家企业搭建相应工作流”和“前线部署工程师(FDE)”,容易误以为公司变成了每接一个客户就把全套系统推倒重写的纯外包厂。实际上,Retell AI 采用的是“标准化平台 + 最后一公里交付”的混合模式(Hybrid):与语音相关的核心功能统一在平台上实现并复用;最后一公里交付则是针对具体企业的业务流程,协助其完成工作流配置与现有通话流程迁移。这样既发挥了通用平台的技术深度,又满足了大企业复杂的落地要求。

探索方向 核心机制与切入层级 市场反馈与团队判断(本期案例)
实时配音与去口音 辅助真人说话,翻译或修饰口音 缺乏市场验证;团队判断若未来由 AI 直接通话,去口音便成过去式需求
TTS(文本转语音) 提供文字合成语音的底层模型 属于中间层,团队决定直接切入最接近客户业务结果的那一层
语音 AI 呼叫中心 语音平台 + 最后一公里工作流交付 自述上线首周获几万用户;覆盖客服、销售、催收等场景并支持大客户迁移
团队在语音赛道的探索与产品演进对照

为什么单纯卖语音合成或去口音工具难以做大,而切入呼叫中心却能跑出高增长?下图展示了企业真正愿意付费购买的完整任务链路,以及平台与交付在其中的分工。

从语音技术走到客户真正购买的任务(依据节目口述整理 · 18:25–25:59;28:37–31:35)
从语音技术走到客户真正购买的任务(依据节目口述整理 · 18:25–25:59;28:37–31:35) 下载 PDF 原图

读图:从语音技术走到客户真正购买的任务

如图所示,上半部分从左到右由单向箭头串联起四个节点:首先是“用户来电(表达具体需求)”,随后进入“语音交互(理解与及时回应)”,接着触发“企业工作流(查询/处理业务)”,最终达成“通话结果(任务完成与记录)”。下半部分用横跨全局的底框标出支撑这套链路的混合架构——底层是“平台:复用通话与模型能力”,上层是“企业交付:适配流程、系统和规则”。

这说明客户买单的不是孤立的发声技术,而是走完这四个节点后的业务结果;把语音能力沉淀在平台上,再扎实做好最后一公里的工作流交付,是团队在竞争中胜出的关键。

本章小结

  1. 顺着需求链条深挖:放弃去口音、纯配音和单点 TTS,直接切入最接近客户需求的语音 AI 呼叫中心,覆盖客服、销售与催收等场景。
  2. 依靠工程纵深错位竞争:针对语音交互在推理、服务器与连接上的严苛要求做深产品,以全公司的投入度对阵大厂的非核心分支团队。
  3. 混合交付模式:在标准化平台上实现通用语音功能,配合最后一公里交付为企业搭建专属工作流并完成漫长的系统迁移。

为什么 YC 让团队先少招人再做大客户

既然企业级语音交付需要深入客户工作流,拿到首波数万用户的初创团队按常理似乎应该立刻大举招人、扩张销售。为什么 YC 导师反而要求他们尽量少招人,并督促他们离开热情友好的小客户,去啃态度冷淡的大型企业?

创始人先把业务跑通

许多初创团队在拿到产品验证后,第一反应是立刻募资扩招,但李正韬在访谈中分享了完全相反的经验(25:59)。他们的导师曾提醒,在某种程度上,早期过多的客户和过多的资金反而可能带来伤害。为了解释这一逻辑,李正韬在节目里举了一个假设性的反事实例子:假如五位刚创业的合伙人账上突然有 5 亿美元,外界定会催促他们别把钱放着吃利息,赶紧招 100 名销售和 100 名工程师把事情做大;但如果创始人此前没有创业和招聘经验,根本不知道怎样识别合适的人才,仓促招来的大概率是不匹配的团队,最终也做不出好产品。

因此,李正韬强调创业很大程度上是创始人的自我修炼(27:22)。在他看来,一家公司想要变强,创始人的综合分数与投入时间必须排在最前面,绝不能指望自己坐在办公室喝茶、招一堆人替自己干活。Retell AI 的实际做法是创始人先自己冲进去把业务跑通,摸清什么标准才算好,再去寻找专业领域更强的人来复制这套流程。即便如此,新员工接手后初期的交付质量大概率仍不如创始人亲自操刀,团队还需花大力气带教,才能把质量重新拉高。

正因为坚持创始人亲力亲为,五位合伙人包揽了早期的产品转型与研发,一直到公司年收入达到约 300 万美元时,才招入第一位工程师(30:50)。支撑这种精简运转的,是当时够用的早期资金与算力支持:YC 提供的 50 万美元投资在不盲目招人的情况下,支付每月几千美元的办公室租金与几人各几千美元的工资开销,按李正韬的估算足够维持好几年;而在服务器与开发成本上,当时各家云厂商针对初创公司的扶持计划(Startup Program)赠送了可观的云服务额度(Credits,用于在对应云平台抵扣服务器与算力账单的额度,非现金),例如他提到当时 Amazon、Google Cloud 和 Azure 各自提供约 30 万美元额度,这些不同平台的额度加起来差不多有 100 万美元,足以支撑团队完成大量早期开发与验证(31:00–31:35)。

导师纠偏与渠道放大

既然早期资金和算力额度并不紧缺,YC 这类孵化器真正核心的价值究竟在哪里?李正韬在 32:50 处将创始人的能力拆解为两块:一块是执行力,另一块是认知与战略。团队成员过去在大厂工作时,他个人就有自愿高强度投入工作的经历,因此执行力早已被打磨得非常扎实;但团队恰恰缺乏创业经验与战略认知。他坦言,当时团队虽然点子很多,但如果没有导师及时帮他们否决掉不切实际的想法,他们恐怕要多走许多弯路、多试错很多次。

面对外界“YC 到底有没有用”的争论,李正韬从自身经历给出了看法(33:52)。他回忆自己早年曾上过一门课,当时并不懂,后来才意识到那位授课老师自己并没有创业成功,因此回过头看觉得那门课对自己可能也没什么用。由此他认为,是不是去 YC 并不重要,重要的是找到真正有过创业经验或取得过一定成功的导师(Mentor),家人或朋友若有这类经验同样可以作为导师;只是对于大多数尚未证明自己的普通创业者而言,日常很难接触到这类指导者,而 YC 提供了一个可以公开申请并通过筛选获得导师指导的渠道。

除了认知上的纠偏,孵化器还在关键节点起到了资源对接与传播放大的作用(35:06)。李正韬对比说,进 YC 之前从来没有投资人主动找他们聊项目,而入选之后,大量投资人开始主动接触,这种倍增效应给了团队极大的信心。当产品正式上线(Launch)时,YC 内部论坛及其在 Twitter、LinkedIn 等平台的活跃账号允许被投企业(Portfolio Companies)发布动态;对于已经具备扎实执行力和可用产品的团队来说,这种集中曝光就像关键的一点“燃料”,帮他们迅速点燃了早期的市场传播。

从容易试用的客户走向深度合作

在导师的指导下,团队并非一帆风顺地全盘接受建议,反而在招聘节奏和客户定位上与导师 Michael Seibel 发生过多次激烈争论(38:05)。除了反复叮嘱“尽量少招人、先把创始人能力练强”之外,导师很早就督促他们向大型企业市场(Enterprise)进军。李正韬复盘时承认,当时团队经常持反对态度,但事后证明导师的判断是对的:如果创始人在认知没跟上的时候手里握着大把资金乱招人、乱花钱,就容易在市场上迷失方向。

为什么导师坚持让他们尽早切入大客户?李正韬在 39:00 处结合自身观察剖析了不同客群的特点:中小企业(SMB,Small and Medium-sized Business)的好处是比较容易成为早期采用者(Early Adopters),能帮团队打磨产品,但它们的留存率(Retention)和客户体量通常不是最大的。相比之下,在他观察的企業服务(B2B)市场中,许多公司最终还是会走向大型企业市场(Enterprise):虽然进入难度大得多,但一旦进去之后,客户黏性往往更强,净收入留存率(Net Dollar Retention,简称 NDR)表现也会更好。

然而,从中小客户转向大客户在执行心理上非常煎熬(39:50)。李正韬感叹,小客户通常很愿意试用新产品,还会热情地夸赞团队“太棒了”;而大客户可能对初创团队爱答不理,团队却必须把精力从夸奖自己的小客户身上转过来,主动去求大客户试用与合作。在他看来,跨越这道门槛,本质上就是强迫团队去完成一件“难而正确”且反人性的事。

误区警示:把融资额与团队规模当成早期进度条

初创团队常误以为账上资金越多、招人越快,业务推进就越稳。李正韬通过“账上 5 亿美元”的反事实推演指出,当创始人自身尚未摸清业务标准与用人标准时,盲目扩招只会引入不合适的人,导致产品质量下滑。先把业务由创始人亲自跑通、沉淀出可复制的标准,再克制地补充专业人手,才能避免资金与组织空转。

核心指标:净收入留存率(Net Dollar Retention, NDR)

净收入留存率(NDR)用于衡量企业从存量客户身上持续获得收入的能力,计算口径为:期末来自同一批期初存量客户的经常性收入 ÷ 期初这批客户的经常性收入(注意:分子仅统计期初那批老客户的留存、扩容增购与缩减流失,不包含当期新签约客户;它衡量的是收入金额留存,而非单纯的客户数量留存率)。

【教学示例(非节目披露数据)】假设某公司年初有 10 家客户,合计年付费 100 万美元;到年底,其中 1 家流失(减少 10 万),其余 9 家因业务量增长增购了 30 万美元服务,另有当年新签客户贡献 50 万美元。计算 NDR 时需剔除新客的 50 万,期末存量客户收入为 100 - 10 + 30 = 120 万美元,NDR 即为 120%。在李正韬看来,大型企业一旦切入成功,往往黏性更强、NDR 表现更好。

概念 机制 本期案例
云服务额度(Credits) 云厂商扶持计划提供的各自平台算力抵扣额度(非现金) 自述当时获 Amazon、Google Cloud、Azure 各约 30 万美元额度
孵化器导师(Mentor) 提供成功创业者的经验参考以否决走不通的想法,并助推首发传播 导师 Michael Seibel 建议少招人、做大客户,YC 社区助推产品上线
中小企业(SMB) 愿意尝试新工具,适合作为早期采用者,但体量与留存通常有限 早期试用快、反馈积极,常夸赞产品,帮团队完成初步打磨
大型企业(Enterprise) 准入难、迁移慢,但切入后客户黏性与净收入留存率(NDR)通常更好 初期态度冷淡、攻克过程反人性,但成为团队主攻的长期方向
早期关键要素与不同客群特征对照

为什么初创团队不能在拿到钱后立刻大规模招人铺摊子?在团队自身能力演进与外部客户结构切换之间,究竟遵循着怎样的先后顺序?

为什么 YC 让团队先少招人再做大客户(依据节目口述整理 · 25:59–28:37;31:35–40:31)
为什么 YC 让团队先少招人再做大客户(依据节目口述整理 · 25:59–28:37;31:35–40:31) 下载 PDF 原图

读图:为什么 YC 让团队先少招人再做大客户

图上方四个递进节点展示了团队内部的能力建设路径:首先由「创始人亲做」,在一线实战中「知道什么算好」;接着将经验沉淀,「形成可复制流程」并「识别真正瓶颈」;在此基础上才开展「针对性招聘」以「补充专业能力」;新人加入后仍需创始人「持续带教反馈」,从而「保持交付质量」。图下方文本框则对比了外部客群的演进特征:「早期客户」的特点是「试用快、反馈直接」,而「大型客户」则是「迁移慢、要求深、关系长期」。

这幅图说明,唯有通过“少招人、创始人先冲在一线”把内部交付标准练扎实,团队才有能力跨越心理舒适区,承接大型企业严苛但长期的业务需求。

本章小结

  1. 组织克制:创始人在跑通业务前盲目招人容易拉低产品质量;Retell AI 依靠 YC 投资与各云平台扶持额度精简运转,在自述年收入达 300 万美元时才招入首名工程师。
  2. 导师价值:团队的执行力靠日常打磨,而战略认知需借助有过成功创业经验的导师来纠偏,并借力孵化器社区点燃早期传播。
  3. 客群演进:中小企业适合作为早期采用者打磨产品,而顶住冷遇攻克大型企业(Enterprise),有助于获得更强的客户黏性与更好的净收入留存率(NDR)。

五位联合创始人如何共同做决定

在确定向大企业市场推进、并要求创始人在招人前先把业务亲手跑通之后,一个现实问题随之出现:五位联合创始人要如何分工、协作并处理分歧?本章围绕 Retell AI 团队的内部运转,拆解多人创业中的职责边界、争论纠偏机制与运营体系的演化。

按兴趣与能力分工

在创业团队配置上,外界通常认为两三位创始人较为常见,而 Retell AI 共有五位联合创始人,在他们同一届 YC 中属于创始人数量最多的团队之一(40:31–41:42)。这五位成员由三位南加州大学(USC)校友和两位前同事组成。面对多创始人容易出现的职责重叠问题,团队采取了清晰的板块切分:两位创始人负责市场拓展(Go-to-Market,简称 GTM,即面向客户的市场营销与销售工作),两位创始人负责产品与技术研发,李正韬本人则负责公司的运营(Operations)。

这种分工并非机械指派,而是建立在个人长期兴趣与意愿之上(44:23–45:51)。李正韬在访谈中强调,每个合伙人负责的最好是自己真正喜欢做的事;例如让他长期做销售就会非常痛苦,难以持续。因此,团队中有两位合伙人几乎全天候深耕产品与技术,另外两位深耕市场与销售,而李正韬自认不喜欢每天重复同一件事,更愿意跨部门解决不同问题,因而主动承担了涵盖财务、招聘、法务、IT 等多模块的运营工作。

因为每个人都在自己既感兴趣又高度专注的领域持续投入,团队内部自然形成了专业信任与决策授权。对于日常业务中的小事,大家尊重对应领域负责人的专业判断与投入时间,由该领域的创始人直接拍板,绝大多数(李正韬口述形容为 99%)日常事务都在这一层得到解决;只有涉及公司层面的重大方向,才由五个人共同商量并在大家认同后推进(47:08–47:50)。

信任让争论成为纠错

多位创始人共事不可避免会产生分歧,但李正韬将日常争论视为团队防止决策失控(go rogue)的必要机制(42:34–43:29)。他结合实践经验指出,人性容易让单打独斗的创业者觉得自己最聪明、最努力,一旦缺乏内部制衡,走偏后很难拉回来;而多位联合创始人反复开会争论,本质上是通过互相纠偏(correct)和制衡(balance),把更好的想法与更高的质量磨出来。

为了让高强度的业务争论不演变成内部消耗,这支团队依靠两项基础安排来托底:

  1. 股权分配追求公平:团队认同 YC 倡导的联创团队股份分得差不多的理念,认为在硅谷同行普遍采用类似分配的外部环境下,如果内部股份差距悬殊,股份较少的创始人容易产生心理失衡,长期下来可能滋生怨恨(41:30–42:33);
  2. 合伙人之间具备朋友信任基础:三位 USC 校友与两位前同事的熟人背景,让团队在起步时就不必从零建立信任(41:06;43:37)。

李正韬提到,如果合伙人之间没有朋友基础,在激烈的业务争论(Argument)中很容易把反对意见解读为人身攻击或刻意针对;而建立在朋友信任之上的争论,大家清楚彼此是对事不对人,从而让冲突真正发挥出修正方向的作用。

运营部门随着真实问题长出来

虽然李正韬受访时作为总裁(President)负责全公司的运营,但在创业最早期,五位创始人全员都扑在工程开发或市场拓展上,并没有独立的运营部门(44:55–46:20)。当时李正韬同样在一线写代码,亲手搭建了公司前几个版本的基础设施(Infrastructure,支撑软件运行的底层服务器与网络环境),包括配置 AWS 服务、优化语音服务在长时间运行的服务器上的运转速度,以及搭建 CI/CD(持续集成与持续交付,即让代码自动完成测试与部署的工程流程)。

随着客户数量和团队规模扩大,原本不存在的组织需求开始逐一浮现,李正韬的工作重心也随之从写代码转向解决公司运转中的新问题(46:20–47:08):

  • 财务职能:当付费客户变多后,收款成了必须专门花时间处理的事务;
  • 招聘与 HR:当公司需要扩充员工、对接招聘人员(Recruiter)时,逐步投入大量时间并形成新部门;
  • IT、法务合规与数据:当团队规模增长到 50 至 100 人的区间时,每台员工电脑的访问控制(Access Control)和 VPN(虚拟专用网络)等 IT 需求突然凸显,仅靠创始人顺手处理已不现实,进而催生了专门处理这些事务的新部门。

可以看出,Retell AI 的运营体系并不是在公司创立之初就按大企业模板预设好的,而是遵循着一条清晰的演化路径:先由创始人全员投入产品与市场把业务跑起来,随后在增长过程中遇到哪类真实的运转阻力,就由负责运营的创始人先行介入解决,最终随着需求常态化而生长出对应的专业部门。

分级决策机制:专业授权与重大共识

多人联合创业常面临“议而不决”或“一言堂”两极困境。Retell AI 的实践是将决策分为两层:1. 领域内日常事项:基于各创始人在产品、技术、市场、销售、运营上的长期深耕,由对应负责人独立判断拍板,解决绝大多数日常问题,保障执行速度;2. 跨领域重大方向:由五位联合创始人共同讨论,通过充分争论实现互相制衡与纠偏,达成共识后再共同推进。

早期工程基建:Infrastructure 与 CI/CD

在软件初创公司起步阶段,基础设施(Infrastructure)与持续集成/持续交付(CI/CD)是保障产品快速迭代的底座。基础设施涵盖云服务器(如 AWS)及让语音服务在长时间运行服务器上保持高速运转的环境;CI/CD 则是将代码集成与部署串联起来的自动化流程。早期由创始人亲手搭建这套体系,能让团队在人数极少时依然保持高频、稳定的产品发布。

职责板块 负责人数 核心工作内容 团队演进特点
产品与工程 2 位创始人 专注产品设计与底层技术研发 全天候深耕,日常事务由领域负责人直接拍板
市场与销售(GTM) 2 位创始人 分别深耕市场营销与客户销售 按个人兴趣切分,聚焦市场拓展与客户转化
公司运营(Operations) 1 位创始人 涵盖财务、招聘、HR、售后、法务合规、IT 与数据 早期写代码搭基建,随收款、招人、IT 权限等需求浮现而组建新部门
Retell AI 五位联合创始人的分工与演进

当团队共有五位联合创始人时,如何在避免内耗的同时兼顾决策效率与方向准确性?下图梳理了 Retell AI 的职责划分与两层决策原则。

五位联合创始人如何共同做决定(40:31–47:50)
五位联合创始人如何共同做决定(40:31–47:50) 下载 PDF 原图

读图:五位联合创始人如何共同做决定

图中上方并列展示了三个核心职能模块:左侧蓝色框为“产品与工程(两位创始人)”,中间紫色框为“市场与销售(两位创始人)”,右侧黄色框为“运营(一位创始人)”,体现五人按各自专长与兴趣驻守不同业务线。下方绿色长框总结了支撑这套分工运转的两条决策规则:“日常事项:领域负责人判断”与“重大方向:五人讨论形成共识”。

这种“上层专业分工、底层分级决策”的结构,既避免了五个人对每件小事反复开会,又保留了关键方向上的集体纠错能力。

本章小结

  1. 分工原则:五位联创(三位 USC 校友与两位前同事)按个人兴趣与专长切分为产品工程(2人)、市场销售(2人)和运营(1人),各自在专注领域建立深度。
  2. 决策与制衡:绝大多数日常小事由领域负责人直接拍板;重大方向由五人商量达成共识,依靠相近的股权分配理念与朋友信任基础,把争论转化为对事不对人的纠错机制。
  3. 组织生长:运营部门并非预先空转搭建,而是李正韬从早期写代码搭基建出发,随着收款、招聘、IT 访问控制等真实需求出现而逐步演化出的职能体系。

从自然传播到长期企业交付

五位联合创始人明确分工并逐步搭起运营体系后,业务迎来了真正的市场考验:当一款语音产品靠社区自然传播引爆流量、甚至把服务器撑爆之后,团队如何筛选出最有长期价值的场景,并通过严苛的合规与系统集成考验,把早期的试用热度转化为 CVS 等大型企业的长期合作?

传播带来流量,产品承接使用

产品方向一旦贴近真实需求,市场反馈往往首先体现在自发的试用与分享上(48:08)。Retell AI 上线时,团队将产品同步发布在 YC 论坛、Hacker News、Product Hunt、Twitter 和 LinkedIn 等社区。早期用户测试后惊讶于语音对话像真人一样自然,由此形成自然传播;随后 Garry Tan、Paul Graham、Aaron Levie 等业界人士转发,瞬间引爆流量并导致服务器过载。面对突发流量,团队的行动非常直接:服务器满了就立刻扩容修复,用户在社区提问就逐一解答。李正韬在访谈中强调,营销必须建立在好产品之上,如果产品本身没用,哪怕全世界都看了一遍也不会产生任何留存。

承接这波流量的商业模式是基于用量的计费机制(49:24)。客户在平台上配置好不同参数的语音助手后,系统会设定对应的每分钟价格,并按实际通话时长计费,逻辑类似于大模型按 Token(词元,模型处理文本的计费单位)收费。由于初期作为开放平台上线,用户构建的场景五花八门,甚至有人用来给“AI 女友”打电话。团队在观察了大量自发涌现的用法后,主动从中筛选长期成功率与商业价值最高的方向,最终将主攻目标收敛到大型企业的 AI 客服中心。

CVS 案例与组织层面的交付

在 Retell AI 的发展历程中,客户群体的拓展呈现出从小到大的演进过程(50:43)。一开始团队面对的全是小客户,小客户自助使用产品,遇到问题拉个群就能提供客服与售后指导;小客户使用后形成背书,慢慢吸引来中型客户。到了中型客户阶段,采购开始涉及更多法务与合规要求,例如会对公司做背景调查、询问是否具备 SOC 2 合规(SOC 2 compliance,针对服务商安全性、可用性等内部控制的独立鉴证报告体系)。在中型客户使用之后,大型企业客户也随之进入。

攻克美国大型连锁药店零售商 CVS 的过程,直观展现了大客户高标准的合规要求对初创公司的改变(51:26)。为了满足大客户的合规需求,团队近期在办公室安装了创业初期根本想不到的门禁系统,并在电脑上部署防火墙等安全措施。李正韬从保护客户信任的角度解释这些动作:如果不去满足客户的这些安全与合规要求,就不应该接下客户;因为一旦发生数据泄露,或者出现员工已经离职却还能看到公司系统等情况,本质上是在伤害客户、辜负信任。

在推进大客户销售与系统集成(Integration)时,团队配备了销售与 FDE(前线部署工程师)团队。据李正韬在访谈时介绍,这部分团队已从最初的 7 人扩大到约 10 人,并计划再增加约 20 个招聘名额(Headcount),在这一方向上三倍加码(Triple down)(53:23)。他以自己采购软件时遇到销售过度承诺(Overpromise,夸大产品现有功能或易用性)的糟糕体验为例指出,大企业愿意采用一家比自己小得多的公司的产品,下了很大决心并给予了极高信任;因此团队在研发、销售到合规的各个环节都追求扎实兑现承诺(Deliver),到了这一阶段,把事情做好比单纯追求表面速度更重要(53:46–55:24)。

客户价值怎样进入下一阶段投入

当越来越多公司加入语音 AI 赛道、声音自然度与实时性不断提升时,李正韬认为真正的难点在于从演示版本(Demo)走向生产环境(Production)(56:45)。他回忆说,如果只是做一个演示版本,他们自己三年前就已经做出来了;但宣传有产品,与真正有客户在生产环境中使用并拿到价值,完全是两回事。据他介绍,在客户发起的 RFP(Request for Proposal,提案征询)评测中,客户经过对比测试认为他们的产品表现最好,因此常在采购中选择他们。在内部时间分配上,他估计团队花在营销上的时间相对产品而言最多占 10%,大部分时间都用来讨论产品、收集客户反馈并打磨体验,力求确定能为客户带来十倍、百倍的帮助与价值(52:28)。

在李正韬看来,只要从第一性原理出发为客户提供更多价值,自然会带来更多营收(Revenue),只是这中间存在一定的时间转化周期——例如今年提升了客户价值,营收未必立刻暴涨,但到第二年客户继续使用和续约时就会体现出来,回报周期可能在 12 个月或 24 个月左右(59:00–59:42)。基于这一判断,团队计划将积攒的盈利投入三个长期重点项目(Initiatives)(57:42–59:00):

  1. 扩展产品覆盖面(Product surface):从现有的 AI 语音平台延伸至人与人通话场景,计划涉足面向人工坐席的独立 SaaS 平台,使企业无论发起 AI 通话还是人工通话都能在同一套系统内完成;同时探索针对以语音通话为主要沟通渠道(Channel)的客户开发专用系统,以替代其现有的 Salesforce 或 HubSpot 等 CRM(客户关系管理系统);
  2. 深化模型后训练:招募 AI 研究员(AI researcher),开展更多模型的后训练工作;
  3. 扩充销售与部署团队:招募更多销售人员与前线部署工程师(FDE),帮助更多大客户完成系统部署(Deployment)。

实战误区:把演示效果与过度承诺当成企业级竞争力

在语音 AI 赛道,录制一段流畅的通话 Demo 或在销售阶段夸大功能(Overpromise),或许能换来一时的关注或首月订单。但进入企业采购的 RFP 实测与生产环境后,缺失的功能、不稳定的连接以及权限合规漏洞会迅速暴露。一旦客户发现承诺无法兑现或存在安全隐患,不仅第二个月就会流失,还会彻底破坏创业公司在行业内的信誉。

概念解析:为什么企业采购看重 SOC 2 与权限控制

大型企业将呼叫中心业务交给外部平台时,高度重视数据安全与访问控制。SOC 2 是针对服务机构安全性、可用性等内部控制的独立鉴证报告体系,它并非“绝对零泄露的保证书”,而是核验企业是否建立并执行了有效的安全控制措施。在访谈案例中,为了满足 CVS 等大客户的合规要求、防范数据泄露或离职人员越权访问系统等风险,团队专门落实了办公室门禁、电脑防火墙等具体管控动作。

客户阶段 核心诉求与接入方式 Retell AI 的应对与交付机制
早期小型客户 快速试用语音助手,按配置与分钟用量付费 保障服务器运转,通过建群提供客服与售后使用指导
中型企业客户 采购涉及更多法务审查与安全合规要求 接受公司背景调查,满足 SOC 2 合规等要求并积累背书
大型企业客户(如 CVS) 经 RFP 评测,要求深度系统集成与严密合规管控 配备销售与 FDE 推进集成,落实门禁与防火墙等安全要求
不同阶段客户的服务方式与交付重点对照

当一款技术产品通过社区转发获得初期爆发后,怎样才能避免沦为“试用即走”的玩具?下图梳理了将早期流量沉淀为长期企业合作的四个关键台阶。

从自然传播到长期企业交付(依据节目口述整理 · 47:50–59:58)
从自然传播到长期企业交付(依据节目口述整理 · 47:50–59:58) 下载 PDF 原图

读图:从自然传播到长期企业交付

图中上方自左向右展示了企业交付的四个递进节点:首先通过“试用与评估”承接客户的“真实通话任务”;接着进入“工作流集成”,协助客户完成“现有系统迁移”;随后在组织层面落实“运营要求”,严格把关“权限与合规”;最终实现“持续使用”,在业务运转中形成“反馈与续约”。下方的横框总结了贯穿全程的时间尺度差异:短期靠“可用的演示让人愿意试”,长期靠“承诺的功能稳定进入业务”。

这套演进路径说明,创业初期需要极快的产品迭代来抓住自然流量,而进入大客户交付期后,扎实的系统集成与合规建设才是留住收入的根本。

本章小结

  1. 早期增长:依靠自然的语音体验在技术社区引发自发传播与业界转发,通过按分钟用量的计费模式承接需求,并从开放平台用法中选定大客户 AI 客服中心作为主攻方向。
  2. 深度交付:历经小、中、大客户的演进,在服务 CVS 等大企业时落实门禁与电脑防火墙等合规要求,拒绝过度承诺,依靠销售与 FDE 团队扎实推进系统集成。
  3. 长期投入:将主要精力放在创造客户价值上(自述营销时间相对产品最多占 10%,价值转化周期约 12–24 个月),计划将盈利投入人工坐席平台与语音 CRM 方向、模型后训练以及扩充销售与 FDE 团队。

招聘与激励如何支撑产品质量

既然团队计划在产品扩展、模型后训练与企业级部署上持续投入,并准备再招募 30 多名新成员,一个新的管理难题随之浮现:在兑现客户承诺比单纯追求速度更重要的阶段,怎样选拔和激励人才,才能确保团队扩张后产品质量不滑坡?

从做题转向真实工作表现

为了支撑企业级交付与新产品线的研发,团队需要持续扩充人才,但传统技术面试往往依赖 LeetCode(算法题平台,常用于考察标准化编程题),容易筛出擅长刷题应试却未必适应实际工程开发的人。李正韬在访谈中指出(59:58),员工入职后绝大多数时间都在处理具体的工程任务,因此招聘的核心应当是还原真实工作场景,直接测试候选人解决实际工程问题的能力。

围绕这一思路,团队在招聘中完全取消了算法刷题,改用两类贴近实战的评估方式(01:01:29):

  1. Practical coding(实战编程):考察候选人动手编写实际工程代码的能力,让平时工作繁忙、没有时间专门刷题准备面试的工程师,也有机会通过面试展现真实水平。
  2. Work trial(试岗):这是一种针对特定情况的补充评估机制,并非所有候选人都需要参加。如果候选人在某一轮面试中展现出很强的能力,但在终面时发挥不够理想,团队可以邀请其利用在其他公司请假的时间来实际工作一个星期(无需先辞去原有工作),让双方在真实工作环境中互相观察表现。

即使设计了实战编程和试岗,李正韬依然坦承面试本质上是一个“有损的评估过程”(01:02:21)。要在短短几个小时的接触中衡量一个人的真实工作能力,必然伴随信息损失(Loss)和干扰(Noise)。为了在严格的筛选标准下持续推进招聘,团队在招聘端投入了专门人力:据李正韬在访谈时介绍,当时公司共有 50 名全职员工(Full-time employees)和 50 名合同工(Contractors),其中专门负责招聘(Recruiting)的就有 2 名全职员工和 10 名合同工(01:02:40)。

文化、潜力与技能的顺序

除了改变考察形式,李正韬在实践中反思并调整了评估候选人的维度顺序。他坦言自己过去常犯的一个错误,是按照“工作技能(skills)\(\rightarrow\) 学习潜力(talent)\(\rightarrow\) 文化契合度(culture)”的顺序去衡量候选人,而在实际带团队的过程中,他意识到正确的评估顺序应当完全反过来(01:00:18)。

调整后的评估顺序依次为:

  1. 文化与兴趣(Culture):首先看重候选人是否真心觉得所做的事情有意思、能否认可公司文化,以及是否认为这份工作能产生价值并能从中学习,而不是仅仅将其当成一份差事(01:01:13);
  2. 学习潜力(Raw talent,天赋/学习速度):在算法与 AI 工具快速演进的环境下,过往经验多是加分项(Plus),但更重要的是候选人足够聪明,能够很快掌握(Pick up)新算法、新 AI 工具并适应创业环境;
  3. 工作技能(Skills):在确认文化契合度与学习潜力之后,再衡量当前的具体技能。

李正韬坦言,自己直到受访时有时仍会犯先看技能的错误,但他明确意识到应当把文化认同与快速学习的能力放在前面。这种选人逻辑,与前文所述创始人先把业务跑通、再寻找优秀人才来承接的思路一脉相承。

让员工分享长期成果

高标准的筛选与高强度的工作投入,需要相匹配的薪酬与福利机制来支撑。李正韬按受访时的标准介绍,公司将薪资目标设定为市场前 5%(Aim for top 5% of the market),同级别岗位的薪酬预计高于 Meta 或 Google 等大厂(01:03:06;01:04:04)。在工资总包之外,公司还提供了覆盖日常生活的额外福利(01:03:15):

  • 餐饮补贴:每人每天享有 70 美元的 DoorDash(外卖平台)额度,无论在家或是在办公室上班均可自由点餐;
  • 通勤福利(Commuter benefits):每月 300 美元,可用于抵扣打车、私家车加油或车险等费用;
  • 健康福利(Wellness benefits):每月 300 美元,可用于健身房、购买 Oura Ring(智能戒指)或助眠产品订阅等;
  • 保险福利:公司另外提供保险方案。

设计这套福利体系的想法非常直接:除了房租之外,尽量帮员工解决生活中的所有其他事务,让大家能把时间专心放在工作上(01:03:59)。在长期回报层面,李正韬表达了团队的心愿:如果未来公司实现退出(Exit,指通过首次公开募股 IPO 或其他方式实现股权变现),他们的目标是希望每一位员工都能实现财富自由(01:04:12–01:04:48)。在他看来,大家一起辛苦工作创造价值,如果最终只有创始人自己财富自由而员工未能实现,是一件不公平且会让他感到内疚的事。

回看全篇访谈,这家语音 AI 公司的成长脉络呈现出清晰的阶段演进:在从零到一的早期探索期,团队依靠快速试错、抢抓技术窗口与密集的业余项目练习,用极高的执行速度找到市场验证;而在进入大客户服务与规模化扩张阶段后,团队则将重心转向扎实的工程交付、合规建设与高标准的人才培养。清楚区分早期试错的速度与后期企业级交付的稳健,并用匹配的组织与激励机制加以支撑,正是把前沿 AI 技术做成企业愿意长期付费产品的关键所在。

常见误区:把“技能熟练度”当成招聘的首要筛选标准

许多团队在急需扩充人手时,习惯先按既有技能和过往经验打分,最后才顺带考察文化契合度。李正韬结合自身踩坑经验提醒(01:01:00),这种顺序容易招到虽然熟练但缺乏内在动力或难以适应新工具的人。在技术与工具快速演进的创业环境中,更稳妥的做法是先确认候选人是否真正认同工作价值与团队文化,再考察其快速掌握新算法的原生潜力(raw talent),最后才评估当前的工作技能。

概念解析:试岗(Work Trial)为何能弥补传统面试的信息损失

传统面试通常只有几个小时,面试官只能通过问答或短时编程题进行间接推演,李正韬将其形容为带有信息损失(loss)和干扰(noise)的“有损评估过程”(01:02:21)。试岗(work trial)则提供了一种高保真的补充观察窗口:当候选人在单轮面试中展现出亮眼特质但终面表现存在不确定性时,邀请其利用假期参与一周真实项目开发,既无需候选人冒险裸辞,又能让双方在真实代码库与日常沟通中验证协作质量。

管理维度 具体机制与标准 支撑的产品与组织目标
考察方式 实战编程与适用时的试岗(Work trial),不考 LeetCode 考察真实工作表现,弥补几小时面试的信息损失与干扰
评估顺序 文化与兴趣 \(\rightarrow\) 学习潜力(Raw talent)\(\rightarrow\) 工作技能 优先看重对工作价值的认可及快速掌握新算法、新工具的能力
日常薪酬福利 薪资目标瞄准市场前 5%;配每日 70 美元餐饮、每月各 300 美元通勤与健康福利及保险 解决除房租外的日常琐事,让员工专心投入工作
长期回报愿景 希望在公司未来退出(如 IPO)时让员工都能实现财富自由 以共享长期成果为目标,匹配高强度投入与高标准筛选
Retell AI 招聘评估与激励机制对照

当公司计划扩充约 30 个岗位以支撑企业级交付与新产品研发时,如何避免招来不合适的人稀释产品质量?下图展示了团队的人才选拔顺序与配套支撑机制。

招聘与激励如何支撑产品质量(依据节目口述整理 · 59:58–65:03)
招聘与激励如何支撑产品质量(依据节目口述整理 · 59:58–65:03) 下载 PDF 原图

读图:招聘与激励如何支撑产品质量

图中上方三个横向串联的节点展示了团队调整后的候选人评估顺序:首先考察“文化与兴趣”,确认候选人是否“认可工作价值”;接着指向“学习潜力”,看重其能否“快速掌握新工具”;最后指向“工作技能”,检验其能否“实际完成任务”。下方宽框则给出了支撑这一选人标准的两个落地抓手:在“观察方式”上采用“实战编程与适用时的试岗”来贴近真实工作;在“激励方式”上则通过“薪酬、福利与共享长期回报”来匹配高标准的筛选与投入。

通过将选人重心前置到文化与潜力,并用实战考核与高水平激励托底,团队得以把早期创始人的个人执行力转化为组织层面的稳定交付能力。

本章小结

  1. 考核贴近实战:取消 LeetCode 算法题,采用实战编程与特定情况下的试岗机制;受访时公司 50 名全职员工与 50 名合同工中,有 2 名全职员工与 10 名合同工专门负责招聘。
  2. 反转评估顺序:按“文化与兴趣 \(\rightarrow\) 学习潜力 \(\rightarrow\) 工作技能”的顺序衡量候选人,优先看重候选人对工作价值的认同及快速掌握新工具的能力。
  3. 高标准激励托底:薪资目标瞄准市场前 5%,额外提供每日餐饮、每月通勤与健康补贴及保险方案,并以未来公司退出时希望全员实现财富自由为目标,支撑长期的扎实交付。

总结与延伸

回顾 Retell AI 的成长路径,最核心的启示在于创业团队如何根据发展阶段动态调整重心。在从零到一的探索期,团队当时判断大模型等新技术出现后的机会窗口通常只有两到三年,因此没有把时间花在空想完美赛道上,而是借助业余开发、导师纠偏与密集迭代,先后推翻作文批改、直播翻译、去口音与单点语音合成等过渡方向,通过高频执行去获取真实的市场验证。在这一阶段,团队内部也保持着极强的组织克制:五位联合创始人先亲手跑通产品研发、底层基建与早期业务标准,直到自述年收入达到约 300 万美元时才招入第一位工程师。

随着产品通过社区自然传播引爆流量,并循着小型、中型客户逐步向大型企业核心业务演进,竞争的分水岭便从“能否做出惊艳的演示”转向“能否在生产环境中稳定兑现承诺”。面对实时语音严苛的延迟要求,以及部分大型企业长达近一年的呼叫中心迁移周期,团队采取了“标准化语音平台 + 前线部署工程师(FDE)最后一公里工作流交付”的混合模式;同时,随着收款、扩招与大客户安全审查等真实需求浮现,公司逐步生长出运营、IT 与合规体系,落实办公室门禁、电脑防火墙与权限管控等企业级交付要求。

为了支撑这一阶段的交付质量与长期产品拓展,团队将选人顺序调整为“文化与兴趣 \(\rightarrow\) 学习潜力 \(\rightarrow\) 工作技能”,用实战编程与特定情况下的试岗替代传统算法刷题,并以瞄准市场前 5% 的薪酬目标、完善的日常福利以及未来共享退出回报的心愿来凝聚人才。早期靠高频执行与快速迭代寻找方向,后期靠扎实工程、合规建设与组织体系承接大客户信任,这两套能力的适时切换,构成了把前沿语音 AI 技术做成企业愿意长期付费产品的完整路径。

拓展阅读

以下资料供回看节目、查阅术语与继续学习。