AI时代的软件工程最佳实践

几周前，我写了一篇关于大多数 AI 生产力仪表盘都是虚构的的文章。此后不断有人追问我同一个问题的某种变体：“好吧，可我的团队到底该实际做点什么不一样的事？”

问得合理。那我们就来聊聊这个。

大多数工程组织，至今仍在按一份为“已不存在的世界”所写的剧本运行。过去十年定义“好工程”的那些实践，是为人类的局限而优化的——比如一个人的记忆力、重构成本、代码理解速度。而那些局限，如今绕过它们的代价已经便宜了很多。

这是诚实的重新排序。有三样东西，你可以悄悄停止投入；也有三样，本季度你就该加倍下注。

1、已经不再物有所值的那三个

1.1 死记硬背语法、API 和样板代码。

二十多年来，“把一门语言摸得滚瓜烂熟”一直是“资深工程师”的信号。它是“能不打断心流地把东西交付出去”的代名词。而这个代名词，已经失效了。

回想某个正则的确切形态、某个方法的签名、或者一个新服务的脚手架长什么样，都只是一句五秒钟的提示词。那些把自我认同建立在“百科式记忆”上的工程师，正在输给那些把认同建立在“判断力”上的工程师（这个我马上会展开！）。记忆从来都只是手段，人们只是舒服地把它错当成了目的。它让人舒服，是因为它让你感觉很资深。这正是人们停不下来的原因。

别再为这个招人了。别再为这个出题考人了。要招的是品味和判断力——那本才是记忆当初该代理的东西。小建议：别在软件工程师面试里让人去反转链表。

1.2 以“复用”之名过早抽象。

“别重复你自己”（DRY）这条福音，催生了一代被基类、辅助层，以及为那个“永远不会出现的第二个用例”而造的聪明泛型所窒息的代码库。

当初那种毫不留情的 DRY，理由在于“日后重构很贵”。而现在它便宜太多了。AI 能在几分钟里，把三个近乎重复的东西解开、重构成一个干净的抽象。重复，如今是远比“错误的抽象”便宜得多的错误。为今天的两个用例而构建。等第三个用例真的出现时再重构——而不是在你臆想它“可能会出现”的时候。

这，正是“感知上的优雅”与“实际的优雅”之间的那条鸿沟，也是大多数过度工程藏身的地方。

1.3 详尽而低价值的文档。

给每个 getter 写注释。把函数名已经说清的事再在 README 里复述一遍。那张在启动会之后就再没人打开过的架构图。这些，都是用来对冲“重读代码之成本”的保险。而那项成本，已经崩塌了。

AI 现在能按需读取、总结、解释代码，细节程度任你挑。文档依然重要——但仅限于它捕捉了意图与权衡、而未来的读者无法从代码本身重建出来的那些地方。那些机械性的东西，是死重；你的团队之所以还在被要求生产它们，仅仅是因为文档规范是这么写的。

注意这三者的共同点：每一个，都是对“AI 刚刚消除的人类局限”的一种绕行方案。如果你的某个实践之所以存在，是因为“读代码或写代码曾经很贵”，那它大概已经可以退休了。

2、刚刚变得不可或缺的那三个

2.1 CI/CD，以及快速交付的纪律

当一名工程师借助 AI，能在一下午里产出以往一整周的代码时，瓶颈就转移到了代码周围的一切上。合并。测试。部署。还有半夜十一点出状况时的回滚。

没有强健流水线的团队，如今生产 bug 的速度，已经快过他们交付修复的速度。CI/CD 曾经是一项竞争优势，现在它是入场门槛；而“有它”和“没它”的团队之间的差距，正在每个季度持续拉大。如果你的部署故事里还涉及“某个周二由一个人手动跑脚本”，那么 AI 会先让你的事故数量看起来像一根曲棍球杆，然后才让你的速度看起来像一根。

2.2 端到端测试

测试金字塔告诉我们要重度依赖单元测试，因为集成测试“慢、脆、写起来贵”。AI 把这三样里的两样给翻了过来。测试如今写起来便宜太多，维护起来也轻松太多。

与此同时，AI 生成的代码有一种非常特殊的失败模式：它在局部看起来合理，在全局却很诡异。它能通过评审，因为那个函数长得就像人类会写的函数。它会在组件之间的接缝处失败，在对状态的假设里失败，在所有人的单元测试都没覆盖到的集成点上失败。

单元测试能抓住 AI 已经不再写的那些 bug。E2E 测试能抓住 AI 真正在写的那些 bug。请相应地把你的测试投入挪过去。Playwright 会出现在你的未来里吗？

2.3 代码评审与品味

这是几乎没人投对资、而我却会把它排进清单第一名的一件事（不过为了阅读参与度，我把它放最后啦！）。

当下软件领域里最被低估的技能，是这种能力：看着一个能跑、能通过测试、AI 生成的 diff，然后说“这不对，而且是那种六个月后才显形、现在看不出来的不对”。品味——尤其是那种对“什么属于这个代码库”的直觉感受——是新的资深工程师超能力。

AI 会很乐意地生成这样的代码：它能编译、能通过测试、能上线到生产环境，却悄悄违背你团队奉为圭臬的每一条架构原则。你的单元测试抓不到它。你的 linter 抓不到它。你的 CI 抓不到它。唯一能抓住它的，是一个挣得了说“不，不是那样，原因在这里”的权利的资深工程师。

评审，如果它曾经是的话，现在也不再是一个官僚步骤了。它正是真正的工程正在发生的地方。如果你的评审文化是“一小时内两个 approve 然后 LGTM”，那你根本没有评审文化。你有的，是一个戴着挂绳的橡皮图章。

3、本季度该做什么

把你团队的工程准则、新人文档，以及晋升阶梯拿出来。对每一条列出的“最佳实践”，问一个问题：它是为了补偿“AI 现已消除的人类局限”而写下的吗？

如果是，就砍掉它，或者缩减它。别再在评审里衡量它。别再在招聘里给它权重。

然后看看，你团队的时间有多少花在了 CI/CD 投入、E2E 覆盖，以及由有品味的人主导的结构化评审上。如果这三样加起来，都没占到资深工程工时的一个有意义的比例，那你还在为旧游戏做优化。

4、信号

噪声，是“做我们一直做的事”所带来的那份安逸。记更多东西。更早抽象。给一切写文档。交付更快，评审更轻，信任工具。

信号，是认出那些本能里，哪些曾经真正“承重”，哪些只是肌肉记忆。曾经，“好工程”的一半意味着补偿人类做不到的那些快的事。AI 让其中大部分都变便宜了。剩下的，才是始终是真正活儿的那部分：判断力、整合性思考，以及在高速下安全交付的纪律。

如果你团队对“最佳实践”的定义，在过去 18 个月里没变过，那它就是错的。不是小错。而是会以静默复利的方式，滚进那个你将在 2027 年为之道歉的代码库里的那种错。

更新文档吧。

祝好运！

原文链接: AI Just Re-Ranked Software Engineering Best Practices. Over Half Your Docs Are Wrong.

汇智网翻译整理，转载请标明出处