先说结论：这不是标题党，是我这两个月真实发生的事——App 从想法到上架，代码仓库里躺着 9 万行代码，我确实一行都没逐字读过。传统的编程经验告诉我"不读代码就是埋雷"，但这次我是刻意不看。我用的是 vibe coding 的路子：把自己当成需求方、测试方和验收方，把 AI 当成结对编程里那个真正敲键盘的人。这篇博文不是劝你抛弃代码功底，也不是让你无脑拥抱"用嘴写代码"，而是把我这两个月怎么从零把一个 App 撸到能上架的真实过程、踩过的坑、总结出的工作流，全部摊开讲清楚。

如果你正站在"要不要试试 vibe coding"的十字路口，或者已经在用 AI 写代码但总被各种翻车整到怀疑人生，又或者你是个传统程序员，想搞清楚这种新玩法究竟是趋势还是泡沫——这篇文章应该能给你一份比较靠谱的参考。我会尽量把话说得实在一点，毕竟"9 万行代码一行都没看过"这种事，听起来像段子，做起来是真要命的。

1. 先交代清楚：什么叫 vibe coding，它真不是什么玄学

1.1 一个词掀起的热潮，以及它的真实定义

vibe coding 这个说法能火，很大程度上是因为 Andrej Karpathy 在社交平台上提了一嘴。他描述的那种状态非常形象：你完全沉浸在"氛围"里，不再像一个严谨的工程师那样逐行审视代码，而是顺着感觉走——敲一段描述、看 AI 输出、跑一下、有问题再把报错贴回去，循环往复。用大白话说，就是"你负责 vibe，AI 负责 coding"。

但衍生到现在，这个词已经被用滥了。有人在公司里用 AI 写了个脚本就号称 vibe coding，也有人把 vibe coding 等同于"完全不看代码、什么都不懂也能做软件"。这两种方向都偏了。我自己的理解是：vibe coding 不是放弃思考，而是把思考的重心从"这段代码怎么写"转移到"这个软件应该是什么样、怎么验证它没跑偏"。它针对的是那些"我怎么实现不重要，能跑、能交付、用户愿意用"的场景。对于我个人而言，这次两个月做 App 的体验，就是一次把这种理解落到实处的实验。

1.2 它和传统编程思维的本质差异：从抄写员到架构师

传统开发里，代码是核心资产，每一行都需要被理解和掌控。尤其在我们这些老程序员的职业习惯里，"看不懂的代码就不该进代码库"几乎是铁律。但在 vibe coding 的模式下，这个铁律被打破了。

我自己画了一个对照，方便理解：

说白了，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 的效果出乎意料地好。我只要说"这个页面太空了，加一个统计卡片，圆角大一点，背景用浅灰色"，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 最痛苦的一面：我连问题出在哪个文件、哪个组件都不知道，只能一遍遍把现象描述给 AI，AI 则像无头苍蝇一样到处改一通，每次改完我都得在真机上重新测，如此反复了五六轮。

最后我实在没办法了，打开了那个"平时不看的代码"。虽然我仍然是快速扫视，但我注意到问题组件里有一段用useEffect无限循环更新 state 的逻辑——每次渲染都会触发一个新的 state 更新，又导致重新渲染，形成了一个死循环。而连续点击按钮时，React Native 的异步渲染特性让这个循环被放大，最终假死。

这给我上了宝贵的一课：vibe coding 不是"出了事全靠 AI"，你需要至少掌握最基础的代码阅读能力，用来做"关键节点的人工介入"。尤其是在性能、并发、状态管理这类问题上，AI 往往很难通过现象描述直接命中根因。

4.3 依赖升级的连锁反应：一个版本号引发的连续炸弹

还有一个很常见的坑，我放在了表格里，因为它非常典型：

依赖版本冲突是我最后一个月的常客。某次 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 做新项目之前先过一遍：

1. 错误容忍度关：这个项目如果出错，最坏后果是什么？我能不能接受？
2. 行为验证关：它的核心功能，我能否通过界面或测试用例快速判断是否正确？
3. 维护期限关：我只用三个月还是要长期维护？如果是长期，我是否愿意中途补读代码或重构？

三个问题里，只要有任何一个答案不理想，我就会把项目往"传统开发"或者"混合模式"挪。这不是说 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 的存在不是为了让你变成超级程序员，而是为了让你在真实世界里解决真实问题时，又能多一种趁手的方式。