NO.A0 嵌入式 AI 算法开发的工业化（开篇）：用「平台 + 模板仓」两层架构搭一个团队开发范式

⚠️ 法律与用途声明：本系列基于一套开源工具链（Conan 2 / Artifactory CE / GitHub Actions / Docker / CMake 等）讨论企业级嵌入式 C/C++ 与 AI 算法的开发范式与平台工程，仅用于技术学习与工程研究。所有企业名、域名、IP、账号、凭据均已脱敏。读者须遵守所在地区法律法规，作者不对读者使用方式负责。

一、痛点：嵌入式 AI 算法交付的四重困境

做嵌入式 AI 的人大概都经历过这种场景：算法工程师在自己机器上把模型跑通了，精度达标、延迟可接受。然后呢？

团队复用难：同事想用这个算法，拿到的是一堆散落在各处的源码、依赖说明、构建脚本，版本对不上、环境配不通，重头踩一遍坑。
跨平台构建难：同一个算法要跑在 Linux x86、Cortex-A Linux、Cortex-M 裸机上，工具链、libc、链接器各不相同，交叉编译像玄学。
版本追溯难：到底哪个版本的算法上了哪块板？谁改的、为什么改、能不能回滚？靠人脑记忆和文件夹命名撑着。
上板验证难：编译通过不等于板子上跑得通。性能数据靠手工烧录、手工记录、手工对比，没有基线、没有回归、没有自动化。

这四个"难"叠加起来，嵌入式 AI 团队的真实状态往往是：每个人都在重复造轮子，算法交付靠个人英雄主义，团队没有沉淀、没有复用、没有质量基线。

本质问题不是"算法写不出来"，而是缺少一套让算法能被团队复用、跨平台构建、版本可追溯、上板可验证的工业化体系。

这个系列要回答的，就是怎么搭这样一套体系。

二、解法：两层架构——平台 + 模板仓

我们的答案是两层架构：

平台层：团队共享的 DevOps 基础设施。它提供私有制品库（Artifactory CE + Conan 双 remote）、CI 调度（GitHub self-hosted runner）、交叉编译执行（Docker 三层模型）、上板验证链路。它解决怎么构建、怎么发布、怎么验证的标准答案。
模板仓：每个算法 / SDK 仓库的出生模板。它自带 Conan recipe、CMake 框架、文档系统、测试骨架、benchmark 框架、自动版本发布。它让每个算法仓库生来就合规，开发者只写算法、不碰基础设施。

打个比方：平台是"开发区"，把水电气路（CI、制品库、构建环境、上板测试台）铺好；模板仓是"标准厂房图纸"，每个新算法项目按图纸建厂，水电接口天然对齐开发区。

关键在于：两层是解耦的，但靠契约对话。

平台不知道模板仓里有什么业务算法；
模板仓不感知平台内部脚本细节；
它们只通过两个声明式文件交流：configs/build-matrix.yaml（算法仓库声明"我要在哪些平台构建、要不要上板测"）和 metadata.json（声明"我叫什么、版本多少、依赖什么"）。

这种"平台演进、业务无感"的分层，是整套体系能长期演进、能推广到新团队的根本。

三、6 层 CBB 模型：从接入到模板的完整闭环

把两层架构展开，平台侧可以细成 6 个内聚的能力层（CBB，Common Building Block），每层各司其职：

层	职责	代表组件	解决什么
接入层	让开发者最低成本用起来	Token Broker 自助 token、Conan 双 remote	不碰 admin 密码、一条命令登录
调度层	统一 CI 入口	GitHub Actions workflow、self-hosted runner	声明式触发、调度与执行分离
执行层	可复现的交叉编译	Docker 三层模型（纯净镜像 / 模板缓存 / 即时容器）	环境 zero 污染、用完即毁
制品层	可追溯的包仓库	Artifactory CE、recipe sources 归档	制品真源唯一、源码随包
验证层	上板自动验证	board 三键模型、benchmark 框架、watcher	从能构建到能验证
模板层	能力下沉到业务	模板仓、build-matrix.yaml、CI 模板	业务只声明、不感知内部

