Nuxt Kit Builder 工具详解:扩展 Vite / webpack 配置与构建输出的完整指南
导读
Nuxt 的构建系统建立在 Vite 与 webpack(以及 Rspack)之上,为了让模块作者能够无侵入地介入各类打包器的配置装配过程,Nuxt Kit 提供了一组围绕“构建器(Builder)”的高层工具函数。本文围绕 docs/4.api/5.kit/15.builder.md 展开,系统讲解 extendViteConfig、extendWebpackConfig、addVitePlugin、addWebpackPlugin、addBuildPlugin 与 setBuildOutput 六个 API 的用法、参数语义与底层实现机制。读完本文,你将掌握在 Nuxt 模块中追加 Vite/webpack 插件、修改两类打包器配置、以及注册构建产物(build output)供 Nitro 服务端运行时消费的完整套路,并理解 Nuxt 5+ 中 Vite Environment API 引入的配置作用域变化。
Nuxt 的构建器与 Kit 工具定位
Nuxt 生态中存在三种官方或官方相关构建器:Vite(见 packages/vite)、webpack(见 packages/webpack),以及社区与 Rspack 相关的构建链路。它们各自的完整实现位于 packages 目录,而 Nuxt Kit 的构建工具函数则集中在 packages/kit/src/build.ts,并在 packages/kit/src/index.ts 中统一导出:
export { addBuildPlugin, addVitePlugin, addRspackPlugin, addWebpackPlugin, extendViteConfig, extendRspackConfig, extendWebpackConfig, setBuildOutput } from './build.ts'
export type { ExtendConfigOptions, ExtendViteConfigOptions, ExtendWebpackConfigOptions } from './build.ts'
从用途上可以把这些 API 分为两类:
- 配置扩展类:
extendViteConfig/extendWebpackConfig允许模块读取并原地修改传给对应构建器的配置对象; - 插件注册类:
addVitePlugin/addWebpackPlugin/addBuildPlugin允许模块把插件实例“挂”进最终配置的plugins数组; - 构建产物注册类:
setBuildOutput让构建器(或参与构建的模块)把产物的“提供者”写入nuxt.buildOutputs,供 Nitro 服务端运行时以稳定的nuxt/*子路径导入消费。
所有函数都必须在模块的 setup() 阶段调用(此时 Nuxt 上下文可用),它们内部依赖 useNuxt() 获取当前 Nuxt 实例。
extendViteConfig:扩展 Vite 配置
extendViteConfig 用于扩展传给 Vite 的配置对象。其回调可能被调用多次——当同一份配置同时作用于客户端与服务端构建时(准确地说,取决于你传递的 options)。
基本用法
在模块 setup 中为 optimizeDeps.include 追加依赖项:
import { defineNuxtModule, extendViteConfig } from '@nuxt/kit'
export default defineNuxtModule({
setup () {
extendViteConfig((config) => {
config.optimizeDeps ||= {}
config.optimizeDeps.include ||= []
config.optimizeDeps.include.push('cross-fetch')
})
},
})
类型签名
import type { UserConfig as ViteConfig } from 'vite'
import type { ExtendViteConfigOptions } from '@nuxt/kit'
function extendViteConfig (callback: ((config: ViteConfig) => void), options?: ExtendViteConfigOptions): void
参数说明
| Property | Type | Required | Description |
|---|---|---|---|
dev |
boolean |
false |
若设为 true,开发模式下构建时会调用回调函数。默认来自源码 ExtendConfigOptions 中的 @default true,即默认在开发与生产构建都会生效;显式传 false 会在开发模式下跳过。 |
build |
boolean |
false |
若设为 true,生产构建时会调用回调函数;传 false 则在生产构建时跳过。 |
server |
boolean |
false |
若设为 true,构建服务端 bundle 时调用回调。Nuxt 5+ 已弃用,改用 addVitePlugin() 配合 applyToEnvironment()。 |
client |
boolean |
false |
若设为 true,构建客户端 bundle 时调用回调。Nuxt 5+ 已弃用,改用 addVitePlugin() 配合 applyToEnvironment()。 |
prepend |
boolean |
false |
若设为 true,回调以 unshift() 方式前置追加到数组中,而非默认的 push() 追加(该选项实际作用于插件数组的插入顺序)。 |
关于
dev/build的默认语义:结合 packages/kit/src/build.ts 的ExtendConfigOptions源码可知,dev、build、server、client四个布尔开关的默认值均为true(即默认在所有模式、所有端生效)。dev: false/build: false会让函数在对应模式下提前返回、跳过注册。
弃用警告:文档明确提示
extendViteConfig已经弃用,官方推荐改用 Vite 插件(plugin)形态并实现config钩子;如果需要按环境(environment)做差异化配置,则使用applyToEnvironment钩子(详见下文addVitePlugin一节)。
Nuxt 5+ 的推荐替代写法
针对 Nuxt 5+ 的环境级配置,官方推荐直接改用 addVitePlugin():
import { addVitePlugin, defineNuxtModule } from '@nuxt/kit'
export default defineNuxtModule({
setup () {
// 全局配置(影响所有环境)
addVitePlugin(() => ({
name: 'my-global-plugin',
config (config) {
// 该钩子在环境装配之前运行,修改的是全局配置
config.optimizeDeps ||= {}
config.optimizeDeps.include ||= []
config.optimizeDeps.include.push('cross-fetch')
},
}))
// 按环境做差异化配置
addVitePlugin(() => ({
name: 'my-client-plugin',
applyToEnvironment (environment) {
return environment.name === 'client'
},
configEnvironment (name, config) {
// 仅影响 client 环境
config.optimizeDeps ||= {}
config.optimizeDeps.include ||= []
config.optimizeDeps.include.push('client-only-package')
},
}))
},
})
执行顺序要点:config 钩子先于 applyToEnvironment 运行,且修改的是全局配置;需要环境级差异时请用 configEnvironment。这是 Nuxt 5+ 采用 Vite Environment API 之后的关键变化。
底层实现原理
从源码看,extendViteConfig 的实现非常轻量(packages/kit/src/build.ts):
export function extendViteConfig (fn, options = {}) {
const nuxt = useNuxt()
if (options.dev === false && nuxt.options.dev) { return }
if (options.build === false && nuxt.options.build) { return }
// 若显式只针对 server/client,会向调用者打印弃用警告
// ...
// fn() 只被调用一次
return nuxt.hook('vite:extend', ({ config }) => fn(config))
}
关键事实:
- 回调挂在
vite:extend钩子上。该钩子由 Vite 构建器的 packages/vite/src/vite.ts 在完整ViteConfig装配完成后触发一次(await nuxt.callHook('vite:extend', ctx))。 - 从源码注释(
Call fn() only once)可以看出,Vite 分支不再像 webpack 那样为 client/server 各调一次——因为 Nuxt 5+ 的 Vite Environment API 让client与ssr环境共享同一份基础配置,环境级差异交给插件钩子处理。因此文档中“回调可能被调用多次”的描述主要针对旧版行为与 webpack 场景。 - 当你显式传入
server: false或client: false时,Kit 会通过getUserCaller()找到调用点并打印形如[@nuxt/kit] calling extendViteConfig with only server/client environment is deprecated...的弃用警告,提示改用 Vite 插件方案。
extendWebpackConfig:扩展 webpack 配置
extendWebpackConfig 用于扩展 webpack 配置。与 Vite 分支不同,webpack 的 client 与 server 是两份独立命名配置,因此回调默认会被调用多次(分别针对 server 与 client 构建)。
基本用法
为 webpack 追加一条 raw-loader 规则,用于导入 .txt 文件:
import { defineNuxtModule, extendWebpackConfig } from '@nuxt/kit'
export default defineNuxtModule({
setup () {
extendWebpackConfig((config) => {
config.module!.rules!.push({
test: /\.txt$/,
use: 'raw-loader',
})
})
},
})
类型签名
import type { Configuration as WebpackConfig } from 'webpack'
import type { ExtendWebpackConfigOptions } from '@nuxt/kit'
function extendWebpackConfig (callback: ((config: WebpackConfig) => void), options?: ExtendWebpackConfigOptions): void
参数说明
| Property | Type | Required | Description |
|---|---|---|---|
dev |
boolean |
false |
若设为 true,开发模式构建时调用回调;false 则在开发模式跳过。 |
build |
boolean |
false |
若设为 true,生产构建时调用回调;false 则在生产构建跳过。 |
server |
boolean |
false |
若设为 true,构建 server bundle 时调用回调。 |
client |
boolean |
false |
若设为 true,构建 client bundle 时调用回调。 |
prepend |
boolean |
false |
若设为 true,回调以 unshift() 方式前置追加,而非默认 push()。 |
底层实现原理
extendWebpackConfig 与 extendRspackConfig 实际共享同一个工厂函数 extendWebpackCompatibleConfig(packages/kit/src/build.ts):
const extendWebpackCompatibleConfig = (builder: 'rspack' | 'webpack') => (fn, options = {}) => {
const nuxt = useNuxt()
if (options.dev === false && nuxt.options.dev) { return }
if (options.build === false && nuxt.options.build) { return }
nuxt.hook(`${builder}:config`, async (configs) => {
if (options.server !== false) {
const config = configs.find(i => i.name === 'server')
if (config) { await fn(config) }
}
if (options.client !== false) {
const config = configs.find(i => i.name === 'client')
if (config) { await fn(config) }
}
})
}
由此可确认的实现事实:
- 回调注册在
webpack:config(或rspack:config)钩子上。Nuxt 服务端运行时在 packages/nitro-server/src/index.ts 处统一回调webpack:config与rspack:config钩子,钩子类型定义见 packages/schema/src/types/hooks.ts。 - 回调并非对整份配置数组调用一次,而是从
configs数组中按name === 'server'/name === 'client'查找命名配置并分别调用。默认情况下(server、client均未显式关闭)同一个回调会被执行两次,这正是文档“callback function can be called multiple times”的来源。如果你只需要修改某一端,务必传入{ server: false }或{ client: false }。 - webpack 配置对象可能是
Promise形式的结果,回调函数支持async(await fn(config)),因此返回值为Thenable<void>也是允许的。
addVitePlugin:追加 Vite 插件
addVitePlugin 把插件实例追加进 Vite 配置。它是 Nuxt 5+ 环境中做配置扩展的首选入口。
基本用法
模块化地接入 SVG 图标插件:
import { addVitePlugin, defineNuxtModule } from '@nuxt/kit'
import { svg4VuePlugin } from 'vite-plugin-svg4vue'
export default defineNuxtModule({
meta: {
name: 'nuxt-svg-icons',
configKey: 'nuxtSvgIcons',
},
defaults: {
svg4vue: {
assetsDirName: 'assets/icons',
},
},
setup (options) {
addVitePlugin(svg4VuePlugin(options.svg4vue))
// 或者:只把插件加到某一个环境
addVitePlugin(() => ({
name: 'my-client-plugin',
applyToEnvironment (environment) {
return environment.name === 'client'
},
// ... 其余仅客户端生效的插件逻辑
}))
},
})
类型签名
pluginOrGetter 同时接受插件实例、插件实例数组,或返回这两者的(可异步)函数:
import type { Plugin as VitePlugin } from 'vite'
import type { ExtendViteConfigOptions } from '@nuxt/kit'
function addVitePlugin (pluginOrGetter: VitePlugin | VitePlugin[] | (() => VitePlugin | VitePlugin[]), options?: ExtendViteConfigOptions): void
参数说明
pluginOrGetter:Vite 插件实例,或插件实例数组。若传入函数,则该函数必须返回插件实例或插件实例数组;函数也可以是 async 的(返回 Promise)——这一点对“懒加载”插件特别有用:只有真正执行构建时才会 import 插件模块,避免模块加载阶段不必要的开销与副作用:
import { addVitePlugin, defineNuxtModule } from '@nuxt/kit'
export default defineNuxtModule({
setup () {
// 懒加载插件——只在构建真正执行时才 import
addVitePlugin(() => import('my-vite-plugin').then(r => r.default()))
},
})
options:与 extendViteConfig 相同的 ExtendViteConfigOptions:
| Property | Type | Required | Description |
|---|---|---|---|
dev |
boolean |
false |
true 表示开发模式构建时安装插件。 |
build |
boolean |
false |
true 表示生产构建时安装插件。 |
server |
boolean |
false |
true 表示在 server bundle 安装插件。Nuxt 5+ 弃用,改用 applyToEnvironment()。 |
client |
boolean |
false |
true 表示在 client bundle 安装插件。Nuxt 5+ 弃用,改用 applyToEnvironment()。 |
prepend |
boolean |
false |
true 表示用 unshift() 前置插入插件数组,而非默认 push() 追加。 |
底层实现与 Nuxt 5+ 环境 API
源码实现(packages/kit/src/build.ts)展示了 Nuxt 5+ 的两个关键分支:
- 判断是否为“同构”插件:
const isIsomorphic = options.server !== false && options.client !== false。未显式关闭任何一端时,插件被视为同构插件,直接以顶层插件追加进config.plugins。 - 环境 API 感知:若 Vite 配置尚未使用 Environment API(不存在
config.environments?.ssr与config.environments.client),则非同构插件被标记为needsEnvInjection,改由每个环境逐个触发的vite:extendConfig钩子注入(该钩子在 packages/vite/src/vite.ts 中按client/ssr循环触发);若已启用 Environment API,则通过scopeToEnvironments包装插件:- 为插件补上
applyToEnvironment(environment):当isAllowed判定环境不属于该插件作用域时返回false,否则调用插件自身的applyToEnvironment(若存在); - 为插件推导默认
enforce:同构插件仅在prepend时取'pre',否则保持不指定;按端区分的插件在prepend时取'pre',否则取'post'。 - 包装插件仍然作为顶层插件返回,而不是嵌套在包装器内,这样 Vite 仍会正常执行
apply、按enforce排序、调用configureServer等服务器级钩子,并暴露插件声明的其它属性(如api)。
- 为插件补上
这意味着:在 Nuxt 5+,用 server: false 或 client: false 注册的插件,其 config / configResolved 钩子不会再被调用;如需按环境生效,应使用 applyToEnvironment() 方法编写插件。
addWebpackPlugin:追加 webpack 插件
addWebpackPlugin 把插件实例追加到 webpack 配置的 plugins 数组中,通常配合构建时 lint、代码分析等场景使用。
基本用法
一个把 eslint-webpack-plugin 接入 Nuxt 的模块示例(客户端构建生效、生产/开发默认均启用):
import EslintWebpackPlugin from 'eslint-webpack-plugin'
import { addWebpackPlugin, defineNuxtModule } from '@nuxt/kit'
export default defineNuxtModule({
meta: {
name: 'nuxt-eslint',
configKey: 'eslint',
},
defaults: nuxt => ({
include: [`${nuxt.options.srcDir}/**/*.{js,jsx,ts,tsx,vue}`],
lintOnStart: true,
}),
setup (options, nuxt) {
const webpackOptions = {
...options,
context: nuxt.options.srcDir,
files: options.include,
lintDirtyModulesOnly: !options.lintOnStart,
}
addWebpackPlugin(new EslintWebpackPlugin(webpackOptions), { server: false })
},
})
类型签名
import type { WebpackPluginInstance } from 'webpack'
import type { ExtendWebpackConfigOptions } from '@nuxt/kit'
function addWebpackPlugin (pluginOrGetter: WebpackPluginInstance | WebpackPluginInstance[] | (() => WebpackPluginInstance | WebpackPluginInstance[]), options?: ExtendWebpackConfigOptions): void
参数说明
pluginOrGetter:webpack 插件实例或实例数组;也可传函数,函数须返回插件实例或数组,且可以是 async(返回 Promise),从而支持插件的懒加载。
options:完整的 ExtendWebpackConfigOptions(webpack 分支的 server/client 未弃用):
| Property | Type | Required | Description |
|---|---|---|---|
dev |
boolean |
false |
true 表示开发模式构建时安装插件。 |
build |
boolean |
false |
true 表示生产构建时安装插件。 |
server |
boolean |
false |
true 表示在 server bundle 安装插件。 |
client |
boolean |
false |
true 表示在 client bundle 安装插件。 |
prepend |
boolean |
false |
true 表示用 unshift() 前置插入插件数组,而非默认 push() 追加。 |
底层实现原理
源码(packages/kit/src/build.ts)内部即是对 extendWebpackConfig 的封装:
export function addWebpackPlugin (pluginOrGetter, options) {
extendWebpackConfig(async (config) => {
const method = options?.prepend ? 'unshift' : 'push'
const plugin = typeof pluginOrGetter === 'function' ? await pluginOrGetter() : pluginOrGetter
config.plugins ||= []
config.pluginsmethod)
}, options)
}
要点:函数形态的 pluginOrGetter 会被 await,实现懒求值;得到的插件通过 toArray 归一为数组后一次性展开追加/前置。因底层复用 extendWebpackConfig,插件同样默认会被同时安装到 server 与 client 两份配置中,如示例所示通常需要显式传 { server: false } 来限定作用端。
addBuildPlugin:构建器无关的插件注册
addBuildPlugin 是 addVitePlugin 与 addWebpackPlugin(以及 Rspack 链路)的构建器无关版本:向它传入一个工厂,它会自动把对应构建器的插件分发给当前存在的 Vite / webpack / Rspack 配置——前提是这些构建器确实被启用。
类型签名
import type { ExtendConfigOptions } from '@nuxt/kit'
import type { Plugin as VitePlugin } from 'vite'
import type { WebpackPluginInstance } from 'webpack'
import type { RspackPluginInstance } from '@rspack/core'
interface AddBuildPluginFactory {
vite?: () => VitePlugin | VitePlugin[]
webpack?: () => WebpackPluginInstance | WebpackPluginInstance[]
rspack?: () => RspackPluginInstance | RspackPluginInstance[]
}
function addBuildPlugin (pluginFactory: AddBuildPluginFactory, options?: ExtendConfigOptions): void
参数说明
pluginFactory:一个返回对象工厂,对象的 vite 与/或 webpack(及 rspack)属性必须是函数,各自返回对应构建器的插件实例或实例数组。
options:ExtendConfigOptions:
| Property | Type | Required | Description |
|---|---|---|---|
dev |
boolean |
false |
true 表示开发模式构建时安装。 |
build |
boolean |
false |
true 表示生产构建时安装。 |
server |
boolean |
false |
true 表示在 server bundle 安装。 |
client |
boolean |
false |
true 表示在 client bundle 安装。 |
prepend |
boolean |
false |
true 表示用 unshift() 前置插入插件数组。 |
底层实现原理
源码(packages/kit/src/build.ts)极为直白——工厂里声明了哪个构建器,就分发给哪个构建器:
export function addBuildPlugin (pluginFactory, options) {
if (pluginFactory.vite) { addVitePlugin(pluginFactory.vite, options) }
if (pluginFactory.webpack) { addWebpackPlugin(pluginFactory.webpack, options) }
if (pluginFactory.rspack) { addRspackPlugin(pluginFactory.rspack, options) }
}
它的价值在于:如果你的模块希望同时兼容使用 Vite、webpack 或 Rspack 的 Nuxt 项目,只需写一次注册逻辑,Kit 会按实际启用的构建器自动分发。注意 addVitePlugin 收到的 options 语义受上一节所述的环境 API 行为约束。
setBuildOutput:注册构建产物
setBuildOutput 为给定 key 设置一个“构建产物提供者”。构建产物是构建器(Vite、webpack、Rspack 或自定义构建器)与 Nitro 服务端运行时之间的契约:每个 key 对应一个 nuxt/* 子路径导入,服务端运行时在构建期解析它。它通常由构建器内部调用,或由参与构建过程的模块调用。关于这套契约的完整机制,参见 docs/3.guide/6.going-further/8.builders.md(原文以 /docs/4.x/guide/going-further/builders 链接指向的“build output contract”小节)。
类型签名
import type { NuxtBuildOutputs } from '@nuxt/schema'
function setBuildOutput<K extends keyof NuxtBuildOutputs> (key: K, provider: NuxtBuildOutputs[K]): void
参数说明
key:构建产物键,取值于 NuxtBuildOutputs 的键集合:serverEntry、clientManifest、clientPrecomputed、ssrStyles、entryChunkName、entryIds 之一。
provider:对应 key 的值——一个(可异步的)函数,返回模块内容(string),在服务端构建解析对应的 nuxt/* 导入时被惰性读取(lazily read)。
完整示例
import { setBuildOutput } from '@nuxt/kit'
// 通过绝对 specifier 重新导出构建好的 SSR entry
setBuildOutput('serverEntry', () => `export { default } from ${JSON.stringify(serverEntryURL)}`)
// 提供序列化后的 client manifest
setBuildOutput('clientManifest', () => `export default ${serializedManifest}`)
// 重新导出按组件生成的样式映射,供 `nuxt/styles` 使用
setBuildOutput('ssrStyles', () => `export { default } from ${JSON.stringify(pathToFileURL(resolve(serverDir, 'styles.mjs')).href)}`)
底层实现与契约细节
从 packages/schema/src/types/nuxt.ts 可以看到 NuxtBuildOutputs 的完整定义,其中每个 key 都被注释说明了消费方:
serverEntry:模块体重新导出 SSR app 入口,服务端运行时经nuxt/entry子路径拿到createRenderer所需的 SSR app factory;ssrStyles:按组件划分的 SSR 内联样式映射模块体,并含inlinedCSS具名导出——把渲染时可能被丢弃<link>的每个已输出 CSS 文件映射到“内联了其内容的模块 ID 分组”,默认两者均为空映射;运行时经nuxt/styles解析;clientManifest:供vue-bundle-renderer使用的序列化客户端 manifest;clientPrecomputed:供vue-bundle-renderer使用的序列化预计算客户端依赖数据;entryChunkName:导出“带 hash 的入口 chunk 文件名”的模块体,用于 import maps;entryIds:导出入口模块 ID 的模块体,用于内联样式提取。
setBuildOutput 的源码实现(packages/kit/src/build.ts)非常简洁,就是把 provider 写入当前 Nuxt 实例的 nuxt.buildOutputs[key]:
export function setBuildOutput<K extends keyof NuxtBuildOutputs> (key: K, provider: NuxtBuildOutputs[K], nuxt: Nuxt = useNuxt()): void {
nuxt.buildOutputs[key] = provider
}
在消费侧,Nitro 服务端运行时会把 nuxt.buildOutputs 作为 nuxt/* 虚拟模块的来源。例如 packages/nitro-server/src/index.ts 里保留了默认的构建产物并提供给 nuxt/entry-chunk、nuxt/entry-ids 等,同文件第 571 行则用 nitroConfig.virtual![specifier] = () => nuxt.buildOutputs[key]() 把用户构建器注册的产物注入虚拟模块。由于 provider 是惰性函数,产物内容(例如 SSR entry 的路径、manifest 数据)只在实际构建解析 nuxt/* 导入时才被读取,这为构建器提供了在构建流程中“随时”填充产物的灵活性。
不常用到的 key 不必全部提供:例如 SSR 被禁用时 serverEntry 的默认值就是 no-op app,其它多数输出也不会被消费;只提供你的构建器真实产出的 key 即可。这与构建输出契约文档中“defaults are sensible… provide only what your build produces”的指导一致。
小结与选型建议
| API | 用途 | 作用构建器 | Nuxt 5+ 注意事项 |
|---|---|---|---|
extendViteConfig |
原地修改 Vite 配置对象 | Vite | 已弃用;推荐改用 Vite 插件的 config 钩子 |
extendWebpackConfig |
原地修改 webpack 配置对象(server/client 各调一次) | webpack | 无环境 API 问题,server/client 选项仍有效 |
addVitePlugin |
追加 Vite 插件(支持懒加载) | Vite | server:false/client:false 下 config 钩子不再触发;按环境请用 applyToEnvironment |
addWebpackPlugin |
追加 webpack 插件(支持懒加载) | webpack | 注意默认会同时作用于 server 与 client |
addBuildPlugin |
同时向 Vite/webpack/Rspack 分发插件 | 多构建器 | 是编写跨构建器模块的首选入口 |
setBuildOutput |
注册 nuxt/* 构建产物 provider |
全部(含自定义构建器) | 是构建器与 Nitro 服务端运行时之间契约的核心 |
实际编写模块时的两条核心经验:
- 新代码优先走插件化路线:在 Nuxt 5+,凡是想修改 Vite 配置的地方,优先用
addVitePlugin配合插件的config/configEnvironment/applyToEnvironment钩子,而不是直接调用extendViteConfig——后者面向旧版共享配置模型的server/client区分已经弃用并会打印警告。 - 跨构建器模块用
addBuildPlugin:如果你无法预知使用方项目用的是 Vite 还是 webpack/Rspack,写一份AddBuildPluginFactory即可覆盖三种构建器;再配合setBuildOutput参与到构建产物契约中,模块就能与 Nuxt 的构建管线深度集成。
所有 API 的类型与导出声明可在 packages/kit/src/index.ts 及 packages/kit/src/build.ts 中直接查阅,模块开发的基础流程可参考 docs/3.guide/4.modules/1.getting-started.md。
atomcodeClaude Code 的开源替代方案。连接任意大模型,编辑代码,运行命令,自动验证 — 全自动执行。用 Rust 构建,极致性能。 | An open-source alternative to Claude Code. Connect any LLM, edit code, run commands, and verify changes — autonomously. Built in Rust for speed. Get StartedRust0629
MiniCPM5-2BMiniCPM5-2B 是一款面向端侧、本地部署和资源受限场景的 2B 稠密 Transformer,能够达到同尺寸开源模型 SOTA 水平。Markdown00
GLM-5.3GLM-5.3 与 GLM-5.2 使用相同的基座模型——所有提升均来自后训练。与 GLM-5.2 相比,它在复杂编程和长程任务上的表现显著提升。Jinja00
HivisionIDPhotos⚡️HivisionIDPhotos: a lightweight and efficient AI ID photos tools. 一个轻量级的AI证件照制作算法。Python07
DragonOSDragonOS is an operating system developed from scratch using Rust, with Linux compatibility. It is designed for **Serverless** scenarios. 使用Rust从0自研内核,具有Linux兼容性的操作系统,面向云计算Serverless场景而设计。Rust00
Spark-X2.5-1.7BSpark-X2.5-1.7B 旨在让强大的 AI 更加实用、高效且易于获取。这些模型在广泛的日常任务中表现出色,涵盖对话、写作、翻译、推理、编程、工具调用和智能体工作流,并在同等规模的开源模型中取得领先结果。Spark-X2.5 将面向效率的架构与最高 1M tokens 的原生上下文窗口相结合,并支持 200 多种语言。Python00