先说结论这不是标题党是我这两个月真实发生的事——App 从想法到上架代码仓库里躺着 9 万行代码我确实一行都没逐字读过。传统的编程经验告诉我不读代码就是埋雷但这次我是刻意不看。我用的是 vibe coding 的路子把自己当成需求方、测试方和验收方把 AI 当成结对编程里那个真正敲键盘的人。这篇博文不是劝你抛弃代码功底也不是让你无脑拥抱用嘴写代码而是把我这两个月怎么从零把一个 App 撸到能上架的真实过程、踩过的坑、总结出的工作流全部摊开讲清楚。如果你正站在要不要试试 vibe coding的十字路口或者已经在用 AI 写代码但总被各种翻车整到怀疑人生又或者你是个传统程序员想搞清楚这种新玩法究竟是趋势还是泡沫——这篇文章应该能给你一份比较靠谱的参考。我会尽量把话说得实在一点毕竟9 万行代码一行都没看过这种事听起来像段子做起来是真要命的。1. 先交代清楚什么叫 vibe coding它真不是什么玄学1.1 一个词掀起的热潮以及它的真实定义vibe coding 这个说法能火很大程度上是因为 Andrej Karpathy 在社交平台上提了一嘴。他描述的那种状态非常形象你完全沉浸在氛围里不再像一个严谨的工程师那样逐行审视代码而是顺着感觉走——敲一段描述、看 AI 输出、跑一下、有问题再把报错贴回去循环往复。用大白话说就是你负责 vibeAI 负责 coding。但衍生到现在这个词已经被用滥了。有人在公司里用 AI 写了个脚本就号称 vibe coding也有人把 vibe coding 等同于完全不看代码、什么都不懂也能做软件。这两种方向都偏了。我自己的理解是vibe coding 不是放弃思考而是把思考的重心从这段代码怎么写转移到这个软件应该是什么样、怎么验证它没跑偏。它针对的是那些我怎么实现不重要能跑、能交付、用户愿意用的场景。对于我个人而言这次两个月做 App 的体验就是一次把这种理解落到实处的实验。1.2 它和传统编程思维的本质差异从抄写员到架构师传统开发里代码是核心资产每一行都需要被理解和掌控。尤其在我们这些老程序员的职业习惯里看不懂的代码就不该进代码库几乎是铁律。但在 vibe coding 的模式下这个铁律被打破了。我自己画了一个对照方便理解维度传统编程vibe coding核心产物代码本身可运行的软件行为开发者角色代码的作者需求的翻译官、验收者对代码的态度每行都要理解与控制只关注行为是否符合预期错误处理方式读代码、断点、逐步定位观察现象、贴报错、让 AI 修质量保障手段代码评审、静态检查频繁运行、联调、用户反馈说白了vibe coding 把写代码这个行为从核心位置移开了取而代之的是定义行为和验证行为。你不再是那个趴在桌子上逐字翻译需求的人而是站在高处看全局的人这个功能逻辑是否成立、数据流是否通畅、用户体验是否顺滑。听起来很爽对吧但后面会讲到这种爽是有代价的——当 AI 生成的代码在某个深夜开始抽风的时候你连从哪里下手查都不知道。1.3 为什么偏偏是现在能玩起来工具链的三次迭代五年前你让我搞 vibe coding我肯定觉得是天方夜谭。但这两年工具链的成熟度确实发生了质变我自己主要感知到三层变化第一层是通用大模型的能力暴涨。现在的模型不光是能写点代码而是在理解上下文、实现复杂逻辑方面有了长足进步尤其面对做一个登录页写一个打卡功能这种泛需求时给出的代码质量相当能打。第二层是交互形态的革命。从最早的复制报错去谷歌到后来 Copilot 在编辑器里的行内补全再到 Cursor 这类工具把整个项目作为上下文吃进去你可以在对话里让 AI 跨文件改代码。这个项目级上下文特别关键等于 AI 不再是一个只能写单文件的打字员而是能理解整个项目结构的人。第三层是生态的填充。Expo、Firebase、Supabase 这类服务把登录、数据库、推送、存储这些基础设施全包了用 vibe coding 做 App 的人根本不需要自己去搭建那些硬核后端。我这次做的 App 就大量依赖这类服务帮我省掉了至少一半的工作量。2. 两个月复盘从试试看走到真上线了的全过程记录2.1 第一周需求定义和冷启动原来最难的是说清楚要什么我这次做的 App 定位很简单一个面向个人用户的记账 月度预算分析工具。老实说这种 App 在市面上已经多如牛毛但我的目标不是做爆款而是用它作为 vibe coding 的完整试验田。正因为功能边界足够清晰——记录收支、按月统计、做预算对比——它非常适合用来验证 AI 编程的效果。第一周我几乎没有让 AI 写任何代码就在做两件事一是把需求用自然语言完全写清楚包括用户故事、页面流转、关键数据字段二是选定技术栈。我最终选了 React Native Expo TypeScript理由有三条Expo 对新手和 AI 都非常友好依赖都封装好了不需要折腾原生工程TypeScript 的类型检查能在编译期拦掉大量 AI 生成代码的低级错误React Native 的生态够大AI 训练语料充足写出来的代码质量普遍在线。这一周最大的体会是vibe coding 虽然嘴上说不用懂代码但需求拆解能力反而变得更加重要。你不把用户点这个按钮后应该发生什么想清楚AI 就只能瞎猜。这就像你叫了个代驾但自己不说清楚要去哪那车技再好也没用。2.2 第一到第四周核心功能开发我每天都在调教AI从第二周开始我进入了真正的对话式开发阶段。我的基本工作模式是这样的新建一个 Cursor 的 Composer 会话把自己的需求描述粘贴进去然后看着它像变魔术一样生成一堆文件。举个具体例子。第三周我要做月度预算对比功能我给的提示词大概是这样的我需要一个函数输入是当月每一笔收支记录数组和预算设置对象 输出一个汇总对象包含当月总支出、总收入、结余、预算使用百分比、 以及按照一级分类拆分的对比列表每类预算值、实际值、超出状态。 请用 TypeScript 实现并导出类型定义。 不要使用任何第三方库。结果不到一分钟AI 给我生成了一段 80 多行的代码带两个类型接口、一个主函数、三个边界情况的处理。我没细读直接扔进项目里跑了一个测试用例输入、输出完全符合预期。那一瞬间我确实有种科技改变生活的爽感。但爽完之后很快就迎来了第一个大型翻车现场——后面专门写一节讲。整体来说第一个月结束时App 的核心功能已经全部能跑通了记一笔账、编辑、删除、按月份查看统计、预算对比、设置预算。因为 Expo 的 Expo Go 可以直接在手机上扫码预览我每隔几小时就能在真机上摸一遍那种今天写的东西晚上就能用的反馈感特别上瘾。2.3 第二个月打磨体验、处理边界、提交商店如果说第一个月是把功能做出来第二个月就是把它变成人样。这个阶段我做的事可以列一个表看阶段主要工作vibe coding 参与度第5-6周界面美化、动效补充、空状态设计高大量对话式调整第7周数据校验、错误处理、异常边界中需要我来定义边界逻辑第8周应用商店打包、测试、审核材料低这块 AI 帮不上太多忙界面美化方面vibe coding 的效果出乎意料地好。我只要说这个页面太空了加一个统计卡片圆角大一点背景用浅灰色AI 就能直接改出让我满意的效果。因为 UI 调整的结果是肉眼可见的所以就算不读代码我也能准确判断改对了没有。数据校验和异常处理则相对痛苦一些。比如用户输入负数金额、删除已经被统计的月份的数据、日期的时区问题——这些边界场景如果没有程序员的直觉很难提前想到。我采取的策略是让 AI 替我头脑风暴我直接问它这个记账 App 在真实使用场景下可能会遇到哪些异常情况请列出清单并给出对应的处理方案。这个思路帮了大忙AI 列出的 20 多条边界场景中至少有三分之一是我这个非专业产品经理完全没想到的。3. 9 万行代码的来源拆解AI 生成代码的真实构成3.1 数字是怎么来的仓库里的代码堆积路径你可能好奇一个记账 App 而已怎么会攒出 9 万行代码这确实是 vibe coding 项目一个非常有意思的现象。我从 git 仓库的统计信息里大致拆了一下发现这 9 万行主要由四部分构成大概有三成来自 Expo 脚手架和第三方依赖的配置文件、原生模块的声明文件两成左右是重复生成的产物——AI 经常在一个新会话里重写一遍已有的逻辑导致出现多个功能类似的组件文件三成是业务代码包括页面、组件、状态管理、工具函数这是真正的核心剩下两成是测试文件、模拟数据、类型声明和其他零散内容。换句话说9 万行里有不少水分。如果是一个传统程序员来写这个 App可能最终就两万行左右的代码而且更干净。但 vibe coding 模式下AI 生成的代码本来就习惯多写、写全,尤其是只要你不在提示词里写请尽量精简它就会生成很多防御性代码和冗余分支。所以看到 9 万行这个数字我一点都不意外。3.2 不读代码的底气行为验证与不可见边界的博弈不读代码还能把项目做完靠的不是玄学而是三层保障第一层是类型系统。TypeScript 编译这一步能拦住至少三成的基础错误。变量名拼错、参数传错、返回值类型不匹配基本都会在编译时暴露。我每次让 AI 改完代码做的第一件事永远是跑一次 TypeScript 检查。第二层是可运行验证。Expo 的即时预览让我能在真机上持续操作把主要流程全部点一遍。对记账这种数据密集型 App我可以用造数据的方式反复验证统计逻辑是否准确。这里的核心逻辑是与其读代码去推断它应该是对的不如直接验证它确实是符合预期的。第三层是测试兜底。我给核心的统计逻辑写了一套单元测试每次 AI 改动后跑一遍测试通过的才敢合并。虽然我读不懂每一行代码但测试告诉我这些代码的行为没有跑偏。这就好比你不懂厨师的每道工序但米其林评委替你尝过了你信这个结果。3.3 为什么不看代码反而节省了巨大的心智负担作为一个有过传统编程背景的人我深知代码阅读时间在总开发时长里的占比很高。看代码不仅是看这行在干什么还要在脑子里构建整个调用链和数据流。当你面对几万行代码时这个心智负担是巨大的。vibe coding 把我的角色转变了我不需要关心函数内部是怎么循环的、组件是怎么渲染的我只需要关心这个模块输入什么、输出什么、在界面上表现成什么。这其实很像从信源级别审计变成行为级别验收。听上去很粗暴但对于功能边界清晰的中小型项目行为验收是够用的。当然不看代码不等于不知道代码存在。我在关键节点还是会瞄一眼比如某个功能反复出 bug或者 AI 改了半天都改不对这时候我就会打开代码文件扫一眼看看问题到底出在哪一层。这种平时不看、出了问题才看的模式反而让我在着手排查时目的更明确。提示如果你完全没有代码基础、也不打算学一点点语法直接开始 vibe coding 做复杂 App大概率会在问题定位这个环节彻底卡死。这也是我后面要反复强调的边界。4. 一行都不看的代价我踩过的大坑和最狼狈的两次排查4.1 幻觉代码大赏AI 一本正经地给我编 API第一个让我印象极其深刻的翻车发生在第四周做数据导出功能的时候。我需要把统计数据导出成 CSV 文件在 React Native 里实现这个功能一般要调用一个分享库。我把需求发给 AI它在代码里郑重其事地引用了一个名为react-native-csv-export的包还写好了安装命令看起来像模像样。我按照提示安装了以后编译直接报错——这个包根本不存在。这就是圈内人常说的 AI 幻觉AI 根据语料中的模式猜测了一个看起来合理的包名但它并没有真的去验证这个包是否存在。这种错误在 vibe coding 里特别坑人因为你不读代码、不熟悉生态就很容易被 AI 的自信骗过去。我的解决方案是在提示词里增加一条硬性约束——所有第三方库必须写清楚用途和安装方式并提示我先去 npm 官网或 GitHub 验证包是否存在。同时我养成了一个习惯每次 AI 说要引入新依赖我先花 30 秒钟去搜一下这个包名确认它真实存在且维护活跃再继续灌入项目。4.2 死循环与内存暴涨无代码认知排障的至暗时刻第二个大坑发生在第 6 周App 在测试时突然卡死。现象是用户连续快速点击添加账目按钮时App 会逐渐变得非常卡顿最后直接假死。我把这个现象描述给 AI它推断可能是大量事件堆叠导致的内存问题然后给我改了几处代码。改完之后问题反而变得更容易触发了。那个晚上我体验到了 vibe coding 最痛苦的一面我连问题出在哪个文件、哪个组件都不知道只能一遍遍把现象描述给 AIAI 则像无头苍蝇一样到处改一通每次改完我都得在真机上重新测如此反复了五六轮。最后我实在没办法了打开了那个平时不看的代码。虽然我仍然是快速扫视但我注意到问题组件里有一段用useEffect无限循环更新 state 的逻辑——每次渲染都会触发一个新的 state 更新又导致重新渲染形成了一个死循环。而连续点击按钮时React Native 的异步渲染特性让这个循环被放大最终假死。这给我上了宝贵的一课vibe coding 不是出了事全靠 AI你需要至少掌握最基础的代码阅读能力用来做关键节点的人工介入。尤其是在性能、并发、状态管理这类问题上AI 往往很难通过现象描述直接命中根因。4.3 依赖升级的连锁反应一个版本号引发的连续炸弹还有一个很常见的坑我放在了表格里因为它非常典型问题类型现象排查难度vibe coding 应对方式AI 幻觉包编译报模块不存在中装包前人工验证包名状态死循环运行时卡顿直至假死高提高基础代码阅读能力人工介入依赖版本冲突升级后一堆接口报错高尽量锁定版本能不升就不升行为漂移更新后旧功能失效中建立回归测试清单依赖版本冲突是我最后一个月的常客。某次 AI 建议我升级一个导航库的版本以解决某个 UI 问题升级之后虽然那个问题解决了但导致另外三个页面出现了新的布局错乱。因为 AI 读不了全部代码项目大了之后模型上下文也有限它只能给出面向局部的解决方案却看不到全局的连锁反应。后来我学乖了命令 AI 以后的每次修改都遵循一个原则只动需要改的地方不要顺手动其他无关代码升级依赖之前必须先在本地开分支测试所有主要流程通过后再合并。同时我养成了一个习惯——每天早上先花十分钟把昨天的改动跑一遍主要流程确保昨天没给自己埋雷。5. 什么项目适合 vibe coding什么项目我劝你千万别碰5.1 适合项目画像边界清晰、行为可见、容错率高两个月的实战让我对 vibe coding 的适配边界有了比较清晰的感知。最适合它的项目一般具备三个特征功能边界清晰、行为可通过界面验证、出错后的损失在可接受范围。我做记账 App 就非常典型每一笔账、每一个统计数字都能在界面上立刻验证对不对。就算某个功能出了问题损失顶多是数据重复或统计不准修复成本低。类似的项目还包括个人工具类 App随手记、打卡、习惯养成、内容展示类RSS 阅读器、博客客户端、简单的 CRUD 管理端、原型验证 Demo、内部效率工具以及各类我给自己用的小软件。这类项目的共同点是把正确性溶解在可验证性里。你不需要读代码来推测它的正确性直接操作界面、看输出结果就够了。AI 即使写得很糟糕只要行为是对的你就不亏行为不对你也能马上发现并回头让它改。5.2 不适合项目画像安全敏感、高并发、强一致性反过来有几类项目我强烈不建议纯 vibe coding 冒着风险去做。首当其冲的是涉及支付、金融账户、身份认证等安全敏感的业务。这类场景下代码的每一个细节都值得推敲安全漏洞不是多跑几遍测试就能发现的你需要逐行审计确保没有越权逻辑、没有敏感信息泄露。其次是高并发、强一致性的服务端系统。vibe coding 生成的代码在单机、低负载下表现良好但一旦面对大规模并发请求锁机制、缓存策略、数据一致性这些硬骨头就会暴露出来。AI 很难在缺乏真实压测数据的情况下设计出可靠的架构。再有就是长期维护的复杂业务系统。vibe coding 模式下产出的代码可读性普遍一般且由于 AI 经常重复造轮子项目中会出现大量功能趋同、实现各异的代码碎片。一旦这个项目要持续迭代六个月以上维护成本会呈指数上升。5.3 我自己的决策清单动手之前先过这三关经过这次实践我给自己总结了一个三关决策法每次想用 vibe coding 做新项目之前先过一遍错误容忍度关这个项目如果出错最坏后果是什么我能不能接受行为验证关它的核心功能我能否通过界面或测试用例快速判断是否正确维护期限关我只用三个月还是要长期维护如果是长期我是否愿意中途补读代码或重构三个问题里只要有任何一个答案不理想我就会把项目往传统开发或者混合模式挪。这不是说 vibe coding 不行而是要用对地方、用对程度。很多人翻车不是因为 AI 太弱而是因为用错了场景还非要死磕。6. 沉淀下来的工作流我的 AI 辅助开发工具箱与个人操作心得6.1 工具组合选型不追求最强追求闭环如果你也想试试 vibe coding工具选型不需要太复杂关键是形成编辑—运行—反馈—修复的闭环。我这两个月的组合非常简单编辑器用的是 Cursor它的优势是能把整个项目目录作为上下文交给模型AI 跨文件改代码的能力比纯对话强很多语言框架选了 React Native Expo TypeScript理由前面说过类型检查兜底 真机预览即时反馈后端全部用 BaaS后端即服务登录用 Firebase Authentication数据存 Firestore统计逻辑在客户端本地执行版本控制用 Git不过我掌握的命令只有三招git add .、git commit -m xxx、git reset --hard 版本号。前两个是存检查点第三个是回滚救命用的。为什么强调闭环因为 vibe coding 的效率提升很大程度来源于每次修改都能立刻看到效果。如果一套工具链能让你在 30 秒内从AI 改完代码到在真机上看到新效果你就获得了极快的反馈循环这比用任何一个单一工具都重要。6.2 需求喂给 AI 的技巧场景化描述比术语堆砌有用十倍很多人在 vibe coding 里卡住不是 AI 不行而是需求说不清。我总结了一个场景化描述模板效果很不错分享给大家我要在[某个页面/某个流程]实现[某个功能]。 用户会先看到[什么]然后点击[什么]期望出现[什么结果]。 输入的数据长这样[示例数据]。 输出的结果应该是[预期输出]。 请用[技术栈]实现并且[约束条件]。这个模板的精髓在于给足上下文、给示例数据、给预期行为。AI 不需要猜你在想什么它只需要把行为翻译成代码。相比之下像帮我写个登录功能这种一句话需求AI 是写不出你心里的那个登录功能的——字段校验规则、登录后跳转到哪、错误提示怎么显示全是未知数。另外我发现让 AI 先列方案再动手非常有用。每次涉及复杂功能时我先让它给出两到三种实现方案并简述各自的优劣我选定方案后再让它写代码。这个习惯避免了大量返工因为很多时候 AI 上来就写的方案并不是最优的。6.3 验证与回滚的节奏白天疯狂写晚上疯狂试因为不读代码我的验证策略必须依赖高频行为测试。我把这个节奏总结成了每天的固定流程每次 AI 完成一个功能点的修改后我立刻在真机上走一遍与该功能相关的用户路径每攒三到五个提交就完整走一遍记一笔账→查看统计→设置预算→查看对比这四条核心链路每周末把本周所有的新功能汇总成一份清单逐条过一遍发现行为漂移就立刻回滚到最近的正常版本并让 AI 重新分析问题。这套流程听上去很简单但它是我踩过改 A 坏 B的坑之后总结出来的。vibe coding 最大的风险就是渐进式腐化——每次改动看着都没问题但积累两周后整个 App 的行为开始整体偏离预期。高频回归测试是唯一能拦住这种腐化的手段。6.4 几个可能只有实操过才懂的小招数分享几个比较零碎但很实用的小技巧都是这两个月里切身验证过的会话隔离每做一个新功能就开一个全新的 AI 会话不要让上一个功能的上下文污染当前工作。否则 AI 经常会顺手把别的功能的代码也改了。代码文件尽量拆小在提示词里明确要求单个文件不超过 200 行这样每个文件行为单一AI 修改时定位更精准我偶尔扫一眼代码时也能快速看懂。让 AI 写文档每完成一个模块就命令 AI 用自然语言写一份模块说明文档记录输入、输出、关键逻辑。这相当于给不看代码的我留了一套阅读索引。保存每一次成功提示词遇到那种一次就能跑到完美效果的提示词我会单独存起来。后续做类似功能时直接改几个关键词就能复用效率翻倍。注意如果你完全不懂代码至少要学会看编译器报错的第一行。这行字通常指明了哪个文件、哪一行出了问题。把这句话原样贴给 AI比你描述一百遍它不动了都管用。7. 两个月后的思考vibe coding 是未来但不是神话7.1 它解决了什么没有解决什么冷静下来复盘我承认 vibe coding 解决了一个非常真实的问题把从想法到可用软件的成本压到了极低。过去一个能上架的 App至少需要一个懂前端、懂后端、懂 UI 的人折腾几个月现在一个人只要会清晰表达需求、会做基本的验收测试就能在两个月里把一个完整产品推上线。这确实是生产力层面的真实跃迁而不是什么泡沫叙事。但另一方面它没有解决的恰恰是软件工程里最硬核的部分架构设计、性能调优、数据一致性、安全保障和长期维护。这些问题不会因为 AI 能生成代码就自动消失它们只是被推迟了——推迟到项目变大、用户变多、问题集中爆发的那一天。到那时候你砍掉的读代码时间会加倍变成排故障时间。我自己的态度是vibe coding 适合做从 0 到 1的探路者它让我用最低的试错成本验证一个产品想法是否成立。但如果这个想法真的被市场验证了、用户量上来了该引入正规军、该重构代码、该做技术沉淀就得老老实实补课。这不是两难选择而是不同阶段的合理配比。7.2 它对非技术人群意味着什么人人可造物但别指望人人可运营我最开始想过既然我都能一行不看做出 App那是不是意味着人人都是程序员的时代来了两个月的体验告诉我答案既对也不对。对的地方在于一个完全没有开发经验的人确实可以在 AI 的辅助下做出一个能用的工具不对的地方在于能做出和能做好、能持续运营之间横亘着一条用真实经验填平的河。非技术人群用 vibe coding 做 App最缺的从来不是写代码的手而是拆需求的大脑和定位问题的耐心。我对这类朋友的建议是从非常小的个人工具开始不要一上来就做社交平台、电商这种复杂系统。先做一个只给自己用的小工具在完整走完描述需求→生成代码→运行验证→修复问题的闭环之后你再来判断要不要继续深入。7.3 给想入坑的人的三条最实在的建议这次体验让我有了三条压箱底的感悟写在这里第一一定要学会抄底当你决定用 vibe coding 做项目时请保证你有最基础的语言语法能力——哪怕只是看懂 if 和 for。这不是为了让你替代 AI而是让你在 AI 抽风时具备拔电源的能力。你可以不写代码但你不能完全不懂代码在做什么否则出了问题你连判断该不该信 AI 解释的资格都没有。第二把 Git 当成你的第二条命每次功能能跑通立刻提交一个版本。我这两个月至少回滚过二十次以上如果没有这个习惯整个项目早就被 AI 改成一坨无法恢复的混沌了。第三保护你的场景感vibe coding 很容易让人陷入生成代码—跑通—下一个需求的机械循环慢慢丢失对产品整体的感知。我每周都会抽出完整的一小时以一个新用户视角从头到尾使用一遍 App不带任何任务目标单纯感受它的顺手与别扭。很多体验问题就是从这种无用时间里冒出来的。这两个月下来我最大的感受是vibe coding 不会让开发者的价值消失但它会改变开发者的价值所在。过去我们的价值在如何写未来我们的价值在写什么和怎么验。9 万行代码我一行都没看过但我全程都知道这个 App 正在往哪个方向走——这大概就是 vibe coding 最准确的写照你掌控的是方向和体验而不是语法和实现。最后再分享一个小细节就在我写这篇复盘的时候那个 App 后台收到了一条用户反馈说预算对比页的数字多算了 20 块。我打开代码扫了一眼确实发现有个工具函数在处理不计入统计的钱时少了一个过滤条件。我直接在对话里把问题描述给 AI它改完、我验证、修复整个过程不到十分钟。这一刻我觉得vibe coding 的存在不是为了让你变成超级程序员而是为了让你在真实世界里解决真实问题时又能多一种趁手的方式。