最近关于工程岗位变化的讨论明显多了起来。

我之所以想写这篇文章，不只是因为这个话题在技术社区里热度很高。

更直接的原因是，我所在的公司也开始出现类似方向的动作。

岗位边界在变薄。

AI 工具被更深地放进研发流程。

工程师被期待覆盖更完整的交付链路。

这些变化不再只是新闻里的“大厂趋势”，而是正在进入很多普通工程团队的日常。

所以我想借这篇文章，把自己的判断梳理出来。

不是为了讨论哪个岗位会不会“被消灭”。

这个说法太粗糙，也太容易制造焦虑。

我更关心的是：

工程师应该如何理解 AI 时代的挑战？

当岗位边界被重新画过以后，我们要靠什么继续保证质量、责任和交付？

有些讨论来自公司管理层的公开备忘录。

有些来自技术媒体。

也有不少来自知乎、掘金、CSDN 这类技术社区。

它们的措辞不完全一样，但指向一个共同问题：

AI Coding 之后，前端、后端、测试这些岗位边界，正在变得越来越薄。

先把事实边界说清楚。

我没有找到可靠证据证明“阿里、字节或美国大厂已经正式把前端、后端、测试等岗位全部合并”。

这句话不能当新闻标题写。

但我确实看到了大量信号：

岗位职责在融合。

工程师被要求覆盖更长的链路。

组织更关心端到端交付，而不是单一技术栈标签。

这件事值得认真讨论。

因为它表面上是在问“岗位会不会消失”。

实际上是在问：

当执行节点被 AI 压缩以后，质量责任怎么重新分配？

先看几个信号

美国这边，Shopify CEO Tobi Lütke 的备忘录被媒体报道后，引发过一轮讨论。

核心意思很直接：团队在申请新增人手或资源之前，要先说明为什么这件事不能用 AI 完成。

Amazon CEO Andy Jassy 也在备忘录里谈到，随着生成式 AI 和 agent 推进，一些现有工作会需要更少的人。

国内这边，技术社区已经在讨论更具体的岗位融合。

比如搜索“阿里、字节、前端、后端、测试、岗位合并、AI”，能看到知乎、CSDN、InfoQ、掘金等结果都在讨论类似问题。

掘金上有一篇流传较广的文章，标题直接写到“前阿里 P10 毕玄：公司不再划分前端、后端，统一叫做 Agent 工程师”。

这类文章不能等同于公司公告。

但它说明一个现象：技术社区已经开始用“Agent 工程师”“AI 全栈”“产品工程师”这些词，重新理解岗位边界。

阿里云开发者社区也有文章讨论“为什么字节/阿里的 AI 测试团队都在招 Skill 工程师”。

这同样不是官方组织调整公告。

但它至少说明，在测试这个传统岗位上，行业讨论已经从“会不会写测试脚本”，转向“能不能把测试经验封装成 AI 可调用的能力”。

这些材料放在一起看，我的判断是：

岗位名称是否立刻改变，并不是最重要的事。

真正重要的是，工程组织正在把“单点执行者”推向“多节点 Owner”。

岗位边界会变薄，职能不会消失

过去的软件团队，习惯按技术栈和流程节点拆人。

前端写页面。

后端写接口。

测试做验证。

PM 拆需求。

发布、监控、安全，再交给另一组人。

这个模式不完美。

它慢。

它重。

它有大量沟通成本。

但它至少有一个优点：

每个关键节点都有相对独立的人在守。

AI Coding 出来以后，这个结构开始松动。

一个工程师可以借助 AI 写页面、补接口、生成单测、修 CI、查日志。

原来需要多个岗位交接的动作，现在有可能被一个人加几个 agent 覆盖。

所以岗位边界会变薄。

一部分岗位会合并。

一部分职责会重新打包。

这件事不需要回避。

但这里最容易发生一个误判：

把“岗位消失”理解成“职能消失”，是这轮讨论里最大的误读。

这是两回事。

测试岗位可以减少。

但验证不会消失。

前端岗位可以被重新定义。

但用户体验不会消失。

后端岗位可以变得更全栈。

但数据一致性、性能、权限、稳定性不会消失。

PM 的边界也会变化。

但需求澄清、优先级判断、验收标准不会消失。

它们只是换了载体。

以前是一个人守一个节点。

以后更可能是一个 Owner 覆盖多个节点。

这就是我最核心的判断：

岗位可以合并。

职能不会蒸发。

AI 降低的是编码成本，不是责任成本

这轮变化背后的经济逻辑很清楚。

AI 把编码成本降下来了。

过去一个接口、一个页面、一个测试用例，都需要人一点点写。

现在很多执行动作可以交给工具完成。

当编码成本下降以后，组织自然会重新计算分工。

如果一个人可以用 AI 覆盖前后端，为什么还要维持那么细的岗位边界？

这个问题站在效率角度，是合理的。

但站在工程质量角度，它只问了一半。

另一半是：

如果一个人覆盖更多节点，质量责任是否也同步升级？

