移动互联网把产品带进了 App，AI 可能会把它们重新带回 Web

移动互联网把产品带进了 App，AI 可能会把它们重新带回 Web

过去很多年，互联网行业几乎默认了一件事： 真正的产品，应该做成 App。

网站当然也有价值，但更多时候，它只是品牌介绍页、搜索入口、活动落地页，或者一个“下载 App”的中转站。 真正的交易、留存、通知、复购、会员体系，最后都应该沉淀在 App 里。 这套逻辑在移动互联网时代太强了，强到很多人已经不再怀疑它。

但到了今天，这件事开始松动了。

原因不是大家突然怀旧，也不是 Web 技术突然“文艺复兴”。 真正的变化在于：AI 的确大幅降低了做产品的技术门槛，但它并没有顺手把 App 生态那套上线、审核、双端维护、分发获客的流程成本一起打掉。 Apple 目前仍然维持完整的 App Review 规则与分发约束；而 Web 依然保留了它最朴素但最致命的优势——发布快、修改快、分享快、被搜索快。developer.apple.com

所以今天越来越多开发者面对的现实，已经不是“我能不能把这个产品做出来”，而是：

既然我都能把它做出来了，为什么还要主动把自己送进一条更重、更慢、更封闭的链路里？

这才是现在 Web 重新变得有意思的地方。

AI 降低了开发门槛，却顺手抬高了 Web 的性价比

过去，小团队做产品时最常见的取舍是： 先把功能做出来，体验以后再说。

因为真正把一个 Web 产品做得顺手、流畅、稳定、好看，本来就是一件很费资源的事。 前端细节、响应式布局、性能优化、设计一致性、内容结构、SEO 语义，这些东西嘴上都说重要，实际一到资源不够的时候，最先被压缩的往往还是它们。

但 AI 改变了这里的成本结构。

2025 年，a16z 在讨论 AI-powered web app builders 时就提到，像 Lovable、Bolt、v0 这类工具，已经让大量技术用户和非技术用户开始直接创建网站与 Web 应用，甚至已经有人在没有传统开发流程的前提下做出可收费的产品。文章还提到，Bolt 一度扩张到 2000 万美元的 revenue run rate，Lovable 在开始商业化几个月后就达到 1700 万美元 ARR。到 2025 年 7 月，Lovable 上线仅 8 个月就跨过 1 亿美元 ARR；到 2026 年 2 月，它又达到 4 亿美元 ARR。a16z.com techcrunch.com techcrunch.com techcrunch.com

这件事真正重要的地方，不在于“AI 会写代码”这句已经快被说烂的话。 而在于，AI 正在把“做一个像样的 Web 应用”这件事，从大团队专属能力，变成小团队也能碰到的现实选项。

以前，很多产品不是不想把 Web 做好，而是没那个资源。 今天，这个借口正在慢慢失效。

还有一个常被忽略的事实：连最火的 AI 产品自己，也在用 Web 当主战场

如果 App 真的还是成功产品的必需品，那今天最火的 AI 平台，本该一开始就把重心押在原生 App 上。 但现实刚好相反。

从 ChatGPT 到 Perplexity，再到 Claude，它们最核心的使用入口都明确存在于浏览器里。OpenAI 的 ChatGPT 官网本身就是一个可直接使用的对话界面；Anthropic 也在官方文档里明确把 Claude 定义为可通过 web browser 使用的消费者产品；Perplexity 官网则直接把自己描述为一个可以“Ask anything”的 AI answer engine。更关键的是，这些产品并没有因为主要存在于 Web，就失去用户规模。OpenAI 在 2025 年 2 月告诉 Reuters，ChatGPT 的周活跃用户已经超过 4 亿。chatgpt.com anthropic.com perplexity.ai reuters.com

这其实说明了一件很直接的事： 今天的用户，并不会因为一个优秀产品首先以 Web 形态存在，就自动放弃它。

反过来说，这也在倒逼开发者。 既然 Web 已经不再天然等于“阉割版体验”，既然用户也不会因为你没有 App 就立刻掉头走人，那产品竞争就会重新回到一个更残酷但更健康的地方：谁能借助 AI，把 Web 应用做得更顺、更稳、更像真正的产品。

App 的问题，从来就不只是技术问题

很多人一谈 App vs Web，容易先掉进“性能”和“能力边界”的老话题里。 但对于个体开发者、小团队、独立品牌来说，App 最大的问题其实并不首先是技术，而是商业和流程上的沉重。

