为什么我建议你在 IDEA 里接本地大模型
直接把话说在前面：如果你每天写代码都要打开网页问 ChatGPT，或者担心公司代码被云端 AI 服务拿去做了训练数据，那我强烈建议你把这事彻底换一个玩法——在 IDEA 里装一个 ProxyAI 插件，后端接上你自己机器上的本地大模型，让代码补全、注释生成、代码解释这些日常工作，彻底不经过外部网络。
这套方案我实际跑了几个月，从 7B 的小模型一直试到 14B 的量化版本，过程中踩了不少坑，也总结出了一套稳定能用的配置路径。这篇文章就把整个思路、选型理由、配置细节和排坑经验全部摊开讲。
文章适合三类人：一是对代码隐私有要求、公司还没有统一 AI 编程平台的技术负责人；二是想跑通本地模型的进阶开发者，手里有一张不错的显卡但不知道怎么把模型跟 IDE 打通；三是不想每月花订阅费、想用自己的硬件白嫖 AI 辅助能力的效率党。
先说结论：这套组合完全可以做到“开箱即用”，配置难度不高，真正花时间的是模型选型和参数调优。我会把这些坑都指出来，你照着走会顺利很多。
1. 整体设计拆解：为什么是 ProxyAI 而不是直接用本地模型
一开始我拿到这个需求的时候，第一反应是：本地模型不是有 Ollama 或者 LM Studio 就够了嘛，为什么还要专门装一个 IDEA 插件？
后来我发现，这个理解有个很大的盲区：Ollama 解决的是“模型怎么跑起来”的问题，但它不是一个 IDE 层面的交互入口。你在 IDEA 里写代码的时候，需要一个能感知当前文件、当前光标位置、选中代码片段的助手，它才能做真正贴合上下文的补全和对话。如果只是开个浏览器访问本地模型，那跟用云端 Web 版没有本质区别，体验碎片化，效率也不会高。
ProxyAI 在这个链路里扮演的角色，是一个桥接层。它把 IDEA 的 AI 功能请求，按照约定格式发送到你指定的本地服务地址，然后接收模型返回的内容，再以代码补全、侧边栏对话、代码审查建议这些形式呈现到编辑器里。
也就是说，ProxyAI 不关心模型有多强，也不关心服务跑在哪台机器上。它只做一件事：把你的指令和代码上下文，打包成 HTTP 请求发出去，再把结果拿回来。
1.1 这背后的核心思路：协议标准化
在具体配置之前，我想先聊清楚一个概念性问题：为什么要通过插件去连？直接自己写代码调用模型不行吗？
当然可以，但你要应付的东西太多了。比如 IDEA 自带的 AI 相关接口、编辑器的光标事件、选择文本的回调、异步加载、侧边栏 UI、补全触发时机……这些工作量加起来，足够你写一个自己的插件了。ProxyAI 的定位就是省掉这些重复造轮子的时间，你只需要告诉它：我的模型服务在哪个地址，它就能把 IDEA 各个入口接进来。
协议标准化是这个方案能成立的关键。现在几乎所有本地推理工具都支持 OpenAI 兼容的 HTTP 接口，也就是说它们暴露出来的接口长得很像：都接受api_key、model、messages这些字段，返回也都是类似格式。ProxyAI 只要实现一次 OpenAI 格式的客户端，就能接住市面上几乎所有本地模型后端。
这就是为什么配置的核心只有三项：接口地址、密钥（可任意填）、模型名称。
1.2 ProxyAI 对比直连本地服务：差在哪
有朋友可能问，那我把 Ollama 的服务地址直接配进其他 AI 插件里不也行吗？
行，但 ProxyAI 有一点做得比较好：它对本地服务的容错性和兼容性都在线。比如模型首次加载需要时间、请求超时应该怎么处理、上下文长度超出限制时怎么自动降级，这些细节它都有一定的处理策略。而不少云服务优先的插件会在连接本地地址时出现各种莫名其妙的问题，有的甚至不支持自定义地址。
我实际测试下来，ProxyAI 还有一个我很喜欢的特点：它可以让你在同一个界面里管理多个模型后端，来回切换非常方便。比如我本地同时跑了一个代码专用的模型和一个通用对话模型，切一次下拉框就行，不用去改配置文件。
当然，我也要说句公道话。ProxyAI 本质上还是一个插件，它不是万能的。比如社区版 IDEA 能用的功能范围有限，某些功能需要旗舰版的 IDE 接口；另外它本身不带模型管理能力，模型下载、启动、监控依然要靠 Ollama 或同类工具来做。理解了这个分工，你就知道配置的时候该把精力花在哪了。
2. 实操准备：本地模型服务怎么搭建
在配置 ProxyAI 之前，最核心的前置工作是把本地模型跑起来。我推荐使用 Ollama，它目前是本地部署大模型最省心的方案之一，跨平台支持也好，Windows、macOS、Linux 都有安装包。
2.1 安装运行环境与模型拉取
Ollama 的安装没什么好讲的，去官网下载对应系统的安装包，双击安装即可。装完之后，打开终端验证一下：
ollama --version如果正常输出版本号，说明安装成功。接下来就是拉取模型。我强烈建议代码相关的场景不要拉通用模型，直接拉代码专用模型。目前我主力用过两个：
# 阿里通义千问的代码版，14B 量化后效果和速度比较均衡 ollama pull qwen2.5-coder:14b # 如果想要响应更快、对显存要求更低，可以先从 7B 版本起步 ollama pull qwen2.5-coder:7b拉取之后，用ollama list确认模型已经存在。
2.2 服务启动与接口验证
Ollama 默认装好后会作为一个系统服务运行，监听在11434端口。你可以手动启动，也可以直接交给系统服务管理。我最常用的是手动前台启动，方便看日志：
ollama serve如果要验证接口是否通，可以这样检查：
curl http://localhost:11434/v1/models如果返回了一段 JSON 数据，里面有模型列表，说明服务已经就绪。这里有个关键点要记住：这个/v1/models路径对应的是 OpenAI 兼容协议，不是 Ollama 原生接口。你在 ProxyAI 里配置的地址，也是这个/v1前缀的地址。
2.3 关于显存和模型规模的硬指标
很多朋友刚接触本地模型，第一反应是“先上最大的”。我要泼一盆冷水：本地模型能不能流畅跑，核心瓶颈不是 CPU，而是显存。
以我的经验，14B 模型用 4-bit 量化之后，占用大概 9GB 到 10GB 显存，7B 量化版大概 5GB 到 6GB。如果你的显卡只有 8GB 显存，我建议你老老实实用 7B，不要硬上 14B，否则性能会让你怀疑人生。
另外，内存大小也值得关注。模型加载时要有一部分参数驻留在内存里，16GB 内存跑 14B 会很吃力，至少要有 32GB 才会比较从容。如果你没有独立显卡，纯靠 CPU 跑 7B 模型也能出结果，但速度会慢很多，基本只能当对话用，代码补全的体验很差。
我的建议配置分档如下：
| 硬件水平 | 推荐模型规模 | 预期体验 |
|---|---|---|
| 无独显，内存 16GB | 3B~4B 量化小模型 | 对话尚可，补全较慢 |
| 8GB 显存以上 | 7B 量化模型 | 日常补全可用，响应 2-5 秒 |
| 12GB 显存以上 | 14B 量化模型 | 质量明显提升，响应 3-8 秒 |
| 24GB 显存以上 | 32B 量化模型 | 逼近云端体验，值得一试 |
这个表是基于我实际测试的体感，显卡型号不同会有浮动，但是大方向不会错。
3. 配置 ProxyAI 插件的完整过程
服务端准备就绪之后，真正的重头戏来了：在 IDEA 里装插件、配置地址、接通模型。
3.1 安装插件并打开设置面板
打开 IDEA 的设置界面（macOS 是Preferences，Windows/Linux 是Settings），进入Plugins，在 Marketplace 搜索ProxyAI，找到之后点击 Install，重启 IDE。
重启后，IDEA 的右侧一般会出现一个 ProxyAI 的工具窗口。如果没有，可以在View -> Tool Windows里找到它。首次打开会有一个引导配置页面，不用急着关，直接跳到下一步设置。
3.2 填写 API 地址与密钥：这步最关键
在 ProxyAI 的设置项里，会有几个核心字段需要填写，我逐个说一下：
第一项是API Base URL，也就是模型服务的访问地址。本地默认情况下填：
http://localhost:11434/v1注意这个/v1必须带上，因为 ProxyAI 是照着 OpenAI 协议去请求的。如果你漏了，会出现“404 Not Found”或者“接口路径不存在”之类的报错。如果你把 Ollama 跑在另一台机器上，或者跑在 Docker 容器里，就填对应的局域网地址，把localhost换掉即可。
第二项是API Key。很多人到这一步会卡住，觉得本地模型没有密钥，不知道该填什么。实际上 Ollama 这类本地服务默认不校验 Key，你随便填一串字符串就行，比如ollama、local-model、sk-123456都可以，只要不为空。ProxyAI 会把密钥放在请求头里发出去，服务端不校验，自然就通了。
第三项是Model Name。这里填你从ollama list里看到的模型名称，要完全一致。比如：
qwen2.5-coder:14b大小写、冒号、标签都不能写错，否则服务端会提示模型不存在。
3.3 其他值得调整的细节设置
除了这三个核心项，ProxyAI 还有一些行为设置，我建议你花几分钟过一遍。
一个是请求超时时间。默认时间有时候不够用，尤其是本地模型第一次加载会很慢（要十几秒到几十秒），建议把超时设到 120 秒以上。我自己的配置是 300 秒，第一不怕冷启动，第二不用担心长上下文生成到一半被挂断。
另一个是流式输出开关。如果你发现代码补全要等完全生成完才一次性显示，体验会很差，把流式响应打开，让内容一个字符一个字符地蹦出来，交互感会舒服很多。
如果 ProxyAI 有“上下文携带范围”之类的设置，建议把当前文件和最近编辑过的文件作为主要上下文来源。本地模型上下文窗口有限，不要无脑塞很多东西进去，后面我会专门讲这个问题。
3.4 连接测试与首次对话
配置完成后，点一下连接测试类的按钮，或者直接在侧边栏发一条消息试试。
我第一次测试的时候发的是“用一句话介绍你自己”，模型加载了几秒之后开始逐字返回。如果你能看到那种打字机效果的输出，说明整条链路已经打通。接下来就可以试试真正的代码场景了。
选中一段代码，右键选择解释代码，或者把光标放在一个方法上让它生成注释。我这边 14B 模型对 Java 方法生成注释的质量相当不错，能准确识别这个方法是做数据校验还是做状态流转，注释的风格也像人写的。
4. 排坑实录：我遇到过的每一个问题
这部分是这篇文章里最值钱的地方。本地模型 + IDE 插件的组合，问题数量远比想象中多，而且很多问题的报错信息看不出来根因。我按遇到频率排个序，你把这篇当速查手册看就行。
4.1 无法连接本地服务
这是新手最常遇到的问题。如果你配置了地址，测试的时候提示Connection refused，大概率是 Ollama 服务根本没有在运行。
排查步骤：
# 先确认端口有没有监听 lsof -i :11434 # 没有输出说明服务没起来，换个终端执行 ollama serve如果端口有监听但还是连不上，检查一下地址是不是写成了11434之外的端口。有些朋友用 Docker 跑 Ollama，端口做了映射，宿主机的地址可能就不是 11434 了。这种情况要么改成正确的映射端口，要么直接别用 Docker，用原生安装版本最省心。
4.2 报错 404 或 Model Not Found
能连上但提示404，那就是 API 路径不对，检查是不是少了/v1。如果提示model not found，检查模型名称是否和ollama list输出完全一致。
我踩过的一个坑是：模型拉取时候用了大写字母，后来记成小写了；还有一次是版本标签里有一个看不出来的空格。这种问题最朴实也最磨人，心态稳住就好。
4.3 响应太慢，补全长不出东西
这个问题的根因基本都在硬件。想要流畅体验，我总结了一句口诀：显存大小决定能跑多大模型，算力高低决定生成快慢。
但如果不是硬件问题，也有可能是模型在后台被其他任务占了。Ollama 是单模型常驻机制，如果你同时跑了多个模型，切换时会有换入换出的开销。建议只保住一个主力代码模型，把其他不常用的删掉。
另外，长度较大的代码文件会让生成速度明显下降，因为它要一起考虑前面几百行代码的上下文。如果发现补全突然变卡，看看是不是当前文件已经超过一千行，在超大文件上本地模型的体验确实会打折。
4.4 上下文窗口不够用
这是我认为最需要提前了解的问题。本地模型的上下文窗口普遍不如云端模型。常见的 7B/14B 模型上下文可能只有 8K 或者 16K，这意味着你一次性塞给它的代码量是有上限的。
我之前就犯过这个错误：把整个项目几百个文件的路由配置往对话里一贴，想让模型帮我分析一下依赖关系，结果它直接报上下文溢出，或者答非所问。
正确做法是把问题拆小。你要改某个接口，就把接口定义文件和相关调用方放进去；你要生成单元测试，就只喂目标类和它的依赖接口。ProxyAI 的侧边栏对话支持手动指定上下文范围，配合好这个功能，本地模型能发挥出远超其纸面参数的效果。
4.5 IDEA 版本兼容问题
最后提一个很多人容易忽略的点：IDEA 的版本会直接影响插件的稳定性。ProxyAI 这类插件对 IDEA 的底层接口依赖很深，建议至少使用 2023.1 以上的版本。部分老旧版本会出现侧边栏空白、补全不触发、设置项不显示这类诡异问题，升级 IDE 往往比折腾插件配置更有效。
5. 使用习惯与经验技巧：如何把本地模型用到最好
配置通了只是第一步，本地模型能给你的工作效率带来多大提升，取决于你怎么用它。这里分享几个我摸索出来的实用技巧。
5.1 明确分工：什么任务交给哪个模型
本地跑多个模型的话，我给它们分配了不同的角色。代码补全和注释生成，用代码专用模型，质量和响应速度最均衡；日常概念问答、设计思路讨论，用通用对话模型，表达更自然、逻辑更全面。
这样分配的原因是术业有专攻。代码专用模型在补全场景下会在你的代码风格基础上续写，不容易跑偏；通用模型在解释抽象概念时驾驭文字的质感更好。来回切换并不麻烦，ProxyAI 的模型下拉框点一下就换。
5.2 把选中代码作为上下文，而不是全文件
这是我和本地模型协作下来最重要的心得。在 IDE 里跟 AI 协作，最高效的姿势是：先选中你想让它处理的代码块，再发起指令。
比如我习惯让模型生成一个方法的单元测试，我会选中整个方法体，在对话框里写“帮我为这个方法生成 JUnit 5 测试用例，覆盖正常路径和空指针异常”。这样模型收到的上下文非常聚焦，生成出来的测试代码几乎不需要大改。
反过来，如果你不选中任何内容直接问，模型只能从当前文件里找信息，猜测你到底想让它做什么，结果往往偏得离谱。
5.3 利用“解释代码”功能替代搜索引擎
我现在看别人项目里的复杂代码时，已经形成了一个固定动作：选中一段看不懂的代码，让本地模型解释一遍。14B 模型对常见框架代码的解释基本准确。
遇到个别上下文复杂、解释不到位的情况，我会对比通用模型一起看。两个不同模型的回答互相印证，比我以前自己去翻源码定位快得多。这相当于在我的 IDE 里装了一个随叫随到的结对工程师。
5.4 关于性能监控和模型更新
长时间开着 Ollama 的话，我建议偶尔看一眼它的内存占用。模型常驻内存的时间越长，系统越可能变慢，尤其是同时开着多个大型 IDE 项目的时候。
模型更新这一点也容易踩坑：代码专用模型更新频率不高，但每次发布新版本都值得关注。更新的操作很简单，重新ollama pull同名更新的标签即可，不需要先删旧模型。我一般会先在一台备用机器上试一下新版效果，再决定要不要替换主力的工作模型。
6. 这套方案我用了半年之后的真实评价
最后说点掏心窝子的话。
当初配置 ProxyAI 接本地大模型，我图的不是所谓“前沿技术体验”，而是三个非常朴素的东西：代码不出本机、不用每个月付订阅费、网络断了也能用。半年用下来，这三个目标全都实现了，但我也必须诚实地说，本地模型的水平跟顶级云端模型之间，依然存在肉眼可见的差距。
具体差在哪？一是代码生成的复杂逻辑能力，云端模型可以轻松处理的跨文件重构，本地 14B 模型在很多时候只能给你一个“接近但不完全正确”的方案；二是对超大上下文的驾驭能力，目前本地模型无法像云端那样吃下一整个仓库还保持稳健输出。
所以我对这套方案的真实定位是：它不是一个替代顶级云服务的方案，而是一个在隐私、成本和稳定性之间做到最佳平衡的替代方案。如果你的代码保密要求高，或者你希望有一个不依赖网络的 AI 副驾，那么 ProxyAI 加本地模型这套组合，是目前我试过的所有方案里最靠谱、最省心的。
如果你也想上手试试，我最后的建议是：先别急着追求大模型，把你手头能跑的模型装好、把插件配置通、把上下文控制的手感练出来。跑通之后再考虑升级更大的模型，你会更清楚每一步收益在哪里。
本地模型这条路，我还会继续走下去。等我在更大参数的模型上跑出新的心得，再来跟大家分享。
重要提示：不要为了追求效果硬上显存放不下的模型，没意义的。模型量化、上下文裁剪、插件配置这三件事做好，远比盲目升级硬件更能提升你的实际体验。
