“别做 App”：一人团队的 Web vs 原生决策指南

每个 vibe coder 都在某个深夜动过这个念头：产品上线了，数据还不错，"要不要顺便做个 App，上架 App Store？"这个念头看起来很顺理成章，实则可能是你今年做的最贵的决定。贵不是因为开发本身难——AI 帮你把 React Native 的脚手架搭出来也就一个下午——贵的是你从此背上了一套永远甩不掉的税：双端兼容、审核排期、推送证书、版本碎片、商店抽成。对一个人来说，这笔税往往比开发本身更致命。

本文给出一句结论，剩下的几千字都是它的论证：对一人团队，原生 App 不是起点，而是一种"增长税"——只有在被验证的增长需求面前，它才值得交。在交税之前，先做 Web。几乎永远，先做 Web。

一、为什么 AI 时代，Web 的优势反而更大了

很多人直觉上觉得"AI 降低了所有开发的成本，所以原生和 Web 的差距也缩小了"。这个直觉错了一半：AI 确实把两边的绝对成本都压低了，但它把 Web 的相对优势放大了。原因有三条，每一条都直击一人团队的命门。

1. 迭代速度：Web 是"改完即上线"，原生是"改完等审核"

Web 的部署是 push 到 main 就全球生效。用 Vercel、Cloudflare Pages 这类平台，从 AI 改完代码到用户用上新版，中间是几分钟。原生呢？iOS 发版要走 App Store 审核，常规几个小时到一两天，赶上被拒一次，整改加重新排期，半周没了；Android 虽然审核快得多，但你要维护两套构建流水线、签名证书、版本号管理。对一人团队，迭代速度就是生命线：你验证一个想法的速度，等于你交一次学费的速度。Web 让你一天验证三次，原生让你一周验证两次——这个差距在 AI 时代没有被抹平，反而因为 AI 让 Web 的迭代更快了，被进一步拉大。

更隐蔽的是热修复成本。Web 上线后发现一个崩溃 bug，你改一行、重新部署，五分钟后全网恢复。原生 App 的崩溃 bug 要等用户更新版本——而相当一部分用户根本不开自动更新，你得在代码里写版本兼容逻辑、发强制更新弹窗、眼睁睁看着崩溃率报表上的旧版本长尾拖你两周。这是维护层面的"利息"，每周都会收一次。

2. 分发零摩擦：链接就是渠道

原生 App 的获客漏斗是这个形状的：看到推荐 → 跳转商店 → 下载（几十 MB）→ 安装 → 注册 → 首次使用。每多一步，漏掉 20%–40% 的人。Web 的漏斗是：点开链接 → 直接用。把产品链接丢进一条推文、一个群聊、一条评论区，用户零成本体验——这对冷启动的一人产品是决定性的。你的第一个 100 个用户，几乎一定来自你亲手发出去的链接，而不是应用商店的搜索流量。

别忘了 SEO 和分享带来的长尾。Web 页面天然可被搜索引擎收录、可被社交媒体抓取卡片、可被别人引用链接。原生 App 的内容是商店围墙里的黑盒，Google 搜不到你 App 里的那篇精彩内容。一个靠内容和口碑传播的一人产品，Web 的分发能力是原生给不了的。

3. AI 写 Web 代码，是它最熟练的活

这是最被低估的一条。大模型的训练语料里，HTML/CSS/JS/React 的数量级远超 SwiftUI 和 Kotlin Compose。反映到实际体验上：你让 AI 写一个复杂的 Web 交互，它一次成型的概率明显更高；让它写原生 UI，遇到平台 API 的坑（权限申请流程、生命周期、后台模式）时，幻觉率显著上升。更不用说调试：Web 的报错可以直接贴进对话，浏览器 DevTools 的信息密度极高；原生的构建错误动辄涉及 Xcode 配置、Gradle 依赖冲突、签名证书过期，AI 在这些"环境型"问题上的表现一向拉胯。

