LLM 重构职场：不是谁消失，是每个人都在变

作为一个同时做过产品经理和项目经理的人，我最近开始认真想一个问题：身边这些岗位，哪些在 LLM 时代会真正被压缩，哪些只是看起来危险？

直觉上，开发、测试这类技术执行岗位首当其冲，这个判断大家基本都有。但另一个问题更模糊：像项目经理、PMO 这样偏流程协调的岗位，会不会反而因为“执行层被替代”变得更重要？

我的结论是：这个问题问错了方向。不是“谁更重要”，而是不同性质的工作，在 LLM 冲击下遭遇的是完全不同的变化。

先建立一个分析框架

与其按岗位名称逐个分析，不如先按工作性质分类。这是我自己归纳的框架，不是行业通用术语，但我觉得它比岗位名称更能说明问题。我把软件团队里的工作大致分成三类：

第一类：专业技术执行类。 开发、测试、设计、UI 等。这类工作的共同特征是：输入相对结构化（需求文档、测试用例、设计规范），输出可以被客观验证（代码跑不跑得通、测试通不通过、视觉稿符不符合规范），反馈闭环快。

第二类：流程协调类。 项目经理、PMO 等。这类工作的输入是人——人的状态、利益诉求、组织政治；输出不是一份文档，而是“让事情发生”——让一个决策落地，让两个团队对齐，让一个项目推进下去。

第三类：对外关系类。 销售、客户成功、商务等。输入是外部市场和客户，输出是信任和关系。这类工作受 LLM 冲击最小，不是本文的重点，点到为止。

这个分类不是非此即彼的——同一个人身上往往同时有多类工作。产品经理是典型例子：写 PRD 和拆解需求属于第一类，内部对齐和优先级判断属于第二类。接下来按这个框架逐类分析，产品经理的工作拆分会在第一类里展开。

第一类：专业技术执行类——冲击最直接

这类工作被压缩，不是因为 LLM 有多聪明，而是因为它们本身的结构特征让 LLM 介入的条件全部成立。

输入结构化，意味着 LLM 能读懂任务；输出可验证，意味着错误可以被快速发现和纠正；反馈闭环快，意味着 LLM 能在迭代中自我修正。这三个条件叠加在一起，效果是可观的。

数据已经反映出这种趋势。据 Stack Overflow 2025 年开发者调查，84% 的开发者现在使用 AI 工具，AI 生成的代码占所有提交代码的比例接近 46%。GitHub Copilot 在受控实验中显示，开发者完成任务的速度可以提升约 55%（官方声称，基于 4800 名开发者的实验，未经独立全面验证）。与此同时，美国软件开发职位招聘量从 2022 年 2 月的峰值下降了近 49%，初级开发者（22-25 岁）的就业率从 2022 年末的峰值下降了约 20%。

需要说明的是，这些趋势并不意味着开发岗位会整体消失。美国劳工统计局的预测显示，软件开发者就业仍预计在 2024 到 2034 年间增长 15%。据行业普遍分析，这个增长更可能集中在系统设计、架构判断和 AI 输出验证等更高层次的工作，而不是基础代码编写——但 BLS 原文并未直接说明增长集中在哪些层次，这是外部推断，不是官方结论。被压缩的是执行层，留下来的是判断层。

测试岗位的处境类似。据行业数据，目前超过 40% 的 QA 团队已经采用 AI 测试工具，AI 能自动生成测试用例、执行回归测试、识别常见 bug 模式——这些曾经是测试工程师大量时间的去处。设计和 UI 方面，Figma 2025 年调查显示，22% 的设计师已经在用 AI 生成界面初稿，21% 用 AI 探索不同布局和视觉风格；但 40% 的设计师和开发者表示尚不完全信任 AI 生成的输出，最终的审美判断和用户体验决策仍需要人来做。

产品经理的工作同样横跨两类，这里先说属于第一类的部分。需求文档的撰写、需求拆解、会议纪要整理——这些是 PM 工作里最接近执行类的部分，LLM 已经能处理相当一部分。但产品方向的判断、功能优先级的取舍、用户洞察的解读，不是信息整合，而是在不确定性下做决策，LLM 给不了答案——这部分属于第二类，放到下一节讨论。

第二类：流程协调类——冲击有限，但内部有分化

第一类工作面临的是直接压缩，第二类遭遇的是不同性质的冲击。这类工作为什么相对稳定？有两个结构性原因。

第一，输入是非标准化的人。项目经理和 PMO 每天处理的，是各种状态的人——有的团队进度落后但不愿承认，有的部门之间存在利益冲突但没有明说，有的问题表面是技术分歧实际是资源争夺。这些输入不能被标准化成一份文档，因为大量信息存在于语气、关系、组织政治的隐性层面。LLM 能处理显性信息，处理不了这些。

