同樣是工程師，AI為什麽讓一些人漲薪、讓另一些人失業

最近這幾個月，灣區科技圈有一件讓很多人覺得困惑的事。

兩個朋友，都在做軟件工程，學曆差不多，工作年限差不多，甚至在某些時期還在同一家公司——但最近一兩年，他們的處境開始分叉。一個在找工作，另一個在拒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會不會替代我”，而是”我現在的工作裏，有多少是隻有我在場才能發生的。”

 

--

有共鳴的歡迎留言，

想看更多這類分析的可以關注莎姐說（Substack 免費訂閱）：shajieshuo.substack.com