OpenAI剛剛投下了一枚重磅炸彈：原本作為程式設計師「副駕駛」的Codex迎來史詩級更新，正式從程式碼工具進化為通用個人助理，奧特曼親自下場帶貨。開發者實測後驚呼：Codex接管整台Mac，人類全程0操作圍觀，太炸裂了！OpenAI重大更新！OpenAI的智能體Codex，這次直接硬剛Claude Cowork。Codex是OpenAI的旗艦程式碼生成模型，支援GitHub Copilot等產品，已成為全球開發者不可或缺的AI助手。這次的更新，非常重磅。YouTube創作者Mike Russell發佈了一條實測視訊，效果炸裂。他把自己的Mac完全交給了OpenAI最新升級的Codex，讓GPT-5.5操控Adobe Audition修複音頻、用Photoshop做封面、再用Adobe Firefly生成AI視訊。從頭到尾，人類全程零操作。這不是Demo，不是PPT，是一個真實創作者把自己的生產力工具鏈完整交給AI跑了一遍。OpenAI聯創、總裁Greg Brockman直接喊話：「Codex人人可用，電腦任務全可做！」是的，一個寫程式碼的工具，突然要搶所有人的鍵盤了。AI大V歸藏表示，一下午，一句話，Codex就幫自己開發了一個完整的遊戲。最讓人驚訝的是Codex處理素材的方式：他提供了一個包含上千張圖片的素材包，並未說明篩選方法。Codex卻自動將每個資料夾內的圖片整合成一張總覽圖，附帶檔案名稱。這樣一來，只看一張圖就能掌握全部素材風格，選中後再直接呼叫檔案即可。這個操作實在令人震驚，讓他直呼Codex太牛了！網友直呼，Codex終於迎來自己的「Claude Code高光時刻」——一個複雜的完整的Mac應用，整合了攝影機、麥克風、錄屏，它一次就搞定了。用過Codex的網友，根本停不下來！Codex變了：從程式碼助手到電腦管家總之，過去大家對Codex的認知很清晰——就是一個寫程式碼的工具。它能幫你補全函數、偵錯bug、生成指令碼，是程式設計師的副駕駛。這次升級直接把邊界炸開了。OpenAI官方公告裡最核心的一句話：Codex現在支援Slack整合和Google Workspace全家桶整合。翻譯成人話就是——它不光能寫程式碼，還能讀你的郵件、回你的Slack消息、操作你的Google Docs和Sheets。這句話，讓OpenAI的野心藏不住了：它不再把Codex定位為開發者工具，而是——通用電腦操控agent。就在昨天，Codex就忽然官宣了一大波更新。它能跨Slack、Gmail、Calendar自動總結變化、做資料分析、輔助決策。可以組織研究材料、製作電子表格和簡報。可析資料匯出、標記更改的內容，起草解讀報告。還能根據標準對比多個選擇、跟蹤權衡取捨。OpenAI聯創Greg Brockman，這位習慣了20年黑屏命令列終端、視程式碼如生命的頂級駭客，公開宣佈：我徹底愛上了Codex App，它已經取代了我用了20年的終端。開發者懂的都懂，這是什麼份量。如此強大的更新，讓奧特曼直接發帖直呼：「Codex正在經歷ChatGPT時刻！」繼昨天的這一大波更新之後，今天凌晨，OpenAI Codex核心成員Tibo在X上發帖稱「Feeling codexy today」，預示著Codex又將迎來史詩級更新。此帖一出，程式設計師圈瞬間沸騰了！果然，沒過多久，OpenAI又開始放出新的case了。使用Codex處理日常工作，從未如此輕鬆。你可以選擇你的角色，連接每天使用的應用，並嘗試推薦的提示詞。無論是調研與規劃，還是文件、簡報、電子表格等，Codex都能提供幫助。Codex會根據你的角色推薦有用的外掛，並指導你連接各種應用程式，比如SlackHQ、GoogleWorkspace、Microsoft365等等。它如同你的私人助理，可以彙總來自不同應用程式和文件的資料，規劃下一步，起草工作，組織研究，或建立項目計畫。你可以一目瞭然地看到正在發生的事情，包括任務進度、使用的檔案和工具以及接下來要做的事情。從草稿到成稿，你可以在Codex中隨著內容逐步成形進行審閱。打開檔案，提出修改意見，並在同一個對話線程中不斷最佳化和調整。開發者大V表示，Codex和Claude Code非常不一樣。如果限額即將結束，那就可以執行一個長時間任務，即使限額已經結束，Codex都會繼續執行這個任務，直到任務完成。這個帖子直接被奧特曼轉發。Tibo還表示，在良好的使用者體驗和最佳化利潤率之間，OpenAI選擇了前者。甚至，OpenAI專門放出一個官方部落格指南，介紹如何在日常工作中使用Codex。Claude Code頭號粉絲轉向Codex，奧特曼鼓掌就在Codex升級的同一天，另一場好戲開演了。在X上，有使用者說出自己的心聲：Claude Code生成質量在最近三周內明顯下滑了，精準率暴跌，因此她90%的時間都在用Codex，感覺非常滿意。奧特曼很快出現，以星戰梗回應道：「歡迎加入光明面！」果然，又有更多開發者站出來表示，真的不喜歡用Claude，因為它很笨拙，使用者介面也總是不對勁，bug也很多。這一次，開發者自己用腳投了票。Codex實測太瘋狂了！Codex App開發人員Andrew Ambrosino直言：「Codex 搞定一切！」這次更新，Codex為當前任務自動適配動態UI，體驗更佳：幻燈片和表格體驗更佳支援在瀏覽器、工件和程式碼中直接標註上手更簡單整體設計更簡潔性能全面提升在Codex應用內瀏覽器中還加入了裝置工具列，讓建構和測試響應式應用變得更加便捷——瀏覽器使用的速度（在主觀測試中約提升30%）。不過，「大家好才是真的好」，全網第一波實測已經來了。讓我們一睹為快吧！接管整台Mac，人類全場0操作圍觀Mike Russell的實測才是這次升級最直觀的證明。他給Codex下了三個任務：任務一：音訊修復。 一段錄音有明顯的背景噪聲和齒音問題。Codex自動打開Adobe Audition，識別噪聲特徵，應用降噪濾波，調整EQ參數，匯出成品。Russell事後回聽評價：「專業級修復，比我手動調得還乾淨。」任務二：播客封面設計。 Codex打開Photoshop，根據播客主題自動選擇配色方案、排版標題文字、調整圖層混合模式，輸出一張可以直接上傳的封面圖。任務三：AI視訊生成。 Codex呼叫Adobe Firefly，根據文字描述生成視訊素材片段，自動拼接、加轉場。三個任務，跨三個Adobe專業軟體，全自動完成。Russell在視訊裡反覆強調一個細節：他全程沒碰滑鼠，沒碰鍵盤，甚至沒有切換過窗口。Codex自己在作業系統層面完成了所有軟體間的切換和協調。「這不是AI在幫我工作，」Russell說，「這是AI在替我工作。」Codex這次升級打中的不是程式設計師，是所有依賴電腦工作的人。當AI能操控你的整台電腦，「會不會用軟體」這個技能本身就在貶值。當然，Russell的實測並非完美。Firefly生成的視訊素材有幾幀出現了明顯的畫面抖動，Codex沒有自動識別並修正。Photoshop封面的文字排版在第一次嘗試時出現了字型大小不一致的問題，Codex自己發現後做了第二次調整才過關。Russell的總結很實在：「它不是100分，大概85到90分。但問題是——達到這個水平它用了8分鐘，我自己做要2個小時。」85分乘以8分鐘，和100分乘以2小時。大多數場景下，前者贏。Codex幫你0成本無限次拍攝網友Matthew Berman直接介紹如何用Codex無限次的拍攝產品，一個網路連線就能轉化為完整的電商照片：以前： 一套電商產品圖要5,000 - 25,000美元，耗時4周。現在：輸入一個 URL，10 分鐘出片，成本為0。他把整套系統封裝成了 「品牌商拍工具包（Brand Shoot Kit）」。它如何把一個網頁連結變成一整套電商攝影庫？只需以下 7 個 Agent（智能體）技能：人類的鍵盤，終於要淘汰了？以往，全面用手動方式偵錯UI的方式，往往非常消耗心力。每次都要一點一點地檢查AI有沒有破壞其他不相關的部分，這種壓力是無聲的。但如果我們能把執行階段的UI行為測試也交給AI去做，那人類這邊的負擔就能得到合理減輕。現在，Codex終於帶來了希望！顯然，Codex，已經能用滑鼠逐一檢查UI介面或行為是否正常——整個過程完全自動化。網友感嘆：「這感覺就像是「人們一直期待AI能做到的事情」終於到來了。」「我感覺我們正在逐漸接近下一個重大轉變的臨界點。」在視訊最後，Russell說了這樣一句話：「當AI能操控你的整台電腦，會不會用軟體這個技能本身就在貶值。」這次，Codex打中的不是程式設計師，畢竟程式設計師早就習慣了AI寫程式碼。這次打中的是所有依賴電腦工作的人——做PPT的、寫郵件的、剪音訊的、修圖的、做報表的。以前的邏輯是，人學會用工具，工具放大人的能力。現在的邏輯開始變了：AI學會用工具，人只需要說清楚自己要什麼。可以說，Codex不是在升級功能，它是在重新定義「使用電腦」這件事本身。在Russell的45分鐘實測裡，那台Mac上發生的一切——滑鼠自己在動、軟體自己在切換、音訊自己在渲染——這個畫面大概會成為2026年最具象化的一幕。以前人類用滑鼠呼叫軟體，現在AI用API呼叫軟體。下一步呢？不可想像。 (新智元)

