别再入局大模型，除非你是马斯克！OpenAI董事长90分钟深度访谈

逐渐地，当人们谈论一家Agent公司时，它会看起来有点像SaaS公司。你会更少地谈论如何处理模型，就像现代SaaS产品中很少有人会问你用了什么数据库一样，而是会更多地询问你的工作流程和你带来了什么商业成果。你是为销售团队创造潜在客户？还是在降低采购成本？不管你提供什么价值，这个方向都会逐渐发展下去。

我对此非常兴奋。我并不认为初创公司应该去构建基础模型。你当然可以尝试，如果你对未来有愿景，那就去实现它，但我认为这是一个已经趋于集中、竞争激烈的市场。而我对另外两个市场非常感兴趣，尤其是随着构建Agent变得越来越容易，我们将会看到大量“长尾”Agent公司涌现出来。

我最近浏览了一个网站，列出了市值排名前50的软件公司。毫无疑问，前五大公司是像微软、亚马逊、谷歌这样的巨头，但接下来的50家全都是SaaS公司。其中有些公司令人兴奋，有些则非常无聊，但这正是软件市场的发展轨迹。

我认为我们会在Agent市场看到类似的趋势。它不会只是客户服务或软件工程等几个巨大市场，还会覆盖许多目前人们投入大量时间和资源的领域，而这些领域完全可以被一个Agent解决。但这需要创业者真正深入理解某个业务问题。我认为AI市场的巨大价值，将在这一领域释放。

Bret Taylor：去和经济学家，比如Larry Summers（他和我一起在OpenAI董事会）交谈，他们会从经济角度看技术的价值所在：技术推动了经济的生产力增长。

回顾历史，生产力的大幅跃升出现在上世纪90年代。很多我交流过的人都认为，那次飞跃是第一波信息化浪潮——企业开始使用ERP系统，把会计等内容搬进了电脑和数据库，甚至是主机系统。

我们说的还不是PC时代，而是更早期的企业信息化。那种变化是真正颠覆性的。想象一下，一个跨国企业的账本在计算机化之前需要多少人力才能完成。而信息化彻底改变了整个部门。

我举个例子来说明这个生产力提升。我父亲刚退休，是一位机械工程师。他说自己在70年代末进入工程行业时，公司大多数人都是绘图员。也就是说，你有一个设计方案，但需要为每个楼层、每个角度绘制视图，然后提供给承包商。

而现在，他所在公司已经没有绘图员这个职位了。设计图直接在AutoCAD上完成，现在甚至用Revit建模，直接出3D图纸，绘图这个流程已经完全消失了。这项工作根本不需要再做了。设计和绘图的分工也不存在了，只剩下设计本身。

这就是真正的生产力提升。机械工程公司的职责是做设计，绘图只是为了交付给施工方的中间产出，它本身并不增加实际价值，只是供应链的一部分。

从PC时代开始回顾软件产业发展史，我们确实获得了生产力提升，但远不如最初那次飞跃显著。我并不清楚原因，但这很有意思。技术带来的生产力提升，并没有如很多人预期的那样全面实现。

我认为Agent将再次拉动这条曲线，就像计算机早期那样。因为软件正从帮助个人提高效率，迈向自主完成完整任务。因此，就像机械工程公司里不再需要绘图员那样，未来也不会再需要人工去做某些工作了。这意味着这些人可以转向产出更高的作。

一小部分人就能完成更多事情，推动经济的整体生产力提升。企业软件销售会经历与客户之间关于“价值”的讨论。你需要设计一套略显复杂的逻辑，比如：假设你在销售一个销售类软件，如果每位销售人员的业绩提升5%，那么你们公司就应该因此多赚多少钱，所以你应该支付我们一百万美元。这样的讨论往往很难精确归因。

这也是为什么销售生产力软件会如此困难，我是通过切身经验学到的。很难评估让每个人的效率提升10%到底价值几何。你真的让他们效率提高了10%，还是其他因素在起作用？你其实并不清楚。

但现在，当一个Agent真正完成了一项任务，不仅确实以非常现实的方式推动了生产力提升，而且这种提升是可衡量的。这些因素结合在一起，让我觉得这是我们看待软件的方式上的一次跨越式变化，因为它可以自主完成工作，这种自主性本身就更直接体现了它对效率的推动作用，并且是可以量化的。因此人们对它的价值判断也会不同，这也是我相信软件应该基于结果来定价的原因。

