11 個專案，誰在燒錢？

狀態只存在我的腦子裡#

測試全過了，但敵人不在裡面之後，kit 安靜了五天。這五天 kit 沒事，機隊有事。

用 kit 的專案一路長到 11 個。部落格、量化交易、RAG 應用、爬蟲管線、遊戲工具……每個都在不同階段：有的上線維運中、有的等決策、有的做完封存。然後某天你想回答三個很基本的問題——哪個專案還在跑？怎麼啟動它？誰在燒錢？——才發現答案不在任何檔案裡，只在自己的記憶裡。而且是 11 個專案份的記憶。

單一專案的狀態，repo 自己記得；機隊的狀態，沒有人記得。這是規模帶來的新問題種類：不是任何一個專案壞了，是「整體」這個東西沒有可讀的形狀。

解法樸素到近乎無聊#

我拍板的決策一句話：「狀態要機器可讀，維護不靠記性」。AI 落地成兩件東西。

第一件，一個 PROJECT.toml，放在每個專案根目錄。kit 鋪出去的骨架長這樣（模板原文節錄）：

name = "[專案名]"
status = "active"          # active | mvp | done | paused | abandoned
status_note = "[目前進度];[下一步]"   # 固定兩段以分號隔開;細節歸 LESSONS/commit,不寫這裡
updated = 2026-07-11       # 最後一次人工確認本檔內容的日期

[commands]                 # 只收「用它」的指令(本專案工具/服務的啟動與操作,可直接複製執行)。
# summary = "uv run yt-summary <youtube-url>"

# [[paid]]
# service = "OpenAI API"
# billing = "按用量"        # 按用量 | 月費 | 年費 | free-tier
# monthly_est = "~$3"
# cancel = "拿掉 .env 的 key 即停"

欄位設計直接對著那三個問題長：status 回答「哪個還在跑」、[commands] 回答「怎麼啟動」、[[paid]] 回答「誰在燒錢」。連退場方式（cancel）都要求寫清楚，因為訂閱制時代的帳單，都是從「忘記怎麼退」開始失控的。歸屬劃在使用者側：kit 部署時只在缺席時放一份骨架，之後永不覆蓋（跟權限設定同一條先例：專案自己的真理，kit 不碰）。

順帶一提，這種「每個專案放一張登記卡」的做法有個正式名字叫 manifest（貨船的艙單：船上載了什麼，一張單子寫清楚）。後面就叫它登記卡。

第二件，一支 proj 彙總指令：掃全機隊的登記卡拼成一張總表。它還會抓內鬼——比對登記卡的更新日期和 repo 的最後 commit，落差太大就在該列標上「⚠ manifest 可能過時」（登記簿最大的罪不是空白，是理直氣壯地過時）。proj money 只列有付費服務的專案，「誰在燒錢」從回憶題變成查詢題；另一個視圖對照 GitHub，抓出「遠端有、本地沒 clone」的漏網之魚。後來又加了輸出成單檔 HTML 的儀表板，理由很誠實：終端太窄，十幾個專案的橫排資訊塞不下。

實作的速度側寫了問題的成熟度：從設計文件進 repo 到主體完工，六個 commit、11 分半（00:25:30 → 00:37:02）。這不是炫技，而是問題早就在腦子裡想清楚了，代碼只剩抄寫。真正的工作發生在寫 spec 的那幾天，不在打字的那一刻。反過來說也成立：如果一個「簡單的小工具」寫了三天還在改介面，多半不是手慢，是問題根本還沒想清楚。實作時間是設計成熟度的溫度計。

登記卡最大的死因是過期#

這種「狀態登記簿」人人都建過，大多數的下場是三個月後全面過期。過期的登記簿比沒有更糟，因為它會用過時的資訊理直氣壯地騙你。

kit 的解法是不指望人：「session 結束前，狀態、指令、付費服務有變就同步登記卡」這條慣例，做成 kit 的規則檔隨更新鋪進全機隊，讓在每個專案裡工作的 AI 收工前順手維護。登記簿的維護者不是記性好的人，是每天都在現場的工人。

順帶一提，這個解法在沒有 AI 常駐的年代根本不成立：沒有工人天天在現場，登記簿就只能靠人的自律，而自律型登記簿的下場前面說過了。有些老問題的新解法，其實只是「現場多了一個不會忘記的人」。

格式本身也有紀律。一句話進度欄規定固定兩段、分號隔開：「目前進度;下一步」。bug 的來龍去脈、數據、待辦清單一律不准寫進來，那些歸各自的檔案。因為一個欄位一旦允許自由發揮，三個月後就會長成一篇沒人讀的小作文；把格式釘死，總表才永遠掃一眼就懂。

收哪些指令？「半年後回來用它」判準#

登記卡的指令欄位上線後又收斂過一次，因為它開始長雜草：dev、build、test、deploy 什麼都往裡塞。

我的裁定：只收「用它」的指令，也就是這個專案提供的工具怎麼跑；不收「開發它」的指令，因為 build 與 test 在 package.json 裡查得到，抄進登記卡只是第二份會過期的副本。判準一句話：「半年後回來用它，需要的才收」。想想你上次回到半年沒碰的舊專案，第一個想知道的是「這東西怎麼跑起來」，還是「當年怎麼跑測試」？

同一輪還做了個結構性小動作。這條收錄規範原本是彙總工具在渲染端用過濾邏輯實現的，後來上移到登記卡的 schema 規範裡：規則寫在源頭，渲染層有什麼顯什麼，不再猜。如果過濾邏輯住在下游，每個新視圖都要再實作一次；住在源頭，寫的人一次就寫對。

下一篇#

這一篇把機隊狀態從人腦搬進登記卡：三個問題對三個欄位、AI 收工前順手維護、收錄規範寫在源頭。解法本身樸素，值錢的是兩條判準：「半年後回來用它，需要的才收」，以及「維護不靠記性，靠現場多一個不會忘記的人」。

機隊的狀態從此機器可讀。但同一批治理動作裡，還藏著這個系列到目前為止最戲劇性的一次自我推翻：一個上線才五天的全機隊決策，被一場 rebase 事故連根掀翻，而且事故的機制陰險到值得每個用 git 的人記一筆。下一篇：上線五天的決策，被一場 rebase 掀翻。