在快速發展的 AI 輔助開發領域，程式設計師們正在尋找創新方法來克服內建 AI 工具的限制。一個名為 ProxyAsLocalModel 的新開源專案應運而生，為希望在 JetBrains AI 助手中使用自己偏好的大型語言模型（LLMs）的開發者提供瞭解決方案，繞過了平臺限制性的免費層配額。
擴充套件 JetBrains AI 助手超越預設選項
ProxyAsLocalModel 透過將第三方 LLM API 代理為與 AI 助手相容的本地模型，充當了這些服務與 JetBrains IDE 之間的橋樑。該工具解決了開發者常見的一個困擾：JetBrains AI 助手提供的免費配額有限且很快耗盡，同時僅支援來自 LM Studio 和 Ollama 的本地模型。透過建立一個模擬這些受支援的本地端點的代理，開發者可以利用他們已經購買的替代 LLM 服務，如 OpenAI、Claude、Gemini、Qwen、Deepseek、Mistral 和 SiliconFlow。
該專案在技術實現上尤為顯著，它使用 Kotlin、Ktor 和 kotlinx.serialization，透過 GraalVM 原生映象編譯實現了跨平臺相容性。這種方法避免了使用反射密集型的官方 SDK，後者使原生映象編譯變得困難，從而實現了更快的啟動時間和更低的記憶體使用率。
ProxyAsLocalModel 支援的 LLM 提供商
- 代理來源： OpenAI、Claude、DashScope（阿里巴巴 Qwen）、Gemini、Deepseek、Mistral、SiliconFlow
- 代理為： LM Studio、Ollama
- API 支援： 僅支援流式聊天完成 API
JetBrains AI 助手改進（2025 版本）
- 專案級啟用/停用選項
- 本地模型與線上模型的偏好設定
- 支援主要 LLM 提供商（OpenAI、Claude、Gemini）
- 更好的整體 IDE 整合
JetBrains AI 助手的演進和使用者體驗
社群討論顯示，對 JetBrains AI 助手的接受度參差不齊但正在改善。早期版本因其侷限性和傾向於重寫整個檔案而非專注於特定函式或程式碼塊而受到批評。
「我在 AI 助手剛推出時嘗試使用它，但似乎太笨了，無法正確使用。我試圖讓它為我編寫單個函式或簡短的程式碼塊，但它總是開始從頭重寫整個檔案，這太慢了。」
然而，最近的更新顯著提升了該工具的能力。2025 版本提供了更好的專案級控制，支援主要的 LLM 提供商如 OpenAI、Claude 和 Gemini，並改進了與 IDE 工作流的整合。使用者報告在程式碼審查、生成 REST 端點、編寫測試和探索不熟悉的庫方面取得了成功。JetBrains 較新的系統 Junie 的引入也因能解決其他 LLM 難以處理的複雜問題而獲得積極反饋。
替代解決方案和法律考量
雖然 ProxyAsLocalModel 提供了一種擴充套件 JetBrains AI 助手功能的方法，但社群成員也提出了一些替代方案，如 OpenRouter，它透過單一端點提供對數百個模型的訪問，除了提供商的公開價格外沒有額外成本。其他類似專案包括 enchanted-ollama-openrouter-proxy 和 LiteLLM Gateway。
討論中提出的一個重要考慮因素是將商業 AI 服務用於開發可能帶來的法律影響。一些使用者指出，許多 AI 服務提供商在其服務條款中包含不競爭條款，如果企業使用這些服務開發競爭產品，可能會使其面臨法律風險。這引發了關於這些 AI 工具在專業環境中適當使用場景的問題。
隨著 AI 輔助開發的不斷成熟，像 ProxyAsLocalModel 這樣的工具代表了社群定製和最佳化工作流的努力，即使底層平臺在不斷發展。對於希望在使用 JetBrains IDE 時最大化生產力的開發者來說，這些代理解決方案提供了一種方法，可以利用首選的 LLM 服務，同時應對平臺特定實現的限制。