企业官网建设流程全解析

简介：这份资料是一篇面向地面无人作战平台研究、论证与装备管理人员的性能评价研究文献，针对无人平台缺乏统一评价标准、需求方与研制方交流时性能描述口径不一的问题，梳理国内外自主性分级与性能度量研究现状，并从平台内涵出发讨论机动性、自主性和任务载荷性能三类基础维度。文内进一步分析机动性与自主性的支撑指标，构建层次化评价指标体系，并对快速性、灵活性、通过性、续航能力以及环境感知、决策规划、人机交互等指标的内涵与度量方式展开说明，可为指标选取、方案比较和后续量化评估提供参考。资源包共1个PDF文件，大小约306KB，适合按需查阅与引用。目前已有93人学习，便于快速了解该领域早期评价框架与指标设计思路。

1. 从一次对接会上的“鸡同鸭讲”说起

某次地面无人平台的交付对接会上，需求方问的是“这台平台在典型任务剖面下自主性到底处在什么水平”，研制方答的是“能自主跑完一圈、能避障、能绕开临时出现的障碍物”。两句话都没错，但说的不是一回事：一边要的是可比、可复现的数值，一边给的是功能演示。地面无人平台的性能评价长期卡在这个位置——不是没有指标，而是指标定义不统一、测试条件没写清、叶节点根本没法度量，于是需求方、研制方、第三方测试各说各话。这套方案要解决的就是把机动性、自主性、任务载荷性能三个内涵，拆成一棵可测、可复现、可扩展的性能评价指标树，让三方拿到同一套语言。它适合做无人平台总体设计、性能评估、试验验收与课程设计的人直接参考。

2. 内涵拆解与总体架构：三类一级指标撑起一棵四层树

2.1 三个内涵决定三类一级指标

地面无人平台之所以难评，根子在于它同时是三种东西：它是一台机动平台，要能从 A 点运动到 B 点；它是一台无乘员平台，原本由乘员承担的感知、判断、操纵向系统内部转移；它还是一件任务装备，靠挂载不同的任务载荷完成具体任务。这三重身份对应三项基础能力——机动性、自主性、任务载荷性能，缺一项，综合评价就是残缺的。

这个拆法看着朴素，实际解决了一个大问题：它给出了“为什么不能照搬有人平台指标”的正面回答。有人平台的评价体系里，乘员是天然的感知与决策单元，指标只需要衡量“车”本身；无人平台把乘员从车上拿掉了，感知、决策、执行这三段能力必须由系统自己补齐，评价体系里就必须出现对应的度量项。反过来，如果只盯着车体参数（功率、轴距、悬挂行程），自主性这一整块就是空白，两台车在同一个场地跑出完全不同的任务完成率，评价结果却一模一样。

所以一级指标的划分不是分类癖好，而是把“平台是什么”翻译成“平台该测什么”。后续所有叶节点，都必须能回答“它支撑三类基础能力中的哪一个”，答不上来的指标，要么删掉，要么挂到别处。

2.2 树状层次结构：父节点由子节点衡量

指标体系的骨架是一棵树，每个节点是一个指标，父节点的水平由它的子节点共同衡量，所有子节点构成父节点的评价依据。整棵树大致分四层：

这个结构有三个必须写进方案说明的性质。其一，树状结构意味着父子关系明确，任何一个叶节点数值异常，都能沿着路径回溯到具体能力项，不会出现“总分低但不知道低在哪”的黑匣子。其二，分层结构意味着抽象程度可控：给上级汇报看第一、二层，给测试组看第四层，同一套体系两种读法，不用另建一套。其三，评价过程天然是自底向上的——先把叶节点测出来，逐层合成到根节点，中途任何一层都可以停下来出中间结论。

叶节点的选取有一条硬约束：必须是可测量的量，且带单位。凡是只能写成“较好”“较强”“具备一定能力”的描述，一律不许进第四层。这条约束是整个体系能不能落地验收的分水岭。

2.3 指标选取原则与任务载荷的处理

