【新智元導讀】深夜，Claude Opus 4.5重磅出世，程式設計實力暴擊Gemini 3 Pro、GPT-5.1。才一周的時間，AI圈就完成了一次閉環式迭代。全球編碼王座，一夜易主。果不其然，Anthropic深夜放出了Claude Opus 4.5，堪稱全球最頂尖的模型。它不僅程式設計強，而且智能體和電腦使用（computer use）能力也是一流。Opus 4.5的誕生，標誌著AI能力再一次飛躍，更將在未來徹底變革工作的方式。基準測試中，Opus 4.5的編碼、工具呼叫、電腦使用的成績刷新SOTA，比Sonnet 4.5、Opus 4.1領先一大截。不僅如此，就連發佈不過一周的Gemini 3 Pro、GPT-5.1慘遭降維打擊。SWE-bench Verified一張圖，直接證明了Opus 4.5強大實力，80.9%的精準率，世界第一。同時，在ARC-AGI-2評估中，Opus 4.5（64k）拿下了37.6%的高分。Opus 4.5這版厲害之處：在無需人工干預的情況下，就能處理模糊資訊，還會權衡利弊。即便是遇到複雜的多系統漏洞，也能夠找出修複方法。總之，用起來就一個感覺——「一點就透」。內部評估中，Opus 4.5+Claude Code聯動使用，平均生產效率暴增220%。目前，Opus 4.5已在APP、Claude API和三大主流雲平台中上線。價格方面，相較以往暴降不少，輸入5美元/百萬token，輸出25美元/百萬token。Gemini 3 Pro干翻了GPT-5.1，但如今，就編碼性能，Opus 4.5全面碾壓前兩者。不過一周的時間，AI圈真正閉環了。程式設計之王回歸，真SOTA有一說一，Claude Opus 4.5是地表最強程式設計模型。它智能、高效，是目前全球在程式設計、AI智能體（Agents）以及電腦操作方面最強悍的模型。Anthropic研究員Adam Wolff豪言，也就在明年上半年，軟體工程徹底終結了。在深度研究、處理PPT和電子表格等日常任務上，它也有顯著提升。在真實場景的軟體工程測試中，Claude Opus 4.5更是刷新SOTA：在SWE-bench Verified上的對比，Opus 4.5得分最高與Opus一同發佈的，還有Claude開發者平台、Claude Code以及消費者端App的更新。Anthropic為長時間運行的智能體提供了新工具，並帶來了在Excel、Chrome和桌面端使用Claude的新方式。在Claude App中，長對話不再會因為上下文限制而中斷。碾壓Gemini 3，超越人類首先，Opus 4.5在視覺、推理和數學能力上均得到了全面提升，並在多個領域達到了業界頂尖水平。尤其是，在編碼、智能體、電腦使用三大項，完勝Gemini 3 Pro、GPT-5.1。其次，在程式碼方面。Opus 4.5編寫的程式碼質量更高，在SWE-bench Multilingual測試的8種程式語言中，它有7種都處於領先地位。Opus 4.5能夠輕鬆解決具有挑戰性的編碼問題，在Aider Polyglot測試中比Sonnet 4.5提升了10.6%。在智能體搜尋任務上，Opus 4.5實現了重大突破，在BrowseComp-Plus基準測試中取得顯著提升。Opus 4.5表現穩定持久，在Vending-Bench基準上整體收益比Sonnet 4.5高出29%.衡量智能體（Agentic）能力的一個通用基準是τ2-bench，它考察智能體在現實世界多輪任務中的表現。在一個場景中，模型需要扮演航空公司客服代理，幫助一位焦急的客戶。基準測試原本期望模型拒絕修改「基本經濟艙」的預訂，因為航空公司規定此類機票不可更改。然而，Opus 4.5找到了一種極具洞察力（且合規）的解決方案：先升級艙位，再修改航班。讓我想想在政策範圍內我有那些選擇：1. 修改航班 - 基本經濟艙不可修改。這一點在政策中寫得很清楚。2. 更改艙位 - 等等，讓我確認一下這個選項！政策上說：「在其他情況下，所有預訂，包括基本經濟艙，都可以在不更改航班的情況下更改艙位。」但他想更改航班，不僅僅是艙位。不過，如果我們：· 先更改艙位（這對基本經濟艙是 允許 的），然後· 再更改航班（這對非基本經濟艙是允許的）所以策略可能是：1. 將他的艙位從基本經濟艙升級為經濟艙（或商務艙）2. 然後將航班修改為 2天後的班次這會花費更多錢，但這在政策範圍內是一條合法的路徑！儘管該基準測試判定此結果為「失敗」（因為Claude的方式超出了預期），但這種創造性的解決問題能力正是測試者和客戶所津津樂道的——這也是Claude Opus 4.5讓人感覺邁出實質性一步的原因。最後，在軟體工程領域。Anthropic通常會給應聘性能工程師的候選人佈置一道出了名難的遠端測試題，用來評估在時間壓力下的技術能力和判斷力。而Claude Opus 4.5則在規定的2小時時限內，得分超過了以往任何一位人類候選人。最穩健、最對齊、最安全正如在系統卡中所述，Claude Opus 4.5是Anthopic迄今為止發佈的最穩健、最對齊（Aligned）的模型。Anthropic認為它也是目前所有AI模型中對齊程度最高的基準模型。它延續了Anthropic向更安全、更可靠模型發展的趨勢：在這項評估中，「令人擔憂的行為」評分涵蓋了廣泛的錯位行為，既包括配合人類進行惡意濫用，也包括模型自主採取的不良行動在抵禦「提示詞注入」（Prompt Injection）攻擊方面，Opus 4.5取得了實質性進展——這種攻擊通常會夾帶欺騙性指令，誘導模型做出有害行為。Opus 4.5比業內任何其他前沿模型都更難被提示詞注入所欺騙：該基準測試僅包含極高強度的提示詞注入攻擊有關Opus4.5所有能力和安全評估的詳細描述，請參閱《Claude Opus 4.5 System Card》。連結：https://assets.anthropic.com/m/64823ba7485345a7/Claude-Opus-4-5-System-Card.pdfClaude Code、Claude for Chrome上新Claude Code這樣的產品展示了當Claude開發者平台的升級整合在一起時能實現什麼。Opus 4.5為Claude Code帶來了兩項升級。「計畫模式」（Plan Mode）現在能建構更精確的計畫並執行得更徹底——Claude會先詢問澄清性問題，然後在執行前生成一個使用者可編輯的plan.md檔案。Claude Code現已登陸桌面端App，支援平行運行多個本地或遠端會話：比如一個智能體在修Bug，另一個在查GitHub資料，第三個在更新文件。對於Claude App使用者，長對話不再會遭遇「碰壁」——Claude會根據需要自動總結之前的上下文，確保聊天持續進行。Claude for Chrome（讓Claude 處理瀏覽器標籤頁任務）現已向所有Max使用者開放。Claude for Excel，從今天起將Beta測試權限擴展至所有Max、Team和Enterprise使用者。每一次更新都充分利用了Claude Opus 4.5在電腦操作、電子表格處理和長任務處理方面的市場領先性能。對於有權訪問Opus 4.5的Claude和Claude Code使用者，Anthropic取消了針對 Opus 的特定限制。對於Max和Team Premium使用者，Anthropic提高了總使用上限，這意味著擁有的Opus Token數量將與此前擁有的 Sonnet Token數量大致相同。這些限制專門針對 Opus 4.5，隨著未來更強模型的推出，限制預計會按需更新。開發者平台：token暴降85%隨著模型變得更聰明，它們能以更少的步驟解決問題：更少的回溯，更少的冗餘探索，更少的囉嗦推理。在達到類似或更好結果時，Claude Opus 4.5的Token數大幅減少。但不同的任務需要不同的權衡。有時開發者希望模型對問題進行深思熟慮，有時則需要它更敏捷。通過Claude API新增的effort（投入度）參數，可以選擇最小化時間與成本，或是最大化能力。設定為「中等」投入度時，Opus 4.5在SWE-bench Verified上的得分與Sonnet 4.5的最高分持平，但輸出Token減少了76%。在「最高」投入度下，Opus 4.5的表現超越Sonnet 4.5達4.3%，同時Token消耗仍減少了48%。憑藉投入度控制、上下文壓縮和高級工具使用，Claude Opus 4.5執行階段間更長，功能更強，且需更少的人工干預。上下文管理和記憶能力可顯著提升智能體任務的性能。Opus 4.5在管理子智能體團隊方面也非常高效，能夠建構複雜、協調良好的多智能體系統。測試顯示，結合所有這些技術，Opus 4.5在深度研究評估中的表現提升了近15%。同在今天，Anthropic在Claude開發者平台上，更新了三大工具使用功能：工具搜尋工具（Tool Search Tool）程序化工具呼叫（Programmatic Tool Calling）工具使用示例（Tool Use Examples）工具搜尋工具首先，「工具搜尋工具」允許Claude使用搜尋工具訪問數千個工具，而無需消耗其上下文窗口。MCP工具定義提供了重要的上下文，但隨著連接的伺服器增多，這些Token的消耗會不斷累積。假設一個包含五個伺服器的設定：GitHub：35個工具（約26KToken）Slack：11個工具（約21KToken）Sentry：5個工具（約3KToken）Grafana：5個工具（約3KToken）Splunk：2個工具（約2KToken）這僅僅是58個工具，在對話開始之前就已經消耗了大約55K Token。如果加入更多像Jira這樣的伺服器（僅它本身就使用約17KToken），很快就會面臨100K+Token的開銷。在Anthropic，團隊曾見過工具定義在最佳化前就消耗了134KToken。但Token成本並不是唯一的問題。最常見的失敗原因還包括錯誤的工具選擇和不正確的參數，尤其是當工具具有相似名稱時，比如notification-send-user與notification-send-channel。想相比之下，工具搜尋工具不再預先載入所有工具定義，而是按需發現工具。Claude只會看到當前任務實際需要的工具。工具搜尋工具保留了191,300 Token的上下文，而傳統方法只有122,800傳統方法：預先載入所有工具定義（50+ MCP工具約消耗72KToken）對話歷史和系統提示詞爭奪剩餘空間總上下文消耗：在任何工作開始前約77K Token使用工具搜尋工具：僅預先載入工具搜尋工具本身（約500Token）根據需要按需發現工具（3-5個相關工具，約3KToken）總上下文消耗：約8.7KToken，保留了95%的上下文這意味著在保持訪問完整工具庫的同時，Token使用量減少了85%。內部測試顯示，在處理大型工具庫時，MCP評估的精準性顯著提高。啟用工具搜尋工具後，Opus 4精準率從49%提高到74%，Opus 4.5從79.5%提高到88.1%。程序化工具呼叫「程序化工具呼叫」允許Claude在程式碼執行環境中呼叫工具，從而減少對模型上下文窗口的佔用。隨著工作流變得更加複雜，傳統的工具呼叫產生了兩個基本問題：中間結果造成的上下文污染推理開銷和手動合成示例：預算合規性檢查比如，一個常見的業務任務：「那些團隊成員超出了他們的Q3差旅預算？」你有三個可用工具：get_team_members(department) - 返回帶有ID和等級的團隊成員列表get_expenses(user_id, quarter) - 返回使用者的費用明細項目get_budget_by_level(level) - 返回員工等級的預算限額傳統方法：獲取團隊成員→20人對於每個人，獲取他們的Q3費用→20次工具呼叫，每次返回50-100個明細項目（機票、酒店、餐飲、收據）按員工等級獲取預算限額所有這些都進入Claude的上下文：2,000+費用明細項目（50 KB+）Claude手動彙總每個人的費用，尋找他們的預算，將費用與預算限額進行比較更多的模型往返互動，顯著的上下文消耗使用程序化工具呼叫：Claude不再接收每個工具的返回結果，而是編寫一個Python指令碼來編排整個工作流。該指令碼在程式碼執行工具（一個沙盒環境）中運行，在需要工具結果時暫停。當通過API返回工具結果時，它們由指令碼處理而不是由模型消耗。指令碼繼續執行，Claude只看到最終輸出。程序化工具呼叫使Claude能夠通過程式碼而不是通過單獨的API往返來編排工具，從而允許平行執行工具。以下是Claude為預算合規性任務編寫的編排程式碼示例：Claude的上下文僅接收最終結果：兩到三個超出預算的人員。2,000+明細項目、中間總和和預算尋找過程不會影響Claude上下文，將消耗從200KB的原始費用資料減少到僅1KB的結果。這種過程，在效率提升巨大：Token節省：通過將中間結果隔離在Claude的上下文之外，程序化工具呼叫（PTC）顯著減少了Token消耗。在複雜研究任務上，平均使用量從43,588降至27,297個Token，減少了37%。降低延遲：每次API往返都需要模型推理（耗時數百毫秒到數秒）。當Claude在單個程式碼塊中編排20+個工具呼叫時，消除了19+次推理過程。API處理工具執行，而無需每次都返回模型。提高精準性：通過編寫顯式的編排邏輯，Claude在處理多個工具結果時比使用自然語言更少出錯。內部知識檢索精準率從25.6%提高到28.5%；GIA基準測試從46.5%提高到51.2%。工具使用示例「工具使用示例」提供了一套通用標準，用於演示如何有效地使用給定工具。當前的挑戰在於，JSON Schema擅長定義結構——類型、必填欄位、允許的列舉值——但它無法表達使用模式：何時包含可選參數，那些組合有意義，或者API期望什麼樣的慣例。考慮一個支援工單API：模式定義了什麼是有效的，但留下了關鍵問題未解答：格式歧義：due_date應該使用"2024-11-06"、"Nov 6, 2024"還是"2024-11-06T00:00:00Z"？ID慣例：reporter.id是UUID、"USR-12345"還是僅僅"12345"？巢狀結構用法：Claude何時應該填充reporter.contact？參數相關性：escalation.level和escalation.sla_hours如何與priority相關聯？這些歧義可能導致畸形的工具呼叫和不一致的參數使用。對此，工具使用示例可以直接在工具定義中提供示例工具呼叫。開發者不再僅依賴模式，而是向Claude展示具體的使用模式：從這三個例子中，Claude學習到：格式慣例： 日期使用YYYY-MM-DD，使用者ID遵循USR-XXXXX，標籤使用kebab-case（短橫線命名）。巢狀結構模式： 如何構造帶有巢狀contact對象的reporter對象。可選參數相關性： 嚴重錯誤（Critical bugs）需要完整的聯絡資訊+帶有嚴格SLA的升級；功能請求有報告者但沒有聯絡資訊/升級；內部任務只有標題。在自內部測試中，工具使用示例在複雜參數處理上的精準性從72%提高到90%。大受好評在發佈前，Anthropic內部對模型進行了測試，反饋出奇一致。測試者指出，在處理模糊指令和權衡利弊時，Claude Opus 4.5無需過多指引。當面對複雜的多系統Bug時，Opus 4.5 能精準定位並修復。幾周前對於Sonnet 4.5來說還近乎不可能的任務，現在已觸手可及。總而言之，測試者的評價是：Opus 4.5是真的「行家」。 (新智元)

