AI“氛围编程”背后：从效率神器到代码负债之王，缺的是工程纪律

前阵子技术小圈子里传得最凶的话题，不是哪个框架又发了新版本，而是某公司有位开发因为“氛围编程”被优化了。这个词上半年还是生产率的代名词，下半年已经成了裁员理由，落差大得让人恍惚。

所谓氛围编程，有人也直接叫 vibe coding，说穿了并不玄乎：你对着AI编码工具报需求——“我想要一个订单列表页，左边筛选右边表格，状态色用蓝绿”，然后一路 Accept 生成的大段代码，直到感觉“差不多了”。它和传统的“用AI辅助写代码”最大的区别在于：人只负责提方向和验收体感，不负责读代码和懂实现。代码是AI写的，人是那个“负责感觉氛围”的人。

今天想聊的不是新闻本身，而是这起典型事件背后真正值得警惕的东西：一个有着正常编程基础、被公司认可过产出的开发，是怎么一步步从“效率之星”变成“代码负债之王”，最后把工作赔进去的。纯责怪AI或者纯责怪个人都没意义，真正的病灶在用法和机制。

1. “氛围编程”走红后的三分天下：谁在玩，谁在裸泳

1.1 别把它当成高级版找答案

很多老程序员第一次听到氛围编程，第一反应是“这跟我当年复制粘贴有什么区别”。还真有区别。当年从技术论坛找答案的场景是：带着一个已经发生的报错，去找一个已知的、别人验证过的解决方案，粘进来之后你大概率还会顺手改几行。这里有个隐含前提——答案的真实性是可以追溯的，你不放心还能看看底下几百楼的讨论怎么评价它。

AI生成的代码不具备这个前提。它输出的是一段看起来完全合理、局部符合你上下文、但没有经过任何真实运行或社区检验的文本。也就是说，你面对的不再是“真但需要调”的方案，而是“真伪未知的华丽文本”。氛围编程最危险的地方不是它偷代码，而是它让人失去了对输出做真实性判断的能力。判断不了，就只能靠感觉，而感觉恰恰是最容易被“看起来工整”欺骗的。

你可以把这件事类比成点菜：以前是照着别人吃过的菜单点，虽然也可能踩雷，但至少评价可查；现在是让一位热情的新厨师自由发挥，菜单写得天花乱坠，端上来之前你根本不知道里面放了什么。体面、快速、有氛围，唯独不可控。

1.2 玩氛围编程的其实是三种人

第一种是老手。他们代码素养扎实，把AI当结对伙伴用，生成完照样逐行审，遇到不懂的马上让AI解释并亲手验证。对这种人，氛围编程只是加速器，翻车概率低，也是行业里真正靠AI吃到红利的那批人。

第二种是半熟手。能看懂常见代码，但没有足够经验判断设计是否合理，也缺乏把“直觉不对劲”转成“具体技术质疑”的能力。这种人是高危人群。你能想象他每天的节奏：需求来了，打开会话窗口描述需求，Accept，跑一遍能跑，提交。代码确实能跑，bug也不常出现，但没人比他更不清楚自己刚才合了什么进主干。

第三种是纯新手。连基础逻辑都要问AI，产出高度依赖工具，一旦AI给出的方案超出训练分布，立刻原地停摆。按常理说最该出事的是第三种，但实际被请走的往往是第二种。原因很现实：第三种撑不到月度考核就被发现了，而第二种可以用“像模像样的产出”遮掩两三个月，直到问题集中爆发。

1.3 公司为什么最初愿意买单

公司层面对氛围编程的容忍，本质上是被三个因素撑起来的。

其一，管理层的度量标准是“可见产出”。氛围编程在可见产出上的表现力极强：半天一个页面、一天一个看板，目录结构、注释、函数命名都像老手手写。以PR数量、功能点、页面数为主要指标的管理方式，很容易把这种“表象专业”当成交付质量。

其二，演示文化的掩护。演示环境里走的是造好的数据、最顺的路径、最干净的交互，氛围编程恰恰在这条路上表现完美。它的缺陷藏在第二条路径、第三个参数、第五百个并发请求上，在Demo现场根本不会暴露。

其三，所有人都在默认“AI辅助开发是大势所趋”，没有人想做那个限制AI使用的“老古董”。这导致最早期的轻度失控没人过问，等大家反应过来时，代码库已经变成一堆没有人类心智锚点的拼接物。到这一步，问题的规模就已经超出了个人能力圈。

