影片版

圖 1｜Day 2 影片封面，點擊圖片可觀看完整影片。

本文是 2026 iThome 鐵人賽系列「不只會寫 Code：用 ChatGPT × Codex 打造企業級 AI 開發工作流」第 2 天。Day 1 建立了 Context → Plan → Execute → Verify → Review → Deliver 的閉環；今天先處理最容易讓後續全部失真的入口：需求。

圖 2｜從模糊需求、ChatGPT 拆解、團隊確認到 Codex 落地的需求收斂閘門。

上圖把本日工作流分成四站：模糊需求、ChatGPT 拆解、團隊確認與 Codex 落地。真正的閘門是：尚未確認的 OPEN 項目不能直接進入實作。

為什麼「請做一個匯出功能」不是需求

在企業專案裡，最昂貴的錯誤通常不是語法錯，而是團隊對同一句話有不同解讀。例如「讓管理員可以匯出訂單」至少還缺少：

• 哪些角色可以匯出，是否需要租戶隔離？
• 匯出範圍是目前篩選結果、指定日期，還是全量資料？
• CSV 欄位、編碼、時區與金額精度如何定義？
• 10 萬筆資料要同步下載，還是建立非同步工作？
• 失敗、取消、重複點擊與稽核紀錄如何處理？

如果直接把原句交給程式代理人，Codex 可能會產生「看起來能跑」的實作，但驗收標準仍然不存在。企業工程需要先把自然語言轉成可追蹤、可測試、可拒絕的規格。

先由 ChatGPT 做需求拆解與方案比較

我會把 ChatGPT 放在「規格分析師與審查者」的位置，而不是直接寫檔案。輸入的 Context 至少包含：

1. 使用者角色與權限模型。
2. 現有 API、資料表與服務邊界。
3. 非功能需求：資料量、延遲、可用性、稽核與個資。
4. 不在本次範圍內的事項。

接著要求它輸出四份東西：

這一步的重點不是讓模型「猜得更像」，而是把不確定性顯性化。對尚未決定的假設，標記為 OPEN；只有產品與技術負責人確認後，才升格為規格。

一份可交給 Codex 的最小規格

以訂單匯出為例，規格可以收斂成：

圖 3｜整理規格從角色、輸入到治理證據的五個層次。

規格不只描述成功結果，也要逐層補齊角色、輸入邊界、狀態、失敗重送，以及最後可供審查的證據。

目標：管理員可依目前篩選條件建立訂單 CSV 匯出工作。

驗收：
- Given 使用者不是租戶管理員，When POST /exports，Then 回傳 403 且不建立工作。
- Given 日期區間超過 31 天，When 建立工作，Then 回傳 422 並指出欄位。
- Given 合法請求，When 建立工作，Then 回傳 202、job_id，且工作只讀取該租戶資料。
- Given 相同 request id 重送，When 尚未完成，Then 回傳同一 job_id，不重複排程。
- Given 工作完成，When 下載檔案，Then 連結限時、只能由原租戶使用，並留下稽核事件。

非目標：本次不提供自訂欄位、不改變既有訂單查詢 API。

圖 4｜訂單 CSV 匯出的非同步工作架構，以及權限、冪等、儲存與稽核流程。

這個參考架構把驗收條件落到實際元件：API 閘門負責權限與輸入驗證，Export API 以 request id 保證冪等，工作佇列與 Worker 處理大量資料，物件儲存提供短效下載連結；建立工作與下載行為則統一寫入稽核日誌。

搭配 GitHub 實作範例

本文不只提供規格與架構圖，我也準備了可直接執行的 Python 範例程式：查看 Day 2 訂單 CSV 匯出範例。

範例包含 ExportService、工作佇列、匯出 Worker、租戶隔離、request id 冪等控制、短效下載網址與稽核事件，並附上 6 項驗收測試。下載 Repository 後可直接執行：

cd day02/example-api
python3 -m unittest -v

目前 6 項測試均已實際執行通過，讀者可以一邊對照下方 Given / When / Then，一邊查看程式如何落實每項驗收條件。

注意 request id、租戶條件與限時下載不是 UI 細節，而是可驗收的治理控制。它們會直接影響 repository 的介面、資料模型、測試與監控。

再看三個常見需求，怎麼改寫成可驗收規格

範例一：登入失敗鎖定

模糊需求是：「登入錯太多次就鎖住帳號。」可驗收版本至少要補齊：

• Given 同一帳號在 10 分鐘內連續登入失敗 5 次，When 第 6 次嘗試，Then 回傳 423 並鎖定 30 分鐘。
• Given 帳號已鎖定，When 使用者輸入正確密碼，Then 仍拒絕登入，且不能洩漏密碼是否正確。
• Given 管理員解除鎖定，When 使用者再次登入成功，Then 清除失敗次數並留下稽核紀錄。

範例二：費用報銷附件

模糊需求是：「員工可以上傳收據。」可驗收版本要說清楚格式、大小與權限：

• Given 使用者上傳 PDF、JPG 或 PNG，且檔案小於 10 MB，When 送出報銷單，Then 附件與該筆報銷單綁定。
• Given 檔案副檔名合法但內容格式不符，When 上傳，Then 回傳 422，且不保存檔案。
• Given 使用者不是申請人、審核者或財務人員，When 讀取附件，Then 回傳 403。

範例三：批次通知

模糊需求是：「每天寄信提醒尚未付款的客戶。」可驗收版本必須處理排程、重送與時區：

• Given 客戶帳單逾期且尚未寄送當日提醒，When 客戶所在時區上午 9 點，Then 建立一筆通知工作。
• Given 排程因網路問題重跑，When 相同帳單已建立通知工作，Then 不重複寄送。
• Given 寄送失敗，When 重試 3 次仍失敗，Then 標記失敗並通知營運人員。

這三個例子分別代表安全、檔案與排程情境。共同原則都是把「誰、何時、什麼條件、預期結果、拒絕路徑」寫進規格。

再由 Codex 執行：限制它的工作邊界

把已確認規格交給 Codex 時，不要只說「請實作」。指令應包含：

• 先閱讀 repository 的 CONTRIBUTING、測試慣例與相鄰模組。
• 只修改匯出工作相關檔案，不任意重構。
• 先列出 plan 與預計新增的測試，再開始編輯。
• 每個驗收條件都要有測試，包含拒絕路徑與重送情境。
• 完成後回報修改檔案、測試指令、實際輸出與尚未驗證的風險。

Codex 的價值在於把規格變成 repository 裡可執行的變更；它不應替團隊決定尚未確認的產品政策。遇到 OPEN 項目時，正確行為是停下來回報，而不是自行補完。

Verify 與 Review：驗收的不只是測試綠燈

完成後分三層驗證：

最後回到 Deliver：把規格、決策紀錄、測試證據與未決問題一起交付。這樣下一個人接手時，不必從聊天紀錄猜測「當初到底想做什麼」。

GitHub 專案

本文的 Markdown 來源與架構圖原始檔已公開保存於 GitHub，方便閱讀、下載與後續延伸：

今日小結

Day 2 的核心不是更會下 prompt，而是建立一個拒絕模糊需求的閘門：ChatGPT 負責拆解與比較，團隊確認政策；Codex 負責在明確邊界內實作、測試並回報證據。明天再把這份規格推進到 repository 的 Plan，處理多代理協作時如何避免上下文漂移。