我觉得它对软件行业的变革意义堪比云计算，甚至从技术角度来看可能更甚。从商业模式的转变角度来看，肯定是一次有“前后时代”之分的重大变革。我不知道还有多少人还在销售永久授权的本地部署软件，但现在应该已经非常少了。

我认为我们将经历类似的转变，整个市场会转向Agent，转向基于结果的定价方式。并不是因为那是唯一的选择，而是市场会自然地推动大家走向那条路，因为这显然是构建和销售软件的正确方式。

主持人：前段时间我和另一位嘉宾讨论了AI公司的定价策略，他非常认同你的观点——如果可以，就应该按结果定价。提出的逻辑和你刚才讲的一样。你能不能简单解释一下“基于结果定价”是什么意思？然后再以Sierra为例说明它是怎么运作的？

Bret Taylor：我先从Sierra的例子讲起，然后再泛化一下。我们在Sierra帮助公司构建面向客户的AI Agent，主要用于客户服务，也更广泛地服务于客户体验。

如果你在使用SiriusXM收音机时遇到问题，你打电话或在线聊天时接待你的就是我们的AI Agent Harmony。如果你用的是ADT的家庭安保系统，警报器出了问题，你也可以和他们的Agent沟通。还有Sonos音响等很多消费品牌都在用我们的产品。

运营电话客服中心时，每接一个电话都有切切实实的成本，大部分是人力成本。一通普通电话的成本可能在10到20美元之间，虽然其中有一部分是软件或通信费用，但主要还是接听者的薪资。

如果Agent能够接管这个电话并成功解决问题，这在行业中被称为“呼叫分流”或“问题封闭”，本质上意味着你节省了大约15美元，因为无需人工介入。

在我们的行业里，只要Agent能解决客户的问题，客户满意，且无需人工干预，我们就按照事先约定好的价格收费。我们称之为“基于问题解决的计费”。

当然也有其他结果导向的模式，比如我们的一些销售类Agent是按销售佣金来计费的。我们确实把Agent视为客户体验的一部分，像是品牌的礼宾服务。我们希望我们的商业模式与客户的业务模式高度一致。

正如你说的，Agent需要是自主运行的，结果必须是可衡量的。虽然这并非总能做到，但在大多数情况下是可行的。

这套模式特别好的一点在于，任何一个首席财务官或采购负责人，在面对主要供应商时，看着那长长的账单往往会感到困惑，很难判断自己到底有没有从合同中获得期望的价值。

按用量计费的方式，尤其是在基础设施领域比较流行的那种，是朝这个方向迈进的一步。但我并不认为“按Token数”就是衡量AI价值的好方法。我常用一个类比：现在大多数编程Agent是按Token或使用量计费的，就像那个著名的苹果工程师的故事——他有个差劲的经理要求他每天报告写了多少行代码，这种衡量方式对所有工程师来说都是荒谬的。

他后来在日报上报了一个负数，因为那天他重构了代码，删了很多行，这是他对这位上司的反击。我觉得Token计费就和那种逻辑类似。你用了很多Token，好像看起来不错，但真正的问题是：你有没有产出一个高质量的Pull Request？

这正是关键所在。我认为基于结果定价和基于用量定价之间有本质区别，尤其是在AI领域，两者甚至都未必相关联。你可以接一个很长的电话却没解决客户问题，客户可能还会在网上留下差评、再次打电话，那所有的投入都白费了，甚至造成了负面价值。我非常相信这种模式。

我觉得软件行业就应该朝这个方向发展。这当然对公司的组织形态有很高要求，你必须真正能帮助客户实现他们的目标，不能只是把软件扔过去了事，因为如果没实现结果，你根本不会拿到钱。

采用这种模式后，公司就会变得极度以客户为中心。我觉得这会让软件行业变得更好，从第一性原理的角度看就是对的，对采购方也是合理的，对整个世界而言也是正确的方向。

主持人：我们刚刚聊到了一些关于生产力提升的话题。现在媒体上对AI是否真的能提升效率抱有很多怀疑，比如“AI到底在做什么”、“真的让人更高效了吗”。最近有一项研究显示，AI甚至让工程师效率变低了。除了我们刚才谈到的客户体验之外，在你们公司，或者你们合作的其他公司中，还有看到明确的生产力提升吗？

Bret Taylor：我对AI提升生产力非常看好，但我确实认为目前很多工具和产品还比较不成熟。举个例子，现在几乎每家软件公司都会使用类似Cursor这样的工具来辅助开发者。多数人现在把Cursor当成自动补全的工具来用。

