前言

昨天，我把這段時間建立的開發流程打包成 Plugin。今天，換個角度，盤點這 28 天用 AI 開發系統的成本。

成本的主體不是產出，是重讀

把 repo 的 Session Transcript 全部加總，總共有 3,168 個回合，累計約 12.1 億個 Token：

平均每個回合，模型讀取約 356,243 個 Token，卻只產出 1,615 個。

每產出一個 Token，它平均要先重讀兩百多個 Token。

我原本以為最大的成本是「叫 AI 寫了多少程式碼」。但數據顯示，產出只佔 0.42%，幾乎可以忽略。真正占大宗的是上下文的讀取。換句話說，模型的負載主要取決於每個回合需要處理多少上下文，而不是最後產出了多少內容。

這也改變了我對「降低成本」的理解：與其要求 AI 少寫一點，不如先想辦法讓它少讀一點。而「減少重讀」其實正是前面幾篇文章已經採用、只是當時出發點不同的做法。

例如，開兩個 Session，分別扮演 SA 和 PG，原本是為了隔離上下文；文件多記錄判斷、少記錄容易過期的事實，原本是為了降低維護成本。現在回頭看，這兩種做法也都能減少每個回合需要重新讀取的內容。

好的協作方式，往往也能降低模型的使用負載。

產出的組成：程式碼不到一半

來看系統本身的產出。

排除 node_modules 與套件鎖定檔後，整個系統共有 9,493 行：

如果把前後端實作加總，實作程式碼只佔整個系統的 44%。

測試程式碼約是實作的 0.72 倍，規格文件則約是程式碼的 0.45 倍。也就是說，每寫 100 行功能程式碼，就有約 72 行測試，以及 45 行規格文件。

從 Git 的 35 筆 Commit 類型來看，也呈現出類似的分布：

11  test:
10  docs:
 9  feat:
 4  chore:
 1  refactor:

test: 比 docs: 多，docs: 又比 feat: 多。

如果只看功能實作，很容易以為這個專案的主要工作就是寫程式。但從實際留下的成果來看，功能開發反而只是整個過程的一部分。這正好呼應了系列開頭提出的觀察：當 AI 大幅降低實作門檻，開發流程的瓶頸就可能轉移到規劃、驗證與整合。

當時我主要是從實際經驗出發，現在則有了另一組數據，可以從產出的組成再次檢視這個現象。

哪些變便宜，哪些變貴

後面四項，是我一開始沒有充分估計到的成本。

其中最違反直覺的，是「判斷」不但沒有變少，反而可能變多。

實作變便宜後，AI 能在短時間內產出更多程式碼、測試與文件。但產出增加，不代表每一項都正確，也不代表每一項都符合原本的設計。人仍然需要判斷哪些結果可以接受、哪些需要修改，以及哪些問題值得優先處理。

前幾天，我把 CI 閘門打開時，就遇到一個很具體的例子：一次出現了一千多條錯誤，實際修正並沒有花上一個下午，但大量時間都花在判斷「這一千多條裡，哪些是真的問題」。

AI 降低了產出的成本，卻沒有等比例降低判斷產出的成本。

甚至因為產出變多，原本可以忽略的檢查，也可能變成必須面對的工作。

結論

AI 確實幫我省下不少時間，包括打字、查文件、撰寫樣板程式碼，以及補上測試。這些工作原本需要投入大量時間，現在都能更快完成。但省下來的時間，也有一部分被新的工作吃了回去：規格維護、產出驗證，以及大量需要人做判斷的工作。因此，雖然整體仍然值得，但實際收益並沒有「AI 幫你寫 Code」這句話給人的印象那麼單純。

對我來說，這次最有價值的成果，不只是更快完成系統，而是在相同的時間裡，能夠投入更多資源在規格與測試上。

每 100 行功能程式碼，搭配約 72 行測試，這是以前的我很難做到的事。不是因為不知道測試重要，而是實際工作中，往往沒有足夠的時間把測試寫到這個密度。

現在，AI 讓這件事變得可行。但要讓這些產出真正可靠，仍然需要人負責定義規則、檢查結果，以及決定哪些問題必須先解決。

AI 帶來的收益，不只是把同一件事做得更快，而是讓原本因為時間不足而做不到的事，開始有機會被做好。

明天是最後一天：把這 28 天累積的東西收斂成一份可以交給別人的 SOP，以及接下來要怎麼走。