一组新模型与现有模型在 SWE-bench 各子项上的跑分差距，再次点燃了「最后一代人类程序员」的讨论。本文梳理争论中的三类核心分歧——上下文上限、新人入行机会、职业形态变化，并给出一份可执行的应对清单：如何用验证闭环约束 AI 产出、如何拆分长任务、哪些判断必须留在人手里。
一组跑分，把「最后一代程序员」的话题又点着了
讨论的起点是一组模型对比数据：一个尚未公开发布的新版本，与当前在用的版本在 SWE-bench 几个子项上拉开了明显差距——Verified 子项 93.9% 对 80.8%，Pro 子项 77.8% 对 53.4%，多语言和多模态子项同样差了一大截。数字一摆出来，「写代码这行要没了」的声音立刻占了上风。
先泼一点冷水。这些分数来自特定基准，题目形态、评分脚本、是否允许检索仓库、上下文怎么喂，都会影响结果；更关键的是，其中一个模型还没有对外开放，真实项目里的表现无法复现验证。基准衡量的是「在给定仓库里修好一个已有测试覆盖的缺陷」，而日常工作中大量时间花在搞清楚要做什么、这个需求该不该做、改动会不会连带影响别的系统——这部分并不在计分范围内。所以值得讨论的不是数字本身，而是数字背后反复出现的几类分歧。
分歧一：上下文是不是那道过不去的墙
一部分人认为，只要上下文问题解决不了，AI 就永远只能当助手：一次会话能装下的代码量有限，跨模块的隐式约定、历史包袱、只在老员工脑子里的「为什么这么写」，很难完整交代给模型。项目一大、维护周期一长，全自动生成的代码就会失准。
另一部分人反驳得很直接：人类学习本身也是模式匹配，记忆力、精力、成本都不占优，凭什么认为「理解」是人独有的。
两种说法都有道理，但落到工程实践上，真正的问题不是「上下文窗口有多大」，而是「有效上下文有多少」。窗口再长，塞进去的无关文件越多，模型注意力越分散，出错率反而上升。可控的做法是主动管理上下文，而不是指望窗口无限增长：
- 在仓库根目录维护一份约定文件（如
CLAUDE.md、AGENTS.md），写清技术栈、目录职责、命名与提交规范、禁止改动的区域； - 一次只让它处理一个可独立验证的改动，不要「顺手把整个模块重构了」；
- 把需求拆成「输入—预期输出—验证方式」三段，验证方式优先写成测试；
- 长任务分阶段提交，每阶段跑一次测试再继续，避免错误层层累积。
分歧二：新人是不是真的没机会了
这是整场讨论里最扎心、也最现实的一条。有回复说得很坦白：以前团队会招实习生或应届生打杂写简单模块，那正是新人熟悉代码库、建立手感的入口；现在熟练工借助 AI 一个人能顶几个人的产出，这类岗位直接被压缩了。
与之相对的观点是：门槛降低应该吸引更多人学编程，而不是劝退。但反驳也成立——门槛降低和需求增加是两件事。如果市场需求没有同步扩大，那么「底层岗位减少、高级岗位提效」的组合，结果就是中间层被挤压。
在这一条上，各方没有共识，也不存在放之四海皆准的答案。比较稳妥的判断是：
- 单纯「会写 CRUD」不再构成竞争力，这部分供给已经过剩；
- 能把模糊需求拆成可执行方案、能判断 AI 产出对不对，这类能力仍然稀缺；
- 新人用 AI 的正确姿势是「先自己写、再让 AI 对照挑错」，而不是「让 AI 写、自己看不懂就提交」。前者练的是判断力，后者练的是复制粘贴。
如果所在团队仍在招新人，可以主动争取有明确验收标准的小任务，哪怕它很小——能跑通「读代码、改代码、验证、说明理由」这个完整闭环，比写多少行更重要。
分歧三：是消失，还是换个形态
「程序员」这个词本身就有歧义。如果定义成「敲代码的人」，那这部分工作的确在被大量接管；如果定义成「用工具解决计算问题的人」，那只是工具从手写代码变成了描述需求加审核产出。有人开玩笑说这是「最后一代古法编程」，其实说中了要害：变的是工作方式，不是问题本身。
另一个常被提起的类比是纺织业——机器替代了大量手工纺纱，但行业仍在，只是岗位结构完全变了。也有反对意见认为，代码不是一锤子买卖，交付之后还有长期维护、责任归属和事故追查，而「出了事谁签字」这件事，AI 目前接不住。
比较务实的看法是：岗位总量可能收缩，但角色会向两端分化——一端是能把系统边界、取舍和风险讲清楚的人，一端是能把 AI 工具链搭好、把产出管住的人。中间那层纯执行的工作，是最先被压缩的。
一份可执行的应对清单
与其争论会不会被取代，不如把手上流程改造成「AI 可加速、但错误拦得住」的形态：
- 先建验证闭环，再谈提效。 单元测试、类型检查、lint、CI 至少要有两样能自动跑起来。没有验证手段的模块，不要让 AI 直接改动。
- 权限最小化。 只给必要的文件读写范围，禁止直接推送到主分支，所有改动走合并请求和人工审查。
- 把约定写成文件。 架构决策、目录职责、禁用依赖，落到仓库里的文档，比每次在对话里重复交代可靠得多。
- 任务切小、提交切碎。 一个提交对应一件事，出问题能快速回滚和定位。
- 架构和技术选型留在人手里。 两个项目看起来再像，约束条件也不同，套用「最常见做法」经常是错的。
- 长任务要有稳定的运行环境。 批量重构、跑全量测试、长时间对话式开发，最怕机器休眠或网络抖动打断会话。如果本地设备性能有限或网络不稳，一种可选做法是把这类任务放到一台长期在线的远程 Mac 上执行（例如整机托管在机房、按月租用、远程连接的独享 Mac mini），让运行时长和环境更可控；这不是必需项，先确认自己的工作流和合规要求是否适合。
- 留痕。 记录每次让 AI 改了什么、为什么改、验证结果如何，出问题时这是唯一能复盘的线索。
需要提醒的边界
- 跑分不等于实战。 基准成绩能说明趋势，不能说明你的项目里它一定好用。上新模型前，用自己仓库里的真实任务做小样本对比，比看排行榜可靠。
- 模型能力和可用范围会变。 具体版本、开放地区、配额政策请以官方最新说明为准，不要依据二手转述做技术选型。
- 责任在人。 无论是代码审查、上线决策还是事故处理，签字的一方需要能解释清楚逻辑，这一条短期内不会因为模型变强而改变。
- 不要把敏感代码和凭据交给不可控的渠道。 使用前先看清数据使用条款和团队的安全规范。
小结
这轮讨论里，最激进的「马上取代」和最坚决的「绝无可能」都不是主流。更常见的态度是：AI 已经把大量执行层面的工作接了过去，把入门岗位的入口挤窄了，但把「定义问题、设计方案、判断结果、承担责任」这几件事留给了人。真正需要焦虑的不是职业会不会消失，而是自己是否还停留在只做执行的那一层。把验证闭环建起来，把上下文管起来，把判断力练出来，无论工具怎么换代，都还有位置可站。