它还有很多Agent功能，OpenAI的Codex、Anthropic的Claude等都有类似功能，很多编程Agent方案正在涌现。

但其中一个问题是，由于技术还不成熟，Agent生成的代码里经常会有错误，而检查他人或者Agent生成的代码，实际上比修改自己写的代码还要难。

如果生成的代码经常出错，你需要花费大量的认知精力和时间去修复。事实上，如果它给你的客户带来了各种问题，你可能表面上是开发了很多新功能，但其实却把系统弄得更混乱，效果适得其反。

目前有几种有趣的技术路线。首先是很多AI创业公司正在开发代码审查工具。我认为“Agent的自我反思是非常关键的一点，用AI去监督AI其实非常有效。

你可以这样想：如果你做了一个Agent，准确率90%，这其实并不算太好。但要开发另一个Agent去找出那10%的错误，听起来却是个可以解决的问题。

假设这个“审查Agent”准确率也有90%，那么将两者组合起来，整体准确率就可以达到99%，这其实是一个数学问题。

可以用一个系统来生成代码，再用另一个系统来审查它，本质上就是用计算力来换取认知能力。可以层层叠加认知、推理、判断过程，从而产出更稳健的结果，这点让我非常兴奋。

另一个关键是“根因分析”。我们公司有一位工程师专门负责服务我们Cursor实例的MCP服务器。我们的理念是：当Cursor生成了错误的代码时，我们不只是去修复它，而是要找到根本原因，确保下次它能生成正确的代码。

这本质上是一种“上下文工程”。我们要思考的是：Cursor缺少了什么样的上下文信息，才导致它无法产出正确的结果？

我认为，那些希望在软件工程等部门实现生产力提升的人，如果想要现在就看到效果，就必须停止等待模型能力的升级，转而进行根因分析，弄清楚每一行糟糕代码的根源，并提供正确的上下文，构建合适的系统，让模型今天就能胜任这项工作。

这类工作可能会逐渐减少，对上下文工程的依赖也会减轻。但现在，你必须把这件事当作一个系统来思考。我看到很多人仍在等待模型自己变得更好。我想说，那终究会发生，但如果你想现在获得成果，你就得付出努力。这正是应用型AI公司存在的原因。

虽然工作并不简单，但它是可以做到的。对于那些使用像Sierra这样的平台的客户来说，没错，AI Agent不完美，但我们正在打造一个系统，让客户可以持续改进，形成正向循环。

如果你想把自动化解决率从65%提升到75%，我们有无数工具帮助AI实现这个目标。识别优化机会，搞清楚用户不满的原因，思考我们还能为Agent增加哪些新功能来提升解决率——你可以让AI帮你大海捞针式地找出关键问题，这才是优化这些系统的正确方式。

主持人：我以前从没听说过通过增加上下文来改进Cursor的做法，具体是怎么实现的？你是搭了一个MCP服务器，所有内容都要经过它，还是加了Cursor的规则？这个方法到底是什么？

Bret Taylor：这已经有点超出我的理解范围了，但基本上就是用MCP，这就是你给Cursor提供上下文的方式。我认为，如果模型本身能力没问题，却做出了错误决策，那问题就在于上下文不足。

要找出你的产品和代码库与这些编码Agent可用上下文之间的交叉点，然后从根本上修正问题，这就是核心原则。

主持人：你提到仍然把自己定位为工程师，听说你还会靠写代码放松。现在不少大学生在问：还值得学编程吗？未来几年这个领域会不会发生巨变？

Bret Taylor：我仍然觉得“学计算机科学”和“学写代码”是两回事。学计算机科学依旧非常有价值，因为它不只是写代码。理解大O记号、复杂度理论、算法，知道为什么两个复杂度相同的算法在实践中性能不同，为什么缓存未命中很重要——这些知识的意义远远超出敲代码本身。

写代码这件事，我认为会从“人往终端或VS Code里敲字符”变成“人操作一台代码生成机”，我认为这会成为软件工程的未来。不过，要用好这台机器，需要系统思维，而计算机科学正是培养系统思维最好的学科之一。

最终，AI会承担大量软件开发工作，但人的任务是操作这台机器去打造产品、解决问题。要有很好的系统性思维，必须理解技术与商业问题的交集，并设计能真正解决客户问题的系统。系统思维永远是做产品最难的部分。

