一、开启大模型打零工之旅
从去年 Cursor 发布开始，这一年大模型在编程领域的进展可以说是日新月异。Vibe Coding 的火热也昭示着编程，这项曾经有着很强专业门槛的领域走进寻常百姓家，各种编程模型的推陈出新、各种编程工具的争相迭代，技术平民化浪潮可见一斑。
编程当然天然适合大模型的商业落地，因为相对其他行业，编程对结果的把握更有确定性，在一个可接受的限定范围内找到一个最优解不是难事。尤其是一些经过充分预训练的领域，程序员被替代的传闻铺天盖地。从人事视角看也是一笔合算的买卖，使用大模型编程工具的程序员可以提供更高的效率更优的产出，老板又会以此为由继续提高工作强度。身处其中，必然是果断拥抱。至于什么是程序员的核心竞争力，或者说是大模型无法轻易替代的，后续会专门来聊一下（这个话题在每次技术浪潮中都会被拿出来审视一遍）。
这里，我会拿出若干篇实证过的经验案例探讨工具的使用，然后回到程序员的工作流中来。我给这个系列起了一个名字「打零工」，这是从生产资料与生产力的关系看待此起彼伏的技术浪潮。好的工具一定可以提高生产力，但程序员依然要拥有决策能力（核心竞争力）。
那至于为什么是这个节点，因为今年 2 月 Claude 3.7 Sonnet 的发布被公认为基本可以达到生产代码可用性标准，这和以往开发个 demo、生成个小游戏的模型质量有了质变。同时，结合各家的 Agent 能力，Vibe Coding 真的可以照进现实。
我这里使用的环境是：
- JetBrains IntelliJ IDEA 2025.1
- JetBrains AI Assistant 251.x
- JetBrains Junie 251.x
- Claude 3.7 Sonnet
二、为什么还是 JetBrains
作为 Java 程序员，在大模型之前的十五年，甚至是二十年，IDE 首选是 JetBrains IntelliJ IDEA 几乎是没有悬念的。
这家诞生于上个世纪总部在捷克的专门从事各类编程语言 IDE 研发的公司仿佛是一个老古董，但不可否认，他们的 IDE 就是独树一帜的存在。对于程序员这么挑剔的群体而言，产品体验一直保持着不错的水准。编码与部署、重构与调试，它的诸多设计成为了后续很多编程工具借鉴的模板。
诚然，它臃肿的内存占用，飘忽的产品定价多为人诟病，但综合来看，依然是第一梯队可选项。因为对于 Java 程序员而言，绝大部分日常所处理的都是茫茫代码中的工程决策。Java 在企业级软件开发中的地位，就注定它是代码规模庞大的、多人协作的、承载数年业务知识的。工欲善其事，必先利其器。大模型时代，JetBrains 依然是第一梯队可选项，我的理由是：
- Java 工程需要持续稳定的输出，构建起完备的编程工作流并深入细节，这是一项产品设计能力，和大模型无关
- 限于上下文理解能力与代码之外的推理能力限制，大模型辅助编程依然有局限性，需要有克制的结合
总的来说，Java 领域 IDE 与 AI 的关系更像是是 IDE+AI，而不是 AI+IDE。
这也是为什么在 V0、Devin、Cursor、Windsurf、Github Copilot 这些弄潮儿之外我依然站在 JetBrains 这里的原因（这个是前提，如果抛开 Java，如果有其他编程需要，选择肯定会发生变化）。这一点 Windsurf 可以佐证------Windsurf 的精髓从来不仅仅在于模型本身。尽管模型至关重要，但构建一个模型封装器并非难事。Windsurf 的真正魔力在于：对既有知识的深度语境理解；精心设计的用户体验；独特的功能，如预览模式、一键部署、协同评审；定制化能力，包括工作流引擎、智能规则库、记忆中枢；企业级就绪特性，如与 JetBrains 的智能体级深度集成、混合部署 /FedRAMP 认证的安全架构等，这一切共同构成了 Windsurf 产品的核心价值。
因此目前市面上流行的 Java 编程辅助工具，要么就是基于 VS Code 做魔改，要么就是基于 JetBrains 做插件。前者受限于微软的开源协议，后者受制于 JetBrains 开放的 API 能力，那么没有什么比 JetBrains 自己来开发大模型辅助工具更合适的了。
三、AI Assistant 与 Junie
对于程序员而言，JetBrains AI 的产品特性由两个工具提供，一个是 AI Assistant，一个是 Junie。
很多人初次使用对他们的产品定位很困惑，都有对话和编辑模式，重合度很高。以我来看，Junie 是一个纯粹的 Coding Agent，就是用来完成编码任务的。AI Assistant 更像是一个编程顾问，除了编码还会处理编程环节中其他的事务，比如重构建议、代码翻译、提交信息生成、bug 发现等，用来弥合开发过程中的各种间隙。
如果需要理解代码库，生成 README 或者 Guidelines，可以用 Junie；如果需要项目中的模块代码做重构，或者基于此开发新功能，可以用 Junie；如果想要了解代码中使用的某种开源技术，并生成一些示例程序，可以用 AI Assistant；如果想要对 Git 提交记录分析找到某个功能的修改历史，可以用 AI Assistant。
从两者提供的模式大概也能有所区分，AI Assistant 提供的是 Chat 和 Edit 模式，Junie 提供的则是 Ask 和 Code 模式。也就是说和项目代码更相关的推荐用 Junie，其他的就去找 AI Assistant，当然这也不绝对。
四、程序员与 JetBrains AI 的关系
最后，谈一下人与工具之间的关系------它能帮我们做什么以及如何做得更好，不能帮我们做什么以及如何规避无效工作。
这里直接问了一下 AI Assistant 它自认为的优劣势，对于劣势部分还算比较真诚，尤其是讲到了不能过度依赖可能会导致基础编程能力减弱（手动狗头）。
至于优势部分，它的回答比较客套。
以我目前使用经验来看，JetBrains AI 提供的产品名称比较准确。把 Junie 看成是一个初级开发人员，也可以看做一个实习生，指导分配清晰明了的编码任务，它能够很快很好完成。把 AI Assistant 看成是一个高级编程顾问，在一些认知模糊的领域提供指导意见与发散思路，帮助建立接下来的行动计划。
还要注意的是：
-
Junie 的代码需要检查并理解，在必要的时候仍然需要人工介入，因为大模型的幻觉始终存在，有些任务也不能完全通过对话传递清楚并被 Junie 理解
-
在业务知识传递与技术架构决策的过程中，AI Assistant 几乎帮不上什么忙，这不是 IDE 的领域，因此要格外小心代码结构质量的维护
-
任务拆解的能力被进一步放大了，如果想要 Junie 的工作不被经常返工，做一个任务列表至关重要，不仅任务清晰，还有明确的验收条件表明任务进展