Vibe Coding 时代，真正稀缺的是什么

写在前面

Vibe Coding 不是一个严格的技术定义，更像是一种开发姿态：先把意图说出来，让 AI 快速生成、修改和运行代码，人再通过结果继续对话。

它确实让很多事情变简单了。但它没有让软件工程本身消失。

最近几年，写代码这件事发生了一个很微妙的变化。

以前打开编辑器，面对一个空文件，第一件事往往是翻译：我要的是一个居中的卡片，应该先写容器，再写 flex，再处理响应式；我要的是一个搜索功能，应该先设计接口，再写状态，再补 debounce。

现在，我们越来越经常直接说：

帮我做一个页面，像一张安静的编辑纸，有轻微的层次，但不要像模板。

几秒钟后，代码出现了。页面基本能跑，风格也大致对。我们再看着结果说：

这个标题太抢了，留白再多一点。移动端不要把它做成桌面端的缩小版。

这大概就是 Vibe Coding 最直观的体验：从“写代码”变成了“和结果对话”。

它听起来像一次效率升级，实际上更像一次角色变化。因为当生成代码越来越便宜，决定什么值得做、如何判断它做对了、出了问题谁来负责，反而变得更重要。

一、最明显的好处：从想法到可见结果的距离变短了

Vibe Coding 带来的第一个变化，不是“程序员要失业了”，而是尝试的成本变低了。

很多想法以前不值得动手。

一个只用一次的小脚本，一个验证交互的产品原型，一个给自己看的统计页面，一套临时自动化工具。它们可能只需要存在几个小时，却要经历创建项目、查文档、处理依赖、修语法、调试环境这些完整流程。

于是我们经常选择不做。

现在不一样了。你可以先描述目标，让 AI 生成一个能跑的版本，再决定它值不值得继续。

这件事的价值不只是快，而是保留了很多原本会死在脑子里的小念头。

对于创作者来说，这非常重要。很多真正有意思的东西，最初都不是一个完整需求，而只是一句模糊的感觉：

这个页面如果更安静一点，会不会更好？
这个流程能不能少一步？
这类重复工作，是不是可以交给脚本？
如果把这几个数据放在一起，会不会出现新的联系？

以前这些问题需要先翻译成实现成本，再决定要不要探索。现在可以直接把原型拿在手里看。

降低探索成本，本质上是在增加创造的机会。

二、更多人获得了“把东西做出来”的能力

过去，软件是一种有门槛的表达方式。

一个设计师知道按钮应该在什么时候出现，却不一定能把它做成可交互的产品；一个运营知道后台流程哪里不顺手，却很难自己搭一个工具；一个普通用户知道重复劳动很烦，却只能继续忍受。

AI 编程把一部分“翻译层”拿走了。

这并不意味着所有人都突然成了工程师。它更像是让更多人获得了原型能力：能把自己的需求变成一个可以点击、可以验证、可以讨论的东西。

这会带来一种很实际的变化：

讨论不再只发生在需求文档里，而是发生在一个真实作品上。

一个能点开的原型，比十页描述更容易暴露问题。人们会突然发现，原来按钮放在这里不顺手，原来这个流程需要三步，原来这个“简单功能”实际上涉及权限、同步和撤销。

从这个角度看，Vibe Coding 不是让专业能力变得不重要，而是让产品思考更早地进入现实。

三、工程师开始从“实现者”变成“导演”

当代码生成变得容易，工程师最重要的工作会向两端移动。

前端是理解问题。

你必须知道用户真正卡在哪里，知道什么功能值得做，知道一个需求背后的约束是什么。一个描述不清的需求，生成的代码越多，返工可能越大。

后端是验证结果。

代码看起来能运行，不代表它真的正确；页面看起来完成了，不代表边界条件、权限和异常路径已经处理。

中间那段重复的机械实现仍然重要，但它不再是唯一的价值来源。

工程师更像导演：

