最近听到一个做硬件研发的人分享自己的经历，我觉得特别有意思的。 他说以前团队几个人一起开发一个系统，代码改动没有那么快，大家按照模块分工，定期提交、合并、测… · @UPing123zzz · TwKit

@UPing123zzz

最近听到一个做硬件研发的人分享自己的经历，我觉得特别有意思的。 他说以前团队几个人一起开发一个系统，代码改动没有那么快，大家按照模块分工，定期提交、合并、测试，虽然效率不算高，但协作流程还比较稳定。 后来他开始大量使用 AI 编程，一个人就能快速完成很多原来需要多人处理的功能，代码修改速度明显提高。结果反而出现了新问题：其他研发人员很难跟上他的节奏，原来的协作方式开始变得不太适用了。 尤其是涉及硬件的项目，问题更复杂。上位机软件、下位机、电路板、机械结构、摄像头和实际设备是关联在一起的。AI 可以很快生成代码，却不代表真实设备一定能正常运行。很多功能必须上机测试，验证成功之后才能继续往下开发。 这让我想到一个很有意思的问题：如果 AI 把代码生成速度提高了很多倍，但测试、评审和团队协作还是原来的速度，那系统整体效率到底提升了多少？ 我们现在很喜欢展示一个 Agent 半小时写出几千行代码，或者让几个 Agent 同时开发不同功能。看起来生产力爆炸，但代码写出来以后谁负责验收？多个 Agent 同时修改相同文件怎么办？一个模块的接口变了，其他模块知不知道？出了线上故障，又怎么找到是哪一次修改造成的？ 这些问题以前就存在，只是 AI 把代码生产速度提高以后，它们可能暴露得更明显。 我自己使用 Codex、Claude Code 时，也越来越觉得不能只关注它一次生成了多少代码。真正值得关心的是代码能不能维护，有没有测试，执行过程能不能追踪，换一个 Agent 接手之后能不能看懂之前的项目。 我听到有人已经在研究让不同 Agent 共享代码地图、项目记忆和即时文件锁，甚至重新设计协作机制。我觉得这个方向有意思，但现阶段对大部分开发者来说，Git、独立工作目录、模块边界和自动化测试仍然是非常有价值的基础设施。 尤其不能因为 AI 生成代码快了，就觉得人工审核和工程规范已经没有意义。 恰恰相反，代码生产越来越便宜以后，验证代码是否正确、判断架构是否合理、控制不同模块之间的影响，可能会变得更加重要。 我觉得以后程序员之间的差距，可能不只是看谁的 AI 能写更多代码，而是看谁能把这些代码稳定地组织成一个长期运行的系统。 生成代码只是开始，把系统交付出去并且持续维护下去，才是真正的工程能力。

曝光 391 · 评论 1 · 点赞 4 · 书签 1