這幾年用 AI 寫程式，我已經很習慣把問題切小之後丟給它，某個 function 不知道怎麼寫、SQL 卡住，或是一段程式看不太懂，就把相關片段貼上去問，通常幾個來回就能拿到一個可以繼續修改的答案。

但這種用法其實有一個很大的前提：我已經先幫 AI 把問題整理好了，知道問題在哪個檔案、大概跟哪段程式有關，也知道哪些背景需要一起交代，所以 AI 真正拿到的，通常只是一小塊被我整理過的任務。

Coding Agent 出現之後，我反而比較想知道另一件事——如果今天我不幫它把問題切好，而是直接把一個真的專案交給它，它到底能不能自己把專案看懂？

剛好有一個可以拿來測的專案

今年暑假實習的時候，我接觸到一個 ASP.NET Web Forms 的公司網站，它不是為了教學做的，也不是那種只有幾個檔案的小型 Demo，而是真的一路累積功能留下來的網站。

裡面有前台、後台、SQL Server、ADO.NET、圖片上傳、多語系、快取、Master Page，還有不少歷史留下來的命名跟結構，有些功能集中在 Helper，有些邏輯直接放在 .aspx.cs，資料庫 migration 也不是每一個地方都整理得很漂亮。

簡單來說，它不像教學範例那麼乾淨，反而很適合拿來測 Codex，因為真正在接別人的專案時，本來就不會有人先幫你整理成最舒服的樣子。

第一關先不要寫 Code

我第一天不打算叫 Codex 修 Bug，也不會先叫它新增功能，第一個任務只有一件事：

先閱讀整個 Repo，不要修改任何檔案。

請整理：
1. 這個網站主要在做什麼。
2. 前台與後台的入口在哪裡。
3. 主要資料夾分別負責什麼。
4. 資料庫怎麼被存取。
5. 共用功能放在哪裡。
6. 哪些地方修改時風險比較高。
7. 如果之後要接手這個專案，建議先讀哪些檔案。

這個任務看起來很普通，但我覺得比直接叫它寫一段 Code 更重要，因為如果它一開始就把專案理解錯了，後面即使產生的程式本身沒有語法錯誤，也可能只是在錯的地方做了正確的事情。

以前其實都是我先幫 AI 整理好

以前遇到問題，我可能會直接問：

ASP.NET Web Forms 要怎麼做圖片上傳？

或者：

這段 SQL 為什麼查不到資料？

這種問題對 AI 其實很友善，因為範圍已經被我縮得很小，但真的進到 Repo 裡，問題通常不會這麼乾淨。

假設之後我要改圖片上傳功能，Codex 得先自己找到後台頁面、Upload Handler、共用的 AdminBasePage、圖片縮放 Helper，還要知道資料庫裡可能已經存了舊路徑，如果它只看到一個 Uploads 資料夾就直接開始改，很可能表面上完成需求，實際上卻把其他功能一起弄壞。

所以我這次想測的，不只是它「會不會寫」，而是它在動手之前，到底會不會先搞清楚自己正在改什麼。

這個 Repo 還有一個麻煩：它不新

Web Forms 本身就不是現在最常看到的新專案架構，所以 Codex 不能完全照著最新框架的習慣直接套，像這個專案裡就會看到：

.aspx
.aspx.cs
Master Page
Handler
ADO.NET
SQL Server
App_Code / Helpers
Database migrations

有些資料夾名稱甚至有歷史原因，單複數不一定完全一致，migration 編號也有重複的情況，這些東西如果單純站在「把 Code 整理漂亮」的角度看，很容易想順手重構。

但在真的舊專案裡，名稱看起來很醜，不代表現在就應該動它，因為資料庫、程式碼，甚至正式站上的檔案路徑，都可能還依賴原本的結構。

我也想看 Codex 能不能分辨這種差異，而不是一看到不漂亮的地方就開始整理。

我想記的不只是成功或失敗

後面幾天我會開始真的讓 Codex 修改專案，不過我不想只記「今天成功了」或「今天失敗了」，我比較想觀察的是這幾件事：

這樣到最後，比起單純說「Codex 很強」或「Codex 不好用」，至少可以比較清楚知道它到底在哪一類工作上真的能幫忙，又在哪些地方還是很需要人盯著。

Day 1 先從很無聊的事情開始

所以今天其實沒有叫 Codex 寫任何新功能，只先把 Repo 交給它，讓它讀。

以前用 AI 寫程式時，我最常關心的是答案出得快不快，這次反而想先看它願不願意把時間花在理解專案上，因為真正接一個既有系統，本來就不可能打開第一個檔案後馬上開始改。

如果連「先看懂再動手」這一關都做不到，那後面的 Bug、Issue、跨檔案修改跟測試，其實也不用太期待，明天再來看它第一次讀 Repo 的結果。