决定作品要解决什么问题；
把模糊想法拆成可验证的步骤；
给 AI 足够的上下文和边界；
检查它有没有偷换概念；
在多个方案之间做取舍；
对最后上线的东西负责。

这不是“门槛降低”，而是门槛换了一个位置。

以前会写语法就能开始做很多事。现在写代码的门槛降低了，但系统理解、验证能力和判断力的价值被抬得更高。

四、坏处一：最容易得到的是“看起来能用”

Vibe Coding 最危险的地方，不是生成的代码完全不能用，而是它经常刚好能跑。

页面能打开，按钮能点，数据能显示，于是我们很容易认为功能已经完成。

但真实世界里的问题常常藏在“刚好能跑”之外：

网络超时以后，界面会不会永远停在加载中？
用户连续点击两次，会不会生成两条重复数据？
权限校验在前端看起来有，后端是否真的拒绝？
浏览器刷新以后，状态能不能恢复？
构建成功，是否代表功能真的已经部署？
第三方服务失败时，数据是否仍然保持一致？

我最近给自己的博客加友链申请功能时，就遇到过一次很典型的例子。

前端页面能正常打开，构建通过，本地模拟测试也通过了。但上线之后，申请接口一直返回 405。原因不是页面写错了，而是新的接口路径没有进入 Cloudflare Worker 的路由范围。

代码本身没有报错，构建也没有失败，甚至从表面上看不出它有问题。只有把整个部署链路真正走一遍，问题才会暴露。

这类问题提醒我：

AI 很擅长把“看起来应该能用”变成现实，但真正的软件还要求“在实际环境里确实能用，并且坏了能被发现”。

五、坏处二：代码生成得越快，理解债务越重

在传统开发里，写代码的速度通常和阅读代码的速度差不多。

你一边写，一边形成对系统的理解。为什么这里有缓存，为什么那里要重试，为什么某个状态不能直接删除，这些问题会在实现过程中慢慢进入脑子。

当代码由 AI 快速生成时，这个形成理解的过程可能被跳过。

于是出现一种新的债务：

代码已经存在，但团队里没有人真正理解它为什么这样工作。

它和传统技术债很像，却更隐蔽。传统技术债至少通常来自一次有意识的选择：为了赶时间，先这样。理解债则可能来自一种错觉：既然能跑，那应该已经懂了。

直到某天需要改一个看起来很小的东西，才发现：

为什么要用两层状态同步？
这个 hook 依赖了哪个隐藏行为？
这个错误为什么被吞掉了？
这段代码能不能删？
改这里会不会破坏另一个页面？

AI 可以继续帮你修，但每一次修复都可能建立在上一轮没有被真正理解的代码上。

最后，系统会变得越来越像一间没有图纸的房间。东西确实都在，但没人知道哪面墙承重。

六、坏处三：审查会成为新的瓶颈

AI 让写代码变快了，却没有让 Review 同样变快。

一个几千行的改动，人可以几分钟内生成，却可能需要几个小时才能真正看懂。

更麻烦的是，AI 生成的代码往往“看起来很合理”。命名完整，注释自然，结构也像模像样。它不一定错得很明显，反而会把问题藏在看似专业的实现里。

所以真正的瓶颈开始从“能不能写出来”转向：

有没有足够的测试覆盖；
能不能复现关键路径；
权限和数据边界是否清楚；
日志能不能定位问题；
失败时能不能回滚；
改动是否足够小，方便审查。

生成速度越快，越需要小步提交、明确验证和可回滚的发布方式。

否则所谓提效，只是把工作从写代码推到了以后某个人修代码。

七、坏处四：安全和隐私不能被“感觉”覆盖

Vibe Coding 很容易让人产生一种整体性的信任：页面看起来像认真的，代码应该也是认真的。

但安全不会因为界面好看而自动成立。

密钥有没有写进前端？用户输入有没有正确转义？后台接口是否真的验证了身份？上传文件的类型和大小是否有限制？邮件接口会不会被滥用？删除操作有没有权限检查？

这些问题很多时候无法通过“打开页面看一遍”发现。

