在 ChatGPT Pro 中規劃，在 Codex 中執行：設計文件交接實戰手冊

這個月值得偷學的工作流程不是某個模型，而是一種分工方式。你把GPT-6 Pro在 ChatGPT 裡交給它一個儲存庫網址，請它產出一份設計文件而不是修補程式，再把那份文件交給Codex或Claude Code來實作。規劃端跑在GPT-6 Astra 上——GPT-6 Pro 是 ChatGPT 用量上限對它的稱呼——而 Astra 是 2026-09-03 的模型，所以這裡沒有任何內容屬於發表會報導或發行宣告。過去七天內真正改變的事範圍更窄，也值得精確說明：2026-09-17 有實務工作者回報，一般 ChatGPT Chat（不是 ChatGPT Work，也不是 Codex）裡的官方 GitHub 外掛能編輯儲存庫檔案、提交並開啟拉取請求，而且不會動用到 Codex／Work 的額度。那是社群說法，不是官方文件——官方說明頁仍把 GitHub 應用程式描述為唯讀，並把所有寫入操作導向 Codex——而隨附的但書與這項說法同樣重要。以下所有內容都標註為官方回報、社群回報，或是在 2026-09-19 從官方頁面讀到的資訊。

工作流程，一次完成

實務工作者描述的其實是同一套迴路，只有些微差異。其中最常反覆出現的是：把 GitHub 位址貼進 ChatGPT，請它讀取程式碼並產出一份設計文件，接著下載那份文件，餵給負責執行的代理。有些人還會順帶要求開一份 pull request；其他人則停在文件這一步，讓執行者自己去寫。無論哪一種，形狀都一模一樣——在聊天產品裡規劃，在代理產品裡建置——而它值得照搬的原因是，這兩半是分開計量的。

• 規劃產出物 — 一份設計文件：要新增的介面、依路徑指名的待修改檔案、遷移順序、驗收測試，以及出錯時該怎麼辦。

• 執行產物 — 由能夠執行自己剛寫好的測試的代理所產生的分支與 pull request。

• 審閱產物——diff，這是唯一該送到審閱者手上的東西。

設計文件是承重的關鍵部件，而它能佔有一席之地有兩個原因。第一，文件是可攜的：無論執行者是 Codex、Claude Code，還是你自己寫的腳本化代理，同一份文字都能運作，因此你花錢換來的規劃不會綁死在單一廠商的工具上。第二，它是在任何內容寫入你的儲存庫之前就存在的審閱介面——這點至關重要，因為聊天產品中的寫入路徑是整套安排裡記載最不完整的一部分。

為什麼雙桶結構就是全部的訣竅

ChatGPT 不會把這個工作流程從同一個池子裡計費。Chat、ChatGPT Work 和 Codex 各自擁有獨立額度，其中 Work 與 Codex 彼此共用單一池；OpenAI API 金鑰又是另一筆獨立計費。這樣的結構正是讓交接合乎成本效益的原因：思考發生在 Chat 這個桶裡，執行發生在 agent 這個桶裡，而一份設計文件只花費一則 Chat 訊息，實作則消耗 agent 用量。

這些數字，一如 OpenAI 針對 Chat 端所公布的那樣——是供應商在其自家方案文件中回報的數字，而非實測數據：

• ChatGPT Pro 每月 200 美元——每週 200 則 GPT-6 Pro 訊息；GPT-5.6 Sol Pro 另外每天還可傳送 170 則，而兩款模型合計每天上限為 200 則。

• ChatGPT Pro 每月 100 美元 —— 每週 50 則 GPT-6 Pro 訊息，額度與 GPT-5.6 Sol Pro 共用。

• Business Standard — 每月 15 則 GPT-6 Pro 訊息，與 Sol Pro 共用；Business Premium — 每週 50 則，同樣以共用方式計算。

• ChatGPT Plus — Chat 中完全沒有 GPT-6 Pro。Astra 僅透過 ChatGPT Work 和 Codex 觸及 Plus，而這正是本教戰手冊試圖保護的客群。

