阿星Codex編程白皮書:0基礎入門AI編程保姆級實操手冊

作者:阿星AI工作室
日期:2026年5月18日 下午7:42
來源:WeChat 原文

整理版優先睇

速讀 5 個重點 高亮

Codex 係一個任務式執行嘅 AI 編程 Agent,重點係學識點樣清晰派任務,而唔係當佢聊天工具。

整理版摘要

呢篇文章係由阿星整理嘅 Codex 入門實戰手冊。阿星留意到企業家都開始學 Codex,覺得如果只能學一個 AI 工具,就係佢。文章目標係幫 0 基礎嘅人快速上手 Codex,唔係講理論,而係實際操作指南。

作者指出,好多人以為 Codex 只係另一個 AI 寫 code 工具,但其實佢已經進化成一個可以進入項目現場嘅 Agent:讀項目、改檔案、行命令、處理 Git,仲可以透過桌面、CLI、IDE、Web、Chrome 插件唔同入口工作。Codex 嘅核心轉變係由「問答式生成」變成「任務式執行」,即係你唔係叫佢寫一段 code,而係叫佢執行一個完整開發任務,例如「喺現有項目加個登入頁,重用現有組件、唔用新函式庫、加基礎驗證、改完行類型檢查」。

整體結論係:真正要學嘅唔係 Codex 呢個工具,而係點樣派任務——清晰定義目標、背景、限制同驗收標準。你將佢當執行者,佢就會畀到執行結果;你當佢聊天對象,佢就只會畀聊天式答案。文章由概念、安裝、首次使用流程、基礎能力、Prompt 結構、Plan 模式、AGENTS.md、進階功能(Skills、Automations、MCP、多 Agent)到完整實戰案例,一步步帶讀者建立一套同 Agent 協作嘅方法。

  • Codex 已經唔係單純 code 生成器,而係一個可以讀項目、改檔案、行命令嘅 AI Agent,將編程由問答式推進到任務式執行。
  • 使用 Codex 嘅關鍵係清晰定義目標、背景、限制同驗收標準,避免模糊指令,否則佢會亂猜。
  • 第一次用 Codex 要循序漸進:先讀項目唔改 code,再解釋結構,做極細微修改,最後先做功能;每一步都 check diff。
  • 喺項目根目錄放 AGENTS.md 可以寫低技術棧、命令、規範同禁止事項,等 Codex 每次進入都跟住規則做。
  • 進階功能如 Skills、AutomationsMCP 可以將重複流程自動化,但要設好邊界同人工覆核,唔好無腦執行。
值得記低
Prompt

第一次讀項目嘅標準指令

先唔好修改任何 code。請通讀當前項目,回答:1. 呢個項目係做乜;2. 用咗咩技術棧;3. 主要目錄結構;4. 啟動命令;5. 測試或類型檢查命令;6. 首頁或主入口檔案;7. 如果要新增頁面,應該從邊度開始。

Skill

AI 工具拆解 Skill

當我要求拆解一個 AI 工具時,請按以下結構輸出:1. 呢個工具解決咩問題;2. 適合咩人;3. 主要功能;4. 新手點樣上手;5. 三個真實使用場景;6. 同同類工具嘅分別;7. 適合做成咩內容選題。

結構示例

內容片段

內容片段 text
先不要修改任何代碼。請通讀當前項目,並回答:
1. 這個項目是做什麼的;
2. 使用了哪些技術棧;
3. 主要目錄結構是什麼;
4. 啓動命令是什麼;
5. 測試或類型檢查命令是什麼;
6. 首頁或主入口文件在哪裏;
7. 如果我要新增一個頁面,應該從哪裏開始。
整理重點

Codex 嘅核心定位:從問答到執行

以前嘅 AI 編程工具好似「code 問答器」——你問點樣寫登入頁,佢畀一段 code,你複製貼上,報錯再返嚟問。呢個流程入面,AI 只係俾材料,真正執行嘅仍然係你。

Codex 嘅方式唔一樣:你可以將一個真實項目目錄交畀佢,等佢先讀項目,再按你要求修改檔案、行命令、檢查結果。

例如你唔係淨係話「幫我寫一個登入頁」,而係話:「請喺當前項目入面新增一個登入頁面。要求:1. 重用現有 UI 組件;2. 唔引入新表單庫;3. 支援電郵同密碼輸入;4. 加基礎校驗;5. 修改完成後行類型檢查;6. 最後總結改咗邊啲檔案。」

呢種轉變令 Codex 適合嘅人唔止係程序員。產品經理可以叫佢解釋技術項目,運營可以叫佢做輕量小工具,團隊負責人可以叫佢做項目檢查。門檻在於你能否將任務講清楚。

整理重點

入門操作:先讀後改,逐步建立信任

第一次打開 Codex,最常見嘅錯誤係直接叫佢「幫我做一個完整系統」。呢類需求太模糊,邊界唔清,好易寫出一堆睇落熱鬧但好難維護嘅嘢。

正確流程係:先讀項目,再解釋結構,再做細微修改,最後先做功能

  1. 1 第一步:只讀項目。輸入「先唔好修改任何 code。請通讀當前項目,回答:1.呢個項目係做乜;2.用咗咩技術棧;3.主要目錄結構;4.啟動命令;5.測試或類型檢查命令;6.首頁或主入口檔案;7.如果要新增頁面,應該從邊度開始。」
  2. 2 第二步:解釋關鍵模塊。例如「請重點解釋『內容列表』模塊,說明頁面檔案位置、數據來源、組件之間點樣傳數據、有冇狀態管理、如果要加篩選功能大概要改邊啲檔案。」
  3. 3 第三步:做一個極細微修改。例如「請將首頁主按鈕文案由『開始使用』改做『立即體驗』,只改必要檔案,唔調整樣式,改完話我知改咗邊個檔案。」
  4. 4 第四步:做一個可驗證嘅小功能。例如「請幫列表頁加一個搜索框,重用現有樣式、唔引入新 UI 庫、支援關鍵詞過濾、唔修改後端接口,改完行類型檢查並總結修改檔案。」
  5. 5 第五步:檢查 diff。叫 Codex 先總結 diff,然後你自己睇一次 Git diff,確保冇無關改動。

小任務唔係為咗省時間,而係測試 Codex 嘅執行邊界。一個小文案都改得精準,後面先值得叫佢做功能。

另外,建議喺項目根目錄放一個 AGENTS.md,寫低技術棧、常用命令、code 規範同禁止事項。咁樣 Codex 每次進入項目都自動跟住規則,唔使你重複講。

整理重點

進階用法:Skills、Automations、MCP 同實戰案例

Skills 唔係提示詞收藏夾,而係將重複流程封裝成一套標準執行步驟。例如你做 AI 工具教程,可以做一個「工具拆解 Skill」,規定每次拆解嘅結構;你做 code review,可以做一個「code 審查 Skill」。

Skills 嘅意義係沉澱你嘅工作習慣。你反覆講過十次嘅規則,唔應該每次都手動複製。

  • Automations 適合定時檢查,例如每週五自動整理項目更新、生成週報草稿,但唔適合高風險自動執行。
  • MCP 同插件可以將 Codex 接入 GitHubFigma、Notion 等工具,但要按需安裝,唔係越多越好。
  • 多 Agent 並行要分清任務邊界,避免幾個 Agent 同時改同一批檔案。每個線程完成後先睇 diff,合併前總結衝突風險。

最後,文章提供咗一個完整實戰案例:做一個「公眾號選題管理工具」。流程係:先叫 Codex 設計方案(唔寫 code),再實作最小版本(用前端陣列寫死數據),然後加本地保存(localStorage),再加覆盤字段,最後生成 README。呢個流程任何人都可以跟住做。

圖片



哈囉,大家好,我係阿星

琴日去學劉潤年中大課,發現企業家個個都喺度學codex👉🏻劉潤年中大課筆記:一句話講清楚AI落地之戰嘅本質

嚇到我即刻返嚟整理咗呢本手冊😂

