grill-me + graphify：AI 代理開發的拷問與地圖
27 Jul 2026
用 AI 代理寫程式時，效率瓶頸通常來自兩個地方：需求不夠清楚，或是 專案太大看不完。grill-me GitHub 與 graphify 是目前 AI 代理工作流中極受歡迎的兩個開源模組（Skills），各自解決上述其中一個問題。兩者不衝突，反而能組成流暢的協同管線。
grill-me：動手前把需求問到透徹
grill-me 的核心機制是決策樹反向拷問。開發者提出一個想法後，它不直接動手，而是用一連串的問題逼開發者把規格說清楚。每次拷問的最終產物是一份完整的 Action Items 表格，直接當作實作規格。
實際拷問過程
拿一個真實案例來看。CareerWise 是一個職涯諮詢 AI 服務，使用者在上面詢問面試準備、履歷健檢、轉職規劃等問題。以下是用 grill-me 針對 CareerWise 學習與適應功能設計進行拷問的過程：
Q1：成本
每次回答後做 LLM 偏好分析，但沒有算過 inference cost。假設 1K users × 20 次/天，成本是多少？
回答：目前還沒有實際估算，這個量級需要先確認使用模式才能推算。
grill-me 給出的建議：
- GPT-4o-mini 粗估約 $63/月（1K users）、$630/月（10K users）
- 有信號才分析（按 👎、說「太長了」才觸發，可省 50-70%）
- client-side heuristic 過濾（閱讀時間 < 3s 直接忽略）
- 上生產前先 beta 測 actual usage
Q2：誤判防護
使用者心情不好對短回答也說「太長了」，一次 outlier 直接蓋掉正確的 detail_level，怎麼辦？
回答：單次誤判確實會汙染偏好資料，需要防護機制。
grill-me 的解法建議：
- 信號先累計到暫存區，count >= threshold 才寫入正式 preferences
- 明確修正 threshold = 1，行為推斷 threshold = 5，回饋按鈕 threshold = 2-3
- 7 天無更新自動過期清除
最終產出是一份結構化的 Action Items：
| Priority | Item |
|---|---|
| 🔴 High | 成本優化：有信號才跑 inference |
| 🔴 High | 誤判防護：threshold-based 偏好更新 |
| 🟡 Medium | Feedback linking：加 regeneratedFrom 欄位 |
每個拷問分支都產出可執行的下一步，規格不需要等人來補。
graphify：專案的結構化地圖
graphify 走的是另一條路。它用 Tree-sitter 與 LLM 掃描整個專案資料夾，自動解析程式碼結構、檔案類型與文件內容，產出可供 AI 查詢的知識圖譜（graph.json）。
實際產出
針對一個 CareerWise 專案跑一次 graphify .，產生的圖譜包含 90 個節點（function、class、type、file）與 120 條以上的邊（imports / calls / contains / uses 關係），涵蓋 51 個檔案。
局部聚焦 router 的三層分類邏輯：
router.ts ──classifyIntent()──→ layer1Rules()
layer2Embedding() ──→ embed.ts
layer3LLM() ──→ groq_sdk
router.ts 負責意圖分類，使用三層架構：Layer 1 用關鍵字規則秒判斷（如「嗨」→ greeting），Layer 2 用 embedding 相似度比對，Layer 3 由 LLM 判斷。Layer 2 和 Layer 3 都依賴 embed.ts 提供的向量搜尋。可參考之前的路由設計文章-CareerWise 從 Pipeline 到 Agentic：路由、提示鏈與反思模式。
chat.ts 如何組合 routing 與處理 handlers：
chat.ts ──getReply()──→ getKnowledge() ──→ loadAllKnowledge()
buildMessages()
getHandler(intent) ──→ handlers/*
chat.ts 是主要的對話邏輯入口。收到使用者訊息後，先載入知識庫、組合 system prompt 與對話歷史，再透過 router.ts 分類意圖，最後派發給對應的 handler（greeting / career / resume / booking）產生回應。可參考知識庫搜尋重構文章-CareerWise 從強制注入到 Tool Use。
不需要逐檔打開閱讀，AI 直接看懂誰呼叫誰、依賴誰。
graphify 的關鍵差異在於結構就是訊號。傳統 RAG 把檔案切碎後用向量相似度撈取，檔案之間的關聯全部丟失；graphify 保留每條邊並標註 EXTRACTED、INFERRED 或 AMBIGUOUS，開發者永遠知道哪些是真實的程式碼關係，哪些是 AI 推論。
功能對照表
| 維度 | grill-me | graphify |
|---|---|---|
| 解決痛點 | 需求模糊、思慮不周、AI 亂猜需求 | 大型專案檔案繁多、重複讀檔燒 Token |
| 運作方式 | AI 主動提出一連串拷問讓人類回答 | 本地解析程式結構與檔案，建立知識圖譜 |
| 主要產出 | 清楚定義的規格邊界與行動項目 | 互動網狀圖（graph.html）、結構化資料（graph.json） |
| 互動對象 | 針對人類開發者進行提問與確認 | 針對 AI 助手提供結構化檢索的 MCP / 記憶層 |
對 UI/UX 的影響
grill-me：從空白輸入到結構化對話
沒有 grill-me 時，開發者面對的是空白的對話輸入框。規格只能靠自己從腦袋裡擠出來，AI 收到 prompt 就開始產出。等看到結果才發現方向錯了，來回修改的情緒從期待變成沮喪。
使用 grill-me 後，對話變成結構化的問答流程。開發者不再對著空白輸入框苦思，而是回答 AI 拋出的問題就好。每次拷問結束後產出 Action Items 表格，開發者看到的是可執行的規格，不是一堆需要再消化的草稿。
graphify：從讀檔等待到圖譜導航
沒有 graphify 時，開發者的工作節奏是：餵檔案 → 等 AI 讀完 → 發現漏了 → 再餵檔案。回覆時間長，且 AI 常在不對的檔案裡找答案，答非所問。
使用 graphify 後，開發者跑一次 graphify . 產出 graph.html，打開瀏覽器就能看到整個專案的視覺化圖譜。AI 回覆時間明顯縮短，查詢特定模組時不再亂給不相關的程式碼。
還能更好的地方
目前的體驗還有改善空間：
- grill-me 的拷問進度可視化。開發者不知道「還要問多久」。如果在對話介面加上進度提示（如「已確認 3/8 項邊界條件」），會更有掌控感。
- Action Items 可互動。點一下 item 就自動產生對應的實作 prompt，或勾選完成狀態，從「看完規格」變成「直接接著做」。
- graphify 查詢附圖譜路徑。AI 回答時附上它在圖譜中的導航路徑（如
router.ts → classifyIntent() → layer2Embedding() → embed.ts），開發者看到這條路徑就知道答案從哪來，信任感更高。
核心效益
- grill-me 降低的是開發者的認知負擔。沒有 grill-me 時，開發者得自己想到所有邊界條件，遺漏一個 AI 就做出錯誤假設，來回修改耗時。grill-me 在前期主動把模糊地帶問清楚，開發者只需要回答問題，不需要自己窮舉所有可能性。
- graphify 降低的是開發者解釋專案結構的負擔。沒有 graphify 時，開發者得手動引導 AI 讀哪些檔案、解釋誰依賴誰，不然 AI 就在錯誤的上下文裡亂猜。graphify 讓 AI 直接讀圖譜理解專案，開發者不用充當嚮導。
協同搭配建議
在實際的工程日常中，兩者可以組成流暢的管線：
- 探索與理解 — 剛拿到陌生專案時，先跑
graphify .建立專案地圖，讓 AI 瞬間掌握全局核心架構 - 規格收斂 — 當要修改或新增功能，對 AI 提出的初步 Plan 進行檢視時，用 grill-me 進行交叉詰問，補足邊界條件
兩者連在一起用，效果遠勝單打獨鬥：graphify 讓 AI 知道專案長什麼樣，grill-me 確保 AI 做對的事。
總結：grill-me vs graphify
- grill-me 在動手前把需求問到透徹，避免 AI 做出錯誤假設
- graphify 為 AI 提供永久專案結構地圖，減少重複讀檔的 Token 消耗
兩者解決的是不同階段的效率瓶頸，適合串成完整的 AI 代理工作流，正在使用 AI 代理的開發者，不妨兩個都裝起來試試。
