Junie Local Windows版转正

Windows 本地 AI 编程终于越过实验阶段

JetBrains 于 10 月 16 日宣布，Junie Local 对 Windows 的支持已经从实验阶段升级为稳定版，并完成对英伟达 RTX Spark 平台的 Day 0 适配。符合硬件要求的开发者现在可以让 AI 在本机读取代码库、修改文件、执行终端命令并运行测试，不需要注册或订阅，也不会产生按词元计算的费用。

Junie Local 是 JetBrains 推出的本地 AI 编程智能体，它把模型推理和代码代理的执行过程放在用户自己的电脑上完成。这里的重点不是离线聊天，而是让模型真正进入开发闭环：理解项目结构、制定修改计划、编辑多个文件、调用构建工具、运行测试，再根据报错继续修正。

这次更新真正解决的是 Windows 开发者能不能把本地编码智能体用于日常工作的问题。此前，Junie Local 在 Windows 上只能通过 nightly build 使用实验性 RTX 支持；转为稳定版后，安装、硬件检测和模型部署进入正式支持范围，使用门槛明显低于手动搭建推理框架、量化模型和智能体工具链。

它不只是补全代码，而是在本机执行任务

AI 编程智能体是能够自主规划并执行多步骤开发任务的软件系统。传统代码补全主要根据光标附近的上下文预测下一段代码，而 Junie 这类智能体需要浏览整个项目，判断应该修改哪些文件，并通过测试结果验证修改是否成立。

Junie Local 当前能够覆盖一条相对完整的开发流程：

• 读取项目文件并理解目录结构、依赖关系和已有实现；
• 将自然语言需求拆分为多个执行步骤；
• 创建、删除或修改代码和配置文件；
• 运行测试、构建命令及必要的终端工具；
• 根据失败日志继续调整实现；
• 展示文件差异，并允许用户保留或回滚修改。

这套能力最适合边界明确、验证方式清晰的工程任务。例如，开发者可以让 Junie Local 为已有模块补齐单元测试、完成跨文件重命名、升级依赖、修复静态检查问题，或者先阅读一个接手不久的仓库，再解释关键调用链。

本地运行并不意味着智能体可以不受约束地操作电脑。JetBrains 的 Junie 产品提供只读询问、代码执行、操作审批、允许列表和回滚等机制，默认可以要求用户批准命令和文件操作；对于高风险仓库，开发者仍应限制可执行命令，并在独立分支或工作树中审查最终差异。

24GB 显存是现实门槛

Junie Local Windows 稳定版对硬件的最低要求并不低。普通集成显卡和常见的 8GB、12GB、16GB 游戏显卡不在此次正式支持范围内，系统需要至少 24GB 显存的英伟达 RTX 显卡，并采用 Ampere 或更新架构。

| 硬件或软件 | 最低要求或官方信息 | 实际意义 | |---|---:|---| | 操作系统 | 对应架构的 Windows 11 | Windows 10 不在本次要求内 | | GPU 架构 | NVIDIA Ampere 或更新 | RTX 20 系列不符合架构要求 | | GPU 显存 | 至少 24GB | 决定模型能否装入及上下文容量 | | 已列出的显卡 | RTX 3090、RTX 4090、32GB RTX 5090 | 24GB 及以上高端消费卡成为主要选择 | | NVIDIA 驱动 | 581 或更新版本 | 安装前需要升级驱动 | | 磁盘空间 | 约 20GB | 用于模型、运行时及相关文件 | | RTX Spark 性能 | 最高 55 tokens/s | 属于 JetBrains 初步测试结果 |

24GB 显存是这次更新最明确的分界线。它意味着 Junie Local 还不是所有 Windows 笔记本都能使用的普惠功能，而是首先面向拥有高端 RTX 台式机、移动工作站或专用 AI 设备的开发者。

安装程序自动化是稳定版比实验版更重要的改进之一。新版安装程序会检查显卡型号和驱动版本、部署模型，并根据可用 GPU 内存调整上下文容量，开发者不必手动判断模型层应该如何装载，也不必自己组合推理后端和量化文件。

上下文容量是模型一次推理能够保留的代码、指令和对话信息总量。Junie Local 会根据显存动态调整这一容量，显存越充足，智能体越有机会同时保留更多项目文件和历史步骤；如果上下文过小，模型可能在长任务中遗忘早期约束，或需要反复读取文件，从而增加延迟。

每秒 55 个词元够不够用

JetBrains 表示，Junie Local 在英伟达 RTX Spark 平台上的初步测试速度最高达到每秒 55 个词元。词元是模型处理文本时使用的基本单位，英文代码中的变量、符号和单词可能被拆成一个或多个词元，因此 55 tokens/s 不能直接换算为每秒生成多少行代码。

每秒 55 个词元已经进入可交互使用的区间。按照持续生成 1000 个输出词元估算，纯生成阶段理论上约需 18 秒，但一次智能体任务还包括扫描仓库、构建上下文、调用工具、等待编译和运行测试，实际总耗时通常会显著高于模型输出时间。

这个性能数字也需要谨慎解读。JetBrains 将其表述为 RTX Spark 上的初步测试最高值，而不是所有受支持显卡的统一速度；RTX 3090、4090 和 5090 的实际表现还会受到模型版本、上下文长度、量化方式、项目规模、显存占用和散热条件影响。

融合模型试图压缩“思考税”

