智能座舱成果物管理系统PRD智能座舱成果物管理系统 PRD 文档版本修改日期修改人修改说明 V1.0 2026-0

智能座舱成果物管理系统 PRD

文档版本	修改日期	修改人	修改说明
V1.0	2026-04-14	PMO	初稿发布

1. 引言

1.1 背景与痛点

业务背景
汽车主机厂，智能座舱产品采用“主机厂定义产品 → 拆分功能模块 → 分包至 Tier1 供应商”的研发模式。软件代码与设计文档均由 Tier1 产出，在车型开发的各里程碑节点需向主机厂交付成果物。

当前痛点

成果物分散：10+ 家 Tier1 交付物分散在邮件、微信、FTP 等渠道，缺乏统一入口。
版本管理混乱：文档多次修改后版本难追溯，代码备份与主机厂镜像不同步。
验收无标准：各模块交付物清单不统一，准出依赖人工逐个核对，效率低且易遗漏。
追溯困难：2200+ Feature 散落于各模块中，无法快速回答“某个 Feature 当前在哪个节点、交付了哪些成果物”。

1.2 项目目标

建立标准化收作业体系：定义 KO/P1/P2/P5/P8/SOP 六大正式节点的交付清单与验收标准。
实现成果物统一存储与版本追溯：以 Git + Git LFS 作为唯一成果物仓库，所有文档、代码、测试产物纳入版本管理。
打通自动化验收与提醒：飞书多维表格作为任务面板，通过 Webhook 与 Git 联动，自动更新交付状态，减少人工催收。
提供 Feature 维度交付追溯：构建 Feature ↔ 模块 ↔ 交付物的关联报表，支持按 Feature ID 查询交付进度与缺失项。

1.3 适用范围与排除项

范围类型	内容
In Scope	智能座舱软件类成果物（PRD/SRS/UI&UE/架构设计/详细设计/单元测试/测试用例/测试报告/代码/编译产物/生态 APK 等）
Out of Scope	硬件工程成果物（PCB/BOM/硬件测试报告）、车主 APP 后端服务、Tier1 内部过程管理文档

1.4 术语定义

术语	定义
Feature ID	功能唯一标识，格式 `D01-F01-01-01`，按 3~5 级层级拆分
FIP 打点	Feature Implementation Point，表示某功能在哪个项目节点达到何种成熟度（如 DI 20%/50%/100%）
里程碑节点	KO / P1 / P2 / P5 / P8 / SOP，本系统正式收作业的检查点
成果物	指各节点要求交付的文档、代码、测试产物等实体文件
DI	Development Index，功能完成度指标，常用于测试通过率阈值判断
豁免名单	生态类通用 APK（无定制开发），可简化验收流程的清单

2. 管理模型总览

2.1 管理主线

本系统以 软件模块 为管理主线，而非以 Feature 为单位收作业。一个软件模块（如 Launcher、设置、空调 App）可承载数十个 Feature 的实现。

管理维度：车型项目 → 软件域（Android / QNX / VIP）→ 软件模块 → 成果物类型
Feature 作为追溯标签，在交付时关联。

2.2 Feature 与模块关系

每个 Feature 可能横跨多个软件模块（如“预警功能”涉及 Android App、QNX 仪表、VIP 车身信号）。
成果物交付时，由 Tier1 在提交清单中标注本次交付涵盖的 Feature ID 列表。
系统通过反向索引，支持从 Feature 视角查看所有关联模块的交付状态。

2.3 里程碑节点与收作业映射

节点	时间定义（示例）	核心交付物类型	准出判断
KO	战略准备结束	Tier1 定点方案、项目计划	人工确认
P1	项目预演收尾	PRD / SRS / UI&UE 资源包	审批流
P2	设计研发收尾	架构设计、详细设计、接口文档	审批流 + 自动校验
P5	DV 收尾	单元测试报告、测试用例、集成测试报告（DI 门槛）	自动校验 + 人工抽查
P8	试生产收尾	全功能验证报告、回归测试报告	自动校验 + 人工抽查
SOP	量产	最终发布基线、代码镜像 Tag	审批流

3. 角色与职责

3.1 角色定义

