介绍一个技术大佬时，“给知名开源社区贡献过代码""某个核心功能的作者""某个模块长期 Reviewer”，通常都是非常有分量的履历。对于不少像我这种做 PG 开源数据库研发的人来说，能够向上游提交 Patch、参与社区讨论，甚至有一天成为 Committer，也是一条相当明确的成长路线。
那么，Contributor 到底有什么了不起的？（好吧我承认标题是博眼球的）
他们也是在读代码、写代码、修 Bug、讨论设计。过去我们可能会认为，他们厉害是因为源码读得多，代码写得深，能够完成普通研发难以完成的功能。
但现在，AI 已经能帮我们搜索代码、梳理调用链、生成实现、补充测试，甚至自己调用编译和测试工具，根据错误继续修改。当写出一个 Patch 越来越容易时，Contributor 和普通研发之间真正的差别还剩下什么？AI 可以帮助我写出越来越多的 PostgreSQL 代码，但它能帮助我成为一个真正的 Contributor 吗？
最近的整理
最近我一方面在大量用 AI 写代码、做功能和修 Bug，另一方面因为准备一场 AI Agent 相关的培训，重新梳理了一遍大模型和 Agent 的工作方式演进。
以前用 AI 写代码更多是问答式的：贴一段代码让它解释，描述一个错误让它分析。现在的 Agent 不只是”给出答案”了，它可以搜索整个仓库，阅读相关文件，执行命令，查看编译结果，运行测试，再把新的结果放回上下文继续下一轮修改。
坦率地说，这种体验很好（好到让人有点心虚）。过去需要花很长时间搜索和拼接的信息，现在能快速得到一个相当完整的初稿。一些以前因为不熟悉代码入口而迟迟没有开始的功能，现在也更容易动手尝试了。
但与此同时，一个问题也越来越难回避：代码做出来了，是否意味着我真的掌握了这段代码？
代码和”拥有”是两回事
AI 最容易给我的并不是明显错误的代码——明显错误反而好处理，编译失败、测试失败，继续修就是了。更难处理的是一种看起来相当合理的代码：局部逻辑通顺，风格接近原项目，测试能通过，每个问题都有一套自信而完整的解释。但我自己无法确认这个解释是不是遗漏了一个更深层的系统边界（即使你可以不断问AI还有没有没考虑到的边界）。
我把这种状态叫作没有真正”拥有”这份 Patch。这里的”拥有”不是版权意义上的，而是一种工程责任：我能解释它为什么存在，为什么选择当前方案，我知道替代方案的取舍，了解它触碰了哪些系统边界，能回应 Reviewer 的追问，也愿意承担它合入之后的维护责任。
如果 Reviewer 每提出一个问题，我都需要把问题复制给 AI，再把 AI 的答案转发回去，那社区到底是在和我讨论，还是在间接地调试一个 Agent？
低效的过程，反而在训练我们
不要误会，标题的意思并不等于”我们还是应该少用 AI，坚持亲自读代码、亲自写代码”
亲自敲下每一行代码并不会天然带来深入理解，传统开发中一样有大量复制粘贴和只求测试通过的工作方式。花几个小时搜索一个函数入口，本身也没有什么高贵之处。
问题在于，过去那些看起来低效的过程，确实会在不经意间训练我们：为了找到修改入口，我们不得不阅读周围代码；为了处理编译错误，我们不得不理解某些数据结构；为了排查异常，我们逐渐看到正常路径之外的并发、恢复和失败场景；为了回复 Review 意见，我们需要阅读历史邮件，理解为什么某些看似简单的方案过去没有被采用。
这些过程虽然低效，却会附带产生理解。现在 AI 帮我们跳过了许多执行过程，节省下来的时间是真实的，但被跳过的认知过程也是真实的。真正的问题不是”要不要回到古法编程”，而是跳过了被动学习以后，怎么主动补回被跳过的理解？
Contributor 真正稀缺的能力
回到最开始的问题。如果只是从代码生产能力来看，这种能力确实在快速贬值。AI 可以记住更多 API，可以更快搜索实现，也可以同时阅读远超人类工作记忆容量的代码。
但我觉得，Contributor 真正稀缺的从来不只是把功能写出来。
首先，他们知道一个模块是怎么工作的——主要调用链、核心数据结构、状态流转。但更重要的是，他们知道系统为什么这样设计：哪些复杂性来自并发，哪些步骤在保护崩溃恢复，哪些接口已经形成兼容承诺，哪些看似重复的状态实际上承担了不同职责。
再进一步，他们能判断一次修改触碰了什么：是否破坏了某个隐含不变量，是否把局部问题放到了错误的层次解决，是否增加了超过收益的系统复杂度。（资深 Contributor 最有价值的贡献不只是写出方案，还包括指出这个功能现在根本不应该做 —— 这种情况在日经月经问题上尤其常见。）
Review 带宽才是最容易被消耗的
一份 Patch 需要有人理解、测试、质疑、比较替代方案，最后才有可能进入主干。对于 PostgreSQL 这样的基础软件，合入还意味着未来长期的兼容和维护责任。
这里有一个明显的成本不对称：借助 AI 生成一个 Patch 可能只需要几小时，但 Reviewer 理解它的设计可能需要几天，验证并发、恢复和边界场景可能更久，合入后的维护责任可能持续很多年。AI 可以快速扩大 Patch 的供给，但不会自动增加同等数量的资深 Reviewer。
而且，一个没有被作者充分理解的 Patch，也可能看起来相当成熟——结构完整、代码风格一致、有测试、Commit Message 逻辑通顺。Reviewer 的任务于是从”找出明显错误”变成了”证明一个看起来很合理的设计为什么并不真正成立”，后者往往更费精力。
Linux 内核社区的应对方式很直接：AI 可以参与代码生产，但不能进入责任链。提交者必须理解自己的整个提交，并准备回应 Review 意见；做不到，就不应该提交[1][2]。PostgreSQL 社区也已经开始在 2026 年的 Committers Meeting 中正式讨论类似问题，讨论内容直接参考了 Linux 的方式[3]。
想成为 Contributor，稳妥的方式是从模块和 Review 中长出来
如果希望有一天能 Review 设计而非只检查代码，我能想到的路径仍然比较传统：选择一个模块，长期扎进去。
这种”扎进去”不是拒绝 AI，也不是要求自己背下每一个函数。真正要建立的是一个能够用于推导新问题的系统模型——比如研究 WAL 模块时，不止要知道某个入口函数最终调用了什么，还要逐渐理解哪些状态是权威的，哪些可以在故障后重建，任意一步崩溃之后系统依靠什么回到一致状态。AI 非常适合帮忙完成搜索调用链、总结历史 Commit、生成测试矩阵这些工作，但最后仍然需要自己把这些信息组织成一个可以反复使用的模型。
而且社区也一直强调，Review 不是成为 Contributor 之后才承担的义务，反而是成长为 Contributor 的主要路径。Review 别人的 Patch 时，你被迫练习另一套能力：寻找反例、识别隐含假设、判断测试是否真的证明了结论。从应用 Patch、运行测试、检查文档开始，逐渐进入自己熟悉的模块，再尝试参与设计讨论——这可能比一开始就让 AI 帮自己生成一个大功能更接近真实的成长路线。
最后
Contributor 了不起的地方，不是他们从来不用 AI，也不是他们能背下整个 PostgreSQL。他们同样会用 AI，而且会越来越多地用。
真正的区别在于：他们知道哪些信息可以相信，哪些结论还需要验证。他们能看见局部修改背后的系统边界。他们愿意为一次设计选择承担长期责任。更重要的是，社区经过一次次 Patch 和 Review 之后，开始愿意相信他们的判断。
AI 可以帮助我们更快地到达一份代码，却不能直接跳过这个建立信任的过程。至少现在不能。
节省出来的时间，也不应该全部用来生产更多功能（虽然老板可能不这么想）。至少有一部分，应该重新投入模块理解、历史研究，以及对别人 Patch 的 Review。
AI 会不会替我写代码这个问题，答案必然是会——毕竟懒是第一生产力。
但在它替我写完以后，我一定要继续问自己：我是否还在成长为一个能够真正掌握这些代码的人？