寫好 Codex 提示詞

📖 本篇術語速查表

英文 / 縮寫	中文	一句話解釋
Outcome-first	結果優先	先說要什麼結果再說怎麼做的寫法。
停止條件	stop condition	告訴 Codex 什麼時候該停、不要硬猜。
缺證據行為	missing-evidence rule	資訊不足時讓它澄清而非編造的約定。

不想讀完？把下面這段提示詞丟給 AI 幫你跑完——幫你把一個寫不好的提示詞改成 outcome-first 的好結構。

你是 Codex 提示詞最佳化顧問，幫我把一個寫得不好的提示詞改成 outcome-first 的好結構。

【角色】
你懂好 prompt 的結構、outcome-first 寫法、停止條件和缺證據時的行為約定，也知道複雜任務要先拆、prompt 裡該少寫什麼。

【輸入】
- 我現在的提示詞原文：___
- 我真正想要的結果：___
- 任務複雜度：___

【工作流程】
1. 找出原 prompt 的問題（目標不清 / 沒停止條件 / 囉嗦）
2. 按 outcome-first 重組
3. 加停止條件和缺證據時的行為
4. 複雜任務建議先拆

【輸出規範】
▌一、改寫後的提示詞
▌二、原 prompt 的問題
▌三、加的停止條件 / 缺證據行為
▌四、是否需要先拆任務

【硬約束】
- outcome-first：先說要什麼結果，再說怎麼做
- 必須有停止條件，避免 Codex 跑偏
- 刪掉冗餘，prompt 不是越長越好
- 不替我假設目標，目標不清先問

你透過 prompts 和 Codex 互動。Prompt 描述你希望它做什麼，Codex 隨後進入迴圈：呼叫模型、讀取檔案、編輯檔案、執行命令和呼叫工具，直到任務完成或被取消。

好的 Codex prompt 不只是“請幫我做”。它要寫清目標、上下文、範圍、禁止事項、驗證方式和交付格式。

Prompting

官方 Codex prompting 基礎。

From theory to practice

把模糊需求改寫成可執行任務。

How a task completes

理解 Codex 從 prompt 到驗證的迴圈。

兩個簡單例子

解釋程式碼：

請解釋 transform module 是如何工作的，以及其他模組如何使用它。

新增功能：

請新增一個新的命令列選項 `--json`，用於輸出 JSON。

這兩個 prompt 能跑，但真實專案裡還不夠。要穩定交付，需要補上下文、範圍和驗證。

好 prompt 的結構

flowchart LR
    Goal["目標"] --> Context["上下文"]
    Context --> Scope["範圍"]
    Scope --> Boundaries["禁止事項"]
    Boundaries --> Verify["驗證"]
    Verify --> Deliver["交付"]

建議包含：

目標：使用者層面的結果是什麼。
上下文：相關檔案、錯誤記錄、截圖、連結、業務規則。
範圍：只允許動哪些檔案或目錄。
禁止事項：不新增依賴、不改資料庫、不動無關檔案等。
驗證：跑什麼測試、lint、build、截圖或人工檢查。
交付：最後彙報改動檔案、驗證結果、未驗證項和風險。

Outcome-first 寫法

GPT-5.5 的官方提示詞指導強調 outcome-first：先定義結果、成功標準、約束和可用上下文，讓模型選擇具體路徑。對 Codex 來說，這比寫一長串“先做 A、再做 B、再做 C”更穩，除非每一步都是業務硬約束。

可以用這個模板：

目標：
修復使用者在移動端開啟設定頁時按鈕錯位的問題。

上下文：
- 復現路徑：開啟 /settings，寬度 390px，點選 Profile tab。
- 相關檔案優先看 src/app/settings 和 src/components/tabs。

範圍：
- 只改佈局和樣式相關檔案。
- 不改介面、不改資料結構、不新增依賴。

驗證：
- 跑現有 lint/build。
- 用瀏覽器檢查 390px、768px、1440px 三個寬度。
- 最後說明改動檔案、驗證結果和殘餘風險。

這個 prompt 沒規定 Codex 必須先讀哪個檔案、後改哪個元件，但把目標和驗收寫清楚了。Codex 可以按實際程式碼結構選擇路徑。

停止條件和缺證據行為

長任務尤其要寫 stopping conditions。否則 Codex 可能一直擴大搜尋範圍或改到無關檔案。

建議直接寫：

如果沒有復現到問題，先停下並報告已檢查路徑，不要猜改。
如果需要新增依賴，先說明原因和替代方案。
如果測試失敗且與本次改動無關，記錄失敗命令和證據，不要順手大改。
如果超過約定範圍，先輸出計劃，等確認後再繼續。

缺證據時也要明確：

如果官方文件、原始碼和現象不一致，以本儲存庫目前原始碼和可復現行為為準；無法確認時標註為推斷，不要寫成確定結論。

複雜任務先拆

Codex 處理複雜工作時，拆成更小、更聚焦的步驟更穩。小任務更容易測試，也更容易 review。

如果不知道怎麼拆，先讓 Codex 只做計劃：

請先不要改檔案。基於目前問題提出最小實現計劃，列出需要讀取的檔案、可能風險和驗證方式。

確認計劃後，再讓它執行第一步。

Prompt 裡應該少寫什麼

很多舊 prompt 會堆滿絕對規則，例如 ALWAYS、NEVER、must、only。官方提示詞指導建議把這些詞留給真正的不變數，例如安全邊界、必填欄位、絕對禁止的動作。

判斷類任務更適合寫 decision rules：

不推薦	推薦
“永遠不要聯網。”	“只有當本地資料不足或需要最新事即時聯網，並引用來源。”
“必須先讀所有檔案。”	“先讀入口檔案和呼叫鏈，發現範圍不足再擴充套件。”
“一定要完整重構。”	“優先最小改動；只有現有結構無法滿足目標時再提出重構計劃。”

對 Codex 來說，過多絕對規則會讓它在衝突指令裡浪費推理，甚至錯過更簡單的驗證路徑。