Claude Code 產品主管 Cat Wu 轉投 OpenAI：程式代理人的下一場競爭，是誰能把產品做進工作流程

專題編輯：Nolan Tsai｜全球科技與產業編輯

當寫程式的 AI 能做得更多，決定勝負的工作反而不只在模型團隊

早期的 AI 程式工具主要補上一行函式或回答工程問題。今天的程式代理人已被設計成能閱讀專案、理解多份檔案、修改程式碼、執行測試、檢查錯誤並提出 Pull Request。它不再只是文字生成器，而是一個必須被納入軟體開發流程的工作參與者。功能變多，產品也更難做好：它要知道何時採取行動、何時請求批准、如何保存上下文，以及如何讓人類在出錯時接手。

這是 Claude Code 產品主管轉往 OpenAI 特別受到關注的背景。多家科技媒體報導，Catherine Wu 將負責 OpenAI Core Products 的產品管理，並與產品高層 Thibault Sottiaux 團隊合作。Wu 在公開說明中強調，希望建立能支援個人與團隊、同時讓使用者保有控制權的代理產品。報導所確認的是職務異動與公開產品方向；產品功能分工及未來路線仍要以 OpenAI 日後正式公告為準。

把這件事單純寫成「挖角成功」雖然有戲劇性，卻容易錯過更實際的競爭問題。當多家前沿模型都能產出可用程式碼，企業開始比較的將是：誰能更穩定地完成任務、接上現有工具、遵守權限規範、支援多人協作，並讓管理者有能力判斷交付品質。產品管理在這裡不是包裝功能，而是決定模型能力能否變成可靠工作流程的核心職能。

Claude Code 的成長，為何使產品經驗成為稀缺人才

Claude Code 的產品價值，並不只取決於底層模型善於寫程式。對開發者來說，一個可信的代理需要理解目錄與程式庫的關係、知道專案規範、判斷何時跑測試、提供可以審核的修改，還要避免在未授權時動到不相干的環境。這些能力涉及模型、工具層、介面設計、權限管理、版本控制與團隊採用方式，任何一環做得不好，都可能讓一次驚人的 Demo 無法穩定進入日常工作。

Wu 曾帶領 Claude Code 的產品工作，多家報導描述她參與了產品從內部實驗走向廣泛使用的過程。這段經歷的價值在於理解開發者不是為了使用 AI 而使用 AI，而是為了完成既有任務：修復問題、實作需求、更新依賴、維護測試或與同事交接。產品必須融入這些任務，不是要求使用者每天轉換到另一套與現有制度脫節的工作方式。

過去工程產品的典型設計，是先提供清楚的功能按鈕，再等待使用者操作。代理產品則經常面臨反向問題：系統可能主動提出一系列動作，因此必須協助使用者快速辨認它的目標、依據、範圍與風險。需要批准的時候，提示太多會使人疲乏；提示太少又可能失去控制。產品經理必須把這種取捨轉化成可測試、可理解的互動，而不是單靠模型有多聰明。

這也說明為什麼懂得「使用者如何交付工作」的人才，在 AI 公司間具有吸引力。模型能力會持續升級，介面與流程也需要持續調整。從單人程式編輯器走向團隊代理，產品經理要面對的使用者不只有工程師，還包括系統分析師、資訊安全、專案經理與 IT 主管。這些人未必每天寫程式，卻可能擁有需求、批准或驗收權限。

Codex 與 Claude Code 的競爭，不能只靠相同的程式題比較

比較兩款代理時，最容易找到的是公開基準測試、執行速度或展示影片。但一家企業選擇 AI 開發工作流，往往要考慮許多測試分數以外的條件。第一個是既有版本控制與問題追蹤系統是否能自然整合。第二個是對本機、雲端、受管制網路及企業帳號的支援。第三個是企業能否將程式規則、資安要求與代碼審查政策變成每次任務都會遵守的工作契約。

例如，一家金融企業想讓代理替內部系統新增查詢欄位。代理即使能在十分鐘內產出完整程式碼，如果它修改了錯誤分支、忽略 API 契約、把測試資料送到未批准服務，或沒有留下變更記錄，這次交付仍不能算成功。反過來說，另一個代理即使生成速度稍慢，卻能把需求拆成可驗收工作、限制修改範圍、產出測試證據並交給人類完成 Code Review，可能更適合正式生產環境。