因为 App 从来不只是“做一个客户端”这么简单。 它背后对应的是一整套平台型秩序：

• 需要适配不同系统与设备
• 需要处理版本发布与更新节奏
• 需要面对审核规则与不确定性
• 需要额外承担下载安装这一步带来的转化损耗
• 需要在本来就拥挤的应用商店里重新争夺发现机会

Apple 官方今天依然明确说明，App Store 分发建立在完整的审核机制之上，应用与更新都必须符合既有规则；而 web.dev 对 PWA 的定义则正好指出了另一面：Web 应用可以单代码库覆盖多设备，部署机制更透明直接，不需要打包，不需要额外内容审核，也没有更新延迟，用户访问时拿到的就是最新版本。developer.apple.com web.dev

说白了，AI 让“开发”变便宜了。 但它没有让 App 的分发成本、运营成本、维护成本一起变便宜。

于是 Web 的性价比，就突然被重新看见了。

Web 也不是以前那个“只能凑合用”的 Web 了

2026 年搜索结果页里，什么样的 Web 产品更容易被点击？

如果你的产品需要依赖搜索获取发现机会，那么今天要问的已经不是“要不要有网页”，而是：你的网页是不是足够像一个可被快速判断的产品。

用户在 AI summary、搜索摘要和推荐结果里停留的时间更短，这意味着页面是否清楚、标题是否准确、结构是否好理解，比过去更重要。一个只是“能打开”的网站，和一个能被理解、能被点击、能承接下一步动作的 Web 产品，差别会越来越大。

如果今天的 Web 还停留在“一个能打开的手机版网站”这个水平，那它当然很难挑战 App。 问题是，Web 早就不是那个 Web 了。

web.dev 对 Progressive Web Apps 的定义很直接：PWA 本质上是 Web App，但它可以安装、可以独立窗口运行、可以拥有图标、可以离线工作，还能获得更高层级的系统集成。更重要的是，它天然保留了 Web 的覆盖范围和单代码库优势。web.dev

这不是概念游戏。 很多年里，Web 世界一直在干一件很朴素但很重要的事： 把“像 App 一样工作”这件事，一点点搬进浏览器。

而且结果并不差。

例如 web.dev 收录的 Blibli 案例里，这家印尼电商在推进 PWA 和移动 Web 体验优化之后，拿到了相当直接的业务结果：跳出率下降 42%，已安装 PWA 的移动转化率比普通移动 Web 高 8 倍，每用户收入比之前的移动网站高 10 倍。另一个案例 Mainline Menswear 也很夸张：安装 PWA 的用户转化率提升 55%，每次会话收入提升 243%，页面浏览量提升 40%，跳出率下降 50%。web.dev web.dev

这说明了一件很现实的事：

Web 不再只是“能访问”，而是在很多场景里，已经足以承担“像产品一样运作”的任务。

尤其在交易、内容、工具、服务型产品这几个领域，这种变化非常明显。

在 AI 时代，Web 还有一个 App 很难替代的优势：更容易被 AI 看见

还有一个经常被低估的点： AI 天然更容易理解和接入 Web，而不是 App。

Chrome 官方现在已经把 Built-in AI 明确放进 Web 开发叙事里。Chrome 的文档直接写得很直白：你的网站或 Web 应用可以调用浏览器管理的 AI 模型和 API，在本地执行写作、改写、翻译、总结等任务；这意味着浏览器本身，正在从“打开网页的容器”往“提供 AI 能力的平台”继续演进。与此同时，Google 在 2025 年扩大 AI Overviews 和推出 AI Mode 时，也明确强调 AI 搜索会提供链接回到开放 Web，并表示在美国和印度等核心市场，AI Overviews 已经带来了相关查询 10% 以上的使用增长。developer.chrome.com blog.google

这件事放在产品层面，其实很要命。

因为在 AI 逐渐参与搜索、推荐、比价、内容摘要、任务执行的时代， 一个开放的、可抓取的、结构化的、语义清晰的 Web 产品，天然就更容易：

• 被搜索引擎理解
• 被外部链接传播
• 被 AI 代理访问
• 被大模型在回答里引用
• 被用户通过“问一句”的方式间接发现

而 App 呢？

App 当然也有能力，也有体验优势。 但它首先是一个封闭容器。 它更像一个需要先进入、再理解的世界；Web 则是一个先被看见、再被进入的世界。

