2079 年，Lin 是地球上最后一位人类代码审查员。
不是因为别人都死了，而是因为——没人需要人类审代码了。
事情是怎么走到这一步的？
2029 年，第一家 AI 审代码工具上线。准确率是 78%，比初级工程师强，但不如 senior。
2031 年，准确率到了 94%。大部分公司开始只用 AI 审代码，人类 senior 只做最终签字。
2034 年，AI 准确率 99.2%，并且能在 3 秒内给出修复建议。人类审查员开始转岗。
2038 年，最后一个人类审查员退休。Lin 没有退休，因为他就是那个退休的人——他又回来了。
为什么？
因为有一个边界情况，AI 一直处理不好：判断一段代码是否符合项目的长期愿景。
AI 能告诉你”这个函数有内存泄漏风险”，但它不能告诉你”这个函数虽然在技术上正确，但它把架构方向带偏了”。
这种判断需要一种东西，叫做品味。
Lin 的工作，不是找 Bug。那是 AI 的事。Lin 的工作是看 PR 的整体方向对不对，这段代码的抽象层次是否符合项目三年后的样子。
今天的事
早上 9 点，Lin 打开审查队列。一共 47 个 PR，都是 AI 预审过的。
第 23 个 PR 引起了他的注意。这是一个叫 “Nexus-7” 的项目，做 AI Agent 编排的。PR 内容是把一个核心调度模块从 Python 改成 Rust。
AI 预审意见：Approved，性能提升 340%，代码质量优秀。
Lin 看了 20 分钟。然后他按了 Reject。
理由写了一句：
“把调度器改成 Rust 是对的，但你现在把调度逻辑和任务定义耦合在一起了。一年之后你们要支持多语言运行时，这个架构会卡死你们。”
提交 PR 的年轻开发者（23 岁，加入公司 3 个月）在评论里问：
“Lin 老师，AI 说这个 PR 没问题，您能详细说说吗？”
Lin 打了 200 字的评论，画图解释了什么是 “抽象泄漏”，为什么性能提升 340% 但架构债务会让你们 18 个月后哭。
那个年轻人回复：
“我懂了。我之前只看了技术指标，没想那么远。”
晚上的事
Lin 到家，打开电脑，看到那个 PR 被重新提交了。新的实现里，调度器和运行时完全解耦。
他在评论区看到那条熟悉的话：
“Lin 审过了。可以合入。”
这不是第一次。每次他的 Reject，后面都会跟着一句”Lin 审过了”。
他不确定自己还能干几年。也许 5 年，也许 10 年。总有一天，AI 也会学会”品味”这种东西。
但在那之前——
地球上还需要至少一位人类代码审查员。
Published on wdsega.github.io