OpenAI 的開發者關係負責人 Romain Huet 宣佈 Codex 上線了一個官方案例庫。12 個實打實的使用場景，每個都帶完整的操作步驟、Prompt 範本，甚至可以一鍵在 Codex 應用裡打開。“我們剛剛發佈了 Codex 案例庫！這是一個涵蓋程式設計和非程式設計任務的實用案例集合，展示了 Codex 的真實使用方式。我特別喜歡的一點是：如果你安裝了 Codex 應用，可以直接一鍵打開每個案例的 Starter Prompt！Codex 案例庫首頁這 12 個案例覆蓋了從程式碼審查到做 PPT、從資料分析到做遊戲的各種場景，有些確實刷新了我對「AI 程式設計工具」邊界的認知。逐個來看。PR 自動審查PR 自動審查案例頁面第一個案例是 GitHub PR 審查，也是上手門檻最低的一個，難度標註為 Easy，耗時大約 5 秒。做法很直接：把 Codex 接入你的 GitHub 倉庫，它會在每個 PR 提交後自動掃一遍，找出潛在的回歸問題、缺失的測試、以及文件漏洞。你也可以選手動模式，在 PR 評論裡 @codex review，它就來了。發現問題之後呢？直接在評論裡回一句 @codex fix it，Codex 會啟動一個雲端任務自動修復。這裡面有個細節值得一提：你可以在倉庫裡放一個 AGENTS.md 檔案，定義審查規則。比如「拼寫和語法錯誤標為高優先順序」「缺少測試覆蓋標為中優先順序」，Codex 會根據離每個檔案最近的 AGENTS.md 來調整審查策略。Starter Prompt：“@codex review，檢查安全回歸、缺失測試、以及有風險的行為變更。算是把 Code Review 這件事從「等同事有空」變成了「提交即審查」。截圖變頁面截圖轉前端 UI 案例頁面第二個案例是前端開發：把截圖和設計稿直接變成響應式 UI 程式碼。難度中等，大約需要 1 小時。流程是這樣的：你把設計參考圖（桌面版、移動版、各種互動狀態的截圖）丟給 Codex，同時告訴它你項目裡已有的設計系統、元件庫、色彩 token、排版規範。Codex 會用你現有的元件和設計 token 來實現，而不是另起爐灶搞一套新的。然後用 Playwright 打開瀏覽器，逐個螢幕尺寸對比。不對？繼續調。Starter Prompt：“用截圖和說明作為參考，在當前項目中實現這個 UI。要求：復用現有設計系統的元件和 token，把截圖翻譯成倉庫裡的工具類和模式，匹配間距、佈局、層級和響應式行為，相容桌面和移動端。這個案例的關鍵在於「復用」二字。Codex 會基於你已有的設計體系來寫程式碼，復用現成的元件和 token，這一點倒是和真人前端工程師的工作方式一致。資料分析全流程資料分析案例頁面第三個案例，也是我覺得最適合非程式設計師的一個：資料分析。難度中等，大約 1 小時。這個案例的完整度讓我有點意外。它不只是「幫我畫個圖」，而是從資料匯入、清洗、合併、建模到最終報告，一條龍。具體的步驟：先定義問題。 比如「高速公路附近的房子，房價是不是更低？」問題越具體，Codex 越好辦事。再設定環境。 在 AGENTS.md 裡定義項目規則：用什麼 Python 環境，資料夾結構怎麼放，原始資料放 data/raw/，清洗後的放 data/processed/，永遠不覆蓋原始檔案。然後讓 Codex 自己看資料。 它會檢查檔案格式、編碼、每個資料集代表什麼、有那些候選主鍵、明顯的質量問題。接著合併和建模。 在合併之前先做資料畫像，測試主鍵的唯一性和空值率，用試探性 join 看匹配率。建模則從可解釋的基線模型開始，statsmodels 和 scikit-learn 為主。最後輸出報告。 可以是 Markdown 給同事看，Excel 給營運看，PDF 或 .docx 給老闆看。這套流程其實就是一個標準的資料分析 pipeline，只不過以前是人寫程式碼跑，現在是 Codex 幫你寫幫你跑。Starter Prompt：“我在這個工作區做資料分析項目。目標：搞清楚高速公路附近的房子是否估值更低。先讀 AGENTS.md 瞭解 Python 環境，載入資料集，描述每個檔案的內容、可能的 join key 和資料質量問題，然後提出一個可復現的工作流程。約束：優先用指令碼而非 notebook 狀態，不要編造缺失值或合併鍵。輸出：環境配置計畫、資料清單、分析計畫、第一批要建立的命令或檔案。做 ChatGPT 應用ChatGPT 應用案例頁面第四個案例是高級玩法：把你的產品做成一個 ChatGPT 應用。難度標註為 Advanced，大約 1 小時。一個 ChatGPT 應用由三部分組成：• MCP 伺服器：定義工具、返回資料、處理認證• 可選的 Widget：一個在 ChatGPT 內渲染的 Web 元件（React 或原生 HTML/CSS/JS）• 模型整合：ChatGPT 根據你的工具中繼資料來決定何時呼叫Codex 在這裡的角色是幫你規劃工具介面、搭建 MCP 伺服器和 Widget 腳手架、配置本地 HTTPS 測試環境、實現認證流程。工作流程分七步：先規劃（別一上來就寫，先想清楚核心使用者場景），然後選技術堆疊，搭腳手架，測試，迭代核心功能，最後才加認證和部署。Starter Prompt：“用 $chatgpt-apps 和 $openai-docs 為 [你的場景] 規劃一個 ChatGPT 應用。要求：從一個核心使用者場景開始，提出 3-5 個工具及其名稱、描述、輸入輸出，建議 v1 是否需要 Widget，TypeScript 做 MCP 伺服器，React 做 Widget。輸出：工具規劃、檔案樹、測試 Prompt 集、風險和待定事項。官方文件裡還貼心地列了常見坑：別一開始就想把整個產品搬過來，先做一個核心功能。別寫一個巨大的 Prompt，拆成「規劃 → 搭建 → 認證 → 部署 → 稽核」五步。別先做 UI，先把工具介面定義清楚。別跳過在 ChatGPT 開發者模式裡的實際測試。iOS 和 macOS 開發iOS 和 macOS 開發案例頁面第五個案例面向 Apple 生態的開發者：用 Codex 搭建 SwiftUI 應用。難度 Advanced，大約 1 小時。核心思路是 CLI 優先。用 xcodebuild 命令列工具，不走 Xcode GUI，保持終端化的工作流程。如果覺得 xcodebuild 太繁瑣，可以用 Tuist 來簡化項目生成。對於已有的 Xcode 項目，可以接入 XcodeBuildMCP 工具來做 Scheme 檢查、模擬器控制、截圖捕獲和 UI 自動化。官方還提供了一系列專項 Skill：SwiftUI 專家、Liquid Glass 專家、性能審計、並行專家、檢視重構……每個都是一個可以載入的專項能力包。Starter Prompt：“搭建一個 SwiftUI 啟動應用，並加入一個建構和啟動指令碼，我可以把它繫結到本地環境的 Build 操作上。瀏覽器遊戲瀏覽器遊戲案例頁面第六個案例畫風突變：做遊戲。難度中等，但官方標註為「長時間運行任務」，因為大量素材生成可能需要幾個小時。流程值得展開說說。先寫一份遊戲策劃文件 PLAN.md，定義玩家目標、核心遊戲循環、操作方式、勝負條件、難度遞進、視覺風格、技術堆疊和開發里程碑。然後在 AGENTS.md 裡配置 Codex 的行為規範：遊戲名稱、類型、技術堆疊（推薦 Next.js + Phaser 或 PixiJS 做渲染），以及要用到的 Skill。這裡用到三個關鍵 Skill：• Playwright Interactive：在真實瀏覽器裡測試遊戲，調整操控和 UI• ImageGen：生成概念圖、精靈圖、背景、各種視覺素材• OpenAI Docs：查最新的 API 文件Codex 根據計畫生成第一版，然後你截圖反饋，它再調整，如此迭代。Starter Prompt：“用 $playwright-interactive、$imagegen 和 $openai-docs 來規劃並建構一個瀏覽器遊戲。實現 PLAN.md，並在 .logs/ 下記錄工作日誌。從寫策劃到出成品，一個人就能做一款瀏覽器小遊戲……這也算是 Vibe Coding 的最佳註腳了。自動做 PPT自動生成 PPT 案例頁面第七個案例回到職場剛需：做 PPT。難度 Easy，大約 30 分鐘。用的是 PptxGenJS 庫來操作 .pptx 檔案，配合 ImageGen 生成視覺素材。幾個關鍵原則：先看再改。 改已有的 PPT 之前，先讓 Codex 檢查現有的幻燈片結構，匹配寬高比，對照渲染截圖來調整。保持可編輯。 文字保留為 PowerPoint 文字對象，簡單圖表用原生 PowerPoint 圖表，不要把整張幻燈片柵格化成圖片。驗證流程。 渲染成每頁 PNG 再檢查，檢測文字是否溢出畫布邊界，報告缺失或被替換的字型。Starter Prompt：“用 $slides 和 $imagegen 編輯這個幻燈片：在每頁右下角加 logo，把文字左移並在指定頁面生成抽象數字藝術插圖，保持文字可編輯，按現有品牌風格新增幻燈片，渲染成圖片稽核，檢查溢出和字型替換問題，保存可復用的生成 Prompt。30 分鐘，即可做一套品牌風格統一的 PPT 出來。死磕難題迭代攻克難題案例頁面第八個案例的思路和其他的都不一樣：它教你怎麼讓 Codex 反覆迭代，死磕那些一次搞不定的難題。這個案例的核心概念是「評估驅動的改進循環」。很多任務並非「做了就對」，需要反覆最佳化。Codex 的做法是：檢查輸出 → 打分 → 決定下一步改動 → 再檢查再打分，循環往復，直到達標。打分機制分兩層：確定性檢查（程式碼能不能跑、測試過不過）和 LLM 評審（可讀性好不好、輸出有沒有用）。Starter Prompt：“這個工作區裡有個棘手的任務，我想讓你用評估驅動的改進循環來做。開始之前：讀 AGENTS.md，找到給當前輸出打分的指令碼或命令。迭代循環：每次只做一個聚焦的改進，每次有意義的改動後重跑評估，記錄分數和改動內容，直接檢查生成的產物，持續迭代直到總分和 LLM 評審平均分都超過 90%。約束：不要在第一個可接受的結果就停下來，除非新結果明顯更差否則不要回退，遇到瓶頸時說明卡在那裡。這其實是把「進化演算法」的思路用到了 AI 程式設計裡，通過反覆評估和微調來逼近最優解，不追求一步到位。Slack 發任務Slack 整合案例頁面第九個案例走的是整合路線：直接在 Slack 裡給 Codex 派活。難度 Easy，5 分鐘搞定。裝好 Slack 應用，連接倉庫和環境，把 @Codex 加到頻道里。然後在任何一個 Slack 對話線程裡 @Codex，附上你的需求，它就會啟動一個雲端任務。做完之後會線上程裡貼回結果連結，你也可以去 Codex 雲端面板查看詳情。Starter Prompt：“@Codex 分析這個線程裡提到的問題，並在 <環境名稱> 中實現修復。官方建議：請求要具體，指明用那個倉庫和環境，大型程式碼庫的話還要引導 Codex 去看那些檔案或目錄。這其實是把 Codex 變成了一個隨時待命的遠端程式設計師。產品經理在 Slack 裡描述 bug，@Codex，然後去喝杯咖啡回來看結果。Figma 變程式碼Figma 轉程式碼案例頁面第十個案例是設計師和前端的橋樑：把 Figma 設計稿直接變成程式碼。難度中等，大約 1 小時。和第二個案例（截圖變頁面）的區別在於，這個直接從 Figma 的結構化資料入手，而不是從截圖。流程分幾步：先在 Figma 裡做好準備工作。用 Variables/Design Tokens 管理顏色、排版、間距，建構可復用的元件，別用散落的圖層，用 Auto Layout 實現響應式行為，命名規範清晰。然後用 Figma Skill 的幾個關鍵命令：get_design_context 獲取節點的結構化設計資訊，get_metadata 獲取更詳細的中繼資料，get_screenshot 獲取精確的視覺參考。最後用 Playwright 做視覺驗證，對比實際渲染效果和設計稿。Starter Prompt：“實現這個 Figma 設計……先用 get_design_context 獲取目標節點或畫面……復用現有設計系統的元件和 token……桌面和移動端都要做響應式……用 Playwright 檢查 UI 是否匹配參考設計。讀懂大型程式碼庫程式碼庫理解案例頁面第十一個案例特別適合新人：快速理解一個陌生的程式碼庫。難度 Easy，5 分鐘。你要做的就是問 Codex：這個系統的請求是怎麼流轉的？那些模組負責什麼？資料在那裡做校驗？改程式碼之前有什麼坑要注意？最後推薦我下一步該讀那些檔案？Starter Prompt：“解釋程式碼庫中 <系統區域> 的請求流轉過程。包括：那些模組負責什麼，資料在那裡做校驗，改程式碼前有那些注意事項。最後告訴我接下來應該讀那些檔案。還可以追問更深的問題：•  那個模組負責業務邏輯，那個負責傳輸層，那個是 UI？•  校驗邏輯在那裡執行，有那些隱含的假設？•  如果我改了這個流程，那些關聯檔案和後台任務容易被忽略？•  改完之後應該跑那些測試？對於新入職的工程師來說，這相當於一個隨時線上的「程式碼庫導遊」。5 分鐘就能對一個模組建立起初步認知，比翻文件快太多了。升級 API 整合API 升級案例頁面最後一個案例是 API 遷移：把現有的 OpenAI API 整合升級到最新版本。難度中等，大約 1 小時。這個案例直面一個現實問題：換模型不是改個模型名就完事的。API 參數可能變了（比如 GPT-5.4 新增了 phase 參數），模型行為可能不同導致 Prompt 需要調整，還需要建評估流水線來防止回歸。Codex 的做法是先盤點：當前用了那些模型、那些 endpoint、那些工具呼叫假設。然後製訂最小遷移計畫，只改必須改的。更新 Prompt 時參考最新的模型指南。最後標記出所有需要人工稽核的 Prompt、工具或響應格式變更。Starter Prompt：“用 $openai-docs 將這個 OpenAI 整合升級到最新推薦的模型和 API 特性。具體來說，尋找最新的模型和 Prompt 指南。盤點當前的模型、endpoint 和工具假設，制定最小遷移計畫，保留現有行為（除非新 API/模型要求改變），根據最新指南更新 Prompt，標記所有需要人工稽核的變更。◇ ◆ ◇回過頭來看這 12 個案例，有幾個觀察。Codex 應該是在有意模糊「程式設計工具」和「通用工作工具」之間的界限。做 PPT、分析資料、做遊戲，這些案例裡有一半和寫程式碼沒什麼直接關係。另一個值得注意的是 AGENTS.md 的檔案。它在幾乎每個案例裡都出現了，承擔的角色類似於「給 AI 的工作手冊」。定義好規則，Codex 按規則辦事。這本質上是一種新的協作範式：你只需要定義規則和目標，剩下的讓 AI 自己去執行。 (AGI Hunt)

