這個系列一路寫下來，我除了開發本身，還做了一件事：寫「程式閱讀日記」。做法是把 AI 寫出來的程式在做什麼、我當時怎麼理解它，記錄在 Heptabase 的卡片裡。
寫了一段時間後，我想回頭整理它到底幫了我什麼。以下分三個部分：

它實際幫了什麼
它哪裡做得不好
我從中學到什麼，現在改成什麼做法

一、它實際幫了什麼
程式閱讀日記幫我看懂了整個 benchmark 的流程、跑通整個測試迴圈，也讓我搞懂 Hugging Face 這類工具在專案裡扮演的角色。

它最大的價值在「回想」。每當我忘記某段程式在做什麼，直接在 Heptabase 搜尋卡片，就能找回當初寫了什麼、當時怎麼思考，不用重新學一遍。
對用 AI 開發的非技術背景者來說，這點特別重要。開發過程會遇到大量專有名詞，常常要看過兩三次才真正記住。有一個能系統化回想的地方，對理解自己到底在做什麼幫助很大。

二、它哪裡做得不好
第一，看不懂時容易偷懶。 AI 寫的解釋常常比我自己寫得好，所以我有時會直接複製貼上，沒有自己手打或手寫一遍，錯過了原本可以深入學習的機會。

第二，花太多時間。 寫日記的時間大約是開發本身的 0.5 到 1 倍。理解確實提升了，但開發進度也明顯變慢。
三、學到什麼，現在怎麼做

回頭看，問題出在我讓 AI 逐行解釋程式，然後把解釋整段搬進卡片。這樣既花時間，又容易變成照抄。

所以我把有 AI 參與的程式閱讀日記改成直接放在 Claude 上，並在它回答之前，先用一段指令規範回答的架構：
用一句話說明這段要做什麼

使用了什麼方法，以及為什麼選這個方法

過去的技術脈絡，以及未來可能產生的技術債（為了快速完成而先用的權宜做法，之後要花成本回頭修的問題）

做完之後的預期結果，以及我可以怎麼驗證

最後用一句話總結：做了什麼、為什麼這樣做

這段指令的重點，是不要求 Claude 逐行解釋程式碼，而是幫我掌握整體架構、預先看到可能遇到的技術問題，並理解寫程式的人在做決策時如何思考與取捨。
接下來我還想做的一件事，是把日記轉成 Heptabase 的白板，把程式從核心架構到各個功能畫成一張網狀圖。之前因為不熟這種開發方式，常常看完 AI 的內容沒有即時整理，這一步一直沒做到，也讓日記無法幫我完整掌握整個程式。

程式閱讀日記讓我確認了一件事：用 AI 開發，理解和進度之間需要取捨。逐行讀懂每一段程式太慢，完全不讀又不知道自己在做什麼。我現在的做法是把力氣放在理解為什麼這樣寫?而不是每一行在寫什麼。