JetBrains Junie：一个移动端工程师的 AI Agent 实战手记

《AI Agent如何改变移动端开发：从上下文缺失到高效协作》文章讲述了AI工具从初期低效到深度集成IDE的进化历程。作者以JetBrains Junie为例，展示了AI Agent如何通过“计划-执行-校验”工作流自主获取项目上下文，解决传统网页版AI需要手动复制粘贴代码的痛点。重点介绍了Ask模式（技术咨询）和Code模式（自动化编码）的应用场景，以及通过左右互搏式Fact-Check验证A

fundroid

488人浏览 · 2026-04-16 08:30:00

fundroid · 2026-04-16 08:30:00 发布

在这里插入图片描述

自从 AI 这个“外星物种”闯入我们的世界，说实话，我跟大伙儿一样，经历了一系列复杂的心情变化：从一开始的“哇塞牛逼”，到中间的“就这？还得我来给你擦屁股”，再到现在的“嗯，有点意思，好像能用了”。

一开始，我和我的 Android Studio、我的 Kotlin 代码，与 ChatGPT、Claude 这些网页版 AI 工具之间，隔着一道无法逾越的鸿沟——上下文（Context）。

每次我想让它帮我解决一个稍微复杂点的问题，比如分析一个 Crash、重构一段屎山代码，都感觉像是在教一个只有七秒记忆的实习生干活。我得吭哧吭哧地把 ViewModel、Repository、build.gradle.kts 等一堆文件复制粘贴过去，还得时刻担心别超过它那点可怜的“上下文窗口”。结果往往是，它给的建议牛头不对马嘴，因为它根本不知道我项目里用了哪些奇奇怪怪的内部库，或者某个 Composable 函数背后藏着多深的业务逻辑。

这种感觉，就像你想让一个顶级大厨帮你炒个菜，但他既没有你的厨房，也不知道你的冰箱里有啥食材，只能凭空给你念菜谱。太低效了！

直到我下定决心，把一个“更懂我”的家伙——一个深度集成在 IDE 里的 AI 代理（AI Agent），正儿八经地“踹”进了我的项目里。今天，我就以一个移动端工程师的第一视角，聊聊 JetBrains 推出的 Junie 这个 AI Agent，是怎么改变我日常搬砖姿势的。

上下文，上下文，还是 XX 的上下文！

AI Agent 和网页聊天 AI 最大的区别在哪？一言以蔽之：它“活”在你的项目里，能自己找上下文。

这听起来有点玄乎，但工作流其实非常直白且高效。当我给 Junie 下达一个指令，比如“我想把这个项目重构成多模块架构，你觉得靠谱吗？”之后，它并不会像个小白一样两手一摊等我喂代码。相反，它会上演一套漂亮的“计划-执行-校验”三连：

分析与计划（Plan）：它首先会解析我的自然语言指令，然后自己琢磨：“要回答这个问题，我需要了解这个项目的哪些信息？” 接着，它会生成一个清晰的执行计划，比如“我要先看看项目的文件结构，再分析一下 build.gradle.kts，最后检查一下代码的分层情况。”
执行（Execute）：计划定好后，它会把这些步骤翻译成一系列终端命令（比如 ls -R, grep, cat），在后台默默执行，精准地从我那庞大如山的代码库里，把最关键的几个文件给捞出来。
校验与回答（Verify & Answer）：它只把这些高度相关的代码片段作为上下文，连同我的问题一起，发给背后真正干活的主流推理模型（比如 GPT 或 Claude 系列）。拿到答案后，它还会结合上下文进行校验，最终给我一个高度定制化、贴合我项目实际的分析报告。

整个过程，我就像个产品经理，提了个需求；而 Junie 则像个经验丰富的老鸟，自己拉齐信息、分析现状、给出方案。这种感觉，跟对着网页版 AI “复制粘贴”相比，简直是降维打击。

Ask 还是 Code？这是一个问题

在 IDE 里，Junie 提供了两种核心工作模式：Ask（提问） 和 Code（编码）。这恰好对应了我们在开发中需要 AI 扮演的两个核心角色：技术导师和初级工程师。

Ask 模式：我的 7x24 小时技术顾问

