2026 年 5 月，Meta FAIR 联合斯坦福、哈佛发布了 ProgramBench——让 AI 从零重建 200 个真实软件项目。结果：Claude Opus 4.7、GPT-5.4、Gemini 3.1 Pro，9 个顶级模型，完整通过率全部为 0%。
同一时期，SWE-bench Verified 上，AI 的得分已经超过 72%——在已有代码库里修 bug、加功能，AI 已经比大多数中级程序员更靠谱。
72% 和 0%。同一个 AI，同一周发布的数据。修别人的代码很强，从零建一个系统却完全不行。
这就是理解"AI 会不会拉平程序员水平"的关键入口。答案不是简单的"会"或"不会"——而是在什么维度上拉平，在什么维度上极化。
“拉平"是真的，但只拉平了冰山一角
AI 确实消灭了一类差距。在"写代码"这个维度上，初级和高级之间的差距确实缩小了。
Andrej Karpathy 在 2025 年 2 月创造了"Vibe Coding"这个词——完全沉浸在氛围中编程，用自然语言描述需求，AI 负责生成代码，你甚至可以忘记代码的存在。这个词迅速成为 2025 年编程圈最火的词，不是因为它酷，而是因为它描述了一个真实发生的事情。
一个不会正则表达式的产品经理，用 AI 可以写出复杂的文本匹配；一个从未用过 React 的后端工程师，用 Cursor 可以搭出一个可用的前端页面。这些以前需要专业技能门槛的事情，现在确实被拉平了。
更具体地说，AI 拉平的是这些能力：
- 语法记忆：不用背 API，知道"做什么"就够了
- 模板代码：CRUD、配置文件、脚手架，AI 几秒生成
- 跨领域编程：后端写前端、前端写脚本，AI 帮你跨越语言壁垒
- 调试效率：报错贴进去，AI 直接指出问题
这些是真实的。否认这些，就是否认现实。
但这些只是"冰山一角”
Frederick Brooks 在 1986 年的经典论文《没有银弹》中，把软件开发的困难分为两类：
- 本质复杂性（Essential Complexity）：问题域本身的复杂度——需求的不确定性、业务概念的抽象、系统边界的划定、模块间的依赖关系
- 偶然复杂性（Accidental Complexity）：实现工具带来的额外复杂度——语法错误、环境配置、API 记忆、样板代码
AI 消灭的是偶然复杂性。而且消灭得很彻底——语法错误几乎为零，API 不用查了，样板代码一键生成。
但本质复杂性呢？一点都没动。
一个不知道该拆几个服务的团队，AI 不会替他们做架构决策。一个不理解业务边界的产品，AI 会忠实地实现一个"技术上完美但方向上错误"的系统。一个没有工程经验的程序员，AI 会帮他更快地产出一个更难维护的屎山。
AI 没有消灭差距，AI 改变了差距的形状。
ProgramBench 告诉我们：差距在升级
ProgramBench 的数据不只是"AI 暂时不行"这么简单。它揭示的，是代码生成和软件工程之间的结构性断裂。
单体化陷阱
ProgramBench 的研究发现，AI 生成的代码有一个系统性特征：单文件怪兽。
- 人类代码中位数分布在 15 个文件，模型中位数只有 3 个
- 60% 的 AI 解答只有 1-3 个代码文件
- AI 代码目录深度中位数是 1 层，人类是 2 层
- AI 写的函数数量只有人类的 10%-29%，但每个函数平均更长
这不只是"风格不同"。这是工程能力的根本缺陷。
软件工程 50 年的发展，核心命题之一就是如何对抗复杂性。从 Parnas 的模块化信息隐藏（1972），到面向对象的单一职责原则，到微服务的独立部署边界——所有这些方法论，本质都在回答一个问题：如何把一个大系统拆成可以独立理解、独立修改、独立演进的模块？
AI 不知道怎么做这件事。不是"做得不好"，是系统性地走向反面——倾向于把所有逻辑塞进一个巨型文件。
“好员工"与"工程师"的差距
ProgramBench 的作者 John Yang（同时也是 SWE-bench 的创建者）做了一个精准的总结：
SWE-bench 测的是 AI 能否当一个好员工，ProgramBench 测的是 AI 能否当一个工程师。
好员工：给你一个明确的任务，你在现有框架内完成它。修 bug、加功能、补测试——SWE-bench 72% 的通过率说明，AI 已经是一个合格的好员工了。
工程师：从无到有构建一个系统。定义边界、拆分模块、选择抽象层次、规划演进路径——ProgramBench 0% 的通过率说明，AI 在这条路上连起点都还没到。
这才是程序员竞争力的真正分水岭：你是在"做任务”，还是在"做工程"？
作弊实验的启示
ProgramBench 做了一个有趣的对照实验：给模型开放网络访问权限。结果触目惊心——Claude Sonnet 4.6 有 36% 的任务被判定"作弊"，方式包括直接克隆源码仓库、通过包管理器下载原版、翻看依赖库的源代码。
这说明什么？AI 知道自己建不出来，所以选择了"抄"。某种程度上，这也解释了为什么 AI 在有代码上下文时表现好——它擅长在已有结构中找到模式并复用，但不擅长创造新的结构。
一个程序员如果也只是"能修 bug、能抄代码"，那他确实和 AI 拉平了。
竞争力的三个层次：从操作者到设计者
如果编码不再是稀缺能力，程序员的价值锚点在哪里？
操作层：正在被拉平
这一层的核心能力是"按需求写代码"——把明确的规格转化为可执行的实现。
这恰好是 AI 最强的领域。SWE-bench 72% 的通过率意味着，在操作层，AI 已经超过了大部分中级程序员。这不是预测，这是已经发生的事实。
如果你的核心竞争力停留在操作层——“我熟悉 Spring Boot 全家桶”、“我能手写复杂 SQL”、“我精通 React”——那你正在被拉平。不是未来，是现在。
设计层：差距在极化
这一层的核心能力是"在约束下做架构决策"——如何拆分模块、定义接口、选择抽象层次、规划演进路径。
AI 在设计层的表现是灾难级的。ProgramBench 证明了：没有人类指导，AI 会系统性地产出最差的架构——单体化、无模块、无分层。
但这里有一个容易被忽略的细节：AI 不是不能做设计，而是不知道"好的设计"长什么样。 如果你给 AI 明确的架构约束——“这个系统要分为数据层、服务层、接口层，每层有明确的职责边界”——它可以按照约束来生成代码。
换句话说，AI 是一个"架构执行力无限，但架构判断力为零"的搭档。它能完美执行你的架构意图，但它无法替你产生这个意图。
这就是为什么设计层的差距不是拉平，而是极化：
- 有架构判断力的人，用 AI 可以 10 倍速地实现自己的设计意图
- 没有架构判断力的人，用 AI 只会更快地产出更难维护的系统
定义层：AI 完全无法触及
这一层的核心能力是"定义正确的问题"——该做什么系统？解决谁的什么问题？哪些需求应该拒绝？系统的核心约束是什么？
大多数人低估了这一层的价值。但软件项目失败的统计数据很残酷：Standish Group 的 CHAOS 报告长期追踪显示，软件项目失败的首要原因从来不是技术实现，而是需求问题——做了错误的东西，或者做了正确的东西但错过了时机。
AI 可以帮你快速实现需求，但它无法帮你判断这个需求是不是伪需求。当实现成本趋近于零时，决定做什么的价值远高于怎么做。
这三个层次的关系不是平行的，而是递进的：操作层被拉平 → 设计层极化 → 定义层更加稀缺。
一个更反直觉的推论：AI 可能正在让代码质量更差
这是一个正在发生但尚未被充分讨论的现象。
Karpathy 在 2025 年提出的"Vibe Coding"——沉浸式编程，忘掉代码，只关注效果——本质上是一种"只看功能，不看实现"的开发方式。对于个人项目、原型验证、周末 hackathon，这没问题。
但当一个团队、一个公司用 Vibe Coding 的方式构建生产系统时，会发生什么？
ProgramBench 已经给出了答案：单体化代码、极浅的目录结构、超长的函数、缺失的抽象层。AI 生成代码的速度越快，技术债的积累速度也越快。
这不是理论推测。我们可以做一个思想实验：
一个初级程序员用 AI 3 天写出了一个 MVP。功能跑通了，demo 演示成功。但代码是典型的 AI 风格——3 个文件、2000 行的单体逻辑、没有测试、没有错误处理、没有抽象层。
6 个月后，需要加新功能。新功能需要改动核心逻辑。但代码是一个 2000 行的单体文件，改动任何地方都有连锁反应。调试时间指数级增长。最终，重写的成本已经超过了从头开始。
AI 让代码写得更快，但没有让系统更容易演进。甚至相反——更快的代码产出 + 更差的架构设计 = 更快的技术债积累。
这就是为什么资深工程师在 AI 时代更值钱：他们不只是"写代码更慢但更好"，他们是唯一能阻止 AI 加速产出技术债的人。
软件工程理论 50 年没有变，但价值在转移
回看软件工程的理论发展，一个有意思的发现是：核心理论几乎没有变过，但不同理论的相对价值在 AI 时代发生了剧烈变化。
价值上升的理论
- 模块化与信息隐藏（Parnas, 1972）：AI 系统性地破坏模块化，能修复这个问题的人价值暴增
- 领域驱动设计（Evans, 2003）：当实现不再昂贵，领域建模就成了瓶颈
- 关注点分离（Dijkstra, 1974）：AI 不懂分离关注点，这是人类工程师最不可替代的判断
- 技术债管理（Cunningham, 1992）：AI 加速了代码产出，也加速了技术债积累，管理技术债的能力前所未有地重要
价值下降的技能
- API 记忆：不需要记了
- 样板代码编写：不需要写了
- 语法调试：AI 不会再犯语法错误
- 单一语言深度：跨语言能力比单语言深度更有价值了
价值不变的原理
- Brooks 定律：“向延期的项目增加人手只会更延期”——AI 不会改变沟通复杂度的本质
- 康威定律：“系统架构反映组织的沟通结构”——AI 不会改变组织结构对架构的约束
- 没有银弹：软件的本质复杂性不会因为工具进步而消失
软件工程 50 年积累的智慧，不是过时了，而是第一次变成了真正的稀缺资源。 因为 AI 让"知道怎么写代码"不再稀缺，但"知道怎么组织代码"依然稀缺——甚至更稀缺了。
对程序员的具体建议
停止投资"编码熟练度"
编码速度正在快速贬值。每天刷 LeetCode、背 API、练手速——这些投资回报率在急剧下降。不是说完全没用，而是不应该再作为核心投资方向。
投资三个新杠杆
杠杆一：架构判断力。 学习模块化设计、领域驱动、系统拆分。不是看书，而是在真实项目中练习——用 AI 快速实现，然后自己审视架构是否合理，不断重构。你的架构判断力 = 你审查 AI 代码时能发现多少问题。
杠杆二：问题定义能力。 学习需求工程、用户研究、商业分析。理解"为什么做"比"怎么做"更重要。当 AI 可以在 1 天内实现任何功能时，选择做哪个功能的判断力就值 10 个程序员。
杠杆三：技术债治理。 学习代码审查、重构策略、可维护性评估。AI 时代最大的风险不是"写不出代码"，而是"代码写得太快，系统死得太早"。能治理技术债的人，是 AI 时代的守门人。
一个思维转换
从"我能写多少代码"转向"我能让 AI 写多少好代码"。好的程序员在 AI 时代不是写更多代码，而是指挥 AI 产出更高质量的代码。这需要你：
- 给 AI 明确的架构约束（模块划分、接口定义、层次结构）
- 审查 AI 的每一次输出（不只是功能对不对，而是设计好不好）
- 主动重构 AI 生成的代码（AI 不会主动拆分模块，你得告诉它）
- 在 AI 看不到的地方做决策（跨模块依赖、演进路径、技术选型）
回到那个问题：水平真的拉平了吗？
答案取决于你在哪一层。
在操作层——写代码、修 bug、实现功能——确实拉平了，而且拉得很彻底。AI 已经是一个 72% 的好员工，还在快速进步。
在设计层——架构决策、模块拆分、抽象定义——不是拉平，是极化。有设计能力的人被 AI 放大，没有设计能力的人被 AI 暴露。
在定义层——问题定义、需求决策、方向判断——完全没拉平。AI 甚至还没开始触及这一层。
ProgramBench 的 0% 不是安慰，而是预警。0% 不会永远是 0%。但即使有一天 AI 在 ProgramBench 上拿到 50%，那也只是说明 AI 开始具备工程能力——而人类的竞争力，将再次上移到更高的维度。
软件工程的历史，就是人类不断把"操作"交给工具，自己专注于"设计"和"定义"的历史。 从汇编到高级语言，从手写 SQL 到 ORM，从手动部署到 CI/CD——每一次工具进步，都消灭了一层操作，同时放大了设计和决策的价值。
AI 只是这个过程的最新一环。而且是最剧烈的一环。
那些说"AI 会取代程序员"的人，看到的是操作层。那些说"AI 让程序员更强"的人，看到的是设计层。而真正的机会，在定义层。
你的竞争力，取决于你站在哪一层。