1. Vibe Coding是怎么火起来的先别急着站队过去这半年我身边几乎所有写代码的朋友都换了一种干活的方式。以前是打开IDE盯着光标想半天然后一把梭敲上几十行现在是打开对话窗口把需求一股脑倒给AI看它刷刷刷生成一大片代码然后复制、粘贴、跑一下亮了绿灯就算完事。这就是Vibe Coding一个由前OpenAI研究员Andrej Karpathy带火的词。他在2025年初的一条推文里说现在写代码已经不是写代码了而是描述需求、 Review 差异、点个接受偶尔遇到AI卡住的时候动手改一行。他原话的意思是你只要顺着感觉走把意图交给工具剩下的交给模型。这个词传播速度快得吓人相关热搜里满屏都是Vibe Coding下载Vibe Coding安装这种搜法好像它是一个需要安装的软件一样。这个误解本身就很有意思——Vibe Coding不是某个工具而是一种开发姿势一种把AI当作主要编码执行者的工作流。但作为一个在软件工程这个行当里摸爬滚打了十几年的人我第一反应不是兴奋而是警惕。不是因为我保守也不是因为我对AI有敌意。恰恰相反我日常工作里已经离不开AI辅助了大到架构设计的思路梳理小到单元测试的骨架生成都让它参与。我警惕的是另一件事Vibe Coding正在把写代码这件事变得极其廉价但软件的复杂度和责任一点都没有减少。代码可以交给机器生成可系统的正确性、可维护性、安全性和团队协作的秩序没有任何一个AI能替你兜底。说白了Vibe Coding解决的是怎么把代码写出来的问题而软件工程解决的是怎么让这些代码在未来的两年、五年里还能被理解、被修改、被信任的问题。前面的问题越来越容易后面的问题越来越难这两者之间的落差就是我这篇文章想展开聊的东西。2. 凭感觉编码的理想工作流它到底改变了什么2.1 你只需要感觉对剩下的交给模型先说清楚Vibe Coding具体是什么样的工作状态。我实测下来的典型循环是这样的第一步你在对话窗口里用自然语言描述你想要的东西比如帮我写一个Python脚本批量把某个目录下的CSV文件按日期分桶并且生成摘要报表。第二步AI给你一段能跑的代码。第三步你直接跑看到结果符合预期就收工了。遇到报错你甚至不用自己读堆栈而是把报错信息整个复制粘贴回去让它自己修。这个循环和传统开发方式有一个根本性的差异传统的做法是编写-调试-理解Vibe Coding的做法是描述-生成-试错-再生成。你不再需要逐行维护对代码的心智模型因为每一轮交互都像是请了一个新的程序员替你干活而且它记忆力惊人、查文档速度极快、写样板代码永远不会不耐烦。我见过一个前端同事半天时间就搭出了一个以前要写两天的后台管理界面原型页面、路由、状态管理、接口封装全部由AI完成他只负责把需求描述成一个个对话片段。效率确实高这个没什么好嘴硬的。但请注意我用了一个词原型。2.2 效率翻倍的幻觉与现实Vibe Coding最容易让人迷惑的地方在于它把从0到1阶段的时间压缩到了极致。你只需要一个模糊的想法就能得到一个跑得起来的Demo。很多开发者第一次接触这个工作流时都会产生一种软件开发不过如此的错觉。我一个朋友做得更极端他用AI生成了一个完整的小工具从需求描述到发布到应用商店只花了一个周末。他兴奋地告诉我这是软件工程的终结。我没急着反驳只问了他三个问题这个工具的数据存储层如果后面要加字段改动成本是多少如果有用户报告了一个只在特定机型上出现的崩溃你能定位吗三个月后你自己回来看这些代码还能说出每个模块为什么这么写吗他沉默了。这就是Vibe Coding最核心的矛盾它优化了前10%的产出速度却把后90%的系统性成本悄悄转嫁给了未来。而这个未来往往来得比你想象的快——需求变化、人员流动、bug分析、性能调优、安全加固这些活儿不是一个能生成代码的对话窗口就能替你扛住的。2.3 承认它的合理之处也不是全无价值我不想全盘否定Vibe Coding。事实上它在几个场景里是有真实价值的一次性脚本和自动化小工具用完即弃不需要长期演进原型验证和Demo制作目标是快速验证想法能不能行样板代码生成比如DTO、简单的CRUD接口、配置文件的初始化学习期探索新手想看看某类代码长什么样AI可以充当一个随时响应的示例库。在这些场景里Vibe Coding没什么问题因为代码本身就不是核心资产想法才是。可一旦你越过这条线开始用同样的方式去构建需要长期运行、多人协作、承载真实业务逻辑的系统时问题就接踵而至了。3. 再聊软件工程它本来就是为了收拾写代码太快的烂摊子3.1 回到1968年软件危机的教训没过去太久很多人不知道软件工程这门学科的诞生恰恰就是因为在写代码特别快这件事上吃过巨亏。1968年北大西洋公约组织的软件工程会议上专家们提出了一个概念叫软件危机。那时候的危机是什么不是写不出代码而是代码写得太多、太快了导致根本管不过来。大型项目的开发周期一拖再拖预算严重超支系统上线后bug满天飞维护成本高到离谱甚至出现了一些因为软件缺陷导致的严重事故。当时的人们发现用个人英雄主义的方式写代码在小规模场景下可行一旦规模上去项目管理、需求分析、系统设计、测试验证这些问题就会集体爆发。所以软件工程这门学科的出现本质上不是为了让写代码变得更爽而是为了约束写代码太随意带来的混乱。你品一下这个背景再回头看Vibe Coding。今天我们是不是又一次站在了代码生成变得极其容易的节点上AI让每个开发者都变成了一小时能写一千行的超人但我们的工程能力、质量意识、协作纪律有没有跟着提升十倍答案不言而喻。3.2 软件工程的承重柱需求、设计、测试、维护软件工程发展到现在不管方法论怎么迭代瀑布、敏捷、DevOps有几根承重柱从来没有变过需求工程。搞清楚到底要建什么是所有工程活动的起点。需求错了后面做得越快错得越远。架构设计。确定系统的大结构模块边界、数据流、依赖关系。这是为了让复杂度可控让多人协作成为可能。质量保障。测试、评审、静态分析、监控告警这一整套机制是为了让代码从能跑变成可靠。维护与演进。软件的生命力在于持续变化。一个不能低成本修改的系统不管初始功能多惊艳最终都会变成遗产。这四根柱子没有一根能被AI生成代码替代。AI可以帮你写需求文档的初稿但它替不了你和业务方的沟通AI可以帮你画出模块结构图但它替不了你对业务领域的深入理解AI可以帮你生成单元测试用例但它替不了你判断断言写得对不对AI可以帮你重构代码但它替不了你决定这个模块到底应不应该拆。Vibe Coding真正危险的地方在于它让开发者误以为前面那四根柱子都不需要了——反正代码能跑。3.3 1.0到2.0软件工程本身也在进化顺便说一句热搜里有个词叫软件工程1.0和2.0我猜很多人是把它当考点背的。其实这个概念并不复杂用一句话来概括1.0时代关注的是从无到有地造出正确的软件2.0时代关注的是在已有系统上持续演进、快速响应变化。1.0的思路是重型文档驱动先把需求、设计、计划全部做扎实再进入编码。它的问题在于太慢等到文档写完了市场早变了。2.0的思路是更强调迭代、反馈、自动化用更轻量的方式持续交付价值。敏捷开发、持续集成、DevOps这些东西本质上都是为了支持软件要不停变化这个现实。把视角拉回Vibe Coding你会发现它其实和2.0的某些理念有表面上的亲和力——快速生成、快速验证、快速迭代。但它跳过了2.0最核心的东西反馈闭环的质量保障。敏捷的前提是你有一套快速检测错误的机制否则快速迭代就变成了快速制造垃圾。4. 我踩过的坑当Vibe Coding遇上真实业务4.1 第一个坑AI生成的代码全是局部最优解我做过一个数据同步服务初期为了赶进度大量使用AI生成核心逻辑。当时看每一段代码都很顺眼变量命名规范、注释齐全、逻辑清晰。但随着业务方陆续加了几个新需求我开始感觉到不对劲AI生成的两段功能代码之间往往用的是完全不同的模式来处理相似问题。一个模块用同步阻塞的方式写数据库操作另一个模块用异步回调的方式一个模块把配置放在环境变量里另一个模块硬编码在类里一个模块的错误处理是抛出异常让上层兜底另一个模块是内部捕获之后打日志返回null。单看任何一段都挑不出大毛病。但把它们拼在一起系统就变成了拼图怪。你需要维护的心智负担不是112而是每一处都要重新确认这一次它又是用了什么套路。这就是局部最优解的陷阱。AI没有全局观它不会记得一周前的对话里你确定的技术选型和约定它只会针对当前这段提示词给出最合理的独立方案。而软件的复杂度恰恰来自所有局部方案之间的相互一致性。4.2 第二个坑提示词写不清楚的需求AI也不会替你搞懂很多人有一种迷思觉得AI可以帮助做需求分析。实际用下来你会发现AI确实能帮你整理需求但前提是你已经把需求讲清楚了。如果你自己都只有一个模糊的、矛盾的想法AI只会把它包装成一份看起来很专业的、同样模糊和矛盾的需求文档。我让AI帮我写过一个订单状态流转的功能。我把需求描述得七七八八AI生成了代码状态机看起来有模有样。结果评审的时候业务方一提问才发现我压根没想清楚退款中的订单能不能取消已发货的订单能不能修改地址这几个边界场景。AI没有追问因为它的目标是让我满意而不是帮我发现我不知道的事情。AI是特别擅长迎合的工具它不是真相的探照灯。这个教训让我深刻体会到一件事需求分析这个环节你可以用AI做记录、做模板、做初版草稿但想清楚到底要什么这个责任永远只能你自己扛。你脑子里如果没有对业务逻辑的清晰建模AI只是让你更快地抵达错误。4.3 第三个坑你以为你在Review其实你只是看到了Vibe Coding工作流里少了传统开发中自己亲手敲代码时对每一行的天然审视。因为代码不是你写的你天然会降低对它的警惕性。你打开Diff快速扫一眼看到没有明显的语法错误然后就是Accept。这其实是最大的风险窗口。我统计过自己用AI辅助开发的代码评审状态在加速开发的那段时间线上问题里有接近一半来自AI生成的逻辑处理了正常情况但没有处理边界情况或者AI用了看似合理但实际违反了我们项目约定的API。这些问题如果放在手写代码里我在敲到那一段的时候大概率会意识到这里的数据可能是空的这里需要加个校验。但AI生成的时候这些隐性的工程意识全都消失了。Vibe Coding的开发者经常觉得我review过了但那个review质量和手写代码时的review质量根本不在一个量级上。原因很简单你review别人的代码时大脑默认它可能是对的你review自己的代码时大脑默认它可能有bug。AI生成的代码对你的大脑来说是别人的代码。5. 超越Vibe Coding把AI嵌进工程纪律而不是替代工程纪律5.1 我的结论Vibe Coding是能力不是立场经过大半年的实践和踩坑我对Vibe Coding的态度已经稳定下来了。它不是一个应该被全盘拥抱或者全盘批判的东西它更像是一个新的工具维度——你可以用它来加速但你绝对不能让它替代你作为工程师的职责。那工程师的职责到底还剩什么我的答案是四个字对系统负责。你负责系统能不能正确满足需求而不是AI生成的代码看上去有没有道理 你负责系统在三个月后还能不能低成本地修改而不是今天能不能跑通 你负责系统在极端输入下会不会崩溃、在攻击面前会不会失守而不是Demo演示时会不会卡顿 你负责团队里的其他成员能不能看懂这套东西而不是只有你和AI知道它为什么工作。只要这个责任还是你的那Vibe Coding用起来就没有问题。怕的是你用着用着真的以为自己不用负责了。5.2 一个可行的折中AI编码人做工程具体到工作流我现在是这样组织开发和AI辅助的关系的先做人再做AI。一切的起点仍然是你对问题的理解。我会先用结构化的方式把需求拆成功能列表、验收标准、边界条件哪怕只是一个简单的表格。这个表格不一定给AI看但它是你自己的地基。然后是AI加速。需求拆清楚了AI生成代码的效率确实高尤其适合处理样板逻辑、CRUD、正则表达式、数据清洗这类高度模式化的任务。与领域强相关的核心逻辑我建议你还是自己写——不是AI写不出来而是你写的时候脑子里会顺带把异常处理、性能考虑、未来扩展都过一遍这些东西AI不会替你想也不该替你想。最后是工程化兜底。所有AI生成代码一律要过完整的工程流程设计评审哪怕只是自己写个简短的决策记录、单元测试、代码评审、集成验证。不要开AI生成代码免测试的先例一旦开了你会很快失去对系统的掌控力。5.3 给不同类型开发者的建议如果你是独立开发者做的是小工具、Demo、个人项目Vibe Coding完全可以用起来但请至少做到给每个AI生成的核心模块写一小段注释说明它的行为约定保留一份简单的系统设计笔记哪怕只有几行字。这是给未来的你留后路。如果你是在团队里做业务系统AI编码的比例建议控制在五成以下并且所有核心路径支付、权限、数据一致性必须人工编写和review。这里没有讨价还价的余地。如果你是学生正在上软件工程相关的课程——《软件工程导论》《软件工程课程设计》同时在热搜里搜软件工程导论第六版答案搜得飞起。我的建议是AI可以帮你解释概念、生成示例代码、帮你理解设计模式但作业一定要自己写。因为你正在构建的不是软件是你自己的工程思维体系。年纪轻轻就依赖外部生成器你会发现毕业设计的时候连最基本的项目分解都无从下手。5.4 工程师的未来从打字员变成架构师很多人担心AI会让程序员失业。我个人的判断是AI不会让程序员失业但会让只会打字编程的程序员失业。那些把工作理解为把需求翻译成代码的人确实会被替代而那些把工作理解为构建和维护复杂系统的秩序的人反而会因为AI而变得更强大。同样的工具落在不同人手里结果完全不同。我一个同事用AI辅助重构老系统的模块划分AI帮他快速生成了依赖分析的脚本、给出重构方向的参考方案他基于自己的领域知识做决策一周完成了原来预计两周的活。另一个朋友用AI从头到尾生成了一整个微服务项目结果第一个生产事故就花了三天排——因为他根本不知道日志里那些报错对应的是哪段生成代码。同样的AI前者是放大器后者是加速器——只不过加速的是失控。6. 几个具体的实操纪律防止Vibe Coding退化乱七八糟讲了这么多最后给到一些可以直接抄走的硬性约束。免得你读完点头如捣蒜回去之后又打开了对话窗口开始vibe。第一条AI生成的代码先过你的手再过编译器。不要直接复制粘贴。把它重新在自己的编辑器里敲一遍结构边敲边想。这个过程不是为了重复劳动而是强制你建立对代码的熟悉感。如果你发现自己根本不想看它内部怎么实现那说明这段代码根本不该被接受。第二条凡是涉及状态流转和金额计算的逻辑禁止纯AI生成。这两类逻辑错误是最难通过测试发现的而且往往是在上线后、数据量上来之后才爆雷。你可以让AI写参考实现但最终版本必须自己逐行审查和修改。第三条建立一个需求决策记录文件。哪怕是几句话为什么订单取消后不允许退款因为这样设计可以避免重复支付问题。以后AI生成代码时把这份文件的关键内容粘贴进提示词你会发现生成的质量有显著提升——AI有了决策上下文才能给出符合预期的方案。第四条把自动化测试当作AI生成代码的验收门槛。AI生成的功能必须附带一套能跑通的单元测试否则不合并。这不是为了测AI是为了给你自己留一条安全网。没有测试网的Vibe Coding就像蹦极没绑绳——看起来帅落地全靠运气。第五条定期做一次去AI化复盘。每两周挑一个你依赖AI最多的小模块尝试完全靠手写重写它。这个训练能帮助你保持手感并且让你对AI生成的代码保持批判性。写代码和你认不认得清自己写的代码其实是两种能力。用一次真实经历给这个话题画个逗号上周我帮一个朋友排查线上问题。他用了AI辅助写了一个文件上传服务小文件没问题大文件总是中途失败。我打开代码一看AI用的是read()一次性读取再写盘。也不怪AI它的很多训练语料里教的是方便优先但生产环境里大文件必须走分块读写。这本来是个很小的坑。但朋友盯着报错信息看了半小时也没反应过来问题在哪因为他压根不知道AI帮他写了read()这种实现。他只会向AI描述现象让AI修了几次来来回回都没抓住重点。最后我把那段代码里的read()换成流式读取问题解决。整个过程不到五分钟。朋友很感慨说原来我应该自己看一眼代码的。不是应该是必须。你可以不写每一行代码但你必须理解每一行代码在做什么。Vibe Coding可以让你跑得更快可如果你脱了缰连方向都把控不住跑得多快反而意味着栽得多狠。祝大家都能在这个AI强势介入的时代仍然握得住系统的方向盘。
