粘菌公司：Perplexity 如何用 250 人做出 5 亿美元年收入

250 人，年收入 5 亿美元。这个数字放在任何行业都是异常值——人均创收约 80 万美元，接近 Google 的一半，是传统 SaaS 公司的三到四倍。1

Perplexity 不是靠压榨员工做到这个数字的。在联合创始人 Johnny Ho 眼里，这是一套有意识设计出来的组织逻辑——从团队结构到沟通方式，几乎每一个决策都在服务同一个目标：让每个节点都能自己做决策，不用等人。

Perplexity 2022 年由四位联合创始人共同创立：CEO Aravind Srinivas、Denis Yarats、Johnny Ho、Andy Konwinski。

Aravind 在联合创立 Perplexity 之前，先后在 OpenAI、Google Brain 和 DeepMind 做研究，研究方向是机器学习和强化学习。Denis Yarats 来自 Meta AI 研究院，Johnny Ho 曾是 Quora 工程师，Andy Konwinski 是 Databricks 的联合创始人之一。2

四个人都是工程和研究背景——公司里没有一个「专职 BD 出身的创始人」。Aravind 自己在多次访谈里坦率说过，他的联合创始人在技术执行层面都比他强：「他们比我更懂工程，执行力更强，更会管项目，更会做交易。我这个 CEO 只能算各方面都还行的多面手。」3

这个起点塑造了 Perplexity 的组织底色：一家从研究员习惯出发设计协作方式的公司，而不是从管理流程出发。

Perplexity 全公司只有 2 名全职产品经理——一名负责 Web 端，一名负责移动端。未来一年的计划是，最多再招 1 到 2 名，且门槛维持极高。4

这不是预算问题。Johnny Ho 在 Lenny's Newsletter 的访谈里直接说，简历里出现「Agile 专家」「Scrum Master」这类关键词，通常就不匹配 Perplexity 的期待。他们不要善于管理流程、协调他人的 PM，而是要有「产品品味」的工程师——能自己判断方向、能量化用户价值、懂基础统计和编程。

单个项目的团队通常是 2 到 3 人，最复杂的项目最多 4 人。AI 播客功能从立项到上线，全程只有 1 个人负责，没有 PM 参与。

这种配置隐含一个判断：当工程师有足够的产品品味，PM 的价值边际就急剧下降。Perplexity 在赌技术能力足够好的人，可以同时承担「做什么」和「怎么做」两层决策。

Johnny Ho 描述 Perplexity 内部组织方式时，用的是一个罕见的比喻：粘菌（slime mold）。

粘菌没有中央指挥，每个细胞自主决策，但整个群体能协同找到食物源，效率往往高于有层级的组织。被反复引用的 Alex Komoroske 的理论正是这个——有机体在最小化内部协作摩擦的前提下保持整体目标对齐。4

落到具体操作上，Perplexity 的「粘菌」方式体现在几个地方：

人员分工文档公开且持续更新：任何人需要对接另一个人，直接查文档联系，不用通过中间层。

项目并行而非串行：一个功能启动后，设计、前端、后端、业务侧会同时开工，不等上一个环节交付。Johnny Ho 说这是主动把可以并行的任务拆解出来，让阻塞点尽可能消失。

完成后主动广播，不经审批上线：功能做完先在内部试用（dogfooding），获得内部认可后，在 Slack 里分享，收到反馈，直接发布。没有层层审批，小优化甚至可以直接上线。

Slack 有专门的 brainstorm 频道，想法收集在 Linear：Discovery 功能、AI 播客都是工程师和设计师自下而上提出来的，不是产品路线图里提前规划好的。

这套组织方式的前提，是极高的内部信任和对齐。Johnny Ho 也承认，随着规模扩大，这套方式面临新的挑战：Slack 信息量开始爆炸，Linear 的 issue 组织开始需要额外维护成本。如何在规模增长后保留这套扁平特质，是他眼下最主要的执行挑战。

Aravind 在公开场合谈到 Perplexity 的文化时，反复用一个词：extreme bias for action（极度行动倾向）。

