前阵子和几个做投资的朋友聊起AI圈的怪现象不少独角兽烧了好几年钱才把估值抬起来可今年冒出来的几个个人/小团队AI产品短短一年就被传到了百亿美金量级最离谱的是——它们从头到尾连个APP都没做。你没看错没有App Store那一套也没做安卓包所有用户都是打开一个链接网页端直接开干。这件事放在三年前几乎不可想象因为那时候一个互联网产品想要证明自己先做个APP几乎是默认动作。但现在AI时代的产品形态正在被重新定义入口从图标变成了对话框分发从应用商店变成了链接体验从安装变成了打开即用。这篇文章我想把这股“不做APP也能估值百亿”的现象彻底拆一遍聊清楚背后的产品逻辑、技术骨架、实操路径还有普通人能怎么抄作业。1. 产品形态变了为什么“没有APP”反而成了卖点1.1 先还原一下爆火产品的用户路径这类产品通常走的是同一个路径用户在社交媒体上刷到一条演示视频或截图点击评论区里的链接浏览器打开一个很干净的页面中间一个输入框旁边写着“输入你的需求”。用户随手敲一行字几秒钟后页面像打字一样慢慢吐出一整篇结果。全过程不超过一分钟没有下载按钮没有“请注册后使用”更没有人要求授予通讯录权限。等用户反应过来他已经在用这个产品了。这个路径的价值被很多传统产品经理严重低估了。一个用户从“听说一个产品”到“真正用上”在APP时代需要经历搜索下载、等待安装、打开注册、学习界面、至少三到四次的点击确认。每一步都是流失点。有数据显示应用商店详情页到激活的转化率能做到30%就已经很优秀而网页链接到首次使用的转化率在场景匹配的前提下能做到60%甚至更高。原因很简单——用户不需要在自己手机上给一个陌生产品“腾地方”。1.2 APP时代的惯性已经被打破了老一辈产品人习惯把APP当成“资产”因为APP意味着推送权限、桌面图标、可控的分发渠道。但这个逻辑在个人开发者和两三个人组成的团队面前完全失效上架审核要等发版要过审用户升级要提醒权限弹窗遭人反感还要兼容五花八门的机型。一年的维护成本动辄几十万对个人产品来说无异于自杀式负重。AI产品最核心的资产不是应用而是你的模型能力、任务编排逻辑和数据飞轮。用户没有兴趣在你的手机上多装一个“智能助手”他只想在需要用的时候打开浏览器把问题解决掉。工具属性越强用户越不愿意为它承担安装成本。这是人性不是你产品不够好。1.3 对话成了新的入口网页天然最适合它ChatGPT这类产品花了两年时间教育市场AI产品的标准界面就是“一个输入框一块流式输出的区域”。用户在新的AI产品上几乎不需要学习成本因为他已经习惯了对话式交互。对话式交互天然适合Web形态你不需要申请摄像头、不需要常驻后台、不需要推送只要给用户一个能打字、能展示内容的页面就够了。这也意味着过去APP形成的“图标-红点-推送”的唤醒体系正在失效。AI产品的唤醒靠的是任务本身用户想起了某个待办打开浏览器输入拿到结果。没有比这更轻的路径了。很多爆火产品甚至连登录都不强制先让你用完再决定要不要注册这种“用完即走”反而带来了更高的完整体验率。2. 技术骨架拆解网页版AI产品是怎么搭起来的2.1 核心模块模型网关、编排层、记忆层这类产品的技术架构并不复杂但和传统Web应用有很大区别。传统Web是“前端页面业务API数据库”AI产品多了两个关键层模型网关和任务编排层。模型网关负责统一封装各家大模型API比如对外提供同一个接口内部根据任务类别分发到不同的模型。为什么要这一层因为不同模型在代码能力、长文本、数学推理、成本上各有优势你不可能让一个模型干所有事。网关还可以做缓存命中的结果直接返回省掉一次真实模型调用。任务编排层是更核心的部分。用户输入一句话后系统要判断这句话需要哪些步骤是直接生成还是先查资料再生成还是需要调用外部工具。这时候就用上了Agent的概念——一个大模型作为调度中枢把一个复杂任务拆成子任务逐个执行再汇总结果。做AI产品如果没有这层你的产品就只是个“套壳聊天框”没有任何壁垒。记忆层负责把用户的历史行为、偏好、常用配置存下来。很多人以为AI产品只要有模型就够实际上连续多轮任务的体验差异全靠记忆层。比如用户上礼拜用你的产品跑过一次数据分析这周再打开系统应该还记得他上次用的指标口径而不是让他重新输入一遍。这个层通常用到向量数据库把用户历史转成向量做相似度检索。2.2 为什么Web足够用了流式传输、PWA、WebGPU有人会质疑很多重计算任务浏览器扛得住吗答案是大部分AI推理都不需要在浏览器端执行而是放在服务端浏览器只负责展示。你需要的核心能力其实是三个流式传输让模型输出一个字一个字蹦出来用户等待的焦虑感会大幅降低。PWA能力可以把网页“添加到主屏幕”看起来像一个原生APP。后台任务用Service Worker实现简单的离线缓存和通知。至于重计算浏览器端有WebGPU这样的接口可以做轻量推理但在产品和成本层面绝大多数场景都不需要走这条路。别过度设计先把服务端调度做好比什么都实在。2.3 一个最小架构示例我见过很多小团队的产品后端就是一个Python服务加一个任务队列前端一个React页面部署在一台带GPU的服务器或者直接调用云厂商的模型API。拿代码示意的话最小闭环大概是这样的# 伪代码一个简单的AI Agent编排入口 from llm_gateway import chat_completion, cache_if_hit from agent_planner import plan_task, run_tool def handle_request(user_input: str, user_id: str): # 1. 查询记忆层看有没有可复用的上下文 context memory_db.get(user_id) # 2. 判断是否需要走复杂任务编排 plan plan_task(user_input) if len(plan) 1: # 多步骤任务让Agent逐个执行 results [] for step in plan: if step.type tool: results.append(run_tool(step)) else: results.append(chat_completion(step.prompt, context)) return merge_results(results) # 3. 简单任务直接在网关层做缓存查询 cached cache_if_hit(user_input user_id) if cached: return cached return chat_completion(user_input, context)这套代码看着简单里面藏着的关键点是记忆层的上下文注入、网关层的缓存策略、编排层的任务分解。这些才是决定一个AI产品用户体验好坏的细节而不是你用的模型有多大。2.4 没有APP登录怎么做不做APP不代表没有用户体系这套系统照样需要识别用户。最常用的方案是“两段式”未登录用户先用一个匿名ID把任务跑完拿到结果满意了再引导他“登录保存历史记录”。登录方式首选手机号验证码或社交账号免密登录别用复杂的账号密码体系。为什么因为AI产品是频繁打开的工具如果登录摩擦太大用户转头就走了。这里有一个实操细节匿名用户的任务数据不要急着删可以保留24小时等他登录后直接把历史记录合并过来。虽然技术上多一点兼容工作但转化率的提升非常明显尤其是从分享链接进来的那批用户他们很大概率是想用了才点进来的一定要给他们最低门槛的体验。3. 实操路径从零开始做出一个Web优先的AI产品3.1 第一步选场景认准“高频但轻”的需求不是所有需求都适合做成纯Web AI产品。我建议优先选那些“用户临时有需求、拿到结果就走”的场景比如写一段营销文案、做一份摘要、翻译并润色长文、把一段录音转成结构化纪要。这些需求的共同点是单次使用时长在1到5分钟之间结果可以马上被复制带走不需要长期驻留进程。反过来那些需要7x24小时监听、需要和硬件交互、需要常驻后台的场景比如桌面助手、实时翻译、监控提醒就不适合完全没有APP的形态。别看着爆火产品眼馋先问自己我的场景里用户是“顺便用一下”还是“挂着一直用”如果是后者那Web优先就不合适。3.2 第二步30天做出一个能传播的版本做个人AI产品别一上来就憋大招。我给你一个30天时间表照着做就行第1-7天把模型网关搭起来接好大模型API写一个最简单的对话框能对话、能流式输出。这个阶段的目的是让产品跑通别优化体验。第8-14天加任务编排选定一个具体场景把单轮对话升级成“能干活”比如“输入主题自动生成一篇带小标题的公众号风格文章”。第15-21天加用户层和记忆层匿名体验、登录、历史记录、结果分享链接。分享功能尤其重要这是传播的种子。第22-30天集中打磨一次性体验把加载速度、流式输出的流畅度、错误提示文案做好。然后找20个朋友压力测试把卡住的任务全部修掉。我见过太多人死在第一周天天在纠结用哪个模型、报备哪个框架结果两星期过去连个页面都没有。先跑通再优化这是铁律。3.3 第三步围绕“复访”设计钩子纯Web产品最大的痛点是没有桌面图标用户很容易忘了你。所以产品设计上必须刻意增加“回来的理由”。实操中有几个屡试不爽的钩子历史记录要躺在显眼的位置用户上次做的事下次打开直接续上。支持把常用任务“固定”成模板比如“周报生成器”“会议纪要模板”用户每次只需改几个参数。提供定时任务和结果推送比如每周五早上自动生成一份数据汇总通过邮件或站内消息提醒用户回来查看。最后生成的结果要做成“可分享的URL”别人打开分享链接也会看到产品的水印和引导语这是最廉价的口碑裂变。3.4 成本护栏让产品不被API账单吃死个人做AI产品成本失控是最常见的死法。尤其是那些做了免费体验的产品一旦被羊毛党盯上一天几万次调用就可能把半个月预算烧光。我建议从第一天就做好三件事限流每个匿名IP每天最多调用N次每个登录用户每天有明确的次数上限。缓存相同请求直接命中缓存缓存有效期设置合理短时间重复调用不会重复计费。分级模型轻量任务走便宜的小模型只有复杂任务才调大模型。很多场景下小模型的输出质量完全够用能在保证体验的同时把成本降一个量级。设置这些护栏的时候多花两天时间后面能给你省出十倍的时间和钱。千万别想着“等流量大了再做”等流量大了你连被挤爆的机会都没有。3.5 什么情况下才需要补一个APPWeb优先不等于永远不做APP。当数据出现下面几个信号时你就该认真考虑做原生APP了用户有明显的“常驻”行为比如一天打开五次以上且每次都是碎片化快速使用。产品需要系统级入口比如通过桌面小组件一键发起任务。依赖推送通知做核心提醒比如定时任务跑完要立刻通知用户。需要调用系统硬件比如摄像头扫码、本地录音处理。大部分AI产品长期都用不到这些能力。哪怕到了估值几十亿美金的阶段一个Web产品也照样能支撑业务运转。做APP前先让用户用网页端用到离不开再做加法也不迟。4. 估值百亿美金的资本逻辑到底在看什么4.1 资本买的是增长加速度和用户心智为什么一个没有APP的AI产品能拿到夸张的估值资本不是在做慈善也不是单纯追风口。他们买的是三样东西增长曲线的斜率、用户完成任务时的“WOW感”、以及产品在某个垂直场景里形成的品牌心智。先说增长曲线。Web产品天然具备病毒传播属性每个用户分享出去的链接都是产品的新访问入口用户增长几乎是复利式的。资本看到月度复合增长率30%到50%再对比传统APP动辄几十块钱的获客成本立刻就会高看一眼。再说用户心智。当一个产品的名字成为一类任务的代名词比如“找资料就用它”“写文案就开它”这个心智本身就值很多钱。Web产品不做APP反而更快完成这件事因为用户访问的是网址不是图标场景联想更直接——他是在干活的时候想起你的不是在看手机桌面的那一眼想起你的。4.2 估值模型变了从DAU到“任务完成量”传统互联网的估值模型极度依赖用户时长和广告变现但AI产品的核心指标变成了任务完成量、任务成功率、用户为任务支付的单位成本。这里有个关键点用户时长越长对AI产品来说未必是好事。用户用了三分钟拿到结果离开是健康的用户在你的对话框里来回绕了三十分钟还没搞定那是灾难。所以资本看这类产品更关心的是“单次任务交付率”和“用户复访频次”而不是“停留时长”。没有APP反而让产品必须用任务交付来证明自己从第一天起就逼着团队把体验做干净。这套指标体系和传统估值框架完全不同也是新一波价值重估的根本原因。4.3 估值泡沫的风险点必须承认百亿美金的估值里有一定预期成分。这类产品最大的风险有三个入口替代如果底层大模型后续直接把类似能力内置了你的产品可能一夜之间失去存在意义。同质化竞争今天这个场景火明天几百个同类产品就冒出来了没有数据积累和品牌壁垒的话很容易被淹没。留存不稳新鲜期过了用户是否还能持续回来决定了估值能不能站住。对从业者来说与其纠结估值是不是泡沫不如想清楚自己做的事在三个维度上有没有壁垒数据飞轮、场景know-how、用户习惯绑定。三者至少占一样你才算在真正建立护城河而不是给平台免费打工。5. 避坑指南实操中容易翻车的细节5.1 流式输出反而变卡了很多产品做完第一个版本后发现用户反馈“打字太慢像卡住了一样”。原因多半不是模型慢而是你服务端没有把流式数据及时吐给浏览器。排查时先看三个地方是不是用了缓冲模式是不是反向代理层缓冲了数据是不是前端用了非流式的请求解析。简单做法是直接在前端用原生fetch配合ReadableStream读取别用老的HTTP响应解析库。5.2 用户输入乱七八糟任务经常理解失败个人开发者最容易高估大模型的理解能力。用户不会按你的预期说话他会写错别字、带口语、甚至一下子塞进来一整段无关内容。应对方案是在编排层加一个“意图纠偏”小模块先用一个便宜的模型把输入做标准化提取关键参数再交给主流程。这一步看着多花一次模型调用实际能显著降低下游任务的失败率。5.3 并发一高支付级别的账单压力来了访问量涨起来是好事但如果没做并发控制和成本告警离崩盘就不远了。这里分享一个血泪教训上线一周后产品被好事者发到热门社区流量翻了十倍API账单也跟着翻了十倍。后来加了两个机制才救回来一是按用户维度做请求队列并发超了就排队二是设置了日账单告警超过预算自动切到低配模型并降速宁可用户体验稍有折损也不能让资金链断裂。5.4 内容安全与数据合规不能漏很多人以为不做APP就不用考虑合规这是天大的误会。Web产品直接面向公网内容安全反而更重要。你生成了什么内容、怎么处理用户数据、隐私政策放哪、未成年人能不能用都需要提前规划。关键是你的产品如果允许用户输入任意内容并生成结果你必须有能力在输出端做风险识别和过滤同时记录必要日志。千万别等出了问题再补救个人产品一旦出事没有公关团队给你兜底。我在实际操盘这类Web优先AI产品时最深刻的体会是技术难题从来不是最大的门槛能不能克制住“什么都想要”的欲望才是。做精一个场景用链接把产品和用户连接起来让用户每次打开浏览器都能顺手完成一件小事这个产品就已经比绝大多数想做“超级入口”的大平台活得健康。如果你正在做类似的事情建议从今天起把APP的计划放一边先把网页端的那条主任务流打磨到让人愿意分享为止。