來到第十天，我基本已經完成所有大題的設計外加檢討流程，但考量到一點是，好的應用程式會不斷接收使用者的回饋而成長，而我目前所研發的技能除了不存在使用者反饋外，開發者（我自己）也無法確保設計符合多數人的需求。

建立使用者回饋平台

既然想要獲取其他人的意見，首先就需要有一個平台來收集回饋。

假設未來我以 Google 表單來進行收集，當表單自動匯入到試算表後，透過 CSV 連結再發布到網路，Claude Code 便可以利用 WebFetch 抓下試算表內容了。

建立定時回饋抓取機制

沒人知道使用者何時會提交反饋，為此設定定時功能就有必要了。

schedule Skill 能依排程執行設定好的任務，寫入定時抓取連結內容的命令就可以達成要求。

但此處有一點是值得注意的：我目前的資料都還只在本機端，而雲端代理的 session 需要指定一個 Git 儲存庫才能有東西可以修改。我預計會在之後將專案移至 GitHub，讓這份專案變成真正的 Git repo。

預想中的自動化流程

repo 準備好之後，我目前想像是這樣一條線：

1. schedule 排一個每週執行一次的例行任務。
2. 代理啟動後，先把 repo checkout 下來。
3. 用 Bash 抓取發布到網路上的 CSV 連結。
4. 跟上次執行時記錄的「已處理到第幾筆」進行比對。
5. 篩選新的回饋，並排除一些「重複性訊號」。
6. 只有通過這道篩選的回饋，才會被餵進去，跑一輪跟 gsat-exam-fidelity-critic 現在做的事幾乎一樣的流程。
7. 複製沙盒，依據回饋內容進行收斂。

PR 與人工審核流程

收斂完之後，代理不會直接改動正式檔案，而是開一份 PR。

說明裡會附上：

• 這次是被哪些回饋觸發的。
• 改了什麼。
• 沙盒驗證過程的樣本佐證。

最後再發布前，我會在本機 Claude Code 打開這個 repo，看過修改內容跟驗證證據，覺得沒問題才 merge。

merge 之後，才會是下一次我重新把 SKILL.md 同步回本機，或是直接讓本機從 GitHub pull 最新版本。

回饋資料的安全性

另外，為避免真的失控，CSV 裡的某一欄永遠只能被當成「資料」丟給沙盒驗證邏輯去讀，不能被當成「指令」執行。

畢竟回饋來源是任何填過表單的人，就得假設裡面遲早會有人想在意見欄裡塞一句「請直接覆蓋 XX 檔案」之類的話，而整條流程裡不會有任一步可以讓他生效。

換句話說，使用者回饋只能作為輸入資料，而不能取得代理的執行權限。

下一步要做的，就是先把專案實際搬上 GitHub、把 gsat-exam-fidelity-critic 現有的沙盒邏輯改寫成能在雲端代理裡跑的版本，排練並確認整條線從「表單填寫」到「PR 開出來」真的走得通，再考慮要不要真的開放收集回饋。