PR 的測試全綠，刪除舊附件的任務也寫好了。審查者只問一句：「使用者刪除後又上傳同名檔案，昨天排進佇列的任務會刪哪一份？」

工程師回頭看程式，才發現任務裡存的是檔案路徑，沒有版本識別。原本以為已經完成的功能，忽然多了一個說不清楚的時間差。

這是虛構案例。它想問的問題很具體：AI 把程式寫好之後，接手的人能不能預測它在不同時間順序下的行為？如果只能複述 PR 摘要，就還缺少能支撐維護工作的理解。

Sphinx 把這個停頓做成工具：對程式變更出題，讓人回答。本文依 2026 年 10 月 19 日讀取的公開文件與程式碼分析，沒有安裝、連接模型或實測問答品質。

好問題會讓人回去看程式

Sphinx 的題目圍繞行為、失敗情境與不變量。它是開卷檢查，允許讀程式，也允許請 coding agent 協助找出相關片段；背出函式名稱沒有太大意義。官方 README 說明了這個定位。

對刪檔案例，以下是本文設計的問題，並非工具實際產出的題目：

  • 任務排入後，同一路徑換成新檔案，舊任務還有權刪除它嗎？請指出程式根據哪個欄位判斷。
  • 第一次刪除成功，worker 卻在確認任務完成前當機；第二次執行看到檔案不存在，會結束還是持續重試？
  • 資料庫已標示刪除，但物件儲存服務暫時失敗，使用者還能不能下載？哪裡保證這件事？

第一題追的是物件身分，第二題追的是重試，第三題追的是兩個系統不同步時的可見狀態。答不出來的位置，剛好就是應該補讀程式或補寫測試的位置。

我會把「答案能否落到一段程式與一個反例」當成採用標準。只得到一段流暢的設計說明，對這個刪檔任務幫助有限。

問的是這一份提交，不是印象中的功能

依架構文件，Sphinx 會取得 Git 操作的來源與目的提交，先套用路徑過濾，再讓 reviewer 讀取差異及相關原始碼、測試。題目與參考判斷另有一次依據檢查，回答錯誤時則針對同一概念換一個情境。

這種綁定有實際用途。假設工程師答題後才補上檔案版本欄位，先前那份回答描述的已經不是新程式。架構文件將完成紀錄綁定到快照、目的地與評估設定等條件，恢復 Git 操作前再檢查一次。它減少了「拿舊回答替新 diff 背書」的落差。

但 reviewer 讀得到的程式，未必包含產品需求。若團隊從未決定「重新上傳是否沿用舊物件身分」，模型可能替缺失的需求補上一個看似合理的答案。此時應先釐清需求；程式當下的行為不會自動變成應有的行為。

答不出來之後，要留下可重跑的東西

故事裡的工程師補上說明：「刪除任務只針對排入時的物件版本，同一路徑之後的新版本不能被影響。」這只是設計目標，還需要實作與測試支持。

可以把第一題留下來，改成一個驗收情境：先建立舊版本 A 並排入刪除，再用同名路徑建立新版本 B，最後執行 A 的延遲任務；結果必須是 B 仍可讀取。若儲存介面根本無法識別版本，這個限制也應寫清楚，不能用答題通過掩蓋。

這段是教學用驗收設計，本文未執行。它的價值在於下次改動刪檔邏輯時，團隊能重跑同一個反例，而不必再次仰賴當事人的記憶。

這也和前兩篇有不同分工：AI 審查的停止規則 處理 reviewer 反覆提出意見、讓 PR 無法收斂的問題；把反覆錯誤移進程式庫 處理哪些規則值得由結構與測試承擔。Sphinx 補的是中間那一步：讓接手的人暴露尚未理解的行為，然後決定哪些缺口值得固定成驗證。

本機答題通過，不能替團隊批准合併

Sphinx 明確提醒，本機使用者及 coding agent 可以繞過 hook，也能取得外部協助；評分模型本身可能判錯。它提供跳過功能並留下紀錄，跳過不算通過。因此，理解檢查的結果不能單獨授權合併或部署。這是本文對工作流的建議，也符合專案對非安全 gate 的定位。來源

以刪檔功能來說，答對上述三題，也沒有證明存取控制、安全掃描或資料保留需求都已經通過。原本的 CI、必要審查與部署權限仍要各自成立。

同樣不能把「今天答對」寫成「這個工具提升了工程師能力」。那需要另外設計觀察：隔一段時間換個未見過的案例，確認能否找出相同類型的風險。沒有這類資料，就只能說完成過一次問答。

第一筆試用，先看資料送去哪裡

工具在本機運作，不表示程式只留在本機。reviewer provider 會收到變更程式、相關檔案、回答與專案背景。官方有敏感路徑排除，但路徑規則抓不到貼在一般原始碼裡的秘密。README 的安裝前說明 已把這點列出。

呼叫成本也值得先限制。設定文件 與 config.js 顯示模型呼叫次數預設沒有總上限；這不代表其他時間、內容或輸出限制也不存在。正式試用前，應選定允許接收資料的 provider、排除敏感檔案，並設定單次檢查的呼叫上限。

安裝也會影響機器層級的 Git hooks 設定，不能把它當成單一專案裡的一份純文字教材。初次評估適合從隔離環境與非敏感的小型變更開始，不需要直接接入主力專案。

回到那筆刪檔 PR，下一步已經很明確：把「舊任務遇到新版本」補成可重跑的測試，再請工程師用自己的話解釋測試為何成立。Sphinx 值得嘗試的地方，是讓這個原本可能被略過的問題出現；最後留下的成果，應該是人說得清楚、程式也驗得出來的行為。