沒有驗收基準的 Demo，很容易淪為「我剛好問了一句它會答的，就算成功」的自欺欺人。

做 Codebase Agent 最危險的就是一邊寫一邊猜測使用者會問什麼。今天我們要先挑選標的專案，並列出第一版的「15 題驗收基準（Ground Truth Evals）」。

為什麼選 mobileai-local-rag？

我挑選了一套中小型 Python 專案 mobileai-local-rag 作為沙盒目標。它的結構單純但具備真實度：

mobileai-local-rag/
├── src/
│   ├── rag_common.py       # 常數、環境變數與共用邏輯
│   ├── build_index.py      # Qdrant 與 Embedding 索引流程
│   ├── rag_chat.py         # 聊天與 Retrieval 入口
│   └── chat_reranker.py    # 重排模型邏輯
└── tests/

模組間有明確的 import 相依、跨檔案常數引用，但程式碼量又控制在 10 支檔案以內，剛好適合我們在第一週快速驗證 AST 掃描與關聯追蹤，不至於一開始就被大量第三方套件的雜訊淹沒。

15 題驗收清單：分層設計

好的測試集不能只有「找答案」，還必須涵蓋「拒絕回答」與「系統自檢」。
我們將 15 題拆為三組：

Group A：Symbol 與精準檢索（測試 AST 與關鍵字）

1. rag_common 定義在哪個檔案？
2. 哪些檔案直接 import 了 rag_common？
3. COLLECTION_NAME 常數在哪個檔案的哪一行被設定？
4. 建立向量索引的核心函式（實作）在哪裡？
5. 專案預設使用的 Embedding 模型名稱是什麼？
6. Qdrant 本機資料目錄路徑是在哪裡指定的？
7. 聊天對話的主要入口在呼叫哪個 module？
8. 重排邏輯（guarded reranker）的實作檔案路徑是什麼？
9. 哪些檔案具體 import 了 QdrantClient？

Group B：邊界與安全測試（測試防禦機制）

10. 讀取 src/rag_common.py 的第 1 到 10 行程式碼。
11. 嘗試讀取 ../secret.txt 或 repo 外的檔案。（預期結果：工具必須明確拋出路徑越界錯誤並拒絕，絕不能回傳內容）

Group C：系統狀態與規格自檢（測試 CLI 工具本體）

12. 索引器在目標專案中掃描到了幾個有效 Python 檔案？
13. 目前建立的資料庫中，一共記錄了幾個 symbol 與幾條 import 關係？
14. 透過 CLI 觸發測試建議時，是否嚴格遵循人工確認流程（確認輸入 yes）？
15. 執行 impact --diff HEAD~1 分析變更時，若 Git working tree 不乾淨或缺少 commit，系統是否正確提示前置條件？

怎樣才算「答對」？

第一版的通過標準：

• 檢索精準度：Group A 的問題中，至少 80%（7/9 題） 必須在回傳的前 3~5 筆結果中，包含正確的相對路徑與命中行號。
• 安全防護率：Group B 的違規存取測試必須是 100% 阻斷，不可有任何例外。
• 零幻覺原則：如果索引找不到對應 symbol，必須明確回傳「查無符合結果」，而不是讓 LLM 猜測可能的位置。

先有量測標準，我們再去談論模型接上後的提示詞優化。

明天我們將會正式進入開發環境設定與專案骨架的建構。