如果你正在维护一个编译型开源项目并且已经发布了 amd64 版本那么随着 ARM 云服务器、Apple Silicon 和各类开发板的普及“要不要支持 arm64”这个问题早晚会摆到面前。最近围绕 “omarchy 添加 arm64 支持” 这类架构适配任务的讨论越来越多本质上就是一次典型的跨架构工程改造。本文结合 Codex 命令行工具以 omarchy 项目为示例完整讲解从环境准备、构建脚本改造、CI 多架构发布到常见问题排查的全过程。无论你是刚开始接触跨架构编译的新手还是已经有 x86 项目需要扩展 ARM 发布的开发者这篇文章都可以作为一份可落地的操作笔记。文中会给出完整的命令、代码和排错思路你可以直接照着跑一遍再把方法迁移到自己的项目里。1. 背景Codex、omarchy 与 arm641.1 Codex 是什么Codex 是 OpenAI 推出的 AI 编码助手近期更受关注的是它的命令行形态 Codex CLI。它可以在终端中读取仓库代码、定位问题、生成修改建议甚至直接修改文件并执行命令。你可以把它理解成一个“能看懂整个工程的编程搭档”。这里需要区分两个概念早期 OpenAI 做过名为 Codex 的代码模型主要用于代码补全而现在大家常说的 Codex更多是指可以在终端安装使用的 Codex CLI 工具。本文提到的 Codex 均指后者。Codex CLI 的典型使用方式是在仓库根目录启动一个交互会话然后输入自然语言指令。例如codex 帮我看看当前仓库里哪些文件与 CPU 架构相关它会扫描代码、给出结论并询问是否执行修改。这种“先分析、后动手”的工作方式非常适合架构适配这类跨文件、跨环节的改造任务。1.2 omarchy 是什么omarchy 是一个开源项目从常见资料来看它与 Linux 环境的定制化体验有关可能是桌面主题、工具集或系统配置方案。由于项目的安装方式、构建方案会随版本持续变化本文不把重点放在 omarchy 的具体功能上而是把它当作一个需要适配 arm64 的示例项目。换句话说本文展示的“用 Codex 分析工程、添加 arm64 构建目标、验证产物”这套流程适用于各类需要同时发布 amd64 和 arm64 版本的项目不管底层用的是 C/C、Go、Rust 还是其他编译型语言。1.3 为什么要支持 arm64arm64 全称是 AArch64是 64 位 ARM 指令集架构。过去它主要出现在手机、路由器等嵌入式设备里但近几年它的应用范围迅速扩大Apple Silicon 的 Mac 全面转向 arm64AWS Graviton、阿里云倚天等 ARM 架构云服务器逐渐普及树莓派、各类 RK 开发板、边缘网关设备都在跑 Linux国产化芯片平台大多基于 ARM 或类 ARM 架构。对一个发布型项目来说如果只提供 amd64 产物就意味着这些设备上的用户无法直接安装使用。所以“支持 arm64”不是锦上添花而是扩大用户覆盖面的必要动作。1.4 amd64 与 arm64 的核心区别在动手改造之前先理清两个架构的本质区别对比项amd64 / x86_64arm64 / AArch64指令集类型CISC指令复杂、长度不固定RISC指令精简、长度固定典型设备传统 PC、服务器Apple Silicon Mac、ARM 云主机、开发板功耗表现相对较高相对较低软件生态最成熟几乎全覆盖快速增长仍有少数软件缺包构建方式在 x86 机器直接构建需要交叉编译或使用 ARM 构建机常见判读结果uname -m输出x86_64uname -m输出aarch64同一份源代码在不同架构上编译出的机器码完全不同。所以架构适配的关键不是改业务代码而是保证构建系统、依赖库、CI 发布链路都能为不同架构产出正确产物。2. 准备工作安装 Codex、确认架构、搭建编译环境2.1 安装 Codex CLICodex CLI 的安装方式以官方 README 为准常见途径是 npm 全局安装。在终端执行npm install -g openai/codex安装完成后验证一下codex --version如果能看到版本号说明安装成功。如果你的机器没有安装 Node.js或者更习惯用预编译二进制可以直接从 Codex 的 GitHub Releases 页面下载对应平台的可执行文件解压后放到PATH目录中。无论用哪种方式最终目标是让codex命令可以在终端中直接调用。2.2 配置 API Key 或完成登录Codex 在工作时需要调用后端模型服务因此需要配置访问凭据。环境变量方式如下export OPENAI_API_KEYsk-your-key-here或者使用 Codex 自带的登录流程完成认证。如果你使用的是第三方 OpenAI 兼容服务则需要在配置文件中修改 API endpoint 和模型名并确保该服务支持你配置的模型。需要注意密钥属于敏感信息不要写进仓库。本地开发时可以放在 shell 配置文件中CI 环境则应该使用 GitHub Secrets 等机密管理能力。2.3 确认当前系统架构在 Linux/macOS 上执行uname -m输出x86_64当前是 amd64 架构输出aarch64当前是 arm64 架构。在 Windows PowerShell 中执行echo $env:PROCESSOR_ARCHITECTURE输出AMD64表示 x64输出ARM64表示 arm64。下载安装包时也容易踩这个坑很多软件会区分“Windows amd64”和“Windows arm64”两个版本amd64 是给 Intel/AMD x64 处理器用的arm64 是给骁龙、苹果 M 系列等 ARM 处理器用的。选错版本会导致“安装后无法启动”或“运行不兼容”的报错。2.4 准备交叉编译工具链要给 omarchy 添加 arm64 支持常见的做法是在 x86 机器上做“交叉编译”也就是生成目标架构为 arm64 的二进制然后拷贝到 ARM 设备或 ARM 云主机上运行。不同技术栈的工具链不一样技术栈关键工具/参数C/Cgcc-aarch64-linux-gnu、aarch64-linux-gnu-gccGo直接支持GOOSlinux GOARCHarm64Rustrustup target add aarch64-unknown-linux-gnuPython需要编译扩展模块或用pip安装 arm64 的 wheel 包如果是 C/C 项目在 Ubuntu/Debian 上可以安装sudo apt update sudo apt install gcc-aarch64-linux-gnu如果项目使用了 CGO 或外部 C 库交叉编译时需要指定对应的交叉编译器路径。如果项目是纯 Go且没有依赖 CGO那么CGO_ENABLED0会让交叉编译简单很多。2.5 准备一个最小示例工程为了让后续步骤可复现这里准备一个模拟 omarchy 的最小 Go 工程。Go 的交叉编译非常直观适合用来演示架构适配思路。omarchy/ ├── main.go ├── Makefile ├── Dockerfile └── .github/ └── workflows/ └── release.ymlmain.go内容package main import ( fmt runtime ) func main() { fmt.Printf(omarchy running on %s/%s\n, runtime.GOOS, runtime.GOARCH) }这个程序本身没有业务逻辑但它可以在运行时输出当前平台信息方便我们验证编译出的 arm64 产物是否真的跑在 ARM 架构上。3. 架构适配的核心思路3.1 架构适配要改什么很多开发者以为“支持 arm64”就是把代码放到 ARM 机器上重新编译一遍实际上一个完整的架构适配往往涉及多个层面编译产物需要产出 amd64 和 arm64 两类二进制构建脚本Makefile、Shell 脚本中的架构变量不能写死CI 流程GitHub Actions、Jenkins 等流水线需要加入多架构构建任务容器镜像Docker 镜像需要支持linux/amd64和linux/arm64运行时逻辑代码里如果有 CPU 指令集判断、汇编代码、依赖库加载路径也需要适配。其中 2、3、4 是绝大多数项目最容易忽略的部分。改业务代码往往很快真正的坑都在构建和发布链路里。3.2 构建脚本中的架构硬编码观察一个典型的 Makefile可以很直观地看到问题。比如下面的写法就把架构写死了BINARYomarchy build: GOOSlinux GOARCHamd64 go build -o bin/$(BINARY) .这个 Makefile 只能构建 amd64 版本。它的问题有两个GOARCH被写死为amd64产物文件名没有区分架构后续如果同时构建两个架构文件会互相覆盖。更合理的做法是让架构可以作为参数传入。例如BINARYomarchy GOOS ? linux GOARCH ? amd64 build: GOOS$(GOOS) GOARCH$(GOARCH) go build -o bin/$(BINARY)-$(GOOS)-$(GOARCH) .这样我在 x86 机器上执行make build GOARCHarm64就能生成bin/omarchy-linux-arm64不需要改任何代码。3.3 CI 与发布链路中的架构配置构建脚本只是第一步CI 流水线同样需要调整。很多项目在 GitHub Actions 中只会在ubuntu-latest上构建一次然后直接发布。这样的流水线天然不具备多架构发布能力。改造思路有两种使用矩阵构建matrix在多个任务里分别执行不同GOARCH使用 Docker buildx 一次构建多平台镜像。矩阵构建的优势是每个任务彼此独立一个问题架构不影响其他架构buildx 的优势是一条命令搞定多平台镜像发布。实际项目中通常两者结合使用。3.4 Codex 能帮我们做什么传统做法是人工搜索代码里的x86_64、amd64、uname -m等关键字逐个项目排查。而 Codex 可以一次性读取整个工程定位所有架构相关逻辑甚至直接给出修改方案。Codex 适合做的三类事仓库扫描找出构建脚本、CI 配置、源码中与架构相关的硬编码代码生成为 Makefile、workflow、Dockerfile 生成多架构版本解释答疑解释某个编译报错的架构原因并给出修复建议。但它并不能完全替代人工 review。尤其在 CI、发布这类影响面较大的环节AI 生成的修改仍然需要人工确认。4. 完整实战使用 Codex 为 omarchy 添加 arm64 支持4.1 分析现有工程进入示例工程目录先看一下整体结构cd omarchy ls -la cat Makefile cat .github/workflows/release.yml假设初始的 Makefile 是“只能构建 amd64”的版本BINARYomarchy build: GOOSlinux GOARCHamd64 go build -o bin/$(BINARY) .初始 CI 配置也只有一个构建任务name: release on: push: tags: - v* jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - uses: actions/setup-gov5 with: go-version: 1.22 - name: Build run: make build这个配置的问题很明显产物只覆盖linux/amd64。4.2 让 Codex 定位架构相关代码在仓库根目录启动 Codex 交互会话codex然后在会话里输入请分析当前仓库中的 Makefile、CI 配置和源代码找出所有与 CPU 架构相关的内容特别是硬编码 amd64 / x86_64 的地方然后整理成一份需要修改的文件清单。Codex 给出的结果一般会包含Makefile中GOARCHamd64是硬编码建议参数化release.yml中没有矩阵构建只构建了一种架构源码main.go没有架构相关逻辑不需要修改。有了这份清单后续改动就有了明确范围。这里也体现了一个好处AI 先做全量扫描人工再针对性复核比一上来就翻文件高效得多。4.3 改造构建脚本下面手动给出一个完整的参数化 Makefile这也是 Codex 通常会建议的写法BINARYomarchy VERSION0.1.0 GO ? go build: $(GO) build -o bin/$(BINARY) . build-all: GOOSlinux GOARCHamd64 $(GO) build -o bin/$(BINARY)-linux-amd64 . GOOSlinux GOARCHarm64 $(GO) build -o bin/$(BINARY)-linux-arm64 . GOOSdarwin GOARCHarm64 $(GO) build -o bin/$(BINARY)-darwin-arm64 . GOOSdarwin GOARCHamd64 $(GO) build -o bin/$(BINARY)-darwin-amd64 . GOOSwindows GOARCHamd64 $(GO) build -o bin/$(BINARY)-windows-amd64.exe GOOSwindows GOARCHarm64 $(GO) build -o bin/$(BINARY)-windows-arm64.exe这里有几个关键点产物文件名加入GOOS和GOARCH避免多架构产物互相覆盖build-all目标一次性产出 Linux、macOS、Windows 的常见架构版本如果某个项目依赖 CGO需要额外设置CGO_ENABLED0并在命令中指定交叉编译器。执行构建make build-all然后检查产物ls -lh bin/ file bin/omarchy-linux-arm64file命令的预期输出类似bin/omarchy-linux-arm64: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), statically linked, Go BuildIDxxx, stripped看到ARM aarch64就说明这个二进制确实是 arm64 版本的。4.4 更新 CI 多架构构建接下来的改动进入 CI 环节。把 GitHub Actions 的构建任务改成矩阵模式name: release on: push: tags: - v* jobs: build: runs-on: ubuntu-latest strategy: matrix: goarch: [amd64, arm64] steps: - uses: actions/checkoutv4 - uses: actions/setup-gov5 with: go-version: 1.22 - name: Build run: | GOOSlinux GOARCH${{ matrix.goarch }} make build - name: Upload artifact uses: actions/upload-artifactv4 with: name: omarchy-linux-${{ matrix.goarch }} path: bin/矩阵构建意味着goarch: [amd64, arm64]会生成两个并行任务分别执行一次构建。这样做的好处是架构之间互不影响一个失败不会阻塞另一个构建产物通过upload-artifact分开保存发布时可以选择合并后续想增加386、riscv64等架构只需要在矩阵数组里加一项。需要注意如果你的项目依赖 CGO 或外部原生库那么 CI 构建机还需要额外安装对应架构的交叉编译工具链矩阵里也要增加goos等维度。4.5 添加 Docker 多架构镜像如果 omarchy 用 Docker 发布镜像也需要支持多架构。Docker 官方方案是 buildx。先准备一个支持多阶段构建的 DockerfileFROM golang:1.22 AS builder ARG TARGETARCH WORKDIR /src COPY . . RUN CGO_ENABLED0 GOOSlinux GOARCH${TARGETARCH} go build -o /out/omarchy . FROM alpine:3.20 COPY --frombuilder /out/omarchy /usr/local/bin/omarchy ENTRYPOINT [omarchy]关键点在于ARG TARGETARCH。buildx 在构建多平台镜像时会自动把目标架构写入TARGETARCH变量因此我们不需要在 Dockerfile 里写死架构。构建并推送多架构镜像docker buildx create --use docker buildx build \ --platform linux/amd64,linux/arm64 \ -t your-registry/omarchy:0.1.0 \ --push .执行完后可以用docker buildx imagetools inspect查看镜像支持的平台docker buildx imagetools inspect your-registry/omarchy:0.1.0输出会列出linux/amd64和linux/arm64两个条目说明镜像已经支持双架构。用户在 amd64 或 arm64 机器上执行docker pull时Docker 会自动拉取对应架构的镜像层。4.6 运行与验证构建出 arm64 二进制后需要验证它确实能运行。最简单的方式是把产物拷贝到一台 ARM 机器上执行./omarchy # 预期输出 # omarchy running on linux/arm64如果没有现成的 ARM 机器在 x86 的 Linux 环境下可以用 qemu-user 来模拟运行sudo apt install qemu-user-static ./bin/omarchy-linux-arm64qemu 会为不匹配的 ELF 文件自动启动用户态模拟从而在 amd64 机器上运行为 arm64 编译的程序。这个方式非常适合做冒烟测试确认程序没有在架构层出现问题。5. 常见问题与排查思路5.1 Codex CLI 无法启动或找不到二进制热词中经常出现这样一条报错Unable to locate the Codex CLI binary. Set Codex CLI path or ensure the executable exists on PATH.这个报错通常出现在桌面端应用尝试调用 Codex CLI 时根本原因是系统找不到codex可执行文件。排查步骤# 1. 检查 codex 是否存在 which codex # 2. 查看版本号确认安装成功 codex --version # 3. 如果找不到先安装或把二进制加入 PATH npm install -g openai/codex如果codex已经安装但桌面端仍然报错可以在桌面端设置里手动指定 codex 二进制的绝对路径。产生这个问题的常见场景是使用 nvm 管理 Node.js全局 npm 包的安装路径不在系统默认PATH中。5.2 模型不支持或模型名称错误热词中还有一条类似下面的报错The gpt-5.6-sol model is not supported when using Codex with a...这类报错说明 Codex 配置中的 model 字段写了一个当前环境不支持或服务商不允许的模型名。解决方案是打开 Codex 配置文件把 model 改成官方支持或你的 API 服务商允许的模型。如果你接入的是第三方 OpenAI 兼容服务也要特别注意模型名和接口能力是否一致。不同服务商开放的模型列表并不相同Codex 本身只负责把请求发出去模型是否可用取决于后端服务。5.3 交叉编译时报错找不到交叉编译器在编译 C/C 或依赖 CGO 的 Go 项目时交叉编译容易遇到类似报错gcc: error: unrecognized command-line option -marm或者exec: aarch64-linux-gnu-gcc: executable file not found in $PATH原因通常是系统没有安装 arm64 的交叉编译工具链。Ubuntu/Debian 安装sudo apt install gcc-aarch64-linux-gnuGo 项目如果不需要 CGO建议直接禁用CGO_ENABLED0 GOOSlinux GOARCHarm64 go build ...禁用 CGO 后Go 会使用纯静态编译避免依赖目标机器上的 glibc 版本也省去了交叉编译器的配置。5.4 在 Windows 上下载了错误的架构版本Omarchy 或其他开源工具在提供安装包时通常会区分omarchy-windows-amd64.zip给 x64 处理器的 Windowsomarchy-windows-arm64.zip给 ARM64 处理器的 Windows。如果你的设备是 Intel/AMD x64却下载了 arm64 版本运行时会直接报“程序无法运行”或“系统不兼容”。反之亦然。判断当前 Windows 架构echo $env:PROCESSOR_ARCHITECTURE下载前先确认安装包名称里的架构标识是最简单也最有效的预防手段。5.5 常见问题汇总问题现象常见原因解决思路codex 命令不存在Codex CLI 未安装或未加入 PATH执行npm install -g openai/codex确认 PATH桌面端提示找不到 Codex CLI桌面端无法定位 codex 路径在设置中手动指定 codex 二进制绝对路径模型不支持报错配置了错误或不存在的 model 名修改配置文件中的 model 字段交叉编译找不到交叉编译器未安装 arm64 工具链安装gcc-aarch64-linux-gnu生成的产物无法在 arm64 设备运行实际构建成了 amd64用file命令确认 ELF 架构下载安装包后无法启动架构版本选错确认设备架构并重新下载6. 最佳实践与工程建议6.1 构建参数参数化不要写死架构架构适配的第一条规范就是不要在构建脚本里写死arch、GOARCH、--platform等参数。把所有架构相关变量做成可传入的参数默认值可以是当前构建机架构但必须允许覆盖。这样无论是本地构建、CI 矩阵构建还是 Docker 多架构构建都能复用同一套脚本。6.2 CI 矩阵要多架构、多平台覆盖如果项目发布 Linux 二进制CI 至少覆盖amd64和arm64两个架构。如果项目还需要 macOS 和 Windows 版本建议把GOOS也加入矩阵。矩阵模式能让每个组合独立运行日志更清晰排错也更方便。但要注意矩阵并不是越多越好。每增加一个组合就多一份 CI 时间成本。合理的做法是常见架构全量覆盖小众架构按需增加。6.3 发布产物命名与校验规范多架构发布最容易出的问题就是产物同名覆盖。建议统一命名规则omarchy-${VERSION}-${GOOS}-${GOARCH}[.exe]示例omarchy-0.1.0-linux-amd64 omarchy-0.1.0-linux-arm64 omarchy-0.1.0-darwin-arm64 omarchy-0.1.0-windows-amd64.exe另外在发布前用file、sha256sum校验产物确保二进制架构正确、校验和已生成。发布说明里要明确列出每个文件的适用平台减少用户选错架构的概率。6.4 使用 Codex 辅助开发的注意事项Codex 能显著提升架构适配效率但要把它当成“结对编程搭档”而不是“自动修改机器”。以下几点值得注意先让 Codex 产出问题清单人工确认后再说“开始修改”涉及构建、CI、发布脚本的改动必须逐行 reviewAI 生成的命令尤其是有--push、rm、强制覆盖等操作的命令执行前要确认影响范围不要在 AI 会话中暴露 API Key、Token、私钥等敏感信息每次改动后都要跑一次完整构建验证 AI 修改没有引入隐藏问题。6.5 生产环境与安全边界如果你是在公司项目里做 arm64 适配还需要注意交叉编译产物要在目标架构的真实设备或云主机上做集成测试不能只依赖 qemu 模拟涉及 CI 的 Token、镜像仓库的凭据必须使用密钥管理系统禁止明文写入 workflow发布前保留上一版 amd64 产物方便快速回滚如果项目涉及数据库、系统级命令要评估 arm64 平台上的兼容性差异。7. 总结与下一步给 omarchy 这样的项目添加 arm64 支持本质是一次典型的跨架构工程改造。本文完整走了一遍流程先理解 amd64 与 arm64 的差异安装并配置 Codex CLI分析现有构建脚本参数化 Makefile改造 CI 矩阵最后用 Docker buildx 构建多架构镜像并通过file和 qemu 验证产物。这套方法不局限于 Go 项目。C/C、Rust、Python 项目在架构适配时的核心思路是一致的找到写死架构的位置把架构参数化让构建系统能同时产出多平台产物最后在 CI 和镜像发布环节完成覆盖。如果你正在做类似改造建议按这个顺序推进先扫描仓库列出所有架构硬编码点用 Codex 辅助生成初版修改方案在本地完成单架构交叉编译确认产物可运行再改 CI 矩阵和镜像构建最后用真实 arm64 设备做回归验证。架构适配的坑大多不在代码里而在构建和发布链路中。把构建参数化、CI 矩阵化、镜像多平台化这三件事做好你的项目距离“全架构发布”就不远了。