mise GitHub Backend 完全指南从 GitHub Release 资产直装预编译工具【免费下载链接】misedev tools, env vars, task runner项目地址: https://gitcode.com/GitHub_Trending/mi/misemise 的githubbackend 允许你直接从 GitHub 仓库的 Release 资产安装预编译工具无需经过 asdf 插件或自建脚本。本文以 docs/dev-tools/backends/github.md 为核心结合 src/backend/github.rs 与 src/backend/asset_matcher.rs 的源码实现系统讲解githubbackend 的使用方法、版本列出的过滤逻辑、全部工具选项asset_pattern、matching、rename_exe、bin_path、checksum、prerelease等以及面向 GitHub Enterprise 的自托管配置帮助你精确掌控预编译二进制的选择、下载、校验与安装全流程。GitHub Backend 是什么githubbackend 是 mise 众多安装后端之一与gitlab、forgejo、aqua、ubi、asdf等并列完整列表见 docs/dev-tools/backends。它直接对接 GitHub Releases API把某个仓库 Release 中上传的构建资产下载并安装为可执行工具。适用场景上游仓库通过 GitHub Releases 分发预编译二进制如ripgrep、gh、ollama但没有发布 mise registry 条目或你希望绕过 registry 直接指定仓库。核心实现源码中 GitHub、GitLab、Forgejo 三个后端共用同一个UnifiedGitBackend结构src/backend/github.rs通过BackendType区分三者get_type因此本文的资产匹配、校验、安装逻辑对三者大多同样适用只是 API 端点与个别选项行为不同。安装来源mise 只从 Release 的上传资产assets中安装绝不回退到 GitHub 自动生成的源码压缩包。这一点同时决定了版本列表的过滤规则见下文「版本列出」一节。快速上手在项目中使用githubbackend 安装 ripgrepmise use github:BurntSushi/ripgrep mise exec -- rg --versionmise use会把工具写入当前项目的mise.toml。加上-g参数则写入全局配置[tools] github:BurntSushi/ripgrep latest接下来可以查看可选版本mise ls-remote github:BurntSushi/ripgrep安装指定版本mise use github:BurntSushi/ripgrepVERSION将VERSION替换为列表中的条目遇到 GitHub API 限流或需要访问私有仓库的 Release 时参见 docs/dev-tools/github-tokens.md 配置 token。mise 的 token 解析顺序github.com 上从MISE_GITHUB_TOKEN环境变量开始到git credential fill收尾详见该文档本文不再展开。版本列出为什么无资产的 Release 会被跳过mise ls-remote列出仓库的 Release。没有任何资产的 Release 会被剔除mise 只从 Release 的上传资产安装绝不回退到自动生成的源码压缩包因此这种 Release 没有任何可安装来源列出它等于广告一个必然安装失败的版本。源码中对应逻辑是 github_release_has_assetsfn github_release_has_assets(release: github::GithubRelease) - bool { !release.assets.is_empty() }在版本列出时_list_remote_versions它作为过滤条件之一作用于每个 Release.filter(|r| skip_asset_check || github_release_has_assets(r))同时/releases/latest快捷端点也做了同样的判断latest_stable_version_info如果最新 Release 没有资产mise 会放弃快捷路径回退到完整列表解析避免latest解析到一个列表里不存在的版本。端到端测试 e2e/backend/test_github_ls_remote_skips_assetless 用本地模拟 GitHub API 验证了这一行为v3.0.0无资产被剔除v2.0.0有资产被保留latest正确回落到2.0.0。过滤的是空不是平台不匹配这里有几个容易混淆的关键点过滤的是空资产而非平台适配性。一个 Release 的资产没有覆盖你的平台它仍然会被列出。因为版本列表必须在所有主机上含义一致才能支撑跨平台 lockfile详见 docs/dev-tools/mise-lock.md。如果按平台过滤同一份mise.lock在不同机器上解析出的版本就不同了。平台级url是豁免条件。如果工具配置了平台范围的直接下载地址——platforms.os-arch.url或扁平的platform_os_arch_url——安装路径会直接从这个 URL 下载而不做资产选择因此这些 Release 无论有没有资产都会被列出。源码中的has_direct_urlsrc/backend/github.rs只认这两种平台级写法因为它与安装路径读取url的方式严格一致direct_url_for_target 使用platform_string_for_target_without_base绝不回退到裸的顶层url。裸的顶层url不算豁免。因为安装路径只按平台读取url顶层url会被忽略安装仍会走资产选择并失败。豁免是全有或全无。同一份版本列表要服务所有平台所以只要某个平台配置了url所有平台上无资产的 Release 都会被保留列出。若某个平台的url未覆盖在该平台安装仍会失败——和过滤机制出现之前的行为完全一致。因此要么为支持的每个平台都配置url要么干脆不配url让资产选择接管。翻页读取与 MISE_LIST_ALL_VERSIONSmise 默认只抓取一页 Release并且只在找到可提供的稳定 Release 前继续向后读。由于无资产的 Release 不可提供一个最新稳定版都没有资产的仓库会被继续读下去直到小型分页上限。设置MISE_LIST_ALL_VERSIONS1可强制读取所有页。工具选项总览以下选项与[tools]中的工具条目搭配使用全部位于mise.toml的[tools]表内工具选项的通用说明见 docs/dev-tools/index.md。选项还支持命令行内联传递用[keyvalue]语法mise use github:oxc-project/oxc[matchingoxlint,rename_exeoxlint]apps_v1.69.0资产自动检测Asset Autodetection未指定asset_pattern时mise 会为你的平台自动挑选最佳资产。打分维度包括OS 兼容性linux、macos、windows源码中还识别 darwin、android 等变体架构兼容性x64、arm64、x86、arm另有 riscv64、loongarch64Libc 变体Linux 的 gnu/muslWindows 的 msvc归档格式偏好tar.gz、zip 等构建类型回避 debug/test 构建自动检测逻辑实现在 src/backend/asset_matcher.rs由 GitHub、GitLab、Forgejo 三个 backend 共用。其核心是把资产名与 OS/架构/libc 正则逐一比对并打分OS_PATTERNSasset_matcher.rs识别linux、manylinux*、darwin、macos、win64、mingw-w64等标记ARCH_PATTERNSasset_matcher.rs识别x86_64/amd64/x64、aarch64/arm64、i386/i686、armv7等LIBC_PATTERNSasset_matcher.rs识别gnu/glibc、musl/musllinux、msvc。对大多数工具无需指定模式即可安装mise install github:user/repoasset_pattern指定用于匹配 Release 资产名的模式。当同一 OS/架构组合有多个资产或需要完全覆盖自动检测时使用[tools] github:cli/cli { version latest, asset_pattern gh_*_linux_amd64.tar.gz }模式支持与bin_path相同的模板能力{{ version }}以及{{ os() }}/{{ arch() }}函数可带重映射关键字参数。asset_pattern会完全取代自动检测——匹配模式时不再调用match_by_auto_detection。源码中该优先级体现在 resolve_github_asset_url_for_target先尝试asset_pattern命中失败报No matching asset found for pattern未设置才走自动检测。模式中的*/?/.会被转换为正则pick_by_pattern多个匹配时优先最短名称其次字典序保证确定性。additional_asset_patterns从同一 Release 额外下载归档并按列出顺序解压进主资产primary asset的安装目录。用于上游把一次安装拆成基础包 若干补充包的情况。例如 Ollama 把 Linux AMD64 的 ROCm 支持发布为需要叠加在普通包之上的归档[tools.github:ollama/ollama] version latest [tools.github:ollama/ollama.platforms] linux-x64 { additional_asset_patterns [ollama-linux-amd64-rocm.tar.zst], }约束与行为每个模式必须恰好选中一个归档模式支持与asset_pattern相同的模板补充资产必须是归档裸二进制不支持解压时不应用主资产的strip_components、bin、rename_exe若补充归档与先前归档包含相同路径后解压的文件胜出。启用 lockfile 时mise 会为每个补充资产记录 URL 与校验和以及可用的 provenance 元数据。Provenance 会对当前平台做密码学验证跨平台 lock 条目则记录检测到的 provenance安装时再验证。--locked安装只使用已记录的资产列表列表不完整则直接失败。源码侧补充资产的状态记录在.mise-additional-assets.tomlADDITIONAL_ASSETS_STATE_FILENAMEgithub.rs安装时通过 additional_assets_install_state_matches 判断已安装目录是否与当前模式匹配。matching将资产选择范围收窄到名称包含给定子串的资产同时保留平台自动检测。与完全取代自动检测的asset_pattern不同matching只是缩小候选集——自动检测仍从收窄后的列表里挑选正确的 OS/arch因此一份配置可以跨平台移植。适合同一仓库为每个平台发布多个独立二进制且自动检测无法区分你想要的哪一个的场景[tools] # oxc-project/oxc 每个平台同时发布 oxlint 与 oxfmtmatching 在任意 OS/arch 上 # 都选中 oxlint而无需写死平台专属的 asset_pattern。 # apps_v1.69.0 是字面 Release tag资产是各平台归档 # rename_exe 把解压出的 oxlint-triple 重命名为 oxlint。 github:oxc-project/oxc { version apps_v1.69.0, matching oxlint, rename_exe oxlint }内联写法mise use github:oxc-project/oxc[matchingoxlint,rename_exeoxlint]apps_v1.69.0注意事项matching是大小写敏感的子串测试。若取值恰好是另一资产名的子串如同时发布tool-*与tool-extras-*时设matching tool无法唯一选中目标此时改用带锚点的matching_regex。若同时设置asset_pattern它优先matching/matching_regex被静默忽略——asset_pattern完全取代自动检测已无候选集可收窄。无效的matching_regex在这种组合下也不会报错mise 不对被取代的选项报错。过滤同样作用于校验范围校验和只针对被选中的资产查询SLSA provenance 的发现范围同步收窄避免多二进制 Release 用 A 的 provenance 校验 B。若整个 Release 共享同一份 provenance 文件如multiple.intoto.jsonl在找不到按二进制命名的 provenance 时仍会作为回退使用。源码中matching作为自动检测前的预过滤条件传入AssetMatchergithub.rs同时在 provenance 选择时经 matching_for_provenance 保持与二进制选择一致asset_pattern设置时抑制避免 provenance 收窄到错误二进制。matching_regex与matching类似但要求资产名匹配给定正则表达式。子串不够精确时使用默认大小写敏感可用内联(?i)实现忽略大小写[tools] github:oxc-project/oxc { version apps_v1.69.0, matching_regex ^oxlint-, rename_exe oxlint }若matching与matching_regex同时设置资产必须同时满足两者逻辑与才成为候选。无效的正则会在安装与mise lock前被 validate_matching_regex 提前拦截报错asset_pattern设置时跳过该校验。version_prefix为 Release tag 指定自定义版本前缀。默认 mise 已处理常见的v前缀如v1.0.0但有些仓库使用release-、version-或完全无前缀[tools] github:user/repo { version latest, version_prefix release- }配置后 mise 的行为过滤可用版本时带上前缀匹配并剥离前缀搜索 Release 时补回前缀安装时依次尝试带前缀与不带前缀的版本。示例version_prefix release-用户指定1.0.0→ mise 搜索release-1.0.0tag版本列表显示为1.0.0前缀已剥离。version_prefix 空字符串用户指定1.0.0→ mise 搜索1.0.0tag无前缀适用于完全不用前缀的仓库。源码中前缀剥离在 strip_version_prefix先剥自定义前缀再处理repoversion形式的 tag如tectonic0.15.0仅当前缀与仓库短名/全名匹配时剥离最后回退剥v。搜索时通过try_with_v_prefix_and_repo依次尝试带/不带前缀。平台专属资产模式Platform-specific Asset Patterns不同平台用不同asset_pattern[tools.github:cli/cli] version latest [tools.github:cli/cli.platforms] linux-x64 { asset_pattern gh_*_linux_amd64.tar.gz } macos-arm64 { asset_pattern gh_*_macOS_arm64.zip }平台键为os-arch形式如linux-x64、macos-arm64、windows-x64平台级取值在 asset_pattern_for_target 中解析。同一 Release 的多个资产Multiple Assets from the Same Release分两种截然不同的情况资产属于同一次安装用additional_asset_patterns补充归档叠加进同一个安装目录。资产是各自独立的工具需要独立安装目录为每个二进制定义一个 tool alias指向同一个github:owner/repobackend。优先推荐matching或matching_regex它在保留平台自动检测的同时收窄候选集一份配置适配所有 OS/arch。当各平台资产名无法用模板可移植地表达时例如 Rust target-triple 命名的oxlint-aarch64-apple-darwin.tar.gz这是正确选择。下面从单个oxc-project/oxcRelease 同时安装oxlint与oxfmt。每个matching值必须足够精确只选中目标二进制——若一个二进制的名字是另一个的子串改用带锚点的matching_regex如^oxlint-[tool_alias] oxlint github:oxc-project/oxc oxfmt github:oxc-project/oxc [tools.oxlint] version apps_v1.69.0 matching oxlint rename_exe oxlint [tools.oxfmt] version apps_v1.69.0 matching oxfmt rename_exe oxfmt注意alias 不是叠加机制。每个 alias 创建独立的安装目录。独立二进制如oxlint、oxfmt用 alias需要多个归档组合成一个可运行工具时用additional_asset_patterns。如果二进制名与你想要的调用名不一致加rename_exe重命名从归档解压出的可执行文件或bin选择/重命名二进制含单个裸的非归档二进制。只有在需要完全手动控制、且资产名能可移植表达时才改用asset_pattern它取代自动检测因此其中任何{{ os() }}/{{ arch() }}模板都必须覆盖你目标的所有平台[tool_alias] tool-a github:owner/repo tool-b github:owner/repo [tools.tool-a] version latest asset_pattern tool-a-* [tools.tool-b] version latest asset_pattern tool-b-*checksum为特定版本与特定资产设置期望摘要。将占位符替换为从可信来源取得的完整 SHA-256 摘要[tools.github:owner/repo] version 1.0.0 asset_pattern tool-1.0.0-x64.tar.gz checksum sha256:REPLACE_WITH_THE_64_HEX_DIGIT_DIGEST除了在配置里手写更推荐用 docs/dev-tools/mise-lock.md 管理校验和。另外即使不配置checksummise 也会优先使用 GitHub API 返回的资产 digest并从SHA256SUMS、*.sha256等资产中尝试提取校验和try_fetch_checksum_from_assets。平台专属校验和Platform-specific Checksums每个平台需要各自的摘要。以下为占位值安装前从发布方获取或生成mise.lock[tools.github:cli/cli] version 2.100.0 [tools.github:cli/cli.platforms] linux-x64 { asset_pattern gh_*_linux_amd64.tar.gz, checksum sha256:REPLACE_WITH_THE_64_HEX_DIGIT_DIGEST, } macos-arm64 { asset_pattern gh_*_macOS_arm64.zip, checksum sha256:REPLACE_WITH_THE_64_HEX_DIGIT_DIGEST, }size可选地校验期望字节数。下方数字仅为示意请使用所选资产的实际大小并固定版本。size 检查不认证发布方也不能替代 checksum[tools] github:owner/repo { version 1.0.0, size 12345678 }源码中 size 校验发生在下载后verify_additional_artifact_checksum 展示了同样逻辑期望 size 与实际字节数不符即报错lockfile 启用时会自动记录实际大小。strip_components解压归档时剥除的目录层级数[tools] github:cli/cli { version latest, strip_components 1 }当strip_components与bin_path都未设置时mise 会自动判断是否需要应用strip_components 1当解压后的归档根层恰好只有一个目录、没有文件时触发。这常见于 ripgrep 这类把二进制放在版本化目录里的工具如ripgrep-14.1.0-x86_64-unknown-linux-musl/rg自动检测确保二进制直接落在 mise 期望的安装路径上。bin把下载的二进制重命名为指定名称。常用于下载名字带平台后缀的单个二进制[tools.github:docker/compose] version 2.29.1 bin docker-compose # 把下载的二进制重命名为 docker-compose下载单个二进制非归档时mise 会自动去除文件名中的 OS/arch 后缀例如docker-compose-linux-x86_64变成docker-compose。只有需要特定自定义名称时才用bin。rename_exe归档解压后重命名可执行文件。适用于归档内含平台专属名二进制、需要重命名的情况[tools.github:yt-dlp/yt-dlp] version latest asset_pattern yt-dlp_linux.zip rename_exe yt-dlp # 把解压出的二进制重命名为 yt-dlp字符串形式重命名工具的主二进制按仓库名匹配。当归档内含多个需要以干净名字暴露的二进制时用表形式——每个键是源文件名精确文件名或 glob每个值是新名字[tools.github:DanielGavin/ols] version latest # 归档内含 ols-x86_64-unknown-linux-gnu 与 odinfmt-x86_64-unknown-linux-gnu rename_exe { ols-* ols, odinfmt-* odinfmt }两个二进制都会被重命名并加入 PATH。缺失的源文件跳过并告警对 ZIP 等会丢失可执行位的归档会恢复可执行位。经验法则归档内二进制名与期望名不同时用rename_exe单个二进制下载非归档用bin。no_app在自动检测期间跳过 macOS .app bundle 资产优先独立 CLI 二进制。仓库同时提供 .app bundle常为 Xcode 扩展或 GUI 应用与独立命令行工具时适用[tools.github:nicklockwood/SwiftFormat] version latest rename_exe swiftformat no_app true # 跳过 SwiftFormat.for.Xcode.app.zip改用 swiftformat.zipno_app true时名称含.app.的资产如Tool.app.zip、Tool.for.Xcode.app.zip在自动检测中被降权独立归档如tool.zip、tool-macos.tar.gz被优先主要影响 macOS 资产选择非 macOS 平台的.app.资产本就被平台匹配降权仅影响自动检测显式asset_pattern原样使用。不设置该选项时mise 的自动检测可能在 macOS 上选中 .app bundle——若 bundle 是 GUI 应用或 Xcode 扩展而非独立 CLI会带来问题。bin_path路径相对于strip_components应用之后的安装目录。设置bin_path会禁用自动根目录剥除。对于形如tool-VERSION/bin/tool的归档可以保留外层目录并用bin_path tool-{{ version }}/bin或同时设置strip_components 1与bin_path bin。指定解压归档内包含二进制的目录或下载文件的放置位置。支持 Tera 模板含{{ version }}与{{ os() }}/{{ arch() }}函数[tools.github:cli/cli] version latest strip_components 1 bin_path bin # 剥除归档外层目录之后两个函数都可带关键字参数重映射 mise 本应输出的值os()输出linux/macos/windowsarch()输出x64/arm64用于上游目录命名不同时[tools.github:pizlonator/fil-c] version latest # 展开为 filc-0.681-linux-x86_64/build/bin strip_components 0 bin_path filc-{{ version }}-{{ os() }}-{{ arch(x64x86_64, arm64aarch64) }}/build/bin模板含双引号时请使用 TOML 单引号字符串如上。注意不存在裸的{{ os }}/{{ arch }}变量也没有{{ x86_64_arch }}风格别名——{{ arch(x64x86_64, arm64aarch64) }}才是获得那些名字的方式。二进制路径查找顺序源码对应 discover_bin_paths指定了bin_path直接用该目录未设置bin_path查找安装路径中的bin/目录安装路径根目录含可执行文件用安装路径根目录无bin/目录在子目录中搜索bin/目录无bin/目录搜索直接子目录中的可执行文件若在某个子目录内直接找到可执行文件该子目录作为二进制路径无可执行文件使用解压目录根。此外源码还处理了 macOS .app 结构安装根出现被剥离后的Contents/MacOS/目录github.rs或子目录内含.appbundlegithub.rs时会指向其中的Contents/MacOS作为二进制路径。filter_bins只把指定二进制软链进过滤后的.mise-bins目录。工具自带多余二进制、不想暴露到 PATH 时使用[tools] github:jgm/pandoc { version latest, filter_bins pandoc } github:owner/repo { version latest, filter_bins [tool, helper] }启用后创建.mise-bins子目录仅包含指向指定二进制的软链其他二进制如pandoc-lua、pandoc-server不暴露到 PATH。源码实现为 create_symlink_bin_dir在discover_bin_paths找到的源目录中定位每个二进制并建立软链filter_bins中的名字必须是纯文件名拒绝含路径分隔符/父级组件的名字防止把任意文件链接进 PATHlist_bin_paths在设置了filter_bins或.mise-bins目录存在时只返回.mise-bins路径github.rs。api_url为 GitHub Enterprise 或自托管 GitHub 实例指定 API URL。mise 用它做 Release 列表与资产查询当浏览器下载 URL 不可达或使用自定义/私有实例时也可能用它下载资产[tools] github:myorg/mytool { version latest, api_url https://github.mycompany.com/api/v3 }源码中默认 API 基址为https://api.github.comDEFAULT_GITHUB_API_BASE_URLgithub.rsapi_url选项覆盖之GitBackendOptions::api_url。安装时若资产 API URL 以默认公共 API 开头mise 会探测浏览器 URL 与 API URL 哪个可达pick_reachable_asset_url对于自定义 API 主机则直接走 API 下载github.rs。注意GitHub Artifact Attestations 只由https://api.github.com提供attestations_supportedGHE Server 不实现该端点。github_attestations默认情况下mise 会在 GitHub Release 资产可用时校验 GitHub Artifact Attestations。对单个工具设置github_attestations false可跳过该校验同时保持全局的 attestation 验证开启[tools] github:myorg/mytool { version latest, github_attestations false }把它当作特定工具的临时逃生舱当 GitHub 的 attestation 服务或可信根数据导致安装失败时使用。其他验证路径checksum、SLSA provenance在已配置且可用时仍然执行。如果mise.lock已为该工具记录了github-attestationsprovenance禁用该选项后请重新运行mise lock使 lockfile 不再要求工具配置已关闭的验证器否则安装会报出明确的错误见 github_attestations_disabled_for_tool_error。验证的优先级与回退在 verify_attestations_or_slsa 中实现先 GitHub Attestations找不到再回退 SLSAlockfile 指定了 provenance 类型时只运行对应机制校验失败或类型不匹配视为降级攻击硬错误。prerelease默认情况下GitHub 上标记prerelease: true的 Release 会被排除在mise ls-remote与latest解析之外。设置prerelease true以包含它们[tools] github:myorg/mytool { version latest, prerelease true }设置后预发布 tag如v1.0.0-rc1、v0.1.2-dev.86出现在mise ls-remote中latest在稳定版与预发布版中取最新而不是走 GitHub/releases/latest快捷端点该端点返回仓库所有者标记为 Latest 的 Release——通常是最近的稳定版但也可能是通过 API 钉住的任意 Release模糊版本查询如1.2可匹配该前缀下的预发布 tag。源码中latest_stable_version_info在prerelease true时直接返回Nonegithub.rs让通用latest_version回退到基于完整列表含预发布的解析远程版本缓存存的是预发布超集读取时再按当前选项过滤github.rs因此切换prerelease选项无需失效缓存。适用于活跃 Release 全是预发布版的仓库如持续发布 dev 构建的内部工具或需要追踪 RC 版本。Draft Release 始终被排除。该选项对 GitLab 无效果。自托管 GitHub使用自托管 GitHub 实例时设置api_url工具选项见上文。认证方式参见 docs/dev-tools/github-tokens.md——GHE 的 token 解析顺序为MISE_GITHUB_ENTERPRISE_TOKEN→ github.com 系列环境变量 →credential_command→ 原生 OAuth →github_tokens.toml→ gh CLI token → git credential。支持的 GitHub 语法最新版简写github:cli/cli指定版本github:cli/cli2.40.1相关设置github backend 的行为还受全局设置影响主要包括github_attestations/slsa是否启用 GitHub Artifact Attestations 与 SLSA provenance 验证对应源码中的Settings::get().github_attestations、Settings::get().slsa以及settings.github.*子开关MISE_LIST_ALL_VERSIONS1版本列出时读取全部 Release 页token 相关设置[settings.github]下的credential_command、oauth_client_id、use_git_credentials、gh_cli_tokens等详见 docs/dev-tools/github-tokens.md。这些设置在仓库的 settings 定义中统一管理可参考 docs/settings.data.ts 与 docs/settings.toml 中的说明。安全验证链路小结githubbackend 的安装流程在下载后依次执行download_and_install配置的checksum或size校验若有GitHub API digest / 资产校验和文件自动提取并验证GitHub Artifact Attestations默认开启可用时SLSA provenance启用时作为回退上述 provenance 结果写入lock_platforms供 lockfile 复用。通过工具选项checksum、size与全局设置github_attestations、slsa的层层组合mise 能在不经手脚本的前提下对来自 GitHub Releases 的预编译二进制建立起可审计的完整性验证闭环。若要追踪这些验证在 e2e 层的真实行为可阅读 e2e/backend/test_github、e2e/backend/test_github_matching 等测试用例。【免费下载链接】misedev tools, env vars, task runner项目地址: https://gitcode.com/GitHub_Trending/mi/mise创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考