这两个逻辑，在 AI 时代的分量，可能会重新洗牌。

所以，AI 不一定会消灭 App，但很可能会把更多产品逼回 Web

我并不觉得未来所有产品都会回到浏览器里，也不觉得 App 会失去意义。 那种判断太轻飘了，像行业里每隔几年就要来一轮的“XX 已死”。

但我确实觉得，越来越多中轻量级工具、交易型服务、内容型产品、品牌型产品，都会重新认真考虑 Web。

理由很简单：

• AI 让开发门槛下降了
• Web 的上线和迭代成本依然最低
• 浏览器本身在持续补足能力
• 用户越来越习惯通过搜索、链接、AI 对话发现服务
• 小团队没有太多资本去同时经营多端、审核、商店分发和复杂维护链路

以前大家做 Web，多少有点“先上线凑合一下”的意味。 现在，Web 正越来越像一种主动的产品选择。

而这，也是 Foundax 从一开始就没有把自己理解成“建站工具”的原因。

什么样的产品，更适合先做 Web 再考虑 App？

如果你的产品天然依赖搜索发现、内容解释、快速迭代、轻量注册、跨设备访问或低成本试错，Web 往往应该先于 App 被认真评估。典型场景包括：品牌官网、内容站、交易型独立站、工具型产品、轻量 SaaS，以及需要边发布边验证的小团队产品。

判断标准并不复杂：用户是不是必须强依赖原生系统能力、是不是高度依赖推送和深度设备接口、以及你当前最贵的成本到底是“功能开发”，还是“分发、解释和转化”。

如果你现在在做品牌官网、内容站或独立站，应该优先看哪几个判断标准？

对这类产品来说，更关键的往往不是 App 看起来够不够“完整”，而是：

• 能不能被搜索和 AI 结果稳定发现
• 能不能快速更新页面、内容和结构
• 能不能把介绍、FAQ、案例、价格和转化路径放在同一套体系里
• 能不能让小团队用更低成本持续运营

只要这四件事的重要性高于“必须先上应用商店”，Web 就不该只是一个附属渠道。

Foundax 从一开始想做的，就不是一个“把网页拼出来”的工具

为什么这对品牌官网、内容站和独立站商家尤其重要？

对品牌商家、小团队和独立开发者来说，Web 的优势不只是开发效率，而是它更容易同时承接三个入口：

• 搜索入口
• 内容入口
• 转化入口

如果这三件事还是分散在不同工具和不同系统里，团队就会持续为同步、发布和结构一致性付出额外成本。AI 降低了开发门槛之后，这种系统层的低效会变得更显眼。

如果我们只是想做一个普通的网站搭建器，那其实完全可以走两条老路里的任何一条：

一条是给用户极高自由度，让人像素级拖拽、自由堆叠，爱怎么搭怎么搭； 另一条是彻底模板化，选个模板、换图换字、三分钟上线。

这两条路都有人走，而且都不新鲜。

但我们从一开始更关心的是另一件事：

如果 Web 正在重新成为产品主场，那用户要的就不是一个“网页编辑器”，而是一个更接近 Web 应用搭建平台的东西。

所以在 Foundax 里，我们做了一个很明确的取舍：

• 品牌表达这部分，做成模块化
• 交易流程这部分，做成系统化

首页、品牌页、重点产品页、内容页，这些地方本来就承担表达任务。 它们需要层次、节奏、视觉风格、信息组织，也需要品牌差异。 所以我们让它们以组件化方式存在：你可以选变体、组合模块、替换内容、设置主题，在一个相对稳定但不死板的框架里，把网站搭出自己的样子。

但交易流程不是这样。

交易流程最怕的，就是每个人都想自己重新发明一次。 按钮位置改一点、信息层级乱一点、行动区晃一点，看上去只是审美选择，最后掉的却是转化。

所以 Foundax 的另一面，是把很多真正影响用户完成交易的关键结构做得更稳定。 你可以有样式选择，但不需要为“结账流程到底该怎么组织”这种事情反复掉坑。

这就是我们的中间路线。

不是极端自由。 也不是死模板。 而是让表达有空间，让成交有秩序。

说一个很小的细节：我们为什么会对底部导航这种东西较真到近乎烦人

我们在做 Foundax 的时候，花过不少时间折腾一个看起来很不起眼的东西：

手机底部那一条导航。

