他拯救了 OpenAI、发明了“Like”按钮，并打造了 Google Maps：Bret Taylor（Sierra）

Bret Taylor 2025-07-31

他拯救了 OpenAI、发明了“Like”按钮，并打造了 Google Maps：Bret Taylor（Sierra）

文字稿

开场片段

Lenny Rachitsky： 你是 Meta 的 CTO，是 Salesforce 的联席 CEO，也是 OpenAI 的董事会主席。你认为 AI 市场将如何演变？

Bret Taylor： 整个市场都将走向智能体（agents）。我认为整个市场都将走向基于结果的定价模式。这显然是构建和销售软件的正确方式。

Lenny Rachitsky： 这让我想到，我之前请过 Marc Benioff 来做播客。你们曾一起担任联席 CEO。他对智能体的信念极其坚定。

Bret Taylor： 销售生产力软件太难了，这是我亲身领教过的。

Lenny Rachitsky： 提到你最大的失误时，你脑海中浮现的故事是什么？

Bret Taylor： 我当时是一个产品的产品经理，那个产品叫 Google Local，和 Marissa 以及 Larry 做了一次相当艰难的产品评审，而且在 Google 首页有链接加持的情况下表现不佳，实在令人尴尬。

Lenny Rachitsky： 我觉得让人们听到这样的故事很有启发——即使经历了如此巨大的失败，依然有可能取得成功。

Bret Taylor： 他们给了我另一次机会去做 V2 版本，最终诞生了 Google Maps。上线第一天就有大约一千万用户在使用。

Lenny Rachitsky： 是什么样的心态帮助你在如此多样的角色中都取得了成功？

Bret Taylor： 每天早上醒来，问自己：今天我能做的最有影响力的事情是什么？

Lenny Rachitsky： 今天的嘉宾是 Bret Taylor。Bret 是一位绝对的传奇级建设者和创始人。他在 Google 联合创造了 Google Maps。他联合创立了社交网络 FriendFeed，发明了点赞按钮和实时新闻流，后来将其卖给了 Facebook。随后他成为 Facebook 的 CTO。之后他创办了一家名为 Quip 的生产力公司，以 7.5 亿美元卖给了 Salesforce。然后他成为 Salesforce 的联席 CEO。他目前还担任 OpenAI 的董事会主席。曾一度担任 Twitter 的董事会主席。如今，他是 Sierra 的联合创始人兼 CEO，这是一家 AI 公司，致力于构建智能体来帮助企业处理客户服务、销售等业务。

在我们的对话中，我们涵盖了许多话题，包括哪些技能和心态最能帮助 Bret 在如此多的角色中取得成功，为什么我们都仍然低估了智能体对商业世界的影响力，编程在未来几年将如何变化，初创公司最大的机会在哪里，AI 领域定价和推向市场的经验教训，点赞按钮背后的故事等等。这是一次与传奇建设者真正史诗级的对话。

（此处跳过广告段落）

失败角落：Google Local

Lenny Rachitsky： Bret，非常感谢你能来，欢迎来到播客。

Bret Taylor： 谢谢你的邀请。

Lenny Rachitsky： 我的荣幸。我想聊的内容太多了。你的职业生涯中做了太多令人难以置信的事情，你所取得的成就令人叹为观止，我们会聊到很多这些，但我想从相反的方向开始。我想聊聊你搞砸的一次经历，一次重大失误。我们的播客有一个固定环节叫”失败角落”（Fail Corner），所以我觉得在我们聊你的所有伟大成就之前，从这里开始会很有趣。当你想到自己在构建产品方面的最大失误时，脑海中浮现的故事是什么？

Bret Taylor： 也许不是最大的，但这是我在 Google 担任产品经理时第一个引人注目的失误。对我来说它感觉很重大，因为它对我作为产品设计者的成长影响深远。我在 2002 年底、2003 年初加入 Google，是公司最早的一批 associate product manager 之一。起初我在搜索系统工作，主要是将我们的索引从 10 亿个网页扩展到 100 亿个，这在当时是一件大事，虽然现在看来微不足道。之后我做得还不错，我的老板 Marissa Meyer 就给了我一个机会来领导一个新的产品项目，这对我来说是一次重大的押注，既是一个为 Google 做贡献的机会，但作为一个年轻的新产品经理，我也受到了相当严格的审视。分配给我的任务是做本地搜索。

当时黄页（Yellow Pages）仍然占据主导地位。Google 擅长搜索网页，但在找水管工或餐厅方面并不擅长，主要是因为当时互联网上这类内容并不算多。这些内容不一定存在于互联网上，即使存在，你也不太想找曼哈顿的水管工——如果你是我的话，你更想找旧金山的水管工。所以这既是一个技术问题，也是一个产品问题和内容问题。

我作为产品经理负责的那个产品的第一个版本叫做 Google Local。现在我可以比当时更苛刻地评价它——它基本上就是雅虎黄页的跟风之作，本质上是在 Google 搜索之上嫁接了黄页搜索功能。如果你构造了恰当的查询，可以在搜索结果顶部看到那些列表，同时还有一个独立网站 local.google.com。事实上，这个项目足够重要，Google 首页上有 Web、Images 和 Local 的入口，所以它得到了最高的展示位。

Google Local 的挫败与 Google Maps 的诞生

Bret Taylor： 说实话，你几乎可以把任何链接放到 Google 首页上，都能获得巨大的流量。但尽管如此，那个产品表现并不好——在拥有 Google 首页链接的情况下表现不好，说实话挺丢人的。作为产品负责人或产品经理，别人能给你的支持，几乎也就到这个程度了。产品本身没什么问题，能用，但确实没有什么差异化优势。在很多方面，我现在回想起来比当时更清醒——当时也有些感觉，但毕竟不够清晰——为什么用这个而不用雅虎黄页？更重要的是，为什么用这个而不用传统的黄页？它只是把已有的东西做了一个数字化版本。我和 Marissa、Larry 等人做了一次非常严厉的产品评审，结果还行，我倒不至于被开除什么的，但怎么说呢，我身上那层光环确实有点黯淡了。

他们给了我另一次机会去做 V2。我的感觉是这还不至于说是最后一次机会，但从一个炙手可热的新 PM 变成一个需要重新证明自己的人，心里确实有点沮丧。所以我们花了很多时间思考，怎样才能做出一个真正有吸引力的东西，而不仅仅是黄页的数字化版本，也不仅仅是市面上那些同类产品的翻版。这条线索最终引导我们做出了 Google Maps。我们当时从 MapQuest 获得了授权，可以在搜索结果旁边放一个小地图，但那一直是产品里最难看的部分，我们内部没少说它的风凉话。后来我们花了大量时间讨论：如果我们把这里的层级关系倒过来，让地图成为整个画布呢？

后来我们找到了 Lars 和 Jens Rasmussen，他们当时正在做一个 Windows 地图产品。我们把招他们进了公司，开始探索这个方向。在这个过程中，我们最终整合了很多不同的产品——地图、本地搜索、驾车导航，当时这些其实都是独立的产品品类——最终做出了一个重新定义了整个行业的东西，也彻底改变了我的职业生涯。但我觉得，作为一名产品领导者，这次经历改变了我对产品的认知方式。因为产品有功能和特性，但还有一个更根本的问题：我为什么要用这个东西？其中有几个很有意思的时刻值得一提。

Google Maps 上线第一天就有大约一千万人使用，以当时互联网的规模来看，这个数字非常惊人。然后到了2005年8月，我们整合了刚收购的一家叫 Keyhole 的公司的卫星图像——它后来变成了 Google Earth——当天就有九千万用户涌入。卫星图像一出来，每个人都想看看自己家的房顶。这里面有很多微妙的产品教训。首先，当你面对一项新技术时，与其简单地把过去的东西数字化，不如创造一个全新的体验，这样就能回答一个新用户的问题：我为什么要花时间试这个东西？所以，真正把这套乐高拆散，重新组装成全新的东西，而不是仅仅把原有的东西数字化。Google Maps 的成功经验确实在于——它是真正原生于这个平台的，这是纸质地图无法做到的，这是一个非常有意义的突破。

而卫星图像，坦白说，它并不是 Google Maps 最重要的部分，但它锦上添花，创造了一个——当时人们可能还不太说”病毒式传播”这个词——但它确实创造了一个病毒式传播的时刻。我们上了《周六夜现场》（Saturday Night Live），这简直太酷了。Andy Samberg 在一个叫 Lazy Sunday 的节目里用说唱提到了 Google Maps，Lars 和我互相发短信：我们做到了！我们上了《周六夜现场》！任务完成。这也说明，当你在思考产品时，有一个问题是用户为什么决定使用一个产品，另一个问题是这个产品持久的真正价值是什么。这两者紧密相关，但并不完全是一回事。我从中学到了太多教训，在后来做的每一个产品中都一直在用。

关于职业发展与方法论

Lenny Rachitsky： 这个故事太棒了。我觉得这对很多人来说是很有鼓舞作用的——即使是像 Bret 你这样成功的人——我接下来会分享你取得的所有成就——也一样经历过被 Google CEO 严厉批评的时刻，“Bret，你搞砸了”。而且那是一个很大的赌注。所以，第一，即使经历了这样的重大失败，也有可能像你一样取得巨大的成功。然后你分享的一些产品教训，我想强调其中几点，因为我觉得非常好：如果你只是做一个更好的模仿品，你通常赢不了；你要找的是一个全新的体验，一个有差异化的、更有吸引力的东西。现在让我们换个话题，聊聊你从那些真正成功的事情中学到了什么。

