JetBrains Junie /demo：让代码变更自动生成可审查的演示视频
你已经准备好变更，测试也通过了。现在需要有人启动应用、找到正确的界面并检查流程。很多时候，这个人仍然是你，即使有智能体帮忙编写了代码。
这部分也应该能够委托出去。
Junie /demo 是 Junie CLI 中的一种新模式。描述你想检查的内容，Junie 就会构建并启动你的应用，与它的 UI 交互，并记录发生的情况。你会得到一份 HTML 报告、截图，以及可供查看或分享的视频。
有用之处在于，把例行点击从你手头移走，同时让结果保持可检查。由你决定变更是否可以发布。
[LOADING...]
设置 Junie /demo 并运行你的第一次检查
让我们用一个小型问题跟踪器作为示例。你添加了批量状态更新：选择两个 issue，将它们标记为“Done”，然后看到计数器发生变化。你还想检查更新在重新加载后是否仍然保留。
第一次在这个仓库中？启动 Docker，并让 Junie 设置 /demo。它会分析你的项目，并提出构建和启动计划。确认计划后，Junie 会替你填写配置。检查生成的文件，然后运行：
从你的分支、会话、工作树或最后一次提交中选择变更。对于特定检查，在提示词字段中输入请求：
检查提示词，然后让智能体开始工作：
你可以观看实时运行，看它如何在 UI 中操作，并检查它实际做了什么：
带有预期结果的请求会给运行一个明确目标。与明确指出操作、预期状态以及重新加载后应保持的条件相比，“检查该功能”会留下更多解释空间。
说明会随视频一起提供
当你知道自己在看什么时，屏幕录制会容易审查得多。每个演示视频都以一张介绍该演示的幻灯片开始。如果一次运行涵盖多个场景，每个场景都会有各自的介绍幻灯片。最后一张幻灯片会总结结果。
模型会帮助准备这种结构。在后处理期间，它会检查捕获的截图，识别场景，并编写说明幻灯片。在最终视频组装时，这些幻灯片会被添加到录制中。
视频还带有说明字幕，你可以在播放器中打开或关闭。旁白可能会在未来的更新中推出。
HTML 报告将请求、结果、视频和截图汇总在一起。你可以检查运行过的步骤，并查看哪些检查通过、失败或仍未完成。
这对评审者、QA 工程师，或询问某功能如何工作的队友都很有用。我们还在 Junie Live（我们的 Slack 智能体）中试验这一点，以便通过演示来回答合适的功能问题。
给评审者一些可以观看的内容
diff 解释了代码变更。演示则补充了你能看到的行为：打开哪个界面、点击后发生什么变化，以及流程是否达到预期结果。
在 JetBrains 内部，我们将演示智能体连接到了 GitHub Actions。在我们的智能体仓库中，我们已经为超过 1,500 个唯一 PR 运行过它，并创建了超过 2,100 个演示视频。
第一个工作流示例遵循同样的思路。它会检查 PR 是否包含值得演示的行为，如果有就运行演示，并添加一条评论，链接到可用的 artifacts。提示词就在 YAML 中，因此你可以在一个文件里阅读并调整整个示例。
你可以阅读完整的 demo-pr-changes.yml，并将其调整到你的仓库。
当一个变更具有可供操作的界面时，这最有用。例如，后端变更也可以通过现有的 Swagger UI 来演示。价值取决于运行实际能观察到什么。
将可重复的检查移入 CI
我们还使用演示智能体进行发布冒烟测试。我们的内部工作流在推送到发布分支时运行 22 个场景，并为每个场景保留结果和视频。在我们的内部发布分支中，我们已经使用该智能体进行了超过 1,300 次冒烟测试。
第二个示例从小处开始：两个独立场景，由推送或手动运行触发。将提示词替换为你自己的步骤和预期结果。一段被注释掉的 schedule 展示了如何添加定期运行。
你可以阅读完整的 demo-release-tests.yml，并将场景替换为你自己的。
有一个细节值得保留：智能体进程完成并不意味着检查通过。在这个示例中，提示词要求 Junie 写出明确的判定。只有 PASS 才通过结果检查。FAIL、PARTIAL 以及缺失或无效的结果都会使其失败。其他场景仍然可以完成并上传它们的证据。
两个示例都使用 GitHub Artifacts，因此不需要配置单独的视频托管服务。
底层运行机制
演示环境是一个基于 Debian Bookworm 的 Docker 容器。基础镜像包含 Chromium、Node.js、xterm、由 Xvfb 和窗口管理器提供的虚拟桌面，以及截图工具、xdotool 和 ffmpeg。
一个支持 Computer Use 的模型通过点击、按键和截图来驱动应用。你的 Dockerfile 会添加项目依赖；.junie/demo.md 描述其构建和启动步骤。
复杂的仓库可以有多个 VM 模板。对于包含一个后端和多个前端的 monorepo，每个环境都可以在 .junie/vms/ 下拥有自己的 Dockerfile 和自己的启动设置。在 .junie/demo.md 中描述要使用哪个模板、它需要哪些服务，以及如何启动它们。然后 Junie 可以为请求的演示选择合适的环境。
如果当前激活的模型支持 Computer Use 且可用，Junie 会保留它。否则，它会按以下顺序选择第一个可用模型：GPT-5.6 SOL、GPT-6 Astra、GPT-5.5，然后是 GPT-5.4。无论你选择的推理强度级别如何，所有模型在 /demo 中都会以 High 推理强度运行。没有受支持的模型，运行就无法开始。Junie /demo 文档详细介绍了环境和配置。
在 CI 中，可以通过 --demo 使用同一模式：
运行预算
在我们内部的 22 个用例对比中，GPT-5.6 SOL 在我们测量的三个模型中拥有最低的平均时间和成本。
[LOADING...]
完整的一组运行在 SOL 上花费 $19.94。在这些数字所用的订阅换算中，$1 等于一个 AI Credit。这些是我们场景下的内部测量，因此你的应用、构建步骤和提示词都会影响结果。CI runner 的使用需要单独计入预算。
团队还发现，SOL 在这些运行中更快，而且观察到的质量没有明显下降。这一观察来自我们自己的工作负载，也有助于解释这种模型偏好。
一次运行仍然需要几分钟。好处在于，你可以把例行交互交出去，然后回来查看可检查的结果。
在下一次变更中试用
在你的仓库中设置一次 /demo，检查生成的配置，然后从一个小功能或修复开始。对于 CI，先提交该配置，并在复制任一工作流之前添加 JUNIE_API_KEY 仓库密钥。
选择你本来要自己点击检查的变更。让 Junie 演示它，观看输出，并决定哪些地方需要进一步查看。