刘新征1. 车企与科技公司的协同困局
2018年我第一次参与车企与科技公司的联合研发项目时，遭遇了典型的"鸡同鸭讲"场景。当时我们团队为某主机厂开发车载娱乐系统，在需求评审会上出现了戏剧性一幕——车企工程师拿着打印的CAN总线协议文档拍桌子："你们连报文周期都搞不清楚，怎么做车规级开发？"而我们这边的产品经理则反复强调："用户要的是像手机一样流畅的滑动体验。"
这种认知冲突在汽车智能化转型过程中屡见不鲜。传统车企的V型开发流程强调层层验证，一个ECU软件版本从需求冻结到量产可能需要18个月；而互联网背景的团队习惯敏捷迭代，两周一个版本是家常便饭。更棘手的是组织壁垒——双方KPI体系割裂，车企考核功能安全达标率，科技公司关注用户日活增长，导致联合项目常陷入"互相甩锅"的恶性循环。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 东软与吉利的破局实验
2020年启动的智能座舱联合开发项目，成为双方探索新协作模式的试验田。这个被内部称为"穿山甲"的计划，核心是建立三个穿透机制：
2.1 需求穿透管理
在宁波研发中心设立的联合办公室墙上，挂着巨幅的需求映射矩阵。不同于传统PRD文档，这个动态看板用不同颜色标记每项功能的来源：黄色代表吉利整车定义的基础需求，蓝色是东软基于用户体验提出的增强需求，红色则是双方技术团队共同识别的技术预研项。每周五的站立会上，双方产品经理必须共同更新每项需求的实现状态。
关键突破：建立需求双向追溯机制。车载语音助手的"免唤醒词"功能就是典型案例，既满足吉利对行车安全的硬性要求（必须通过物理按键激活），又实现了东软建议的"快捷指令"用户体验（长按方向盘按键说出"打开空调"直接执行）。
2.2 代码穿透审计
双方共建的GitLab企业版服务器打破了代码黑箱。通过定制化的权限管理系统，吉利工程师可以实时查看与其模块相关的代码变更，但不能下载完整代码库；东软则开放了持续集成流水线，每次代码提交都会自动触发吉利端的静态检查工具扫描。这套机制下，某个导致CAN通信延迟的bug在合并请求阶段就被发现，相比传统联调模式节省了23天排查时间。
2.3 数据穿透分析
最敏感的车辆数据采用"联邦计算+差分隐私"技术处理。比如优化语音识别准确率时，东软的NLP模型可以访问脱敏后的语音指令文本，但无法获取原始音频文件；吉利能获取模型输出的意图识别结果，但看不到模型参