在 Work/Codex 方面，OpenAI 發布的是估計值而非限制，並且明確如此表示：在 Plus 上，每五小時視窗大約可傳送 5 到 45 則 Astra 訊息；Pro 5x 為 25 到 225；Pro 20x 則為 100 到 900。同一頁面也指出，實際消耗量會因任務複雜度、上下文、輸出與工具使用而異，且可能額外適用每週限制。這些範圍大約落在對應 Sol 數字的一半，這正是前沿模型之所以能以代理形式運行、且成本還負擔得起的算術原因。

實際的結果是一條你可以寫在卡片上的預算規則。把 Chat 訊息花在決策上，把 agent 用量花在程式碼上。一場為了介面爭論二十分鐘的規劃會議，只耗掉幾則 Chat 訊息，卻能產出一份文件，替 agent 省下一小時的探索性編輯——而這正是討論串裡的實務工作者實際在做的取捨。

寫入路徑：連接器實際做了什麼，以及人們聲稱它做了什麼

這裡各方來源說法不一，而分歧之處正是有趣的部分。

OpenAI 自家的說明文件寫得毫不含糊：ChatGPT 裡的 GitHub 應用程式會讀取你的儲存庫以進行分析與搜尋，而生成程式碼、編輯程式碼並推送至 GitHub，才是 Codex 的用途。這是唯讀的立場，如果你要把這套做法納入團隊流程，就該以它為規劃依據，因為它才是有廠商背書的那一方。

社群立場（日期為 2026-09-17）是：網頁版的 GitHub 外掛在 Chat 模式下會編輯程式碼、提交變更並開啟提取要求；而且由於它是官方外掛，而非第三方 MCP 伺服器，因此不會耗用 Codex 或 Work 的配額。同一則討論串對適用範圍也很謹慎：小型工具、細微修改、小錯誤——大型重構與棘手除錯仍屬於 Codex 的範疇。它自家的留言者補充了值得反覆提醒的注意事項，因為真正會出問題的就是這些：

• 一般 ChatGPT 速率限制仍然適用。「不是 Codex 額度」並不等於「免費」。

• 品質可能在經過幾輪之後無預警地下降，工作階段會在任務進行到一半時降級為較小的模型。

• 該討論串的作者建議，當介面提供切換至 Work 的選項時，不要切換過去，並警告頻繁猛刷匿名聊天頁面會損害所有人的網路體驗。

一份針對相同模式的獨立日文文章，在沒有配額主張的情況下得出了相容的結論：如果 GitHub 整合支援寫入動作，一般聊天可以讀取儲存庫、修改檔案、建立分支並開啟提取要求；一般聊天的速率限制適用；而 Codex 與 Work 會取用共用的代理程式集區，因此一般聊天適合少量檔案的編輯，Codex 則適合長時間的軟體任務。在兩份說法一致之處，一致的部分就是可用的部分：聊天是小型變更的管道，Codex 是長時間工作階段的管道，而集區則是分開的。

目前已有第三方 MCP 伺服器提供真正的 git 工作流程——分支、差異、提交、推送、開啟 Pull Request——且權限可分級，從唯讀一路到推送。如果你要的是可確定且可稽核的寫入路徑，而不是一種你只能期盼的行為，那就是這條途徑；如果你想留在 OpenAI 文件所記載的範圍內，就在 Chat 規劃、在 Codex 撰寫。

無論如何，設計文件移交才是讓聊天寫入路徑站得住腳的關鍵。對儲存庫具備寫入範圍的聊天工作階段，是比具備讀取範圍的聊天工作階段更大的權限授予；而這份文件，就是你在行使該授權之前所審閱的產物。

交接，一步一步來

• 將規劃器指向儲存庫——把公開 URL 貼到提示中，或使用你已授權的 GitHub 連接器——並要求它在提出任何建議之前先閱讀程式碼。

• 要求一份設計文件，而不是一份修補程式。要求提供檔案路徑、要新增或變更的介面、變更必須依序合併的順序，以及能證明每個步驟的測試。

• 要求它引用它實際讀取的檔案。一份描述該儲存庫並不存在的介面的設計文件，是這個工作流程最常見的失敗方式；而這些引用能讓你在一分鐘內、而不是花上一個衝刺才抓出問題。

