ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

自动驾驶生态圈实战:从百度英飞凌合作看软硬件协同开发

自动驾驶生态圈实战:从百度英飞凌合作看软硬件协同开发 1. 从CES看生态合作自动驾驶的“新玩法”每年一月的拉斯维加斯国际消费电子展早已不是电视和手机唱主角的舞台。这几年CES最热闹的展区一定是被各种自动驾驶概念车、激光雷达阵列和智能座舱方案挤得水泄不通。但如果你仔细观察会发现一个有趣的变化几年前车企和科技公司都喜欢单打独斗摆出自己的“全栈自研”方案恨不得把Logo印在车的每一个角落。而最近几届CES尤其是围绕“CES-百度英飞凌共创自动驾驶生态圈”这个主题大家谈论的核心词变成了“生态”、“共创”和“朋友圈”。这背后反映的是自动驾驶行业一个根本性的认知转变。自动驾驶的复杂程度远超任何一家公司能够独立覆盖的范畴。它横跨了感知、决策、规划、控制、芯片、软件、云、地图、安全等数十个专业领域。一家公司哪怕是巨头也很难在每一个环节都做到世界顶尖。于是一种新的产业协作模式——“生态圈”打法开始成为主流。百度、英飞凌在CES上的携手正是这种模式的典型缩影。百度作为中国领先的AI和自动驾驶平台公司拥有“阿波罗”开放平台在算法、高精地图和云端数据闭环上积累了深厚能力。而英飞凌则是全球汽车半导体领域的隐形冠军其微控制器、功率半导体和传感器是车辆实现稳定、可靠控制的物理基石。他们的合作绝非简单的“你卖芯片我用平台”的买卖关系。这个“生态圈”的核心逻辑在于将百度的算法和软件能力与英飞凌的硬件和芯片级安全特性进行深度耦合。比如百度的感知算法需要高效地运行在英飞凌的AURIX™系列微控制器上这就涉及到算法模型的优化、编译器的适配、内存的分配等一系列底层工作。再比如英飞凌的硬件安全模块如何与百度的云端安全体系对接共同构建从车端到云端的可信执行环境。这种共创目标是为车企和一级供应商提供一个“开箱即用”程度更高、安全认证基础更牢靠的自动驾驶解决方案缩短他们的开发周期降低集成风险。所以当我们谈论“CES-百度英飞凌共创自动驾驶生态圈”时我们实际上是在解剖一个经典的产业合作案例在技术壁垒高筑、供应链要求严苛的智能汽车时代如何通过强强联合、优势互补共同把蛋糕做大而不是在存量市场里互相厮杀。这对于行业内的开发者、创业者甚至是关注科技趋势的普通人来说都是一个值得深入理解的信号未来的竞争将是生态与生态之间的竞争。2. 拆解生态圈的三层核心架构一个健康的生态圈不能只是口号上的联合必须有清晰、坚实的架构支撑。百度与英飞凌的共创生态我们可以从硬件基石、软件中间件与工具链、以及云端数据闭环这三个层层递进的维度来理解其核心架构。这就像盖房子英飞凌提供了坚实的地基和承重结构硬件百度则提供了标准化的水电管线、门窗框架软件中间件和智能物业管理系统云端让开发商车企能够更专注于房屋的内部装修和品牌特色差异化功能。2.1 硬件基石英飞凌的“铁三角”与可靠性的根源生态的底层是硬件而英飞凌在这里扮演的是“基石供应商”的角色。其产品线构成了支撑自动驾驶尤其是底盘控制和域控制器功能的“铁三角”微控制器、功率半导体和传感器。首先是微控制器尤其是其旗舰的AURIX™ TC3xx/TC4xx系列。这是汽车功能安全领域的“标杆”产品。为什么车企和Tier1敢把刹车、转向这些性命攸关的控制任务交给它核心在于其设计之初就遵循了汽车功能安全最高等级ASIL-D的标准。它内部采用多核锁步架构即多个核心执行相同的代码并实时比对结果一旦出现不一致立即触发安全机制。同时它集成了硬件安全模块能进行加密运算和安全启动确保代码在芯片内部执行时不被篡改。对于百度而言其自动驾驶规控算法最终就要落地到这样的芯片上运行芯片的实时性、算力分配和功能安全特性直接决定了算法执行的可靠上限。其次是功率半导体即IGBT和碳化硅模块。自动驾驶不仅关乎“思考”更关乎“执行”。当决策系统命令车辆加速、制动或转向时最终驱动电机、控制刹车液压力的就是这些功率器件。英飞凌在此领域的优势在于其产品的效率和可靠性特别是在高压平台下碳化硅器件能显著降低能耗提升续航这对于电动智能汽车至关重要。生态圈的合作意味着百度的控制算法输出如扭矩请求、制动压力可以与英飞凌的驱动芯片特性进行更精准的匹配和优化实现更平顺、更高效的动力响应。最后是传感器如雷达芯片。英飞凌提供的毫米波雷达射频芯片是构成汽车“感知”能力的重要一环。虽然百度自身也研发激光雷达和视觉算法但毫米波雷达在恶劣天气下的稳定性和测速测距能力不可替代。生态圈内的合作可以让雷达的原始数据与视觉、激光雷达数据进行更深度的前融合处理提升感知系统的鲁棒性。例如针对英飞凌雷达芯片的噪声特性和探测模式百度的感知算法可以进行针对性优化减少误报和漏报。注意选择硬件合作伙伴尤其是核心控制器芯片时功能安全认证和长期供货保障是比单纯算力参数更重要的考量因素。很多初创算法公司容易忽略这一点导致方案无法通过车规认证。2.2 软件中间件与工具链百度的“阿波罗”如何连接硬件有了坚实的硬件地基就需要一套标准化的“管线”和“工具”来把硬件能力高效、便捷地释放给上层应用开发者。这就是百度“阿波罗”开放平台的核心价值之一——提供统一的软件中间件和成熟的工具链。中间件可以理解为操作系统和具体应用程序之间的“粘合剂”。在自动驾驶领域它负责管理不同硬件资源CPU、GPU、各种传感器的调度处理模块间大量的数据通信如感知结果发给规划模块并提供统一的开发接口。阿波罗平台基于ROS机器人操作系统进行了深度定制和车规级强化提供了诸如Cyber RT这样的高性能通信框架。在百度-英飞凌的生态中一个关键任务就是确保阿波罗的中间件能够完美适配英飞凌AURIX芯片的底层驱动、中断系统和内存管理单元。这需要双方工程师在编译器层面进行深度合作。这里就不得不提“英飞凌tc264的编译器”这个关键词。TC264是AURIX系列中一款经典产品其编译器是将高级语言如C/C代码翻译成芯片能执行的机器码的关键工具。百度的算法工程师用熟悉的框架如PyTorch训练好模型后需要经过转换、量化、编译等一系列步骤才能部署到TC264上运行。这个编译过程绝非简单的点击“编译”按钮。它涉及到代码优化针对AURIX多核架构如何将算法任务并行化分配到不同的核上避免资源争抢和实时性瓶颈。内存优化TC264的片上内存有限编译器需要智能地安排代码和数据的存储位置充分利用高速缓存减少访问外部存储器的延迟。指令集优化利用AURIX芯片特有的DSP指令或硬件加速单元来加速矩阵运算等常见AI计算。生态圈的共创意味着百度可以和英飞凌的编译器团队直接对接将阿波罗框架下常用的算子库进行深度优化甚至共同定义一些编译器的扩展功能使得从算法模型到芯片部署的路径更顺畅、效率更高。这远比开发者自己摸索要高效得多。此外工具链还包括仿真调试工具、标定工具、日志分析系统等。例如英飞凌的调试器如“英飞凌ads下载”中的ADS可能指其开发套件如何与百度的云端仿真平台打通让开发者可以在一个集成的环境里完成代码编写、硬件在环测试和效果验证。2.3 云端数据闭环与生态赋能第三层架构是云端这是生态活力的源泉和价值放大的引擎。百度智能云为这个生态圈提供了数据闭环和持续进化的能力。自动驾驶算法的进化离不开海量数据。车辆在路上行驶会产生海量的感知数据、驾驶行为数据和系统状态数据。通过英飞凌芯片内置的安全通信模块这些脱敏后的数据可以被安全地上传到百度云端。在云端百度的数据平台可以对这些数据进行自动化处理自动化标注利用预训练模型对“自动驾驶数据集”进行自动标注大幅降低人工标注成本这也是“中国自动驾驶数据集”规模能不断扩大的关键。场景挖掘从海量数据中自动发现长尾场景、极端场景Corner Case例如突然横穿马路的行人、特殊天气下的障碍物等。模型训练与评测在云端的超算集群上用挖掘出的新数据持续训练和优化感知、预测模型并通过仿真系统进行大规模评测。训练好的新模型再通过OTA的方式分发给搭载了英飞凌芯片的车辆。这就形成了一个“数据采集 - 云端处理 - 模型优化 - 车端部署”的完整闭环。在这个闭环里英飞凌的硬件确保了数据采集端和模型执行端的可靠性与安全性而百度的云端平台则提供了数据处理和算法迭代的核心能力。更重要的是这个云端平台可以对生态内的其他开发者开放。比如一个专注于“点云分割标注”的初创公司可以将其标注工具接入百度的数据平台为生态内的算法公司提供服务。一个研究“自动驾驶控制”算法的团队可以调用百度提供的标准车辆模型和仿真场景来验证自己的控制算法。这就是生态的赋能效应它降低了单个参与者的创新门槛让大家都能在统一的“地基”上建造自己的“特色房屋”。3. 从概念到落地生态圈如何解决实际开发难题理解了架构我们再来看看这个生态圈具体如何帮助开发者解决那些令人头疼的实际问题。自动驾驶开发不是纸上谈兵每一个环节都充满了“坑”。百度与英飞凌的共创正是在试图填平这些坑提供一条更平坦的“高速公路”。3.1 工具链断裂与开发效率之痛在没有成熟生态支持的情况下一个自动驾驶功能从算法设计到实车落地路径极其漫长且痛苦。算法工程师用Python在服务器上训练出一个表现优异的模型但如何把它变成能在车规级芯片上实时运行的代码这中间隔着编译器、嵌入式驱动、内存管理、任务调度等一系列嵌入式开发的深水区。典型的痛点包括编译器兼容性开源框架如TensorFlow Lite Micro对特定芯片的支持可能不完善或者生成的代码效率低下。调试困难芯片上的程序崩溃了日志怎么打如何在线调试传统的printf方式在实时性要求高的自动驾驶任务中根本行不通。性能瓶颈定位难算法在芯片上跑得慢到底是模型本身计算量大还是内存访问成了瓶颈或者是任务调度不合理缺乏工具定位问题如同盲人摸象。百度-英飞凌生态圈提供的是一套“端到端”的工具链。算法工程师可以在阿波罗的框架下使用相对熟悉的接口进行开发。当需要部署到英飞凌芯片时可以利用双方共同优化过的模型转换工具和编译器。例如针对一个视觉识别模型工具链可以自动完成从ONNX格式到针对AURIX芯片优化后的C代码的转换并给出初步的内存占用和计算耗时预估。调试阶段可以使用集成好的调试插件在IDE中直接查看芯片内部寄存器的状态、任务运行时间线等。这大大缩短了开发调试周期让算法工程师能更专注于算法本身而不是底层移植的泥潭。3.2 功能安全与预期功能安全合规的“护城河”自动驾驶产品要上车必须通过严苛的功能安全ISO 26262和预期功能安全SOTIF认证。这对任何公司尤其是初创公司来说都是一道极高的门槛。自己从头开始构建一个符合ASIL-D要求的软件架构成本和时间都是天文数字。在这个生态圈中英飞凌的AURIX芯片本身已通过ASIL-D认证提供了硬件层面的安全基础。而百度阿波罗平台则在软件层面提供了符合功能安全要求的中间件和软件组件尽管完全达到车规级需要更严格的流程和认证。更重要的是双方的合作模式为车企提供了一条潜在的“合规捷径”。车企在采用这套“芯片基础软件栈”的方案时可以复用英飞凌芯片的大量安全认证资料以及百度在中间件层积累的安全设计文档和测试案例。这相当于生态圈为车企预先扫清了一部分最复杂、最耗时的合规障碍。在应对SOTIF即处理那些系统本身无故障但因性能局限或场景复杂导致的危险情况时云端数据闭环的能力就凸显出来。通过不断收集真实世界的长尾场景数据并在云端仿真中进行测试和优化可以系统地提升系统的预期功能安全水平。生态圈提供了规模化处理SOTIF问题的可能。3.3 成本控制与供应链安全自研一切固然能体现技术实力但也意味着巨大的研发投入和供应链风险。一颗车规级芯片从设计、流片到认证周期长达数年投入以亿计。对于绝大多数车企而言这并不现实。加入一个成熟的生态圈本质上是进行“技术采购”和“风险分担”。车企可以以合理的成本获得经过市场验证、性能可靠的芯片和基础软件。英飞凌作为全球顶级供应商其产能和供应链稳定性相对有保障。百度阿波罗平台的开源和开放策略也降低了软件的授权成本。这使得车企特别是传统车企和新势力能够将有限的资源集中投入到最能体现品牌差异化的领域如整车体验、人机交互、特定场景的自动驾驶功能如自动泊车、高速领航的打磨上。同时生态圈也促进了国内供应链的成长。虽然英飞凌是国际巨头但百度作为平台方可以带动一批国内优秀的算法公司、传感器公司、集成商在这个生态内成长逐渐形成本土化的供应链能力这从长远看也符合产业安全的需求。4. 生态的挑战与开发者的机遇尽管前景广阔但构建和融入一个生态圈也并非全是坦途。无论是对于生态的主导者百度、英飞凌还是对于希望加入其中的开发者都面临着各自的挑战同时也孕育着独特的机遇。4.1 主导者的平衡术开放与控制的边界百度和英飞凌作为生态的核心构建者首要挑战是如何界定“开放”的边界。完全开源、毫无约束可能导致生态内方案碎片化、质量参差不齐最终损害整个生态的品牌和可靠性。但过于封闭和控制又会扼杀创新活力让生态失去吸引力。百度的阿波罗平台采取的是“开放能力、共建生态”的策略。它将基础的框架、中间件、仿真工具开源吸引开发者入驻。但对于最核心的算法模型、高精地图数据以及云端训练平台则保持一定的控制力通常通过API服务或合作授权的方式提供。英飞凌则主要开放芯片的硬件接口、驱动和基础开发工具但核心的IP和工艺技术自然是不开放的。这种模式下生态主导者需要建立一套公平、透明的规则和认证体系。比如对于想要接入的硬件传感器需要制定统一的接口标准和性能测试基准对于软件算法模块需要有代码质量、安全性和性能的准入评估。这就像管理一个大型社区既要有包容性又要有基本的规则维持秩序。4.2 开发者的新定位从“全栈英雄”到“领域专家”对于广大的自动驾驶开发者包括算法工程师、软件工程师、系统工程师而言生态的成熟意味着职业发展路径的深刻变化。过去一个优秀的自动驾驶工程师可能需要懂感知算法、懂控制理论、懂嵌入式编程甚至还要懂一些硬件是稀缺的“全栈英雄”。但在生态化分工下这种要求正在改变。生态提供了标准化的“基础设施”开发者可以更专注于自己最擅长的垂直领域成为“领域专家”。机遇体现在算法创新者你可以不再操心模型如何部署到具体的芯片上而是专注于研究更前沿的感知模型如“端到端 大模型vla”、更高效的规划算法如改进“apollo em planner 曲率”生成算法利用生态提供的仿真平台和数据集快速验证想法。系统集成专家你的价值在于深刻理解生态内各个模块芯片、中间件、算法组件的特性能够根据具体的车型和功能需求像搭积木一样高效地完成系统集成、性能调优和问题排查。工具链开发者生态本身也需要不断进化。你可以开发更好的标注工具、更高效的编译器插件、更强大的仿真测试用例生成工具为整个生态提效。例如针对“点云分割标注”这个细分需求开发出自动化程度更高、精度更好的专用工具就能在生态内找到广阔市场。特定场景深耕者自动驾驶的应用场景非常多元除了乘用车还有矿山、港口、环卫、干线物流等。生态提供了通用的基础能力你可以基于此深入某个垂直行业开发适配该行业特殊需求的软硬件解决方案。挑战也同样明显竞争会更加激烈。因为门槛相对降低会有更多开发者涌入某个细分领域。你的技术深度、对行业需求的理解、以及工程化落地的能力将成为更关键的竞争力。单纯会调用几个API的“调参侠”价值会越来越低。4.3 数据隐私与安全生态的“阿喀琉斯之踵”自动驾驶生态高度依赖数据但数据隐私和安全是全球性的监管难题。车辆收集的环境数据、用户驾驶行为数据都涉及个人隐私和地理信息安全。如何在使用数据驱动算法进化的同时确保数据合规是生态必须解决的“阿喀琉斯之踵”。百度-英飞凌生态在这方面需要构建多层防御车端数据脱敏与匿名化在数据上传云端之前就在车端英飞凌芯片的可信执行环境中完成对车牌、人脸等敏感信息的模糊化或剔除处理。联邦学习技术应用这是一种“数据不动模型动”的技术。可以在不集中原始数据的情况下让分布在千万辆车上的模型本地训练只将模型参数的更新聚合到云端。这能极大降低数据泄露风险。建立严格的数据治理体系明确数据所有权、使用权和收益分配机制确保符合各地法律法规如中国的数据安全法、个人信息保护法欧洲的GDPR。生态的信任建立在安全之上。如果无法妥善解决数据安全问题整个生态的根基就会动摇。因此我们看到生态的主导者一定会将数据安全能力作为核心卖点之一进行建设。5. 实战推演基于该生态开发一个自动泊车功能为了更具体地感受这个生态圈如何工作我们不妨以一个相对成熟但仍有优化空间的场景——记忆泊车功能为例推演一个开发团队如何利用百度-英飞凌生态进行开发。记忆泊车指车辆在人工驾驶一次后学习并记忆从停车场入口到固定车位的路线之后可自动重复该路线泊入车位。5.1 需求分析与方案选型首先产品经理会定义功能需求在大型办公楼或住宅的地下停车场用户下班后可在入口下车车辆自主行驶至固定车位并泊入。要求支持最多1公里的记忆路线应对行人和低速车辆避障泊入精度在10厘米内。基于此团队进行方案选型。如果完全自研需要自建高精地图采集车成本高、开发全套感知和定位算法周期长、寻找符合功能安全要求的控制器并完成软硬件集成难度大。而选择百度-英飞凌生态方案路径则清晰很多硬件平台采用一款集成了英飞凌AURIX TC397用于安全控制和某款高性能AI芯片用于感知计算的域控制器。TC397负责最终的车辆控制指令执行、整车网络管理和安全监控。软件基础基于百度阿波罗开放平台进行开发。阿波罗提供了定位模块可融合轮速计、IMU和摄像头特征点进行视觉定位无需昂贵的激光雷达在光线稳定的地库中精度足够。感知模块提供经过优化的目标检测模型用于检测车辆、行人、柱子等可直接部署到域控制器的AI芯片上。规划与控制模块提供基础的路径规划和轨迹跟踪控制器框架。开发工具提供用于路线录制和回放的仿真工具、数据回灌调试工具。选择生态方案核心是大幅降低了启动门槛和不确定性。团队可以立即在阿波罗的仿真环境里用开源数据集验证算法可行性而不用等待硬件到位。5.2 开发与集成工作流开发工作流会变得高度标准化环境搭建与学习开发者从阿波罗GitHub仓库获取代码参考官方文档在Ubuntu系统上搭建开发环境。同时熟悉英飞凌提供的TC397芯片数据手册和开发指南。记忆路线录制模块开发这是功能的特色部分。需要基于阿波罗的框架开发一个轻量级的“教学”模式。当用户手动驾驶时系统以高频记录车辆轨迹来自轮速和IMU、关键帧图像用于后续视觉重定位以及用户泊车操作时的方向盘和档位信号。这些数据被结构化存储为一条“记忆路线”。感知算法适配地库环境光照不均、阴影多、目标多样车、人、手推车、柱子。虽然阿波罗提供了通用检测模型但团队需要收集一批地库场景的数据或利用生态内可能有的“自动驾驶数据集”进行筛选对模型进行微调Fine-tuning提升在地库场景下的检测准确率特别是对低矮障碍物如地锁的识别。控制算法调优记忆泊车对控制的平顺性和精确性要求很高。阿波罗提供的控制器可能更适用于高速场景。团队需要针对低速、大曲率直角转弯、窄路会车的泊车场景调整控制器的参数甚至修改局部规划算法使其生成的轨迹更平滑避免急刹和顿挫。这里需要与底层的线控底盘其执行器响应特性进行匹配英飞凌芯片的精准控制能力在此发挥作用。系统集成与资源分配这是最体现生态价值的环节。需要将自定义的录制模块、微调后的感知模型、优化后的控制算法与阿波罗的基础模块定位、通信、日志等集成并部署到目标域控制器上。编译器与部署使用经过优化的编译器链将AI模型转换成能在AI芯片上高效运行的代码。同时将控制等安全关键代码编译部署到TC397核上。这里需要仔细进行任务划分视觉定位和感知放在算力强的AI芯片路径规划和车辆状态估计放在TC397的某个性能核最终的车轮扭矩和转角控制指令生成与校验则必须放在TC397的锁步核上以确保功能安全。通信优化模块间大量的数据流如图像、感知结果、规划轨迹需要通过Cyber RT框架进行传输。需要根据数据频率和实时性要求合理配置通信通道和资源优先级避免总线拥堵。5.3 测试验证与问题排查测试将贯穿整个流程仿真测试在百度提供的仿真平台中构建虚拟的地库场景导入录制的真实路线添加动态障碍物模拟行人、突然驶出的车辆进行海量回归测试。这能快速发现逻辑错误和大部分性能问题。硬件在环测试将域控制器接入HIL台架模拟车辆传感器信号和执行器反馈测试代码在真实硬件上的运行情况特别是多核间的协同和实时性。实车测试最后在真实车辆上进行。这时生态提供的调试工具链就至关重要。当出现泊车轨迹偏差时可以通过工具链回灌录制好的传感器数据在办公室复现问题。查看各个模块的运行日志和时间戳分析是感知延迟了还是规划轨迹计算慢了。使用英飞凌的调试器抓取TC397芯片内部的任务调度时序看是否有高优先级任务阻塞了控制指令的发送。如果怀疑是控制参数问题可以快速修改参数通过OTA或线下刷写的方式更新到控制器快速验证。例如遇到在狭窄直角弯处车辆偶尔会过于贴近内侧墙角的问题。通过日志分析发现是局部规划模块在计算避障轨迹时对车辆轮廓的膨胀处理不够。通过调整膨胀参数并在仿真中反复测试不同车型的通过性最终解决问题。这个过程如果没有生态提供的统一日志格式、仿真场景和高效的部署调试工具排查效率会低得多。5.4 经验总结与避坑指南通过这个实战推演可以总结出几点基于此类生态开发的关键经验吃透“中间件”而非“造轮子”不要试图替换阿波罗的Cyber RT通信框架或英飞凌的底层驱动。你的精力应放在理解它们的工作原理、配置方法和性能边界上。例如搞清楚Cyber RT中不同QoS服务质量设置对数据传输延迟的影响这比你自己写一个通信库要实际得多。安全与非安全域的严格隔离这是功能安全开发的铁律。明确哪些软件组件运行在TC397的安全核ASIL-D上哪些运行在性能核或AI芯片上。两者之间的通信必须通过严格定义的、带有安全校验的接口。在项目初期就设计好软件架构避免后期返工。充分利用云端数据闭环在实车测试中一定会遇到训练数据里没有的Corner Case。例如地库里一种特殊反光材质的柱子导致视觉检测失败。这时应触发数据采集将这段场景数据脱敏后自动上传到云端。云端算法团队可以将其加入训练集迭代出新的模型再通过OTA推送给车队。这样功能才能越用越聪明。性能分析与优化是持续过程不要等到所有功能都开发完才做性能优化。在模块开发中期就应利用生态提供的性能剖析工具分析关键路径的耗时。是感知模型推理慢了还是规划算法搜索空间太大针对瓶颈点进行优化。例如发现某个视觉算子耗时过高可以尝试利用英飞凌芯片的硬件加速单元或者使用百度提供的优化后的算子库进行替换。保持对底层芯片特性的关注虽然生态试图抽象硬件细节但作为系统开发者仍需了解关键硬件特性。比如TC397不同核之间的共享内存大小、访问延迟这直接影响你如何划分任务和数据共享方式。再比如AI芯片的片上缓存大小决定了你能否将整个感知模型放进去避免频繁访问外部DDR内存带来的延迟。融入一个强大的生态并不意味着工作变得简单而是意味着你的工作重心从“从零到一”的基础构建转移到了“从一到N”的性能优化、体验打磨和场景深耕上。这要求开发者具备更深的系统思维、更强的调试能力和对垂直场景更敏锐的洞察力。百度-英飞凌这样的生态圈为开发者提供了一个更高的起跳平台但最终能跳多高还是取决于开发者自身的专业深度和工程能力。
返回列表