剛開始用 Codex 時，最容易注意到的是它會寫代碼、改文件、跑命令。用久以後，拉開體驗差距的卻是另一些事，下面爲大家整理一套更好用的工作方法。
1. 對話、項目、記憶與上下文
項目和對話最好從一開始就分開。項目保存的是會反覆使用的東西：代碼、資料、規則、來源，以及多次任務都需要的背景。對話的壽命則短得多，它只負責一個能說清楚的結果。
比如同一個產品正在做登錄修復、界面重構和代碼審查，這三件事可以屬於同一項目，但不要塞進同一條對話。讓它們各自擁有獨立的目標、過程和交付記錄，後續查找更方便，Codex 也不容易把某次排查中的臨時判斷帶進另一項工作。
源文件夾決定 Codex 在這個項目中可持續參考的代碼和資料。可以添加多個文件夾，例如前端倉庫、後端倉庫與共享文檔目錄；但應避免無關文件擴大檢索範圍和上下文噪聲。
本地項目還有一個很實際的細節：主目錄會影響 Git 操作，以及 AGENTS.md、Skill 和 config.toml 的自動發現。很多看似是模型理解能力的問題，最後發現只是目錄選錯了。開始任務前注意看一眼工作目錄和 Git 狀態。
上下文不該全放在聊天裏。架構、數據流和關鍵決策寫進項目文檔；構建命令、測試要求、禁改目錄和完成標準寫進 AGENTS.md；個人偏好與反覆出現的歷史經驗交給記憶。這樣分層以後，新對話不必從零解釋。
Codex 說明適合放每次對話都成立、又不屬於某個倉庫的偏好。例如可以寫：
默認使用中文回覆。
修改代碼前先說明計劃；不覆蓋用戶已有改動。
完成後列出修改文件、執行過的驗證和仍未驗證的項目。
涉及刪除、外部發送或生產環境操作時，先說明影響範圍。
這類說明應保持短而穩定。項目專屬的構建命令、目錄邊界和驗收要求，仍應放在項目文檔或 AGENTS.md，不要混入個人說明。
AGENTS.md 是告訴 Codex 先看哪些文件，哪些地方不要碰，修改後跑什麼檢查，最後怎樣彙報。等同一種錯誤重複出現，再增加一條規則。提前寫幾十條抽象原則，只會擠佔上下文。
全局 AGENTS 適合保存跨項目重複執行的操作約定。例如：
通用工作約定
開始前確認當前目錄、Git 分支和工作區狀態。
改動後運行與改動範圍匹配的測試；不要把無關格式化混入提交。
不讀取或輸出密鑰、令牌和本地憑據。
最終彙報包含：修改內容、驗證結果、已知限制和下一步建議。
全局規則應只寫通用約束；某個倉庫特有的命令、部署流程和禁止修改目錄，放在倉庫內的 AGENTS.md 更清晰。
結束對話時，可以讓 Codex 留下一份很短的交接：做了什麼、改了哪些文件、跑過什麼驗證、還剩哪些風險。真正需要長期保留的內容再更新到項目文檔。任務已經結束，就開一條新對話；任務仍在延續，就沿用原對話。
2. 計劃、目標、Fork 分支與“/”命令
計劃模式最適合那些“一旦方向錯了，重來很耗時耗力”的任務。跨模塊重構、數據庫變更、架構遷移和難以復現的故障，先用 /plan 調查現狀、補齊未知項，再討論方案。
一個有用的計劃會回答幾件具體的事：涉及哪些文件，哪些接口必須保持不變，工作怎麼拆成可驗證的步驟，失敗後如何回退。
/goal 處理的是另一類問題，說明任務最終要走到哪裏。需要長時間推進的遷移、重構或實驗，可以把最終狀態、邊界、驗證方式和停止條件寫進目標，讓 Codex 自己循環推進。
但諸如“持續優化這個項目”並不算目標，因爲它沒有終點。
Fork 經常被誤解成代碼回退。它只是從當前歷史派生一條新的對話路線，硬盤上已經發生的修改不會消失。想比較、恢復或合併代碼，仍然要看 Git。即 Fork 處理談話的分叉，Git 處理代碼的分叉。
可以把它類比爲 GitHub Fork 的探索，但不同的是：GitHub Fork 會在你的賬號下複製一個代碼倉庫，可獨立提交併通過 Pull Request 合併；Codex Fork 則從當前節點複製一條對話歷史，用來比較兩種排查或實現路線。它不會新建遠程倉庫、分支或提交，也不會自動隔離本地工作區。需要隔離代碼時，仍要創建 Git 分支或 Worktree。
輸入 / 後出現的命令面板，值得熟悉，但不必死記。日常使用頻率較高的大致是這些：
這些命令組合起來，對應一條完整節奏：先想清楚，設定終點，執行中及時糾偏，路線確實分叉時再 Fork，交付前做 Review。對話拖得太長就 Compact；工作已經結束就收口，不要繼續往裏堆內容。
熟悉 “/” 命令可以少靠一段模糊的自然語言去猜當前意圖，降低遺漏關鍵步驟的概率，也讓對話在複雜任務中更容易回到可驗收的軌道。
3. 瀏覽器、手機端控制與交互
前端任務只跑測試是不夠的。佈局錯位、按鈕不可點、登錄跳轉異常、錯誤提示消失，這些問題都可能躲過構建和單元測試。內置瀏覽器的意義就在這裏：讓 Codex 打開真實頁面，按用戶路徑操作，再把結果和代碼改動放在一起檢查。
內置瀏覽器適合需要 Codex 參與驗收的頁面：它可以在受控的瀏覽器表面中打開頁面、按步驟操作、觀察結果並留下截圖或測試證據。將網頁 URL 默認交給 Chrome 等外部瀏覽器，則更適合日常閱讀、複用個人登錄狀態、擴展和書籤；頁面會在你的常用瀏覽器中打開，但是否能被 Codex 繼續操作取決於瀏覽器連接與授權狀態。
瀏覽器驗收最好提前寫清楚。以表單爲例，至少應該覆蓋正常提交、缺少必填項、接口失敗和權限不足。每個場景都寫明操作與預期結果，Codex 才知道該停在哪裏、看什麼，以及什麼現象算失敗。
如果故障只在頁面上出現，先復現並截圖，修改後再走同一條路徑。這樣留下的是可重複的驗證過程。瀏覽器控制還涉及另一條邊界：允許訪問某個網站。網頁裏的文字不能自動變成新的任務指令，提交信息、修改權限、刪除數據等動作仍需單獨判斷。
手機端遠程控制適合把已經定義清楚的工作繼續推進。連接後，任務仍運行在電腦或電腦連接的 SSH 環境中；手機用來啓動任務、追加要求、審批命令、查看 diff 和測試結果。主機需要保持在線，Windows 上涉及計算機操作時，桌面會話也要可用。
這套方式很適合查看長測試、批准一條明確命令，或者在任務跑偏時及時拉回來。需要處理複雜衝突、評估大段代碼或精細檢查 UI 時，回到桌面會更穩妥。
4. Hooks、SSH、Git、環境與 Worktrees
這一組功能看起來分散，其實都圍繞執行環境。環境決定依賴和工具在哪裏；SSH 把工作位置延伸到遠程主機；Git 記錄代碼歷史；Worktree 隔離並行修改；Hooks 則在特定節點自動運行檢查或動作。
Hooks 適合做確定性工作。例如會話開始時加載項目狀態，工具調用前檢查危險命令，文件修改後運行掃描，任務結束前確認測試結果。用戶級 Hook 可以放在 ~/.codex/hooks.json 或 config.toml，項目級配置放在倉庫的 .codex/ 目錄。
Hook 可以直接執行命令，也可能把輸出加入模型上下文。新增或修改後的非託管 Hook 需要先審查；輸出應保持短小，不要包含密鑰和隱私數據。
SSH 的原則和普通遠程開發一樣：在 ~/.ssh/config 中配置明確別名，使用可信密鑰和低權限賬戶，先確認 ssh <alias> 可以正常連接，再把主機加入 Codex。遠程主機上要能從登錄 Shell 找到 Codex。不要把 App Server 或無認證端口直接暴露到公網；需要跨網絡連接時，使用合適的 *** 或安全網絡。
Local、SSH 和 Cloud 沒有絕對優劣。依賴已經配好的本機工具時用 Local；代碼或算力在遠端時用 SSH；需要容器化、後臺化執行時再考慮 Cloud。無論選哪一種，安裝步驟、環境變量、網絡權限和驗證命令都應明確。
Git 始終是底座。任務開始前確認分支和 git status，結束後看 diff、跑測試，再按邏輯提交。Fork 不會恢復代碼，遠程控制不會替你保存歷史，Worktree 也不負責判斷改動是否應該合併。
Worktree 適合多個對話同時修改同一倉庫。每個任務使用獨立目錄和 Git 狀態，就不會在同一個工作區裏互相覆蓋。Codex 管理的 Worktree 一般從所選分支的 HEAD 創建，初始處於分離 HEAD；後續可以在其中創建分支，也可以通過 Handoff 移回 Local。
這裏有兩個容易踩的坑。
第一，Git 不允許同一分支同時在多個 Worktree 中檢出，這是正常保護。
第二，.env、本地證書等被忽略文件不會自動齊全，確實需要時可用 .worktreeinclude 精確聲明。
5. Skill、插件、MCP 與子 Agent
這幾個名字經常同時出現，但職責並不重疊。Skill 記錄一套可複用的做法；插件把 Skill、MCP、Hook 等內容打包分發；MCP 提供外部數據和動作；子 Agent 接手可以獨立處理的工作。
Skill 應從已經跑通的流程里長出來。發佈檢查、日誌排查、PR 審查、固定格式的文檔生成，這些流程在普通對話裏穩定執行幾次後，再整理成 Skill。剛想到一個點子就封裝，後面往往要一邊使用一邊拆掉重做。
插件解決分發問題。團隊需要統一安裝一組 Skill、MCP 和 Hook 時，插件比手工複製配置合適。安裝前要看清它能讀什麼、能寫什麼、是否會把內容發送到外部服務。
MCP 用在倉庫之外：GitHub、工單、設計稿、知識庫、數據庫或內部服務。服務器處理認證、授權、實時數據和受控操作，Skill 負責告訴 Codex 以什麼順序使用這些工具。只需要本地文件時沒必要先搭 MCP；需要外部寫入時，則要把讀取和修改權限分開考慮。
子 Agent 適合範圍明確、結果可獨立檢查的任務，例如掃描受影響文件、補既定測試、歸類日誌、並行研究幾個方案。整體目標、方案取捨和最終合併仍由主 Agent 負責。委派時至少寫清輸入範圍、禁止事項、輸出格式和驗證標準。
模型也可以按角色分工：先用推理能力較強的 Sol 完成任務拆解，再把邊界清楚的執行項交給速度、成本更合適的 Luna，或已接入並完成驗證的 DeepSeek 模型。
可以使用OpenCodex 一類的模型路由工具把子 Agent 請求發送給選定的提供方；但接入前應覈對模型能力、隱私邊界、價格和失敗回退策略。
還有一個常被忽略的成本：子 Agent 會獨立使用模型和工具，Token 消耗通常高於單 Agent。只有當並行能減少等待，或把大量探索噪聲擋在主線程之外時，委派才划算。
6. 成本、效率與 SOP
Codex 最貴的部分通常是返工。目錄選錯後讀了一遍倉庫，目標沒說清便開始重構，幾個 Agent 重複搜索同一批文件，對話太長導致舊結論不斷回來，最後只看總結沒看 diff——這些損耗往往比模型單價更大。
因此，優化順序應該是先縮小任務，再補足相關上下文，寫清約束和完成條件，最後才討論模型與推理強度。範圍明確的檢索、歸類和文檔整理可以優先速度；架構、安全、複雜調試和高風險遷移更需要推理質量。
一條夠用的任務描述通常包含以下幾部分：
當然，這些任務描述也可以通過計劃模式來完成。
權限也會影響效率。合適的狀態是：工作區內的常規操作可以順暢執行，越過文件、網絡或系統邊界時仍然可見。自動審查只是把審批請求交給獨立審查 Agent，不會擴大可寫目錄，也不會自動開放網絡。
實際工作可以收斂成一套不復雜的順序：
確認項目、目錄、分支、Git 狀態和運行環境。
寫清目標、相關上下文、不可觸碰的邊界和完成條件。
簡單任務直接做；複雜任務先 /plan；長任務再設 /goal；並行修改放進 Worktree。
保持小步修改。方向不對就立即糾偏，只把真正獨立的部分交給子 Agent。
運行測試、lint、類型檢查和構建。涉及界面的改動，用瀏覽器走一遍真實流程。
查看 diff 和失敗日誌，區分已經驗證、驗證失敗和沒有驗證的部分。
提交或創建 PR 後，把長期有效的信息寫回項目文檔或 AGENTS.md。重複流程穩定以後，再做成 Skill。
更多遊戲資訊請關註：電玩幫遊戲資訊專區
電玩幫圖文攻略 www.vgover.com
