平常遇到不熟悉的技術問題，很多人都會直接打開 ChatGPT 說一句：「教我。」
現在又多了 Codex 這類 coding agent。它不只可以回答問題，還能進入專案、閱讀檔案、修改程式和執行測試。開發方式好像從「問 AI 怎麼寫」變成了「和 AI 一起完成工作」。

但如果我只丟下一句：

幫我做一個 Issue Tracker。

AI 知道我要做給誰使用嗎？知道功能要做到什麼程度嗎？知道什麼狀況才算完成嗎？即使它真的產生了一堆程式碼，我又該怎麼確認這些程式可以信任、可以維護，最後可以放心送進 Pull Request？

這是我參加這次 iThome 鐵人賽想回答的問題。

系列名稱是：

從 Prompt 到 Pull Request：30 天玩懂 ChatGPT & Codex

接下來 30 天，我不打算只介紹功能或整理 Prompt 大全，而是會實際做出一個專案，完整記錄從想法、需求、開發、測試、Review，到送出 Pull Request 的過程。

這個系列想解決什麼問題？

很多 AI 程式開發教學會停在「輸入 Prompt，得到一段程式碼」。但在真正的專案裡，產生程式碼只占其中一部分。

還需要處理：

• 需求是不是已經說清楚？
• AI 有沒有理解現有專案？
• 修改範圍是否超出原本需求？
• 測試是真的保護行為，還是只把覆蓋率變高？
• AI 回報「完成」之後，有沒有實際驗證？
• 這些變更能不能讓另一位工程師順利 Review？

OpenAI 官方將 Codex 定位為 coding agent，相關工作情境也不只包括產生程式碼，還涵蓋理解大型程式庫、測試、部署、程式碼審查與安全檢查等工作。
詳情可以參考：OpenAI Docs：ChatGPT 與 Codex 使用案例

因此，這次系列的重點不會是「怎麼叫 AI 寫程式」，而是：

我們如何提供足夠的上下文、清楚的邊界與可驗證的完成條件，讓 AI 產出的內容真正進入軟體開發流程。

ChatGPT 與 Codex 在系列裡的角色

這 30 天會同時使用 ChatGPT 與 Codex，但不會把兩者當成完全相同的工具。

ChatGPT：協助想清楚問題

在這個系列中，我會使用 ChatGPT 協助：

• 發想與收斂產品需求
• 找出描述中的模糊處
• 將想法整理成使用者故事
• 拆解任務與驗收條件
• 討論設計選擇
• 整理文章結構與技術說明

它比較像是一位可以反覆討論的夥伴。在還不確定「要做什麼」時，先透過對話把問題說清楚。

Codex：進入專案完成工作

當需求已經比較明確，我會讓 Codex：

• 閱讀 repository 與專案規範
• 找出相關檔案與資料流
• 提出實作計畫
• 修改程式與補上測試
• 執行 lint、型別檢查與測試
• 檢查 Git diff
• 協助整理 Pull Request 說明

Codex 可以在桌面應用程式、CLI、IDE extension 與 cloud 等環境中使用。
官方文件也把 code review、整合式終端、AGENTS.md 和 sandboxing 等內容列為開發工作流程的一部分：OpenAI Docs：Codex 文件入口

這只是現階段的初步分工。明天我會把同一個任務分別交給 ChatGPT 與 Codex，實際比較兩者取得的上下文、採取的動作和交付結果。

30 天要做的專案：Issue Tracker

只談方法很容易流於空泛，因此接下來每一天都會圍繞同一個示範專案：一個給個人開發者使用的 Issue Tracker。

它不會是一個只有畫面的 Todo List。我希望它具備足夠完整的開發情境，讓我們可以真的練習需求、資料流、錯誤處理、測試與 CI，同時又能在 30 天內完成。

預定功能

第一版規劃包含：

• 顯示 Issue 清單
• 新增、編輯與刪除 Issue
• 將 Issue 標記為待處理、進行中或已完成
• 依標題搜尋 Issue
• 依狀態篩選 Issue
• 驗證輸入資料
• 在操作失敗時顯示錯誤訊息
• 保存資料，重新整理後不會消失
• 為核心行為建立自動化測試
• 使用 CI 自動執行品質檢查

預定技術方向

示範專案暫定採用 TypeScript、React、Node.js、SQLite、自動化測試與 GitHub Actions。

我先把想法交給 ChatGPT

在寫任何程式以前，我先從下面這段 Prompt 開始：

我要用 30 天完成一個 Issue Tracker。

請幫我整理：
1. 最小可行版本的功能
2. 適合示範的開發階段
3. 每個階段的驗收條件
4. 可能讓專案失控的風險

目前只提出計畫，不要撰寫程式，也不要替我決定尚未提供的產品需求。

這段 prompt 的回覆

和最初的「幫我做一個 Issue Tracker」相比，這段 Prompt 多提供了更詳細的要求。

30 天的五個階段

第一階段：先學會把問題說清楚（Day 1～7）

從 ChatGPT 與 Codex 的差異開始，逐步練習需求釐清、Prompt 結構、任務拆解與失敗後的修正方式。

第二階段：讓 Codex 走進程式庫（Day 8～14）

正式讓 Codex 閱讀專案，認識 repository 上下文、AGENTS.md、實作計畫與 Git diff，並完成第一個小功能。

第三階段：把 AI 產出變成可靠程式（Day 15～21）

處理除錯、regression test、測試品質、重構、Code Review 與安全檢查。

第四階段：進入團隊開發流程（Day 22～27）

把 AI 的修改放回 Git、Issue、commit、CI 與 README 等日常流程，讓每一次變更都能被追蹤、驗證與回復。

第五階段：完成 Pull Request（Day 28～30）

根據完整 diff 整理 PR 說明、模擬 Reviewer 進行最終檢查，並完成一個真正可審查的 Pull Request。

今日小結

這 30 天，我想驗證的不是 ChatGPT 或 Codex 能不能取代工程師，而是工程師能不能建立一套更好的 AI 協作流程。

我們將從一句模糊的 Prompt 開始，逐步補上需求、上下文、限制、測試與 Review，直到它成為一個能被團隊理解、驗證與合併的 Pull Request。