角色	所属方	职责说明
项目经理 (PM)	主机厂	节点发起、整体进度跟踪、豁免审批、最终验收确认
功能负责人 (FO)	主机厂	对应功能模块的交付内容确认，参与审批
质量工程师 (QA)	主机厂	审批流评审、抽查交付物质量、准出校验
SPM	主机厂	监督 Tier1 交付质量与进度，版本历史抽查
Tier1 PM	供应商	按节点提交成果物，维护提交清单，反馈打回问题
Tier1 开发/测试	供应商	实际文档撰写、代码提交、测试执行
生态供应商	外部	提交生态 APK 及相关交付物

3.2 RACI 矩阵（关键活动）

活动	PM	FO	QA	SPM	Tier1 PM
节点发起与 Checklist 发布	A	I	I	I	R
成果物提交	I	C	I	I	A/R
审批验收	I	C	R	I	I
豁免申请审批	A	C	I	I	R
质量抽查	I	I	A/R	C	I
版本基线打 Tag	I	I	C	A	R

R=Responsible, A=Accountable, C=Consulted, I=Informed

4. 收作业节点与触发规则

4.1 正式节点清单与交付要求

节点	触发条件	作业范围	验收方式
KO	项目启动会完成	Tier1 定点方案、资源计划	责任人确认
P1	需求冻结	PRD、SRS、UI/UE 资源包	审批流
P2	架构设计完成	架构设计文档、详细设计、接口定义	审批流
P5	DV 测试完成	单元测试报告、测试用例、集成测试报告、代码覆盖率	自动校验 + 人工抽查
P8	试生产验证完成	全功能测试报告、回归测试报告	自动校验 + 人工抽查
SOP	量产评审通过	最终发布版本 Tag、合规文档	审批流

4.2 FIP 打点与交付物对应关系

Feature 在不同节点有不同成熟度要求（如 E1 阶段要求 DI 20%，E2 要求 DI 50%）。交付物提交需满足对应 DI 阈值。

映射规则：

若某 Feature 的 FIP 计划在 P3 完成 DI 50%，则其单元测试报告最晚需在 P5 节点提交。
系统在 P5 节点自动比对“该 Feature 关联模块的测试报告”是否满足 DI 阈值，不满足则阻断准出。

4.3 中间节点处理

P3、P4、P6、P7 为内部进度跟踪节点，不触发正式收作业流程。仅由 PM 在多维表格中查看 Tier1 更新进度备注，不做强制交付要求。

5. 成果物 Checklist 定义

5.1 成果物分类

成果物
├── 内部作业（主机厂内部产出）
│   ├── 产品类：PRD
│   ├── UI&UE类：设计稿（Figma链接）、资源包
│   └── 软件需求类：SRS
└── 外部作业（Tier1/生态交付）
    ├── 设计类：架构设计文档、详细设计文档、接口定义文件
    ├── 开发类：单元测试报告、代码覆盖率报告、代码仓库同步凭证
    ├── 测试类：测试用例、集成测试报告、验收报告
    └── 发布类：编译产物清单、Release Note

5.2 按模块的 Checklist 模板

主表字段设计（飞书多维表格）

字段名	字段类型	说明	示例
节点	单选	KO/P1/P2/P5/P8/SOP	P5
软件域	单选	Android/QNX/VIP	Android
功能模块	文本	模块名称	Launcher
成果物名称	文本	具体交付物	单元测试报告
成果物类型	单选	设计类/开发类/测试类/发布类	测试类
负责供应商	单选	德赛/伟世通/伯泰科/地平线/...	伟世通
标准模板版本	文本	引用模板编号	TPL-UT-01
必须/可豁免	单选	必须/豁免	必须
验收方式	单选	审批流/责任人确认/自动校验	自动校验
关联 Feature ID	多选/文本	本次交付涵盖的 Feature 列表	D01-F01-01-01, D01-F01-01-02
提交状态	单选	待提交/已提交/审核中/已通过/已打回	待提交
提交人	人员	Tier1 提交人	@张三
提交时间	日期	系统自动记录	2026-04-14
Git 版本/Commit ID	文本	文件对应的版本标识	a1b2c3d
审核人	人员	主机厂 QA/FO	@李四
打回原因	文本	审批不通过时填写	测试覆盖率不足 80%
重提截止日	日期	打回后自动计算	2026-04-18
准出校验结果	文本	系统自动判断	通过/阻断-缺测试报告
备注	文本	补充说明

5.3 豁免名单管理机制