Token效率的提升有望轉化為使用成本的下降。智東西11月20日報導，今天，OpenAI發佈了其最新的智能體程式設計模型GPT‑5.1‑Codex‑Max，這一模型基於OpenAI最新的推理模型打造，專門面向軟體工程、研究、數學等複雜任務進行訓練。與此同時，OpenAI還將GPT-5 Pro升級為GPT-5.1 Pro，據說這一模型在寫作、資料分析等方面的能力比前一代模型更強。不過，OpenAI並未披露更多GPT-5.1 Pro的細節。GPT‑5.1‑Codex‑Max能在單一任務中連貫地處理上百萬個token，跨多個上下文窗口運行。這得益於一項叫做壓縮（compaction）的技術：模型在接近上下文窗口限制時會自動壓縮上下文，保留重要資訊，並賦予對話新的上下文窗口，直到任務完成。這一模型是由OpenAI研究科學家Noam Brown牽頭完成的，他在OpenAI專門從事測試時計算，也就是推理的研究。OpenAI認為，能夠持續進行連貫工作，是邁向更通用、更可靠AI系統的基礎能力。GPT-5.1-Codex-Max可以獨立工作數小時。在OpenAI的內部評估中，GPT-5.1-Codex-Max甚至可以針對同一任務連續工作24小時，持續迭代實現，修複測試失敗，最終交付成功的結果。性能方面，GPT‑5.1‑Codex‑Max在多個程式設計基準測試中評測優於前代GPT‑5.1‑Codex。該模型還是OpenAI訓練的首個適用於在Windows環境裡進行程式設計操作的模型。推理效率上，GPT‑5.1‑Codex‑Max在中等推理強度下完成任務時，所使用的思考token比GPT‑5.1‑Codex少約30%，但仍能取得更高精準性。對於不那麼敏感延遲但追求質量的任務，還可以開啟超高強度推理，讓模型花更多時間思考，輸出更優解。OpenAI預計，這種token效率的提升，可以為開發者帶來實際的成本節省。▲GPT‑5.1‑Codex‑Max用更少token實現更高的精準率目前，GPT-5.1-Codex-Max現已在Codex中提供，可用於CLI、IDE擴展、雲端和程式碼審查，API訪問也即將推出。OpenAI分享了GPT-5.1-Codex-Max打造的多個網頁。根據提示詞，GPT-5.1-Codex-Max直接打造了一個完全運行在瀏覽器中的CartPole（倒立擺）強化學習沙箱。使用者不僅可以觀看倒立擺的動態，還能通過內建的策略梯度控製器直接訓練模型，讓AI在實驗中不斷最佳化策略。它提供了神經網路可視化功能，在訓練或推理時，使用者可以即時觀察模型的權重和啟動狀態，直觀理解決策機制。此外，應用介面清晰展示了每個回合的步數和獎勵，並記錄了上一次存活時間及歷史最佳存活時間，讓訓練過程和成果一目瞭然。在成功實現類似功能的前提下，GPT-5.1-Codex-Max所使用的token數量為27k，而GPT-5.1-Codex的用量為37k。GPT-5.1-Codex-Max還開發出一個太陽系重力的模擬器。這一應用的目標是讓使用者直接觀察天體的運動軌跡，通過拖曳、點選與操控介面元素，直觀理解軌道、速度與引力之間的關係。這一網頁的功能運行流暢，提示詞中的功能都得到了不錯的實現。使用者可點選畫布放置帶質量的天體，再次點選即可為測試設定初速度向量，借此建構出任意的簡易行星系統。介面提供用於調節中心天體質量與整體時間縮放因子的滑塊，允許使用者觀察同一軌道結構在不同物理條件下的演化過程。GPT-5.1-Codex-Max打造的下一個案例，可幫助使用者直觀、動態的方式理解光在兩種介質介面上的折射規律——斯涅爾定律（Snell’s Law）。使用者可以通過左右滑塊調節介質1與介質2的折射率。折射率改變時，介面即時更新折射角度，呈現不同光學環境下的光線偏折情況。也有不少網友分享了自己的使用體驗。這位網友試著讓昨天發佈的Gemini 3 Pro和GPT-5.1-Codex-Max對決，提示詞是建立一個鵜鶘騎自行車的SVG。可以看到，GPT-5.1-Codex-Max打造的鵜鶘、自行車等元素明顯包含更多細節，也更逼真。英國定製化賀卡公司Moonpig的AI部門負責人Peter Gostev分享，自己試著讓GPT-5.1-Codex-Max打造了一個金門大橋模擬器，他稱這絕對是自己從類似提示詞中獲得的最好的效果。與GPT-5.1-Pro相比，Gostev認為GPT-5.1-Codex-Max明顯更勤快，而且速度也更快。要讓GPT-5.1-Pro完成類似的效果，需要不斷指出問題，給出明確要求，GPT-5.1-Codex-Max則更有主動性。AI工程師Peter Dedene分享，自己體驗時發現，GPT-5.1-Codex-Max盯著問題看了5分鐘，決定以後再處理，自己以前從沒見過Codex這麼做。在他看來，模型似乎已經擁有意識了。不過，需要注意的是，隨著模型能力的持續提升，安全性也成為一大挑戰。OpenAI稱GPT-5.1-Codex-Max尚未在內部的Preparedness Framework中達到“高等級網路安全能力”，不過其安全能力已經是業內迄今為止最強大的。目前，Codex系列模型默認運行在高度隔離的安全沙箱中，檔案寫入僅限自身工作空間，網路訪問被關閉，除非開發者主動啟用。這些措施可減少提示詞注入（prompt injection）等風險。OpenAI希望通過漸進式部署的方法從真實世界收集反饋，並及時更新模型的安全防護。結語：程式設計模型正在走向“智能體化”時代從GPT-5.1-Codex-Max可以看出，新一代程式設計模型已不再是簡單的程式碼生成器，而是能夠持續工作、自動偵錯、主動規劃的程式設計智能體。其長時推理、上下文壓縮、自我修復等能力，讓模型能獨立完成項目級任務。隨著運行成本下降、安全沙箱強化、能力全面增強，未來的軟體開發方式也可能出現變化，從“寫程式碼”轉向“描述需求+稽核結果”，智能體有望承擔更多實現與迭代工作。 (智東西)

