企业官网建设流程全解析

从助推 Anthropic 冲上 9650 亿美元估值的 Claude Code，到应用直出的「20 分钟死亡线」，聊聊 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”“一句话生成代码”“一句话生成游戏”……一个看似简单但结构性极强的趋势正在形成：用户越来越不需要“操作软件”，只需要“表达目标”。

我主要想聊这么几件事：这场狂欢是怎么开始的；为什么很多“一句话直出”的产品很快就被用户放弃了；为什么同样是“一句话”，代码工具却成了真生意；接下来可能的出路在哪里。

一、被热炒的“氛围编程”

先说这场狂欢本身。

这两年，Cursor、Manus、Lovable 这类工具在发布时，几乎都带来过类似的“震撼时刻”。在社交媒体的演示视频里，用户只输入一行指令，屏幕上闪过密密麻麻的代码流和组件，几秒钟后，一个看起来相当完整的网页就渲染了出来。这种视觉冲击力很强，转发和播放量也极高。

这种状态后来有了一个被广泛引用的名字。2025 年 2 月，前特斯拉 AI 总监 Andrej Karpathy 在 X 上随手发了一条推文，提出了“Vibe Coding（氛围编程）”这个词。他自己后来说这只是一条“洗澡时冒出来的想法、随手一发”的推文，但它意外地传开了。¹他大致的意思是：你“完全沉浸在感觉里，忘记代码本身的存在”——看一眼、说一句、跑一下、复制粘贴，然后它大概就能跑。¹

值得注意的是，Karpathy 本人给这个词划过边界。在他和后来一些开发者（比如 Simon Willison）的讨论里，氛围编程被定位成适合做原型、做“周末扔掉就算了的小项目”的方式，而不是用来交付严肃生产系统的方法。²但在传播过程中，这层限定常常被略过了。

于是大众更容易接收到的版本是：技术门槛归零，人人都能靠“氛围和感觉”成为全栈开发者。我自己当时也有点被这种叙事感染。直到真的把这些工具放进相对真实的使用场景里，我才慢慢意识到，演示视频里的“几秒钟”，和用户真正想做成一件事之间，隔着一条不小的沟。

二、我观察到的“20 分钟死亡线”

所谓的“20 分钟死亡线”，是我个人的一个粗略概括，不是某份报告里的精确结论。它来自我自己体验、看产品数据和用户行为时反复出现的体感——大多数“一句话直出”的应用，用户很容易在很短的时间里就放弃。

这个体感，在公开数据里能找到一些侧面印证。RevenueCat 在 2026 年发布的《State of Subscription Apps》里有一组对比：AI 类订阅应用虽然单客户收入更高，但用户流失也明显更快——AI 应用的月留存率约为 6.1%，而非 AI 应用是 9.5%；年留存率则是 21.1% 对 30.7%。报告里有一句话我印象很深，大意是：AI 的热度能带来初次付费，但还没能创造出留住用户所需要的、持续的价值。³⁴

数据是宏观的，但具体到一次次使用里，我把这个“放弃”的过程，大致拆成了三段。需要强调，下面的时间刻度是示意，不是测出来的精确值：

第一段：0-3 分钟的「多巴胺时刻」。用户输入一句模糊的意图，比如“做个赛博朋克风的抽卡游戏”。模型调动它预训练里见过的样式，拼出一个观感不错的前端界面和动画。这一刻多巴胺确实拉满了，但这个东西基本不具备“真实需求”和“真实业务逻辑”，更像一个“能看不能用”的玩具。

第二段：3-17 分钟的「微调泥潭」。用户试着提一些实质性的需求，比如“把抽卡概率根据用户前三次结果动态调整，并且数据要存下来”。这时候，模糊的自然语言和底层确定性的逻辑开始打架。上下文一长，模型容易出现幻觉，陷入“修一个旧 bug、又造出一个新 bug”的循环，代码很快堆成谁也理不清的一团。