作为开发者，我们总会遇到拿不准的技术选型。比如，在我的一个 Compose Multiplatform 项目里，所有的代码都挤在一个模块里，我想知道迁移到**多模块架构（multi-module architecture）**是否明智。

我直接在 Junie 的 Ask 模式下问了这个问题。几秒钟后，它不仅告诉我迁移的好处（比如改善编译速度、明确模块边界），还根据我项目里的代码，给出了具体的模块拆分建议，比如可以拆分出 feature-book、core-network、data-repository 等模块，甚至还提供了一份可行的迁移步骤指南。

这还没完。我们都知道，AI 会一本正经地胡说八道。为了避免被它带到沟里，我发明了一套“左右互搏”的 **Fact-Check（事实核查）**方法论：

把 Junie（比如用 GPT-4 模型）给我的第一份答案完整复制下来。
在 IDE 里新开一个聊天窗口（这会开启一个无历史记录的全新会话）。
（可选但推荐）在设置里，把后端模型切换成另一个，比如 Claude 3 Opus。
把刚才的答案粘贴进去，然后问：“嘿，哥们，有人给了我这么个方案，你帮忙审审，靠谱不？有没有啥坑？”

通过这种方式，我相当于雇了第二个 AI 专家来审查第一个专家的工作。它们可能会互相认可，也可能会暴露出对方没考虑到的小细节或边界情况。多来回几次，一个技术点的认知盲区就被扫得七七八八了。这比自己吭哧吭哧地看一个礼拜博客和文档，效率高到不知道哪里去了。

Code 模式：让它去干那些“体力活”

当然，光说不练假把式。AI Agent 最让我爽到的，还是它的 Code 模式。

我给自己定了个原则：

交给 AI 的：中等复杂度、有明确模式、涉及大量**样板代码（boilerplate code）**的任务。比如，给 RecyclerView 写个 Adapter、添加一个新的网络请求、或者……实现响应式布局适配。
不交给 AI 的：高度复杂的业务逻辑、伤筋动骨的架构大改。这类任务，我会先用 Ask 模式跟它“头脑风暴”，拿个初步策略，然后由我这个“人类架构师”亲自操刀。

接下来，就是见证奇迹的时刻。

一个响应式页面的真实落地

这是我们移动端开发最经典的场景之一：让一个界面在手机竖屏、横屏、甚至平板上都看起来“像个人样”。

我的任务是：为一个已有的 Compose 图书详情页，创建一个横屏状态下的两列布局——左边是书的封面，右边是书的详细信息。

我没动手写一行代码，而是打开 Junie 的 Code 模式，给了它一段精心设计的 Prompt：

“为图书详情页创建一个优化的横屏布局，左侧显示书籍封面，右侧显示书籍详情。请使用 WindowSizeClass 来获取屏幕尺寸。”

这个 Prompt 写得很讲究：目标明确（横屏布局），布局清晰（左封面、右详情），技术方案具体（用 WindowSizeClass）。

然后，我点击“执行”，去泡了杯咖啡。回来时，Junie 已经提交了它的“工作成果”：

自动添加依赖：它检查了我的 build.gradle.kts，发现没有 androidx.compose.material3:material3-window-size-class 依赖，然后自己动手给加上了！就冲这一点，我就想给它点个赞。

生成布局逻辑：它在我的 Composable 函数里，加入了 calculateWindowSizeClass()，然后用一个 when 表达式判断当前的宽度是 WindowWidthSizeClass.Compact（紧凑，通常是竖屏）还是其他（中等或展开）。

@Composable
fun BookDetailScreen(book: Book) {
    val windowSizeClass = calculateWindowSizeClass()

    when (windowSizeClass.widthSizeClass) {
        WindowWidthSizeClass.Compact -> {
            // 默认的竖屏布局...
            PortraitLayout(book) 
        }
        else -> {
            // 新生成的横屏布局...
            LandscapeLayout(book)
        }
    }
}

创建新布局：它把原有的垂直布局代码抽离到了 PortraitLayout，然后新建了一个 LandscapeLayout Composable，用一个 Row 来实现左右两列的布局，甚至还贴心地给右侧的内容加上了滚动。
提供 Diff 供审查：所有改动都以清晰的 Diff 形式展示给我，我可以逐行审查。如果不满意，一键就能“全部回滚”，安全感满满。