因此 AI 程式工具應該以「可驗收任務」而非「生成程式行數」作為比較單位。可驗收任務包含原始需求、修改範圍、測試標準、權限、交付文件與最終批准。開發主管可以設計相同的任務包，讓不同代理在同一個乾淨的專案分支中執行，觀察完成率、返工次數、回歸測試失敗率與審查耗時。這比拿兩支沒有相同資料、相同工具與相同資源限制的展示影片比較更有意義。

產品競爭的另一個面向是多角色協作。工程師 A 開發 API、工程師 B 改前端、工程師 C 寫測試、系統分析師 D 維護需求；代理如何讀取同一份規範、避免重複修改、解決衝突並保存決策，是團隊產品真正困難的地方。這些問題不會隨著模型參數變大而自動消失，反而可能因代理一次能修改更多檔案而變得更尖銳。

從聊天到長任務，下一個瓶頸叫作「可接續的上下文」

軟體專案不是一次對話。需求可能今天由 BA 整理、明天由 SA 確認、後天交給工程師開發，再經過測試與正式部署。若代理只能記住聊天視窗中的片段，工作在不同人員、不同裝置與不同時間之間就很容易失去一致性。因此 AI 開發產品逐漸需要把可重複使用的知識、專案規則與任務狀態分開保存。

專案規則像是團隊共同遵守的工作手冊，應說明技術堆疊、架構限制、命名規範、測試命令與禁止修改的部分。任務狀態則像一張可追蹤的工單，記錄已完成什麼、還缺什麼、目前有哪些已知風險。決策紀錄要說明為什麼採用某個設計，避免下一個代理把前一位同仁討論好的內容重新推翻。這三者可以分開管理，但需要在同一個流程裡互相對應。

對產品來說，優秀的上下文不是把所有聊天記錄無限塞進提示詞，而是讓每位參與者取得與當下任務相關、具來源及版本的資料。當 API 規格更新，代理不能繼續使用舊文件完成看似漂亮的程式碼。當資料來源相互矛盾，代理應該標示衝突並請求確認，而不是選一份文件就自行覆寫其他人已同意的決策。

這裡存在產品與組織制度的共同設計問題。工具可以協助彙整規則，但不能替企業決定誰對需求負責、誰有修改權、誰批准合併、哪個環境允許存取真實資料。沒有制度的代理工作流，就像有自動駕駛功能卻沒有道路規則。功能愈強，管理模糊造成的成本可能愈高。

人才移動讓市場聯想加速，但不應推論太多

對於 Wu 的轉職，有些報導把它放進 OpenAI 與 Anthropic 爭奪程式代理市場的脈絡。這是合理的產業觀察，但仍須區分被證實的事實與外界的動機推論。可以證實的是人事變動、她過去的產品工作、她公開說明的新職務與目標；不能只憑這些公開資訊斷定 Anthropic 內部出現危機、特定產品將被取消，或 OpenAI 已經決定將某些功能全部改成 Claude Code 的設計。

職涯選擇通常涉及個人發展、職務責任、團隊文化與工作機會等多重因素。未經本人與公司證實的動機，不應被包裝成確定原因。同樣地，個別人才對產品成功可能有重要貢獻，但一個成熟產品仍涉及研究、工程、設計、資安、法務、銷售與客戶成功團隊的共同工作，不能將全部成果歸給單一人士。

對企業決策者而言，更有價值的觀察是兩家公司的產品策略是否因此出現可驗證變化。例如，開發代理是否改進與團隊協作工具的整合、是否更清楚區分研究與生產環境、是否改善工作交接與人工批准，以及企業合約是否提供足夠可預期的治理條款。這些才是人才移動可能在未來產生的外部結果，應由實際推出的功能與客戶體驗來確認。

台灣 IT 主管如何避免被兩家公司產品戰拖著走

台灣企業可先訂出中立的採購驗收規格，不必急著預測哪個模型最終會贏。選擇一項具有一定複雜度、但可在隔離測試環境執行的真實需求，把需求文件、程式庫版本、測試資料及驗收條件一次備妥。讓不同供應商的代理在相同條件下執行，並留下完整執行紀錄。最重要的是測試完之後誰能接手、誰看得懂變更、能否安全合併到主分支。

