有些产品,不是被 AI 加速,而是被 AI 吞掉

今天看到 Karpathy 的一段炉边谈话整理，里面有三条线索。

第一，LLM 的意义不只是加速已有软件。它会让一部分原本需要 App、脚本、工具链才能完成的事，直接被语言模型吞掉。

第二，LLM 的能力是参差不齐的。它可以在某些任务上强到离谱，也会在一些人类觉得很简单的地方犯很低级的错。

第三，未来的产品和服务，可能会越来越围绕 Agent 来重新设计：信息怎么给它读，动作怎么让它调用，流程怎么让它接手。

这三条都很重要。

但最打到我的，是第一条。

因为它提醒我一件事：下班后做产品时，不能只问 AI 能不能帮我做得更快，还要问这件事会不会已经不该做了。

很多时候，我们理解 AI 的第一反应，是把它当成加速器。

写文章更快，写代码更快，做图更快，整理资料更快，写方案更快。

这当然是真的。

但如果只停在这一层，很容易把问题想窄。因为你还是默认原来的东西都应该存在，只是需要被 AI 提效。

原来有一个 App，现在让 AI 帮它写代码。

原来有一个流程，现在让 AI 帮它自动化。

原来有一个工具，现在让 AI 帮它补几个智能功能。

这类思路没有错，但它只是在旧地图上跑得更快。

真正更狠的问题是：这张地图本身还成立吗？

有些东西，不是需要被 AI 加速，而是会被 AI 直接吞掉。

Karpathy 举的第一个线索，是一些应用会被 LLM 完全吞没。

它原本看起来像一个 App：用户输入某个东西，系统处理一下，再输出一个结果。

但如果这个过程的核心只是理解输入、转换表达、生成输出，那它可能根本不需要一个完整的传统软件形态。

以前我们会想：我要不要做一个小工具？要不要做登录、页面、按钮、状态、导出、模板、历史记录？

现在要多问一句：这件事是不是直接在对话里就能完成？

如果一个产品只是把一句话变成另一句话，把一张图变成另一张图，把一段材料整理成另一种格式，那它很可能不是一个长期产品，而只是模型能力的一层薄包装。

这对下班后做产品的人很重要。

因为我们的时间本来就少。如果花几周做了一个东西，最后发现它只是一个很薄的模型入口，那不是执行问题，而是判断问题。

这件事也不能走向另一个极端。

不是所有产品都会被 LLM 吞掉。

有些东西会被吞掉，是因为它没有真实上下文，没有长期状态，没有工作流里的责任边界，也没有和现实世界的反馈闭环。

但有些东西不会。

比如它需要长期记忆，需要用户数据沉淀，需要团队协作，需要权限和审批，需要真实交易，需要稳定交付，需要和别的系统连接，需要承担结果。

这种产品不是一句 prompt 就能替代的。

LLM 可以进入它、增强它、改写它，但不一定能直接吞掉它。

所以关键不是喊一句“所有软件都会消失”，而是判断：这个产品的核心价值到底在模型能力里，还是在模型之外的上下文、流程、数据、关系和责任里。

如果价值主要在模型能力里，它危险。

如果价值主要在模型之外，它还有机会。

Karpathy 的第二条线索，是 LLM 能力的参差不齐。

这个现象每个用 AI 的人都熟悉。

它有时像一个很强的工程师，能帮你重构复杂代码、拆解一套系统、生成一份像样的方案。

但有时又会在非常简单的常识题、约束题、现实场景里犯错。

这不是单纯的“它聪明”或“它不聪明”。

更实用的理解是：你要看这个任务是不是容易验证，训练和强化学习里有没有足够多类似分布，以及模型犯错以后有没有清晰反馈。

代码为什么相对适合？

因为很多代码能运行、能测试、能报错、能回滚。它的反馈比较清楚。

现实生活里的很多任务为什么容易翻车？

因为约束很隐蔽，反馈很慢，常识很多，目标还经常不清楚。

这对做产品也很关键。

如果一个场景本身不可验证、反馈很慢、结果很难定义，那你不能简单相信“加个 AI 就行”。你需要给它更强的边界、更清楚的输入、更小的动作和更快的反馈。

第三条线索，是 Agent 原生经济。

很多人一听 Agent，就会想到自动执行任务、帮我订票、帮我写代码、帮我处理邮件。

但更底层的变化可能是：产品和服务要重新设计自己的信息接口。

过去产品主要给人看。

所以我们设计页面、按钮、菜单、表单、导航、说明文档。

未来一部分产品还要给 Agent 读。

它需要清楚知道：这里有什么信息，能调用什么动作，每个动作的风险是什么，哪些步骤需要确认，哪些结果要写回系统。

换句话说，产品不只是 UI 给人用，还要把自己的能力暴露成 Agent 能理解、能调用、能验证的结构。

这对普通 builder 的启发是：不要只盯着“我要做一个 AI 功能”。

更重要的是，你的产品有没有把信息、动作、反馈和权限设计清楚。

Agent 不是魔法，它需要可读的上下文和可执行的边界。

这三条线索放在一起，我觉得最有价值的不是预测未来，而是改变我们做产品前的判断顺序。

以前我可能会先问：

这个东西能不能做？

我能不能用 AI 更快做出来？

有没有类似产品？

这个方向是不是热门？

现在我会先问另一个问题：

它会不会被 LLM 直接吞掉？

如果答案是会，那我就要非常谨慎。

因为这意味着我可能不是在做产品，而是在做一个随时会被模型能力覆盖的中间层。

更值得做的方向，往往不是“把模型能力包装一下”，而是把模型接入真实场景，解决那些需要上下文、责任、反馈和持续迭代的问题。

一个人做产品，最怕的不是做得慢。

最怕的是做得很快，但做的是一个不该存在的东西。

如果把这件事落到自己的产品判断里，我现在会先问三个问题。

第一，这件事是不是直接在对话里就能完成？

如果用户只需要一次输入、一次转换、一次输出，那它很可能会被模型吞掉。除非你有独特数据、稳定渠道、强场景绑定或更深工作流。

第二，这件事的核心价值在哪里？

是在模型本身的生成能力里，还是在场景理解、历史记忆、协作流程、交付责任、数据闭环里？

如果核心价值只在生成能力里，风险很高。

第三，它有没有现实反馈闭环？

用户用了以后，会不会留下数据？会不会产生新的判断？会不会影响下一次交付？会不会让系统越来越懂这个人或这个场景？

没有反馈闭环的 AI 产品，很容易变成一次性工具。

有反馈闭环的产品，才有机会沉淀成系统。

这也是我看完 Karpathy 这三条线索后，最想记下来的东西。

不要只用 AI 加速自己。

还要用 AI 逼自己判断：

哪些东西已经不该做了。

哪些东西以前做不了，现在第一次值得做。

哪些东西看起来像产品，其实只是模型能力的一层影子。