结论：EdgeForge 的「自编译」不是把 Clang 塞进 MCU，而是让设备自己把一份受限描述语言编译成字节码——基础示例的 88 字节 EFIR 在端侧生成 36 字节 EdgeVM 代码，且与 Node 参考编译器的输出逐字节一致。这样页面、规则、阈值、迟滞与窗口统计的改动都不再需要重刷整机固件，只有外设驱动、协议栈、VM 漏洞修复才走固件更新。
为什么不在 MCU 上放完整 C/C++ 编译器
因为 ESP32-S3、STM32 和 RP2040 的内存、存储和安全边界不适合长期携带完整 Clang / GCC、系统头文件、链接器和动态加载器。
源方案书写得很直接：即使勉强运行，编译延迟、RAM 峰值、ABI、恶意代码和崩溃恢复都会使产品难以量产。EdgeForge 采用的是受限自编译——把链路切成「描述语言 → 检查 → 平台无关 IR → 能力链接 → 字节码 / Wasm / 预审原生模块 → 签名安装」，MCU 端只负责最后一段：把 IR 快速编译成 EdgeVM 字节码并执行。复杂算法交给 Linux、Android 上的 Wasm，或可信工业场景下的预审原生模块。
AI 在这个框架里的输出也是描述语言，而不是代码：AI 不能直接输出设备可运行的 C、JavaScript、Shell 或原始总线指令，只能产出 EdgeSpec 提案。即使不启用大模型，Studio 的表单和规则编辑器也能生成完全相同的 EdgeSpec。
哪些改动从此不必重刷固件
因为框架把「应用功能」与「平台能力」分开，前者可动态编译，后者仍需固件或系统更新。这条边界是承诺成立的前提：
| 可动态编译（不重刷固件） | 仍需固件或系统更新 |
|---|---|
| 页面与组件、信号绑定、单位显示 | 新外设驱动 |
| 阈值与迟滞、窗口统计、数据记录策略 | 新无线协议栈 |
| 经过允许的信号解码、设备选择、本地提醒 | 底层 CAN / USB / 显示驱动 |
| 有限状态机、经过审核的 Wasm 算法 | VM 漏洞修复、加密库更新、启动链与电源管理逻辑 |
所以正确的宣传口径是「多数应用功能无需重编译整机固件」，而不是「以后永远不更新底层软件」。这个边界与 OBD AI 插件化平台 里给出的分层判断是同一逻辑：能否插件化，取决于宿主是否已提供相应底层原语。
从 EdgeSpec 到 36 字节字节码：链路上各产物有多大
因为「链路短」是可以量化的，源方案给出了各阶段的真实字节数，全部来自当前原型而非估算：
| 场景 | EFB 功能包 | EFIR 链接 IR | EdgeVM 字节码 | 签名 EFP |
|---|---|---|---|---|
| 基础示例应用（ESP32-S3） | 2,519 字节 | 88 字节 | 36 字节 | 3,421 字节 |
| Studio 四规则草稿 | 3,715 字节 | 212 字节 | 132 字节 | 4,742 字节 |
| 8 样本平均窗口规则 | 2,294 字节 | 58 字节 | 20 字节 | — |
关键在于端侧编译器的工作方式：它使用定长头与任务表，表达式只包含有限 opcode，事件动作使用索引表；ESP32、STM32 和 RP2040 的 C99 编译器在调用者提供的固定缓冲区内把 EFIR 转成字节码，不申请堆内存，也不携带 C/C++ 预处理器、汇编器或链接器。原生测试证明端侧输出与 Node 参考编译器逐字节一致。当前 EFIR 已覆盖基础表达式、信号有效性、本地事件、带固定状态槽的 GATE 持续条件、数值型低阈值 / 高阈值迟滞，以及固定样本数的 window_avg / window_min / window_max；通用状态变量与 UI 更新算子仍待扩展。
包格式方面，当前 .efb v2 为「24 字节头 + 规范 JSON manifest + 二进制 EIDX v2 运行索引 + EdgeVM 字节码」。JSON manifest 供 Studio、诊断与审计使用，而 MCU 启动关键路径只需解析定长的 EIDX 记录，不需要携带通用 JSON DOM；加载器不使用堆内存，可验证包头、记录范围、字符串范围、任务连续性、UI 重叠与边界、栈深、跳转边界、信号 / 事件索引、opcode 与指令预算。
EdgeVM 靠什么把插件关在笼子里
因为「小体积」和「不拖垮宿主」是两件事，所以 EdgeVM 的设计目标是 C99 可移植、核心运行时保持在几十 KB 以内、使用固定或受限栈、不做运行时任意堆分配。每次任务有指令预算、墙钟预算和输出预算；非法 opcode、越界跳转、栈溢出和包截断会立即停止当前插件；关键采集线程不执行用户字节码。
持续条件与迟滞是最能体现「有界」的两个机制。每条 pipeline 使用一个固定状态槽：条件连续成立 for_ms 后才通过；repeat_ms = 0 时本次条件保持期间只触发一次，大于 0 时按该间隔重复。低阈值在 < threshold 时进入、到 >= threshold + hysteresis 时恢复；高阈值在 > threshold 时进入、到 <= threshold - hysteresis 时恢复。使用迟滞的包要求 Host API 1.2.0，使用窗口的包要求 signal.window 能力与 Host API 1.3.0，旧包继续兼容。Studio 的四规则草稿里，四条 pipeline 均记录 for_ms = 3000、repeat_ms = 0、hysteresis = 0.1 bar。
调度器负责合并相同信号订阅、按信号实际频率运行规则、超额时跳过低优先级任务而不阻塞采集，并记录执行耗时、峰值栈、失败原因与连续超限次数；多次越限后禁用插件并回退到已知可用版本。包卸载、A/B 切换或重新加载时必须清零状态槽，不能让旧版本的持续时间状态泄漏到新版本——这是「有界执行」之外容易被忽略的一条。
五个平台的目标构建已经闭环，但还没有上实板
因为「编译链接通过」与「实机运行通过」是两回事，源方案把两者分得很清楚。当前状态是：本地 Studio、通用 MCU Host 及五个平台的软件目标构建链已经闭环。
| 平台 | 工具链 | 构建产物 | 余量 / 边界 |
|---|---|---|---|
| ESP32-S3 | ESP-IDF 5.3.2 / Xtensa ESP GCC 13.2.0 | 应用 .bin 550,112 字节（镜像内容 550,004 字节） | 1.5 MiB factory 分区剩 1,022,752 字节（约 65%） |
| RP2040 | Pico SDK 2.1.1 / Arm GNU Toolchain 14.2.1 | .bin 85,776 字节，.uf2 172,032 字节 | 功能包预留区自 0x101b2000 起，按 256 字节块补齐后余 1,691,648 字节 |
| STM32F429ZI | STM32CubeF4 HAL / Arm GNU Toolchain 14.2.1 | BIN 37,024 字节，RAM 使用 49,776 字节 | 到 Bank 2 起点 0x08100000 余 1,011,552 字节 |
| Linux ARM64 | AArch64 Linux，-O2 与最高警告等级 |
16 个对象链接为 4,798,248 字节完整 ELF | 待 ARM64 目标机运行验证 |
ESP32-S3 侧的余量值得单独看：DIRAM 使用 151,255 / 341,760 字节，专用 16 KiB IRAM 段只剩 1 字节；EdgeForge 组件占静态 RAM 60,808 字节、链接 Flash 31,733 字节。这些数字说明片内 RAM 是真正的约束——加入显示、触摸或 Wi-Fi 后必须重新链接，并在实板测量最小空闲堆、任务高水位、连接恢复、总线错误、刷新抖动与 CPU 占用。
通用 MCU 侧的做法是不为每个芯片重写加载逻辑：STM32、RP2040、RP2350 与其他 C99 MCU 共用 hosts/mcu-common 无堆 Host，平台层只实现五类接口——双槽 Flash 与 96 字节事务状态记录、SHA-256 / Ed25519、UART / USB / BLE EdgeDeploy、单调时钟、具体传感器与显示驱动。启动链固定为「读取活动 A/B 槽中的 EFP → 校验目标 / Host API / 能力 / 摘要与签名 → 验证 EFB / EIDX → 解析 EFIR → 设备内编译到 RAM → 逐字节核对与签名 EFB 一致 → 执行」，任何不一致都拒绝加载。RP2040 的原生生命周期测试已安装三个签名 EFP，把 88 字节 EFIR 编译为 36 字节代码，输入 tpms.fl = 2.1 bar 触发低胎压事件并生成 4 个 UI 组件。
必须说清楚的边界：ESP32-S3、STM32F4、RP2040 的实物烧录与启动验证尚未完成，Linux ARM64 目标机运行、EdgeDeploy 的真实 UART / BLE / USB 传输、掉电工装、具体 LCD 控制器与触摸、Android 实机兼容性也都在未完成清单里。自动测试当前共 46 项，本机 44 项通过，Linux POSIX 与 SocketCAN vcan0 两项集成测试在非 Linux 主机按条件跳过。显示链路的帧率口径可对照 车载 HMI 的 30 FPS：SPI 与 MIPI-DSI 显示链路差在哪，其中说明了 30 FPS 属验收目标而非硬件事实。
签名只证明来源，不代表授权
因为签名解决的是「包有没有被篡改」，而权限解决的是「这个包被允许做什么」，两者不能互相替代。当前 EFP v2 同时包含 EFB 与 EFIR，Ed25519 签名覆盖包头、ESEC 安全索引、审计 JSON 以及两个产物；ESEC 为 MCU 提供不依赖 JSON 的目标平台、应用版本、发布序列、密钥 ID、最低 Host API、能力清单和两个 SHA-256 摘要。但框架明确规定，实际权限是五项的交集：
包声明 ∩ 发布者权限 ∩ 用户授权 ∩ 设备能力 ∩ 平台策略
也就是说，签名证明来源和完整性，不代表插件自动获得其清单中请求的所有权限。包状态用 active / candidate / last-known-good 三态管理，固件用 A/B 槽；升级过程任意断电点都要能恢复到确定状态，回退受最低安全版本限制，不能恢复已撤销的漏洞版本。设备适配器与用户功能包也分开：用户可以把已注册的胎压信号放到任意页面，但不能因为改页面而获得原始射频、任意 BLE 写入或 CAN 发送权限。采集设备选型与信号质量的口径可参照 SR-RaceBox 车载数据采集器；屏幕形态与可读性的取舍见 圆屏还是方屏：车载仪表的显示形态该怎么选。
常见问题
EdgeForge 的「自编译」是要在 ESP32 上跑 C 编译器吗？
不是。MCU 端只把平台无关 IR 编译成 EdgeVM 字节码，在调用者提供的固定缓冲区内完成，不申请堆内存，也不携带 C/C++ 预处理器、汇编器或链接器。完整 C/C++ 编译只在受控的构建服务或高性能平台上考虑。
免重刷固件能免到什么程度？
页面与组件、信号绑定、单位显示、阈值与迟滞、窗口统计、记录策略、经过允许的信号解码、有限状态机和经审核的 Wasm 算法都可以动态编译。新外设驱动、新无线协议栈、底层 CAN / USB / 显示驱动、VM 漏洞修复、加密库更新、启动链与电源管理逻辑仍需固件或系统更新。
五个平台的构建都已经验证过实机了吗？
还没有。当前完成的是软件目标构建链闭环，包括 ESP32-S3、RP2040、STM32F429ZI 与 Linux ARM64 的目标编译链接。ESP32-S3、STM32F4、RP2040 的实物烧录与启动验证，以及真实 UART / BLE / USB 传输、掉电恢复、具体 LCD 与触摸，均在未完成清单中。
插件包签了名，是不是就拿到了清单里申请的全部权限？
不是。实际权限取「包声明、发布者权限、用户授权、设备能力、平台策略」五项的交集。签名只证明来源和完整性，宿主必须独立拒绝所有未开放的操作。
本文数据来自星核火花赛车科技内部 EdgeForge 自编译软件框架方案的 V1.4 稿（2026-09-21，状态为固定容量窗口统计、Studio 软件闭环、通用 MCU 自编译 Host 及五类常见硬件平台目标构建通过）。文中字节数、Flash / RAM 占用与余量均为该稿记录的原型构建结果，属软件目标构建证据，不证明开发板启动、掉电行为或实机传输；ESP32-S3、STM32F4、RP2040 的实物烧录与启动验证尚未完成。所述权限交集与实际授权行为以正式 SDK 与发布流程为准。