SYSTEM ARCHITECTURE & ENGINEERING METHOD
架构不是一张图，
是一组有依据的取舍。
面对机器人、汽车电子与智能硬件中的复杂问题，我们先看清需求、约束与系统边界，再决定模块如何划分、变化由谁承担、结果怎样验证。
先定义问题，再选择实现
同一块芯片，
可以长成完全不同的系统。
器件选型、代码框架或工具链都只是实现手段。真正影响系统能否演进的，是业务语义是否清楚、软硬件边界是否合理、共性与差异是否被放在正确的位置。
因此，立芯不把某一套架构当成所有项目的标准答案。实时性、成本、团队规模、维护周期和验证条件不同，设计结论也应该不同。
01 / 通用分层视角
从业务到器件，
每一层回答不同的问题。
这张图用于解释方法，不对应任何一个项目的实际架构。真实项目会根据需求合并、拆分或省略层级。
解释方法的通用示意图，不对应某一项目的实际架构。
02 / 从分层到平台化
复用不是目的，
控制变化才是。
先把职责说清楚
业务逻辑不直接关心寄存器，硬件驱动不替产品做业务决定。先建立可讨论的边界，再谈代码复用。
把稳定的共性留下
当多个产品确实共享通信、设备管理或数据语义时，再把共性沉淀为平台，避免为了“平台”增加无谓复杂度。
让系统状态可理解
用明确的对象、状态和数据关系表达设备与业务，让调试、测试和后续扩展有共同语言，而不是散落在各处判断。
03 / 科学开发过程
验证不是最后一道工序，
它贯穿每一次设计决定。
需求与约束
明确使用场景、外部系统、实时性、成本、安全和维护要求，把未知项单独列出。
系统分解
划分业务、软硬件和外部接口，识别关键链路、风险与需要优先验证的假设。
详细设计
让电气、结构、驱动、通信和控制设计相互对齐，记录关键取舍与版本差异。
分步实现
优先打通高风险链路，再扩展功能。每个阶段保留可运行、可回退、可检查的状态。
台架与调试验证
结合日志、波形、通信记录和真实台架确认现象，区分单点验证、子系统验证与整机验证。
复盘与迭代
把问题追溯到需求、设计或实现，不用一次性“跑通”替代持续验证，也不把阶段结果包装成商业交付。
04 / AI 有界协作
让 AI 加速实现，
不让它替代工程判断。
边界先由人定义
需求、架构、接口和验证标准由工程师明确，AI 在上下文充分、范围可控的任务中辅助实现。
生成结果必须被检查
代码、文档和分析需要经过审阅、构建、静态检查或真实测试，不能把“看起来合理”当成正确。
责任仍在工程闭环
涉及硬件、电气、通信和系统安全时，最终判断必须回到真实约束和可复现证据。
方法如何落到材料
从设计文档，
走到实物与阶段测试。
方法是否有效，不看术语数量，而看能否形成清晰的设计、可追溯的版本和与实际阶段相符的验证材料。