都係嗰句話,如果你而家得閒學一個AI工具,淨係學codex就夠㗎喇。希望呢本手冊可以幫你慳返啲時間。

圖片
🦄

呢篇文章只係解決入門實操問題。

可以當教程睇,亦都可以當手冊嚟查。

背景

好多人第一次聽講 Codex,會下意識將佢理解成「OpenAI 版嘅 Cursor」或者「另一個 AI 寫 code 工具」。呢個理解唔算錯,但係唔夠準確。今日嘅 Codex 已經唔係一個單純嘅 code 生成器。

佢更加似一個可以進入項目現場嘅 AI 編程 Agent:

可以讀項目、改檔案、執行指令、處理 Git、叫插件,亦都可以經桌面版、命令行、IDE、Web、Chrome 擴展進入唔同嘅工作流程。

圖片


OpenAI 官方將 Codex 定義為面向軟件開發嘅 coding agent,使用方面:ChatGPT Plus、Pro、Business、Edu、Enterprise 都包含 Codex 使用途徑。(OpenAI Developers)

圖片

1. Codex 係咩嘢?

一句講曬:

Codex 係 OpenAI 面向軟件開發同工作自動化嘅 AI Agent。

普通 AI 編程工具更加似「code 問答器」。你問佢點樣寫登入頁,佢俾你一段 code;你複製到項目入面,執行,出錯,再返嚟問佢點樣整返好。呢個流程入面,AI 淨係俾材料,真正執行嘅人仲係你。

Codex 嘅方式唔一樣。你可以將一個真實項目目錄交俾佢,叫佢先讀項目,再按你嘅要求修改檔案、執行指令、檢查結果。例如你唔單止話「幫我寫一個登入頁」,而係話:

請在當前項目中新增一個登錄頁面。

要求:
1. 複用現有 UI 組件;
2. 不引入新的表單庫;
3. 支持郵箱和密碼輸入;
4. 增加基礎校驗;
5. 修改完成後運行類型檢查;
6. 最後總結修改了哪些文件。

呢個就唔係「生成 code 片段」,而係「執行一個開發任務」。

Codex 嘅核心價值亦喺呢度:佢將 AI 編程由「問答式生成」,推向「任務式執行」進咗一步。你唔再淨係關心佢識唔識寫某個函數,而係要學識幫佢定義目標、範圍、限制同驗收標準。


Image



2. Codex 適合邊啲人?

Codex 嘅第一批核心用戶當然係 programmer,但係佢唔止適合 programmer。只要你嘅工作裏面有項目、網頁、表格、重複流程、小工具需求,佢都可能有用。

Programmer 可以用佢處理日常開發入面嗰啲唔難但係花時間嘅事:讀陌生嘅 code base、補測試、整返好出錯、拆 components、搬舊 API、生成 PR 描述。

佢最舒服嘅區間唔係「由 0 做一個巨型系統」而係有明確 context 嘅中等任務,例如「將當前列表頁加一個搜尋功能」、「俾呢個 module 補 unit test」、「將呢幾個重複嘅 function 抽做工具方法」。

Product manager 可以用佢理解技術項目。例如你接手一個後台系統,唔知道某個功能嘅數據由邊度嚟,可以叫 Codex 解釋頁面、接口、狀態管理之間嘅關係。佢未必可以幫你做技術決策,但係可以令到你同研發溝通嘅時候少啲「靠估」。

營運、自媒體人、培訓老師亦可以用。呢度唔使將自己當成 programmer。你可以叫 Codex 做一啲輕量小工具,例如選題管理頁面、課程資料整理器、評論關鍵詞統計 script、圖片批量改名工具、Excel 清洗 script。

團隊負責人可以用佢做項目檢查。例如總結最近一個星期嘅改動,整理等緊 review 嘅 branch,分析邊啲 module 欠 test,或者將項目入面嘅重複邏輯列曬出嚟。佢唔一定直接改 code,但係可以幫你先理清楚啲資訊。

所以,Codex 嘅使用門檻唔在於「你識唔識寫 code」,而在於你識唔識將個任務講清楚。


Image



3. Codex 嘅主要入口點樣揀?

Codex 唔係一個單一入口,佢而家更加似一個產品家族。

新手唔使一次過學曬。先按自己嘅場景去揀。

我嘅建議好簡單:如果你唔知道揀邊個,先裝 Desktop。佢係最容易理解嘅入口。你可以睇到項目、線程、修改檔案、diff、插件同任務狀態,唔會似命令行咁一開始就有壓力。

Programmer 可以 Desktop + CLI 一齊用。Desktop 負責管理任務,CLI 負責喺終端機入面快速調用。IDE 插件適合你喺編輯器入面寫 code 嘅時候用,唔使來回切換視窗。Cloud 更加適合長任務同團隊協作。Chrome 插件就係工作自動化方向,後面會單獨講。

Image



4. 安裝方式:先行到先講

4.1 安裝 Codex Desktop

如果你係新手,優先安裝桌面版。打開官方 Codex 頁面,按系統下載 macOS 或 Windows 版本就得。

圖片

Codex App 官方文件顯示,佢支援用 ChatGPT 賬號或 API key 登入,並選擇本地項目資料夾開始工作。

圖片

安裝完成之後,建議先做三件事:

  1. 1.登入你嘅 ChatGPT 賬號;
  2. 2.新建或選擇一個項目資料夾;
  3. 3.喺第一個對話入面叫 Codex 淨係讀項目,唔好直接改 code。

唔好急住裝插件、開自動化、接 MCP。先叫佢做一個最小任務試嚇手感。

4.2 安裝 Codex CLI

如果你熟悉命令行,可以安裝 CLI。官方 Codex CLI 係本地終端機入面嘅 coding agent,可以讀取、修改同執行你選擇嘅目錄入面嘅 code。(OpenAI Developers)

常見安裝方式:

npm install -g @openai/codex

驗證安裝:

codex --version

入咗項目目錄之後啓動:

codex

亦可以直接俾任務:

codex "請解釋這個項目的目錄結構"

CLI 適合開發者。佢更快、更直接,但對非技術用戶就冇 Desktop 咁親民。

4.3 安裝 IDE 插件

如果你日常用 VS Code,可以安裝 Codex IDE 插件。

佢適合處理編輯器現場嘅小任務:

解釋當前檔案、修改揀咗嘅 code、俾 component 補 test、根據 diff 寫 commit message。

4.4 Chrome 插件唔好急住開

Chrome 插件好勁,但亦更加敏感。佢嘅作用係叫 Codex 用你 Chrome 入面嘅登入狀態,處理需要登入嘅網站任務。官方文件明確提到,Codex Chrome extension 適合嗰啲需要 signed-in browser state 嘅瀏覽器任務,例如需要讀取或操作已登入網站。(OpenAI Developers)

如果你只係啱啱入門,唔建議第一日就開呢個。先將本地項目入面嘅讀 code、改 code、睇 diff 做到順手,再研究網頁自動化。

Image


5. 第一次用 Codex:唔好直接叫佢做大項目

第一次打開 Codex,最常見嘅錯誤係直接話:

「幫我做一個完整系統。」

呢類需求太大,邊界唔清楚,AI 好容易寫出一大堆睇落好熱鬧但好難維護嘅嘢。

正確流程應該係:先讀項目,再解釋結構,再做細微改動,最後先做功能。

第一步:淨係讀項目

第一次入到項目,先輸入:

先不要修改任何代碼。

請通讀當前項目,並回答:
1. 這個項目是做什麼的;
2. 使用了哪些技術棧;
3. 主要目錄結構是什麼;
4. 啓動命令是什麼;
5. 測試或類型檢查命令是什麼;
6. 首頁或主入口文件在哪裏;
7. 如果我要新增一個頁面,應該從哪裏開始。

呢條指令嘅重點係「先唔好修改任何 code」。你唔係叫佢即刻開工,而係先叫佢建立 context。好多項目本身冇文件,Codex 可以幫你先補一個「口頭項目說明」。

