嵌入式 Linux 上层应用：让 AI「搭脚手架」

大家好，我是杂烩君。

最近有个项目中，有个进程代码需要从零开始开发，用 AI 搭建了个能跑、符合预期的脚手架。

很多人对 AI 的期待是「一句话生成可上线成品」，在嵌入式上层应用里通常会碰壁：内存不算多、线程不能乱飙、还不能把 PC 上那套想当然搬过来。

本文把一套可落地的打法说清楚：AI 负责重复劳动和模板，人盯住需求对齐、资源边界和关键逻辑。

从 0 到 1 的五个步骤

人先把需求剁成提示词条目：单板型号、操作系统、C++ 版本、必选库（比如日志和 YAML 解析）、模块清单、线程上限、禁用事项（禁用 PC API、禁用乱开线程）。

让 AI 出「空壳框架」：标准目录、CMakeLists骨架、接口头文件、无业务实现的类占位、零散工具函数。这里别急着让人家写核心业务。如：人做第一轮审核：看分层是否自相矛盾；依赖路径是不是还在「我笔记本上碰巧能编过」的形态；CMake 是否已经留好调试和量产两道门。

再投喂细提示，让 AI 补实现：日志轮转、配置的监听或热加载、串口超时、协议解析草稿、 systemd 或服务脚本等。这一轮的重点转到

线程安全和错误路径：外设离线、半包黏包怎么处理，别留「开心路径-only」。

跑板、裁切、封存：能交叉编译且在目标板上冒烟通过后，把这版目录树和脚本沉淀成团队母版，新项目只改业务，而不是每场重头搭积木。

人工审核最常看的四件事：架构分层有没有互相踩脚（尤其 HAL 和业务是否混在一起）、资源参数是不是拍脑袋（线程池深度、缓冲区大小）、兼容性（没有出现只在 x86 Demo 成立的调用）、团队命名和 CMake 是否与现有仓库一致——这些项过了，再往细节里投喂模型会省很多时间。

维护阶段

项目在板子上跑半年后，最常胖起来的地方无非是日志口径、线程习惯、三方库补丁和那份没人爱的接口说明。这个阶段给模型加几条「技能」就够用：帮读日志并排出可疑模块；提重复代码与忙等清单；盯依赖库的变更说明有没有动到你的 API；合并完顺手补一段对外可读的小结，别让 README 还停留在去年的截图。

冗余和性能：让模型先做静态巡检，但真正拍板要结合板上 CPU 占用曲线和端到端延时；别把「读起来顺」当成了「跑得稳」。

疑难定位：把人读不完的日志和它整理成的时间线并排看，模型的价值是列出「先试这几刀」的假说，你还要用断点、strace、perf、示波器等工具把猜想钉死。

依赖升级这类活，AI 可以提前写升级前后差异草稿，顺带列出重新交叉编译的步骤，最后仍要人在板子上跑一晚上压力。

文档同步是最容易拖后腿的事：定下规矩——凡是合并改了对外接口或配置项语义，就由模型自动生成一条「对用户可见变更」加到发布说明末尾，再在知识库里挂一条可复制链接。拍板该不该升库、修了会不会影响实时性与内存峰值，始终把钥匙留在人这边。

下面这张是「出事时怎么问」的简单决策枝，专治慌。

Agent 规范

谁是「机长」要写清楚：管理员握着技能表的增删旋钮，同时维护团队提示范本和审核规则；

资深同事可以拉模型起框架或大改蓝图；

其他同学多用模型写测试脚手架、格式化文档、做小工具。普通权限不要直接触碰技能配置，更别把未审过的生成物推到主线——这点写进门禁比写进倡议书管用。

提示词别再各写各的，统一留个五件套：场景类别（搭架子、补缺、救火、裁剪）、环境与工具链口令（板卡、系统、编译器后缀）、需求粒度（模块和功能边界写得像验收条款）、输出形态（只要头文件还是先给补丁）、硬性禁区（比如禁止无脑阻塞读、禁止 C++17 结构化绑定这类团队没启用的甜点）。

拿去排查线上崩溃时再加一句：「修复不得以牺牲峰值内存为代价」，模型就不会甩给你一个「加个缓存就好」的小学生答案。

审查分成三级就足够：一级盯语法和规范；二级盯线程、外设异常路径和配置默认值；改动面铺开或牵涉依赖大版本时再拉到三级。谁心里发虚谁就把审核往上塞，别怕麻烦。

关于风险，心里有根弦：核心业务别指望模型端到端写完；敏感算法、密钥处理、牵涉安全的逻辑别交给模型「自由发挥」；出厂镜像前必须经过长时间抖动与断电类场景；源码里写明「此处经模型辅助、人工复核」可比口头交代靠谱；缓冲区、权限、sprintf 这类老熟人还要偶发人工巡检。

配置文件里该出现 IP、波特率、话题名就走外部配置加载，别把魔法数留在生成片段里。

该用的、不该用的、出了事先摸哪里：

落地前自检可抄到小本本：

板卡口令写清楚再提示模型；

壳子审过再上肉；

资源与依赖每轮过目；

线程和 IO 设硬顶；

动三方库前先 diff；

生成片段写清出处并完成人审；

涉密段落坚持手写双人走读。

做到这些，AI 才像靠谱的夜班工友，不至于变成第二天的惊吓包裹。

一份打通“应用→驱动”的Linux底层修炼指南！