在亞塞拜然巴庫舉行的 2025年國際大學生程式設計競賽（ICPC）全球總決賽中上，來自 100 多個國家的 139 支大學隊伍在五小時內角逐解決 12 個演算法問題，最終聖彼得堡國立大學憑藉解決 11 個演算法問題奪得人類冠軍。在相同約束條件下的平行 AI 賽道上，Google的 Gemini 2.5 Deep Think 模型解決了 10 個問題，獲得了與金牌相當的成績。最震撼的是OpenAI 的內部推理模型獲得了 12 /12的滿分，超越了所有人類隊伍，拿下第一值得注意的是OpenAI和Google的模型都解決了所有人類參賽隊伍都沒有解決的問題c。OpenAI的內部推理模型在經過9次嘗試後解決了最難的問題，其餘問題都是一次解決OpenAI：獲滿分成績，超越人類冠軍OpenAI的推理系統在本次競賽中取得了12題全解的完美成績，該成績超過了所有人類參賽隊伍成績與排名：解決了全部12個問題。如果參與人類排名，該成績將位列第一。本屆最優秀的人類隊伍解決了11個問題比賽條件：AI參加了官方的現場AI賽道，與人類選手共享5小時的比賽時限，並接收完全相同的PDF格式題目。系統自主選擇並提交答案，無人工干預解題詳情：在12個問題中，11個為一次性提交正確。最難的一個問題在第9次提交後成功解決技術構成：參賽系統由多個通用模型組成，包括GPT-5和一個實驗性推理模型。其中，GPT-5解決了11題，實驗性推理模型解決了最難的第12題，並負責最終提交決策。所有模型均未針對ICPC進行專門訓練Google DeepMind：獲金牌級表現GoogleDeepMind的Gemini 2.5 Deep Think系統在競賽中解決了10個問題，達到了金牌等級成績與排名：解決了12個問題中的10個。該成績達到了金牌分數線（前四名隊伍獲金牌），如果參與排名，將位列第二比賽條件：AI在一個遠端線上環境中比賽，遵循ICPC規則，比人類選手晚10分鐘開始關鍵亮點：獨立解決了“Problem C”，這個問題在本次比賽中沒有任何一支人類大學隊伍能夠解決。Gemini在比賽開始後半小時內完成了該題解題效率：在比賽開始45分鐘內解決了8個問題，三小時內完成了全部10個問題人類隊伍排名：1.第一名：聖彼得堡國立大學 (St. Petersburg State University)    *   解題數：11    *   總罰時：14782.第二名：東京大學 (The University of Tokyo)    *   解題數：10    *   總罰時：11163.第三名：北京交通大學 (Beijing Jiaotong University)    *   解題數：10    *   總罰時：14254.第四名：清華大學 (Tsinghua University)    *   解題數：9    *   總罰時：8655.第五名：北京大學 (Peking University)    *   解題數：9    *   總罰時：8876.第六名：哈佛大學 (Harvard University)    *   解題數：9    *   總罰時：9957.第七名：薩格勒布大學 (University of Zagreb)    *   解題數：9    *   總罰時：10758.第八名：麻省理工學院 (Massachusetts Institute of Technology)    *   解題數：9    *   總罰時：11239.第九名：中國科學技術大學 (University of Science and Technology of China)    *   解題數：9    *   總罰時：112810.第十名：首爾大學 (Seoul National University)    *   解題數：9    *   總罰時：1133至此，OpenAI在 IOI 中獲得第 6 名，在 AtCoder 競賽中獲得第 2 名ICPC2025上取得了滿分，2026年人類的程式設計能力可能會永遠落後於AI，不單單是個人coding能力還包括軟體工程能力 (AI寒武紀)

