「日報服務」從一套難以測試的既有系統出發，經過任務拆解、補測試、程式碼考古、除錯、文件更新與安全審查，最後得到的結論是：ChatGPT 與 Codex 不會自動消除技術債，卻能協助我把黑盒子拆成有來源、有驗證規則，也能交接的判斷鏈。接下來進入「AI 輔助生成系統」案例，我會把焦點從工程師修改程式，擴大到產品、設計、品質保證、法遵與維運等角色如何共同運用 ChatGPT 與 Codex。目的不是讓每個角色都學會寫程式，而是建立一套能交接、可驗證的協作流程，讓需求、決策、實作與驗收留下可追溯的證據。

我的分界：要不要碰專案

我以產出是否碰專案分工具：ChatGPT 整理來源；要讀寫檔案、執行命令或留下可重跑結果，才交給 Codex。產品經理也能請 Codex 查限制，工程師也會用 ChatGPT 整理訪談。OpenAI 官方分別提供需求文件、介面原型與品質保證（Quality Assurance，QA）案例，我只在指定審查者與證據後採用其中做法。

用 ChatGPT 把空白攤開

桌上演練時，我刻意把起始交辦縮成「請做複核介面」。我把需求書裡待確認的去識別化規則交給 ChatGPT，限制它只能使用提供的內容：

請整理成：已確認、待確認、驗收條件、負責人。
缺少依據就標示「待確認」，不要自行決定門檻或責任歸屬。
每項驗收條件都要能由畫面、測試、日誌或設定驗證。

我把「不含自動發布」列為已確認，並將複核原因必填、保留版本納入最小驗收。我再從設計角度補列載入、儲存失敗與唯讀，從 QA 角度補列空白原因與版本衝突；這些不是跨部門簽認結果。

規格確認後，才讓 Codex 實作契約

確認後，我把條件、可改目錄與測試要求交給 Codex。Java 最小案例只驗證複核決策，不含資料庫或正式授權。複核原因不可空白；每次決策新增事件，不覆蓋原稿。

String normalizedReason = reason == null ? "" : reason.strip();
if (normalizedReason.isBlank()) {
    throw new IllegalArgumentException("複核原因不可空白");
}
events.add(new ReviewEvent(decision, normalizedReason, reviewer));

我執行 mvn clean test，4 項測試全部通過：採用、修改後保留版本、複核原因必填，以及否決後保留原稿。結果只涵蓋程式契約；畫面、正式授權、資料留存與版本衝突仍待真實環境驗證。

上線判斷還要回到各角色

交付包把未完成項目連到建議責任角色與所需證據。法遵／資安要核定遮蔽與留存規則，QA 要決定風險覆蓋，維運要檢查權限、監控與復原步驟。共用欄位是否真的縮短等待時間，仍要放進真實流程量測。

小結：讓下一位重跑我的判斷

我用一個問題檢查交付：接手者能否分辨既定需求、演練假設與待確認項目，並重跑同一組測試？只有答案還不夠，來源與驗證方法也要留下。Day 26 會處理下一題：這套做法怎樣離開個人聊天紀錄，變成團隊能測試與維護的提示詞（Prompt）資產。

參考資料

• OpenAI：ChatGPT 與 Codex 使用案例總覽
• OpenAI：Draft PRDs from internal context
• OpenAI：Turn user stories into UI mocks
• OpenAI：QA your app with Computer Use
• AI 輔助生成系統需求書