举个简单例子：在Facebook设计NewsFeed时，设计师用Photoshop做的原型永远完美——照片漂亮、文字优雅、长度刚好、评论友善。一旦上线，真实数据进来，NewsFeed立刻惨不忍睹：照片质量差、文字长短不一、评论里还有人骂你。

这时你才明白：用Photoshop设计NewsFeed是最简单的，真正难的是设计一个系统，让它在你无法掌控输入的情况下，依旧输出令人愉悦的内容和视觉体验。我们后来强制设计师必须用真实、凌乱的数据做原型，逼他们把过程做得更贴近现实。

AI生成代码、生成设计以后，你仍然需要在脑子里构建这套系统，理解什么难、什么易、什么可能、什么不可能。AI也能帮你做这件事。

我认为，随着AI Agents的出现，以及AI某些领域的能力接近“超人”水平，我们所使用的工具会出现深刻的变化。

人类不应再依赖于特定的行事方式，不应再纠结于“我现在擅长的事情，未来可能就没用了”这种问题。就像NASA早期用人类充当计算器一样，未来的人们可能会惊讶：“原来你们以前是一行行手写代码的？”

别因为“以后不用手写代码”就不去学这些学科，就像有人会说“我以后用不到数学就不学数学”。学数学的价值在于培养人的思维方式，同样的，计算机科学的基础知识，仍将是未来构建软件的基础。

尤其是在与比你聪明的系统协作时，它生成的代码你未必能一行行读完。你需要具备足够的能力，去约束它、引导它产出想要的结果，这需要大量技巧。

主持人：这让我想起你最近在一档播客里提到的一个观点——你认为应该出现一种新的编程语言，这种编程语言更适合大模型而不是人类。能展开说说吗？

Bret Taylor：我不确定它该叫“语言”，我倾向叫“编程系统”，因为“语言”这个词可能太窄。如果把过去40年甚至更久的计算机史简化版一下，大概的过程就是：先造硬件，再用打孔卡告诉机器干什么；接着出现操作系统、分时系统，于是有了C、Fortran等高级语言；再往上抽象，就很少有人写汇编、写C语言了，更多人用Python、TypeScript。

每一次抽象层提高，都让我们用更少的力气去干更大的事。今天再让人用React写一个可拖拽地图，很多工程师都能很快搞定，这在当年Google Maps时代是惊世骇俗的壮举。当Salesforce成立时，把数据库放到云端都是一件很困难的事情，能做到这点就已经是一条技术护城河了。现在，技术的护城河在不断缩窄，但产品的护城河依然存在。

如果我们假设写代码的人力成本趋近于零，那么我们过去几十年围绕“提高人类程序员效率”打造的所有抽象层的工具、语言，都需要重新评估。

我常开玩笑说，Python大概是大模型生成最多的语言，因为它在训练语料里无处不在，数据科学家又爱它。但从AI角度看，Python简直糟糕：慢、难验证、运行时错误多。它之所以存在，是为了让人写得舒服，像伪代码。

未来如果我们只需要操作代码生成机，我们根本不需要在乎语言对人类多“符合人体工学”，只在乎两件事：机器生成的代码能否被快速验证“确实做了我想要的事”；如果不对，能否很容易地进行改掉。

这就引出对“编程系统”的新需求。比如Rust之所以有意思，是因为编译器能静态保证内存安全，编译通过就等于没有内存泄漏。如果让AI生成一百万行C语言，你很难判断有没有泄漏；生成一百万行Rust，只要编译过就基本安全。

我们需要更多这种设计。如果人无法完全信赖AI的代码，需要逐行阅读、核验代码，那这将极大地限制编程的效率。如今，问题的关键就在于如何给人提供这种自动化核验的工具。

AI的自我核验当然是一种方式，让系统具备自我反思能力，确实是提高鲁棒性的一种有效手段。但我认为，如果不用再担心写代码是否繁琐，就可以重新考虑一些传统的技术手段，比如形式化验证、单元测试等。

把这些技术叠加起来，我脑中会浮现出一个画面，就像《黑客帝国》里的那个人，看着屏幕上流动的绿色代码，思考：我怎样才能构建出一个让操作者能够高效产出极其复杂、规模庞大的软件系统，并且确信它是正确的系统？

从这个目标出发来做设计，那你可能会改变编程语言、系统架构，甚至所有相关的构建方式。最有意思的是，这一过程中我们可以放宽许多限制，比如——“写代码是免费的”。这真的很酷。