一句话：同样是你+AI 的组合，做 Web 时 AI 是你的十倍速队友，做原生时它时不时变成需要你擦屁股的实习生。你一个人的时间是最贵的资源，把它花在 AI 最擅长的战场上。

二、五个"必须做原生"的例外

Web-first 不是 Web-only。下面五种情形，原生不是可选项，是必答题。判断标准很简单：如果你的核心价值主张离开了原生能力就不存在，那就做原生；如果只是"有了更好"，那就先做 Web。

例外 1：强推送依赖——推送就是产品本身

注意这里说的是"强推送依赖"，不是"想发推送"。几乎所有产品都"想"发推送，但只有少数产品的核心循环离开推送就转不动：即时通讯（消息不及时到达产品就死了）、外卖/打车的状态通知、限时抢购提醒、安防告警。检验方法：问自己"如果用户三天收不到任何推送，产品还成立吗？"如果答案是"不成立"，这是原生。

但先别急着下结论，读完第四节再决定——PWA 的 Web Push 在 2026 年已经能覆盖相当一部分"中等强度"的推送需求，iOS 16.4 之后安装到主屏幕的 Web 应用也能收推送了（来源：Apple WebKit 官方博客）。只有"必须 100% 到达率、必须富媒体、必须静默唤醒"这种级别，才锁死原生。

例外 2：硬件传感器——你要调用 Web 够不着的硬件

蓝牙外设（智能硬件配对）、NFC（门禁、支付终端）、USB 串口（工业设备调试）、ARKit 级别的 AR、精确到亚米级的后台定位——这些是浏览器的禁区，Web API 要么没有，要么在 iOS 上被阉割。反例也要说清楚：相机、麦克风、地理位置、加速度计，Web 全都能调。 很多人以为"扫码必须原生"，其实现在浏览器调摄像头做扫码已经非常成熟。做决定之前，先查一遍 MDN 的兼容性表，别凭 2019 年的印象下结论。

例外 3：后台常驻——App 关了还要干活

音乐播放、导航、运动记录、下载管理、VoIP 通话——这类"用户切出去、App 还要在后台持续运行"的场景，原生是刚需。浏览器的后台能力（Service Worker 的后台同步、周期性同步）在 Android 上部分可用，在 iOS 上基本等于没有：iOS 的 Web 应用一切到后台，定时器和网络请求很快就会被系统掐掉。如果你产品的核心场景是"锁屏了还在跑"，别犹豫，做原生。

例外 4：应用商店自然流量——商店就是你的获客主渠道

这是最容易被误判的一条。先说结论：对 99% 的一人产品，应用商店带来的自然流量约等于零。App Store 里每天上架上千个应用，没有外部导流的新 App 在分类榜里的可见度基本为零。真正的例外只有两类：一是工具类 App 的精准搜索流量（比如"PDF 扫描""白噪音"这种有明确搜索意图的词，ASO 确实能吃到长尾）；二是你的目标用户只信任商店下载（某些地区的老年用户、企业客户）。检验方法：去 App Store 搜你的核心关键词，看看前 20 名里有没有最近一年上架、不做投放还活着的新面孔。没有的话，商店流量这条对你不存在。

例外 5：性能硬门槛——Web 的帧率就是过不了

3D 游戏、实时音视频特效、4K 视频剪辑、大型 CAD 查看器——这类对 GPU 和内存有硬要求的场景，Web 的性能天花板是真实存在的。注意关键词是"硬门槛"：不是"Web 有点卡"，而是"Web 根本跑不起来"。绝大多数 CRUD 型产品、内容型产品、AI 对话型产品的性能瓶颈都在网络和模型推理上，不在渲染层，别拿"性能"当借口。真有疑虑时，先做个 Web 原型实测帧率，数据比直觉可靠。

五个例外，一个都不沾？那就先做 Web。这不是保守，这是算术。

三、决策矩阵：场景 × 团队 × 阶段的三维打分表

例外清单是定性的，这一节给一套定量的打分方法。三个维度，每个维度按 -2 到 +2 打分（+2 必须原生，+1 倾向原生，0 中立，-1 倾向 Web，-2 必须 Web），加总看结果：总分 ≥ +3 做原生，≤ -3 做 Web，中间地带看第四节的 PWA 中间态。