说真的，这玩意儿一点都不性感。 用户不会因为一个底部 bar 爱上你，媒体也不会因为你把它做好了专门写篇报道。 它小得像一个随时可以被产品会议牺牲掉的细节： “差不多能用就行吧。” “先上线吧，后面再调。” “别在这种地方浪费时间了。”

可偏偏就是这种地方，最容易暴露一个产品到底是“做出来了”，还是“被认真做过”。

因为手机上的购物体验，本质上不是页面体验，而是拇指体验。 用户在手机上浏览时，并不是像在电脑前那样有耐心研究页面结构。 他是在地铁里、在沙发上、在等红灯的间隙，用一只手快速判断：

这个网站顺不顺？ 我下一步该点哪里？ 这个品牌靠不靠谱？ 我有没有被打扰？ 我敢不敢继续往下走？

这时候，底部区域根本不是一个“可有可无的装饰件”。 它其实是行动节奏的一部分。

问题是，把底部导航放进浏览器环境里，并没有听起来那么简单。

浏览器本身就有自己的底栏。 不同机型有不同的安全视口。 页面滚动时，底部元素很容易遮挡内容。 如果只是生硬地把导航抬高一点，虽然技术上避开了遮挡，视觉上却往往会变成一场灾难——像是一个不该悬在那里的东西，硬被钉在页面底部。

很多产品做到这里，大概就会停了。 毕竟功能已经在了，用户也不是不能点。

但我们不太甘心。

因为我们始终觉得， 如果独立站想在浏览器里长出接近 App 的体验，那它就不能只满足于“看起来能用”。 它得在那些最容易被忽略的小地方，也有一种真正被打磨过的顺手感。

所以我们后来反复在想一个问题：

这个底部 bar，到底什么时候该出现，什么时候该退后？

用户在浏览商品描述、翻规格、看细节图的时候，需要的是沉浸。 这时候如果底部区域一直悬着、一直催促，体验其实是被打断的。 可一旦用户到了行动区，准备加入购物车、准备进入下一步，行动入口又应该及时回到手边。

所以最后做出来的，不是一个永远贴在底部刷存在感的导航。 而是一个会根据场景进退的悬浮 bar： 该隐藏的时候隐藏，该出现的时候出现； 既不挡内容，也不故作聪明地永远后退； 它要像一个训练有素的配角一样，平时不喧宾夺主，关键时刻永远站在最顺手的位置。

表面上看，这真的只是一个小功能。 但我们一直很喜欢这种地方。

因为一个团队到底有没有把产品当成“真正的 Web 应用”在做，往往不写在那些最大最显眼的模块里，反而写在这些外人看起来“不就一个底栏吗”的地方。

用户也许不会准确说出问题出在哪里。 他不会说：“这个网站的底部交互和安全视口处理让我感受到了你们对移动端行为与转化漏斗的深度理解。” 正常人不会这么说话，除非他刚从产品评审会上下来。

但他会感觉到一件很真实的事：

这个网站，用起来很顺。

而这种“顺”，很多时候就是信任开始发生的地方。

我们为什么这么看重这种“小地方”

因为在交易型产品里，很多真正影响结果的因素，本来就不是那种一眼能看出来的大功能。

用户不会因为你写了一句“我们非常重视用户体验”就信你。 他也不会因为你后台有一百个配置项就自动愿意下单。 真正让人留下来的，常常是那些很难被单独命名、但又会连续叠加的感受：

• 页面是不是清楚
• 操作是不是顺手
• 行动区是不是稳定
• 移动端是不是像为手机而生，而不是桌面网站的缩水版
• 品牌表达和交易动作之间，是不是在互相成就，而不是彼此打架

Foundax 想做的，从来都不是“给你一套模板，让你上线一个能打开的网站”。

我们更想做的是： 让不懂代码的人，也能搭出兼顾品牌表达、交易效率和移动端体验的 Web 应用。

所以我们会把交易流程系统化，把品牌建设模块化； 会在那些看起来不值钱的小地方死磕； 也会尽量把很多本来需要插件、定制开发、前端补丁才能做到的能力，做成系统原生的一部分。

因为我们相信，Web 要重新成为产品主场，靠的不会是情怀。 靠的是它真的变得更好用了。

AI 不会把我们带回 old web，它会把 Web 推向一个更像应用的新阶段

所以，如果一定要给这篇文章下一个结论，我会这样说：

AI 不会把我们带回那个“做个官网就够了”的旧 Web 时代。 那种时代已经过去了。

