---

🔥 个人主页：铁皮哥（欢迎关注）
📌 作者简介：28届校招生，后端开发/Agent 方向在学
📚 学习内容：Java、Python、计算机视觉、大语言模型、Agent开发
📝 专栏内容：从零开始的Claude Code零代码生活（持续更新中）
✨不只背八股，更想搞懂为什么这样设计

---

前言

现在很多人开始不再满足于让 AI 写一个局部片段，而是直接把一个想法丢给它：做一个页面，接一个接口，生成一套后端逻辑，再顺手把数据库表也设计出来。几轮对话之后，一个原本还停留在脑子里的产品雏形，就已经能在浏览器里跑起来。

这就是 Vibe Coding 最让人上头的地方。

它把“从想法到结果”的距离压得非常短。过去需要拆需求、搭结构、写代码、调接口、修报错的过程，现在被 AI 包装成了一种近乎流畅的体验。你只需要不断描述自己想要什么，AI 就会不断把代码补出来。页面出现了，按钮能点了，请求能发了，项目看起来也就慢慢成型了。

这种感觉很容易让人产生一种判断：

既然代码已经能跑，那项目应该也差不多完成了。

但真实的软件开发，往往不是从“能跑”开始变难，而是从“能跑以后还要继续改”开始变难。

一个 Demo 能跑起来，并不代表它的结构经得起扩展；一个接口能返回数据，并不代表它的异常路径已经处理完整；一个页面能正常展示，并不代表它后续接入权限、缓存、分页、状态管理时不会变成一团乱麻。

Vibe Coding 的风险也正在这里。

AI 让代码生成变得越来越便宜，也让技术债出现得越来越隐蔽。以前一个糟糕的设计可能会在开发初期就暴露出来，因为人写得慢，改起来痛，很多问题会逼着开发者提前思考。现在 AI 可以快速把大量代码堆出来，项目很快拥有了“看起来完整”的外观，反而让人更容易忽略那些暂时不会报错、但迟早会反噬维护成本的问题。

一、Vibe Coding 的爽感，来自跳过了中间过程

Vibe Coding 之所以容易让人上头，不只是因为 AI 能写代码，而是因为它把软件开发里最磨人的中间过程压缩掉了。

过去你想做一个功能，脑子里可能只是一个很模糊的想法：做一个登录页、做一个任务列表、做一个简历分析页面、做一个后台管理系统。

真正开始写的时候，问题马上会变得具体起来。页面怎么拆组件，接口怎么定义，数据从哪里来，状态放在哪里，异常怎么提示，加载中怎么处理，字段为空怎么办，这些问题都会一个接一个冒出来。

但在 Vibe Coding 的工作流里，这些问题很容易被一句自然语言暂时盖过去。

你只需要告诉 AI：

帮我做一个登录页，接上后端接口，登录成功后跳转首页。

几秒钟后，它可能已经给你生成了页面结构、表单校验、请求函数、跳转逻辑，甚至顺手补了错误提示。你把代码放进项目里，页面真的能打开，按钮真的能点击，请求也真的发出去了。那一刻，人很容易产生一种强烈的推进感：原来做功能也可以这么快。

1.1 从“先想清楚”到“先跑起来”

传统开发里，一个功能从想法变成代码，中间往往要经历一段并不轻松的整理过程。

开发者要先把模糊需求拆成明确对象：这个页面需要哪些字段，用户会触发哪些动作，动作之后系统状态怎么变化，成功和失败分别怎么处理。如果是后端接口，还要继续考虑请求参数、返回结构、错误码、权限校验、数据库字段和事务边界。

这些内容看起来琐碎，却是软件开发真正建立秩序的过程。

而 Vibe Coding 改变了这件事的节奏。它让很多人不再从结构出发，而是从结果出发：先让页面出现，先让接口能调，先让功能看起来能跑。只要 AI 能在短时间内生成一个可运行版本，开发者就会获得一种“项目已经向前走了一大步”的感觉。

问题在于，“先跑起来”本身没有错。很多时候，快速做出原型确实能帮助我们验证想法，尤其是在需求还不稳定、产品方向还没完全确定的时候。真正危险的是，开发者把“原型跑起来”误判成“工程已经成型”。

