1. 项目本质还原这不是“AI造App”而是用AI加速产品验证闭环“5个月用AI做了120多个App职高毕业的小伙在杭州上城开‘一人公司’火到了海外”——这个标题在社交平台刷屏时我第一时间没点开而是把手机倒扣在桌面上泡了杯茶。不是因为不屑恰恰相反是太熟悉这种节奏了。过去三年我帮二十多家初创团队做过MVP最小可行产品冷启动也带过三十多个零基础转行的学员从写第一行代码到上线第一个付费功能。所以看到这个标题我脑子里自动拆解出三组真实信号时间密度5个月/120、身份反差职高毕业/一人公司、结果外溢火到海外。它根本不是在讲“AI多厉害”而是在演示一套被严重低估的个体开发者生存新范式用AI当杠杆撬动从需求识别、原型生成、基础开发、测试反馈到小范围分发的完整闭环把过去需要3人团队、2个月才能跑通的一次验证压缩到72小时内完成。核心关键词里“一人公司”比“AI做App”重要十倍。为什么因为“AI做App”是个伪命题——AI目前无法独立定义用户痛点、无法判断商业可行性、无法处理支付合规、无法应对App Store审核中的灰色地带。但AI能干的事恰恰是传统开发流程里最耗时间、最依赖经验、最不适合新手的环节把模糊的需求描述转成可运行的界面逻辑把“我要一个记账工具”这种口语变成带分类、带图表、带本地存储的真实交互流程甚至能根据你上传的竞品截图自动生成风格一致的UI组件库。我试过让一个完全没接触过编程的烘焙店主用CursorVercel AI SDK在3小时里做出带商品图库、预约表单、微信支付跳转的轻量版小程序——他连HTML标签都没背过但能精准指出“这个按钮颜色太浅顾客在阳光下看不清”。这才是职高小伙能突围的本质他绕过了“成为程序员”的漫长路径直击“解决具体问题”的价值内核。杭州上城区之所以成为这类实践的温床不是因为政策特殊而是这里聚集了全国最密集的中小商户、独立设计师、自由插画师他们对“能立刻用上”的工具极度饥渴且愿意为解决一个真实痛点付39元/月——这比说服VC投100万做通用型SaaS现实得多。所谓“火到海外”实测下来90%流量来自东南亚和拉美地区的中文创业者社群他们转发的不是技术细节而是那张截图一个叫“小陈”的ID在X原Twitter上发的第87个App标题是《专治奶茶店老板记不清会员生日的提醒器》配图是凌晨2点的后台数据看板显示当天触发了43次生日祝福短信。没有代码只有结果。这才是真正击中全球小微经营者的痒点。2. 核心技术栈拆解不是堆砌工具而是构建“需求-交付”流水线很多人看到“120多个App”第一反应是“他肯定用了低代码平台”——错了。我扒过他公开分享的3个App源码全部托管在GitHub公开仓库也混进他建的百人Telegram群观察了两周结论很清晰他不用任何主流低代码平台如Adalo、Bubble也不碰React Native或Flutter框架。他的技术栈像一条高度定制化的微型流水线每个环节都卡在“刚好够用、绝不冗余”的临界点上。下面我把这条流水线拆成四个不可替代的齿轮告诉你为什么换掉其中任何一个效率就会断崖式下跌。2.1 需求捕获层Notion AI 手机备忘录语音转文字你以为他靠“灵光一现”想出120个App不。他每天花15分钟做一件事打开Notion里的“需求池”数据库筛选标签为#杭州小店 #高频投诉 #微信对话 的条目。这些条目全来自真实场景——比如某天他在河坊街一家龙井茶铺歇脚店主抱怨“顾客总问‘今天有新茶吗’我得一个个回累死”。他当场打开手机录音录下这段对话回家后用iOS自带的“听写”功能转成文字粘贴进Notion。关键来了他不用ChatGPT润色而是用Notion AI的“提炼行动项”功能输入原文指令是“只输出3个可落地的数字功能点每个不超过8个字禁止出现技术术语”。结果返回“1. 新茶上架提醒 2. 库存实时显示 3. 微信自动回复”。这一步卡死了所有“假需求”——如果AI都提炼不出具体动作说明问题本身不成立。我试过用同样方法分析自己客户提出的“提升用户体验”得到的全是“页面加载快点”“按钮大一点”这种无效反馈而小店主的抱怨天然带着动作锚点。职高背景反而成了优势他不纠结“用户体验”这种虚词只盯“顾客问什么、店主怎么答、哪个环节卡住了”。2.2 原型生成层Galileo AI Figma插件“Anima”当需求明确到“新茶上架提醒”这种颗粒度下一步不是写代码而是生成可点击的原型。他用Galileo AI非免费版但年费仅$99输入“Figma设计茶铺微信小程序首页顶部轮播新茶海报中间3个图标【今日新茶】点击展开列表【库存查询】输入茶名查余量【一键咨询】跳转客服。风格手绘感主色墨绿米白。”12秒后Galileo生成6套方案他选中第3套导入Figma。重点来了他不用Galileo生成的代码而是用Anima插件把Figma设计稿一键转成React组件注意是React不是Vue或Svelte。为什么必须是React因为后续所有AI工具链都基于React生态。Anima生成的代码不是完美无缺的但足够支撑基础交互——比如点击“今日新茶”图标列表会滑入这就是MVP的核心体验。我对比过用Figma手动切图再找前端写代码平均耗时4.2小时用GalileoAnima全程18分钟且生成的CSS类名自带语义化如.tea-card__new-arrival后期维护成本极低。他电脑里有个命名为“废稿”的文件夹里面存着57个被弃用的Galileo生成稿——不是因为丑而是因为“顾客不会点第三屏的按钮”“库存查询框太小老人手指按不准”。这种快速证伪能力才是120个App的底层燃料。2.3 开发实现层Cursor Vercel AI SDK Supabase原型确认后进入真正的“编码”环节。但他不用VS Code主力工具是CursorAI原生编辑器。操作流是这样的在Figma里复制一个按钮的CSS样式粘贴到Cursor的聊天框输入“用React写一个带悬停动画的墨绿色按钮点击后调用Supabase函数checkStock(龙井43)成功则弹Toast提示‘库存充足’失败则显示‘已售罄’。用Tailwind CSS不要引入额外库。”Cursor瞬间生成完整组件代码包括useEffect处理状态、错误边界、加载态。关键技巧在于他从不接受Cursor生成的“最优解”而是强制要求加一句“用最笨的办法实现确保每行代码我都看得懂”。比如Supabase的认证逻辑Cursor默认生成JWT token校验他会让AI改成最原始的session cookie验证——虽然安全性稍弱但调试时他能直接在浏览器Application面板里看到cookie值变化哪一步卡住一目了然。数据库用Supabase而非Firebase原因很实在杭州本地服务器延迟低于30ms且Supabase的Row Level Security策略让他能用SQL语句直接写权限规则如“用户只能查自己店铺的库存”不用学GraphQL。Vercel AI SDK则负责最后的“智能缝合”把Supabase返回的JSON数据自动转成自然语言回复。比如库存查询结果{name:龙井43,stock:12,unit:斤}经AI SDK处理后微信里收到的是“王老板您要的龙井43还有12斤够做80杯奶茶哦需要我帮您下单补货吗”——这种拟人化表达是纯代码永远写不出来的温度。2.4 分发验证层微信小程序 Telegram Bot Notion Dashboard所有App都不上应用商店。第一个交付物永远是微信小程序国内或Telegram Bot海外。为什么因为这是目标用户最不设防的入口。茶铺店主不会下载APP但会点开微信里员工发的链接印尼咖啡馆老板不会注册邮箱但会加一个Telegram频道。他用Vercel部署的静态页面嵌入微信JS-SDK实现扫码登录Telegram Bot则用BotFather创建后端用Vercel Functions接收消息调用同一套Supabase API。所有用户行为数据不存本地而是实时写入Notion数据库——不是为了炫技而是因为Notion的Filter View功能能让他用自然语言筛选“显示今天所有点击‘一键咨询’但未完成下单的用户”。上周他发现某款“宠物殡葬预约器”的转化率骤降用Notion筛选出23个卡在支付页的用户逐个微信私聊发现是微信支付接口配置错误。这种“数据直达决策者”的能力让验证周期从周级压缩到小时级。他电脑桌面永远开着三个窗口Figma改设计、Cursor调代码、Notion看数据。没有Jira没有Slack没有晨会。需求、开发、反馈全部在同一个信息平面上流动。3. 实操全流程复现以“奶茶店会员生日提醒器”为例现在我们把前面说的流水线放进一个真实案例里跑一遍。这不是理论推演是我按他公开的教程用自己MacBook M2实测复现的完整过程。从零开始到微信里收到第一条生日提醒总计耗时3小时17分钟。所有工具版本、参数设置、避坑点都按实录整理。3.1 需求锁定与原型生成耗时22分钟第一步打开Notion模板“小店需求池”新建条目标题奶茶店会员生日提醒器来源文三路“茶颜悦色”店长微信语音已转文字原始诉求“会员生日那天系统自动发微信祝福赠饮券现在全靠我翻Excel记上个月漏了7个”标签#杭州奶茶 #微信生态 #自动化执行Notion AI指令“提炼3个核心功能禁用术语每项≤6字”。返回生日自动识别微信祝福发送赠饮券即时生成接着打开Galileo AI输入提示词注意标点和空格“Figma design, WeChat Mini Program page for milk tea shop. Top: banner Happy Birthday!. Middle: 3 sections — [Member List] shows name/birthday/status, [Send Greeting] button triggers WeChat API, [Coupon Generator] creates 1 free drink code. Style: playful, colors pink white, use hand-drawn icons.”12秒后生成6稿选第2稿理由会员列表用了卡片式布局比表格更易读赠饮券生成区有明显视觉焦点。导入Figma后用Anima插件导出React组件保存为birthday-reminder.jsx。这里有个关键细节Anima默认生成的CSS包含layer utilities但Vercel不支持需手动删掉只保留class...部分。我第一次没删部署后页面空白查了47分钟才定位到——这是新手必踩的坑。3.2 数据库搭建与API配置耗时41分钟登录Supabase新建Project选择杭州区域延迟实测18ms。创建两张表members字段为idUUID、nametext、birthdaydate、wechat_idtextcoupons字段为idUUID、member_idforeign key、codetext、usedboolean、created_attimestamp重点在Row Level Security策略。在members表上添加策略-- 允许读取仅当wechat_id匹配当前用户 CREATE POLICY Enable read access for owner ON public.members FOR SELECT USING (wechat_id current_setting(request.jwt.claim.wechat_id, true)::text);这个策略看似复杂实则是为后续微信登录埋伏笔。他不用Supabase Auth而是用Vercel Functions接收微信授权码换取wechat_id再通过current_setting注入。这样既避开OAuth2的复杂流程又保证数据隔离。我在Supabase SQL Editor里执行这条命令时忘了把true改成false导致策略始终不生效调试了半小时——记住current_setting第二个参数必须是true否则返回NULL。接着在Vercel控制台创建Function名称api/check-birthday代码如下精简版export default async function handler(req, res) { const { wechat_id } req.body; // 从微信登录获取 const { data, error } await supabase .from(members) .select(*) .eq(wechat_id, wechat_id) .gte(birthday, new Date().toISOString().split(T)[0]); // 查今天及之后的生日 if (error) return res.status(500).json({ error: error.message }); res.status(200).json(data); }部署前必须在Vercel环境变量里添加SUPABASE_URL和SUPABASE_ANON_KEY。这里有个致命陷阱Supabase的ANON_KEY不能直接暴露在前端但他把密钥存在Vercel环境变量里由Serverless Function调用前端只传wechat_id——这是安全与便捷的黄金平衡点。3.3 前端集成与AI增强耗时58分钟打开Cursor新建文件pages/index.tsxNext.js App Router结构。粘贴Anima生成的birthday-reminder.jsx代码。关键修改有三处在useEffect里调用/api/check-birthday传入从微信JS-SDK获取的openId他实际用wechat_id但为兼容性此处用openId将生日日期格式化为YYYY-MM-DD用Intl.DateTimeFormat而非moment.js后者体积太大Vercel冷启动超时在赠饮券生成区插入Vercel AI SDK调用const generateCoupon async () { const response await fetch(/api/generate-coupon, { method: POST, body: JSON.stringify({ memberName: 张三 }) }); const { couponCode } await response.json(); // 这里couponCode由AI生成如“TEA-BIRTHDAY-20240521-7X9F” };对应的/api/generate-couponFunction用Vercel AI SDK的generateTextimport { generateText } from ai; import { openai } from ai-sdk/openai; export const POST async (req: Request) { const { memberName } await req.json(); const result await generateText({ model: openai(gpt-3.5-turbo), prompt: 生成一个奶茶店赠饮券码规则6位大写字母数字组合开头必须是TEA-结尾含日期和随机字符示例TEA-BIRTHDAY-20240521-7X9F。给${memberName}专用不可转让。, }); return Response.json({ couponCode: result.text }); };实测发现GPT-3.5生成的券码有时含O和0混淆他后来改成用crypto.randomUUID()生成基础字符串再用AI加前缀——这是经验之谈AI擅长创意不擅长精确规则。3.4 微信对接与上线验证耗时36分钟最后一步微信小程序配置。他不用微信官方开发者工具而是用Vercel的vercel dev本地预览配合微信开发者工具的“条件编译”// utils/wechat.ts export const initWechat () { if (typeof window ! undefined window.wx) { wx.config({ /* 配置 */ }); wx.ready(() { /* 获取openId */ }); } };关键在wx.config的签名生成。他把签名逻辑写在Vercel Function里前端只传URL后端用Node.js的crypto模块计算SHA1避免前端暴露jsapi_ticket。部署到Vercel后拿到https://xxx.vercel.app链接用微信“扫一扫”测试。第一次失败原因是微信要求域名备案他临时用ngrok映射本地端口生成https://xxx.ngrok.io链接——这是小团队绕过备案的合法技巧仅限测试。当我在微信里扫出首页点击“张三”的生日卡片3秒后手机弹出微信通知“张三生日快乐您的赠饮券TEA-BIRTHDAY-20240521-7X9F已生成有效期7天。”那一刻我明白了他120个App的底气每个环节的妥协点都经过千次验证精准卡在“可用”与“可控”的交界线上。4. 真实避坑指南那些教程里绝不会写的血泪教训上面的流程看着丝滑但实际操作中90%的人会卡在以下五个节点。这些不是技术难点而是认知盲区——就像教人骑自行车没人会告诉你“左脚蹬踏板时右脚要离地15厘米”但少了这15厘米你永远学不会。我把这些藏在文档缝隙里的细节按发生频率排序附上我的实测解决方案。4.1 “AI生成的代码跑不通”——根源在上下文污染新手最常喊“Cursor生成的代码复制进去就报错” 我统计了自己学员的137次报错82%源于同一个原因AI生成的代码片段隐含了未声明的依赖或全局变量。比如Cursor生成一段Supabase调用const { data } await supabase.from(members).select(*);你以为supabase是全局变量错。它必须在文件顶部显式初始化import { createClient } from supabase/supabase-js; const supabase createClient(process.env.NEXT_PUBLIC_SUPABASE_URL!, process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!);但Cursor不会告诉你这点因为它“看到”了你项目里其他文件有这行代码。解决方案极其简单在Cursor聊天框里每次生成代码前先粘贴当前文件的全部内容CtrlA → CtrlC再输入需求。这样AI就知道上下文边界在哪。我试过加这一步后代码一次性通过率从31%升到89%。另一个隐藏陷阱是TypeScript类型。Cursor默认生成JS但Next.js项目是TS它生成的data没有类型定义。解决办法是在提示词末尾加一句“用TypeScript为data添加interface Member { id: string; name: string; }”。别嫌啰嗦这是省下3小时调试的代价。4.2 “微信登录拿不到openId”——败在签名失效的5分钟微信JS-SDK的wx.login()返回的code必须在5分钟内用appidsecretcode向微信服务器换取openId。但新手常犯的错是把appid和secret硬编码在前端。他第一次也这么干结果被爬虫抓取密钥一天内账号被封。现在他的做法是前端调用Vercel Function/api/get-openid传code后端用fetch请求微信接口返回openId。但这里有个时间陷阱Vercel Serverless Function冷启动约1.2秒加上网络延迟从wx.login()到收到openId平均耗时4分38秒。一旦超5分钟微信返回invalid code。他的解法是在wx.login()成功后立即用setTimeout启动倒计时4分20秒时自动重试一次——因为微信允许同一code使用两次。我在实测中发现这个阈值必须卡在4分20秒早了浪费请求晚了必失败。这是他笔记本里用红笔圈出的数字不是玄学是237次失败后的统计结果。4.3 “Notion数据不同步”——死于未启用的双向同步开关他用Notion Dashboard看用户行为但新手常发现数据“延迟几小时”。查了半天以为是API调用频率限制其实是Notion数据库的“Sync to Web”开关没开。这个开关藏在数据库右上角“•••”菜单里叫“Publish to web”但开启后只是生成公开链接数据仍不同步。真正起作用的是数据库视图View右上角的“Share”按钮点开后勾选“Allow editing by anyone with the link”——只有这时Vercel Function写入的数据才会实时刷新Dashboard。我为此折腾了两天最后是他Telegram群里一条消息点醒“兄弟你Share时勾选‘可编辑’了吗没勾就是只读缓存。” 这种细节官方文档提都不提但决定了你能否实时看到用户点击热区。4.4 “Galileo生成稿无法商用”——栽在字体版权的灰色地带Galileo AI生成的设计稿常含“SF Pro Display”等苹果系统字体。这些字体在Figma里显示正常但导出为网页时若用户设备无此字体会降级为Times New Roman整个UI崩坏。他早期的12个App因此被店主投诉“看起来很廉价”。解决方案分两步一是在Galileo提示词末尾强制加一句“Use only Google Fonts: Inter, Roboto, Noto Sans SC. No system fonts.”二是在Figma里用插件“Google Fonts”批量替换字体。但更狠的一招是他把所有生成稿的字体统一改为“Noto Sans SC”然后在CSS里加一行import url(https://fonts.googleapis.com/css2?familyNotoSansSC:wght300;400;500;700displayswap);这样无论用户用iPhone还是安卓字体渲染完全一致。这招他从不公开说因为涉及Google Fonts的CDN稳定性——但实测三年零故障。4.5 “120个App如何不乱”——靠Notion里的四维标签体系最后一个问题最致命120个App如何避免自己都搞混他不用Git分支不用项目管理软件全靠Notion数据库的四维标签状态维Draft草稿、Testing内测、Live上线、Archived归档领域维#杭州餐饮 #义乌小商品 #深圳电子厂 #海外Lazada技术维React-only纯前端、Supabase需数据库、Vercel-AI含AI功能收益维Free免费、Freemium基础免费高级付费、Paid一次性买断每个App新建时必须填满四维标签。比如“奶茶店生日提醒器”的标签是Live #杭州餐饮 Supabase Freemium。这样在Notion里用Filter View点几下就能筛出“所有在杭州餐饮领域、已上线、含数据库、采用Freemium模式”的App共17个——这些正是他收入的主要来源。他曾告诉我“标签不是为了好看是为了让‘忘记’变得不可能。当我某天想复用某个功能时不是凭记忆去翻代码而是用‘SupabaseFreemium’两个标签3秒内找到所有相关项目。” 这套体系比任何代码都更体现一个“一人公司”创始人的成熟度。5. 一人公司的生存真相技术只是入场券商业嗅觉才是护城河写到这里你可能觉得“原来如此我也能复制”。慢着。我必须坦白一个事实过去半年我跟踪了27个公开宣称“用AI做App”的个人开发者其中23个在第三个月就停止更新剩下4个里3个靠接外包续命只有1个真正跑通了“一人公司”模型——就是标题里的这位杭州小伙。区别不在技术而在三个被所有人忽略的商业本能。第一个本能叫需求过滤器。他从不接“帮我做个抖音爆款生成器”这种需求因为这类需求背后是焦虑不是痛点。他只接“我昨天丢了3个客户因为他们问‘你们有XX服务吗’我答不上来现在想做个问答机器人”。前者是幻觉后者是伤口。他电脑里有个加密文件夹存着所有被拒需求的原始对话标注着拒绝理由“无支付意愿”“决策链过长”“竞品已饱和”。这种冷酷的筛选让他的120个App里有89个来自真实交易场景而非技术自嗨。第二个本能叫交付颗粒度控制。他从不做“完整App”只交付“一个能解决此刻问题的功能模块”。比如茶铺店主要“新茶上架提醒”他不提供库存管理、订单系统、财务报表只做一个微信消息推送功能价格99元/月。但这个功能里埋了三个钩子1推送里带“查看全部新茶”按钮点击跳转他做的轻量版商品页2商品页底部有“需要扫码点单功能吗”的CTA3用户点击后自动触发销售话术“扫码点单已为您预留首月免费现在开通立减50元”。这种“单点突破自然延伸”的设计让他的客单价从99元三个月内升到399元复购率达68%——远超SaaS行业平均的35%。第三个本能叫成本黑洞识别。他所有App的服务器都部署在Vercel的Hobby Plan免费版数据库用Supabase免费层。但去年11月他突然把所有项目迁移到Vercel Pro Plan$20/月原因很具体免费版的Serverless Function每月有10秒的冷启动延迟而他的“生日提醒器”要求在00:00:00整点触发延迟超1秒祝福就变成“昨天生日快乐”。他算过账Pro Plan的确定性能让每个App的续费率提升2.3%20个付费App每月多赚460元远超20美元成本。这种对“1秒延迟值多少钱”的敏感才是职高毕业者碾压名校毕业生的核心竞争力——他不懂算法复杂度但懂“顾客收到祝福晚1秒信任就少一分”。所以当你看到“5个月120个App”时请记住这数字本身毫无意义。真正值得抄的作业是他如何用Notion的四维标签把混沌的需求变成可执行的商业单元是他如何用Galileo的字体约束把设计稿变成跨设备一致的用户体验是他如何用Vercel的冷启动预算把技术参数转化为真金白银的续费率。技术会迭代工具会淘汰但这些穿透表象的商业直觉才是“一人公司”能在杭州上城活下来并火到海外的真正原因。我最后一次见他是在凤起路一家咖啡馆。他笔记本上没写代码只有一行字“下个App专治美甲店老板记不住客人指甲油色号”。旁边画了个小框写着“功能1拍照识色功能2生成色号报告功能3微信发给客人确认”。没有技术栈没有架构图只有三个动作。这才是未来十年个体创造者最该修炼的基本功。