过去，一个工程师在自己的节点做到 60 分，系统有时还能跑。

因为后面还有测试。

还有 Code Review。

还有灰度。

还有线上监控。

系统靠分工和流程兜底。

现在如果一个人同时负责需求理解、代码生成、测试生成、发布判断，那每个节点都不能还是 60 分。

否则不是效率提升。

是风险打包。

AI 最容易制造的幻觉，不是“它不会错”。

而是“它好像都做完了”。

代码有了。

测试有了。

文档有了。

提交说明也有了。

但“做完”不等于“做对”。

这也是 GitLab 最近报告里提到的方向：AI 让代码生成变快，但很多组织的瓶颈转移到了代码审查、验证和治理。

换句话说，AI 没有取消流程。

它只是把问题往下游推。

如果下游治理没有跟上，速度就是负债。

工程师会越来越综合

这件事对工程师的要求会很直接。

AI 时代的工程师，不会只是“更会写代码的人”。

更准确地说，会越来越像一个小型系统负责人。

要懂业务意图。

要懂产品取舍。

要懂系统边界。

要懂数据流。

要懂测试和验证。

要懂上线风险。

还要懂怎么让 AI 在规则内工作。

Business Insider 最近采访 EY 的 AI 负责人 Dan Diasio 时，提到一个很典型的变化：

软件工程、数据工程、AI 工程这些原来相对分开的角色，正在出现重叠。

EY 对工程师的期待，也从单纯编码能力，转向端到端产品建设、架构思考、设计意图和可扩展性。

这个判断我非常认同。

过去的工程师，价值经常体现在“我能把这段代码写出来”。

但当 AI 可以快速生成代码以后，代码本身会变得更便宜。

真正稀缺的东西会变成：

你能不能定义清楚问题。

你能不能判断输出是否正确。

你能不能设计验证机制。

你能不能知道什么风险不能放过。

你能不能把一个模糊需求，变成可执行、可验证、可维护的系统。

2026 年关于软件工程工作的研究也在往这个方向走。

有研究把未来工程师的能力拆成技术、认知、社会技术、治理和组织能力几类。

也有研究指出，当 agent 负责更多实现工作时，验证和确认会变得更重要。

这说明一个趋势：

AI 不是让工程师变窄。

AI 是逼着工程师变宽。

只会写某个技术栈的一段代码，价值会下降。

能把需求、架构、实现、验证、发布、监控串起来，价值会上升。

这也是“全栈”这个词在今天需要重新理解的原因。

过去的全栈，是一个人同时背两套甚至三套技术栈。

今天的全栈，更像是一个人能理解完整问题链路，并调度 AI 完成不同节点。

不是手更快。

是脑子里的系统边界更完整。

业务侧更像 FDE，平台侧更像专业领域 + Agent

这里还需要再分一层。

如果只说“所有工程师都变成 Agent 工程师”，其实还是太粗。

我更倾向于这样理解：

在业务侧，工程师会越来越像 FDE。

也就是 Field Developer Engineer。

他不是单纯坐在研发链条后半段等需求的人。

他要更靠近业务现场。

理解真实用户怎么工作。

理解业务流程为什么这么设计。

理解一个功能上线以后，究竟改变了哪个环节的效率、成本或体验。

然后再用技术和 AI，把这个变化真正落到系统里。

这种角色的核心不是“会不会写更多代码”。

而是能不能把业务问题翻译成工程问题。

再把工程能力翻译成业务结果。

这也是为什么我觉得业务侧工程师会越来越综合。

业务理解、产品判断、技术实现、数据验证，会被压到同一个人或同一个小团队里。

但平台侧不完全一样。

平台、安全、测试、数据、基础架构这些方向，专业门槛反而不会降低。

甚至会更高。

因为 AI 可以让更多人调用能力，但它不能自动补齐深层专业判断。

安全工程师不是因为用了 Agent，就不需要理解攻击面、权限模型和供应链风险。

测试工程师不是因为用了 Agent，就不需要理解质量模型、覆盖边界和反馈闭环。

平台工程师不是因为用了 Agent，就不需要理解稳定性、可观测性、容量和发布治理。

所以在平台侧，严格来说不应该只是“Agent 工程师”。

更准确的说法是：

安全 + Agent。

测试 + Agent。

数据 + Agent。

平台 + Agent。

专业领域才是真正的壁垒。

Agent 会逐渐变成通识能力。

就像今天大家都要会用 Git、会用 CI、会看监控一样。

未来大家也都要会调度 Agent、约束 Agent、验证 Agent。

但真正决定你不可替代性的，不是你会不会叫 AI 做事。

而是你在哪个专业领域里，知道什么事情不能随便交给 AI。

从这个角度看，大厂把很多岗位统一命名为 Agent 工程师，我更愿意把它理解成一种组织转型的意识形态动作。

它的作用是告诉所有人：

不要再用旧岗位边界定义自己。

不要再把“我是前端”“我是后端”“我是测试”当成能力边界。

公司要推动的是一种 AI-native 的工作方式。

这个动作在意识形态上是有价值的。