2月6日，OpenAI總裁Greg Brockman在X上公開發了一條面向全公司工程團隊的帖子，設了一個deadline：到3月31日，任何技術任務，工程師的第一工具應該是agent，而不是編輯器或終端。這是OpenAI對自己下的動員令。如果只看這句話，你可能會覺得又是一條矽谷式的願景聲明。但接下來六周發生的事情表明，Brockman不是在喊口號。OpenAI的Coding Agent平台Codex，正在經歷一輪罕見的產品衝刺，密度之高，節奏之快，甚至讓一些長期關注AI編碼工具的開發者開始重新審視自己的工具鏈。與此同時，Codex在程式設計師群體中的熱度和口碑也在肉眼可見地上升。一切動作都指向“狙擊”Anthropic 如日中天的Claude Code。六周的瘋狂迭代拉一下時間線就能感受到這個節奏。2月2日，Codex桌面App發佈（macOS），OpenAI同時宣佈向ChatGPT免費和Go使用者開放Codex，所有付費使用者的速率限制翻倍。2月5日，GPT-5.3-Codex發佈，OpenAI稱它為"第一個幫助創造了自身的模型"。同一天，Anthropic發佈Claude Opus 4.6。2月12日，Codex-Spark發佈，與AI推理硬體公司Cerebras合作，推理速度超過每秒1000 tokens。OpenAI的說法是，“當模型能力越來越強，互動速度就成了明確的瓶頸。”2月14日，OpenClaw創始人Peter Steinberger宣佈加入OpenAI。據Pragmatic Engineer報導，Steinberger用Codex編寫了OpenClaw的全部程式碼，偏好長時間運行的agentic loop。Sam Altman在X上稱他為“天才”，說他將“推動下一代personal agents”。3月4日，Codex桌面App登陸Windows。3月5日，GPT-5.4發佈，是OpenAI第一個同時具備reasoning、coding和原生computer use能力的通用模型，在Codex和API中支援100萬token上下文。3月6日，Codex Security進入research preview。這是OpenAI推出的應用安全代理，前身為內測階段的Aardvark，能夠分析程式碼倉庫、建構項目級威脅模型、在沙盒中驗證漏洞並提出修復建議。過去30天的beta測試中，它掃描了超過120萬次commits，發現792個critical等級漏洞和超過10000個高危問題，覆蓋OpenSSH、GnuTLS、Chromium等重量級開放原始碼專案。誤報率降低超過50%，噪音降低84%。使用資料也在同步攀升。Sam Altman在X上確認，Codex的周活使用者自年初以來增長超過三倍；Codex團隊負責人Thibault Sottiaux（Tibo）告訴Pragmatic Engineer的Gergely Orosz，1月以來它的使用量增長了5倍，周活開發者超過100萬。Tibo還在播客中提到，Super Bowl周日播出的Codex廣告讓系統幾乎立即承受了巨大負載。六周，七次重大產品動作，這成了OpenAI在產品上最激進的衝刺之一。要理解這個節奏，一方面要看供給側的變化。GPT-5系列模型的agent能力在過去幾個月出現了質的飛躍，從上下文窗口、工具呼叫到長時間自主執行，模型本身的能力到了一個可以支撐Coding Agent這個產品形態的臨界點。另一方面，需求側的訊號同樣強烈。據SemiAnalysis報導，Anthropic的Claude Code已經做出25億美元的年化收入，佔其企業收入的一半以上。Claude Code用真金白銀證明了Coding Agent可以成為AI公司的核心收入引擎。對於估值據報已達數千億美元的OpenAI來說，放棄這個賽道不是一個現實的選項。根據SemiAnalysis的預測AnthropicARR增速一度超過OpenAI時間點上的貼身肉搏也值得注意。GPT-5.3-Codex和Claude Opus 4.6在2月5日同一天發佈。Codex Security和Claude Code Security幾乎同期推出。這種節奏本身就是訊號，兩家公司正在把Coding Agent平台視為正面戰場。開發者開始從Claude Code的單一模式變成混合模式在很長一段時間，Anthropic旗下的Claude Code看起來似乎已經沒有了對手，使用者對它的依賴變得越來越重。而OpenAI顯然不想讓Anthropic 這麼舒服。在Codex的一通激進衝刺後，開發者社區的反應也開始發生一些變化。過去一個月，Reddit和Hacker News上關於Codex和Claude Code的討論，出現頻率最高的詞不是更好或替代，而是stacking。也就是說，越來越多的開發者不是在兩者之間選擇，而是同時使用。Calvin French-Owen是一個典型案例。他是Segment聯合創始人，曾在OpenAI參與Codex web產品的發佈，同時也是Claude Code的深度使用者。他在今年2月寫的一篇部落格裡說，自己選擇工具的核心標準是“我有多少時間，以及我想讓它多自主地跑”。他的日常工作流是用Claude Code做規劃、編排終端和管理git操作，然後切到Codex做實際編碼。他說Opus在跨上下文窗口的工作中效率更高，會同時啟動多個子代理平行探索程式碼庫；而Codex在長時間自主編碼任務上更穩定。Reddit上也出現了更具體的分工模式。有開發者詳細描述了一個五段式workflow，先讓Claude Code出計畫，再讓Codex review計畫，然後由Claude實施，最後交給Codex做code review和QA迭代。還有人直接把Claude Code和Codex串成了一個CLI bridge，因為手動在兩者之間複製貼上太累了。一篇社區分析總結了500多條Reddit評論後的結論，Claude Code在一組小樣本盲測中勝率達到67%，質量更高；但Codex 20美元的套餐能編碼一整天不斷，而Claude Code同價位十幾個prompt就用完了。“Claude Code質量更高但用不完，Codex稍弱但全天能用”，這是2026年3月開發者社區最真實的共識。在Cursor官方的benchmark中，GPT系列整體領先其他模型。開發者社區還流傳著一個比喻來描述兩者的氣質差異，Claude像美國人，適合做充滿創造力的探索和頭腦風暴，Codex像德國人，代表極致的效率和專注執行。“它就像一條咬住骨頭不放的狗，非常固執，會一直嘗試直到解決問題。”當然也有反面聲音。Hacker News上有開發者說Codex對自己來說“每一項都比Claude Code差”，尤其是code review會製造看似合理但實際不存在的問題，他最後只把Codex用來覆核Claude的產出。但大方向已經很明確了，社區討論正在從那個更好就用那個，變成兩個都用，各佔一個工位。比的不再是benchmark，是誰是更實用的產品只看模型benchmark，你不太容易理解Codex為什麼起勢。在SWE-Bench這類編碼評測上，Claude Opus 4.6仍然領先。真正讓Codex拉開差異的地方在別處，OpenAI正在圍繞它建構一整套工程系統。Orosz今年2月發表了一篇對Codex團隊的深度報導。其中最引人注目的事實是，Codex超過90%的程式碼是由Codex自己編寫的。Anthropic方面也有類似的說法，Claude Code的建立者Boris Cherny告訴Orosz，Claude Code的資料大致相當。當然，這裡的90%需要打個折扣理解，在一個成熟項目中，樣板程式碼、測試用例、常規重構佔了大量行數，核心架構決策仍然由人來做。但兩家AI實驗室都在用自己的coding 工具來編寫自己的coding 工具，這種自舉本身就說明了這些工具已經深度嵌入了日常工程流程。Codex 的基本工作原理Codex團隊在工程組織層面走得更遠。Orosz的報導描述了一種新的工作方式，Codex團隊的典型工程師同時運行4到8個平行agent，分別處理feature開發、code review、安全審計、程式碼庫理解、bug修復等任務。工程師的角色正在從寫程式碼的人變成管理agent的人。技術選型上，Codex CLI選擇了Rust（Claude Code使用的是TypeScript）。團隊負責人Tibo給出的理由不僅是性能和正確性，還有工程文化，選擇Rust是為了給團隊設定一個高工程標準，同時減少對npm依賴生態的依賴。他們甚至招募了Rust終端UI庫Ratatui的維護者全職加入團隊。更值得關注的是分層程式碼審查機制。Codex團隊訓練了一個定製的code review模型，據Tibo說約9/10的評論能指出有效問題。審查分兩層，非關鍵程式碼在AI review後可以直接merge，核心agent程式碼和開源元件仍然要求強制人工審查。這套機制的意義在於，審查本身開始分層了。還有兩個細節能說明Codex正在從工具走向系統。Codex可以運行自己的完整測試套件來測試自身；團隊還設定了夜間巡檢，讓Codex自動掃描程式碼庫並生成待審修復建議，工程師每天早上進公司時就有一批修復等著review。一家名為Wonderful的AI開發公司的首席架構師在今年3月寫了一篇文章，描述了他們四個月前禁止手動coding後的經驗。他對兩個工具的定位是，Codex是坐在房間後面戴耳機的工程師，默默讀完你整個程式碼庫15分鐘才寫第一行程式碼，Claude則更有產品感，更擅長判斷什麼感覺對。他們把Codex用於低延遲系統工作、即時語音管線、性能敏感程式碼，Claude則用於UI和前端。從coding工具到Agent平台拉遠來看，Codex六周衝刺的方向指向一個更大的野心。Peter Steinberger的加入是一個人事訊號。他日常同時平行5到10個agent，加入OpenAI後的方向是下一代personal agents，不是coding工具。OpenAI正在用Codex作為agent戰略的入口。Codex Security則是另一個方向的延伸。當Codex從幫你寫程式碼走向幫你審計安全，它的定位就已經變了。GPT-5.4進一步加速了這個轉變。作為OpenAI第一個具備原生computer use能力的通用模型，它在Codex中不僅能寫程式碼，還能操作電腦、跨應用執行工作流。配合正在成型的外掛/skills生態系統和企業級權限管理，Codex的輪廓越來越像一個AI原生的開發平台。Codex團隊在Every的播客中透露了他們眼中的下一個瓶頸，就是程式碼審查。模型生成程式碼的速度已經遠超人類review的速度，驗證產出的正確性成了最緊迫的問題。他們已經在嘗試讓模型通過重現使用者操作路徑來“證明”修復有效，而不是讓人類逐行讀程式碼。這些野心和Claude Code已經越來越清楚的發展方向有很多重合，在從Claude Code那裡迅速搶走了一些使用者和使用場景之後，Codex的勢頭正在起來。回到Greg Brockman 2月6日的那條帖子。他設的deadline是3月31日，目前距離deadline還有兩周多，而從過去六周的節奏來看，Codex的衝刺還遠沒有結束。OpenAI把曾經在模型上呈現出的狠勁兒和卷王的氣質，都放到了Codex上，接下來它和Claude code之間短兵相接的故事，會更精彩了。 (硅星人Pro)

