企业官网建设流程全解析

• 人工智能
• AI Agent
• MCP 服务
• 工具调用
• GUI 自动化
• 语音
• 数字人
• 交互助手

AIRI（Project AIRI）是一套自托管、可自由拥有的 Grok 风格 AI 伴侣与赛博生命灵魂容器，同时提供 Web 与桌面（macOS / Windows / Linux）形态。本文以官方文档「版本一览」页为核心，系统讲解 AIRI 的三类版本通道（稳定版 Release、预发布版、Nightly 每夜构建）分别面向什么场景、如何获取，并深入到文档背后的数据加载器、GitHub Actions 构建矩阵、产物命名与自动更新元数据，帮助你准确选择适合自己的版本，同时理解整个发布流水线的运作原理。

版本体系总览：三条通道各司其职

AIRI 的桌面端版本并非只有"正式版"一个概念，官方文档将其划分为三种形态，对应不同的稳定性预期与使用场景：

其中稳定版与预发布版都通过 GitHub Releases 发布，Nightly 则由定时构建的 Actions 工作流产出、以 Artifacts 形式提供。文档页面中这两块内容分别由两个 Vue 组件渲染：ReleaseDownloads.vue 负责两张下载卡片，ReleasesList.vue 负责最近的版本列表。

下载 Release：稳定版与预发布版的选择逻辑

原文档「下载 Release」一节的核心是一套双卡片下载界面（<ReleaseDownloads />），其源码逻辑在 ReleaseDownloads.vue 中实现：

• 稳定版卡片（图标i-lucide:package-check，绿色标签）：展示最新稳定版的tag_name，点击"下载"按钮会跳转到最新稳定版 Release 的详情页；若暂时没有稳定版数据，则回退到 Release 列表页面。
• 预发布版卡片（图标i-lucide:package，黄色标签）：展示最新预发布版的tag_name，同样提供下载按钮与回退地址。

两张卡片分别配置了推荐使用场景，文案由多语言包统一维护，中文语义见 packages/i18n/src/locales/zh-Hans/docs/versions.yaml：

• 稳定版适用场景：生产环境使用；需要稳定体验的用户；直播和内容创作。
• 预发布版适用场景：想要尝试新功能的早期采用者；测试并向开发者提供反馈；能够接受偶尔出现问题的用户。

由此可以得到清晰的选版建议：如果你把 AIRI 用于日常陪伴、长期存档或直播推流，请选择稳定版；如果你希望提前体验 Live2D / VRM 渲染、语音交互等新特性，并且愿意承担偶发问题，可以选择预发布版——但要注意预发布版并不适合作为唯一版本长期使用。

版本数据从哪来：releases.data.ts 数据加载器解析

页面上所有版本号、日期、链接并非手工维护，而是由 VitePress 的 Data Loader 在构建时实时抓取 GitHub API 生成的。核心实现在 docs/.vitepress/data/releases.data.ts，其中Release与NightlyBuild两个接口定义了数据形状：

export interface Release { name: string tag_name: string html_url: string published_at: string prerelease: boolean draft: boolean body: string } export interface NightlyBuild { id: number name: string html_url: string created_at: string updated_at: string status: string conclusion: string workflow_name: string head_sha: string head_commit_message: string }

加载器的主要行为可以概括为以下几点：

1. 抓取 Releases：调用 GitHub Releases API，过滤掉draft（草稿）发布。
2. 识别预发布：除了 API 自带的prerelease标记外，还会把tag_name中包含-beta或-alpha的版本也归入预发布通道——这是从源码可见的分类规则。
3. 分通道截取：稳定版与预发布版各自只保留最新的 10 条。
4. 抓取 Nightly：调用 GitHub Actions 的 workflow runs API，仅统计status=success的运行，每次取 10 条；每条记录截取head_sha前 7 位作为短哈希，并取提交信息第一行作为构建名称。
5. 容错降级：任何一次 API 请求失败（网络、限流等）都会让对应通道返回空数组，页面随即展示"暂无可用版本"的空状态，而不是直接崩溃。