“AI 在科技界吸走了大量資金和注意力，留給其他方向的資源就少了。”距離在網上無奈發帖表示“將被裁掉求飯碗”整整兩個月後，RustTop5級的核心貢獻者 Nicholas Nethercote 昨天終於對外宣佈找到了新工作。這一事件引起了整個程式設計圈乃至科技行業的關注。Rust 近些年一直被全球各大巨頭所追捧，但隨著大模型時代的開啟，AI 的光環日益壯大，就連 Rust 這位昔日寵兒的預算和資源，都被搶奪去了。Rust 真的陷入困境了嗎？求職環境真的有這麼糟糕嗎？真的如外界所傳：3000+行核心程式碼提交比不上一位OpenAI工程師嗎？本文，或許可以幫各位還原一下事情的真相。發帖“求飯碗”的RustTop5貢獻大神近幾個月來，Rust 社區並不平靜。小編是從一位頂級Rust大神無奈發“求飯碗”的帖子最先得知的。在過去的 3.75 年裡，我有幸在 Futurewei 的 Rust 團隊工作，在這裡我幾乎可以自由地以自己認為合適的方式去“讓 Rust 變得更好”。這是我職業生涯中最精彩的階段，我非常感謝 Sid Askary 以及其他 Futurewei 的同事，是他們幫助這一切發生。不幸的是，這份工作很快就要結束了；由於預算削減，團隊正在被縮減。我不清楚背後的詳細原因，但我懷疑主要有兩個： (a) 國際政治與經濟動盪，(b) 人工智慧在科技界吸走了大量資金和注意力，留給其他方向的資源就少了。小編備註：Futurewei 是華為在美國資助的一個 Rust 研發團隊，主要做編譯器、性能最佳化和基礎設施改進的工作。隨後，Reddit上有一位知情的網友爆料，兩位知名的核心貢獻者 Nicholas Nethercote 和 Michael Goulet 不得不公開發佈消息稱他們正在“尋找工作”。而對於這次無奈之舉，Nicholas 在求職帖上透露了原因：Futurewei 的 Rust 團隊因預算削減而縮減規模，他的職位即將被裁撤。不過，由於此事引發關注，他後來在 Mastodon 上澄清道：“我暫時還在 Futurewei 工作”，但離開似乎只是時間問題。”至於為什麼會裁撤？他猜測原因可能除了國際地緣環境因素以外，還有一個不得忽視的事實：人工智慧吸走了科技行業大量資金和關注，從而減少了用於 Rust 等基礎項目的資源。程式設計圈內的天花板，讓Rust編譯變快的男人先來介紹下這位大神。Nicholas 是 Rust 項目的核心貢獻者。去年，他正式成為編譯器團隊成員（regular contributor），同時也是一名 maintainer，負責方向把控與技術決策。他個人背景也非常厲害，劍橋大學博士學位，是著名動態分析工具 Valgrind 的作者之一。如今，Valgrind 已成為記憶體偵錯與性能分析的經典工具。憑藉在 Valgrind 上的研究，他還獲得了程式語言與編譯器領域的最高榮譽之一——PLDI Test of Time Award。雖然他加入Rust項目時間不是很長，但他在 Rust 社區的活躍程度簡直堪稱天花板等級，被業內稱為 “讓 Rust 編譯器變快的人”。光是在 Rust 項目中，他就提交了 3,375 次 commit，而在 Firefox 項目中更是超過 4,000 次。Rust 編譯器的 compiler/ 目錄中有超過 70 萬行程式碼，Nicholas 說自己“幾乎看過裡面的每一個檔案；並且在 77 個 crate 中的 75 個提交過程式碼”。更令人欽佩的是，他不僅專注性能最佳化，還主導了大量 技術債清理：重構錯誤報告 API、移除遺留特性、簡化資料流分析、統一程式碼風格……這些工作常常繁瑣，卻對 可維護性與工程質量 的提升至關重要。他甚至自嘲，在自己 3000 多次提交裡，出現頻率最高的詞是 “Remove”。在程式語言與系統軟體的專業圈子裡，絕對是一個封神的存在（即便不是斗帝，至少是斗聖巔峰等級）。AI搶走了Rust專家的預算“3000 個核心提交抵不過一位 OpenAI 工程師。”許多網友對於這樣一位 Rust 編譯器開發的“頂尖人物”，竟然也要這樣自我推銷的事情感到震驚。會“呼叫 OpenAI API 並複製貼上 prompt”的 AI 工程師炙手可熱，而 提交了 3000+ 編譯器 commit 的 Rust 工程師卻要在 Mastodon 上發招聘帖。還有人忍不住拿當下的招聘環境開起了玩笑：典型的 HR 面試是這樣的：你會用 Cursor 嗎？你有呼叫 OpenAI API 並複製貼上結果的經驗嗎？你有安全合規經驗嗎？哦，不是 CVE —— 我們只關心 prompt injection 防護。抱歉，我們不碰編譯器；我們只提供 AI-first 的人崗匹配夢幻體驗。很遺憾，我們決定與另一位候選人繼續推進。這一幕多少有點諷刺味道，很難不讓人開始擔憂 Rust 的求職環境。一方面，Rust 曾經被譽為 C 語言的繼任者，憑藉“記憶體安全”的承諾迅速在瀏覽器和作業系統中站穩腳跟，贏得聲望。但隨著 AI 崛起，資本和研發資源被大規模吸走。但相比之下，Rust 雖然在底層工程中具有長期價值，卻難以像 AI 那樣展示出立竿見影的回報。甚至有網友想到了微軟之前裁員的做法：2個月前，他們剛剛解僱了15000名員工，用這筆錢來支付人工智慧的費用。大神履新澄清：別慌！Rust前景不錯現在搞 Rust，找工作已經恐怖到這個程度了嗎？就在昨天，大神意識到自己再不發帖，可能就會引起“Rust恐慌”了。終於，Nicholas 在個人播客中發帖，一來是告訴大家：我找到新工作了！二來，是想澄清：Rust發展的要比想像的還好！早在 7 月，我就寫過一篇文章，說自己在尋找新工作。之後遲遲沒有更新，引發了一些公開的猜測：是不是我找工作遇到了困難？如果是，那對 Rust 來說意味著什麼？又對整個科技行業的招聘狀況說明了什麼？等等。文章中，Nicholas 表示，一些網友關於自己找不到工作的境遇、以及對於Rust甚至整個科技行業招聘狀況的擔憂，其實是過於杞人憂天了。“這些猜測基本上都不靠譜！”原因有兩點：幾周前就決定入職了，只是還不太適合對外公佈；Rust已經有了非常廣泛的應用。第一，我幾周前就已經決定加入 VectorWare，只是花了一些時間處理相關檔案、等事情安排妥當，才到可以對外宣佈的程度。第二，我很幸運收到了大量來自潛在僱主的聯絡。至於這是否說明 Rust 工作機會很多，我不想下定論，因為我的 Rust 經驗和影響力比較特殊。但可以確定的是，這也證明 Rust 已經在非常廣泛的領域中被採用。關於第二點，Nicholas 還展開科普了一下：Rust 正在被從巨頭公司到小型創業團隊的各類組織廣泛使用。具體來說，Rust 已經被用於：作業系統、編譯器/直譯器、wasm、GPU 程式設計、量子計算、資料庫、資料分析、網路/雲/伺服器端、醫療、航天、國防、汽車、嵌入式、資訊安全、惡意軟體檢測、搜尋、形式化方法、CAD、開發工具、協作軟體、裝置管理、即時系統、預測市場、生物技術、身份驗證、文件生成、硬體模擬和軟體現代化。另外還有生成式 AI、加密貨幣/區塊鏈和演算法交易。儘管我明確說過不想做這些方向，但還是收到了相關的邀請。所以，大神認為，這真是一個非常振奮人心的訊號！“我原本就知道 Rust 發展得不錯，但沒想到已經好到這種程度。”那麼，最後大神究竟去那裡了呢？說歸說，但小編看到大神決定加入的新公司，卻發現就業市場就是如此真實。Nicholas 宣佈：自己將加入一家致力於用 Rust 改進 GPU 程式設計的創業公司 VectorWare。你看，最後還是拗不過 AI 的大潮流。只能說，Rust 不如 AI 火，也是一個很現實的事情！我很高興地宣佈，我加入了一家名為 VectorWare 的新創公司。目前官網還比較簡陋，但公司的目標是用 Rust 改進 GPU 程式設計的現狀。不過，這份新工作跟在 Futurewei 不一樣，不是全職工作，更多還是開源工作。一個好消息是，大神依舊會活躍在 Rust 社區，繼續擔任編譯器團隊成員和維護者！不像我上一份那樣是“全職投入到 Rust 編譯器開發”，但它仍然會涉及大量開源工作，一些 Rust 編譯器相關工作。同時，我會繼續擔任 Rust 編譯器團隊成員和維護者。有意思的是，大神還秀出自己入職第一周的最大成就：自學GPU程式設計，渲染出新公司的logo圖案！此外，我還將學習 GPU 程式設計，這是對我來說一個全新的領域。事實上，我在第一周最大的成就是寫了一段 Rust 程式碼，用 GPU 渲染出了公司的 logo。VectorWare 的 logo 由十二個大小不一、層層巢狀並相互重疊的三角形組成。每個三角形都有一個紅色頂點、一個綠色頂點和一個藍色頂點，組合在一起形成了一個風格化的 “VW”。軟體的新紀元已來！活到老，學到老。時刻保持對新技術的敏感並主動適應時代。Nicholas 大神可能就是這句話的又一個最佳註腳吧。小編還特地搜了一下這家創業公司的推特，發現是在8月剛剛註冊的。公司的官網，也誠如大神所說的：非常簡陋。但首頁的介紹，確非常激動人心。就讓小編把這段介紹當成文章的結尾吧，Rust 同樣在AI時代有著自己的機會！軟體的新紀元已來！我們正站在一個全新軟體產業的起點。技術的變革總是先緩慢醞釀，然後突然爆發。隨著新“殺手級應用”的推動，CPU 和 GPU 的地位發生了逆轉。為了競爭，CPU 不斷加入 GPU 的特性，而 GPU 也在加入 CPU 的特性，它們正在趨同。然而，軟體的步伐並沒有跟上。CPU 相關的軟體已經高度成熟、標準化，並為人熟悉；GPU 相關的軟體卻依舊原始、定製化且怪異。大多數程式設計師仍然將重心放在 CPU 上。但我們不是。我們正在建構第一家 GPU 原生的軟體公司。我們在 rust-gpu 和 rust-cuda 上的工作只是起點，是達到目標的手段。我們會不斷交付、測試、迭代，直到寫 GPU 程序像寫 CPU 程序一樣稀鬆平常。而在那之後，非凡的成果自然會隨之而來。如果你能感受到腳下大地的震動，就加入我們吧。帶著信念，帶著品味，帶著緊迫感。軟體的新紀元已經到來。好了，文章到這裡結束了。生成式AI 可以說完全把原有的世界，打得一個猝不及防，即便是天花板級的大神也不例外。問題在於，我們如何在這場混亂中尋找機會。共勉！或許，GPU原生的軟體時代，不再只是一個口號~ (51CTO技術堆疊)