第三段：17-20 分钟的「终局放弃」。当界面白屏、或者逻辑彻底乱掉时，问题来了：这类产品为了照顾“小白用户”，往往把所有技术细节都藏了起来——看不到日志、进不了控制台、没有分支也没法单步调试。一个有经验的开发者遇到 bug，至少有抓手；但目标用户恰恰没有这些抓手。于是唯一的选择就是清空重来。重来几次，热情耗尽，人就走了。

我倾向于认为，问题的核心不在“生成得不够好看”，而在出问题之后，用户手里什么都没有。这一点，会在下一节和代码工具的对比里看得更清楚。

三、为什么 Claude Code 是真生产力，应用直出却容易变成玩具？

同样是“一句话”，为什么以 Claude Code、Cursor 为代表的代码辅助工具能跑出商业化，而很多“全包式”的应用直出平台却留不住人？

Anthropic 这一年的商业增长几乎是爆炸式的：年化营收从 2025 年底的约 90 亿美元，到 2026 年 5 月已经突破470 亿美元，而Claude Code 与企业级应用正是其中的主要增长引擎。⁵受此带动，公司在完成 650 亿美元 H 轮融资后，估值飙到了9650 亿美元，逼近万亿。⁶更说明问题的是它落地的场景：2026 年 6 月，Anthropic 与全球 IT 服务巨头塔塔咨询（TCS）宣布全球级合作，TCS 会让 5 万名员工用上 Claude，并明确提到在银行、金融（BFSI）这类强监管行业里用 Claude Code 提升软件工程效率。⁷⁸也就是说，这类工具已经真的走进了对确定性要求极高的生产一线。

对比这两类产品，我能想到的关键差别有三个。

差别一：有没有一个“确定的对错标准”。

代码这个领域，天然带着一套确定的裁判：编译器、类型检查、单元测试——代码能不能跑、对不对，可以得到一个近乎二元（0 或 1）的客观信号。正因为有这个“可验证的奖励”，模型才能在后台自己反复试错、自我纠偏，强化学习也才真正训得动。业界把这类做法叫 RLVR（Reinforcement Learning from Verifiable Rewards），近来甚至已经有把编译器和语言服务器的实时反馈直接喂给 Agent 当奖励信号的研究。⁹

反观应用直出要解决的“业务逻辑对不对”，很难有一个自动裁判。“抽卡概率有没有按我说的动态调整”这种需求，既不会触发编译器报错，也没有现成的测试用例去判定对错——模型无法自检，用户也无从验证。没有裁判，就没有可靠的纠偏，错误只能一层层积累下去。我觉得这才是两类产品最底层的分水岭：一边是在有标准答案的考场里答题，一边是在没有标准答案的旷野里瞎走。

差别二：用户有没有审查的能力和“抓手”。

代码工具的用户，本身就是程序员。他们脑子里有清晰的架构和控制流，所谓“一句话”，对他们而言其实是一条相当精确的指令；AI 吐出代码后，他们能看出哪里有问题、手动改掉。也就是说，人本身就是那道质检关。

更关键的是，代码工具把这套“抓手”做成了实打实的功能。以 Claude Code、Cursor 为例：每次改动都以 diff 的形式摆出来让你逐行审，提供 checkpoint 和 git 回滚，shell 命令执行前要逐条确认，终端和日志也全程可见。¹⁰哪一步不对，你随时能退回上一个状态。而应用直出平台为了所谓“小白体验”，恰恰把这些全藏了起来。所以第二节说的“没有抓手”，本质就是这道质检关、连同支撑它的工具，被一起拿掉了。

差别三：场景的边界，和交付物离用户真实目标有多远。

先说边界。代码工具的交付终点其实非常克制——它只负责给出符合工程标准的代码片段（patch）。至于高并发、CI/CD 部署、数据库迁移这些“环境墙”，交给企业已经成熟的工程基础设施（Git、Docker、K8s 等）去兜底，它没有越过自己能力的边界。而应用直出产品则试图把前端、后端、数据库、服务器托管全包下来，一脚踩进真实线上产品几乎 100% 的确定性要求里：schema 迁移、状态一致性、高并发、权限和安全。模型靠概率拼出来的代码，在这些地方往往很脆。

