AI产品正经历从Chatbot到Agent的形态跃迁，而Claude Code的崛起与"20分钟死亡线"现象揭示了技术驱动下的产品本质。本文将深入分析代码工具为何能成为万亿级生意，而多数应用直出平台却沦为玩具，并探讨在技术主导的时代，产品经理如何重新定义自身价值。
从助推 Anthropic 冲上 9650 亿美元估值的 Claude Code，到应用直出的「20 分钟死亡线」，聊聊 AI 产品的现象与未来
作为生成式 AI 浪潮的亲历者，同时也是这一轮“AI 产品变革”里的产品新人——过去两年，我既在千万级用户的大型 AI 产品里待过，也参与过从 0 到 1 的早期 AI 项目。回看这些经历，我对 AI 产品攒下了一些直观、但还不算完整的感受，也顺着这些感受，试着理出了几个问题。
这篇文章不是什么行业宣言，更像是一份个人复盘。我想把我看到的现象以及一些还不成熟的判断，尽量诚实地写下来，也欢迎大家一起交流。
先从产品形态说起。回看这两年的 AI 产品，形态一直在变，大致可以分成三代：最早是 Chatbot（ChatGPT），你问一句它答一句；后来是 AI Workflow（Dify、Coze），把一串提示词、工具调用、检索和分支编排成一条固定的流水线；再到现在的 Agent（Manus、Cursor、Claude Code、Lovable、Go2Run.ai），它能自己拆解任务、调用工具、多步执行，甚至直接操作电脑。
这背后是模型能力的几次台阶式进展。最早的模型基本只能做单轮的文本问答；后来逐渐学会了稳定地调用外部工具、接入检索（RAG）来补足知识；再到这一两年，以 OpenAI o1 为代表的「推理模型」把思维链（CoT）和回答时多想一会儿的 Test-Time Compute 跑通，加上 Computer Use 这类直接操作界面的能力，模型才第一次具备了「自己规划、自己执行」的底子。可以说，产品形态从 Chatbot 走到 Agent，并不是产品经理拍脑袋的设计——它和底层模型能力更像是相互促进：模型每上一个能力台阶，就解锁一种新的产品形态；而产品侧跑出来的真实场景和数据，又反过来牵引着模型往哪个方向进化。
也正是在这个过程里，几乎所有 AI 产品都渐渐收敛到同一个故事上：“一句话生成 **”。包括“一句话生成应用”“一句话生成营销方案”“一句话生成 PPT”“一句话生成代码”“一句话生成游戏”……一个看似简单但结构性极强的趋势正在形成：用户越来越不需要“操作软件”，只需要“表达目标”。
值得一提的是，技术的这股强势牵引，也在悄悄重塑我们这些做产品的人。这两年 AI 产品经理的招聘要求，肉眼可见地往技术深处靠：据领英《2024 Future of Work》的数据，欧洲已有约 72% 的产品岗位明确要求 AI、机器学习或数据分析相关技能；[^22] 而有 ML 或数据科学背景的 PM，薪资普遍比没有技术深度的同行高出 15%–25%。[^23] 连“产品经理该懂什么”这件事，都在被底层技术重新定义。
这就引出一个我自己也常常困惑的问题：如果产品形态、甚至产品经理的能力模型，都越来越像是被技术趋势牵着走，那“产品”这个角色还剩下什么价值？ 这个问题我想留到最后再聊——得先把这两年到底发生了什么看清楚，答案才不至于是空的。
我主要想聊这么几件事：这场狂欢是怎么开始的；为什么很多“一句话直出”的产品很快就被用户放弃了；为什么同样是“一句话”，代码工具却成了真生意；接下来可能的出路在哪里；以及最后，回到上面那个问题——在这一切里，产品经理还能做点什么。
先说这场狂欢本身。
这两年，Cursor、Manus、Lovable 这类工具在发布时，几乎都带来过类似的“震撼时刻”。在社交媒体的演示视频里，用户只输入一行指令，屏幕上闪过密密麻麻的代码流和组件，几秒钟后，一个看起来相当完整的网页就渲染了出来。这种视觉冲击力很强，转发和播放量也极高。
这种状态后来有了一个被广泛引用的名字。2025 年 2 月，前特斯拉 AI 总监 Andrej Karpathy 在 X 上随手发了一条推文，提出了 “Vibe Coding（氛围编程）” 这个词。他自己后来说这只是一条“洗澡时冒出来的想法、随手一发”的推文，但它意外地传开了。[^1] 他大致的意思是：你“完全沉浸在感觉里，忘记代码本身的存在”——看一眼、说一句、跑一下、复制粘贴，然后它大概就能跑。[^1]
值得注意的是，Karpathy 本人给这个词划过边界。在他和后来一些开发者（比如 Simon Willison）的讨论里，氛围编程被定位成适合做原型、做“周末扔掉就算了的小项目”的方式，而不是用来交付严肃生产系统的方法。[^2] 但在传播过程中，这层限定常常被略过了。
于是大众更容易接收到的版本是：技术门槛归零，人人都能靠“氛围和感觉”成为全栈开发者。我自己当时也有点被这种叙事感染。直到真的把这些工具放进相对真实的使用场景里，我才慢慢意识到，演示视频里的“几秒钟”，和用户真正想做成一件事之间，隔着一条不小的沟。
所谓的“20 分钟死亡线”，是我个人的一个粗略概括，不是某份报告里的精确结论。它来自我自己体验、看产品数据和用户行为时反复出现的体感——大多数“一句话直出”的应用，用户很容易在很短的时间里就放弃。
这个体感，在公开数据里能找到一些侧面印证。RevenueCat 在 2026 年发布的《State of Subscription Apps》里有一组对比：AI 类订阅应用虽然单客户收入更高，但用户流失也明显更快——AI 应用的月留存率约为 6.1%，而非 AI 应用是 9.5%；年留存率则是 21.1% 对 30.7%。报告里有一句话我印象很深，大意是：AI 的热度能带来初次付费，但还没能创造出留住用户所需要的、持续的价值。[^3][^4]
数据是宏观的，但具体到一次次使用里，我把这个“放弃”的过程，大致拆成了三段。需要强调，下面的时间刻度是示意，不是测出来的精确值：
第一段：0-3 分钟的「多巴胺时刻」。 用户输入一句模糊的意图，比如“做个赛博朋克风的抽卡游戏”。模型调动它预训练里见过的样式，拼出一个观感不错的前端界面和动画。这一刻多巴胺确实拉满了，但这个东西基本不具备“真实需求”和“真实业务逻辑”，更像一个“能看不能用”的玩具。
第二段：3-17 分钟的「微调泥潭」。 用户试着提一些实质性的需求，比如“把抽卡概率根据用户前三次结果动态调整，并且数据要存下来”。这时候，模糊的自然语言和底层确定性的逻辑开始打架。上下文一长，模型容易出现幻觉，陷入“修一个旧 bug、又造出一个新 bug”的循环，代码很快堆成谁也理不清的一团。
第三段：17-20 分钟的「终局放弃」。 当界面白屏、或者逻辑彻底乱掉时，问题来了：这类产品为了照顾“小白用户”，往往把所有技术细节都藏了起来——看不到日志、进不了控制台、没有分支也没法单步调试。一个有经验的开发者遇到 bug，至少有抓手；但目标用户恰恰没有这些抓手。于是唯一的选择就是清空重来。重来几次，热情耗尽，人就走了。
我倾向于认为，问题的核心不在“生成得不够好看”，而在出问题之后，用户手里什么都没有。这一点，会在下一节和代码工具的对比里看得更清楚。
这是我自己想了挺久的一个问题。同样是“一句话”，为什么以 Claude Code、Cursor 为代表的代码辅助工具能跑出商业化，而很多“全包式”的应用直出平台却留不住人？
先看一组能说明“这是真生意”的数据。Anthropic 这一年的商业增长几乎是爆炸式的：年化营收从 2025 年底的约 90 亿美元，到 2026 年 5 月已经突破 470 亿美元，而 Claude Code 与企业级应用正是其中的主要增长引擎。[^5] 受此带动，公司在完成 650 亿美元 H 轮融资后，估值飙到了 9650 亿美元，逼近万亿。[^6] 更说明问题的是它落地的场景：2026 年 6 月，Anthropic 与全球 IT 服务巨头塔塔咨询（TCS）宣布全球级合作，TCS 会让 5 万名员工用上 Claude，并明确提到在银行、金融（BFSI）这类强监管行业里用 Claude Code 提升软件工程效率。[^7][^8] 也就是说，这类工具已经真的走进了对确定性要求极高的生产一线。
对比这两类产品，我能想到的关键差别有三个，从浅到深。
差别一：有没有一个“确定的对错标准”。
这是我后来才慢慢想明白、可能也是最根本的一点。代码这个领域，天然带着一套确定的裁判：编译器、类型检查、单元测试——代码能不能跑、对不对，可以得到一个近乎二元（0 或 1）的客观信号。正因为有这个“可验证的奖励”，模型才能在后台自己反复试错、自我纠偏，强化学习也才真正训得动。业界把这类做法叫 RLVR（Reinforcement Learning from Verifiable Rewards），近来甚至已经有把编译器和语言服务器的实时反馈直接喂给 Agent 当奖励信号的研究。[^19]
反观应用直出要解决的“业务逻辑对不对”，对一个没有编程背景的用户来说，根本没有这样一个自动裁判。“抽卡概率有没有按我说的动态调整”这种需求，既不会触发编译器报错，也没有现成的测试用例去判定对错——模型无法自检，用户也无从验证。没有裁判，就没有可靠的纠偏，错误只能一层层积累下去。我觉得这才是两类产品最底层的分水岭：一边是在有标准答案的考场里答题，一边是在没有标准答案的旷野里瞎走。
差别二：用户有没有审查的能力和“抓手”。
代码工具的用户，本身就是程序员。他们脑子里有清晰的架构和控制流，所谓“一句话”，对他们而言其实是一条相当精确的指令；AI 吐出代码后，他们能很快看出哪里有问题、手动改掉。也就是说，人本身就是那道质检关。
更关键的是，代码工具把这套“抓手”做成了实打实的功能。以 Claude Code、Cursor 为例：每次改动都以 diff 的形式摆出来让你逐行审，提供 checkpoint 和 git 回滚，shell 命令执行前要逐条确认，终端和日志也全程可见。[^20] 哪一步不对，你随时能退回上一个状态。而应用直出平台为了所谓“小白体验”，恰恰把这些全藏了起来。所以第二节说的“没有抓手”，本质就是这道质检关、连同支撑它的工具，被一起拿掉了。
差别三：场景的边界，和交付物离用户真实目标有多远。
先说边界。代码工具的交付终点其实非常克制——它只负责给出符合工程标准的代码片段（patch）。至于高并发、CI/CD 部署、数据库迁移这些“环境墙”，交给企业已经成熟的工程基础设施（Git、Docker、K8s 等）去兜底，它没有越过自己能力的边界。而应用直出产品则试图把前端、后端、数据库、服务器托管全包下来，一脚踩进真实线上产品几乎 100% 的确定性要求里：schema 迁移、状态一致性、高并发、权限和安全。模型靠概率拼出来的代码，在这些地方往往很脆。
这种脆弱还会随着“走得越深”被放大。研究机构 METR 给模型能独立完成的任务做过一个“时间跨度”的量化：当前最前沿的模型，在 50% 成功率下大约只能稳定搞定人类需要约 110 分钟的任务，再长、再多步，可靠性就明显往下掉。[^21] 这从侧面解释了第二节那条“死亡曲线”——用户一旦从“生成个好看界面”推进到需要多步、长链路的真实业务逻辑，正好踩进了模型可靠性快速衰减的区间。New Relic 在 2026 年 6 月《State of AI Coding》里的一组数据也印证了这点：94% 的技术负责人认为 AI 生成的代码在评审时质量不输人写的，但 82% 的受访企业在过去半年里，至少经历过一次由 AI 代码直接引发的线上故障——报告把这种“评审没问题、上线埋雷”的现象，称为 “Agent Debt（智能体债务）”。[^9][^10] 一句话：问题不在“生成质量”这一个维度，而在生成之后那条看不见的链路里。
除了边界，还有一层更隐蔽的错位——交付物离用户真实目标有多远。对程序员来说，代码补丁本身就是他要的东西，交付物即目标，中间没有需要再翻译的鸿沟；而且全世界要写代码的人本身就是个巨大、稳定、付费意愿又强的群体。应用直出的用户却不一样：一个想做产品的创业者，要的从来不是“一个 app”，而是一门能跑起来、最好能盈利的生意。生成出来的应用顶多算个起点，离他真正的目标（能运营、能留住用户、能赚钱）还隔着十万八千里。交付物和真实目标之间，本来就横着一条工具填不平的沟，所以哪怕生成质量再高，对这类用户也常常是“给了，但不是我真正想要的”。
把这三个差别倒过来看，其实就浮现出一个 AI 产品能不能跑出来的几个前提条件。 我大致归成三层：
代码工具几乎是这三层同时占满的“天选场景”，所以它先跑了出来。而大多数 AI 产品的难处在于：它们往往只占了其中一层，甚至哪一层都不算稳。这也正好引出下一节我想聊的——如果一个场景天生不具备这些条件，能不能靠产品和工程的手段，把缺的那几层硬“补”回去。
如果上面的判断大致成立，那接下来的竞争，可能就不在那个“黑色输入框”本身了，而在它背后那条用户看不到的“执行与质检链路”里。结合我看到的一些做法，我把可能跑通的路径，粗略归纳成三条。这三条不是互斥的，更像是不同的发力点。
把它们对回上一节那个“三层条件”的框架，思路会更清楚：路径一是在补技术层的“自检”和用户层的“抓手”，路径二是在补场景层的“边界”，路径三则回到技术层，把能力直接长进模型里。 说到底，都是在替那些不像代码工具那么“天选”的场景，把缺的那几层硬补回来。
第一条路，是不再幻想模型“直达用户”，而是在后台先建一道关。
这件事有数据支撑。在更贴近真实工程任务的评测 SWE-bench Pro 上，主流模型的单次解决率其实并不高（公开集 ≤23.3%、商用集 ≤17.8%），远低于一些早期榜单上 70%+ 的数字。[^11] 但研究也显示，给 Agent 接上能自己跑测试、自己迭代修复的能力之后，解决率能有明显提升——比如 Live-SWE-agent 这类工作，靠在线合成工具和自我迭代，把强模型的解决率最多提升了约 22.6 个百分点。[^12] 这给了一个方向：真正起作用的不是“一次生成得更准”，而是“生成之后能自检、能自愈”。
落到产品上，我理解大致是两件事：
第二条路，是干脆不追求“什么都能生成”，而是把场景边界限制得很死，在一个很窄的范围里做到商用级质量。
这条路最典型的例子是 Vercel 的 v0.dev。它从不承诺帮你生成一整套带复杂后端的系统，而是把“一句话”的边界牢牢锁在前端 UI 组件生成上，技术栈也固定在 Next.js + Tailwind + shadcn/ui 这一套里。正因为围栏够窄，它的产出质量反而稳定到可以直接用。[^13]
这背后的逻辑，和投资机构对垂直 AI 的判断是一致的。Sequoia 这两年反复在讲一个观点：能活下来、能进入企业生产环境的，往往不是“更好的聊天机器人”，而是那些靠领域专业知识、专有数据和深度嵌入工作流来构建壁垒的垂直系统。[^14][^15] 换个说法，约束本身——把领域结构焊死——可能正是挡住模型幻觉进入生产环境的有效手段之一。
放到更广的场景里也类似：在游戏或互动叙事里，底层引擎、状态机、行为树可以完全硬编码锁死，AI 只在安全的“槽位”里填立绘、剧情分支或 NPC 文本。戴着镣铐跳舞，反而更容易跳稳。
第三条路更靠近模型层，也最难，我理解得也最浅，先记下来。
随着 OpenAI 在 o1 上跑通的 Test-Time Compute（让模型在回答时多想一会儿） 路线被验证，行业的一个变化是：与其在外部写几千行提示词、搭复杂 Workflow 去“教”模型做业务，不如把这套流程，通过强化学习直接训进模型自己的思考方式里。[^16]
Cursor 是个具体例子。它没有只套用通用模型，而是把大量程序员在编辑器里真实的删除、修改、接受、拒绝等行为轨迹，变成训练信号，去训练自己的 Tab 模型和 Composer 模型——每天甚至会重训多次。[^17][^18] 这样一来，模型在“吐代码”之前，内核里就更接近一个有工程直觉的人在思考，而不是临时被提示词约束的通用模型。
这条路的门槛在于数据和算力，目前更像是头部团队才玩得起的游戏。但方向上，我认为它指向了一个更根本的答案：确定性最终可能不是靠外部围栏堆出来的，而是长进模型自己的能力里。
回到开头那个问题。如果“能做什么”越来越由模型能力说了算，那留给产品的空间，我觉得恰恰在模型决定不了的地方——也就是前面反复出现的那三层（技术、用户、场景）里，那些需要“做选择”和“做约束”的环节。结合前面聊的，我把产品经理还能使上劲的地方，大致归成四件事。
一是选场景、划边界。 这可能是最重要、也最容易被低估的一件事。第三节那个“三层条件”——任务有没有客观对错标准、用户有没有审查能力、交付物是不是用户的真实目标——本质上是一张判断清单。一个场景这三层占了几层、缺的是哪层，决定了它到底是“天选生意”还是“20 分钟玩具”，也决定了该不该做、做到哪一步该收手。模型不会替你做这个判断，这是产品的活。
二是决定“确定性”注入在哪。 第四节那三条路径，落到具体产品里都是一连串选择题：哪个环节用后台沙盒自检、哪个节点必须用硬编码兜底、哪里该把手柄交还给用户、哪些能力值得花代价沉淀进模型。这些都不是模型能力问题，而是产品权衡——在“体验顺滑”和“结果可靠”之间，替用户把那条线划在合适的位置。
三是管理预期，给叙事祛魅。 过去两年，产品在“一句话生成”这件事上其实欠了用户不少——把一个概率性的、会出错的过程，包装成“说句话就行”的魔法，落差最后全让用户自己扛。我慢慢觉得，诚实地告诉用户“这里 AI 会犯错、你可以这样接管”，比再丢给他一个黑色输入框更有价值。把交互从“许诺奇迹”还原成“可控的渐进协作”，是产品能主动做的事。
四是把领域知识和数据变成资产。 路径二、三都高度依赖 domain knowledge 和真实场景数据——什么该锁死、什么能交给模型、哪些行为轨迹值得收集。这些东西不会自己长出来，需要产品贴着业务，把它们一点点梳理、沉淀下来。到最后，它们才是模型能力之外、真正属于这个产品的壁垒。
这四件事说大不大，但没有一件是模型能替我们做的——它们全都落在“技术能做什么”的边界之外，关乎“要不要做、为谁做、做到哪一步才算数”。我慢慢觉得，被技术牵着走本身没什么不好，真正要紧的是：在被推着往前跑的同时，还能不能稳稳地替用户做出这一连串选择。
写到这里，我自己的结论挺朴素的。
“一句话生成”是一次很惊艳的交互体验，但热度退下去之后，我越来越倾向于这样理解它：自然语言并没有取代软件工程，它更像是寄生、并且繁荣于最成熟的那套软件工程基础设施之中。 那些跑得通的产品，无一例外都是在“不确定的模型概率”之上，老老实实补回了“确定性”这一课——要么靠后台沙盒，要么靠场景约束，要么靠把流程训进模型。
作为一个还在路上的产品新人，我没法说自己看清了全貌。这篇里的很多判断，可能过半年就被证明是错的。但有一点感受越来越强：产品的价值，大概率不在于给用户一个空洞的输入框去迎合他模糊的意图，而在于在那句“一句话”背后，为他真实的目标，默默织一条尽可能稳的流水线。
至于那条线具体怎么织——我也还在学。如果你有不同的看法，或者觉得我哪里想岔了，很欢迎一起聊聊。
[^1]: Andrej Karpathy 提出 “vibe coding” 的原始推文（2025-02-02）：x.com/karpathy/status/1886192184808149383；及其一周年回顾推文：x.com/karpathy/status/2019137879310836075
[^2]: Simon Willison，《Not all AI-assisted programming is vibe coding》：simonwillison.net/2025/Mar/19/vibe-coding/；Wikipedia 词条 “Vibe coding”：en.wikipedia.org/wiki/Vibe_coding
[^3]: RevenueCat，《State of Subscription Apps 2026》官方报告页：revenuecat.com/state-of-subscription-apps
[^4]: TechCrunch，《AI-powered apps struggle with long-term retention, new report shows》（2026-03-10）：techcrunch.com/2026/03/10/ai-powered-apps-struggle-with-long-term-retention-new-report-shows/
[^5]: Anthropic 年化营收从 2025 年底约 90 亿美元增至 2026 年 5 月约 470 亿美元，Claude Code 与企业级应用为主要增长引擎（Sacra 追踪页）：sacra.com/c/anthropic
[^6]: Anthropic 完成 650 亿美元 H 轮融资、估值达 9650 亿美元（Anthropic 官方公告）：anthropic.com/news/series-h；另见 ABC News 报道：abcnews.com/Technology/wireStory/anthropic-vaults-965-billion-valuation
[^7]: TCS 官方新闻稿，《TCS and Anthropic launch Global Premier Partnership to drive Enterprise AI scaling》：tcs.com/who-we-are/newsroom/press-release/tcs-anthropic-launch-global-premier-partnership-drive-enterprise-ai-scaling
[^8]: TechCrunch，《Anthropic taps TCS to scale its enterprise AI deployments》（2026-06-11）：techcrunch.com/2026/06/11/anthropic-taps-tcs-to-scale-its-enterprise-ai-deployments/
[^9]: New Relic / Business Wire，《New Relic Report Reveals AI-Generated Code Grades Higher in Review, Yet Triggers Rise in Production Incidents》（2026-06-10）：businesswire.com/news/home/20260610259591/en/
[^10]: 同上报道（AIwire 转载，含 “agent debt” 概念阐述）：hpcwire.com/aiwire/2026/06/10/
[^11]: Scale AI，《SWE-Bench Pro: Can AI Agents Solve Long-Horizon Software Engineering Tasks?》（论文 PDF）：static.scale.com/uploads/…/SWEAP_Eval_Scale.pdf；公开榜单：labs.scale.com/leaderboard/swe_bench_pro_public
[^12]: 《Live-SWE-agent: Can Software Engineering Agents Self-Evolve on the Fly?》（arXiv）：arxiv.org/pdf/2511.13646
[^13]: Vercel v0 介绍与约束化技术栈说明（Vercel Academy）：vercel.com/academy/ai-sdk/ui-with-v0
[^14]: Sequoia Capital，《Services: The New Software》：sequoiacap.com/article/services-the-new-software/
[^15]: Sequoia Capital，《AI in 2025: Building Blocks Firmly in Place》：sequoiacap.com/article/ai-in-2025/
[^16]: OpenAI，《Learning to reason with LLMs》（o1 与 test-time compute）：openai.com/index/learning-to-reason-with-llms/
[^17]: Cursor，《Improving Cursor Tab with online RL》：cursor.com/blog/tab-rl
[^18]: Cursor，《Composer: Building a fast frontier model with RL》：cursor.com/blog/composer
[^19]: 可验证奖励（RLVR）概念说明（Label Studio）：labelstud.io/blog/reinforcement-learning-from-verifiable-rewards/；《Reinforcement Learning from Compiler and Language Server Feedback》（arXiv）：arxiv.org/abs/2510.22907
[^20]: Claude Code 的 diff 审查、checkpoint/git 回滚、命令逐条确认与权限沙盒等机制说明：penligent.ai/hackinglabs/inside-claude-code-the-architecture-behind-tools-memory-hooks-and-mcp/
[^21]: METR，《Measuring AI Ability to Complete Long Tasks》（前沿模型 50% 成功率下时间跨度约 110 分钟）：metr.org/blog/2025-03-19-measuring-ai-ability-to-complete-long-tasks/
[^22]: 领英《2024 Future of Work》报告：约 72% 的欧洲产品岗位明确要求 AI/机器学习/数据分析技能（经 SkillSeek 整理）：skillseek.eu/answers/ai-impact-on-product-management-roles
[^23]: 具备 ML/数据科学背景的产品经理薪资溢价约 15%–25%（Axial Search，基于 592 个 AI 产品岗位的分析）：axialsearch.com/insights/ai-product-management-jobs/
本文由 @逃去海边 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。