KotlinLLM 俾執行中程式即場補邏輯，但 code review 要事後先做

JetBrains Research 公開咗 KotlinLLM，一個俾 Kotlin/JVM 程式喺執行途中補寫邏輯嘅研究原型。佢有趣嘅地方，係 LLM 生成嘅答案唔會用完即棄，而會變成普通 Kotlin source code，編譯後塞返入行緊嘅 JVM。下次撞到已識處理嘅輸入，程式直接行嗰段碼，毋須再問模型，延遲、費用同每次答案唔同嘅問題都少一截。

實際行一次就容易明

拎官方 GitHub Issue Radar sample 做例，開發者可以用 asLlm(from, hint)，要求程式將 repository 名稱變成 API URL、拆 GitHub 回傳嘅 JSON，再按各個專案唔同嘅 label 命名揀出 beginner issue。生成邏輯未見過某種資料格式時，plugin 會停住程式，讀取當刻嘅值同 Kotlin type，叫 LLM agent 檢查輸入，再提交一小段新 handler。跟住佢編譯改動、經 JDI hot reload 個 class，重試頭先失敗嗰次呼叫。

另一個入口 mockLlm<T>() 會按介面同實際 method call 生成有狀態嘅 test double，適合快速砌 prototype。不過支援範圍幾窄：JetBrains 論文寫明，現階段只處理專案自己定義嘅 interface，唔支援 class、外部 library interface 同 generic Smart macro。JVM hot reload 本身亦有限制，程式啟動後唔可以任意加 field、method 或新 class，所以 plugin 要預先起好骨架，LLM 主要改入面準備好嘅 implementation body。

圖片：JetBrains Research

同普通 LLM 呼叫、coding agent 差喺邊

每次 request 都直接問 LLM，優點係彈性最大，但 latency、API 費用、服務斷線同輸出飄忽會一路跟住個 app。外置 coding agent 通常喺開發階段改 repository，改動可以先經 pull request、CI 同人手批核，之後先部署。KotlinLLM 就夾喺兩者中間：call site 清楚標住由 LLM 補邏輯，生成結果亦會留低，不過第一次遇到新情況時，未經人手 review 嘅碼已經編譯兼載入咗執行中程式。

持久化確實令之後嘅審計容易啲。團隊可以將生成檔放入 Git、補測試、跑靜態分析，再跟正常 release 流程出貨；覆蓋過嘅情況甚至可以完全斷開 LLM。不過 code review 次序已經倒轉：系統先用真實輸入試行，開發者之後先見到改動。放喺獨立開發環境幾方便，但擺入有客戶資料、付款權限或內部憑證嘅 production server，就等於俾未經審批嘅程式碼掂到高風險權限，好難接受。

官方數字要連細節一齊睇

JetBrains 官方文章話，改裝過嘅 Spring Petclinic 有 18 個 asLlm call site，24 個情況最後全部完成，30 次已編譯更新亦全部 hot reload 成功；編譯同 class redefinition 只佔總時間約 1%。但論文入面仲有兩個關鍵數字：生成碼 36 次嘗試得 30 次編譯成功，即 83.3%，而每次 LLM request 平均等 64.9 秒。換句話講，嗰個約 1% 講緊編譯同換 class 嘅開支，唔代表程式撞到新輸入時只會窒一窒。

另一個 Issue Radar 測試涵蓋 20 個 repository、30,637 個 issue，JetBrains 報告嘅整體 recall 係 0.8907；生成碼編譯成功率得 71.4%，每次模型請求平均 114.7 秒。呢啲仍然係研究團隊自己揀嘅 sample 同評估方法，亦冇 production 流量、多個請求同時執行、惡意輸入或長期累積改動嘅數據。呢組測試只顯示 compiled JVM 程式可以動態補碼；要確認業務邏輯長期可靠，仲要做多好多測試。

安全檢查有做，但未夠做防線

論文披露，現有安全檢查只係 heuristic，會擋常見高危模式，例如檔案同網上存取、開 process、讀環境變數、reflection、classloader、thread、coroutine，同時間或隨機數操作。呢層限制有用，但 JetBrains 自己都講明佢唔構成完整安全證明。runtime input 亦可能係外部人士控制嘅文字，團隊要當 prompt injection、過闊 guard、錯誤資料轉換同越權讀值全部有機會發生。

資料外傳同樣唔可以略過。現時 main branch 預設經 Koog 用 OpenAI GPT-5，程式碼亦留有 JetBrains Grazie staging 配 Claude Sonnet 4.5 嘅路徑；公開 README 主要教用家喺專案 .kotlinllm 檔放 OpenAI API key。agent 會接觸 runtime value、type 資料，亦有工具搜尋大型輸入。OpenAI 官方話 API 資料預設唔會用嚟訓練模型，但 abuse monitoring log 仍可能保留 prompt 同回應最多 30 日，所以「唔訓練」唔等於敏感資料冇離開公司環境。

而家適合點用

現階段要求 IntelliJ IDEA 2025.2.x、JDK 21、Kotlin/JVM 同 IDEA Kotlin run configuration；Gradle 啟動、Android/ART 或其他 Kotlin target 都唔應自行當成支援。想試嘅團隊，可以喺冇 production 資料同高權限憑證嘅隔離環境收集情況，之後將生成碼當第三方交付物咁掃描、review、補測試，再經 CI 編譯成固定版本。正式環境關掉自動生成，只跑已批核 source code，會係而家比較穩陣嘅用法。

參考來源

• iThome — JetBrains開源KotlinLLM，執行中程式可按需呼叫LLM補寫邏輯 — original report
• JetBrains Research：KotlinLLM is Going Open Source — 官方功能解說、定位、評估摘要同 Apache 2.0 授權資料。
• JetBrains Research KotlinLLM GitHub repository — 核對 runtime 流程、IDE/JDK 要求、模型設定、Smart macro 限制同安裝方式。
• KotlinLLM 研究論文 — 評估完整數字、JVM 限制、生成碼可靠度同 heuristic 安全檢查細節。
• OpenAI API data controls — 核對 API 資料會唔會用作訓練、abuse monitoring 同預設保留期。

本文根據原文及公開資料整理；資料有出入時，以原文及官方資料為準。