讓兩個 AI 分工，一個寫一個驗
以前如果你的用法也是先在 ChatGPT 討論需求、想架構，再把結論丟給 Codex 寫程式，這套工作流會很有用。
Wisely Chen 做的事，是把這段原本要人手搬運的流程也自動化：Codex 負責讀文件跟架構、把任務交給 ChatGPT Pro、拿回結果後再跑測試驗收，人不用在兩個工具中間複製貼上。
我自己已經拿任務跑過，不是只整理原文。會想這樣搞，原因很單純：省 Codex 的 token 額度，加上網頁版 ChatGPT 看起來好像寫得比較強。這篇會記這兩個目的划不划算，也記一下這個做法聰明在哪、卡在哪，順便對照我自己現在的 Claude Code + Codex rescue 流程。
那怎麼分工：Codex 管、ChatGPT Pro 寫
分工是這樣切的：
- Codex：分析需求、讀文件跟架構、開對話、盯進度、本地跑測試驗收
- ChatGPT Pro：深度研究、想架構、寫 production code
Codex 不寫程式，只負責搞懂要做什麼、把工作交出去、然後檢查交回來的東西對不對。真正動手寫的是 ChatGPT Pro。
同一個人又寫又驗，本來就有問題
平常我們叫一個 AI 寫程式，寫完再叫它自己說「我測過了，沒問題」，這件事本身就怪——寫的人跟驗的人是同一個，本來就沒有動機找出自己的錯。
Wisely Chen 那句話講得很直白：「寫代碼的不負責驗證，驗證的不負責寫代碼。」把這兩件事拆給不同的角色做，是這整套工作流的起點。
接法是把手動接力交給 Codex，不是人工貼過去
Codex 今年四月那次更新後內建了瀏覽器功能，可以直接操作網頁，而不只是讀寫本機檔案。原本你得自己把 ChatGPT Pro 討論出的需求和架構搬去 Codex，現在可以讓 Codex 自己開分頁、自己把任務貼進去、自己盯著 ChatGPT Pro 跑，跑完再自己讀結果。
要讓 Codex 這樣做，需要一段 14 條規則的 orchestrator（調度者）prompt，內容包含要先讀 repo 文件跟架構、怎麼把需求寫成完整的工程任務描述、獨立複雜任務要開不同的 ChatGPT Pro 對話、回報缺陷時要附具體證據、最後要交一份包含對話連結跟測試結果的報告。要不要照抄這 14 條、還是整理成我自己的版本，我還沒有答案，先記著。
其實理由很單純：省額度，網頁版好像更強
先講額度：ChatGPT Pro 網頁版的對話不會吃 Codex 的 token 額度，兩邊的額度本來就是分開算的——寫程式的重活丟給 ChatGPT Pro 處理，Codex 那邊只負責調度跟驗收，額度消耗自然少很多。這點我自己用起來也確認是真的。
再講品質：這部分我自己還沒有大量的經驗，沒辦法給出很篤定的比較，只能說幾次用下來的印象是，複雜的工程任務丟給網頁版，寫出來的東西感覺真的比較好。Wisely Chen 自己拿一整個工作天實測過，Codex 跟 ChatGPT Pro 來回將近 20 輪，他的結論是某些複雜任務的程式碼品質甚至比某個 Claude 5 系列模型還好，架構比較乾淨，邊界條件也顧得比較周全——這是他的結論，我還沒有拿同一個任務認真比過，先記著。
調度的不用最強模型，這件事有研究背書
這呼應 AgentOpt 那類研究：在特定任務與角色配置下，小模型做 planning（規劃任務怎麼拆）、大模型做 solving（解決問題），可能比把最強模型放在所有角色更好。這剛好對應 Codex 在這裡的角色——它不需要是最會寫程式的那個，只需要會分派、會盯、會驗。
另一個有意思的觀察是，同一家的模型放進不同產品，品質會不一樣。有兩個猜測：一是 ChatGPT Pro 網頁版每次對話分到的算力可能比較多；二是 Codex 的 harness（agent 外面包的那層工具骨架，管檔案、管測試、管 Git 這些雜事）本身會吃掉一部分注意力，而 ChatGPT Pro 的介面比較單純，全部算力都拿去想程式怎麼寫。Wisely Chen 的結論是：「同一家的模型，在不同產品裡跑出不同品質，通常不是模型的問題，是基礎設施和工程架構的問題。」
模型可能被切換，品質會受影響
有一件事容易被忽略：有一則 GitHub 回報提到 Codex App 可能把使用者手動選的 GPT-5.5 High 工作階段切到 mini，造成輸出變差；但該 issue 沒有提到 VPN／proxy、GPT-5.6 Sol Pro，也不是官方確認。只能靠輸出品質變差來察覺：回覆變短、邏輯變鬆散、推理不連貫。GitHub 上有一則類似的回報（issue #28211）。
適合複雜的後端任務，前端視覺不用碰
這套分工的邊界很清楚：偏後端、需要深度推理、程式碼量大、要做架構決策的任務，比較有效。
CSS、視覺微調、動畫細節這類工作不適合，因為 ChatGPT Pro 網頁版沒辦法預覽，看不到畫面長什麼樣。簡單的 bug fix、小功能、快速原型也不用這樣搞，設定這一整套 orchestrator 的成本，只有任務複雜到一定程度才划算。
跟我自己的 Claude Code + Codex rescue，是不是同一件事
Day 121 提過我在 Claude Code 裡直接呼叫 Codex 的 /codex:rescue，遇到卡住或想聽第二意見時把任務整包丟給它。精神上跟這篇有點像——都是找另一個角色來做驗收、給第二意見，不是同一個 agent 球員兼裁判。
但差別也很明顯：我的 rescue 是我自己決定什麼時候觸發，觸發之後我還是那個貼錯誤訊息、盯進度的人；這套是把「找誰驗收、什麼時候找、怎麼溝通」整個交給 Codex 自己判斷，人真的退場了。
這招聰明，但容易卡住的地方還是不少
這套做法真正聰明的地方，是前面講的那招——直接用 Codex 內建瀏覽器操作網頁上的 ChatGPT，不用另外接 API，也不用人工貼來貼去。
但用瀏覽器操作網頁，本身就是一條很容易卡住的路：頁面要等載入、按鈕要等出現，中間任何一步卡住，就得停下來處理。這是瀏覽器自動化這條路線本身的限制，跟分工設計得好不好是兩回事。
明天分享一個更人性化的做法。
最近開始做免費的一對一諮詢，幫你把 AI 接進自己的工作流——有需要的話可以約：https://www.dawsonwang.com/
原文：https://ai-coding.wiselychen.com/codex-chatgpt-pro-dual-agent-workflow/（擷取 2026-07-29）