豁免条件

生态类 APK（爱奇艺、腾讯视频、喜马拉雅等）无定制开发，仅做集成验证。
由生态供应商直接提供正式发布版本，主机厂不做二次验收。

豁免流程

FO 在 Checklist 中将对应条目标记为“豁免”。
系统自动将验收方式改为“责任人确认”，不触发审批流。
责任人（FO）在交付后手动勾选“已确认”即视为通过。
豁免名单变更需 PM 审批。

6. 验收流程

6.1 验收方式概览

本系统提供两种验收方式，前期以 方式二（责任人确认 + 抽查） 为主，方式一（标准审批流）为备选，预留后续启用可能。

方式	名称	适用场景	当前状态
方式一	标准审批流	高合规要求交付物（如安全相关 Feature）	备选保留（后续视人力情况启用）
方式二	责任人确认 + 质量抽查	常规交付物、豁免项	当前主用

6.2 方式二：责任人确认 + 质量抽查（主流程）

流程步骤：

Tier1 提交成果物 → 系统自动校验(格式/路径/阈值) → 责任人(FO)在多维表格勾选“确认” → QA 按比例抽查 → 抽查通过/不通过处理

详细说明：

提交与自动校验
- Tier1 按规范提交后，系统自动执行基础校验（文件存在性、命名规范、DI 阈值比对）。
- 校验结果写入多维表格“准出校验结果”字段。
责任人确认
- 自动校验通过后，对应 FO 收到飞书通知。
- FO 登录多维表格，查看交付内容，勾选“责任人确认”复选框。
- 勾选后状态变为“已确认”，视为验收通过，可进入下一节点准备。
质量工程师抽查
- QA 每月（或每节点结束后）从“已确认”条目中随机抽取 20% 进行深度审查。
- 审查内容包括：文档完整性、测试数据真实性、代码与文档一致性等。
抽查不通过处理
- QA 在多维表格中标记“抽查不通过”，填写原因。
- 该条目状态回退为“待整改”，并自动转为 方式一（标准审批流） 进行重试验收。
- 同时通知 FO 关注该模块整体质量，必要时扩大抽查范围。

6.3 方式一：标准审批流（备选保留）

流程步骤：

Tier1提交 → 飞书审批自动发起 → QA初审 → FO复审 → PM终审 → 状态更新为“已通过”

启用条件（后续）：

安全相关 Feature（如 ADAS 预警）的交付物。
抽查连续两次不通过的模块，强制转入审批流。
项目进入 SOP 阶段前的最终交付物。

当前备注：
该方式因人力有限暂不作为主流程，但多维表格字段与飞书审批流已预留配置，可按需激活。

6.4 不通过处理与重提闭环（两种方式通用）

无论哪种验收方式，打回/不通过后均遵循以下闭环：

打回原因结构化记录
- 审批人（或 QA）从下拉选项中选择原因分类（如“文档缺失”、“测试数据不足”、“格式不符”），并填写具体说明。
重提截止日自动计算
- 系统按“打回日期 + 3 个工作日”生成截止日。
逾期告警升级
- 逾期 1 天：飞书提醒提交人及 Tier1 PM。
- 逾期 3 天：抄送主机厂 PM 与 SPM。
重提后流程
- 若原为方式二打回且转为方式一，则重提时直接进入审批流。
- 若仍为方式二，则重新走责任人确认流程。

6.5 验收状态流转图

┌─────────┐
│ 待提交  │
└────┬────┘
     │ Tier1 提交
     ▼
┌─────────┐    自动校验失败    ┌──────────┐
│ 已提交  │ ─────────────────▶ │ 格式不符  │──▶ 通知 Tier1 修正
└────┬────┘                    └──────────┘
     │ 自动校验通过
     ▼
┌─────────────┐
│ 待责任人确认 │
└──────┬──────┘
       │ FO 勾选确认
       ▼
┌─────────┐      QA 抽查不通过      ┌──────────┐
│ 已确认  │ ──────────────────────▶ │ 待整改    │──▶ 转方式一审批流
└────┬────┘                         └──────────┘
     │ QA 抽查通过 / 无需抽查
     ▼
┌─────────┐
│ 验收通过 │
└─────────┘

6.6 验收方式在 Checklist 中的体现

在多维表格 Checklist 中新增字段 “验收方式” ，由系统根据规则自动赋值，也可由 FO 手动调整：

