后端工程师

英国国家网络安全机构的指引,由它的一位首席安全架构师撰写,把 AI 辅助开发放在从「完全生成」到「手写」的光谱上。它建议在编写认证或授权逻辑、处理敏感个人数据、处理密钥、令牌或凭据,或者安全缺陷后果严重时,往手写那一端靠。它是建议,不是有约束力的规则,也没有禁止用 AI 写安全代码;它没有给出开发者实际怎样工作的数字。

失败、撤回、监管或成本正在抑制采用。可以下调评估,或扩大不确定区间。

同一份普查:20 道固定题,每个依法上报的机构逐题答 Y 或 N,写下产品名与授权数量级。「用 AI 生成代码」是 45 个里 31 个答 Y,在 20 道题里排第七。这一行比那个数字更值钱的是产品那一列,因为点到的工具三年前都还不存在:农业部、退伍军人事务部、证券交易委员会等十几家填 GitHub Copilot,内政部填 Claude Code,国土安全部与劳工部填 Poolside,人事管理局填 Codex,卫生与公众服务部填 Amazon Q Developer。对照同一份文件里的差旅订票那一行 —— 那里多数答 Y 的机构填的是 SAP Concur:那道题上机构多半是指着本来就有的平台,这道题上不是。三条界限。能源部或环保署那个「10,000-50,000」是一份企业授权,它同时也是这份文件里别的行的答案,所以它不是「有这么多人在用它写代码」。一个 Y 是雇主报告自己有这个工具,不是在量它写了多少代码、其中多少被留下。而那道题只说「代码」,不分前端后端,也不分入行十年还是十个月;这条记录挂在这里,是因为写常规服务代码本来就是这项任务,不是因为清单这么说。

企业已正式投入使用。可以改变基线,但要结合规模与场景相似度加权。

一项同行评审的基准:392 个后端任务,每个都是按规格实现一组接口,配有功能测试和端到端的安全攻击,包括访问控制不当和授权错误。正确性最好的模型达到 62%;平均而言,各模型写出的正确程序里约有一半可被攻破;既正确又安全的最好成绩是 35%。这些是 2025 年的模型按规格写整个后端,不是在现有代码库里做修改;部分作者任职于开发 AI 编程代理的公司。

失败、撤回、监管或成本正在抑制采用。可以下调评估,或扩大不确定区间。

Uber 工程师发表的同行评审论文,讲的是在 Uber 自己的开发流程里运行的一个工具。18 个月里,它在 Uber 的 Go 代码库中识别出 404 个可复现的数据竞争,为其中 224 个(55%)生成了修复,开发者在代码评审中批准了其中 193 个(86%);被拒的修复里有通过了初步测试却被判定为错误的。Uber 不出售这个工具。它讲的是一门语言、一个代码库里的底层数据竞争,不是跨服务的事务、幂等、重试或顺序;每一个修复都经过了人的评审。

企业已正式投入使用。可以改变基线,但要结合规模与场景相似度加权。

Google 工程师描述自己用大模型做大型内部代码迁移。在一个案例里,广告代码库(5 亿多行)里的 ID 必须从 32 位改成 64 位,以免出现可能导致宕机的负数溢出;落地的改动中有 80% 的代码修改完全由 AI 编写,多数情况下人必须撤回模型的一部分改动,工程师估计总耗时减少了 50%。论文写明,代码评审和改动上线仍需要人来操作。Google 出售它所用的模型。这是跨代码库的类型修改,不是线上数据库的结构迁移。

企业已正式投入使用。可以改变基线,但要结合规模与场景相似度加权。

一家大型科技公司的自报数据,未说明「生成」如何计量(补全还是整段函数)。这个比例说的是 Google 的全部新代码,没有说是哪一类;这条记录挂在这里,是因为写常规服务代码 —— 处理函数、校验、服务之间的调用以及它们的测试 —— 本来就是这项任务,不是因为这句话单独说到了后端。未提及招聘;审核环节仍由工程师承担。

