距离上次那篇Vibecoding尝鲜分享，差不多过去了两周。上一回我用Claude Code做的还是一些小脚本，属于打完就跑的玩具。这一篇我打算换个玩法，用它认真推一个前后端都要动、还带着数据库依赖的真实小项目。整个过程走下来，我最直观的感受是：Vibecoding并没有把写代码的门槛踩平，它改变的只是"从想法到代码"的传递方式，你反而更得想清楚自己要什么，才能让AI真正帮上忙。
这篇文章就记这一轮尝试里真正值得说的东西：怎么把模糊需求翻译成AI听得懂的指令，哪些环节我放心交出去，哪些环节无论如何都得自己把关，以及几个差点让我心态崩掉的坑。如果你已经玩过几天AI编程助手、正犹豫要不要把它用到实际项目里，这篇应该能给到你一些参照。
1. 为什么第二弹我开始认真对待Vibecoding
1.1 从"玩具脚本"到"要上线的东西"的转折
第一弹的心态其实很单纯，就是尝鲜。当时我拿Claude Code做了一堆一次性脚本，把乱七八糟的CSV整理成表格，批量改文件名字，再用正则清理文本。体验确实爽，但我心里清楚，这和"正经开发"还有很长一段距离。一个完整项目意味着要设计数据表、处理接口对接、面对异常和边界情况，甚至还得为上线之后的运行事故做好准备。
真正让我转变态度的是手头压了一个需求：我想给自己做一套周期性任务提醒系统，用来跟踪几件每周都要推进的琐事。一开始我用表格硬撑，后来发现事情越来越多、越来越碎，表格根本扛不住。按老办法从零写一个网页应用，至少要搭几个晚上的时间，而我又实在不想为一个内部小工具投入这么大的成本。于是我把目光转回Claude Code，这次不是让它写个脚本，而是让它陪我写完整个项目。
说白了我的诉求很朴素：在一个低风险的内部工具上，把Vibecoding从"玩一玩"变成"生产方式"。我给自己定了个目标，尽量让AI完成大部分代码生成和修改，但每一步我都亲自验收。这样等我跑完整个项目，就能相对客观地判断它到底是玩具还是能用。
1.2 Vibecoding的含义，以及它的适用边界
有人听到Vibecoding，第一反应是又一个人造流行词。其实意思非常直白：vibe是氛围和感觉，coding是写代码，合起来就是"跟着感觉写代码"。传统开发要求你先想清楚模块划分，再到编辑器里一行行敲。Vibecoding是反过来的，你先把脑子里那个模糊的东西说出来，AI把它变成初版实现，你再看着结果继续提意见、继续对话。代码不是从键盘上敲出来的，更像是从对话里一层层长出来的。
但这个方法的边界必须讲清楚。我敢拿它做内部小工具，前提是项目风险足够低：只有我一个人用，坏了不会造成业务影响，最坏的情况也就是我多烦十分钟。如果是面向公众的服务，涉及支付、隐私、数据一致性，我绝对会回到最保守的开发流程：设计文档、评审、测试、灰度发布，一步都不会省。Vibecoding缩短的是"从想法到可运行代码"的路径，它没有取消工程约束，这一点想不明白，用它做严肃项目很容易出事。
1.3 它对不同基础的开发者意味着什么
从我这段时间的观察看，Vibecoding收益最大的人群不是纯零基础小白，而是那些"知道编程大概怎么回事、也能看懂基本逻辑、但没时间也没耐心去追语法细节"的人。你不需要背语法，但你需要能把需求描述清楚，也需要能大致判断AI给的方案靠不靠谱。相反，如果完全没有编程概念，一开始容易觉得惊喜，等需求复杂起来，你连该问什么都不知道，很容易在错误的实现上反复打转。
我一直把Claude Code当成一个手脚麻利但经验有限的实习生。它不怕苦不怕累，知识面也广，但你不能让它单独定方向。你要做的是把目标、约束、验收标准都交代清楚，然后检查它交上来的东西。如果你自己都不知道"对不对"，那你只能被动接受一切输出，这才是最危险的状态。
2. Vibecoding的真实工作流：从模糊想法到能跑的代码
2.1 第一步：先花半小时把需求写成文字
这一次我的起手式和上次完全不同。上次是想到什么直接问，这次我逼着自己先写了一段结构化需求说明。原因很简单：Claude Code对指令的分辨率很高，你说得越细，它自由发挥的空间就越小。
我写的需求描述大意是：一个网页应用，用来记录周期性任务；每个任务有名称、周期（每天/每周/每月）、开始日期；首页展示今天到期的任务，可以打勾完成；历史完成记录能按月查看；数据保存在本地数据库；不做用户系统，因为只有自己用。整段话平淡无奇，但每个关键点都覆盖了：页面形态、核心数据、操作流程、存储方式、权限边界。把需求写下来之后，我自己也清楚了不少。
2.2 第二步：先让AI出方案骨架，别急着填肉
传统开发里我的习惯是先搭工程再拆模块，但和AI协作，顺序最好反过来。第一轮对话我不让它写任何功能代码，只让它基于需求描述给出整体设计方案，包括目录结构、数据表怎么建、接口怎么划分、页面路由怎么组织。这一步就像是和同事开会确定技术方案。
AI给出来的初稿不一定完美，但几秒钟就能给你一个可以讨论的版本。我看完之后调整了两处：一是把任务和完成记录之间的关联字段理得更干净，二是把报表导出功能砍掉放到二期。这一步很关键，因为上下文窗口是有限的，里面塞的无效信息越多，重要信息被稀释得越厉害。趁早砍掉不做的需求，能减少后面对话里的噪音。
2.3 第三步：按模块逐个推进，每跑通一块再接下一块
方案确定后，真正的Vibecoding节奏才刚开始。我按"数据层→接口层→前端页面→联调"的顺序一段段推进。每让它写一个模块，我就亲手把服务跑起来验证：启动服务、发几个真实请求、点几下页面。遇到报错，我不会自己闷头查，而是把报错信息原样复制回对话里，让它基于堆栈信息分析。
这个阶段最容易犯的错，是一次性提一大堆修改要求。我有一回图省事，同时让它加筛选功能、把列表改成卡片视图、顺便改页面标题。结果它确实都做了，但卡片视图和筛选条件在交互上打架，页面行为变得非常怪。之后我就给自己立了规矩：每次对话只交代一件完整的事，做完我先验，验完再提下一个。看着像多跑了几轮对话，实际总时间反而省了，因为问题边界清晰，定位成本低。
2.4 第四步：把验收当成固定动作，而不是可选动作
所有模块都让AI告诉我"完成"之后，我没急着宣布完工。我做了一次完整回归：从打开首页、新建任务、修改周期、完成任务、查看月度记录，把主流程从头到尾走了一遍。这一步比想象中更值，当场抓出三个问题：日期解析因为时区设置差了一天、列表翻页接口漏了参数、删除任务后页面没有及时刷新状态。
这三个问题如果当初全盘信任AI，很可能要等到真实使用时才会暴露。但正因为我把验收当成了绕不开的环节，它们在上线前就被拦住了。结论其实很朴素：AI能把代码质量的起点拉得挺高，但它永远替代不了最后一轮人工验收。AI看到的是你的描述，而真正知道"这样算对"的人，只有你。
3. 那几个差点让我摔键盘的坑：上下文、误解与幻觉
3.1 上下文丢失：它"忘"了说好的约定
第一个大坑是上下文丢失。Claude Code每次对话都有上下文上限，当项目文件变多、对话轮次变长，它可能渐渐不记得早期定下的约定。我项目里有一个很明确的约定：任务ID使用字符串而不是自增数字，方便将来导出迁移数据。这个约定在项目初期一直被执行得很好，但随着对话推进，某次它生成的接口代码里直接用数字类型去解读ID，导致前端传过去的字符串ID怎么都对不上。
当时排查的成本比修bug更高，因为我没往"上下文被挤掉"的方向想，先怀疑是前端传参写错。一层层追下去才发现，问题出在AI后来某个响应里不再遵守初始约定。之后我学到的处理办法是：关键约定不能只依赖对话记忆，必须写进项目根目录的说明文档。每次开新会话，我先让它读文档再干活，这样就算对话轮次拉长，AI也能从文件里把约定找回来。
3.2 需求误解：模糊的词会让AI替你"补全"决定
第二个坑更隐蔽。我在需求里写了"任务周期支持按月"，这句话实在太短了。AI实现的时候，把"按月"理解成"每月同一天重复"。可我脑子里想的其实是"每个自然月上旬要先处理一次"。这两种规则差异非常大，如果只看代码，几乎发现不了，只有跑真实数据时才会感觉到不对劲。
本质上这不能怪AI，是我作为需求方没把话说透。传统开发里，这种模糊可能很快会被业务规则逼着澄清；但在Vibecoding里，AI会把模糊直接补成一个看起来非常合理的假设，然后安静地交付。你如果不拿数据去测，根本不知道它替你做了决定。所以我后来写需求时，凡是碰到"支持""按月""按需"这类泛指词，都会强迫自己补一句：具体指什么？特殊日期怎么算？边界状态怎么处理？写清楚再喂进去，效果完全不同。
3.3 幻觉接口：AI语气笃定地调用一个不存在的库
第三个坑是那些报告里常说的"幻觉"，这次被我结结实实撞上了。它为了让列表支持模糊搜索，直接调用了一个项目里根本没用过的工具库，还煞有介事地写了导入语句和调用方式。我运行起来立刻报错，提示模块找不到。
遇到这种问题，我一般不会急着怪AI，而是把报错信息贴回去，顺手加一句"这个库项目里没有安装过，请换成现有依赖能实现的方式"。通常一两轮就能修正。真正值得警惕的是它当时的语气非常确定，如果不是明确的模块报错，普通人很难判断那段逻辑是不是建立在幻觉上。这件事让我更加确信，AI生成质量要靠运行来画边界，凡是没有跑过的代码都不算数。
3.4 一次真实报错的完整排查链路
顺手复盘一个完整的排错案例。当时的现象是：新建任务后列表没有即时刷新。我没有直接问AI"帮我修"，而是先自己把链路捋了一遍：前端提交请求→接口返回成功→后端落库→前端刷新列表，到底断在哪一步？我在关键位置加了临时日志，发现接口返回成功、数据库记录也写进去了，问题被定位到前端提交回调里少了一步重载数据。
等范围缩小到这个程度，我才带着结论去问Claude Code："提交成功后的回调中缺少重新拉取列表的调用，请补上，顺便检查有没有竞态问题。"修复只花了几分钟。现在很多人用AI排错时喜欢把一大坨日志直接丢过去让它大海捞针，其实AI更擅长的是在你已经缩小的范围内做局部判断。先定位，再求助，这个顺序能省下大量来回成本。
3.5 一个容易被忽略的坑：不同环境之间的差异
还有一个不算AI的坑，但经常被误记到AI头上，就是运行环境差异。我在本地开发时一切正常，等部署到自己的小服务器上，突然发现静态资源路径不对、数据库文件权限不足。AI并不感知你的服务器环境，它只能按照最通用的部署方式推断，所以这类问题基本只能靠人工处理。
这类环境问题其实很适合自己动手排查，没什么技术难点，一旦经历一次，以后部署流程就顺手了。不过它也提醒我：AI默认生成的东西是以"最常见、最通用"为前提的，凡是和你的运行环境有出入的地方，都要在部署阶段额外多留一点排查时间。
4. 让Claude Code真正好用的三个关键习惯
4.1 用文档和代码约束替代口头约定
第一个关键习惯，是在项目里维护一份精简的说明文档。前面聊到上下文丢失的时候，我已经提过它的作用。这份文档不需要长，三到五段足够：项目是干嘛的、技术栈是什么、目录怎么组织、有哪些必须全局遵守的约定。每次开始新会话，我都会在第一个指令里注明"开始前请先阅读项目根目录的说明文档"。
这相当于是给接手的同事写交接文档。AI的记忆再强也会衰减，但文档躺在硬盘里，随时可以重新读入。凡是需要长期遵守的东西，比如ID格式、命名风格、运行命令、部署方式，都值得落到文档里。我甚至还会把接口定义文件也当成一种"约束"，让AI先读定义再写调用代码，从代码本身学习规则，这比依赖上下文更可靠。
4.2 一次只改一个点，小步提交
第二个习惯是小步提交。前面提到一次性提三个需求导致交互冲突，那次之后我就养成了"一次只改一点"的强制习惯。加了一个字段，提交一次；调整了某个页面样式，提交一次；修好一个bug，提交一次。每次提交前先跑一遍与这次改动相关的测试，确保没有把别处改坏。
有人会觉得，用AI就是为了快，这样一点点提交是不是反而拖慢进度？我的体验恰恰相反：正因为AI生成速度快，小步提交才更像给进度打点。它的价值一是回退代价低，二是我能随时看清楚每个阶段的结果，方向不对立刻调头。如果一股脑把所有改动堆到最后再合并，一旦出问题，所有工作混成一团，分离成本远比省下来的那点时间高。
4.3 把测试当成"验收标准"而不是"可选项"
第三个习惯是被时区bug教育出来的。以前我做内部小工具，总觉得写一两个测试就够了，其他手动点一点就行。但用上AI之后，我发现测试的价值反而更高了。因为AI写的代码更倾向于走"主路径"，对边界条件和异常情况覆盖不足，测试恰好能把这些问题暴露出来。
所以我给自己定了一套"验收三连"：数据层的增删改查要有基础测试；接口层的关键逻辑要有冒烟测试；前端必须人工走一遍主流程。前两项可以让Claude Code来写，后一项必须自己做。这几项听上去很基础，但它们把AI的输出从"看起来正确"推进到"真的正确"。在这个项目结束之后，我对"小工具测试可省"这个旧观念已经有了完全不同的认识。
5. 一组实测项目复盘：从需求到上线的完整轨迹
5.1 项目背景与需求边界
为了让这次分享具备一点参考性，我把项目说具体一些：一个单用户周期性任务提醒应用。功能三类：任务维护、到期提醒、月度回顾。页面就三个：任务列表、新增编辑表单、月度统计。数据库用轻量级嵌入式方案，不需要单独部署。整套系统只跑在本地和个人小服务器上，没有对外的用户。
我刻意没有把功能做得更大，原因是我更想观察Vibecoding在一个边界清晰的场景里表现如何，而不是看它在无限膨胀的需求里逐渐失控。后来的结果证明，这个边界设定起了很大作用。因为需求清晰、数据模型简单，AI大多数时候都走在正确路径上，我只需要在少数边界点出手纠正。如果你也想做类似尝试，我建议从小而明确的项目开始，不要一上来就挑战复杂业务。
5.2 各阶段的产出节奏
我简单记录了一下时间线：技术方案讨论十来分钟；数据层和接口层实现大约四十分钟，中间改了两轮接口参数问题；前端页面实现和接口对接用了一个多小时，掐掉一次样式与交互冲突，又补了一轮时区修复；最后整体回归加补测试用了半小时。整个项目从开工到正常可用，大约是三个小时出头。
这个速度放在以前我不敢想。同样的项目，我自己从零写，按周末零碎时间算，至少得两个完整工作日。差距主要在于我不需要反复查语法细节、不需要为了某个日期函数翻半天文档，AI直接给出方案，我只需要做判断和验收。省下来的不是一点点时间，而是一种持续占用精力的"编码疲劳"。
5.3 效率背后的真实代价：精力重新分配到了思考上
不过必须承认一个容易被忽略的代价：省下的是敲代码的时间，耗掉的是描述需求、验收结果、排错澄清的时间。我的工作量并没有消失，只是换了一种形态。甚至在对话次数上，"描述—验收—修正"这个循环占用的精力，比以前自己写代码时还要多，因为我得始终保持头脑清醒，才能判断AI给的方案是否合理。
我觉得这个代价很值。传统编码把大量时间花在语法和工程细节上，Vibecoding则把时间重新分配给了思考本身。它逼着你更清楚自己要什么，更敢对AI的方案说"不对"，也更愿意主动去补测试和文档。对很多厌倦繁琐细节的开发者来说，这种时间分配的转向甚至是一种解放。当然，它的前提是你能扛住"随时负责"的压力，指望AI替你兜底是不现实的。
5.4 上线后的小修补与运维感受
项目上线后，当然没有天下太平。运行一周内我修了两个小问题：一个是提醒判断里对"昨天漏打勾的任务"处理得比较生硬，另一个是页面在手机浏览器上排版有点错位。这两个场景在开发时都没被我列入验收范围，等真实使用才暴露。我依然是老办法：把现象和预期描述给Claude Code，让它给出修改方案，然后我手动验证。
这也是我比较推荐的运维节奏——让AI处理确定的小修改，你自己专注判断"是不是我想要的"。整个项目从开发到小修补，AI承担了很大一部分编码劳动，但所有的关键决策、验收和部署，我都牢牢握在自己手里。这种分工让我既享受了效率，又没丢掉控制感。
5.5 我在实际使用中的几点体会
最后聊几个零散但真实的感受。第一，Claude Code给我的最大帮助不是凭空写整项目，而是省去了"从有了想法到搭好架子"之间那段特别无聊的距离。第二，不要被它流畅的输出迷惑，任何没跑过的代码都只能算是候选代码，手工走一遍主流程是底线。第三，Vibecoding最顺手的用法不是一句"帮我做一个应用"然后躺着等，而是一种高频率短反馈的协奏：你说一个小目标，它给一个片段，你验证，再提下一个。
还有一个挺有意思的发现：当我把需求文字写得越来越精确之后，我自己对项目的理解也变得越来越清晰。这大概就是写作的力量——把模糊想法落到纸面上，本身就是一次梳理。Vibecoding真正迷人的地方，可能正是在这里：它逼着你把内心的模糊"氛围"翻译成语言，而翻译过程，也就是你认识自己需求的过程。如果你想试试，挑一个边界清楚、风险可控的内部小项目开始，接受"它会犯错"的现实，把人工验收当作分内事。这套组合打下来，Vibecoding确实能成为一把趁手的工具，但它值得你付出的，从来不是无条件的信任。