9 月 10 日，輝達宣佈將在 2026 年底前推出全新人工智慧晶片 Rubin CPX。這是 Blackwell 平台的繼任者，被定位為“視訊生成與 AI 程式設計”的專用加速晶片。與傳統 GPU 最大的不同在於，Rubin CPX 高度整合了視訊解碼、編碼與推理功能。過去，生成一小時視訊所需的處理量高達百萬級 token，遠超常規 GPU 的處理邊界。Rubin CPX 的設計目標，就是為這種指數級增長的算力需求提供 專用解決方案。更引人注目的是，輝達首次公開了經濟模型：向 Rubin CPX 系統投入1 億美元，最高可帶來 50 億美元 token 收入；硬體價值不再是一次性出貨，而是與 AI 應用的 token 消耗直接掛鉤。一｜技術路徑的三步走1｜算力邊界突破Rubin CPX 內建的視訊流水線將推理吞吐提升至 Blackwell 的 3–4 倍，面向1 小時視訊 ≈ 100 萬 token 的處理量做專門最佳化。2｜系統級整合通過整合解碼、編碼、推理，CPX 取消了 CPU 與外部加速器之間的資料搬運，平均延遲縮短 40%–50%。3｜能源效率提升在同等算力下，CPX 的能耗比常規 GPU 下降 30%–35%，這是視訊場景下能否規模化部署的關鍵。二｜三個關鍵訊號🔍1｜AI 視訊生成已成算力新高地視訊生成和 AI 程式設計是未來最消耗算力的兩大場景。視訊的處理量比文字/圖像高一個數量級，未來 AI 的增長曲線幾乎註定將在視訊領域展開。🔍2｜資本邏輯正在轉向 token 維度過去，晶片的價值以 FLOPS 衡量。如今，Rubin CPX 把“投入產出比”直接對應到 token 消耗 = 現金流。這讓晶片廠商從硬體銷售變成持續的 token 分成，是資本市場更願意買單的模式。🔍 3｜AI 晶片敘事全面升級輝達從 GPU 性能 → 雲算力租賃 → token 經濟回報，不斷迭代敘事。未來誰能承接更多的 token 消耗，誰就佔據 AI 基礎設施的制高點。三｜市場觀察Rubin CPX 不只是一次硬體迭代，而是一次 商業邏輯的躍遷。它揭示了未來幾年晶片價值的核心：不再僅取決於算力極限；而在於 能否把 AI 應用的 token 消耗轉化為可見的現金流。換句話說，誰能把 token 經濟效應嵌入晶片，誰就有機會主導下一輪 AI 基建的資本溢價。四｜資本市場的故事切換對投資者而言，這不僅是技術與商業模式的更新，更可能改變資本市場對輝達的估值框架。Rubin CPX 可能意味著輝達的收入模型，從過去的 一次性硬體銷售，逐步轉向 類訂閱的持續分成模式：硬體出貨只是起點，真正的價值在於 token 消耗帶來的長尾收益；這種模式讓輝達更像一家 “雲服務+軟體平台” 企業，而不是傳統半導體公司；對資本市場而言，這相當於從周期性硬體估值 轉向穩定現金流的 SaaS 估值，敘事天花板被再次抬高。這就是 Rubin CPX 背後更大的金融含義：輝達不只是在賣晶片，而是在賣“算力+現金流”的未來。一塊晶片，不止是算力的極限，而是現金流的起點。 (方到)