ChatGPT的發佈讓OpenAI一戰封神，所有人都覺得這家AI公司會一直贏下去。然而在AI程式設計這條賽道上，佔據先機的卻並非OpenAI。2025年2月份，競爭對手Anthropic低調發佈了Claude Code。這款能夠直接操作電腦、自主完成程式設計任務的AI智能體，在短短幾個月內為Anthropic帶來了超過25億美元的年化收入。與之相比，OpenAI的同類產品Codex，同期年化收入約為10億美元。雙方的差距不止一倍。更令OpenAI尷尬的是，Anthropic的核心創始團隊，正是幾年前從OpenAI離開的那批人。OpenAI位於舊金山Mission Bay的新總部大樓是一棟現代化的玻璃幕牆建築。接待處擺放著介紹公司發展歷程的宣傳資料，樓梯間的牆壁上掛滿了一系列里程碑事件的紀念海報：GPT系列、DALL·E、ChatGPT——每一幅都記錄著這家公司過去幾年的高光時刻。但其中沒有AI程式設計。01. 從Codex到Copilot，OpenAI錯失的先發優勢OpenAI其實很早就開始了AI程式設計方向的探索。2021年，奧特曼和OpenAI聯合創始人格雷格·布羅克曼（Greg Brockman）還在舊金山Mission區的老辦公室，向《連線》雜誌記者展示了一個叫Codex的項目。它是GPT-3的一個分支版本，在GitHub的數十億行開放原始碼上訓練而成。使用者輸入一句自然語言描述，它就能生成一段相應的程式碼。“它可以代表你在電腦世界裡執行操作，”布羅克曼當時說，“你擁有一個可以執行命令的系統。”但這個早期的技術積累，最終沒有轉化為產品層面的持續投入。Codex被微軟看中了。這家軟體公司當時正在開發一個叫GitHub Copilot的產品，這是一款能嵌入程式設計師編輯器、提供程式碼補全功能的工具。一位早期加入OpenAI的員工回憶，當時的Codex“除了自動補全之外做不了太多事情”，但微軟已經將其視為未來產品的重要方向。2022年6月，GitHub Copilot正式發佈，幾個月內就吸引了數十萬使用者。正常情況下，OpenAI應該會加大對這一方向的投入。但接下來發生的事情，讓後來負責Codex產品的團隊感到遺憾。最初的Codex團隊被解散了。一部分成員轉去做DALL·E 2圖像生成項目，一部分去參與GPT-4的訓練。當時公司的首要目標是實現AGI，AI程式設計沒有被視為需要獨立投入的領域。一位前團隊成員說，之後的幾年裡，OpenAI沒有專門的團隊在開發AI程式設計產品。“當時的感覺是，這個領域已經被GitHub Copilot覆蓋了，”畢竟微軟會繼續使用OpenAI的模型來迭代這個產品，不需要OpenAI自己操心。幾個月後，ChatGPT上線，兩個月內使用者數突破1億。OpenAI完全被這次成功轉移了注意力。接下來的2023年和2024年，OpenAI把主要資源投入到多模態模型的研發上，致力於讓AI理解圖像、視訊、音訊，像人一樣操作游標和鍵盤。當時Midjourney等產品正在興起，行業普遍認為大語言模型需要具備處理多模態資訊的能力，才能邁向更高層次的智能。這個方向的選擇本身沒有問題。只是在這段時間裡，AI程式設計這條賽道正在悄然生長，而OpenAI的注意力並不在這裡。02. 競爭對手Anthropic突圍Coding賽道Anthropic選擇了另一條發展路徑。這家公司也做多模態模型和聊天機器人，但有一個方向始終沒有放鬆：程式設計能力。布羅克曼後來在一個播客節目裡談到，Anthropic“從早期就非常專注在程式設計上”。他們不僅用演算法競賽題目訓練模型，還往訓練資料裡加入了真實項目中那些結構混亂的程式碼，就像普通開發者日常面對的那種。“這是我們沒有及時意識到重要性的地方，”他說。2024年6月，Anthropic發佈Claude Sonnet 3.5。很多開發者試用後發現，這個模型的程式設計能力確實突出。一家叫Cursor的初創公司最先受益於此。幾個二十多歲的年輕人做了一款產品：在程式碼編輯器裡用自然語言提需求，AI直接幫忙修改程式碼。他們接入Sonnet 3.5後，使用者量開始快速增長。據熟悉Cursor的人士透露，幾個月內，Anthropic就開始內部測試自己的獨立版本了，也就是後來的Claude Code。Cursor火起來之後，OpenAI曾試圖收購這家公司，但遭到拒絕。對方認為程式設計賽道潛力巨大，希望保持獨立。收購未能達成，OpenAI內部也開始有團隊嘗試AI程式設計方向。2024年底，幾個小型團隊陸續啟動。一個是安德烈·米申科（Andrey Mishchenko）和蒂博·索蒂奧（Thibault Sottiaux）帶領的團隊，這兩人分別是Codex的研究負責人和前GoogleDeepMind研究員。他們最初的動機比較務實：用AI程式設計來加速AI研究，讓AI自動管理訓練任務、監控GPU叢集，研究員就能騰出時間做更有創造性的工作。另一個是亞歷山大·恩比里科斯（Alexander Embiricos）帶領的團隊，他之前負責多模態智能體的研發。他做了一個叫Jam的演示項目，在公司內部引起了不少關注。Jam和2021年的Codex有本質區別。Codex是輸出程式碼讓人來執行，Jam則可以直接進入命令列，自己運行程式碼。恩比里科斯看著電腦螢幕上那個跟蹤Jam操作的自建頁面一遍遍自動更新，感到有些不可思議。“我以前一直以為多模態互動可能是實現AGI的路徑，也許我們以後就是整天和AI共享螢幕，”他說，“但後來逐漸意識到，讓模型以程式設計方式直接訪問電腦，可能是更有效的方向。”這幾個團隊磨合了幾個月後合併在一起。等OpenAI在2025年初完成o3（比o1更針對程式設計任務最佳化的模型）的訓練，他們終於有了建構產品的技術基礎。但這時，Claude Code已經準備公開發佈了。03. 收購受阻與內部衝刺，OpenAI的雙線應對2025年2月，Claude Code以“有限研究預覽”的形式首次亮相。5月，全面開放使用。這個產品和之前流行的“氛圍編碼”模式不同。氛圍編碼是人主導、AI輔助的程式設計模式，由人做決策，AI執行具體操作。而Claude Code可以直接在命令列工作，訪問使用者的所有檔案和應用程式，開發者可以把部分工作真正交給AI來完成。OpenAI也開始加快節奏。索蒂奧在3月組建了一個“衝刺團隊”，把內部幾個小組整合在一起，計畫在幾周內推出競品。與此同時，奧特曼開始尋找收購目標，他們看上了一家叫Windsurf的AI程式設計初創公司，報價30億美元。如果收購完成，產品、團隊、企業客戶都能快速補齊。但這筆交易被微軟擱置了數月。據《華爾街日報》報導，微軟希望獲得Windsurf的智慧財產權。這家雲巨頭從2021年起就用OpenAI的模型支撐著GitHub Copilot，每次財報電話會都會提及這個產品。但Cursor、Windsurf、Claude Code陸續出現後，GitHub Copilot的產品形態顯得有些過氣。此時OpenAI再推一個新的編碼產品，微軟的態度自然變得複雜。Windsurf的交易正趕上OpenAI和微軟重新談判合作協議。OpenAI希望從微軟那裡爭取更多自主權，不希望產品和算力資源被過度控制。這筆收購成了雙方博弈過程中的犧牲品。到7月，交易正式告吹。後來Google招攬了Windsurf的創始人，剩餘團隊則被另一家編碼初創公司Cognition收入麾下。“我本來挺希望做成這筆交易的，”奧特曼說，“但不是每一筆交易都能控制。”不過他提到，Codex團隊的表現讓他有些意外。談判那幾個月，索蒂奧和恩比里科斯一直在迭代產品，沒有停下來。到8月，OpenAI開始加速推進自己的產品。04. 從5%到40%：Codex猛追市場份額布羅克曼有一個自己設計的測試方法，叫“反向圖靈測試”。他多年前親自編寫了這套程序，規則是這樣的：兩台電腦前各坐一個人，每人螢幕上有兩個聊天窗口，一個連接著對面的人，一個連接著AI。目標是判斷那個窗口是AI，同時還得讓對方以為你才是AI。去年大部分時間，OpenAI最好的模型要完成這個遊戲的程式碼編寫，需要好幾個小時，中間還得有人一步步引導。到12月，Codex用GPT-5.2做引擎，一個結構清晰的提示詞輸入後，就能直接生成一個可運行的遊戲。感受到變化的不僅僅是布羅克曼。開發者社區裡開始頻繁討論AI程式設計智能體的能力提升，話題從矽谷擴散到更廣的範圍。一些沒有程式設計背景的人，也開始嘗試用這些工具做些簡單的軟體項目。Anthropic和OpenAI都在爭搶使用者。有開發者表示，自己每月支付200美元的Codex或Claude Code訂閱費，實際能用到價值1000多美元的服務。兩家公司都在用慷慨的用量限制把使用者往工作流裡引導，等人用習慣了，再按實際用量收費。從資料上看，OpenAI確實在縮小差距。2025年9月，Codex的使用量大約是Claude Code的5%。到2026年1月，這個比例上升到接近40%。Notion的聯合創始人西蒙·拉斯特（Simon Last）說，他和團隊在GPT-5.2發佈後從Claude Code切換到了Codex，主要原因是後者更穩定。“我發現Claude Code有時候會給出不精準的資訊，”他說，“它說自己正在處理任務，實際上並沒有進展。”在OpenAI負責Codex行為研究的凱蒂·施（Katy Shi）說，有些使用者覺得Codex的回應風格偏“干”，但越來越多人開始接受這種不刻意迎合的特點。“工程領域的工作，本來就需要能夠接受批評性反饋，不能因為表達方式直接就覺得被冒犯。”企業客戶也在逐步進入。OpenAI應用部門的CEO菲吉·西莫（Fidji Simo）稱：“ChatGPT已經成為AI領域的代表性產品，這在B2B市場是一個明顯優勢，多數企業傾向於使用員工已經熟悉的技術。”OpenAI銷售Codex的策略，主要是將其打包進ChatGPT的企業套件中一併提供。思科的總裁傑圖·帕特爾（Jeetu Patel）告訴員工，不用太在意使用Codex產生的費用，關鍵是要熟悉這個工具。有員工問他用了之後會不會失業，他的回答是：“不會，但不用一定會失業。不熟悉這些工具的人，慢慢會失去競爭力。”有開發者認為，OpenAI在B端市場的管道優勢正在發揮作用。不少公司已經採購了ChatGPT的企業版，在此基礎上增加一個Codex功能，決策成本並不高。也有分析指出，Codex最近的能力提升與GPT-5.2的推理能力最佳化直接相關。o系列模型採用的訓練方法，即讓模型在結果可驗證的程式設計任務中不斷試錯、獲得反饋，這對程式碼生成的質量有明顯幫助。程式設計本身就是一個反饋訊號明確的領域，程式碼要麼能運行要麼不能，這種特性對模型迭代很有利。05. 奧特曼的難題：既要速度，又怕失控AI程式設計智能體的影響已經不限於開發者社區。《華爾街日報》上個月將科技股1兆美元的拋售部分歸因於Claude Code，因為投資者擔心軟體本身的價值可能被壓縮。之後Anthropic宣佈，Claude Code可以對IBM那些運行COBOL語言的老系統進行現代化改造，IBM的股票遭遇了25年來最大單日跌幅。OpenAI也在加大投入。今年的超級碗廣告，他們投放的是Codex，而不是ChatGPT。在OpenAI總部，Codex的使用已經相當普遍。多位工程師提到，他們現在很少手寫程式碼，每天的工作主要是和Codex互動。一位參與了內部駭客馬拉松的工程師描述說，現場大約100人，用四小時時間通過Codex搭建一個可用的演示項目。不少項目既是用Codex開發的，目標也是為了讓工程師更好使用Codex。有的團隊做了個工具，把Slack消息自動彙總成周報，有的團隊用AI生成了一個內部服務的百科式指南。以前這些事情可能需要幾天才能完成，現在一個下午就能跑通流程。凱文·維爾（Kevin Weil）是前Instagram高管，目前負責OpenAI for Science部門，為研究人員開發AI產品。他說Codex現在會在夜間幫他處理一些項目，早上到公司檢查進度就行。這種做法已經成了他和幾百名同事的日常工作方式。OpenAI 2026年的目標之一是開發一個能夠自主進行AI研究的AI實習生。西莫表示，Codex最終會整合進ChatGPT和所有產品線，不僅是用來程式設計，而是協助處理各種任務。奧特曼說他想發佈一個通用版本的Codex，但對安全性還有些顧慮。1月底，他一個非技術背景的朋友請他幫忙安裝OpenClaw，但他沒有答應，認為“現在還不是時候”，那個智能體可能會誤刪重要檔案。但這件事過去幾周後，OpenAI就把OpenClaw的創作者招進了公司。不少開發者認為，Codex和Claude Code之間的差距確實在縮小，但也有機構對OpenAI的進度表示擔憂。一個叫Midas Project的非營利組織發佈報告稱，OpenAI在GPT-5.3-Codex上沒有完整披露網路安全風險，安全承諾的落實情況不夠透明。OpenAI的對齊負責人阿米莉亞·格拉澤（Amelia Glaese）否認為了推進Codex而犧牲安全，表示Midas對公司的承諾存在誤解。布羅克曼對AGI的進展保持樂觀，認為“項目正在按計畫推進”。但在不少矽谷工程師的印象裡，他一直是那種產品發佈前夜還在檢查程式碼庫細節的負責人。現在的狀況不太一樣了。布羅克曼面對的是幾十萬個AI智能體，在執行具體的任務和項目。他說這種新的工作方式“讓人感覺輕鬆了一些，因為以前確實需要記住很多細節”。但有時候，“你不太清楚那些事情具體是怎麼被解決的”。他說，這種變化會讓你“感覺對問題的感知不像以前那麼敏銳了”。 (騰訊科技)

