AI 编写嵌入式 Linux / OPC UA Server

上一篇聊了 STM32 单片机上的 AI 编程，这篇继续——嵌入式 Linux 上的应用程序开发。

宿主机（nano pi r2s）

手头有一块 Nano Pi R2S，双千兆以太网，Rockchip RK3328，四核 Cortex-A53。拿它来做 OPC UA 服务器。

和 STM32 一样，第一步是烧录 Ubuntu 和配网络。时隔多年全忘了。上 Friendly Elec 官网下了 Ubuntu 镜像，附带一个丑得没法看的 Win32 写入工具。镜像写进去后文档没讲清楚以太网 IP、用户名和口令——Claude Code 跟我一起查了半天，结论：DHCP，口令 pi/pi。

接着 Claude Code 直接帮我把网络改成固定 IP，又开通了第二个以太网口：

开发环境

Nano Pi R2S 是 ARM64，Mac M4 也是 ARM64。直觉上 Mac 上的编译器就够了——但 Mac 的 gcc/clang 出的是 macOS Mach-O 格式，而 R2S 要 Linux ELF。操作系统不同，二进制格式、系统调用、glibc 全不一样。Mac 上 gcc 出来的程序，R2S 跑不了。

Claude Code 提出用 Docker：拉一个 linux/arm64 Ubuntu 容器，里面是 Linux + glibc, gcc 直接出 aarch64 Linux ELF，和 R2S 完全匹配。它自己建了一个 r2s-build 容器，我全程没管。Mac Mini 上本来就装了 Docker 和 Docker Desktop，所以整个过程很顺。

Claude Code 判断：不写驱动也不调特殊库的话，不需要 Nano Pi 的 SDK。

scp、ssh 这些工具 Mac Mini 自带，不用额外折腾。

项目开发

跟 STM32H743 上搞 OPC UA Server 的痛苦比起来，Linux 上开发 open62541 简直是闭着眼睛过——几乎一把跑通。随后 Claude Code 建议下载 UaExpert 做测试，我觉得下客户端麻烦，直接让它写一个 Python 客户端。它很快写好，测试结果非常满意。

下一步工作

这个项目让我更确信 AI 适合写嵌入式软件——尤其是在 Linux 平台上，工具链和生态对 AI 更友好。接下来的打算：

老工程师手里都攒了不少项目的源代码，这些是新项目的参考。但人读代码费劲，积压的代码往往吃灰。AI 不一样，读代码比人快得多，而且这些代码都是调通了的，对 AI 来说是高质量的参考样本。现在就可以动手，把尘封的代码整理出来，用 AI 做描述、分析、改进。

同理，读别人的代码更辛苦。公司技术部保管的产品代码，新人接手时常说“之前代码一塌糊涂，不如重写”——宁可重写也不愿看。但 AI 没有偏见，不挑食，能从历史代码中学到技巧、风格和方案，也能做审计、排错和安全检查。为了让 AI 高效地读公司的代码库，可以在本地搭建类似 GitHub 的平台（推荐 Gitea），把代码集中存放。安全、权限、保密机制是关键。

每家公司的产品开发都需要公共技术文档：元器件数据表、技术标准、产品标准等。把这些收集起来，构建一个企业编程知识库（CodeWiki），AI 编程时可以直接检索。

继续研究嵌入式程序设计的技巧和指南，将它们包含到 claude.md 中。

结束语

AI 编程在拉低软件的研发成本。传统组态软件、低代码平台的价值在被侵蚀——AI 能直接替代那些靠拖拽配置和模板拼装完成的工作。

过去几十年，为了提高软件研发的效率和质量，业界搞出了各种设计方法论，以及包罗万象的系统设计和项目管理工具（比如 PLM）。AI 编程逐步成熟后，这些综合工具应该转向 AI Agent 的基础设施——不再为人的操作习惯和 UI 设计，而是面向 AI 友好的 CLI 和无头服务。软件工程的方法论会被重构，这里面有不少创新的空间。