治理驗收至少涵蓋身份與權限、敏感資料處理、動作審批、變更追蹤、成本可見性、失敗回復及知識交接。若使用 GitHub Enterprise 或類似平台，應確認開發分支、Pull Request、Code Owners 與分支保護政策沒有因導入代理而失效。如果任務牽涉金融客戶資料或封閉網路，還需要明確確認工具是否支援企業的執行環境；不能把公開雲端展示視為私有環境已可部署的證明。

從第一性原理看，企業購買 AI 開發代理不是購買更多自動產生的程式碼，而是購買可接受的交付速度、品質與風險。這意味著應把「一項需求從批准到可上線」作為最終單位，並同時計算人工審查、返工、故障和資安治理成本。若使用工具後開發時間下降，但測試缺失與維運負擔增加，整體效益可能為負。

也不應忽略人員培訓。過去團隊用手動程式碼審查判斷工程品質，未來還要學會審閱代理提出的計畫、確認來源、檢查跨檔案副作用，以及在必要時停止或復原操作。系統分析師與專案經理可以貢獻更精準的需求和驗收設計，資安人員則需要參與工具權限與敏感操作流程。企業要培養的是多角色共同監督代理的能力，而不是把「會下提示詞」當成全部轉型成果。

下一場競爭，先看產品能否承擔團隊責任

Cat Wu 加入 OpenAI 是近期 AI 產業人才競爭的一個具體事件，卻不該被簡化成某家公司已經贏得下一回合。程式代理的市場仍在發展，模型、部署形式、企業治理與定價方式都可能繼續改變。成熟企業可以關注供應商動態，但更應保留自己的程式碼、需求、測試與專案知識資產，避免工作流程完全依賴單一工具的特定操作習慣。

值得追蹤的指標包括團隊採用深度、可重複任務完成率、企業級權限設計、整合能力與長期維護品質。人才可能加快某些功能的成熟，但採購選擇仍應由自身的環境、成本與驗收結果決定。當開發代理從「幫人寫程式」成長為「幫團隊交付軟體」，能否把工作責任說清楚，才是產品勝負的重要分水嶺。

AI 程式代理人的產品能力，已經可以分成五個不同層次

第一層是程式碼產生。模型根據文字指令補上函式、解釋錯誤或建立範例程式，屬於對工程師個人生產力的直接協助。這仍然重要，但很難單靠它判斷是否適合大型企業。因為真正的交付包含需求、版本、測試與其他人的修改，單次回答寫得漂亮並不能證明整條開發流程可靠。企業如果只在第一層做比較，容易買到很強的展示能力，卻缺少正式導入條件。

第二層是任務執行。代理能先閱讀專案，提出計畫，再依序修改檔案、運行命令、檢查錯誤並改善結果。此時模型不再只負責輸出程式碼，而是會影響工作環境。產品需要提供清楚的執行紀錄、工具呼叫權限、失敗回復與使用者介入方式。若工程師不知道代理正在修改哪些檔案，或只能在工作完成後才發現大量不相關變更，就算模型具備更長的上下文，也未必能帶來高品質交付。

第三層是專案知識。代理必須知道技術堆疊、團隊規則、架構決策、命名方式、資料來源與測試要求。這些知識可能保存在 Markdown、版本控制中的設定檔、文件系統或專案管理工具中。產品若只能理解目前聊天紀錄，而不能可靠地引用有版本的專案規範，跨天、跨人員的任務就容易反覆推翻先前決定。知識管理不是額外附屬功能，而是代理能否接續工作的核心前提。

第四層是團隊協作。多人在不同分支與任務中工作，代理需要懂得任務邊界、避免同時修改同一個敏感檔案、提出可供 Code Review 的變更，並在發現需求衝突時請求協調。它還要能對接企業現有的身分與批准流程，不能把對話中的一句「可以」直接理解成對所有環境的永久授權。對大型企業來說，這一層的可靠性往往比模型單次生成速度更影響是否願意擴大採用。

第五層是治理與營運。主管需要知道哪些團隊使用代理、哪些任務真正完成、是否產生重大故障、是否遵守資料政策，以及每項可驗收成果的成本。產品必須提供稽核、可移轉的紀錄與事件處理方式，而不能讓治理完全依賴個別使用者截圖。這五層不是所有供應商都已完整提供的功能清單，而是一個企業可用於比較產品成熟度的分析框架。Cat Wu 的轉職受到矚目，正是因為把模型能力整合成後四層的產品，是越來越重要的競爭工作。

