看懂易盾空间推理：从图形识别、方位判断到API接入

一、空间推理的难点，藏在题目和图形之间

空间推理验证看起来像一道找图小游戏：画面里摆着几个立体物体，题目要求找出某个颜色、某种形状，或者位于指定方向的目标。人眼往往扫一下就能判断，程序却需要逐步回答三个问题：画面上有什么，题目指的是谁，最后应该选择哪个位置。

以“选择红色立方体右侧的蓝色球体”为例，识别出蓝色球体只是第一步。程序还得找到红色立方体，把它当作参照物，再比较两个物体的位置。如果画面里有两个蓝色球体，单靠类别和颜色就会选错，相对位置才是决定结果的关键条件。

实际分析可以把任务拆成图像理解、语义解析、关系判断和结果输出四个环节。图像理解负责找出物体，语义解析负责整理题目条件，关系判断筛选候选目标，结果输出则把目标位置转换成业务需要的数据。每个环节单独检查，问题会更容易定位。

前端响应中可能出现名为front的字段，但字段名本身不能说明它究竟承载图片、题目信息还是其他资源。分析时应结合响应内容与页面渲染结果核对，确认题目从哪里来、图片如何展示，以及哪些字段会随验证轮次变化，避免凭名称推断用途。

题目中的keyword、color、direction可以作为语义拆分的起点，分别对应物体类型、颜色属性和方位关系。不过这三个字段只是一个基础框架。如果题目同时包含参照对象和目标对象，两者都应保存各自的属性，否则“谁在谁的右边”很容易被解析反。

初步梳理时，可以先观察浏览器里已经加载的图片、文字和页面元素，记录同一轮题目对应的输入与输出。把识别结果画回图片，比只看接口返回值直观得多。图框圈错了物体，或题目条件漏了一项，通常在这一阶段就能看出来。

做逆向分析也需要保留这样的分层视角。页面事件、图像识别、参数处理和服务端反馈各自解决不同问题。识别坐标正确，并不意味着请求一定被接受；请求有响应，也不代表目标判断正确。沿着数据流逐层核对，才能避免把所有异常都归到模型身上。

二、样本标注要能支撑判断，不能只给图形起名字

搭建识别流程之前，先整理有权使用的样本。每张图片最好同时保存对应题目、原始尺寸、目标框和属性标签。图片与题目必须一一对应，否则后续即使模型训练正常，关系判断也可能建立在错误的样本记录上，排查起来尤其费时间。

标注时最容易省掉的是颜色和方向。只把目标命名为“球体”“圆锥”“立方体”，检测器能够区分形状，却无法直接处理“红色球体”这样的条件。可以把形状与颜色拆成独立属性，也可以组合成类别；具体选择要看类别数量和样本规模。

组合标签比较直观，例如“蓝色球体”就是一个类别，但颜色与形状一多，类别数量会迅速增加。独立属性更便于扩展，却需要处理属性与目标框之间的对应关系。对于刚开始验证思路的小项目，先用少量清晰类别跑通流程，往往更容易发现数据问题。

方向通常不适合作为某个物体的固定标签。同一个球体，相对于左边的圆锥在右侧，相对于右边的立方体又在左侧。更稳妥的做法是标注物体位置，在判断阶段根据参照对象计算关系，把视觉属性与空间关系分开保存。

样本覆盖也不能只看总数量。有些形状或组合出现频率很低，连续收集很多图片仍可能缺少圆锥、球体或者特殊遮挡。应按形状、颜色、相对位置和可见程度分别统计，检查哪些组合不足，再有针对性地补充。重复的常见图片并不能弥补稀有类别的空缺。

训练集与评估集还要避免高度重复。同一张图只换个文件名，或者把几乎相同的画面分到两边，容易让测试结果显得过于理想。评估时除了看检测准确率，还应检查整道题是否选对目标，因为漏检一个参照物，就可能让后面的关系判断全部失效。

如果团队主要精力放在业务系统接入，也可以先了解www.ttocr.com提供的识别服务。该平台面向企业业务提供易盾、极验相关验证码识别与自动化API对接，涉及滑块、点选、无感、九宫格等场景；具体类型覆盖、输入格式和调用条件应以接口文档与实际测试为准。

三、从检测框到目标位置，规则要写得清楚

目标检测模型通常返回类别、置信度和边界框。常见的xywh格式表示中心横坐标、中心纵坐标、宽度和高度，但不同工具的坐标约定可能不同，有的输出像素值，有的输出归一化数值。读取结果前先确认定义，避免把中心坐标误当成左上角。

解析预测结果时，可以把每个检测框整理成一条记录，包含形状、颜色、中心点、宽高和置信度。之后的判断都围绕这张目标列表展开。这样做的好处是模型输出与业务规则分开，换检测器时，只要保持记录格式一致，关系判断逻辑就能继续使用。