這不是科幻片，而是 2026 年 2 月剛剛發生的現實。如果有人在 2020 年告訴你，「六年後，AI 會自己設計下一代 AI」，你大概會覺得這是天方夜譚。但就在上周，OpenAI 的 GPT-5.3-Codex 和 Anthropic 的 Claude Opus 4.6 同日發佈，兩家公司不約而同地宣佈了一個令人震驚的消息：這些 AI 模型，已經能夠有意義地參與改進自己。這只是 2026 年初，中國農曆馬年春節之前的「AI 春運」大戰的開始，但很有可能多年後重新回頭看，這可能是一個 AI 進化史上的重要節點——人工智慧，已經開始非常熟練地，設計和並建造下一代人工智慧了。更重要的是，這對使用者——人類——來說，到底意味著什麼？作者 Matt Shumer 在文章中為大家拆解了，為什麼現在，可能正是這樣一個節點時刻。01自我進化的「潘多拉魔盒」已開啟OpenAI CEO Sam Altman 在 Twitter 上興奮地表示：「我喜歡用這個模型建構；感覺比基準測試所示的進展更大。能以 5.3-Codex 來開發 5.3-Codex 的速度，這是未來的一個訊號。」這句話背後的含義讓人細思極恐。Anthropic CEO Dario Amodei 更是直接承認：「我們基本上已經讓 Claude 設計下一版本的 Claude 本身，不是完全地，也不是在所有方式上，但在很多方面，這個循環開始快速閉合。」或許，我們正在見證 AI 發展史上最重要的一個拐點：從人類設計 AI，到 AI 協助設計 AI，再到 AI 主導設計 AI。這個過程比任何人預想的都要快。但現實遠比宣傳複雜。Medium 分析師 Alex Carter 在 48 小時實測後潑了一盆冷水：Codex 5.3「感覺倉促。行銷承諾與現實不符。它聲稱『幫助自己建設』聽起來令人印象深刻，直到你意識到它無法可靠地建構登錄系統。」這種巨大的期望差距恰恰暴露了當前 AI 自我改進的真實狀態：概念已經突破，但實際能力仍在爬坡。02知識工作體系的重構更值得關注的是這背後的連鎖反應。如果 AI 真的能自我迭代最佳化，那麼依賴知識積累和經驗傳承的工作，將面臨根本性衝擊。這不是簡單的「AI 取代人類」，而是整個知識工作體系的重構。技術分析師 Sebastian Raschka 在《State of LLMs 2025》中指出，2026 年的進展「主要來自推理而非純粹的訓練方面」，進步出現在「架構調整、資料質量改進、推理訓練、推理擴展和工具呼叫」等多個維度。這意味，AI 不再是單純的工具，而是開始具備「思考如何更好地思考」的元認知能力。我們可以想像這樣的場景：一個法律 AI 不僅能處理案例，還能分析自己在處理過程中的不足，並設計改進方案；一個醫療診斷 AI 不僅能看病，還能反思自己的診斷邏輯，最佳化決策路徑。當 AI 開始擁有自我反思和改進的能力，人類在知識工作中的獨特優勢——經驗積累、模式識別、創新思維——還能保持多久？03掌控權還在人類手中... 嗎？但最讓人擔憂的不是就業問題，而是控制權問題。AI 安全研究者 Jared Kaplan 一針見血地指出：「當 AI 開始獨立設計下一代 AI 時，它使用的最佳化路徑可能完全超出人類認知範圍... 我們無法檢查是否有『特洛伊木馬』或錯位的目標函數隱藏其中。」這就是 AI 自我改進的核心悖論：我們需要足夠智能的 AI 來解決複雜問題，但當 AI 智能到可以改進自己時，我們可能就失去了理解和控制它的能力。HackerNews 和 Reddit 社區的討論也反映了這種擔憂。使用者們質疑基準測試結果，認為 GPT-5.3 和 Claude Opus 4.6 的性能資料，可能存在「不同的基準測試或資料解釋」問題。更重要的是，當 AI 能夠自我改進時，傳統的評估和監管體系都可能失效。Interconnects AI 分析師 Nathan Lambert 的觀察很有啟發性：「我們正在走向一個 AI 世界，其中與模型發佈相關的基準，不再對使用者傳達有意義的訊號。」換句話說，我們甚至可能無法精準衡量，這些自我改進的 AI 到底有多強。Fello AI 的分析報告顯示，2024 年近 90% 的著名 AI 模型來自工業界，OpenAI 不再主要與研究實驗室競爭，而是「與超大規模計算公司、晶片製造商和資金充足的 AI 優先公司競爭」。在這場競賽中，自我改進能力已經成為必爭之地。誰先實現真正的 AI 自我迭代，誰就能在未來五年的知識工作革命中佔據主導地位。就像 Matt Shumer 在文章開頭提到的 2020 年 2 月——如果你當時足夠敏銳，你會注意到「有幾個人在談論海外傳播的病毒（新冠）」。現在，我們也處在這樣一個歷史轉折點：AI 自我改進的種子已經種下，接下來的五年，整個知識工作的生態都將被重新定義。問題不再是「會不會發生」，而是「我們準備好了嗎」。 (極客公園)

