為什么AI會先吃掉程序員，而不是產品經理

如果你還在用職業名判斷AI風險，先停一下。

姚順宇在訪談里給過一個反直覺判斷：AI最先高速改變的，不一定是人類覺得簡單的工作，而是反饋最清楚的工作。這個判斷落到職業上，最扎眼的例子就是程序員。

過去很多人以為，AI會先替代那些重復、低門檻、標準化的工作。客服、簡單文案、資料整理，聽起來都比程序員更容易被自動化。程序員是高門檻腦力勞動，寫的是復雜系統，按這個直覺，它不該這么早站到第一排。

結果最早被AI工具改寫工作方式的，偏偏是代碼世界。Cursor、Claude Code、Copilot和各種代碼智能體，讓很多人第一次感覺到，AI不只是會聊天，它真的開始接一段工作了。

但姚順宇恰恰把AI編程拿出來當第一批爆發的AI原生場景。原因不在寫代碼低端，也不在產品經理更高級；關鍵是代碼世界有測試、編譯、運行結果、日志和版本記錄。模型做完以后，環境會告訴它哪里錯了。AI不按職業聲望排隊，它先進入那些能被清楚定義、快速驗收、低成本糾錯的任務。

程序員只是第一排。AI盯上的，是所有職業里能被拆成輸入、輸出、標準和反饋的可驗收執行層。

職業替代榜單太粗了

這幾年，關于"AI會先替代誰"的討論很容易變成一張職業榜單。程序員排第幾，產品經理排第幾，設計師、運營、咨詢、律師、會計又排第幾。這個游戲好玩，因為它簡單，像看K線圖。但職業名太粗了。

同樣叫程序員，有人每天接明確需求，改一個局部函數，跑一下測試，然后提代碼；也有人要理解業務目標，拆系統邊界，決定哪些依賴不能動，最后對整個系統結果負責。同樣叫產品經理，有人按模板寫PRD、整理會議紀要和競品截圖；也有人要判斷用戶到底卡在哪里，定義指標，協調資源，承擔版本取舍。

姚順宇那條判斷有用的地方就在這里。它把問題從職業名換成了任務結構：一個任務做完以后，環境能不能告訴模型做對了沒有；這個信號能不能被重復收集、訓練和糾錯；失敗以后，能不能低成本再試一次。

所以AI不認識你的崗位頭銜。它只看這件事能不能被定義，能不能被執行，能不能被驗收，失敗以后能不能繼續修。

代碼世界像一座提前鋪好的練習場

寫代碼對人很難，但對訓練系統很友好。這句話聽起來有點別扭。因為我們習慣把"人覺得難"直接等同于"機器也應該覺得難"。但模型學習一件事，和人類職業聲望不是同一套坐標。

代碼世界恰好在這件事上非常慷慨。你寫完一段代碼，能不能編譯，測試能不能過，類型檢查有沒有報錯，運行結果對不對，日志里有沒有異常，這些信號都會露出來。很多時候它們不是人類主觀評價，而是工具鏈直接給出的反饋。

一個代碼智能體修改了某個函數，測試失敗了，它至少知道失敗在哪里；命令跑不通，它能看到報錯；依賴不對，它能讀配置文件。這個過程當然還需要人審查，但它已經比很多知識工作更接近"做一步，看反饋，再修一步"的閉環。

再往外看，GitHub和開源生態又給了代碼世界大量任務、上下文和修改歷史。一個模型不只是看到最終答案，還能看到別人怎么提交issue、怎么改bug、怎么做code review、怎么圍繞一個repo迭代。倉庫本身就像一臺狀態機，文件、提交、測試、討論和文檔把上下文記錄下來。

所以程序員先站到第一排，并不是因為這份工作低端。恰恰相反，軟件工程復雜到一定程度，才給了AI足夠多的可學習信號。代碼世界像一座提前鋪好的練習場：有題目，有上下文，有工具，有錯誤提示，有回滾，有復盤。

產品經理不是安全，只是反饋更臟

那是不是產品經理就安全了？不是。這個誤讀很常見。產品經理工作里有大量結構化子任務，都會被AI改造：寫PRD、整理用戶訪談、總結會議、生成競品分析、做數據初篩、拆需求列表、寫埋點方案、生成原型說明。這些事情本來就有模板、有輸入、有輸出、有交付格式，不可能長期停在純人工狀態。

