最近看到一個叫 Sphinx 的 Git hook，設計給 agent-assisted development 使用。它在推送受保護分支前，會讀取 diff，反過來問使用者：如果這段變更遇到某個失敗情境，實際上會發生什麼事？答錯時不只是擋下來，還會提供回饋並換一個情境；答對了才放行。這個機制讓我想到高中資訊課裡一個越來越重要的問題：學生用 coding agent 產出的程式能執行，不等於學生理解程式。

在教學現場，我們很容易把「按下執行沒有錯誤」當成 checkpoint，但真正該檢查的可能是：輸入為空時會怎樣？資料格式不符合預期時，哪一層會先失敗？使用者重複送出請求，結果會不會被寫入兩次？權限不足時，程式是安全地拒絕，還是把錯誤吞掉？這些邊界條件，往往不會出現在最順利的示範流程裡。

如果把 Sphinx 的概念轉成課堂活動，我會讓學生在提交專題前，抽一張「失敗情境卡」，先不用改程式，而是用自己的話預測行為，再對照實際測試結果。答錯時，要求他們指出是哪個假設不成立；答對也要說明是從哪一段程式看出來的。這比單純問「這份 code 是不是 AI 寫的」更能驗證理解，也比較不會把教學變成抓作弊。

Sphinx 本身是 FOSS、MIT 授權，可搭配 Codex、Claude Code、Cursor、OpenCode、Pi 或一般 Git 使用；回答不會交給 coding agent，.env 和 key 也不會被開啟。它提供 sphinx yolo 跳過檢查，但仍會留下紀錄。這些設計提醒我，工具的價值不在於替老師判定學生懂不懂，而在於把「解釋失敗模式」固定成開發流程的一部分。我還沒有在學校部署它，不過這種 checkpoint 思維，很值得先放進下學期的評量設計裡。📚