AI一键出前端，后端全是半成品？Vibe Coding 真正撞的墙不是代码，是架构_IT互联网

今年 7 月底，知乎上冒出一个扎眼的问题：Vibe Coding 吹得神，做前端一键出成品，为啥写后端全是半成品，根本没法上线？知乎评论区很快有人反呛「你确定前端一键出成品？？？」——但问这个问题的人，描述的体感是真实的。

这不是孤例。把 8 月以来的讨论摆在一起看，你会发现它们其实是同一个问题的不同侧面：

8月8日，「为什么 VibeCoding 跑起来容易，二次修改却格外痛苦？」（知乎）
8月31日，「靠 Vibe Coding 完成整个项目，却看不懂大部分代码，这样的路能走多远？」（知乎）
8月31日，「现在程序员的代码大多数都是用 AI 生成的，后面会成为屎山代码看不懂吗？」，64 条评论（知乎）
8月31日，「AIcoding 导致代码量大幅增加，如何做好代码质量管控？」，43 条评论（知乎）
8月31日凌晨，微博博主宝玉 xp（114 万粉）转发整理了一份海外 Vibe Coding 工程经验，第一条就是：合理的架构和分层依然很重要。微博

一边是「AI 什么都能写」的宣传，一边是后端项目反复卡在「没法上线」的现场。这个落差到底卡在哪？这篇不是劝退文，也不是站队文——它只回答一个问题：在 AI 写掉大部分代码的时代，哪些架构决策可以外包给模型，哪些必须留在你手里。 面向的人群也说得具体一点：写过两三年后端、用 AI 助手做过 side project 或内部工具、现在犹豫要不要把 AI 放进主业的开发者。

一、前端"一键出成品"、后端"全是半成品"，落差是结构性的

很多人以为这是模型能力差异：AI 更会写 React，不太会写服务。但把社区里的失败案例摊开看，真正的原因是前后端任务的反馈回路根本不一样。

前端写完，屏幕立刻告诉你成没成——渲染对了、交互通了，肉眼可验收。AI 拿到的是一个秒级、零成本的验证信号，它可以在你眼皮底下快速自我纠错。后端的「对不对」是看不见的：事务提交没有、幂等做了没有、并发超卖会不会发生、索引在 100 万行时会不会塌——这些东西没有一项能在「跑起来」的那一刻暴露。所谓「一键出成品」的前端，很多也只是 demo 级成品：状态管理混乱、没做错误边界、接口 mock 得像真的一样，到联调那天照样现原形。

所以更准确的说法是：AI 不是写不好后端，是「能跑起来」这个验收标准对后端根本无效。 而后端恰恰是钱、数据和责任所在的位置。这也解释了为什么宝玉 xp 总结的那份海外工程经验，第一条不是用什么模型、怎么写提示词，而是「架构和分层依然很重要」——分层的作用，是在 AI 每次上下文都不同的情况下，给系统划出「改哪里不会牵连哪里」的边界。没有这个边界，AI 写得越快，牵连爆炸的概率越高。

二、Vibe Coding 的三道坎：0→1、1→10、1→100 是三个物种

知乎答主 kimmking（8月31日）对「看不懂代码的路能走多远」给了一个很少见的、按阶段切分的答案，和社区里大量案例对得上：

阶段	场景	Vibe Coding 状态	典型症状
0→1	Demo、个人工具、内部小工具	完全能跑通，是 AI 时代最大的红利	无
1→10	几十到几百真实用户、开始有数据	开始吃力	改一个功能崩三处、bug 复现不了、AI 每次给的方案互相冲突
10→100	付费用户、并发、钱、隐私数据	基本走不下去	问题类型变了：不再是「帮我实现某功能」，而是「为什么周三下午三点响应变慢」「为什么这 37 条订单金额对不上」

关键洞察在第三行：10→100 阶段的输入是「你的现场」——日志、监控、数据分布——AI 拿不到，而你读不懂。 这不是模型不够聪明的问题，是信息不对称的问题。能走到的终点也很确切：第一次真正的线上事故为止。前面一路顺风，不是因为过关了，是因为还没遇到需要你背责的那一刻。知乎

三、五个崩点：AI 默认给的都是「最宽松配置」

把 8 月讨论里的事故复盘归拢，Vibe Coding 项目的崩塌集中在五个位置，每一条都见过真实案例：

安全：SQL 注入、越权（IDOR，把 URL 里的 id 改成别人的就能看别人数据）、密钥硬编码进前端、CORS 全开、没限流。AI 在「能跑起来」这个目标下，默认给的就是最宽松配置。
数据：没事务导致钱算错、并发下超卖、没幂等导致重复扣款、迁移脚本把线上数据洗掉且无备份。
成本：一个没加索引的查询，10 万行时毫无征兆，100 万行时把数据库拖死；云账单突然涨十倍。
不可维护：AI 每次上下文不同，同一个项目长出三种风格、三套状态管理、重复实现的工具函数——技术债在这里吃复利。
合规：个人信息处理、数据留存、支付资质。出事是法律责任，不是一个 bug。

