Day 1 時，我從一句話開始：

幫我做一個 Issue Tracker。

30 天後，手上不只有一段 AI 產生的程式碼，而是一個包含需求、功能、測試、文件、CI、Code Review 與 Git 紀錄的 Issue Tracker。

昨天，我們也完成 feature/delete-issue 的最終 Review，並把 Pull Request 合併到 main。

今天不再加入新功能，而是回頭整理這 30 天真正完成了什麼，以及我從 ChatGPT 和 Codex 的協作過程學到什麼。

最初的一句話缺少什麼？

「幫我做一個 Issue Tracker」只有一個模糊目標，沒有說明：

• 誰會使用
• 第一版要有哪些功能
• 哪些內容不做
• 使用什麼現有技術與架構
• 什麼狀況算完成
• 要執行哪些測試
• 可以修改哪些檔案
• 最後應該如何回報

AI 當然可以自己補上這些空白，但每一個自行補完的地方，都可能和我真正想做的產品不同。

經過這 30 天，交給 Codex 的 Prompt 已經會包含：

目標
-> 專案上下文
-> 明確需求
-> 不做事項
-> 修改範圍
-> 驗收條件
-> 驗證命令
-> 完成回報

最後做出了什麼？

這個系列最後完成的 Issue Tracker 包含：

• 新增任務與輸入驗證
• 待處理、進行中、已完成三種狀態
• 依標題搜尋任務
• 依狀態篩選任務
• 搜尋與篩選同時使用
• 切換並保存任務狀態
• 刪除前確認與取消操作
• 刪除任務並保存結果
• 使用 localStorage 保留資料
• 相容沒有狀態欄位的舊資料
• 自動化測試
• 統一的 npm run check
• GitHub Actions CI
• 根據實際 repository 更新的 README

功能之外，也留下 GitHub Issue、branch、commit、Pull Request 與 Review 紀錄。這些紀錄讓讀者不只能看到最後結果，也能理解每個決定是怎麼形成的。

30 天其實在練習同一件事

回頭看每天不同的主題，核心都是建立一條可驗證的協作流程：

模糊想法
-> 需求釐清
-> 任務拆解
-> 提供 repository 上下文
-> 先提計畫
-> 小範圍實作
-> 檢查 diff
-> 測試與除錯
-> 安全與 Code Review
-> commit、CI 與文件
-> Pull Request
-> 最終 Review 與合併

前面的步驟不是拖慢寫程式，而是讓後面的修改更容易判斷對錯。

第一階段：先把問題說清楚

Day 1 到 Day 7 還沒有急著寫正式功能，而是在練習：

• 分辨 ChatGPT 和 Codex 適合處理的任務
• 找出模糊 Prompt 缺少的資訊
• 使用目標、上下文、限制、驗收與輸出格式組織 Prompt
• 先問清楚產品需求
• 把大功能拆成可驗證的小任務
• 從失敗結果回頭修改 Prompt

第二階段：讓 Codex 進入專案

Day 8 到 Day 14 建立 Issue Tracker 的最小環境，接著讓 Codex：

• 把 repository 當成陌生專案閱讀
• 分辨對話提供的資訊和檔案中的證據
• 閱讀 AGENTS.md 的開發規則
• 修改前先提出計畫
• 完成第一個小功能
• 使用 diff 說明實際修改

第三階段：不要把「能跑」當成完成

Day 15 到 Day 21 把重點放在品質：

• 提供完整錯誤訊息，而不是只說「有錯」
• 修 Bug 前先建立可以重現的證據
• 檢查 AI 產生的測試到底驗證什麼
• 為重要行為補測試，而不是只追覆蓋率
• 在測試保護下進行小範圍重構
• 使用 Reviewer 視角找 correctness 問題
• 根據信任邊界與資料流檢查安全風險

第四階段：把 AI 放回開發流程

Day 22 到 Day 27 開始處理真正的團隊開發流程：

• 一個 commit 只處理一個目的
• 使用 GitHub Issue 當成需求來源
• 比較 Issue 和 diff，避免範圍膨脹
• 把本機驗證整合成 npm run check
• 使用 GitHub Actions 在 Pull Request 自動驗證
• 讓 README 只描述 repository 能證實的內容

第五階段：完成一張新的 Pull Request

最後三天，我們從最新的 main 建立：

feature/delete-issue

接著完成：

1. 定義刪除與取消確認的行為
2. 讓 Codex 提出計畫並實作
3. 人工驗收 localStorage、搜尋與篩選情境
4. 執行 npm run check
5. 檢查完整 diff
6. 建立 commit 並推送 branch
7. 根據實際修改整理 PR 說明
8. 使用新的 Codex 任務進行最終 Review
9. 確認 CI 通過後合併 Pull Request

ChatGPT、Codex 和人的分工

經過 30 天，我會這樣整理三者的角色。

ChatGPT

適合協助：

• 發想與收斂需求
• 找出描述中的模糊處
• 比較不同做法
• 整理驗收條件與文章結構
• 在還沒有 repository 時先把問題說清楚

Codex

適合協助：

• 閱讀 repository 與開發規則
• 追蹤跨檔案的程式流程
• 提出實作計畫
• 修改程式與測試
• 執行命令並檢查 diff
• 協助除錯、Review、CI 與文件

人

仍然需要負責：

• 決定產品真正要解決的問題
• 核准需求與不做事項
• 判斷 AI 的假設是否合理
• 驗證測試和 Review findings
• 檢查資料、安全與使用者影響
• 決定是否 commit、push 與合併
• 對最後交付結果負責

我最常用的 Prompt 結構

如果要把這 30 天濃縮成一份可以重複使用的模板，我會留下：

目標：
這次要解決什麼問題？

上下文：
請先閱讀哪些需求、規則與程式？

範圍：
必須完成哪些行為？

限制：
哪些內容不能做？哪些操作需要先停止確認？

驗收：
什麼證據能證明任務完成？

驗證：
需要執行哪些測試、Type Check 或 build？

回報：
請列出修改檔案、測試結果、差異與未完成事項。

不是每個任務都要填滿所有欄位，但越可能影響檔案、資料或 Git 歷史，就越值得把邊界寫清楚。

給讀者的最後練習

挑選自己 repository 裡一張小型 Issue，試著走一次：

釐清需求
-> 建立 branch
-> 要求 Codex 先提計畫
-> 實作與補測試
-> 檢查 diff
-> 執行完整驗證
-> 建立 Pull Request
-> 換一個 Reviewer 視角檢查

第一次不需要做很大的功能。範圍越小，越容易看清楚哪些部分是 AI 幫上忙，哪些判斷仍然必須由自己完成。

30 天後的答案

回到第一天的問題：要怎麼讓 AI 產生的內容真正進入軟體開發流程？

我的答案不是找到一句完美 Prompt，而是建立一套能反覆檢查的合作方式：

• 用需求減少猜測
• 用 repository 提供上下文
• 用限制控制範圍
• 用 diff 看清楚修改
• 用測試和 CI 提供證據
• 用 Review 挑戰假設
• 用 Git 和 Pull Request 保存決策過程

Prompt 不是讓 AI 猜答案的咒語，而是一份可以討論、執行與驗證的工作契約。

Codex 也不是按下按鈕就能自動合併程式的黑盒子。當人提供清楚的目標、足夠的上下文與品質防線時，它會成為很有能力的開發協作者。

從一句 Prompt 到一個 Pull Request，真正重要的不是 AI 寫了多少程式，而是我們能不能說明每一項修改為什麼存在，以及用什麼證據相信它。

這就是我用 30 天得到的答案。