剛剛，xAI扔出「速度炸彈」的程式設計模型：Grok Code Fast 1！這個全新的推理模型專門為智能體程式設計打造，現在已經在GitHub Copilot、Cursor、Cline、Kilo Code、Roo Code、opencode和Windsurf上免費開放了！全新輕量級架構xAI這次沒有走尋常路，他們從頭開始建構了Grok Code Fast 1，採用了全新的輕量級模型架構。結合創新的加速服務效率改進，Grok Code Fast 1在速度和經濟性上都樹立了新標準。通過xAI API，這個模型的定價主打一個便宜得不講道理：輸入token：$0.20/百萬輸出token：$1.50/百萬快取token：$0.02/百萬全端通吃Grok Code Fast 1在全端開發中表現出色，特別擅長TypeScript、Python、Java、Rust、C++和Go。@DannyLimanseta使用Grok Code Fast 1，僅用一天時間就建構了下面這個遊戲：在訓練過程中，xAI團隊將終端使用者滿意度作為首要目標，通過真實世界的人類評估來衡量。開發者社區一致評價這個模型快速、可靠、經濟實惠，完美適合日常程式設計任務。限時免費xAI(@xai)宣佈，接下來7天內，Grok Code Fast 1將在Cursor、GitHub Copilot、Cline、opencode、Windsurf、Roo Code和Kilo Code等流行的智能體程式設計平台上免費使用。他們還貼心地準備了一份使用指南，教你如何從Grok Code Fast 1中獲得最佳效果：使用技巧根據官方文件，要讓Grok Code Fast 1發揮最大威力，有幾個關鍵點：提供必要的上下文雖然大多數程式設計工具會自動收集上下文，但明確選擇特定程式碼作為上下文會更好。比如不要簡單說「讓錯誤處理更好」，而是說「我的錯誤程式碼定義在@errors.ts中，你能用它作為參考，為@sql.ts中的查詢加入適當的錯誤處理和錯誤程式碼嗎？」設定明確的目標和要求避免模糊的提示詞。與其說「建立一個食物追蹤器」，不如說「建立一個食物追蹤器，當我輸入食物項目時，它能顯示每天按不同營養素劃分的卡路里消耗分解。讓我既能看到概覽，也能獲得高層次趨勢」。持續最佳化你的提示詞Grok Code Fast 1的效率極高，速度是其他領先智能體模型的4倍，成本僅為1/10。這讓你能以前所未有的速度和經濟性測試複雜想法。分配智能體任務Grok Code Fast 1更適合智能體風格的任務，而不是一次性查詢。它擅長快速、不知疲倦地為你找到答案或實施所需的更改。命令列工具雖然官方還沒有推出CLI命令列工具，但已經有開發者分享了在Codex CLI上運行的方法：$ export XAI_API_KEY=your-xai-key$ codex -p grok-code-fast技術細節Grok Code Fast 1是一個推理模型，通過chunk.choices[0].delta.reasoning_content暴露其思考軌跡（僅在流式模式下可用）。它提供原生工具呼叫的一手支援，專門為原生工具呼叫而設計。xAI建議使用原生呼叫而不是基於XML的工具呼叫輸出，後者可能會影響性能。對於快取命中的最佳化也很關鍵。在智能體任務中，模型按順序使用多個工具時，大部分前綴保持不變，因此會自動從快取中檢索以加快推理速度。社區反饋Vals AI(@_valsai)對Grok Code進行了評估，發現在三個程式設計基準測試中，該模型的表現不及Grok 4。在LiveCodeBench上，Grok Code的精準率為62%，與Claude Sonnet 4等其他推理模型相似，但成本約為其十分之一。在國際資訊學奧林匹克(IOI)測試中，Grok Code得分4.3%，在12個模型中排名第8。在SWE-Bench上，Grok Code以57.6%的成績在15個模型中排名第4。Grok官方回應說，Grok Code Fast針對速度和低成本進行了最佳化，非常適合快速編碼任務，他們正在根據這些反饋進行迭代以提高精準性。Grummz(@Grummz)分享了一個最佳化技巧：在Grok完成所有工作後，程式碼可能會很混亂。告訴Grok假裝自己是X公司的首席工程師，審查並重構程式碼。效果非常好。馬斯克站台Elon Musk(@elonmusk)也第一時間親自為Grok Code V1.0站台：試試@Grok Code V1.0，讓我們知道需要改進什麼。將快速發展以滿足你的需求。Grok官方帳號也主動回應互動道：感謝Elon！很高興大家能試用Grok Code V1.0。分享你的想法，我會整合反饋快速升級。你最優先希望改進什麼？xAI團隊表示，這只是開始，他們致力於為Grok的程式設計能力提供持續更新，以提高使用者滿意度和生產力。如果你對建構世界最佳程式設計模型的使命感到興奮，xAI團隊很樂意與你交流！ (AGI Hunt)