多年來我一直是終端/Emacs 的忠實使用者，但自從使用 Codex 應用程式後，再回到終端就感覺像是回到了過去。這簡直是專為Agent打造的原生開發介面體驗這是OpenAI總裁Greg Brockman為剛剛推出的Codex App的彩虹屁，當然了好不好還要使用者說了算行業內的人應該有個基本共識，codex程式碼能力非常強，但是體驗比較差勁，基本上這一段時間讓Claude code 壓著打，終於OpenAI的反擊還是來了，還是搶在據傳Claude sonnet 5發佈前一天推出MagicPath CEO 說他最近幾周一直在使用 Codex 應用。  這已經成為在大型複雜程式碼庫中進行編碼的首選方法。  正因如此，他們才能在 MagicPath 中推出如此多的功能。  它完全取代了Cursor使用方式和 Claude Code這次OpenAI 推出的是macOS版Codex應用，這是一個全新的互動介面，旨在幫助開發者輕鬆管理多個AI Agents，支援平行運行任務，並與智能體協作處理長時間運行的複雜工作，通過skills擴展 Codex 的功能帶來的是旗艦級體驗。介面長這樣：一個好消息，在限定時間內，ChatGPT免費版和Go版使用者將能使用Codex。對於Plus、Pro、商業、企業和教育版使用者，速率限制將翻倍（這些更高的限制適用於所有使用Codex的場景——包括桌面應用、CLI、IDE以及雲端）OpenAI表示，Codex應用正在改變軟體的建構方式和建構者——從與單個編碼智能體配對進行有針對性的編輯，到在設計、建構、發佈和維護軟體的整個生命周期中，監督協同工作的智能體團隊。定位：Codex應用為Agent的指揮中心自2025年4月Codex發佈以來，開發者與智能體的工作方式發生了根本性變化。模型現在能夠端到端地處理複雜的長期任務，開發者則開始在項目中編排多個智能體：分配工作、平行運行任務，並信任智能體承擔可能跨越數小時、數天或數周的實質性項目。核心挑戰已從智能體能做什麼，轉變為人類如何大規模地指導、監督和與它們協作。現有的IDE和基於終端的工具並非為支援這種工作方式而建構。這種新的建構方式與新的模型能力需要一種不同的工具，因此OpenAI推出了Codex桌面應用，一個專為智能體打造的指揮中心1. 與多個智能體平行工作Codex應用提供了一個專注於與智能體進行多工處理的空間。智能體在按項目組織的獨立線程中運行，因此使用者可以在任務之間無縫切換而不會丟失上下文。使用者可以線上程中審查智能體的更改、對差異（diff）發表評論，甚至在編輯器中打開它進行手動修改。它還內建了對worktrees的支援，因此多個智能體可以在同一個程式碼倉庫上工作而不會產生衝突。每個智能體都在程式碼的隔離副本上工作，允許使用者探索不同的實現路徑，而無需追蹤它們對本地程式碼庫的影響。在智能體工作時，使用者可以在本地檢出（check out）其更改，或者讓它在不觸動本地git狀態的情況下繼續推進。該應用會自動同步使用者在Codex CLI和IDE擴展中的會話歷史和配置，因此使用者可以立即在現有項目上開始使用。2. 通過Skills超越程式碼生成Codex正在從一個編寫程式碼的智能體，演變為一個使用程式碼在電腦上完成工作的智能體。通過技能（skills），使用者可以輕鬆地將Codex的能力從程式碼生成擴展到需要收集和綜合資訊、解決問題、寫作等更多工。skill捆綁了指令、資源和指令碼，使Codex能夠可靠地連接到工具、運行工作流，並根據團隊的偏好完成任務。Codex應用包含一個專門用於建立和管理技能的介面。使用者可以明確要求Codex使用特定技能，或者讓它根據當前任務自動使用為了展示其能力，OpenAI讓Codex製作了一款賽車遊戲，一句話消耗700萬Token，從零手搓3D賽車遊戲！要求包含不同的賽車手、八張地圖，甚至還有玩家可以用空格鍵使用的道具，Codex利用一個圖像生成技能（由GPT Image驅動）和一個網頁遊戲開發技能，僅憑一個初始使用者提示，便獨立工作並消耗了超過700萬個token來建構這款遊戲。在此過程中，它扮演了設計師、遊戲開發者和QA測試員的角色，通過實際玩遊戲來驗證自己的工作以下是用於建立遊戲的、為清晰起見經過總結的初始提示：> 將Voxel Velocity實現為一款使用Three.js的3D體素卡丁車賽車遊戲，只設定一種模式：單人賽（固定3圈，1名人類玩家對7名CPU，所有8條賽道立即解鎖，無進度系統）。建構一個最簡化的賽前流程，僅包含：賽道（8個）、角色（8個）、難度（休閒/標準/困難）、可選的鏡像模式、可選的允許克隆角色，以及開始比賽按鈕。另外需要一個選項菜單和一個賽內暫停菜單（繼續/重新開始/退出）。> 建立一個街機風格的駕駛模型，具有響應靈敏的操控、對輕微撞牆的容錯、以有意義的漂移為主要技巧，以及一個能產生精確增壓等級的漂移充能系統（1級0.7秒，2級1.1秒，3級1.5秒），同時保持基礎速度“快但可讀”，並在寬闊的道路上保持持續的超車機會。> 實現8種道具，單道具容量，具有微妙的位置加權分佈和溫和的效果（最大失控時間≤1.2秒，最大轉向停用≤0.6秒），旨在創造有趣的混亂而非硬控。越野減速效果在增壓期間減少50%。> 定義8個角色的給定屬性和AI傾向，實現CPU難度預設和賽道編寫的賽車/變化樣條線、漂移區和障礙規避，以便AI能利用多車道寬度進行乾淨的超車。> 最後，交付HUD/音訊等基本要素（位置、圈數/最後一圈橫幅、小地圖、道具槽、計時器/分段時間、清晰的音效，以及每條賽道一個音樂循環）。隨後，Codex被從一個包含十個通用提示的列表中隨機抽取提示，進行持續的重新提示，以使其繼續解決問題。其中一個示例提示是：> 你的工作是加入新功能，使遊戲更接近原始設計。首先，玩遊戲並確定與原始設計相比缺少了什麼。然後選擇幾個缺失的功能並實現它們。每實現一個功能後，通過玩遊戲進行徹底測試，確認它能正常工作。如果在玩的過程中發現任何錯誤，也要優先修復它們。在OpenAI內部，團隊已經建構了數百個技能，幫助多個團隊將那些原本難以一致定義的工作放心地委託給Codex——從運行評估、監控訓練過程，到起草文件和報告增長實驗。Codex應用包含了一個技能庫，涵蓋了在OpenAI內部流行的工具和工作流，部分重點skill如下：實現設計：從Figma獲取設計上下文、資產和截圖，並將其轉化為具有1:1視覺保真度的生產級UI程式碼管理項目：在Linear中分類錯誤、跟蹤發佈、管理團隊工作量等，以保持項目推進部署到雲端：讓Codex將你建立的Web應用部署到Cloudflare、Netlify、Render和Vercel等流行的雲託管服務商生成圖像：使用由GPT Image驅動的圖像生成技能，建立和編輯用於網站、UI模型、產品視覺和遊戲資產的圖像使用OpenAI API建構：在建構時參考最新的OpenAI API文件建立文件：一套用於讀取、建立和編輯具有專業格式和佈局的PDF、電子表格和docx檔案的技能。當使用者在應用中建立一個新skill時，該技能可以在任何工作環境中使用：應用內、CLI或IDE擴展中。使用者還可以將技能檢入程式碼倉庫，使其對整個團隊可用。3. 通過自動化委託重複性工作借助Codex應用，使用者還可以設定自動化（Automations），讓Codex按照自動計畫在後台工作。自動化將指令與可選技能相結合，並按使用者定義的時間表運行。當自動化完成時，結果會進入一個審查佇列，以便使用者在需要時可以返回並繼續工作。在OpenAI內部，自動化已被用於處理重複但重要的任務，例如每日問題分類、尋找和總結CI失敗、生成每日發佈簡報、檢查錯誤等。4. 適配個人工作風格的個性開發者在與智能體協作時有不同的偏好。一些人想要一個直截了當、注重執行的夥伴；另一些人則更喜歡溝通性強、更具互動性的交流。Codex現在允許開發者在兩種個性之間進行選擇——一種是簡潔務實的風格，另一種是更健談、更具共情力的風格，兩者在能力上沒有差異。使用者只需在應用、CLI和IDE擴展中使用 /personality 命令即可切換。請參閱文件，瞭解更多關於如何設定和使用 Codex 應用的資訊https://developers.openai.com/codex/app默認安全，可配置設計OpenAI正在整個Codex智能體技術堆疊中整合設計即安全的理念。Codex應用使用與Codex CLI中相同的原生、開源且可配置的系統級沙盒。默認情況下，Codex智能體僅限於編輯其工作所在資料夾或分支中的檔案，並使用快取的Web搜尋。當需要運行網路訪問等需要提升權限的命令時，它會請求許可。使用者可以為項目或團隊配置規則，允許某些命令自動以提升的權限運行。下一步計畫企業和開發者越來越依賴Codex進行端到端開發。自去年12月中旬GPT-5.2-Codex推出以來，Codex的總體使用量翻了一番，在過去一個月裡，有超過一百萬名開發者使用了Codex。OpenAI表示將繼續擴展開發者可以使用Codex的場景和方式，包括在Windows上推出該應用、推動模型能力的前沿，並推出更快的推理速度。在應用內部，團隊將根據真實世界反饋繼續完善多智能體工作流，使其更容易管理平行工作並在智能體之間切換而不丟失上下文。同時，他們也在建構支援基於雲的觸發器的自動化功能，這樣Codex就可以在後台持續運行，而不僅僅是在電腦開著的時候。Codex建立在一個簡單的前提上：一切都由程式碼控制。一個智能體在推理和生成程式碼方面越出色，它在所有形式的技術和知識工作中就越有能力。然而，當今的一個關鍵挑戰是，前沿模型的能力與人們在實踐中輕鬆使用它們之間的差距。Codex旨在通過簡化指導、監督和將模型全部智能應用於實際工作的方式來縮小這一差距。OpenAI表示，他們專注於使Codex成為最好的編碼智能體，這也為它成為一個能夠處理超出編寫程式碼範圍的廣泛知識工作任務的強大智能體奠定了基礎。 (AI寒武紀)

