AI 创业真正难的，不是做出 Demo

最近看了 Jake Heller 在 YC AI Startup School 的一场分享。

他是 Casetext 的联合创始人，后来靠 CoCounsel 把公司卖给了 Thomson Reuters。

但这场分享真正打动我的，不是那个 650M exit 的结果，而是他讲清楚了一件更重要的事：

这一轮 AI 创业里，做出一个看起来很聪明的 demo，已经没有以前那么稀缺了。真正稀缺的，是把 demo 变成一个客户愿意长期依赖的产品。

我觉得这句话，几乎可以当成今天很多 AI 项目的分水岭。

先说我的判断

如果把这轮 AI 创业浪潮浓缩成一句话，我会这么说：

真正的门槛，已经不在“能不能调到最强模型”，而在“能不能把一个工作流做深、做稳、做出信任”。

很多团队其实都能做出第一次演示：

• 输入一段话，输出一个像样的回答。
• 丢一个任务，系统看起来会自己跑。
• 做个界面，接上模型，演示的时候很惊艳。

但问题是，能演示 和 能交付 完全不是一回事。

客户真正买单的，不是“它有时很聪明”，而是：

• 它大多数时候靠不靠谱。
• 它错的时候能不能被发现。
• 它能不能嵌进现有流程。
• 团队敢不敢把真实工作交给它。

我觉得 Jake Heller 这场分享最强的地方，就是他一直在讲这条鸿沟。

AI 时代，选题逻辑已经变了

过去做软件，常常要猜“用户到底想要什么”。

现在做 AI，有一种更直接的办法：去看用户今天已经在为哪些工作付钱。

这是他整场分享里我最喜欢的一个切口。

如果今天一家公司还在花钱请人做某件事，那至少说明两件事：

• 这个需求已经存在。
• 这件事本身有预算。

这比从“模型最近多了什么新能力”出发，要扎实得多。

他把 AI 创业机会拆成三类：

• assist：辅助人做事
• replace：直接替代这项工作
• do the unthinkable：做以前因为人力太贵而根本不可能做的事

这个框架表面上是在帮人找点子，实际上是在逼你回到一个更硬的问题：

你做的到底是不是一个真实工作流，而不是一个看起来很酷的功能。

我很认同这一点。因为很多 AI idea 最大的问题，不是不新，而是不够“真”。它们更像一句 slogan，而不是一项已经存在、正在被执行、正在被付费的工作。

好的 AI 产品，核心不是 Prompt，而是 Workflow

这场分享的第二个重点，是他对“怎么做产品”的理解。

他的思路不是先问：

• 要不要做 agent
• 要不要上多轮推理
• 要不要搞一个自动化系统

他先问的是：

这个行业里最强的人，真实是怎么把事情做完的？

我觉得这是一个特别重要的区别。

很多 AI 产品之所以做浅，不是模型不够强，而是团队从来没有认真理解过目标任务本身。他们在自动化一个自己并不真正懂的东西。

Heller 的做法非常朴素：

• 先把专家做事的流程拆出来。
• 看哪些步骤是确定性的。
• 看哪些步骤真的需要判断、归纳、理解。
• 能用普通软件工程解决的，不要硬塞给模型。
• 真需要模型的部分，再认真设计 prompt 和上下文。

这其实是在给“agent”降温。

不是所有问题都要 agent 化。很多任务，如果路径稳定、步骤固定，用普通 workflow 就够了。只有那些会随着情境变化而变化的流程，才真的需要更 agentic 的结构。

所以在他这里，AI 产品的核心不是“智能感”，而是“流程建模能力”。

这点我觉得特别值钱。因为它会直接改变一个人做项目的起点：不是先想模型能干什么，而是先想这件事原本是怎么被完成的。

Evals 才是 Demo 和 Product 的分界线

如果说前两部分是在讲选题和构建，那我觉得这场分享最硬的一部分，是他讲 evals。

他的意思很直接：

很多团队能把东西做到 60% - 70% 的水平。这已经够拿去融资，够做演示，甚至够拿到 pilot。

但这还远远不够成为产品。

因为生产环境里最重要的，不是“偶尔很惊艳”，而是“持续靠谱”。而“持续靠谱”这件事，靠感觉是做不出来的，只能靠评测、反馈和反复迭代磨出来。

这也是为什么我越来越认同一个说法：

AI 应用团队真正的工程纪律，不是把 API 接起来，而是把 eval 建起来。

没有 eval，你根本不知道系统到底哪里错。没有 holdout，你也不知道自己是不是只是在对着样例集调 prompt。没有错误模式分析，你就只能在“这次好像不错”里自我感动。

Heller 讲得很现实：很多人做到 60% 就放弃了，觉得“AI 不能干这个”。但他真正相信的门槛是，团队愿不愿意围着一个任务，花很长时间去磨 prompt、补样本、修错误模式。

这背后其实是一种很朴素的创业判断：

护城河很多时候不是理念，而是有人愿意把脏活累活做到底。

AI 产品不是界面，而是一整套信任系统

这场分享里我最想记住的，不只是那句“产品不只是屏幕上的像素”，而是他其实讲清楚了一整套关于 trust 的产品观。

在 [00:27:06] 到 [00:30:15] 这一段里，Heller 讲的不是“怎么让用户觉得你很强”，而是“怎么让用户在真实工作里慢慢敢用你”。我觉得他主要讲了五层。

第一层，AI 天然有 trust gap。
对很多公司来说，AI 不是普通软件升级，而是 something new and scary。客户不是没兴趣，相反他们很想试。但问题是，他们过去把工作交给人，人可以被训练、被纠正、被管理，AI 还没有这种默认信任基础。

