1. 量产交付全景导入

智能驾驶感知项目的量产交付，本质上不是“把算法做出来”，而是把一套在实验室里能跑通的感知能力，变成能在客户整车上、在真实道路环境中、在既定成本与法规约束下稳定运行，并且可以被持续维护和升级的量产软件。Bosch作为Tier-1供应商，交付对象通常不是终端消费者，而是整车厂（OEM）。这意味着感知项目从立项第一天起，就同时受到技术指标、客户节点、功能安全、信息安全、质量体系和供应链节奏的多重约束。

先看业务背景。一个典型的Bosch智能驾驶感知项目，往往围绕前视摄像头、毫米波雷达、超声波雷达，或它们的融合方案展开。以L2/L2+量产项目为例，感知系统需要输出车道线、车辆、行人、两轮车、可行驶区域、交通标志等目标信息，并通过域控制器或独立ECU把结果送给规划控制模块。OEM关心的不只是“识别率”，还包括误报率、漏报率、响应时延、功能可用范围（ODD）、失效降级策略，以及整车生命周期内的OTA升级能力。因此，感知交付的实质是“可量产、可验证、可维护的软件产品交付”。

交付目标可以拆成四个层次。第一层是功能目标：在定义好的场景和ODD内，感知输出满足客户需求规范中的性能指标。第二层是质量目标：软件满足ASPICE过程要求，关键安全相关功能满足ISO 26262的ASIL等级要求，网络安全满足ISO/SAE 21434。第三层是节点目标：在SOP（Start of Production）之前完成A样、B样、C样到量产版本的逐级交付，每个节点都有明确的软件版本、数据记录、测试报告和问题关闭率要求。第四层是成本与可制造性目标：算法要能部署到目标芯片上，满足算力、内存、功耗和成本约束，不能只在服务器上“跑得好看”。

核心角色方面，Bosch内部通常由项目经理（PM）统筹交付节奏，系统工程师负责需求分解与接口定义，感知算法团队负责模型与后处理，软件团队负责嵌入式部署与集成，测试与验证团队负责台架、HIL、实车和数据回灌，功能安全与网络安全团队负责安全论证，质量团队负责过程合规。对外，OEM的电子电气架构、整车集成、测试认证和采购团队会深度介入。一个常见的误区是“算法强就能交付”，实际上量产项目里，接口对齐、版本管理、问题闭环和客户沟通往往比单点算法指标更决定成败。

端到端流程总览可以用一条主线理解：需求与场景定义 → 系统架构与接口设计 → 算法开发与数据闭环 → 软件集成与嵌入式部署 → 台架/HIL/实车验证 → 客户节点交付与问题关闭 → SOP与量产维护。下面这张图把这条主线、关键输入输出和角色协作关系放在一起，便于建立整体认知。

把这张图读透，就能理解为什么量产交付需要“端到端”视角。比如需求阶段如果ODD定义模糊，后面算法团队可能用大量数据训练了一个在客户实际场景中很少触发的功能；接口阶段如果信号矩阵没有对齐，集成阶段就会出现“算法输出正确但整车收不到”的问题；验证阶段如果只做台架不做实车，就可能漏掉光照、雨雾、隧道进出等真实工况。每个环节的输入输出都必须可追溯，问题才能闭环。

再落到具体操作层面。假设一个前视摄像头感知项目进入B样阶段，典型的一周工作节奏可能是：周一确认客户新提交的DBC信号变更，系统工程师更新接口文档；周二算法团队用上周实车回灌数据复现两个漏检场景，调整后处理阈值；周三软件团队把新模型量化部署到目标芯片，记录推理时延和内存占用；周四测试团队在HIL台架跑回归用例，重点看车道线曲率输出和车辆横纵向距离误差；周五项目经理汇总问题清单，向客户同步关闭率和风险项。这个节奏里，任何一环的延迟都会直接压缩下一环的验证时间。