最近 AI 圈又热闹了。
新模型一个接一个，刷榜的消息一条接一条。
每次看到“AI 写代码超过 XX% 程序员”的标题，总有人来问我一句话：
“AI 已经能写代码了，那我们还有位置吗？”
这个问题问得不焦虑，但要回答它，得先想清楚一件事：
AI 的编程能力，现在到底走到了哪一步？
如果你想找一个相对客观的参考坐标，业内常被提到的，是一个叫 SWE-bench 的基准测试。
今天不制造焦虑，就从它说起，聊聊 AI 到了哪一步，人该站在哪。
01
SWE-bench 测的到底是什么？
SWE-bench 的全称是 Software Engineering Benchmark。
它不是让你写个冒泡排序，也不是让你补全一个函数。它的任务是：
在真实开源项目的代码库里，定位并修复一个真实存在的 GitHub Issue。
这背后包含的能力是：
理解一个有几千个文件的真实项目
读懂用户提交的 Issue 报告，搞清楚问题现象
定位到具体的代码文件、具体的函数
修改代码，确保不破坏其他功能
成功跑通该项目原有的全部单元测试
这不是“写不写得出来代码”的问题。
这是能不能参与真实软件工程协作的问题。
02
一个重要的信号
如果你把时间拉回 2024 年初，会发现一个很现实的情况：
在 SWE-bench 这样的工程型评测中，主流模型的成功率极低，几乎可以视为“不可用”。
但随着模型能力提升，以及 工程化 Agent 方案 的引入，这个情况开始发生变化。
到 2024 年下半年：
部人模型在结合工具调用、上下文管理、多轮反馈之后
在 SWE-bench 上的成功率，开始进入 两位数
进入 2025 年：
在公开评测中
部分最优方案的解决率，已经接近甚至超过 40%
这说明一件事：
AI 已经不再只是在“写代码”，而是开始具备在受限条件下参与工程任务的能力。
03
这是否意味着：AI 已经能“独立干活”了？
还没有。
SWE-bench 的进步，同时也非常清楚地暴露了 AI 的边界。
在那些失败案例中，AI 往往卡在这些地方：
问题本身是模糊的
用户说“有点慢”“不太稳定”，但没有明确标准
需要权衡与取舍
多种修复方案都成立，但要选哪一个？
涉及复杂业务逻辑
一个改动，可能影响到另一个团队、另一个系统
需要承担后果
改动上线后出问题，谁来负责？
这些问题的共同点只有一个：
它们都需要“人”。
AI 可以生成代码，但它不会为结果负责。
04
测试工程师的位置在哪？
这对测试工程师来说，尤其值得想清楚。
很多人担心：“AI都能自动生成测试用例、自动执行回归了，测试是不是要被取代了？”
但你想一个问题：
测试的核心是什么？
不是“点点点”，不是“写用例”，不是“跑脚本”——这些都只是手段。
测试的核心是：判断一个系统是否可信。
这个判断，包含了很多东西：
这个Bug严重吗？要不要拦住上线？
这个功能用户体验好吗？会不会被用户骂？
这个系统的性能够吗？大促会不会崩？
这个改动有风险吗？会不会影响别的模块？
这些问题，AI回答不了。
因为判断需要理解业务目标、用户场景、组织约束和潜在风险——而这些，恰好是测试工程师每天都在做的事。
05
在 AI 时代，人最重要的三件事
所以，在AI越来越强的未来，人该站在哪？
不是和AI对抗，不是和AI比赛写代码，而是做好这三件事：
第一，定义问题。
AI很擅长解题，但不擅长选题。用户说的“有点卡”，到底是前端渲染慢，还是接口返回慢，还是网络问题？把这个模糊的现象翻译成可验证、可执行的工程任务，是人的责任。
第二，校验结果。
AI写了一段代码，改了一个Bug，跑通了所有测试。但它真的改对了吗？会不会在边缘场景引入新问题？会不会破坏未覆盖的业务路径？这个深度验证与风险兜底，必须由人完成。
第三，承担责任。
上线出问题了，AI不会被问责。用户投诉了，AI不会被追责。最后签字、复盘、改进流程的，永远是人。这听起来沉重，但这就是人和工具最本质的区别——人有判断，也有责任。
06
不是替代，而是扩展
回到最开始那个问题：
“AI 已经能写代码了，那我们还有位置吗？”
我的答案是：
不仅有，而且更重要了。
因为 AI 越强，对“能判断的人”的需求就越高。
未来更可能是这样：
AI 帮你写脚本，你有时间思考系统风险
AI 帮你分析日志，你能关注更大的稳定性问题
AI 帮你生成用例，你可以深入理解业务逻辑
你不需要和 AI 比谁写代码快。
你要做的是：
让 AI 帮你干活，你去干 AI 干不了的活。
07
写在最后
2026年的春天已经来了，路还长。
这一年，AI还会进化，模型还会更强，评测数字还会往上涨。
但有一件事不会变：
在需要判断对错、权衡利弊、承担责任的地方，永远需要人在。
你不是被AI替代的人。
你是那个用AI，让自己变得更强的人。
稳住，往前走。
