jevgrep 是什麼？用自然語言找程式碼，真的能讓 AI Coding Agent 省 40% 成本嗎？
jevgrep 讓 Coding Agent 用自然語言找相關程式碼。本文拆解 40% 成本主張、最新 SWE-bench 證據、安裝方式與隱私風險。
jevgrep 作者 David Zhang 在 2026 年 9 月 26 日於 X 發布這款開源 CLI，主打讓 Coding Agent 用「這段程式在做什麼」搜尋陌生程式庫，並宣稱在 SWE-bench 驗證中降低 40% Agent 成本。
CLI 是 Command-Line Interface 的縮寫，也就是從終端機輸入文字指令的工具。jevgrep 的指令名稱是 jg。使用者可以問「請求進入 handler 前，在哪裡檢查驗證？」或「哪些測試覆蓋 timeout retry？」工具會回傳相關檔案、閱讀線索，以及帶有行號的原始程式片段。
先說結論：40% 不是所有專案都能重現的通用保證。官方 README 已把它改寫成「單一 10 題 SWE-bench 重跑中，Coding Agent 成本約低 40%」，而且該輪解題率是 7/10，低於保存的 baseline 8/10。9 月 28 日的更新測試則在同樣 8/10 解題率下，Agent 成本比 no-jevgrep baseline 低 29.97%。兩組結果都排除 Jev 本身的費用。
我的判斷是中性偏多。當 Agent 知道要理解的行為，卻不知道檔名和 symbol，jevgrep 能提供好起點。當你已知精確函式名稱、錯誤文字或路徑時，rg 往往更快、更透明，也不會把程式片段送到外部模型。
jevgrep 是什麼？它不是一般關鍵字搜尋
一般 grep 或 ripgrep 會尋找精確文字或規則。例如你知道函式叫 validateToken，就能搜尋這個名稱。問題是陌生程式庫的命名可能完全不同，你只知道「請求在進入處理器前會做驗證」。
jevgrep 接受自然語言問題，讓 Jev 判斷資料夾、檔案和程式宣告與問題的相關性。Jev 是 TypeSafe AI 的 decision model，也就是針對多個候選項目做判斷與排序的模型。
工具不會直接替 Agent 生成最終答案。它輸出的是相關檔案、原始碼片段與行號，呼叫它的 Coding Agent 再閱讀完整檔案、修改程式並跑測試。官方架構文件也強調，取回的 source code 是資料，不應被當成指令。
它怎麼找？從資料夾一路縮小到原始碼片段
jevgrep 先走訪程式庫階層，利用資料夾資訊與內容預覽判斷要深入哪些分支。選到檔案後，再辨識可能有用的函式、類別或其他宣告，最後保留附近上下文與行號。
Python、TypeScript 和 JavaScript 可使用宣告解析。其他文字檔或無法解析的程式碼則退回有限長度的文字區塊。它不強迫每次只回傳固定前兩名，通過相關性判斷的檔案可以保留。
輸出最前面是簡短狀態與檔案摘要，接著是逐字原始碼，再列出較詳細的宣告與呼叫位置。這個順序是為了讓 Agent 先看到能直接判斷的證據，再決定是否讀更多檔案。
重要限制是搜尋不保證完整。尚未走訪的分支、分類失敗的內容與被 ignore 規則排除的檔案仍然未知。jevgrep 提供的是研究起點，不是「所有相關程式一定都找到了」的證明。
什麼時候用 jg，什麼時候用 rg？
| 問題類型 | 建議工具 | 原因 |
|---|---|---|
| 已知函式、錯誤文字或檔名 | rg |
精確、快速、完全在本機 |
| 知道行為但不知道命名 | jg |
能依自然語言和程式內容找線索 |
| 功能跨多個資料夾與測試 | 先 jg，再 rg／讀檔 |
先縮小範圍，再做精確確認 |
| 機密程式不可送外部服務 | rg 或核准的內部搜尋 |
jg 會把合格 source 送到選定 provider |
| 要證明所有引用或呼叫 | LSP、rg、編譯器工具 |
語意相關性搜尋不等於完整 reference analysis |
LSP 是 Language Server Protocol，能提供定義、引用與型別資訊。若問題是「這個 symbol 被哪些地方呼叫」，LSP 或精確搜尋比相關性模型更合適。
最有效率的組合通常不是二選一。先用 jg 找可能的模組，再用 rg 搜尋精確名稱、讀完整檔案並檢查測試。官方 skill 也教 Agent 在必要時用一般工具補足缺口。
「省 40%」的 SWE-bench 證據怎麼看？
SWE-bench 是以真實 GitHub issue 評估 AI 是否能修改程式並通過測試的基準。jevgrep 作者最初在 X 宣稱降低 40% Coding Agent 成本，官方 README 現在提供了更完整的限制。
該輪只有 10 個經調整的 Python 任務，使用 Sol 模型。加入 jg 後，完整 Coding Agent 成本從 7.62 美元降到 4.52 美元，約低 40%。但解題率從保存的 baseline 8/10 降為 7/10。這表示它觀察到成本下降，也同時出現品質取捨，不能寫成「同品質省 40%」。
9 月 28 日公布的速度研究使用同一組 10 題。候選版本與 no-jevgrep baseline 都解出 8/10，Agent 成本為 5.34 美元對 7.62 美元，低 29.97%，token 少 41.51%，整體時間快 12.70%。這一輪保留了解題數，但仍只是小型、已調整的 Python cohort。
兩份報告都沒有把 Jev API 成本加入 Coding Agent 帳單。API 是讓程式透過網路呼叫另一項服務的介面。最新速度研究指出，原生 Jev 回應沒有價格 metadata，因此 Jev 費用是未知，不是零。總成本比較時，必須把模型 provider 的實際帳單另外加入。
David Zhang 示範 jevgrep 如何替 Coding Agent 收集陌生程式庫的相關上下文。 影片來源：David Zhang 官方 X。
40%、30% 和 41.51% 為什麼不是同一件事？
- 約 40%：較早一輪的 Coding Agent 成本下降，解題率從 8/10 變成 7/10。
- 29.97%：最新速度研究相對 no-jevgrep baseline 的 Sol 成本下降，兩邊都是 8/10。
- 41.51%：最新研究的 Sol 輸入與輸出 token 減少比例。
- 12.70%：最新研究的 wall time，也就是從開始到結束的實際時間改善。
成本、token、時間與解題率是四個不同指標。產品介紹只摘其中最大的百分比，很容易讓讀者以為所有面向都同時改善。對自己的專案評估時，至少要一起記錄成功率、完整 Agent 帳單、Jev 帳單和總耗時。
jevgrep 怎麼安裝？CLI 和 Agent Skill 都要裝
官方要求 Node.js 22 以上，支援 macOS 與 Linux。先安裝 CLI：
npm install -g @dzhng/jevgrep
jg auth
jg skill
jg auth 會要求選擇 provider 並儲存 API key。官方列出的 provider 包括 Vercel AI Gateway、TypeSafe、OpenRouter 與 OpenCode Zen。金鑰會保存在只有檔案擁有者可讀的設定檔。
CLI 安裝後，還要執行 jg skill。這個 Agent Skill 會教 Claude Code、Codex 或其他 Agent 何時使用 jg、如何閱讀回傳內容，以及何時改用一般搜尋補足。只安裝指令，不代表 Agent 自動知道應在什麼情況呼叫它。
基本用法如下：
jg "How are telemetry events recorded and sent?" ./my-project
若已知路徑，可以縮小 search root，減少送出的程式碼與成本。團隊環境也應固定 jevgrep 版本，分開更新 CLI 與 skill，因為更新 npm 套件不會自動覆寫專案中的 skill 檔案。
程式碼會離開本機嗎？會，需先確認資料邊界
官方 README 明確表示，搜尋會把符合條件的 source content 送到 Jev，並經由 jg auth 選定的 provider。它會遵守 ignore 檔案，排除隱藏、相依套件、build、binary 和明顯 credential 檔，但官方也強調這些過濾不能保證移除所有敏感資訊。
因此，search root 應只包含你確定可以送出的內容。客戶專案、未公開演算法、金鑰、個資、合約或受出口管制內容，都要先依公司政策審查。不要把整個工作區或家目錄當成搜尋範圍。
另一個風險是 prompt injection。原始碼註解、測試資料與文件可能包含看似指令的文字。官方架構把取回內容定義為 data，但最終 Coding Agent 是否遵守仍取決於它的 system rules 和工具權限。高風險環境應限制寫入、網路與命令執行權限。
它適合哪些團隊？
最適合的是大型、陌生或命名不一致的程式庫，且 Coding Agent 經常花很多 token 在列目錄、猜關鍵字和讀無關檔案。新進工程師接手舊系統，或 Agent 處理跨模組 issue，也可能受益。
不一定適合的情境包括小型專案、檔案結構清楚、精確 symbol 已知，或程式碼不能離開核准環境。這些情況下，rg、LSP 和直接讀檔通常更快，也沒有額外 provider 成本。
對非 Python、TypeScript 和 JavaScript 專案，jevgrep 仍能用文字區塊搜尋，但缺少專門的宣告解析。Go、Rust、Java 或混合語言程式庫應先用真實 issue 測試，不要直接套用官方 Python cohort 的成本結果。
如何在自己的專案驗證？
挑選 10 個已經解過、答案可核對的歷史 issue，分成兩組交叉執行。每個任務固定相同程式版本、Agent、模型、提示與工具權限，一組允許 jg，另一組只用原有搜尋工具。
記錄每題是否通過測試、Agent token 和費用、Jev API 費用、wall time，以及 jg 是否找到實際修改檔案。失敗任務也要計入，不能只比較成功案例。
樣本很小時，不要只看平均。列出每題結果，檢查成本下降是否集中在少數大型任務，以及是否有某些語言或結構更容易漏掉關鍵檔案。
我會把導入門檻設為：解題率至少不下降，完整總成本明顯降低，機密資料政策允許，而且失敗時 Agent 能用 rg、LSP 或讀檔補足。只要其中一項不成立，就應把 jg 保留為選用工具。
jevgrep 常見問題
jevgrep 會取代 ripgrep 嗎？
不會。已知精確文字、symbol 或路徑時，rg 更快且完全本機。jevgrep 主要處理「知道行為，不知道叫什麼」的問題。
它真的能省 40% 成本嗎？
官方只在一個 10 題 Python cohort 觀察到約 40% Agent 成本下降，而且解題率低一題。更新研究在相同 8/10 解題率下觀察到 29.97% Agent 成本下降。兩者都不是通用保證，也未把 Jev 費用加入。
搜尋結果是 AI 生成摘要嗎？
主要輸出包含原始程式碼片段、檔案路徑和行號。摘要與檔案選擇仍受模型判斷影響，不能保證完整。
程式碼會送到外部服務嗎？
會。符合條件的 source content 會送到選定 provider 的 Jev。官方過濾敏感檔案，但不保證完全移除，使用者必須限制 search root 並遵守公司政策。
安裝 CLI 後 Agent 就會自動使用嗎？
不一定。官方要求另外安裝 jg skill，讓相容 Coding Agent 知道何時呼叫 jevgrep。CLI 與 skill 更新也要分開處理。
結語：把它當成研究助手，不是搜尋真相機
jevgrep 解決的是 Coding Agent 很常見的浪費：知道要理解哪種行為，卻在陌生程式庫反覆猜檔名與關鍵字。它用自然語言縮小範圍，再把帶行號的原始碼交給 Agent，這個方向合理。
X 上的 40% 成本主張需要完整上下文。較早測試伴隨解題率下降，更新測試則觀察到 29.97% Agent 成本下降與相同解題數。樣本只有 10 個調整過的 Python 任務，Jev 成本也未納入。
最務實的做法，是在可送出程式碼的專案，用 10 個歷史 issue 做配對測試。只有當解題率不降、完整帳單下降，而且 jg 找到的線索能被原始碼與測試證明，才值得讓 Agent 把它加入預設研究流程。
