Vibe Coding 时代：起码要知道 AI 在做什么

代码像瀑布一样冲下来

现在写代码，有时候像站在瀑布下面接水。

你刚把需求说完，AI 已经吐出一屏又一屏代码：组件有了，接口有了，测试也像模像样地补了几段。以前半天写不完的功能，现在一杯咖啡还没凉，Diff 已经大到让人眼皮发紧。

这当然是好事。问题是，这也会变成一种压力。很多开发者现在卡在一个尴尬处境里：AI 生成代码太快、太多，逐行读懂不现实；可完全不看，又像把方向盘交给一个很能干但没有责任感的实习生。车开得飞快，至于开到高速路还是菜市场，它不一定知道。

我的观点很朴素：Vibe Coding 可以让 AI 代劳编码，但起码你要知道 AI 在做什么。

这不是反对 AI，也不是怀念手敲代码的田园时代。老程序员也没那么浪漫，能少写重复代码当然开心。真正的问题是：当编码这件事越来越便宜，判断、约束和负责就变得越来越贵。

不必逐行读，但不能完全不懂

先说一个容易吵起来的问题：AI 生成的每一行代码，都需要人读懂吗？

我认为不需要。

如果你要求自己把几千行 AI 代码逐行吃透，那 Vibe Coding 的效率优势基本就没了。工具把生产速度提上来，你又把自己拖回人工校对时代，这就像买了自动洗衣机，最后还是坚持用手搓一遍，理由是“这样才踏实”。

可是反过来，完全不看也不行。

因为 AI 不知道你的系统边界，不理解你的历史包袱，也不会为线上事故写复盘。它可以生成看起来很合理的代码，也可能悄悄引入一个新依赖、绕过一层权限检查、把业务规则写死在前端、或者给你造一个“今天能跑，明天没人敢改”的小怪兽。

所以重点不是“逐行审查”，而是换一种审查方式：

一句话：不要做低效的代码校对员，要做高效的系统负责人。

四个身份：你到底该管什么

Vibe Coding 时代，开发者的角色确实变了。

以前我们主要是代码执行者，脑子里想清楚，然后用手把逻辑敲出来。现在 AI 可以承担大量“敲出来”的部分，人就必须往上走一层。不是躺平，而是升级。

我把这个角色变化拆成四个身份。

1. 你是规则制定者

AI 很擅长执行，但前提是你给它规则。

规则包括什么？至少包括这些：

• 技术栈和依赖选择：哪些库可以用，哪些库不要碰。
• 架构边界：Controller、Service、Repository、UI、SDK，各自该干什么。
• 安全红线：鉴权不能绕过，敏感信息不能进日志，输入不能直接进 SQL 或命令行。
• 编码风格：异常怎么处理，日志怎么打，测试怎么写，命名怎么统一。
• 变更范围：这次只改哪几个模块，不顺手重构半个项目。

没有规则的 AI，就像一个精力过剩的同事。你让它“优化一下”，它可能真的很努力，然后把你熟悉的房间重新装修成了迷宫。

规则不是为了限制 AI 的能力，而是为了限制它的乱跑空间。好的规则让 AI 少猜，少发散，少自作主张。

2. 你是蓝图绘制者

AI 可以补砖，但蓝图必须你画。

一个功能要拆成哪些模块？数据从哪里来，到哪里去？失败时怎么回滚？用户看见什么，后台记录什么？哪些逻辑属于业务规则，哪些逻辑只是展示细节？

这些问题不能交给 AI 临场发挥。

很常见的翻车方式是：你只给 AI 一句“帮我实现一个订单审批功能”，它会很认真地给你生成页面、接口、状态枚举和数据库字段。乍一看都对，细看就会发现：权限模型没对齐，审批状态和现有系统冲突，异常流程没有落地，审计日志也缺了一块。

不是 AI 懒，而是你没给蓝图。

蓝图不一定要很重。很多时候，一个简短的设计说明就够：

目标：实现订单审批入口。
边界：只改审批页面和审批 API，不改订单核心模型。
流程：提交 -> 校验权限 -> 更新审批状态 -> 写审计日志 -> 返回结果。
风险：重复提交、越权审批、失败重试、日志脱敏。
验收：覆盖成功、无权限、重复提交、状态冲突四类场景。

这类说明写给 AI，也是写给自己。它会逼你先想清楚，再让 AI 跑起来。

3. 你是技术把关者

技术把关不是逐行抠代码，而是看关键问题。

我通常会重点看五件事：

1. 入口是否收敛：外部输入有没有统一校验，接口边界是否清楚。
2. 权限是否可信：关键判断是否发生在后端或可信服务里。
3. 状态是否一致：失败、重试、并发、幂等有没有处理。
4. 依赖是否克制：有没有为一个小功能引入一个大包袱。
5. 测试是否覆盖风险：测试是不是只覆盖了 happy path。

AI 有时候会给出比你预期更好的实现，这是好事。不要因为不是自己写的就本能排斥。

但你必须能判断它好在哪里，坏在哪里，能不能放进当前系统。否则所谓“惊喜”，很可能只是你暂时没看懂的风险。

4. 你是产品监控者

