如果说电脑是 AI 项目的“办公室”，那真实硬件就是它的“施工现场”。
这一次，我没有只在 Mac 上写代码、跑脚本、模拟设备效果，而是把开发环境直接搬进了一块 Orange Pi 5 Max Android 设备里。
目标很简单，也很有意思：
让这块 Android 开发板自己跑起 Termux、Node.js、Python、Rust、Git，最后再装上 OpenAI Codex CLI。
这样一来，它就不只是一个被动显示内容的屏幕，而是可以直接参与 AI 相框项目开发、调试、排障和验证的设备端工作台。
◆为什么要这么折腾？
AI 相框听起来像一个“展示照片”的产品。
但真正做起来，它更像一个小型的边缘智能终端：
要能管理本地图片、视频和文案素材。 要能生成播放列表。 要能运行展示页面或播放器。 要能排查网络、缓存、文件权限和设备状态。 以后还可能接入家庭相册、语音、传感器和 Agent 自动化。
如果所有调试都只发生在电脑上，等到上真机时，很多问题都会变成“它在我电脑上明明可以”的经典现场。
所以这次的思路是：把 Codex 带到设备上。
让 AI 不只在桌面开发环境里给建议，而是在真实硬件里参与排查和改代码。
◆第一步：确认我们操作的是哪一台设备
这一步看起来很基础，但它决定了后面会不会误伤别的 Android 设备。
本次目标设备是：
ADB 地址：192.168.99.73:XXXX 型号：orangepi5max 产品：rk3588_t Android：13 架构：arm64 内核：Linux 5.10.157 内存：约 8GB 屏幕：1024x600 GPU/OpenGL：OpenGL ES 3.2
本机 ADB 路径：
/Users/XXX/Library/Android/sdk/platform-tools/adb
同一局域网里还出现过另一台 Android 设备，所以所有 ADB 操作都明确带上 -s 192.168.99.73:5555。
在硬件开发里，这不是洁癖，是保命习惯。
◆第二步：给 Android 装上 Termux
Pi 5 Max 的 Android 系统里原本没有 Termux，所以直接安装 F-Droid 官方签名版本。
版本信息：
包名：com.termux 版本：0.118.3 versionCode：1002 架构：arm64-v8a
安装完成后，Termux Activity 可以正常启动。也就是说，这块 Android 开发板已经有了一个接近 Linux 的终端入口。
接下来就可以在设备上准备开发工具链。
◆第三步：把基础工具链补齐
Termux 初始化后，先更新包，再安装基础工具：
pkg update -y pkg install -y curl tar coreutils pkg install -y nodejs-lts python rust git
最终验证到的版本是：
Node.js v24.15.0 Python 3.13.13 rustc 1.95.0 cargo 1.95.0 git version 2.54.0
这里有一个小插曲。
原本希望精确使用 Node.js v24.14.1，但 Termux 当前可维护的 LTS 包安装到的是 v24.15.0。中间也短暂试过当前版 nodejs，会安装到 v26.2.0。
最后选择 nodejs-lts。
做硬件端环境，稳定和可维护比“版本数字刚好一致”更重要。
◆第四步：安装 Codex CLI
优先尝试官方 standalone installer：
curl -fsSL https://chatgpt.com/codex/install.sh | CODEX_NON_INTERACTIVE=1 sh
安装器在 Termux 里识别为：
Linux (ARM64)
安装后得到：
Codex CLI 0.138.0 安装路径：~/.local/bin/codex
把路径加到当前会话：
export PATH="$HOME/.local/bin:$PATH"
验证：
codex --version
输出：
codex-cli 0.138.0
到这里，事情已经成功了一半。
但 Android/Termux 毕竟不是标准 Linux 发行版，后面还有一个平台识别的小坑。
◆第五步：补上 npm 方式，绕过 Android 平台识别问题
为了让 Termux/Android 下的可执行文件更稳，后续又补了一次 npm 安装：
npm install -g @openai/codex
问题来了：Termux 会把平台识别成 android，导致 npm 可选 native 包不会按普通 Linux 方式自动安装。
处理方式是强制补装官方 Linux ARM64 native 包：
npm install -g --force @openai/codex-linux-arm64@npm:@openai/codex@0.138.0-linux-arm64
最终验证路径：
/data/data/com.termux/files/usr/bin/codex
最终版本：
codex-cli 0.138.0
这一步的意义是：以后在设备端调试，不用担心某次 PATH 或 native 包选择导致命令不可用。
◆第六步：登录认证，遇到真正的坑
原计划使用设备码登录：
codex login --device-auth
但在 Pi 5 Max Termux 中多次失败，错误指向设备码接口请求失败：
Error logging in with device code: error sending request for url (https://auth.openai.com/api/accounts/deviceauth/usercode)
尝试过 CA 证书路径、网络连通性和 DNS 方向排查后，设备码登录仍没有成功。
最后采用了本机已有 Codex 登录缓存迁移方式：
源文件：/Users/XXX/.codex/auth.json 目标位置：/data/data/com.termux/files/home/.codex/auth.json
权限设置：
chmod 700 ~/.codex chmod 600 ~/.codex/auth.json
这里必须强调：这不是通用首选方案。
通用首选仍然是设备码登录。只有在设备码网络请求失败，并且本机已经有可信 Codex 登录状态时，才考虑迁移认证缓存。
认证文件不能写进文档、Git 仓库、聊天记录或任何项目文件。
◆第七步：验证 Codex 已经在设备端跑起来
认证完成后，在 Pi 5 Max Termux 中执行：
command -v codex codex --version codex doctor --summary codex debug models
关键结果：
codex命令可以被找到。 版本为 codex-cli 0.138.0。codex debug models能返回模型能力 JSON。 返回内容包含上下文窗口、输入模态、搜索工具支持等字段。
这说明 Codex CLI 已经能读取认证，并且可以访问 OpenAI 服务。
换句话说，Pi 5 Max 不再只是一个“被电脑控制的屏幕”，它已经具备了设备端 AI 开发节点的雏形。
◆接下来，AI 相框可以怎么跑？
后续可以在 Pi 5 Max 上建立一个设备端项目目录：
mkdir -p ~/ai-frame cd ~/ai-frame codex "检查当前目录，并帮我规划 AI 相框的设备端项目结构"
建议的目录结构是：
~/ai-frame/ content/ # 图片、视频、文案、展示素材 scripts/ # 拉取内容、生成播放列表、清理缓存等脚本 renderer/ # 相框页面或播放器逻辑 agent/ # Codex/LLM 驱动的决策逻辑 logs/ # 运行日志 config/ # API、设备、显示、网络配置，不提交密钥
第一阶段不用一下子做得很复杂。
最小闭环可以是：
设备启动后进入一个固定展示页面。 本地 content/目录里的图片可以轮播。用脚本生成 playlist.json。用 Codex CLI 辅助修改脚本和排查运行错误。 再逐步接入联网内容、家庭相册、语音或传感器输入。
这样做的好处是，每一步都发生在真实硬件上。
不是先幻想一个完整系统，而是让设备自己先跑起来。
◆这次最值得记住的几个坑
第一，ADB 网络连接可能不稳定。
安装过程中 Pi 5 Max 一度从 ADB 设备列表里消失，ping 和 ARP 也出现过异常。恢复后，192.168.99.73 可以 ping 通，但 ADB TCP 5555 一开始仍然 Connection refused。
所以不要省略确认步骤：
adb connect 192.168.99.73:5555 adb devices -l
第二，Termux 不是标准 Linux。
它足够强，但在平台识别、native 包选择、路径权限和登录请求上，都会有 Android 自己的差异。
第三，认证文件必须谨慎处理。
不要把 auth.json、API Key、Cookie 或 token 写入项目，也不要为了“方便复现”把它们贴到文档里。
第四，真实设备开发一定要带设备 ID。
多台 Android 设备同时在线时，ADB 命令不带 -s 就是在和运气合作。
◆结论：这块屏幕开始变得不一样了
这次的结果是：
Pi 5 Max Android 可通过 ADB 访问。 Termux 已安装。 Node.js、Python、Rust、Git 已安装。 Codex CLI 已安装。 Codex CLI 版本为 0.138.0。Codex CLI 已完成认证。 codex debug models已能返回 OpenAI 模型能力信息。
它还不是一个完整的 AI 相框产品。
但它已经从“一块能显示内容的 Android 板子”，变成了“可以在设备端开发、调试、验证 AI 相框逻辑的边缘节点”。
这一步很关键。
因为真正的 AI 硬件产品，不是 PPT 里的能力堆叠，而是一个个能在真实设备上跑通的小闭环。
电脑负责规划，设备负责验证。
当 Codex 也能进入设备现场，AI 相框项目就开始离真实产品更近了一点。