一個企業級代理的安全設計，不應只靠提示詞規範

許多團隊會在專案檔案寫下「不要讀取機密」「不得修改主分支」等規則。這些文字可以協助模型理解任務，但不能代替技術控制。若代理的帳號本身有權存取生產資料庫，僅靠提示詞要求它不要使用，並不足以滿足正式治理要求。更可靠的設計，是讓代理只能取得當次任務必要的憑證，預設在受限制的環境運作，對高風險操作另設人工批准。

開發流程可分開處理讀取、編輯、測試與正式部署。讀取專案文件不一定等於可以讀取所有客戶資料；修改工作分支不等於可以合併主分支；測試環境能執行不等於生產環境可以部署。企業應讓不同操作對應不同權限與稽核欄位，並把批准權交給清楚指定的角色。這也可以減少權限設定太複雜的反效果：一般低風險操作順暢執行，只有真正敏感的動作才要求額外審核。

此外，代理可能讀到不可信的程式註解、網頁、開源套件說明或外部文件，這些文字不應自動升格為企業指令。若外部內容混入要求忽略原本規則的文字，系統應維持較高信任層級的政策與權限限制。產品需要明確區分來源資料與使用者命令，讓工程師可以檢查代理依據什麼決定採取行動。當不同供應商聲稱支援「安全代理」時，企業應要求在受控測試中展示這些邊界，而不是只接受一份原則說明。

完整的稽核至少要保留任務目的、工具與模型版本、輸入的規範來源、執行時間、工具呼叫、改動的檔案、測試結果、審核人員與最終合併紀錄。這些資料不一定需要永久保留，保留期限可依公司政策與法規決定；但在需要調查故障或安全事件時，應能重建發生過哪些重要操作。若代理沒有足夠的記錄，後續維護成本可能比省下的程式工時還高。

用一個標準化的開發任務，真正比較 Claude Code、Codex 與其他工具

可用的測試任務應具有清楚的業務目的，也要包含足以反映真實工作的限制。假設金融企業內部有一套案件管理系統，需求是為案件新增優先級及前端篩選。測試包應有需求說明、資料表結構、API 契約、前端畫面、既有測試與驗收案例。代理必須先說明預計修改哪些檔案、對資料與 API 有沒有影響，再在各自獨立的分支完成工作。這是一個教學型示例，不代表任何特定供應商的實測結果。

在任務進行時，測試人員不只記錄模型用了多少 token，還要觀察它是否遵守既有契約、是否對不確定的需求提出問題、是否自行新增未授權功能、是否產生足夠的自動化測試，以及其他工程師能不能讀懂變更。完成後由未參與生成的人員審核 Pull Request，並依同一套規則驗收。這能把產品能力從「看起來寫完了」轉成「外部審查者確認符合要求」。

最終評估指標可以分成任務品質、治理與成本三組。任務品質包括功能通過率、回歸測試通過率、修改範圍準確性和返工次數；治理包括敏感資料處理、權限遵守、紀錄完整度與回復能力；成本則包括模型用量、代理運行時間、人工審查時間和部署後修正成本。若某工具比較便宜，但要讓資深工程師花更長時間追查副作用，就不一定比較划算。

這種比較方式也需要對版本與環境保持公平。工具可能採用不同預設模型、不同權限設定和不同整合方式，不能刻意讓其中一個使用完整專案文件、另一個只得到一段模糊提示。測試應記錄版本、授權功能、網路限制和可使用的工作時間。更重要的是至少重複執行多次，並使用不同複雜度的任務，避免單次運氣左右採購決策。

企業在採購合約中，應該把什麼寫成可執行條款

當 AI 代理被用於正式研發流程，採購契約不能只列出每人每月授權費。企業還需要確認原始碼與資料的處理條件、服務可用性、企業身份與權限整合、模型變更通知、日誌可取得性，以及供應商發生事故時的通報與應變責任。某些產業需要資料留在指定環境，另一些企業則有禁止向外部服務傳送特定原始碼的要求，不能假設所有軟體開發團隊都採用同一種雲端政策。

