需要对用户名做跨平台 OSINT 并确认真实归属时：用…

适用于用户名 OSINT、跨平台账号关联、昵称/屏幕名 pivoting，以及欺诈/合成身份、招聘/市场诈骗、信任安全、内部威胁、个人曝光审计中的账号归属确认。

适用场景

解决思路

1. 先读 ../../ETHICS.md，写清 subject、objective、in-bounds selectors、out-of-bounds actions（登录、联系、请求关注）、governing jurisdiction；确认什么行为会越界。注意 handle hunting 容易漂移，一次运行会带来三十个新平台，很容易把共享同一字符串的无关人员也纳入画像。完成标准：scope 已写下，且能说出什么会让自己越界。
2. 选择枚举器：需要一个 handle 快速大范围扫描时用 sherlock，它只做存在性检查；需要 profile 内容时用 maigret，它解析页面：display name、bio、IDs、links，有时还有 country 和 creation date；需要知道命中为什么触发时读 WhatsMyName 数据，因为每条检查都是一个声明的 URI 加可读 match rule；已知某个 handle 在单个已知平台上时，直接人工访问实际 profile。
3. 运行命令：sherlock jdoe_92 --timeout 10 --csv；maigret jdoe_92 --html。关联时优先用 maigret，因为它返回字段而不是布尔值；display name、avatar URL、self-declared location、numeric user ID、also known as 列表都可用来测试下一个平台。Sherlock 只给一个 URL 和一个声明。
4. 把 WhatsMyName 当作检测列表而非扫描器：它是 JSON 文件，每个 site entry 有 URI template 和明确 match 标准，包括 expected HTTP status、expected string in body，以及 missing 的对应标准。怀疑任何站点时读它的 entry，看工具到底把什么当作证据。许多 wrapper 和 web front-end 消费同一列表，所以三个不同工具都命中，常常是同一条规则触发三次，而不是三次独立确认。
5. 记录每个候选：platform、URL、发现它的 tool、live/dead status。
6. 生成变体：分隔符替换 john.doe、john_doe、john-doe、johndoe；截断和缩写 jdoe、johnd、j_doe、doej；数字后缀：出生年、出生年两位、1、99、007；leetspeak 和字符替换 j0hnd0e、johnd0e；把 email local part 当 handle，把 handle 当 email local part；gamer-tag 形态：前缀、xX…Xx、clan tags、重复字母。完整模式列表见 reference/variant-patterns.md。
7. 做两个方向的推断：handle → name，例如 jdoe_92 暗示 first-initial-lastname 和 1992 出生年，这只是待检验假设而非发现；name → handle，如果已有真实姓名，生成该姓名可能产生的 handle 并枚举，这常比从别人给的 handle 开始效果更好。把产生命中的变体折叠回 Step 2。完成标准：变体集已枚举，且产生命中的变体已合并回 Step 2。
8. 对每个候选确认或拒绝，寻找能经受怀疑读者检验的证据。强证据：相同 avatar，用 find-the-original-image 验证——如果匹配到 stock photo 或第三方图片，就是拒绝而不是确认；byte-identical 或 near-identical bio text，尤其带 typo 或不寻常措辞；self-declared cross-link，即一个 profile 链接到另一个 profile，这是没有自认时可得的最好证据；两边都有 contact selector，如相同 email、相同 personal domain。
9. 中等证据：账号创建日期在跨平台窄窗口内聚集，因为人会成批注册；与相同且独特的小账号有 follower/following overlap；写作风格，包括 idiom、punctuation habits、timezone of posting。单独 handle 匹配是弱证据；它是你要检验的对象，不是支持它的证据。
10. 优先利用暴露 numeric user ID 的平台：如果 ID 按注册顺序发放，ID 可界定账号创建日期，即使 profile 隐藏了它。GitHub 的 https://api.github.com/users/<login> 返回 numeric id 和 created_at；Discord 的 snowflake ID 直接编码 creation timestamp。按平台细节见 reference/platform-leakage.md。
11. 防误报：识别 soft 404s，即站点返回 200 但页面是 user not found，如果 match rule 只看 status code，则一切都会存在；catch-all profile pages，即平台对任何字符串都渲染通用外壳，只在 API 上 404；rate-limit 和 CAPTCHA interstitials，challenge page 是 200 且有 body，可能同时满足 found 和 missing 规则，而且一旦被限流，本轮其余结果都是垃圾，应单独重跑失败项而不是相信单次扫描；reserved、squatted、impersonation accounts，即已注册、真实，但不是你的对象；stale entries，即站点改变 404 行为而检测列表滞后，没有命中不等于没有账号。
12. 评估 collision：普通 handle 属于很多无关的人，短或字典词 handle 在十个平台出现，更像十个人而不是一个人。置信度应随 handle 独特性缩放：罕见自造字符串本身是弱到中等证据，mike 则没有证据力。
13. 不要通过登录、发消息或请求关注来解决歧义。那是交互行为，默认越界，而且会告诉对象你存在；见 investigate-without-getting-made。
14. 按置信度分级：Confirmed——通过 find-the-original-image 验证的 avatar 匹配加另一个强项，或两个 profile 之间的 self-declared cross-link，或 shared contact selector；Probable——distinctive handle 加一个中等项，如 creation-date cluster、follower overlap、consistent style，且无矛盾证据；Unconfirmed——只有 handle 匹配，其他都不匹配，报告为 enumeration hit，而不是对象账号；Rejected——content、language、timeline 或 avatar provenance 与对象矛盾，记录拒绝原因，避免下一位分析师重复工作。
15. 对可疑命中做 catch-all 测试：例如用故意荒谬的 handle 请求同一平台，如果也返回 200 和相同空页面，就排除该平台命中。对 avatar 做反向搜索，若只在 code-hosting profile 出现且与 photography 账号的加入月份同月，可结合两项中等证据确认。对同 handle 但不同语言、无关主题、早六年的 microblog 命中，判为不同人并明确记录拒绝。
16. 根据新 selector 转向：display name 或 real name → find-anyone；exposed 或 inferred email → what-an-email-reveals；profile 上的 phone number → whose-number-is-this；avatar 或 posted photos → find-the-original-image、secrets-in-file-metadata；带位置上下文的照片 → where-was-this-taken；code-hosting handle → secrets-in-git-history；bio 中的 personal domain → who-owns-this-domain；credential dumps 中的 handle → what-leaked-about-you；已确认账号的完整 posting history → pattern-of-life-from-socials；账号地图本身 → graph-the-network。
17. 遵守法律和 ToS：自动枚举会用脚本请求平台，多数 ToS 禁止，即使数据公开。保持低并发，不要破解 CAPTCHA，平台表示拒绝时停止。在 EU 和 UK，把分散的公开账号组装成活人档案属于处理个人数据，需要 lawful basis 和 data minimisation。
18. 报告：运行 write-the-intel-brief。给出 platform/URL/confidence/evidence 表格，列出拒绝项及原因，并先给 handle 产出的 real-name 和 contact selectors。完成标准：表格中每个候选都有 grade 和 source，且没有任何 enumeration hit 不带 grade 和 source。
19. 完成 Step 4 时：每个候选都被评为 confirmed、probable 或 rejected，且旁边写明证据。

适用边界 · 注意事项

• 没有合法依据、授权范围未写清，或需要登录、联系、请求关注等交互行为时，不要开始或继续。
• 只是验证一个已知平台上的单个 handle 时，直接人工查看实际 profile，不必跑大规模枚举。
• handle 是短词、字典词或非常普通且没有其他 selector 佐证时，跨平台命中很可能属于不同人，不应据此归因。