重读《精益创业》：生成式 AI 项目为何普遍失败

企业已经向生成式 AI 投入数十亿美元，但其中大部分项目并没有带来可衡量的回报。MIT NANDA 计划 2025 年的一项研究发现，约 95% 的企业级生成式 AI 试点都没有产生可被测量的影响。模型本身是有效的，真正失效的是项目运行的方式。

失败的根源：把一次押注当成了实验

问题并不新鲜。过去企业很少用迭代方式构建软件，反而更习惯于一次下注、提前规划、整年后再上线。Eric Ries 在 2011 年出版的《精益 Startup》中，正是为了纠正这种做法才写下了「构建—测量—学习」的循环。他强调的核心不是发布速度，而是学习速度。

生成式 AI 的出现让执行成本大幅下降，但也让这种「先把一切想清楚再做」的旧习惯显得更为危险。文章作者认为，设计行业同样有自己的「提前大投入」传统——例如以 IDEO 为代表、动辄持续数月、设计思维五步法（移情、定义、构思、原型、测试）的项目流程。在原型一个下午就能完成的今天，再用一整个季度去做「移情地图」式的研究，很难再被称为严谨，更像是过场。

设计领域的精益回归

作者回溯了自身经历：在《精益 Startup》出版之前，设计团队就已经在做两周冲刺、持续学习和数据复盘。本文想要强调的是，用户理解本身并不过时，过时的是「在能小步学习时仍然把移情流程前置」的仪式感。

文章给出的四条核心建议如下：

• go and see（到现场去）：问题发生在工作现场，而不在会议室。这一原则源于丰田的「genchi genbutsu」。
• 先命名任务再构建产品：写下一个具体的人要完成的具体任务；如果写不出来，说明还没有真正的产品方向。
• kill demo-driven roadmaps（砍掉只服务于演示的路线图）：停止为取悦会议室而投钱，转向支持那些「在一个普通周二能撑住使用」的产品。
• 保持 build—measure—learn 循环：善用 Google Ventures 团队在《Sprint》中提出的五天方法，让真实用户在一周之内使用原型，把想法的成本压到可以承受。

真正的瓶颈不是模型，而是工作方式

文章引用 CB Insights 对数百家初创公司复盘的结论：产品市场不匹配依然是失败的第一大原因；资金耗尽只是结局，找不到用户的真实痛点才是开端。MIT 的研究也明确表示，生成式 AI 项目的失败并非因为模型不够强，而是因为这些工具被设计来「展示创新」，而不是解决某个真实岗位上的工作。

作者进一步指出，不管是 Mary 与 Tom Poppendieck 二十年前把丰田精益思想引入软件开发的《Lean Software Development》，还是 Ries 的《精益 Startup》，抑或 Google Ventures 的《Sprint》，都指向同一件事：先放大学习、让决定尽可能晚地做出、把大而全的前期规格视作浪费。在生成式 AI 拉低执行成本的今天，这套循环终于变得可以负担。瀑布式的「想清楚再全部建」已经过时，许多企业只是还没有真正给它举行葬礼。

给设计师的启示

文章最后强调：「变化的只有工具，UX 的法则并未因此改变。」对设计团队而言，这意味着仍然要去现场、仍然要先定义任务、仍然要让原型在真实使用场景中被检验。生成式 AI 把执行变得廉价，正好是把「先学习、后构建」的方法论重新放回工作中心的机会。