一个登录页能登录，不代表登录体系已经设计好；
一个列表页能展示数据，不代表分页、筛选、缓存、空状态都已经处理完整；
一个 AI 生成的后台接口能返回结果，也不代表它已经具备真实项目里需要的异常处理、权限边界和数据一致性。

Vibe Coding 最迷人的地方，恰好也是它最容易误导人的地方：它把软件开发中最有成就感的结果提前展示出来，却把那些支撑结果长期稳定运行的过程藏到了后面。

1.2 代码出现得太快，思考就容易被挤到后面

人在写代码时，其实会被速度反向约束。

手写代码慢，所以开发者不得不提前想清楚再动手。一个接口要不要抽成 service，一个组件要不要拆出来，一个字段要不要放进数据库，一段逻辑要不要加测试，这些判断之所以会发生，是因为每一次修改都有成本。写得越慢，人越容易在动手前停下来想一想。

AI 改变了这种成本结构。

当生成代码的成本突然变低，开发者很容易倾向于“先让 AI 写出来看看”。如果不满意，就继续让它改；如果报错，就把错误粘回去；如果页面不好看，就让它优化样式；如果逻辑不完整，就让它补一版。整个过程像是在和代码聊天，反馈非常快，挫败感很低，甚至会让人忘记自己其实正在不断堆叠实现。

这也是 Vibe Coding 和传统开发最大的差别之一。

传统开发里，代码是思考之后的产物；而在 Vibe Coding 里，代码常常变成了思考之前的草稿。它可以很快给你一个方向，但如果开发者没有及时接管结构判断，这些草稿就会一层一层沉进项目里，最后变成正式代码的一部分。

比如你让 AI 做一个用户中心页面，它可能会直接在页面组件里完成所有逻辑：请求用户信息、处理加载状态、展示资料、提交修改、弹出提示。第一版看起来非常顺滑，因为所有东西都在一个文件里，功能也都能跑。可当你后面要加头像上传、账号绑定、权限角色、操作日志时，这个文件就会开始膨胀，原本方便的“一把梭实现”会变成难以拆分的混合逻辑。

这类问题在初期不会刺眼。它不像语法错误那样立刻让项目跑不起来，也不像接口 500 那样马上暴露在控制台里。它更像是一种慢性的结构松动：今天多塞一点状态，明天多加一个判断，后天再补一段请求逻辑。等到你真正想重构时，才发现问题已经不只是某一段代码写得不好，而是整个功能从一开始就没有留下清晰边界。

1.3 最容易上头的，是“看起来已经完成了”

Vibe Coding 最强的心理反馈，是它能不断制造“完成感”。

页面生成了，完成一次。
接口接通了，完成一次。
样式调好了，完成一次。
报错修掉了，又完成一次。

这些反馈会让开发者觉得项目始终在高速前进。尤其是和过去反复查文档、搭结构、调环境的开发体验相比，AI 带来的推进感太明显了。它让很多原本卡在起步阶段的想法迅速落地，也让很多人第一次感受到“一个人也能做完整项目”的可能性。

但软件项目的麻烦之处在于，它很少死在第一眼看不到结果，而是死在后面每一次需求变化里。

第一版能跑，只说明当前路径被打通了。用户输入异常值怎么办，网络请求失败怎么办，后端字段变化怎么办，多人协作怎么维护，后续需求怎么扩展，这些问题不会因为页面已经出现就自动消失。相反，越是快速生成的项目，越需要在结果出现之后回头检查：这个结果到底是建立在清晰结构上，还是建立在一堆临时拼接上。

所以，Vibe Coding 的爽感并不是假的。它确实能让开发者更快看到成果，也确实能降低从 0 到 1 的门槛。

只是我们需要意识到：它跳过的那些中间过程，并不会凭空消失。需求拆解、边界设计、异常处理、测试验证、代码审查，这些环节如果没有在前面完成，就会在后面以技术债的形式重新出现。

而且出现得往往更晚，也更难处理。

二、AI 写出的代码，最容易欠下“看不见的债”

Vibe Coding 的爽感来自它把结果提前推到了开发者面前。页面能打开、接口能调用、功能能演示，这些快速反馈会让人觉得项目正在高速成型。

但真正危险的地方并不在于 AI 偶尔写错一段代码。语法错误、类型错误、接口路径写错，这些问题反而很好发现，因为它们会立刻报错。控制台会提醒你，编译器会拦住你，页面也会直接告诉你哪里炸了。