我看了你的简历，你基本上在职业阶梯的每一层都非常成功，而且涉猎的角色种类之多令人惊叹。让我为那些不太熟悉你背景的人念几个：你是 Meta 的 CTO，你是 Salesforce 的联席 CEO，同时也在 Salesforce 担任过 CPO 和 COO。在 Google，你以 associate product manager 的身份加入，众所周知——你没提这个——你在一个周末重写了 Google Maps。这个我们就不展开了。你是 OpenAI 的董事会主席，也曾任 Twitter 的董事会主席。你还创办了三家公司，一个社交网络，一个生产力文档公司 Quip，以及现在的 Sierra。一个有趣的冷知识：在 FriendFeed，你发明了点赞按钮，我不知道大家是否知道这一点，还有新闻信息流，顺便也归功于你。

所以你做过 associate product manager、独立贡献者级别的产品经理、工程师、CPO、COO、CTO，还是三家不同公司的 CEO，其中包括一家上市公司。一个人在所有这些角色和层级上都能取得成功，这非常罕见。那么我想直接问：你觉得自己培养了哪些心态、习惯或者工作方式，是你认为最能帮助你在这如此多样的角色和层级中取得成功的？

Bret Taylor： 这个问题很好，这确实是我引以为豪的一点。我喜欢自己戴过不同的帽子。其实挺有趣的，当我遇到那些在某一份工作中认识我的同事时，他们往往会通过那份工作的视角来看待我。比如我遇到 Facebook 的同事，他们主要把我看作一个工程师；遇到 Google 的同事，他们主要把我看作一个产品人；在 Salesforce，很多同事和我互动时更多把我当作——没有更好的说法——一个”穿西装的人”，一个老板。他们可能完全想不到我还是个工程师，尽管那时我周末可能还在写代码自娱自乐。我的一条原则是，对自己的身份保持一种非常灵活的认知。如果要自我描述的话，我大概会说自己是一个工程师，但更广义地说，我认为自己是一个 builder（建设者），我喜欢打造产品，而我认为公司是打造产品最有效的载体之一。

当然也有开源这样的方式，但我深信科技与资本主义的交汇能为客户创造出非凡的成果。因此，我认为要真正打造出有影响力的东西，要成为一个出色的创始人，你真的不能对自己的身份有那么僵化的认知，以至于无法转变为公司在那个阶段需要你成为的角色。你跟任何一个创始人聊天，总有一天你会发现，销售是做创始人很重要的一部分。你需要说服投资者投资你的公司，说服候选人加入你的公司，说服客户使用你的产品。你需要有好的设计品味，不仅仅是对产品，还包括对市场营销，本质上是在吸引你的客户。

你还需要过硬的工程能力。如果你在打造一家科技公司，技术永远是第一位的。这也是这个行业之所以如此具有变革性的原因。我可能要归功于——这个我以前也讲过——但我非常感激她——我大概要归功于 Sheryl Sandberg，是她真正改变了我面对新工作的方式。这个故事我可能有些夸大，但大体是准确的。当时我刚成为 Facebook 的 CTO，一开始这个 CTO 的角色是一种……向我汇报的团队相对较小，但我几乎是以非常资深的架构师身份参与了很多项目。后来到了某个节点，Mark Zuckerberg 对公司进行了重组，把它分成了好几个不同的业务组。我最终接管了一个非常大的团队，有100人……不对，上千人直接或间接向我汇报，我基本上在负责我们的平台和移动业务团队，涵盖产品、设计、工程。

所以我从只有几个直接下属，变成了——我也说不清——超过1000人或者更多的规模。那是一个很大的团队，也是我管理过的最大规模。我在 Google 时当过管理者，但只是一个不大的团队。所以我当时做得还行，但不算好。然后有这么一个时刻，Sheryl 看到了我，我记得我在给一个合作伙伴改演示文稿，就因为我收到的那个文稿达不到我的质量标准，我一边改一边抱怨。她把我拉进一个房间，给了我一番谈话，大意是关于如何让团队达到和我一样高的标准。如果有人达不到我的期望，我的计划是什么？是帮他提升还是让他离开？基本上就是在给我上管理一对一。

她是一位非常出色的导师，她能给你非常直接、有时甚至让人不太舒服的反馈，但你知道她是真心关心你。所以那种反馈你是会听进去的。那天晚上我回家后一直在反复想这件事，心里很不痛快。你会本能地在那种时刻变得有点防御性——她说的是真的吗？我真的搞砸了吗，还是她反应过度了？然后第二天醒来，我心想，“不，她说得对。“我意识到自己有一个潜意识里的限制器，在限制我在这份工作中的表现，那就是——我一直试图让这份工作去适应那些我以为自己喜欢做的事情。所以我花了大量时间在一些我感兴趣的产品和技术事务上，心想我是老板嘛，我应该专注于我想专注的事情，而不是去思考：好吧，我在负责 Facebook 的移动和平台团队，今天做什么才是让我们的移动业务和开发者平台成功的最重要的事情？

当我用这种方式重新定义这份工作时，我做的事情就不一样了。而最大的惊喜是——我居然喜欢上了这些事。我原以为自己喜欢的是工程和产品，但实际上，当我改变了一个组织，让它变得更成功的时候，我从那种成功中获得了极大的快乐。我们的开发者平台有很多合作伙伴，当那里出了问题，我花时间处理合作伙伴关系，问题解决了，平台变得更健康，合作伙伴也更成功了——我为这种成功感到自豪。然后我就开始变得更擅长自己的工作了。我意识到，实际的工程行为也好，产品设计也好，所有那些我以为自己喜欢的事情——我真正喜欢的其实是影响力。

所以，那次对话之后，我每天早上醒来——有时真的是字面意义上的醒来，但更广义地说——都会问自己：“今天我能做的最有影响力的事情是什么？“几乎就像是有了一个外部顾问团在告诉你：如果你专注于哪些事情，就能最大化实现你目标的可能性？有时候是招聘，有时候是产品，有时候是工程，有时候是销售。我对自己应该专注于什么变得更加自省了，也变得更愿意去做那些以前我会说不是自己最喜欢的事情，因为我从创造影响力中获得了如此多的满足感，以至于我现在享受的事情比以前多得多。所以，我真的要归功于 Sheryl，我非常感激她。其实还有一点很有意思，就是我现在给别人反馈的时候常常会想到这件事，想到那些能改变你职业轨迹的时刻。我把这一切都归功于她。

Lenny Rachitsky： 有太多人分享过 Sheryl Sandberg 给他们建议并由此改变了他们人生的故事了。她真是一位了不起的人。

Bret Taylor： 是的。

“今天最有影响力的事”

Lenny Rachitsky： 我从中最大的收获就是这个问题——“我今天能做的最有影响力的事情是什么？“这真是一个非常有力的启发式原则，值得时刻记在心里。就像你说的，你可能会发现自己并不想做销售或者招聘，但如果那是最有影响力的事，你做了之后，可能会发现：我喜欢这件事，而且我擅长这件事——

Bret Taylor： 我能在这一点上再展开说一下吗？

Lenny Rachitsky： 当然。

创始人的”错误叙事”陷阱

Bret Taylor： 我认为这其实很难。创始人和产品经理面临的一个危险——尤其是创始人——就是错误的叙事。比如告诉自己”人们不喜欢我的产品是因为 X”。如果你对自己这么说，也对团队这么说，突然之间，它就从一个直觉变成了一个事实。那你最好祈祷你是对的，因为如果你围绕修正一个问题来制定战略，而你又搞错了，你的公司就会失败。那么你为什么丢了一单生意？你可以去跟负责那个客户的人谈，或者也许当时有产品经理也参与了那次沟通。在这些时刻保持 intellectual honesty（智识诚实）非常重要，因为你可能会说，“哦，他们没买是因为平台太贵了。“这可能是销售人员会说的话。

但也许真正的原因是他们其实没有在你的平台上看到太多价值。所以传达给销售人员的信息是”太贵了”，但实际上问题是产品差异化不足。你可能因此陷入一场关于定价的讨论，而实际上背后有一个更深、更难解决的问题。就像你跟人分手的时候，你不会说”是因为我不再喜欢你了”，你会说”不是你的问题，是我的问题”。你会说各种好听的话，因为我们都是社会性动物，你想和周围的人保持和气。所以，直接把客户说的话，或者用户在焦点小组或可用性研究中说的话当成事实，这很少是正确的。它往往和真相有一定关联，但把这一点搞清楚非常重要。因此，我觉得我观察到的一个现象，尤其是对初次创业的创始人来说，就是你们往往会基于自己的技能特长成为”单一议题投票者”。

如果你是一位出色的工程师，你公司里几乎每一个问题的答案都是工程。如果你是产品设计师，答案几乎就是——我开玩笑说的——那种典型的重新设计，就像消费品里的死薪金帽一样，总觉得”下一次重新设计就能解决所有问题”。我不知道这招有没有真正奏效过。然后我也见过很多来自商务拓展背景的创业者，他们总是在想合作关系——“哦，只要我们把这个合作谈下来、把这个分发渠道搞定，一切都会改变。“我觉得作为创始人，非常重要的是要有自知之明：你会自然地、下意识地选择自己最擅长的东西、自己的超能力，作为解决更多问题的方案。事实上，如果你认为那就是解决问题的办法，它可能是对的，但你默认应该先质疑它。

如果你认为自己整个职业生涯一直在做的事就是解决问题的办法，那至少有 30% 的可能，你选择它是因为舒适和熟悉，而不是因为它是对的。所以我认为一项关键技能——这其实又回到了——你有没有一个好的联合创始人？你有没有一个好的领导团队？如果你是产品经理，你在工程方面需要搭档，在营销方面也需要搭档，你真的需要和他们进行非常真实的对话，确保你实际在做的是真正正确的事情。我觉得”今天最有影响力的事情是什么”这个问题说起来容易。我的猜测是，如果很多人去尝试回答这个问题，他们多半会在自欺欺人。这是一个非常难回答的问题。这个问题本身很有趣，但能够准确地回答它，才是真正困难的部分。

Lenny Rachitsky： 这感觉像是你学到的一个非常重要的教训。你有没有一个具体的例子，亲身经历了这种教训，最后付出了代价——

Bret Taylor： 哦，有。你就是想让整个访谈都聊我的失败，不过我没问题。