第二步:解釋關鍵模塊

例如你想了解選題管理、登入、訂單、課程報名呢類模塊,可以繼續問:

請重點解釋當前項目裏的“內容列表”模塊。

請說明:
1. 頁面文件在哪裏;
2. 數據從哪裏來;
3. 組件之間如何傳遞數據;
4. 有沒有狀態管理;
5. 如果我要增加篩選功能,大概需要改哪些文件。

仍然不要修改代碼。

呢一步用嚟判斷 Codex 係咪真係睇明咗個項目。如果佢只能夠泛泛而談,就唔適合即刻交複雜任務俾佢。

第三步:做一個超細微嘅修改

比如:

請把首頁主按鈕文案從“開始使用”改成“立即體驗”。

要求:
1. 只修改必要文件;
2. 不調整樣式;
3. 不改其他文案;
4. 修改後告訴我改了哪個文件。

小任務唔係為咗慳時間,而係為咗測試佢嘅執行邊界。細微嘅文案改動都改得精準,後面先值得叫佢做功能。

第四步:做一個可以驗證嘅小功能

例如幫列表頁加搜尋功能:

請給當前列表頁增加一個搜索框。

要求:
1. 複用現有樣式;
2. 不引入新的 UI 庫;
3. 支持按關鍵詞過濾列表;
4. 不修改後端接口;
5. 修改後運行類型檢查;
6. 最後總結修改了哪些文件,以及如何驗證。

呢個任務大小比較合適:有 context、有邊界、有驗收標準。Codex 最適合由呢類任務開始練。

第五步:檢查 diff

無論 Codex 總結得幾好,都唔好 skip 咗 diff。你可以叫佢先自查:

請總結當前 diff:
1. 修改了哪些文件;
2. 每個文件為什麼修改;
3. 有沒有無關改動;
4. 有沒有潛在風險;
5. 是否運行了測試或類型檢查。

然後你自己再睇一次 Git diff。如果一個小任務改咗幾十個檔案,就要小心。

Image

6. 基礎能力:讀 code、改 code、修 Bug、寫 test

Codex 嘅基礎能力可以分成四類。

唔好急住學進階功能,

先將呢四件事用到順手。

6.1 讀 code

讀 code 係最穩陣嘅入門場景。

適合接手舊項目、學習開源項目、理解外判交付項目,

亦適合 product manager 理解開發實現。

提示詞:

請解釋這個項目的整體架構。

輸出格式:
1. 項目用途;
2. 技術棧;
3. 目錄結構;
4. 核心模塊;
5. 數據流;
6. 啓動方式;
7. 新人上手建議。

不要修改代碼。

如果你做內容或培訓,可以叫佢進一步生成「俾非 programmer 睇嘅解釋版」:

請把上面的項目結構解釋成非程序員也能聽懂的版本。
不要出現太多術語,如果必須出現,請順手解釋。

呢個用法好啱用嚟做技術課程、工具教學、內部培訓材料。

6.2 改 code

改 code 嘅時候,一定要寫清楚「邊啲唔可以改」。好多 AI 出問題,

唔係因為唔識寫,而係為咗完成目標順手改咗唔應該改嘅地方。

示例:

請重構當前組件。

目標:
1. 降低組件複雜度;
2. 抽離重複邏輯;
3. 保持現有功能不變;
4. 不修改對外 props;
5. 不改變樣式表現。

執行前請先給出計劃,等我確認後再修改。

尤其係「保持現有功能不變」、「唔修改對外 props」呢類限制,

要寫出嚟。

AI 唔會自然知道你嘅隱藏規則。

6.3 修 Bug

修 Bug 嘅時候,唔好淨係貼一句「出錯啦」。要貼曬成個錯誤訊息、操作步驟、預期結果。

提示詞:

我遇到了下面這個報錯:

[粘貼完整報錯]

復現步驟:
1. 打開某個頁面;
2. 點擊某個按鈕;
3. 出現報錯。

請按步驟處理:
1. 解釋報錯含義;
2. 判斷最可能的原因;
3. 列出你要檢查的文件;
4. 給出修復計劃;
5. 等我確認後再修改代碼。

如果已經允許佢修改,可以加一句:

修復後請運行相關測試或啓動命令,確認問題是否解決。

6.4 寫 test

寫 test 好啱交俾 Codex。因為測試規則明確,重複性高,亦方便驗證。

提示詞:

請為當前模塊補充測試。

要求:
1. 參考項目已有測試風格;
2. 覆蓋正常情況、異常情況和邊界情況;
3. 不修改業務邏輯;
4. 測試文件命名遵循項目規範;
5. 寫完後運行測試並彙報結果。

如果項目冇 test,可以先叫佢檢查:

請先檢查當前項目是否已有測試框架和測試示例。

如果有,請說明測試框架、測試命令和推薦寫法。
如果沒有,請給出最小化測試方案,先不要安裝依賴。


Image

7. Prompt 寫法:唔好傾偈,要派任務

Codex 唔係普通傾偈工具。你要似俾同事派任務咁寫指令。最實用嘅結構係四個部分:目標、背景、限制、驗收標準。

差嘅寫法:

幫我優化一下頁面。

呢個指令太空泛。優化啲乜?速度、樣式、互動、結構定係 SEO?Codex 只能靠估。

好嘅寫法:

【目標】
優化當前文章列表頁的加載速度。

【背景】
這是一個 Next.js 項目,文章列表頁目前首屏加載偏慢。

【限制】
1. 不改變頁面視覺效果;
2. 不修改後端接口;
3. 不引入新的狀態管理庫;
4. 優先檢查重複請求和不必要渲染。

【驗收標準】
1. 給出性能問題分析;
2. 修改前先列出計劃;
3. 修改後運行類型檢查;
4. 總結修改文件和驗證方式。

寫得清楚,唔係為咗顯得專業,而係為咗減少重做。

一個簡單判斷標準:

如果呢個需求交俾真人同事都聽唔明,

咁 Codex 好大機會都會走偏。

Image

8. Plan 模式:複雜任務先規劃

只要任務會影響多個檔案,就應該先規劃。尤其係登入、權限、數據庫、支付、部署、大規模重構,唔好叫 Codex 直接動手。

提示詞:

請先進入計劃模式,不要修改代碼。

任務:
給當前項目新增“文章收藏”功能。

請輸出:
1. 需要修改哪些文件;
2. 每個文件準備做什麼;
3. 是否需要新增依賴;
4. 是否涉及數據結構變化;
5. 可能的風險點;
6. 驗證方式。

等我確認後再執行。


呢個習慣會令你少踩好多陷阱。

Image

9. AGENTS.md:俾 Codex 嘅項目說明書

如果你長期喺一個項目入面用 Codex,建議喺項目根目錄放一個 AGENTS.md。佢相當於項目說明書,將技術棧、啟動指令、code 規範、禁止事項寫清楚。

示例:

# AGENTS.md

## 項目簡介
這是一個內容選題管理工具,用於記錄選題、平台、狀態、發佈時間和覆盤數據。

## 技術棧
- Next.js
- TypeScript
- Tailwind CSS
- shadcn/ui
- SQLite

## 常用命令
- npm run dev:啓動開發環境
- npm run build:構建項目
- npm run lint:運行 lint
- npm run test:運行測試

## 代碼規範
- 使用函數組件;
- 所有組件使用 TypeScript;
- 樣式優先使用 Tailwind;
- 不要引入新的 UI 庫;
- 不要修改數據庫結構,除非任務明確要求。

## 目錄說明
- src/app:頁面
- src/components:通用組件
- src/lib:工具函數
- src/db:數據庫相關代碼

## 注意事項
- 修改超過 3 個文件前,必須先給出計劃;
- 涉及數據刪除操作時,必須等待人工確認;
- 完成任務後必須總結修改內容。

有咗呢個檔案,你唔使每次都由頭講規則。Codex 入咗項目之後,可以更快貼近你嘅項目習慣。


Image

10. Codex for Chrome:將瀏覽器入面嘅重複動作交俾 AI