2. 复盘失控链条：从“两天一个看板”到“没人敢碰”

这种失败很少是瞬间发生的，它通常走完四幕，每一幕单独看都不致命，连起来就是职业终点。

2.1 第一幕：闪电交付带来的虚假安全感

模拟项目X（一个内部月度数据看板）起初非常顺利。负责的同事入职第一周，用AI两天搭出了完整原型，包括登录、筛选、图表联动，界面质感比许多老项目还好。业务方看到了，管理层看到了，所有人都觉得“捡到宝了”。

那段时间的代码评审几乎流于形式。与会者看到他提交的PR有模有样，没人逐行读，因为“一个两天跑出来的东西能有什么大问题”。这种集体性的放松警惕，给后面所有失控埋下了伏笔。氛围编程最大的迷惑性就在于此：它在短期内的确能产生真实的业务价值，让你没有理由去怀疑它正在积累的长期成本。

2.2 第二幕：需求一改，代码开始“互相打架”

第二个月需求开始变化：筛选维度要加两个，某个图表要从柱状换折线，权限要从角色改成部门加角色的组合。这些改动在老代码上属于常规操作，但在这套AI生成的代码上，每次修改都像在玩扫雷。

AI没有跨会话的长期记忆，也没有对整套项目架构的稳定理解，它每次只根据当前会话的局部上下文做“看起来最合理”的局部修改。于是，A模块的一位字段被顺手改名，B模块从数据库读取逻辑里多了三层空值包装，图表组件的数据口径在三次迭代中换了三种定义。功能仍然能跑，但所有人已经说不出它到底是怎么跑起来的。

这一阶段有个很有意思的信号：那位同事开始花越来越多的时间“跟AI解释现状”。每次改需求前都要先把上一轮代码贴进对话框，让AI先看看，再描述要改成什么。他的实际工作效率从第一周的一天十个提交，掉到了后面的一天改一个bug还要过夜。氛围编程的“快”，在这里第一次被证明是透支性的。

2.3 第三幕：代码评审变成“AI答辩会”

评审会议后来逐渐变了味。问“这个接口为什么设计成同步调用？”答“AI说这样简单”；问“状态机里这个回退分支什么条件下触发？”答“之前有个bug，AI加了这段防御”；问“这个缓存过期时间怎么定的？”答“我设了两分钟，AI说够用”。

被评审者姿态诚恳、有问有答，但每个问题的源头都是他聊天窗口里的某一轮对话，而不是项目文档、架构评审或设计讨论。他变成了一座人肉API——你问他什么，他回去问AI，再把答案转发给你。问题是AI的解释和代码的真实行为经常对不上，而全场没有人能当场验证。

我把这个阶段称为“责任蒸发”。当代码是AI生成的、解释是AI给的、决策依据也是AI建议的，那么出了问题到底该谁负责？在团队协作层面，这种模糊地带比bug本身更致命。因为正常的工程管理依赖“责任人能解释自己的决策”，而氛围编程直接把这条链路剪断了。

2.4 第四幕：一次小事故点燃导火索

真正引爆是一次不算大的事故：某天定时任务把一批空数据写进了线上库，特定账号登录后看板直接白屏。按正常流程，收到反馈的第一件事是读代码定位问题，结果发现相关逻辑这一周被AI改过四处，每处都加了看起来合理的空值处理，其中一处把空值“吞掉”了——异常被捕获后静默返回，日志里什么都没有。

排查用了整整两天，最后是通过翻聊天记录反向考古，才发现第七轮对话里AI擅自加了这个吞错逻辑。当这个结论被放上复盘会，问题就不只是“bug难查”了，而是“这个人的代码没有任何人具备排查能力，包括他自己”。公司算了一笔账：继续让他在岗，意味着每条依赖他的业务线都要预留额外的维护人力，风险还不可控。让他走，几乎是唯一理性的结论。

这里我想说句公道话：被请走不是因为用了AI，而是因为把不可维护性变成了团队的公共负担。任何一个工程组织，最不能容忍的都是“产出无法被接住”的人，不管他的产出是手写的还是AI生成的。

3. 四个裂开的盲区：氛围编程的黑箱究竟漏在哪

3.1 架构与抽象：模型看的是局部，项目要的是全局

