用 Workflows 編排任務

你是 Codex Workflow 編排顧問，幫我把一組多步驟任務編排成清晰、可複用的 workflow。

【角色】
你熟悉 workflow 的基本結構、常見型別、入口選擇，以及從 workflow 沉澱到 skill 的路徑。

【輸入】
- 我要編排的多步驟流程：___
- 步驟之間的依賴關係：___
- 從哪個入口觸發：___
- 是否會反覆用 / 團隊共享：___

【工作流程】
1. 判斷這個流程適合 workflow 還是單 prompt 就夠
2. 把步驟編排成結構清晰的 workflow
3. 選合適的觸發入口
4. 說明穩定後怎麼沉澱為 skill

【輸出規範】
▌一、是否值得做成 workflow 的判斷
▌二、workflow 結構（步驟 + 依賴）
▌三、觸發入口建議
▌四、後續沉澱為 skill 的條件

【硬約束】
- 簡單流程別硬編排，單 prompt 能解決就不做 workflow
- 步驟依賴要寫清，避免亂序
- 高風險步驟保留人工確認
- 先跑通再編排，不在錯誤流程上固化
- 不確定的機制標註需查官方文件

Workflow 是 Codex 任務的可複用執行方法。它不是一段長 prompt，而是一套明確的“什麼時候用、給什麼上下文、怎麼執行、如何驗證”。

OpenAI 的 workflow examples 覆蓋 IDE、CLI 和 Cloud 等入口。本頁把它整理成可複用模板。

Workflow 的基本結構

flowchart LR
    When["When<br/>什麼時候用"] --> Context["Context<br/>需要哪些上下文"]
    Context --> Steps["Steps<br/>執行步驟"]
    Steps --> Verify["Verification<br/>怎麼驗收"]
    Verify --> Deliver["Deliver<br/>交付什麼"]

每個 workflow 至少寫清：

• 適用場景。
• 推薦入口：IDE、CLI、App、Cloud。
• 需要使用者提供哪些上下文。
• Codex 可以自動讀取哪些上下文。
• 執行步驟。
• 驗證方式。
• 輸出格式和風險說明。

如果一個 workflow 說不清驗證方式，暫時不要自動化。

常見 workflow 型別

解釋程式碼庫

適合 onboarding、接手陌生服務、理解資料流。

輸入：

• 目標模組或目錄。
• 你關心的問題。
• 已知入口檔案或請求路徑。

執行：

請只讀分析這個服務，不要修改檔案。
輸出請求流、模組職責、關鍵檔案、資料校驗位置和修改風險。
把事實和推斷分開寫。

驗證：

• 要求 Codex 列出讀取過的檔案。
• 讓它畫出請求流程圖。
• 抽查關鍵檔案是否確實存在。

修復 bug

適合有復現步驟、記錄、測試失敗或明確症狀的問題。

輸入：

• 復現步驟。
• 報錯、記錄或截圖。
• 相關路徑。
• 不允許修改的範圍。

執行：

請先復現或定位問題。
確認相關檔案和根因後，再提出最小修復計劃。
不要做無關重構。

驗證：

• 修復前後同一個復現路徑。
• 相關測試或型別檢查。
• 若無法執行，說明環境阻塞和替代驗證。

寫測試

適合需求明確、函式或行為邊界清楚的場景。

輸入：

• 目標函式、元件或 API。
• 期望行為。
• 邊界條件。
• 專案測試框架。

執行：

請為這個行為補測試。
先檢視現有測試風格，再新增最小測試。
不要修改生產邏輯，除非測試暴露真實 bug。

驗證：

• 新測試能執行。
• 測試覆蓋目標行為。
• 不用 stub 掩蓋真實邏輯。

從截圖做原型

適合 UI prototype、頁面重建、設計稿落地。

輸入：

• 截圖或設計稿。
• 使用的框架和元件約束。
• 目標路由或元件位置。
• 響應式和互動要求。

執行：

請根據截圖實現一個可執行原型。
複用專案已有元件和樣式，不新增設計系統。
先說明檔案位置和實現計劃，再修改。

驗證：

• 啟動 dev server。
• 檢查桌面和移動端。
• 截圖或人工驗收。

迭代 UI

適合前端頁面微調。

輸入：

• 目前頁面 URL。
• 具體視覺問題。
• 不允許改動的範圍。
• 目標 viewport。

執行：

只修改 header 區域。
目標是減少文字溢位並保持桌面佈局不退化。
改完檢查 375px 和 1440px。

驗證：

• 瀏覽器截圖。
• 無控制台錯誤。
• 目標區域未影響其他模組。

入口選擇

IDE：

• 最適合目前檔案附近的區域性開發。
• 上下文來自開啟檔案、選區和編輯器狀態。

CLI：

• 最適合終端、指令碼、SSH 和可重複檢查。
• 需要顯式說明路徑和驗證命令。

App：

• 最適合多 thread、worktree 和 diff review。
• 適合把 workflow 變成長期任務工作臺。

Cloud：

• 最適合非同步、遠端環境、GitHub workflow。
• 需要先設定 environment、secrets、網路和許可權。

從 workflow 到 skill

當某個 workflow 重複出現，就應該沉澱成 skill。

判斷標準：

• 至少重複多次。
• 步驟穩定。
• 輸入和輸出清楚。
• 驗證方式明確。
• 風險邊界可描述。

沉澱後，workflow 負責“方法”，skill 負責“可觸發複用”。如果還需要定時執行，再考慮 automation。

Workflow 模板

名稱：
{workflow 名稱}

適用場景：
{什麼時候用，什麼時候不用}

入口：
{IDE / CLI / App / Cloud}

輸入：
- {使用者必須提供的資訊}
- {Codex 應讀取的上下文}

邊界：
- 不修改 {範圍}
- 不新增 {依賴/功能/許可權}

步驟：
1. 只讀收集上下文。
2. 輸出計劃和風險。
3. 按確認範圍修改。
4. 執行驗證。
5. 交付 diff、證據和未驗證項。

驗證：
{命令、截圖、人工檢查或其他驗收方式}

Workflow 的目標是讓 Codex 每次都按同一套工程標準完成任務，而不是靠臨場發揮。