“谁有资格定义 AI 汽车”这个问题放在技术社区里很容易变成发布会文案之争。但如果从工程实践角度去看AI 汽车并不是一个靠营销关键词就能定性的概念。它是一套由传感器、计算平台、感知模型、决策规划、控制执行、人机交互、云平台数据和评测体系共同组成的复杂系统。真正有资格定义 AI 汽车的人不是只给汽车贴标签的人而是能对系统能力做度量、测试、追溯和验证的人。这篇文章从工程视角拆解 AI 汽车的定义权到底落在哪一层并把感知基线、运行边界、数据质量、评测复现和安全验证这些环节串成一条可落地的主线。在这个讨论里我尽量不把“定义 AI 汽车”理解成一句话宣言而是理解成一套工程判断标准。谁能说清楚系统在什么条件下能做什么、不能做什么、出问题时如何归因谁就在真正参与定义。文章会先讲为什么定义权本质上等于评测权然后分别从感知能力、自动驾驶分级、评测脚本、数据质量和常见争议五个角度展开最后给出一份可以在团队内部使用的定义和检查清单。1. AI 汽车的定义权本质上是一个评测权1.1 为什么“谁能定义”会成为一个技术问题传统的汽车定义方式相对清晰看动力形式、车身结构、底盘布局、安全等级再做碰撞测试和耐久测试。这些指标可以量化可以被第三方机构重复验证。到了“AI 汽车”这个阶段情况明显不同。汽车开始依赖模型、数据、软件更新和持续学习很多能力不再是出厂固定参数而是随着数据迭代不断变化。同一辆车今天能识别的障碍物范围可能因为一次软件更新的训练数据变化而改变。一辆车的“智能程度”也不再只是发动机功率或百公里加速而是取决于感知模型在不同天气下的表现、决策模块在复杂道路上的合理性、以及系统在无法处理时能否安全退出。这些能力很难用一句“这辆车很智能”来概括。它必须落到具体的指标上比如 mAP、误报率、接管次数、运行设计域、故障降级策略。因此定义权看似是一场话语权之争本质上却是一套评测体系的竞争。谁能定义“好”的标准谁就掌握了衡量 AI 汽车能力的尺子。1.2 先拆解 AI 汽车的能力域感知、决策、执行、交互、数据闭环在实际项目中定义 AI 汽车之前要先拆能力域因为不同能力域的测评方法完全不同。如果不拆开讨论很容易用一个大而化之的概念掩盖真正的问题。感知层负责回答“周围有什么”。它包含摄像头图像里的目标检测、语义分割、激光雷达点云里的目标聚类、多传感器融合后的目标跟踪以及车道线、交通标志、红绿灯、可行驶区域等结构化要素的提取。感知能力的定义方式是数据集加指标比如在特定测试集上的召回率、精确率、mAP 和误报率。决策规划层负责回答“接下来怎么走”。它包含行为预测、轨迹预测、路径规划、速度规划和避障策略。这里的评测更依赖仿真环境和实车场景需要看规划出来的轨迹是否安全、舒适、可执行以及在出现动态障碍物时能否及时调整。控制执行层负责回答“车能不能按指令走”。它涉及转向、制动、驱动的底层执行器控制。即使感知和规划都正确如果控制指令跟踪误差过大车辆依然可能出现危险。控制层常用的指标包括横向偏差、纵向加速度误差、超调量和稳定时间。人机交互层负责回答“系统能不能让人理解自己”。当系统要降级、要接管、要退出某个功能时驾驶员是否在正确时间内理解并接管是非常关键的定义维度。还有座舱里的大模型助手它属于 AI 能力的一部分但通常不直接决定车辆安全等级定义时要避免把“会聊天”和“会开车”混为一谈。数据闭环层负责回答“系统能不能越用越好”。包括数据采集、场景挖掘、标注、训练、评测、部署、监控和回滚。这一层决定了 AI 能力的迭代速度也决定了问题能不能被追溯。没有数据闭环的所谓 AI 汽车严格来说只是嵌入了几个人工智能模块。1.3 谁在现实链路里参与定义从工程实践看定义 AI 汽车并不是某个岗位或某家公司单独完成的而是由多个角色在不同环节输入定义。技术团队定义能力边界。车辆能否在特定道路上开启领航辅助需要感知、规划、控制团队给出可验证的参数和阈值。标准组织定义分级框架。目前业界普遍参考的自动驾驶分级方式讨论的是系统在什么条件下承担什么责任它不是营销话术而是工程和安全事件里用来判断责任边界的基础。第三方评测机构定义可比性。不同企业对自己的系统当然会给出积极评价但如果评测机构使用统一的数据集、统一的场景库、统一的打分流程用户和行业才能横向比较。监管机构定义准入门槛。不同国家和地区对自动驾驶产品的准入、测试、上路要求存在差异具体项目落地前必须对照当地现行法规和技术要求来处理。用户定义真实体验。指标再好看如果用户在实际路上频繁感到不安全、不理解系统行为或者对降级提示反应不过来这个 AI 汽车在实际使用意义上仍然不合格。这些角色共同构成定义网络。单一角色试图垄断定义权都会导致评估失衡。工业界的合格做法是企业提供自测数据第三方提供独立复现标准提供分级框架监管提供准入门槛用户提供反馈闭环。2. 在工程上定义 AI 汽车的第一道门槛感知能力基线2.1 感知任务不是“识别出物体”这么简单很多介绍会用“这辆车能识别行人、车辆、交通标志”来描述感知能力。这句话作为产品说明没有问题但作为工程定义远远不够。感知任务在工程上至少包含以下几点目标检测要给出物体的位置、类别和置信度目标跟踪要维持同一目标在时间序列上的身份一致性多传感器融合要解决雷达、摄像头、激光雷达之间的坐标系对齐还要在不同天气、光照和遮挡条件下保持稳定。真正定义感知能力的是一套可复现的评测流程。拿目标检测举例工程师需要约定一套标准用什么测试集、什么样的标注格式、IoU 阈值取多少、是否只测主要类别、小目标怎么处理、雨天样本占多少比例。这些问题不前置确定后续所有“识别得很准”的结论都可能失真。2.2 用公开数据集和 mAP 建立感知基线在项目从零起步阶段最常见的做法是先用公开数据集建立感知基线再逐步加入自采数据。公开数据集的好处是标注相对统一评测指标可复现团队之间也容易对比。目标检测领域最常用的指标是 mAP也就是各类别平均精确率的均值。要理解 mAP先要理解这几个概念IoU 衡量预测框和真实框的重合程度。通常 IoU 大于 0.5 才算一个有效命中。Precision 表示模型预测出的目标中真正命中的比例。Recall 表示真实目标中有多少被模型找出来。AP 是 Precision-Recall 曲线下的面积。mAP 是对所有类别 AP 取平均。指标回答的问题常见值含义IoU预测框和真实框重叠多少0.5 或 0.5:0.95 是常见评价段Precision预测结果里正确比例多高高表示误报少Recall真实目标里找回多少高表示漏报少AP单个类别的综合能力接近 1 表示该类很准mAP所有类别的平均能力用于跨模型对比在自动驾驶场景不能只盯着 mAP。漏报行人比误报一处阴影更危险所以很多团队会单独看行人和骑行者类别的 Recall并给关键类别设置更高权重。2.3 标定、传感器配置和算力是定义的前提同一套感知模型放在不同传感器配置的车上结果可能差别很大。摄像头安装高度、俯仰角、内参标定质量激光雷达的线束和点云密度毫米波雷达的位置都会影响输入数据质量。算法评测必须在固定的传感器拓扑下进行否则评测结果没有意义。下面是一个简化的传感器配置示例用于说明参数管理思路。实际项目中要结合自己的硬件方案调整。sensors: camera_front: type: camera resolution: 1920x1080 fov: 60 position: front-mirror intrinsic_calibrated: true extrinsic_to_vehicle: [0.0, 0.0, 1.2] lidar_top: type: lidar lines: 128 range_m: 200 position: roof-top extrinsic_to_vehicle: [0.0, 0.0, 1.8] radar_front: type: radar range_m: 150 position: front-bumper extrinsic_to_vehicle: [1.8, 0.0, 0.5] compute: gpu_power_usage_percent: 70 inference_fps: 15 latency_ms: 80配置文件里每个值都影响定义结论。标定参数如果过期或错误感知结果会整体偏移算力如果预留不足模型推理延迟会超过安全阈值。所以任何感知评测报告都应该附带传感器版本、外参版本、标定日期和算力负载。缺少这些信息指标无法复现也就没有定义价值。3. 第二道门槛决策安全与运行边界ODD3.1 自动驾驶分级不是“L2、L3 的标签战”自动驾驶分级常被用来宣传产品定位但在工程上它最重要的作用是明确责任边界和运行限制。不同等级对应的不是“高级、低级”的好坏判断而是“系统能做什么、驾驶员需要做什么、出问题时谁负责”的工程约定。分级系统承担的横向和纵向控制驾驶员职责典型边界L0无持续控制始终驾驶只有警告或短时辅助L1横向或纵向之一监控并随时接管单车道巡航L2横向和纵向同时控制持续监控并接管组合辅助驾驶L3限定条件下全部控制响应系统请求接管特定 ODD 内L4限定条件下全部控制无需接管但限制区域限定道路和区域L5全场景全部控制基本无人工接管理论上不限作为工程师尽量不要把 L2 宣传成无人驾驶也不要把 L3 理解成系统可以完全自行负责。后续更细的落地规则会因地区、法规、审批条件而异产品团队必须时刻跟踪并遵守当地最新要求。在定义 AI 汽车时更重要的是 ODD 和管理边界而不是等级代号本身。如果一个系统只在高速公路、白天、无雨、有清晰车道线时可用那么定义它的正确方式就是列出这些约束而不是简单说“这是 L2”。3.2 用 ODD 明确系统能在哪里跑ODD 的全称是 Operational Design Domain也就是运行设计域。它定义自动驾驶或辅助驾驶系统被设计为可以运行的道路、环境、交通、天气和速度等条件。一个清晰的 ODD 应该包含以下维度ODD 维度示例值为什么重要道路类型高速公路不包含城市路口避免在未验证场景启用天气条件无雨、无雪、无雾传感器在恶劣天气性能下降光照条件白天或夜间结构化道路视觉模型对光照敏感速度范围0 到 120 km/h规划和控制算法与车速强相关地图区域高精地图覆盖区域没有地图时定位可靠性降低通信状态不依赖远程驾驶避免因网络波动影响安全ODD 定义得越清晰系统能做什么、不能做什么就越明确车辆在超出边界时的退出策略也越容易设计。下面是一个简化的 ODD 配置文件示例。实际系统里ODD 不只是一份文档它还会被编码成运行时的前置条件判断逻辑。odd: version: demo-odd-v1 road_types: - highway - expressway weather: - clear - cloudy light: - day - night speed: min_kmh: 0 max_kmh: 120 guardrails: - high-definition-map-covered-area - camera_calibration_ok - lidar_degraded_level: none - system_health: okODD 文件不是写出来就结束的运行时需要不断检查这些条件。一旦任一条件不满足系统应该进入降级或退出流程比如提醒接管、减速、靠边停车。把 ODD 写清楚比单纯争论“这车是不是 AI 汽车”更有工程价值。3.3 从功能安全到预期功能安全车辆安全设计的传统基础是功能安全它关注电子电气系统故障时如何避免对人造成伤害。业界常讨论的 ISO 26262 就属于这一类。它要求团队分析可能出现的系统故障并设计安全机制。但 AI 系统还有一个特殊问题功能一切正常但算法在某个场景下做出了错误判断。比如摄像头没有故障模型却把路边广告牌里的行人也识别成真人或者雨天下雨滴导致误检增加。这类问题不是“硬件坏了”而是“性能不足”传统功能安全框架很难完全覆盖。于是预期功能安全被引入它关注的是系统在无故障情况下由于性能局限、场景覆盖不足、算法误判等原因导致的危险。它的核心思路是识别系统在 ODD 内的潜在不足通过测试、冗余、限制条件、人工接管机制来降低风险。在项目里给 AI 汽车下定义不能只看“功能是否正常”还要回答“即使所有模块都按设计运行系统是否仍然可能做出危险决策”。这就是为什么定义权必须建立在安全分析、场景挖掘、系统边界和持续监控之上而不能只靠某个模型的性能指标。4. 从模型评测到整车定义搭建可复现的能力评估脚本4.1 评测目标要分三层不要只跑一个指标给 AI 汽车建立能力基线至少要分三个层次来评测。算法层评测关注模型本身使用固定数据集计算 mAP、Recall、Precision、误报率等指标。它的优点是快速、可复现适合日常迭代。仿真层评测关注算法在交通流、天气、道路结构中的表现。通过仿真平台构造极端场景比如前车急刹、行人横穿、旁车切入可以重复验证决策规划逻辑。实车路测关注系统在真实环境中的表现。实车测试覆盖面有限但能验证传感器标定、执行器响应、车辆通信和驾驶员接管体验这是仿真无法完全替代的。项目早期可以主要依赖算法层和仿真层进入量产阶段后三者的比例和流程需要重新设计。生产环境不能只靠某一个高指标而是要靠“算法层指标 仿真场景通过率 实车接管数据”组成的一组证据。4.2 搭建一个最小可复现的感知评估脚本下面用一个最小脚本说明 mAP 评估的流程。这个脚本只展示思路不适用于生产级完整评测。生产环境建议使用成熟的评测库并接入数据集管理平台。# minimal_map_demo.py # 逻辑简化示例用于理解 mAP 计算链路 import json import argparse def compute_iou(box_a, box_b): x1 max(box_a[0], box_b[0]) y1 max(box_a[1], box_b[1]) x2 min(box_a[2], box_b[2]) y2 min(box_a[3], box_b[3]) inter max(0.0, x2 - x1) * max(0.0, y2 - y1) area_a (box_a[2] - box_a[0]) * (box_a[3] - box_a[1]) area_b (box_b[2] - box_b[0]) * (box_b[3] - box_b[1]) union area_a area_b - inter return inter / union if union 0 else 0.0 def eval_single_iou(predictions, ground_truths, iou_threshold0.5): preds_sorted sorted(predictions, keylambda x: x[score], reverseTrue) gt_matched set() hits 0 for pred in preds_sorted: best_iou 0.0 best_gt_idx -1 for idx, gt in enumerate(ground_truths): if idx in gt_matched: continue iou compute_iou(pred[box], gt[box]) if iou best_iou: best_iou iou best_gt_idx idx if best_iou iou_threshold and best_gt_idx 0: gt_matched.add(best_gt_idx) hits 1 precision hits / len(preds_sorted) if preds_sorted else 0.0 recall hits / len(ground_truths) if ground_truths else 0.0 return {precision: precision, recall: recall, hits: hits} if __name__ __main__: parser argparse.ArgumentParser() parser.add_argument(--preds, requiredTrue) parser.add_argument(--gt, requiredTrue) args parser.parse_args() with open(args.preds, r, encodingutf-8) as f: predictions json.load(f) with open(args.gt, r, encodingutf-8) as f: ground_truths json.load(f) result eval_single_iou(predictions, ground_truths) print(fprecision{result[precision]:.3f} recall{result[recall]:.3f} hits{result[hits]})运行方式python minimal_map_demo.py --preds predictions.json --gt ground_truths.json这段代码只演示了固定 IoU 阈值下的 Precision 和 Recall并没有计算完整 mAP但已经能暴露一个重要问题如果把阈值从 0.5 改成 0.7结果会明显变化。所以评测报告必须写明使用的 IoU 阈值、数据集版本和评测代码版本。否则两个团队说“我们 mAP 90”很可能说的不是同一个东西。4.3 评测报告应包含哪些关键字段一份可复现的 AI 汽车能力评测报告至少要有三部分被测对象信息、评测数据集信息、结果指标和运行环境信息。字段示例缺失时的影响模型版本detector_v2.3无法确认测的是哪个模型权重文件哈希sha256:xxx无法确认文件一致性数据集版本nuimages-style-dataset-v4不同版本无法对比测试集切分方式按场景随机切分不按车辆切分可能造成数据泄漏IoU 阈值0.5:0.95 或 0.5指标含义不同计算环境GPU 型号、驱动、依赖库复现时可能不一致mAP0.821只展示最终值不够关键类别 Recall行人 0.94 / 骑行者 0.88全局指标掩盖安全风险边界说明不含雨雪天、不含夜间窄路避免误用模型生产环境还应该加入日志、超时、退化、回滚相关的说明。线下测试通过只是第一关只有仿真、实测和监控数据形成闭环定义才算完整。5. 数据与测试集定义权最容易失控的地方5.1 训练集与测试集重叠会污染一切指标AI 汽车的感知模型训练依赖海量行车数据但如果训练集和测试集来自同一个采集批次且没有按车辆、时间、路段做严格切分模型就可能泄漏表现为“测试集上分数很高换一条路就崩”。这种问题的危害在于它会误导决策。数据切分有一些基本要求按车辆 ID 切分避免同一辆车的数据同时出现在训练和测试阶段按时间窗切分避免模型在评测时已经看到未来数据按路段场景切分避免测试集只覆盖模型训练过的熟悉路段。在项目早期建立评测协议时就要把数据切分规则写成文档并把切分逻辑固化在脚本里。如果数据集和评测代码都在同一套代码仓库里维护每次更新数据时都要重新确认切分逻辑没有被意外变动。5.2 长尾场景和 corner case 需要专门度量普通测试集更多反映数据的统计平均情况但安全风险往往来自统计分布之外的长尾场景。比如交通桩桶被风吹倒、施工区域改道、行人穿黑色衣服夜间过马路、动物突然横穿、大型车辆转弯时内轮差区域出现行人。衡量长尾覆盖能力不能只看平均分数还要看场景子集上的表现。项目组可以把测试集按场景打标签单独统计每个场景子集的 Recall、误报率和接管率。下面是一个简化的场景标签示例。{ scene_id: cut-in-rain-night-001, road_type: highway, weather: rain, light: night, traffic: medium, speed: 80, key_hazard: side_cut_in, model_score: 0.81, result: pass }场景库需要持续扩充。每次发现新问题就把相关片段加入回归场景集确保后续版本不会在这个场景上退步。不能只追求平均指标也不能只靠少数几个极端场景下结论。5.3 数据版本管理和溯源AI 汽车的数据集和标注会频繁更新。如果数据没有版本管理就会面临一个问题同样一个评测脚本昨天跑出的结果和今天跑出的结果不同但没人能说清是哪条数据、哪个标注、哪个模型权重引起的。建议使用类似 DVC 的数据版本管理工具把数据集文件哈希、标注文件哈希和模型权重哈希一起记录到评测结果里。代码仓库里不直接存放几十 TB 的原始数据而是存放数据下载地址和版本指针。数据管理要素推荐做法错误做法原始数据不可变存储按采集批次归档覆盖原始文件标注数据标注任务 id 与数据版本号关联只存最后一份标注测试集单独锁定不许随意修改每次随机抽样评测代码使用 Git 版本号记录脚本到处改名复制模型产物记录权重 hash 和训练版本只记住“感觉更好了”有了这些记录当某个指标变化时团队才能逐层定位是数据变化、标注变化还是模型训练变化引起的。没有溯源能力的评测结论不能作为对外定义 AI 汽车能力的依据。6. 常见争议和踩坑链路从现象倒推根因6.1 “mAP 高实际表现却很差”的排查路径现象模型在公开测试集上 mAP 很高车辆上路后却频繁漏检行人或误报障碍物。可能原因有很多。第一种是测试集和实际场景分布不一致公开测试集以中远景目标为主而实车运行时有很多近处截断目标和小目标。第二种是训练集和测试集存在数据泄漏模型分数被高估。第三种是传感器标定参数异常导致模型输入质量变差。第四种是模型推理延迟过高低速工况下目标位置信息已经过期。排查顺序建议是先确认测试数据本身再检查训练集和测试集切分然后看传感器标定和同步时间戳接着看推理日志里的置信度和输入预处理最后对照实际场景的困难片段补充到回归测试集中。问题现象常见原因检查方式处理建议mAP 高但路上漏检多测试集分布不覆盖关键场景按场景统计子集指标增加夜间、雨雾、截断目标场景测试集分数虚高训练测试数据重叠检查按车、时间切分规则重新切分并锁版本实车感知延迟明显模型推理超时或上游数据延迟记录时间戳和队列堆积压测推理延迟设置超时告警同一模型换车后变差标定外参或传感器位置不同检查标定文件和硬件配置做上车标定评测附带配置签名6.2 “L2 辅助驾驶到底算不算 AI 汽车”的工程解释这个争议在市场上经常出现。从工程角度看L2 级系统通常意思是横向和纵向控制可以同时工作但车辆仍然要求驾驶员持续监控并在任何需要的时候接管。严格来说这类系统属于高级辅助驾驶不是无人驾驶也不是 Robotaxi 式的全无人系统。但“AI 汽车”不等于“无人驾驶”。辅助驾驶、自动泊车、智能座舱、大模型语音助手这些都属于 AI 能力。真正需要说清楚的是当一个产品说自己是 AI 汽车时它到底指哪些能力哪些能力经过了严格评测哪些能力只是实验室结果。工程师在定义产品时要避免一句话概括。更好的做法是明确划分能力等级辅助驾驶能力覆盖哪些场景导航辅助驾驶可以在哪些道路使用泊车能力是否依赖固定车位座舱大模型是否能处理涉及安全的问题。这样定义比争论“是不是 AI 汽车”更有价值。6.3 评测通过但事故仍然发生的预防机制评测通过不代表绝对安全。模型可能遇到未见过的新场景地图可能过期系统状态可能退化驾驶员也可能误解系统能力。为了降低风险生产系统需要设计多道防线。系统运行时应该记录完整的决策上下文包括传感器状态、ODD 判断结果、感知输出、规划轨迹和控制指令。当发生接管或异常时这些日志要能够回放。下面是一个简化日志字段示例。{ timestamp: 2025-01-01T10:00:00.123Z, vehicle_id: demo-01, mode: highway-pilot, odd_version: demo-odd-v1, location: highway-exit-42, weather: rain, light: day, speed: 18.0, sensor_status: { camera_front: ok, lidar_top: degraded, radar_front: ok }, perception: { object_count: 8, low_confidence_count: 1 }, planner: { target_deceleration: -2.5, takeover_required: false }, takeover: { event: true, reason: user_discomfort, elapsed_ms: 380 } }这类日志的价值在于持续定义系统每次实际运行都提供真实反馈。如果接管事件频繁出现说明系统定义把某些场景“高估”了需要收窄 ODD 或改进算法。只有线上日志和线下评测闭环起来AI 汽车的能力定义才能不断更新。7. 谁有资格定义 AI 汽车工程实践的建议7.1 把定义权分散到五方角色上单一角色不应该垄断 AI 汽车的定义权。比较合理的方式是让五方角色各自定义自己擅长的那一层。角色定义什么输出物技术团队算法能力边界、系统指标、运行限制评测报告、ODD、日志规范标准组织分级框架、术语、通用安全要求标准文档第三方测评横向可比性、独立复现独立测试报告监管机构准入条件、上路要求、责任认定法规和审批要求用户真实体验、信任度、接管反馈反馈、投诉、接管日志当企业发布“AI 汽车”相关能力时最有力的方式不是只给结论而是同时提供它的 ODD、评测数据集、评测代码版本、关键指标和失败边界。这套材料越完整定义就越可信。7.2 给从业者的可执行检查清单在团队内部讨论“这辆车 AI 能力强不强”之前可以先过一遍下面这份清单。是否定义了完整的 ODD是否在运行时执行 ODD 检查。是否使用固定版本的数据集和测试集切分规则是否明确。是否记录模型权重、数据集、标注、评测代码的版本。是否同时关注全局指标和关键类别、关键场景指标。是否区分算法层、仿真层、实车实测三层证据。是否有独立的第三方或复盘机制挑战内部结论。是否记录接管、降级、异常退出事件并用于迭代。是否在上线前做了功能安全和预期功能安全分析。是否明确系统在超出边界时的退出策略和用户提示方式。是否保留日志回放能力能否对线上事故做根因分析。如果大部分项都能回答“是”说明团队对 AI 汽车能力的定义是工程化的而不是口号化的。如果很多项是“否”那么即使口号说得再好系统能力也仍然处于难以验证、难以追溯的阶段。7.3 下一步可以延伸的方向AI 汽车的定义权最终会落在数据和工程体系上而不是落在某次发布会上的形容词里。对于开发者团队来说可以先从建立自己的评测基线开始选一个公开数据集固定一个模型版本写一份可复现的评测报告再把 ODD、日志和回放机制逐步接入。之后可以扩展到仿真平台、场景库建设和真实路测数据闭环。更远期可以参与开源基准和第三方评测体系用跨团队、跨企业的对比来校准自己对“好”的定义。到那时“谁有资格定义 AI 汽车”这个问题就不再需要靠争辩解决而会通过可度量、可复现、可追溯的工程实践自动给出答案。