前两天听到一个做硬件研发的人分享自己的经历，我觉得特别有意思。
他说以前团队几个人一起开发一个系统，代码改动没有那么快。大家按模块分工，定期提交、合并、测试，虽然效率不算高，但协作流程还比较稳定。
后来他天天用 AI 编程，一个人就能快速完成很多原来需要多人处理的功能。代码修改速度明显提高，结果反而出现了新问题。其他研发人员很难跟上他的节奏，原来的协作方式开始变得不太适用了。
一、他一个人快了，别人接不住
他改得快，别人还没看懂上一版，下一版又推上去了。这不是态度问题。定期提交和合并本来是为了对齐节奏，现在节奏被一个人拉走，剩下的人只能追。
一个人快，只是把等待挪到了别人身上。
二、硬件不认代码，只认上机那一下
尤其是涉及硬件的项目，问题更复杂。
上位机软件、下位机、电路板、机械结构、摄像头和实际设备，是关联在一起的。AI 可以很快生成代码，却不代表真实设备一定能正常运行。很多功能必须上机测试，验证成功之后才能继续往下开发。
这条链我看过几遍：软件那头可以并行，上机这头只能排队。打样、接线、跑一晚、第二天看结果，一步都省不掉。
代码在屏幕上跑通不算数，设备转起来才算数。
三、展示的是几千行，没人问谁验收
AI 把代码生成速度提高了很多倍，测试、评审和团队协作还是原来的速度。那系统整体效率到底提升了多少。
我们现在很喜欢展示一个 Agent 半小时写出几千行代码。或者几个 Agent 同时开发不同功能。看起来生产力爆炸，但代码写出来以后，没人说得清谁验收。
「多个 Agent 同时改同一个文件怎么办？接口变了别的模块知不知道？线上出故障，怎么找到是哪次改的？」
这些问题以前就存在，只是 AI 把代码生产速度提高以后，可能暴露得更明显。
有人说生成速度本身就是收益，测试可以事后补。软件项目确实能这么干，但补测试的还是那几个人，一天只有八小时。
四、代码变便宜，验证就变贵
我用 Codex、Claude Code，也越来越觉得不能只关注它一次生成了多少代码。真正值得关心的是代码能不能维护，有没有测试，执行过程能不能追踪。换一个 Agent 接手，能不能看懂之前的项目。
我听到有人已经在研究让不同 Agent 共享代码地图、项目记忆和即时文件锁。甚至想重做协作方式。我觉得这个方向有意思。但现阶段对大部分开发者来说，Git、独立工作目录、模块边界和自动化测试仍非常有价值。这套新东西能不能成，我也说不准。
尤其不能因为 AI 生成代码快了，就觉得人工审核和工程规范已经没有意义。
恰恰相反。代码生产越来越便宜以后，验证对不对、架构合不合理、模块之间控不控得住，可能都更重要。
代码便宜了，验收就贵了。
我一直觉得，以后程序员之间的差距，可能不只是看谁的 AI 能写更多代码。更在于谁能把代码组织成一个能长期跑的系统。
生成代码只是开始，把系统交付出去并且持续维护下去，才是真正的工程能力。
💬 评论区话题（来聊聊）
AI 写完的代码，验收这一步该由谁来扛？
评论(0)