前一篇我還在追問：找到合法的 Open Access 路徑，為什麼仍可能只拿到 landing page？接著我發現一個更麻煩的問題。若取得全文失敗，系統可能要換合法路徑、重新解析、更新 Evidence Card；如果正文因此改動，引用、段落支持與跨章一致性也得重驗。每一步各自都會做，不代表整份研究有資源做到最後。

我原本以為 ResearchForge 最難的是讓模型寫得更好。等搜尋、證據、正文和驗證串起來，真正擋住我的卻是「能不能承諾完成」。身為高中生，我曾把額度看成手機剩餘電量：還有，就先跑。但研究工作不是按一下生成鍵；開始後，系統就欠下一串必須履行的義務。

剩餘額度不是可完成性

假設畫面顯示還能呼叫模型，這只回答「此刻還剩多少」，沒有回答研究計畫已承諾多少來源、多少證據整理、多少小節，以及後續的引用檢查、語意驗證、跨章檢查、修訂與匯出。更何況 request、輸入 token、輸出 token 和單次模型可容納的上下文，是四種不同限制；其中一個數字夠，不代表其他也夠。

最近一次對既有報告的驗證成本盤查，讓我把這件事看得很清楚。原生計畫有 147 個邏輯判斷，被安排成 128 個待執行的模型請求；它們是計畫量，不是已花掉的請求。當時有效的有限恢復授權只餘 57 次，輸入預留量也不足，於是工作停在派送之前。到了今天，那份授權已過期；全域帳本的名目餘額不能代替有期限、有專案範圍的授權。

這也改變了我對「一次預留整份報告」的看法。若把搜尋、全文取得、寫作、所有可能的修訂與重驗都按最大值一次鎖住，還沒開始就可能被過度保守的上界擋下；若只算最順利的一條路，又可能寫完大半才發現 Evidence 不足或 coherence 檢查失敗。兩種估法都不能直接當作「這篇一定做得完」的證明。

我想要的是有邊界的承諾

現在的方向是把 Research Plan 留作完整義務清單，再於每個階段只承諾下一個能安全完成、能保存結果的工作包。這裡的 checkpoint 是「可核對的保存點」：它要記住目前版本、完成了什麼、哪些回執仍有效、接下來還欠什麼。它不是把一份完整研究改成幾份低標準研究。

flowchart TD
    A[完整研究計畫與義務] --> B[估算下一階段工作包]
    B --> C{容量與授權足夠嗎}
    C -->|否| D[保存狀態與缺口，暫停]
    C -->|是| E[預留並綁定輸入版本]
    E --> F[執行階段]
    F --> G[寫入用量與回執]
    G --> H[保存 checkpoint]
    H --> I{義務已履行嗎}
    I -->|否| B
    I -->|是| J[正式驗證與匯出判定]

圖中的箭頭是一個目標流程，不是我宣稱整條流程今天已在正式研究跑完。關鍵是每到下一站，都重新用當前已保存的正文、證據和授權估算。尚未生成的文字，連完整 prompt 都不存在，不能假裝已經知道精確 token 成本；估不準的部分必須寫成未知或保守上界。

我把這個差別整理成一小段簡化流程，而不是直接把「剩餘額度」當開工許可：

Estimate  下一階段的完整輸入與義務
Reserve   核對有效授權，為確定的請求預留
Execute   依相同輸入版本執行，不暗中擴張範圍
Commit    保存實際用量、原始回執與判定
Checkpoint 保存版本與未完義務
Resume    核對保存狀態，再規劃下一步

這裡的 ledger（用量帳本）也不只是 token 計數器。Used 是實際消耗；Reserved 是已承諾、尚未結算的量；Available 是在有效授權下仍可配置的量。Obligation 則在另一邊：研究計畫答應要做的工作，即使還沒花一個 token，也不能因帳本目前有餘額就消失。真正要管理的，不只是 AI 用了多少資源，還有它答應完成多少工作。

預估變小，不能靠少做驗證

成本盤查時，我也曾希望找出重複工作，把龐大的請求數壓下來。但同一段文字同時出現在章內、跨章和三章關係檢查，不一定是重複；檢查目的與完整輸入不同，就不能為了得到較小數字而刪掉。這次核對沒有證明那些工作可以無損合併。已保存的驗證回執可以在身分、輸入與結果都吻合時重用；只看到「模型已回應」，仍不能當成語意通過。

另一個候選方案想用一次全文聯合檢查取代部分細分工作，估出的請求數較少，卻碰上更硬的限制：完整檢查所需上下文超過目前登錄的模型容量。它因此停在 CAPACITY_UNRESOLVED，只是一條影子政策，沒有取代正式驗證。把全文截短、拆成彼此獨立的「通過」，或省略來源與跨章義務，都會讓帳面成本好看，研究標準卻變了。

今天做到哪裡？

目前有可查的階段派送預檢、模型請求容量檢查、順序預留估算、身分綁定的回執重用與保存狀態。原站也能唯讀查看新驗證政策的預檢結果。這些工程工作幫我在派送前看到容量缺口，並防止某些中斷後的盲目重送；隔離測試通過，不等於一份真實報告已依新流程完整續行。

尚未完成的部分同樣具體：未來階段的正文與修訂成本仍有未知項；新的三題授權仍是提案，沒有成為有效 grant；影子驗證沒有 LIVE 語意資格。既有受阻報告尚未產生新的正式 revision，完整的 bounded checkpoint、正式驗證和 Markdown／DOCX／PDF 三格式輸出也沒有在這一輪走通。資源不足時，正確動作是保存、暫停、報出缺口，而不是少找來源、跳過引用或 coherence 檢查，再把 LIMITED 寫成 FORMAL。

我以前把額度不足當成部署問題，現在覺得它直接關係到系統能否誠實履約。Day 28 我會回頭檢查另一個相連的問題：已保存的結果和最後摘要若對不上，系統能否承認先前的「通過」不再成立？只有 checkpoint、帳本與最終判定說的是同一件事，中斷後的續行才有可信的起點。