ChatGPT 同 Codex 傳整合:OpenAI 想將 AI 工作流收歸一個入口
Tech News

ChatGPT 同 Codex 傳整合:OpenAI 想將 AI 工作流收歸一個入口

圖片:via TechCrunch — https://techcrunch.com/2026/05/16/openai-co-founder-greg-brockman-reportedly-takes-charge-of-product-strategy/
TechLab 編輯部(譯)·

對開發者同 IT team,重點唔係人事,而係 coding agent 會點變成工作平台

OpenAI 最近一輪產品重組,表面上係 Greg Brockman 由共同創辦人兼總裁,再正式接手產品策略;真正值得留意嘅,其實係背後嗰句:ChatGPT 同 Codex 可能會合併成一個統一體驗。呢個唔係單純將兩個 app 擺埋一齊,而係 OpenAI 想將對話、寫 code、debug、操作網頁、處理企業流程,逐步收斂到一個 agent 平台入面。對開發者、startup、公司 IT team 嚟講,未來用 AI 唔再只係「問一句、貼一段 code」,而係將一件任務交畀系統,由佢讀 repo、跑測試、開 PR、甚至喺瀏覽器或 desktop app 入面完成部分流程。

不過,呢件事仍然要分清楚「報道」同「已推出功能」。TechCrunch 引述 WIRED 報道,話 Brockman 正式負責 OpenAI 產品策略,並喺員工備忘錄入面提到會將 ChatGPT 同 Codex 合併成單一統一體驗。OpenAI 官方暫時未就「ChatGPT + Codex 統一產品」發布完整功能清單、推出日期、香港價錢或港區支援細節,所以而家最穩陣嘅寫法,係將佢視為產品方向同組織重整訊號,而唔係即時可以落手測試嘅新版 ChatGPT。

唔只係換人,而係產品線重新排陣

據 WIRED 報道,OpenAI 係向員工宣布重組,Brockman 會喺 AI infrastructure 工作之外,同時掌管產品策略;佢之前已經因為 AGI deployment CEO Fidji Simo 放病假而臨時負責產品,今次就變成正式安排。報道亦指 OpenAI 會將 ChatGPT、AI coding agent Codex、同面向開發者嘅 API 收入同一個核心產品團隊。呢個細節比人事更重要,因為 API、consumer app、coding agent 以前可以係三條唔同產品線;而家如果放入同一個 product brain,OpenAI 就有條件將「模型能力」變成跨場景工作流。

TechCrunch 原文亦提到,呢次重組延續 OpenAI 過去半年嘅取向:Sam Altman 早前曾經要求公司重新聚焦核心 ChatGPT 體驗,之後 OpenAI 減少部分 side project,並多次暗示自己想做 AI super app。換句話講,Codex 未必只係畀工程師用嘅工具;OpenAI 可能想將 Codex 嘅 repo 理解、長任務執行、code review、PR workflow,變成 ChatGPT 入面可調用嘅一組能力。當 ChatGPT 可以同檔案、瀏覽器、企業 app、GitHub repo、API workflow 接上,Codex 就唔只係「寫 code」,而係 agent 執行層。

呢種整合如果成事,最大改變係使用者入口會變少。今日一個開發團隊可能同時用 ChatGPT 做規格草稿,用 Codex CLI 改 repo,用 IDE extension 解釋錯誤,用 GitHub agent 開 PR,再用另一套工具做瀏覽器自動化。統一體驗嘅意思,可能係同一段上下文可以由對話延伸去 coding task,再由 coding task 變成 PR、測試記錄、部署前檢查,甚至回到 ChatGPT 入面做決策摘要。呢個對細 team 特別有吸引力,因為佢哋通常冇資源砌一整套內部 AI platform,但又想將 AI 用喺日常工程流程。

Codex 已經唔係舊日嘅 autocomplete

OpenAI 官方開發者文件而家將 Codex 定義為軟件開發用嘅 coding agent,功能包括寫 code、理解陌生 codebase、做 code review、debug、以及自動化 refactor、測試、migration、setup 呢類重複工序。Quickstart 亦顯示 Codex 可以用桌面 app、IDE extension、CLI 同 cloud 版本;桌面 app 支援 macOS 同 Windows,CLI 支援 macOS、Windows、Linux,cloud 入口係 chatgpt.com/codex,仲可以喺 GitHub PR comment 標記 @codex 去委派任務。呢啲已經同傳統「AI 幫你補幾行 code」有好大距離。

更關鍵係身份同計費入口。OpenAI 文件寫明 Codex 可以用 ChatGPT account 登入,亦可以用 OpenAI API key;但用 API key 時,部分 cloud threads 等功能可能不可用。Pricing 文件又顯示 Codex 被放入 ChatGPT Free、Go、Plus、Pro、Business、Edu、Enterprise 等方案框架之內,並用 usage limits 或 credits 管理用量。即係 OpenAI 已經喺產品層面將 Codex 由「開發工具」推近「ChatGPT 方案內嘅 agent 能力」,而今次報道所講嘅合併,只係將呢個方向再推前一步。

對香港 startup 或 IT team,呢度有兩個實際 implication。第一,AI coding agent 嘅採購可能會由「買 IDE plugin」變成「買一套 AI 工作平台」,因為同一個供應商可以提供聊天、coding、agent task、API、自動化、企業管理、審計等功能。第二,內部 governance 會變得更重要:邊啲 repo 可以畀 agent 睇、agent 可唔可以跑 shell command、可唔可以連 GitHub、可唔可以自動開 PR、敏感資料會唔會被放入 prompt 或 logs,呢啲都唔係工程師個人效率問題,而係公司 IT policy 問題。

Agent 會由「答問題」走向「做工」