那么在这种前提下，你会想做什么？哪种语言、编译器、测试框架、自我反思机制或监督模型才最适合？我认为这不是单一的编程语言问题，而是整个编程系统的设计问题。

一旦我们构建出这种系统，它将真正赋能创造者、开发者们，让他们得以构建出既复杂又鲁棒的系统。我对“vibe coding”感到非常兴奋，但我不认为“快速生成原型”曾是软件开发的核心瓶颈。

真正的挑战，是如何构建日益复杂的系统，并具备灵活改动它们的能力。可以回顾下当年Netscape浏览器从1.0到2.0的重写过程，很多人认为这就是它输给Internet Explorer的原因之一。

写出一个系统并不难，难的是维护它，并保证它的鲁棒性。我觉得我们正处于定义“下一代软件开发体系”的初期阶段，我非常期待它将如何演化。

主持人：当你这样的人在谈论要打造一种类似《黑客帝国》的编程体验，并认为这可能是未来的开发方式时，我真的觉得我们已经身处未来了。我迫不及待想看到它成真——这将是一次伟大的机会，也是一个非常有趣的项目。

主持人：现在很多AI初创公司在市场化方面遇到困难。各种AI应用、产品层出不穷，你在AI产品，特别是Agent类产品的市场落地方面，有哪些经验值得大家借鉴？

Bret Taylor：我认为成功的市场落地路径其实就那几种，关键是要选对匹配你产品类别的方式。

第一种是开发者主导。

Stripe和Twilio就是这个典型，他们的市场策略是吸引某个工程师，通常在CTO负责的部门里，这些人有选择工具的决策权。这种方式适用于平台类产品。

如果你的产品是帮助某个业务部门的，那就不适用，因为这些业务线通常没有专属的工程师团队，也没有权限去随便下载库或接入服务。如果你的客户是初创公司，这种方式特别管用，因为初创团队的工程师常常有决策自由去选择他们喜欢的服务，来解决创始人提出的问题。

第二种是产品驱动增长。

虽然每家公司的产品都很重要，但这里的意思是用户可以直接在官网注册，通常可以试用，也可以用信用卡买几个账号。这适用于使用者和购买者是同一个人的情况。小型商业软件几乎都属于这类，因为个体户什么都得自己处理。

比如早期的Shopify，还有很多类似产品，主要面对小型商家，这种方式非常合适。但如果使用者和购买者不是同一个人，这方式就不灵了。比如报销软件，用的是普通员工，买的是财务部，用信用卡购买就不合逻辑，因为实际使用者并没有公司信用卡。

第三种是传统直销。

直销曾一度被认为过时了，但如果我想到最强的直销公司，很多都来自Oracle体系，比如SAP、ServiceNow、Salesforce、Adobe等。他们都通过传统销售流程向大企业的业务线销售产品。

由于产品驱动增长一度很火，很多公司也跟着走，确实也能催生出优秀产品。但如果产品驱动增长，导致你完全没有和真正的软件购买者打交道，那你是不会成长的。

我最近看到越来越多AI公司开始重新重视直销方式。因为AI的很多机会，确实是使用者和购买者不同的情况，确实需要这种市场推进方式。

很多创业者的问题是，选择了某种市场策略，却没有认真思考客户是怎么购买软件的。怎么评估软件的价值？我认为人们需要从第一性原理出发，更加深入思考。

坦率地说，我觉得很多公司其实应该更多地采用直销。尽管有些直销公司的产品质量名声不太好，但这只是个别情况。我很高兴看到直销正在市场中重新获得重视。

主持人：我觉得这个信息是很多创始人需要听到的，尤其是那些不具备商业背景的创始人，他们对“销售”本能抗拒，认为自己不擅长。但有时候你必须变得擅长这件事，这就是你能否成功的关键，不能只靠产品带动增长。

我在2002年底或2003年初加入谷歌，是最早的助理产品经理之一，起初负责搜索系统，将索引规模从10亿扩展到100亿。表现不错后，我得到了Marissa Mayer（谷歌第一位产品经理）的信任，被安排负责一个全新产品项目。

对我来说，这是一次重要机会，也面临很多人的审视，毕竟我是个刚起步的年轻产品经理。

Bret Taylor：我想再补充一点。对创始人和产品经理来说，有一个常见的陷阱是讲错故事，比如把“人们不喜欢我们的产品是因为 X”当成事实，告诉公司里的所有人，然后据此调整战略，如果判断错了，可能会导致公司方向彻底跑偏。