任何软件能长期演进，靠的不是每行代码都写得好，而是抽象层级稳定、模块边界清晰。而会话式AI没有全局视野，它只能在当前上下文里做局部合理决策。如果人的指令只描述了功能，模型的默认做法就是按最稳妥的模板堆代码——工具类、状态枚举、配置全部平铺在一起，该抽象的地方不抽象，不该抽象的地方套上五层。

这种代码在规模小的时候跑得挺好，规模一上来，改动的影响面再也无法估计。举个实际例子，某次AI把用户资料的更新逻辑直接落到数据库操作，却在读取层包了一个写文件系统的缓存层，数据量上万之后磁盘IO暴涨，负责的开发毫无察觉，因为他本机演示时只有三条测试数据。这类问题根本不是“代码写错了”，而是“没有人做过架构权衡”，而架构权衡恰恰是AI最不擅长、也最不该由AI决定的事情。

3.2 调试盲区：人没有心智模型，所有假设都是瞎猜

传统调试的本质是建立心智模型：读代码、形成假设、用小实验验证。读到的是别人可读的代码，假设就有依据，验证就有效率。氛围编程把这个过程击穿了。代码不是自己写的，心智模型只存在于AI的参数空间里，你面对的是中了奖但不知道号码的彩票。

具体表现是：报错后把堆栈贴给AI，AI给了三种可能；照着改完，错误换了个样子；再贴回去，AI又给两种新解释。每一轮都“很像真的”，但都无法被人当场验证。用大白话讲：以前修车好歹能看见发动机在哪，现在整台车是个黑箱，修车师傅只能靠和卖车客服反复聊天来猜故障。

这也是为什么很多氛围编程的翻车现场都特别憋屈——不是没有排查工具，不是没有日志，而是原本应该由人脑承担的“假设”环节失效了。没有假设，什么工具都只是摆设。

3.3 测试真空：全绿，是因为测试和代码出自同一个爹

AI生成的测试有个通病：它们是“证明代码按当前实现能跑”的测试，不是“证明业务需求被满足”的测试。两者差别巨大。前者写出来必然全绿，因为测试和实现出自同一个生成过程，错误会被同源复制；后者要求测试作者具备先于实现的业务判断，而氛围编程者恰好最缺这个。

更普遍的现象是：测试只覆盖开心路径，边界条件、异常分支、空数据全被忽略。前面那个被AI“吞掉”的错误之所以没人发现，正是因为没有任何测试作者想过“如果这里是空值会怎样”。所以，一个团队如果全是氛围编程式的产出，测试覆盖率再高也可能是摆设——绿色只是集体幻觉的颜色。

我自己判断一份测试值不值得信任的标准很简单：找一行核心实现，故意改成错的，看测试会不会变红。如果测试纹丝不动，那它就是在陪代码演戏，删了也不心疼。

3.4 安全与性能：看起来能用，不等于扛得住

安全与性能问题在氛围编程里尤其隐蔽，因为它们平时不痛不痒，只在特定条件下爆发。

安全方面，AI的默认取值倾向往往是“看起来最像标准做法”。比如把第三方服务的访问凭据直接写进前端配置，因为模型见过的教程都这么干；又比如引入某个名字很“官方”的依赖，实际上根本没做过来源审查。功能是正常的，风险却挂在账上，直到某个安全评审才发现。

性能方面，AI习惯生成“教科书正确但工程危险”的写法：同步循环嵌套查询，一次页面渲染触发几十次数据库往返；无界列表加载；每次请求都重复编译同一个正则。单机演示完美，并发二十个用户就开始排队。这些问题在代码审查阶段不容易被发现，因为它们的触发条件依赖于运行规模，而氛围编程的验证环境通常只有一个本地样例。

4. 同样是AI辅助，为什么有人被高薪抢，有人被请走

4.1 分界线不在AI，在“你还能不能读代码”

如果把被优化者的特征列一个清单——从不通读生成代码、无法解释自己的PR、修改问题靠补丁、缺少测试意识——你会发现每一条都指向同一个能力空缺：读代码。会读代码的人把AI当作生成草稿的实习生，不读代码的人把AI当成永远正确的外包，后者注定在某一天为整个团队的不可维护性买单。

读代码能力包括三层：能不能快速定位一条数据流从入口到落库的完整路径；能不能在没有任何AI帮助的情况下把一段陌生代码的行为讲清楚；能不能在改动前判断改动的影响面。这三层能力在氛围编程时代没有被废除，反而成了求职市场上最硬的通货。