Codex for Chrome 係一個好關鍵嘅變化。佢令 Codex 唔止停留喺 code 項目入面,而係可以喺授權之後用你嘅 Chrome 登入狀態,處理一啲網頁任務。官方文件對佢嘅描述係:當 Codex 需要讀取或操作需要登入狀態嘅網站時,可以使用 Chrome extension。(OpenAI Developers)

呢類任務一般有三個特徵:路徑固定、動作重複、結果可以人工覆核。

舉個內容團隊嘅例子。每星期覆盤嘅時候,可以利用佢嚟覆盤數據。呢個流程唔複雜,但好花時間。你可以叫 Codex 先整理數據:

請打開我已經登錄的幾個內容平台後台,整理最近 7 天的數據。

需要記錄:
1. 內容標題;
2. 發佈時間;
3. 閲讀量或播放量;
4. 點贊、收藏、評論;
5. 新增粉絲;
6. 表現最好的 3 條內容。

請先整理成表格,不要發送給任何人。完成後等我檢查。

呢度嘅重點唔係叫 Codex 幫你判斷邊條內容一定會爆,而係叫佢先完成「打開網頁、讀取數據、整理表格」呢啲重複動作。最後邊啲數據有效、點樣覆盤,仍然由人嚟判斷。

同樣嘅邏輯可以放到其他場景:

教培機構整理學生簽到同功課提交情況;

招聘團隊匯總候選人面試狀態;

行政同事檢查供應商資料係咪缺字段;

活動營運將多個報名頁面嘅數據合成一張表……


Image

11. 內置瀏覽器、Chrome 插件、Computer Use、MCP 有咩分別?

呢幾個概念好容易混淆。

內置瀏覽器更適合開發場景。例如你叫 Codex 啟動本地項目,喺瀏覽器入面打開 localhost:3000,睇嚇頁面有冇行到,再根據截圖修改樣式。

Chrome 插件適合需要登入狀態嘅網站。例如內容平台後台、內部系統、電郵、項目管理工具。

Computer Use 更偏向桌面操作,例如某啲冇 API、冇網頁入口嘅軟件。呢個能力更強,但亦更需要小心。

MCP 同插件係更穩定嘅連接方式。

如果一個工具有 GitHub、Figma、Notion、數據庫呢類接口,優先使用插件或 MCP。行到結構化接口,就唔好叫 AI 模擬滑鼠點擊。OpenAI 官方亦將 Plugins 作為 Codex 擴展能力嘅一部分,用嚟連接外部應用、skills 同 MCP servers。

Image

12. Skills:將你嘅經驗變成 Codex 嘅工作流程

Skills 唔係提示詞收藏夾。佢更加似將一套重複流程封裝起嚟,令 Codex 每次按同樣標準執行。

OpenAI 官方文件對 Skills 嘅解釋係:skill 會打包說明、資源同可選 script,令 Codex 更可靠地跟隨某個工作流程。

如果你成日做 AI 工具教學,可以做一個「工具拆解 Skill」。規則可能係:

當我讓你拆解一個 AI 工具時,請按以下結構輸出:
1. 這個工具解決什麼問題;
2. 適合什麼人;
3. 主要功能;
4. 新手怎麼上手;
5. 三個真實使用場景;
6. 和同類工具的區別;
7. 適合做成什麼內容選題。

如果你做企業 AI 培訓,可以做一個「培訓課件 Skill」:

當我給你一個 AI 工具主題時,請幫我生成半天培訓方案。

輸出:
1. 培訓對象;
2. 培訓目標;
3. 課程模塊;
4. 每個模塊的講解重點;
5. 現場練習;
6. 學員作業;
7. 講師提示。

如果你係開發團隊,可以做「code 審查 Skill」:

審查代碼時,請優先關注:
1. 是否有明顯 Bug;
2. 是否破壞現有 API;
3. 是否存在安全風險;
4. 是否缺少必要測試;
5. 是否有過度設計;
6. 是否有無關文件被修改。

只標出重要問題,不要糾結格式偏好。

Skills 嘅意義係沉澱自己嘅工作習慣。

你重複講過十次嘅規則,就唔應該每次都手動複製。

將佢變成 Skill,先係將 Codex 由「傾偈工具」變成「個人工作台」嘅關鍵。

Image

13. Automations:適合做定時檢查,唔適合無腦執行

Automations 可以令 Codex 按計劃喺後台執行 recurring tasks。官方文件亦提到,佢可以將發現嘅結果放入 inbox,如果冇乜嘢可以報告,亦可以自動歸檔;同時可以同 Skills 組合使用。

注意,呢個功能最適合「檢查」同「整理」,唔適合一開始就做高風險自動執行。

例如內容團隊可以設定一個逢星期五自動任務:

每週五下午,檢查本週內容項目的更新情況。

請整理:
1. 本週新增了哪些選題;
2. 哪些選題已經發布;
3. 哪些選題卡在待修改狀態;
4. 哪些內容數據表現最好;
5. 下週建議優先推進的 5 個選題。

輸出一份週報草稿,等我確認後再使用。

開發團隊可以設定:

每天早上檢查當前項目狀態。

請整理:
1. 昨天新增的問題;
2. 仍未關閉的高優先級任務;
3. 最近失敗的構建或測試;
4. 需要人工 review 的分支;
5. 今天建議優先處理的事項。

只生成報告,不要自動修改代碼。

培訓團隊亦可以用:

每週一上午檢查課程資料庫。

請整理:
1. 本週要交付的培訓主題;
2. 哪些課件還沒準備;
3. 哪些案例需要更新;
4. 哪些工具最近有重大更新;
5. 建議補充的練習題。

只輸出清單,不要修改文件。

Automations 嘅價值唔係「叫 AI 幫你返工」,而係將每日、每星期固定要睇嘅材料預先擺好。佢似一個定時醒嘅助理,唔係一個可以無限放權嘅員工。

Image

14. MCP 與插件:將 Codex 接入真實工具

當 Codex 淨係留喺本地項目入面,佢主要係編程助手。

當佢接入 GitHub、Figma、Notion、Linear、數據庫、Slack 呢啲工具之後,

先開始似一個工作流程 Agent。

典型場景有幾個。

第一,接 GitHub。你可以叫 Codex 總結某個 PR 改咗啲乜、有咩風險、review 評論點樣處理,亦都可以叫佢根據 issue 生成實現計劃。

第二,接 Figma。設計稿唔係截圖,而係結構化節點。透過插件或 MCP,Codex 可以讀取設計結構,再生成更接近設計稿嘅前端組件。亦可以直接用 Codex 入面自帶嘅圖像工具轉成前端 code,實現像素級還原。詳細可以睇我上星期嘅文章入面有,往前翻一下🍎🍎🍎

第三,接項目管理工具。例如將待辦任務拉出嚟,按優先級排序,或者將完成情況整理成週報。

第四,接數據庫。呢個場景要小心。更適合查詢同分析,唔建議叫 Codex 直接改生產數據。呢個之前都寫過,可以直接搜嚇關鍵詞 supabase🤔😂

一個比較穩陣嘅用法係:

請讀取項目管理工具裏本週標記為“待處理”的任務。

請按以下格式整理:
1. 任務標題;
2. 所屬模塊;
3. 優先級;
4. 是否阻塞其他任務;
5. 建議處理順序。

只整理,不修改任務狀態。

MCP 同插件嘅關鍵唔係「接得越多越好」。

根據自己需要安裝就得。

Image

15. 多 Agent:唔好同時亂行,要分清任務邊界

Codex 支援多線程、多項目、worktree 等功能。OpenAI 官方功能頁亦提到,Codex App 支援 side-by-side 嘅項目線程同內置 Git worktree,用嚟隔離並行 code 變更。

直接執行

 codex features enable multi_agent


設定檔 ~/.codex/config.toml 入面加個並發上限參數,即係最多允許幾個嘅意思。佢就會自己 spawn_agent。

呢個好有用,但唔可以亂用。