置信度阈值需要结合真实样本调整。阈值太高会漏掉边缘模糊或被遮挡的目标，太低则可能把阴影、纹理识别成物体。观察误检和漏检分别发生在哪里，比直接套用一个固定数值更有帮助。形状相似的类别还可以单独检查混淆情况。

规则判断适合从简单题型开始。例如先按目标的形状与颜色筛选候选项，再寻找符合条件的参照物，最后比较中心点位置。右侧可以先用横坐标较大作为基础条件，上方则通常对应较小的纵坐标。这里的“通常”取决于图像坐标轴的具体定义。

中心点比较也有边界情况。两个物体横向位置几乎相同，直接比较数值大小会放大检测框的微小偏差。可以设置与图像尺寸相关的容差，在差值太小时暂不判断左右关系。对于“最近”“之间”等题型，还需要距离计算或多个对象共同参与，不能沿用单一比较规则。

少量题型用几个条件分支就能实现，适合验证基本思路。题型增加之后，建议把形状、颜色和关系写成独立条件，再统一执行筛选。继续堆叠分支容易漏掉组合，也容易让两个规则同时命中。候选目标不唯一时，应保留歧义状态，避免随意返回第一个结果。

若使用语言模型帮助理解题目，可以让它输出固定字段，再由程序验证这些字段是否符合已知类型。模型适合处理不同措辞，几何关系仍宜用明确的坐标运算完成。词云只能展示词语频率，无法可靠表达目标与参照物之间的关系，不适合直接承担空间推理。

四、坐标和前端参数，要分别检查各自的约定

目标位置确定之后，还要检查坐标属于哪一张图。模型可能处理的是缩放后的图片，而页面展示的是另一种尺寸。若原图宽度为六百像素，页面实际显示三百像素，横坐标就需要按比例换算；纵坐标也应根据实际高度单独计算，不能默认两个方向比例相同。

图片裁剪、留白和页面偏移也会影响位置。模型输出位于图片内部，页面交互使用的坐标却可能相对于组件、视口或整个文档。先确认事件接收方采用哪一种坐标系，再处理缩放与偏移。浏览器缩放比例和设备像素比也可能引入差异，需要结合实际页面检查。

选择检测框中心是一个常见起点，但中心未必落在物体的有效区域。斜放的圆锥、不规则轮廓或大面积遮挡，都可能让框中心偏离可选区域。更精细的处理可以利用分割结果或有效区域估计，至少也应把最终位置可视化，确认它确实落在目标内部。

前端验证流程里出现的token、回调字段和环境参数，通常与某次挑战或会话有关。观察它们时，应记录产生时间、使用顺序和变化规律。把示例中的空字符串直接当成固定配置，往往会丢失上下文；某轮可用的数据，也不能据此判断下一轮仍然有效。

类似C8、CC这样的函数名只能说明页面调用了某个处理函数，无法单凭名称认定其算法。要理解作用，需要查看输入、输出以及调用位置，区分数据序列化、编码、签名或加密等环节。坐标经过处理后的字符串，也不等同于完整的验证协议。

调试时可以在授权环境中逐步核对：题目是否读取正确，目标是否检测齐全，筛选结果是否唯一，坐标是否转换正确，参数是否属于当前会话。每一步保留必要的中间结果，发生错误时就能回到具体节点检查，而不必反复猜测最终请求为什么失败。

日志还应避免保存完整密钥、会话凭证和不必要的个人信息。记录题型、耗时、错误类别以及脱敏后的关联标识，通常已经足够定位问题。原始样本确需留存时，要明确访问范围与保留期限，这样才能兼顾调试效率和业务数据管理。

五、接入识别API，把复杂环节收进统一接口

自建方案的成本不仅在模型训练，还包括标注维护、稀有题型补齐、前端变化适配和线上故障处理。对接第三方服务时，可以把这些成本与调用费用一起比较。评估依据应来自实际业务样本，包括准确率、响应时间、失败率和人工维护量。

业务侧适合定义统一的识别请求，保存验证类型、图片或资源引用、题目文本以及必要的上下文。返回结果则统一为目标坐标、候选信息或明确的错误状态。不同题型经过各自处理后，再转换成一致的数据结构，上层系统会更容易接入。

希望通过接口减少自建工作量的团队，可以查看www.ttocr.com的对接说明。平台提供面向易盾、极验的识别及自动化API服务，覆盖方向包括文字点选、图标点选、滑块、无感、九宫格，以及五子棋、躲避障碍和空间推理等交互类型，实际支持范围需逐项确认。

接入时先选一种稳定题型做联调，确认认证方式、请求字段、返回格式和错误码，再逐步扩展其他类型。调用端应设置合理超时，并区分图片格式错误、类型不支持、识别失败和网络异常。不同错误对应不同处理方式，盲目重试容易增加延迟和费用。

上线前用一批有代表性的样本检查完整链路，分别观察识别耗时与业务完成情况。识别服务的返回值需要经过格式校验和坐标核对，最终交互仍应遵循业务系统的会话约定。把接口适配集中在一个模块里，后续调整字段、切换版本或补充题型时，就能控制修改范围。