Lenny Rachitsky： 你太成功了，需要平衡一下。

FriendFeed 的失败教训

Bret Taylor： FriendFeed 是我的第一家公司。巅峰时期我们有 12 个员工，12 个是我共事过的最优秀的人。我和 Jim Norris 一起创立了这家公司，他是我在 Stanford 就认识的工程师，还有 Paul Buhite 和 Sanjeev Singh——Paul 创立了 Gmail，Sanjeev 是 Gmail 的第一位工程师，所以我们团队里有做 Google Maps 的人和做 Gmail 的人。这是一个非常棒的创始团队。如你所说，我们做了一个社交网络。我们发明了很多后来在信息流中流行的概念。我们发明了”赞”按钮。那段经历真的很棒，很有趣。但我们真正受欢迎的地方其实只有土耳其、意大利和伊朗，后来在某个时候被伊朗封了，于是只剩下土耳其、意大利和硅谷。直到今天，实际上硅谷还有很多人会说”我好喜欢 FriendFeed。“我就说，那太好了。

它其实不是一个成功的生意。我们是一个以关注为导向的社交网络，而不是以友谊为导向的社交网络，这意味着我们的很多内容更接近 X 或 Twitter，而不是 Facebook。大量分享的是新闻文章、兴趣爱好、科学社区之类的东西。有一段时间，Twitter 当时是我们的竞争对手之一——那个时代的社交网络其实多得多，我可能记不太准确——我认为 Obama、Ashton Kutcher 和 Oprah Winfrey 在同一个夏天都上了 Twitter，然后我们就被打得一败涂地。

这是一个很好的例子，说明你会……那 12 个人里有 11 个是工程师，我们就是在埋头做产品。而我觉得 Twitter 那边是 Biz Stone。如果你和 Twitter 的人聊，他们可以给你讲这段历史，但我认为 Biz 非常专注于把名人和公众人物拉到 Twitter 上，这其实完全合情合理。如果你有一个以关注他人为导向的社交服务，那就放一些值得关注的人上去。而我们呢，则完全专注于打磨产品。

实际上，在我们最受欢迎的巅峰时期，我们非常自信——那时 Twitter 还在频繁出现”失败鲸鱼”，一半的时间都是宕机状态，人们甚至没法正常使用。而我们的产品创新更快、功能更多、用户喜欢，而且 100% 的时间都在线——但我们彻底输了，原因和产品完全无关。这是一个相当有名的例子——很多优秀的创业者并没有从 Google 出来，我认为原因是 Google 太成功了，作为一个产品经理，当你有 AdWords、钱像下雨一样从天上掉下来的时候，你很难真正理解分发渠道、产品设计乃至商业模式。那时候没有那么多审视和考验，而我觉得像 PayPal 帮（PayPal Mafia）那样的人，比 Google 的典型产品经理学到了更多关于创业的东西。所以，我们就是一直在挨揍，用最惨痛的方式学习。

这大概是最突出的一个例子。我觉得我们确实也有——我可以告诉你那个产品的所有缺陷，但我不认为那是我们输掉的原因。原因有很多，产品确实有很多问题，但还有很多其他因素。所以，随着时间推移，我逐渐积累了这些经验，但我想说的是，那个问题最难的部分是正确地回答它——当你在某方面没有经验的时候，很难对此产生直觉。所以如果说有一个结构性缺陷的话，并不是——我不知道我能不能想出办法去联系 Ashton Kutcher，他又不在我的人脉名单上。但我当时可能也没有向对的人请教。

我认为科技行业的好处在于，有很多建议可以获取。但选择听谁的其实非常困难。我觉得我们当时有些目光短浅，活在自己的小世界里创造这个产品，没有从外部引入视角来问：你看到了什么可能出错的地方？你看到了什么可能做对的地方？你在这个行业里看到了什么我们没在做、但可能应该去做的事情？这就是为什么董事会很重要。这就是为什么要找到合适的顾问——那些会告诉你你不想听、但你需要听的话的顾问。我认为那可能是当时缺失的一环。我不确定我当时在市场方面做得有多好，但如果我当时向对的人请教，我是可以了解到那是自己的一个短板的。我觉得这是我从那次经历中深刻学到的教训。我现在非常相信董事会的作用，也非常重视获取好的建议。

如何选择该听谁的建议

Lenny Rachitsky： 对于该听谁的建议，你有什么启发式的方法或建议吗？当你判断”忽略这个人，听那个人的”时，你关注什么？

Bret Taylor： 有的，不过这个确实难。归根结底还是要有好的判断力，以及对人品的判断能力。有一件事特别难——一个人表达观点时的自信程度，和这个观点的质量之间，并没有很强的相关性。我不想说它是负相关的，但说起来也挺有意思——现在播客这么多，如果聊到我非常了解的话题，有时候那些关于我熟悉领域最雄辩、最自信的论述，反而是最不准确的，但听起来极其有说服力。所以这确实需要非常好的判断力。有一点我觉得很有用——不仅仅是直接请教建议，而是问别人”我应该去找谁获取好的建议？“你会发现一些共同的答案会出现，那通常是一个非常强的、关于判断力的信号。

深挖建议背后的”为什么”

还有一点我发现很有用——在请教建议时，不要只问”该怎么做”，还要问”为什么”。像个烦人的两岁小孩一样，为什么？为什么？为什么？为什么？真正去理解对方给你建议时所依据的思维框架。关于建议，有趣的一点是，人们往往是从相对有限的经验中进行外推。所以他们会说，千万别这么做，或者一定要那么做。而原因可能只是他们有过一次反面经历，或者某次如果换种做法本可以做得更好。所以这是一条有用的经验之谈，但如果你不追问”为什么”，不去了解他们其实只有一次经历、具体发生了什么，这些建议听起来就像是一条规则，而实际上它只是零散的数据点。如果你向三个人请教，而他们的经历非常相似，你就可以从中提炼出一个第一性原理的框架。当你开始运用这个框架时，你能做到更加细致入微，而不是简单地遵循一条规则。所以我觉得，归根结底还是要靠好的判断力。我不知道怎么教这个。

Bret Taylor： 我非常笃信好的判断力。这也是我招聘时看重的东西。我觉得这可能来自于一种自我完善的习惯——作为创业者、作为产品经理，你必须真正对自己负责。如果你做了一个糟糕的决策，花时间反思，这是第一。真正去理解为什么，并始终努力提升自己的判断力。说到底，这才是你成为优秀创业者、优秀产品经理的原因。第二，当你获得建议时，真正理解它的来源和原因，这样你就能形成自己独立的判断，并认识到没有谁的建议具有统计学上的显著性——或者说极少有。如果你从 Warren Buffett 那里获得投资建议，好吧，那确实有统计学意义，但大多数建议不过是”某人有过一次经历，然后留下了遗憾”。

学习计算机科学还有价值吗

Lenny Rachitsky： 我特别喜欢这一点——你说”我不知道自己有没有好的回答”，然后却给出了一个精彩的回答。我想换个方向聊聊。你提到你把自己描述为工程师，我知道听说你现在还靠写代码来放松。我想直接问你一个很多大学生都在思考的问题：你觉得现在学写代码还有意义吗？你觉得未来几年这会发生显著变化吗？

Bret Taylor： 我确实认为学习计算机科学和学写代码是两个不同的问题。但我想说，学习计算机科学仍然非常有价值。我这么说是因为计算机科学不仅仅是写代码。如果你理解 Big O notation、复杂度理论，学过算法，明白为什么随机化算法能工作，为什么两个 Big O 复杂度相同的算法，一个实际性能比另一个更好，为什么缓存未命中很重要——所有这些细碎的知识点……写代码远不止是把代码敲出来那么简单。我这么认为的原因是，我确实觉得创建软件的方式将从对着终端敲打、或者对着 Visual Studio Code 敲打，转变为操作一台代码生成机器。我认为这才是创建软件的未来。但操作一台代码生成机器需要系统思维，而计算机科学——当然还有其他学科——是培养系统思维的绝佳专业。归根结底，AI 会推动软件的创建。

未来几年我们能做到的事情可能会超出我们现在的想象，但你作为那台代码生成机器的操作者，你的任务是做出一个产品或解决一个问题，你真的需要具备很强的系统思维。你将管理这台机器，它在做大量繁琐的工作——做按钮、连接网络之类的。而当你思考技术与业务问题的交汇点时，你试图构建一个能在规模上为客户解决问题的系统，而这种系统思维始终是创造产品中最困难的部分。

我举个很俗但很有代表性的例子。在 Facebook 的时候，我们花了大量时间设计 News Feed。如果你遇到一个非常优秀的设计师，他给你展示当时 News Feed 的 Photoshop 模型，一切看起来都很美。照片里家人幸福美满，照片本身就是完美的，帖子的语法完全正确，长度恰到好处，评论也恰到好处，还有点赞按钮……一切都完美无缺。然后你把那个设计实现了，看看自己的 News Feed——简直不忍直视，因为事实证明，并非每个人的照片都是专业摄影师拍的。帖子长度参差不齐，评论是”你太烂了”之类的——诸如此类的东西。

然后你突然意识到，设计 News Feed，用 Photoshop 做效果图是容易的部分。你真正需要设计的是一个系统——在内容层面和视觉设计层面，面对你无法控制的输入，都能呈现出令人愉悦的体验。这是一个系统，一种设计。我们在实践中做的——我确信自从我 2012 年离开后已经变了很多——我们建立了一套机制，要求设计师必须用真实的、杂乱的 News Feed 数据来展示他们的设计，而不是任何人工的东西，因为这迫使设计过程更加贴近现实。

