当 AI 一个月写出 259 个 PR：软件工程正在发生的真实变化，而不是幻想

不是“AI 是否会取代程序员”，
而是“程序员的价值，正在从写代码转移到哪里”。

---

一、从一条推文说起：259 个 PR，不是段子

最近，一条来自 X（原 Twitter）的推文在技术圈被频繁转发，原文链接：https://x.com/dotey/status/2005069751920337194：

Claude Code，在一个真实项目中，一个月自动生成：

• 259 个 Pull Request

• 497 次 commit

• 净新增约 4 万行代码

• 净删除约 3.8 万行代码

这不是 Hacker News 上的玩具 demo，也不是课堂作业，而是一个真实项目、真实仓库、真实 CI 流水线中的产出。

很多人第一反应是两个极端之一：

• 😱「程序员要失业了」

• 🤩「AI 彻底写代码，人类只管喝咖啡」

但如果你真的做过中大型工程、系统级项目、浏览器内核、基础设施，你会意识到：
这件事真正重要的，不是“写了多少代码”，而是它暴露了软件工程价值结构正在发生变化。

---

二、我们必须先搞清楚一件事：AI 到底“写了什么”

1️⃣ 写代码 ≠ 解决工程问题

“259 个 PR”听起来很唬人，但工程师必须问一个更关键的问题：

这些 PR 是什么类型？

现实中，AI 当前最擅长的，往往是：

• 重构已有代码（rename、抽象、拆函数）

• 模板化修改（API 升级、接口迁移）

• 样板代码（boilerplate）

• 重复性逻辑（配置、adapter、glue code）

• 明确目标的 bugfix（能通过测试定义）

这些工作本来就不是工程中最具价值的部分。

如果你做过 Chromium、Linux、数据库、编译器，你会非常清楚：

真正困难的部分，几乎从来不在“把代码敲出来”。

---

2️⃣ AI 写得多，不代表它“理解得深”

AI 在这些项目中表现得像什么？

更准确的比喻是：

一个执行力极强、但不对结果负责的初级工程师。

它可以：

• 快速铺开大量修改

• 不疲倦地尝试

• 按既有模式扩展

但它不具备：

• 对系统边界的敬畏

• 对历史技术债的真实理解

• 对线上事故的恐惧

• 对性能、内存、兼容性长期影响的直觉

而这些，正是成熟工程师的核心价值。

---

三、这条推文真正说明的，不是“AI 强”，而是“代码不值钱了”

1️⃣ 写代码，正在成为“廉价能力”

这其实并不新鲜。

历史上类似的转变发生过多次：

时代	稀缺能力
汇编时代	写高级语言
C 时代	操作系统抽象
Web 初期	全栈开发
框架时代	业务建模
AI 时代	问题定义 & 决策

代码产出本身，正在快速去稀缺化。

AI 的出现，只是把这个趋势加速到了一个让人无法忽视的程度。

---

2️⃣ 真正稀缺的，是这三件事

从工程视角看，AI 暂时无法替代的能力高度集中在三个点上：

🧠 1. 问题建模能力

• 这是 bug 还是 feature？

• 是局部修补还是架构问题？

• 该不该做，而不是怎么做？

🧱 2. 系统边界与约束理解

• ABI 是否稳定？

• 是否破坏向后兼容？

• 是否影响 sandbox / security model？

• 是否触发性能退化路径？

⚖️ 3. 风险判断与责任承担

• 出问题谁背锅？

• 是否值得上线？

• 是否要灰度？

• 是否要 rollback？

AI 目前完全不具备“责任感”，也无法真正理解风险的长期后果。

---

四、为什么“PR 数量”是一个危险的指标

1️⃣ 工程质量 ≠ 提交频率

如果你当过 Reviewer，你一定遇到过这种情况：

PR 很大，看起来很“努力”，
但你内心只有一句话：
“这玩意儿我不敢 merge。”

AI 生成的 PR，天然存在几个风险：

• 修改范围过大，边界模糊

• 上下文理解不完整

• 隐含假设过多

• 缺乏历史背景

Review 的成本并没有消失，只是从“写代码”转移到了“看代码”。

---

2️⃣ AI PR 的真正瓶颈：Review

现实中最常见的情况是：

• AI 能生成 10 个 PR

• 人类最多有精力认真 Review 2 个

于是工程会出现一种新型瓶颈：

不是写得慢，而是“不敢合”。

这对大型项目尤其致命。

---

五、对安全、基础设施工程师来说，风险甚至更大

你如果做过以下任一领域：

• 浏览器内核

• 安全沙箱

• 网络栈

• 密码管理

• IPC / 多进程架构

你会非常清楚：

“看起来没问题的代码”，往往才是最危险的。

1️⃣ AI 对隐含安全模型几乎是“盲的”

比如：

• 为什么这个函数必须在 Browser Process？

• 为什么这里不能跨 Profile？

• 为什么这个 flag 默认是 off？

• 为什么不能提前初始化？

这些都不是代码层面的问题，而是设计约束。

AI 很容易在“合理重构”的名义下，破坏这些隐性规则。

---

2️⃣ 安全事故的代价，AI 不会承担

• 数据泄漏

• 权限绕过

• 沙箱逃逸

• 合规风险

这些事故不会记在 AI 的履历上，只会记在 工程师和团队的事故复盘里。

---

六、那这是否意味着 AI 编程“没价值”？

恰恰相反。

AI 的真正价值，不在于“替代工程师”，而在于：

放大工程师的有效判断。

---

七、一个更健康的 AI 编程定位模型

我更倾向于这样一个分工模型：

层级	责任
人类	定义问题、设定边界、做最终决策
AI	执行、尝试、铺开、验证
系统	测试、CI、监控

AI 更像是：

一个永远不累的执行层，而不是决策层。

---

八、工程师应该如何应对这次变化？

1️⃣ 刻意从“写代码”升级到“设计系统”

如果你现在还把自己的核心竞争力定义为：

• API 熟练度

• 语言熟练度

• 框架熟练度

那么你确实会被 AI 快速追平。

你应该转向：

• 系统设计

• 性能与稳定性

• 复杂问题拆解

• 风险控制

---

2️⃣ 学会“指挥 AI”，而不是和它比赛

未来更重要的能力是：

• 能不能把问题拆成 AI 能执行的子任务？

• 能不能识别 AI 生成结果的风险？

• 能不能高效 Review 和收敛？

这是“技术领导力”的雏形。

---

九、回到那条推文：它真正的意义是什么？

不是：

“AI 已经无敌了”

而是：

“写代码这件事，终于被拉回了它本该处于的位置——工程的下游。”

---

十、结语：这是工程师的危机，还是升级机会？

历史已经多次证明：

每一次工具革命，淘汰的都不是工程师，而是拒绝升级认知的工程师。

AI 不会取代你，但它会：

• 取代不思考的人

• 放大有判断力的人

• 加速工程分层

---

一句话总结：

当 AI 能写 259 个 PR 时，工程师真正值钱的，已经不是写 PR 的速度，而是决定“哪些 PR 值得存在”。