座舱合入申请流程指导书
源文档: https://mi.feishu.cn/wiki/XcSBwykEYi4oV1k04TCcmxpyn1c document_id: Xxmzd5m1xoWUO9xJsfWcZAs7nzh 抓取说明: 本文档位于 wiki 空间 7541461146314817537(与发版文档空间权限不同),所有图片 API 下载均 403,仅保留 feishu.cn/file/{token} 形式的原链接;3 个白板已转写为文字流程。
目的
代码管控期间,在代码合入之前,充分评估软件变更的有效性及其影响,以尽早识别风险,预防问题,确保软件版本质量。
本流程旨在通过线上流程的方式,更好的支持代码合入申请从提出到合入全周期的活动,提升有效性和效率;
实现:
- 多项目/团队登记入口统一, 消除多项目多车型评审冗余/ 项目依赖
- 验证状态的自动获取 (从gerrit)
- 主管确认状态的信息获取 (提出人书写)
- 自动检查工具/ 代码评审工具的调用,及风险获取
参考文档
适用范围
数字化主要覆盖如下范围。
- 适用座舱所有合入管控期间的合入评审流程,包括域内& 住户;
- 线上流程可直接在流程中进行检查项确认,即不需要额外编制代码合入检查单
流程总览白板(已转写)
来源: whiteboard
Gieawx0S8hgVnPbh06QcxYUpnnb
主流程(从上到下):
| 活动 | 角色(R=负责, S=知会) | 输入 | 输出 |
|---|---|---|---|
| 必要性批准 | R: SRC委员会接口 / 发起方部门总经理;S: 项目组成员 | 必要性&可行性评估结果 | — |
| 开发&测试 | R: 项目组成员 | 正式的需求 | 1/完成评审的代码 2/通过的测试报告 |
| 合入检查 | R: 项目组成员 | 主线3天性能ok / 合入检查通过 | 代码合入检查单 |
| 登记申请 | R: 项目组成员 | 代码合入检查单 / 已登记的合入申请 | 代码合入申请清单 |
| 预评审 | R: 评审委员;S: 项目组成员 | — | 研发主管的合入建议 |
| 正式评审 | R: 团队主管;S: 项目组成员 | — | 评审结论 |
| 合入分支 | R: 开发工程师 | — | — |
触发条件备注:
- 没赶上最后一轮集成测试的需求,触发代码合入控制流程
- 没有赶上 MRD 之前的最后一轮回归测试的 bugfix,触发代码合入控制流程
- 座舱配合发版情况,所有 bugfix 合入均触发代码合入控制流程(如 lemans 单月版本,无集测安排,不接受需求)
Workflow
流程图白板(已转写)
来源: whiteboard
CtWUwggj0hl2tebJ9ktc8FQQn6g(grid 内左侧)
关键节点流转:
[合入申请] (浅蓝, 手动)
│
▼
[合入前检查 a&b&c] (黄色, 工具自动)
│ 工具根据提交的申请, 去gerrit中查询, 都满足则自动通过
▼
[业务负责人/技术leader 确认] (浅蓝, 手动)
│ 按照申请时填写的责任人, 自动分配; 手动点击通过
▼
[主管确认] (浅蓝, 手动)
│ 按照登记的团队, 分配给到不同的主管; 手动点击通过
▼
[待评审] (浅蓝)
│
├──评审通过──▶ [评审通过] (绿色, 最终态)
├──评审拒绝──▶ [评审拒绝] (绿色, 最终态)
└──待定─────▶ [待定] (浅蓝)
│ 挂起项确认
└──▶ [评审通过] (绿色, 最终态)
自动检查项说明(评审 d&e 在 “自动检查” 节点执行):
- a. 验证结果确认 V+1
- b. 主线 3 天确认
- c. 验证人与 +v 是否一致?
- d. 评审 skill 结果
- e. AI code review
- f. 代码变更量确认(>200 行)
节点配色含义:
- 浅蓝底色:需要 owner 手动操作的节点
- 黄色底色:工具自动操作的节点
- 绿色底色:最终态
- 红色边框:为显示的过程状态
流程图配图(403 不可下载)