但姚順宇說難的，是完整產品判斷。他在訪談里反復指向一個問題：好產品的獎勵信號不清楚。翻譯成人話，就是你做完一個產品決定以后，很難立刻知道它到底對不對。產品反饋經常晚、臟、主觀——需要時間顯現，混進了太多變量，用戶心理、審美、組織目標和商業取舍都會進入判斷。

所以產品經理的護城河不是寫文檔，也不是開會。文檔會被生成，會議會被總結，競品會被整理，數據會被初篩。PM難被完整訓練的部分，是把模糊目標變成可驗證的問題、標準和取舍。代碼世界更早暴露了未來所有知識工作的重構方式；產品世界的核心判斷更難訓練，但它的外圍執行層一樣會被重構。

AI提效以后，工作未必變少

很多人以為AI寫代碼以后程序員會輕松一點。但姚順宇給出的體感更接近另一種結果：想法實現得更快以后，人會試更多方案，跑更多實驗，做更多判斷。AI提效先改變的是嘗試成本。嘗試成本一降，高競爭環境通常不會把省出來的時間留給你，它會把更多嘗試塞進同一天。

過去一個方案要兩天，團隊可能只試一個。現在一個下午能試三個，大家都會自然地問：那為什么不多試幾個？工作沒有少，只是從"手寫實現"遷移到了"定義任務、組織上下文、審查結果、比較方案、承擔驗收"。手從鍵盤上少敲了一些，腦子里的窗口反而開得更多。

AI未必先讓人失業。它可能先讓同一份工作變得更密。這才是很多人已經感受到、但還沒說清楚的變化。

真正危險的是可驗收執行層

問題不是程序員會不會消失。這個問題太大，也太容易吵。更有用的問題是：一個職業里，哪些部分只是在明確標準下完成局部執行？只接局部任務、寫局部實現、無法定義需求、無法審查跨文件影響、無法承擔系統驗收的人，價值會被壓縮。

姚順宇那條判斷在這里完成了職業轉譯：AI優先進入的不是某個職業名，而是職業內部可驗收、可拆解、可低成本糾錯的執行層。再壓一層，可以變成三個指標：第一，驗收速度；第二，糾錯成本；第三，你是不是在制定標準，而不只是執行標準。前兩個越高，第三個越低，風險就越近。

如果你的工作能被拆成輸入、輸出、標準和反饋，它就會開始變得像代碼。它比"程序員危險"更準確，也更難躲。因為它把所有職業都拉進來了。

人的價值會往反饋責任遷移

被壓縮的是純執行，不是所有人的價值。問題在于你有沒有從執行層往反饋層遷移。人的價值會往上游和下游遷移：上游是定義任務、組織上下文、設定邊界；下游是審查結果、設計驗收、承擔取舍。中間那段純執行，會被越來越多的AI工作者接走。

程序員的價值不再只在手寫實現上。AI進入以后，人要更擅長定義任務邊界，給模型足夠上下文，知道哪些文件不能動，知道結果如何驗收，知道一個局部修改會不會影響系統其他部分。更稀缺的是你能不能組織一批AI工作者去做事，然后對結果負責。

產品經理也一樣。PM的價值不在于把一句需求擴寫成三頁文檔，而在于把模糊目標變成可驗證的問題、指標、實驗和復盤。你能不能判斷用戶真正需求是什么，能不能定義成功標準，能不能在數據不好時判斷是方向錯了還是執行錯了。

無法驗收，就是AI協作里的最高優先級問題。一個任務如果沒有成敗標準，就很難交給AI穩定執行。下一階段稀缺的，已經不只是會寫代碼或懂產品的人，而是能管理AI工作者的人。

不要先問學AI編程還是學產品

所以以后不要先問學AI編程更安全，還是學產品更安全。這個問題仍然停在職業名上。職業名只是股票代碼，決定風險的是底層資產。

你可以先問五個問題：你的結果能否自動驗收？任務能否拆成小閉環？上下文是否結構化？失敗能否低成本糾錯？你是否擁有標準設定和取舍責任？前四個答案越是"是"，而最后一個答案越是"否"，你手里的那部分工作就越容易站在第一排。反過來，如果你能定義問題、組織上下文、設定驗收、承擔取舍，AI進入以后，你反而會被放大。

職業榜單還是會繼續流行。但真實的AI改造不按這個邏輯走。它不先問你是什么職業，而先問你的工作能不能被評價、復盤和重來。姚順宇的判斷給這篇文章留下的，不是一張職業排名，而是一套更冷靜的看法：不要把職業名當護身符，也不要把某個工具當災難本身。AI改造工作的順序，更像是在尋找反饋最清楚的地方。