文件畢業那天訂下的門檻，六天後早就紅了，只是從來沒人裝上它

Futari 是給兩個人一起記生活帳的家計簿，有 iPhone App 也有網頁版。它的程式大多是我跟 AI agent 一起寫的，所以 repo 裡那些說明文件，讀者不只是我，agent 每次開工也要先讀。文件寫錯，agent 就照著錯的做。

為了知道這些文件到底靠不靠得住，我寫了一個小工具叫 docgrad，專門替文件打分數：有沒有寫完整、寫的跟程式碼對不對得上、日期是不是太舊、文件之間有沒有互相矛盾。還有一項叫「經濟性」，量的是 agent 每次開工都會自動讀進去的那份入口文件有多長。越長，agent 每次出門前要背的東西越多，真正做事的空間就越少。

Futari 的文件在 7 月 13 日跑過一次，那次就「畢業」了。9 月 13 日凌晨一點，docgrad 多了經濟性這一項，我回來重跑。從凌晨跑到晚上七點五十一分，第 13 輪報告寫著「六維全部達標」。

畢業的時候，docgrad 會照當下的數字產生一道關卡，是一段可以放進自動檢查的程式。以後只要文件退步，例如死連結變多、入口文件變長，它就亮紅燈。數字照「現在的樣子」釘死，之後只准變好。那天入口文件是 5,391 個 token（agent 讀文字時用的計量單位），門檻就釘在 5,500。

我看到全部達標，就去做別的事了。

六天後，9 月 19 日晚上，docgrad 出了新版，我又回來跑一次。這次三輪各修了一個小地方：一份記錄錯誤監控的文件少寫了一條新規則，兩份文件的「最後更新」日期跟實際修改差了好幾週，還有入口文件又變長了。那三輪加起來，前後不到四分鐘。

入口文件的數字是 6,578。六天裡多了將近 1,200，比那道關卡允許的上限還多了一截。照理說它早該亮紅燈，可是它一聲都沒吭。那道關卡從頭到尾就沒有被裝上去。docgrad 刻意不去動任何人的自動檢查，它把程式產生出來，放在資料夾裡，旁邊的說明第一句就寫著「它沒有在跑」。我讀過，也同意，然後就忘了。

類似的事，9 月 13 日當天其實就發生過一次。跑到一半，我發現前幾輪訂的「有標日期的文件比例」門檻已經紅了四輪，原因是新文件加進來，分母從 46 份變成 50 份，比例自然往下掉。還有一份 7 月第一次畢業時就沒標日期的文件，兩個月後還是沒標。那次我把它當成一個小插曲，記下來就過去了。

9 月 19 日最後一輪，入口文件其實可以再砍，砍到 5,000 以下就能拿到「沒問題」的評價，但要砍的是品牌文案準則，那一段寫著 Futari 說話的語氣，我希望 agent 每次都讀到。所以我讓 agent 把一段原生 App 打包的注意事項搬去另一份文件，數字降到 5,863，剩下的我接受，評價停在「留意」。新的門檻也就釘在 5,863，連同理由一起寫進畢業紀錄。紀錄裡還加了一句給以後的自己：下次想再調高這個門檻之前，先看入口文件多了什麼，因為 9 月 13 日到 19 日之間它長了約 1,200，沒有人發現。

報告上的達標，是那一刻拍下來的照片，repo 每天在動，照片不會跟著動。如果你也有類似的品質報告，可以看看最後一次全綠是哪一天，以及從那天之後，有沒有任何東西會在它變紅時通知你。

Futari 在作品集裡，iPhone 和網頁都能直接試。

先不說了，我得去看看入口文件這陣子又長了多少。

這段文件收斂跑於 2026 年 9 月 13 日到 19 日，文章整理於 2026 年 10 月。