我举这个例子是因为，不管是 AI 在写代码、做设计还是做其他各种事情，你都需要在脑海中建立一个系统模型。你需要理解什么是难的、什么是容易的、什么可能、什么不可能。顺便说一下，AI 也可以帮助你做到这一点。但我确实认为这是一项非常有用的技能。我认为总的来说，随着 AI agent 的出现，以及 AI 在某些领域接近超级智能，我们完成工作的工具会发生巨大变化。我认为对自己的工作方式保持一种非常松散的执念是很重要的——那个我们之前没聊到的、我重写 Google Maps 的故事，大家都在谈论那个故事，我觉得是因为 Paul 在某个播客上讲过，然后就传开了。

我觉得那最终会成为过去的遗迹，就像计算机发明之前 NASA 的人类计算员一样——哇，一个人居然是计算员？哇，真有趣，给我讲讲那个故事。我觉得我擅长的事情在未来将不再有用，或者说不再有价值，但这没关系。所以我认为我们需要对自己的技能有一种很松散的看法。但那种认为你不该学这些学科的想法——就像有人说”我不想学数学，因为我以后工作中用不到”——学数学其实很重要。它教你如何思考，教你世界如何运转，物理、数学都是如此。而计算机科学尤其如此——至少它的基础——将继续成为我们构建软件的基石。特别是当你与比你更聪明的东西交互时，理解你如何约束它、如何让它产生你想要的结果，在你可能并不完全理解它所生成的代码的情况下。我觉得这实际上需要相当高的专业素养。

Lenny Rachitsky： 这个回答太好了。人们总有一种二元对立的感觉——到底该不该学编程？而你的观点是，应该去理解工程是怎么运作的、系统是怎么运作的、你的代码在做什么、一切如何相互关联，但你坐在桌前实际写代码的方式会发生巨大的变化。这让我想到你最近在另一个播客上提到的一件事——你认为将来会出现、或者说应该出现一种新的编程语言，它更多是为 LLM 而非人类设计的。能聊聊这个吗？因为我觉得很多人还没想到这一点。

为 AI 设计的编程系统

Bret Taylor： 我不确定它是不是一门语言，我更愿意称之为编程系统，因为”语言”这个词可能太局限了。我对过去大概四十年甚至更久的计算机历史做一个过于简化的概括：我们首先创造了计算机硬件，然后发明了穿孔卡片——那是七十年代中后期你告诉计算机该做什么的方式。接着我们发明了早期的操作系统和分时系统，比如 Bell 实验室和 Berkeley 发明的 Unix 之类的东西，然后出现了 C 语言、Fortran 以及许多高级编程语言。大概是先有 Fortran，然后是 C。

我们不断向更高的抽象层攀升。显然，现在没人再用穿孔卡片了。写汇编的人也很少了。还有一些人写 C，一些人写 Rust。但很多人在写 Python、TypeScript 之类的语言。随着我们发明越来越多的抽象层，做高杠杆事情变得越来越容易。如果你回想当年 Google 或 Google Maps 有多么了不起，现在你大概可以给很多 React 程序员一个任务——做一个可拖拽的地图——我觉得很多人都能做到。而当年那可是真正的前沿研发。

Salesforce 在 1998 年创立时，仅仅把一个数据库放到云端就很困难，仅凭这一点就构成了一道技术护城河。而如今用 Amazon Web Services 这已经轻而易举，那道技术护城河窄得可笑，但产品护城河却相当庞大。我认为，如果写代码这件事正在从成本高昂变成边际成本趋近于零，那我们构建的那么多抽象层中，有多少是基于人类程序员的生产力而设计的？我觉得非常多。我常笑着说，我猜 Python 大概是最常见的 AI 生成代码语言，因为训练数据里 Python 的量太大了，数据科学家们又热爱 Python——我也很喜欢 Python。但对 AI 来说用 Python 生成代码简直荒谬，因为它是史上效率最低的编程语言之一。你知道全局解释器锁（global interpreter lock）那套东西，就是慢。我写过很多大规模 Web 服务，Python 确实很慢，而且很难做验证。

虽然不至于像 Perl 那么糟糕，但如果你有一个大型 Python 程序，你在运行时发现的错误会比发布前多多少？Python 被设计得非常符合人体工学，看起来几乎像伪代码，让人类写代码时感到愉悦。这也是数据科学家们如此钟爱它的原因。所以当我们走向一个——姑且假设，我不确定这会完全成真——人类不再写太多代码的世界，我们将成为这些代码生成机器的操作者。我们大概不会在乎编程语言是否符合人体工学。我们关心的是，当这台机器生成代码时，我们能否确信它做了我们想要它做的事？如果它没做到，我们能否轻松地修改它？我觉得编程语言领域有很多洞见可以为此服务。

比如 Rust 就很有意思。如果我让你看一个 C 程序，问”它有没有内存泄漏？“你可能很难判断，因为这确实很难——如果是一个百万行的 C 程序，那就更是难上加难。但如果我让你验证一个 Rust 程序没有内存泄漏，你只需要编译它就行了。因为它有编译时内存安全保证，编译成功这件事本身就告诉你没有内存泄漏。我觉得我们需要更多这样的东西。因为如果 AI 在生成代码，按定义来说，如果你必须逐行阅读，那将成为代码产出的瓶颈；更糟的是，你可能根本不会逐行阅读，于是就会把大量不安全、未验证的代码发布到生产环境中。

所以问题是，如何让人类拥有尽可能大的杠杆？也就是说，利用计算机替你完成工作。最简单的形式，显然是 AI 监督 AI，做代码审查，这很好。自省确实是提高 AI 系统鲁棒性的一个非常有效的方式。但我确实认为，既然写代码的繁琐程度已经无关紧要，你大概可以叠加一些目前不太流行的技术，比如形式化验证（formal verification）、单元测试等等。当你把这些都叠加起来，我在想的是——就像《黑客帝国》里那个面对绿色字符瀑布的人一样——作为一个代码生成机器的操作者，我怎样才能打造一种方式，让我能极其快速地构建极其复杂、大规模的软件，并且确信它能正常运作？

如果以这个为设计中心，你大概会改变语言、改变系统、改变所有这些东西，并且会调动大量不同的手段。而真正有趣的是，你可以放松很多约束——比如编码是免费的，这很好。带着这个前提，你想做什么？对语言、编译器、测试、自省、监督模型等等来说，什么才是最合适的？我认为这更像是一个编程系统，而不仅仅是一门语言。但我觉得当我们创造出这样的东西时，它真的能让创建者、构建者们打造出极其健壮、极其复杂的系统。

我对 VibeCoding 非常兴奋，但话说回来，生成原型从来就不是软件行业的瓶颈。真正的瓶颈在于构建越来越复杂的系统，并以敏捷的方式去修改它们。你看看著名的 Netscape 1 到 Netscape 2 重写的故事，很多人把 Netscape 在与 Internet Explorer 竞争中的部分失败归咎于此。制造这些东西不难，维护它们才难，确保它们健壮才难。我认为我们正处于定义这种新型软件开发系统的非常早期的阶段，我对将会涌现出什么感到非常期待。

Lenny Rachitsky： 当像你这样的人提出我们要打造一个《黑客帝国》式的体验，而且这可能是编程和构建的未来时，我真觉得我们活在未来了。我等不及了。这感觉是一个绝佳的机会，也是一个有趣的项目。

Lenny Rachitsky： 好的，沿着这个方向再问一个问题，然后我想把视角拉远，聊聊 AI 的走向。我特别想问像你这样站在 AI 最前沿的人一个问题——你在教你的孩子什么？我知道你有孩子，我觉得等他们长大以后，世界会截然不同。你在鼓励他们学些什么，跟之前的世代相比有什么不同，能帮助他们在 AI 供给充裕的世界里取得成功？

Bret Taylor： 我不知道我的教法是否有什么不同，但我确实在努力鼓励他们把 AI 融入生活。我回想了一下，我在 ‘97、‘98 年参加 AP 微积分 AB 和 BC 考试时，可以使用图形计算器。我还没来得及查证——本来想在对话前问问 ChatGPT 的，之后会去查——在允许使用计算器前后，微积分考试是否发生了变化？我猜应该是有的。但本质上，当你在考试中允许使用计算器时，你需要确保没有任何题目会仅仅因为有没有计算器而产生不公平的优势，这实际上迫使你重新设计题目，考察那些不会因为运算技巧或图形计算器的其他功能而受益的微积分知识。

我觉得很多教育并不假设你口袋里揣着一个超级智能。所以，如果你让学生就他们读过的一本书写一篇论文，他们可能很容易通过 ChatGPT 这样的大模型凭空生成一篇，如果你提示词技巧足够高明，甚至老师都看不出是 AI 写的。那该怎么办？怎么用不同的方式教孩子？现在老师们真的很困难，因为我认为我们还没有经历”把计算器加入考试”那样的转型。所以，我认为我们现有的大量评估学生的机制，已经被 ChatGPT 之类的东西打破了。我觉得我们处在一个非常尴尬的阶段，但我们仍然可以教孩子如何思考、如何学习。我认为我们的教育体系能够跟上，而且我实际上认为这些模型可以成为历史上最有效的教育工具之一。

AI 作为个性化导师

我不知道你是视觉型学习者还是阅读型学习者。我喜欢阅读，不太喜欢听讲座，从讲座中学到的东西不多。我喜欢读课本。如果你的老师的教学风格不适合你，你现在可以回家让 ChatGPT 用另一种方式教你。我的孩子在考试前会用 ChatGPT 测试自己，可以用语音模式或文字模式，比抽认卡好用多了。我女儿带了一本莎士比亚的书回家，她拍了一张看不懂的书页照片，ChatGPT 给她的讲解比我给她讲的清楚多了。我觉得这个世界上每个孩子都有一个个性化导师，可以用最适合他们的方式教学——视觉的、听觉的、阅读的。我们有一个可以测试你、考你的平台。我认为这真的是一种对能动性的放大。

那些有主动性、有学习渴望的孩子，你拥有的是所有你遇到过的老师与这些模型的最佳组合，而且你可以随时使用。所以对我的孩子，我大女儿学编程、做网站的时候，每次她来问我问题，我就让她去用 ChatGPT。不是因为我想做一个烦人的父亲，而是我觉得她需要学会使用这个工具，因为它真的很棒。

