vibecoding一位叛离守旧派的激进派自述(一)

其实标题也顾名思义，从前我也是一名守旧派，在我看来古法编程最是可控，在企业级代码中也最为可靠，如果只是为了所谓的提升效率而引入vibecoding带来的不必要的风险，而vibecoding不过一个llm时代浪潮中的泡沫。

但是随着思考和应用的深入，当我开始回忆自己的学习过往，当我开始"俯视自己"时，我开始质疑自己是否墨守成规，是否过于木讷封闭，也许现在的vibecoding确实是一群弄潮儿的自嗨，但也并不妨碍它是下一代编程范式的雏形。

约束大模型就像是带实习生

其实进入到公司的大多数实习生基本都是在做一些crud的"杂活"，但是mentor为了降低风险，很多时候都会选择让实习生先去看代码库，然后再沟通，之后开始写需求，而最开始的需求往往都是一些风险可控，体量较小的建议需求，甚至一些细心的mentor会帮忙先在分支中提交好需要修改的代码的注释，实习的同学只需要按照注释完成coding即可，然后慢慢的随着深入，开始负责一些体量更大的需求。

抽象来看: 浏览代码库->阅读需求->完成代码->提交CR->merge->上线。

其实这很像agent写代码的过程，我先拿一些开源的skills示例，都有异曲同工的地方。

所以就有了vibecoding的可行性萌芽，我们走过一条类似的开发之路，只是现在的vibecoding更像是刚刚入职的实习生。

mentor需要学会放手

随着实习时间变长，需求逐渐变多变大也变得更独立完整，如果mentor一直一板一眼的去教实习生怎么写代码，那mentor的效率一定会被拉低。随着信任的建立，开始逐渐放手让实习生自己完成开发，但是要慎重CR和Review，以确保线上不会发生故障。

所以目前企业上绝大多数的提效也类似这个阶段，代码使用ai生成，一线研发主要集中在审核以及对需求的理解。这也是当前ai提效的根本点，也许降低了机械性重复性的代码操作，降低了身体疲劳，但是对脑力和精力的消耗从未减少，因为脑力的消耗从开发转化到了审核，真正在一线开发过的都知道，看别人的代码是最心累的，这一点从未变过，而此刻ai的代码就是"别人的代码"。

而且如果有多个ai写的代码要审核，需要人脑不停的切换上下文，对人的精神消耗极大。

所以到这一步，只能说是提效，但绝对谈不上解放生产力。

如果再走一步

合并主分支，势必还要走pipeline自动测试流水线，无论是linter、单测、覆盖率检测、防注入检测等等，其实都是为了避免风险，如果这一步做的足够强，是不是也能降低审核的风险。

如果再更近一步，把抽象的点转移到人的经验上。

俯视自己帮其他同事cr的情景，多数情况我们会 :

先看需求->知道大概的改动点->查看业务逻辑是否满足-> 是否有高风险(引发panic、deadlock等)代码->然后给出打分

这基本就是我自己cr其他人代码的过程，当我思考到这里的时候我发现，如果我能清晰的列出流程，那么我就可以用这一套东西抽象出来，然后去约束AI。

写到这里，其实就有点恍然大悟，一些工作流的skills、或者是skills的存在的意义就体现出来了。

容我浅薄的给skills做一个定性，如果从技术的角度来说skills完全就是一堆字符串混在上下文，没有任何技术上的突破，但是skills诞生把"抽象"这个词进一步推到了新的高峰，因为md可以对人的思维和经验进一步提炼和总结，这是在代码中难以做到的。只是代码中的oop，面向函数等编码的禅与道转化成了奥卡姆剃刀原理、结构化表达、第一性原理诸如此类的思路。

当我考虑到这里的时候，对skills不屑一顾的傲慢，认为skllls毫无技术上突破的傲慢，轰然倒塌，突然想到自己只是执着在skills不过是往上下文塞信息的想法是多么狭隘。

回到产研组织配合

如果不再研究代码，开始反思企业间不同职能的协同配合过程，对ai编程、skills、workflow、subagent有更深的体会。

产品侧:

badcase分析 -> mrd -> 需求内审 -> 需求上产研会吵架 -> 研发排期 -> 上线

研发侧:

需求评估 -> 需求分配 -> 时间排期 -> 上线

以上简化了很多流程，实验、测试 等其实也需要。

所以当mrd越来越卷的时候，一方面为了写的好看，一方面是为了避免歧义和减少考虑不周的地方。

(因为不这么做就会被研发argue yes！！ 就是那种"鸟语花香"的argue )

但其实很现实，如果产品是自然语言表述，研发是程序语言，歧义和模糊点不光会带来效率的降低，更严重的是带来不必要的风险和成本。在互联网公司，研发处于交付的一线，所以面临的信息会非常的复杂，如果产品的主需求也需要不断的揣摩和理解，势必带来的影响非常巨大，所以argue也是组织协同不得不后的结果。

(因为研发转产品的原因，有时候很能共情角色差异带来的问题，毕竟自己被喷过也喷过别人，阿弥陀佛~)

所以会发现组织架构和协调方式的配合，其实同样是在解决沟通成本和试错成本，当skills开始对这个写作流程进行抽象的时候，就会发现，其实是把以前的流水账落成token账的过程。

所以有了brainstorming，writingPlans，grilling-me,toissue，toPrd 等等一系列流程的抽象，一切似乎都有迹可循。

一篇看来是写不完了，先写到这里，还有针对harness、loop、goal、以及重新回到组织协同可能还得继续写2-3个文章，后面持续更新。