先把问题放缓一点

如果把这轮 AI 变化简化成一句口号，最常见的说法就是“程序员被取代、产品经理被取代、测试被取代”。这种说法传播很快，因为它抓住了情绪，但它最大的问题也很明显：它把岗位理解成一堆静态头衔，而不是一组持续变化的责任链。

这组系列更想把问题换一种方式问。真正值得追的，不是哪个岗位会在名义上最先消失，而是哪一部分工作会先被压缩，哪一部分判断会被推回人手里，哪一类角色会因此重新上移。只要换成这个问法，很多看似极端的判断都会变得更具体。

为什么要把 8 个角色拆开看

外界之所以容易把所有岗位混成一锅，往往是因为大家只盯着“AI 已经会写、会说、会总结、会调工具”，却没继续往下问：这些能力到底落在软件组织的哪一层。

把角色拆开之后，有三条主线会更清楚。

• 第一条主线是“可验证性”。代码、测试、配置、工单路由和结构化文档，比组织协调和高风险签字更容易先被 Agent 吃进去。
• 第二条主线是“责任链”。只要一项工作最后还要有人定义成功、签字放行、承担后果，它就更像被重组，而不是被整块替代。
• 第三条主线是“系统位置”。越靠近运行时、权限、评测、审批和例外治理，岗位价值通常越会上移；越靠近重复执行、格式加工和人肉搬运，越容易先被压缩。

这组系列可以怎么读

如果你想先抓住主线，比较稳的读法不是按组织结构图，而是按“问题从哪里最先暴露”来读。

• 先读《01. AI 时代怎么面试程序员：10 个经典问题与 3 层追问》。这篇先把“会写代码”退到次要位置，转而追问候选人是否真的会把 AI 带进交付链。
• 再读《02. AI 时代程序员面试题答案：从提示词到验证闭环》。这里会把视角从单个问题抬到整套判断标准，解释什么样的回答才算真的理解 Agent 时代的软件工作。
• 然后读《03. 产品经理在 Agent 时代，会从写需求转向什么》。这篇会把需求、边界和成功定义这层重新抬出来。
• 接着读《04. 测试工程师在 Agent 时代，会更靠近哪一层》。很多团队真正的缺口，会最先暴露在 eval、verifier 和回归闭环上。
• 再往下读《05. 架构师在 Agent 时代，会更像哪一种角色》。当系统开始长时间运行、跨工具执行，架构问题会重新抬头。
• 然后读《06. 项目管理进入 Agent 时代之后，会先变化什么》。这篇会把“催进度”背后的流程编排和例外治理重新拆开。
• 最后读《07. 当 Agent 开始读文档，文档的角色会怎么变》和《08. AI 工具扩散之后，IT 部门会回到哪一层》。这两篇会把最容易被轻视、却最可能成为基础设施的两层重新抬出来。

把总判断收在这里

把 OpenAI、Anthropic、微软、AWS 和一些关键 benchmark 放在一起看，我更倾向的结论很简单：这轮变化的关键词不是“岗位消失”，而是“岗位重组”。

真正会先被吞掉的，往往不是一个完整岗位，而是岗位里那些高度重复、低责任、弱上下文、弱验收的切片。真正会变贵的，则是另外几类能力。

• 能把任务目标、边界和样例一次说清楚的人。
• 能把工具、状态、评测和审批串成闭环的人。
• 能对运行时、权限、安全和责任链负责的人。
• 能把组织里的模糊经验压成可执行流程的人。

所以如果你是这 8 类角色中的任何一种，与其急着问“我会不会被替代”，不如先问另外一句更有用的话：在我的工作里，哪些环节已经能被机器稳定接手，哪些环节反而会因为 AI 更强而更需要我亲自定义、验证和兜底。

这组系列，就是围绕这个问题展开的。

更新附注

• 版本：v1.1
• 更新日期：2026-03-22
• 更新原因：修正系列导读中误指向两篇误发 slug 的失效链接，改为当前已发布的两篇程序员面试文章，避免读者从 guide 页点入 404。