「AI 辅助编码不能用于生产代码」——这位有十多年经验、一半时间在 FAANG 的 AI 软件工程师说:这根本不是事实。这篇高赞帖用 7 个步骤讲清他们团队怎么把 AI 引入生产级开发:重心依然在设计文档和评审上,AI 在写码环节做「战力倍增器」,而且永远先写测试。最终效果:从功能提案到上线,整体提速约 30%。
作者开门见山:发这个帖,是因为他见到太多人「开火」(flak)——不相信 AI 辅助编码能用在生产代码上。他的回应很直接:这根本不是事实(This is simply not true)。
接下来,就是他所说的「我们正开始这样把 AI 用于生产代码」的完整流程。
网络上关于 vibe coding 的争论常在两个极端:「AI 能替代工程师」vs「AI 代码全是垃圾」。这篇帖子的价值在于它是一线大厂工程师对真实生产流程的白描——它展示的既不是「无脑放手给 AI」,也不是「禁止 AI」,而是把 AI 嵌进一套本来就严谨的工程流程里。这也是它被斯坦福 CS146S 课程选为读物、被 AI 博主 Rohan Paul 转发的原因。(此段为帮助理解的增补,非原帖内容。)
注意一个关键事实:7 步里,AI 真正大显身手的是第 5 步(第 6 步初显潜力);前 4 步——设计、评审、拆解——依然是「人类的主场」,而且作者说,大部分工作量就发生在第 1 步的设计文档里。
一切永远从技术设计文档开始——大部分工作量就发生在这里。文档先以提案(proposal doc)的形式出现;如果能让足够多的利益相关方(stakeholders)认同提案有价值,才进入系统设计本身的展开:完整架构、与其他团队的集成等等。
在启动开发之前,先过设计评审:让团队的设计文档被资深工程师「彻底撕碎」(absolutely shredded)。作者说这是好事——他把这看作把痛苦前置(front loading the pain)。
设计里的错误越晚被发现,修复代价越高:评审阶段改一行文档,开发后期可能就是返工几千行代码。让最挑剔的人在动工前把问题全挑出来,等于把「将来必然要还的债」提前一次还清。(此为帮助理解的增补解释。)
通过评审后正式启动开发。但头几周仍在写文档:对每一个将由各开发小组负责构建的子系统,再做一轮更细的文档。
开发者与 PM(产品经理)和 TPM(技术项目经理)一起,把工作敲定成一个个离散任务(discrete tasks),并排定各个开发者处理它们的顺序。
终于,手可以放上键盘、开始「粉碎」任务工单了——AI 在这一步是战力倍增器(force multiplier)。他们采用测试驱动开发(TDD):先让 AI 编码智能体为要构建的功能写测试;只有在这之后,才开始用智能体去实现功能本身。
代码要合入 main,必须经过两名开发者批准的评审流程。AI 在辅助评审方面也展现出很大的潜力。
在 staging(预发环境)测试;staging 没问题,就推向生产环境(prod)。
作者的原话:整体上,他们看到从功能提案到功能上线生产,速度提升了约 30%——「这对我们来说是巨大的」(This is huge for us)。
FAANG 的 vibe coding 不是「跟 AI 聊出一个产品」,而是把 AI 嵌进一条本就严谨的流水线:设计文档打地基、评审把痛苦前置、AI 先写测试再写码、两人评审 + staging 收口——流程没变软,速度却快了三成。