简介:面向地面无人作战平台研究、论证与研制交流场景的学术文献,针对当前缺乏统一性能评价标准、不同单位对平台性能描述不一致的问题,梳理国内外自主性分级与性能度量研究现状,并从平台内涵出发构建层次化评价指标体系。文中将机动性、自主性和任务载荷性能视为综合性能评价的基础,重点讨论快速性、灵活性、通过性、续航能力,以及环境感知、决策规划、学习适应和人机交互等支撑指标的内涵与度量思路,可为装备需求方、研制人员和相关专业学习者提供指标设计与性能描述的参考框架,也适合撰写综述、论证报告时对照查阅。资源包共1个PDF文件,约306KB,篇幅紧凑,便于快速检索与引用;已有93人学习下载。
1. 两台平台摆在同一张评审桌上,谁更强说不清
两台地面无人平台摆在同一张评审桌上,A 方材料写的是「最大速度 25 km/h、续航 6 h」,B 方写的是「越野平均速度 12 km/h、连续工作 4 h」。两份材料都合规,却没法判断谁更强——这正是地面无人平台性能评价指标体系要解决的问题。口径不统一,需求方和研制方对不上话,不同研制方之间也各说各话,最后只能靠印象打分。
这套体系的做法是:把平台拆成机动性、自主性、任务载荷三条内涵,再往下展开成一棵可计算、可实测的指标树,每个叶节点都给出定义、单位和采集方式,评价过程自底向上逐层汇总。它适合两类人:要交一份完整性能评价方案的毕设或课设学生,以及要给多台平台做横向比对的评测负责人。下面按需求边界、总体架构、两个维度的指标落地、避坑、验收的顺序走一遍。
2. 需求边界与总体架构:从三条内涵长出 24 个可测叶节点
2.1 现状盘点:定性分级撑不起一次横向比较
围绕无人平台自主程度的描述,国外较早就有分级方案。一种做法把自主性划成 0~10 共 11 个等级,另一种划成 1~10 共 10 个等级,并从感知、决策、能力几个方面描述各级内涵。这些分级在沟通概念时好用,但每一级都是描述性的,没有明确的数量化指标去标示和衡量,两家单位都说自己「达到 7 级」,实际能力可能差出一大截。
更接近落地的尝试出现在城市搜索与救援机器人评测上:先设计一个工作场景,让机器人在场景里跑搜索任务,从过程中采集定位、建图、人机接口、可靠性等变量的值,再套进一个度量公式算出总体得分。这种「场景+变量+公式」的思路是对的,问题在于强绑定单一任务,换个任务场景公式就失效。
国内的公开成果相对少,能查到的多是无人驾驶车辆智能测试标准与环境设计方向的预研,尚未形成可直接套用的指标清单。供给端的空白,直接导致需求描述层面的混乱:同一台平台,有人强调爬坡角度,有人强调连续工作时间,指标集合都不一样,横向比较无从谈起。指标体系的第一价值不是打分,而是把「说什么」这件事先统一掉。
还有一层必须提前想清楚:有人平台那套成熟的评价指标不能直接搬。有人平台默认车里坐着人,感知、判断、处置由乘员兜底,指标只需衡量车本身;无人平台把乘员那份能力挪到了系统内部,感知、决策、执行全要自己扛,还要额外度量「人还得帮多少」。指标集合因此必须重做,而不是在旧表上删几行。
2.2 三条内涵划出指标边界,任务载荷只留接口
平台的内涵决定了指标的边界。一条是「机动平台」,对应机动性;一条是「无乘员平台」,原本由乘员承担的功能要由平台自己完成,对应自主性;一条是「具备任务能力」,通过配置特定任务载荷实现,对应任务载荷性能。三条内涵不是并列的口号,它们各自对应一组功能子系统,子系统的性能决定平台综合性能,指标就挂在这些子系统上。
任务载荷这一支在方案里做了取舍:载荷配置由具体任务决定,不同类型的载荷之间缺乏可比性,硬把一份载荷清单塞进同一棵树里横向打分,结果没有意义。通常的做法是只保留载荷作为一级维度的接口位置,在具体评测任务中再按任务类型单独展开子表,通用指标体系不往下钻。
于是通用部分收敛成两个一级维度、八个二级维度:机动性下的快速性、灵活性、通过性、续航能力;自主性下的环境感知能力、决策能力、执行能力、人员依赖度。再往下展开到叶节点,一共 24 个,每个叶节点都对应一个能在台架或场地上实际测出来的量。这 24 个数字就是整套体系的「底数」,上层所有结论都由它们算出来。
2.3 建标四条原则与树状分层结构
建指标集时容易犯的错是贪多。原则上有四条约束:指标宜少不宜多,能用一个指标说清的不拆成三个;指标之间保持独立性,避免同一能力被重复计权;指标要有代表性,能反映该维度的主要矛盾;指标要具备差异性与可行性,既能把不同平台区分开,又能在现有测试条件下采到值。第四条的筛除力最强,很多看起来漂亮的指标就是因为测不出来被砍掉的。
结构上采用树状分层。每个节点是一个指标,父节点的水平由子节点衡量,所有子节点共同组成父节点的评价集合。上层节点综合性强、抽象程度高,屏蔽了具体实现细节;底层节点具体、可测、单位明确。这种分层带来一个实际好处:评价目的变了,可以只展开相关子树,或者在不影响其他分支的前提下增删某个分支,不用推倒重来。
评价流程因此固定为自底向上:先采齐所有叶节点值,逐层向上汇总到二级维度,再汇总到一级维度,最后得到综合评价结果。这个方向不能反,一旦允许上层直接拍分,叶节点的采集就形同虚设。
2.4 指标树的数据结构与一致性校验
指标树在文档里画出来是一张图,在代码里必须是一个能校验的结构,否则增删节点时很容易出现「父节点写了单位、叶节点没写度量方式」这类问题。下面这份定义把节点类型、方向、单位和子节点关系都收进一个 dataclass:
from dataclasses import dataclass, field from typing import List, Optional @dataclass class MetricNode: code: str # 指标编码,全局唯一,如 MOB_SPEED_MAX name: str # 中文名 direction: int = 1 # +1 越大越好,-1 越小越好 unit: Optional[str] = None # 仅叶节点填写,如 "km/h" measure: Optional[str] = None # 仅叶节点填写:采集与计算方法 children: List["MetricNode"] = field(default_factory=list) @property def is_leaf(self) -> bool: return len(self.children) == 0 def validate(root: MetricNode) -> List[str]: """返回问题清单,空列表代表结构合法""" problems, seen = [], set() def walk(node: MetricNode): if node.code in seen: problems.append(f"编码重复: {node.code}") seen.add(node.code) if node.is_leaf: # 叶节点必须有单位与度量口径,否则数据落不了库 if not node.unit: problems.append(f"叶节点缺单位: {node.code}") if not node.measure: problems.append(f"叶节点缺度量口径: {node.code}") else: # 非叶节点不允许挂单位,避免被直接赋分 if node.unit: problems.append(f"非叶节点不应有单位: {node.code}") for child in node.children: walk(child) walk(root) return problems这段代码做了三件事。code作为主键贯穿后续所有数据表,采集表、评分表都靠它关联,避免用中文名做键。direction提前声明方向,是因为 24 个叶节点里有相当一部分是「越小越好」,比如制动距离、指令响应时间、定位误差,归一化时必须知道往哪边翻。validate的两条硬规则对应两个高频翻车点:叶节点没有度量口径,现场就没人知道该怎么测;非叶节点挂了单位,评审时一定有人拿它当叶节点直接填数。
跑一次校验,正常输出应该是空列表。如果输出里出现某个非叶节点「不应有单位」,别急着改代码,先确认是不是有人把二级维度当成了可直接打分的项,那通常意味着下面的叶节点还没设计完。
3. 机动性指标:四类支撑性能与 12 个叶节点的度量口径
3.1 快速性与灵活性:速度、加速、转向、制动
机动性的定义很朴素:平台从一个位置运动到另一个位置的能力。这句话落到指标上要拆成四类,快速性、灵活性、通过性、续航能力,四类各自还是综合指标,得继续往下拆,拆到能拿秒表、卷尺和测速设备读出数为止。
快速性用两个指标表征:最大直线行驶速度和平均速度。前者是平台在良好道路上的最大行驶速度,单位 km/h;后者是平台在规定比例的各种公路与越野路面上的平均行驶速度,同样以 km/h 计。这两个指标看着像,含义完全不同,最大速度反映动力上限,平均速度反映综合工况下的实际推进效率,评测时不能互相替代,也不能拿最大速度去填平均速度那一栏。
灵活性用三个指标表征:加速性、转向性、制动性。加速性是在规定路面与环境条件下,从起步加速到规定速度所需的时间,单位 s,注意「规定速度」要在方案里写死,否则不同单位各取各的终点,数据不可比。转向性用最小转向半径度量,即稳定转向时从转向中心到车体纵向对称轴线的最小距离,单位 m,这个值直接决定了平台在狭窄通道和室内空间的可用性。制动性用制动距离度量,即在规定工况下以规定速度在规定水平路面上行驶,从紧急制动开始到停车所移动的距离,单位 m,属于典型的「越小越好」型指标。
3.2 通过性:爬坡、越墙、越壕、涉水与软地面
通过性是四类里叶节点最多的一类,因为它面对的是完全不同的地形障碍,每种障碍对应一种失效模式,没法用一个数概括。
爬坡能力用最大爬坡度度量,定义要卡死:在规定坡道上,不用惯性冲坡所能通过的最大纵向坡道角,单位度。加不加「不用惯性冲坡」这个限定,测出来的结果能差出好几度,这是口径统一里最容易被忽略的一处。
越障能力拆成两个指标:越墙高度和越壕宽度。越墙高度是垂直翻越水平地面上规定坚实垂直墙的最大高度,单位 m;越壕宽度是低速行驶能跨越的水平地面上壕沟的最大宽度,单位 m。这两个指标必须绑定行驶状态,越壕写的是「低速行驶」,高速冲过去跨过的宽度不计入。
涉水能力是不用任何辅助设备、器材的情况下,能安全通过规定宽度水障碍的最大深度,单位 m。软地面通过性用平台通过地面时的平均接地压力度量,单位 kg/m²,这个指标选得比较讲究——它不直接测「陷不陷车」,因为陷车还跟土壤含水量、履带花纹相关,变量太多不可控;接地压力是一个能算能测的中间量,把地形侧的不确定性挡在外面。
3.3 续航能力与工况约定
续航能力用连续工作时间和最大行程两个指标。最大行程是一次加足规定数量的油料或充满电后,按规定的道路、环境条件和速度所能行驶的实际里程,单位 km;连续工作时间是平台在平均工况下的最长连续工作时间,单位 h。
把这两个指标并列是有原因的:电驱平台和油驱平台的能量特性不同,有的平台能跑很远但跑不久(散热或电池放电倍率限制),有的平台能连续工作很久但单位时间耗能高。只报其中一个,都会给需求方传递错误印象。方案里还专门加了「平均工况」这个限定,因为怠速待机和满负荷越野的耗能完全不是一个量级,不约定工况,报出来的时间没有参考价值。
3.4 机动性叶节点的采集表与入库
12 个叶节点整理成一张表,采集和评审时对着表走,避免现场临时定义:
| 叶节点 | 度量定义 | 单位 | 方向 |
|---|---|---|---|
| 最大速度 | 良好道路上的最大行驶速度 | km/h | +1 |
| 平均速度 | 规定比例公路与越野路面上的平均行驶速度 | km/h | +1 |
| 加速性 | 规定路面条件下从起步加速到规定速度的时间 | s | -1 |
| 转向性 | 稳定转向时转向中心到车体纵向对称轴线的最小距离 | m | -1 |
| 制动性 | 规定速度下紧急制动到停车的移动距离 | m | -1 |
| 爬坡能力 | 不用惯性冲坡能通过的最大纵向坡道角 | ° | +1 |
| 越墙高度 | 垂直翻越规定坚实垂直墙的最大高度 | m | +1 |
| 越壕宽度 | 低速行驶能跨越的壕沟最大宽度 | m | +1 |
| 涉水能力 | 不用辅助器材能安全通过水障碍的最大深度 | m | +1 |
| 软地面通过性 | 通过地面时的平均接地压力 | kg/m² | -1 |
| 最大行程 | 加足油料或充满电后按规定条件行驶的实际里程 | km | +1 |
| 连续工作时间 | 平均工况下的最长连续工作时间 | h | +1 |
数据入库建议按「一平台一指标一记录」的方式存,保留测试条件,方便复现和追溯:
CREATE TABLE ugv_leaf_metric ( id BIGINT PRIMARY KEY, platform_id VARCHAR(32) NOT NULL, -- 平台代号,如 UGV-A metric_code VARCHAR(64) NOT NULL, -- 对应指标树叶节点编码 raw_value DOUBLE NOT NULL, -- 原始实测值 unit VARCHAR(16) NOT NULL, test_cond VARCHAR(255), -- 测试条件:路面、载荷、车速等 sample_count INT DEFAULT 1, -- 重复采样次数 measured_at TIMESTAMP, UNIQUE KEY uk_platform_metric (platform_id, metric_code) );test_cond这一列不要省。同一台平台的越壕宽度,空载和满载能差出 20 cm 以上,没有条件字段,事后看到两个不同的数根本没法判断哪个对。sample_count用来标记重复采样,通常的做法是关键指标至少测三次取中位数,次数一并记下来,答辩时被问到波动性可以直接调。
叶节点值收集齐之后,进汇总前必须做方向统一和量纲消除:
def normalize(value: float, lo: float, hi: float, direction: int) -> float: """ min-max 归一化到 [0, 1],并按 direction 翻转方向 lo / hi 为该指标在本批次平台中的实测下界与上界 """ if hi == lo: return 1.0 # 所有平台该项相同,视为无区分度 score = (value - lo) / (hi - lo) return score if direction == 1 else 1.0 - scorelo和hi取的是同批次参评平台的实测极值,而不是理论极值。这一点会影响结果:如果这一批只来了两台平台,归一化后的分差会被放大,看起来差距很大,实际绝对差值可能只有一点点。正式横向比对建议参评平台不少于三台,并在报告里同时给出原始值和归一化值。
4. 自主性指标:感知、决策、执行与人员依赖度的量化方法
4.1 环境感知能力:感知范围、建模精度与更新频率
自主性比机动性难量化,因为它没有直观的物理量。业界对自主性的定义大致一致:为了实现操控人员通过人机接口赋予的目标,系统自身所具有的感知、分析、通信、规划、决策和执行等综合能力。这个定义从功能模块角度切分,正好对应「感知—决策—执行」三段,再补上「人还得帮多少」这一维,就构成自主性的完整指标框架。
环境感知能力指平台通过配置的传感器获取环境信息、处理后建立环境模型的能力,用三个指标表征。
环境感知范围用感知扇形面积度量:以平台中心为圆心,最远感知距离为半径,感知角度为中心角,算出的扇形面积,单位 m²。这个指标把「看得多远」和「看得多宽」压成一个数,好处是直观,代价是丢失了视场形状信息——同样是 100 m²,窄长视场和宽扁视场在通过路口时的表现完全不同,所以报告里建议同时附上最远感知距离和中心角两个原始量。
环境建模精度用所建栅格地图与真实栅格地图之间的关联度度量。两张地图分别表示为占据概率矩阵,元素取值在 0 到 1 之间,表示该栅格存在障碍的概率。关联度的落地算法就是逐格比对:
import numpy as np def grid_map_correlation(built: np.ndarray, truth: np.ndarray) -> float: """ built / truth: 同尺寸栅格占据概率矩阵,元素取值 [0, 1] 返回 0~1 的关联度,1 表示与真值完全一致 """ if built.shape != truth.shape: raise ValueError("两张地图尺寸必须一致,先做重采样对齐") diff = np.abs(built - truth) # 平均绝对差越小,关联度越高 return float(1.0 - diff.mean())三个前置条件决定了这个数可不可信。第一,两张图必须先对齐到同一分辨率、同一坐标系,没对齐直接算,关联度会低得毫无意义;第二,真值地图怎么来要说清楚,通常是用高精度激光扫描或人工测绘构建,这一点在答辩时一定会被问到;第三,占据概率的阈值化要统一,0.5 以上算占据还是 0.6 以上算占据,两套标准算出来的结论不一样。
模型更新频率用单位时间内环境模型的更新次数度量,单位次/s。这个指标反映的是平台对环境动态变化的响应速度,静态场景下它不重要,一旦场景里有移动障碍,更新频率低的平台会出现「地图里有个人,人走了地图上还在」的情况。
4.2 决策能力:规划决策速度与正确率、定位精度、路径规划
决策能力指根据各种外界输入信息、任务和内部信息正确判断并作出决定的能力,内涵包含两块:任务规划与决策、自主定位与导航。
任务规划与决策的产出是「做什么」,用两个指标:规划与决策速度,即给定任务后自主完成一次规划与决策的平均时间,单位 s;规划与决策正确率,即正确规划与决策的次数占总次数的百分比。正确率的分母和判定标准要在方案里写死,通常的做法是预设若干典型任务场景,由至少两名评审独立判定「这次决策是否合理」,两人不一致时引入第三人。判定标准不写死,正确率这一栏谁填谁有理。
自主定位与导航的产出是「怎么走」,用三个指标:平台定位精度,用定位误差均方差度量,单位 m;路径规划正确率,用运行过程中成功规划路径的百分比度量;路径更新频率,用单位时间内规划路径的更新次数度量,单位次/s。定位精度用均方差而不是最大误差,是因为最大误差受单次异常点影响太大,一次信号遮挡就能把数据拉爆,均方差更能反映整体水平——但报告里建议把最大误差作为附注一起给出,毕竟工程上关心最坏情况。
4.3 执行能力:指令响应速度与路径跟踪精度
执行能力指严格执行决策结果的能力,包含指令响应速度和执行精度两方面。对地面无人平台来说,执行精度主要体现为能否精确跟踪导航系统规划出的路径。
指令响应速度用从指令下达到执行机构开始响应的时间间隔度量,单位 s。这个指标的测试要区分指令类型,转向指令和加减速指令的响应链路不一样,混在一起取平均没有意义,通常分类型各测一组。
路径跟踪精度用给定直线路径轨迹与实际行驶轨迹之间所包围面积的平方根度量,单位 m。选直线路径是为了排除路径曲率带来的额外误差,让不同平台在同一基准下比较。面积取平方根是把量纲从 m² 拉回 m,便于理解。这个指标也有前提:实际轨迹要能稳定复现,同一路径跑三次的轨迹离散度要一并记录,否则单次结果的说服力有限。
4.4 人员依赖度:操控时间比例与一人控多台
前三类指标描述平台自己能做到什么,人员依赖度描述「人还得搭进去多少」,这是无人平台区别于有人平台最实质的一维。
人员操控时间比例,用平台运行过程中操控人员干预或帮助平台进行决策和执行动作所用时间占完成任务总时间的比例度量。这个比例越低,自主性越高。统计口径必须提前约定:通信中断的时间算不算操控时间、平台自主待机的时间算不算任务总时间、一人同时看多台时时间怎么分摊。这几条不定清楚,两家单位报出来的比例能差一倍。
人员操控平台数量,用一名操控人员能同时控制几台平台度量,单位台。这是一个人机比指标,直接对应实际使用中的人力成本。测试时要给「同时控制」下定义:是仅在监控层面同时盯多台,还是要对多台同时下达干预指令。通常的做法是分级给出,比如「仅监控 N1 台 / 需定期干预 N2 台 / 需持续操控 N3 台」,单报一个数会掩盖差异。
12 个自主性叶节点汇总如下:
| 叶节点 | 度量定义 | 单位 | 方向 |
|---|---|---|---|
| 环境感知范围 | 感知扇形面积(半径最远感知距离,中心角感知角度) | m² | +1 |
| 环境建模精度 | 建图与真值栅格地图的关联度 | 无量纲 | +1 |
| 模型更新频率 | 单位时间环境模型更新次数 | 次/s | +1 |
| 规划与决策速度 | 给定任务后完成一次规划决策的平均时间 | s | -1 |
| 规划与决策正确率 | 正确规划决策次数占总次数的百分比 | % | +1 |
| 平台定位精度 | 定位误差均方差 | m | -1 |
| 路径规划正确率 | 运行过程中成功规划路径的百分比 | % | +1 |
| 路径更新频率 | 单位时间规划路径更新次数 | 次/s | +1 |
| 指令响应速度 | 指令下达到执行机构开始响应的时间间隔 | s | -1 |
| 路径跟踪精度 | 给定直线路径与实际轨迹所围面积的开方 | m | -1 |
| 人员操控时间比例 | 干预或帮助决策执行的时间占任务总时间比例 | % | -1 |
| 人员操控平台数量 | 一名操控人员能同时控制的平台数 | 台 | +1 |
两套叶节点加起来的 24 个指标,全部有单位、有方向、有可执行的采集口径。到这一步,指标体系才算有了「底数」,上层任何加权方式都只是对这批数字的不同组织,不会凭空造出新信息。
5. 避坑与常见问题:五处最容易让指标体系当场失效的地方
5.1 拿理想路面的最大速度去填「平均速度」
现象:报告里平均速度一栏填的数和最大速度几乎一样,两台平台在这一项上分不出高低。
原因:测试场地是平整硬化路面,全程没有越野段,测出来的自然接近最大速度。规定要求是「规定比例的各种公路和越野路面」,这个比例在方案里没写,测试方就按最省事的方式跑。
解决:在采集表里把路面配比写死,通常按硬化路、碎石路、土路各占一定比例,测试前报备路线。平均速度的分母是全程时间,中途任何停车、等待都要计入。
5.2 非叶节点被直接赋分
现象:评审表上「机动性」一栏被打了 85 分,但下面 12 个叶节点有一半空着。
原因:评审人习惯对整体印象打分,指标体系的分层结构没有落到表格上,汇总表直接给了二级维度行。
解决:用指标树校验把这条路堵死,非叶节点带单位就报错。评审表只生成叶节点行,二级维度和一级维度的分值全部由公式算出来,不提供手填单元格。
5.3 自主性只报等级不报底数
现象:对方材料写「自主等级达到 7 级」,问具体感知范围多大、建模精度多少,答不上来。
原因:分级体系流行,描述性等级比量化指标好写,一套等级表能套用到各种平台,写材料省事。
解决:等级可以作为对外沟通的口径,但内部评测必须落到 12 个自主性叶节点上。评审规则里加一条:凡引用等级的,必须附对应叶节点实测值,否则该项按缺测处理。
5.4 指标之间强相关,同一能力被重复计权
现象:某平台的机动性得分明显偏高,拆开看,最大速度、平均速度、加速性三项都高,而这三项本质上是同一个动力水平的三种表现。
原因:建标时只考虑「要覆盖哪些能力」,没做相关性检查,等权相加等于给动力性加了三倍权重。
解决:汇总前先算叶节点之间的相关系数,强相关的指标合并成一个二级维度内的子组,组内降权,或者每组只保留一个代表指标。权重不拍脑袋,用层次分析或熵权法算,把计算过程留在附录里。
5.5 人员操控时间比例统计口径不统一
现象:同一台平台,两家单位测出的人员操控时间比例一个 15%,一个 45%。
原因:一家把通信链路中断的等待时间算进了操控时间,另一家没算;一家按单人操控计,另一家按双人轮班计,分母不一样。
解决:在方案里给出明确的任务剖面定义,把「任务总时间」拆成平台自主运行、人员干预、链路异常三类,逐类计时。计时工具统一,通常是带时间戳的操作日志,而不是事后凭记忆估算。
6. 验收与答辩:用三张表和一次复现把体系讲圆
验收阶段的核对,重点不是分数好不好看,而是这套指标能不能被别人照着跑一遍。准备三张表就够了:
| 表 | 内容 | 判据 |
|---|---|---|
| 指标树表 | 24 个叶节点的编码、名称、单位、方向、度量口径 | 无重复编码,无缺单位、缺口径的叶节点 |
| 采集记录表 | 每台平台的原始值、测试条件、采样次数、时间 | 关键指标至少 3 次采样,测试条件完整 |
| 汇总计算表 | 归一化过程、权重来源、各级得分 | 计算过程可复算,权重有出处 |
答辩时的讲述顺序建议跟指标树的生成顺序反过来:先讲三条内涵,说清为什么是机动性、自主性、任务载荷三条,为什么任务载荷只留接口;再讲结构,树状分层、自底向上的评价方向,说明为什么不允许对非叶节点直接赋分;然后挑两个叶节点讲度量细节,一个机动性的(越壕宽度,讲限定条件),一个自主性的(环境建模精度,讲关联度算法和地图对齐的前提);最后留一段讲复现——同一台平台、同一场地、同一套采集表,换一队人能不能测出接近的数。这一段最能说明问题,评审最关心的往往不是分值高低,而是这个数明年换个单位还能不能测出来。
被问到「为什么不多设几个指标」时,不要答「覆盖更全面」,答建标四原则里的宜少不宜多和可行性:多一个测不出来的指标,等于给整棵树开了一个可以随便填的口子。被问到「权重怎么定」时,坦白说权重是组织方式不是信息本身,把权重计算过程和敏感性分析一并给出——换一组权重后排序是否变化,变了说明平台之间差距本来就不大,这个结论比分数更有价值。
从那以后我每次做这类评测方案,都强制走一遍「叶节点能不能当场测出来」的自检:随便点一个叶节点,问测试负责人用什么设备、在什么场地、测几次、条件怎么记。答不上来的,这个指标要么改写要么砍掉,绝不留着等评审时再补。希望这套结构能帮到你。
本文还有配套的精品资源,点击获取