太帶勁了！搶先Claude 5，OpenAI深夜祭出了一個編碼殺器——Codex。它可以讓一人指揮多Agent平行協作，自帶Skills，編碼從此進入自動化時代。Claude 5的腳步聲越來越近，奧特曼終於坐不住了。就在剛剛，OpenAI毫無預警地拋出「王炸」——Codex正式進化為獨立的桌面App。這不僅僅是一個寫程式碼的窗口，更是一個能同時指揮千軍萬馬（多個Agent）的「全能指揮部」。Codex定位非常明確：要做Agent的「指揮中心」具體來說，Codex可以做到以下幾點：多工平行切換，毫不費力：同時呼叫多個AI智能體開展工作，並通過「工作樹」（worktrees）實現變更隔離，互不干擾；建立並呼叫Skills：將工具和開發規範封裝成可復用的能力；設定自動化流程：通過後台定時工作流，把那些重複性的瑣事統統交給Codex處理。假設想要為相簿裡的照片加入「拖曳」功能，選擇「工作樹」，即可讓AI在同一倉庫中各司其職。Codex的進化令人毛骨悚然，它不僅生成程式碼，還學會了利用程式碼作為「Skills」來操控電腦。比如想要解決項目中的Comment，直接呼叫安裝好的Skills，Codex立刻就把問題破解了。不僅如此，OpenAI僅憑一句話，就讓Codex消耗700萬 token，徒手搓出一個3D版賽車遊戲。這一次，Codex的誕生，並非是新瓶裝舊酒，更不是一次毫無誠意的「套殼」包裝。它標誌著AI程式設計正式從「對話助手」進化為「指揮中心」。奧特曼激動表示，「真是愛了愛了，它比我想像中還要驚喜」！「AI程式設計師就是不會耗盡多巴胺。他們不會感到沮喪，也不會耗盡能量。它們會一直堅持下去，直到解決問題」。OpenAI總裁Greg牆裂推薦——我多年來一直是終端和Emacs的鐵粉，但自從用了Codex之後，再回到終端簡直感覺像穿越回了過去，代差太明顯了。這種感覺，就像是一個專門為開發而生的AI智能體原生介面。OpenAI Codex代表著一種全新的AI Coding範式，極有可能重塑開發者與程式碼互動的邏輯。甚至，Codex還可與Claude Cowork狂飆能力，把雜亂桌面瞬間清理乾淨。目前，Codex正式在macOS上線，Windows版即將推出。OpenAI還放出了「限時福利」，ChatGPT免費使用者和Go版本也可用上Codex，Plus、Pro、Business、Enterprise和Edu計畫的使用者，速率直接翻倍。編碼殺器Codex APP震撼登場一人指揮所有AgentmacOS版Codex應用，是一個功能強大的新介面。它能讓開發者能輕鬆駕馭多個AI智能體，平行處理任務，並與AI協作搞定那些耗時的大活兒。過去一直以來，開發者和AI的關係是「結對程式設計」，你寫一段，它接一段。如今，Codex的出世將徹底改變軟體建構的方式——人類不再與AI緊密結對，直接給AI委派任務，貫穿於軟體設計、建構、發佈和維護的全生命周期。這一轉變的苗頭，實際上從2025年4月發佈Codex以來，便已初見端倪。開發者與AI的協作方式已發生了根本性轉變。現有模型可以端到端地處理複雜的、長流程的任務，開發者也開始在跨項目中指揮多個AI智能體：分派工作、平行跑任務，並放心地把耗時數小時、數天甚至數周的重大項目交給 AI 。核心挑戰已不再是AI能做什麼，而是人們如何大規模地指揮、監督並與它們協作——遺憾的是，現有的IDE和終端工具並非為此而生。這種全新的建構方式，加上模型能力的提升，呼喚著一種全新的互動載體。這正是OpenAI要推出Codex桌面應用的原因，主打「一個AI智能體的指揮中心」。多智能體平行，狂飆程式碼不亂套Codex為與AI智能體多工平行，建構了一個專注的空間。所有AI在按項目組織的獨立線程中運行，確保你無縫地在任務間切換，而不會丟失上下文。你可以在應用裡直接檢查AI的改動，在diff上寫評論，甚至用編輯器打開進行手動調整。它還內建了對Git worktree的支援，所以多個AI可以在同一個倉庫（repo）上開工而互不衝突。每個AI都在你程式碼的隔離副本上工作，讓你能探索不同的開發路徑，而無需操心它們會如何影響你的主程式碼庫。當AI智能體幹活時，可以把改動拉（checkout）到本地，或者讓它繼續推進，完全不動本地的git狀態。應用會自動從Codex CLI和IDE擴展中同步會話歷史和配置，這樣你馬上就能在現有項目中用起來。解鎖Skills外掛，手搓3D賽車遊戲Codex正從一個只會寫程式碼的AI，進化為一個能用程式碼在電腦上真正解決問題的AI。通過Skills（技能），可以輕鬆擴展Codex的能力。今後，Codex不再侷限於程式碼生成，還能處理資訊收集與整合、問題解決、寫作等任務。Skills就像是打包好的指令、資源和指令碼，讓Codex能可靠地連接工具、運行工作流，並按照團隊的習慣完成任務。Codex應用裡有一個專門的介面來建立和管理Skills。你可以明確要求Codex使用某個Skill，或者讓它根據手頭的任務自動呼叫。OpenAI舉了一個例子，曾讓Codex做一個賽車遊戲——要有不同的車手、八張地圖，甚至還有玩家能用空格鍵觸發的道具。利用圖像生成 Skill（由GPT Image驅動）和網頁遊戲開發Skill，Codex僅憑最初的一個使用者提示詞，就獨立工作並消耗了超過700萬個Token，把遊戲做了出來。它身兼數職，既是設計師、遊戲開發者，又是QA測試員，通過實際試玩來驗證成果。6萬Token可以看到，在只消耗了6萬token的這個版本裡，畫面非常粗糙。很窄的賽道中間，塞滿了撞上去會穿模的「障礙物」。技能箱可以吃，也可以發射，但好像沒有什麼效果。最尷尬的是，你會永遠在「第二圈」無限循環下去……80萬Token在80萬token的版本裡，畫面似乎好了一些，賽道也寬敞了不少，更接近大家平時玩的賽車遊戲了。但是箱子吃到的技能好像沒什麼用，發射出去之後，小車們還是各跑各的……而且依舊會在第二圈陷入循環，永遠跑不完。700萬Token最後這個700萬token的版本，畫質明顯好了很多。不僅有清晰的賽道，技能箱也更精緻了。這次，技能箱確實有用了。比賽剛開始，我們就吃了AI扔出的一個大招，沒有閃。於是，喜提倒數第一，不過，比起前兩個陷入無限循環的世界來說，這次至少能完賽了。從跑評測和盯著模型訓練，到起草文件和匯報增長實驗，OpenAI內部建構了數百個Skills，來幫助多個團隊自信地把以前很難統一定義的工作委派給Codex。Codex應用內建了一個Skills庫，涵蓋了OpenAI內部流行的工具和工作流，下面重點介紹幾個。實現設計：從Figma拉取設計上下文、資源和截圖，並將其轉化為視覺上1:1還原的生產級UI程式碼。管理項目：在Linear中處理Bug分類、追蹤發佈、管理團隊工作負載等，推動項目進展。部署到雲端：讓Codex把你做好的Web應用部署到流行的雲主機，如Cloudflare、Netlify、Render和Vercel。生成圖像：使用由GPT Image驅動的圖像生成Skill來建立和編輯圖像，用於網站、UI原型、產品配圖和遊戲素材。使用OpenAI API建構：在使用OpenAI API開發時，參考最新的文件。建立文件：一套用於閱讀、建立和編輯PDF、電子表格和檔案的Skills，排版佈局專業。使用Vercel和圖像生成Skills更新網站使用電子表格Skill建立表格以生成購物清單使用Linear管理你的Issue Backlog當你在應用中建立一個新Skill時，Codex可以在你工作的任何地方使用它：應用內、CLI或IDE擴展中。你也可以把Skills提交到程式碼倉庫，讓整個團隊都能用上。OpenAI分享的Agent Skills：https://github.com/openai/skills一鍵自動化，24h為你打工Codex可以設定Automations（自動化），按計畫在後台自動幹活。Automations將指令與可選的Skills結合，會按照你設定的時間表運行。當Automation完成時，結果會進入審查佇列，可以隨時切回來查看並根據需要繼續後續工作。設定自動化以定期建立新Skills在OpenAI，團隊一直用Automations來處理那些重複但重要的任務，比如每日Issue分類、尋找和總結CI失敗原因、生成每日發佈簡報、檢查Bug等等。雙人格模式，秒切換開發者在與AI合作時口味各不相同。有人喜歡直截了當、只講執行的搭檔；有人則喜歡話多一點、更有互動感的風格。Codex現在允許開發者在兩種個性間選擇——一種是簡潔務實風，另一種是更具對話感和同理心的風格。兩者的能力完全一樣，只為貼合你的喜好。只需在應用、CLI和IDE擴展中輸入/personality命令即可切換。默認安全，按需配置此外，OpenAI還將「設計即安全」（Security by Design）的理念融入了Codex AI智能體棧的方方面面。Codex 應用採用了原生的、開源且可配置的系統級沙箱（Sandboxing），這就跟在Codex CLI裡一樣。默認情況下，Codex AI 智能體只能編輯它當前工作的資料夾或分支裡的檔案，並使用快取的網頁搜尋。如果需要運行像聯網訪問這類需要更高權限的命令，它會先請求你的許可。你可以為項目或團隊配置規則，允許特定命令自動以提升的權限運行。一切皆由程式碼控制如今，企業和開發者正越來越依賴Codex進行端到端開發。自12月中旬發佈GPT-5.2-Codex以來，Codex的總使用量翻了一番，過去一個月裡有超過100萬開發者使用Codex。下一步，團隊繼續擴展Codex使用場景，包括上線Windows版應用、不斷突破模型能力邊界，以及實現更快的推理速度。OpenAI科學家感慨，過去幾周寫的程式碼比過去幾年還要多。而且，還用Codex修復了Prism多個bug和功能更新在應用內部，OpenAI還將根據實際反饋持續打磨多AI智能體工作流，讓管理平行任務和在AI間切換變得更容易，且不丟失上下文。他們還在為Automations開發基於雲端的觸發器支援，這樣Codex就能在後台持續運行——而不僅僅是在你電腦開著的時候。Codex建立在一個簡單的前提之上：一切皆由程式碼控制。一個AI智能體在推理和生成程式碼方面越強，它在各類技術和知識工作中的能力就越強。OpenAI全家桶然而，當今的一個關鍵挑戰在於，前沿模型的能力與人們在實際中輕鬆使用它們之間存在差距。Codex旨在縮小這一差距，讓人們更容易指揮、監督並將OpenAI模型的全部智慧應用到實際工作中。OpenAI致力於將Codex打造成最強的程式設計AI智能體，這也為它成為能處理程式碼之外廣泛知識工作的全能AI奠定了基礎。附錄在製作上面這款賽車遊戲時，Codex使用的初始提示詞如下（總結精煉版）：使用Three.js實現Voxel Velocity作為一個3D體素卡丁車賽車遊戲，只有一種模式：單人比賽（總是3圈，1個人類對7個CPU，所有8條賽道立即在這個模式下可用，沒有進度限制）。建構一個最小的賽前流程，僅包括：賽道（8），角色（8），難度（輕鬆/標準/刻薄），可選的鏡像模式，可選的允許克隆，和開始比賽，加上一個選項菜單和一個賽中暫停菜單（恢復/重新開始/退出）。建立一個街機駕駛模型，具有靈敏的操控，寬容的擦牆碰撞，有意義的漂移作為主要技能，以及一個漂移充電系統，產生精確的加速等級（1級0.7秒，2級1.1秒，3級1.5秒），同時保持基準速度「快但可讀」，並且在寬闊的道路上保持持續的超車。實現正好8個道具，單道具容量，微妙的位置加權分佈，和溫和的效果（最大失控≤1.2秒，最大轉向停用≤0.6秒），創造滑稽的混亂而沒有硬眩暈，加上在加速期間減少50%的越野減速。定義8個角色及其給定的統計資料和AI傾向，實現CPU難度預設和賽道編寫的賽車/變化樣條線，漂移區和危險迴避，以便AI使用多車道寬度進行乾淨的超車，並行布HUD/音訊要素（位置，圈數/最後一圈橫幅，小地圖，道具槽，計時器/分段，可讀的音效，和每個賽道一個音樂循環）。隨後，Codex不斷地被從10個通用提示詞的隨機列表中重新提示，以繼續處理這個問題。其中一個提示詞的例子是：你的工作是加入新功能，使遊戲更接近原作。首先，玩遊戲並確定與原作相比缺少了什麼。然後挑選幾個缺失的功能並實現它們。在每個功能之後，徹底測試它，通過玩遊戲並確認它工作正常。如果你在玩的時候注意到任何錯誤，也要優先修復它們。 (新智元)