建指标体系时有五条原则要守住：指标宜少不宜多，独立性要好，代表性要强，不同平台之间要有差异性，工程上要可采集。前四条是常规，第五条最容易被忽略——一个指标再科学，如果只有原研制单位自己那套台架能测，第三方复现不了，它在验收场合就等于不存在。

任务载荷这一块，方案里做了一个刻意的取舍：保留一级指标，暂不向下展开。原因很直接，任务载荷是按任务配的，侦察类、运输类、作业类载荷之间几乎没有共同度量口径，硬凑一套叶节点，只会得到一堆互相不可比的数字。合理的做法是把它作为预留子树——等具体任务域确定后，再按该域的载荷特性挂载对应的叶节点。这个处理在答辩时反而是加分项：它说明体系是开放的、可生长的，而不是一次性封死的清单。

同样的思路也适用于新技术：激光雷达换成固态、导航从卫星加惯导换成视觉惯性，叶节点不变，变的只是测试方法。体系稳定的前提是指标稳定，不是器件稳定。

2.4 指标树的配置化落地

把树写进代码配置而不是写进文档，是这套方案能反复用的关键。文档改一次要同步好几个版本，配置改一次只改一处。

# 指标树配置：只描述结构与层级，叶节点另外挂"度量定义" INDEX_TREE = { "综合性能": { "机动性": { "快速性": ["最大速度", "平均速度"], "灵活性": ["加速性", "转向性", "制动性"], "通过性": ["爬坡能力", "越墙高度", "越壕宽度", "涉水能力", "软地面通过性"], "续航能力": ["最大行程", "连续工作时间"], }, "自主性": { "环境感知能力": ["环境感知范围", "环境建模精度", "模型更新频率"], "决策能力": { "任务规划与决策": ["规划与决策速度", "规划与决策正确率"], "自主导航": ["平台定位精度", "路径规划正确率", "路径更新频率"], }, "执行能力": ["指令响应速度", "路径跟踪精度"], "人员依赖度": ["人员操控时间比例", "人员操控平台数量"], }, "任务载荷性能": {}, # 故意留空：按任务域后续挂载子树 } }

配置里有两处设计意图要说清。第一，节点既可以是列表也可以是字典：列表表示“这一层直接就是叶节点”，字典表示“还要再往下分一层”，这样四层树和三层的分支能共存在同一份配置里，不必强行凑齐层数。第二，任务载荷性能是空字典，合成函数遇到空子树时跳过该分支并重新归一化权重，不会因为缺项把总分拉低——这一点在跨任务域比较时特别重要，否则挂了重型载荷的平台会天然吃亏。

配套还需要一张叶节点定义表，把每个名字映射到单位、测试条件和度量口径。配置管结构，定义表管口径，两者分开维护，改口径不动结构。

3. 机动性指标：四类支撑能力与可测量的叶节点

3.1 快速性、灵活性、通过性、续航的四分法

机动性定义为平台从一处运动到另一处的能力，但这个定义太粗，直接拿去测会得到互相纠缠的数字。拆成四类之后，每一类都有独立的物理含义，彼此不重叠：快速性管“跑得快不快”，灵活性管“速度和方向变得利不利索”，通过性管“地形拦不拦得住”，续航管“能跑多久”。

这四类之间确实存在耦合，比如通过性差的平台平均速度必然低。但耦合不等于重复：平均速度是在规定比例路面上统计的，反映的是综合结果；通过性是一组极限值，反映的是能力边界。评价时两者都要，因为一个平台可能平均速度不低，却在某个特定障碍前彻底失效，只看平均值会把这种失效隐藏掉。

灵活性单独成类的理由值得多说一句。初学者容易把加速性并进快速性，实际上两者的测试剖面完全不同：最大速度测的是稳态，加速性测的是瞬态，一台最大速度高的平台完全可能起步肉。转向性和制动性同理，都是瞬态能力，和稳态速度不是一回事。

3.2 叶节点的定义与度量口径

这张表里最容易被砍掉的是“测试条件”那一列，而它恰恰是可比性的来源。同样写“平均速度 18 km/h”，一台是在七成铺装路面上跑出来的，一台是在三成铺装路面上跑出来的，数字一样，能力差一截。口径不写，指标就退化成宣传数字。