维度	+2（必须原生）	+1（倾向原生）	0（中立）	-1（倾向 Web）	-2（必须 Web）
场景	命中第 2/3/5 条例外（硬件/后台/性能硬门槛）	命中第 1 条例外（强推送），或目标用户只用手机且只信任商店	桌面和移动场景并重	内容/工具型，靠链接传播和 SEO 获客	还在验证 PMF，需求每周都在变
团队	有专职移动端经验（你本人写过 2 年以上原生）	用过 React Native/Flutter，能独立处理证书和上架	2–5 人小团队，有人能分担双端维护	纯一人，无原生经验，靠 AI 补位	一人且 AI 是你唯一的"队友"，Web 是 AI 最擅长的战场
阶段	已验证 PMF，原生是明确的增长瓶颈（见第五节触发信号）	收入稳定，付得起"增长税"，想吃商店流量	增长期，多渠道并行测试	冷启动期，获客靠亲手发的链接	想法验证期，连 Web 版都还没人用

举两个例子。例 A：你一个人，用 AI 做了一个 AI 健身打卡工具，核心循环是"每天提醒我打卡"——场景上推送是强依赖（+1），团队一人无原生经验（-2），阶段是冷启动（-1），总分 -2：先做 Web + PWA 推送（第四节会讲具体做法），等日活过万、推送到达率真的成为瓶颈再考虑原生。例 B：你做智能门锁的配蓝牙硬件，需要调蓝牙 API（场景 +2），你本人写过三年 iOS（团队 +2），硬件已经量产有真实用户（阶段 +1），总分 +5：直接原生，别犹豫。

这个矩阵的真正价值不是算出分数，而是逼你把"我觉得该做 App"翻译成三个可检验的命题。很多人在"场景"这一行就卡住了——仔细一想，所谓的"必须原生"只是"原生体验更好"，那在打分表里最多值 +1，左右不了大局。

四、PWA：被严重低估的中间态，以及它的真实边界

PWA（渐进式 Web 应用）是 Web-first 路线里最重要的一张牌：用户从浏览器"添加到主屏幕"，得到一个全屏、无地址栏、有独立图标、可离线、可收推送的"类 App"体验——而你维护的依然是一套 Web 代码、一次部署全球生效。2026 年的 PWA 早已不是当年的半成品，但它的边界依然清晰，决策前必须逐条核对。

PWA 能力对照表（2026 年 10 月现状）

能力	桌面 Chrome/Edge	Android Chrome	iOS Safari	备注
添加到主屏幕 / 独立窗口	✅	✅	✅（需用户手动"分享 → 添加到主屏幕"）	iOS 没有自动安装提示（beforeinstallprompt 不支持），必须手把手教用户操作
Web 推送通知	✅	✅	⚠️ 仅限已安装到主屏幕的 Web 应用，iOS 16.4+	来源：Apple WebKit 官方博客；iOS 18.4+ 另有声明式 Web Push，可靠性更高
离线访问（Service Worker 缓存）	✅	✅	✅	注意 iOS 对存储配额和缓存逐出更激进
后台同步 / 周期性同步	✅（周期性同步需安装）	✅	❌	这是 iOS 上 PWA 最大的短板之一
相机 / 麦克风 / 地理位置	✅	✅	✅	扫码、录音、定位类需求 Web 完全够用
蓝牙 / NFC / USB	✅（桌面 Chrome）	✅（部分）	❌	智能硬件配对类需求直接判原生
应用角标 / 桌面小组件	✅（角标）	✅	⚠️ 有限支持	强依赖小组件展示的场景要实测
应用商店分发	—	⚠️ 可通过 TWA（可信 Web Activity）进 Google Play	❌	想吃商店流量就别指望 PWA

把 PWA 做到"像个 App"的三件实事

