到了从 Vibe Coding 转向 Vibe Reading 的阶段了

张开发
2026/4/8 3:23:53 15 分钟阅读

分享文章

到了从 Vibe Coding 转向 Vibe Reading 的阶段了
最近和朋友聊天他说了一句特别准的话现在 vibe coding 反而越来越难受了。东西一多就容易失控。真到排查问题的时候还得重新回头看代码补逻辑补上下文。我听完的第一反应不是反驳而是觉得这大概是很多人都会遇到的下一阶段。这两年AI 把“写出来”这件事变得太容易了。早期做原型、试方向、搭页面、补接口速度确实快得吓人。你给一句需求它就能先吐出一个八成像样的东西。过去一周才能摸到的轮廓现在可能一个下午就出来了。那种体验太顺了顺到人很容易产生一种错觉是不是以后开发都会一直这么快下去但项目不是只有起步那一下。真正把人拖慢的往往都出现在后面。前面快是因为系统还轻。模块不多逻辑不深历史也不长。你今天改一处脑子里大概还记得另外几处会不会受影响。可项目一旦往前走情况就慢慢变了。需求改过几轮补丁打过几层很多代码虽然还能跑但为什么这么写已经不是一眼能说清的事了。这时候你会发现最耗时间的已经不是“让 AI 再写一点”而是“把已经有的这些东西重新读懂”。读不懂才是真正让项目慢下来的原因。不是因为 AI 不够强也不是因为谁突然变笨了而是因为复杂度已经堆起来了。代码越来越多依赖越来越密过去那些为了赶进度留下来的小修小补也会慢慢变成理解成本。到了这个阶段任何一个问题都不再只是一个点的问题它后面牵着的是一整串上下文。而且别忘了AI 也不是在真空里写代码。项目复杂以后它和人一样也会被技术债拖住。前期为了快很多地方先能跑就行命名先不管结构先不理重复代码先留着边界条件先靠补丁兜住。这些东西在早期都不是大问题因为最重要的是把功能先推出来。但一旦项目变重这些“先放一放”就会反过来咬你。最典型的情况就是明明只是一个小需求AI 却要改一串文件。这里补一下那里顺一下表面看每一处都像是合理的可最后很容易挂一漏万。少改一个分支漏掉一个旧判断或者改动之间互相打架bug 就会一下子冒出来。然后人工测试成本也跟着涨因为你已经没法只测那个小需求本身了得把它可能波及到的一圈都重新过一遍。所以我很认同对话里另一句判断这个是“事情”决定的而不是“人决定的”。很多管理者会天然地希望既然 AI 已经把速度拉起来了那团队是不是就应该一直保持高速。站在业务角度这种期待完全可以理解谁都希望更快。但项目有自己的节奏。前面是探索后面是消化。前面是把东西先做出来后面是把已经做出来的东西重新理顺。这个阶段慢下来不一定是坏事很多时候恰恰说明项目已经进入了真正需要梳理的时候。说到底这件事的本质是注意力。不管是人还是 AI一个阶段里真正能做好的往往都只有一件事。你让它专注快速完成功能它就会天然偏向“先做出来再说”这种时候代码结构、边界收束、可维护性通常都会被放到后面。等功能堆到一定程度再继续照着这个节奏往前冲代价就会越来越高。所以更健康的方式不是从头到尾只用一种节奏而是接受开发本来就该分阶段推进先冲一轮功能把关键需求落下来然后停一下做一轮重构和梳理把可维护性拉回来把技术债还一还接着再进入下一轮功能完善再到下一个阶段再做一次整理。以前没有 AI这个阶段通常很痛苦。人要自己啃代码补文档翻提交记录问老同事靠记忆把零散的信息一点点拼起来。现在其实不一样了。AI 不只是能帮你写它也应该帮你读也应该帮你一起还债。我现在越来越觉得vibe coding的后半程其实会自然走到另一件事上vibe reading。这个词听起来有点新但意思一点都不新鲜。说白了就是让 AI 帮你把项目重新读一遍。不是泛泛地“分析一下代码”而是把那些最容易把人困住的东西先捋出来核心模块怎么分关键调用链怎么走哪些地方耦合最重哪些改动看着不大其实风险很高哪些问题不是新 bug只是之前的技术债终于爆了。这件事听上去没有“十分钟生成一个功能”那么兴奋但它往往更重要。很多项目不是死在没人写而是死在没人敢动。代码越来越多知道全貌的人越来越少最后每次修改都像拆盲盒。表面上看是进度慢了实际上是团队对系统的理解跟不上系统本身的膨胀速度了。而且vibe reading也不只是“读”它其实是在为下一轮迭代腾地方。你把结构捋顺了把重复逻辑收了把容易漏改的地方合并了把风险点提前露出来后面再让 AI 接着做功能稳定性会高很多。否则功能越堆越多测试范围越来越大最终不是开发时间被吃掉就是测试时间被吃掉。所以如果一个项目已经做到了某个阶段进入一个相对“慢”的时期我现在反而会把它当成一个信号该开始读了。这个时候最有价值的不一定是继续猛堆功能而是借着 AI 把前面欠下来的东西补一遍。把模块关系讲清楚把历史包袱找出来把关键路径捋顺把那些以后一定会出事的地方提前看见。很多问题一旦被说清楚处理起来就没有想象中那么难。说到底AI 当然能让开发变快但它带来的不应该只有“写得更快”这一种速度。它还应该帮你更快地恢复理解更快地找回全局更快地把一个快要失控的项目重新拉回到可控状态。这可能才是下一阶段真正重要的事。不是一直快而是知道什么时候该快什么时候该停下来读什么时候该停下来收债。每个靠 AI 推进的项目最后大概都会走到这一步。能不能穿过去看的不再是谁更会写 prompt而是谁能更快把系统重新读懂谁知道什么时候该把注意力从“继续加功能”切到“先把系统理顺”。

更多文章