所以，我确实在努力让他们学会在生活中建设性地使用它。但说了这么多，我对公立学校的老师们充满了共情。现在非常困难，因为技术发展的速度远远超过了我们的教育体系。尤其是在评估方面，老师们现在确实面临很大的挑战。我也有些担忧，因为这些技术放大了能动性，反过来也一样成立——如果一个学生不想学什么东西，这些工具大概也提供了很多逃避学习的手段。所以，我认为这对家长和老师来说都是一个挑战，我觉得我们将面临一段这样的时期。

教育体系终将适应

但我提起 AP 微积分考试，当然，图形计算器不是 ChatGPT，别误会。但我觉得我们迄今为止一直能找到办法，让作业、课堂学习和考试围绕我们可用的技术进行相当成功的调整。我相当有信心我们最终能想出办法。而且从更积极的角度来看——我不知道，我上的公立学校，不知道你是不是也是——你有时确实会遇到一些不太好的老师，而现在，你有了一个替代方案。你不再需要是那个请得起家教的富家子弟才能获得辅导了。如果你是一个数学特别好的孩子，而你的学校没有高等统计学课程，现在你有了。

所以我认为这对有主动性的孩子来说是一种极其民主化的力量，我觉得这非常令人兴奋。我希望现在有一个 11 岁的孩子，10 年后会创立一家非常了不起的公司，而 ChatGPT 将是促成这一结果的主要导师。我觉得这太酷了。

Lenny Rachitsky： 我有一个两岁的孩子，感觉又多了一个新的里程碑节点——什么时候给手机，什么时候给什么 Snapchat 之类的现在孩子用的东西，然后又多了个什么时候给第一个 ChatGPT 账号。说真的，我在想这应该多快发生。

Bret Taylor： 我个人的看法是，这跟前两件事不一样。我认为手机对学校、对孩子并不好，我个人主张尽量晚给。但我觉得 ChatGPT 更像谷歌搜索。口袋里放一个让人上瘾、有推送通知的设备是一回事，用 AI 来学习是另一回事。所以，这两者是不同的。我确实从根本上把 AI 看作一种工具设施。在 ChatGPT 出现之前，应该没多少家长会问”我什么时候该让孩子用谷歌搜索”。这是另一种类型的工具。我认为用这种方式来理解这些技术，是我思考它们的方式。

Lenny Rachitsky： 你的孩子用的设备是 iPad 还是笔记本电脑之类的？

Bret Taylor： 对，他们用的是桌上的电脑。

AI 市场的三个细分领域

Lenny Rachitsky： 明白了，好的，很好的建议。这些对我很有参考价值，随着我家孩子长大可以学以致用。好，我拉远视角，聊聊 AI 商业战略。现在很多创始人都在思考的一个大问题是：应该在哪里构建？哪些事情基础模型公司不会自己做、不会把创业者挤掉？作为一位正在成功运营 AI 业务的人，同时也是 OpenAI 董事会成员，你在什么方向是好主意、什么方向不是好主意方面，有着非常独特的视角。你认为 AI 市场将如何演变？创始人应该聚焦哪些领域，又应该尽量避开哪些？

Bret Taylor： 我认为 AI 市场有三个细分领域最终会形成相当有意义的市场，然后我再谈谈我认为整体将如何演变。首先是前沿模型市场，或者说基础模型市场。我认为这个市场最终会由少数几家超大规模云服务商（hyperscaler）和真正大型的研究实验室主导，就像云基础设施即服务市场一样。原因在于，创建前沿模型完全是资本支出（CapEx）的函数。你需要一家拥有巨额资本支出能力的公司才能构建这样的模型。所有试图做这件事的创业公司，几乎全部已经被整合了——Inflection、Adept、Character 以及其他一些。我认为，由于所需的资本支出规模巨大，初创公司没有足够的融资跑道来达到逃逸速度，因此看起来并不存在可行的商业模式。而且，模型作为一种资产类别，其价值贬值得相当快。

所以，你需要很大的规模，才能在一个价值贬值得如此之快的模型上获得投资回报。因此，我的看法是，大概没有创业者应该去构建前沿模型。

Lenny Rachitsky： 除非你是 Elon。

Bret Taylor： 对，对，他不一样。他有能力筹集数十亿资金，我猜你的大多数其他听众做不到。而且他是有史以来最伟大的，这是有原因的，他不一样。你不要拿自己跟他比。

工具市场：离核心太近的风险

市场的另一部分是工具层。我认为有很多人在 AI 淘金热中卖铲子——数据标注、服务、数据平台、评估工具。还有一些更专门的模型，比如 11 Labs 拥有一套出色的语音模型，很多公司在用，质量非常高。就是说，如果你想在 AI 领域取得成功，你需要哪些不同的工具和服务？

但工具市场也存在一些风险，因为它离太阳太近了。如果你看看基础设施即服务市场和云工具市场，像 Confluent、Databricks 和 Snowflake，Amazon 和 Azure 等很多厂商在这些领域都有竞争产品，因为它们与基础设施本身非常紧密相邻，而每个基础设施提供商都在努力通过向栈上层移动来实现差异化，而你正好就在那个位置上。

所以，确实有一些真正有意义的公司，正如我提到的 Snowflake、Databricks、Confluent 等等，但也有很多其他公司被基础设施提供商自身的技术所淘汰。所以这些公司面临的风险最大——某一天某家大型基础模型公司可能发布跟它们一模一样的产品。所以可能会有很多人需要你的工具，但问题在于，某家大型基础设施提供商推出竞争对手时——或者更准确地说是”是否”以及”何时”——人们为什么还会继续选择你？所以这是一个不错的市场，但正如我所说，它离核心有点太近了。

应用型 AI 与智能体的未来

然后是应用型 AI 市场。我认为这将由构建智能体（agent）的公司来展开。我认为智能体就是新的应用，它会成为产品的标准形态。有些公司像 Sierra，我们帮助企业构建智能体来接听电话或回复聊天，用于客户体验和客户服务。有些公司像 Harvey，为法律、律师助理行业打造智能体，做反垄断审查、合同审查等等。有做内容营销的公司，有做供应链分析的公司。我认为这就像软件即服务（SaaS）市场一样。它们可能是利润率更高的公司，因为你卖的是实现业务成果的东西，而不是模型本身的副产品。它们几乎肯定需要向模型提供商”纳税”，这就是为什么那些模型提供商会变得规模极大但利润率可能略低，而面向它们的市场可能技术性会更弱一些。

如果你想想软件即服务最纯粹的形式，你不会问”你用什么数据库？“，真正关心的是功能和特性。我认为智能体也会朝这个方向发展。我认为随着时间推移，它更多关乎产品而非技术。回到我的比喻——1998 年 Mark 和 Parker 创办 Salesforce 时，仅仅让那个数据库在云端运行就是一个技术成就。而今天，没人会问这个问题，因为你可以在 AWS 或 Azure 上轻松启动一个数据库，完全不是问题。我认为今天，在模型之上编排一个智能体流程，听起来很炫，而且确实很难，诸如此类。但我很确定，三四年后这会变得很简单。这只是技术进步的自然结果。所以，随着时间推移，你会问，什么是一家智能体公司？它看起来有点像 [不清晰] 即服务。

你会越来越少谈论如何处理模型——就像现代 SaaS 一样，很少有人问你用什么数据库——但你会更多地讨论工作流和你所驱动的业务成果。你在为销售团队生成线索吗？你在降低采购支出吗？无论你提供什么价值，它都会慢慢朝着那个方向演进。

我非常兴奋。我认为初创公司大概不应该构建基础模型。但如果你对未来的前景有愿景，放手去干。但我认为这可能是一个已经整合完毕的、充满挑战的市场。我对另外两个市场非常兴奋。我尤其期待的是，随着构建智能体变得越来越容易，看到大量长尾智能体公司涌现出来。我之前在看一个网站，列出了股票市场排名前 50 的软件公司，显然，前五名是那些巨头——Microsoft、Amazon、Google 等等，但接下来的 50 家全是 SaaS 公司，有些令人兴奋，有些极其无聊，但这就是软件市场的演变方式，我认为智能体也会出现类似的情况。

不仅仅是我们所在的客户服务和软件工程这些巨大市场。还会有很多人们花费大量时间和资源的领域，智能体可以直接解决——但这需要一位真正深入理解那个业务问题的创业者。我认为这才是 AI 市场中大量价值将被释放的地方。

与 Marc Benioff 的智能体共识

Lenny Rachitsky： 这太有帮助了。这让我想到，我之前请 Marc Benioff 来上播客，你们曾经是联合 CEO，他极度 agent-pilled，满脑子想谈的就是 Agentforce。显然你也非常 agent-pilled。是什么让你——

Bret Taylor： 我从没听过 agent-pilled 这个词 [笑声]。

Lenny Rachitsky： 显然你们看到了某些东西，觉得必须全力押注智能体，这就是未来。你认为人们忽略了什么？为什么这是软件运作方式的一次关键性变革？人们没有看到什么？

技术与生产力的跃迁

Bret Taylor： 如果你和像 Larry Summers 这样的经济学家聊聊——他和我一起在 OpenAI 董事会——他们会讨论技术的价值是什么，是否能推动经济生产力的提升。回顾经济史上生产力的重大飞跃，其中一次发生在九十年代。我和很多人交流过，他们认为那其实是计算技术的第一波浪潮——人们构建了 ERP 系统，把会计工作搬进了计算机和数据库，甚至大型机里，我们说的是 PC 时代。那是一次巨大的跃升。想象一下，在那之前一家大型跨国公司的账本是什么样的，一堆又一堆的数字，技术真正地彻底改变了整个部门。

