要不要把 ABot-Earth 0.7 用在交通或城市仿真里，判断点不在渲染好不好看，而在它交付的是哪一层：尺度受约束的静态场景、带语义标签的场景，还是含动态参与者的可运行场景。这三层可以分开确认，而且不能互相推断——演示里街区看起来比例正常，不代表路网带可查询标签；车辆在动，也不代表有实时交通流。比较稳妥的顺序是先做一轮尺度、语义、动态的核对，把确认不了的能力写进待验证清单，再决定是否投入试点。

城市仿真场景按尺度、语义、动态三层分别核对：尺度层看最小街区与车道、车辆的相对比例是否自洽；语义层看路网、建筑、植被是否有可查询标签；动态层看车辆行人是否实时生成。任何一层只凭演示观感推断，都不足以支撑选型。建议先用带参照物的截图和场景导出文件留证据，把无法确认的项列为待验证，再决定是否深入试用。

量一遍演示里最小街区与实际道路的尺度关系

这一层解决的是「生成出来的东西能不能量」。演示视频里最容易误导人的地方是镜头：广角、贴地视角、快速推拉，都会让街区看起来比实际更紧凑或更宽松，所以核对时必须先固定两件事——同一路段的可对比参照物，以及截图的相机视角。

参照物优先选演示里已经带标注或轮廓清晰的对象，比如车道线、斑马线、路缘石、路灯杆，以及行驶中的车辆本身。不要用「感觉差不多」来判断尺度是否可信。

• 记录可对比的参照物：把同一段道路截两张图，一张俯视、一张跟车视角，看车辆与车道线的相对比例是否一致。如果俯视图里车辆明显宽于相邻车道线，说明生成结果没有锁定到真实尺度约束，只是视觉效果。
• 记录相机视角：标注清楚这张截图用的是自由视角、固定俯视还是第一人称视角。不同视角下的比例不能直接横向比较，混用会让判断完全失真。
• 记录尺度标注：界面或导出文件里是否给出单位、比例尺、坐标范围。有标注才谈得上尺度约束，没有标注就只能记为待验证。

这里刻意不估算具体米数。一次截图加上未知焦距，换算出来的数字没有核验价值；只有当场景里存在单位标注或可读的坐标范围时，再谈尺度才有意义。

检查路网、建筑、植被是否带语义分层

仿真里能不能按对象筛选，取决于路网、建筑、植被这些元素是不是分了层、带了可查询的标签。图层面板里颜色分明，不等于标签可查询，这两件事要分开记。

先把实际看到的东西枚举出来：图层面板的条目、对象树的节点类型、鼠标点选后弹出的属性面板。逐条写名称，不要写「道路相关」「绿化相关」这种合并描述，否则后续没法复用。

• 列出看到的图层或对象类型：例如道路中心线、车道面、建筑轮廓、树冠、地面等，一项一行。
• 标注是否有可查询的标签：属性面板里是否存在类别字段，导出文件里是否存在对应键值。

如果场景可以导出为结构化文件，可以先用一段通用命令看字段，字段名以实际导出文件为准：

grep -o -E '"(class|label|semantic|layer|tag|type)"[[:space:]]*:' scene_export.json | sort | uniq -c

这条命令的作用是确认这些键是否真的落在导出结果里，而不是只存在于界面上。如果导出文件里查不到类别键，说明语义层还不能支撑按对象筛选的仿真流程，需要先用属性面板截图留证据，并把该项放进待验证清单。

区分静态场景与动态参与者

演示动画和仿真能力是两回事，判断方法不是看画面，而是看时间轴、状态重置和运行日志。把看到的车辆、行人等元素逐项标注为实时生成还是预制动画，是这一层唯一要交付的记录。

• 暂停或停止仿真时钟后，车辆是否仍在移动。如果时间停了车还在跑，多半是预制动画而不是运行时行为。
• 把场景重置到初始时刻，观察同一辆车的轨迹是否逐帧复现。完全复现且不受任何外部输入影响，倾向预制。
• 改变相机位置或视角，动态元素是否仍按原轨迹运行。只有渲染层变化、行为不变，说明行为逻辑不在场景内部。
• 查看运行日志里是否出现参与者生成、交通流、路径规划一类事件记录，可用通用检索先看有没有：

grep -iE 'agent|spawn|traffic|pedestrian|route' run.log | tail -n 50

日志里没有这类记录，不等于没有动态能力，只能说明当前这次运行没有暴露出来。这种情况应记为待验证，而不是直接判定支持或不支持。

把无法确认的能力写成待验证清单

把前三个小节里「看不清」的项集中起来，写成一份可交付的待验证清单。写法上避免结论性判断，只写需要什么材料才能确认。

• 尺度类：是否存在单位与坐标范围定义；最小街区是否对应真实道路网；建筑高度与路宽是否为固定比例关系。
• 语义类：类目标签是否可查询；标签层级是否覆盖到车道级；导出格式是否支持按类别过滤。
• 动态类：参与者是否为运行时生成；是否接受外部交通流输入；时间推进是否可被外部时钟控制。
• 接入类：是否有可调用的接口或配置文件；能否替换输入数据源；日志是否记录参与者状态。

记录模板建议固定成下表，一行一个能力项，状态只填三档，避免出现「大概可以」这类描述。表可以直接放进项目文档，拿到官方说明或试用环境后再回填。

状态一栏只允许「能用、待验证、不能用」三种取值。填「能用」要有可复现的证据，比如导出文件里确实能查到字段；填「不能用」只针对本次运行的观察结果，最好在备注里写清观察范围，别把一次现象当成整体结论。按这套流程走完，ABot-Earth 0.7 能覆盖的是哪一层、还缺哪一层，就会比看演示视频清楚得多。