更麻烦的是那些不会立刻报错的部分。

它们藏在结构里，藏在边界里，藏在未来需求变化时才会暴露的维护成本里。项目刚跑起来时，一切看起来都还正常；等你继续往里加功能、改逻辑、接真实数据、多人协作时，才发现之前那份“很快生成出来的代码”，已经悄悄把后面的路变窄了。

这就是 AI 编程最容易欠下的债：它不是显性的错误，而是隐性的复杂度。

2.1 能跑，不等于结构合理

很多人第一次评估 AI 代码时，最容易使用一个简单标准：能不能跑。

能跑，就说明大体没问题；能展示，就说明功能完成了；能提交，就说明这一轮开发可以结束了。

这个判断在 Demo 阶段当然有用。原型本来就是为了验证思路，先跑起来比什么都重要。但如果一个项目要继续向真实业务推进，只看“能不能跑”就会变得非常危险。

因为软件项目不是一次性作品，而是会不断变化的系统。今天只是一个登录功能，明天可能要加注册，后天要加找回密码，再往后还要支持第三方登录、权限角色、Token 刷新、账号冻结、操作审计。第一版代码如果只是为了让当前路径跑通，很可能会把所有逻辑都塞进最方便的位置。

比如一个 AI 生成的登录页，可能会在同一个组件里完成表单输入、字段校验、接口请求、Token 存储、路由跳转和错误提示。第一眼看起来没什么问题，甚至很“贴心”，因为你要的东西它都帮你补上了。

可问题也正是在这里。

当页面逻辑、业务规则、接口调用和状态管理全部混在一起时，代码短期内看起来完整，长期看却很难拆分。你想复用登录请求，会发现它绑在页面里；你想统一处理 Token，会发现每个页面都各写了一套；你想调整错误提示，会发现提示文案散落在各个组件中。代码仍然能跑，但每一次修改都开始变得不踏实。

这类债不会在第一天跳出来。它通常会等到需求变多、文件变大、逻辑变复杂之后，才慢慢显形。

2.2 技术债往往不是 bug，而是修改成本

很多人理解技术债时，会把它和 bug 绑定在一起：代码有问题、功能有缺陷、线上出事故，这些当然都是债的一部分。

但在真实项目里，更常见的技术债并不一定表现为 bug，而是表现为修改成本越来越高。

一个功能明明只是加一个字段，却要改五六个文件；一个接口只是调整返回结构，前端一堆页面跟着崩；一个业务规则只是多了一个状态，原来的 if else 开始不断膨胀；一个页面只是要复用部分逻辑，却发现所有实现都写死在当前场景里。

这些时候，代码并不一定“错”。它甚至可能一直都能正常运行。只是它的结构让每一次变化都变得困难。

AI 生成代码尤其容易放大这一点。因为它往往更擅长根据当前上下文完成眼前任务，而不是天然替项目规划长期演进路径。如果你只告诉它“帮我实现这个功能”，它就会优先给你一个满足当前描述的实现。至于这个实现以后能不能扩展，能不能复用，和项目已有风格是否一致，异常边界是否完整，很多时候取决于你有没有明确要求它这么做。

这不是 AI 的“原罪”，而是使用方式带来的后果。

AI 并不知道你后面还要加什么功能，也不知道这个项目未来会不会多人协作，更不知道你希望某块逻辑稳定三个月、一年还是长期维护。它只能根据当前上下文和提示词生成一个概率上合理的答案。如果开发者没有提供足够的工程约束，它就很容易选择那条最快抵达结果的路径。

而最快的路径，往往不是最稳的路径。

一个项目里真正可怕的技术债，通常不是某个明显写错的函数，而是一堆“当时看起来很方便”的选择叠在一起。第一次把请求写进组件里，没问题；第二次复制一段类似逻辑，也能接受；第三次为了赶进度再补一个特殊判断，好像也不值得重构。可当这些临时选择不断累积，项目就会逐渐从“能快速生成”变成“很难继续改”。

这也是为什么 AI 写代码越快，技术债可能来得越猛。速度本身不是问题，问题是速度降低了临时方案的心理成本。

2.3 最隐蔽的债，是缺少边界感

边界感说起来有点抽象，但放到项目里其实很具体。

