昨天結尾停在將專案正式轉為Github repo，後來由於要求電腦重啟，所以今天要把剩下的決策完成。

一、ticket 04：回饋評估函式的最終設計

昨天筆記只寫到「不是用檔案位置畫死一條線，而是依情況動態評估」這個大方向，今天把它談成具體可執行的三層判斷：

1. 設計共識硬關卡——先比對五條設計共識，任何一條違反直接拒絕，不進入後續判斷。
2. 影響度分級（兩個二元問題，不是模糊的高中低）：
   • Q1：會不會碰到共用檔案（VAULT-RULES.md／INTERACTION-RULES.md／hub的跨大題邏輯）或核心演算法/schema（familiarity_score、vault.json結構、標籤分類）？是→高影響。
   • Q2（Q1否才問）：會不會真的改變行為/規則，不只是文字？是→中影響；否（只是修正文字/錯字，不改變實際行為）→低影響。
3. 相似回饋數門檻：低影響2筆、中影響4筆、高影響8筆，同一大題/功能且AI判斷語意指向同一問題的算同一組，門檻沒到就先累積、不動作。

動作：低/中影響直接開PR；高影響先開issue，明確要求開發者核准留言，這次執行永遠不自動把issue轉成PR，核准與否留給下一次routine執行時去檢查。

追加的一個關鍵區分：要先分辨「規則本身有問題」還是「單次生成內容品質問題」。例如某一篇生成的翻譯翻得不準，那次內容早就過去了，改規則文字修不到那次結果——這種情況該問的是「規則指引夠不夠嚴謹」，不是徒勞修正已經過去的具體例子；如果找不到規則缺口，寧可在PR/issue裡誠實承認，也不要為了交差硬改不相關文字。

二、表單製作與連結

google表單由我親自建立後提供給AI定時檢查，其內容包含:

1.你在哪個地方遭遇問題?
2.發生了甚麼問題?(或使用不順的地方)
3.你原本預期是什麼？(預期結果或改良建議)
4.當下的使用情境(選填)
5.當下的單字Level(註:幫助確定範圍)
6.你的聯繫方式?(我們可能會想要進一步了解狀況)(選填)

學測英文家教·回饋表單
(上為連結)

接著到Claude設定routine，在每天凌晨1:00去查收集回饋的表單，紀錄下資訊並送回github判斷。

這邊補充一下，如果真的這麼直接安排的話。由於google drive沒有單格讀取能力，所以我額外將狀態追蹤改成repo裡一個JSON檔案（triage-state.json），用試算表的時間戳記欄位（精確到秒、不會撞key）當唯一key，透過GitHub API直接寫到main分支——刻意不用一般的git push，因為Claude的推送規則會自動把新commit推到當次的claude/*分支，如果那個分支的PR沒被merge，隔天全新session clone repo時根本看不到這次的修改，狀態等於沒有真的持續下去。

三、正式實測

接著到表單填寫問卷，先以最簡單的低影響問題做測試，提交兩份關於主介面文字太過複雜的表單，記錄進試算表中。

AI強制先觸發routine，執行prompt將試算表內容讀取並給出方案。

接著我進入github時就可以利用留言針對方案給出否決或核可的決定。

(非同一個，僅供參考)

以上就是今天的大致內容，這項功能有很多地方值得測試，等到告一段落我就會開放外部下載並正式接收使用者回饋，當然，有鑑於多數高中生應該不會有claude code，有的估計也不需要這東西...。

總之我會將他再修正為網頁友善版(拔除以錯題本為首的修改檔案功能)再大範圍開放。