当你失去一笔交易时，销售往往会归咎于“价格太贵”，但真正的原因可能是客户根本没看到你的价值——问题在于产品缺乏差异化。结果，你围绕定价做文章，却忽略了更深层次的产品问题。

就像分手时人们不会直说“我不喜欢你了”，而是习惯性地说“不是你的问题，是我的问题”，因为我们总想维护关系的和谐。类似地，用户或客户在调研中给出的反馈也未必准确，你必须深入分析、抓住核心。

可惜，很多初创公司的创始人容易陷入“单议题选民”陷阱：工程师只信工程能解决一切，产品设计师只信一次redesign，而BD背景的人只信大合作。现实中，没有哪一种方法能一招搞定所有问题。

真正优秀的创始人，会清楚地认识到自己是有偏好的，人天然会更倾向用自己的强项去解决问题，但你需要保持警觉，时刻注意自己是不是因为习惯而选择了这一方向，而不是遵循真理。

创始人需要一个能够坦诚对话的联合创始人和领导团队，共同验证思路，确保方向正确。尽管“今天我能做的最有影响力的事是什么？”是一个极好的思考框架，但要准确回答它，却比你想象的要难得多。

我们做了一个社交网络，发明了Newsfeed（信息流）和“点赞”按钮，这些功能之后都很流行。当时我们发现平台上有很多评论都是“Wow”、“Nice”这样表示“我看到了”的内容，而我们想让评论区里有真正的讨论。点赞按钮就是这一问题的解决方案。

不过，我们只在土耳其、意大利和伊朗流行了起来，后来伊朗封了我们，只剩土耳其、意大利和硅谷。直到今天，还有人说“我爱FriendFeed”，我就说“那太好了”。

但它不是一个成功的商业模式。我们是“关注型”社交网络，用户关注特定用户，获取信息，更像Twitter而非Facebook，分享的是新闻、兴趣、科研等内容。那年夏天，奥巴马和奥普拉等人都入驻了Twitter，我们被彻底碾压。

我们团队几乎全是工程师，埋头打磨产品。而Twitter专注拉名人入驻，这是“关注”场景下显而易见的策略：如果要打造一个基于关注的社交网络，那就得拉一些值得关注的人加入。虽然我们功能更多、上线更快、几乎零宕机，但我们却输了，这一失败和产品本身没有任何关系。

这也说明了谷歌出身的创业者一个通病：在谷歌太顺了，产品经理往往忽视分发、设计，甚至不思考商业模式，因为从广告上已经赚得盆满钵满。相比之下，PayPal黑帮这样的人在创业上学得更多，我们被现实打脸了。

我可以说出FriendFeed产品方面的很多问题，但我认为那不是失败的关键。我后来逐渐补齐了短板，但如何准确判断应该做什么是很困难的。没经验时很难有直觉。

做FriendFeed时，我不是找不到名人加入，而是根本没去找有经验的人咨询相关问题。科技圈信息很多，难的是选择听谁的。我们当时太专注产品，没请外部人指出问题，也没请教行业专家。这让我成为董事会和高质量建议的坚定信徒。

主持人：如何判断谁的意见值得听？

Bret Taylor：这确实需要判断力。有一点很重要：一个人表达意见时的自信程度，和意见的质量往往并不正相关。现在播客这么多，有时我对非常熟悉的话题，发现最自信的说法其实错得离谱，却极具说服力。所以得靠判断力。

一个办法是：不仅问“我该怎么做”，还问“我该去问谁”。你会发现有些人总被反复推荐，那就是强信号。

另外，问建议时不要只问“做什么”，还要问“为什么”。像个两岁小孩一样不停地问“为什么”，直到你理解对方给出建议的框架。

其实，大部分建议往往来自极少数经历，人们会说“永远别做X”或“永远做Y”，但那其实只是某次经历让他们后悔或庆幸。得多问问不同人的意见，据此整理出你的第一性原理，应用时要分情况，而不是简单照抄。

说到底，判断力来自自省和复盘。如果你做了一个糟糕的决定，花时间反思为什么，并持续提高自己的判断力——这才是优秀创业者或产品经理的核心能力。

其次，当听取建议时，一定要弄清建议的来源和背后的原因，这样你才能形成自己独立的观点；同时要意识到，任何人的建议基本都不具备统计显著性。