User Scanner 置信度评分系统指南：confirmed/likely/candidate/conflicting 四级详解-平芜编程栈

User Scanner 置信度评分系统指南：confirmed/likely/candidate/conflicting 四级详解

【免费下载链接】user-scanner🕵️‍♂️ (2-in-1) Email & Username OSINT suite featuring native MCP support for deep data extraction just from a single Email/Username. Analyzes 550+ actively maintained scan vectors (175+ email / 375+ username) for security research, investigations, and digital footprinting.项目地址: https://gitcode.com/GitHub_Trending/us/user-scanner

🕵️ User Scanner 是一款 2-in-1 的 Email & Username OSINT 工具，内置置信度评分系统（Confidence Scoring）：交叉扫描（cross-scan）命中的每个账号，都会被打上confirmed、likely、candidate、conflicting四级置信度标签，帮助你快速区分"确属目标本人"与"只是撞名的陌生人"。本文面向新手，完整讲解四级评分的判定逻辑、锚点机制与结果解读方法。

为什么需要置信度评分？

用户名扫描存在一个天然难题：同一 ID 可能被多人注册。一次扫描命中某个账号，只能证明"这个 ID 在某网站被注册了"，无法证明"这个账号就是被扫描的那个人"。

User Scanner 的解法是：从已确认的命中中提取身份信息（姓名、个人域名、邮箱、个人主页链接、已确认账号），组成一组锚点（Anchors），再拿每个新命中与锚点对比打分。评分逻辑定义在 user_scanner/core/confidence.py。

📋 四级评分标准速查

等级	含义	一句话解释
🟢`confirmed`	已确认	某个线索直接点名了这个网站和这个 ID
🔵`likely`	很可能	元数据与已确认档案相互印证
🟡`candidate`	候选	ID 已注册，但没有任何证据指向目标
🔴`conflicting`	有冲突	元数据指向另一个人

评分等级在扫描结束后统一计算，并写入结果的extra.confidence字段，具体应用流程见 user_scanner/core/cross_scan.py。

🎯 逐级详解

1️⃣ confirmed（已确认）——最强证据

confirmed表示：某个已确认账号的资料里直接点名了"这个网站 + 这个 ID"（例如 Gravatar 的已验证账号列表里明确写着github.com/johndoe）。

账号类命中：被线索点名的 (site, handle) 组合直接判定为confirmed
邮箱类命中：当两个及以上独立网站在各自正式的邮箱字段中发布了同一地址时，该地址被判为confirmed——独立来源的一致，是不发任何邮件即可获得的 strongest 信号

2️⃣ likely（很可能）——元数据互证

likely的命中通常满足以下任一条件：

姓名匹配：账号的显示姓名与锚点中的姓名一致（如 GitHub 档案写了 "Johnathan Doe"，Behance 上也出现同名）
链接指向已确认账号：若 X (Twitter) 已确认，而某个 Twitch 档案里放着同一个 X 账号的链接，该 Twitch 账号即为likely——持有同名 ID 的陌生人不会去宣传目标的推特。匹配基于解析后的 (site, handle) 对，twitter.com/JohnDoe2与x.com/johndoe2视为同一账号
回显锚点信息：简介中出现目标的个人域名、邮箱或已确认的档案 URL
邮箱地址：单个网站的邮箱字段发布了该地址，或该地址位于目标链接指向的域名上

3️⃣ candidate（候选）——默认的"待定"

绝大多数命中最终落在这一档：ID 已注册，但站点没有暴露可判断的元数据（如 Roblox、Scratch 只返回 ID 本身）。

⚠️ 关键认知：candidate不是负面结论。它只是"证据不足"，绝大多数普通命中都会停在这里，不代表账号与目标无关。

4️⃣ conflicting（有冲突）——指向他人

若账号的姓名字段读起来像另一个人的真名（至少两个词，如 "Other Person"），而与锚点姓名不符，则判定为conflicting。两条规则保证降级的诚实性：

仅复述 ID 本身的显示名（如john.d.oe→john.d.oe）不算姓名证据，会被忽略
字段中夹带描述符的（如Other Person, 44, male），只读第一个逗号前的部分，不把年龄性别误判为姓名冲突

🧭 评分如何运行：锚点机制

评分流程的核心数据结构是 Anchors：

锚点 = 已确认命中中收集到的 ├── 姓名（names） ├── 个人域名（domains） ├── 邮箱地址（emails） ├── 档案 URL（urls） └── 已确认账号（accounts）

打分函数 score() 按优先级依次判断：先查姓名 → 再查链接是否指向已确认账号 → 再查是否回显锚点信息 → 若姓名明显是他人则降为conflicting→ 否则candidate。

几个精巧的设计值得了解：

排除"平台域名"：github.com、t.co、bit.ly等短链/平台域名不构成身份信号，不计入锚点
排除循环论证：邮箱评分故意不参考锚点邮箱和域名集合——因为这些信息正是从同一批档案里采集的，参考它们等于"用自己的出现证明自己"
conflicting永远不会用于邮箱：地址本身不带姓名，从邮箱前缀猜测"冲突"会误伤所有共享邮箱

📖 如何在实际结果中读取评分

交叉扫描的每个命中都携带两个关键字段（完整说明见 docs/CROSS_SCAN.md）：

pivot_source：该目标是怎么被发现去扫描的
confidence：该账号与目标关联的紧密程度

例如通过邮箱路径到达的 Spotify 账号：

{ "status": "Found", "site_name": "Spotify", "username": "john@acme.dev", "extra": { "pivot_source": "address from Github (email), Gravatar (emails)", "confidence": "confirmed" } }

通过邮箱路径到达的账号会继承该邮箱的评分——账号与目标的关联度，不会高于引导到它的那个邮箱。

运行结束时，总结部分会按等级统计命中数，并点名列出confirmed、likely、conflicting的具体站点，方便快速 triage。

⚠️ 置信度评分"不做"的事

candidate不是否定：多数站点暴露的元数据太少，评分无从判断
不使用地理位置："巴西"匹配数百万人且人会迁移，无法作为升级依据
不会丢弃任何命中：无论评分如何，所有命中都会进入导出结果
是分拣辅助，不是终审判决：它只读取模块碰巧提取到的元数据，读不到证据的站点无法评分

🔍 相关源码与文档

模块	说明
user_scanner/core/confidence.py	评分引擎：`Confidence`枚举、锚点构建、`score()`打分逻辑
user_scanner/core/cross_scan.py	交叉扫描中`_apply_confidence()`如何为每个命中应用评分
user_scanner/core/pivots.py	线索（pivot）提取与 URL 解析
docs/CROSS_SCAN.md	交叉扫描与置信度的官方文档
tests/test_confidence.py	评分逻辑的完整测试用例，可对照学习各种边界场景