验收方式值	赋值规则
责任人确认	默认值（常规交付物）
审批流	安全 Feature 或手动指定
豁免确认	当“必须/可豁免”=“豁免”时自动赋值

7. 成果物存储与版本管理（Git + Git LFS）

7.1 Git 仓库架构

采用 双仓库组 架构：

mirror/ 镜像组：只读镜像，从各 Tier1 代码仓库同步，作为主机厂备份。
eov-cockpit/ 主仓库组：主机厂管理的成果物主仓库，包含文档、测试报告、发布包等。

git.company.com/
├── mirror/                      # 镜像组（只读备份）
│   ├── tier1-desaysv/           # 德赛代码镜像
│   ├── tier1-visteon/           # 伟世通代码镜像
│   └── tier1-horizon/           # 地平线代码镜像
└── eov-cockpit/                 # 主仓库组（成果物总库）
    ├── EOV/                     # 车型项目
    │   ├── 00_项目管理/
    │   ├── 01_需求管理/
    │   ├── 02_系统工程/         # 架构设计等
    │   ├── 03_软件工程/         # 按软件域划分
    │   │   ├── Android/
    │   │   │   ├── APP/
    │   │   │   └── FW_BSP/
    │   │   ├── QNX/
    │   │   └── VIP/
    │   ├── 04_集成与测试/
    │   └── 05_发布管理/
    └── templates/               # 标准模板库

7.2 Git LFS 管理的大文件类型清单

文件类型	典型后缀	管理方式
UI 设计源文件	`.sketch`, `.fig`, `.psd`	Git LFS
资源包	`.zip`, `.tar.gz`, `.car`	Git LFS
二进制固件/编译产物	`.bin`, `.hex`, `.img`, `.apk`, `.so`	Git LFS
测试报告 PDF	`.pdf`	Git LFS（超过 5MB）
架构图/流程图原图	`.drawio`, `.vsdx`	Git LFS

7.3 版本号规范与 Tag 打标规则

文件版本号格式： [车型]_[节点]_[供应商]_[模块]_[成果物类型]_vX.Y

示例：EOV_P5_Visteon_Launcher_UnitTestReport_v1.2.pdf

里程碑基线 Tag：
每到达一个正式节点，由 SPM 在 eov-cockpit 仓库打 Tag，格式：[车型]_[节点]_[日期]

示例：EOV_P5_20260115

7.4 Commit 信息规范

格式： [节点] [模块] [供应商] [成果物类型]: 简要说明

示例：[P5][Launcher][Visteon][单元测试报告]: 新增异常场景用例，覆盖率提升至85%

7.5 代码仓库镜像同步策略

Tier1 每日凌晨自动推送代码至 mirror/ 对应仓库（通过 CI 定时任务）。
主机厂不直接修改镜像仓库，仅供备份与审计追溯。
成果物提交时，Tier1 需在 Checklist 中填写“镜像仓库 Commit ID”作为代码交付凭证。

8. Feature 追溯报表

8.1 报表数据模型

┌─────────────┐     ┌─────────────┐     ┌─────────────┐
│  Feature ID │────▶│   软件模块   │────▶│   成果物    │
│  (D01-...)  │     │  (Launcher) │     │ (文件+版本) │
└─────────────┘     └─────────────┘     └─────────────┘
       │                                       │
       └─────────── 交付状态 ──────────────────┘

数据来源于：

Feature-模块映射表（人工维护的 Excel，定期导入多维表格）
Checklist 中的“关联 Feature ID”字段
Git 提交记录（通过 Webhook 解析）

8.2 报表视图设计

主视图：Feature 交付清单

字段	说明
Feature ID	D01-F01-01-01
Feature 名称	预警
所属域	智能驾驶域
计划交付节点	P5
关联模块列表	Android::Safety, QNX::Alert
实际交付状态	部分完成
缺失成果物	QNX::Alert - 集成测试报告
当前 FIP 成熟度	DI 80%（目标 DI 100%）

覆盖率看板（图表）

按节点统计 Feature 交付完成率（柱状图）。
按供应商统计 Feature 覆盖数量（饼图）。

追溯明细（下钻）
点击 Feature ID，展示：

关联的所有模块及对应 Tier1
每个模块已提交的成果物清单及 Git 版本链接
缺失项列表及预计补交时间