【新智元導讀】100%是用Codex寫的。還有內部爆料說，Codex讓他們僅用三天時間就搭出了伺服器，三周就發佈了APP。人類程式設計師，真的要退出歷史舞台了？矽谷的空氣裡再次充滿了躁動，而這一次的震源中心，回到了OpenAI。OpenAI的奇點時刻，也要來了？就在剛剛，X被一條爆料徹底刷屏——Codex，已經正式接管了OpenAI研究員「Roon」100%的程式碼編寫工作！Roon發出了感慨萬千的宣告：程式設計一直很痛苦，然而卻是必經之路。我很高興，它終於結束了。我驚訝於自己竟然這麼快就擺脫了程式設計的陰影，而且一點都不懷念它。甚至我有點遺憾，從前的電腦為什麼不是這樣的。早在去年12月，Claude Code之父Boris Cherny就曾投下一枚震撼彈——自己對Claude Code的貢獻100%都是由Claude Code完成的。這一「套娃式」的自我進化，直接引爆了矽谷的自動編碼狂潮。面對如此巨大的蛋糕，OpenAI顯然不會拱手相讓。如今，反擊已經開始。在剛剛過去的周末，Sam Altman已經公開預告：接下來一個月會發佈一堆關於Codex編碼模型的新產品。社區的風向也開始發生微妙的轉變。一些資深開發者評論道：在90%的情況下，GPT-5.2-Codex都能一次性完成我提出的請求。Claude雖然不錯，但它偶爾會偷偷插入「壞程式碼」；相比之下，OpenAI的新方案更像蘋果——主打一個開箱即用。看來，Codex和Claude Code的大戰，已經一觸即發！人類寫程式碼的時代，徹底結束？OpenAI研究員Roon的這個爆料，也讓網友們直言：AI終於到達了這個奇點！看來，人類直接手寫程式碼的時代，真的結束了。經過多年的模型迭代與資料積累，我們似乎真的站在了一個臨界點上：人類直接手寫程式碼，正在變得不再有任何意義，甚至是一種效率的浪費。在Roon的評論區，人們開始集體對程式設計時代說再見。是的，我熱愛電腦，熱愛軟體開發，對我而言，程式設計只是實現目標的手段，僅此而已。複雜的語法只是是我們為了讓邏輯得以執行而必須付出的昂貴代價。如今，這些中間商終於可以退場了。激進的觀點開始湧現。甚至有人建議，既然不需要人類閱讀程式碼了，我們就該讓模型跳過人類可讀的彙編語言，直接使用機器程式碼。今天的程式設計就像曾經的打孔卡一樣，應該永遠消失了。與此同時，另一個炸裂的消息從OpenAI內部流出——一位研究員爆料，在Codex的輔助下，他們僅用了三天時間，就從零搭建了OpenAI的MCP伺服器，並完成了規模驗證。不僅如此，他們還在3周內推出了Sora的Android應用；此外，還有一大波由Codex建構、甚至由Codex自我稽核的內部工具正在排隊上線。如果沒有Codex的話，很難想像OpenAI能以如此驚人的速度發佈產品。有趣的是，這位大佬似乎還玩起了Claude Code之父的梗：過去30天，我花了大量時間稽核Plan和PR，幾乎沒寫一行程式碼！有人評價，這正是「起飛」第一階段的樣子。而下一步，或許就是真正的端到端AI自主研究。還有人問，確定你們這不是行銷？這位研究者詳細解釋說，絕對不是。具體的使用過程是這樣的：首先，他會花很多時間來撰寫規格說明，並在腦海中構想輸出應該是什麼樣子。然後，會啟動一個「4×Codex」的雲端並行任務。這樣不僅可以一次性看到多種不同的變體，也能補上自己一開始遺漏的細節。接下來，就是讓Codex自己發揮。等它跑完，人類再介入進行測試和驗證。Codex CLI 0.9+來了！既然「人機協作」的範式已經改變，那麼承載這種範式的工具自然也要升級。面對Anthropic在的步步緊逼，OpenAI顯然有備而來。就在今天，Codex CLI連續推送了兩次更新，版本號直接來到了0.91.0。其中，Codex 0.9.0帶來了最受大家期待的功能——Plan Mode（計畫模式）！Code模式是Codex的默認體驗，它的工作方式和其他AI智能體一樣。這點咱們就不多費口舌了。但Plan模式則完全不同，它將程式設計任務拆解為兩個截然不同的階段：第一階段：理解意圖（明確目標、劃定範圍、識別約束條件、制定驗收標準）第二階段：技術規格（生成決策完備的實施方案）在這種模式下，輸出的內容非常詳盡，無需任何後續追問即可直接執行。Plan模式最聰明的地方在於：它堅持「證據優先探索」。在開口問問題之前，Codex會先在你的程式碼庫中進行2次以上的針對性搜尋，檢查配置、Schema結構、程序入口等。此外，Plan模式還可以呼叫全套工具：它可以（並且將會）呼叫各種技能、子智能體和後台終端，從而建構高層級的實施計畫。當Codex確實需要你輸入時，它是結構化的，而且只有關鍵且聚焦的問題：· 儘可能提供選項· 總是包含一個推薦選項（對新手極其友好）· 只問那些會實質性改變計畫的問題為了實現這一互動，它利用了新的request_user_input工具。這個工具會暫停執行流程，拋出一道有針對性的多項選擇題，並支援你在選擇時補充反饋或上下文。更貼心的是，一旦它在任何時候檢測到歧義，尤其是當你在引導它時指令模糊，它會立即停下來確認，而不是盲目執行。現在，開發流程變成了這樣：使用者請求一個計畫 -> AI研究程式碼庫與規劃 -> 針對性詢問使用者 -> AI完善並完成計畫 -> 提示是否執行？但是，程式碼誰來審？看起來完美無缺，對吧？Codex負責思考，Codex負責執行，Codex負責填滿你的GitHub。但就在我們為這種極致的效率歡呼時，一個被忽視的深淵正在腳下裂開——在這個新時代，最大的懸念不再是誰在寫程式碼，而是誰來稽核程式碼。當AI火力全開，每天向倉庫甩出10+個PR時，人類開發者面臨的實際上是一場針對注意力的DDoS攻擊。AI生成程式碼是毫秒級的，而人類理解程式碼上下文是分鐘級甚至小時級的。這種「生產與審查的極度不對稱」帶來了兩個可怕的後果：審查者被淹沒，開始習慣性點「Approve」，Code Review淪為形式。那些看起來能跑、但缺乏系統性思考的程式碼塊，正在像癌細胞一樣在程式碼庫中擴散。利益衝突顯而易見，但我們需要看透這一層。Claude Code的創造者吹捧自己的工具天經地義——這是商業的本能。但作為受眾，我們不能把「Demo裡的完美世界」當成日常。畢竟，Demo不會展示偵錯三小時都找不到的競態條件，也不會展示由於上下文丟失導致的邏輯斷層。除此之外，資料裡還藏著一個迷人的悖論。Ars Technica曾報導稱，開發者對AI工具的使用量在漲，信任度卻在跌。為什麼？因為AI正在跨越「恐怖谷」。以前的AI程式碼爛得很明顯，現在的AI程式碼爛得很隱蔽——它引用了不存在的庫，或者在一個極其邊緣的Case上埋了雷。人們用得越多，踩的坑越多，信得自然越少。正如Jaana Dogan所警示的，我們正在面臨軟體工程「瑣碎化」的風險。100個提交，可能讓GitHub的綠格子很好看。1個架構變更，可能需要三天思考，零行程式碼產出。前者廉價如塵土，後者珍貴如黃金。問題從來不是AI能不能寫程式碼，而是它寫的程式碼，是不是我們系統真正需要的，以及我們是否有能力維護它。這對我們意味著什麼？無論我們是否準備好，這個時代已經來了。對於不同的人群，這意味著完全不同的生存法則。致開發者AI編碼工具不是「即將來臨」，它們已經破門而入。問題在於，如何在不丟失自身核心價值的前提下整合它們。技術大牛們依然在做那些艱難的思考工作，AI只是接過了「打字員」的工作。如果你只會「搬運程式碼」，那你確實該慌了。致非開發者「技術工作」與「非技術工作」的邊界正在消融。Claude Cowork這類工具創造了新物種。曾經需要開發者才能搞定的任務，可能很快只需要你能清晰描述出你想要什麼。清晰描述需求的能力，將成為新的程式語言。最後的話雖然OpenAI的研究員和Claude Code的創造者都在宣稱AI包辦了100%的程式碼，但請記住——那是他們的實驗室環境，不是你的生產環境。唯一可以確定的是，我們正在經歷從「寫程式碼」到「指揮寫程式碼」的不可逆的轉變。而且，正在加速。 (新智元)