讓 AI 幫你寫 spec 前，你得先讀 spec

今天在開發一個新功能時犯了一個錯誤，代價是一個工作天。

事情是這樣的，我們需要同時在新舊系統上實作一個新功能，舊的系統已經由同事開發完成，我只需要在新系統上實作一樣的功能就好。

在我還沒看文件前，先看了一下程式碼沒有很多，想說偷懶一下全部交給 AI 來改好了，所以我的作法是這樣：

1. 用 git diff 找出有修改的地方，讓 AI 根據變動寫成 spec。
2. 讓 AI 拆解成可以被單獨驗證的 tasks
3. 執行

一邊驗證測試一邊讓 AI 持續開發，但是驗證到某個功能的時候覺得不太對，某個功能在這次的改動應該要被移除怎麼還在，而且被改成四不像。於是回頭檢查是不是 spec 有錯，後來發現 spec 沒有明確寫到這個要被移除，而且在舊有的 contract 中有寫到這個功能，所以 AI 還是遵守 contract 把這個功能保留下來，但產出了錯誤的程式碼。

接著我嘗試了第二種作法：

1. 用 git diff 找出修改的地方，並且把變動的 before 和 after 也一起寫進 spec 文件中
2. 要求寫 code 前要先更新 contract
3. 執行

我發現這樣在實作的速度上快很多，而且產生的 spec 文件非常好讀，很快就能做一些調整後進到開發。

紀錄一下這次的 lesson learned：

1. 如果是讓 AI 先進行一次 summarize 產生的 spec 如果太過抽象，可能會漏掉細節。
2. 如果專案有用到 contract，當需求有變動時務必要更新 contract，可以把這個寫進 workflow 中避免這樣的事情。
3. 最後是提醒自己一定要把規格和文件都讀完再來實作，不然連 review AI 產生的 spec 都沒辦法看出問題。