还有几个细节要在方案里点明。爬坡能力强调“不用惯性冲坡”，否则测出来的是冲量而不是爬坡；越壕宽度强调“低速”，否则测的是飞越；涉水强调“不用辅助设备”，否则测的是附件的功劳；连续工作时间强调“平均工况”，因为怠速和满负荷差着数倍。每一条限定词背后都有一次踩坑。

3.3 从原始记录换算指标值

试验现场拿到的是时间序列和里程记录，不是指标值，中间要有一步换算。这一步写成函数，保证每次算法一致，避免不同人算出不同结果。

def average_speed(segments): """按路面比例统计的平均速度。 segments: [(里程_km, 用时_h, 路面类型), ...] 路面类型仅用于事后核对比例是否符合规定剖面 返回: km/h """ total_km = sum(seg[0] for seg in segments) total_h = sum(seg[1] for seg in segments) if total_h <= 0: raise ValueError("用时必须为正") return total_km / total_h def acceleration_time(speeds, dt): """从速度序列中取加速性：起步到规定速度的时间。 speeds: 采样速度序列，单位 m/s，等间隔采样 dt: 采样间隔，单位 s """ target = 60 / 3.6 # 规定速度 60 km/h 换算成 m/s for idx, v in enumerate(speeds): if v >= target: return idx * dt return None # 未达到目标速度，判为不通过

average_speed的关键不在算法而在输入：segments里的路面类型虽然不参与计算，但必须记录，用来核对本次试验的公路与越野比例是否符合规定剖面，不符合就整组数据作废，不能拿来横向比较。acceleration_time里把目标速度写成常量并做单位换算，是为了避免有人直接拿 km/h 序列去比 m/s 阈值，这种错误在联调阶段出现过不止一次。

3.4 把测试剖面固化进方案

机动性指标的复现性，八成取决于测试剖面有没有写死。至少四项要固定：载荷状态（空载、额定载荷还是满载）、胎压与悬挂模式、路面类型与长度比例、环境温度与风速。同一台平台，满载和空载的加速性能差一截，胎压不对，软地面通过性直接失真。

工程上的做法是把测试剖面做成一张表，每个指标对应一行剖面编号，试验记录里必须填编号。评审时先看剖面编号对不对，再看数值。这一步看着笨，但它把“数字能不能比”这个问题前置解决了，比事后争论谁的测试更合理要省事得多。

4. 自主性指标：感知—决策—执行闭环与人员依赖度

4.1 自主性的功能闭环定义

自主性常被说成“智能程度”，这个说法没法测。可操作的表述是：为了完成操作人员通过人机接口赋予的目标，系统自身所具备的感知、分析、通信、规划、决策与执行等综合能力。这句话把自主性拆成了一个闭环——感知拿输入，决策出指令，执行产生动作，动作改变环境后再回到感知。

沿着这个闭环，四个可测的方面自然浮现：环境感知能力、决策能力、执行能力，以及人员依赖度。前三个是闭环的组成环节，第四个是闭环的“补丁量”——当前技术水平下没有完全自主的平台，任务完成总需要人不同程度的介入，介入多少本身就是自主性高低的直接体现。

这里要强调一个易被误用的做法：直接给平台打一个“自主等级 1 到 10 级”。等级描述是定性的，两个人看同一台平台可能给出相差三级的判断，因为每一级的含义都是文字描述，没有数值锚点。合理的用法是把等级当作标签，把叶节点数值当作证据——等级用于对外沟通，叶节点用于对内改进和验收。

4.2 环境感知：范围、建模精度与更新频率

环境感知能力指平台通过配置的传感器获取环境信息、处理后建立环境模型的能力，用三个叶节点度量。

感知范围用感知扇形面积表示，扇形圆心为平台中心，半径为最远感知距离，中心角为感知角度。这个度量把“能看多远”和“能看多宽”合成一个数，避免只报最远距离造成的误导——有些平台远距离点测很强，但视场极窄，实际作业时频繁转台。

建模精度用所建栅格地图与真实栅格地图的关联度度量。两张同分辨率、同尺寸的栅格图，每格取值是 0 到 1 之间的障碍概率，逐格取绝对差再平均，用 1 减去它：