第二，输出是“让事情发生”，不是“产出内容”。开发测试产出的是可验证的交付物，判断好坏有客观标准。但流程协调类工作的价值在于：一个决策有没有真正落地，两个团队有没有真正对齐，一个项目有没有实际推进。这个价值依赖人对人的影响力，依赖在场的权威和信任，LLM 无法替代。

但这类工作内部有分化，不能一概而论。

流程协调类工作里，有一层是信息整合——收集各团队进度、汇总风险、出状态报告。这一层和第一类工作的性质很接近：输入是结构化的项目数据，输出是可验证的报表。这一层同样面临 LLM 的直接冲击。相关研究表明，AI 自动化正在隐去 60-80% 的传统 PM 可见性信号，状态报告、进度追踪这类工作正在被工具取代。

真正稳定的，是协调推进层和治理决策层——处理跨团队冲突、资源优先级排序、在组织政治下推动决策落地。这些才是流程协调类工作的护城河。

明确了这个内部分化之后，项目经理和 PMO 受到的冲击方式就很不一样了，值得分开说。

项目经理的工作实际上横跨第二类和第三类。对外跟客户、供应商打交道的部分——关系维护、预期管理、合同协商——属于第三类对外关系工作，受 LLM 冲击最小，原因和销售、客户成功相同：核心是信任，无法标准化。内部的信息汇总和状态更新部分属于第二类的信息整合层，LLM 能替代的比例在增加。与某头部互联网大厂 PMO 岗位人员的访谈也印证了这一判断：项目经理的核心是“跟人打交道的工作，AI 很难取代”，AI 能做的是生成会议纪要、输出项目计划、辅助合同评审这类提效工具，协调推进的本质没有变。净效果是：一个项目经理能处理的项目复杂度在上升，但不需要那么多人了。

同样，产品经理属于第二类的部分——优先级判断和产品方向决策——也适用这个逻辑：输入是业务理解和用户洞察，输出是在不确定性下的取舍，LLM 能提供信息，但给不了判断本身。

PMO 的情况更复杂，因为不同公司里 PMO 的实际工作内容差异很大——而这个差异直接决定了它面对 LLM 冲击的脆弱程度。

我在一家大型金融科技公司观察到的 PMO，实际上更像“流程进度整理员”——收集各部门进度、维护项目台账、整理会议记录。这类 PMO 做的恰恰是信息整合层的工作，是最容易被 LLM 替代的那一类。

同样是与头部互联网大厂 PMO 的访谈里，呈现的是完全不同的画像。他们的工作涉及跨部门治理机制设计、度量体系建设、知识平台规划，甚至需要判断“这件事现在要不要做、谁来做、往轻了做还是往重了做”——这些判断不是信息整合，是在复杂组织环境下的决策，LLM 辅助不了。

PMO 这个岗位在不同规模、不同定位的公司里，实际工作内容可能完全不同。 如果一个 PMO 的日常工作以信息整合为主，它面对 AI 的处境并不比初级开发者好多少；如果它真正在做治理和决策支撑，护城河要厚得多。

重构，不是消失

把上面的分析整合起来，结论不是“谁安全谁危险”，而是：LLM 压缩的是工作性质，不是岗位名称。

同一个产品经理身上，PRD 撰写被压缩，产品判断被放大；同一个项目经理身上，状态汇报被自动化，跨团队推进变得更核心；同一个 PMO，如果还停留在信息整合层，处境并不乐观，如果真正在做治理，AI 反而可能为它创造新的工作——比如设计人机协作的流程规范，比如建立知识复用平台。

还有一个更大的结构性变化值得关注。过去软件团队的流程和机制，是为人设计的——每个节点的参与者是人，考虑了人的信息处理能力上限、人的沟通成本、人的注意力局限。当这些节点开始变成 AI agent 之后，原有的流程不是“人被替换了”，而是整个机制的设计逻辑需要被重新思考。

这也催生了新的岗位需求。FDE（Forward Deployed Engineer）是一个例子——它的核心不是替代原有岗位，而是解决“每个项目的经验如何被沉淀和复用”这个新问题，这个问题在纯人工时代也存在，但 AI 让它变得更紧迫，也提供了新的解决可能。

AI 时代没有稳定的岗位，只有持续演化的工作性质。值得问自己的，不是“我的岗位会不会消失”，而是“我现在的工作里，哪些部分是信息整合，哪些部分是判断和推进”——前者在被压缩，后者在被放大。