第一，写一个 iOS 安装引导页。这是 PWA 在 iPhone 上转化率的分水岭：因为 Safari 不会弹安装提示，你必须在产品里放一张三步图解——点分享按钮 → 添加到主屏幕 → 从主屏幕打开。别嫌土，这一步能把 iOS 的 PWA 安装转化率从接近零拉到可用水平。检测到 iOS 且未安装（display-mode 不是 standalone）时再弹这个引导，别骚扰已经装好的用户。

第二，把 Web Push 的订阅流程做进 onboarding。iOS 上推送权限只能在已安装的 Web 应用里申请，而且必须由用户手势触发。正确姿势：在用户完成某个有价值的动作之后（比如创建第一个提醒、收到第一条消息），再弹出"开启推送不错过更新"的订阅按钮，一次把"安装到主屏幕 + 允许通知"两步走完。技术上就是标准的 Push API + VAPID，一套服务端代码同时服务 Android、桌面和 iOS，不需要 Apple 开发者账号（来源：Apple 开发者文档对 Web Push 的说明）。

第三，接受并设计"降级态"。PWA 的哲学是渐进增强：先保证在浏览器里 100% 可用，再为安装用户叠加离线和推送。别反过来——别做一个"不安装就用不了"的 PWA，那等于把 Web 的分发优势亲手扔掉。

一句话总结 PWA 的定位：它是 Web-first 路线的"加强版"，不是原生替代品。它能帮你把"要不要原生"的决定推迟 6–12 个月，而这 6–12 个月，正是你验证 PMF 最宝贵的时间窗口。

五、什么时候才值得交这笔"增长税"：迁原生的触发信号

假设你听了前面的建议，先做了 Web，产品也跑起来了。什么时候才该认真考虑原生？不是"有钱了就做"，也不是"用户说想要 App 就做"——用户永远会说想要 App，就像食客永远说"要是开在我家楼下就好了"。交税需要触发信号，而且必须是数据信号：

信号 1：移动端流量占比超过 70%，且移动端转化率显著低于桌面。去看你的分析后台：如果七成用户用手机访问，但手机端的注册/付费转化率只有桌面的一半，先别急着怪 Web——先用站内这篇《一半流量来自手机：vibe 项目的移动端体验清单》把移动端 Web 体验做到 90 分。如果体验已经做到位，差距依然存在，那说明用户要的不是"更好的移动网页"，而是"一个 App"，这时候原生才有明确的 ROI。

信号 2：推送到达率成为可量化的收入漏斗。"我们想发推送"不是信号，"因为推送到不了，我们每月少赚 X 元"才是。先上 PWA 的 Web Push 跑三个月，统计订阅率、到达率、点击率，算出推送带来的真实收入；再估算原生推送（APNs/FCM 近 100% 到达）能多带来多少。只有当这个差值 × 12 个月大于你做原生 App 的总成本（含后续每年的维护税）时，才值得动手。

信号 3：应用商店出现了你吃不到的精准流量。去 App Store / Google Play 搜你的核心关键词，如果竞品靠 ASO 长期占据前排、评论区全是你的目标用户画像，而你的 Web 版在 Google 搜索里排不进前三——这时候商店是一个真实的获客渠道，值得交"入场税"去分一杯羹。反之，如果搜出来的全是巨头，你进去也只是炮灰。

信号 4：有用户愿意为"App 版"付费。这是最硬的信号。在你的定价页或付费墙上加一个选项："App 专享版 +30% 价格"，或者发一封邮件问付费用户"如果出 App 版，你愿意多付多少钱"。当有 20% 以上的付费用户明确表示愿意为原生体验付费时，需求被验证了。记住原则：原生开发对一人团队不是起点，而是一种"增长税"，只在被验证的需求面前才值得交。"被验证"三个字，值千金。

四个信号，一个都没触发？那就继续打磨 Web 版。你的时间应该花在让产品更好，而不是让产品"更像 App"上。

六、三条真实路径：从 Web 到原生的迁移模式

触发信号亮了，决定交税。怎么交最划算？三条路径，按"复用度从高到低"排列：

