被当众羞辱后，Steve Jobs 没有反击，而是解释了产品决策的起点
Published:
一个人当众说 Steve Jobs 根本不懂技术，他停了十几秒，没有反击，只问了一件更重要的事，用户最终能得到什么？
我最近在 LinkedIn 上刷到一段短视频，标题把它包装成 Steve Jobs 面对羞辱时的完美回答。短视频确实剪得很燃，但如果只把它理解成高情商话术，反而错过了真正有价值的部分。
这是 1997 年苹果全球开发者大会，也就是 Worldwide Developers Conference 的现场问答。台下一位观众质问 Jobs，要求他解释 Java、OpenDoc 等技术，还说他根本不知道自己在谈什么，并追问他离开苹果后的七年到底做成了什么。完整录像保留了问题和回答，比社交媒体上的字幕切片更值得看。
OpenDoc 是苹果参与开发的一套软件组件框架。它试图让不同程序生成的内容像积木一样嵌入同一份文档。这个项目在工程上有想象力，也聚集了一批投入多年的开发者，但苹果在 1997 年终止了它。对台下那位提问者来说，这不是抽象的战略调整，而是苹果抛弃了一条他相信的技术路线。
所以，那不是一个毫无来由的喷子问题。问题里的攻击很直接，背后的失望也真实。
Jobs 沉默了一会儿，喝了一口水，然后承认，对方在某些地方是对的。他不可能熟悉所有技术细节，过去也犯过很多错误。
接着，他没有试图证明自己比提问者更懂 OpenDoc。他把判断尺度换了。
他的核心原话只有一句就够了，产品团队必须「start with the customer experience and work backwards to the technology」，从用户体验开始，再倒推技术。
这句话经常被解释成用户至上，但它真正解决的是资源选择问题。一家公司面对十个看起来都不错的技术项目，却只有能力做好两三个，到底如何决定留下谁？
不能只问哪项技术更先进，也不能只问团队已经投入了多少年。要先描述用户最后会获得什么，为什么愿意使用或付费，再倒推产品需要哪些能力、系统和技术。如果这条因果链无法成立，技术再漂亮，也不足以成为公司继续投入的理由。
Jobs 当时用 LaserWriter 激光打印机举例。苹果并不是因为先掌握某种激光技术，才出去寻找市场。团队先看到用户需要更好的桌面出版体验，再组合激光打印、页面描述语言和 Macintosh 电脑，做成一个完整方案。
这里有一个容易被短视频剪掉的边界。Jobs 没有证明被取消的技术没有价值，也没有逐项回答提问者关于 OpenDoc 和 Java 的技术质疑。他回答的是另一层问题，为什么公司即使承认一项技术不错，仍可能停止它。
这个区别很关键。技术价值不等于产品价值，产品价值也不自动等于公司在当下应该投入的战略价值。
1997 年的苹果没有余裕把所有好项目都留下。计算机历史博物馆的回顾指出，Jobs 回归前后，苹果一个季度亏损超过 7 亿美元，现金持续消耗，生存本身已经成为问题。Jobs 后来砍掉大量分散的项目，把资源集中到少数产品上。站在这个背景里，他的回答不是一句营销金句，而是一套生存期资源分配原则。
我觉得这套原则放到今天的 AI 产品和科学研究里，甚至更重要。
现在我们太容易从技术出发。看到一个新模型、一套 agent 框架、一个新数据集，就立刻问能不能围绕它做个产品或发篇论文。于是研究计划常常写成，我们将使用某个模型解决某个问题。模型很具体，问题却只是一张用来填空的皮。
反过来做，问题会变成，谁在什么任务中受阻？现在的失败造成了什么成本？一个结果需要改善到什么程度，才会改变他的决策？我们如何验证这种改变不是一次演示，而是可以复现的能力？明确这些之后，再决定要不要用大语言模型、检索系统、强化学习，或者干脆不用 AI。
对 benchmark 研究也是如此。先做一批题，再找理由说它们重要，很像先造技术再找用户。更可靠的顺序是先定义我们希望测量的真实能力，找出现有评测遗漏了什么，以及分数变化能否预测真实任务表现，再倒推任务、数据、评分器和实验设计。
但我也不想把 Jobs 的话奉为万能公式。基础研究经常在没有明确用户需求时发现新现象，许多通用技术也会在多年后才找到用途。如果所有研究都必须先写出短期用户故事，人类会错过大量知识。
所以这套原则有适用范围。它特别适合资源受限的产品团队、应用研究、工程项目和以真实任务为目标的 benchmark。它不应该被拿来否定探索性研究。
我从这段视频里学到的另一件事，是如何处理公开质疑。Jobs 做了三个动作，承认对方说对的部分，不在自己不掌握的细节上装懂，然后说明自己真正负责的判断框架。他没有赢下一场关于 OpenDoc 的技术辩论，却让所有人看见他打算如何领导苹果。
这比一句机智反击难得多。
下一次我们被一个新技术打动，或准备启动一个新项目，也许可以先把展示页面关掉，问问那件最朴素的事。
用户或者研究对象最终能得到什么？
回答清楚以后，再把技术一步一步倒推回来。