Kenton Varda在自己团队内部下了一道禁令:AI生成的变更说明,包括PR描述、commit信息、issue工单文字,一律不许用。理由很直接——这些文本"比没用还糟"。它们把代码里一眼就能看出来的细节又复述一遍,却漏掉了审查者真正需要的那句"为什么这么改"。
这条表态目前只能看到转引版本,原始推文尚未找到可独立核对的来源。但抛开信源问题,他描述的失败模式本身值得琢磨——这不是"AI写得不够好"那么简单。
禁令具体在拦什么
拦住的对象很明确:PR描述、commit message、issue/ticket里由AI自动生成、未经人工重写的说明文字。
- 发生了什么.AI代理写变更说明时,倾向于逐行转述diff——改了哪个函数、加了哪个参数、删了哪一行
- 为什么讨厌.这些内容看代码本身就能看懂,写出来是冗余信息
- 真正缺的是什么.为什么要这么改、权衡过哪些方案、留下了什么隐患——这些只有作者本人知道
Varda审查PR时发现,自己反而要花更多时间在AI文字里"过滤",把没用的细节筛掉,再去猜真正的意图。文字越详细,噪音越多。
PR消息的价值从来不在"写得全"
传统上,PR描述和commit message承担的是决策记录功能,不是代码复述。diff已经能告诉你改了什么,消息要回答的是"为什么"。
言为心声,这句话搬到这里正合适。AI能仿其言,把语气写得流畅、把结构写得规整,但仿不出作者当时脑子里那次取舍。它没有经历那个决策过程,自然也写不出决策过程留下的痕迹。这不是模型不够聪明,是这类文本的价值锚点原本就在"人类意图"上,而这恰好是当前模型系统性缺失的一块。
- 风险.文字越详细、语气越像模像样,审查者越容易把它当真,反而放松了对"这段代码到底想干嘛"的警惕
一刀切会不会矫枉过正
Varda的做法是彻底禁掉,而不是要求"AI起草、人工编辑"的折中方案。这两者张力不小。
如果AI只是打个草稿,工程师在提交前补上"为什么"这一段,理论上能规避他说的问题。但现实是,一旦允许AI起草,人工补写意图这一步很容易被跳过——反正AI已经"写完了",谁还愿意再花时间重写。禁令的意义,某种程度上是把这道最后关卡重新焊死。
- 结论.这道禁令真正约束的不是AI能力,而是人的偷懒惯性——工具越省事,人越不愿意补那句"为什么"
谁该盯着这件事
首当其冲的是依赖AI编程代理的团队,尤其是承担code review的人——这类政策会直接改变review时该信谁、信多少。开源项目维护者也要考虑,commit历史这种长期可读、可信的资产,一旦被大量AI文字填充,后人溯源会更难。
有意思的是,GitHub、Claude Code、Cursor这些主推"自动生成PR摘要"功能的厂商,在这件事上目前没有公开回应或产品层面的调整——这个视角是缺席的。它们的默认卖点是省事,而Varda的判断恰恰是"省的这点事,代价是审查者要花更多时间"。
这是不是孤例,还是资深工程师群体里一个更普遍的不满,目前也看不清——没有更多公开跟进的团队或公司名单可以佐证。值得留意的,是接下来会不会有第二个、第三个团队公开类似的立场,以及工具厂商是不是会开始区分"表层摘要"和"意图说明"这两种完全不同的写作任务。