他的理由很直接：在 AI 行业，大公司做不到的是「快」。Perplexity 的护城河不是技术壁垒，而是在同样的 24 小时里做出更多决策，发出更多版本。「我们发出 80% 好的产品，6 个月后变成 90%，12 个月后变成 95%——等那时候你追上来，我们又不一样了。」3

这个判断延伸到了会议方式：Aravind 开会不带 PPT，而是直接提问题。他认为从问题出发，比从演示出发，更能快速找到真正的分歧在哪。3

季度规划层面，Perplexity 用类 OKR 机制——所有季度目标可量化，故意设得偏激进，预期完成率约 70%。Johnny Ho 说，完不成的 30% 恰好能暴露出优先级排列和人员配置的真实缺口，比 100% 达成的计划更有信息量。4

Glassdoor 上的员工评价里，有人写「创始人自己每天工作到深夜，工程师们也如此」。Aravind 对倦怠问题的看法是：倦怠通常不是工时长的问题，而是「不得不做自己不喜欢的事、还做了很多」。如果指标在涨、自己做的事有意义，长时间工作不会觉得累。3

这种判断内嵌着一个预设：只招「真的想做这件事」的人。Aravind 说，他愿意给还没有在某领域被证明的人机会，但前提是这个人要对这件事有内驱力，而不只是履历合适。

Johnny Ho 描述 Perplexity 内部使用 AI 的方式，有一句话颇为务实：「AI 不适合写可持续的平台级代码，但足以让你在 5 分钟内开始行动。」4

Perplexity 早期几乎把所有流程问题都先问 AI：如何发布产品、如何写用户升级邮件、如何组织招聘流程。对于小团队来说，这些探索原本可能要花几天——AI 给出一个够用的起点，之后再自然迭代。

对员工的要求也是这套逻辑的延伸：遇到问题先问 AI，再麻烦同事。这条规则的本质，是把「内部沟通」这个协调成本从日常流程里剥离出去，让 AI 承担大量原本需要人类对齐的工作。

现在内部用的工具组合是：Linear 管任务和 bug，Notion 存 roadmap、里程碑、设计文档、RFC 和复盘记录，Unwrap.ai 把用户反馈归类成可操作的主题。工具本身都是市面上现成的，没有内部自研。选工具的标准很简单——够用，且对齐信息的成本低。

一个细节是，Perplexity 员工普遍自己大量使用 Perplexity 做工作。这种内部使用（dogfooding）的密度，让产品迭代的反馈循环比外部用户更紧密，也更快速地暴露 bug 和摩擦点。

一、PM 稀缺是结果，而不是起点。 Perplexity 不是先决定「少招 PM」，而是先找到有产品品味的工程师，发现工程师可以承担绝大部分产品决策之后，才维持了极低的 PM 配置。对应的操作动作：在工程师招聘里把「对用户场景的判断力」作为显性维度，而不是只看技术栈——能说清楚「这个功能解决什么用户问题」的工程师，比「会写 Leetcode hard」的工程师更适合这套组织方式。

二、AI 替代内部沟通，比替代外部招聘更先奏效。 Perplexity 没有用 AI 大量替换员工，但用 AI 替代了大量「内部问人」的协调成本——每个人先问 AI，只有 AI 给不了答案时才找同事。这个逻辑在大公司同样适用：组织效率的瓶颈往往不是人不够，而是人与人之间的对齐成本太高。触发条件：当你发现团队花大量时间在「确认对齐」上时，这类工作优先试试 AI 兜底。

三、故意设置完不成的目标，是一种信息收集机制。 70% 完成率的激进季度目标，在 Perplexity 的逻辑里不是管理失败，而是有意设计的——未完成的 30% 精确暴露了「人力不足」还是「优先级排错了」还是「有隐性依赖没被发现」。对应操作：每个季度结束后，主动分析每一条未完成目标的原因类别，比只看「完成率」能得到更有用的组织洞察。

参考来源：本文核心素材来自 Lenny's Newsletter 对 Johnny Ho 的访谈（lennysnewsletter.com）、Business Insider 对 Aravind Srinivas 的专访、UC Berkeley Haas 演讲实录，以及公开财务数据报道。5