这个文件也是理解后续所有列表、卡片数据的唯一事实来源：页面展示的"最近 5 条"只是把上述数据按发布时间倒序排列后再截取前 5 条的结果。

最近 Release 列表：类型徽标与日期格式化

<ReleasesList type="releases" :limit="5" />渲染"最近 Release"列表，其实现细节在 ReleasesList.vue：

• 排序：将稳定版与预发布版合并后按published_at时间倒序排列，因此列表会同时出现两种类型的条目。
• 类型徽标：稳定版为绿色Stable徽标、预发布版为黄色Pre-release徽标、Nightly 为蓝色Nightly-<短哈希>徽标。
• 日期本地化：根据当前语言环境（如zh-Hans映射为zh-CN）将 ISO 时间戳格式化为"年-月-日"样式，中文界面显示"发布于"。
• 空状态：当没有数据时，显示提示并附带指向对应工作流/发布页面的链接。

下载 Nightly：实验性构建的正确获取姿势

Nightly 是文档中特别标注实验性的通道。原文档明确给出了两点关键约束：

1. 稳定性风险：Nightly 构建可能包含 bug 或不稳定功能，请保留一个 Release 版本作为备份，不要用 Nightly 覆盖日常使用的版本。
2. 来源：Nightly 从最新的main分支生成，需要前往指定的 Actions 工作流页面，选择最近一次成功（success）的运行，在Artifacts部分下载对应平台的构建产物。

值得注意的是，文档描述与 releases.data.ts 中的实现完全一致——加载器查询 workflow runs 时显式使用status=success过滤，确保列表里只会出现构建成功的 Nightly。<ReleasesList type="nightly-builds" :limit="5" />则展示最近 5 条 Nightly，每条包含构建名称（取提交信息首行）、Nightly-<7 位短哈希>徽标与"构建于"日期。

Nightly 背后的构建流水线：release-tamagotchi.yml 深度解读

Nightly 乃至所有桌面端产物都由同一个 GitHub Actions 工作流产出，即 .github/workflows/release-tamagotchi.yml。理解它能帮你更准确地判断"该不该用某个 Nightly"。

触发方式

工作流支持三种触发：

• Release 事件：当有prereleased（预发布）事件时触发，用于正式发布链路。
• 定时调度：schedule使用 cron 表达式0 0 * * *，即每天 UTC 零点自动触发一次——这正是 Nightly "每夜构建"名称的由来。
• 手动触发：workflow_dispatch支持通过参数控制构建行为，详见下文"手动触发构建"。

构建矩阵与产物形态

工作流通过 5 个 runner 组成构建矩阵，覆盖三大桌面平台与主流架构：

每个 runner 的构建步骤大致相同：安装依赖（pnpm install --frozen-lockfile）→ 构建工作区包（pnpm run build:packages）→ 用 Godot 无头模式导出舞台（godot --headless --export-release，对应 engines/stage-tamagotchi-godot）→electron-builder打包桌面应用。Linux 上还会额外通过flatpak-builder生成 Flatpak 包。

Windows 签名与更新元数据修复

Windows 构建有一个特殊环节：安装包先由 electron-builder 生成，随后提交给 SignPath 服务进行重新签名（electron-builder.config.ts 中配置了provider: 'github'的自动更新）。由于重新签名会改变 .exe 的字节，导致 electron-builder 生成的latest-x64.yml更新元数据中的哈希失效，工作流在签名完成后会重新调用regenerate-windows-latest脚本，基于最终签名的安装包重建更新清单（即apps/stage-tamagotchi/scripts/regenerate-windows-latest.ts所对应的pnpm run regenerate-windows-latest）。这正是文档未展开、但决定"Nightly 是否可用自动更新"的关键细节。

