当整个 AI 编程赛道都在比拼谁的侧边栏聊天更智能、谁的自动补全更快时，JetBrains Research 走出了另一条路。不是让 AI 帮你写代码，而是让 AI 成为代码本身的一部分。
KotlinLLM 是什么
2026 年 7 月 28 日，JetBrains Research 正式开源了 KotlinLLM。这不是又一个 AI 编程助手插件。它是一个 IntelliJ IDEA 插件，但做的事情完全不同：它给 Kotlin 语言增加了一种名为 Smart macros 的语言特性。
所谓 Smart macro，看起来就是一个普通的 Kotlin 函数调用。但它的函数体不是开发者手写的，而是由 LLM 在运行时生成并热重载到 JVM 中的。更关键的是，生成的代码会作为普通 Kotlin 源文件持久化到项目目录中，可以被提交、审查、测试，甚至脱离插件独立运行。
这套 API 极其精简，只有两个核心函数。
asLlm<F, T>(from, hint) 将非结构化或半结构化输入转换为类型安全的 Kotlin 值——数据类、枚举、列表或基本类型。比如把一段自然语言描述转换为结构化的 API URL。mockLlm<T>() 则为接口 T 生成有状态的实现，其行为根据运行时的实际调用模式动态演化，相当于一个不需要手写的智能测试替身。
// 用 asLlm 把自然语言意图转为类型安全的 Kotlin 值
val issuesApiUrl: String = asLlm(repoInput, hint = “GitHub API URL: get all issues, including closed”)
val issues: List<Issue> = asLlm(response, hint = “Return all beginner-friendly issues for this repository”)
这套代码不是每次运行都调用 LLM。它只在第一次遇到未覆盖的场景时触发模型生成实现，随后将生成的代码持久化到项目源文件中。后续运行直接执行编译好的 Kotlin 字节码，零延迟、零成本、完全可复现。
JetBrains 在官方博客中总结了三个核心设计目标。Explicit——调用点明确标注这是 LLM 驱动的行为，代码审查时一目了然。Persistent——生成的行为以普通 Kotlin 源文件保存，可以提交、审查、测试、发布，不会只停留在运行时会话中。Portable——一旦生成，代码无需插件即可独立运行。已覆盖的场景不再产生 LLM 调用，没有额外延迟或成本，结果完全可复现。
从工具到语言：AI 编程范式的第三次跃迁
当前 AI 编程助手的范式可以归为两类。
第一类是开发时辅助。GitHub Copilot、Cursor、Claude Code、Windsurf，它们的工作方式是在你写代码时提供补全、对话或 Agent 式任务执行。这些工具在 2026 年已经高度成熟——Copilot 拥有超过 470 万付费用户，Cursor 估值达到 500 亿美元。但它们的共同特点是：AI 介入的是写代码这个阶段，代码写完后，AI 就退出了。
第二类是运行时外部代理。应用程序在运行时调用 LLM 来完成某些逻辑，比如解析用户输入、生成回复、分类数据。这种方式的问题很明显：每次调用都有延迟和成本，结果非确定，而且应用对 LLM 服务产生了运行时依赖。
KotlinLLM 选择了第三条路——把 AI 生成逻辑嵌入到编程语言的编译运行时循环中。它不是在你写代码时帮忙，而是在代码运行到某个边界时，自动生成实现、编译、热重载，然后继续执行。这个过程对开发者透明，但生成的代码完全可见、可审、可版本化管理。
这种方式在编程语言层面解决了一个根本矛盾：静态类型系统要求确定性，AI 生成天然是非确定性的。KotlinLLM 的做法是将非确定性限制在代码生成阶段，一旦生成完成，结果就是确定性的 Kotlin 源码和字节码。
此前学术界在类似方向上的探索，如 byLLM、nightjar、Healer 等项目，更多针对 Python 这类解释型语言。编译型、静态类型语言的运行时代码演化，在 KotlinLLM 之前几乎没有成熟的工作。JetBrains 选择 Kotlin/JVM 作为突破口，很大程度上是因为 JVM 的 JDI（Java Debug Interface）提供了成熟的类重定义能力，这是实现热重载闭环的基础设施。
技术架构：从 JDI 到热重载的完整闭环
KotlinLLM 的技术架构分为三层。Public API 层是开发者代码中直接调用的 asLlm 和 mockLlm 函数。静态基础设施层负责将 Smart macro 调用路由到生成的 provider 管理器。动态基础设施层则由插件维护的 bootstrap、provider、parser 和 mock 类组成。
运行时流程如下。插件首先扫描 Kotlin 项目，识别所有 asLlm 和 mockLlm 调用。然后创建或更新生成的 bootstrap、provider、parser 和 mock 文件。接着通过 JDI 启动应用，并在生成的 regenerate hook 上注册断点。当执行到达未覆盖的场景时，JDI 挂起线程，插件捕获运行时值和类型信息，调用 LLM agent 生成窄幅实现更新，编译修改后的生成源文件，通过 JDI 的类重定义功能热重载受影响的类，最后恢复执行。
这个闭环的关键在于更新范围是窄幅的。LLM agent 只修改预定义的实现体，而不是任意项目文件。这大大降低了生成代码破坏项目结构的风险。
生成的文件被放置在 com.jetbrains.kotlinllm.generated.core 包下，包括 KotlinLlmBootstrap（将生成 provider 注入管理器）、provider 分发器、asLlm 的 parser 类以及 mockLlm 的实现类。这些全部是普通 Kotlin 源文件，一旦行为被生成，后续相同场景无需再次调用 LLM。
评估数据：100% 热重载与 ~1% 开销
JetBrains 在两项评估中验证了 KotlinLLM 的可行性。
在改编版 Spring Petclinic Kotlin 项目上，团队设置了 18 个 asLlm 调用点，覆盖 24 个应用场景。所有 24 个场景全部完成 Smart macro 演化，热重载成功率 100%，编译和类重定义带来的总运行时开销约 1%。
在 GitHub Issue Radar 项目中，插件在 20 个仓库、超过 30,000 个 issue 的数据集上解析真实 GitHub issue 数据，对初学者友好标签的召回率达到约 0.89。
这些数字表明，对于编译型静态类型语言，运行时持久化代码演化不仅在技术上是可行的，而且性能开销几乎可以忽略不计。当然，这些是研究数据而非生产环境承诺，但它们的精确度足以让行业认真对待这个方向。
JetBrains 在 KotlinConf 2026（5 月 20–22 日，慕尼黑）上做了专题演讲，并公开了完整的理论论文和演讲录像。所有代码以 Apache License 2.0 协议发布在 GitHub 上。
当前局限与未解决的问题
KotlinLLM 目前是一个研究原型，不是生产级产品。它的局限也很明确。
仅支持 Kotlin/JVM——因为依赖 JDI 的类重定义机制，Kotlin Multiplatform 和 Kotlin/Native 暂时无法使用。生成的代码更新范围窄，复杂场景可能需要多次演化才能覆盖全部输入空间。依赖 LLM 生成质量，如果 LLM 生成错误代码，热重载后应用可能进入错误状态。需要 IntelliJ IDEA 插件环境，无法脱离 IDE 独立运行。此外，如何确保多次演化过程中生成的代码不会退化，如何测试 LLM 生成的代码行为，以及如何在不同 LLM 模型之间迁移生成的代码，都是尚未解答的问题。
但作为研究原型，KotlinLLM 的贡献已经超出了它本身能做什么。它提出了一个更本质的问题。
AI 编程的下半场：不是更好的补全，而是更深的嵌入
KotlinLLM 的意涵不只在于它本身能做多少事。它指向了一个更长期的趋势：AI 正在从开发工具向语言特性演进。
过去三年，AI 代码生成工具一直在 IDE 的外围打转——侧边栏聊天、自动补全、代码审查。它们可以帮你写代码，但无法融入代码的运行逻辑。KotlinLLM 的实验表明，LLM 生成的代码可以成为编译运行时循环的一部分，以类型安全、持久化、可热重载的方式嵌入到编程语言中。
如果这个方向被证明可行，未来的编程语言可能不再需要区分编译器生成的代码和 AI 生成的代码。它们都是源代码，都有版本历史，都能被审查和测试。LLM 只是编译器的一个新后端——输入是自然语言意图，输出是 Kotlin。
JetBrains 把 KotlinLLM 以 Apache 2.0 开源，并附带了完整的 KotlinConf 2026 演讲录像和理论论文。现在，任何人都可以下载这个插件，在自己的 Kotlin/JVM 项目上尝试让 Smart macro 在运行时演化。
这门技术还很新。但临界点往往不在爆发时，而在第一个把 LLM 塞进语法的编译器里。
快报