Codex 保姆級入門：從安裝、權限到第一次讓 AI 真正替你幹活
整理版優先睇
Codex 入門指南：由安裝到第一次真正用 AI 幫你幹活
呢篇文章係由一位前 Python 程序員、而家搞 AI 編程出海創業嘅作者寫嘅。佢自己成日用 Codex，仲話用得多過 ClaudeMax，覺得 Codex 係一個可以幫你推進任務嘅 AI agent，而唔係淨係畀你問幾句。佢寫呢篇文嘅目的，係想幫更多人用起 Codex，唔好再停留喺「複製 code 去 ChatGPT 解釋」或者「IDE 補幾行函數」嘅階段。
成篇文章嘅結構分咗四層：先了解 Codex 係咩、主界面同權限；然後跑通第一條任務，學寫提示詞、睇 diff、跑測試；再理解 Browser、Computer Use、Appshots、手機、多設備同 SSH；最後睇 IDE、CLI、Cloud、AGENTS.md 同 7 天路線。作者嘅整體結論係：AI 編程嘅關鍵係工作流，而唔係單一工具；新手最緊要係由一個安全嘅 demo 項目開始，逐步建立對 Codex 嘅信任，最後沉澱項目規則。佢特別強調，唔好神化 AI，亦唔好因為怕錯而唔用，最重要係養成睇 diff 同跑測試嘅習慣。
呢篇文適合任何想用 AI 幫手寫 code 嘅人，無論係程序員、PM、設計師定營運。作者提供咗好多實用貼士，包括 12 個常見錯誤同 7 天路線，令你可以由零開始熟習 Codex。總括而言，呢篇係一篇好高質嘅 Codex 入門攻略，值得收藏慢慢跟住做。
- Codex 係一個真正嘅 coding agent，可以喺唔同入口（App、IDE、CLI、Cloud）入面幫你推進任務，而唔係單次問答。佢可以讀你個項目、改文件、跑命令、睇網頁效果，甚至跨設備操作。
- 新手第一步一定要用一個安全嘅 demo 項目，先學識 Codex 點樣理解任務、改咩文件、跑咩命令、點樣驗證完成。目標係睇明佢點做，而唔係一嚟就搞生產項目。
- 寫提示詞要好似寫需求文檔咁清楚：背景、目標、範圍、約束同驗收條件。高風險場景（例如改支付、登錄、數據庫）要先叫 Codex 出方案，等你確認先好畀佢改。
- 每次 Codex 做完，你一定要睇 diff 同跑測試，留意邊界條件、有冇改到範圍外、有冇新增依賴、有冇留低除錯 code。前端任務更加要用 Browser 睇截圖驗收，唔好信曬佢話「code 改完」。
- 作者推薦 7 天路線：第 1 日只讀項目，第 2 日改文檔，第 3 日修低風險 bug，第 4 日做 code review，第 5 日做前端瀏覽器驗收，第 6 日用 IDE/CLI，第 7 日寫 AGENTS.md 沉澱規則。呢個路線可以幫你逐步建立 AI 編程工作流。
Codex 官方網站
OpenAI Codex 開發者頁面，包含所有入口同文檔。
Codex Quickstart
官方快速開始指南，適合新手跟住做。
Codex App
Codex 桌面應用，適合管理任務同多設備。
Codex CLI
喺終端用嘅 Codex，開源，適合終端愛好者。
Codex 係咩？入口分工
Codex 唔係一個單一按鈕，而係一套 AI 編程工作流。佢有至少四種常見入口：Codex App、Codex Web/Cloud、Codex IDE Extension 同 Codex CLI。
Codex 係一個真正嘅 coding agent，唔係淨係畀你問幾句。
- App：管任務，適合管理任務、睇進度、多設備。
- IDE：睇代碼，適合貼住 code 現場改。
- CLI：跑命令，適合終端愛好者。
- Browser：睇網頁效果，前端必用。
- Computer Use：操作桌面應用，但要慎用。
- Cloud：後台跑長任務，適合 GitHub 倉庫同 PR。
新手第一課：安全項目同第一次任務
新手第一件事：準備一個安全嘅 demo 項目，唔好直接攞最重要嘅項目試。目標係睇明 Codex 點理解你個任務、會改邊啲文件、會跑邊啲命令、最後點證明自己做咗。
小任務、小權限、強驗收
- 1 請先閲讀呢個項目嘅 README、package.json 同主要入口文件。只做分析，唔改 code。
- 2 請修復 README 裏面「本地啟動步驟」唔清楚嘅問題。只改 README.md。
- 3 請找到項目入面負責登錄頁表單校驗嘅 code，只修復錯誤提示文案唔統一嘅問題。改完跑現有 lint 或測試。
背景：呢個係一個咩項目，而家遇到咩問題。
目標：我希望你完成咩。
範圍：可以改邊啲 files，唔可以鬱邊啲 files。
約束：唔好引入新依賴，唔好改公開 API，唔好改數據庫結構。
驗收：完成後請話我知改咗邊啲 files，並運行邊啲測試或檢查命令。進階功能：Browser、Computer Use、多任務、自動化
Browser 對前端好重要。每次前端任務都要叫 Codex 打開瀏覽器截圖驗收，唔好淨係話 code 改完。Computer Use 可以操作桌面應用，但權限要慎重，唔好畀佢掂支付、轉帳、刪除數據呢啲敏感操作。
前端一定要睇頁面
Computer Use 要慎重開權限
- 多任務適合：文檔類、檢查類、小修類、分析類。
- 多任務唔適合：大規模重構、數據庫遷移、支付權限鏈路、同時改同一塊核心 code。
新手 7 天路線同常見錯誤
作者提供咗 7 天路線同 12 個常見錯誤。我哋揀幾個重點嚟講。
- 1 第 1 日：只讀項目，唔改 code，睇明結構同建議。
- 2 第 2 日：改文檔，例如 README。
- 3 第 3 日：修一個低風險 bug。
- 4 第 4 日：做 code review，剩係畀意見。
- 5 第 5 日：做前端瀏覽器驗收。
- 6 第 6 日：開始用 IDE 或 CLI。
- 7 第 7 日：寫 AGENTS.md 沉澱規則。
先拆成：先讀項目並給重構建議，不改代碼
唔好因為怕錯而唔用
- 常見錯誤 1：一嚟就做大項目，應該先拆細。
- 常見錯誤 2：唔畀驗收條件，令 AI 亂估。
- 常見錯誤 3：唔睇 diff，最危險。
- 常見錯誤 4：直接喺生產項目開大權限。
- 常見錯誤 5：多任務改同一批文件。
- 常見錯誤 6：將 Codex 當搜索引擎，佢嘅價值係喺項目上下文執行。
- 常見錯誤 7：唔沉澱項目規則。
- 常見錯誤 8：畀佢操作敏感後台。
最近呢兩個月，我用 Codex 嘅時間真係好長，仲多過我自己用 ClaudeMax 20X，唔係偶然開嚟問一句「呢段 code 點改」，而係每日都當佢係一個真係做得嘢嘅 AI Engineer 咁用。
因為 code 嘅問題同 CLI 命令嘅事，好多人見到就怕，但最近 Codex 幾次更新令編程變得簡單咗，甚至好玩咗，變成一個任何人都玩得嘅工具，令我覺得有必要寫篇長文等更多人用起嚟。
以前好多人理解 AI 編程，大概停留喺兩個畫面：
第一，將 code 複製入 ChatGPT，叫佢解釋嚇。
第二，喺 IDE 開一個 code 補全工具，叫佢補幾行 function。
但 Codex 唔係「幫你寫一段 code」，而係「幫你推進一個任務」，係真正嘅人人用得嘅 agent。
呢篇我由 0 到 1 咁寫，內容有啲長，適合收藏慢慢學。
我會將官方影片裏面嘅流程截圖、我自己電腦嘅 Codex 設定截圖、之前手機同多設備嘅截圖全部串埋一齊。你唔需要一開始就明曬所有概念，先知道每個入口係做乜、第一次任務點樣發、權限點樣開、結果點樣驗收，就夠。
你首先將呢條 link 行通，比起一開始研究曬所有進階功能更加重要。
全文你可以分四層嚟睇：
第一層，先睇明 Codex 係乜、主界面同權限。
第二層，行通第一條任務，學識點寫提示詞、睇 diff、行測試。
第三層，再理解 Browser、Computer Use、Appshots、手機、多設備同 SSH。
第四層，最後先睇 IDE、CLI、Cloud、AGENTS.md 同 7 日路線。
一、首先諗清楚 Codex
Codex 唔係一個單獨按鈕。
佢而家更加似一套 AI 編程 workflow，至少有四種常見入口：
1. Codex App：適合管理任務、睇進度、多設備、遠程項目同埋一啲本機操作。 2. Codex Web / Cloud：適合叫佢喺雲端後台行任務，尤其係 GitHub 倉庫、PR、並行任務。 3. Codex IDE Extension：適合喺 VS Code、Cursor、Windsurf、JetBrains 呢類編輯器入面貼住 code 即場做嘢。 4. Codex CLI：適合喺 terminal 入面用，俾佢當前目錄，叫佢讀 code、改 code、行命令。
OpenAI 官方喺 Codex 首頁俾嘅定位好直接：佢係「everywhere you code」呢類 coding agent。唔係淨係喺一個地方用得，而係盡量出現喺你寫 code、審 code、行 project、睇網頁、連遠程機器嘅地方。
我建議新手唔好一開始就糾結「到底用 App 定 CLI」。
你先記一個簡單分工：
• App：管任務。 • IDE：睇 code。 • CLI：行命令。 • Browser：睇網頁效果。 • Computer Use：操作桌面應用。 • Cloud：後台行長任務。
咁樣理解之後，Codex 就唔會亂。
好多工具亂，係因為佢哋得一個入口，但想乜都做曬。Codex 而家嘅方向係反過嚟：同一個 agent，進入唔同嘅工作現場。
以前 AI 係聊天窗口，而家係直接幫你拎結果。
二、新手唔好急，先準備一個安全項目
好多兄弟第一次開 Codex，最容易犯嘅錯係：直接拎自己最重要嘅 project 嚟試。
呢個唔建議。
唔係因為 Codex 唔得，而係因為你仲未知道佢會點樣讀上下文、點樣行命令、邊度需要你審批。
第一日最好拎一個安全項目。
比如：
• 一個 demo repo • 一個自己寫嚟玩嘅 script • 一個靜態頁面 • 一個文檔目錄 • 一個唔涉及金鑰、唔涉及真實用戶數據嘅小項目
目標唔係即刻叫 Codex 幫你搞掂生產問題。
目標係睇明 4 件事：
1. 佢點樣理解你嘅任務。 2. 佢會改邊啲檔案。 3. 佢會行邊啲命令。 4. 佢最後點樣證明自己做曬。
新手第一日將呢 4 件事搞清楚，之後就會順好多。
官方 Quickstart 入面都將入口分為 App、IDE extension、CLI、Cloud 幾類。你可以由任何入口開始，但如果你係第一次接觸，我建議先用 Codex App，因為佢可以俾你比較完整咁睇到任務、上下文、權限同行動過程。
留意呢張圖。
新手最應該先睇嘅唔係「點樣令佢更勁」，而係呢啲權限：
• 自動審核開唔開。 • 係咪允許完全存取。 • 幾時需要你審批。 • 而家嘅 workspace 係邊個。 • 佢可唔可以操作本機。
AI 編程真正進入下一階段之後，權限會變成一個核心問題。
唔俾權限，AI 只能陪傾偈。
權限俾得太大，自己又唔睇 diff，就好易出問題。
正確做法唔係一刀切，而係按任務俾權限。
第一日就記一句話：
細任務、細權限、強驗收。
隨住你對 Codex 能力邊界熟咗，就可以放開權限，咁樣就唔使每次確認浪費時間。
三、主界面點樣睇
Codex 嘅主界面睇落唔複雜，但新手打開之後會矇。
因為你唔知到底應該睇邊度。
我按我嘅理解拆解一下。
左邊主要係項目同歷史任務。
你可以當佢係「我而家叫 Codex 管邊啲 workspace」。呢度會有唔同項目、唔同任務，亦會保留一啲歷史對話。
中間係當前任務 thread。
你發出嘅任務、Codex 嘅思考同行動過程、佢最後嘅結果，都會喺呢度展開。
右邊一般係環境資訊。
例如當前 workspace、模型、執行環境、上下文狀態、係咪啟用咗某啲能力。呢度決定咗 Codex 到底喺咩地方做嘢。
底部係輸入區。
呢個位好關鍵。
你會見到模型、權限、發送掣，以及當前任務可唔可以附加上下文。
我建議新手一開始唔好寫好長好散嘅 prompt。
先跟呢個 template：
背景：
這是一個什麼項目，現在遇到什麼問題。
目標：
我希望你完成什麼。
範圍：
可以改哪些文件，不能動哪些文件。
約束：
不要引入新依賴，不要改公開 API，不要改數據庫結構。
驗收：
完成後請告訴我改了哪些文件，並運行哪些測試或檢查命令。
呢個 template 其實係明確俾 AI 一啲方向，避免 AI 估你嘅想法，總之愈詳細效果愈好。
將 Codex 當成一個會犯錯、但執行力好強嘅臨時 Engineer。
隨住你同 AI 互動溝通愈多，後續 AI 就能俾到你想要嘅答案，當然如果冇，仲可以再發一條【內容】繼續補充。
四、第一次任務點樣發
第一次任務唔好太大。
唔好講：
幫我優化一下這個項目。呢種任務太虛。
你可以講：
請先閲讀這個項目的 README、package.json 和主要入口文件。
只做分析，不改代碼。
告訴我：
1. 這個項目是幹什麼的
2. 本地怎麼啓動
3. 測試命令是什麼
4. 你建議我下一步讓你做哪 3 個小任務
呢個任務特別適合做 Codex 嘅第一條任務。
原因好簡單：佢唔改 code，但可以令你睇到 Codex 點樣讀 project。
第二條任務可以再細啲：
請修復 README 裏“本地啓動步驟”不清楚的問題。
只改 README.md。
不要改代碼。
改完後給我總結改動。
第三條任務先開始掂 code：
請找到項目裏負責登錄頁表單校驗的代碼。
只修復錯誤提示文案不統一的問題。
不要改接口邏輯。
改完後運行現有 lint 或測試。
呢個先係比較穩陣嘅入門方式。
官方影片入面都睇到，Codex 嘅任務唔係一次性問答，而係圍繞一個 workspace 持續推進。
你可以補充上下文，可以叫佢改，可以叫佢撤回，可以叫佢解釋。
呢度有一個好重要嘅習慣：
唔好淨係睇最終答案。
你要睇佢中間做咗啲乜。
例如佢讀咗邊啲檔案、行咗邊啲命令、點解要改某個 function、測試失敗之後點樣處理。
Codex 真正有價值嘅地方，唔係最後嗰幾句總結，而係佢嘅執行過程可以追蹤。
五、點樣寫好任務 prompt
好多人用 AI 編程效果唔好，唔係模型唔得，而係任務寫得太差。
尤其係 Codex 呢啲真係改得 project 嘅工具，prompt 更加似需求文檔。
我俾一個最常用嘅結構：
你是這個項目裏的臨時工程師。
任務目標：
把用戶設置頁裏的保存按鈕，在請求中時顯示 loading，並禁止重複點擊。
上下文：
這個項目是 React + TypeScript。
設置頁在 src/pages/settings 目錄。
已有 Button 組件，優先複用，不要新造 UI 組件。
範圍：
可以修改 settings 頁面和相關 hook。
不要改接口層，不要改路由，不要改樣式系統。
驗收：
1. 保存中按鈕顯示 loading
2. 請求未結束前不能重複提交
3. 請求失敗後恢復按鈕狀態
4. 運行 npm run lint
5. 最後說明改了哪些文件
你睇，呢度冇玄學。
就係將「目標、上下文、範圍、驗收」講清楚。
如果係修 bug，可以咁樣寫：
請排查這個 bug，但先不要直接改代碼。
現象：
用戶在移動端點擊提交後，頁面偶爾沒有反饋。
我希望你先做：
1. 找到相關代碼路徑
2. 判斷可能原因
3. 給出 2-3 個修復方案
4. 推薦最小改動方案
等我確認後再實施。
呢類 prompt 好適合高風險場景。
你唔係唔俾 Codex 做嘢，而係先叫佢出方案。
等你確認咗，先叫佢鬱手。
呢個同帶新人一樣。
新人一上嚟就亂改，你一定唔放心。先叫佢讀 code、講判斷、列方案，你就放心好多。
六、做完之後，重點睇 diff 同測試
Codex 做完，唔代表你可以直接 merge。
呢度我講重啲。
新手一定要養成睇 diff 嘅習慣。
AI 寫 code 最怕三件事：
1. 睇落完成咗，但邊界冇處理。 2. 改動範圍擴大咗，將唔應該改嘅地方都改埋。 3. 測試冇行，或者行失敗咗但被忽略。
所以每次完成之後，你最少睇 5 樣嘢：
1. 改了哪些文件？
2. 有沒有改到任務範圍之外？
3. 有沒有新增依賴？
4. 有沒有跑 lint / test / build？
5. 有沒有留下調試代碼、假數據、敏感信息？
官方影片入面有一個畫面好典型，Codex 會俾出自檢同總結。
你可以繼續追問：
請按文件列出這次改動。
每個文件說明：
1. 為什麼改
2. 具體改了什麼
3. 有什麼風險
4. 用什麼命令驗證過
如果佢冇行測試，你就直接問：
你還沒有運行測試。
請先根據項目文檔找到測試命令。
如果沒有測試命令，請說明你能運行的最小驗證是什麼。呢一步好重要。
唔好因為 AI 好聰明，就將工程入面嘅基本動作丟低。
以前人寫 code 要 code review，而家 AI 寫 code 更加要 review。
呢度我嘅經驗係：細任務可以快啲，大任務一定要慢啲。
例如改 README、改文案、補 comment，風險好低，可以叫佢直接做。
但涉及俾錢、登入、權限、Database Migration、用戶數據、Production 部署，一定要叫佢先出方案，再逐步執行。
AI 編程唔係將人踢走。
AI 編程係將人從重複操作入面解放出嚟，但最後判斷仲喺人度。
七、多任務係 Codex 嘅強項
我而家用 Codex 最爽嘅地方之一，係多任務。
唔係一個任務完咗先開下一個，而係幾個互不影響嘅任務同時進行。
例如我可以同時叫佢做：
• 一個項目入面改 README。 • 另一個項目入面行測試失敗分析。 • 第三個項目入面檢查前端頁面。 • 第四個項目入面整理 issue。
當然，前提係任務之間唔好互相踩到。
如果兩個任務都喺改同一批檔案，就唔適合並行。
多任務適合呢幾類：
1. 文檔類：補 README、生成變更說明、整理接口說明。 2. 檢查類：行 lint、行測試、查失敗 log、揾潛在問題。 3. 小修類：統一文案、微調 style、刪冇用 code。 4. 分析類：理解一個陌生 module、揾入口、整理 call chain。
唔適合呢幾類：
1. 大規模架構重構。 2. Database Migration。 3. 俾錢同權限鏈路。 4. 多個任務同時改同一塊核心 code。
多任務嘅關鍵唔係「開好多個」，而係「拆得夠獨立」。
呢個同管理團隊一樣。
你唔可以叫 5 個人同時改同一個 function，然後期望結果自動變好。
八、自動化任務點樣理解
Codex 仲有 Automations。
呢個我建議新手第二階段先用。
首先將普通任務、diff、測試搞明白，再玩自動化。
自動化適合啲乜？
適合嗰啲「重複發生、規則清楚、結果可以檢查」嘅事。
比如：
• 每日檢查某個項目有冇 failing tests。 • 每星期整理一次依賴更新風險。 • 定期 scan 文檔入面過期嘅 link。 • 每日將某個 repo 嘅 issue 分類。 • 每星期生成一次項目變更摘要。
建立自動化時，最關鍵嘅係將任務寫清楚。
唔好寫：
每天幫我看看項目有沒有問題。呢啲太虛。
改成：
每天上午 10 點檢查這個倉庫：
1. 拉取最新主分支
2. 運行 npm run lint
3. 運行 npm test
4. 如果失敗，彙總失敗命令、錯誤摘要、疑似相關文件
5. 不要自動修改代碼，只給報告
呢個先叫自動化。
自動化入面有個坑：好多人鍾意叫佢「自動修」。
我建議初頭淨係叫佢「自動查」同「自動報」。
等你確認佢查得準，再逐步叫佢做低風險修復。
自動化好似一個每日準時返工嘅助理，你要先俾 SOP 佢。
我嘅習慣係將你同 AI 嘅要求沉澱成一個 workflow，後續 AI 可以跟住你嘅習慣執行，例如寫完要測試、測試要注意邊台 Server、測試完要出正式版等等，咁就唔容易走偏。
九、Browser：前端任務一定要睇頁面
如果你用 Codex 做前端，千祈唔好淨係睇 code。
前端最終係俾人睇嘅。
掣有冇迫埋一齊、Mobile 端有冇重疊、彈窗有冇遮住內容、顏色有冇睇唔清，呢啲問題唔係淨係睇 diff 睇得出嚟。
所以 Browser 好重要。
你可以叫 Codex 打開本地頁面，睇 screenshot，然後繼續改。
比如：
請啓動項目並打開本地頁面。
重點檢查：
1. 375px 移動端是否有文字重疊
2. 1440px 桌面端首屏是否正常
3. 按鈕文字是否溢出
4. 表單錯誤狀態是否清楚
發現問題後先截圖說明，再修改。
呢類任務好啱 Codex。
官方都有專門講前端同 Codex 嘅影片。
前端 workflow 大概係：
描述目標
→ Codex 改代碼
→ Browser 打開頁面
→ 截圖檢查
→ 繼續修樣式
→ 再次驗收
呢度我建議每次前端任務都加一句：
改完後請用瀏覽器截圖驗證，不要只說代碼已經改完。呢個要求好簡單，但可以過濾咗好多「code 睇落啱，頁面其實唔啱」嘅問題。
十、Computer Use：用得，但要慎重開
Computer Use 係叫 Codex 操作你嘅電腦應用，例如瀏覽器、控制枱、某啲桌面軟件。
我自己好鍾意呢個能力，我最近填雲端 Server 設定、填 App Store Screenshot 資料、做網頁填表重複動作，都係靠佢做。
有咗 Computer Use 之後，AI 可以進入 GUI 場景，徹底解放咗我。
但我必須提醒一句：呢個權限要慎重。
你唔好叫佢掂呢啲嘢：
• 俾錢確認 • 轉賬 • 刪數據 • 賬號安全設定 • 金鑰同 token • 私人對話 • 公司內部敏感系統
如果一定要叫佢入控制枱，最好叫佢先講計劃：
你將要操作瀏覽器控制枱。
在點擊任何提交、刪除、支付、確認按鈕前，必須停下來等我確認。
如果頁面出現 token、密鑰、手機號、郵箱，不要讀取或複述。呢個唔係唔信 AI，而係基本安全邊界。
你請一個真人助理操作電腦，都唔會叫佢隨便禁俾錢掣。
AI 都一樣，不過我而家覺得佢嘅權限唔會亂嚟，都會停低等我確認，咁樣好好，但最好都係同 AI 講定要求。
十一、Appshots：將現場俾 Codex 睇
Appshots 可以理解成「將當前應用嘅現場 screenshot 俾 Codex」。
例如你而家喺一個報錯頁面，或者某個 App 嘅設定頁，你想叫 Codex 睇當前狀態，就可以用 Appshots。
呢個能力適合呢啲場景：
1. 頁面報錯，但你唔想複製一大堆文字。 2. 某個設定頁你唔識揀。 3. 前端頁面視覺有問題，需要 AI 睇 screenshot。 4. 你想叫佢根據當前界面繼續解釋下一步。
但 screenshot 都有一個問題：好易帶敏感資訊。
所以你要養成習慣：
• 影 screenshot 之前望下有冇 email、token、項目名。 • 可以打碼就打碼。 • 唔好將私人對話、財務頁面、後台用戶數據直接掟入去。
我呢篇文章入面自己嘅 screenshot 好多都係 Codex 做嘅，佢都幫我打咗碼同標咗註。因為要公開出，就要多一重檢查。
十二、手機、多設備同 SSH
我之前寫過兩篇 Codex App 嘅短文，一篇講手機控制，一篇講 Mac 控 Mac。太犀利，Codex 呢波更新！可以放棄小龍蝦同愛馬仕喇！
Codex 好嘢：MacBook 接管 Mac mini 黑科技
今次放到總教學入面講下。
Codex 嘅連接能力有幾個概念容易混淆：
第一種：用手機控制呢部 Mac。
第二種：用呢部 Mac 控制其他設備。
第三種：透過 SSH 連接遠程項目。
佢哋唔係同一回事。
如果你想喺手機上睇任務進度、發新任務、審批一啲操作，就需要將手機同桌面端打通。
大致流程係：
桌面端開始設置
→ 手機掃碼
→ 手機授權
→ 桌面端確認允許
→ 手機端選擇項目發任務
如果你有多部 Mac，例如一部 MacBook、一部 Mac mini，就會用到「控制其他設備」。
呢度最容易踩嘅坑係：被控嗰部 Mac 要先開「允許其他設備連接」。
然後主控 Mac 先可以加設備。
加咗之後，你可以喺新任務入面揀遠程項目。
如果係 Server、devbox、遠程開發機，就睇 SSH。
我對呢塊嘅理解係：
設備連接解決「邊部電腦做嘢」。
SSH 解決「邊個遠程目錄做嘢」。
手機解決「人唔喺電腦前點樣調度」。
呢三個疊加埋，Codex 先真正由「本機工具」變成「工作調度系統」，隨時隨地做嘢，coding，好愉快。
十三、IDE Extension：黐住 code 現場用
如果你每日主要喺 IDE 度寫 code，Codex IDE Extension 會更加自然。
官方文檔寫得好清楚，Codex IDE extension 可以令你喺編輯器側邊欄度用 Codex，亦可以從 IDE 委派任務去 Codex Cloud。
IDE 入口最適合呢幾類任務：
1. 解釋當前檔案。 2. 修改當前揀中嘅 code。 3. 根據打開嘅 code 做細範圍重構。 4. 睇 diff。 5. 應用或拒絕 AI 改動。
如果你用 JetBrains、Cursor、VS Code 都有對應嘅整合。
IDE 同 App 嘅分別係乜？
我嘅理解：
App 更加似任務中心。
IDE 更加似手術枱。
任務中心適合派工、睇進度、轉項目。
手術枱適合睇實某個檔案、某個 diff、某個 function 細修。
如果你係 Programmer，我建議兩邊都用。
細修細改喺 IDE 度做。
跨檔案、跨項目、長任務就放 App 或 Cloud。
十四、CLI：終端黨會好鍾意
Codex CLI 係喺 terminal 度行嘅。
官方 CLI 文檔話，佢可以喺你揀嘅目錄度讀 code、改 code、行 code，而且係開源嘅。
CLI 適合呢啲人：
• 習慣 terminal 做嘢嘅人。 • 成日寫 script 嘅人。 • 想將 Codex 放入現有命令行 workflow 嘅人。 • 唔想成日開 GUI 嘅人。
常見用法就係入 project 目錄，然後行 Codex。
cd your-project
codex然後你可以喺 TUI 入面繼續對話，叫佢睇當前目錄、改檔案、行命令。
如果你仲未熟 CLI，唔建議第一日就由呢度開始。
App 更加直觀。
但等你用熟之後，CLI 會好爽。
因為佢離真實工程環境好近。
我建議大家至少理解 CLI。
就算你平時主要用 App，都要知道 Codex 唔係淨係喺 GUI 入面做得，而係可以喺其他維度用。
十五、Code Review：新手好啱由呢度入門
好多人第一次用 AI 改 code 會緊張。
咁你可以先唔叫佢改。
叫佢 review。
Code Review 係我好推薦嘅新手入口。
因為 review 嘅風險比直接改低，但可以令你睇到 Codex 嘅判斷力。
你可以叫佢睇一個 PR：
請 review 這個改動。
重點看：
1. 有沒有明顯 bug
2. 有沒有邊界條件沒處理
3. 有沒有安全風險
4. 有沒有測試缺口
5. 有沒有可以簡化的地方
只給 review 意見，不要直接改代碼。
亦可以叫佢睇本地 diff：
請 review 當前 git diff。
按嚴重程度輸出：
P0 必須修
P1 建議修
P2 可以優化
不要泛泛而談，每個問題都指出文件和原因。
呢個場景好適合建立信任。
佢指出的問題如果靠譜，你就知佢對項目有理解。
佢指出的問題如果唔靠譜，你都可以睇到佢喺邊啲地方會誤判。
比起叫佢一上嚟就改核心邏輯，先叫佢 review，係一個更穩陣嘅方式。
十六、Cloud：適合後台長任務
Codex Web / Cloud 適合叫佢喺後台做嘢。
官方文檔入面強調，Codex Cloud 可以喺自己嘅雲端環境入面後台行任務，包括並行任務。你連咗 GitHub 之後，佢可以根據 repo 工作，並產出 PR。
Cloud 適合呢啲任務：
• 修一個獨立 issue。 • 俾一個 PR 補測試。 • 更新文檔。 • 檢查一批失敗用例。 • 做一次細範圍重構。
Cloud 唔適合乜？
• 需要成日睇本地 UI 嘅前端細節。 • 需要你本機私有環境嘅操作。 • 需要手動登入複雜後台。 • 依賴你本機好多未提交檔案嘅任務。
我嘅建議係：
本地強依賴，用 App / IDE / CLI。
倉庫型後台任務，用 Cloud。
網頁視覺驗收，用 Browser。
桌面操作，用 Computer Use。
唔好將所有事都塞俾一個入口。
入口揀啱，體驗會好好多。
十七、AGENTS.md：叫 Codex 明你個項目嘅規矩
新手用 Codex 成日忽略一點：上下文唔係淨係靠傾偈度講。
項目入面應該有自己嘅規則。
比如：
• 項目點樣啟動。 • 測試命令係乜。 • code 風格係乜。 • 邊啲目錄唔改得。 • 發布流程係乜。 • 重要業務邊界係乜。
呢啲嘢如果每次都靠你手寫，好辛苦。
所以應該沉澱落項目文檔度。
最簡單就係 README。
再進一步，可以寫 AGENTS.md。
你可以放類似內容：
# AGENTS.md
## 項目說明
這是一個 Next.js 項目，使用 pnpm。
## 常用命令
- 安裝依賴：pnpm install
- 本地開發：pnpm dev
- Lint：pnpm lint
- 測試：pnpm test
- 構建：pnpm build
## 修改規則
- 不要改數據庫 schema，除非用戶明確要求。
- 不要新增依賴，除非說明理由。
- 修改前先讀 README 和 package.json。
- 完成後必須說明改了哪些文件，以及跑了哪些命令。
呢類檔案本質上係俾 AI 嘅項目 SOP。
你愈常用 Codex，愈會發現：真正提升效率嘅唔係每次寫一個好長嘅 prompt，而係將項目規則沉澱落嚟。
呢個同我而家維護 Obsidian 知識庫嘅邏輯一樣。
唔係叫 AI 每次都由 0 理解我，而係將長期上下文放喺固定地方。
呢個亦係我而家愈嚟愈重視 AGENTS.md 嘅原因。
工具用耐咗之後，真正拉開差距嘅唔係某一次 prompt 寫得幾靚，而係你個項目有冇沉澱出一套穩定規矩。
十八、非工程角色點樣用 Codex
Codex 唔止係 Programmer 工具。
PM、Designer、營運都用得。
但用法唔同。
PM 唔一定要叫 Codex 寫 code，可以叫佢理解需求、拆驗收標準、睇實現有冇漏。
比如：
請閲讀這個 PR 和需求描述。
從產品經理視角檢查：
1. 是否覆蓋需求裏的每個驗收點
2. 是否有明顯邊界漏掉
3. 是否需要補充空狀態、錯誤狀態、加載狀態
4. 是否有用戶體驗風險
不要改代碼，只給檢查清單。
官方 PM 影片入面都有類似思路：用自然語言將產品問題交俾 Codex，叫佢結合項目上下文分析。
Designer 都一樣。
唔係叫 Codex 取代設計，而係將設計稿、Prototype、已有頁面串埋一齊，叫佢做可以行嘅嘢。
營運同內容同事都可以用佢做 script、batch processing、數據整理、頁面檢查。
但有一個前提：你要將任務講清楚。
唔識寫 code 冇問題。
唔識描述目標，先係問題。
十九、新手最容易踩嘅 12 個坑
我直接列，兄弟們對照避開。
1. 一上嚟就叫佢做大項目
例如「幫我重構成個系統」。
呢個任務太大，失敗機會好高。
先拆做：
先讀項目並給重構建議，不改代碼。2. 唔俾驗收條件
你唔話佢知點樣叫完成，佢只能自己估。
一定要寫測試、lint、screenshot、檔案範圍。
3. 唔睇 diff
呢個最危險。
AI 改完 code，你至少望一眼改咗邊啲檔案。
4. 直接喺 Production 項目開大權限
第一日唔好咁玩。
先用 demo 項目，之後先用真實項目。
5. 同時開多個任務改同一批檔案
咁樣會互相覆蓋。
多任務要拆到獨立。
6. 將 Codex 當搜索引擎
Codex 嘅價值唔係揾答案，而係喺項目上下文入面執行。
問概念可以用 ChatGPT。
改項目、行驗證、睇 diff，先係 Codex 嘅主場。
7. 唔沉澱項目規則
每次都重新解釋項目，效率好低。
README、AGENTS.md、測試命令，都要沉澱。
8. 叫佢操作敏感後台
Computer Use 好勁，但敏感後台要小心。
俾錢、刪除、賬號安全、金鑰，一律人手確認。
9. 前端任務唔睇 screenshot
前端一定要叫佢開瀏覽器驗收。
剩係話 build 通過唔夠。
10. 叫佢自動化模糊任務
自動化一定要有明確 SOP。
唔係嘅話每日都會產出一堆冇用嘅報告。
11. 唔區分 App、IDE、CLI、Cloud
入口揀錯，體驗會差。
任務中心用 App，code 現場用 IDE，Terminal 流程用 CLI，後台 repo 任務用 Cloud。建議多用 Codex App。
12. 期望一次 prompt 解決所有問題
真正嘅 workflow 係多輪。
讀 code，出方案，改一小步，行驗證，再繼續。
唔好幻想一條 prompt 就變完美工程。
二十、我建議新手嘅 7 日路線
如果你而家由 0 開始，我建議跟 7 日嚟。
第 1 日：剩係讀項目，唔改 code
任務：
請閲讀這個項目，告訴我項目結構、本地啓動方式、測試命令和你建議的 3 個小任務。目標：睇明 Codex 點樣讀上下文。
第 2 日：剩係改文檔
任務：
請根據項目實際結構，補充 README 的本地啓動說明。
只改 README。目標：睇明佢點樣改檔案。
第 3 日：修一個低風險 bug
任務：
請修復某個按鈕文案不一致的問題。
不要改接口邏輯。
改完跑 lint。目標：睇 diff 同驗證。
第 4 日：叫佢做 code review
任務：
請 review 當前 diff，只給意見，不改代碼。目標：訓練你判斷佢嘅質素。
第 5 日：做一次前端瀏覽器驗收
任務：
請啓動本地項目，用瀏覽器檢查移動端和桌面端首屏。
發現問題先截圖說明，再改。目標：將 code 同視覺結果接埋一齊。
第 6 日：試 IDE 或 CLI
如果你係 Programmer，開始將 Codex 放喺 IDE 或 Terminal 度。
目標：令佢黐近你真正寫 code 嘅地方。
第 7 日：寫 AGENTS.md
將項目規則沉澱落嚟。
目標：令下次任務唔使再由 0 開始。
呢 7 日行完，你基本就唔係「試用嚇 Codex」咁簡單。
你已經開始建立 AI 編程 workflow。
二十一、我最終嘅建議
我而家愈嚟愈肯定一件事：
AI 編程唔係單一工具競爭，而係 workflow 競爭。
邊個可以入到真實項目，邊個可以讀上下文，邊個可以行驗證，邊個可以跨設備，邊個可以連瀏覽器、Terminal、IDE、遠程機器，邊個先有機會真正改變開發方式。
Codex 而家令我有興趣嘅地方就係呢度。
佢唔係淨係喺聊天框度回答你，而係直接幫你拎結果，呢個最重要。
呢個亦係我話佢比小龍蝦 open claw 同 hermes agent 更方便嘅原因。
但新手一定要記住：
唔好神化佢，亦唔好因為怕出錯就唔用。
先由一個 demo 項目開始，做起身。
講到尾，工具唔係用嚟供奉嘅，係用嚟做嘢嘅。
多用，玩壞咗，一齊揾工。🤣
參考來源
• OpenAI Developers Codex：https://developers.openai.com/codex • Codex Quickstart：https://developers.openai.com/codex/quickstart • Codex App：https://developers.openai.com/codex/app • Codex CLI：https://developers.openai.com/codex/cli • Codex IDE extension：https://developers.openai.com/codex/ide • Codex web / cloud：https://developers.openai.com/codex/cloud • OpenAI Developers Codex Videos：https://developers.openai.com/codex/videos
前 Python Programmer，而家係 AI 編程出海方向嘅創業者。
• 需要 AI 生圖？ → HiAPI.ai，新人 50 張 GPT image 2 免費 • 想傾 AI、獨立開發、副業？ → 加微信 257735，備註【AI】 
最近這兩個月，用 Codex 的時間非常長，遠超我自己 ClaudeMax 20X，不是偶爾打開問一句“這個代碼怎麼改”，而是每天真的把它當成一個能幹活的 AI 工程師來用。
因為代碼的問題和 CLI 命令行的事情，很多人都望而卻步，但最近幾次 Codex 的更新讓編程這個事情變得簡單起來，甚至好玩起來，是一個人人都可以玩的工具了，讓我覺得有必要寫一篇長文來讓更多人用起來。
以前很多人理解 AI 編程，大概停留在兩個畫面：
第一，把代碼複製到 ChatGPT 裏，讓它解釋一下。
第二，在 IDE 裏開一個代碼補全工具，讓它補幾行函數。
但Codex 它不是“幫你寫一段代碼”，而是“幫你推進一個任務”，是真正的 人人可以用的 agent。
這篇我按從 0 到 1 來寫，內容有點長，適合收藏學習。
我會把官方視頻裏的流程截圖、我自己電腦裏的 Codex 設置截圖、之前手機和多設備的截圖都串起來。你不需要一上來理解所有概念，先知道每個入口是幹什麼的，第一次任務怎麼發，權限怎麼開，結果怎麼驗收，就夠了。
你先把這條鏈路跑通，比一上來研究所有高級功能更重要。
全文你可以按四層來看：
第一層，先把 Codex 是什麼、主界面和權限看懂。
第二層，跑通第一條任務，學會寫提示詞、看 diff、跑測試。
第三層，再理解 Browser、Computer Use、Appshots、手機、多設備和 SSH。
第四層，最後再看 IDE、CLI、Cloud、AGENTS.md 和 7 天路線。
一、先把 Codex 想清楚
Codex 不是一個單獨按鈕。
它現在更像一套 AI 編程工作流，至少有四種常見入口：
1. Codex App：適合管理任務、看進度、多設備、遠程項目和一些本機操作。 2. Codex Web / Cloud：適合讓它在雲端後台跑任務，尤其是 GitHub 倉庫、PR、並行任務。 3. Codex IDE Extension：適合在 VS Code、Cursor、Windsurf、JetBrains 這類編輯器裏貼着代碼現場幹活。 4. Codex CLI：適合在終端裏使用，給它當前目錄，讓它讀代碼、改代碼、跑命令。
OpenAI 官方在 Codex 首頁給的定位很直接：它是“everywhere you code”這一類 coding agent。不是隻能在一個地方用，而是儘量出現在你寫代碼、審代碼、跑項目、看網頁、接遠程機器的地方。
我建議新手不要一上來糾結“到底用 App 還是 CLI”。
你先記一個簡單分工：
• App：管任務。 • IDE：看代碼。 • CLI：跑命令。 • Browser：看網頁效果。 • Computer Use：操作桌面應用。 • Cloud：後台跑長任務。
這樣理解以後，Codex 就不亂了。
很多工具亂，是因為它們只有一個入口，卻想幹所有事。Codex 現在的方向是反過來的：同一個 agent，進入不同工作現場。
以前 AI 是聊天窗口，現在是直接幫你拿結果。
二、新手先別急，先準備一個安全項目
很多兄弟第一次打開 Codex，最容易犯的錯誤是：直接拿自己最重要的項目試。
這個不建議。
不是因為 Codex 不行，而是因為你還不知道它會怎麼讀上下文、怎麼跑命令、哪裏需要你審批。
第一天最好拿一個安全項目。
比如：
• 一個 demo repo • 一個自己寫着玩的腳本 • 一個靜態頁面 • 一個文檔目錄 • 一個不涉及密鑰、不涉及真實用戶數據的小項目
目標不是馬上讓 Codex 替你搞定生產問題。
目標是看懂 4 件事：
1. 它怎麼理解你的任務。 2. 它會改哪些文件。 3. 它會跑哪些命令。 4. 它最後怎麼證明自己做完了。
新手第一天把這 4 件事跑明白，後面就順很多。
官方 Quickstart 裏也把入口分成 App、IDE extension、CLI、Cloud 幾類。你可以從任意入口開始，但如果你是第一次接觸，我建議先用 Codex App，因為它能讓你比較完整地看到任務、上下文、權限和執行過程。
注意看這張圖。
新手最該先看的不是“怎麼讓它更強”，而是這些權限：
• 自動審核開不開。 • 是否允許完全訪問。 • 什麼時候需要你審批。 • 當前工作空間是哪一個。 • 它能不能操作本機。
AI 編程真正進入下一階段以後，權限會變成一個核心問題。
不給權限，AI 只能陪你聊天。
權限給太大，自己又不看 diff，就容易出問題。
正確做法不是一刀切，而是按任務給權限。
第一天就記一句話：
小任務、小權限、強驗收。
隨着你對 codex 能力邊界熟悉了，就可以放開權限了，這樣避免你每次確認浪費時間。
三、主界面怎麼讀
Codex 的主界面看着不復雜，但新手打開以後會懵。
因為你不知道到底該看哪裏。
我按我的理解拆一下。
左側主要是項目和歷史任務。
你可以把它理解成“我現在讓 Codex 管哪些工作空間”。這裏會有不同項目，不同任務，也會保留一些歷史對話。
中間是當前任務線程。
你發出去的任務、Codex 的思考和執行過程、它最後的結果，都會在這裏展開。
右側一般是環境信息。
比如當前 workspace、模型、執行環境、上下文狀態、是否啓用了某些能力。這裏決定了 Codex 到底是在什麼地方幹活。
底部是輸入區。
這個地方很關鍵。
你會看到模型、權限、發送按鈕，以及當前任務能不能附加上下文。
我建議新手一開始不要寫很長很散的提示詞。
先按這個模板：
背景：
這是一個什麼項目，現在遇到什麼問題。
目標：
我希望你完成什麼。
範圍：
可以改哪些文件，不能動哪些文件。
約束：
不要引入新依賴，不要改公開 API，不要改數據庫結構。
驗收：
完成後請告訴我改了哪些文件，並運行哪些測試或檢查命令。
這個模版其實就是明確給 AI 一些方向，避免 AI 猜你的想法，總之越詳細效果越好。
把 Codex 當成一個會犯錯，但執行力很強的臨時工程師。
隨着你和 AI 互動溝通越多，後續AI 能給到你想要的答案，當然如果沒有，還可以再發一條【內容】繼續補充。
四、第一次任務怎麼發
第一次任務不要大。
不要說：
幫我優化一下這個項目。這種任務太虛。
你可以說：
請先閲讀這個項目的 README、package.json 和主要入口文件。
只做分析，不改代碼。
告訴我：
1. 這個項目是幹什麼的
2. 本地怎麼啓動
3. 測試命令是什麼
4. 你建議我下一步讓你做哪 3 個小任務
這個任務特別適合作為 Codex 的第一條任務。
原因很簡單：它不改代碼，但能讓你看 Codex 怎麼讀項目。
第二條任務可以再小一點：
請修復 README 裏“本地啓動步驟”不清楚的問題。
只改 README.md。
不要改代碼。
改完後給我總結改動。
第三條任務再開始碰代碼：
請找到項目裏負責登錄頁表單校驗的代碼。
只修復錯誤提示文案不統一的問題。
不要改接口邏輯。
改完後運行現有 lint 或測試。
這才是比較穩的入門方式。
官方視頻裏也能看到，Codex 的任務不是一次性問答，而是圍繞一個 workspace 持續推進。
你可以補上下文，可以讓它改，可以讓它撤，可以讓它解釋。
這裏有一個很重要的習慣：
不要只看最終答案。
你要看它中間做了什麼。
比如它讀了哪些文件，跑了哪些命令，為什麼要改某個函數，測試失敗以後怎麼處理。
Codex 真正有價值的地方，不是最後那幾行總結，而是它執行過程可追蹤。
五、怎麼寫好任務提示詞
很多人用 AI 編程效果不好，不是模型不行，而是任務寫得太爛。
尤其是 Codex 這種能真的改項目的工具，提示詞更像需求文檔。
我給一個最常用的結構：
你是這個項目裏的臨時工程師。
任務目標：
把用戶設置頁裏的保存按鈕，在請求中時顯示 loading，並禁止重複點擊。
上下文：
這個項目是 React + TypeScript。
設置頁在 src/pages/settings 目錄。
已有 Button 組件，優先複用，不要新造 UI 組件。
範圍：
可以修改 settings 頁面和相關 hook。
不要改接口層，不要改路由，不要改樣式系統。
驗收：
1. 保存中按鈕顯示 loading
2. 請求未結束前不能重複提交
3. 請求失敗後恢復按鈕狀態
4. 運行 npm run lint
5. 最後說明改了哪些文件
你看，這裏面沒有玄學。
就是把“目標、上下文、範圍、驗收”講清楚。
如果是修 bug，可以這樣寫：
請排查這個 bug，但先不要直接改代碼。
現象：
用戶在移動端點擊提交後，頁面偶爾沒有反饋。
我希望你先做：
1. 找到相關代碼路徑
2. 判斷可能原因
3. 給出 2-3 個修復方案
4. 推薦最小改動方案
等我確認後再實施。
這類提示詞很適合高風險場景。
你不是不讓 Codex 幹活，而是先讓它出方案。
等你確認了，再讓它動手。
這和帶新人一樣。
新人上來就亂改，你肯定不放心。先讓他讀代碼、講判斷、列方案，你會放心很多。
六、做完以後，重點看 diff 和測試
Codex 做完，不代表你可以直接合並。
這個地方我說重一點。
新手一定要養成看 diff 的習慣。
AI 寫代碼最怕三件事：
1. 看起來完成了，但邊界沒處理。 2. 改動範圍擴大了，把不該動的地方也動了。 3. 測試沒跑，或者跑失敗了被忽略。
所以每次完成後，你至少看 5 個東西：
1. 改了哪些文件？
2. 有沒有改到任務範圍之外？
3. 有沒有新增依賴？
4. 有沒有跑 lint / test / build？
5. 有沒有留下調試代碼、假數據、敏感信息？
官方視頻裏有一個畫面很典型，Codex 會給出自檢和總結。
你可以繼續追問：
請按文件列出這次改動。
每個文件說明：
1. 為什麼改
2. 具體改了什麼
3. 有什麼風險
4. 用什麼命令驗證過
如果它沒有跑測試，你就直接問：
你還沒有運行測試。
請先根據項目文檔找到測試命令。
如果沒有測試命令，請說明你能運行的最小驗證是什麼。這一步很重要。
不要因為 AI 很聰明，就把工程裏的基本動作丟掉。
以前人寫代碼要 code review，現在 AI 寫代碼更要 review。
這裏我自己的經驗是：小任務可以快一點，大任務一定要慢一點。
比如改 README、修文案、補註釋，風險很低，可以讓它直接做。
但涉及支付、登錄、權限、數據庫遷移、用戶數據、生產部署，一定要讓它先出方案，再小步執行。
AI 編程不是把人拿掉。
AI 編程是把人從重複操作裏解放出來，但最後判斷還在人這裏。
七、多任務是 Codex 的強項
我現在用 Codex 最爽的地方之一，是多任務。
不是一個任務結束再開下一個，而是幾個互不影響的任務並行推進。
比如我可以同時讓它做：
• 一個項目裏修 README。 • 另一個項目裏跑測試失敗分析。 • 第三個項目裏檢查前端頁面。 • 第四個項目裏整理 issue。
當然，前提是任務之間別互相踩。
如果兩個任務都在改同一批文件，就不適合並行。
多任務適合這幾類：
1. 文檔類：補 README、生成變更說明、整理接口說明。 2. 檢查類：跑 lint、跑測試、查失敗日誌、找潛在問題。 3. 小修類：文案統一、樣式微調、刪除無用代碼。 4. 分析類：理解一個陌生模塊、找入口、整理調用鏈。
不適合這幾類：
1. 大規模架構重構。 2. 數據庫遷移。 3. 支付和權限鏈路。 4. 多個任務同時改同一塊核心代碼。
多任務的關鍵不是“開很多個”，而是“拆得足夠獨立”。
這和管理團隊一樣。
你不能讓 5 個人同時改同一個函數，然後期待結果自動變好。
八、自動化任務怎麼理解
Codex 還有 Automations。
這個我建議新手第二階段再用。
先把普通任務、diff、測試跑明白，再玩自動化。
自動化適合什麼？
適合那些“重複發生、規則清楚、結果可檢查”的事情。
比如：
• 每天檢查某個項目有沒有 failing tests。 • 每週整理一次依賴更新風險。 • 定期掃描文檔裏過期連結。 • 每天把某個倉庫的 issue 分類。 • 每週生成一次項目變更摘要。
創建自動化時，最關鍵的是把任務寫清楚。
不要寫：
每天幫我看看項目有沒有問題。這太虛。
改成：
每天上午 10 點檢查這個倉庫：
1. 拉取最新主分支
2. 運行 npm run lint
3. 運行 npm test
4. 如果失敗，彙總失敗命令、錯誤摘要、疑似相關文件
5. 不要自動修改代碼，只給報告
這個才叫自動化。
自動化裏有一個坑：很多人喜歡讓它“自動修”。
我建議剛開始只讓它“自動查”和“自動報”。
等你確認它查得準，再逐步讓它做低風險修復。
自動化像一個每天按時上班的助理，你得先給它 SOP。
我的習慣是你把自己跟 AI 的要求沉澱一個工作流，後續 AI 可以按照你的習慣執行，比如寫完要測試，測試要注意到哪台服務器，測試完了要發正式等等，這樣不容易跑偏。
九、Browser：前端任務一定要看頁面
如果你用 Codex 做前端，千萬不要只看代碼。
前端最終是給人看的。
按鈕有沒有擠在一起，移動端有沒有重疊，彈窗有沒有遮住內容，顏色有沒有看不清，這些問題不是隻看 diff 能看出來的。
所以 Browser 很重要。
你可以讓 Codex 打開本地頁面，看截圖，然後繼續修。
比如：
請啓動項目並打開本地頁面。
重點檢查：
1. 375px 移動端是否有文字重疊
2. 1440px 桌面端首屏是否正常
3. 按鈕文字是否溢出
4. 表單錯誤狀態是否清楚
發現問題後先截圖說明，再修改。
這類任務非常適合 Codex。
官方也有專門講前端和 Codex 的視頻。
前端工作流大概是：
描述目標
→ Codex 改代碼
→ Browser 打開頁面
→ 截圖檢查
→ 繼續修樣式
→ 再次驗收
這裏我建議你每次前端任務都加一句：
改完後請用瀏覽器截圖驗證，不要只說代碼已經改完。這個要求很簡單，但能過濾掉很多“代碼看起來對，頁面其實不對”的問題。
十、Computer Use：能用，但要慎重開
Computer Use 是讓 Codex 操作你的電腦應用，比如瀏覽器、控制枱、某些桌面軟件。
我自己是很喜歡這個能力的，我最近填寫雲服務器配置，填寫 app store 截圖信息，做網頁填表重複動作，都是靠他做。
有 Computer Use 之後，AI 可以進入 GUI 場景，徹底解放了我。
但我必須提醒一句：這個權限要慎重。
你不要讓它碰這些東西：
• 支付確認 • 轉賬 • 刪除數據 • 賬號安全設置 • 密鑰和 token • 私密聊天 • 公司內部敏感系統
如果必須讓它進控制枱，最好讓它先說明計劃：
你將要操作瀏覽器控制枱。
在點擊任何提交、刪除、支付、確認按鈕前，必須停下來等我確認。
如果頁面出現 token、密鑰、手機號、郵箱，不要讀取或複述。這不是不信任 AI，這是基本安全邊界。
你請一個真人助理操作電腦，也不會讓他隨便點支付按鈕。
AI 也是一樣，不過目前我感覺他的權限沒有說，也會停下來等我確認這很好，但是最好給 AI 同步下要求。
十一、Appshots：把現場給 Codex 看
Appshots 可以理解成“把當前應用現場截圖給 Codex”。
比如你現在正在一個報錯頁面，或者某個 App 的設置頁，你想讓 Codex 看當前狀態，就可以用 Appshots。
這個能力適合這些場景：
1. 頁面報錯，但你不想複製一堆文字。 2. 某個設置頁你不知道怎麼選。 3. 前端頁面視覺有問題，需要 AI 看截圖。 4. 你想讓它基於當前界面繼續解釋下一步。
但截圖也有一個問題：很容易帶敏感信息。
所以你要養成習慣：
• 截圖前看一眼有沒有郵箱、token、項目名。 • 能打碼就打碼。 • 不要把私密聊天、財務頁面、後台用戶數據直接丟進去。
我這篇文章裏自己的截圖很多都是 codex 做的，他也都做了打碼和標註。因為要公開發，就要多一道檢查。
十二、手機、多設備和 SSH
我之前寫過兩篇 Codex App 的短文，一個講手機控制，一個講 Mac 控 Mac。太牛逼，Codex 這波更新！可以放棄小龍蝦和愛馬仕了！
Codex 牛逼：MacBook 接管 Mac mini 黑科技
這次放到總教程裏講一下。
Codex 的連接能力有幾個概念容易混：
第一種：讓手機控制這台 Mac。
第二種：讓這台 Mac 控制其他設備。
第三種：通過 SSH 連接遠程項目。
它們不是一回事。
如果你想在手機上看任務進度、發新任務、審批一些操作，就需要把手機和桌面端打通。
大致流程是：
桌面端開始設置
→ 手機掃碼
→ 手機授權
→ 桌面端確認允許
→ 手機端選擇項目發任務
如果你有多台 Mac，比如一台 MacBook、一台 Mac mini，就會用到“控制其他設備”。
這裏最容易踩的坑是：被控那台 Mac 要先打開“允許其他設備連接”。
然後主控 Mac 才能添加設備。
添加後，你可以在新任務裏選擇遠程項目。
如果是服務器、devbox、遠程開發機，就看 SSH。
我對這塊的理解是：
設備連接解決“哪台電腦幹活”。
SSH 解決“哪個遠程目錄幹活”。
手機解決“人不在電腦前怎麼調度”。
這三個疊起來，Codex 才真正從“本機工具”變成“工作調度系統”，隨時隨地幹活，coding，非常愉快。
十三、IDE Extension：貼着代碼現場用
如果你每天主要在 IDE 裏寫代碼，Codex IDE Extension 會更自然。
官方文檔裏寫得很清楚，Codex IDE extension 可以讓你在編輯器側邊欄裏使用 Codex，也可以從 IDE 委派任務到 Codex Cloud。
IDE 入口最適合這幾類任務：
1. 解釋當前文件。 2. 修改當前選中的代碼。 3. 根據打開的代碼做小範圍重構。 4. 查看 diff。 5. 應用或拒絕 AI 改動。
如果你用 JetBrains，cursor，vscode也有對應集成。
IDE 和 App 的區別是什麼？
我的理解：
App 更像任務中心。
IDE 更像手術枱。
任務中心適合派活、看進度、切項目。
手術枱適合盯着某個文件、某個 diff、某個函數細修。
你如果是程序員，我建議兩邊都用。
小修小改在 IDE 裏做。
跨文件、跨項目、長任務放到 App 或 Cloud。
十四、CLI：終端黨會很喜歡
Codex CLI 是在終端裏跑的。
官方 CLI 文檔裏說，它可以在你選中的目錄裏讀代碼、改代碼、運行代碼，而且是開源的。
CLI 適合這些人：
• 習慣終端工作的人。 • 經常寫腳本的人。 • 想把 Codex 放進現有命令行工作流的人。 • 不想一直打開圖形界面的人。
常見用法就是進入項目目錄，然後運行 Codex。
cd your-project
codex然後你可以在 TUI 裏繼續對話，讓它看當前目錄、改文件、跑命令。
如果你還不熟 CLI，不建議第一天從這裏開始。
App 更直觀。
但等你用熟以後，CLI 會很爽。
因為它離真實工程環境很近。
我建議大家至少理解 CLI。
哪怕你平時主要用 App，也要知道 Codex 不是隻能在圖形界面裏工作，而可以再其他維度使用。
十五、Code Review：新手很適合從這裏入門
很多人第一次用 AI 改代碼會緊張。
那你可以先不讓它改。
讓它 review。
Code Review 是我很推薦的新手入口。
因為 review 的風險比直接改低，但能讓你看到 Codex 的判斷力。
你可以讓它看一個 PR：
請 review 這個改動。
重點看：
1. 有沒有明顯 bug
2. 有沒有邊界條件沒處理
3. 有沒有安全風險
4. 有沒有測試缺口
5. 有沒有可以簡化的地方
只給 review 意見，不要直接改代碼。
也可以讓它看本地 diff：
請 review 當前 git diff。
按嚴重程度輸出：
P0 必須修
P1 建議修
P2 可以優化
不要泛泛而談，每個問題都指出文件和原因。
這個場景很適合建立信任。
它指出的問題如果靠譜，你就知道它對項目有理解。
它指出的問題如果不靠譜，你也能看出來它在哪些地方會誤判。
比起讓它一上來改核心邏輯，先讓它 review，是一個更穩的方式。
十六、Cloud：適合後台長任務
Codex Web / Cloud 適合讓它在後台做事。
官方文檔裏強調，Codex cloud 可以在自己的雲端環境裏後台跑任務，包括並行任務。你連接 GitHub 以後，它可以基於倉庫工作，併產出 PR。
Cloud 適合這些任務：
• 修一個獨立 issue。 • 給一個 PR 補測試。 • 更新文檔。 • 檢查一批失敗用例。 • 做一次小範圍重構。
Cloud 不適合什麼？
• 需要頻繁看本地 UI 的前端細節。 • 需要你本機私有環境的操作。 • 需要手動登錄複雜後台。 • 依賴你本機很多未提交文件的任務。
我的建議是：
本地強依賴，用 App / IDE / CLI。
倉庫型後台任務，用 Cloud。
網頁視覺驗收，用 Browser。
桌面操作，用 Computer Use。
不要把所有事都塞給一個入口。
入口選對，體驗會好很多。
十七、AGENTS.md：讓 Codex 懂你的項目規矩
新手用 Codex 經常忽略一個點：上下文不是隻靠聊天裏說。
項目裏應該有自己的規則。
比如：
• 項目怎麼啓動。 • 測試命令是什麼。 • 代碼風格是什麼。 • 哪些目錄不能改。 • 發佈流程是什麼。 • 重要業務邊界是什麼。
這些東西如果每次都靠你手寫，非常累。
所以應該沉澱到項目文檔裏。
最簡單就是 README。
更進一步，可以寫 AGENTS.md。
你可以放類似內容：
# AGENTS.md
## 項目說明
這是一個 Next.js 項目，使用 pnpm。
## 常用命令
- 安裝依賴：pnpm install
- 本地開發：pnpm dev
- Lint：pnpm lint
- 測試：pnpm test
- 構建：pnpm build
## 修改規則
- 不要改數據庫 schema，除非用戶明確要求。
- 不要新增依賴，除非說明理由。
- 修改前先讀 README 和 package.json。
- 完成後必須說明改了哪些文件，以及跑了哪些命令。
這類文件本質上是給 AI 的項目 SOP。
你越常用 Codex，越會發現：真正提升效率的不是每次寫一個很長 prompt，而是把項目規則沉澱下來。
這和我現在維護 Obsidian 知識庫的邏輯一樣。
不是讓 AI 每次從 0 理解我，而是把長期上下文放在固定地方。
這也是我現在越來越重視 AGENTS.md 的原因。
工具用久以後，真正拉開差距的不是某一次 prompt 寫得多漂亮，而是你的項目有沒有沉澱出一套穩定規矩。
十八、非工程角色怎麼用 Codex
Codex 不只是程序員工具。
PM、設計師、運營也能用。
但用法不一樣。
PM 不一定要讓 Codex 寫代碼，可以讓它理解需求、拆驗收標準、看實現有沒有漏。
比如：
請閲讀這個 PR 和需求描述。
從產品經理視角檢查：
1. 是否覆蓋需求裏的每個驗收點
2. 是否有明顯邊界漏掉
3. 是否需要補充空狀態、錯誤狀態、加載狀態
4. 是否有用戶體驗風險
不要改代碼，只給檢查清單。
官方 PM 視頻裏也有類似思路：用自然語言把產品問題交給 Codex，讓它結合項目上下文分析。
設計師也一樣。
不是讓 Codex 替代設計，而是把設計稿、原型、已有頁面串起來，讓它做可運行的東西。
運營和內容同學也可以用它做腳本、批處理、數據整理、頁面檢查。
但有一個前提：你要把任務說清楚。
不會寫代碼沒關係。
不會描述目標，才是問題。
十九、新手最容易踩的 12 個坑
我直接列，兄弟們對照避坑。
1. 一上來就讓它做大項目
比如“幫我重構整個系統”。
這個任務太大，失敗概率很高。
先拆成：
先讀項目並給重構建議，不改代碼。2. 不給驗收條件
你不告訴它怎麼算完成，它只能自己猜。
一定要寫測試、lint、截圖、文件範圍。
3. 不看 diff
這個最危險。
AI 改完代碼，你至少要看一眼改了哪些文件。
4. 直接在生產項目裏開大權限
第一天不要這麼玩。
先 demo 項目，後真實項目。
5. 同時開多個任務改同一批文件
這會互相覆蓋。
多任務要拆獨立。
6. 把 Codex 當搜索引擎
Codex 的價值不是搜答案，而是在項目上下文裏執行。
問概念可以用 ChatGPT。
改項目、跑驗證、看 diff，才是 Codex 的主場。
7. 不沉澱項目規則
每次都重新解釋項目，效率很低。
README、AGENTS.md、測試命令，都要沉澱。
8. 讓它操作敏感後台
Computer Use 很強，但敏感後台要謹慎。
支付、刪除、賬號安全、密鑰，一律人工確認。
9. 前端任務不看截圖
前端一定要讓它打開瀏覽器驗收。
只說 build 通過不夠。
10. 讓它自動化模糊任務
自動化必須有明確 SOP。
不然每天都會產出一堆沒法用的報告。
11. 不區分 App、IDE、CLI、Cloud
入口選錯，體驗會差。
任務中心用 App，代碼現場用 IDE，終端流程用 CLI，後台倉庫任務用 Cloud。建議多用 codex app
12. 期待一次提示詞解決所有問題
真正的工作流是多輪。
讀代碼，出方案，改一小步，跑驗證，再繼續。
不要幻想一條 prompt 直接變成完美工程。
二十、我建議的新手 7 天路線
如果你現在從 0 開始，我建議按 7 天來。
第 1 天：只讀項目，不改代碼
任務：
請閲讀這個項目，告訴我項目結構、本地啓動方式、測試命令和你建議的 3 個小任務。目標：看懂 Codex 怎麼讀上下文。
第 2 天：只改文檔
任務：
請根據項目實際結構，補充 README 的本地啓動說明。
只改 README。目標：看懂它怎麼改文件。
第 3 天：修一個低風險 bug
任務：
請修復某個按鈕文案不一致的問題。
不要改接口邏輯。
改完跑 lint。目標：看 diff 和驗證。
第 4 天：讓它做 code review
任務：
請 review 當前 diff，只給意見，不改代碼。目標：訓練你判斷它的質量。
第 5 天：做一次前端瀏覽器驗收
任務：
請啓動本地項目，用瀏覽器檢查移動端和桌面端首屏。
發現問題先截圖說明，再改。目標：把代碼和視覺結果接起來。
第 6 天：嘗試 IDE 或 CLI
如果你是程序員，開始把 Codex 放到 IDE 或終端裏。
目標：讓它貼近你真實寫代碼的地方。
第 7 天：寫 AGENTS.md
把項目規則沉澱下來。
目標：讓下次任務不再從 0 開始。
這 7 天跑完，你基本就不是“試用一下 Codex”了。
你已經開始建立 AI 編程工作流。
二十一、我的最終建議
我現在越來越確定一件事：
AI 編程不是單個工具競爭，而是工作流競爭。
誰能進入真實項目，誰能讀上下文，誰能跑驗證，誰能跨設備，誰能接瀏覽器、終端、IDE、遠程機器，誰才有機會真正改變開發方式。
Codex 現在讓我感興趣的地方就在這裏。
它不是隻在聊天框裏回答你，而是直接幫你拿結果，這個最重要。
這也是我說他比小龍蝦 open claw 和 hermes agent 更方便了。
但新手一定要記住：
不要神化它，也不要因為怕出錯就不用。
先從一個 demo 項目開始，幹起來。
說到底，工具不是拿來供着的，是拿來幹活的。
多用，玩壞了，一起找工作。🤣
參考來源
• OpenAI Developers Codex：https://developers.openai.com/codex • Codex Quickstart：https://developers.openai.com/codex/quickstart • Codex App：https://developers.openai.com/codex/app • Codex CLI：https://developers.openai.com/codex/cli • Codex IDE extension：https://developers.openai.com/codex/ide • Codex web / cloud：https://developers.openai.com/codex/cloud • OpenAI Developers Codex Videos：https://developers.openai.com/codex/videos
前 Python 程序員，現在是 AI 編程出海方向的創業者。
• 需要 AI 生圖？ → HiAPI.ai，新人 50 張gpt image2免費 • 想聊 AI、獨立開發、副業？ → 加微信 257735，備註【AI】