Vibe Coding 这个说法最近大半年在开发者圈子里快被说烂了。什么“十分钟从想法到上线”“让 AI 带我飞”“不会写代码的人也能做 App”这类内容刷一刷就能看到好几条。作为一个写了多年代码、也带过团队搞过几个中型项目的程序员我第一反应不是兴奋而是警觉这些把 Vibe Coding 吹上天的帖子几乎没人提它的逻辑漏洞。这篇文章我想认真拆一拆Vibe Coding 为什么会存在无法自洽的问题哪些场景最容易爆雷以及如果你还是想这么写代码到底该怎么用才不会把自己坑了。1. Vibe Coding 到底是个什么东西为什么就被吹上了天1.1 先把它翻译成大白话Vibe Coding 不是一个严谨的技术概念更像是一种编码风格。所谓“跟着感觉走”落到实际操作里就是你把意图用自然语言告诉 AI 编程助手让它生成代码生成完你复制、粘贴、跑一下出了问题再让它改循环往复直到“看起来能用”。这套流程和传统开发最大的区别在于传统开发是先分析需求、画架构、定接口、写设计文档再动手写代码最后测试评审。而 Vibe Coding 直接跳过了前半段核心变成“意图表达 生成 试错”。它流行的原因我完全理解。大模型确实把“从零写代码”的门槛拉低了你不需要记熟所有 API 细节不用反复翻文档描述清楚想要什么基本就能得到一个能跑的版本。对做原型、做脚本、做一次性工具的人来说这个东西简直是救星。但你有没有发现这个流程里少了一个特别重要的环节——设计。少了设计代码也能跑可它很难保证整个系统是自洽的。而这个“自洽”恰恰是软件能不能长期维护的分水岭。1.2 吹捧者最爱说的四句话我刷到过很多“Vibe Coding 改变人生”的帖子翻来覆去其实就四个观点。第一句是“开发效率提升了好几倍”。这句话不能算错但要看对比基准。如果你原来是从零手写所有底层逻辑那 AI 确实快得吓人。但如果你的项目已经有一定规模代码之间互相依赖AI 生成的效率优势会被反复调试、补坑、重构抵消一大截。第二句是“普通人也能做产品了”。这句话在“做原型”的语境下基本成立但产品不等于原型。原型只要演示给投资人看五分钟就行产品要面对真实用户真实流量要经得住异常输入、高并发、数据迁移和版本兼容。这两者之间的鸿沟AI 目前跨不过去Vibe 的粉丝也总喜欢假装它不存在。第三句是“不用到处搜文档了”。这个体验确实爽可问题在于 AI 生成的代码如果没用对 API报错信息经常更加诡异你不仅要搜新文档还得去理解 AI 的“理解偏差”搜索时间不降反升。第四句是“代码生成已经足够智能人工 review 可以省了”。这是最危险的一句话。大模型的知识来自训练语料而训练语料里大量是 demo 和示例代码这些代码往往为了简短牺牲了错误处理、边界判断和安全校验。它生成的代码看起来很流畅但在真实项目里流畅不代表正确。1.3 一条被刻意忽略的分界线我发现一个很有意思的现象所有 Vibe Coding 的成功案例分享展示的都是“跑通的那一瞬间”几乎没有一个人展示“交付之后的三周”和“三个月之后”。而软件工程真正的挑战恰恰发生在跑通之后。“跑通”和“可靠”之间隔着一条巨大的分界线。跑通说明主流程没问题可靠要求的是所有分支、所有异常、所有边界、所有并发情况都没问题。Vibe Coding 的短板正好在后者。自洽性这个词我理解成“代码在整体上能否保持一致”。说白了就是所有模块对同一个业务对象的理解是否相同接口字段是否统一状态流转是否符合同一套规则错误处理风格是否一致AI 生成代码的时候看到的只是你当前对话里那点上下文它根本不知道整个系统的全貌所以它天然就容易产出“局部正确、全局错乱”的结果。这就是漏洞的根源。2. 核心矛盾代码能跑但系统不能自洽2.1 需求层Prompt 不是需求文档很多人以为给 AI 描述得够清楚它就能交出符合需求的东西。但实际上你再怎么打磨 Prompt它也只是“一段描述”不是“一份需求文档”。打个比方。你跟 AI 说“帮我写一个用户注册并登录的功能”它大概率会给你一个能跑的 demo包含注册接口、登录接口、密码加密、token 返回。可真实项目的需求是什么是验证码超时怎么办是连续错误登录需要锁定吗是 token 过期之后自动刷新吗是密码重置流程要不要走邮件验证是用户名和手机号能不能重复注册这些边界条件、异常分支、性能约束、安全要求如果你不逐条喂给它它不会主动想。即便你喂了上下文窗口也会限制它能记住的细节。更麻烦的是需求本身是会演进的。你改了一次 PromptAI 只会在当前对话里调整之前生成的代码里那些隐含假设它根本不会去同步更新。所以在需求层面Vibe Coding 的第一个逻辑漏洞就是Prompt 只能表达你“想到的”需求而你没想到的那些隐性需求AI 也想不到。代码能跑只是因为你没测到它没想到的那条路。2.2 代码层局部正确和全局自洽是两回事AI 生成代码的时候面对的是一个局部。它当前看到的上下文最多包括你贴进对话里的几个文件或者它自己刚生成的这段函数。但任何一个中等规模的项目模块之间都在互相引用、共享数据结构、依赖统一的状态规则。AI 生成的单个函数可能完全正确但全局组合起来就未必了。我自己在项目里遇到过一个最典型的例子让 AI 分段生成前后端代码前端按 camelCase 读取字段后端生成的是 snake_case接口文档里写的是返回数组对象前端代码却把整个 response 当成一个数组来遍历日期格式一边用 ISO 字符串另一边直接转成时间戳传给图表组件。每个片段单独看都说得通拼在一起就全崩了。这种问题本质上是“数据契约”不一致。数据契约不是靠某一段代码定义的而是分布在所有模块之间的一种隐含约定。AI 没有能力也没有意识去全局维护这种约定。它只会顺着你当前的提问给出最合理的局部回答然后下一个局部它又可能给出一个“同样合理但不一样”的答案。生活里有个很像的场景装修房子每个师傅拿到的都是局部图纸。水电工按自己的理解排线木工按自己的理解做柜子等验收那天你会发现插座被柜子挡住了灯线开关和实际位置对不上。每个师傅的手艺都没问题问题是没有人对“全屋自洽”负责。Vibe Coding 正好就是这个状态。2.3 系统层AI 没有系统记忆也不对运行结果负责这是更深一层的问题。AI 编程助手本质上是一个语言模型它在生成代码时并不运行你的程序看不到真实的执行结果。它对你的系统运行状态一无所知线上的 QPS、延迟、错误率、用户反馈它统统不知道。传统开发里面有一个很重要的闭环叫做“观察-假设-验证”。写完代码部署上线观察日志和数据发现异常提出假设修改代码再次验证。这个闭环让代码在真实环境里不断逼近正确。但 Vibe Coding 的工作流里AI 只负责“生成”和“修改”观察和验证全靠人。它得到的反馈是你说给它的错误信息而错误信息本身就可能不完整、不准确。所以它根本没有机会对自己的输出负责。它甚至不知道自己上一轮生成的代码在项目中扮演什么角色。你新建一个对话它就忘掉之前所有的约定重新按训练概率来一个“仿佛正确”的答案。这也就解释了为什么 Vibe Coding 项目越写越乱不是 AI 不够聪明而是它的工作方式里天然缺少系统记忆。代码自洽需要统一错误码、统一状态管理、统一鉴权逻辑、兼容旧版本数据、保持命名风格一致这些背后都依赖一份“全局的、被维护的知识”。而 Vibe Coding 里的这个知识只是零散地躺在你的若干次对话记录里甚至根本不存在。3. 无法自洽的典型现场从案例看风险3.1 前端后端接口对不上去年我帮朋友救过一个内部工具项目那个项目就是典型的 Vibe 开发产物。团队三个人每个人负责一个模块全程靠 AI 生成代码前后端大概 40 个接口跑起来第一个版本居然很顺利。问题出在联调的时候。后端生成的接口返回字段有的用驼峰有的用下划线日期有的返回 ISO 字符串有的直接返回秒级时间戳。前端那边是按自己的理解解析更惨的是列表接口后端包了一层{ data: { list: [] } }前端代码里写的却是直接遍历 response。页面白屏一片控制台全是 undefined。最讽刺的是每段代码都能在 ID 里单独运行前后端对不上是因为两边从没共享过同一份接口契约。如果有一个人提前把 OpenAPI 规范写好再用 AI 生成两侧代码就不至于这样。但 Vibe 的问题就在于大家都觉得“效率高”懒得先写契约结果后面对坑的时间远超省下来的时间。3.2 状态管理互相覆盖另一个更严重的案例是任务看板。某团队想做一个带多人协作的任务面板需求是一人改任务状态其他人实时同步。AI 生成的逻辑是每个操作直接往数据库里写一份完整任务对象没有任何版本号。单机跑 demo 没什么问题可一上真实环境两个同事同时编辑一个任务后保存的人会把先保存的人改的字段覆盖掉。起初他们以为是网络问题查了很久才发现是 AI 根本没做并发版本控制。任务悄悄消失、备注被覆盖、状态回退用户那边全乱套了。这种问题几乎不可能靠“多写几轮 Prompt”发现。因为 AI 在生成的时候你的 Prompt 里可能根本没提“多人同时编辑”这个场景它也默认不需要处理。而一旦多人协作、并发写入变成核心场景自洽性就直接崩了。3.3 安全漏洞被顺手写出来AI 生成代码还有一个非常隐蔽的坑它会在你注意不到的地方留下安全隐患。我在代码评审的时候见过 AI 把数据库密码写在配置里见过它把用户输入直接拼进 SQL 查询见过它遍历鉴权只检查了前端路由没有检查后端接口见过它生成富文本渲染功能时完全没有做输入过滤。原因也不复杂。大模型训练语料里有大量示例代码示例为了“演示方便”会把安全细节省掉。AI 学到的是一种“常见写法”的概率分布不是“生产环境最佳实践”。而且你给它的 Prompt 越短它默认的安全意识就越低。有人总觉得 AI 不会犯错出问题也是小概率事件。但正是在这种“顺手”和“默认”里安全隐患一个接一个出现。Vibe Coding 的整个流程缺少一个关键角色——安全评审。没有安全评审的 AI 生成代码就是在给自己埋雷。3.4 维护成本成倍放大最后说一下没那么惊险但很致命的问题维护。AI 生成代码的风格极不稳定。同一个项目里它会写出三种不同的循环方式命名一会儿 snake_case 一会儿 camelCase函数一会儿拆得很碎一会儿全部塞在一个函数里注释有时候精准到位有时候纯属胡说八道。更要命的是AI 有时会把同一个业务逻辑写成好几份差异很大的代码。你要修一个 bug就得在三处不同写法里分别修改漏一处就出问题。我之前接手过一段 AI 生成的代码改一个报错弹窗前后端加起来动了七处因为同样的字符串被重复硬编码在了七八个地方。这种代码不是不能维护而是维护成本比人写的代码高得多。你不能说“反正有 AI 帮我改”因为 AI 帮你的前提是它得理解旧代码的意图可上下文有限它看一眼代码就“理解”了实际上它只是猜了个大概。于是你的每次修改都在加深系统的不自洽。4. 不是不用而是要会用Vibe Coding 的正确打开方式4.1 先分清哪些任务适合 Vibe我写这么多不是要劝你彻底放弃 AI 辅助编程。我自己现在天天用但用的方式跟“无脑 Vibe”完全不同。关键是把任务按风险区分开。适合 Vibe Coding 的任务我总结有这么几类一次性脚本、原型验证、单元测试生成、简单的工具函数、样板代码、SQL 的初稿、UI 组件的静态版本、代码重构的辅助草稿。这些任务的错误影响面很小坏了改起来也快AI 的不自洽不会造成严重后果。不适合交给 AI 撒手不管的任务也有几类核心业务逻辑、支付和订单、权限与鉴权体系、强一致性的数据修改、系统间通讯协议、安全敏感代码、需要长期维护的底层模块。这些任务对全局一致性的要求极高一个隐藏假设错了就可能造成线上事故。你可以让 AI 帮你起草但必须有人对最终结果负责。一句话总结不是“AI 生成”就一定差而是“没有控制地让 AI 生成”才危险。Vibe Coding 的问题从来不在 AI 模型本身而在使用者放弃了设计、评审和兜底。4.2 一个我推荐的“可控 Vibe”工作流我现在的 AI 辅助编程方式完全不像市面上宣传的那种“直接开干”而是一套带约束的流水线。每步都有意识地补上 AI 缺失的自洽性。第一步先写最少但必要的设计说明。不需要长篇大论几行字就够这个功能要解决什么问题涉及哪些现有模块数据从哪里来状态由谁管理边界异常怎么处理把这些写下来再喂给 AI它做的事情就从“瞎蒙”变成了“根据明确约束生成代码”。第二步先定接口和数据结构再让 AI 实现内部逻辑。这是关键中的关键。数据契约一旦先定死AI 再自由发挥也只能在契约内部发挥。你可以在文档里定义好字段名、类型、返回结构、错误码然后让 AI 只做函数体填充不要让它设计 API。第三步用自动化测试围住 AI。每让 AI 写一段功能都要求它配套写单测或者你提前把测试用例写好让它实现。测试本质上是一条“行为边界”AI 的代码只要跑不过测试就说明它理解错了这时候你让它看报错重新改效率远高于你肉眼 review。第四步强制 code review。AI 生成的代码必须用跟“人写的代码”同样的标准去评审。尤其要检查异常分支、并发问题、安全漏洞、硬编码、外部依赖。Review 不是走过场而是要把它当成“实习生交上来的代码”严格把关。第五步分步提交小步验证。不要一次让 AI 生成一整个模块然后整体替换那样一旦出问题你根本不知道是哪段代码引入的。改成每次改动只涉及一个函数或一个组件提交前跑测试、看 diff。可控性就是这么一点点堆出来的。这个工作流比“纯 Vibe”慢不少但它是“能上线”和“能上线还能睡个安稳觉”的区别。4.3 代码审查自查清单逻辑自洽的 7 个问题不管是自己 review 还是团队 review我建议把下面这张清单贴在工位上。它尤其适合用来审 AI 生成的代码因为 AI 最容易在这些地方犯错而且错得很“自然”。第一个问题这段代码假设了哪些外部状态它假设数据库里一定有某条记录吗假设某个接口一定返回非空吗假设 token 一定合法吗AI 代码的典型特征就是把“理想输入”当成必然没做防御。第二个问题错误分支都覆盖了吗AI 生成的代码经常只写 happy path。网络超时、数据库连接失败、第三方接口返回 500、用户输入非法值这些分支往往被它一句throw new Error()带过甚至直接省略。第三个问题并发场景下状态会不会互相影响如果这段代码涉及共享变量、数据库写入、缓存更新你有没有考虑过两个请求同时进来会发生什么AI 的示例代码几乎不会主动处理并发但真实系统里并发才是常态。第四个问题数据结构前后端、模块之间一致吗字段名、嵌套层级、日期格式、分页结构这类“数据契约”的问题 AI 特别喜欢各写各的。如果你的项目没有类型定义它几乎一定会埋雷。第五个问题密钥和敏感信息有写死在代码里吗不用解释了AI 生成的代码里硬编码 API Key、数据库密码、签名密钥的案例多到数不完。搜一下整个项目里有没有奇怪的字符串常量。第六个问题老数据、旧版本兼容吗数据库表结构如果被 AI 一改旧数据会不会读不出来接口如果字段改名老客户端会不会挂AI 没有“向前兼容”的概念它只会按你当前描述的目标来改。第七个问题这次改动影响哪些调用方AI 改一个函数的签名、改一个返回结构、改一个状态字段名它只看到自己改的这一块不会知道全项目里有八个地方在调用它。每次提交前搜一下调用点。这七个问题不是标准答题模板它们其实就是自洽性的具体化。你每次 review 都过一遍就能把 AI 生成代码里那种“局部对、全局错”的毛病拦住大半。5. 实操中的坑与排查技巧实录5.1 改一处、崩三处的真相用 AI 改代码最让人崩溃的体验就是我说的“改一处、崩三处”。你让它把页面上按钮的颜色改掉结果它顺手把另一个组件的属性也改了你让它加一个字段它会把整个对象序列化的逻辑都动一遍然后别的地方解析就炸了。这不一定是 AI 太笨而是它的上下文窗口有限。你贴给它的代码如果只是目标文件的一部分它对全局一无所知只能靠“常见的关联猜测”来改动。可实际项目里的关联往往不是靠常见逻辑推断出来的而是靠业务规则和历史遗留形成的。我现在遇到这类问题处理办法有三步。第一步改动范围单独成文明确告诉 AI“只允许修改我提到的函数其他所有地方一个字都不许动”。第二步把相关文件里所有调用点都贴给它让它看到引用关系。第三步改完生成 diff逐行看它到底动了几处。别急着直接信任它的“我改好了”AI 说“改好了”跟你妈说“我吃饱了”差不多都得自己确认。5.2 AI 一本正经地虚构 API另一个非常坑的现象是 AI 会引用一些不存在的库函数或 API。它生成代码的时候很自信函数名叫得煞有介事参数也对注释也漂亮但一编译就错找不到模块没有这个导出类型对不上。原因在于大模型是在“预测下一个词”它不是在查文档它是在生成一个“看起来像正确代码”的字符串序列。如果训练语料里没见过这个函数的真实定义它就会用概率上最像的补全。这种东西干过开发的人都懂越是流畅的输出越要警惕它是在虚构。破解方法也很直接。第一强制在真实环境里编译运行任何编译错误都别放过。第二当它引用了某个库函数让它在回答里附带官方文档链接或者源码引用你核对一遍再放行。第三最好在项目里启用类型检查和严格的 LintAI 的虚构一旦触发编译错误会立刻暴露。5.3 自查加速表从现象到原因我在实际项目里整理过一张速查表专门用来排查 Vibe 代码导致的自洽性问题。按现象找原因比无头苍蝇一样重新生成一遍代码快得多。现象可能的原因快速排查路径接口返回字段看似都对前端就是显示 undefined字段命名、大小写、嵌套结构不一致打印真实响应对比前端读取路径用户的更新被后提交的人覆盖缺少并发版本控制没做乐观锁/时间戳检查写操作是否有 version 字段和条件更新某些路径偶发报错错误处理被 AI 省略空指针异常重点检查可选链、判空和 catch 分支线上访问越来越慢AI 生成全量查询、N1 查询查看执行计划和数据库日志改了一处 UI其他页面布局全乱全局样式污染、组件状态耦合检查 diff回退最近的样式改动安全扫描报出高危漏洞输入未过滤、权限缺失、密钥硬编码先搜敏感信息和拼接 SQL这张表不能解决所有问题但它能帮你把“感觉不对但不知道哪里不对”的时间压缩到最短。5.4 验证和备份的兜底手段最后再强调一个 Vibe Coding 必须做的兜底动作版本控制。我见过不止一个人让 AI 做大规模重构结果改到一半代码彻底跑不起来想回退却发现之前的提交已经被 AI 的改动淹没了。因为他们习惯让 AI 连续修改同一个文件中间没有任何提交点。我的习惯是任何 AI 大幅度改动之前先 commit 一个干净版本。每让 AI 完成一个小的可验证的改动就及时提交并在提交信息里写清楚“这是 AI 生成/修改的哪一块逻辑”。这样一旦出了问题可以精准回退到某个节点而不是整段重写或者两个版本之间来回猜。另外所有关键改动都要跑一遍自动化测试再提交不要在本地随便跑一个用例就合入。AI 对错误信息理解力再强也架不住你在错误的验证流程里反复横跳。验证以真实运行结果为准不是以 AI 的回答为准。这条原则你记住能省掉至少一半的调试时间。6. 写在最后关于 Vibe Coding我的真实心态我自己现在依然在用 AI 辅助编程但工作方式已经彻底变了。我不再是“让 AI 写代码”而是在一个明确边界内“请 AI 帮忙填空”。设计我自己做接口我自己定数据契约我自己维护AI 负责把细节实现跑通。它确实帮我省了很多时间尤其在写测试、生成模板、整理重复代码这些地方价值拉满。但我见过太多项目被那种“一切都交给 AI”的无脑 Vibe 搞得一团糟。这些项目有一个共同点最开始跑得飞快到中后期每改一行代码就好像在雷区里走一步线上事故一茬接一茬团队每天都在为 AI 的“自信输出”买单。问题不在 AI 本身而在流程里缺少了人该负起的责任。如果你也想尝试 Vibe Coding我的建议很简单把它当成一个“能力很强但没有常识的实习生”而不是“无所不能的神”。实习生能帮你干活但你需要给需求、给边界、给验收标准还要盯着它别把事情搞砸。你把心态摆到这一步再用我前面说的可控工作流AI 编程确实能变成一匹好马。摆不对心态它就是一头冲进瓷器店的公牛。至于那些还在吹“代码全靠 AI人类躺平”的人我只能说等他们项目上线第三周再来找我聊。我随时欢迎。