企业已正式投入使用。可以改变基线,但要结合规模与场景相似度加权。

亚马逊对亚马逊自家工程的内部估算,由出售这件工具的公司发布 —— 干活的一方、测量的一方与卖工具的一方是同一方,这一点写在这里,是因为它从外部无法核验。公司也公布了方法:节省的时间由迁移的 Java 依赖数量估出,假设人工迁移一个依赖需要一天或更久。要注意这是什么样的迁移:语言版本升级有编译器和既有测试套件充当判卷人,每一步的成败都可被机器判定 —— 这是这类自动化最有利的形态,不是关于后端工作的一般结论。也要注意它主张了什么、没主张什么:四千五百年是没有被做的工作,涉及一千多位开发者,而任何地方都没有一句话说他们中有人离开、或有一个岗位被取消。

企业已正式投入使用。可以改变基线,但要结合规模与场景相似度加权。

一篇同行评审论文,作者大多来自微软,讲的是给处理云服务故障的值班工程师用的工具。它的诊断信息收集部分已在微软 30 多个团队部署使用四年以上;用大模型的根因预测部分在初步阶段成功后,已由一个故障管理团队实际使用了几个月。它帮助的是诊断;它不决定回滚什么、接受什么损失;微软出售其中用到的模型。

企业已正式投入使用。可以改变基线,但要结合规模与场景相似度加权。

这份工作显眼的那一半 —— 接口与管子 —— 正是暴露的那一半,而它恰恰是你会被招进来做的。撑得住的部分讲的是「哪些事绝不能发生」,而这些你只能通过「某件事真的发生时你在场」来学。比你觉得舒服的时间更早地靠近一次值班。

在暴露度最高的那项任务上,你的处境比前端那一页更稳,而原因不是这份工作更难 —— 是「错了很贵而且看不见」,所以责任是集中的。要留神它带来的那种失效模式:去审查那些「一旦出错会沉默好几个月」的系统上的生成改动。

保住并强化

去「错了很贵」的地方

支付、账务、身份,以及任何有监管方的地方 —— 在这些领域里,无人经手的改动本来就不被允许,所以审查与担责是被拨款的,而不是被默认的。

调整职责

把「智能体能越过哪条线」接过来

在一个「出错会沉默」的服务里,总要有人决定一次自动改动能碰什么。多数团队没有指派任何人做这件事 —— 所以它出现在事故复盘里,不出现在职位说明里。

相邻转岗

转到数据或平台那一侧

关于一致性、失败与成本的那套推理可以直接迁移,而这两个方向都是「同一种判断用在更大的面上」。

各部分的速度不一样,所以一个数字会盖住你真正需要知道的东西。写接口在很大程度上已经是机器的活。而「两个请求同时到达时哪些事绝不能发生」、「一条错误信息可以暴露什么」,几乎没有动 —— 因为那是要担责的位置,不是打字。一个你能核对的信号:上个季度出事的时候,难的是找到它,还是决定拿它怎么办。

在最显眼的那项任务上,它的暴露度更低 —— 而这个原因值得弄懂,而不是拿来当安慰:后端的正确性常常是看不见的、而且错了很贵,所以这份工作里有更大比例是担责。那是结构差异,不是难度排名,而且它会变 —— 这份工作里「写接口」的那一半,暴露的条件和前端那一半完全相同。

对面试来说,这一点还没变。对工作来说,诚实的划分是:「背出一个算法」比以前更不重要,而「对失败进行推理」比以前更重要 —— 知道一次重试对一个已经在挣扎的系统意味着什么,和系统设计题想考的是同一种能力,只是用在真实的东西上。从你们自己的事故里学它,而不是从一份清单里学。

它现在就能起草一个,而那不是约束所在。约束在于:必须有人保证它绝不做哪些事、在几年后不丢东西地迁移它的数据、并在它出故障时醒着。那些是担责的位置,而担责并没有变便宜 —— 在受监管的领域里,它反而被更明确地要求了。