这 6 层不是技术堆砌，而是一条数据流的 6 个阶段：开发者提交代码 → 接入层鉴权 → 调度层触发 CI → 执行层在 Docker 里交叉编译 → 制品层归档包 → 验证层上板测试 → 模板层让这一切对新仓库自动生效。

每一层都遵循"高内聚、低耦合"：层内自治，层间靠标准接口（API、声明式文件、协议）通信。这意味着任何一层都可以独立演进甚至替换（比如把 Docker 换成 Podman、把 Artifactory 换成 JFrog Pro），而不牵动其他层。

四、解耦不是零耦合，而是"靠契约的合理耦合"

架构师最常被问的问题：平台和模板仓到底怎么解耦？解到什么程度？

答案是：解耦不是零耦合，而是把耦合点收敛到少数几个声明式契约上。

两个核心契约：

configs/build-matrix.yaml（算法仓库 → 平台）：算法仓库声明"我要在 linux-armv7、baremetal-cortex-m4 这些目标上构建，工具链用 11.3.rel1，要开 benchmark"。平台读到它，展开成 CI 矩阵。算法侧不知道平台用 Docker 还是 Podman，平台不知道算法里写了什么。
metadata.json（算法仓库 → 平台 + 自身构建系统）：声明包名、版本、依赖、C++ 标准、文档语言、测试开关。Conan recipe 从它继承一切，平台 CI 从它读包元数据。

契约之外，两层互不干涉：

平台的 CI 脚本、缓存策略、上板逻辑，永远不暴露给业务仓库——业务只引用 workflow 模板（workflow_call）。
业务的算法代码、依赖选择、benchmark 用例，永远不感知平台内部路径。

这种"合理耦合"的度，是整套体系能规模化（推广到几十个算法仓库）的关键：契约稳定，则平台和业务可以各自狂奔。

五、贯穿全系列的架构哲学

这套体系不是工具的随机组合，而是被几条清晰的工程哲学贯穿。后面每一篇都在落地其中一条：

高内聚低耦合：6 层各管一摊，靠接口对话（本篇、平台篇 01、耦合篇）。
声明式优于命令式：描述"要什么"而非"怎么做"（build-matrix、metadata 驱动）。
单一数据源：一个 metadata 驱动 Conan / CMake / 文档 / CI，消除配置漂移（模板仓系列）。
可复现、可缓存、可销毁：构建即用即毁、加速层可从真源重建（平台篇 02 / 03）。
制品真源唯一：Artifactory 是源，缓存是影（平台篇·制品库）。
构建自动、发布谨慎：CI 产候选，人工确认才发布（人工晋升门禁）。
平台演进、业务无感：下游只看模板，不碰内部（模板化推广）。
实例级隔离：GitHub re-run 不污染旧产物（三键模型）。

记住这八条，就抓住了整个系列的"骨架"。工具会变（Conan 版本升级、Docker 换 Podman、runner 扩容），但这些哲学是稳定的。

六、系列路线图

本系列分两个子系列，在一个大体系下推进，共 28 篇：

子系列 A · 平台基础设施：从 self-hosted runner 架构讲起，覆盖 Docker 三层构建、缓存治理、私有 Conan Center、交叉工具链、Token Broker、制品真源、人工晋升、Build Registry、上板三键模型、benchmark CI，最后收束到模板化推广。讲的是"地基怎么搭"。

子系列 B · 算法仓库模板：从 template repo 与 metadata 单一数据源讲起，覆盖企业 Conan 包规范、semantic-release 自动版本、C/C++ 双接口、baremetal 兼容、C++23 Modules、文档即代码、测试体系、benchmark 双目标框架。讲的是"标准厂房图纸怎么设计"。

中间有一篇耦合篇，专门拆解平台 × 模板仓的解耦边界与契约设计——这是架构师视角的核心。

两个子系列的关系是：A 是地基，B 是建筑。地基先铺（让你知道构建 / 发布 / 验证的标准答案在哪），建筑再起（让每个算法仓库长在标准地基上）。读完整个系列，你会得到一套完整的"嵌入式 AI 算法团队开发范式"——它不是某个工具的教程，而是一套可以被复制、被演进、被治理的工程体系。