把 Codex 用進大型項目：關鍵是先搭 Harness
整理版優先睇
用 Codex 打入大型專案嘅關鍵：先砌好 Harness，將隱性知識變成工程流程
呢篇文章係由陳寶寫嘅，佢係一位專注 AI 編程商業化同副業變現嘅作者。佢想解決嘅問題係：點樣將 Codex 呢類 AI 編程助手有效地用喺真實嘅大型業務代碼庫，而唔係淨係喺小項目試玩。佢指出好多開發者一嚟就諗住將需求掟畀 Codex，但喺大型項目入面，目錄多、歷史包袱重、測試慢、隱式約定多，直接掟任務好易出錯。
整體結論係：大型項目嘅關鍵唔係每次都寫更長嘅 prompt，而係先搭一個俾 Codex 用嘅工程化工作台，佢叫做 Harness。Harness 包括項目說明、代碼地圖、常用命令、自動化腳本、權限策略、外部工具、驗證流程，同埋團隊沉澱落嚟嘅工作規則。目標係令 Codex 少啲靠估、多啲驗證，將每個任務都放喺可複用嘅工程流程裏面，咁先可以喺真實項目持續交付。
- 大型項目用 Codex 嘅痛點：上下文錯位、驗證不足、權限失控，問題源於冇做好工程化基礎。
- Harness 嘅核心係將隱性嘅項目知識變成顯性嘅工作流，唔係單一檔案，而係成個生態系統。
- 第一步要整嘅係 AGENTS.md：一份俾 Codex 睇嘅項目說明書，交代點起動、點組織、點驗證、邊啲唔可以改。
- Code Map 係粗粒度地圖，話畀 Codex 核心模塊喺邊、高風險區喺邊、常用驗證指令係咩，最好用腳本自動生成。
- 權限要按場景分級：只讀、自動編輯、隔離環境高自動化，而且權限提升一定要配埋隔離環境。
任務模板結構
目標：[描述] 範圍：[限定的檔案或模塊] 上下文：先睇 AGENTS.md 同 docs/code-map.md，再睇相關檔案 約束：唔好改嘅嘢（例如數據庫遷移、公共 API） 驗證：要執行嘅指令 交付：解釋改咗邊啲檔案、驗證結果、剩餘風險
結構示例
# Code Map## Web 入口- apps/web/src/app: Next.js App Router 頁面- apps/web/src/components: 可複用 UI 組件- apps/web/src/lib/api.ts: 前端 API client## API 入口- apps/api/src/routes: HTTP routes- apps/api/src/services: 業務服務- apps/api/src/db: 數據訪問和 schema## 驗證命令- npm run lint- npm run typecheck- npm run test -- --runInBand## 高風險區域- apps/api/src/db/migrations: 不要改歷史遷移- packages/contracts: 改動會影響前後端契約直接掟任務嘅三大死因
好多工程師第一次用 Codex，都好想就咁將需求掟入去，等佢自己讀曬成個項目、改代碼、跑測試。細項目成日都行得通，但一去到真實嘅業務代碼庫，就會撞到三個常見問題。
第一係上下文錯位
Codex 可能揾咗個名相似嘅檔案，但唔係真正嘅業務入口；或者睇明咗局部代碼，但漏咗跨模塊嘅契約。
第二係驗證不足
佢改完之後，如果唔知應該跑邊個測試、邊個 lint、邊個類型檢查，就只係畀個是旦嘅修改。
第三係權限失控
真實項目入面，裝依賴、改數據庫、訪問網絡、刪檔案、執行遷移呢啲命令，唔係全部適合自動走，一定要有明確邊界。
Harness 嘅對應關係表
如果你用開 Claude Code，可能會習慣 CLAUDE.md、Hooks、Skills 呢啲概念。換成 Codex 嘅時候，唔可以就咁改名，要睇清楚真正嘅對應方式。
- 1 項目長期說明：Claude Code 用 CLAUDE.md，Codex 用 AGENTS.md
- 2 本地編碼代理：Claude Code CLI 對應 Codex CLI / IDE 擴展 / App
- 3 自動前後置動作：Claude Code 用 Hooks，Codex 用腳本、測試命令、CI
- 4 可複用能力包：Claude Code 用 Skills/插件，Codex 用 skills/plugins
- 5 外部系統連接：Claude Code 用 MCP，Codex 用 MCP/connector/plugin
- 6 代碼理解入口：Claude Code 用 Code Map/LSP，Codex 用 repo 自帶 code map、rg、語言工具
- 7 並行任務：Claude Code 用 Subagents，Codex 用 App 多 agent、worktree、雲端任務
- 8 安全邊界：Claude Code 有權限模式，Codex 用 approval mode、sandbox、workspace 權限
六層 Harness 詳細搭建法
第一層係寫好 AGENTS.md。呢份文件係俾 Codex 嘅項目說明書，要答清楚幾個具體問題：項目點樣啟動、代碼點樣組織、任務點樣驗證、改動有咩邊界、團隊偏好嘅實現方式。唔好寫成企業文化手冊或者塞滿過期背景。
AGENTS.md嘅價值：將每次都要交代嘅上下文變成 Codex 每次都能睇到嘅默認規則
第二層係 Code Map。大型代碼庫最浪費 token 嘅動作係由零開始周圍翻檔案。Code Map 係一張粗粒度地圖，話畀 Codex 核心模塊喺邊、請求點樣入、數據模型喺邊、業務規則分散喺邊啲檔案、測試對應邊啲目錄。最好用腳本生成，例如 rg --files 加語言分析工具。
實用嘅 Code Map 包含 Web 入口、API 入口、驗證命令、高風險區域
第三層係將命令變成可調用工具。大型項目唔好淨係話「修呢個 bug」，而係畀佢可執行嘅工具鏈，例如 npm run test:changed、npm run lint:fix、npm run codemap。呢啲命令令 Codex 可以好似工程師咁循環：睇上下文、定位檔案、小步修改、運行驗證、跟報錯繼續修。
第四層係權限要分場景。做代碼閲讀、方案評審時可以只讀；做小範圍重構時可以自動編輯檔案但命令仍要審批；做長任務、修構建、補測試時，就要畀佢喺受控 sandbox 或者獨立 worktree 入面做更高自動化。最重要嘅規則：權限提升一定要同隔離環境捆綁。
權限提升必須連同獨立分支、worktree、可回滾環境一齊出現
第五層係 Skills、插件同 MCP 要用喺刀刃上。唔好為咗多而堆工具，應該圍繞任務鏈路配置。例如經常寫前端就準備瀏覽器驗證、截圖檢查；經常處理 PR 就準備 GitHub 上下文、CI 日誌；經常查內部系統就通過穩定接口連接。工具越貼近真實流程，Codex 越容易產出可合併嘅結果。
工具越似展示品，越容易變成上下文噪音
第六層係用 worktree 拆任務。大型項目好多需求包含幾條線：理解架構、改後端、改前端、補測試、修 CI。呢啲任務唔一定要串行塞畀同一個 Codex 會話，可以拆到唔同 worktree 或並行 agent，咁樣上下文更乾淨，回滾都更容易。
四步實施路線圖
第一，補齊項目說明：創建 AGENTS.md，淨係寫最關鍵嘅結構、命令、邊界同風格，先覆蓋八成高頻任務。
AGENTS.md唔好追求一次寫完，先覆蓋八成高頻任務
第二，建立 Code Map：手寫第一版都得，關鍵係令 Codex 快速知道從邊度開始讀、邊啲地方高風險、驗證命令係咩。
第三，固化驗證命令：將 lint、typecheck、unit test、e2e 整理成穩定腳本。命令越穩定，Codex 越能夠閉環。
第四，按風險配置權限：閲讀任務用只讀，細改動用自動編輯，長任務放 sandbox 或 worktree 隔離環境，高風險命令保留人工確認。呢四步做曬之後，Harness 就大致成形。
好多人第一次用 Codex，都會由一個好直接嘅期待開始：
將需求掟入去，等佢自己讀項目、改代碼、跑測試。
細項目入面，咁樣通常都行得通。
去到真實業務代碼庫，情況就會變複雜。
目錄多、歷史包袱重、測試慢、隱式約定多、權限邊界複雜。Codex 再勁，都需要先知道：呢個項目點樣讀、點樣改、點樣驗證、邊啲地方唔可以掂。
呢個就係大型項目入面最重要嘅概念：先搭好 Harness，再俾 Codex 開工。
Harness 可以理解成俾 AI 編程 agent 準備嘅一套工程化工作台。
佢唔止係一個提示詞，亦唔止係一個配置文件。
佢包括項目說明、代碼地圖、常用命令、自動化腳本、權限策略、外部工具、驗證流程，以及團隊沉澱落嚟嘅工作規則。
對 Codex 嚟講，Harness 嘅目標好清楚：
令 Codex 少啲估，多啲驗證，將每次任務都放入可複用嘅工程流程入面。
大項目嘅瓶頸
喺細項目入面，Codex 可以直接掃一次目錄，好快揾到入口。
喺大型項目入面，直接將問題掟俾模型，容易出現三類問題。
第一類係上下文錯位。
Codex 可能揾咗個名相似嘅文件，但揾唔啱真正嘅業務入口；亦可能睇明咗局部代碼，但漏咗跨模塊契約。
第二類係驗證不足。
佢改完代碼之後，如果唔知應該跑邊個測試、邊個 lint、邊個類型檢查，就只能畀出表面合理嘅修改。
第三類係權限失控。
真實項目入面唔係所有命令都適合自動跑。安裝依賴、改數據庫、訪問網絡、刪除文件、執行遷移，都需要明確邊界。
所以大型項目嘅關鍵，唔係每次都寫更長嘅 prompt。
關鍵係將項目知識沉澱成 Codex 每次都可以讀取同調用嘅環境。
Codex 版 Harness 係點樣
如果原本用緊 Claude Code，好多教學都會圍繞 CLAUDE.md、Hooks、Skills、插件、MCP、LSP、子 agent 同 Code Map 嚟講。
換成 Codex 嗰陣，唔可以照搬呢啲名。
Codex 入面更真實嘅對應方式係呢幾層：
CLAUDE.md | AGENTS.md | |
rg、語言工具、類型檢查、索引腳本 | ||
呢張表嘅重點係：Codex 唔係將 Claude Code 嘅配置文件改個名就搞掂。
真正要遷移嘅係方法論：將隱性嘅項目知識變成顯性嘅工作流程。
第一層：寫好 AGENTS.md
大型項目用 Codex，最先應該補嘅文件係 AGENTS.md。
佢相當於畀 Codex 嘅項目說明書。
唔好將佢寫成企業文化手冊，亦唔好塞滿過期背景。
佢應該回答幾個具體問題：
項目點樣啟動。
例如前端、後端、數據庫、依賴安裝、環境變量示例。
代碼點樣組織。
話俾 Codex 知邊啲目錄係業務核心，邊啲係生成物，邊啲係歷史代碼，邊啲文件唔好手動改。
任務點樣驗證。
將最常用嘅命令寫清楚：
npm run lint
npm run typecheck
npm test
npm run test:e2e如果項目係 Python、Go、Rust、Java，都應該換成真實命令。
改動有咩邊界。
例如唔好改公共 API、唔好重寫數據庫遷移歷史、唔好修改生成文件、唔好繞過權限校驗。
團隊偏好嘅實現方式。
例如組件寫法、錯誤處理、日誌規範、測試風格、提交信息格式。
AGENTS.md 嘅價值在於：將每次都要交代嘅上下文，變成 Codex 每次入項目都可以見到嘅默認規則。
第二層：畀 Codex 一張 Code Map
大型代碼庫最浪費 token 嘅動作，係俾 AI 從零開始周圍揾文件。
Code Map 嘅作用，係畀 Codex 一張粗粒度地圖。
佢唔需要記錄每一行代碼。
佢需要話俾 Codex 知：
核心模塊喺邊度；
請求從邊度入嚟；
數據模型喺邊度；
業務規則分散喺邊啲文件；
測試對應邊啲目錄；
常見任務應該從邊啲入口開始查。
一個實用嘅 Code Map 可以係咁樣：
# Code Map
## Web 入口
- apps/web/src/app: Next.js App Router 頁面
- apps/web/src/components: 可複用 UI 組件
- apps/web/src/lib/api.ts: 前端 API client
## API 入口
- apps/api/src/routes: HTTP routes
- apps/api/src/services: 業務服務
- apps/api/src/db: 數據訪問和 schema
## 驗證命令
- npm run lint
- npm run typecheck
- npm run test -- --runInBand
## 高風險區域
- apps/api/src/db/migrations: 不要改歷史遷移
- packages/contracts: 改動會影響前後端契約更好嘅做法，係將 Code Map 嘅生成做成腳本。
例如用 rg --files、語言分析工具、依賴圖工具、測試覆蓋率輸出，生成一份 docs/code-map.md。
然後在 AGENTS.md 入面寫清楚：
Before making cross-module changes, read docs/code-map.md first.
If docs/code-map.md looks stale, run npm run codemap.咁樣 Codex 每次處理複雜任務嘅時候，就有一個穩定嘅入口。
第三層：將命令變成可調用工具
大型項目入面，唔好淨係話俾 Codex 聽「整返呢個 bug」。
更有效嘅方式係畀佢可執行嘅工具鏈。
比如：
npm run test:changed
npm run lint:fix
npm run codemap
npm run db:check
npm run storybook:test呢啲命令睇落普通，但對 Codex 好關鍵。
因為 Codex 嘅強項唔係無中生有保證正確，而係讀代碼、改文件、運行命令、根據反饋繼續整。
如果項目冇提供穩定命令，Codex 就會將大量時間花喺估驗證方式度。
如果項目已經將驗證路徑做成腳本，Codex 就可以更像一個工程師咁循環：
閲讀上下文；
定位相關文件；
小步修改；
運行驗證；
根據報錯繼續整；
最後總結改動同風險。
呢個都係 Harness 嘅核心價值。
第四層：權限要分場景
Codex 可以喺本地終端、IDE、Codex App 或雲端任務入面工作。
唔同場景要畀唔同權限。
做代碼閲讀、方案評審、風險分析嗰陣，可以俾佢唯讀。
做小範圍重構嗰陣，可以允許自動編輯文件，但命令執行仍然保留審批。
做長任務、整構建、補測試嗰陣，可以喺受控 sandbox 或獨立 worktree 入面畀更高自動化權限。
最重要嘅一條規則係：
權限提升必須同隔離環境一齊出現。
即係話，想俾 Codex 自己跑更長嘅任務，就將佢放喺獨立分支、獨立 worktree、可回滾嘅環境入面。
唔好俾佢喺主工作區入面無邊界執行高風險命令。
第五層：將 Skills、插件同 MCP 用喺刀口上
Codex 嘅能力可以透過 skills、plugins、MCP、connector 擴展。
但大項目入面唔好為咗「工具多」而堆工具。
應該圍繞任務鏈路配置工具。
如果成日寫前端，就準備瀏覽器驗證、截圖檢查、設計規範同組件庫說明。
如果成日處理 PR，就準備 GitHub 上下文、CI 日誌、review 規則同測試命令。
如果成日查內部系統，就透過 MCP 或 connector 畀 Codex 一個穩定接口，而唔係俾佢估網頁點樣㩒。
如果成日做數據處理，就將表格、文檔、導出腳本整理成固定入口。
工具越貼近真實流程，Codex 越容易產出可以合併嘅結果。
工具越似展示品，越容易變成上下文噪音。
第六層：用 worktree 分拆任務
大型項目入面，好多需求睇落係一件事，實際上包含好幾條線：
理解現有架構；
改後端接口；
改前端頁面；
補測試；
整返 CI；
寫遷移說明。
呢啲任務唔一定要串行塞俾同一個 Codex 會話。
Codex App 同雲端任務更適合將任務拆去唔同 worktree 或並行 agent 入面。
例如：
一個 agent 淨係負責梳理代碼路徑同風險；
一個 agent 負責後端改動；
一個 agent 負責前端改動；
一個 agent 負責測試同 review。
最後再將結果合併返一個主線。
咁樣做嘅好處係上下文更乾淨，回滾都更容易。
一條可執行嘅實施路線圖
如果你真係想將 Codex 用喺大型項目，可以按四步嚟行。
第一步：補齊項目說明。
創建 AGENTS.md，淨係寫最關鍵嘅項目結構、命令、邊界同風格。
唔好追求一次過寫曬。
先覆蓋 80% 高頻任務。
第二步：建立 Code Map。
手寫第一版都得。
關鍵係令 Codex 可以快速知道：從邊度開始讀，邊啲地方高風險，驗證命令係咩。
第三步：固化驗證命令。
將 lint、typecheck、unit test、e2e、構建檢查整理成穩定腳本。
命令越穩定，Codex 越能夠閉環。
第四步：按風險配置權限。
閲讀任務用唯讀。
細改動用自動編輯。
長任務放喺 sandbox、worktree 或雲端隔離環境。
高風險命令保留人工確認。
一個好用嘅 Codex 任務模板
以後俾 Codex 派大型項目任務，可以直接用呢個結構：
目標：
修復訂單詳情頁金額展示錯誤。
範圍：
只改 apps/web 和 packages/contracts，除非發現後端契約確實錯誤。
上下文：
先閲讀 AGENTS.md 和 docs/code-map.md。
重點查看訂單詳情頁、金額格式化工具、相關測試。
約束：
不要修改數據庫遷移。
不要改公共 API 命名。
保持現有 UI 風格。
驗證：
運行 npm run lint、npm run typecheck、npm test -- order。
交付：
說明改了哪些文件、驗證結果、剩餘風險。呢個模板嘅價值，唔在於格式靚唔靚。
佢將 Codex 最需要嘅五件事講清楚曬：
目標、範圍、上下文、約束、驗證。
你有冇將項目變成一個適合 AI agent 工作嘅環境。
AGENTS.md 負責長期規則。
Code Map 負責快速導航。
腳本負責驗證閉環。
Skills、插件同 MCP 負責外部能力。
worktree、審批同 sandbox 負責安全邊界。
呢啲嘢加埋，就係 Codex 版 Harness。
當 Harness 搭起咗之後，Codex 先可以從「幫我改幾行代碼嘅助手」，變成能夠喺真實項目入面持續交付嘅工程 agent。
我係陳寶，專注 AI 編程商業化實戰同副業變現，如果你都對呢樣嘢有興趣，可以加入我哋 2000 人嘅知識星球學習各種 AI 玩法同副業變現，一個人可能行得快，但一班人就可以行得更遠！！！
多謝你嘅觀看，如果覺得唔錯，順手點個讚、在看、轉發三連啦，
你嘅支持係我最大嘅動力
很多人第一次用 Codex，都會從一個很直接的期待開始：
把需求扔進去，讓它自己讀項目、改代碼、跑測試。
小項目裏，這樣經常能跑通。
到了真實業務代碼庫，情況會變複雜。
目錄多、歷史包袱重、測試慢、隱式約定多、權限邊界複雜。Codex 再強，也需要先知道：這個項目怎麼讀、怎麼改、怎麼驗證、哪些地方不能碰。
這就是大型項目裏最重要的概念：先搭 Harness，再讓 Codex 幹活。
Harness 可以理解成給 AI 編程代理準備的一套工程化工作台。
它不只是一個提示詞，也不只是一個配置文件。
它包括項目說明、代碼地圖、常用命令、自動化腳本、權限策略、外部工具、驗證流程，以及團隊沉澱下來的工作規則。
對 Codex 來說，Harness 的目標很清楚：
讓 Codex 少猜一點，多驗證一點，把每次任務都放進可複用的工程流程裏。
大項目的瓶頸
在小項目裏，Codex 可以直接掃一遍目錄，很快找到入口。
在大型項目裏，直接把問題丟給模型，容易出現三類問題。
第一類是上下文錯位。
Codex 可能找到了名字相似的文件，卻沒有找對真正的業務入口；也可能看懂了局部代碼，卻漏掉跨模塊契約。
第二類是驗證不足。
它改完代碼後，如果不知道該跑哪個測試、哪個 lint、哪個類型檢查，就只能給出看似合理的修改。
第三類是權限失控。
真實項目裏不是所有命令都適合自動跑。安裝依賴、改數據庫、訪問網絡、刪除文件、執行遷移，都需要明確邊界。
所以大型項目的關鍵，不是每次都寫更長的 prompt。
關鍵是把項目知識沉澱成 Codex 每次都能讀取和調用的環境。
Codex 版 Harness 長什麼樣
如果原來使用 Claude Code，很多教程會圍繞 CLAUDE.md、Hooks、Skills、插件、MCP、LSP、子代理和 Code Map 展開。
換成 Codex 時，不能照搬這些名字。
Codex 裏更真實的對應方式是這幾層：
CLAUDE.md | AGENTS.md | |
rg、語言工具、類型檢查、索引腳本 | ||
這張表的重點是：Codex 不是把 Claude Code 的配置文件改個名字就完事。
真正要遷移的是方法論：把隱性的項目知識變成顯性的工作流。
第一層：寫好 AGENTS.md
大型項目使用 Codex，最先應該補的文件是 AGENTS.md。
它相當於給 Codex 的項目說明書。
不要把它寫成企業文化手冊，也不要塞滿過期背景。
它應該回答幾個具體問題：
項目怎麼啓動。
例如前端、後端、數據庫、依賴安裝、環境變量示例。
代碼怎麼組織。
告訴 Codex 哪些目錄是業務核心，哪些是生成物，哪些是歷史代碼，哪些文件不要手動改。
任務怎麼驗證。
把最常用的命令寫清楚：
npm run lint
npm run typecheck
npm test
npm run test:e2e如果項目是 Python、Go、Rust、Java，也應該換成真實命令。
改動有什麼邊界。
例如不要改公共 API、不要重寫數據庫遷移歷史、不要修改生成文件、不要繞過權限校驗。
團隊偏好的實現方式。
例如組件寫法、錯誤處理、日誌規範、測試風格、提交信息格式。
AGENTS.md 的價值在於：把每次都要交代的上下文，變成 Codex 每次進項目都能看到的默認規則。
第二層：給 Codex 一張 Code Map
大型代碼庫最浪費 token 的動作，是讓 AI 從零開始到處翻文件。
Code Map 的作用，是給 Codex 一張粗粒度地圖。
它不需要記錄每一行代碼。
它需要告訴 Codex：
核心模塊在哪裏；
請求從哪裏進來；
數據模型在哪裏；
業務規則分散在哪些文件；
測試對應哪些目錄；
常見任務應該從哪些入口開始查。
一個實用的 Code Map 可以長這樣：
# Code Map
## Web 入口
- apps/web/src/app: Next.js App Router 頁面
- apps/web/src/components: 可複用 UI 組件
- apps/web/src/lib/api.ts: 前端 API client
## API 入口
- apps/api/src/routes: HTTP routes
- apps/api/src/services: 業務服務
- apps/api/src/db: 數據訪問和 schema
## 驗證命令
- npm run lint
- npm run typecheck
- npm run test -- --runInBand
## 高風險區域
- apps/api/src/db/migrations: 不要改歷史遷移
- packages/contracts: 改動會影響前後端契約更好的做法，是把 Code Map 的生成做成腳本。
例如用 rg --files、語言分析工具、依賴圖工具、測試覆蓋率輸出，生成一份 docs/code-map.md。
然後在 AGENTS.md 裏寫清楚：
Before making cross-module changes, read docs/code-map.md first.
If docs/code-map.md looks stale, run npm run codemap.這樣 Codex 每次處理複雜任務時，就有一個穩定入口。
第三層：把命令變成可調用工具
大型項目裏，不要只告訴 Codex“修一下這個 bug”。
更有效的方式是給它可執行的工具鏈。
比如：
npm run test:changed
npm run lint:fix
npm run codemap
npm run db:check
npm run storybook:test這些命令看起來普通，但對 Codex 很關鍵。
因為 Codex 的強項不是憑空保證正確，而是讀代碼、改文件、運行命令、根據反饋繼續修。
如果項目沒有提供穩定命令，Codex 就會把大量時間花在猜測驗證方式上。
如果項目已經把驗證路徑做成腳本，Codex 就能更像一個工程師一樣循環：
閲讀上下文；
定位相關文件；
小步修改；
運行驗證；
根據報錯繼續修；
最後總結改動和風險。
這也是 Harness 的核心價值。
第四層：權限要分場景
Codex 可以在本地終端、IDE、Codex App 或雲端任務裏工作。
不同場景要給不同權限。
做代碼閲讀、方案評審、風險分析時，可以讓它只讀。
做小範圍重構時，可以允許自動編輯文件，但命令執行仍然保留審批。
做長任務、修構建、補測試時，可以在受控 sandbox 或獨立 worktree 裏給更高自動化權限。
最重要的一條規則是：
權限提升必須和隔離環境一起出現。
也就是說，想讓 Codex 自己跑更長的任務，就把它放到獨立分支、獨立 worktree、可回滾的環境裏。
不要讓它在主工作區裏無邊界執行高風險命令。
第五層：把 Skills、插件和 MCP 用在刀刃上
Codex 的能力可以通過 skills、plugins、MCP、connector 擴展。
但大項目裏不要為了“工具多”而堆工具。
應該圍繞任務鏈路配置工具。
如果經常寫前端，就準備瀏覽器驗證、截圖檢查、設計規範和組件庫說明。
如果經常處理 PR，就準備 GitHub 上下文、CI 日誌、review 規則和測試命令。
如果經常查內部系統，就通過 MCP 或 connector 給 Codex 一個穩定接口，而不是讓它猜網頁怎麼點。
如果經常做數據處理，就把表格、文檔、導出腳本整理成固定入口。
工具越貼近真實流程，Codex 越容易產出可合併的結果。
工具越像展示品，越容易變成上下文噪音。
第六層：用 worktree 拆任務
大型項目裏，很多需求看起來是一件事，實際上包含好幾條線：
理解現有架構；
改後端接口；
改前端頁面；
補測試；
修 CI；
寫遷移說明。
這些任務不一定要串行塞給同一個 Codex 會話。
Codex App 和雲端任務更適合把任務拆到不同 worktree 或並行 agent 裏。
例如：
一個 agent 只負責梳理代碼路徑和風險；
一個 agent 負責後端改動；
一個 agent 負責前端改動；
一個 agent 負責測試和 review。
最後再把結果合併回一個主線。
這樣做的好處是上下文更乾淨，回滾也更容易。
一條可執行的實施路線圖
如果你想把 Codex 真正用進大型項目，可以按四步走。
第一步：補齊項目說明。
創建 AGENTS.md，只寫最關鍵的項目結構、命令、邊界和風格。
不要追求一次寫完。
先覆蓋 80% 高頻任務。
第二步：建立 Code Map。
手寫第一版也可以。
關鍵是讓 Codex 能快速知道：從哪裏開始讀，哪些地方高風險，驗證命令是什麼。
第三步：固化驗證命令。
把 lint、typecheck、unit test、e2e、構建檢查整理成穩定腳本。
命令越穩定，Codex 越能閉環。
第四步：按風險配置權限。
閲讀任務用只讀。
小改動用自動編輯。
長任務放到 sandbox、worktree 或雲端隔離環境。
高風險命令保留人工確認。
一個好用的 Codex 任務模板
以後給 Codex 派大型項目任務，可以直接用這個結構：
目標：
修復訂單詳情頁金額展示錯誤。
範圍：
只改 apps/web 和 packages/contracts，除非發現後端契約確實錯誤。
上下文：
先閲讀 AGENTS.md 和 docs/code-map.md。
重點查看訂單詳情頁、金額格式化工具、相關測試。
約束：
不要修改數據庫遷移。
不要改公共 API 命名。
保持現有 UI 風格。
驗證：
運行 npm run lint、npm run typecheck、npm test -- order。
交付：
說明改了哪些文件、驗證結果、剩餘風險。這個模板的價值，不在於格式漂亮。
它把 Codex 最需要的五件事講清楚了：
目標、範圍、上下文、約束、驗證。
你這有沒有把項目變成一個適合 AI agent 工作的環境。
AGENTS.md 負責長期規則。
Code Map 負責快速導航。
腳本負責驗證閉環。
Skills、插件和 MCP 負責外部能力。
worktree、審批和 sandbox 負責安全邊界。
這些東西加起來，就是 Codex 版 Harness。
當 Harness 搭起來之後，Codex 才能從“幫我改幾行代碼的助手”，變成能在真實項目裏持續交付的工程代理。
我是陳寶，專注AI編程商業化實戰和副業變現，如果你也對此感興趣，可以加入我們2000人的知識星球學習各種AI玩法和副業變現，一個人可能走的快，一羣人卻能走的更遠！！！
感謝你的觀看，如果覺得不錯，隨手點個贊、在看、轉發三連吧，
你的支持是我最大的動力