前幾天一路把 Codex 從看懂專案、找問題、修改程式帶到自己跑測試之後，我開始發現一件滿有趣的事，就是 Codex 做得好不好，好像不只跟模型能力有關，我怎麼把任務交給它，也會直接影響最後改出來的東西。

以前用 ChatGPT 寫程式時，我很習慣把 Prompt 寫得很完整，背景、需求、限制、預期結果全部塞進去，總覺得寫得越詳細，AI 就越不容易搞錯，但真的開始把整個 GitHub 專案交給 Codex 之後，我反而想測看看，如果今天 Repo、測試和專案規則都已經在那裡了，Prompt 還需要寫那麼長嗎？

所以 Day 9 我沒有繼續加新功能，而是找了一個一樣的任務，分成三種方式交給 Codex，看看最後到底會差多少。

第一組，我只給一句話

第一種最簡單，我只告訴 Codex：

修掉匯出 CSV 時日期格式錯誤的問題

沒有告訴它是哪個檔案，也沒有說日期最後應該長什麼樣子，更沒有特別提醒它哪些地方不能動，我想看的就是它能不能自己從專案裡找到相關程式，再從現有程式、測試或其他使用方式推測真正需求。

這種方式其實滿像真的工程環境，有時候 Issue 就只有一句「匯出日期怪怪的」，接手的人還是得自己往下找，只是交給 Codex 後，問題會變成它到底會花多少時間找 Context，又會不會自己補出一些原本不存在的需求。

實際跑下去之後，我最注意的也不是它能不能改成功，而是它到底讀了哪些檔案、改了多少地方，以及有沒有突然順手幫我重構一些我根本沒叫它動的東西。

第二組，把需求全部寫清楚

第二次我就走完全相反的方向，把背景、目前錯誤、預期格式、可能相關檔案和驗收條件全部寫進 Prompt，例如日期必須輸出成什麼格式、時區怎麼處理、哪些現有行為不能被改掉，甚至連最後要跑哪些測試都直接告訴它。

這種寫法的好處很明顯，Codex 一開始就知道我要什麼，搜尋範圍也縮小很多，看起來比較不容易走歪，只是寫到後面我也發現一個問題，我自己花在整理 Prompt 上的時間開始變長，而且很多資訊其實已經存在 Repo 裡，只是我又重新整理一次給它。

如果每次叫 Coding Agent 做事情之前，我都得先寫一大篇完整規格，那確實可以降低一些誤解，可是使用方式又慢慢變回「我先把問題全部整理好，再叫 AI 幫我寫」，這跟我一開始想測的 Coding Agent 又有一點距離。

第三組，只給任務、規則和驗收方式

第三次我把 Prompt 縮短，但這次不是直接放生 Codex，我保留 Issue 本身，再讓它讀專案規則、現有測試和相關文件，同時很明確地告訴它最後必須通過哪些驗證。

也就是我沒有花很多篇幅告訴它「要怎麼改」，而是把重點放在「最後什麼才算改對」。

例如：

任務：
修正 CSV 日期格式問題

限制：
遵守現有專案規則
不要修改無關功能
不要做額外重構

驗收：
既有測試必須通過
新增日期格式測試
回報實際修改檔案

這組是我今天最想看的，因為它比較接近我心裡理想的 Coding Agent 使用方式，我不需要先幫它找到每一行程式，只需要把需求邊界和驗收方式講清楚，至於程式在哪裡、應該怎麼改，就讓它自己去找。

長 Prompt 沒有直接贏

三組跑完後，我開始覺得「Prompt 要不要寫很長」這個問題本身可能沒有那麼重要，因為真正影響結果的還有 Repo 裡面的 Context、專案規則、測試完整度，以及任務本身有沒有清楚的完成條件。

短 Prompt 如果什麼 Context 都沒有，Codex 很容易自己猜；長 Prompt 可以補很多資訊，但人工整理成本也會一起增加，第三種做法比較像是把原本散落在 Prompt 裡的內容慢慢搬回專案本身，讓規則待在文件裡、需求待在 Issue 裡、驗收條件待在 Test 裡。

這對我來說也是今天比較大的收穫，以前會一直想著「這句 Prompt 到底要怎麼寫比較好」，現在開始變成思考 Repo 有沒有提供足夠資訊，以及 Codex 做完之後，有沒有一套方法可以直接判斷它到底改對了沒有。

Day 9 實驗紀錄

今天我用同一個任務跑了三種方式，第一種只給一句需求，第二種把所有細節塞進 Prompt，第三種則保留簡短需求，再搭配 Repo 規則與 Test，接下來我會繼續觀察修改範圍、人工介入次數、測試結果和額外修改的情況。

做到第九天後，我開始覺得 Coding Agent 的使用方式會慢慢從「學著怎麼跟 AI 講話」，走到「把專案整理成 AI 也能工作的環境」，Prompt 當然還是重要，只是它已經不是唯一決定結果的東西了。