8.3 数据生成与更新机制

每日凌晨：脚本从飞书多维表格 API 拉取最新 Checklist 数据，结合 Git 仓库状态，生成 JSON 数据快照。
报表展示：在飞书多维表格的“报表”页中嵌入自动化应用，读取快照数据并渲染为图表。
订阅推送：每周一自动推送“Feature 交付周报”至项目群。

9. 工具链与自动化方案

9.1 整体架构图

┌─────────────────────────────────────────────────────────────────┐
│                         飞书客户端                              │
│   ┌─────────────┐  ┌─────────────┐  ┌─────────────┐            │
│   │ 多维表格    │  │  审批中心   │  │  机器人消息  │            │
│   │ (Checklist) │  │             │  │             │            │
│   └──────┬──────┘  └──────┬──────┘  └──────┬──────┘            │
└──────────┼────────────────┼────────────────┼────────────────────┘
           │ API 调用        │ Webhook        │ Webhook
           ▼                 ▼                ▼
┌─────────────────────────────────────────────────────────────────┐
│                    自动化服务（自研/飞书应用）                   │
│   ┌─────────────────┐  ┌─────────────────┐  ┌───────────────┐  │
│   │ 状态同步服务    │  │ 审批流转服务    │  │ 报表生成服务  │  │
│   └────────┬────────┘  └────────┬────────┘  └───────┬───────┘  │
└────────────┼────────────────────┼────────────────────┼──────────┘
             │ Webhook            │                    │
             ▼                    ▼                    ▼
┌─────────────────────────────────────────────────────────────────┐
│                      Git 服务器 (GitLab)                        │
│   ┌─────────────┐  ┌─────────────┐  ┌─────────────┐            │
│   │ mirror/     │  │ eov-cockpit/│  │ LFS 存储    │            │
│   │ (镜像仓库)  │  │ (主仓库)    │  │             │            │
│   └─────────────┘  └─────────────┘  └─────────────┘            │
└─────────────────────────────────────────────────────────────────┘

9.2 飞书多维表格设计

主表字段（完整版）
参见 5.2 节。

视图配置

视图名称	筛选条件	用途
全部待办	提交状态=待提交/已打回	PM 催收视图
按节点查看	分组：节点 → 模块	节点交付跟踪
按供应商查看	分组：供应商 → 模块	供应商管理
待我审批	审核人=当前用户	QA/FO 审批入口
逾期清单	重提截止日<今天	告警升级依据
准出校验视图	节点=P5/P8，准出结果=阻断	转段前检查

自动化规则示例

触发条件	执行动作
提交状态变更为“已提交”	发起飞书审批，通知审核人
审批结果为“通过”	状态改为“已通过”，通知提交人
审批结果为“打回”	状态改为“已打回”，计算重提截止日，通知提交人
重提截止日逾期 1 天	通知升级至 PM 与 Tier1 PM

9.3 飞书机器人触发场景与消息模板

场景	接收人	消息模板
节点收作业启动	所有 Tier1 PM	【收作业通知】 ${节点}节点收作业已开启，请于$ {截止日} 前完成以下模块交付：[模块列表]
作业提交	对应 FO/QA	【待审批】 ${供应商} 提交了$ {模块} 的 ${成果物名称}，请及时审批。[链接]
审批打回	提交人	【打回重提】您提交的 {成果物名称} 被打回，原因：{原因}。请于 ${重提截止日} 前重新提交。
逾期提醒	提交人+抄送PM	【逾期提醒】${成果物名称} 重提已逾期，请尽快处理。
准出校验阻断	PM	【准出阻断】{节点} 节点 ${模块} 自动校验不通过，缺失项：{缺失列表}。

9.4 Git Webhook 与多维表格状态同步逻辑

同步流程（时序图）：

Tier1           GitLab           Webhook服务       飞书多维表格
  │                │                  │                 │
  │─ git push ────▶│                  │                 │
  │                │─ POST /webhook ─▶│                 │
  │                │                  │─ 解析Commit ────▶│
  │                │                  │  更新状态         │
  │                │                  │                 │
  │                │                  │◀─ 更新成功 ─────│
  │◀─ 飞书消息 ───────────────────────│                 │
  │   "提交成功，状态已更新"            │                 │

解析规则：