这种脆弱还会随着“走得越深”被放大。研究机构 METR 给模型能独立完成的任务做过一个“时间跨度”的量化：当前最前沿的模型，在 50% 成功率下大约只能稳定搞定人类需要约 110 分钟的任务，再长、再多步，可靠性就明显往下掉。¹¹这从侧面解释了第二节那条“死亡曲线”——用户一旦从“生成个好看界面”推进到需要多步、长链路的真实业务逻辑，正好踩进了模型可靠性快速衰减的区间。New Relic 在 2026 年 6 月《State of AI Coding》里的一组数据也印证了这点：94% 的技术负责人认为 AI 生成的代码在评审时质量不输人写的，但 82% 的受访企业在过去半年里，至少经历过一次由 AI 代码直接引发的线上故障——报告把这种“评审没问题、上线埋雷”的现象，称为“Agent Debt（智能体债务）”。¹²¹³也就是，问题不在“代码生成质量”这一个维度，而在生成之后那条看不见的链路里，这正在有场景有盈利的应用强依赖的链路。

除了边界，还有一层更隐蔽的错位——交付物离用户真实目标有多远。对程序员来说，代码本身就是他要的东西，交付物即目标，中间没有需要再翻译的鸿沟；而且全世界要写代码的人本身就是个巨大、稳定、付费意愿又强的群体。应用直出的用户却不一样：一个想做产品的创业者，要的从来不是“一个 app”，而是一门能跑起来、最好能盈利的生意。生成出来的应用顶多算个起点，离他真正的目标（能运营、能留住用户、能赚钱）还隔着十万八千里。交付物和真实目标之间，本来就横着一条工具填不平的沟，所以哪怕生成质量再高，对这类用户也常常是“给了，但不是我真正想要的”。

这三个差别其实也浮现出一个 AI 产品能不能跑出来的几个前提条件。我大致归成三层：

• 技术层（任务本身）：这件事有没有客观的对错标准，有没有足够的数据基建和 context 让模型自检自纠。能像代码那样有编译器、测试当裁判的，模型才训得动、迭代得动；越是没有标准答案、越靠主观判断的任务，越难。
• 用户层：用户有没有审查和纠偏的能力，产品有没有给他对应的“抓手”。用户自己能当一道质检关，容错空间就大；用户是纯小白、又被藏掉了所有手柄，就只能听天由命。
• 场景层：场景的边界够不够窄（别一脚踩进 100% 确定性的深水区）、工具的交付物是不是就是用户的真实目标、这个目标的人群够不够大够刚。边界清楚、交付物即目标、群体又大，就容易长成生意；既要全包又踩进确定性深水区、交付物还离真实目标（比如“盈利”）十万八千里，就容易停在玩具阶段。

代码工具几乎是这三层同时占满的“天选场景”，所以它先跑了出来。而大多数 AI 产品的难处在于：它们往往只占了其中一层，甚至哪一层都不算稳。这也正好引出下一节我想聊的——如果一个场景天生不具备这些条件，能不能靠产品和工程的手段，把缺的那几层硬“补”回去。

四、可能的出路：把“确定性”重新注回去

如果上面的判断大致成立，那接下来的竞争，可能就不在那个“黑色输入框”本身了，而在它背后那条用户看不到的“执行与质检链路”里。结合我看到的一些做法，我把可能跑通的路径，粗略归纳成三条。这三条不是互斥的，更像是不同的发力点。

把它们对回上一节那个“三层条件”的框架，思路会更清楚：路径一是在补技术层的“自检”和用户层的“抓手”，路径二是在补场景层的“边界”，路径三则回到技术层，把能力直接长进模型里。说到底，都是在替那些不像代码工具那么“天选”的场景，把缺的那几层硬补回来。

路径一：在工程层加硬围栏（后台沙盒 + 给人留手柄）

第一条路，是不再幻想模型“直达用户”，而是在后台先建一道关。

在更贴近真实工程任务的评测 SWE-bench Pro 上，主流模型的单次解决率其实并不高（公开集 ≤23.3%、商用集 ≤17.8%），远低于一些早期榜单上 70%+ 的数字。¹⁴但研究也显示，给 Agent 接上能自己跑测试、自己迭代修复的能力之后，解决率能有明显提升——比如 Live-SWE-agent 这类工作，靠在线合成工具和自我迭代，把强模型的解决率最多提升了约 22.6 个百分点。¹⁵这给了一个方向：真正起作用的不是“一次生成得更准”，而是“生成之后能自检、能自愈”。