正確用法係將任務拆清楚。例如你要做一個內容選題管理工具,可以分成三個線程:

線程 A:實現選題列表同狀態篩選。

線程 B:設計數據結構同本地儲存。

線程 C:生成 README 同使用說明。

呢三個任務之間有邊界,唔容易互相踩檔案。如果你叫三個 Agent 同時改同一個核心組件,好大機會會衝突。

多 Agent 嘅建議:

  1. 1.每個線程只負責一個明確任務;
  2. 2.盡量避免多個線程同時改同一批檔案;
  3. 3.每個線程完成後先睇 diff;
  4. 4.合併前叫 Codex 總結衝突風險;
  5. 5.重要變更必須人工 review。

多 Agent 並行嘅價值唔係炫技,

而係將可以並行嘅任務分出去。

你要似分配同事工作咁分配 Codex,

而唔係叫佢哋喺同一個檔案入面打交。

Image

16. 實戰案例:用 Codex 做一個「公眾號選題管理工具」

下面俾一個完整案例。呢個案例適合普通人,亦適合 programmer 練手。目標唔係做一個複雜系統,而係做一個自己用得着嘅小工具。

16.1 項目目標

 第一步:叫 Codex 設計方案

我想做一個本地運行的“內容選題管理工具”。

請先不要寫代碼,先給我方案。

功能要求:
1. 可以新增選題;
2. 可以編輯選題;
3. 可以按狀態篩選;
4. 可以按平台篩選;
5. 可以搜索標題;
6. 可以記錄發佈時間和覆盤備註;
7. 數據先保存在本地,不做登錄。

請輸出:
1. 推薦技術方案;
2. 頁面結構;
3. 數據結構;
4. 需要創建哪些文件;
5. 第一個最小可用版本怎麼做。

呢一步只要方案,唔要 code。先睇佢點樣拆。

 第二步:叫佢做最小版本

請實現第一個最小可用版本。

要求:
1. 使用當前項目已有技術棧;
2. 頁面包含選題列表、搜索框、狀態篩選、新增選題按鈕;
3. 數據可以先寫死在前端數組裏;
4. 不接數據庫;
5. 不引入新的 UI 庫;
6. 完成後運行類型檢查;
7. 最後告訴我如何打開頁面。

呢度特登先唔用數據庫。先叫頁面行得鬱。

第三步:增加本地儲存

請把選題數據改成本地保存。

要求:
1. 使用 localStorage;
2. 支持新增、編輯、刪除;
3. 刷新頁面後數據仍然存在;
4. 不接後端;
5. 不改變現有頁面佈局;
6. 修改前先說明會改哪些文件。

呢個功能仍然可控,適合練 Codex。

第四步:增加覆盤字段

請給每條選題增加“數據覆盤”字段。

字段包括:
1. 閲讀量或播放量;
2. 點贊數;
3. 收藏數;
4. 評論數;
5. 覆盤備註。

要求:
1. 列表頁顯示核心數據;
2. 編輯彈窗裏可以修改;
3. 不影響已有數據;
4. 如果老數據沒有這些字段,請做兼容處理。

呢度開始接近真實使用。你會見到 Codex 係咪可以處理舊數據兼容。

第五步:生成使用說明

請根據當前項目,生成一份 README。

要求:
1. 說明這個工具是做什麼的;
2. 說明如何安裝依賴;
3. 說明如何啓動;
4. 說明主要功能;
5. 說明數據保存在什麼地方;
6. 說明後續可以擴展哪些功能。

呢個就係一個完整嘅小項目流程:

先方案,後最小版本,

再迭代,再寫文件。

普通人都可以跟住做。


Image

17. 真正要學嘅唔係 Codex,而係點樣派任務

Codex 當然係一個工具,但如果淨係將佢當工具睇,會低估咗呢件事。

佢真正帶嚟嘅變化,係人同軟件生產之間嘅分工變咗。呢度嘅關鍵唔係「AI 有幾聰明」,而係你識唔識派任務。

任務講唔清楚,Codex 就會亂咁估。邊界唔俾,佢就可能改多咗。驗收標準冇,佢就唔知做到咩程度先算結束。你將佢當傾偈對象,佢就俾你傾偈式回答;你將佢當執行者,就要俾目標、背景、限制同驗收標準。

對新手嚟講,先記住一條就夠:唔好叫 Codex 估你嘅需求。

呢個亦都係點解我將呢篇叫《阿星Codex 編程白皮書》,而唔係簡單叫「Codex 教學」。

教學解決嘅係點樣㩒掣。白皮書解決嘅係點樣建立一套方法。

Codex 只係開始。真正重要嘅係,我哋要學識同 Agent 一齊工作。

ok,我係阿星,更多AI應用,我哋下期再見!


圖片
圖片



哈嘍,大家好,我是阿星

昨天去學習劉潤年中大課發現企業家都在學codex👉🏻劉潤年中大課筆記:一句話說清AI落地之戰的本質

嚇得我趕緊回來整理了這個手冊😂

還是那句話,如果你現在只有空學一個AI工具,只學codex足夠了。希望這個手冊能替你省時間。

圖片
🦄

這篇文章 只解決入門實操問題。

可以當教程看,也可以當手冊查。

背景

很多人第一次聽到 Codex,會下意識把它理解成“OpenAI 版的 Cursor”或者“另一個 AI 寫代碼工具”。這個理解不算錯,但不夠準確。今天的 Codex 已經不是一個單純的代碼生成器。

它更像一個能進入項目現場的 AI 編程 Agent:

可以讀項目、改文件、運行命令、處理 Git、調用插件,也可以通過桌面端、命令行、IDE、Web、Chrome 擴展進入不同的工作流。

圖片


OpenAI 官方把 Codex 定義為面向軟件開發的 coding agent,使用方面:ChatGPT Plus、Pro、Business、Edu、Enterprise 都包含 Codex 使用途徑。(OpenAI Developers)

圖片

1.Codex 是什麼?

一句話定義:

Codex 是 OpenAI 面向軟件開發和工作自動化的 AI Agent。

普通 AI 編程工具更像“代碼問答器”。你問它怎麼寫登錄頁,它給你一段代碼;你複製到項目裏,運行,報錯,再回來問它怎麼修。這個流程裏,AI 只是給材料,真正執行的人還是你。

Codex 的方式不一樣。你可以把一個真實項目目錄交給它,讓它先讀項目,再按你的要求修改文件、運行命令、檢查結果。比如你不只是說“幫我寫一個登錄頁”,而是說:

請在當前項目中新增一個登錄頁面。

要求:
1. 複用現有 UI 組件;
2. 不引入新的表單庫;
3. 支持郵箱和密碼輸入;
4. 增加基礎校驗;
5. 修改完成後運行類型檢查;
6. 最後總結修改了哪些文件。

這就不是“生成代碼片段”,而是“執行一個開發任務”。

Codex 的核心價值也在這裏:它把 AI 編程從“問答式生成”,往“任務式執行”推進了一步。你不再只關心它會不會寫某個函數,而是要學會給它定義目標、範圍、限制和驗收標準。


Image



2.Codex 適合哪些人?

Codex 的第一批核心用戶當然是程序員,但它不只適合程序員。只要你的工作裏有項目、網頁、表格、重複流程、小工具需求,它都可能有用。

程序員可以用它處理日常開發中那些不難但耗時間的事:讀陌生代碼庫、補測試、修報錯、拆組件、遷移舊接口、生成 PR 描述。

它最舒服的區間不是“從 0 做一個巨型系統”,而是有明確上下文的中等任務,比如“把當前列表頁加一個搜索功能”“給這個模塊補單元測試”“把這幾個重複函數抽成工具方法”。

產品經理可以用它理解技術項目。比如你接手一個後台系統,不知道某個功能的數據從哪裏來,可以讓 Codex 解釋頁面、接口、狀態管理之間的關係。它未必能替你做技術決策,但能讓你和研發溝通時少一點“憑感覺猜”。