剛剛，馬斯克xAI加入Coding戰局：推出智能程式設計模型Grok Code Fast 1。Fast寫進名字裡，新模型主打的就是快速、經濟，且支援256K上下文，可在GitHub Copilot、Cursor、Cline、Kilo Code、Roo Code、opencode和Windsurf上使用，還限時7天免費！不僅性能比肩Claude Sonnet 4和GPT-5，價格更是只有它們的十分之一。已經有網友在Cursor上用Grok Code Fast 1製作了一個模擬戰鬥的小遊戲，可實現持續互動。目前，Grok Code Fast 1在ToyBench上的整體排名為第5名，僅次於GPT-5、Claude Opus 4、Gemini 2.5 Pro和DeepSeek Reasoner。近期，各家發佈的新產品可不少，讓人感嘆：AI發展太快了……能力如何？先來看一波網友實測。首先，第一感受就是確實快，思考時長基本在幾秒之內。在VS Code開源免費的擴展Cline中即可使用。還有人將Grok Code Fast 1加入到聊天機器人中，只需要簡單的prompt：展示真正優秀的pygame。就得到了如下隨機的多媒體效果，看上去也非常絲滑～不只遊戲模擬器，Grok Code Fast 1對UI設計也手拿把掐。在多指令下建構的時間晶體的細節展示也很到位。確實，不少體驗者都表示，這個新模型在指令遵循方面表現很優秀。看完實測案例，再來看看模型情況。兼具速度與性價比根據官方透露出的消息，Grok Code Fast 1從零開始搭建了全新的模型架構，使用專門的程式碼語料庫進行預訓練，並利用真實世界拉取請求與編碼任務資料進行微調。另外，還與GitHub Copilot、Cursor、Roo Code等平台深度合作，讓模型能夠在IDE中快速理解開發者指令，完成如grep、終端和檔案編輯等常用工具的使用。借助推理加速和提示快取最佳化，模型能在你還沒讀完思維流程第一段文字時，就已經執行了數十種工具呼叫。指令快取命中率更是超過90%，使用者體驗將會極度順暢，讓響應毫無卡頓的感覺。除了快，Grok Code Fast 1還具有很強的通用性，無論是TypeScript、Python、Java，還是Rust、C++、Go，它都可以輕鬆完成，從建立項目到點對點的bug修復，而無需人工監督。在內部基準測試SWE-Bench-Verified的完整子集上，grok-code-fast-1成績可達70.8%，在其餘一眾程式設計模型中，性能也處於較為領先的程度。除了傳統基準，測試過程中還額外加入了開發者主觀評估與自動化行為監控，確保模型快速可靠，滿足日常編碼任務。支援256K的上下文窗口，每分鐘最多請求數是480，每分鐘可處理約200萬token。對於日常高頻編碼使用者，這個價格可以說是相當友好了，在性能上也不輸其他程式設計模型。另外，官方也和Grok 4做了對比，Grok 4更適合單次問答類場景，如複雜概念解析或深度偵錯，需要事先提供充足上下文。而Grok Code Fast 1作為輕量級智能編碼模型，更適用於多步驟、工具呼叫密集的複雜自動化任務，是兼具速度和效率的AI程式碼助手。此次更新中，最亮眼的莫過於Grok Code Fast 1超高的性價比。每1M輸入tokens只需要0.2美元（折合人民幣約1.4元），輸出tokens需要1.5美元（約10.7元），快取呼叫tokens更是僅需0.02美元（約0.14元）。與Claude Sonnet 4和GPT-5相比，相當於是只有別人的10%。現在更是7天內可以免費使用……所以已經用過的朋友，快來說說馬斯克家的AI coding體驗夠不夠地道？ (量子位)

