最近在一个技术群里，看到有人说：

“我的 vibe coding 撞墙了，兄弟们。最近几个月感觉没学到新东西。”

下面的回复也挺有意思。有人说：“vibe coding，越用越快。”但也有人说：“感觉自己变成了一个简单的机器人。”

我也有类似的感觉。

现在写代码，有时更像是在当传菜员：AI 写好，我检查一下；偶尔甚至懒得检查，完全信任它，直接推上去。

结果是代码产出越来越多，自己却越来越少动脑。编码时的专注力和乐趣慢慢消失，认知与知识也没有同步增长。

这大概就是所谓的“撞墙”。

vibe coding 的前期很容易让人膨胀。每次看到 AI 快速完成一个需求，都会感慨：“它怎么什么都能写？”但用久以后，又会觉得好像也就那样。

因为我们可能一直在重复同一种模式：

描述需求 → 接收代码 → 运行 → 修复

就像前面说的，我们只是把需求端到 AI 面前，再把代码端回来。

一段时间后之所以感觉没学到新东西，是因为我们反复锻炼的，可能只有同一块肌肉：写 prompt。

也许，我们应该把“让 AI 干活”升级成“让 AI 干活，同时逼自己理解”，让交付和成长同时发生。

过去想深入一个领域，卡住我们的往往不是没有教程，而是缺少实战：没人带，也没有真实项目。看再多书，理解也可能停留在纸面上。

现在不一样了。想学什么，可以让 AI 陪我们把这个领域实实在在地走一遍：一起设计、实现、调试，再回头复盘。

这些过程中积累的经验，又会反过来提高我们判断 AI 产出的能力。理解越深，越知道该让 AI 做什么、该检查什么，也越能发现它什么时候在一本正经地胡说。

这个雪球一旦滚起来，或许才是 AI 时代真正的红利。

下面是一些可以尝试的具体做法。

试着切换自己的角色

别只当“甲方”，试着当 reviewer。

AI 写完代码后，强迫自己在合并前逐行看懂。遇到不理解的地方，就让它解释：为什么这样写？这一层抽象解决了什么问题？删掉会怎样？有没有更简单的做法？

很多人之所以产生“代码写了不少，却没学到东西”的感觉，往往是因为跳过了理解和审查这一步。

因此，可以停止“AI 写完就提交”的工作方式，改成：

AI 修改 → 自己审查 → 理解关键决策 → 验证 → 提交

在复杂任务中，这当然会增加一些时间成本。但可以把它看成过去独立编码时的“思考时间”：我们仍然在理解问题、比较方案，只是代码的初稿由 AI 帮忙完成了。

让 AI 做更复杂的任务

vibe coding 在 CRUD、脚本和普通页面等相对成熟的问题上非常顺滑，因为这些任务模式明确，也是 AI 的舒适区。

但如果一直停留在这里，我们积累的更多是交付速度，而不是解决复杂问题的能力。

可以主动挑一些 AI 很难一次做对的任务，比如并发控制、性能优化、复杂状态同步、数据一致性或者遗留系统重构。

真正值得学习的，往往不是 AI 顺利写出的部分，而是它撞墙的地方：

  • 为什么这个方案会失败？
  • 它遗漏了哪些边界条件？
  • 问题出在实现、架构，还是需求本身？
  • 我们应该补充什么上下文，才能让它继续推进？

处理这些问题的过程，会迫使我们建立更完整的判断框架，也会让我们学会如何更好地驾驭 AI。

偶尔关掉 AI，自己裸写

子曰：“学而不思则罔，思而不学则殆。”

可以每周挑一个范围不大的功能，暂时关掉 AI，自己从头实现。写完之后，再让 AI review。

把方向反过来以后，暴露出来的就是我们的真实水平：哪里考虑不周，哪里知识断层，哪里只是“看得懂”，却还不会独立写。

然后再用 AI 帮忙复盘、补齐这些缺口。

久而久之，我们扩充的不只是代码片段，而是自己的知识地图。

从“能跑”升级到“为什么这样设计”

每次 AI 给出方案后，都可以多追问一句：

还有别的方案吗？为什么选择这个？

进一步还可以问：

  • 这个方案的代价是什么？
  • 它适用于什么规模和场景？
  • 如果数据量扩大十倍，还成立吗？
  • 如果需求继续变化，哪里最容易出问题？
  • 什么情况下应该选择另一种方案？

这样积累下来的，就不只是某段能运行的代码，而是一套用于比较方案、识别风险和做出取舍的决策框架。

而这恰恰是我们在 AI 协作中最需要保留和强化的能力。

说到底，vibe coding 没让人学到东西，未必是工具的错，更可能是反馈闭环断了：

产出增加了，但理解没有被沉淀下来。

把审查、追问、独立实践和复盘重新放回工作流里，我们仍然可以享受 AI 带来的速度，同时保留作为开发者最重要的东西：理解问题、判断方案，以及为结果负责的能力。

所谓“撞墙”，也许不是 vibe coding 的终点，而是在提醒我们：该升级使用它的方式了。