運營、自媒體人、培訓老師也可以用。這裏不用把自己想成程序員。你可以讓 Codex 做一些輕量小工具,比如選題管理頁面、課程資料整理器、評論關鍵詞統計腳本、圖片批量重命名工具、Excel 清洗腳本。

團隊負責人可以用它做項目檢查。比如總結最近一週改動,整理待 review 分支,分析哪些模塊缺測試,或者把項目裏的重複邏輯列出來。它不一定直接改代碼,但可以幫你把信息先理出來。

所以,Codex 的使用門檻不在於“你是不是會寫代碼”,而在於你能不能把任務說清楚。


Image



3.Codex 的主要入口怎麼選?

Codex 不是一個單一入口,它現在更像一個產品家族。

新手不用一上來全學。先按自己的場景選。

我的建議很簡單:如果你不知道選哪個,先裝 Desktop。它是最容易理解的入口。你能看到項目、線程、修改文件、diff、插件和任務狀態,不會像命令行那樣一開始就有壓力。

程序員可以 Desktop + CLI 一起用。Desktop 負責管理任務,CLI 負責在終端裏快速調用。IDE 插件適合你正在編輯器裏寫代碼時使用,不用來回切窗口。Cloud 更適合長任務和團隊協作。Chrome 插件則是工作自動化方向,後面單獨講。

Image



4.安裝方式:先跑起來

4.1 安裝 Codex Desktop

如果你是新手,優先安裝桌面端。打開官方 Codex 頁面,按系統下載 macOS 或 Windows 版本即可。

圖片

Codex App 官方文檔顯示,它支持用 ChatGPT 賬號或 API key 登錄,並選擇本地項目文件夾開始工作。

圖片

安裝完成後,建議先做三件事:

  1. 1.登錄你的 ChatGPT 賬號;
  2. 2.新建或選擇一個項目文件夾;
  3. 3.在第一個對話裏讓 Codex 只讀項目,不要直接改代碼。

不要急着裝插件、開自動化、接 MCP。先讓它跑一個最小任務玩玩手感。

4.2 安裝 Codex CLI

如果你熟悉命令行,可以安裝 CLI。官方 Codex CLI 是本地終端裏的 coding agent,可以讀取、修改和運行你選擇目錄裏的代碼。(OpenAI Developers)

常見安裝方式:

npm install -g @openai/codex

驗證安裝:

codex --version

進入項目目錄後啓動:

codex

也可以直接給任務:

codex "請解釋這個項目的目錄結構"

CLI 適合開發者。它更快、更直接,但對非技術用戶不如 Desktop 友好。

4.3 安裝 IDE 插件

如果你日常使用 VS Code可以安裝 Codex IDE 插件。

它適合處理編輯器現場的小任務:

解釋當前文件、修改選中代碼、給組件補測試、根據 diff 寫 commit message。

4.4 Chrome 插件先別急着開

Chrome 插件很強,但也更敏感。它的作用是讓 Codex 使用你 Chrome 裏的登錄狀態,處理需要登錄的網站任務。官方文檔明確提到,Codex Chrome extension 適合那些需要 signed-in browser state 的瀏覽器任務,比如需要讀取或操作已登錄網站。(OpenAI Developers)

如果你只是剛入門,不建議第一天就開這個。先把本地項目裏的讀代碼、改代碼、看 diff 跑順,再研究網頁自動化。

Image


5.第一次使用 Codex:別直接讓它做大項目

第一次打開 Codex,最常見的錯誤是直接說:

“幫我做一個完整系統。”

這類需求太大,邊界不清楚,AI 很容易寫出一堆看起來熱鬧但很難維護的東西。

正確流程應該是:先讀項目,再解釋結構,再做小改動,最後才做功能。

第一步:只讀項目

第一次進入項目,先輸入:

先不要修改任何代碼。

請通讀當前項目,並回答:
1. 這個項目是做什麼的;
2. 使用了哪些技術棧;
3. 主要目錄結構是什麼;
4. 啓動命令是什麼;
5. 測試或類型檢查命令是什麼;
6. 首頁或主入口文件在哪裏;
7. 如果我要新增一個頁面,應該從哪裏開始。

這條指令的重點是“先不要修改任何代碼”。你不是讓它馬上幹活,而是先讓它建立上下文。很多項目本身沒有文檔,Codex 可以先幫你補一個“口頭項目說明”。

第二步:解釋關鍵模塊

比如你想了解選題管理、登錄、訂單、課程報名這類模塊,可以繼續問:

請重點解釋當前項目裏的“內容列表”模塊。

請說明:
1. 頁面文件在哪裏;
2. 數據從哪裏來;
3. 組件之間如何傳遞數據;
4. 有沒有狀態管理;
5. 如果我要增加篩選功能,大概需要改哪些文件。

仍然不要修改代碼。

這一步用來判斷 Codex 是否真的看懂了項目。如果它只能泛泛而談,不適合馬上交給它複雜任務。

第三步:做一個極小修改

比如:

請把首頁主按鈕文案從“開始使用”改成“立即體驗”。

要求:
1. 只修改必要文件;
2. 不調整樣式;
3. 不改其他文案;
4. 修改後告訴我改了哪個文件。

小任務不是為了省時間,而是為了測試它的執行邊界。一個小文案都能精準改,後面才值得讓它做功能。

第四步:做一個可驗證的小功能

比如給列表頁加搜索:

請給當前列表頁增加一個搜索框。

要求:
1. 複用現有樣式;
2. 不引入新的 UI 庫;
3. 支持按關鍵詞過濾列表;
4. 不修改後端接口;
5. 修改後運行類型檢查;
6. 最後總結修改了哪些文件,以及如何驗證。

這個任務大小比較合適:有上下文、有邊界、有驗收標準。Codex 最適合從這類任務練起。

第五步:檢查 diff

無論 Codex 總結得多好,都不要跳過 diff。你可以讓它先自查:

請總結當前 diff:
1. 修改了哪些文件;
2. 每個文件為什麼修改;
3. 有沒有無關改動;
4. 有沒有潛在風險;
5. 是否運行了測試或類型檢查。

然後你再自己看一遍 Git diff。如果一個小任務改了幾十個文件,要警惕。

Image

6.基礎能力:讀代碼、改代碼、修 Bug、寫測試

Codex 的基礎能力可以歸成四類。

別急着學高階功能,

先把這四件事用順。

6.1 讀代碼

讀代碼是最穩的入門場景。

適合接手舊項目、學習開源項目、理解外包交付項目,

也適合產品經理理解研發實現。

提示詞:

請解釋這個項目的整體架構。

輸出格式:
1. 項目用途;
2. 技術棧;
3. 目錄結構;
4. 核心模塊;
5. 數據流;
6. 啓動方式;
7. 新人上手建議。

不要修改代碼。

如果你做內容或培訓,可以讓它進一步生成“給非程序員看的解釋版”:

請把上面的項目結構解釋成非程序員也能聽懂的版本。
不要出現太多術語,如果必須出現,請順手解釋。

這個用法非常適合做技術課程、工具教程、內部培訓材料。

6.2 改代碼

改代碼時,必須寫清楚“哪些不能變”。很多 AI 出問題,

不是因為不會寫,而是因為為了完成目標順手改了不該改的地方。

示例:

請重構當前組件。

目標:
1. 降低組件複雜度;
2. 抽離重複邏輯;
3. 保持現有功能不變;
4. 不修改對外 props;
5. 不改變樣式表現。

執行前請先給出計劃,等我確認後再修改。

尤其是“保持現有功能不變”“不修改對外 props”這種限制,

要寫出來。

AI 不會天然知道你的隱性規則。

6.3 修 Bug

修 Bug 時,不要只貼一句“報錯了”。要貼完整報錯、操作步驟、期望結果。

提示詞:

我遇到了下面這個報錯:

[粘貼完整報錯]

復現步驟:
1. 打開某個頁面;
2. 點擊某個按鈕;
3. 出現報錯。

