昨天一次把三個 Issue 丟給 Codex 之後，我開始注意到一個前面比較少碰到的問題，當 AI 同時處理的任務越來越多，它真正麻煩的地方可能已經不只是 Merge Conflict，還包括它腦中理解的那個 Repository，到底還是不是現在 GitHub 上真正的版本。

假設我早上先叫 Codex 處理 Issue A，它讀完整個專案之後開始修改，中午另一個 Branch 已經把共用的 UserService 改掉，下午它繼續處理 Issue B 的時候，如果還沿用早上讀到的結構，就很可能在一個已經不存在的前提上繼續工作。

人自己開發其實也會碰到這種事，只是我們通常很自然會先 git pull、看一下最新 Commit，甚至看到同事改過同一個檔案之後就會重新理解那段 Code，可是 Coding Agent 如果跑得越來越自動，這些原本由人順手完成的小動作，就必須變成工作流程的一部分。

Context 其實也有版本

前幾天一直在看 Codex 能不能理解整個 Repository，一開始我把「理解專案」想成一件做完就可以繼續使用的事情，像是先讓它知道這是一個 ASP.NET Web Forms 專案、資料庫在哪裡、頁面跟後端怎麼連接，後面就可以沿用這些背景繼續工作。

但 Repository 本身一直在改，今天新增一個 Service、明天改掉資料表欄位、後天重新命名一個 Method，原本正確的 Context 很快就可能變成半對半錯。

所以我現在比較傾向把 Context 看成某一個時間點的專案快照，至少要知道它是根據哪一個 Commit 建立的，例如：

Context Base
Commit: a81f3c2
Branch: main
Generated: 2026-09-22 14:20

當 Agent 準備開始下一個任務時，就先比較目前 Repository HEAD 是否還停在同一個 Commit，如果已經往前走很多，就不要直接假設原本的理解仍然有效。

這個概念其實很簡單，但開始同時跑多個 Issue 之後就變得很重要。

不需要每次重新讀完整個 Repo

另一個問題也馬上出現，如果每次 Repository 有一個 Commit，就叫 Codex 把整個專案重新讀一遍，好像又太浪費。

假設只是 README 改了一行字，或前端 CSS 微調，跟目前正在處理的登入 Bug 根本沒有關係，這種變更其實沒必要讓 Agent 重新掃過所有檔案，所以我想做的方式比較接近先看差異，再決定哪些 Context 需要更新。

例如 Agent 上一次理解 Repository 時停在：

a81f3c2

現在 main 已經到了：

c94e12a

先執行：

git diff a81f3c2..c94e12a

如果差異只落在：

README.md
wwwroot/css/site.css

而現在的任務是修改會員登入驗證，那原本大部分的 Context 還可以繼續用。

但如果差異包含：

Services/UserService.cs
Models/User.cs
Database/UserRepository.cs

那就很明顯不能直接沿用原本的判斷，至少跟使用者相關的部分要重新讀。

這樣 Context 更新就不會變成「全部重來」，比較像開發者回到專案之後先看最近改了什麼，再補自己缺掉的資訊。

Issue 自己也可能過期

做到這裡我又發現，會過期的不只 Repository Context，Issue 本身也有可能。

例如 Issue 原本寫：

修正 Login.aspx 登入失敗後沒有顯示錯誤訊息

可是前一個 PR 已經順便把登入流程改掉，現在錯誤訊息改成統一由 LoginService 回傳，如果 Codex 還照著最初 Issue 的描述直接改 Login.aspx.cs，它可能真的可以完成任務，但完成的是昨天的任務。

所以 Agent 在正式修改之前，應該多一步把 Issue 描述跟現在的 Code 對一次，看看問題是否仍然存在、檔案位置是否改變、原本提出的修改方式還合不合理。

這跟我前幾天一直強調的「先讀再改」有一點像，只是現在讀的不只是 Code，還要確認任務本身有沒有跟 Repository 一起變動。

我開始替 Agent 加一個開始前檢查

目前我會希望之後的流程至少長成這樣：

讀取 Issue
↓
取得最新 Repository 狀態
↓
比較上一次 Context 與目前 Commit
↓
找出相關變更
↓
重新讀取受影響檔案
↓
確認 Issue 仍然成立
↓
開始修改

看起來多了幾個步驟，但如果任務開始變多，這些檢查反而可以避免 Agent 花十分鐘很認真地完成一個已經過期的修改。

以前自己寫程式時，我其實沒有特別把「更新 Context」當成一件工程工作，因為人會自然地看 Git、看最新 Commit、看同事改了哪裡，再慢慢把腦中的專案版本更新掉，現在把工作交給 Coding Agent 之後，才發現原來這些看起來很自然的行為，都需要被明確放進流程裡。

走到 Day 16，我開始覺得讓 Codex 寫出正確的 Code 已經只是其中一部分，接下來更值得測的是，當 Repository 持續改變、Issue 同時進來、不同 Branch 一直往前走時，它能不能知道自己手上的資訊已經舊了。

如果這件事沒處理好，AI 寫 Code 的速度越快，可能也只是更快地完成過期的工作。