★ FEATURED ARTICLE 距离上次那篇Vibecoding尝鲜分享差不多过去了两周。上一回我用Claude Code做的还是一些小脚本属于打完就跑的玩具。这一篇我打算换个玩法用它认真推一个前后端都要动、还带着数据库依赖的真实小项目。整个过程走下来我最直观的感受是Vibecoding并没有把写代码的门槛踩平它改变的只是从想法到代码的传递方式你反而更得想清楚自己要什么才能让AI真正帮上忙。这篇文章就记这一轮尝试里真正值得说的东西怎么把模糊需求翻译成AI听得懂的指令哪些环节我放心交出去哪些环节无论如何都得自己把关以及几个差点让我心态崩掉的坑。如果你已经玩过几天AI编程助手、正犹豫要不要把它用到实际项目里这篇应该能给到你一些参照。1. 为什么第二弹我开始认真对待Vibecoding1.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确实能成为一把趁手的工具但它值得你付出的从来不是无条件的信任。
阅读完成 · 觉得有帮助？