我举个简单的小例子。我父亲刚退休，他是一名机械工程师。他讲过七十年代末刚开始职业生涯时，去了一家机械工程公司，公司里大部分员工都是制图员。大致流程是，工程师做完设计之后，需要画出所有不同视角的图纸、每一层的平面图，交给施工方去执行。而现在，他公司里制图员的数量是零。你直接在 AutoCAD 里做设计，现在用 Revit，生成一个三维模型，制图这个环节就被彻底消灭了。不再需要了。设计和制图，制图这件事已经不存在了，就只剩下设计。这才是真正的生产力提升，对吧？机械工程公司的核心工作是做设计，制图只是为了让施工方能看懂而必须产出的中间产物，本身并不创造价值，更像是供应链中的一个必要环节。

回顾 PC 以来软件产业的历史，确实有显著的生产力提升，但远远比不上最初那一次巨大的飞跃。我不够聪明，无法确切知道原因。但有趣的是，技术带来的生产力提升，我认为并没有像一些人预期的那样真正兑现。我认为智能体将真正开始再次让曲线弯折，就像计算技术最早期那样，因为软件正在从帮助个人稍微提高效率，转变为真正自主地完成一项工作。因此，就像机械工程公司不再需要制图员一样，你也不再需要有人专门去做那件事了。这意味着他们可以做更有杠杆、更高效的事情，更少的人可以完成更多工作，真正推动经济中的生产力提升。

如果你卖过企业软件，你肯定作为供应商和客户有过这样的对话——讨论价值，做一些相当牵强的推算。比如你卖的是销售类产品，就说：如果每个销售多卖 5%……那你应该付我们一百万美元。大概就是这样的对话。而且这种价值非常难以归因——这也是为什么销售生产力软件如此困难，我吃过这个苦头。让每个人效率提升 10%，这到底值多少钱？你真的让他们提升了 10% 吗，还是别的什么因素变了？你并不真正清楚。但现在，当智能体真正自主完成一项工作时，它不仅切实地以非常真实的方式推动了生产力，而且还是可衡量的。

智能体将重塑软件行业

所以这一切加在一起，我认为这是我们对软件认知的一次质变，因为智能体自主完成工作，作为生产力驱动因素更加不言而喻，而且是可衡量的，所以人们对它的价值判断也不同了。这也是为什么我同样支持软件采用基于结果的定价。

这一切综合起来，给我的感觉是，其意义堪比云计算的转型——甚至在技术上可能更为深远——尤其是在改变软件行业商业模式方面，将会出现一个前后的分水岭。我不知道现在还有多少人在卖永久授权的本地部署软件，但已经微乎其微了。我认为我们将经历一次类似的转型。整个市场都会走向智能体。我认为整个市场都会走向基于结果的定价，不是因为这是唯一的方式，而是市场会把所有人拉向那个方向，因为这才是构建和销售软件显而易见的正确方式。

Lenny Rachitsky： 让我沿着这个话题继续追问。我们最近请了 Madhavan 来做播客，他是定价专家、行业传奇，写了《Monetizing Innovation》这本书。他谈到了 AI 公司的定价策略，他的观点和你非常一致——如果可以的话，你需要按结果来定价产品。他的理由和你分享的完全一样：如果你能把影响归因到具体行动上，而且它是自主运行的，那你就能做到这一点。他实际上还把 Sierra 作为这方面的成功范例。你能不能简要解释一下，什么是基于结果的定价，然后以 Sierra 为例说明它是怎么运作的？

基于结果的定价

Bret Taylor： 好，我先举个例子，然后再讲得更宽泛一些。在 Sierra，我们帮助企业构建面向客户的 AI 智能体，主要用于客户服务，但更广泛地说是客户体验。比如你的设备出了问题，你会打电话或在线聊天联系他们的 AI 智能体。如果你用的是 ADT 家庭安防系统、报警器不工作了，你可以和他们的 AI 智能体聊天。还有 Sonos 音响，很多不同的消费品牌都是我们的客户。想想运营一个呼叫中心，每接一个电话都是有成本的，主要是人力成本。假设一通典型电话的成本大约在 10 到 20 美元之间，有些是软件费用，有些是通信费用，但很大一部分就是接电话人员的小时工资。

如果 AI 智能体能接听这通电话并解决问题，在行业内这通常被称为呼叫转移（call deflection）或承接解决（containment）。这基本上意味着你省下了大约 15 美元，因为不需要有人来接电话了。所以在我们的行业里，基本逻辑是：AI 智能体解决了客户的问题，客户满意，而且不需要人工接听——对此有一个预先商定的费率，我们称之为基于解决结果的定价。还有其他类型的结果。我们甚至有一些销售型智能体是按销售佣金收费的，你没听错，我们确实这么做。我们真正把智能体视为客户体验的一部分——你品牌的礼宾服务——我们希望确保我们的商业模式与客户的商业模式保持一致。

基于结果的定价与行业愿景

Bret Taylor： 正如你所说，这些智能体需要具备自主性，而且结果必须是可衡量的。这一点并不总是能做到，但我认为在大多数情况下是可行的。真正有趣的地方在于，如果你和任何一位 CFO 或采购负责人聊聊他们与大型供应商的合作，他们会看那份物料清单，上面密密麻麻的，根本无法判断你是否从那份合同中获得了期望的价值。我认为基于消费量的计费方式——这在基础设施领域特别流行——已经更接近正确的方向了。但我不确定 token 是否真的是衡量 AI 价值的好指标。我经常用这个类比：目前大多数编码智能体都是按 token 或按使用量计费的，但有这样一个著名的故事——一位苹果工程师有一个糟糕的经理，要求他每天汇报写了多少行代码。世界上每个工程师都知道，这是衡量生产力的愚蠢方式。

这位工程师 famously 带着一份报告走进去，上面的数字是负数，因为他做了一次大规模重构，删了大量代码，这是他向管理层表达不满的方式。我觉得 token 也是类似的道理。是的，你用了大量 token，恭喜你，但它有没有产出一个好的 pull request？我认为这才是所有这一切的核心。我认为基于结果的定价和基于使用量的定价之间存在巨大差异，因为在 AI 领域，这两者甚至不一定相关。你可能打了一通很长的电话，却没有解决客户的问题，客户在网上给你差评，然后又打回呼叫中心，所有那些努力全都白费了。事实上，你可能还创造了负价值。因此，我是这种模式的坚定支持者。

有意思的地方在于，它真正实现了一致……我认为每一家科技公司都希望成为合作伙伴，而不仅仅是供应商。而在 Sierra，我们真正做到了与每一位客户成为合作伙伴，因为我们在想实现的目标上完全一致。我认为这才是软件行业应该走向的方向。它需要一种截然不同的公司形态。你必须能够帮助客户实现那些成果。你不能只是把软件扔出去就不管了，因为如果它不产生效果，你永远拿不到钱。当你以正确的方式做这件事时，你的取向会变得极度以客户为中心。我认为这是软件行业的一个更好版本。所以我认为，从第一性原理来看它是对的，对采购方来说它是对的，对整个世界来说它也是对的。

AI 的实际生产力提升

Lenny Rachitsky： 我们刚才聊了一些关于生产力提升的话题。最近新闻标题里充斥着各种质疑——AI 到底在做什么？它真的在帮助人们提高生产力吗？最近实际上有一项研究，不知道你有没有看到，他们发现工程师使用 AI 后生产力反而下降了，因为它把他们引向了不同的方向，他们不得不去研究”这里到底出了什么问题？“所以我认为客户体验是一个很好的例子，你确实在那里看到了实实在在的收益。在你的公司或你合作的其他公司中，除了客户体验之外，你是否看到了真正的生产力提升——那种可以明确说”是的，这确实有效，而且意义重大”的提升？

Bret Taylor： 我对 AI 带来的生产力提升非常乐观，但我确实认为目前的工具和产品还不够成熟，而且很多地方是反直觉的。比如，我认识的几乎所有软件工程团队都在使用 Cursor 之类的工具来辅助工程师。目前大多数人把 Cursor 当作编码自动补全来用，虽然他们也有很多智能体方案——OpenAI 有 Codex，Claude 也有……我想不起来 Anthropic 的产品叫什么了。所以也有很多智能体方案正在涌现。一个有趣的现象是，由于技术还不成熟，生成的代码经常存在问题。很多人在尝试利用这些工具来实现生产力提升时遇到了困难，因为任何写过大量代码的工程师都会告诉你，查看、编辑和修复自己写的代码是相对容易的。

审查别人的代码，尤其是在别人的代码中找出一个微妙的逻辑错误，实际上非常困难。这比编辑自己写的代码难得多。所以如果编码智能体生成的代码经常不正确，修复它实际上可能需要耗费大量的认知负荷和时间。事实上，如果你最终给客户制造了大量问题，你可能确实产出了很多功能，但某种程度上是在把系统搞乱，得到的结果并不理想。有几种技巧我觉得很有意思。首先，我认为现在有很多 AI 创业公司正在做代码审查之类的工作。我觉得智能体中的自我反思（self-reflection）这个理念非常重要。让 AI 监督 AI 实际上非常有效。可以这样想：如果你创建了一个 90% 时间都能给出正确结果的 AI 智能体，这不算很好，但是再创建另一个 AI 智能体去找出剩下 10% 的错误，这有多难呢？这或许是一个可解决的问题。

如果那个审查的智能体也有 90% 的准确率——姑且这么说——你可以把它们串联起来，得到一个准确率 99% 的系统。这本质上就是一个数学问题，事实证明你可以做一个生成代码的系统，再做一个审查代码的系统，本质上你是在用计算力换取认知能力，你可以叠加更多层的认知、思考和推理，产出越来越健壮的结果。所以我对此非常期待。另一件事是根因分析。我们在 Sierra 有一位工程师，专门负责为我们的 Cursor 实例提供 Model Context Protocol 服务器的支持。我们的整体理念是：如果 Cursor 生成了不正确的代码，不要只是修复它，而是尝试找到根因。想办法让 Cursor 下次能生成正确的代码——本质上，这就是上下文工程（context engineering）。