請按步驟處理:
1. 解釋報錯含義;
2. 判斷最可能的原因;
3. 列出你要檢查的文件;
4. 給出修復計劃;
5. 等我確認後再修改代碼。

如果已經允許它修改,可以加一句:

修復後請運行相關測試或啓動命令,確認問題是否解決。

6.4 寫測試

寫測試很適合交給 Codex。因為測試規則明確,重複性強,也方便驗證。

提示詞:

請為當前模塊補充測試。

要求:
1. 參考項目已有測試風格;
2. 覆蓋正常情況、異常情況和邊界情況;
3. 不修改業務邏輯;
4. 測試文件命名遵循項目規範;
5. 寫完後運行測試並彙報結果。

如果項目沒有測試,可以先讓它檢查:

請先檢查當前項目是否已有測試框架和測試示例。

如果有,請說明測試框架、測試命令和推薦寫法。
如果沒有,請給出最小化測試方案,先不要安裝依賴。


Image

7.Prompt 寫法:不要聊天,要派任務

Codex 不是普通聊天工具。你要像給同事派任務一樣寫指令。最實用的結構是四個部分:目標、背景、限制、驗收標準。

差的寫法:

幫我優化一下頁面。

這個指令太空。優化什麼?速度、樣式、交互、結構還是 SEO?Codex 只能猜。

好的寫法:

【目標】
優化當前文章列表頁的加載速度。

【背景】
這是一個 Next.js 項目,文章列表頁目前首屏加載偏慢。

【限制】
1. 不改變頁面視覺效果;
2. 不修改後端接口;
3. 不引入新的狀態管理庫;
4. 優先檢查重複請求和不必要渲染。

【驗收標準】
1. 給出性能問題分析;
2. 修改前先列出計劃;
3. 修改後運行類型檢查;
4. 總結修改文件和驗證方式。

寫得清楚,不是為了顯得專業,而是為了減少返工。

一個簡單判斷標準:

如果這個需求交給真人同事也聽不明白,

那 Codex 大概率也會跑偏。

Image

8.Plan 模式:複雜任務先規劃

只要任務會影響多個文件,就應該先規劃。尤其是登錄、權限、數據庫、支付、部署、大規模重構,不要讓 Codex 直接動手。

提示詞:

請先進入計劃模式,不要修改代碼。

任務:
給當前項目新增“文章收藏”功能。

請輸出:
1. 需要修改哪些文件;
2. 每個文件準備做什麼;
3. 是否需要新增依賴;
4. 是否涉及數據結構變化;
5. 可能的風險點;
6. 驗證方式。

等我確認後再執行。


這個習慣會讓你少踩很多坑。

Image

9.AGENTS.md:給 Codex 的項目說明書

如果你長期在一個項目裏使用 Codex,建議在項目根目錄放一個 AGENTS.md。它相當於項目說明書,把技術棧、啓動命令、代碼規範、禁止事項寫清楚。

示例:

# AGENTS.md

## 項目簡介
這是一個內容選題管理工具,用於記錄選題、平台、狀態、發佈時間和覆盤數據。

## 技術棧
- Next.js
- TypeScript
- Tailwind CSS
- shadcn/ui
- SQLite

## 常用命令
- npm run dev:啓動開發環境
- npm run build:構建項目
- npm run lint:運行 lint
- npm run test:運行測試

## 代碼規範
- 使用函數組件;
- 所有組件使用 TypeScript;
- 樣式優先使用 Tailwind;
- 不要引入新的 UI 庫;
- 不要修改數據庫結構,除非任務明確要求。

## 目錄說明
- src/app:頁面
- src/components:通用組件
- src/lib:工具函數
- src/db:數據庫相關代碼

## 注意事項
- 修改超過 3 個文件前,必須先給出計劃;
- 涉及數據刪除操作時,必須等待人工確認;
- 完成任務後必須總結修改內容。

有了這個文件,你不用每次都從頭講規則。Codex 進入項目後,能更快貼近你的項目習慣。


Image

10.Codex for Chrome:把瀏覽器裏的重複動作交給 AI

Codex for Chrome 是一個很關鍵的變化。它讓 Codex 不只待在代碼項目裏,而是可以在授權後使用你的 Chrome 登錄狀態,處理一些網頁任務。官方文檔對它的描述是:當 Codex 需要讀取或操作需要登錄狀態的網站時,可以使用 Chrome extension。(OpenAI Developers)

這類任務一般有三個特徵:路徑固定、動作重複、結果可以人工複核。

舉個內容團隊的例子。每週覆盤時,可以利用它覆盤數據。這個流程不復雜,但很耗時間。你可以讓 Codex 先整理數據:

請打開我已經登錄的幾個內容平台後台,整理最近 7 天的數據。

需要記錄:
1. 內容標題;
2. 發佈時間;
3. 閲讀量或播放量;
4. 點贊、收藏、評論;
5. 新增粉絲;
6. 表現最好的 3 條內容。

請先整理成表格,不要發送給任何人。完成後等我檢查。

這裏的重點不是讓 Codex 替你判斷哪條內容一定能爆,而是讓它先完成“打開網頁、讀取數據、整理表格”這些重複動作。最後哪些數據有效、怎麼覆盤,仍然由人判斷。

同樣的邏輯可以放到其他場景:

教培機構整理學員簽到和作業提交情況;

招聘團隊彙總候選人面試狀態;

行政同事檢查供應商資料是否缺字段;

活動運營把多個報名頁面的數據合成一張表……


Image

11.內置瀏覽器、Chrome 插件、Computer Use、MCP 有什麼區別?

這幾個概念很容易混。

內置瀏覽器更適合開發場景。比如你讓 Codex 啓動本地項目,在瀏覽器裏打開 localhost:3000,看頁面有沒有跑起來,再根據截圖修改樣式。

Chrome 插件適合需要登錄狀態的網站。比如內容平台後台、內部系統、郵箱、項目管理工具。

Computer Use 更偏桌面操作,比如某些沒有 API、沒有網頁入口的軟件。這個能力更強,但也更需要謹慎。

MCP 和插件是更穩定的連接方式。

如果一個工具有 GitHub、Figma、Notion、數據庫這類接口,優先用插件或 MCP。能走結構化接口,就不要讓 AI 模擬鼠標點擊。OpenAI 官方也把 Plugins 作為 Codex 擴展能力的一部分,用來連接外部應用、skills 和 MCP servers。

Image

12.Skills:把你的經驗變成 Codex 的工作流

Skills 不是提示詞收藏夾。它更像把一套重複流程封裝起來,讓 Codex 每次按同樣標準執行。

OpenAI 官方文檔對 Skills 的解釋是:skill 會打包說明、資源和可選腳本,讓 Codex 更可靠地遵循某個工作流。

如果你經常做 AI 工具教程,可以做一個“工具拆解 Skill”。規則可能是:

當我讓你拆解一個 AI 工具時,請按以下結構輸出:
1. 這個工具解決什麼問題;
2. 適合什麼人;
3. 主要功能;
4. 新手怎麼上手;
5. 三個真實使用場景;
6. 和同類工具的區別;
7. 適合做成什麼內容選題。

如果你做企業 AI 培訓,可以做一個“培訓課件 Skill”:

當我給你一個 AI 工具主題時,請幫我生成半天培訓方案。

輸出:
1. 培訓對象;
2. 培訓目標;
3. 課程模塊;
4. 每個模塊的講解重點;
5. 現場練習;
6. 學員作業;
7. 講師提示。

如果你是開發團隊,可以做“代碼審查 Skill”:

審查代碼時,請優先關注:
1. 是否有明顯 Bug;
2. 是否破壞現有 API;
3. 是否存在安全風險;
4. 是否缺少必要測試;
5. 是否有過度設計;
6. 是否有無關文件被修改。

只標出重要問題,不要糾結格式偏好。

Skills 的意義是沉澱自己的工作習慣。

你反覆說過十遍的規則,就不應該每次都手動複製。

把它變成 Skill,才是把 Codex 從“聊天工具”變成“個人工作台”的關鍵。

Image

