Amper 正式併入 Kotlin Toolchain，Gradle 未來何去何從
最近 Amper 發布了[《*Kotlin Toolchain 0.11: The Next Step for Amper*》](https://link.juejin.cn?target=https%3A%2F%2Fblog.jetbrains.com%2Famper%2F2026%2F06%2Fkotlin-toolchain-0-11%2F) ，核心就是 *Amper has evolved into the Kotlin Toolchain and is now Alpha* ，**也就是 JetBrains 正式把 Amper 併入 Kotlin Toolchain，並且從實驗階段推進到 Alpha** 。感覺就是，JetBrains 想給 Kotlin 生態做一個類似
cargo/dotnet/go那種統一入口。
從 Kotlin Toolchain 0.11 開始，Amper 這個名字在產品定位上就被降級了，核心能力被整體遷移進 Kotlin Toolchain，以後也沒有 amper 命令入口了，全部統一成 kotlin ：
原來的
amper/amper.batwrapper 要替換成新的kotlin/kotlin.batwrapper，IDE 外掛也從 Amper 外掛切換為 Kotlin Toolchain 外掛。
從產品上看，以前 Amper 的定位是「幫你用 YAML 設定 Kotlin/KMP 工程」，而現在變成了 Kotlin Toolchain 的一部分，成了 Kotlin 專案的統一入口，可以透過一個 kotlin 命令建立、建置、執行、測試、發布專案。
JetBrains 之所以這麼做，主要是覺得現在的 Kotlin 生態太割裂了，現在做一個 Kotlin 專案需要處理一堆東西：
Kotlin compiler、Gradle、Kotlin Gradle Plugin、Android Gradle Plugin、Kotlin/Native、Xcode/iOS 產物、Maven 發布、Maven Central 簽章、source set、平台差異設定……
而現在 Kotlin Toolchain 把 Kotlin 的工程入口從 Gradle 腳本、外掛版本、模板碎片，收斂成一個統一的 Kotlin 官方入口，目的就是：
Kotlin 語言很現代，但工程體驗還是 JVM 清朝那一套，改變了很多，卻又像沒變。
所以 0.11 開始 kotlin 就是統一入口了，比如 kotlin build / kotlin run / kotlin test / kotlin publish ，同時全域 kotlin 命令不會強行讓所有專案使用同一個工具鏈版本，它會自動找到專案裡的 wrapper，然後執行相符版本。
另外 0.11 也終於支援發佈 JVM 函式庫到 Maven 儲存庫，包括 Maven Central，Maven Central 之前發佈很麻煩：
sources jar、javadoc jar、PGP 簽章、POM 中繼資料、checksum、deployment bundle 等等，這些東西 Kotlin Toolchain 現在會把這些自動處理掉，你在
module.yaml裡宣告 publishing 設定，然後執行kotlin publish mavenCentral，它就會建置、簽章、打包、上傳並等待 Maven Central 驗證。
不過目前 Kotlin Multiplatform 函式庫還不能發布，KMP library publishing 還在做，暫時只能用在 product: jvm/lib ：
yaml 代码解读复制代码product: jvm/lib
description: A meaningful description for this specific module
settings:
publishing:
enabled: true
group: com.example # the group has to match your Maven Central namespace
version: 1.0.0
# artifactId is optional, and defaults to your module's name
mavenCentral: enabled
signArtifacts: true # automatically sign your artifacts, no external GPG binary required
publishSources: true
pom:
url: https://example.com
scm: https://github.com/my-org/example.git # the SCM connection and dev connection are automatically derived from this
developers:
- name: John Doe
licenses:
- name: MIT
url: https://opensource.org/license/mit其次還有 Cinterop 支援增強，Kotlin Toolchain 現在可以根據模組裡 cinterop 資料夾下的 .def 檔生成 C 函式庫 binding，同時 IDE sync 階段也會生成 binding 並提供輔助。
這個對 KMP / Kotlin Native 很關鍵，因為 Cinterop 如果能被 Toolchain 統一管理，就能減少 Kotlin/Native 工程裡大量手動設定。
同時 0.11 也改善了終端輸出和 IDE 同步，例如：
- library sources 會在 sync 後自動背景下載，這樣 sync 完你可以先開始寫程式，不用等 sources 下載完成
- IDE 外掛的相依性解析從「專案級」對齊為「模組級」，和 CLI 行為一致，以前 IDE 可能給某個模組解析出錯誤的相依版本，或者編輯器警告和 CLI 不一致，現在每個 module 有自己的 resolution scope
核心就是 CLI 和 IDE 行為一致，這也是 Amper / Kotlin Toolchain 的核心價值之一，因為 Gradle 生態長期痛點就是各種：
- 命令列能過，IDE 紅字
- IDE 不紅，CI 掛掉
- 同步慢
- 相依性解析不一致
- source set / target / variant 組合複雜
所以現在 Kotlin Toolchain 如果能把 IDE model 和 build model 做成同一套宣告式結構，對 KMP 會很有價值。
最後 0.11 還增加了幾個外掛開發能力：
checks：外掛可以註冊品質檢查，例如 lint，然後透過kotlin check執行
yaml 代码解读复制代码# my-lint-plugin/plugin.yaml
tasks:
runLinter:
action: !kotlinJavaLint
sources: ${module.kotlinJavaSources}
checks:
- name: lint
performedBy: runLintercommands：外掛可以公開命令，例如kotlin do updateBaseline
yaml 代码解读复制代码# my-lint-plugin/plugin.yaml
tasks:
updateBaseline:
action: !runDetektForBaseline
sources: ${module.kotlinJavaSources}
outputFile: ${module.rootDir}/detekt/baseline.xml
commands:
# shorthand when the name of the command matches that of the task
- updateBaselinegenerated：統一宣告 generated sources、resources、classes、cinterop definitions，取代舊的markOutputAs
yaml 代码解读复制代码tasks:
generateStuff:
action: !myGenerateStuffAction
outputSources: ${taskOutputDir}/src
outputResources: ${taskOutputDir}/res
outputDefFiles: ${taskOutputDir}/cinterop
generated:
sources:
- directory: ${tasks.generateStuff.action.outputSources}
language: kotlin
resources:
- directory: ${tasks.generateStuff.action.outputResources}
cinteropDefinitions:
- directory: ${tasks.generateStuff.action.outputDefFiles}關於這個 JetBrains 還特別強調，這樣的生成物可以被人、AI agent 和其他工具更容易識別。
這一點很有意思，也就是 Kotlin Toolchain 明顯不只是給人寫設定用的，它也在為 AI coding / agent 場景做準備，而 YAML 宣告式設定明顯比 Gradle Kotlin DSL 更容易被工具理解。
Gradle 腳本本質上是可執行程式碼，裡面可以有條件判斷、函式呼叫、動態任務註冊、外掛魔法嗎，這些對 IDE、CI、AI agent 來說都很難靜態分析。
從目前看， Amper 進入 Kotlin Toolchain 之後，也代表著它正式成為未來的主角，kotlin 統一入口也意味著未來 gradlew 等命令會慢慢邊緣化。
短期看 Gradle 還會在，但是現在在 Kotlin-first / KMP-first 的新專案裡，Gradle 的「直接可見度」會被逐步降低。
想想，JetBrains 2023 年介紹 Amper 時還說，Amper 是作為 Gradle plugin 實作的，使用 YAML 做專案設定，目的是先驗證使用者體驗，同時也強調他們會承諾支援 Maven 和 Gradle，不會改變對這些技術的支援。
但是 2026 之後，Amper 就不再和 Gradle 有關係，更多強調的是 “ecosystem doesn’t just need another build tool – it needs a unified entry point into all of Kotlin”，也就是 JetBrains 的已經從「改善 Gradle 設定體驗」的目標，升級成了「建立 Kotlin 官方工具鏈入口」。
所以 0.11 這次不是一個小版本，它同時也是一個訊號： JetBrains 在告訴社群：
Kotlin 不想再只是「語言 + Gradle 外掛」，它已經變成一個完整的工具鏈生態。
連結
blog.jetbrains.com/amper/2026/…
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
