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