前端组件只负责展示，还是顺手承担业务判断？
接口层只负责请求，还是把数据转换、错误提示也一起做了？
后端 controller 只做参数接收，还是直接写业务逻辑？
service 里处理业务规则，还是把数据库操作和外部调用全部混在一起？
工具函数是通用能力，还是某个页面的临时补丁？

这些边界如果一开始不清楚，AI 很容易哪里方便就写在哪里。

它可能在页面里直接拼接后端字段，在接口函数里直接弹出错误提示，在 controller 里直接操作数据库，在一个工具类里塞进越来越多互不相关的方法。每一处看起来都是小问题，但它们会共同改变项目的形态：代码之间的关系越来越黏，模块之间的依赖越来越乱，功能之间的耦合越来越深。

这种债比 bug 更隐蔽，因为它不会立刻导致系统不可用。相反，它常常会在早期显得很高效。

所有逻辑写在一起，查起来很方便；所有特殊情况直接补判断，改起来很快；所有重复代码先复制一份，功能马上就能上线。可这种效率是透支未来换来的。等项目变大之后，你会发现很多代码不是不能改，而是不敢改。因为你已经不确定改动某一处，会不会牵动另一处隐藏逻辑。

这也是 Vibe Coding 需要格外小心的地方。

AI 可以在很短时间内生成大量代码，而边界感恰恰是一种需要人类主动维护的工程秩序。它不会自动随着代码数量增长而变好，反而会因为代码生成太快而更容易被冲散。

因此，评价 AI 代码不能只看它是否完成了功能，还要看它是否尊重项目边界。它有没有把展示、状态、请求、业务规则和持久化逻辑放在合适的位置；有没有复用已有模式；有没有制造新的隐式依赖；有没有让未来修改变得更清晰，而不是更沉重。

如果这些问题没有被检查，AI 生成的代码就会像一层漂亮的墙纸。刚贴上去时很整洁，远看也没什么问题，但墙体内部的裂缝并不会因此消失。等到项目继续扩建时，那些被遮住的裂缝才会重新出现，而且通常已经比一开始更难修补。

三、AI 编程越强，开发者越要守住工程边界

3.1 人要先定结构，AI 再填实现

Vibe Coding 最容易失控的地方，是开发者还没想清楚结构，就已经让 AI 开始大量产出代码。

一个项目在早期最需要的，不一定是更多代码，而是更清楚的结构判断。这个功能应该拆成几个模块，核心数据对象是什么，前端页面和业务逻辑如何分层，后端接口和数据库表之间是什么关系，哪些逻辑应该复用，哪些逻辑只是临时实现，这些问题如果没有先定下来，AI 生成得越快，项目越容易被随机实现牵着走。

比如要做一个订单功能，开发者如果只是告诉 AI

帮我实现订单列表和订单详情

它大概率会给出一个能跑的版本。页面有了，接口有了，字段也展示出来了。但如果你没有提前告诉它订单状态有哪些、状态之间怎么流转、取消订单和支付订单分别由谁处理、订单金额是否允许前端计算、接口异常时如何兜底，那么 AI 很可能会按照当前最方便的方式完成代码。

短期看，这样确实快。

长期看，项目会逐渐变成一堆“局部合理”的实现。每个页面单独看都能解释，每个接口单独看也能运行，但放到一起就缺少统一秩序。状态命名不一致，错误处理不一致，数据转换散落在不同地方，业务规则一会儿写在前端，一会儿写在后端，一会儿又藏在某个工具函数里。

这时候再去重构，就不是简单改几行代码，而是要重新整理整个项目的关系。

所以，更稳的方式应该是反过来：先由开发者确定结构，再让 AI 填充实现。你可以让 AI 帮你写代码，但不要让它在没有约束的情况下决定项目长什么样。结构、边界、数据流、异常策略，这些内容应该先被人明确出来，再交给 AI 去生成具体文件、函数和测试。

AI 越强，越不能省掉这一步。因为它生成得越快，一旦方向错了，堆出来的代码也会越多。

3.2 提示词里要有工程约束，而不只是功能描述

很多人使用 AI 写代码时，提示词里只有功能目标。

“帮我做一个登录页。”
“帮我写一个用户接口。”
“帮我实现一个评论功能。”
“帮我把这个页面改好看一点。”