仔细看会发现，这五个崩点里有四个是架构决策的缺位，而不是代码写错了：边界没划（安全）、一致性语义没定（数据）、容量模型没算（成本）、模块归属没管（可维护）。AI 每一段代码可能都写得不错，但「谁和谁在一个事务里」「哪些配置是默认拒绝」这类问题，它在替你回答——用「最宽松」的答案。

四、架构师视角：危险的不是 AI 写代码，是 AI 替你定架构

前 AWS、Google Cloud 的 CTP 办公室负责人、《软件架构师电梯》作者 Gregor Hohpe，8 月下旬一次深度访谈被编译进中文社区，里面几句话正好戳中这轮争论。知乎他说糟糕的架构师「喜欢堆砌流行术语，比如必须云原生、必须松耦合」；他说架构师的价值主张是降低风险，「风险等于成本，风险越低成本越低」；他还给出那句在圈子里传得很广的判断——

在瞬息万变的世界里，最糟糕的情况莫过于有一个你不敢触碰的软件，即遗留系统。我们已经有很多这样的系统，不应该再制造更多。

AI 批量生产的「能跑但没人读得懂」的项目，恰恰是在制造新一代不敢触碰的软件。更值得注意的是，Hohpe 明确把「用 AI 做架构设计」列为危险陷阱：架构决策的价值不在结论本身，而在权衡过程——你让 AI 跳过过程直接给结论，等于把风险的定价权交给了一个拿不到你现场数据的东西。

但 Hohpe 也不是原教旨洁癖派。他那段被反复引用的「四象限」把「单体 vs 微服务」的二元争吵拆成了设计时模块化 × 运行时部署两个维度，顺带给「大泥球」翻了案：设计乱一点、整体部署的单体，对很多业务是合理选项。知乎「不必做最聪明的人」——这句话送给 Vibe Coding 时代同样成立：你不需要为 side project 设计六边形架构，但你需要知道自己处在哪个象限，以及为什么。

五、一张分层委托清单：哪些交给 AI，哪些必须留给你

把上面三家的信号合成一张可执行的表。原则一句话：AI 负责「怎么实现」，你负责「什么算对、坏了找谁」。

决策层	交给 AI	留在人	判断依据
样板与胶水代码	CRUD、DTO、脚手架、单测生成	—	有秒级验证信号，错了损失可控
模块内部重构	提名方案、解释影响面	拍板改不改	AI 看不到三个月后的需求
边界与分层	按你给的边界生成	模块划分、依赖方向由人定	这是 AI 每次上下文漂移时唯一的锚
数据一致性	生成校验代码	事务边界、幂等键、对账口径由人定	崩了是钱的问题
安全默认值	生成实现	默认拒绝的配置由人写死	AI 默认给最宽松答案
容量与成本	估算、压测脚本	索引策略、分表阈值、账单告警	100 万行才暴露的问题
验收与定位	写端到端测试	读懂 diff、定义验收、独立定位	kimmking 的三件事，做不到就是在赌

「读懂 diff、定义验收、独立定位」这三件事，就是 Hohpe 说的「降低风险」职能落到个体身上的版本。具体动作可以立刻执行：每次 AI 改完，强制自己解释一遍它为什么这么改，说不清就让它讲到你能复述；锁死一套技术栈，别让 AI 每次换框架；上线前跑固定清单——认证、越权、注入、日志脱敏、限流、备份可恢复，备份必须演练过，没演练过的备份等于没备份；再让 AI 反过来 review 自己写的代码、逐个文件解释职责，把自己的项目当教材读一遍。

六、三类人分别怎么办

拿 AI 做独立开发/内部工具的：0→1 的红利尽管吃，别被劝退；但从第一天起就做最小安全网——git 分支、5 条关键路径端到端测试、基础报警。你的风险敞口是崩点 1 和 3（安全裸奔、账单失控）。
想把 AI 带进主业后端的：先别动核心链路，从「边界内实现」开始——把模块边界、事务语义、默认拒绝配置用文档钉死（这也是 AGENTS.md 类文件的正确用法：写地图，不是写说明书），让 AI 在围栏里跑。你团队真正的验证信号是事故率和回滚耗时，不是生成速度。
还在观望、担心自己只会调 AI 的：焦虑的对象搞错了。问题不是手搓能力退化，是「不知道自己看不懂哪里」。用 AI 反向教学是当前最快的补课路径——让它解释你的项目，而不是替你写新项目。

最后给一个继续观察的信号：让 AI 把代码仓库变成可验证系统地图的工具正在 GitHub 走红，8 月底已经冒出这个苗头。36氪如果未来几个月「Vibe Coding 生成的代码库被架构分析工具自动识别坏味道」跑通成独立产品线，那就说明市场开始把「架构决策」和「代码生成」正式拆成两层卖——那时你今天留在手里的这些判断，会变成简历上最值钱的部分。