第二层，信任不是靠口头承诺建立的，而是靠对比证据。
所以他提到 head-to-head comparisons。不要只做 demo，而是让客户拿真实任务，把现有人工流程跑一遍，再把你的 AI 产品跑一遍，然后一起看谁更快、谁更好、差异在哪。用户真正会信的，不是你的宣传语，而是他自己看到的结果。

第三层，pilot 不是终点，只是信任建设的开始。
[00:28:22] 之后他提醒得很现实：很多团队以为拿到 pilot 就算赢了，但很多 pilot 最后不会变成真实收入。这说明“愿意试”不等于“愿意长期用”，更不等于“愿意把关键工作迁进去”。

第四层，信任要靠 rollout 和 onboarding 被做出来。
[00:29:05] 到 [00:29:44] 他明确说，创始人的工作之一，是确保用户真的理解产品、真的会用产品。有时候不是把链接发过去就结束了，而是要有人坐在客户旁边，陪他们把第一轮流程跑通。很多 adoption 问题，看起来像销售问题，实际上是 deployment 和 enablement 问题。

第五层，product isn't just the pixels on the screen。
[00:29:46] 到 [00:30:13] 这句最关键。信任不只来自 UI，不只来自一次答案看起来对不对，还来自 support、customer success、training、deployment，来自产品周围那整套东西。也就是说，AI 产品卖的从来不只是“能力”，还包括验证路径、上手过程、出错后的处理方式，以及持续使用中的支持系统。

这也是为什么我觉得很多团队对 adoption 的理解还是太浅。他们会把 adoption 理解成一个产品问题，或者一个销售问题，但实际上它更像是一个系统问题。

客户愿意试，不代表客户愿意迁移。
客户愿意开 pilot，不代表客户愿意续费。
客户愿意夸 demo，不代表客户愿意把真实业务交给你。

这也是 Heller 为什么提醒：不要过度迷信 pilot revenue。很多 AI 公司现在看起来收入不错，但里面有不少其实只是“被好奇心驱动的实验预算”，不一定会转成真正稳定的使用。

所以判断一个 AI 产品是不是成立，不能只看“有没有人愿意试”，而要看“有没有人愿意真正依赖”。

所以，要让用户信任，实际该怎么做

如果把这段视频翻成更具体的产品动作，我觉得至少有六件事。

• 先定义用户到底在怕什么。不是笼统地说“他们不信 AI”，而是具体到：怕答错、怕不稳定、怕合规风险、怕流程中断、怕团队不会用。
• 做并排对比，不要只做 demo。让用户拿真实任务，用旧流程跑一遍，再用你的产品跑一遍，然后一起看速度、准确率和错误类型。
• 在 pilot 前先约定“什么叫合格”。比如准确率、漏报率、响应时间、人工复核比例。没有这个，pilot 很容易只剩感觉。
• 把 pilot 当成“信任建设期”，不是“签单已完成”。重点不是收一笔试用费，而是让用户真的把一小段工作流迁进去。
• 设计上手过程。不要把产品扔给用户就算完。给模板、示例、引导步骤、FAQ、人工支持，必要时做高接触 onboarding。
• 让系统“可验证”。AI 输出后面最好能附来源、引用、时间戳、证据链接、低置信度提示，而不是只给一个漂亮答案。

真正的信任，不是第一次下单，而是用户开始依赖它。

这对我自己的提醒

如果把这场分享落到我自己身上，我大概会记住四件事。

第一，不再从“我能做什么 AI 功能”出发，而从“什么工作今天真的有人在付费做”出发。

第二，不先想 agent，而先想 workflow。先把事情拆开，再决定哪些部分该交给模型。

第三，不把“能跑”当成“能用”。任何一个 AI 项目，只要我想认真做，都应该从一开始就配最小 eval 集。

第四，不把产品理解成一个输出框。证据、引用、置信度、验证路径、上手过程，本身就是产品的一部分。

比如对我来说，一个更值得做的小项目，不是“AI 总结视频”，而是一个更具体的 Founder Research Assistant：

输入一场访谈或演讲，输出一份带时间戳、带证据、可复核的 founder memo。

这个方向的价值不在“总结”，而在“可信”。它要求系统不能乱编观点、乱编引文、乱编时间点。

如果按 Heller 这套方法来做，错误做法是：用户贴一个 YouTube 链接，我回一段“看起来很像总结”的话。
更可信的做法是：每个结论后面都附时间戳、原句出处、低置信度标记，允许用户点回原文核查。

pilot 方式也应该更窄。不是一上来号称“通用研究助手”，而是先只做一个小场景，比如“创业者访谈提炼 5 个 actionable insights”。

trust 设计则应该是：先让用户拿你的输出和他自己手工做的笔记对比，看谁漏得少、谁编得少、谁复查更快。

而这恰好就是 Heller 整套方法能落地的地方：

• 从真实任务出发
• 拆清 workflow
• 把确定性步骤和模型步骤分开
• 用 eval 去压低幻觉
• 用证据设计去建立信任

我觉得这才更像是在做一个产品，而不是做一次展示。

最后

模型能力还会继续变强，工具也会越来越便宜。

但我越来越觉得，真正把团队拉开差距的，不会只是“谁先接到了新模型”，而是：

• 谁更理解真实工作流
• 谁更愿意做评测
• 谁更认真地把信任设计进产品里

能跨过 demo -> dependable product 这道坎的团队，才更像是在建公司。剩下的，大多还停留在演示阶段。