點擊上方藍字關注我，加個??標不迷路。
大家好，我是 cxuan。
大家應該都知道了，GPT-5.6 全量上線之后，Codex 也迎來了大改版，OpenAI 剛開始是把 Codex 改為了 ChatGPT Codex ，然后網上吐槽的聲音太多，OpenAI 不得已又改回了 Codex 。
但大家興許不知道，Codex 這次改版之后，官方手冊上新了一個《Prompt 指南》 ：為 Chat、ChatGPT Work 和 Codex 編寫有用的提示詞。
我也是把 OpenAI 的 Prompting 官方文檔 從頭到尾讀了一遍。
然后就有了這篇文章，廢話不多說，直接進入正題！
首先官方直接給出了 Prompt 的定義：
Prompt 是你用來告訴 ChatGPT 你想要了解、制作或者修改什么的方式。Prompt 既可以是一個問題、也可以是一項指令或者一個目標。你無需使用編程領域內偏技術性的語法或死板的公式，只需要用自然的語言進行描述，LLM 會根據你的語言執行相關的操作步驟，執行完成后你可以查看結果，后續可以經過多輪對話來調整和完善結果。
這其實就是官方的定義了，有些教科書式。但其實也比較好理解，之前我們編寫各種代碼，學的各種語言，其實都是在用程序化的語言來和計算機打交道，現在不必這么復雜了，你只需要用自然語言，就可以跟計算機打交道了。這種方式也正是我們俗稱的 vibe coding 。
一般情況下，Prompt 寫很短的提示詞就夠了。
比如
請繼續執行 啟動一下 你怎么又給我搞崩了？ 請恢復上一個版本 好的 |
但是對于龐大和更重要的內容，需要包括一些關鍵的部分，比如下面四個要素
GoalContextOutputBoundaries這四個要素并不是要你所有的 prompt 都加上，針對不同的場景加上對應的即可。
官方第一條建議是：先從結果開始，不要著急給 AI 安排每一個步驟。
比如你拿到一份會議記錄，需要給項目組同步，可以這樣寫：
把這些會議記錄整理成一份簡短的項目進展通報，供項目團隊閱讀。把已經確定的決策和下一步計劃放在最前面。 |
這句話交代了要做什么、給誰看，以及內容怎么排序。至于先提取決策，還是先整理時間線，可以留給 ChatGPT 自己判斷。
比如讓 Codex 改 Bug 的時候，可以要求它先復現一下 bug ，再定位原因，修改后重新執行復現步驟并運行測試。
財務分析可以規定數據口徑，法律材料可以限定資料來源。
普通改寫和總結，只要把結果交代清楚即可。
上下文不是把所有資料一股腦扔給 ChatGPT，你需要提供會改變結果的信息，并說明每份資料拿來做什么。
假設你上傳了公司品牌手冊、產品功能清單和去年的銷售報告，只說一句參考附件重寫產品介紹，ChatGPT 很難判斷三份文件以哪份資料為準。
但是如果你用下面的 Prompt ，有有效很多
根據產品功能清單核對功能事實；按照品牌手冊里的語氣和用詞重寫；去年的銷售報告只用于理解目標客戶，不要引用其中已經過期的數字。 |
同樣是三份文件，這個 Prompt 給每份資料都找到了各自的作用，這會讓 ChatGPT 知道事實去哪查，風格參考哪個，舊報告又該怎么處理
不同類型的資料，提供方式也不同：文檔、表格、PPT 和 PDF 適合總結、比較和改寫；
任務依賴界面或布局時，可以上傳截圖并指出具體區域；
答案依賴最新信息時，明確要求搜索網絡并附上來源；
多次對話要共用文件時，可以放進同一個 Project。
如果 ChatGPT 已經連接了 Drive、Slack、Gmail 或 GitHub，Prompt 里需要說清楚去哪找，找什么，怎么用即可。
使用 Drive 中最新的項目計劃，以及項目 Slack 頻道里過去兩周的重要決策、進度變化和風險，準備一份狀態報告。 |
具體搜索動作可以留給 ChatGPT。你不用再規定它先打開哪個文件、搜索哪些關鍵詞。
連接源能不能用，取決于對應插件是否安裝、賬號是否授權，以及當前訂閱方案和工作區設置。
Plugins 提供兩類東西：可重復使用的操作指令，以及 Google Drive、Gmail、Slack、GitHub 之類的工具連接。
使用時先說最終要完成什么任務，讓 ChatGPT 從可用工具中進行選擇。
如果你明確想用某個插件，可以在輸入框里輸入 @，然后從列表中選擇。
說白了，插件負責提供能力，你負責描述結果就行。
長期有效的偏好，可以放進 Settings > Personalization 的 custom instructions。比如默認使用中文、少用套話、專業術語第一次出現時保留英文。
個性化設置不適合單次 prompt 有用的條件，只適合放長期起作用的約定。
Boundaries 是我覺得整份指南里最實用的一部分，它給了 AI 以限定條件，就跟 Harness 似的。
官方給了四個典型例子：
這四句話分別在保護已確認的數據、信息真實性、預算和操作權限。
比如讓 ChatGPT 潤色合同，可以寫優化表達，但不要修改金額、生效日期和付款期限；
讓 Codex 改代碼，可以寫不要更改公共 API，不要部署到生產環境。
但是邊界條件也別寫太多，官方建議使用一兩條最容易造成實際損失的地方來作為邊界條件。
兩種話術，兩種結果：
“幫我總結一下”和“整理成一頁、以供主管會前快速瀏覽的摘要”，結果會差很多。
官方給了幾個例子：把會議記錄整理成包含決策、負責人和截止日期的郵件；
把計劃支出與實際支出做成表格；
所有差異超過 10% 的地方高亮顯示。
如果遇到重要任務，還應該加一條最終檢查：
完成之前，檢查每一項后續行動是否都有負責人和截止日期。找不到的信息請標記為“待確認”，不要自行補全。 |
第一條 Prompt 一般有可能達不到你想要的。你可以先看輸出結果，然后再告訴 ChatGPT 具體改什么：
開頭再直接一點，證據保留，把建議移到背景介紹前面。 |
這比一句“寫得不好，再改改”要有用。
Codex 正在工作時，你可以繼續發送消息。Steer 和 Queue 決定這條消息什么時候生效。
Steer 會把新消息送進當前任務，適合補充遺漏信息或及時改變方向。Queue 會把消息留到下一輪，適合等當前工作結束后再處理。
一個插隊，一個排隊。
Codex 可以在 Settings > General > Follow-up behavior 里設置默認行為。排隊中的消息會顯示在輸入框上方，可以編輯、調整順序、發送或刪除。
Codex CLI 中，任務運行時按 Enter 是 Steer，按 Tab 是 Queue。
下面這條 Prompt，把前面的四部分串起來了：
為周一的管理層會議準備一份一頁紙的項目狀態報告。
使用 Drive 中最新的項目計劃，以及項目 Slack 頻道中與項目有關的決策和進展。先列出需要管理層做出的決定和下一步行動，再總結項目進展、風險、負責人和截止日期。
已經批準的日期和預算數字保持不變。如果資料互相沖突或信息缺失，請明確標注。只生成草稿，不要發送或發布。
完成之前，檢查每一項下一步行動是否都有負責人和截止日期。
目標是制作一頁項目報告；上下文來自 Drive 和 Slack；輸出說明了讀者、長度和內容順序；邊界限定保護了日期、預算和發布權限；最后又加了一項檢查。
Codex 支持語音聽寫。輸入框可見時按住 Ctrl + M，然后直接說話。
它會先把語音轉成輸入框里的文字。你可以檢查和修改，確認沒有識別錯再發送。它更像語音輸入，不會跳過你直接執行。
Chat 適合提問、討論想法、起草短文和做日常決定。
Chat 的入口直接在 Codex 中，如下圖示例
Chat 模式適合快問快答。
理解一個主題
給一個從未投資過的人解釋復利是什么，使用一個具體的例子，并解釋其中出現的金融術語。 |
這個例子給了受眾和講解方式。它沒有規定必須分幾段，也沒有要求先講公式。
起草并修改文字
起草一封語氣友好的郵件，因為我要外出旅行，所以需要婉拒這次邀請。字數控制在 120 以內，同時表達以后愿意參加類似活動。 |
郵件的語氣、拒絕原因、長度都說清楚了，生成后基本可以直接改名字發送。
比較選項
為一個每年出國兩次的人比較這兩款手機套餐。先用表格列出重要差異，再推薦一個，并說明需要接受的取舍。 |
哪款最好沒有統一答案，考慮到使用者和出行頻率，這個推薦才有依據。
制定可執行的計劃
安排五頓工作日晚餐，每頓準備時間少于 30 分鐘。避開花生，在不同餐次中復用食材，最后匯總成一份購物清單。 |
這個 Prompt 的實用之處在于，它同時考慮了時間、過敏原、采購和食材復用，你用這個結果能直接拿去買菜了。
Chat 模式適合短問題、簡單改寫、頭腦風暴和編寫草稿。Work 模式更適合需要多份資料、多種工具、一串操作，或者最終要生成較大交付物的任務。
使用 Work 模式時，說明想要的結果、提供原始資料、明確受眾，并告訴它你準備怎么檢查結果。可以要求 ChatGPT 先規劃，再收集資料、創建文件，完成前進行檢查。
Work 模式適合耗時任務、重復任務，以及以后的可復用性文件。
把原始資料做成成品文件
使用附件中的季度報告，制作一份管理層簡報和一套六頁演示文稿。讀者是公司管理層。先寫他們需要做出的三個決定，區分報告事實和你的分析，每個數字注明來源文件，完成前檢查簡報和演示文稿是否一致。 |
這類任務最容易出現兩個文件說法不一致的問題，所以完成前交叉檢查很關鍵。
為決策做研究
為一家 50 人的公司研究三款客服平臺。使用最新資料比較價格、安全性、集成能力和遷移成本。最終交付一份推薦備忘錄，附上來源鏈接、關鍵假設，以及簽合同前需要確認的問題。 |
研究任務要把評價維度和決策寫出來，這樣得到的是一份能輔助決策的材料，不是三段產品介紹。
協調一次發布
根據附件中的產品說明制作發布計劃，包括時間線、負責人、依賴、風險、公告草稿、客戶 FAQ 和發布日檢查清單。發現缺少決策時先標出來，再制作最終文件。 |
發布計劃涉及的人和文件眾多，如果缺一個負責人或關鍵決定，后面就會卡住。讓 Work 模式先標注缺口，比生成一份看起來完整但沒法執行的計劃更實用。
重復性的任務可以先在普通 Chat 中把 Prompt 寫好，是你想要的結果之后，在執行定時任務。
Codex 的入口就是我們最熟悉的了。
碰到你需要處理代碼、代碼庫或開發工具時，直接上 Codex。
一個優秀的 Codex Prompt 要說清楚目標行為，指出相關代碼或復現步驟，保留重要約束，并說明結果怎么驗證。
多步驟任務可以先輸入 /plan，讓 Codex 調查并提出方案，再決定是否編輯。
Goal 模式可用時，在計劃確認后使用 /goal 設置持續目標。
官網后面的每個例子都說明了四件事：什么時候用、適合 IDE／CLI／Cloud 中的哪個界面、用戶需要提供什么上下文，以及最后如何驗證。
IDE 擴展會自動帶上打開的文件。CLI 里最好明確寫出路徑，或者通過 @ 和 /mention 附上文件。
Codex 在 sandbox 沙箱中運行。本地文件、網絡或外部操作超出權限邊界時，會按照當前 approval policy 處理。
剛接手的項目、閱讀你不熟悉的服務，或者需要理解協議、數據模型和請求流程時，可以讓 Codex 先解釋一下代碼。
打開相關的文件，必要時選中關心的代碼，然后輸入：
解釋請求在所選代碼中的完整流轉過程。
請包括：
- 每個相關模塊負責什么
- 數據在哪里驗證
- 修改這些代碼時需要注意的一兩個問題
驗證：讓 Codex 把請求流程整理成編號步驟，并列出涉及的文件。
在項目根目錄運行 codex，然后明確告訴它要讀哪些文件：
我需要理解這個服務使用的協議。閱讀 @foo.ts 和 @schema.ts，解釋 schema 以及請求和響應流程。重點區分必填字段、可選字段和向后兼容規則。
CLI 會保留對話和命令輸出。路徑多時可以用 @ 自動補全，或者通過 /mention 附上文件。
Bug 能在本地復現時，最有用的信息是復現步驟和約束。
下面出現了一個 Bug：頁面保存按鈕刷新后無法使用。
Bug：設置頁面點擊“保存”后顯示成功，但刷新頁面后開關恢復原狀。
復現：
1. 運行 npm run dev
2. 打開 /settings
3. 修改 Enable alerts
4. 點擊 Save
5. 刷新頁面，觀察開關狀態
約束：
- 不要改變 API 結構
- 盡量做最小修改
- 條件允許時補一個回歸測試
先復現問題，再定位原因并修改。完成后重新執行復現步驟，運行最小的相關測試集，并報告命令和結果。
用戶負責提供復現步驟和限制條件。Codex 會補充命令輸出、發現的調用位置和堆棧信息。
驗證：修改代碼之后，重新操作一次原來的出錯流程，確認 Bug 已經消失；再運行代碼檢查和相關測試；最后把實際運行了哪些命令、每個命令是否成功、通過了多少測試告訴我。
打開你懷疑有問題的文件和它最近的調用方，然后輸入：
找出為什么界面顯示已保存，但數據沒有持久化。修復后，告訴我如何在 UI 中驗證。 |
這類 Prompt 適合問題范圍已經比較小，只差定位具體代碼的時候。
編寫測試時，先把測試對象和范圍交代清楚。Codex 會參考代碼庫里已有的測試習慣。
打開包含目標函數的文件，選中函數代碼，通過命令面板選擇 “Add to Codex Thread”，然后輸入：
為這個函數編寫單元測試，遵循項目中其他測試使用的約定。 |
選中的代碼行和當前打開的文件會作為上下文，不需要再復制一遍。
CLI 中可以直接寫函數名和路徑：
為 @transform.ts 中的 |
如果一個文件里有多個同名或相似函數，再補充行號范圍或調用位置。
截圖能看出來布局、字體和間距，但它不會告訴 Codex 應該使用什么技術棧，也看不出 hover、校驗和鍵盤交互。
圖片和文字一起發給 Codex ，它才會拿到完整的輸入。
把截圖保存到項目里，例如 ./specs/ui.png，啟動 Codex 后拖入圖片，再輸入：
根據這張圖片創建一個新的儀表盤。
約束：
- 使用 React、Vite 和 Tailwind
- 使用 TypeScript
- 盡量匹配截圖中的間距、字體和布局
輸出：
- 一個能渲染該 UI 的新路由或頁面
- 所需的小型組件
- 一份包含本地運行方法的 README.md
驗證：讓 Codex 啟動開發服務器，并告訴你查看原型的本地 URL 和路由。
把圖片拖入任務，同時打開項目里風格最接近的頁面，然后輸入：
創建一個新的設置頁面，以附件截圖為目標界面，并遵循本項目其他文件使用的設計和視覺模式。 |
這樣 Codex 既能看到目標圖，也能參考現有項目的組件和樣式。
頁面已經能運行后，可以讓 Codex 每次只改一小塊內容，每次刷新瀏覽器看結果。
在單獨終端運行 npm run dev，然后先讓 Codex 提出兩三個樣式改進。選中一個方向后，把范圍縮小：
采用方案 2。
只修改頁頭：
- 字體更偏編輯風格
- 增加留白
- 確保移動端仍然正常
下一輪可以繼續寫：
保持布局不變，簡化顏色，刪除多余邊框，減少視覺干擾。 |
驗證：每次修改后刷新瀏覽器。滿意的修改及時提交，不滿意的撤銷。你手動改過或回退過文件，也要告訴 Codex，免得下一輪又被覆蓋。
復雜的重構可以先在本地理解代碼和確定方案，再把耗時的實現交給云端。
這個我之前不知道有云端這個功能，這次我才知道。
連接 GitHub 之后，會把你 GitHub 的項目同步過來，然后根據 GitHub 上的項目創建云端環境。
連接之后，你的本地就會出現可以在云端工作的選項。
先提交或暫存當前修改，保證后面能看清差異。然后讓 Codex 規劃：
$plan
重構認證子系統：
- 拆分 token 解析、session 加載和權限判斷
- 減少循環依賴
- 提高可測試性
約束：
- 不改變用戶可見行為
- 公共 API 保持穩定
- 給出分階段遷移計劃
計劃出來后繼續追問：每個里程碑具體移動哪些文件？失敗時怎么回滾？本地規劃階段最需要的是入口文件、模塊邊界和依賴關系。
你設置好 Codex cloud environment 后，在輸入框下方選擇云環境，再發送實現計劃中的里程碑 1。新的云端任務會帶上當前任務里的計劃和上下文。
實現完成后檢查 diff，必要時繼續修改。你可以從云端創建 PR，也可以把修改拉回本地測試。
云端任務運行在隔離環境里。Agent 階段默認沒有互聯網訪問，除非你在環境設置中明確開啟。
提交代碼或創建 PR 前，可以讓 Codex 先檢查當前工作樹。
在項目根目錄啟動 Codex，運行：
/review
也可以加關注點：
/review 重點關注極端情況和安全問題
根據反饋修復后，再運行一次 /review，確認相關問題已經解決。
如果不想把分支拉到本地，可以在 GitHub 上直接觸發 Codex review。前提是倉庫已經啟用 Codex Code review。
打開 Pull Request，發表評論：
@codex review
需要關注安全問題時，可以寫得更明確：
@codex 審查安全漏洞和安全隱患
文檔任務也要寫清修改范圍和驗證方法。只說更新文檔，Codex 很容易順手重寫一大片。
確定需要修改的文檔，在 IDE 中打開，或者在 CLI 里用 @ 指定文件，然后輸入：
更新高級功能文檔，補充身份驗證故障排查說明，并驗證所有鏈接都能訪問。 |
Codex 完成后，最后一步是閱讀渲染出來的頁面。
參考資料：