AI 懂代码，不等于懂产品。

它不知道用户在什么场景下点这个按钮，不知道客服会怎么解释一个错误提示，也不知道运营同学半夜看到一个异常状态会不会血压上来。它更不知道你们系统里那些“文档没有写，但老员工都知道”的业务习惯。

所以产品闭环必须由人盯住：

• 功能是不是解决了真实问题？
• 页面文案是不是让用户知道下一步该做什么？
• 异常提示是不是能指导排查，而不是只说“系统错误”？
• 日志、指标、告警是否足够支持上线后的观察？
• 这个功能失败时，用户和运维各自会看到什么？

AI 能把代码写出来，但产品能不能落地，还得人负责。

一套更实用的审查方法

既然不逐行看，那怎么看？

我建议用“三层审查法”。

第一层：看意图是否对齐

先别急着看代码细节，先让 AI 解释它做了什么。

可以直接问：

请用 10 行以内总结这次修改：
1. 改了哪些模块？
2. 核心流程是什么？
3. 新增了哪些依赖？
4. 哪些地方可能影响旧功能？
5. 哪些场景已经有测试？

如果 AI 连自己的修改都解释不清楚，或者解释和 Diff 对不上，就先别往下走。

第二层：看风险点是否被覆盖

根据功能类型，列一个风险清单，让 AI 自查，也让自己抽查。

比如后端接口重点看：

• 输入校验
• 鉴权和资源归属
• 幂等与并发
• 错误处理
• 日志脱敏
• 数据库事务
• 单元测试和集成测试

前端功能重点看：

• 状态流转
• 加载、空态、错误态
• 用户输入边界
• 可访问性和文案
• API 失败后的恢复路径
• 组件边界是否清楚

注意，这里的清单不是形式主义。它的价值在于提醒你：AI 最容易漏掉的，往往不是语法，而是系统性风险。

第三层：跑验证，而不是相信解释

解释听起来合理，不代表代码真的对。

能跑测试就跑测试，能跑 lint 就跑 lint，能本地走一遍关键流程就走一遍。对于高风险改动，还要补上最小可用的回归测试。

Vibe Coding 不是“AI 说可以就可以”。工程里最朴素的规矩仍然有效：没有验证的正确，只是一个态度很好的猜测。

AI 没有责任感，责任在你这里

这句话可能不太好听，但很重要：AI 不会为自己生成的代码负责。

线上出了 bug，它不会接电话；数据错了，它不会去和客户解释；安全漏洞被打出来，它不会参加复盘；架构被写乱了，它也不会在半年后维护那坨代码。

谁负责？提交代码的人负责，合并代码的人负责，服务 owner 负责。

工具没有责任主体，人有。

所以，Vibe Coding 时代真正的职业底线，不是“我有没有亲手写每一行代码”，而是：

• 我是否知道这次变更解决什么问题？
• 我是否知道它改了哪些边界？
• 我是否知道主要风险在哪里？
• 我是否验证过关键路径？
• 出事时，我是否能解释、回滚、修复和复盘？

如果这些问题答不上来，那就不是 Vibe Coding，是 Vibe Gambling，氛围赌博。

给开发者的一张掌控清单

下次让 AI 写代码前，可以先过一遍这个清单。

开始前

• [ ] 我是否说清楚了目标，而不是只说“帮我实现一下”？
• [ ] 我是否限定了修改范围？
• [ ] 我是否提供了相关代码、接口、文档或约束？
• [ ] 我是否明确了不能碰的地方？

生成中

• [ ] AI 是否先给出方案，再开始大规模改代码？
• [ ] 我是否要求它解释模块拆分和数据流？
• [ ] 我是否发现它引入了不必要的依赖或抽象？
• [ ] 我是否及时打断了跑偏的方向？

合并前

• [ ] 我是否看过整体 Diff，而不是只看最终回答？
• [ ] 我是否检查了权限、输入、日志、错误处理和测试？
• [ ] 我是否跑过必要的验证命令？
• [ ] 我是否能用自己的话解释这次修改？

上线后

• [ ] 有没有日志、指标或告警支持观察？
• [ ] 出问题时是否能快速回滚？
• [ ] 是否需要补充文档或运行手册？
• [ ] 这次经验是否应该沉淀成规则，让 AI 下次少犯同样的错？

最后：做驾驭 AI 的人

Vibe Coding 的确改变了编码方式。以后很多代码不会再由人一行行写出来，而是由人描述目标、设计约束、提供上下文，再由 AI 快速生成。

这没有什么可怕的。

真正可怕的是：代码不是你写的，设计也不是你定的，风险你没看懂，验证你没跑过，最后上线签字的是你。

所以，我对 Vibe Coding 的态度很简单：

不排斥 AI。能让机器干的活，就让机器干。

也不迷信 AI。该由人判断的事，不能外包。

开发者要从“底层代码执行者”升级为“系统负责人”：制定规则，绘制蓝图，技术把关，监控产品。你不必逐行读透每一段代码，但必须掌控方向、边界、风险和结果。

一句话收尾：AI 可以替你写代码，但不能替你负责。

起码，你要知道它在做什么。

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。