Air 系列的工程结构约定

Air 系列的工程结构约定：90 个工程长在同一个骨架上——看懂一个工程，就能看懂全部。

▍统一的工程骨架
一个 Air 工程的标准目录：壳层工程（ArkTS 的入口模块——页面、生命周期、系统桥的壳）；native 目录（原生侧的全部——源码、补丁集、构建脚本、产物组织：移植的主战场）；patches（对上游与框架的补丁集——不动共享副本的纪律落地：补丁篇的体系）；脚本层（构建、部署、验证的脚本化——一键出包的通道）；文档层（工程的状态与实录——移植档案的可追溯）。

▍约定的价值
上手的速度（结构即地图——接过一个新工程，目录结构就是导航：知道去哪找什么）；工具的通用（结构统一的工具复用——一套脚本适配全家族的工程：效率的复利）；经验的流动（同构的踩坑可复制——A 工程的修复经验直接映射到 B 工程：90 个工程的学习曲线是共享的）。

▍关键的结构约定
补丁与源码分离（上游源码不动——修改全走补丁集：升级与审计的基础纪律）；构建产物的前缀管理（依赖的私有前缀——共享栈的链接与私有补丁的隔离：依赖篇的体系）；验证链的固化（构建部署验证的命令——换进程验证与行为签名的纪律：验证不是随兴是流程）；实录的登记（工程状态的如实记录——做到哪、缺什么、为什么：S14 映射表精神的工程化）。

▍为什么值得你知道
开发者参考（给你的鸿蒙工程一个结构参照——90 个工程验证过的骨架：拿去省你自己的试错）；贡献者入门（想参与某个工程——结构约定就是地图：按图索骥找你的兴趣点）；用户理解（应用的边界与状态在哪查——工程实录的登记：透明度的载体）。

▍一句话
结构约定是 90 个工程的宪法——骨架统一，血肉各异，经验互通。

更多工程细节欢迎到 apps 板块翻看 56 篇实录。