它能推动组织从心理上接受新范式。

但一到实际落地，仍然会回到术有专攻。

业务侧需要更懂业务的 FDE。

平台侧需要更懂专业领域的 Agent 工程师。

这两类人都会用 Agent。

但他们真正的价值来源，不是同一个东西。

测试不会消失，但测试会升级

这轮讨论里，测试岗位最容易被拿出来说。

因为 AI 生成测试、跑测试、修测试的能力确实在提高。

阿里云通义灵码官网里就提到，编程智能体可以进行任务拆解、工程检索、文件编辑、终端使用，端到端帮助完成编码任务。

它也把单测、编译运行、错误修复等能力放进了产品叙述里。

这意味着很多传统测试执行动作，会被工具压缩。

但测试的本质不是“点按钮”。

测试的本质是建立可信反馈。

AI 可以生成测试用例。

但谁定义覆盖边界？

AI 可以跑单测。

但谁判断这些单测有没有测到真正风险？

AI 可以修复失败用例。

但谁判断它是在修 Bug，还是在把报警器拆掉？

这就是为什么我更愿意把未来的测试理解为“质量治理”。

传统测试关心：

这个功能对不对。

AI 时代的测试还要关心：

这个 agent 的输出是否稳定。

这个模型的判断是否可复现。

这条自动修复链路有没有引入新风险。

这个 Skill 被复用到别的场景会不会失效。

这已经不是简单的执行岗位。

这是规则设计岗位。

也可以说，是质量系统的架构岗位。

平台团队会成为规则层

如果工程师变成 Owner，AI 变成执行层，那么平台、质量、安全团队的位置会更重要。

过去平台团队经常被理解为“提供工具的人”。

CI/CD。

监控。

日志。

发布系统。

权限系统。

这些当然重要。

但 AI 时代，平台团队更像是在定义工程组织的规则层。

什么代码可以合并？

什么测试必须通过？

什么安全问题必须阻断？

什么性能指标不能退化？

什么 agent 行为必须留痕？

什么自动修复必须经过人工确认？

这些规则如果不清楚，AI 执行得越快，系统越不可控。

如果规则清楚，AI 才能真正变成生产力。

否则所谓“一个人顶一个团队”，很容易变成“一个人背一个团队的锅”。

这也是我反复想强调的地方：

执行可以自动化。

治理不能空心化。

岗位可以合并。

制衡不能取消。

如果一个人既提出方案，又生成代码，又生成测试，又批准发布，最后还自己宣布质量合格，那就不是现代软件工程。

那只是流程被压缩成了一次自我确认。

短期看很快。

长期看一定会还债。

从分工系统到治理系统

过去的软件工程，核心问题是如何分工。

谁写前端。

谁写后端。

谁测。

谁发。

AI 时代的软件工程，核心问题会变成如何治理。

谁定义质量。

谁维护规则。

谁判断风险。

谁对结果负责。

谁能阻断发布。

这不是一个小变化。

它意味着工程组织的设计重心，会从岗位边界转向责任边界。

一个组织可以不再严格区分前端和后端。

但它必须知道体验质量由谁负责。

一个组织可以减少传统测试岗位。

但它必须知道验证体系由谁负责。

一个组织可以让 AI 写更多代码。

但它必须知道 AI 生成代码的可维护性、可追溯性和安全性由谁负责。

否则，所有“提效”最后都会变成一个问题：

快是快了。

谁兜底？

最后真正变化的是人的位置

我不认为 AI 时代工程师的价值会消失。

但工程师的价值会迁移。

从写代码，迁移到定义问题。

从完成任务，迁移到承担结果。

从熟悉单一技术栈，迁移到理解完整系统。

从局部执行，迁移到端到端治理。

这对个人其实是更高要求。

只会等需求、写代码、交付一个局部模块的人，会越来越被动。

能理解业务目标、拆出技术路径、调度 AI 执行、设计验证机制、判断上线风险的人，会越来越重要。

所以我对“岗位合并”的判断是：

它会发生一部分。

岗位名称会变。

边界会重画。

但工程职能不会消失。

开发、验证、发布、监控、质量控制，都会继续存在。

只是它们不再稳定地绑定在某个岗位名称上。

它们会被重新组合到 Owner、AI 执行层和平台治理层里。

AI 时代软件工程的变化，不是前端、后端、QA 的简单消失。

而是执行节点被压缩，质量治理被抬升。

业务侧工程师，会更像 FDE。

平台侧工程师，会更像专业领域 + Agent 的复合角色。

工程师从单节点执行者，变成多节点 Owner。

平台团队从工具提供者，变成规则定义者。

所以“统一叫 Agent 工程师”这件事，我更愿意把它理解成组织转型的语言。

它在意识形态上推动大家接受新工作方式。

但在真实落地上，仍然是术有专攻。

这件事如果做对了，是效率革命。

如果做错了，就是把流程制衡全部压扁，然后假装系统更先进。

我更关心后者。

因为软件工程里最贵的，往往不是写代码。

是没人知道什么时候该停下来。