路径 A：壳应用（WebView Wrapper）——复用 95% 的代码

用 Capacitor 或 Tauri Mobile 把你现有的 Web 应用包一层原生壳，打包上架。你的 Web 代码几乎不用改，壳只负责三件事：提供原生推送通道（APNs/FCM）、补上 Web 够不着的原生 API（比如更稳定的后台定位）、让你出现在应用商店里。Tauri Mobile 是 2026 年值得关注的新选项，包体积比 Electron 系小一个数量级；Capacitor 的生态更成熟，插件市场基本覆盖了常见需求。

这条路线的真相是：它解决的是"分发"和"推送"问题，不是"体验"问题。你的 App 本质上还是 Web，启动速度、滑动手感不会有质变。如果触发你做原生的信号是信号 2（推送）或信号 3（商店流量），壳应用是最经济的选择，一人一周能出第一个 TestFlight 版。但如果用户抱怨的是"卡""不跟手"，壳应用救不了你，看路径 C。

路径 B：渐进增强——同一份代码，原生能力按需替换

适合用 React Native / Expo 的团队：新功能用原生写，老功能继续跑 WebView，两者在同一个 App 里共存，逐步替换热点页面。Expo 的 EAS Build 让"无 Mac 也能打 iOS 包"成为现实，一人团队不用买 Mac mini 当构建机也能走通上架流程。

这条路线的坑在于中间态的维护成本：Web 和原生两套 UI 范式、两套导航、两套状态管理，在你脑子里打架。实操建议：替换顺序按"用户停留时长"排序，先换用户每天看 10 分钟的首页和核心流程，别先换一年点一次的设置页。设定一个明确的终点——比如"六个月内核心流程 100% 原生"——否则你会永远卡在中间态，交着两份税。

路径 C：重写——承认 Web 版是 MVP，原生是 2.0

最贵，但有时候是唯一正确的选择。当你的产品形态在 Web 验证期发生了根本变化（比如从"工具网站"变成了"社交 App"），或者性能硬门槛真实存在，重写比在旧架构上打补丁更便宜。关键动作只有一个：复用后端和 API，别复用前端幻想。你的用户系统、数据模型、业务逻辑、AI 能力全部在服务端，原生端只是一个新的"皮肤"。很多一人团队重写失败，不是因为原生难，而是因为顺手把后端也重构了——两线作战，一人必死。

选哪条路，看触发你的信号是什么：信号 2/3（推送/商店流量）→ 路径 A；信号 1（移动端体验差距）→ 路径 B 或 C；信号 4（用户愿为 App 付费）→ 问付费用户他们要什么，再选 A 还是 C。以及一个真实世界的参照：Google 在 2017 年推出的 Twitter Lite 就是"Web 先行"的经典样本——一个不到 1MB 的 PWA，在新兴市场承担了原生 App 的获客任务（来源：Google Developers 官方博客）。先 Web 后原生，从来不是将就，而是很多大厂验证过的顺序。

七、成本对比表：双端维护对一人团队时间的真实吞噬

下表是"一人团队、产品进入稳定维护期后"的每周时间开销估算。注意这是维护态，不是开发态——开发期的一次性投入另算，而维护税是每周自动扣款，节假日无休。

开销项	纯 Web	Web + 壳应用	Web + 双端原生
常规功能迭代	基准（100%）	110%（多一套壳的构建和冒烟测试）	180%–220%（同一功能写两到三遍）
紧急热修复	几分钟部署，全网生效	Web 部分几分钟；壳本身的问题要走商店审核	修完等审核，用户侧分版本、分平台逐步收敛，平均 3–7 天
系统/依赖升级	Node 依赖升级，一套	再加 Capacitor/Tauri 插件兼容性检查	iOS SDK、Android SDK、Xcode、Gradle 四线升级，每年 WWDC/Google I/O 后各一次大考
推送通道维护	一套 Web Push（VAPID），服务端一次配置	Web Push + APNs/FCM 双通道，证书每年续期	APNs/FCM 双通道 + 厂商通道（国内安卓），推送证书过期是经典半夜报警
商店合规	0	隐私政策、权限说明、审核被拒整改，每次发版都要过一遍	同左 ×2，且苹果偶尔改规则（比如要求必须支持"苹果登录"），不改就下架
用户反馈定位	复现环境=浏览器，远程可调试	多一层"壳版本 × Web 版本"的矩阵	"iOS 18.2 / App 3.4.1 / iPhone 13"式的碎片化定位，复现靠猜
每周固定税合计（估算）	~2 小时	~4 小时	~8–12 小时