这些描述当然能让 AI 开始工作，但它们更像是在告诉 AI“我要什么结果”，而没有告诉 AI“这个结果应该以什么工程方式出现”。

这就是很多 AI 代码看起来能跑，但放进项目里不舒服的原因。它并不是完全没理解你的需求，而是你给它的约束太少。AI 不知道你希望它遵循现有目录结构，不知道你希望请求统一走封装好的 API 层，不知道错误提示要接入全局消息组件，也不知道某些业务规则必须放在后端而不是前端。

于是它只能用一种看起来最直接的方式完成任务。

这也是为什么同样一个功能，不同提示词生成出来的代码质量可能差很多。

如果你只说“帮我写一个登录功能”，AI 可能会生成一个把请求、状态、校验、跳转全部写在页面里的版本。但如果你告诉它：页面只负责展示和交互，接口请求放到 api 层，登录状态交给统一的 auth store 管理，错误处理走项目已有的提示组件，Token 不要散落在页面中，那么它生成的结果就会更接近一个真实项目可以接受的实现。

功能描述解决的是“做什么”，工程约束解决的是“怎么放”。前者决定代码能不能生成，后者决定代码能不能融入项目。很多 Vibe Coding 项目之所以后期变乱，并不是 AI 完全不行，而是开发者每次都只让它完成当前功能，却没有持续把项目规则传递给它。

在真实开发里，一个好的 AI 提示词不应该只是需求说明，更应该像一次小型代码评审前的任务分配。它需要告诉 AI 当前项目已有的结构，哪些文件可以改，哪些模式要复用，哪些事情不能做，生成之后需要满足什么验收条件。

比如你可以这样要求它：

请基于现有项目结构实现这个功能，优先复用已有接口封装和状态管理方式，不要在页面组件里直接写请求逻辑；如果需要新增文件，先说明新增原因；实现完成后补充关键异常路径和测试建议。

这样的提示词并不能保证 AI 一次写出完美代码，但它至少把 AI 从“自由发挥”拉回到了“受约束执行”。而 AI 编程真正成熟的使用方式，恰恰不是让它无限发挥，而是让它在清晰边界里提高效率。

3.3 代码生成之后，审查比生成更重要

Vibe Coding 最容易让人忽略的一步，是生成之后的审查。

因为 AI 的反馈太快，开发者很容易形成一种连续推进的惯性。一个功能生成完，能跑，就马上进入下一个功能；下一个功能生成完，能展示，又继续往下做。整个过程像是在搭积木，速度很快，完成感很强。

但真实项目里，生成代码只是开始，不是结束。

AI 生成的代码需要被审查，就像团队里任何一个新人提交的代码都需要 code review 一样。它可能写出了正确的大方向，也可能在某些地方偷懒；它可能处理了主路径，却漏掉了异常路径；它可能看起来符合当前需求，却没有考虑已有项目风格；它也可能因为上下文不完整，生成一段和现有架构不兼容的实现。

如果开发者不审查，这些问题就会直接进入项目。

更麻烦的是，AI 生成的代码往往有一种“看起来很完整”的迷惑性。变量名还算规范，注释也有，结构似乎也分层了，甚至还能补几个看似周到的边界判断。可这些外观不能替代真正的工程判断。你仍然需要确认它有没有重复造轮子，有没有绕过已有封装，有没有把权限判断写错位置，有没有让前端承担了本该由后端负责的规则，有没有在异常场景下留下不稳定状态。

审查 AI 代码时，最重要的不是逐字逐句怀疑它，而是沿着项目边界去看它。

这个实现是否符合当前目录结构？
这段逻辑未来是否可能复用？
异常路径是否完整？
数据流是否清晰？
如果需求增加一层复杂度，这个方案还能不能继续撑住？

这些问题才是决定代码能不能留下来的关键。

如果说过去开发者的主要工作是“写出代码”，那么在 AI 编程越来越强之后，开发者的工作会越来越像“判断代码”。AI 可以更快地产生候选实现，但最终决定哪一版能进入项目、哪一段必须重写、哪一种结构更适合长期维护，仍然要靠人来把关。

这也是 AI 编程时代对开发者的新要求。

不是每个人都要比 AI 更会写样板代码，但开发者必须比 AI 更清楚项目边界。

写在文后

期待您的一键三连！如果有什么问题或建议欢迎在评论区交流！