用 Codex 在 reComputer RK3576 上构建边缘 AI 应用

如何把一个应用想法变成运行在边缘 AI 开发板上的项目？本文以一次实际开发过程为例，介绍如何让 Codex 连接 reComputer RK3576、检查环境、根据自然语言需求构建应用，通过 SSH 部署，并在真实设备上验证结果。

案例是一款 YOLOv8 视频检测 WebUI：在 PC 浏览器中上传 MP4，由 RK3576 的 NPU 执行目标检测，再在线播放或下载带有检测框、类别标签和 FPS 的视频。GitHub 仓库中提供了源码、测试视频与实测记录。

这个项目希望展示一种可以复用的 AI 辅助开发方法：先提供设备信息，再明确目标和约束，让 AI 执行构建，最后按照具体的验收条件检查结果。

整体流程

Codex 在开发 PC 上运行，通过 SSH 与开发板交互。最终的应用运行在 reComputer RK3576 上，神经网络推理由板载 NPU 完成，目标检测过程不调用 OpenAI API。

text

需求描述 → PC 上的 Codex → SSH → reComputer RK3576
                                      ↓
PC 浏览器 ← 上传 / 播放 / 下载 ← NPU 上的 YOLOv8n

阶段	你需要提供什么	需要验证什么
检查环境	开发板地址、账号、只读操作范围	SSH 可用，NPU 环境可以访问
构建应用	应用行为和设备约束	模型正确，使用硬件推理，界面可操作
部署运行	应用目录和启动要求	服务成功启动，PC 能访问 WebUI
完整验证	测试视频与验收条件	上传、处理、播放和下载全流程可用

开始前的准备

一台运行 Linux 的 reComputer RK3576 Dev Kit，已具备可用的 NPU 驱动和 RKNN Runtime。
一台能够使用 Codex 的 PC，以及本地项目文件夹和供其命令行工具使用的 SSH 客户端或库。
PC 与开发板之间网络互通，并允许 Codex 使用所需的本地工具与 SSH 连接。
一段 MP4 测试视频。本项目仓库包含 video/test.mp4。

本案例复用已经安装的 Python、RKNNLite、OpenCV 和 NumPy，不涉及烧录系统或安装 NPU 驱动。如果你的开发板缺少依赖，应先让 Codex 列出缺少的内容，再决定是否安装。

步骤一：让 Codex 检查开发板

在 PC 上使用 Codex 打开本地项目目录。先提出只读检查要求，让后续方案基于真实设备环境展开。

text

通过 SSH 连接我的 reComputer RK3576。

Host: <DEVICE_IP>
Username: <DEVICE_USER>
使用我的 SSH 密钥，或向我索取连接所需的凭据。

检查操作系统、CPU 架构、内存、可用存储空间、RKNN Runtime、Python 环境、
NPU 驱动及设备访问权限，以及已经存在的 YOLO 模型。
确认可以成功执行远程命令。

暂时不要安装软件包或修改系统。报告环境状态，以及可能阻碍部署的问题。

将占位符替换成自己的设备信息。连接凭据不要写入项目文件或提交到仓库。

本次检查发现，设备运行 Debian 12 ARM64，RKNPU 设备可访问，已经具备 RKNNLite 和 OpenCV，但根分区可用空间有限。因此，后续实现选择复用现有环境，并加入上传大小限制和存储空间检查。

步骤二：描述你希望构建的应用

同时告诉 Codex 用户如何使用应用、需要使用什么硬件，以及完成任务的标准。下面的提示词根据本项目的实际需求整理：

text

通过 SSH，在我的 reComputer RK3576 上构建并部署一个 YOLOv8 目标检测 WebUI。

从 Rockchip 官方资源或经过验证的来源下载适用于 RK3576 的预编译 YOLOv8n
.rknn 模型，记录来源并验证公开的校验值。不要训练或转换模型。

使用 RK3576 的 NPU 进行推理。创建一个现代风格的英文 WebUI，支持从 PC
上传 MP4、执行检测、在线播放或下载处理后的视频。视频中需要显示检测框、
类别标签、置信度和 FPS。

尽量复用现有 RKNN 依赖和官方示例，将应用文件保存在独立目录中。
未经允许，不要重装驱动或修改系统配置。

在真实开发板上测试完整流程并修复错误，最后提供可访问的 WebUI URL、
实测性能和仍然存在的限制。

这样可以让模型选择、界面、部署和测试围绕同一个交付目标展开。提示词可以作为起点，但不同设备环境下生成的实现和性能不一定相同。

