理想用AI做代码审查覆盖率100%(人只能70%)2026年3月24日李想汽车硅基研究所发文《告别“人肉适配”：理想汽车在大规模交付中的硅基经验》理想工程师认为理想核心竞争力是支撑规模化作战的工程体系。

压缩版：理想业务版图从单一芯片、少量项目变为到多平台、多项目并行交付的规模化作战阶段。

传统平台软件开发中，新增一个芯片平台适配，通常需要3-6个月移植周期。

痛点是低逻辑复用，高手工编码。工程师40%-60%精力在改参数、调接口、逐项目验证等重复性配置上。

代码审查过去高度依赖资深工程师人工逐行检视，工具只能检查语法规范，读不懂业务逻辑缺陷，人工审查覆盖率通常只能60%-70%。

理想自研自动化工具链。工程师只需维护和更新需求配置文档，即可自动生成ARXML配置文件，并进一步自动生成.c/.h源代码，实现从需求到代码的贯通。开发周期从天级压缩至小时级。

静态资产与动态配置完全分离：平台资产层（静态代码）：沉淀专家核心逻辑，包括最底层的程序流、复杂的协议栈逻辑。需求配置层（动态代码）：将与具体芯片、具体项目相关的参数抽离，形成标准化的配置模板。

通用AI读不懂车载底层软件约束。理想将积累的技术规范、平台约束、历史复盘中的避坑指南转化为Agent Skill。

车载软件忌讳多线程调用不可重入接口，人工审查几十层嵌套的逻辑链路极其困难，AI在代码合入瞬间识别出调用链路中的冲突隐患。让资深开发头疼的底层接口隐患、内存溢出风险，在合入前就 AI 100%物理拦截。

支撑并行项目数量翻一倍有余，新需求响应从数天至几小时。

车载控制器不同于互联网应用，缺乏随时可查看的云端日志流。软件一旦上车，进入黑盒运行环境。大多数团队遵循用户反馈→问题单流转→现场接线→模拟复现 / 提取日志问题排查链路。

每一个环节间都存在时差。感知滞后，车辆缺乏主动上报能力，发现问题全靠测试反馈或投诉。证据缺失，偶发性Bug往往没有记录触发瞬时的上下文数据，导致工程师在实验室里跑数天也难以复现。

受限于MCU算力资源极其有限、数据通道带宽成本高敏感、以及各模块数据协议不统一，行业普遍做不到数据实时化，停留在事后离线分析阶段。

理想用一套类似于黑匣子的机制。一旦系统出现Trap或重启，底层探针会瞬间抓取当时的内存快照，并配合性能上下文实时上云。底层开发范式从防御性救火到主动式治理。定位用户问题平均时长从周级到小时级。

车载软件的复杂度曲线已经远超人力投入的产出曲线。旧范式下招更多人只会让系统变得更加臃肿。

解决规模化焦虑的唯一解是将从不可控的人力转化给可进化的系统。理想决心花笨功夫构建自动化工厂。

理想汽车理想汽车