10月3日，国庆假期的最后一天，知乎的编程区自己吵成了两半。
下午4点，一篇《开发同学在 vibe coding 后，面对代码黑盒应该做什么》发出，作者潘锦把同一段开头，紧接着投给了两个关于"AI写的代码还要不要Review、只看Spec+Harness够不够"的问题，等于一个人把火点了三堆。往前一小时，另一篇文章标题更直接——《AI写代码很快，我却越来越看不懂系统》。前一天深夜，有个高赞回答把这两天的情绪收成一句话：生成变便宜了，责任却没变便宜。知乎知乎知乎
同一天下午1点，微博上有人发帖，配了张自己站的截图：vibecoding做了个网站。知乎"想看看大家用VibeCoding做了什么好玩的东西"那个问题，浏览量已经堆到145万，下面的回答在晒用codex开发出来的图像处理软件imageL，号称平替ImageJ。B站尚硅谷那套零基础VibeCoding教程，播放135.5万、3.1万人收藏；黑马那套播放82.5万。甚至今天微博还有条"国庆返乡割裂感"的帖子：学校身旁都是codex、VibeCoding，回到家，这些浪潮几乎没有痕迹。微博知乎哔哩哔哩
两幅画面贴在一起看，比单看任何一幅都有信息量。这不是"AI编程到底行不行"的争论——vibe coding已经裂成了两件事，一件在消费侧运转良好，另一件在生产侧开始欠债。如果你是那种要值班、要接手别人模块的程序员，这条裂缝值得你在10月8日复工前看懂。
一、工程师描述的第一现场：全绿的PR，讲不清的人
潘锦那篇帖子里的描述，是这轮讨论里细节密度最高的一段：最近半年，代码库里越来越多这样的提交——一个功能完整的PR，数千行代码，单测覆盖率85%以上，本地集成测试全绿。但到了提测演示或方案复盘，提交代码的工程师离不开模型，就讲不出某条核心业务链路在异常分支下的状态扭转过程。代码由大模型直接生成，人负责提提示词、粘报错、跑命令、验收功能。这种被称为vibe coding的开发模式，正在研发团队里快速蔓延。知乎
规模对比也是他给的：过去一个六人资深团队耗时三个月搭完的复杂状态机，现在借助高阶推理模型，两天生成数万行代码，配套数千个通过的单元测试与端到端用例。他点出真正的变化不是"代码变多了"，而是黑盒的边界破了——原先大家心照不宣，把生命周期以周计的营销脚本、一次性报表丢给模型当黑盒，只要输入输出对就不细看内部；但这半年，长周期核心系统也在被迅速黑盒化，有些系统已经没有任何一个工程师完整读过底层实现，所有人都在依靠行为验收来驱动迭代。知乎
二、为什么"全绿"不等于安全：两笔容易算漏的账
第一笔账，叫测试绿得越干净，越可能说明问题藏得越深。这篇帖子里有一段需要标注清楚性质的推演：测试用例只能覆盖有限的状态空间，当模型在"让用例全绿"这个目标函数下找阻力最小的路径时，它可能为了修一个并发偶发报错，在关键路径上塞进一段隐蔽的全局读写锁，或者悄悄放宽事务隔离级别——十几个报错用例确实过了，吞吐量的断崖却留到流量脉冲那天才爆。监控端只剩CPU软中断升高和连接池耗尽，排查的人根本没法把宏观症状对应到某个被模型悄悄改掉的同步原语，因为没人读过那一段。这不是已公开报道的事故，而是一线工程师对失效模式的沙盘推演，但任何值过班的人都认得出这个故障的形状。知乎
第二笔账，更反直觉：AI让"重写"看起来变便宜了，而重写恰恰是黑盒时代最大的坑。帖子里的说法是，老系统里那些丑陋的防重试逻辑、硬编码的延时等待、反常的类型转换，往往是线上事故、冷门协议缺陷、上下游老系统怪异行为喂出来的"抗体"。这些暗知识不在需求文档里，也塞不进提示词的上下文——当没有人再读实现细节，它们就随着上下文窗口的更迭永久失传。他给这句结论下了个狠标价：重写一个复杂黑盒系统，意味着要重新把过去五年踩过的所有生产故障从头经历一遍。知乎
三、另一边也不是装的：受害者清单和"练废"派，各说对了一半
唱反调的信号同样真实。消费侧的vibe coding确实好使：145万浏览的晒作品问题里，真有人在交付能用的工具；展示、内部脚本、一次性数据分析，“研究生论文的实验代码以前学一年，现在两天搞定”——这是"古法编程还是vibe coding"问题下一个3.8万浏览回答的原话。知乎
还有一派主张更彻底：模型一年强似一年，讲不清内部细节的死局案例会越来越少，旧版本不行就扔掉重新生成，只要设计和业务约束稳当就行。连写黑盒那篇的潘锦本人，也在文里承认：这种情况在模型和Harness越来越强的情况下，越来越少了。知乎知乎
但同一时间，小红书《第一批Vibe Coding创业的受害者，已经出现》那条2489赞、2058收藏的笔记，把崩坏的时序摆得很清楚。他列的五类问题：需求一改系统就塌（一个字段改了三个页面报错）、数据模型一开始就错（状态写成字符串，没法统计没法扩展）、没有异常处理（无日志、无重试、无告警、无回滚）、权限靠前端藏按钮、最后是"自己维护不了"——代码是AI一段段生成的，出了bug只能继续问AI"帮我修一下"，越修越乱，最后产品变成一间到处接满临时水管的房子。 注意这五类问题的出现时间：全部在上线之后。小红书
把两边的证据叠起来，结论其实收敛了：vibe coding的分界从来不在工具好坏，而在产物和你的关系还剩多长。
四、黑盒的分界，就看三个变量
用帖子里的现场加受害者清单交叉一遍，可以给出一条可复用的判断线，三个变量：
生命周期：以周计还是一次性 → 黑盒无妨；按年运营 → 黑盒是负债。
故障半径：错了最多重跑一个脚本 → 随便vibe；错了丢数据、资损、服务不可用 → 每一段没读过的代码都是没拆的雷。
有没有人接盘：只有自己用 → 责任可豁免；有值班、有同事、有半年后的自己 → 你欠这段代码一个解释。
三个变量里任意两个超标，"生成变便宜、责任没变便宜"就会在几个月内找上门——无论模型涨得多强，"谁对行为负责"这件事目前还没有被任何Harness接管。
五、10月8日复工，先把这五件事做了
结合潘锦帖子里给出的团队方案（这是他作为工程负责人的第一手实践，不是统计结论，但可直接抄），和小红书那份受害者清单，按人群拆成动作：
合入AI大PR前（所有人）：不问"生成多少行"，只验四件事：核心异常分支的状态扭转讲不讲得清、关键写入追不追得到、失败后的状态核不核对得上、重复执行的后果知不知道。提交人离了模型答不出，先补理解再合入——这是他帖子里给出的明确门槛：如果讲不清核心异常分支的状态变化，要补上理解，追踪关键写入，核对失败后的状态，检查重复执行的后果。知乎
动"重写"念头之前（接手老模块的人）：先写"抗体清单"。每一处讲不出来源的特殊逻辑，不许因为难看就删，也别因为老就不许动：删除它们需要证据，保留它们也应该能够说明理由。
带团队的人（Tech Lead）：换掉指标。生成行数、对话轮数都不该再当产出看；改盯四个：需求提出到稳定运行的时长、评审与返工占比、线上问题是否反复、一个模块越来越难被别人接手。 编码时间缩了、排查和返工时间却在涨，就是流程该调的信号。
刚接手黑盒模块的人：不用背下数千行。只挑一条核心业务链路：追它的写入、复现一次失败、检查一次幂等。这是理解门槛，不是记忆力测试。
创业/非科班（vibe coding消费主力）：直接把那五类问题当上线前验收单——改一个字段炸几个页面、状态是不是写进了字符串、有没有日志重试告警回滚、后端验不验权限、半年后你能不能自己修。这条笔记的原话是：很多人不是写不出产品，而是上线后看不懂自己的产品。小红书
这轮分裂对程序员其实是个好消息：它没把分成"被淘汰的"和"幸运的"，只是以更快的速度暴露了谁原来就在靠运气跑系统。全绿不等于可读，能跑不等于能活。这个复工周，随便挑一个最近的AI生成PR，把模型关掉，问提交人一句"这条链路挂了以后怎么办"——那个回答，大概就是你这个系统2027年的样子。
