這週的主軸不再是增加規則數量

目前已經可以：

• 提供測試網址，進行多輪問答。
• 保存完整對話，之後回看使用者怎麼問、系統在哪裡卡住。
• 口試計程車題先確認是否與計畫直接相關，不再直接猜測。
• 使用者回答「不知道」時，不把未知條件假裝成已核准。
• 本地模型定位成探索 / 批次測試工具，正式展示仍使用線上服務。

系統從「能不能跑」進入「真實的人會怎麼用」的階段。

對照測試真正說明的是「知識邊界」

主計總處客服主要涵蓋：

中央政府內部審核 / 支出憑證層級

但 Campus Agent 要回答的是：

國科會計畫規定 + 中央大學校內要求 + 案件條件

它不是一個「比較差的同類產品」；它回答的是上一層問題，因此不能取代校內送件前檢核。

這也讓專題的差異化更具體：不是做一般規章 QA，而是把跨層、校內、案件化的判定接起來。

校內實務資料又撞出一個不能靠產品名稱直接判的問題

Vicky 提供的會計科目 Excel 裡，同一個計畫的軟體 / 雲端訂閱曾分別列成：

• 170102 電腦軟體
• 510303-2810 電腦軟體服務費

這份資料的用途不是直接寫成規則，而是：

1. 告訴我們「軟體」不是一看到品名就能唯一分類。
2. 產生要問承辦人的確認問題。
3. 分類不確定時，系統應該標示人工確認，而不是硬判。

下一步需要真人窗口，而不是再自己推論

當時整理了 13 題承辦人確認表，包含：

• 同一計畫為什麼出現兩種軟體細項科目？
• Claude Pro 年繳方案應該怎麼分類？
• 需要哪些附件 / 佐證？
• 口試、計程車等灰色地帶，正式規定與實務怎麼分？

Meeting 要請老師決定：

• 找 Vicky、陳靜儀、其他系辦承辦人，還是主計室？
• 第一封先寄完整 13 題，還是只寄報表衍生的 4 題？

這次刻意先不做的事

• QR Code：等 internal test 確認可用再做。
• 其他補助來源：先把國科會範圍做好。
• 模型效能 / 規則數據大展開：這週重點是實際使用。
• 把校內報表直接當規則：沒有承辦人確認前不自行推論。

研究開始從「我能不能把規則整理好」走向「規則與實務之間的邊界要怎麼被驗證」。