OpenAI 官方 Computer use 文件提供咗另一個線索:模型可以透過截圖理解介面,回傳 click、type、scroll、keypress 等動作,再由開發者嘅 harness 喺瀏覽器或 VM 執行。文件亦反覆提醒要用 isolated browser 或 VM、保持 human in the loop、將網頁內容視為不可信輸入。呢啲唔係直接等於 ChatGPT + Codex 合併功能,但反映 OpenAI 正在將模型定位成可以操作軟件介面嘅 agent,而唔只係輸出文字。

如果將 Codex、Computer use、Agents SDK、ChatGPT 對話入口放埋一齊,未來工作流可能係:產品經理用自然語言描述 bug,ChatGPT 先問幾條澄清問題,再叫 Codex 開 cloud task 讀 repo;Codex 改完 code、跑測試、生成 diff;如果要驗證前端流程,agent 透過 browser harness 開測試站、截圖、點擊、回報錯誤;最後再由人手審 PR 同決定 merge。呢套流程聽落好進取,但每一塊積木其實都已經喺不同 OpenAI 文件或產品入面出現,只係未必已經整合成一個普通用家可用嘅完成品。

呢度要加一個冷水位:agent 做得越多,錯誤成本亦越高。寫錯一段 demo code 同改錯 production repo 係兩回事;自動填 form 同自動提交付款、改權限、發電郵,更加係另一個風險級別。OpenAI 自己嘅 Computer use 文件都要求高影響動作保留人手確認,呢點對公司採用尤其重要。AI agent 最合理嘅位置,唔係無限放權,而係將重複、可回滾、可測試嘅工序交畀佢,將決策、審批、合規、客戶資料處理留畀有責任嘅人同制度。

競爭壓力:大家都喺搶「工程工作入口」

OpenAI 唔係唯一一間向 agentic coding 方向走嘅公司。Google Jules 官方文件將 Jules 形容為 experimental coding agent,可以整合 GitHub、理解 codebase,並自主處理 bug fix、文件、功能開發等任務;GitHub Copilot coding agent 官方文件亦講到,Copilot 可以喺背景獨立完成 task,喺 GitHub Actions 提供嘅臨時開發環境入面探索 code、改 file、跑測試,最後以 PR workflow 交回畀人 review。Anthropic Claude Code 文件亦將 Claude Code 定位成 terminal、desktop app、IDE、cloud、Slack、CI/CD 都可用嘅 agentic harness。

所以 OpenAI 今次整合方向,其實係同整個市場同步:下一代 coding tool 唔再只係 IDE 補字,而係由 issue、prompt、PR、測試、部署前檢查組成嘅背景工作流。分別在於 OpenAI 有 ChatGPT 呢個巨大 consumer 入口,同時又有 Codex、API、Agents SDK、Computer use 等開發者能力;如果佢將入口、agent 執行同企業管理打通,就會由「coding tool」變成「AI 工作系統」。對競爭對手而言,焦點亦唔只係模型邊個 benchmark 高,而係邊個能夠最自然嵌入開發者每日開 repo、開 issue、開 PR、開瀏覽器嘅工作節奏。

香港角度:最關鍵係支援清單同合規,唔係即刻跟風

香港公司要睇呢件事,第一步唔係問「要唔要即刻轉用 Codex」,而係問「官方支援同付款狀態係咪清楚」。OpenAI Help Center 嘅 ChatGPT supported countries 頁面列出目前可支援存取 ChatGPT 嘅國家同地區;用頁面內容搜尋 Hong 或 Hong Kong 未見香港。API supported countries 頁面亦列出支援 API 服務嘅地區,並明確寫明如果某地點不在清單,API 就不支援;同樣未見香港。頁面有日本、新加坡、南韓、台灣等鄰近市場,但呢個唔可以推論香港自動適用。

所以今次文章必須保守寫:香港可用性、港區訂閱、API key 使用、企業方案、data residency 同商業合約支援仍需逐項核實。如果公司本身有海外實體、跨境團隊、外地 billing、或者透過企業合約使用 OpenAI,情況可能同本地個人帳戶唔一樣,但唔應該用傳聞或第三方教學當正式支援證明。對香港 IT team 嚟講,合適做法係先以官方 supported countries、企業 sales 回覆、DPA / data processing terms、內部資料分類政策去判斷;至於「港行價」「港版方案」「本地正式可用性」,目前都應該標成 [待確認]。

呢個限制亦會影響本地 AI workflow 設計。若果 ChatGPT / Codex 官方通道未能穩定支援香港,公司就要避免將核心開發流程綁死喺單一未確認入口,例如將所有 PR review、CI 建議、內部知識庫查詢、客戶資料處理都依賴某個未正式支援嘅平台。比較務實嘅做法,係先將 AI coding agent 當成可替換層:repo 權限最小化、敏感資料遮罩、PR 必須人手 review、CI 必須獨立可重跑、prompt 同輸出要有留痕。咁就算之後 OpenAI、Google、GitHub、Anthropic 之間要轉平台,團隊都唔會被某一個 agent 鎖死。

短期內,今次重組未必令香港開發者聽日就多咗一個新按鈕;但中期訊號好清楚:OpenAI 想將 ChatGPT 由聊天工具推向「可以做工嘅工作入口」,而 Codex 就係工程場景入面最成熟嘅執行臂。真正要等官方交代嘅,係合併後嘅產品形態、權限模型、企業控制、收費、地區支援同 API 分工。喺呢啲未清楚之前,可以研究、可以做受控 pilot,但唔應該將未發布嘅統一體驗,當成已經可落地嘅香港企業方案。


參考來源

本文根據原文及公開資料整理;資料有出入時,以原文及官方資料為準。

分享:WhatsAppThreadsTelegramFacebook