SkillUI v0.2.0 的重点不只是增加一个 Linux 打包脚本，而是开始系统整理跨平台发布流程：Linux 支持 deb 和 AppImage，Windows 与 macOS 的 CI 产物统一携带版本号，Makefile 也加入了 App Store 签名配置和 build-devtools 构建目标。对于一个跨平台编程助手的 GUI 管理面板来说，这些变化直接影响用户如何安装、升级和分发应用。
这次更新解决了什么问题
跨平台桌面应用通常需要同时维护多种产物：Linux 发行版可能需要 deb 或 AppImage，Windows 用户需要 exe，macOS 用户则更关注 dmg 和应用签名。不同平台的文件命名、构建参数和发布方式如果没有统一约定，最终会让 CI 产物难以识别，也会增加后续自动化发布的成本。
v0.2.0 对这些环节进行了集中改进：
- 新增 Linux 打包脚本，支持生成 deb 和 AppImage。
- Linux 的 deb、AppImage，以及 Windows exe、macOS dmg 产物文件名统一加入版本号。
- Makefile 增加 App Store 签名配置。
- 新增
build-devtools构建目标，为构建所需的开发工具提供统一入口。 - 支持 App Store 构建流程，便于继续完善 macOS 分发能力。
这些改动看起来偏工程化，但它们会直接改变项目的交付体验。开发者可以通过文件名判断产物版本，CI 可以更稳定地上传和归档文件，用户也更容易区分旧版本与新版本。
Linux 的 deb 与 AppImage 如何选择
这两个格式服务于不同的安装场景。
deb 更适合 Debian、Ubuntu 及其衍生发行版的系统级安装。它通常可以接入系统的软件包管理流程，适合希望通过标准包管理工具安装应用的用户。
AppImage 更适合希望下载后直接运行的用户。它把应用及其依赖打包到一个文件中，分发时不需要针对每个 Linux 发行版单独制作安装包。不过，用户通常还需要手动赋予执行权限。
一个典型的本地验证流程可以是：
# 假设构建产物位于 dist/，版本号为 0.2.0
VERSION=0.2.0
# 检查产物是否带有版本号
find dist -maxdepth 1 -type f \\
\( -name "*${VERSION}*.deb" -o -name "*${VERSION}*.AppImage" \) \\
-print
# 验证 AppImage 是否可以被系统执行
APPIMAGE=$(find dist -maxdepth 1 -type f -name "*${VERSION}*.AppImage" | head -n 1)
chmod +x "$APPIMAGE"
"$APPIMAGE" --appimage-version
# 在 Debian/Ubuntu 环境中检查 deb 元数据
DEB=$(find dist -maxdepth 1 -type f -name "*${VERSION}*.deb" | head -n 1)
dpkg-deb --info "$DEB"
上面的命令假设项目把构建产物放在 dist/，具体目录应以项目实际脚本为准。重点在于把“文件名检查”“可执行性检查”和“包元数据检查”放进发布前验证步骤，而不是只依赖构建命令返回成功。
版本号应该成为产物的一部分
CI 产物统一带版本号，是这次更新中很实用的一项变化。例如，发布目录中的文件可以采用类似下面的命名方式：
skillui-0.2.0-linux-amd64.deb
skillui-0.2.0-linux-x86_64.AppImage
skillui-0.2.0-windows-x64.exe
skillui-0.2.0-macos-arm64.dmg
具体名称仍应以项目实际配置为准，但命名规则最好至少包含应用名、版本号、操作系统和架构。这样做有几个好处：
- 发布人员不需要打开文件属性就能确认版本。
- 自动上传脚本可以使用稳定的 glob 模式匹配产物。
- 用户下载多个版本时不容易混淆。
- 构建缓存和归档系统可以更准确地定位文件。
在 CI 中，可以把版本号显式传入构建脚本。例如，下面是一个可以按项目情况改造的 shell 片段：
#!/usr/bin/env bash
set -euo pipefail
VERSION="${VERSION:?VERSION is required}"
TARGET="${TARGET:-linux}"
ARCH="${ARCH:-amd64}"
case "$TARGET" in
linux)
PACKAGE="skillui-${VERSION}-${TARGET}-${ARCH}"
echo "Building ${PACKAGE}.deb and ${PACKAGE}.AppImage"
# 将下面两行替换为项目实际的打包命令
make build-deb VERSION="$VERSION" OUTPUT="dist/${PACKAGE}.deb"
make build-appimage VERSION="$VERSION" OUTPUT="dist/${PACKAGE}.AppImage"
;;
*)
echo "Unsupported target: $TARGET" >&2
exit 1
;;
esac
这段示例没有假定 SkillUI 的具体构建工具或参数，make 目标名称需要根据仓库实际定义调整。它展示的是一个重要边界：版本号应由 CI 或发布流程明确传入，而不是依赖脚本内部的隐式默认值。
Makefile 与 App Store 构建
Makefile 增加 App Store 签名配置，说明项目开始把 macOS 分发中的签名步骤纳入标准构建入口。签名通常涉及开发者证书、团队标识和相关密钥，不能把真实凭据硬编码进仓库。
可以采用环境变量的方式组织本地和 CI 配置：
APP_NAME ?= SkillUI
VERSION ?= 0.2.0
build-devtools:
@echo "Building development tools"
# 替换为项目实际的工具构建命令
build-app-store:
@test -n "$(APPLE_TEAM_ID)" || (echo "APPLE_TEAM_ID is required"; exit 1)
@test -n "$(SIGNING_IDENTITY)" || (echo "SIGNING_IDENTITY is required"; exit 1)
@echo "Building $(APP_NAME) $(VERSION) for App Store"
# 替换为项目实际的 macOS App Store 构建命令
运行时可以这样传入非敏感配置：
make build-devtools
APPLE_TEAM_ID="YOUR_TEAM_ID" \\
SIGNING_IDENTITY="Apple Distribution: Example Company" \\
VERSION="0.2.0" \\
make build-app-store
生产环境中的证书和私钥应交给 CI 的密钥管理系统，并限制访问范围。命令行示例中的 YOUR_TEAM_ID 和证书名称只是占位符，不能直接作为真实发布凭据使用。
build-devtools 也值得单独关注。构建工具如果由每个开发者手工安装，容易出现版本差异；将它纳入 Makefile 后，可以把开发工具构建变成可记录、可复用的项目操作。后续还可以为该目标增加版本检查、平台检查和 CI 校验，减少“本地能构建、流水线失败”的情况。
升级到 v0.2.0 时的检查清单
如果你负责维护或分发 SkillUI，可以在采用这一版本时检查以下内容：
- 确认 Linux 构建环境包含生成 deb 和 AppImage 所需的依赖。
- 确认 Linux、Windows、macOS 的产物文件名都包含版本号。
- 确认 CI 上传规则已经匹配新的文件名。
- 确认 AppImage 在干净环境中具备执行权限并能够启动。
- 确认 deb 的架构、依赖和包元数据符合目标发行版要求。
- 确认 App Store 构建所需的签名配置通过安全的环境变量或 CI 密钥注入。
- 确认
build-devtools在开发机和 CI 中行为一致。
SkillUI v0.2.0 的变化集中在发布基础设施，但这正是跨平台桌面应用走向稳定交付的重要一步。对于使用者，Linux 安装选择更多；对于维护者，产物管理、版本追踪和 macOS 分发流程更加清晰。后续如果继续补充自动化测试、签名验证和各平台干净环境测试，整个发布链路会更适合持续迭代。