工具切換成本同樣值得評估。假設一家企業已把工作規範完全寫在某家產品特定的私有功能裡，日後更換供應商時，可能需要大量人工重做。若關鍵資產能以開放且有版本的格式保存，例如需求、API 契約、架構決策、測試與程式碼審查紀錄，就較容易保持選擇空間。企業可以接受供應商具差異化的產品功能，但不應輕易把自己的業務規範、交付證據與權限政策全部鎖在無法匯出的介面中。

人才流動可能改善產品設計，卻不會自動解決上述契約和治理問題。企業應將開發代理視為需持續管理的工作系統，每隔一段時間重新驗證模型表現、資料政策與使用成本。這樣的採購方式比較不會被單次發布、基準測試或高階人事新聞牽動，也更有機會讓 AI 工具轉化成長期穩定的軟體開發能力。

AI 產品經理的競爭，最後仍會落到「誰可以信任代理完成工作」

對一般使用者而言，好的代理體驗通常是任務可以順利完成，卻又不會在關鍵時刻失去控制。產品經理必須理解哪些操作可以預先授權、哪些需要事前說明、哪些失敗可以自動修復，以及何時應交給人類。這不是簡單把更多按鈕藏進選單，而是把信任分配到每個操作節點。當企業把代理放進正式開發流程，這些產品決策還會牽動資安政策、開發效率與跨部門合作。

對模型供應商來說，人才競爭也意味著必須同時具備研究能力、工程平台與產品理解。能在公開基準取得高分的模型，不一定擁有最適合某個企業的功能；能設計流暢介面的產品，也不一定已滿足最嚴格的治理要求。最終的市場結果要看各家公司能否把不同能力整合，讓不同規模的團隊在可控條件下完成工作。

企業不必對每一次高階人才異動做出立即採購反應，更適合建立每季或每半年更新一次的產品評估機制。當新功能、權限規則或定價改變，使用同一套任務包重新測試即可。如此既能吸收技術進步，也能避免使用者因為追逐新聞而反覆遷移，浪費已經累積的開發規範與培訓成本。

此外，產品更新頻繁也會使內部教材迅速過時。企業應把培訓重點從記住特定按鈕，轉向需求定義、版本控制、測試驗收、操作權限與異常復原等可跨平台使用的能力。這些能力即使供應商更換，仍會留下組織價值。

如果企業正在比較 Claude Code 與 Codex，應如何驗證？

Cat Wu 的職務轉換是一則產品人才新聞，不是任何一家程式代理人已勝出的基準測試。企業反而可以把話題轉化成一份真正公平的工具選型表：使用同一個可公開或已授權的專案、相同任務、相同限制與一致的驗收方式。

這份表格不預設哪一家工具比較好。相同提示詞也不保證相同能力；工具版本、可用權限、模型與資料環境都要紀錄。若只能在受限的企業內網執行，還需確認供應商支援方式與資料保護要求。本文另附可實際填寫的 agent_platform_evaluation.csv，每個項目採相同的驗收標準，避免僅根據媒體聲量或單一 Demo 決定採購。

常見問題

Cat Wu 原本負責什麼工作？ 多家媒體報導她在 Anthropic 領導 Claude Code 等相關產品工作，並於 2026 年 11 月初宣布加入 OpenAI。

她加入 OpenAI 後會直接接管 Codex 嗎？ 公開確認的新職務是 Core Products 產品管理領導工作；個別產品分工應以 OpenAI 正式後續說明為準，不宜單憑報導推定。

企業應因此立刻從 Claude Code 換成 Codex 嗎？ 沒有這樣的必然結論。應以自家程式庫、資安限制、團隊協作與驗收條件進行實測，再決定工具組合。

資料來源

1. The Next Web，Claude Code 產品主管轉任 OpenAI，2026／11／05
2. Business Insider，Cat Wu 產品人才異動報導，2026／11
3. The Decoder，Catherine Wu 與 OpenAI 人才競爭分析，2026／11／05
4. RuntimeWire，Cat Wu 公開貼文及職務整理，2026／11／04

圖片資訊

封面圖片為原創概念示意圖，以不同程式工作區交接表達產品人才移動；並非當事人肖像、新聞現場或兩家公司真實工作畫面。

延伸閱讀

探索更多 AI 工作實務