• 將文件儲存到儲存庫中，而不是將它貼進下一個工具。讀取檔案的執行器可以重新讀取它；收到貼上內容的執行器則只有一次機會。

• 以該文件作為指令啟動執行器，並讓每個 pull request 只涵蓋其中的一個章節。長時間的 session 正是 agent 品質悄悄劣化的地方。

• 之後讓規劃者只扮演審查角色。當文件有誤時，重新規劃並更新文件——別讓執行者即興偏離文件，因為即興行事正是這份文件存在的目的所要防範的。

它會在哪裡中斷

• 儲存庫狀態過時 — 規劃器在你於功能分支上工作時讀取了預設分支，因此文件中的檔案路徑落後一個版本。請指明要讀取哪個分支，或貼上分支樹。

• 設計文件漂移 — 文件與程式碼互相矛盾，而執行器會遵循文件。上述的引用檔案步驟就是便宜的保險。

• 配額意外朝錯誤方向發展——一場二十分鐘的規劃對話，在 Chat 訊息上很便宜，在注意力上卻很昂貴；而長時間的 agent 執行則正好相反。為你實際花費的資源桶編列預算。

• 靜默降級 — 一個經過數輪後降級至較小模型的對話工作階段，仍會產出一份語氣自信的設計文件。請根據文件本身的實質內容來審閱，而不是依據它是由旗艦模型撰寫的假設。

• 權限蔓延——無論是透過外掛程式或 MCP 伺服器，寫入路徑都會讓聊天工作階段具備變更你程式碼的能力。將權限分層，並在變更落地後撤銷它們。

透過單一端點執行 executor 那一半

這套工作流程中，規劃的那一半存在於一個訂閱制產品裡，而那一半就是那樣。執行的那一半是一次 API 呼叫，而那才是值得掌握的那一半。如果你把執行器寫成腳本——一個小型的代理迴圈、一項把已核准設計文件轉成分支的 CI 工作——模型呼叫就是唯一必須可替換的部分，因為你下一季想要的模型，並不是你今天規劃時所依據的模型。

這正是路由層存在的目的。openai/gpt-6-astra與其他 200 多個模型位於同一個 OpenAI 相容端點之後，並以 0% 加成原樣傳遞供應商牌價——因此當廠商調整價格時，我們這邊的價格當天就跟著變動，而不必等到下一次合約續約。自動容錯移轉讓你可以在部分流量上放入尚未經過實證的模型，底下再由已驗證的模型承接，這才是誠實查出便宜執行器是否足以應付你測試的方法。而路由 DSL 能把多個模型組合成單一呼叫，因此審查模型可以在同一組金鑰、同一條請求路徑上檢查執行器的差異，無須再進行第二次整合。

這些都不會改變交接的結構。它改變的是實驗你所掌控的那一半所需的成本：一把金鑰、一個端點，以及一個模型字串，讓你不必動到整條管線就能更改。

現在誰應該執行這個，誰又應該等待

如果你已經付費使用 Pro 等級的 ChatGPT 方案，而且已經在執行 Codex 或 Claude Code，那麼這個交接流程值得你本週就採用，因為這兩筆費用在你的帳單上本來就已經分開，而設計文件是整個循環中最便宜的一環。從一項你熟悉到足以看出糟糕計畫的變更開始：要求提供文件、閱讀其中引用的檔案，然後把它交出去。

如果你使用的是 Plus，請把期待放低一些。Astra 是透過 Work 和 Codex 觸及你，而不是透過 Chat，所以這套作戰手冊中屬於「規劃」的那一半，並不會以所述的形式提供給你——你會在同一个池子裡同時進行規劃與執行，這消除了經濟上的理由，只留下先寫好文件這項紀律。那項紀律仍然值得保有。折扣則不然。

而如果你想要這個的原因，是 Chat 裡的寫入路徑，而不是交接，那就等 OpenAI 的說明文件追上那個論壇討論串。一項被供應商自家說明頁面牴觸的能力，就是該留在臨時儲存庫裡、直到那些頁面改變為止的能力。

同一把金鑰即可觸及目錄中其餘內容，而你可以瀏覽完整的模型目錄，看看單一 OpenAI 相容端點背後還有些什麼。