Junie Local 提供 Qwen3.6-27B 和 JetBrains 融合模型等选择。融合模型 Qwen3.8-3.6-27B-blend 是 JetBrains 将两个模型按相同比例合并得到的本地编码模型，目标是在接近高推理能力版本成功率的同时，减少过长的推理输出。

JetBrains 此前披露的 100 项内部编码任务显示，Qwen3.8-3.6-27B-blend 完成了 37 项任务，关闭推理的 Qwen3.6 完成了 34 项，Qwen3.8 则完成了 39 项。融合模型比 Qwen3.6 多完成 3 项任务，与 Qwen3.8 相差 2 项，但输出词元数量比 Qwen3.8 少 71%。

| 模型 | 完成任务数 | 相对表现 | 输出特征 | |---|---:|---|---| | Qwen3.6（关闭推理） | 34/100 | 速度优先的基线 | 输出较短，任务成功率最低 | | Qwen3.8-3.6-27B-blend | 37/100 | 比基线多完成 3 项 | 比 Qwen3.8 少输出 71% 词元 | | Qwen3.8 | 39/100 | 三者中完成数最高 | 依赖推理，任务耗时约为基线的 4 倍 |

融合模型的价值不是单纯减少词元费用，因为 Junie Local 本身不按词元收费。更短的输出会直接降低本地生成时间、显存压力和等待时间，这相当于压缩智能体的“思考税”：模型仍然保留较强的任务完成能力，但不必为每一步生成过长的推理过程。

这组成绩仍然只是 JetBrains 的内部基准，而不是独立第三方评测。100 个任务足以说明模型调优方向，却不足以证明它在不同语言、框架和大型企业仓库中都能保持同样优势，尤其不能将 37%的任务完成率简单理解为日常开发成功率。

本地方案的优势不是“免费”两个字

Junie Local 的核心竞争力是数据边界、可预测成本和持续迭代能力。代码无需上传云端，没有订阅费、词元费用和使用配额，开发者可以把过去因成本而搁置的重复工作交给智能体，例如批量补测试、机械式重构和多轮依赖迁移。

| 对比维度 | Junie Local | 常见云端编码智能体 | |---|---|---| | 模型运行位置 | 用户本机 GPU | 服务商数据中心 | | 代码传输 | 可在本地完成 | 通常需要上传相关上下文 | | 使用成本 | 不收订阅费和词元费，但需要合格硬件与电力 | 通常按订阅、请求或用量计费 | | 使用配额 | 官方称不设配额 | 可能存在速率或月度额度限制 | | 模型上限 | 受本机显存和本地模型能力约束 | 可调用规模更大的前沿模型 | | 维护成本 | 用户负责驱动、磁盘和硬件环境 | 服务商负责基础设施 | | 网络依赖 | 模型运行不依赖云端推理 | 通常要求稳定网络连接 |

本地方案并不等于零成本。若开发者原本没有 24GB 显存显卡，新增硬件投入可能远高于数月云服务订阅费；模型下载约占 20GB 磁盘空间，长时间推理也会带来功耗、噪声和设备占用。

云端模型在复杂推理和超大上下文上仍可能占优。Junie Local 更适合代码敏感、调用频繁、任务可通过测试验证的团队，而偶尔使用智能体、没有高端 GPU，或者需要最强模型处理疑难架构问题的开发者，未必能从本地部署中获得更好的经济性。

JetBrains 的优势在“执行环境”而非模型榜单

JetBrains 在这场竞争中的优势是掌握 IDE、项目索引、构建系统和测试入口。编码智能体的效果不仅取决于模型会不会写代码，也取决于它能否准确找到相关文件、选择正确命令、理解报错，并把修改控制在合理范围内。

Junie Local 把本地模型接入读取、编辑、测试和回滚流程，比单独下载一个 27B 参数模型更接近可用产品。对开发者而言，模型能在榜单上多答对几道题固然重要，但一次修改是否可审查、失败后能否回滚、命令执行是否需要审批，才决定它能不能进入真实仓库。

Windows 稳定版也补齐了 Junie Local 最重要的平台缺口。大量使用 Visual Studio、JetBrains IDE、WSL 和英伟达消费级显卡的开发者集中在 Windows 平台，只支持 macOS 或 Linux 会直接缩小本地编码智能体的可用人群。

结论：可用，但远未到人人可用

Junie Local Windows 转正让本地编码智能体从技术预览向生产工具迈出了一步。自动检测硬件、部署模型和调整上下文，解决了本地大模型最消耗时间的环境配置问题；读取代码、修改文件和运行测试形成的闭环，也比单纯本地聊天更有实际价值。

Junie Local 当前最大的限制依然是硬件门槛和模型能力上限。至少 24GB 显存把多数主流 Windows 电脑挡在门外，而 100 项内部评测中完成 37 项任务，也说明本地模型还不能替代人工审查或顶级云端模型。

这次更新最值得关注的信号，是本地 AI 编程开始从“能跑模型”转向“能完成工程任务”。当安装、权限、测试和回滚都被纳入同一个产品，开发者才有可能把本地推理当作日常生产力工具，而不是一次需要维护大量组件的部署实验。

参考来源

• IT之家：Junie Local 适配 RTX Spark，Windows 支持升级为稳定版：介绍发布时间、硬件要求、安装流程与最高每秒 55 个词元的测试数据。
• GitHub：JetBrains Junie 官方仓库：提供 Junie 的安装脚本、更新通道、模板及本地运行相关文件。
• Hugging Face：Qwen3.8-3.6-27B-blend 模型检索页：用于查询 JetBrains 融合模型及相关模型资料。