相似度 D = 1 − (1/((m+1)(n+1))) · ΣΣ |m_ij − r_ij|

D 落在 0 到 1 之间，越接近 1 越准。这个定义的好处是它同时惩罚两类错误：漏建障碍和虚建障碍，而且惩罚是对称的。

模型更新频率用单位时间内环境模型的更新次数度量，单位是次每秒。动态环境里这个指标比精度更能反映实际可用性，一张建得准但三秒才更新一次的图，在有人员走动的场景里基本没法用。

4.3 决策能力：规划速度、正确率与定位精度

决策能力指根据外界输入、任务与内部状态正确判断并作出决定的能力，拆成两条支线。

任务规划与决策这条线，用规划与决策速度（给定任务后自主完成一次规划决策的平均时间，单位 s）和规划与决策正确率（正确决策次数占总决策次数的百分比）度量。这两个指标必须成对出现，只报速度不报正确率，等于鼓励乱决策。

自主导航这条线，用平台定位精度（定位误差均方差，单位 m）、路径规划正确率（成功规划路径的百分比）、路径更新频率（单位时间路径更新次数）度量。定位精度用均方差而不是最大误差，是因为最大误差受单次异常值影响太大，一次卫星失锁就能把指标毁掉；均方差更能反映常态水平。路径更新频率则对应动态避障能力，更新太慢，规划出来的路径在执行时已经过期。

4.4 执行能力：响应速度与路径跟踪精度

执行能力指严格执行决策结果的能力，包含两件事：听不听指挥，跟不跟得准。

指令响应速度用从指令下达到执行机构开始响应的时间间隔度量，单位 s。对地面平台而言，链路延迟与执行机构响应通常混在一起，测试时要尽量把两者分离，否则定位到的问题会指向错误的模块。

路径跟踪精度用给定直线路径轨迹与平台实际行驶轨迹之间所包含面积的平方根度量，单位 m。这个量的物理意义接近等效横向偏差：轨迹贴合得越好，围成的面积越小。用直线路径做基准，是为了让结果可复现——曲线路径的曲率会影响结果，不同测试场做出来没法比。

4.5 人员依赖度：两个必须同时报的数

人员依赖度是整个自主性体系里最能反映真实水平的一项，也是最容易被简化成“接管次数”的一项。接管次数的问题是它强依赖任务难度：同一条路线，难度调高，接管次数翻倍，但平台能力没变。

更稳的两个度量是：人员操控时间比例，即操控人员干预或帮助平台决策、执行所用时间占完成任务总时间的比例；人员操控平台数量，即一个操控人员能同时控制几台平台。前者衡量“人得盯多紧”，后者衡量“人得配几个”。两个数一起报，才能反映人力成本——时间比例低但一人只能看一台，和比例略高但一人能看三台，后者的实际自主化收益更大。

5. 避坑与常见问题：五个最容易翻车的地方

5.1 指标定义漏了测试条件，数字全废

现象：两台平台都报“平均速度 20 km/h”，放到同一任务剖面下实测差了近三成，双方各执一词。

原因：平均速度强依赖路面构成、载荷状态和胎压，报数时只报了结果没报剖面。这类问题在横向对比场合特别致命，因为双方的数据都“真实”，只是不可比。

解决：把测试剖面编号写进指标定义，作为数值的一部分。试验记录先填剖面编号再填数值，剖面不符的数据一律标为参考值，不参与横向排序。我一般会在指标表里加一列“剖面号”，评审时先扫这一列。

5.2 自主性只报等级，不报叶节点证据

现象：汇报材料写“本平台自主性达到 8 级”，被追问“8 级对应哪些可测能力、每项测到多少”时答不上来。

原因：等级体系本身是定性描述，各级含义用文字界定，没有数值锚点，天然不可复现。把它当结论用，等于把评价变成了玄学。

解决：等级只做对外标签，对内一律用叶节点数值说话。汇报时给一张对照表：等级、支撑该等级的叶节点、每个叶节点的实测值与口径。等级升级必须有对应的叶节点改善，否则不予认可。

