价值认知不足
新玩家很难快速判断一个陌生物品是否值得带走。
Flagship case study持续迭代
Visual recognition · Decision support
LootPilot
- 我的角色
- 产品定义 / UI UX / 构建
- 验证方式
- 公开发布 / 用户反馈
- 当前状态
- 持续迭代
- 主要适配
- 1080p
CASE 01 / Pilot Studio
Visual Recognition & Decision Support
将复杂信息转化为及时、可理解的决策依据。
产品案例封面 / 实际界面与使用证据将在案例正文中呈现
- ROLE
- 产品定义 / UI UX / AI 辅助开发
- STATUS
- 持续迭代
- 01
视觉输入
- 02
信息识别
- 03
结果匹配
- 04
决策呈现
01 · Problem
现有查询方式无法融入高频、紧张的信息判断过程。
在塔科夫局内，问题并不是完全查不到价格，而是查询步骤会打断当前任务，新用户也缺少可靠且及时的价值认知。
逐个查价低效
离开当前场景、输入名称、比对结果，会不断打断决策。
背包判断困难
当物品数量变多，逐格权衡价值与空间的成本迅速上升。
价格记忆会过时
市场价格持续变化，依赖记忆无法保持准确。
02 · Insight
用户需要的不是更多价格数据，而是更短的判断路径。
把查询动作变成对当前画面的理解：尽量不输入、不切换、不逐项搜索，让结果回到物品所在的位置附近。
目标不是替用户做决定，而是把做决定所需的信息及时放回现场。
03 · Solution
从画面截图到可读的价格结果。
LootPilot 使用一条非侵入式视觉识别链路，把游戏画面转换为物品与价格信息。
- 01
截图
- 02
OCR
- 03
物品匹配
- 04
价格 API
- 05
结果显示
识别流程与结果界面
/images/lootpilot/recognition-flow.webp
04 · Use cases
快速确认一件物品，或一次理解整个背包。
单物品快速扫描
/images/lootpilot/single-item-scan.webp
单物品快速扫描
在准星或指定区域快速识别单件物品，适合即时确认。
全背包扫描
/images/lootpilot/full-inventory-scan.webp
全背包扫描
批量读取背包区域，帮助用户在空间与价值之间做整体判断。
05 · Product decision
为什么选择 OCR，而不是读取游戏内部数据？
OCR 只理解用户主动提供的屏幕画面，不需要接入或修改游戏进程。它让方案保持更清晰的边界，也更接近普通视觉工具的工作方式。
非侵入式边界
不读取游戏内存或内部数据。
可解释链路
截图、识别、匹配与显示各自可验证。
真实代价
需要持续处理分辨率、偏移与识别误差。
06 · Validation
准确率不是一个完成状态，而是一轮轮被修正的结果。
OCR 识别经过多个版本迭代，围绕文字区域、候选匹配和界面偏移持续调整。当前不公布未经验证的准确率百分比。
1080p
当前完整回归基准
约 10 秒
全背包扫描
仍在优化
少量漏识别与偏移
分辨率适配测试版
开发记录显示，统一坐标映射已经通过 2K、4K、2560×1600 原生及拉伸画面的合成回归，归一化误差约为 0–4 像素；但真实高分辨率游戏原图仍不足，因此 1080p 继续作为已完整验证的主要基准，其他模式保持测试状态。
07 · Iteration log
每一轮优化，都先保护已经成立的识别结果。
开发不是简单增加功能。识别正确性、扫描速度、内存占用和分辨率适配之间需要持续做取舍。
从单物品到全背包
在快速查一件物品之外，加入动态格线与占用判断，支持对弹挂、口袋、背包和保险箱进行整体扫描。
先减少重复工作
把逐像素 GetPixel、重复截图缓冲和区域重复扫描改为一次缓冲复用；样本占用判断数量保持一致。
承认真正的瓶颈
基础图像处理优化后，主要耗时仍来自 OCR 推理。继续提速不能以降低识别率为代价。
坐标映射加局部校准
用 1080p 逻辑坐标预测区域，再在附近吸附真实格线，以兼容比例、UI 缩放和少量界面偏移。
08 · Feedback
真实反馈不仅指向功能，也暴露交付体验的问题。
用户主要来自 B站、抖音和游戏社区。反馈集中在更多分辨率与画面比例，以及安装使用过程中的障碍。
反馈来源
公开内容平台与用户沟通主要问题
状态、分辨率、窗口与模式切换隐私处理
头像、用户名与时间已匿名化09 · Next
下一阶段，把识别能力和使用体验一起做得更可靠。
01
自定义标价位置
02
真实高分辨率验证
03
OCR 与扫描速度
04
安装流程优化
05
错误提示优化