我顺手列个对照，方便你判断自己目前在哪一侧：

4.2 我给团队立过一条铁律：讲不清楚就不算会

凡是提交由AI生成的代码，必须能脱离AI，在白板上讲清楚三个问题：这段代码解决了什么业务问题；为什么选用当前的实现方式；如果输入出现边界情况会发生什么。讲不清楚，PR打回，哪怕功能演示再顺滑。

看上去很苛刻，但它过滤掉的不只是氛围编程，还有所有“知其然不知其所以然”的提交。规则执行一段时间后，团队里出现了一个很有意思的变化：有人开始主动要求AI先解释再生成，有人学会了在提交前用测试钉死自己的理解。铁律没有杀死效率，反而把大家从“改完就跑”的焦虑里解放了出来。

也有人质疑这会拖慢速度。我的回答是：降的是虚假效率，保的是真实交付。被AI加速十倍，然后被bug吃掉五倍，最后剩下多少，大家心里都有数。

4.3 想把AI当加速器而不是替罪羊，试试这三个动作

第一，让AI先写设计说明，再写代码。别一上来就“帮我改”，先问“现状是什么、改动会影响哪些文件、为什么这样改最合适”。把这轮问答的结论粘进PR描述或项目文档，你就把AI的思考变成了可追溯的人类知识。这招成本极低，但对后续排查和交接价值极大。

第二，让AI生成测试，然后手动“投毒”验证。随便挑一行核心实现把它改错，观察测试能不能变红。如果改错了测试还是绿的，说明测试和实现是同源面包，别指望它能保护你。这个动作每次合入前花十分钟，能把“假绿测试”从源头清掉。

第三，把“解释模式”放在“生成模式”前面。拿到陌生代码，先让AI解释每一段的职责，你自己确认理解之后，再让它动手改。很多氛围编程翻车，不是因为AI改得差，而是因为人根本不知道AI要改哪里。先建立共同上下文，再让AI执行，效率和安全性完全不是同一个量级。

5. 风波过后：团队该把“氛围”装在哪个笼子里

5.1 给氛围编程画一条清晰的沙盒边界

我的立场不是禁用氛围编程，而是分区治理。公司层面可以把代码分成两片：沙盒区用于原型验证、一次性脚本、内部演示工具，氛围编程在里面随便飞；生产区用于业务主链路、核心数据模块、对外服务，必须经过设计说明、代码评审、测试防线三道关。从沙盒搬进生产区之前，至少要有一个人能完整讲清楚它怎么工作。

这套规则的目的不是增加流程负担，而是确保“AI生成”和“人类负责”之间的责任链条清晰可见。出问题时，第一责任人永远是人，不是模型。沙盒区给了试错空间，生产区守住了底线，两边互不污染，这才是跟AI共事的正确姿势。

5.2 别让代码变成孤儿：定期做“代码朗读会”

另一个被忽视的问题是孤儿代码治理。AI生成的代码如果没有人维护心智锚点，两周后对全体同事来说都像刚捡到的——能跑，但看不懂。

我见过比较实用的做法是“代码朗读会”：每周挑一个由AI大比例生成且近期改动频繁的模块，让负责者把核心链路从头到尾用人类语言讲一遍，听众负责挑刺。不用讲全部，讲最核心的三条路径就够了。这个习惯一方面逼着负责者真正去读懂代码，另一方面让至少两三个人形成对该模块的备份认知，交接和排障成本立刻降下来。

朗读会还有一个隐藏收益：它会把“AI生成的代码”逐渐变成“团队共同理解并认领的代码”。一旦代码有了人类的所有权，它就不再是危险的黑箱，而只是普通的工程资产。

5.3 回归到个人：我的那点笨办法

回到开头那件事。被优化的那位同事也许有些冤枉——他只是把行业里最流行的生产方式用到了极致，没有人提前告诉他边界在哪。但作为旁观者，我更愿意把它当成一次集体预警：氛围编程的“氛围”应该形容工作心情，不该形容工程质量。

我自己现在的习惯是：跟AI协作时，把它当成一个速度快、知识广、但偶尔自信胡扯的结对伙伴。如果某一段代码落盘之前我没有逐行读过，它就不算我的代码；如果它要合入主干，我至少会有一两个测试能证明它的核心行为正确。这样做确实比纯氛围编程慢一截，但慢掉的那一截，正是我晚上能睡好觉的原因。