AI 全栈：一个人干完一个团队，然后一个人崩完一个团队

上个月我花了一个周末，从零做了一个小工具：用户注册登录、一个仪表盘、一个后台管理页、数据库、对象存储、部署上线。前端、后端、数据库、运维，全是我一个人干的。

更准确地说，全是 AI 一个人干的。我负责在几个窗口之间来回复制粘贴、点头、说"继续"。

周一早上工具跑起来了，能注册、能登录、能看数据。我泡了杯咖啡，觉得自己像个团队。然后第一位真实用户注册了——他用了一个带 + 号的邮箱。

登录页 500。

一、全栈的难点从来不是"四个技术都会"

AI 让"会一点前端、会一点后端、会一点 SQL、会一点 Docker"这件事变得极其廉价。你描述需求，它给你 React 组件；你贴报错，它给你 Express 路由；你问部署，它给你一份 Dockerfile 加 compose。

每一块单独看都像样。问题是全栈真正的难点不在"每块会不会"，而在块与块之间的接缝：

• 前端把邮箱原样拼进 URL，后端没做解码，中间还过了个没配置的代理；
• 数据库字段是 utf8 不是 utf8mb4，用户存了个 emoji 昵称，写入时截断；
• 对象存储的桶权限设成了 public，AI 说"这样简单"，因为它不知道你的用户会上传身份证照片。

这些接缝，没有任何一个"单栈"的 AI 会主动替你想。你问前端，它只管前端；你问后端，它只管后端。而 bug 恰恰住在它们中间。

二、它能给你四份正确的代码，给不了一份正确的系统

我那个注册流程，最后大概是这样的：

// 前端：把 email 直接塞进 query，没编码
fetch(`/api/check?email=${email}`)

// 后端：取出来直接用，没校验
const { email } = req.query
await db.query('SELECT 1 FROM users WHERE email = ?', [email])

单看哪一行都没毛病。拼在一起，一个 a+b@x.com 就让 + 在 URL 里被解释成空格，查不到用户，前端拿到 null，空指针，500。

AI 写出这两段的时候，它是在两个独立的对话里写的。它没有"这是一条数据通路"的意识，因为你也没告诉它这是一条通路。你只分别说了"写个查询接口"和"写个调用"。

全栈的 AI 用法，真正的功夫不在让它写，在你脑子里那张数据流图。你知道邮箱从输入框到数据库要经过几层、每层会做什么变换，你才能在接缝处追问："这里编码了吗？这里解码了吗？"

三、最危险的是"它能部署"

我那个周末最省事的一步，是让 AI 写部署配置。它给了个 compose 文件，数据库密码明文写在里面，端口 5432:5432 对公网开放，管理后台没有鉴权，因为它"假设内网访问"。

它没错，它按我描述的"快速跑起来"来写。错的是我把"能跑"当成了"能上线"。

全栈里，部署是唯一一个错误不可逆的环节。代码写错，改一行重新部署；权限配错、端口开错、密码泄露，是另一个性质的事故。而 AI 在部署这件事上，默认走"最短路径到能访问"，因为它的训练数据里，教程都这么写。

所以我现在给自己定了一条死规矩：AI 可以写部署脚本，但每一个开放端口、每一个权限开关，我必须自己过一遍，并且能说出"为什么开"。 说不出来的，一律关掉。

四、一个人 + AI，到底等于几个人

诚实地说，那个周末我做出来的东西，抵得上过去我一个前端加一个后端干两周。这是真的效率提升，不是幻觉。

但它不等于"一个人等于一个团队"。它等于"一个人加上一台不会累、不会质疑、什么都敢答的实习生"。产出速度上去了，判断密度也上去了——因为现在所有的接缝、所有的边界、所有的"这里要不要鉴权"，都压在你一个人身上，没人跟你对。

团队的价值从来不只在写代码，在于有人会在你 merge 之前问一句"这个接口要不要限流"。AI 不会问，它只会照做，而且做得飞快。