AI 真正会推动的，更可能是另一个方向： 让 Web 进一步进化成一种更像应用、更适合交易、更容易迭代、也更容易被 AI 理解和接入的产品形态。web.dev

这个新阶段里的 Web，会继续保留它最重要的优点：

• 开放
• 可链接
• 可搜索
• 可分享
• 可快速更新
• 可单代码库覆盖多端
• 可被 AI 与搜索系统直接访问

同时，它也会越来越吸收过去属于 App 的那些优点：

• 更强交互
• 更像原生的移动体验
• 更完整的设备能力
• 更清晰的交易链路
• 更稳定的用户心智

从这个角度看，真正值得关注的，不是“Web 会不会赢 App”这种太粗暴的二选一问题。 而是：

在 AI 把开发门槛打下来之后，越来越多产品会不会发现，Web 已经变成了那个更现实、更划算、也更值得重新认真做一次的选择。

我觉得，会。

而 Foundax，想做的正是这件事。

---

如果你正在判断品牌官网、内容站或轻量 SaaS 是否该先走 Web-first，也可以顺手看一下 Foundax 的功能页面。如果你更关心个人和小团队怎样把这类 Web 优势沉淀成长期资产，也可以继续读这篇：2026年个人品牌资产搭建：为什么偏偏是现在。

常见问题

2026 年哪些产品更适合 Web-first，而不是一开始就 App-first？

通常是那些更依赖搜索发现、内容解释、轻量注册、跨设备访问、快速迭代和低成本试错的产品，比如品牌官网、内容站、独立站、轻量工具和中小团队 SaaS。只要你的关键瓶颈更偏向“被看见、被理解、被转化”，Web-first 往往就比 App-first 更合理。

AI 为什么改变了 App 与 Web 的成本比较？

因为 AI 显著降低了开发和迭代成本，却没有同步降低 App 审核、应用商店分发、双端维护、安装转化和版本更新的流程成本。结果就是，“做出来”变便宜了，但“作为 App 运营起来”并没有一起变轻，Web 的性价比反而更高。

AI 搜索和浏览器入口，为什么会进一步提升 Web 的商业价值？

因为 Web 天然开放、可链接、可抓取、可结构化，更容易进入 AI 摘要、搜索结果、分享链接和内容分发链路。用户越是从摘要和短路径进入产品，Web 这种可被直接理解和直接访问的形态，商业价值就越高。

品牌官网、内容站和轻量 SaaS，什么时候应该先做 Web，什么时候仍然要补 App？

如果你的增长更依赖搜索、内容、介绍、FAQ、试用和跨设备访问，通常应先把 Web 做对；只有当产品核心体验强依赖原生通知、硬件能力、长期高频使用或应用商店分发时，再把 App 补上会更合理。顺序问题，比二选一更重要。

今天做 Web-first 产品，最需要补哪几层能力？

至少要补齐移动端体验、页面性能、结构化内容、清晰转化链路、稳定信息架构和可持续更新能力。今天的 Web-first 不是做一个“能打开的网页”，而是做一个能被搜索、能被理解、能被持续使用的产品表面。

---

参考资料

1. Andreessen Horowitz，《From Prompt to Product: The Rise of AI-Powered Web App Builders》，2025-02-11 阅读原文
2. Apple Developer，《App Review Guidelines》 阅读原文
3. web.dev，《Progressive Web Apps》 阅读原文
4. Chrome for Developers，《Built-in AI》 阅读原文
5. Google，《AI in Search: Going beyond information to intelligence》，2025-05-20 阅读原文
6. web.dev，《Blibli’s PWA generates 10x more revenue per user than their previous mobile website》 阅读原文
7. web.dev，《Mainline Menswear sees 55% increase in conversions with PWA》 阅读原文
8. TechCrunch，《Sweden's Lovable, an app-building AI platform, rakes in $16M after spectacular growth》，2025-02-25 阅读原文
9. TechCrunch，《Eight months in, Swedish unicorn Lovable crosses the $100M ARR milestone》，2025-07-23 阅读原文
10. TechCrunch，《Lovable says it added $100M in revenue last month alone with just 146 employees》，2026-03-11 阅读原文
11. Reuters，《OpenAI's weekly active users surpass 400 million》，2025-02-20 阅读原文
12. ChatGPT 官方产品入口 阅读原文
13. Claude 官方产品入口 阅读原文
14. Perplexity 官方产品入口 阅读原文