步骤三：验证模型与 NPU 推理链路

先使用一张内容已知的图片测试推理，再处理完整视频。让 Codex 提供以下证据：

模型下载来源、固定版本、校验值和 RK3576 目标平台信息。
RKNNLite 成功加载模型并初始化 NPU 的结果。
已知测试图片中识别出的预期目标。
运行时告警及涉及的软件版本。

本项目从 RKNNAI/RK3576-CNN-yolov8n 下载了预编译 YOLOv8n INT8 模型，并验证了发布者提供的 SHA-256。Codex 复用了现有 RKNNLite，参考 Rockchip 官方 YOLOv8 示例实现后处理，使用 NumPy 计算 DFL，没有额外引入 Torch。已知图片测试成功检测出行人和公交车。

设备原有 Runtime 版本为 2.3.0，而模型报告的编译器版本为 2.4.2，运行时产生了版本不匹配告警。本次图片与完整视频测试在未升级 Runtime 的情况下通过；这一结果不代表其他模型或环境也具备相同的兼容性。

步骤四：部署并打开 WebUI

Codex 将应用部署到 /home/seeed/codex-yolov8-webui，并在 8080 端口启动后台服务。在自己的开发板上，可以通过以下地址访问：

text

http://<DEVICE_IP>:8080

最终界面包含 MP4 上传、置信度和 IoU 调节、处理进度预览、检测视频播放器、结果下载和本地运行历史。视频处理和上传文件均保留在开发板上。

如果你希望直接部署仓库中的现有实现，可以让 Codex 先阅读部署说明、检查自己的设备、传输应用文件、按照实际 Python 环境调整应用路径，然后运行 NPU 探测脚本并启动服务。仓库脚本使用了本次设备的环境路径，并不是适用于所有设备的通用安装脚本。

在本次使用的设备上，命令如下：

bash

cd /home/seeed/codex-yolov8-webui
/home/seeed/venvs/rknn-lite2-test/bin/python -B probe.py
sh start.sh

本次没有配置开机启动服务。开发板重启后，需要再次运行 sh start.sh。

步骤五：验证从上传到下载的完整流程

在 PC 浏览器中上传 video/test.mp4 并启动检测。自己检查可见结果，再让 Codex 验证完整链路：

text

使用 video/test.mp4 对已经部署的 WebUI 进行端到端测试。

验证视频上传、NPU 推理、处理进度、检测框和类别标签、浏览器播放、拖动进度条，
以及将结果下载回 PC。确认下载后的视频每一帧都可以成功解码。

使用可清理的临时测试任务检查无效上传、设备忙碌时的处理、取消任务和文件清理。
修复错误，并重新运行受影响的检查。

分别报告 NPU 推理 FPS 和完整处理流程 FPS，保存测试结果，并说明功能限制
和运行时兼容性告警。

2026 年 10 月 15 日的原始测试结果如下：

测试项目	结果
输入视频	3840 × 2160、29.97 FPS、394 帧
检测结果视频	H.264 MP4、1280 × 720、13.146 秒
完成处理及下载后解码的帧数	394 / 394
NPU 推理吞吐量	37.63 FPS
完整处理吞吐量	7.89 FPS
处理耗时	49.92 秒，不含上传和模型初始化
检测到的类别	car、bus、truck、traffic light

NPU FPS 只统计推理调用耗时；完整处理 FPS 还包含视频解码、预处理、推理、后处理、绘制和编码。这些是本次运行的测量结果，不是性能承诺，也不等于视频播放帧率。测试记录保存在仓库的 verification/ 目录中。

步骤六：整理为可以复用的项目

应用运行正常后，可以继续让 Codex 整理源码、部署说明、截图、模型来源、许可证和测试报告。仅上传已经授权使用的媒体文件，排除连接凭据以及运行时上传的视频或日志。

构建下一个应用时，可以复用同样的流程：检查开发板、描述用户操作、明确硬件和系统约束、部署运行，再使用真实输入验证结果。根据新任务调整应用需求和验收条件。

使用范围与参考资源

本示例面向可信局域网使用，没有配置登录或 TLS。
上传限制为 500 MiB；输入最高支持 4K，输出按比例缩放到 1280 × 720 范围内，保留源视频时序，不保留音频。
项目原创代码使用 MIT 许可证；预编译模型保留 AGPL-3.0，Rockchip 示例及其衍生后处理保留 Apache-2.0。
项目源码、部署说明与测试报告
Rockchip 官方 YOLOv8 示例
OpenAI Codex 最佳实践