Cursor 缺少了哪些本应具备的上下文，才导致了错误的结果？所以我认为，那些希望在软件工程等部门获得生产力提升的人，如果想要现在就看到成效，就不应该等待模型自动变好。你真的必须建立根因分析的体系，构建系统，思考如何追溯每一行有问题的代码的根因，提供正确的上下文，建立正确的系统，让模型今天就能做到。随着时间的推移，这可能会变得不那么必要，你需要做的上下文工程也会减少，但你真的必须把这当作一个系统来思考。我看到很多人在等待模型自动变得更好。我的回应是，那最终会发生，但如果你想现在就获得收益，就得投入工作。这本质上就是应用型 AI 公司存在的理由。

而且这项工作并不简单，但你是可以做到的。因此，对于使用 Sierra 这类平台的客户来说，AI 智能体并不完美，但我们正在创建一个系统，让客户能够形成一个持续改进的正向循环。如果你想把自动解决率从 65% 提升到 75%，我们有一系列工具让 AI 帮你做到这一点——识别改进机会，找出人们感到沮丧的原因，我们可以为智能体添加哪些新能力来提高解决率？让 AI 替你把大海捞针变成把针放在 haystack 的最上面，我认为这才是优化这些系统的正确方式。

改进 Cursor 输出的具体方法

Lenny Rachitsky： 我从没听说过这种通过添加额外上下文来改进 Cursor 的技巧。具体是怎么做的？是搭建一个 MCP 服务器让所有东西都经过它，还是给 Cursor 添加规则？具体的做法是什么？

Bret Taylor： 我可能说得不够专业，但本质上就是 MCP，因为那就是你给 Cursor 提供上下文的方式。我觉得几乎在所有情况下，当模型做出一个糟糕的决策时，如果模型本身是好的，那问题就是缺乏上下文。所以，你真正需要做的是找到你的特定产品和代码库与这些编码智能体和系统可获取的上下文之间的交集，从根本上解决问题——这就是核心原则。

Lenny Rachitsky： 明白了，这确实很酷。我之前没听说过有人这么做，Model Context Protocol，很有道理。我们谈到了 TX 之外的生产力提升。正好让你有机会展示一下你们构建的产品有多厉害，你看到使用 Sierra 的客户获得了哪些收益？

Sierra 的客户成果

Bret Taylor： 我们的客户有 50% 到 90% 的客户服务交互被完全自动化，我觉得这真的令人兴奋。我们服务的客户范围非常非常广——医疗保险公司、医疗服务机构、银行。你甚至可以通过一个智能体来办理房屋再融资，这是我们的一个客户在我们平台上构建的。还有电信行业，DIRECTV、SiriusXM，以及大量的零售商，从 Wayfair 到 OluKai、Chubbies Shorts 这样的服装零售商，真的很有趣。最让人兴奋的是用例的多样性——从帮你注册……我们有一个智能体服务于某大型约会应用的客户支持，到帮你升级或降级 SiriusXM 的套餐。其实有个很有意思的事，我们做的技术支持涵盖面很广，从家庭报警系统到 Sonos 音箱，最近还扩展到了 CAT 扫描设备，我觉得这太棒了。技术人员进去维修 CAT 扫描设备时，可以和 AI 智能体对话，引导他们完成整个流程。我们是这个领域的领导者，我们的目标是让世界上每一家公司都能创建属于自己的、带有自身品牌的智能体，我相信它会成为和公司网站、移动应用一样重要的数字化触点。短期内，它可以真正改变运营客户服务团队的成本。更值得注意的是，还能同时保持非常高的客户满意度。Weight Watchers 的那个智能体，客户满意度评分是 4.6 分（满分 5 分），相当惊人。而且服务场景本身就很有意思——人们通常是因为遇到了问题才来联系的。所以当你有一个清晰的解决方案时——不知道你们有没有在机场用过那个智能体——那个智能体的客户满意度是 4.7 分，人们带着问题进来，然后满意地离开。我认为这才是真正的机会所在。

我们的整体愿景是，推动世界走向这样一个未来：与客户的每一次互动都可以是即时的、多语言的，可以通过语音、聊天、数字渠道或电话进行，而且可以高度个性化。我觉得这真的非常非常令人兴奋。回想一下你和品牌之间最美好的那些体验，就像那个认识你的店员——对我来说，就是超市里的那个肉铺老板，我喜欢做饭，他认识我，我们会聊天。你能不能为一家拥有一亿客户的企业规模化地复制这种体验？能不能以一种真正个性化的方式做到？我觉得我们正处于实现这一目标的关键节点。

AI 产品的市场进入策略

Lenny Rachitsky： 在进入非常精彩的快问快答环节之前，让我再问你一个问题。现在有很多创始人在 AI 应用的市场进入策略上苦苦挣扎——应用太多了，产品太多了，面向大型 B2B 企业买家的东西太多了。显然你们找到了突破口，我猜你的个人声誉有帮助，投资者也有帮助，但关于如何成功地推动一款 AI 产品——特别是智能体产品的市场进入，你有什么心得可以分享给那些正在尝试做好这件事的人？

Bret Taylor： 我认为已经被验证有效的市场进入模式其实就那么几种，选择适合你所处产品类别的那一种非常重要。第一种是开发者主导型。这方面最著名的例子大概是 Stripe 和 Twilio，它们可能是最早把这一点做到极致的。这种市场进入方式的核心是吸引某个工程师个体，通常是在 CTO 部门内有责任和相当自主权去选择解决方案的工程师。这种方式适用于你的产品是平台型产品的情况。但如果你的产品是要帮助业务部门，就不适用了，因为业务部门通常没有专门的工程团队，更不用说随意下载一个新库或开始使用某个网络服务的自主权了。这种方式特别适合卖给初创公司，因为初创公司的工程团队通常有相当大的自由度来选择服务，以解决创始人给出的业务问题。

第二种是产品驱动增长（PLG）。这是一个很宽泛的术语——显然每家公司的产品都很重要——但产品驱动增长更具体的含义是：用户可以直接从网站注册，通常会有试用期，往往还能用信用卡买几个席位。这种方式适用于用户和购买者是同一个人的情况。所以它几乎总是适用于小企业软件，因为个体经营者什么都自己干。你要卖的是像 Shopify 早期那样的小企业软件，或者很多类似的产品，面向小商户——这很棒。但当软件的购买者和使用者不是同一个人时，这种方式就不适用了。比如费用报销软件——使用者是普通员工，但购买者通常是财务部门。所以让人注册并用信用卡购买就没有意义，因为使用的人不是拿信用卡的人，根本行不通。

第三种是直销。直销曾经——我不想说过时了——但如果想想最优秀的直销公司，大概有很多源自 Oracle 的传统，你可以想到 SAP、Oracle、ServiceNow、Salesforce，也许还有 Adobe，还有其他一些。这些公司是以相对传统的销售方式，卖给大型业务部门的。我觉得因为产品驱动增长变得非常流行，很多公司采用了那种方式——这很好，那种模式确实能产出优秀的产品——但如果 PLG 意味着你实际上没有和软件的购买者接触，你就无法增长。所以我最近确实看到，在许多 AI 公司中，直销开始重新流行起来，因为我认为 AI 中的很多机会恰恰符合购买者和使用者不一定是同一个人这个特征，确实需要那种市场进入方式。

我看到创业者容易踩坑的地方是，他们会选择一种市场进入方式，但没有深入思考：购买这款软件的流程是什么？评估这款软件价值的流程是什么？我认为大家需要更多地从第一性原理出发来思考这个问题，更加深思熟虑。坦白说，我认为很多公司应该比现在更多地利用直销模式。虽然一些直销公司的产品质量确实有时名不副实，导致直销的名声不太好，但我很高兴看到它在 AI 市场中重新回来了。

闪电问答环节

Lenny Rachitsky： 我觉得这个观点是很多创业者需要听到的，尤其是那些没有商业背景、对销售有抵触情绪的创业者——他们觉得自己不擅长销售。但你要接受的是，这可能恰恰是你必须精通的事情，这就是你获胜的方式，你不能仅仅依赖产品驱动增长。

Bret Taylor： 对。

Lenny Rachitsky： Bret，你还有什么想分享的吗？最后还有什么智慧 nugget 吗？在我们进入非常令人期待的闪电问答之前，有什么想展开聊聊的吗？

Bret Taylor： 没有了，开始吧。

Lenny Rachitsky： 好的，开始吧。欢迎来到我们的闪电问答环节。我有五个问题。准备好了吗？

Bret Taylor： 好的，来吧。

Lenny Rachitsky： 你最常推荐给别人的两三本书是什么？

Bret Taylor： 我不太读非虚构类的书。但如果非要在我们讨论的话题范围内选一本的话，大概是《Competing Against Luck》，这本书催生了 Jobs to be Done 理论，这是一个我非常信奉的框架。我唯一的批评是，我觉得大多数商业书籍其实写成一篇文章就够了。所以也许你可以买这本书，然后把它丢给 ChatGPT 让它给你一个摘要。但书还是值得买的——Clayton Christensen 提出了这个概念——这确实是一个思考如何用产品传递价值的非常好的框架，它确实影响了我。

还有一本书我确实会推荐，叫《Endurance》，讲的是 Shackleton 去南极探险的故事。书的一半内容是他在船上被冰封、和船员一起挨饿、吃海豹肉。我这辈子没见过比这更极致的坚韧故事了。而且这竟然是真实事件，简直不可思议。如果你是一个正在经历艰难时刻的创业者，读读这本书，你会觉得，好吧，情况还能更糟。这是一本很棒的书。它竟然是真实发生的，这一点本身就令人惊叹。

Lenny Rachitsky： 他做得特别好的一点是，他为那些加入探险的人设定了期望——就是那个著名的报纸——

Bret Taylor： 那则报纸广告。我不知道那是不是真的。如果是真的那就太了不起了。