5.3 建模精度用“看起来准”评价

现象：评审现场演示建图，众人都说“挺准的”，但两台平台谁更准没人说得清，换一天再测结论还可能反过来。

原因：没有固定真值地图、没有固定栅格分辨率、没有固定评估区域。三样缺一样，两张图就没法逐格对比，只能靠肉眼。

解决：提前用激光跟踪仪或人工测绘做一张真值栅格图，锁定分辨率与评估区域，所有平台在同一区域、同一分辨率下建图，再算关联度。分辨率一旦变动，历史数据全部失效，所以分辨率要写进测试规范，不能临场改。

5.4 人员依赖度只统计接管次数

现象：同一台平台在简单场地接管 2 次、复杂场地接管 9 次，报告里取了 2 次，结论是“自主性良好”。

原因：接管次数与任务难度强相关，脱离任务难度谈次数没有意义；而且它丢掉了“人需要盯多久”这个关键信息。

解决：改用人员操控时间比例与一人可控平台数量两项，并且必须注明任务剖面。时间比例用操作记录打点统计，从任务开始到结束，人为介入的时长累加除以总时长；并行控制台数在模拟控制席上实测，取稳定可维持的上限。

5.5 指标越堆越多，权重靠拍脑袋

现象：指标体系做到三十多个叶节点，权重靠几个人商量着给，换个评审组结论就变，灵敏度分析一做，排序直接翻转。

原因：违背了“宜少不宜多”和“独立性”两条原则，指标间高度相关，权重稍动就互相抵消；权重来源也没有方法支撑。

解决：先做一轮独立性筛查，把相关系数过高的指标合并或剔除，叶节点控制在合理规模；权重用层次分析法或专家打分加一致性检验，别直接给数；最后做权重扰动分析，正负两成扰动下排序是否稳定，不稳定就说明体系还不够健壮，回去继续筛指标。

6. 综合评价与答辩验收：自底向上加权与三张交付表

评价的落地动作是三步：归一化、定权重、自底向上合成。归一化要先区分方向，速度、行程、感知范围这类越大越好的按效益型处理，制动距离、响应时间、定位误差、人员操控时间比例这类越小越好的按成本型处理，公式不能混用，混用会把优劣算反。权重用层次分析法给出，做完一致性检验再用。合成时从叶节点往上逐层加权，中途每一层都能停下来出中间结论，方便定位短板。

给一段能直接跑的核心代码：

def normalize(values, direction="benefit"): """极差归一化到 [0,1]。direction: benefit 越大越好 / cost 越小越好""" lo, hi = min(values), max(values) if hi == lo: return [1.0] * len(values) if direction == "benefit": return [(v - lo) / (hi - lo) for v in values] return [(hi - v) / (hi - lo) for v in values] def composite(scores, weights): """加权合成；权重与得分一一对应，缺失项跳过并重新归一化""" pairs = [(s, w) for s, w in zip(scores, weights) if s is not None] if not pairs: return None w_sum = sum(w for _, w in pairs) return sum(s * w for s, w in pairs) / w_sum

两个函数的边界处理是关键：normalize在极差为零时全给 1.0，避免除零；composite遇到None就跳过并重新归一化权重，这样某个叶节点因设备缺失没测到时，不会把整条分支的分数拉低，只会降低该分支的置信度，需要在报告里单独标注。

答辩和验收环节，我通常要求交付三张表，缺一张就要返工：

评审时按这三张表倒着看：先看结果表里哪个叶节点拖了后腿，再看剖面表确认那一项是在什么条件下测的，最后看定义表确认口径没被改过。三步走完，结论基本站得住。另外记得预留一个环节做权重扰动，正负两成，看排序会不会翻——翻了不一定是体系有问题，但必须能解释清楚为什么翻。

从那以后我每次牵头做平台评价，都强制先走一遍“定义表、剖面表、结果表”这个顺序，哪怕时间再紧也不跳步。跳过定义直接测，后面全是争论；跳过剖面直接比，数字再漂亮也没人认。希望帮到你。

本文还有配套的精品资源，点击获取