更值得警惕的是，AI 工具本身也需要被当作一个需要界定权限的系统。能读哪些文件、能写哪些数据、能不能访问线上环境、能不能提交代码，都应该有清楚边界。

把整个仓库、数据库和生产密钥一起交给一个自动化 Agent，然后期待它“理解我的意思”，这不是 Vibe Coding，更像是在用概率测试生产事故。

自动化可以提高效率，但不能替代授权设计。

八、坏处五：审美和架构也可能被同质化

AI 很擅长学习流行模式。

你让它做一个“高级”“苹果风”“极简”的页面，它会给你圆角、毛玻璃、渐隐、充足留白和干净的卡片。这些元素单独看都没错，但叠加在一起，很容易变成一种熟悉的模板感。

代码架构也一样。它倾向于选择常见目录、常见框架、常见状态管理方式。对于普通项目，这通常是优点；但对于需要独特产品气质的东西，它也可能把差异磨平。

真正的高级感不是某个 CSS 属性，而是：

这个页面到底想让用户先看到什么；
哪些信息应该被保留，哪些应该被拿掉；
动效是在建立反馈，还是只是在证明自己会动；
每一处细节是否服务于同一个气质。

AI 可以帮你实现品味，但不能替你决定品味。

如果完全把判断交出去，最后得到的往往不是一个作品，而是一份平均值。

九、工程师还剩下什么

我不认为工程师会因此消失。

但工程师的工作内容一定会变化。

未来更重要的能力可能是：

问题定义能力
知道真正要解决的是什么，而不是只接受一个表面需求。
系统理解能力
理解数据怎么流动，状态怎么变化，失败会传播到哪里。
验证能力
不只看代码是否优雅，而是设计能证明它正确的测试。
权衡能力
在时间、成本、可维护性、安全性和体验之间做选择。
责任感
知道 AI 可以生成代码，但上线之后发生的事情仍然属于人。

写代码仍然重要，只是它不再是全部。

会写代码的人，未来不一定比别人多打几千行；但能看懂系统、发现问题、定义边界的人，会更有价值。

十、我会怎样使用 Vibe Coding

我现在更愿意把它分成两种模式。

探索模式

这个阶段允许快一点，甚至允许乱一点。

目的是尽快看见一个东西，验证它值不值得继续。AI 非常适合做这个阶段的脚手架、原型和一次性工具。

但探索模式有一个前提：不要直接拿原型当生产系统。

承诺模式

一旦某个东西要给别人使用，要处理真实数据，就要进入工程模式。

这时候需要：

明确权限和数据边界；
写入小步提交，保留回滚；
对关键路径做真实验收；
给失败状态设计提示；
不把第三方服务当作永远可用；
对 AI 生成的代码做 Review，而不是只看它能不能跑；
保留测试、日志和可观测性。

这两种模式最大的区别不是用了多少 AI，而是我们对错误的容忍度不同。

最后：工具让我们更快，但方向仍然是人给的

我依然记得第一次用 AI 把一个想法快速变成可运行页面时的兴奋。

那种感觉很像原本只能在脑子里播放的画面，突然有了可触摸的版本。它确实让创造变得更快乐，也让很多人第一次感到：原来我也可以做出一个软件。

这是 Vibe Coding 最好的部分。

但它最容易被误解的部分也在这里。

生成代码不等于理解系统，做出界面不等于完成产品，能够运行不等于可以负责。

AI 把“实现”这一段的摩擦力降下来了。接下来真正决定作品质量的，是我们如何定义问题、如何验证结果、如何面对失败，以及愿不愿意为自己创造出来的东西负责。

所以，Vibe Coding 时代真正稀缺的东西，可能不是提示词技巧，也不是会多少个模型。

而是判断力。

是知道什么值得做，什么只是看起来很酷；知道什么时候该快，什么时候必须停下来检查；知道哪些事情可以交给 AI，哪些责任永远不能交出去。

工具会继续变强。

但方向，仍然是人给的。