发布与分发

正式 Release 构建（github.event_name == 'release'）还会把产物上传到 GitHub Releases，并通过softprops/action-gh-release附带所有latest-*.yml更新元数据；另有publish-distributionjob 通过 butler 把各平台产物推送至 itch.io，publish-gitcode-releasejob 则将发布镜像到 GitCode（见 .github/scripts/publish-gitcode-release.sh）。

版本号与产物命名规范

不同通道的版本号与文件命名规则由 apps/stage-tamagotchi/scripts/utils.ts 中的getVersion()统一决定：

• Nightly：取当前git log -1的完整提交哈希前 7 位，拼上构建日期，形如nightly-20261014-abcdef1。
• Release：优先取--tag传入的 Git 标签（去除前缀v）；未指定标签时使用package.json中的version（当前仓库中为0.12.0-beta.5，见 apps/stage-tamagotchi/package.json）；开启--auto-tag时则回退到git describe --tags得到的最新标签。

产物文件名遵循 electron-builder 的模板（electron-builder.config.ts）：

Windows: AIRI-${version}-windows-${arch}-setup.exe macOS: AIRI-${version}-darwin-${arch}.dmg Linux: AIRI-${version}-linux-${arch}.deb / .rpm / .flatpak

更新元数据文件则遵循latest-${arch}通道命名规则，展开后为：

• macOS x64 →latest-x64-mac.yml，arm64 →latest-arm64-mac.yml
• Windows x64 →latest-x64.yml
• Linux x64 →latest-x64-linux.yml，arm64 →latest-arm64-linux-arm64.yml

这套命名保证 electron-updater 在运行时能按平台与架构精确匹配更新源，避免 arm64 用户误拉到 x64 构建。这些元数据的具体生成与重命名逻辑分布在 rename-artifacts.ts 与 artifacts-metadata.ts 两个脚本中。

手动触发构建与本地构建

除等待每日定时 Nightly 外，仓库还为维护者提供了手动触发入口与本地构建脚本：

手动触发（Actions 页面）支持三个输入参数：

本地构建命令（来自 apps/stage-tamagotchi/package.json 的 scripts）：

pnpm run build:win # 构建 Windows（electron-builder --win） pnpm run build:mac # 构建 macOS（electron-builder --mac） pnpm run build:linux # 构建 Linux（electron-builder --linux） pnpm run build:flatpak # 构建 Linux Flatpak pnpm run build:unpack # 仅解包产物，不做安装包（--dir）

同时提供产物相关的工具脚本：rename-artifacts负责把 dist 目录下的产物按目标版本号重命名并归入bundle目录；artifacts-metadata支持--get-version、--get-bundle-name、--get-filename <ext>、--get-output-filename <ext>等参数，供 CI 与本地脚本查询产物信息。

结语：如何选择适合自己的 AIRI 版本

回到文档的核心诉求——"AIRI 的不同版本以及如何获取它们"，可以给出如下实践建议：

1. 日常使用、直播、创作：下载绿色标签的最新稳定版，这是唯一被推荐用于生产环境的通道。
2. 尝鲜新特性并愿意反馈：可以尝试黄色标签的预发布版，但请保留稳定版作为可回退的备份。
3. 开发者与深度体验者：从工作流页面下载蓝色标签的 Nightly（nightly-日期-短哈希命名），但务必清楚它基于每日main分支构建，可能携带未完成功能或 bug。

无论选择哪个通道，版本数据的实时抓取逻辑（releases.data.ts）、页面组件渲染（ReleaseDownloads.vue 与 ReleasesList.vue）以及完整的发布流水线（release-tamagotchi.yml）都是公开可见的，你可以随时对照源码验证页面上每一个版本号、日期和链接的真实来源。

• 人工智能
• AI Agent
• MCP 服务
• 工具调用
• GUI 自动化
• 语音
• 数字人
• 交互助手