靠 AI 写完整个项目，却看不懂代码：Vibe Coding 的终点在哪里？

前言：最近经常看到一种很有冲击力的叙事：++一句代码不会写，也能靠 AI 做出网站和 App++。这个判断并不假，但它通常只讲到了“做出来”，没有讲“接下来由谁负责”。如果你正在用 Vibe Coding（氛围编程）做第一个产品，这篇文章想讨论的不是该不该用 AI，而是一个更现实的问题：当代码开始承载用户、数据和交易时，我们最低限度需要理解什么。

“做出来”从来不是软件项目的终点

自然语言确实打穿了第一层编程门槛。

过去，一个想法要变成产品，至少要先学语法、框架、数据库、部署。现在，你可以直接告诉 AI：“帮我做一个带登录、支付和管理后台的网站。”几轮对话之后，页面能打开，按钮能点击，数据库也写进了数据。

这是一件好事。实现能力不再只掌握在少数人手里，很多过去只能停留在 PPT 里的想法，第一次有机会变成能运行的东西。

但“能运行”只证明了代码在某个时刻、某组输入、某个环境里没有立刻失败。它并不自动证明：权限是安全的，数据是一致的，异常可以恢复，流量上来后系统还能撑住。

AI 降低的是把想法变成代码的门槛，不是把代码变成可靠系统的责任。

真正的分界线，不是你有没有亲手敲出每一行代码，而是项目出问题时，你能不能判断问题在哪里、影响了什么，以及怎样安全地停下来。

把问题继续丢给 AI，不等于解决了问题

Vibe Coding 最容易形成一个循环：提出需求，AI 生成代码；运行报错，把报错贴回去；AI 再改一版；直到页面重新工作。

这个循环在原型阶段非常有效。问题是，当开发者看不懂大部分改动时，修复标准很容易退化成一句话：“现在不报错了。”

可软件故障经常不是消失了，而是被转移了。

一个登录问题，可能被 AI 通过放宽权限“修好”；一个数据库报错，可能被改成吞掉异常；一个重复请求，可能通过关闭校验暂时绕过。界面恢复正常了，风险却进入了更深的位置。

更麻烦的是，AI 往往能给出一段语法正确、解释流畅的代码。这会制造一种危险的确定感：既然它说得这么完整，应该没问题。

但模型并不知道你的真实业务边界。它不知道哪些数据绝不能被跨用户读取，不知道一次扣款能否重试，也不知道某个字段为空代表“尚未填写”还是“权限失效”。这些判断不在代码语法里，而在系统责任里。

所以，我现在判断一次 AI 修改是否可以接受，不只看它能不能跑，而会追问五件事：

这次修改改变了哪条数据流？
失败时，系统会返回错误、静默跳过，还是留下半成品？
权限校验发生在前端、接口层，还是数据库层？
如果上线后出问题，能不能在几分钟内回滚到上一版？
如果我作为逆向技术者，我会怎么逆向/破解我的软件？

这五个问题未必要求开发者亲手写出所有代码，却要求开发者对结果拥有基本解释权，尤其是第五点，是我个人要实测的点，网络安全和逆向手段，未来应该要更被看重了！

不需要科班文凭，但需要工程能力

“Vibe Coding 能不能替代计算机科班能力”，这个问题里其实混在了一起的是两件事：学历和能力。

做产品当然不要求先拿到计算机学位。很多优秀开发者也不是科班出身。数据结构、网络、数据库、操作系统这些知识，并不只存在于大学课堂里，也可以在真实项目中逐步补齐。

但如果把“不是科班”进一步解释成“不需要理解系统”，结论就危险了。

AI 可以替代大量代码输入，也可以解释陌生框架、补测试、查调用链。它暂时替代不了的是责任判断：哪些改动可以直接合并，哪些必须先验证；哪些错误只是体验问题，哪些错误会导致数据泄露或资金损失。

我更愿意把 AI 时代的最低工程能力分成三层。

需求层：能把一句想法拆成边界。

不只是说“做一个登录功能”，而是明确谁能登录、会话多久过期、密码如何重置、管理员和普通用户能看到什么。

代码层：能读懂关键链路，而不是读懂每一行。

至少知道请求从页面进入哪个接口，经过什么校验，写入哪张表；知道 AI 这次改动触碰了认证、支付、文件上传还是数据删除。

系统层：能验证、监控和回滚。

知道如何运行测试，如何查看日志，如何备份数据，如何区分开发环境和生产环境，如何在错误扩大前回到可用版本。

这三层能力不会因为 AI 会写代码而消失。相反，AI 生成代码越快，开发者越需要快速识别风险。过去一个人一天改几十行，错误扩散得慢；现在几分钟可以生成多个文件，理解速度如果跟不上生成速度，技术债也会一起加速。

Vibe Coding 适合走多远，取决于项目承担什么责任

如果只是验证一个想法，Vibe Coding 可以走得非常远。

一个内部工具、一次性脚本、个人使用的小应用，失败成本低，数据也不敏感。此时最重要的是尽快获得反馈，而不是提前搭建完整的工程体系。哪怕部分代码看不懂，只要能限制输入、保留备份、接受重做，风险通常可控。

如果产品开始接触真实用户，就需要换一种模式。

如果系统承担高风险责任，仅靠自然语言反复试错就不够了。

医疗、金融、企业核心数据、高并发基础设施，需要更严格的架构评审、安全测试、权限隔离和故障演练。不是因为 AI 不能写出相关代码，而是因为“看起来正确”无法承担这类系统的证明责任。

因此，Vibe Coding 不是一种固定水平的开发方式。它可以是做原型的快捷键，也可以成为成熟工程流程里的生产力工具。区别在于：有没有测试、评审、监控和回滚把它围起来。

真正要升级的，是从提需求到验收结果

有人担心，不会写代码的人最后只是变成“更会提需求的产品经理”。我觉得这句话只说对了一半。

会提需求本身并不低级。把模糊想法拆成清晰边界，本来就是开发中最重要的能力之一。问题在于，如果能力停在“描述我要什么”，却无法验证“AI 实际做了什么”，那就没有完成从使用者到构建者的跨越。

AI 时代更值得训练的，不是背下更多 API，而是建立一套验收习惯：

每次只让 AI 完成一个边界清晰的改动，避免一次重写半个项目。
要求 AI 先解释方案、影响范围和失败路径，再生成代码。
对认证、支付、权限、删除操作单独补测试，不用“页面能点”代替验证。
保留版本记录、数据库备份和回滚路径，让错误可以撤销。
遇到看不懂的关键代码，不继续堆需求，先让 AI 画出调用链，再对照实际文件逐段确认。

这套做法不会让一个人立刻变成资深工程师，但会让项目从“碰巧能跑”走向“知道为什么能跑”。

可以不写每一行，但不能放弃代码所有权

我并不认为 Vibe Coding 是编程的降级版。它更像一次分工重组：人从大量语法输入中退出来，把更多注意力放在问题、约束、验证和责任上。

但这条路能走多远，有一条很清楚的边界。

你可以不知道某个函数的每个语法细节，也可以让 AI 完成大部分实现；但对于认证、权限、数据和支付这些关键链路，你必须能解释它们怎样工作，知道怎样证明它们没有越界，也知道出错后怎样撤销。

不会写代码，不再是做软件的绝对障碍；不愿理解系统，仍然是。

如果你正在用 AI 做一个准备上线的项目，上线前不妨做一次“代码所有权审计”：任选一条最关键的用户路径，从页面、接口、权限校验一路追到数据库，再完整演练一次失败和回滚。讲不清的地方，就是下一步该补的能力，而不是下一条该丢给 AI 的需求。