#Coding
AI Coding 走到深處:金融開發中心為什麼必須走向“一崗一助手”
金融智能研發的下一步,不是給所有人一個統一聊天框,而是讓每個崗位都有自己的 AI 助手。萬能助手解決個人效率,一崗一助手解決金融級生產流程。金融研發不是一個動作,而是一條由崗位、流程、權限、知識和責任組成的長鏈條。一崗一助手,把 AI 從“黑盒聊天工具”變成了“可審計的生產節點”。萬能助手像一個人帶了一台“萬能破譯機”;一崗一助手像每個工位都配了一把“帶行車記錄儀的專用工具”。測試、交付、維運不智能化,AI Coding 只會把壓力往後傳。崗位智能體真正改變的,不是某個環節的效率,而是研發全鏈路的協同方式。未來金融開發中心,不只是人力組織,而是一套“人 + 智能體 + 知識資產 + 流程規則 + 責任邊界”共同運行的生產系統。01. 萬能助手為什麼不夠用金融機構做 AI Coding,為什麼一個統一 萬能的AI 助手不合適,它能問答,能寫程式碼,能解釋報錯,能生成單測,能總結文件,所有研發人員都可以用。這一步當然有價值。它能快速降低 AI 使用門檻,讓一線研發人員先感受到 AI 的能力,也能在很多零散場景裡帶來效率提升。但只要真正進入金融研發流程,就會發現一個萬能助手很快不夠用。因為金融研發不是一個單一動作,而是一條長鏈條。一個需求從業務想法到生產運行,至少要經過需求、設計、編碼、測試、交付、維運。每個環節的上下文不同、工具不同、權限不同、風險不同、責任也不同。產品經理關心業務目標和需求邊界。架構師關心系統邊界、介面關係和長期可維護性。開發人員關心程式碼實現、工程規範和單元測試。測試人員關心場景覆蓋和出口質量。交付人員關心版本完整性和投產風險。維運人員關心故障定位、告警降噪和生產穩定。這些崗位表面上都在“做軟體”,但實際面對的是完全不同的問題。一個萬能助手如果同時服務所有崗位,最後很容易變成“什麼都能答一點,但什麼都不夠深入”的通用問答工具。它適合個人提效,不適合進入金融級生產流程。所以,AI Coding 走到深處,金融開發中心需要的不是一個越來越大的萬能助手,而是一組越來越懂崗位、懂流程、懂責任的崗位智能體。02. 一崗一助手不是把 AI 拆複雜而是把 AI 放進真實生產關係為什麼要切這麼細?不是為了複雜,而是因為金融研發本來就是按崗位、流程、權限、責任和風險組織起來的。AI 要進入生產,也必須按同樣的方式被組織起來。從責任邊界看,需求是誰確認的,設計是誰稽核的,程式碼是誰採納的,測試是誰放行的,版本是誰交付的,故障是誰處置的,都必須清楚。一個萬能助手跨越多個崗位,很容易讓責任變模糊。崗位智能體對應崗位責任,需求助手就處理需求,設計助手就處理設計,編碼助手就處理編碼,交付和維運也各自有邊界。邊界清楚,責任才清楚;責任清楚,AI 才敢進入生產流程。從專業上下文看,不同崗位需要的知識完全不一樣。需求智能體需要業務規則、產品範本和需求用例。設計智能體需要應用架構、介面文件、表結構和歷史程式碼。編碼智能體需要工程規約、程式碼上下文和開發工具。測試智能體需要測試資產、測試資料和缺陷案例。交付智能體需要流水線、版本、環境和投產規則。維運智能體需要日誌、指標、鏈路和告警知識。上下文不一樣,智能體就不能混用。拿一個通用助手去服務所有崗位,就像拿一把瑞士軍刀去修飛機:能擰幾個螺絲,但不可能成為生產線上的專業工具。從工作流看,金融研發不是隨問隨答,而是流程驅動。需求輸出要進入設計,設計輸出要進入編碼,編碼輸出要進入測試,測試結果要進入交付,生產問題還要反哺維運和研發知識庫。崗位智能體不是孤立回答問題,而是流程節點上的執行者和連接器。從權限安全看,不同崗位能看什麼、能調什麼、能執行什麼,必須被嚴格劃開。需求智能體不能隨意呼叫生產日誌。編碼智能體不能越過程式碼門禁。交付智能體不能繞過投產審批。維運智能體不能在沒有授權和留痕的情況下執行生產動作。從效果評估看,萬能助手很難評價真實價值,但崗位智能體可以被量化。需求智能體看需求澄清效率和需求用例質量。設計智能體看設計採納率和設計缺陷檢出率。編碼智能體看程式碼採納率、AI 入庫率、單測覆蓋率。測試智能體看案例覆蓋率、缺陷發現率、測試結果精準率。交付智能體看風險提前識別率。維運智能體看故障定位精準率和平均處置時間。一崗一助手不是技術花樣,而是金融研發組織邏輯在 AI 時代的自然延伸。萬能助手像一把什麼都能碰一下的瑞士軍刀。一崗一助手更像流水線上的專用工裝,每個工位都為自己的任務、標準和責任而設計。03. 一崗一助手本質是在提高 AI 研發的確定性金融機構不能只追求 AI “會不會做”,更要追求 AI “能不能穩定地做、按規矩做、出了問題能不能說清楚”。通用大模型天然帶有隨機性。同一個問題,不同上下文、不同提示方式、不同模型版本,可能生成不同答案。對個人寫材料、寫程式碼初稿,這不一定是大問題;但對金融研發來說,這就是生產風險。金融軟體不是創意寫作,它有明確技術堆疊、架構邊界、介面規範、資料口徑、安全要求、測試標準和投產流程。AI 如果脫離這些約束自由發揮,越能生成,越可能帶來不可控。一崗一助手的價值,就是把大模型的通用能力壓進具體崗位的工作秩序裡。需求智能體通過業務規則、產品範本和驗收標準約束輸出。設計智能體通過應用架構、介面關係、表結構和歷史程式碼約束輸出。編碼智能體通過工程規約、程式碼上下文和安全規則約束輸出。測試智能體通過測試資產、缺陷案例和覆蓋標準約束輸出。交付智能體通過流水線、環境、版本和門禁規則約束輸出。維運智能體通過日誌、指標、鏈路和告警知識約束輸出。這樣,AI 就不是憑感覺回答問題,而是在崗位知識、崗位規約、崗位流程和崗位權限之內工作。萬能助手像一個聰明但不熟悉規矩的新員工,什麼都願意試;崗位智能體像一個被帶過、看過制度、知道邊界、懂審批流的熟練工。金融研發不怕 AI 聰明,怕的是 AI 聰明得沒有邊界,一崗一助手,就是給 AI 立邊界、裝規矩、接流程。萬能助手解決的是“個人能不能用 AI”。崗位智能體解決的是“組織能不能把 AI 放進生產流程”。04. 一崗一助手更符合金融行業的強審計要求金融行業做 AI,不只是看“能不能生成”,還要看“能不能審計”,強監管環境下,審計最關心的是這件事能不能被追溯:誰在什麼時間,基於什麼權限,呼叫了什麼能力,使用了那些資料,生成了什麼結果,誰稽核採納,最後流向那裡。萬能助手最大的問題,是邊界太寬。所有人都在同一個通用助手裡提問,輸入輸出混在一起,事後只能翻一堆聊天記錄,很難判斷某個結果到底屬於需求分析、設計判斷、編碼建議、測試結論,還是交付決策。某種意義上,萬能助手就像一個人帶了一台“萬能破譯機”:看起來什麼都能做,但誰用它做了什麼、基於什麼權限做、結果流向那裡,並不容易說清楚。一崗一助手更像每個工位都配了一把“帶行車記錄儀的專用工具”。需求智能體處理需求,設計智能體處理設計,編碼智能體處理程式碼,測試智能體處理覆蓋,交付智能體處理版本風險,維運智能體處理故障鏈路。每個智能體都對應一個崗位、一個流程節點、一類權限和一組輸出物。這就把 AI 從“黑盒聊天工具”,變成了一個個“可審計的生產節點”。它至少帶來四個變化。第一,責任主體更清楚。出了問題,可以沿著崗位鏈條追溯,而不是籠統地說“AI 生成的”。第二,日誌從聊天記錄變成生產記錄。一崗一助手留下的是任務編號、關聯需求、輸入文件、呼叫工具、生成結果、稽核記錄、流轉節點,更適合自動化審計。第三,合規護欄可以按崗位嵌入。測試智能體可以強制檢查測試資料脫敏,編碼智能體可以強制掃描硬編碼金鑰和開源漏洞,交付智能體可以強制校驗投產審批單和環境一致性,維運智能體可以強制記錄生產訪問授權和操作留痕。第四,異常監控更精準。當智能體按崗位拆分後,管理平台可以監控每個智能體的呼叫量、權限訪問、Token 消耗、失敗率、越權嘗試和異常行為。需求智能體不該頻繁訪問日誌。維運智能體不該在非窗口期呼叫生產工具。交付智能體不能繞過審批檢查。這些異常在萬能助手裡很容易被淹沒,在崗位智能體體系裡卻能更快被發現。所以,一崗一助手不是把 AI 做複雜,而是把 AI 放進可追溯、可治理、可問責的生產秩序裡。對金融機構來說,審計不是事後翻聊天記錄,而是從一開始就讓 AI 在正確的崗位邊界裡工作。05. 全球共識 Agent 必須進入工作流也必須被治理從公開實踐看,全球頭部金融機構正在形成共同方向:AI 研發不會停留在一個通用聊天框,而會進入崗位、流程和責任邊界。DBS 對 Agentic AI 治理的表述很有代表性。DBS 認為,真正的 AI 自主並不意味著沒有控制,而是需要更有策略的控制;其 AI 部署強調人類監督治理,包括升級路徑、審計軌跡和 fallback 機制,以確保決策可解釋、可問責並與意圖一致。DBS 還提出,企業在部署多個 agent 時,需要考慮 agentic control plane,對企業內所有 agent 進行監督。Citi 的做法更能說明責任邊界。公開報導顯示,Citi 正在向 4 萬名開發者推出 agentic AI,用 Devin 處理軟體補丁、升級等任務;其技術負責人明確表示,不允許 agent 部署程式碼,agent 只產出 artifacts,交給開發者,並經過自動測試和人工 review。Citi 還把內部軟體文件、最佳實踐和知識庫用於約束 agent 行為,不希望 agent “創造性地”引入新技術。Morgan Stanley Research 的判斷也很直接:當 AI coding assistants 和 agents 成為標準開發工作流後,傳統軟體工程師會更多轉向複雜應用,成為 curators、reviewers、integrators 和 problem-solvers,變得更戰略、更有價值;同時,AI 生成程式碼增多,也會把瓶頸推向程式碼審查、測試、安全、驗證和部署等後續環節。Bank of America 的公開材料也提到,其 AI 方法包括 human oversight、transparency 和 accountability for all outcomes;其軟體開發人員也在使用 GenAI 工具輔助程式碼編寫和最佳化,效率提升超過 20%。這些案例放在一起看,結論很清楚:金融機構不是不敢用 Agent,而是必須把 Agent 放進工作流、權限邊界、稽核機制和治理框架裡。這也是一崗一助手的核心邏輯。讓 AI 幹活可以,但不能讓 AI “無證駕駛”。金融研發裡的 Agent,不是無人駕駛汽車沖上高速,而是進了調度系統、裝了行車記錄儀、限定了路線、設定了剎車、有人遠端監管的專業車輛。06. 招行的啟示 從程式碼助手走向任務級研發智能體招行這條線,最值得看的不是“通用模型”,而是直接進入研發現場的 DevAgent。深圳市委金融辦發佈的招商銀行項目展示中提到,招行自研“研發智能體 DevAgent”,採用“感知—規劃—執行—反饋—進化”的多輪互動 ReAct 模式,可結合程式設計現場環境感知、企業研發知識檢索等工具,以開發者業務目標為驅動,提供任務級功能需求開發能力,並具備跨檔案、大片段程式碼生成能力。公開材料顯示,DevAgent 每月完成超過 4.8 萬個開發任務。這說明頭部銀行的 AI 研發已經不只是“問答 + 程式碼補全”,而是在把 AI 放進真實開發現場。它要理解當前工程環境,呼叫企業研發知識,拆解開發任務,並在多輪反饋中完成任務。DevAgent 的關鍵詞不是“通用”,而是“現場感知、知識檢索、任務級開發、跨檔案生成”。這恰好說明,金融研發 Agent 的方向不是萬能助手,而是懂崗位、懂工程、懂企業知識的專業智能體。一個真正能進入開發現場的 AI,不能只會說“我建議你這樣寫”;它還要知道這個工程在那裡、規範是什麼、改那些檔案、影響那些介面、怎麼跑檢查、最後誰來稽核。07. 工商銀行樣本 一崗一助手 更像金融級研發秩序重建在中國金融科技語境下,工商銀行的智能研發建設尤其值得關注。作為超大規模金融機構,工商銀行面對的是超大規模客戶、複雜系統體系、高安全合規要求和大規模研發組織協同。在這樣的背景下推進 AI Coding,難點不是接一個程式碼助手,而是如何讓 AI 進入真實研發流程,並且可控、可審計、可規模化。從前面整理的建設方案看,工商銀行智能研發不是只做程式碼補全,而是圍繞需求、設計、編碼、測試、交付、維運全流程,推進智能研發能力建設。這個路徑的核心,不是“AI 能不能寫程式碼”,而是“AI 能不能在金融級軟體工程體系中穩定工作”。一崗一助手在這樣的超大組織裡,價值更明顯。需求、設計、編碼、測試、交付、維運每個環節都有自己的責任邊界,每個崗位都有自己的知識資產,每個階段都有自己的輸入輸出。如果只有一個萬能助手,很難承接這種複雜度。只有把 AI 按崗位拆開、按流程接起來、按責任管住,才可能進入金融級研發體系。這也是大型金融機構做 AI Coding 最容易被低估的一點:不是模型接入了,智能研發就完成了。真正難的是讓模型進入秩序,讓生成進入流程,讓結果進入審計,讓責任有人承接。08. 需求原型智能體 讓產品經理從“寫需求” 走向“定義意圖”需求階段,是金融研發最容易出偏差的地方。業務說一個方向,產品理解一版,開發再轉譯一版,測試最後補缺口。等系統做出來,才發現最初的業務意圖沒有被精準表達。這種損耗,在大型金融機構裡非常常見,需求原型智能體要解決的是需求階段的“第一公里”。它不是簡單幫產品經理寫幾段需求,而是把自然語言、會議討論、業務說明、草圖、歷史範本和同類案例,轉化為更清晰的需求資產。對產品經理來說,最大的變化是:需求不再只是寫一份文件,而是要把業務意圖轉化為可以被設計、編碼、測試繼續使用的結構化資產。需求智能體可以輔助生成原型,讓業務、產品、設計和開發圍繞一個“看得見的東西”討論。過去大家對著一段文字爭半天,現在可以先看到互動雛形,再討論流程、權限和邊界。它也可以輔助生成需求用例,把使用者角色、業務流程、輸入輸出、異常情況、權限邊界、資料口徑和驗收標準補齊。這樣下游拿到的不是一句“我要一個功能”,而是一組更接近可執行的需求資產。對產品經理來說,這不是被 AI 替代,而是要求更高了,未來好的產品經理,不只是會寫需求的人,而是能把業務目標講清楚、把邊界定義清楚、把 AI 生成結果判斷清楚的人。產品經理過去像“翻譯”,把業務話翻譯成研發話。未來產品經理更像“導演”,要讓業務、AI、設計、開發、測試在同一個鏡頭裡對齊。09. 設計智能體 讓架構師從“補文件”走向“沉澱系統邊界”在金融研發裡,設計階段最容易被低估。很多系統不是新建系統,而是在複雜存量系統上不斷演進。裡面有歷史程式碼、舊介面、表結構、公共元件、上下游依賴、技術債和業務規則。如果設計階段沒有把這些內容理解清楚,後面 AI 生成程式碼越快,返工也可能越快。設計智能體的價值,是幫助架構師和開發骨幹理解存量系統,並生成更高品質的設計。它不能唯讀當前需求,還要理解應用架構、功能清單、介面文件、表結構、歷史程式碼、公共方法和已有設計文件。它要知道這個系統過去怎麼做,那些地方能復用,那些介面不能亂動,那些模組有歷史約束。對架構師來說,最大的變化是:設計不再只是寫給評審看的文件,而是要成為後續智能體能夠執行的結構化藍圖。過去設計文件主要給人看。未來高品質設計要同時給人看、給 AI 看、給測試看、給交付看。它要成為連接需求、編碼、測試和交付的中間資產,這會倒逼架構師的價值上移。未來優秀架構師,不只是懂系統的人,而是能把系統邊界、介面關係、工程規則和長期約束沉澱成 AI 可執行資產的人。過去架構師是“救火隊長”,那裡複雜去那裡。未來架構師更像“軌道設計師”,軌道鋪得越清楚,AI 這列高速列車才越不容易脫軌。10. 編碼智能體:讓開發人員從“敲程式碼”走向“帶 AI 幹活”編碼智能體是現在最容易被看見的崗位智能體,但真正成熟的編碼智能體,不只是“幫我寫一段程式碼”。它要能理解任務、讀取上下文、遵守規約、呼叫工具、生成程式碼、生成單測、執行自檢,並在發現問題後自動修復。一個典型過程是:開發人員給出任務目標,編碼智能體讀取需求規格、詳細設計、工程規約、程式碼上下文和歷史資產;然後拆解任務,判斷需要改那些檔案、呼叫那些公共方法、補那些單測;再生成程式碼、運行檢查、修復問題,最後把結果交給開發人員稽核。對開發人員來說,最大的變化是:過去大量時間花在寫範本程式碼、補欄位、查規範、寫單測、改小錯上;未來這些工作會更多由智能體承擔。開發人員要做的,是把任務講清楚,把設計看明白,把規約補完整,把生成結果審得住。這不是開發人員價值下降,而是開發人員價值重新定價。未來好的開發人員,不只是寫程式碼快的人,而是會拆任務、會用 AI、懂系統、能審查、能兜住複雜邏輯的人。以前開發人員像“親自下地幹活的人”。未來開發人員更像“帶一組 AI 工人的工長”。活可以讓 AI 干,但圖紙對不對、工序對不對、質量過不過關,最後還得人接得住。11. 測試智能體讓測試人員從“後面接鍋”走向“前面設防”如果只做編碼智能體,不做測試智能體,智能研發很容易出問題,AI 生成程式碼越多,測試壓力也越大。如果測試仍然靠人工補案例、人工構造資料、人工執行指令碼,AI Coding 只是把壓力從開發環節推到了測試環節。這就像高速入口拓寬了,但收費站還是老樣子,車流遲早會堵在後面。測試智能體的關鍵價值,是讓測試從“後置執行”轉向“同步設計、自動構造、結果分析”。它要能基於需求、設計和程式碼生成測試案例,覆蓋正常流程、異常流程、邊界場景、權限場景和資料口徑。它要能理解業務資料結構、欄位約束、帳戶狀態、交易狀態和資料依賴,輔助構造可用測試資料。它還要能生成測試指令碼,分析失敗原因,判斷是環境問題、資料問題、指令碼問題,還是程式碼缺陷。對測試人員來說,最大的變化是:不再只是反覆執行案例,而是要設計質量體系。未來好的測試人員,不只是找 bug 的人,而是能定義覆蓋標準、識別遺漏場景、審查 AI 測試結果、把住質量出口的人。過去測試像“最後一道安檢”。未來測試要更像“全流程雷達”。不是等飛機落地再看有沒有問題,而是在起飛前、飛行中、降落前都持續發現風險。12. 交付智能體讓交付人員從“臨門救火”走向“提前控險”金融研發的交付環節,有大量流程、檢查、配置、環境、依賴和審批,很多問題不是編碼時暴露,而是在持續整合、版本打包、環境部署、投產交接和上線驗證時暴露,過去這些環節高度依賴交付人員經驗,一旦資訊不完整,風險很容易到最後一刻才出現。交付智能體要解決的是研發到投產之間的“最後一公里”。它不是簡單幫人點流水線,而是要成為“AI 交付工程師”。在資源供給階段,它可以根據需求項、應用、交付日期和投產安排,輔助識別程式碼庫、分支、環境、流水線和發佈單元。在持續整合階段,它可以監控建構失敗、門禁異常、部署異常,分析原因並推薦修複方案。在版本交付階段,它可以生成版本交付報告,識別程式碼增量、配置變更、門禁異常、環境差異和潛在風險。在投產前,它可以圍繞部署複雜度、歷史故障率、環境差異度和依賴關係,給出風險提示和處置建議。對交付人員來說,最大的變化是:過去很多精力花在流程操作和事後協調,未來更重要的是提前識別風險、組織閉環處置、保障版本穩定。交付智能體的價值,不只是減少人工操作,而是讓風險提前暴露。過去交付像“臨門一腳”。未來交付更像“塔台調度”。每一架飛機能不能起飛,天氣、跑道、路線、機組狀態都要提前看清楚。13. 維運智能體讓維運人員從“告警疲勞”走向“故障推理”很多智能研發文章講到程式碼生成就結束了,但金融系統真正的考驗在生產運行,服務超時、CPU 沖高、資料庫異常、鏈路波動、日誌堆積、告警風暴,這些問題發生時,真正需要的是快速定位、精準判斷和穩定處置。維運智能體要做的,不是簡單回答“這個報錯是什麼意思”,而是模擬資深維運專家的分析過程。它要能讀取指標、日誌、鏈路、告警、變更記錄和歷史故障案例;要能形成診斷計畫;要能邊查邊調整;要能在多個可能原因中做排除;要能生成故障分析報告;還要能把這次處置經驗沉澱為後續可復用的維運知識。對維運人員來說,最大的變化是:不再只是被告警推著跑,而是要把故障模式、處置路徑和專家經驗沉澱成組織能力。一個老專家知道先看那條鏈路、那個指標、那個歷史問題,新人很難一下子掌握。維運智能體如果能把專家經驗變成標準化診斷技能,就可以縮短新人學習曲線,也可以提升常見故障定位效率。維運智能體成熟以後,研發閉環才真正完整。因為生產反饋可以反哺設計、編碼、測試和交付,形成持續改進。過去維運像“消防隊”。未來維運更像“城市神經系統”。不僅要救火,還要提前感知那裡升溫、那裡堵塞、那裡可能出事。14. 一崗一助手的關鍵不是各做各的而是上下游協同一崗一助手聽起來像每個崗位都有一個獨立 AI,但真正的價值不在“獨立”,而在“銜接”。需求智能體生成的需求用例,要能進入設計智能體。設計智能體生成的詳細設計,要能被編碼智能體讀取。編碼智能體生成的程式碼和單測,要能被測試智能體接住。測試智能體發現的問題,要能反饋給編碼智能體修復。交付智能體發現的版本風險,要能反饋給開發和測試。維運智能體發現的生產問題,要能沉澱為知識資產,反向最佳化設計、測試和交付。如果每個智能體只是孤立工作,智能研發仍然是碎片化的,只有當結構化資產在智能體之間持續流轉,金融研發才會從“人和人之間反覆傳話”,變成“資產和流程在系統中自動銜接”。未來研發流程裡最重要的資產,可能不再只是程式碼,而是需求規格、設計資產、測試資產、交付資產、維運知識和規約體系。這些資產如果能持續流轉,智能研發才會越來越強。一崗一助手不是把每個崗位都做成一個小煙囪。它要做的是把每個崗位變成一段標準化軌道,最後連成一條能跑起來的智能研發生產線。15. 開發中心以後不僅管人也要管 Agent一崗一助手帶來的變化,不只是崗位效率提升,也會改變開發中心的管理方式。過去管理研發,主要看人力投入、項目進度、缺陷數量、版本上線、生產問題。未來還要看智能體使用情況、任務閉環率、知識命中率、規約覆蓋率、AI 程式碼入庫率、測試自動生成率、交付風險提前發現率、故障定位精準率、反饋閉環率。過去主要管理人、項目和系統。未來還要管理智能體、知識資產、規約資產、模型能力、算力資源和人機協作流程。過去我們管人,管流程,管系統,未來還要管 Agent,不管 Agent,AI 就只是散落在個人電腦裡的效率工具,管住 Agent,AI 才可能成為金融級研發生產力的一部分。開發中心未來要多一張“智能體組織圖”:每個智能體負責什麼崗位,能呼叫什麼工具,能訪問什麼資料,輸出什麼資產,由誰稽核,進入那個流程。沒有這張圖,AI 越多越亂。有了這張圖,AI 才能從個人工具變成組織能力。16. 不是讓崗位消失是每個崗位都站到更高的位置一崗一助手,聽起來是 AI 工具的事情,做深了才知道是研發組織的事情。它不是給每個崗位配一個聊天窗口,而是把每個崗位的知識、流程、工具、責任和經驗重新整理一遍,讓 AI 真正進入崗位工作流。金融開發中心過去靠人傳經驗、靠文件傳流程、靠會議傳上下文。未來,這些經驗、流程和上下文,要逐步沉澱成智能體能理解、能呼叫、能執行、能反饋、也能被追溯和審計的生產資產。做到這一步,AI 才不只是“幫開發寫程式碼”,而是開始參與需求、設計、編碼、測試、交付、維運的完整鏈條。真正的一崗一助手,不是讓崗位消失,而是讓每個崗位都站到更高的位置。 (Space AIThinker)
用 AI 後,我效率翻 3 倍,人卻更疲憊,別再掉進這個陷阱了
「學不完,真的學不完。」這大概是每一個關心 AI 進展的人,在 2026 年開年最真實的心聲。模型、Agent 、Coding,每天刷新著我們的認知和焦慮 ,尤其是今年春節 AI 發佈的節奏甚至比平日更加瘋狂。我們被一種巨大的 FOMO(錯失恐懼)推著往前跑,生怕一不留神,就被時代甩在身後。但這種追趕是有代價的。像本文作者 Siddhant Khare 這樣的資深工程師,他身處 AI 基礎設施建設的核心,卻發現自己「產出越多,越被掏空」。當 AI 把我們從「創作者」變成了停不下來的「質檢員」,當效率的提升帶來了指數級增長的認知負荷,一種名為「AI 疲勞」的隱性流行病便開始蔓延 。我們都成了在 AI 倉鼠輪上奮力奔跑,卻感覺那裡都去不了的實驗品。同時最近大火的 Clawdbot ,開發者 Peter Steinberger 財富自由後「躺平」了三年,完美錯過了 AI 最喧囂浮躁的階段 。當他重新入場,純粹因為好玩與熱愛。他沒有追趕每一個熱點,只是為瞭解決一個自己真正著迷的問題 。我們發現,對抗 FOMO 最好的解藥,或許不是學得更多、更快,而是學得更「自私」一點。與其被動消費無窮無盡的新工具,不如主動去創造一個那怕很小,但完全屬於自己的東西。在這個過程中,你才能真正理解技術的邊界,建立自己的判斷體系,並從被 AI 消耗的疲憊感中,重新找回創造的樂趣 。我們希望將這篇文章分享給你,它沒有教你任何新的 AI 技巧,反而給在追趕 AI 更新的人潑了一盆冷水,我們試圖探討一種更可持續、也更人性的與 AI 共存的方式願你找到自己的節奏,重新變回 AI 的「主人」。以下是 APPSO 的編譯,在不改變原意的前提下進行了編輯:被忽略的 AI 疲憊上個季度,我提交的程式碼量創下了職業生涯的新高。與此同時,我也感到前所未有的被掏空。這兩件事,絕非巧合。我不是那種在周末隨便玩玩 AI 的票友。我以此為生——建構 AI Agent(智能體)基礎設施,是 OpenFGA 的核心維護者,親手打造了 agentic-authz 和 Distill 這樣的硬核工具。我深潛其中,為其他工程師製造著「讓 AI 在生產環境跑起來」的鏟子。然而,我碰壁了。這種精疲力竭,是任何工具最佳化或工作流調整都無法治癒的。如果你也是一名每天高強度使用 AI 的工程師——用它做設計評審、生成程式碼、Debug、寫文件——然後發現自己比 AI 出現之前更累了,那麼這篇文章就是為你寫的。你沒瘋,你不弱,你只是正在經歷一種被整個行業激進地假裝不存在的真實痛楚。如果像我這樣全職建構 Agent 基礎設施的人都會在 AI 面前燃盡,那它可能發生在任何人身上。我想聊聊那個「不加濾鏡」的版本。不是推特上那些「AI 太神了,看我絲滑工作流」的凡爾賽,而是那個真實的版本:晚上 11 點,你盯著螢幕,被一堆 AI 生成的程式碼包圍,明明是來幫你省時間的工具,卻吞噬了你的一整天。沒人警告過的「效率悖論」有個事兒讓我腦殼疼了好一陣:AI 確實讓單個任務變快了。這不是謊言。以前耗時 3 小時的活兒,現在 45 分鐘搞定。起草設計文件、搭建新服務腳手架、寫測試用例、研究陌生 API,統統加速。但我的日子卻變得更難了。不是更容易,是更難。原因說穿了很簡單,但我花了好幾個月才回過味來:當每個任務耗時變短,你並不會「少做點任務」,你會做「更多工」。你的產能看似擴容了,於是工作量便順勢填滿,甚至溢出。經理看你交付快了,預期自然水漲船高;你自己看自己快了,自我要求也跟著加碼。基準線,被悄悄抬高了。在 AI 之前,我可能花一整天死磕一個設計難題。我會畫草圖、在淋浴時思考、散步,然後帶回清晰的方案。節奏雖慢,但認知負荷是可控的。一個問題,一天時間,深度聚焦。現在呢?我一天可能要碰六個不同的問題。因為 AI 告訴我,每個問題「只需要一小時」。但人類大腦在六個問題之間來回切換的上下文成本,是極其昂貴的。AI 不會因為切換任務而疲勞,但你會。這就是悖論所在:AI 降低了「生產」的成本,卻指數級增加了「協調、審查和決策」的成本。而這些成本,全部由人類買單。被迫上崗的「流水線質檢員」以前,工程師的工作是:思考問題 -> 寫程式碼 -> 測試 -> 發佈。我是創作者,是 Maker。這正是我們當初入行的初衷——為了創造。AI 之後,我的工作逐漸變成了:寫提示詞 -> 等待 -> 閱讀輸出 -> 評估對錯 -> 檢查安全性 -> 判斷是否符合架構 -> 修補不對的地方 -> 重新提示 -> 重複。我變成了一個審稿人,一個法官,一個在永不停歇的流水線上疲於奔命的質檢員。這在心理學上是完全不同的工種。創造能帶來「心流」,而審查只會帶來「決策疲勞」。我第一次意識到這點,是在用 AI 狂寫一個微服務的那周。到了周三,我發現自己連最簡單的決定都做不出了。這個函數該叫啥?無所謂。配置放那?隨便吧。我的腦子滿了。不是因為寫程式碼滿的,是因為「評判」程式碼滿的。成百上千個微小的判斷,全天候轟炸。更殘酷的諷刺在於:AI 生成的程式碼比人類寫的更需要仔細審查。同事寫的程式碼,我懂他的路數、強項和盲區,我可以略讀信任的部分,重點看我不放心的。但面對 AI,每一行都是嫌疑人。程式碼看起來自信滿滿,能編譯,甚至能跑通測試,但它可能在某個隱秘的角落埋雷,只在凌晨 3 點生產環境負載拉滿時才爆炸。所以你必須逐行閱讀。去讀那些你沒寫過、由一個不懂你程式碼庫歷史和團隊習慣的系統生成的程式碼,這本身就是一種精神酷刑。這也是為什麼我認為 Agent 的安全和授權如此重要。如果我們沒法在大規模下審查 AI 產出的每一行程式碼——事實上我們確實做不到——那我們就必須從源頭上限制 Agent 的權限。最小權限原則、範圍受限的 Token、審計日誌。越少擔心「AI 幹了什麼蠢事」,留給真正重要工作的認知預算就越多。這不僅是安全問題,更是人類的可持續性問題。消失的「確定性契約」工程師是被「確定性」喂大的。輸入 A,得到 B。這是契約,是偵錯的基礎,是我們理解系統的基石。AI 撕毀了這份契約。周一運行完美的提示詞,生成了乾淨漂亮的 API 程式碼。周二用同樣的提示詞跑類似的任務,輸出結構變了,錯誤處理邏輯換了,還引入了我沒要求的依賴。為什麼?沒理由。或者說,沒有我可以理解的理由。沒有堆疊跟蹤告訴我「模型今天決定換個口味」,沒有日誌顯示「溫度採樣選了路徑 B」。它就是……變了。對於職業生涯建立在「如果壞了,我就能找出原因」之上的工程師來說,這種感覺極其不安。不是那種劇烈的恐慌,而是一種緩慢的、研磨般的背景焦慮。你永遠無法完全信任輸出,永遠無法完全放鬆。每一次互動都需要保持警惕。這種挫敗感最終逼我做出了 Distill——一個針對 LLM 的確定性上下文去重工具。沒有 LLM 呼叫,沒有嵌入,沒有機率玄學。純演算法,12 毫秒搞定。我想在 AI 流水線裡至少保留一塊我可以推理、偵錯和信任的淨土。如果模型的輸出註定是薛定諤的貓,那我至少要保證輸入是乾淨可控的。我見過應對得最好的工程師,都是那些與此「和解」的人。他們把 AI 輸出當成一個聰明但不靠譜的實習生交來的初稿。他們預期要重寫 30%,他們為此預留了時間。因為從未指望它完全正確,所以當它出錯時,他們不會炸毛。他們指望的是「有用」,而非「正確」。這中間的區別大了去了。被 FOMO 追趕的倉鼠輪深吸一口氣,回頭看看這幾個月發生了什麼:Claude Code 發佈子智能體,然後是 Agent SDK;OpenAI 推出 Codex CLI;Google 甩出 Gemini CLI;GitHub 搞了 MCP 登錄檔;收購案每周都在發生;各種 Agent 框架像雨後春筍:CrewAI, AutoGen, LangGraph, MetaGPT……當你還在研究這個,那個已經過時了。就連 LinkedIn 上的「野生導師」都在恐嚇你:「2026 年還不用子智能體編排,你就被淘汰了!」這不是一年的變化,這是幾個月。我曾狠狠掉進這個坑裡。周末用來評測新工具,看每一個更新日誌,看每一個演示。因為恐懼落後,我強迫自己站在前沿。結果呢?周六下午折騰一套新 AI 編碼工具,周日剛跑通工作流,周三就有人發帖說另一個工具「完爆這個」。焦慮感瞬間襲來。下個周末,我又在折騰新東西。這就好像一隻倉鼠,從一個輪子跳到另一個輪子,每次遷移都耗費一個周末,換來的可能是 5% 無法感知的效率提升。最可怕的是「知識折舊」。2025 年初,我花兩周精心打磨了一套複雜的提示工程工作流。鏈式思維、少樣本示例,那是相當完美。三個月後,模型更新了,最佳實踐變了,我那些複雜的範本跑出來的結果甚至不如一句簡單的大白話。那兩周的時間,不是投資,是浪費。這就是為什麼我現在改變了策略:別追工具,追基礎設施。工具來來去去,但問題永存。上下文效率、授權、審計、執行階段安全——無論這個月流行那個框架,這些底層問題都在。所以我建立 agentic-authz 是基於 OpenFGA,而不是繫結在某個特定的 Agent 框架上。建立在那些不會輕易變質的層面上。「再試一次」的陷阱這個陷阱極其陰險。第一次輸出 70% 正確。你最佳化提示詞。第二次 75% 正確,但把第一次對的地方改錯了。第三次 80% 正確,但結構全亂了。第四次……如果你一開始就自己寫,20 分鐘早就搞定了,現在你已經耗了 45 分鐘。我稱之為「提示詞螺旋」。這就像給犛牛剃毛。你本以此為目標,半小時後卻在偵錯提示詞而不是偵錯程式碼。你在最佳化對語言模型的指令,而不是解決實際問題。這種螺旋很危險,因為它讓你「感覺」很高效。你在迭代,你在逼近真相。但邊際收益遞減得飛快,你忘了最初的目標只是「發佈功能」,而不是「讓 AI 產出完美程式碼」。現在我有一條鐵律:事不過三。如果三次提示還得不到 70% 可用的結果,我就自己寫。這條規則幫我省下的時間,比任何提示詞技巧都多。完美主義者的地獄工程師通常有潔癖。我們要乾淨的程式碼,要全綠的測試。這讓我們擅長建構可靠的軟體。但 AI 的輸出永遠是「湊合」。70-80% 的完成度。變數名有點怪,錯誤處理不完整,邊緣情況被忽略。它能跑,但它「不對味」。這對完美主義者來說簡直是酷刑。因為「差點意思」比「完全錯誤」更難受。完全錯誤你可以直接重寫;差點意思你就得花一小時去微調。修補別人的爛程式碼(尤其是這種沒品位、沒上下文的機器程式碼)是極其令人沮喪的。最受折磨的往往是最好的工程師。 那些標準最高、眼光最毒的人。而 AI 時代獎勵的是另一種技能:能夠迅速從不完美的輸出中提取價值,而不對「完美」產生情感執念的能力。思考能力的肌肉萎縮這是最讓我害怕的一點。某次設計評審,有人讓我在白板上推導一個並行問題。沒電腦,沒 AI,就我和一支筆。我卡殼了。不是我不懂概念,而是那塊肌肉太久沒練了。我太習慣把初稿外包給 AI,導致自己「從零思考」的能力退化了。就像 GPS 毀了我們的認路能力一樣,如果總是先問 AI,你就無法建立那些只有通過「死磕」才能形成神經回路。掙扎是學習的必經之路,困惑是理解的前奏。跳過這些,你得到的是更快的產出,和更淺薄的理解。現在,我強迫自己每天第一個小時完全不用 AI。紙上思考,手畫架構。這感覺很低效,確實低效。但這能保持思維敏銳,而這種敏銳度在我隨後使用 AI 時是無價的——因為只有大腦熱身過,我才能更好地審判 AI 的輸出。比較陷阱與倖存者偏差社交媒體上滿是 AI 大神。「我用 AI 2 小時做完了整個 App!」你看看自己:失敗的提示詞、浪費的時間、重寫的程式碼。你會想:我有毛病?你沒毛病。那些帖子是「集錦」。沒人會發帖說:「我花了 3 小時想讓 Claude 理解我的資料庫架構,最後放棄了自己手擼了 SQL。」沒人會發帖說:「AI 生成的程式碼吞了一個報錯,導致生產事故。」沒人會說:「我累了。」如果一個資訊流讓你感到落後而不是知情,那就取關它。 去關注那些真正在建設、在發佈產品的人,而不是只會做 Demo 的人。真正的技能是「知道何時停手」在這個時代,最重要的技能不是提示詞工程,不是選模型,也不是工作流。是「止損」的能力。知道何時 AI 的輸出已經夠好了;知道何時該自己接手;知道何時合上筆記本;知道何時微小的改進不值得巨大的認知成本。我們給系統設計熔斷機制、背壓機制,我們也應該給自己設計一套。AI 是我用過最強大的工具,也是最耗能的。這不矛盾。在這個時代能活得好的工程師,不是用 AI 最多的人,而是用得最「明智」的人。如果你累了,不是因為你做錯了什麼,實際這真的很難。工具是新的,模式還在成型,行業在假裝「更多產出 = 更多價值」。但這不成立。可持續的產出,才是價值。保護好你的大腦。那是你唯一的資產,沒有任何 AI 能替代它。 (APPSO)
GLM-5 漲價背後的真相:算力稀缺才剛剛開始
一個意料之中的訊號昨天上午,智譜 GLM-5 的 Coding Plan 漲價 30%。這個事情引起了很大的討論,我也非常理解,畢竟價格是最敏感的話題。當時我的第一反應是:終於還是漲了。雖然很反共識,但我一直預期 Token 會漲價,這個訊號是對我預期的一個確認。模型越強,Token 越稀缺,價格越貴。智譜在商業化上確實顯得不夠成熟,他們最大的失誤就是低估了模型能力進步帶來的指數級增長,一開始給的 plan 太大方,現在模型更大了,算力不夠,要麼砍用量,要麼漲價,沒有商業模式支撐的服務無法健康長久。昨晚一個朋友因為沒買到 Coding Plan,來借我的 API key。這時候我才意識到,這次漲價之後,依然是限購狀態。漲價+限購,一代人有一代人的茅台?漲價背後的真相要理解這次漲價,只需要看清一個結構性矛盾:供給是線性的,需求是指數的。先看供給側。Google 2026 年的資本開支相比2025年,差不多翻倍。這已經是全球最有錢的科技公司之一,傾盡全力在砸算力基礎設施了。你不可能讓台積電明天就多造出十倍的晶片。供給側的增長曲線,是一條緩慢爬升的直線。再看需求側。需求不是一重指數,是三重指數疊加。第一重指數:Coding 模型能力提升解鎖新場景。特別是從 Vibe Coding 到嚴肅的 Agentic Engineering 這一躍升。每一次能力提升,都打開一片10倍的 Token 消耗場景。第二重指數:Agent 數量本身在爆發式增長。在未來一個人背後可能有 10 個、100 個 Agent 在 7×24 小時不間斷地呼叫模型。人會睡覺,Agent 不會。人一天工作 8 小時,Agent 一天工作 24 小時。Agent 的數量乘以 Agent 的工作時長,這個數字的增長速度遠超任何人類使用者的增長。第三重指數:Seedance 2.0,Nano Banana Pro 這樣的多模態模型的 Token 消耗量遠超純文字。視訊生成、圖像理解、程式碼工程,每一個場景的單次消耗都是純文字對話的幾十倍甚至上百倍。當這些場景被模型能力解鎖之後,Token 的消耗量會出現斷崖式的躍升。三重指數疊加在一起,面對的是一條線性增長的供給曲線。供給翻 2 倍,需求翻 10 倍甚至 100 倍。這種結構性的失衡,在可預見的未來一年內,只會增強不會逆轉。所以漲價不是智譜的選擇,是物理定律的選擇。有人天真地說,不用擔心,大廠會打價格戰的。你見過賣金鋪打價格戰嗎?稀缺的東西,不存在價格戰。GLM-5 憑什麼值這個價漲價 30% 需要底氣,這種底氣憑什麼?看三件事就夠了。第一,Coding 能力逼近 Claude Opus 4.5。GLM-5 幾個 Coding 能力的跑分上,已經追上了 Sonnet 4.5,開始朝著 Opus 4.5 逼近。在多個權威指標上都是開源模型的 SOTA。跟自己比,從 GLM-4.7 到 GLM-5,內部評估的程式設計任務平均增幅超過 20%。除了指標的提升外,GLM-5 不只是"寫程式碼更好了",而是從寫程式碼進化到了寫工程。它能自主完成後端重構、深度偵錯、長程規劃與執行,已經在朝著資深架構師的方向邁進。第二,Agent 能力是真正的長程任務執行。在 BrowseComp、MCP-Atlas、τ²-Bench 三個 Agent 評測基準上,GLM-5 均為開源第一。在 Vending Bench 2 的模擬經營測試中,GLM-5 經營一年期的自動售貨機業務,最終帳戶餘額達到 4432 美元,接近 Opus 4.5。有些榜是可以刷的,但模擬經營榜,代表模型真的能"做事"。長程任務中的目標一致性、資源管理、多步驟依賴處理,是 Agentic Engineering 時代的核心能力。第三,模型參數翻倍,推理成本也提高了。GLM-5 的參數規模從 355B(啟動 32B)擴展到 744B(啟動 40B),預訓練資料從 23T 提升到 28.5T,以 MIT License 完全開源。在頂級模型中,這種開放程度極為罕見。同時值得注意的是,GLM-5 已經完成了與華為昇騰、寒武紀、摩爾線程等國產算力平台的深度適配。在全球算力稀缺的大背景下,這件事的戰略意義非同小可。總之,使用者付的錢多了 30%,但拿到的能力漲了遠不止 30%。人是為更好的結果買單,所以漲價完全沒毛病。實測體感GLM-5 是第一個國內敢去對標 Claude Opus 的模型我個人測試,目前的水平肯定是達不到 Opus 4.6 水平的但我發現 GLM-5的思維方式和 Opus 4.6 非常像,思考深度非常深,有時候我看著這兩個模型的思考國產,都會非常驚嘆太聰明太全面了。但遺憾的是 GLM-5 還不具備 Opus 4.6 的獨立思考能力,會和 ChatGPT 一樣順著我的意思說。這是我用 GLM-5 寫的一個體感小遊戲,叫《抓馬》能寫出直接可玩的遊戲,還是非常強悍的。我和老婆玩了好幾盤,胳膊都有點累,所以錄視訊的時候已經沒有表情了。。 (AGENT橘)
Google 170 億收編 Windsurf,矽谷 「AI 挖人」白熱化,99% 的錢流向 1% 的人
在 AI 霸權之戰上,錢成了最不值錢的東西。OpenAI 的 Vibe Coding 夢破滅了。當地時間 7 月 11 日,Google DeepMind 被爆成功「收編」AI 初創公司 Windsurf 的核心團隊,就在前不久,OpenAI 還在和 Windsurf 談判 30 億美元收購,極客公園還在播客中大聊特聊,沒想到雙方的合作並未達成,反而讓Google補充了 AI 血液。根據報導,Google將付出 24 億美元(約人民幣 170 億元)的許可費和補償金,換來 Windsurf 團隊聯創 Douglas Chen 和部分高級研究院加入Google,幫助後者在 AI 程式設計上的項目。同時,Windsurf 將保持獨立營運,並仍可將技術授權給其他公司。熟悉的配方,熟悉的味道。就在一個月之前,Meta 做了類似的事——Meta 斥巨資收購了 Scale AI 近一半股份,並順勢把其年輕的 CEO 拉來做自己的首席 AI 官。無論是 Meta、Google、蘋果,還是馬斯克的 xAI,如今都在搶人,要麼整體收編明星初創團隊,要麼直接從 OpenAI、Anthropic 那裡「撬牆角」。各大巨頭用上千萬美元、上億美元的薪酬包誘惑,短時間內「爆破式」挖角對手的團隊,CEO 們親自打電話、組局,或者投資收購公司,只為拿下幾個創始人和技術骨幹,被挖角的對手則被迫用更高的留任獎金來「止血」留人。可以說,矽谷的「AI 人才爭奪戰」已經打到癲狂,99% 的錢最後流向了 1% 的頂尖 AI 人才。01 Meta 瘋狂撒幣,挖空友商在所有巨頭中,Meta 和祖克柏的挖角風格可能是最高調、激進的。今年 6 月,Meta 重組 AI 團隊,官宣成立「超級人工智慧實驗室」,並斥資 143 億美元買下資料標註初創公司 Scale AI 49% 的股份,直接把這家公司年輕的 CEO Alexandr Wang 任命為 Meta 的首席 AI 官,堪稱「買公司送高管」。Alexandr Wang 與祖克柏|圖片來源:網路除了通過投資公司來「買人」,Meta 對單個人才的報價同樣毫不手軟,尤其瞄準了 OpenAI 和Google的頂級研究員,還有蘋果和 Anthropic。本來,那些人動輒年薪數百萬、數千萬美元,還有股票期權,已經算業內頂流。Meta 為了挖走 OpenAI 的核心成員,不惜開出「4年 3億美元」等級的「大包」,第一年就能行權一大筆股票,兌現 1 億美元。雖然 Meta 聲稱這些極端報價僅限於「少數領導職位」,但在科技圈也算聞所未聞。與之相對應的,擁有頂級 AI 模型的 OpenAI 成了最大的被挖角目標,可以說人才流失嚴重,幾乎變成「AI 人才超市」,由各大巨頭掃貨,Meta 至少重金挖走了 7 名 OpenAI 的頂尖研究人員和模型開發人員。OpenAI 的一位高管形容,被 Meta 挖人就像「有人闖入我們家偷了東西」。Sam Altman 當然也感覺到情況不妙,但聲稱 OpenAI「最好的」員工並沒有被挖走。「Meta 開始給我們團隊裡的很多人開出巨額合同,」Sam Altman 今年 6 月在他兄弟的播客節目裡說,「比如每年 1 億美元的簽約獎金,比這還多的薪水」「但至少到目前為止,在我們最好的員工裡,沒有任何人決定接受他的條件。」Meta 據稱曾試圖挖走 OpenAI 的其中一名首席研究員,以及Google的 AI 架構師,然而,這兩次嘗試都未能成功。Sam Altman 還諷刺稱,Meta 執迷於為員工提供高薪,而不是實現 AGI 的使命,這可能無法創造「良好的文化」。Sam Altman 在播客節目中談及 Meta 挖角事件|圖片來源:網路即便如此,除了用所謂的「文化」「願景」留人,OpenAI 還是得在挖角大戰中付出代價,需要調整薪酬,給一些員工開出 100 萬至 200 萬美元的留任獎金,並附送更多股權,作為忠誠獎勵,說服關鍵研究人員在收到外部報價後留下來。據稱,過去兩年發生的董事會危機、組織動盪對 OpenAI 員工的歸屬感也有一定影響,讓一些對手和獵頭覺得「從 OpenAI 挖人更容易」。不過,OpenAI 也不是被動挨打,一直在挖人,或者反挖,不僅從 Meta 挖回一名研究員,還從馬斯克的 xAI 和特斯拉挖走了高級 VP 和多名核心工程師,其中部分人參與過馬斯克旗下超級電腦 Colossus 的建構。馬斯克和 Sam Altman 早就因路線分歧撕破臉,目前甚至還在互相起訴。在這樣的薪酬環境下,連一向高冷的蘋果也不得不改變作風。蘋果原本因為保密文化不鼓勵研究員發表論文,導致很難吸引 AI 頂尖學者。與之相比,Google、Meta 和微軟等公司長期以來都允許研究人員發表論文和開源一些工具,這可以增加他們的影響力。到了 2025 年,蘋果似乎開始放鬆一些限制,大舉投資內部大模型項目。即便如此,蘋果負責基礎模型研究的主管仍被 Meta 以超過 1 億美元的「大包」挖走,這筆薪酬傳聞甚至超過了除 CEO Tim Cook 之外的所有蘋果高管,蘋果並未嘗試反挖或匹配 Meta 的報價。為了搶 AI 人才,一些公司也在調整措施,縮短行權期限,例如,Google將部分 AI 招聘的行權期限從 4 年縮短為 3 年,以提高薪酬吸引力。數千萬美元的簽約獎金也並不罕見。另外值得注意的是,巨頭們開出的並非單純的高薪,還包括股票和一次性簽約獎金。一些 offer 據稱帶有「爆炸期限」——24 小時內簽字,否則作廢。當下,整個矽谷 AI 圈裡,一些履歷就像轉會市場:在Google幹過、去 OpenAI 升級、再被 Meta 挖走,以後說不定幹脆自己開個新公司,靠之前的履歷拿上億融資。當然,也有的人選擇反覆橫跳,例如,一名被 xAI 挖走的工程師在不到一年的時間裡就回到了 OpenAI。也有的選擇拒絕 Meta 的高薪包裹,單純因為不想「卷」。由於 Meta 將簽約費打到了「職業球星」等級,一張將一名華人 AI 研究員與足球巨星 C 羅並排的圖片,附上他們的簽約身價對比,甚至成為科技圈流傳的熱梗。網友將華人 AI 研究員與 C 羅對比|圖片來源:X02 華人面孔成「香餑餑」在這場巨頭挖角大戰裡,如果你留意他們的名字,或者姓氏,可以發現不少華人。比如,前面圖中與 C 羅並排的余嘉輝(Jiahui Yu)就是華人,中科大少年班出身,曾在Google DeepMind 工作,領導過 Gemini 多模態項目,後加入 OpenAI 參與 GPT-4o、GPT-4.1、o3、o4-mini 等模型的開發,然後才被 Meta 重金挖走。蘋果被 Meta 挖走的也是一名華人,叫彭若明(Ruoming Pang),Meta 為了挖他,據稱開出了超過 2 億美元的總包。彭若明在蘋果工作了 4 年,負責蘋果人工智慧/機器學習的基礎模型團隊,該團隊主要研發支撐 Apple Intelligence 的基礎模型。在蘋果工作之前,彭若明還曾在Google工作長達 15 年,期間參與語音識別研究和產品開發,聯合開發了 Babelfish/Lingvo 深度學習框架和 Tacotron 2 語音合成系統,是Google全球授權系統 Zanzibar 的聯合創始人和技術負責人。彭若明(Ruoming Pang)|圖片來源:其 X 帳戶除了彭若明,Meta 的華人挖角名單裡,還有好幾位前 OpenAI、Google華人研究員,他們之前在 OpenAI、Google時參與的,是 GPT-4、Gemini、o-series 等最前沿的大模型版本開發。比如,常慧文(Huiwen Chang)是清華大學姚班的畢業生,在普林斯頓大學獲得博士學位,在Google擔任研究科學家四年多,發明了 MaskGIT 和 Muse 架構,於 2023 年加入 OpenAI,參與開發了 GPT-4o 的圖像生成系統,在多模態 AI 模型方面有貢獻。常慧文(Huiwen Chang)|圖片來源:Linkedin又比如,任泓宇(Hongyu Ren)本科畢業於北京大學,博士畢業於史丹佛大學,曾在微軟、輝達、Google和蘋果實習,加入 OpenAI 後,負責後訓練團隊,專注語言模型訓練最佳化,是 GPT-4o mini、o1-mini 等模型的開發者之一。任泓宇(Hongyu Ren)|圖片來源:其個人網站還有 Ji Lin,本科畢業於清華大學,博士畢業於麻省理工學院(MIT),於 2023 年加入 OpenAI 擔任技術團隊成員,參與開發過 GPT-4o、GPT-4.1、GPT-4.5、圖像生成系統(4o-imagegen)以及 Operator reasoning stack。被 Meta 從 OpenAI 挖角的 Ji Lin|圖片來源:其個人網站2025 年 7 月,Google宣佈將聘請 AI Coding 初創公司 Windsurf 首席執行官、聯合創始人以及部分研發員工,將他們納入Google DeepMind 團隊,阻止了 OpenAI 對 Windsurf 的收購計畫。其中,被Google打包招進來的 Windsurf 聯合創始人 Douglas Chen 也是華裔面孔,畢業於麻省理工學院(MIT),曾在 Meta 和 Facebook 擔任機器學習工程師。Windsurf 聯合創始人 Douglas Chen|圖片來源:Linkedin蘋果同樣在 AI 方面倚重部分華人。彭若明出走後,蘋果很快提拔了另一位華人工程師陳志峰接手,繼續負責 Apple Intelligence 背後的大語言模型研發與部署。華人面孔的密度之高不是偶然。據一些智庫對全球頂級 AI 會議論文作者的分析,在美國頂尖 AI 研究人員中,超三成擁有中國背景,比例甚至略高於美國本土出身的研究人員。馬斯克對華人工程師的傾向也很明顯,其團隊合照總有很多華人面孔,甚至 xAI 創立時,12 位創始研究員裡有 5 位是華人——Tony Wu、Jimmy Ba、Greg Yang、Zihang Dai、Guodong Zhang,不少人曾在Google或 DeepMind、OpenAI 實習或工作過。有時人們打趣「大半個 xAI 是中國人」並不為過。在 Grok 4 的直播發佈會上,坐在馬斯克旁邊頻繁露臉的就是吳懷宇(Tony Wu),現在身份是 xAI 的聯合創始人,曾在Google DeepMind、OpenAI 實習,在史丹佛做過博士後,同時在Google工作過一段時間。馬斯克和 Tony Wu(右)|圖片來源:xAI今年甚至還有一個流行說法,時不時就會被科技圈調侃轉發:「AI 大戰就是在美國的中國人 VS 在中國的中國人」。03邊裁邊挖 99% 的錢,流向 1% 的人?不過,在風光無限的天價合同背後,也藏著另一個群體的焦慮,因為這場挖角大戰,可能只針對金字塔尖的 1%,剩下的 99% 呢?雖說就連「普通」的 AI 資深工程師,有的也能拿到 100 萬到 150 萬美元年包,比傳統軟體崗位高出兩三倍。Levels.fyi 平台資料顯示,Meta 的 E7 等級 AI 工程師平均年包可以逼近 154 萬美元,這個價碼那怕在矽谷也算是上游。但對很多矽谷程式設計師來說,AI 的崛起和巨頭的搶人大戰帶來的不僅是羨慕,還有切實的危機感:一邊是 Meta、OpenAI、Google 等巨頭正以數千萬、乃至數億美元級簽字費、年薪爭搶頂尖 AI 科學家,AI 大牛拿著天價合同、享受九位數待遇;另一邊則是普通工程師擔心被裁、價值被邊緣化。「一邊是看著各路 LLM 大牛拿大包,一邊是普通牛馬整天擔心被裁。」有人在矽谷碼農聚集的論壇發帖如此稱,類似這樣主題的帖子不在少數,遍佈各種矽谷科技圈社交網路平台。而巨頭們的確在「邊裁邊挖」。Meta 這幾年起碼裁了幾萬人,尤其是非 AI 項目的員工,實行「末位淘汰制」,今年被矽谷華人碼農圈戲稱為「魷魚廠」;Google同樣持續最佳化,甚至啟動「自願離職補償計畫」,將資源投向 AI 項目;亞馬遜去年裁員超過 2 萬人,今年初再裁減數十個企業崗位,3 月開始重組 AWS 相關部門。2025 年 7 月,微軟宣佈再次裁員數千人,主要集中在工程師崗位,其中矽谷本地就有上百個軟體工程職位被砍,部分理由是 AI 提高了生產效率。微軟 CEO 納德拉|圖片來源:微軟微軟 CEO 納德拉在 2025 年公開表示,微軟內部已有 20% 至 30% 的程式碼由 AI 生成。類似情況出現在其他企業,比如,Salesforce 高管也稱,公司內部約 20% 的程式碼由 AI 生成,AI 讓工程團隊生產力提升超過 30%,因此減少了程式設計師招聘。一些矽谷軟體工程師認為,隨著 AI Coding 效率提高,普通軟體工程師的生存反而「越來越難」。有人還認為,目前 99% 的錢流向了 1% 的頂尖 AI 人才,AI 本身崗位不多,程式設計師開發的 AI 取代了很多崗位,最後可能會革了自己的命。矽谷的 AI 搶人大戰,不只是巨頭之間的零和遊戲。無論是 AI 人才、普通軟體工程師、還是矽谷巨頭,現在都不得不接受這種高流動性和短期主義,以及一個現實:大量的錢、更多的錢,都只流向 AI。 (極客公園)