对一周只有 10–20 小时能投入产品的一人团队，这意味着：纯 Web 时你 90% 的时间在做"让产品更好"的事；双端原生时，一半时间在交税。更残酷的是机会成本——那每周 8 小时，本可以用来做三个增长实验、写四篇 SEO 文章、回 50 封用户邮件。而增长实验，才是一人产品活下去的真正燃料。

还有一笔账别忘了：应用商店的抽成。苹果 App Store 小企业计划（年收入 100 万美元以下）抽 15%，标准 30%；Google Play 对首个 100 万美元同样 15%（来源：苹果开发者官网、Google Play 政策页面）。如果你的 Web 版用 Stripe 收款，费率是 3% 左右。从 3% 到 15%–30%，这 12–27 个点的差值，也是"增长税"的一部分——只不过这次是真金白银。

八、一页纸决策模板：10 个问题，30 分钟出结论

打印出来（或者复制到备忘录），诚实回答。是=1 分，否=0 分。得分 ≥7：去做原生；≤3：先做 Web；4–6：走 PWA 中间态，三个月后重测一次。

1. 你的核心功能是否依赖蓝牙、NFC、USB 或 ARKit 级能力？（是=原生方向）
2. App 被用户切到后台后，是否还必须持续运行（播放、导航、记录）？
3. 如果三天发不出任何推送，你的产品核心循环是否就转不动了？
4. 是否有明确证据表明，应用商店的搜索流量能给你带来用户（而不是"我觉得会"）？
5. 你的 Web 原型是否实测过性能，确认帧率/内存真的过不了硬门槛？
6. 你的移动端用户占比是否已超过 70%，且移动端 Web 体验优化到 90 分后转化率依然显著落后？
7. 是否有 20% 以上的付费用户明确表示愿意为 App 版多付费？
8. 你本人（或你的 AI 工作流）是否有独立走完"证书→构建→上架→被拒→整改"全流程的经验？
9. 你是否算过账：原生带来的增量收入 × 12 个月，大于做 App 的总成本加每年维护税？
10. 如果明天 App Store 把你的 App 下架 7 天，你的业务是否还能运转？（答"是"说明你对商店没有单点依赖，反而更应该先做 Web）

第 10 题是故意反着问的。很多人没意识到：上架应用商店等于把你的分发命脉交出去一半。苹果改一条审核规则、Google 调一次政策，你的获客就可能停摆。Web 版永远是你自己的地盘——域名是你的、服务器是你的、用户关系是你的。先有自己的地盘，再去商店里租摊位，这个顺序别反了。

结语：把"做 App"从待办清单移到"增长税"账本

回到开头的结论：对一人团队，原生 App 不是起点，而是一种增长税。税本身不是坏东西——公司做大了都要交税。问题只在于时机：在产品还没验证、还没收入、还没被真实需求推着走的时候，提前交税，交的是你的命。

所以决策流程应该是这样的：先做 Web，用 PWA 把移动端体验做到 80 分；跑三个月，看数据；四个触发信号亮了一个，再按三条路径里最便宜的那条交税。交完税也别扔 Web 版——它是你的 SEO 入口、分享载体和最后的避风港。

等你真的决定"要做移动端"的那一天，体验层面的事另有一份清单可查：站内《一半流量来自手机：vibe 项目的移动端体验清单》假设你已经做了这个决定，讲的是怎么把移动端体验做到 90 分。那篇是"怎么做"，这篇是"做不做"——顺序别反。