关于AI与工作的讨论，最容易吸引注意的问题始终是“哪些岗位会消失”。这个问题适合做标题，却不适合指导企业做组织设计。一个岗位从来不是一项单一工作。软件工程师写代码，也做需求澄清、架构判断、代码审查、故障处理和跨团队协作；产品经理既分析需求，也需要定义问题、做取舍、推动共识。AI对这些任务的影响程度完全不同。
因此，更有操作价值的视角，是把岗位重新拆回任务和工作流。
岗位本身是一种历史打包方式
企业今天的岗位边界，很大程度上来自过去的技术条件和协调成本。有些任务被放在同一个岗位里，并不因为它们天然不可分，而是过去由同一个人完成最经济。信息搜索昂贵时，熟悉领域的人同时负责分析和判断；沟通成本高时，同一职能内部的任务更容易被捆绑。
AI正在降低搜索、生成、归纳、分析和标准化执行的成本。一旦这些成本变化，原来的“打包方式”就有重新设计空间。这也是为什么AI对就业的影响很难通过岗位名称直接预测。大多数岗位不会整齐地消失，它们会先发生内部任务比例变化。
AI更容易接管“可描述、可验证、可重复”的部分
同一个岗位内部，AI适配度差异很大。结构清晰、规则稳定、输出容易验证的任务，更容易被AI承担；高歧义、涉及关系、价值判断和重大责任的任务，仍然需要人类主导。例如，工程师生成一段常规代码可能高度适合AI，判断这段代码是否符合整体架构则需要更多上下文；客服Agent可以处理标准问题，涉及高价值客户和复杂情绪时，人工介入仍然必要。
组织设计因此需要从“这个岗位是否会被AI替代”改成“这条工作流里，哪些任务由谁完成最合适”。
人的工作不会简单缩成“审核AI”
如果企业只是把旧任务交给AI，再安排人做最后审核，很容易形成新的低价值岗位。人的工作更值得向上移动：定义问题、设置边界、处理异常、做跨系统取舍、维护关系、承担责任。这要求重新设计整个流程。原来先写报告、再分析、再开会决策的流程，AI进入后可能根本不需要保留原来的三步结构。真正值得问的是：如果今天从零设计，这项工作还会长成现在这样吗？
岗位能力要求会随任务组合一起变化
当生成和检索变得便宜，知识储备的价值不会消失，但区分度会下降。更重要的能力包括判断AI输出质量、识别风险、整合跨领域信息、设计人机工作流，以及在模糊情境里做决定。这也会改变人才发展。新人过去通过大量基础任务形成基本功，AI可能大幅减少这些练习。企业需要重新设计哪些工作可以交给AI，哪些必须保留给人作为训练。
岗位重构最终一定会进入绩效和职业路径。
组织可以从一条真实工作流开始
不需要先做全公司的“AI岗位重构”。选择一个高频、价值明确的流程，把它拆成任务，逐项判断四件事：这一步创造什么价值，规则是否稳定，输出是否容易验证，失败代价多大。然后再决定是Human-led、AI-assisted、AI-led加人工审核，还是Agent持续运行。
这种工作会比编一份“未来岗位清单”慢一点，却更接近真实组织变化。AI对工作的影响最终不会以一次大规模岗位消失的方式整齐出现。 组织里的正式岗位变化通常慢于真实工作。一个“软件工程师”可能已经把一半时间用于AI Review、系统集成和工作流设计，职位名称仍然没有改变；一个“项目经理”可能不再花大量时间收状态，却开始负责Agent流程、异常和跨团队决策。
这意味着企业不应该等HR完成新Job Architecture才开始调整工作。经理可以先在团队内部重新分配任务、改变责任和发展目标。正式岗位体系随后再跟进。
绩效和人才机制必须跟着任务一起移动
如果基础执行被AI承担，继续按原有产出量评价员工，会向组织发送错误信号。同样，如果新人培养仍然依赖那些已经自动化的基础任务，人才梯队会逐渐出现断层。岗位重构因此会形成一条连锁反应：任务变化——能力要求变化——绩效变化——职业路径变化。
企业真正面对的是任务、能力、绩效和职业路径持续滚动的变化，岗位消失只是其中一种可能结果。 企业的Job Architecture通常更新很慢。现实工作却可以在几周内发生变化。一个工程师开始把大量时间从编码转到Review和系统集成，一个产品经理开始负责Agent工作流和Evaluation，这些变化最初往往不会体现在职位名称里。
管理者因此需要比HR体系更早感知任务变化。可以通过项目复盘、1:1和人才盘点记录“这个岗位过去六个月新增了什么、减少了什么”。等到变化稳定以后，再更新岗位标准和职业路径。
任务重构还会影响组织成本结构
过去增加产能的主要方式是增加Headcount。当一部分执行能力可以由AI按需获得后，团队会出现新的成本组合：模型调用、平台、数据、人工Review和少量高阶人才。这会改变Build vs Buy、固定成本与可变成本的关系。
管理者开始需要把“人力规划”升级成“智能容量规划”：同一业务结果，最合适的人、AI、外部能力组合是什么。这一步会把岗位重构进一步推向Operating Model。它会先改变每天具体做什么，随后改变能力、绩效和组织边界。企业如果能够尽早看见任务层变化，就不需要等岗位名称失效以后才开始调整。
拆任务时，不能只看“AI能不能做”
很多任务盘点最后会变成一张自动化清单：模型能完成就交给模型，暂时不能完成就留给人。这样的拆法只看技术可行性，忽略了工作在组织里的真正作用。一项任务至少要从五个维度判断：
| 维度 | 需要回答的问题 |
|---|---|
| 价值 | 它直接创造客户价值，还是为下一步准备信息？ |
| 情境 | 完成它需要多少隐性知识、关系判断和现场信息？ |
| 可验证性 | 正确与错误能否被快速、低成本地识别？ |
| 风险 | 错误能否撤回，会影响谁，责任是否清楚？ |
| 学习 | 它是否承担新人训练、知识传承或风险感知的功能？ |
最后一个维度尤其容易被忽视。一段基础代码、一份客户分析或一次故障排查，可能产出价值不高，却是员工建立专业心智模型的必经练习。只按即时效率把它全部移走，企业可能今天节省工时，几年后失去能够处理复杂异常的人。
岗位说明书通常回答职责范围，任务组合契约则需要更动态地说明四件事：这个阶段由人承担哪些关键判断，AI可以完成哪些步骤，交接点在哪里，结果由谁负责。这份契约不必成为新的HR表格。它可以嵌入季度目标、项目启动和复盘：
- 画出当前工作流以及主要等待点；
- 标出由经验、关系与责任驱动的关键判断；
- 选择一到两个可逆、可验证的环节改变分工；
- 同时定义质量门、异常升级和人工接管；
- 用端到端结果复盘，再决定是否扩大。
这样做的好处，是岗位变化不再等同于一次大规模组织调整。管理者可以逐步改变任务组合，同时保留对质量、人才和责任的观察。
三种常见的重构假象
第一种是“旧流程加AI”。每一步都快了一点，审批、交接和等待仍然原封不动，端到端价值没有明显变化。第二种是“人变成兜底层”。AI大量生成，人负责清理所有边界问题，工作更碎、更被动，资深员工反而被低价值审核占满。
第三种是“产能增长等于需求增长”。生成成本下降以后，组织会自然制造更多文档、功能和分析。如果没有更强的优先级，新增智能最终只是增加在制品。所以，岗位重构真正要追求的是减少无效工作、缩短价值流、提高判断质量。自动化比例只能作为过程变量，不能作为目标。
一个可控的起点，是选择跨越两到三个角色、每月重复发生、结果可以度量的流程。用四到六周建立基线并试运行，至少观察周期时间、人工接管率、返工率、异常类型和员工学习负担。如果局部速度提高但返工和等待同步上升，说明瓶颈已经迁移；如果错误集中在少数情境，应该先完善Context和规则；如果人频繁接管，可能是边界设得过宽，而非员工“不愿意使用AI”。
这也是权威劳动力研究反复强调“任务转型”而非简单岗位替代的原因。ILO对生成式AI职业暴露的研究把工作转型视为更主要的现实路径；OECD也指出，AI会改变岗位中的任务结构以及非AI专业人员所需的技能。这些研究支持一种更谨慎的组织判断：从真实任务变化出发，不急于绘制确定的未来岗位清单。
从观点到管理动作
| 观察面 | 需要核对的事实 | 可以先做的动作 |
|---|---|---|
| 任务结构 | 岗位时间实际花在哪些任务上 | 选择三个典型岗位，记录两周真实任务而非照抄职责说明 |
| AI边界 | 哪些步骤可描述、可验证、可撤回 | 为一条流程标出Human-led、AI-assisted与人工Gate |
| 价值流 | 局部提速后，等待和返工是否迁移 | 同时记录总周期、人工接管与下游积压 |
| 人才成长 | 被自动化任务是否承担训练功能 | 为新人保留诊断、解释和承担后果的练习 |
| 责任成本 | 新分工下谁有权决定、谁承担结果 | 在试运行前写清Owner、升级和停止条件 |
第一次任务重构不宜追求覆盖全公司。选一条真实流程运行四到六周，周期结束时只问三件事：客户或业务结果有没有改善，人的注意力是否移动到更高价值判断，组织是否对异常和责任拥有更清楚的控制。三项没有同时成立，就需要重做任务组合，而非继续扩大工具使用。
延伸依据：ILO：Generative AI and Jobs、OECD：Artificial intelligence and the changing demand for skills、NIST AI RMF Core