落到产品上，我理解大致是两件事：

• 对内造一道沙盒。AI 生成的代码先在后台隐形运行，自己吃掉编译报错，跑通测试用例后，才渲染给用户。在账务、安全这种关键节点，甚至该用写死的硬规则去拦截模型可能的幻觉。
• 对外给用户留手柄。把单一输入框，还原成可视化、可追溯的工作流节点，允许人通过点选、连线做渐进式的微调——也就是把第二节里缺失的那个“抓手”重新还给用户。

路径二：用“垂类积木”把场景边界焊死

第二条路，是干脆不追求“什么都能生成”，而是把场景边界限制得很死，在一个很窄的范围里做到商用级质量。

这条路最典型的例子是 Vercel 的v0.dev。它从不承诺帮你生成一整套带复杂后端的系统，而是把“一句话”的边界牢牢锁在前端 UI 组件生成上，技术栈也固定在 Next.js + Tailwind + shadcn/ui 这一套里。正因为围栏够窄，它的产出质量反而稳定到可以直接用。¹⁶

这背后的逻辑，和投资机构对垂直 AI 的判断是一致的。Sequoia 这两年反复在讲一个观点：能活下来、能进入企业生产环境的，往往不是“更好的聊天机器人”，而是那些靠领域专业知识、专有数据和深度嵌入工作流来构建壁垒的垂直系统。¹⁷¹⁸换个说法，约束本身——把领域结构焊死——可能正是挡住模型幻觉进入生产环境的有效手段之一。

放到更广的场景里也类似：在游戏或互动叙事里，底层引擎、状态机、行为树可以完全硬编码锁死，AI 只在安全的“槽位”里填立绘、剧情分支或 NPC 文本。戴着镣铐跳舞，反而更容易跳稳。

路径三：把流程内化成模型自己的能力

第三条路更靠近模型层，也最难，我理解得也最浅，先记下来。

随着 OpenAI 在 o1 上跑通的Test-Time Compute（让模型在回答时多想一会儿）路线被验证，行业的一个变化是：与其在外部写几千行提示词、搭复杂 Workflow 去“教”模型做业务，不如把这套流程，通过强化学习直接训进模型自己的思考方式里。¹⁹

Cursor 是个具体例子。它没有只套用通用模型，而是把大量程序员在编辑器里真实的删除、修改、接受、拒绝等行为轨迹，变成训练信号，去训练自己的 Tab 模型和 Composer 模型——每天甚至会重训多次。²⁰²¹这样一来，模型在“吐代码”之前，内核里就更接近一个有工程直觉的人在思考，而不是临时被提示词约束的通用模型。

这条路的门槛在于数据和算力，目前更像是头部团队才玩得起的游戏。但方向上，我认为它指向了一个更根本的答案：确定性最终可能不是靠外部围栏堆出来的，而是长进模型自己的能力里。

结语：自然语言没有杀死软件工程，它寄生其中

写到这里，我自己的结论挺朴素的。

“一句话生成”是一次很惊艳的交互体验，但热度退下去之后，我越来越倾向于这样理解它：自然语言并没有取代软件工程，它更像是寄生、并且繁荣于最成熟的那套软件工程基础设施之中。那些跑得通的产品，无一例外都是在“不确定的模型概率”之上，老老实实补回了“确定性”这一课——要么靠后台沙盒，要么靠场景约束，要么靠把流程训进模型。

作为一个还在路上的 AI 从业者，我没法说自己看清了全貌。这篇里的很多判断，可能过半年就被证明是错的。但有一点感受越来越强：产品的价值，大概率不在于给用户一个空洞的输入框去迎合他模糊的意图，而在于在那句“一句话”背后，为他真实的目标，默默织一条尽可能稳的流水线。

至于那条线具体怎么织——我也还在学。如果你有不同的看法，或者觉得我哪里想岔了，很欢迎一起聊聊。

参考资料