Robert Haas · PostgreSQL 提交者 · 阅读原文
原始来源：Robert Haas · PostgreSQL 提交者
PostgreSQL 提交者 Robert Haas 在10月21日发表于 Neon、10月30日转载到个人站的文章中，解释了一个反直觉的结果：AI 更会找缺陷，版本发布却可能更慢。旧代码里本来就存在问题；现在更多人借助模型发现它们，维护者还要判断修复是否正确、是否符合项目标准，以及应回补到哪些旧版本。
他比较两年4月8日至9月25日的提交记录，称准备发布的稳定分支提交由724增至1169，较旧稳定分支由248增至433。提交次数不是缺陷个数，也不能单凭增长率证明全部由AI引起；“发现比修复加速更多”是维护者结合实际工作的解释。团队处理旧版本安全和正确性问题，也挤占了评审新功能的时间。
本轮另查发布团队邮件及当前开发跟踪页：第二个候选发布版（RC2）计划在11月12日推出，正式版计划为11月19日。邮件明确希望先把大量回补修复带入候选版。延期和回补压力有原始记录支持，AI造成多大比例的压力则没有独立因果测量。
可信度 65 · 重要性 84 · 新颖度 75
技术与主题
AI 编程 · 评测与基准 · 缺陷发现 · 回补修复 · 人工审查 · 发布管理
Robert Haas
长期提交者解释为什么缺陷更多地被发现，并没有改变他对代码库质量的评价。
忠实转述（非原句）：Haas仍把PostgreSQL视为自己参与过的高质量代码库。他不觉得短暂推迟本身特别可怕，因为这体现了对质量的坚持；真正没有答案的是，面对数十年累积、现在更容易被发现的问题，项目如何一边处理它们，一边继续创新。这个担忧针对维护容量，不能概括成AI把代码写坏了。
编辑评读
这条经历修正了一种过于简单的生产率读法：发现更多问题，既可能增加今天的工作，也可能减少今后的事故。若只数发布功能和交付时间，清理原本看不见的缺陷会显得像退步；若只数新增漏洞报告，又会把尚未确认、尚未修复的任务提前算成收益。两边都需要沿同一个问题追到最终状态。
更实用的观察单位是维护队列。应区分新代码引入的问题、历史存量缺陷、重复报告与误报，再看确认、修补、回补和发布各花多少等待与人工时间。Haas的材料支持“真实发现增加也会挤占新功能工作”这一可能机制，但没有给出全链路工时。为维护者附上最小复现、受影响版本和可检查的补丁，可能比多投递一份模糊报告更有帮助；这是待验证的流程建议。
需要留意
- 文章不是随机对照；提交数、缺陷数和人工时间不是同一指标。
- 正式发布日期仍可能调整，本文记录的是核对时的计划。