Lenny Rachitsky： 哦，可能不是真的。

Bret Taylor： 我不知道。互联网上的东西，谁知道呢。

Lenny Rachitsky： 天哪，那时候就有”深度伪造”了。好的。你最近有没有特别喜欢的电影或电视剧？

Bret Taylor： 我最近没怎么看新电视剧。我们刚和孩子们一起看了《盗梦空间》，他们很喜欢，也让我重新欣赏了 Christopher Nolan，真是一部很酷的电影。那种你看完之后能围绕它讨论两天的电影。所以，就是一部很棒的电影。

Lenny Rachitsky： 我看到有人用 VO 3 来制作自己的《盗梦空间》视频，里面的世界层层折叠。天哪。好的。你最近有没有发现一个特别喜欢的新产品，或者一个你长期以来一直很爱的产品？

Bret Taylor： 我真的很喜欢 Cursor。我觉得它改变了一切。我热爱创造软件，而我对智能体更加期待。我一直非常兴奋——看到 OpenAI 的 Codex 和其他产品让我很激动。所以我认为 Cursor 在其当前形态下是一个过渡性产品。我知道他们也在做智能体，但我真的很享受把一件我热爱的事情——它也是我一生的热情所在——真正深入这个 AI 工具，看看它如何改变我创造软件的方式。所以我在这款产品上花了很多时间，因为它和我热爱做的事情如此核心相关，而且它确实是一款精心打造的产品。

Lenny Rachitsky： 我觉得这是第一次有人在这个回答中提到 Cursor，所以这可能是一个趋势的开始。Michael Trell 上过这个播客，他其实在谈话开头传达了一个和你非常相似的信息——关于代码的未来、代码之后会是什么，以及代码之上会出现一个额外的伪代码层的概念。和你的想法非常一致。你有没有一个经常回想的、在工作或生活中觉得有用的人生座右铭？

Bret Taylor： “预测未来的最好方式是创造未来。“我认为这句话出自 Xerox PARC 的 Alan Kay。他发明了我们今天在计算中使用的很多核心抽象。我是一名创业者，这就是我热爱构建事物的原因，这确实是我的人生座右铭。

Lenny Rachitsky： 我觉得很多人都在说这句话，但我觉得你真的已经这么做了很多次。你真的在践行这个座右铭。最后一个问题。我们聊到了你在 FriendFeed 发明了”点赞”按钮。除了”like”之外，当时还有没有其他候选名称？是显而易见就叫”like”吗？还是有过其他考虑？

Bret Taylor： 那是在 emoji 出现之前。如果你看 FriendFeed 帖子下面的评论，至少 70% 都是”cool”、“wow”、“yeah”或”neat”这样的词。FriendFeed 的一个主要用途就是对事物进行讨论。所以你会看到一个帖子，下面有相当丰富的讨论。与 Twitter 等平台相比，它是一个进行讨论的好地方。所以我们想解决的产品问题是，把那些只有一个词的回复过滤掉，让讨论区里是真正的评论，而不是”我读到了”的确认。

所以，最初的定位是”一键评论”。这就是我们的思路。我做的第一个版本用的是一颗心，她否认记得这件事——Anna Yang，现在叫 Anna Muller，当时在公司工作——她非常讨厌这个设计。她说，“如果我每条帖子都看到心，我会吐的。太过了。“而且还有一点很有意思，我们当时模拟了一个场景——比如一篇关于某个悲剧事件的报道——一颗心就不合适。实际上，“like”这个词很难翻译，因为它是一种非常中性的情感表达，这就是它难翻译的原因——因为它很微妙。所以我们最终选定了这个方案。

我们一开始用的是心形图标，我不知道我们有没有考虑过用”love”这个词，但我们确实是从图标开始的，然后才是”like”——这个词感觉既积极又尽可能中性，这样它就能适用于更复杂的内容。但这一切都源于我们需要一个”一键评论”。这就是这个概念的由来。

Lenny Rachitsky： 哇，我从没听过这个故事。这让我想到现在的 LinkedIn。他们基本上在试图解决同样的问题——他们有那些自动回复的标签按钮。我觉得大家不太喜欢那些东西。

Bret Taylor： 是的，他们有很多功能。

Lenny Rachitsky： 太多 AI 功能了。Bret，这次对话太精彩了。非常荣幸。非常感谢你来参加这个播客。最后两个问题——如果大家想联系你，或者想去 Sierra 工作，可以在哪里找到你？听众可以怎样帮到你？

Bret Taylor： 如果你想要一个 AI 智能体来帮助处理客户服务，请访问 sierra.ai。如果你想申请职位，请访问 sierra.ai/careers。我们在旧金山、纽约、亚特兰大和伦敦都有办公室，各个部门都在大量招聘。所以如果你感兴趣，请联系我们。

Lenny Rachitsky： 听众可以怎样帮到你？试试 Sierra？还有别的吗？

Bret Taylor： 对，试试 Sierra。我是一个”单议题选民”。

Lenny Rachitsky： 非常清晰的信息传递。我喜欢。

Bret Taylor： 是的。

Lenny Rachitsky： Bret，非常感谢你来。

Bret Taylor： 谢谢你的邀请。

Lenny Rachitsky： 大家再见。

感谢大家的收听。如果你觉得这期节目有价值，可以在 Apple Podcasts、Spotify 或你喜欢的播客应用上订阅本节目。也请考虑给我们评分或留下评论，这真的能帮助更多听众发现这个播客。你可以在 Lennyspodcast.com 找到所有往期节目或了解更多关于本节目的信息。下期再见。

术语表

原文中文
11 Labs11 Labs（公司名）
AdeptAdept（公司名）
AdobeAdobe（公司名）
agent智能体（AI 领域术语）
agent-pilledagent-pilled（网络用语，指对智能体概念深信不疑）
AgentforceAgentforce（产品名）
Alan KayAlan Kay（人名，计算机科学家）
Amazon Web ServicesAmazon Web Services（产品名）
Anna MullerAnna Muller（人名）
Anna YangAnna Yang（人名）
AutoCADAutoCAD（产品设计名）
Big O notationBig O notation（计算机科学术语，首次出现）
Bret TaylorBret Taylor（人名，首次出现）
call deflection呼叫转移（呼叫中心行业术语）
CapEx资本支出（CapEx）
CharacterCharacter（公司名，即 Character.AI）
Christopher NolanChristopher Nolan（人名，电影导演）
Chubbies ShortsChubbies Shorts（品牌名）
Clayton ChristensenClayton Christensen（人名，哈佛商学院教授）
CodexCodex（OpenAI 产品名）
Competing Against Luck《Competing Against Luck》（Clayton Christensen 著商业书籍）
ConfluentConfluent（公司名）
containment承接解决（呼叫中心行业术语）
context engineering上下文工程（AI 工程术语）
CSAT客户满意度（CSAT，Customer Satisfaction Score）
CursorCursor（AI 编码工具）
DatabricksDatabricks（公司名）
DIRECTVDIRECTV（公司名）
ElonElon（人名，即 Elon Musk）
Endurance《Endurance》（Shackleton 南极探险纪实著作）
ERPERP（企业资源计划系统）
formal verification形式化验证（计算机科学术语）
FortranFortran（编程语言名）
FriendFeedFriendFeed（产品名，首次出现）
Garrett LordGarrett Lord（人名，首次出现）
go-to-market市场进入策略（go-to-market）
Google MapsGoogle Maps（产品名，首次出现）
HarveyHarvey（公司名）
hyperscaler超大规模云服务商（hyperscaler）
Inception《盗梦空间》（电影名）
InflectionInflection（公司名）
Internet ExplorerInternet Explorer（产品名）
Jobs to be DoneJobs to be Done（产品理论框架）
Larry SummersLarry Summers（人名，经济学家、OpenAI 董事会成员）
Lenny RachitskyLenny Rachitsky（人名，首次出现）
MadhavanMadhavan（人名，定价专家）
Marc BenioffMarc Benioff（人名，首次出现）
Marissa MeyerMarissa Meyer（人名，首次出现）
Mark Zuckerberg马克·扎克伯格（人名，首次出现）
Michael TrellMichael Trell（人名）
Model Context ProtocolModel Context Protocol（技术协议名，简称 MCP）
NetscapeNetscape（产品名）
News FeedNews Feed（Facebook 产品功能名，首次出现）
OluKaiOluKai（品牌名）
one click comment一键评论（产品概念）
OracleOracle（公司名）
outcomes-based pricing基于结果的定价（定价模式）
ParkerParker（人名，指 Parker Harris）
PerlPerl（编程语言名）
PLG产品驱动增长（PLG，Product-Led Growth）
pull requestpull request（软件开发术语）
QuipQuip（产品名，首次出现）
ReactReact（技术框架名）
resolution-based基于解决结果的（定价模式）
RevitRevit（产品设计名）
root cause analysis根因分析（工程术语）
RustRust（编程语言名）
SaaS软件即服务（SaaS）
SalesforceSalesforce（公司名）
SAPSAP（公司名）
self-reflection自我反思（AI 智能体术语）
ServiceNowServiceNow（公司名）
ShackletonShackleton（人名，南极探险家）
Sheryl Sandberg谢丽尔·桑德伯格（人名，首次出现）
ShopifyShopify（公司名）
SierraSierra（公司名，首次出现）
SiriusXMSiriusXM（公司名）
SnowflakeSnowflake（公司名）
SonosSonos（品牌名）
StripeStripe（公司名）
tokentoken（AI 计费单位）
TwilioTwilio（公司名）
VibeCodingVibeCoding（概念名）
virtuous cycle正向循环（管理学术语）
Visual Studio CodeVisual Studio Code（产品名，首次出现）
Warren BuffettWarren Buffett（人名，首次出现）
WayfairWayfair（公司名）
Weight WatchersWeight Watchers（品牌名）
Xerox PARCXerox PARC（研究机构名）

此文档由 AI 分片翻译（translate_long_document）