登记申请
- 申请入口:https://project.f.mioffice.cn/intelligent_cabin_codemr/codemr/create?parentUrl=%2Fintelligent_cabin_codemr%2FfeatureHome%2Fnav-ILMwIHhvg
- 申请人填写申请的基础信息,确认创建。然后再完善表单内容,点击完成节点 (节点变绿色)
住户:软件团队选住户之后还需要选择住户名称,如果没有对应的业务,或者没有 gerrit 的权限,参考文档申请住户入住 汽车部座舱新住户申请入住说明
-
特别注意以下信息填写:
- 必要性说明: 若涉及批准,如整车评审通过,总经理批准等要求,请在追赶必要性外,附批准记录;
- 业务负责人/技术leader: 研发团队的小组长或者业务 SE,作为后续节点的负责人;
- 测试人员:请务必完整填写验证人,以避免由于 “测试人员” 与 gerrit +v 成员不一致,导致的节点阻塞
- 对应主线patch: 作为主线 3 天的检查依据,请正确填写主线提交记录,避免节点阻塞
- 不足三天,需要追赶的,可以点击申请特批,申请之后将由软件团队主管进行批准
- Patch url: 作为后续自动检查是否完成合入的关键输入,请确保链接准确;


合入前检查 - 自动
- 系统自动检查,以下全部通过,节点自动完成;申请人关注节点状态,及时推进;
- 验证结果确认 V+1?
- 主线 3 天确认?
- 测试人员与 +v 一致?
- 验证相关的不一致,申请人及时联系测试人员进行纠偏/偏差;
- 主线不满 3 天,申请人及时提出偏差申请,并联系主管批准;
业务负责人/技术leader 确认
团队 leaders 就变更的必要性,方案有效性&合理性,代码实现与设计的一致性进行检查确认,无误后完成节点。
主管确认
主管就变更的必要性,方案有效性&合理性,代码实现与设计的一致性进行批准确认,无误后完成节点。
自动检查- 自动
系统自动就编码规范&修改的合理性进行 ai 检查,给出评审建议。
Xx 车型评审- (评审会议)
QA 组织会议,会议根据申请的必要性,方案有效性&合理性,代码实现,验证结果,风险等进行决策,给出评审建议:
- 评审通过: 评审流程结束,QA 标记 TR 版本,完成评审节点
- 评审拒绝:评审流程结束,QA 标记 TR 版本为 NA,完成评审节点
- 评审待定:QA 标记 TR 版本为待定,完成评审节点,指派任务,进入待定节点;
Xx 车型待定 & 待定验收
- 待定:任务责任人完成任务后,完成节点
- 待定验收:QA 对待定任务完成情况进行确认,并据此给出最终意见
- 评审通过: 评审流程结束,QA 标记 TR 版本,完成评审节点
- 评审拒绝:评审流程结束,QA 标记 TR 版本为 NA,完成评审节点
申请总经理特批

管控期间(Last 轮集测启动之后)原则上不接受需求合入;
到达 xxx 车型评审节点后,系统将自动判断合入类型,若为需求,系统将
- 自动将评审结论置为拒绝;
- 发信息给到合入申请创建人,确认是否需要发起总经理特批;
- 若选择不发起,流程结束,拒绝合入
- 若选择发起,系统将自动拉群,由申请人补充追赶必要性 & 方案合理性等,并最终由总经理发起决策;
- 注:相关群暂不拉座舱外成员;
快捷查询
我的工作台
进入 我的工作台,可以快捷查询车型管控策略 & 评审计划 & 个人待办 & 新建申请
此页面仅合入信息,不包括住户准入准出信息
- 我的待办: 我未完成被分配节点的合入申请;
- 我的关注:我相关的合入申请,如我是测试人员,合入前检查,没通过的申请;
- 新建: 创建合入申请

合入申请总览
进入 合入申请总览,可以快捷查询车型/团队/版本 相关合入详情
总览看板白板(已转写)
来源: whiteboard
CcArwg5OChZCI7b2phnc7RarnTc
条件筛选区:可根据实际需要对 合入车型 / 软件版本 / 软件团队 进行筛选。
看板显示区(4 个卡片):
| 卡片 | 数据范围 | 关注角色 |
|---|---|---|
| 合入申请 by 状态 | 按筛选条件展示 申请状态;待评审状态=合入评审会议准入状态;饼图,单击对应区域可查看清单 | 业务负责人关注(业务负责人/技术 leader 确认状态);主管关注(主管确认状态);QA 关注(待评审状态) |
| 存在风险的合入申请 | 按筛选条件展示 未完成评审条目 ai 风险;评审会议参考意见;单击对应区域可查看清单 | 业务负责人 & 主管(评审会议前可关注信息) |
| 合入数量 by TR | 按筛选条件展示 评审结论;TR1-TR4=评审通过的合入申请;NA=评审拒绝;空=未评审;单击对应区域可查看清单 | TPM & 测试业务线(回归范围) |
| 合入申请 by 版本 | 按筛选条件展示 申请数量;单击对应区域可查看清单 | all |
问题反馈
变更历史
| 版本 | 变更历史 | 变更时间 |
|---|---|---|
| V1.0 | 初始发布 | 2026/04/15 |
| V1.1 | 4.8 章节:新增 “申请总经理特批” 节点 | 2026/06/02 |