13.Automations:適合做定時檢查,不適合無腦執行

Automations 可以讓 Codex 按計劃在後台執行 recurring tasks。官方文檔也提到,它可以把發現結果放進 inbox,如果沒什麼可報告,也可以自動歸檔;同時可以和 Skills 組合使用。

注意,這個功能最適合“檢查”和“整理”,不適合一上來就做高風險自動執行。

比如內容團隊可以設置一個每週五自動任務:

每週五下午,檢查本週內容項目的更新情況。

請整理:
1. 本週新增了哪些選題;
2. 哪些選題已經發布;
3. 哪些選題卡在待修改狀態;
4. 哪些內容數據表現最好;
5. 下週建議優先推進的 5 個選題。

輸出一份週報草稿,等我確認後再使用。

開發團隊可以設置:

每天早上檢查當前項目狀態。

請整理:
1. 昨天新增的問題;
2. 仍未關閉的高優先級任務;
3. 最近失敗的構建或測試;
4. 需要人工 review 的分支;
5. 今天建議優先處理的事項。

只生成報告,不要自動修改代碼。

培訓團隊也可以用:

每週一上午檢查課程資料庫。

請整理:
1. 本週要交付的培訓主題;
2. 哪些課件還沒準備;
3. 哪些案例需要更新;
4. 哪些工具最近有重大更新;
5. 建議補充的練習題。

只輸出清單,不要修改文件。

Automations 的價值不是“讓 AI 替你上班”,而是把每天、每週固定要看的材料提前擺好。它像一個定時醒來的助理,不是一個可以無限放權的員工。

Image

14.MCP 與插件:把 Codex 接進真實工具

當 Codex 只待在本地項目裏,它主要是編程助手。

當它接入 GitHub、Figma、Notion、Linear、數據庫、Slack 這些工具後,

才開始像一個工作流 Agent。

典型場景有幾個。

第一,接 GitHub。你可以讓 Codex 總結某個 PR 改了什麼、有哪些風險、review 評論怎麼處理,也可以讓它根據 issue 生成實現計劃。

第二,接 Figma。設計稿不是截圖,而是結構化節點。通過插件或 MCP,Codex 可以讀取設計結構,再生成更接近設計稿的前端組件。也可以直接用codex裏自帶的圖像工具轉為前端代碼,實現像素級復刻。詳細看我上週的文章裏面有,往前翻一下🍎🍎🍎

第三,接項目管理工具。比如把待辦任務拉出來,按優先級排序,或者把完成情況整理成周報。

第四,接數據庫。這個場景要謹慎。更適合查詢和分析,不建議讓 Codex 直接改生產數據。這個之前也寫過,都可以直接搜下關鍵詞supabase🤔😂

一個比較穩的用法是:

請讀取項目管理工具裏本週標記為“待處理”的任務。

請按以下格式整理:
1. 任務標題;
2. 所屬模塊;
3. 優先級;
4. 是否阻塞其他任務;
5. 建議處理順序。

只整理,不修改任務狀態。

MCP 和插件的關鍵不是“接得越多越好”。

根據自己需求安裝即可。

Image

15.多 Agent :不要同時亂跑,要分清任務邊界

Codex 支持多線程、多項目、worktree 等能力。OpenAI 官方功能頁也提到,Codex App 支持 side-by-side 的項目線程和內置 Git worktree,用來隔離並行代碼變更。

直接執行

 codex features enable multi_agent


配置文件 ~/.codex/config.toml 里加個併發上限參數,就是最多允許幾個的意思。它就會自己spawn_agent。

這很有用,但不能亂用。

正確用法是把任務拆清楚。比如你要做一個內容選題管理工具,可以分成三個線程:

線程 A:實現選題列表和狀態篩選。

線程 B:設計數據結構和本地存儲。

線程 C:生成 README 和使用說明。

這三個任務之間有邊界,不容易互相踩文件。如果你讓三個 Agent 同時改同一個核心組件,大概率會衝突。

多 Agent 的建議:

  1. 1.每個線程只負責一個明確任務;
  2. 2.儘量避免多個線程同時改同一批文件;
  3. 3.每個線程完成後先看 diff;
  4. 4.合併前讓 Codex 總結衝突風險;
  5. 5.重要變更必須人工 review。

多 Agent 並行的價值不是炫技,

而是把可以並行的任務分出去。

你要像分配同事工作一樣分配 Codex,

而不是讓它們在同一個文件裏打架。

Image

16.實戰案例:用 Codex 做一個“公眾號選題管理工具”

下面給一個完整案例。這個案例適合普通人,也適合程序員練手。目標不是做一個複雜系統,而是做一個自己能用的小工具。

16.1 項目目標

 第一步:讓 Codex 設計方案

我想做一個本地運行的“內容選題管理工具”。

請先不要寫代碼,先給我方案。

功能要求:
1. 可以新增選題;
2. 可以編輯選題;
3. 可以按狀態篩選;
4. 可以按平台篩選;
5. 可以搜索標題;
6. 可以記錄發佈時間和覆盤備註;
7. 數據先保存在本地,不做登錄。

請輸出:
1. 推薦技術方案;
2. 頁面結構;
3. 數據結構;
4. 需要創建哪些文件;
5. 第一個最小可用版本怎麼做。

這一步只要方案,不要代碼。先看它怎麼拆。

 第二步:讓它做最小版本

請實現第一個最小可用版本。

要求:
1. 使用當前項目已有技術棧;
2. 頁面包含選題列表、搜索框、狀態篩選、新增選題按鈕;
3. 數據可以先寫死在前端數組裏;
4. 不接數據庫;
5. 不引入新的 UI 庫;
6. 完成後運行類型檢查;
7. 最後告訴我如何打開頁面。

這裏故意先不用數據庫。先讓頁面跑起來。

第三步:增加本地保存

請把選題數據改成本地保存。

要求:
1. 使用 localStorage;
2. 支持新增、編輯、刪除;
3. 刷新頁面後數據仍然存在;
4. 不接後端;
5. 不改變現有頁面佈局;
6. 修改前先說明會改哪些文件。

這個功能仍然可控,適合練 Codex。

第四步:增加覆盤字段

請給每條選題增加“數據覆盤”字段。

字段包括:
1. 閲讀量或播放量;
2. 點贊數;
3. 收藏數;
4. 評論數;
5. 覆盤備註。

要求:
1. 列表頁顯示核心數據;
2. 編輯彈窗裏可以修改;
3. 不影響已有數據;
4. 如果老數據沒有這些字段,請做兼容處理。

這裏開始接近真實使用。你會看到 Codex 是否能處理舊數據兼容。

第五步:生成使用說明

請根據當前項目,生成一份 README。

要求:
1. 說明這個工具是做什麼的;
2. 說明如何安裝依賴;
3. 說明如何啓動;
4. 說明主要功能;
5. 說明數據保存在什麼地方;
6. 說明後續可以擴展哪些功能。

這就是一個完整的小項目流程:

先方案,後最小版本,

再迭代,再寫文檔。

普通人也能照着走。


Image

17.真正要學的不是 Codex,而是怎麼派活

Codex 當然是一個工具,但只把它當工具看,會低估這件事。

它真正帶來的變化,是人和軟件生產之間的分工變了。這裏的關鍵不是“AI 有多聰明”,而是你會不會派活。

任務說不清楚,Codex 就會亂猜。邊界不給,它就可能多改。驗收標準沒有,它就不知道做到什麼程度算結束。你把它當聊天對象,它就給你聊天式回答;你把它當執行者,就要給目標、背景、限制和驗收標準。

對新手來說,先記住一條就夠了:不要讓 Codex 猜你的需求。

這也是我為什麼把這篇叫《阿星Codex 編程白皮書》,而不是簡單叫“Codex 教程”。

教程解決的是怎麼點按鈕。白皮書解決的是怎麼建立一套方法。

Codex 只是開始。真正重要的是,我們要學會和 Agent 一起工作。

ok,我是阿星,更多AI應用,我們下期再見!


圖片