从 Commit Message 中提取节点、模块、供应商、成果物类型。
匹配 Checklist 中对应条目，将“提交状态”改为“已提交”，自动填入“提交时间”和“Commit ID”。
若匹配失败（非规范格式），则忽略并记录日志。

10. 操作规范（SOP）

10.1 节点发起与 Checklist 生成

PM 在节点开始前 2 周，在多维表格中复制上一节点 Checklist 作为模板。
根据当前节点交付要求，调整必选条目（参考附录 B 映射表）。
发布通知（飞书机器人自动发送），告知 Tier1 交付清单与截止日。

10.2 供应商提交指引

Tier1 登录飞书多维表格，找到自己负责的模块条目。
点击“提交”按钮，填写提交表单（成果物名称、Git 路径/Commit ID、关联 Feature ID）。
对于大文件（>5MB），确保已通过 Git LFS 推送。
提交后，状态自动流转，无需额外邮件通知。

10.3 主机厂验收操作

QA/FO 在“待我审批”视图中查看待办。
点击条目进入详情，可预览 Git 上的文件内容。
选择“通过”或“打回”，填写审批意见。
若为抽查项，QA 可在抽查后手动发起审批流（通过“转为正式审批”按钮）。

10.4 豁免申请流程

FO 在 Checklist 中将条目“必须/可豁免”改为“豁免”。
系统自动发起一条“豁免申请”审批，流转至 PM。
PM 审批通过后，该条目验收方式变为“责任人确认”。
后续提交由 FO 自行勾选确认即可。

10.5 版本回溯与审计

需要查看某模块历史交付记录时，在 Git 仓库中按路径查看 Commit History 或使用 git log -- <path>。
里程碑基线 Tag 包含该节点全部交付物快照，可一键检出。
多维表格中的“Git 版本”字段提供直接跳转链接。

11. 附录

附录 A：成果物标准模板索引

模板编号	模板名称	适用成果物	存储路径
TPL-SRS-01	软件需求规格说明书模板	SRS	/templates/SRS/
TPL-ARCH-01	软件架构设计文档模板	架构设计	/templates/Arch/
TPL-UT-01	单元测试报告模板	单元测试报告	/templates/Test/
TPL-IT-01	集成测试报告模板	集成测试报告	/templates/Test/
TPL-CM-01	代码提交说明模板	代码交付	/templates/CM/

附录 B：模块与供应商映射表（示例）

软件域	模块名称	负责供应商	主要成果物类型
Android	Launcher	伟世通	APK源码、单元测试报告、集成测试报告
Android	设置	伟世通	同上
Android	空调 App	德赛	同上
QNX	仪表	伯泰科	QNX工程、架构设计、测试报告
VIP	车身控制	地平线	固件、通信矩阵、测试用例

附录 C：Git 目录结构详细规范

eov-cockpit/
├── EOV/
│   ├── 00_项目管理/                 # 计划、风险、会议纪要
│   ├── 01_需求管理/
│   │   ├── PRD/
│   │   ├── SRS/
│   │   └── UI_UE/
│   ├── 02_系统工程/
│   │   ├── 架构设计/
│   │   ├── 详细设计/
│   │   └── 接口定义/
│   ├── 03_软件工程/
│   │   ├── Android/
│   │   │   ├── APP/                # 按模块分子目录
│   │   │   │   ├── Launcher/
│   │   │   │   ├── Settings/
│   │   │   │   └── HVAC/
│   │   │   └── FW_BSP/
│   │   ├── QNX/
│   │   │   ├── Cluster/
│   │   │   └── Safety/
│   │   └── VIP/
│   │       └── BodyControl/
│   ├── 04_集成与测试/
│   │   ├── 测试用例/
│   │   ├── 单元测试报告/
│   │   └── 集成测试报告/
│   └── 05_发布管理/
│       ├── DEV/
│       ├── PRE/
│       └── SOP/
└── templates/                       # 模板库，独立于车型版本

附录 D：飞书多维表格字段定义（详细）

参见 5.2 节。

附录 E：Feature 与模块关联维护表模板

Feature ID	Feature 名称	关联模块 (Android)	关联模块 (QNX)	关联模块 (VIP)	负责人
D01-F01-01-01	预警	Safety	Alert	-	@廖工
D01-F02-03-01	空调控制	HVAC	-	Climate	@张工