最近这几个月，湾区科技圈有一件让很多人觉得困惑的事。
两个朋友，都在做软件工程，学历差不多，工作年限差不多，甚至在某些时期还在同一家公司——但最近一两年，他们的处境开始分叉。一个在找工作，另一个在拒offer。
如果你只看新闻标题，你会觉得这没什么奇怪的：AI时代，工程师当然有人被淘汰。但问题是，这两个人都叫SWE，都在写代码。为什么AI对他们的影响，方向完全相反？
你可能会想：是不是一个更努力？是不是一个更早学AI工具？是不是一个更senior？这些因素都有影响，但都不是这件事的核心解释。
这一期我想跟大家一起拆开看这件事。不是告诉你”学哪些技能最安全”——那种清单网上有很多，而且很快就会过期。我想解释的是背后的机制：AI到底在按什么逻辑给劳动力重新定价。
这期结束的时候，你能用一个三步框架，自己判断——AI对你是放大器，还是替代器。
第一层：AI在做一件什么事
先说一个可能反直觉的判断：从当前市场信号来看，AI对劳动力的影响呈现出明显的差异化特征——某些工作类型的价值在压缩，另一些在上升——而不是均匀地影响所有人。
在进入这个框架之前，我需要先说一件重要的事。AI时代劳动力重新定价，受多类因素影响——离钱近不近、是否处于资本开支优先区、组织内部的稀缺性、错误代价高不高。其中”可路由性”是最能被个人直接用来自测的一个维度——不是唯一决定因素，但是最可操作的那个。后面我们用这个框架分析各个岗位的时候，它是切入角，不是全部答案。
怎么理解这个”可路由性”？
打一个比方。想象一个大型物流中心。过去，里面有很多人在做分拣工作——拿起包裹，看看标签，放到对应的格子里。这个工作需要识字、需要注意力、需要一定的判断力，但归根到底，它的核心逻辑是：输入（包裹信息）→规则（分拣标准）→输出（放到正确格子）。
这类工作，一旦有了足够好的机器，就会被路由给机器。不是因为机器”更聪明”，而是因为这个工作的结构，是可以被机器接手的——或者用一个词来说，它是可路由的。
但在同一个物流中心，还有另一类工作：处理损坏包裹的纠纷、判断某一类货物的特殊监管要求、决定在某个节假日高峰期如何重新分配人力——这些工作需要的是上下文判断、跨部门协调、以及对后果的责任归属。它的结构不是”输入→规则→输出”，而是”模糊情境→整合多个维度→做出没有标准答案的判断”。
机器能帮这类工作变得更有效率，但它不能接管判断本身。
这个逻辑，放到tech行业，就是今天在发生的事情。
第二层：AI的定价逻辑是什么
我们一起来把这本账打开看。
AI正在做的一件事，是把可路由工作的边际成本压向接近零。代码补全、单元测试生成、文档撰写、标准化功能实现——这些工作不是消失了，它们变便宜了。便宜到什么程度？据GitHub和Microsoft发布的研究，开发者在特定编码任务上的完成速度提升约55%。
这是一个值得注意的信号，但它不直接等于人力需求下降。从局部实验效率提升，到组织层面实际减少headcount，中间还有很多变量：需求侧有没有同步扩张、AI生成代码的review成本有多高、senior工程师和junior工程师的需求结构是否同向变化。这些变量的走向，目前没有完整的证据。所以这个55%，更准确的读法是：可路由工作的边际成本正在被系统性压缩，而不是”因此某个数量的人会被裁”。
与此同时，市场对另一类工作的定价，在往上走。
从公开的招聘数据来看，AI Safety工程师、模型评估（Evals）工程师、AI基础设施工程师——这些职位在Anthropic、OpenAI、Google DeepMind等公司持续扩招。从公开JD的薪资范围区间来看，这类职位的公开挂牌区间通常位于较高带，且这一倾向在多家AI优先公司的JD中都有体现。
为什么会这样？因为这些工作里有大量不可路由的判断。
一个AI Safety工程师需要做什么？不是运行测试用例——那个AI自己能做。他需要判断：在某个特定使用场景下，模型的某种行为是否构成安全风险；当一个边界案例出现的时候，这是需要修复模型的问题，还是需要修改使用约束的问题；当一个新的能力涌现出来的时候，它带来的最坏情形是什么，值不值得阻止它上线。这些判断，目前尚没有工具能够接管——它们需要上下文理解、价值权衡和责任归属，这是AI Safety工程师薪资溢价更合理的解释之一。
第三层：具体岗位里的分化长什么样
让我们把这个逻辑对应到几个具体岗位上。每一段的核心问题不是”这个岗位安不安全”，而是”这个岗位的内部结构正在发生什么变化”。
SWE（软件工程师）：分化不在岗位之间，在工作内部
同样叫SWE，两个人的账本可能完全不同。让我用一个最直接的方式说清楚。
工程师A的日常大概是这样的：接ticket，实现产品经理写好规格的功能；review AI生成的代码；修已知的bug；跑既有的测试流程。
工程师B的日常是另一回事：决定服务的边界在哪里、该怎么划；设计评估方法，判断一个系统在什么条件下算”工作正常”；处理跨团队的技术权衡，比如这个设计对平台组有利但对业务组有成本，怎么取舍；对架构选择的长期后果承担责任——不只是写代码，而是让这个决策的理由被团队记住和传递。
A的工作里，可路由比例高。AI工具已经能做其中相当大的比例，而且还在变好。B的工作里，可路由比例低。AI可以是助手，但判断本身是B做的。
关键不是你的title是L4还是L5，而是你每天真实工作里这两部分的比例。
Platform / Infra SWE：供需逻辑和任务类型逻辑同时在起作用
做平台和基础设施的工程师，目前处境相对有利——原因有两个层面，需要分开说。
第一个层面是任务类型。Infra工作极度复杂：系统故障的根因分析、跨层级的性能调优、在成本和可靠性之间做取舍——充满不可路由的判断，AI工具难以接管。
第二个层面是资本逻辑。AI应用在快速扩张，但支撑这些应用的计算基础设施、数据管道、模型服务层，需要大量投入。这不只是”工作类型”的问题，而是：资本优先流向的地方，需求结构也跟着变化，供给端的稀缺性会被额外放大。
但这里需要加一个不那么直觉的补充：复杂 ≠ 稀缺 ≠ 离钱近。不是所有充满判断、难以路由的工作都能拿到高溢价。Infra岗位目前的相对优势，是”任务类型 + 资本方向”两者刚好对齐的结果。
从可路由性框架来推断，标准化程度高的开发工作承压更早、更直接——这与部分已公开报道的裁员案例方向一致，但构成性数据并不完整。同时，据各公司财报，AI基础设施方面的招聘和投入仍在增加。这不是矛盾，这是同一个逻辑的两面。
PM（产品经理）：价值正在从”需求整理者”转向”问题定义者与风险裁判”
这个变化在湾区科技社区里很多人都有感受。
传统PM的核心价值，往往是把用户需求翻译成规格文档，管好路线图，协调各方优先级。这些工作现在的可路由比例在上升——AI工具在有效地做结构化整理、访谈摘要、优先级排序辅助。
AI产品开发重新定义了PM应该在哪里创造价值。这不是PM岗位变不重要，而是”哪种PM在这件事上是不可替代的”这个问题的答案变了。
能够判断”这个功能让模型来做还是让规则来做”、”这个边界案例到底是产品设计问题还是模型对齐问题”、”这个评估指标是否真的在测对的东西”——这类PM正在从”方便有”变成”必须有”。因为这些判断，不懂技术的PM没有办法参与，而把它们全部丢给工程师，会造成问题定义层面的系统性失误。
更本质的转变是：PM的位置从需求的整理者，移动到了问题的定义者和风险的裁判。这两个角色在AI产品开发里的价值，完全不在一个数量级上。
DS / ML：模型能力本身不是护城河，问题定义和评估才是
数据科学这个类别里，分化同样在发生，而且分化的逻辑比”你会不会用AI工具”更深一层。
做标准化分析报告、跑既有的模型pipeline、套用现成方法论解决可模板化问题的DS，感受到的压力与写CRUD代码的SWE类似——AI工具在有效地做同类工作，而且这个替代速度在加快。
但以下这类工作的处境完全不同：判断业务问题是否真的是一个ML问题、为一个新业务场景设计评估框架、在模型行为和业务指标之间建立可解释的连接、决定某个模型的失败模式是否构成业务风险。
会用一个模型，会调参，会跑实验——这些现在是入场券，不是护城河。真正稀缺的能力，是在更上游做出判断：这个问题值不值得用ML来解、解出来的东西怎么评估才算对。这类判断，需要对业务有深度理解，需要对数据局限性有清醒认知，需要对”模型告诉你的结果”保持合理的怀疑——而这些，不是跑更多实验就能获得的。
以下是招聘数据给我们的观察：据LinkedIn等招聘平台的数据，AI/ML相关工程师职位在2024年的招聘需求持续增加。以下是我对这个信号的解读——这个增长集中在有能力做模型设计和系统判断的人，而不是所有”ML”标签下的人。这是根据岗位描述和市场信号的推断，不是招聘数据本身能直接证明的结论。
第四层：哪些看起来”安全”的职位，其实没有那么安全
需要说一件反直觉的事，否则这期内容就不完整。
“软技能更安全”、”创意类工作不会被AI替代”——这两个论断，在当前市场上已经部分失效了。
内容生成、标准化文案、基础平面设计——这些工作里可路由的部分，据多家媒体报道，正在受到AI工具的直接竞争，市场需求出现收缩信号。这不是说所有创意工作都不安全，而是说：创意工作里同样有可路由和不可路由的部分。导演和摄影指导的工作，可路由比例低；写营销邮件和产品描述的工作，可路由比例高——即使它们都被叫做”创意工作”。
对tech从业者更相关的一点是：“我在大公司，title好听”不等于”我的工作不可路由”。
据多家媒体报道，近期科技行业的裁员，被影响的并不只是小公司——部分大公司的裁员同样集中在工作内容高度标准化的岗位上。title和公司名字不提供保护，保护你的是你每天实际做的那些判断。
第五层：自测框架——你现在可以做的一件事
好，现在我们来到这期最核心的部分。
我给大家一个可以立刻对自己用的框架，分三步。说完三步之后，我会用一个具体的例子走一遍，你会更直接地看到它怎么用。
第一步：列出你最近一个月真实工作内容
不是你的JD写的，而是你实际在做的。大概五到十件事，越具体越好。比如：写需求规格文档、review代码、参加架构讨论、给新团队成员讲背景知识、处理一个跨团队的摩擦、决定某个技术方案选哪条路、分析某个数据异常背后的原因……
第二步：对每一件事，问自己一个问题
“如果我明天不做这件事，用什么能替代我？”
如果答案是AI工具、或者一个更初级/更便宜的人——那这件事的可路由比例高。
如果答案是”没有什么能替代，因为需要我的上下文、我的判断、或者我的责任归属”——那这件事的可路由比例低。
不需要每件事非黑即白，可以给它打分：1分（完全可路由）到5分（完全不可路由）。
第三步：看你的分布
如果你的工作内容大多数在1–2分区间，这是一个信号：你目前的市场溢价在压缩区。这不是判决，而是一个数据点，让你知道下一步该往哪里走。
如果你的工作内容大多数在4–5分区间，那你目前处于被放大的位置——但也要注意：今天不可路由的工作，可能几年后就变得可路由了。这不是一次性的调整，而是一个持续的校准。
如果你发现自己在1–2分和4–5分各占一半——这其实是一个很好的起点，因为你已经知道往哪里加重量了。
让我用一个例子走一遍这个框架。
假设你是一个在大厂做L4 SWE的工程师，你列出来的最近一个月工作大概是这样：
第一步，你列了七件事：接sprint里的ticket实现功能（2天）、review队友的PR（1天）、参加一个新服务的架构讨论（0.5天）、跟PM讨论一个需求的技术可行性（0.5天）、排查一个线上异常（1天）、给刚入职的新人讲系统背景（0.5天）、写一个新功能的设计文档（1天）。
第二步，你逐一问自己：接ticket实现功能——评1–2分。review PR——AI能做初步扫描，但你做的是更高层级的逻辑判断，评3分。架构讨论——评4–5分。需求可行性讨论——同上，4–5分。排查线上异常——如果是已知问题类型AI能帮大忙，评2–3分；如果是新型异常需要你的系统知识，评4分。给新人讲背景——评5分。设计文档——如果是根据既有模式套写，评2分；如果需要你判断边界和权衡，评4分。
第三步，你看分布。你发现七件事里，大约四件在1–3分区间，三件在4–5分区间。这不是坏消息，这是一个清晰的信号：你每天花时间最多的那些工作，市场溢价在压缩；你花时间相对少的那些工作，才是你真正的定价基础。下一步要思考的不是”我该不该焦虑”，而是”我能不能调整日常工作的结构，让自己更多地参与4–5分的那部分”。
结尾
我想在最后说一件事。
这期我没有给大家一个”最安全的十类职位”清单。因为我觉得那个清单的价值是有限的——它会过期，它也没有考虑你的具体情况。
更有用的，是那个问题：你的工作里，有多少是无法被路由的？
这个问题的答案，每个人都不一样。而且更重要的是，它不是固定的——你可以通过调整自己工作内容的结构，往不可路由的方向靠。
这不是一个AI来了就一定要慌的时代，也不是一个躺平就会没事的时代。它是一个差异放大的时代。
AI对你是放大器还是替代器，这个答案不在AI身上，在你现在的工作账本里。你真正该问的不是”AI会不会替代我”，而是”我现在的工作里，有多少是只有我在场才能发生的。”
更多我的博客文章>>>