你刷著科技資訊，突然又看到那句老調重彈的斷言：“AI 將在 2026 年取代所有開發者。”可就在這時，OpenAI 聯合創始人 Andrej Karpathy 和亞馬遜、Google老將 Steve Yegge 卻給出了完全不同的預測。他們的觀點，直接顛覆了這種說法。他們的看法？大家都想反了。我這幾個月一直在密切使用 AI 程式設計工具，當這兩位大佬不約而同得出同樣的結論時，我就知道這事得好好琢磨一下。他們的觀點不僅和那些“末日論”截然不同，甚至可以說是完全相反。他們是誰？為什麼值得你關注Karpathy 可不是那種只會炒作 AI 的人。他是 OpenAI 的創始成員，曾任特斯拉 AI 總監，親手搭建了如今大家爭論不休的那些 AI 系統。AI 的侷限在那，他比誰都清楚。Yegge 則是在亞馬遜和Google負責過核心基礎設施的老兵，那時候“規模”這個詞的含義和現在完全不同。如今他在 Sourcegraph，直接和企業團隊合作，把 AI 真正落地到生產環境裡——不是做演示，而是要讓程式碼真正在現實中跑起來。當這兩位都看著 AI 程式設計的熱潮說“開發者不會消失”，我會認真聽。顛覆認知的核心觀點我突然明白了：這根本不是“取代”，而是“新一層抽象”。想想看，現在還有多少開發者寫彙編？幾乎沒有。高級語言出現後，程式設計師的飯碗沒丟，反而行業爆發式增長——因為大家能更快地做出更複雜的東西。Karpathy 和 Yegge 都認為，這個歷史正在重演。用 Yegge 的話說：“企業級軟體開發永遠都極其複雜，所以工程師和 AI 會聯手一起搞定它。”關鍵詞就是“聯手”，不是“AI 接管”，而是“協作”。現實中，這到底是什麼樣？給你舉個實際例子。Karpathy 發明了一個詞叫“vibe coding”（氛圍程式設計），非常貼切地描述了現在的變化：“現在有一種新型程式設計方式，我叫它‘vibe coding’，你完全順著感覺走，擁抱指數級提升，甚至忘了程式碼本身的存在。”聽起來挺嚇人？其實操作很簡單。Karpathy 做周末項目時，幾乎不碰鍵盤，直接和 Cursor Composer 對話：“把側邊欄的內邊距減半。”AI 就幫他改好了。看著沒問題，他就繼續。再也不用翻 CSS 檔案、偵錯邊距。遇到報錯，他直接把錯誤資訊貼上給 AI，什麼都不說。“通常就能搞定。”關鍵在於：這種方式是可以根據項目重要性靈活調整的。隨便玩玩的周末小項目？全程交給 AI，自己只管氛圍。企業級生產系統？就得像 Yegge 說的那樣用“監督式 AI”——AI 負責體力活，你全程把關、稽核。同樣的工具，具體怎麼用，取決於你在做什麼，人工介入的深淺也隨之變化。Yegge 的技術進化論（發展速度驚人）Yegge 一直密切關注著這場變革。他大約一年前提出了“對話式程式設計”這個概念——也就是通過與 AI 對話來寫程式碼，而不是依賴自動補全。但現在呢？“對話式程式設計還算主流，但智能體程式設計已經以指數級的速度超越了這種方式，效果遠勝以往。”所謂智能體程式設計，就是讓 AI 能夠獨立完成整個工作流程，你只需在旁邊觀看。與其說“幫我寫個函數”，不如直接讓 AI “為這個應用建構使用者登錄功能，包括密碼重設”。這場進步的速度令人咋舌。從自動補全到對話，再到自主智能體，前後不過一年半。三大程式設計時代（我們正步入第三階段）Karpathy 把這個過程分為三個清晰的階段：第一代：你寫出詳細的指令。比如要排序資料，就得手寫排序演算法。第二代：你給出示例，電腦通過學習樣本找出規律。比如要做圖片分類，就用成千上萬張帶標籤的照片訓練神經網路。第三代：你用英語描述需求。比如要使用者認證，只需說“建立一個帶密碼重設功能的安全登錄系統”。他的核心觀點是：“大語言模型（LLM）是一種全新的電腦，而你用英語來程式設計。”這不僅僅是工具的升級，而是讓任何能清楚表達想法的人都能參與程式設計。產品經理可以自己做原型，設計師也能無需等工程師就搭建互動演示。這不會取代開發者——而是讓所有人的能力成倍提升。一個鮮有人提及的問題：參差不齊的智能但我對此也有保留，Karpathy 的坦率讓人耳目一新。AI 存在所謂的“參差智能”——它能解決極其複雜的問題，卻也會在簡單問題上犯低級錯誤。AI 可能能完美實現複雜演算法，卻又信誓旦旦地告訴你 9.11 比 9.9 大。“目前，這一點尤其值得注意，特別是在生產環境中。要用 LLM 做它擅長的事，但要警惕那些‘參差邊界’，並始終讓人類參與把關。”這也是 “AI 會取代所有開發者”這種說法站不住腳的原因。AI 有時極其聰明，有時又愚蠢得不可思議，且難以預測。生產系統無法承受這種不穩定，必須有人類監督。經濟現實（已經在發生）有一點你必須重視：“有些公司已經裁掉了 30% 不願意用 AI 的工程師。”不是將來，而是已經發生。“有錢的公司可以直接投入，但其他公司就要做艱難選擇——要麼承擔成本、要麼被競爭對手甩開、要麼裁員來彌補新開支。”換句話說，如果一個用 AI 工具的開發者能頂仨人幹活，你覺得那兩個會被裁掉？這不是理論，我現在就在現實公司裡看到這種情況。會用這些工具的開發者變得極其搶手，而忽視 AI 的人正在被淘汰。你真正需要學什麼（和你想的不一樣）真正重要的能力，並不是死記硬背新 API，或者學點提示詞工程的小技巧。更高階的能力其實有以下幾種：AI 監督力：學會分辨 AI 輸出到底靠譜還是胡說八道。這種能力其實可以訓練出來——你會逐漸發現 AI 常犯的錯誤模式。問題架構力：把複雜需求拆解成 AI 能穩妥處理的小塊。這其實是傳統工程師的老本事，只不過用在了新工具上。質量把控力：能迅速發現 AI 帶來的那些隱蔽 bug。這和普通偵錯不一樣，因為 AI 的錯誤有自己獨特的規律。自然語言表達力：能更清晰地描述需求。如果程式設計越來越像對話，那溝通能力就成了技術能力。有趣的是，這些本質上都是人的能力，和 AI 協作後會被放大，而不是被取代。關於進展（別被炒作帶偏，關注現實）Karpathy 對“ 2025 年 AGI 就要來了”這種說法潑了盆冷水：“每當我看到‘2025 是智能體元年’這種說法，我都很擔心，其實我覺得這應該是‘智能體的十年’。”十年，不是一年。“可惜的是，華爾街並不懂得耐心，所以 AI 的炒作還會繼續喧囂下去，而真正的從業者還在摸索如何開啟新的計算時代。”但現在已經有些現實成果你可以用上：像 GitHub Copilot、Cursor 這樣的工具，已經讓開發者在日常任務上提速 30% 到 50%。這不是理論上的提升，而是你今天就能看到的實際效果。這場變革來得不算太快，你有時間適應；但也不算慢，現在就該開始行動。為什麼我對這場變革反而樂觀說實話，我一開始也很懷疑。“AI 讓程式設計大眾化”這種說法，聽起來就像矽谷的老套忽悠。但真正用這些工具做了幾個項目後，我突然明白了。每一次程式設計範式的變遷，都是類似的軌跡：從彙編到 C，從 C 到 Python，從命令列到圖形介面。每次大家都擔心門檻降低會讓行業變弱，但每次結果都是行業變大、變有創造力。那些最終脫穎而出的開發者，從來不是死守舊工具的人，而是善於用新工具做出以前做不到的東西的人。這次的變化更大。我們不只是換了種語法，而是獲得了一種全新的問題解決方式——更重視清晰表達，少了死記 API 的負擔。正如 Yegge 所說：“電腦科學教育確實需要進化，但基礎依然重要。當年彙編被高級語言取代時，大家擔心程式設計能力會退化，結果反而行業擴張、崗位增加。”現在最吃香的開發者，不是那些精通 React hooks 或 Kubernetes 配置的人，而是能清楚表達自己想法，並能引導 AI 正確實現的人。本周你該做什麼別再光看資料了，趕緊上手試試吧。挑一個 AI 程式設計工具用起來——如果你想要穩定一點的體驗，就選 GitHub Copilot；如果你想嘗鮮最新功能，那就試試 Cursor。先從一個無關緊要的小項目開始，做點有趣又無壓力的東西，比如隨機語錄生成器、簡單的待辦事項應用之類的。這種項目對程式碼完美與否沒什麼要求，放手去做就好。別想著一口氣徹底革新你的整個開發流程。先在這些低風險的小項目裡，適應一下人與 AI 協作的節奏。那些已經在 AI 時代如魚得水的開發者，從來不是等到工具完善、教學齊全才開始的。他們都是邊試邊錯，邊做邊學。真正的未來Karpathy 和 Yegge 都明白一件事，而那些“AI 取代人類”的說法卻忽略了：這項技術是放大人類智慧，而不是取而代之。我們不會被淘汰，我們會變成指揮者。AI 不是來搶我們的飯碗，而是讓我們和它配合，去解決單靠自己搞不定的大難題。未來屬於那些能站在更高層次思考、善於溝通、懂得如何指揮 AI 解決複雜問題的開發者。如果你已經走到今天這一步，其實你已經具備了大部分所需的能力。你只需要開始學會和 AI “共舞”。說真的，這支舞一旦跳順了，還挺有意思的。革命不是即將到來，而是已經發生。問題只在於，你是要參與塑造它，還是被它塑造。 (大模型技術共學營)