phantomstars

自动化检测与追踪GitHub上的虚假互动

一个 JS Labs 项目 — 属于 AI Slop Intelligence 倡议的一部分。
每天运行。给每个可疑账户打分。检测协调性的机器人活动。
直接在受影响的仓库上提交问题，以便维护者采取行动。

支持此项目

BTC   3QjWqhQbHdHgWeYHTpmorP8Pe1wgDjJy54
ETH   0x5851e6145F4773d1585b8686095FB16E368a4dA1
ZEC   t1KSR5YkNPbjqRSCoLKo5AddFWdm9Kzxh1B

为什么存在

GitHub 星标是一种信任信号。开发者据此决定评估什么、依赖什么、推荐什么。那个信号正在被系统性地破坏。

在 2024-2026 年的人工智能繁荣期间，出现了一个机器人农场产业，为低质量、通常恶意的仓库制造可信度。一个在 48 小时内获得 800 个星标的项目，对于浏览搜索结果的开发者来说，看起来是合法的。这就是关键所在。虚假互动的目标不是星标本体，而是这些星标所产生的社会认同，以及这种社会认同所影响的下游决策。

这种模式是可识别的。同一周创建的账户，没有个人简介，没有关注者，没有原创仓库，在两小时内为相同的 15 个仓库加星标。不是一个活动，而是每天同时运行数十个，涉及数千个账户。数据显示在某些仓库中，185 个互动者中有 185 个是机器人。百分之百的虚假率。整个热门排名建立在虚无之上。

phantomstars 的构建是因为这个问题是可处理的。GitHub 公共 API 中的信噪比目前仍然足够高，以至于协调性活动留下了清晰的指纹。该项目读取这些指纹，发布原始数据，并直接通知受影响的仓库维护者。

这是 JS Labs 更广泛的 AI Slop Intelligence 工作的一部分，正在进行的研究，旨在探究低质量 AI 生成内容淹没开发者生态系统的机制和可测量影响。虚假互动不是一个外围问题。它是让劣质内容出现在真正用户面前的传播机制。

功能

phantomstars 每天运行一个 GitHub Actions 作业，该作业：

1. 抓取 GitHub Trending 页面，获取今天获得星标的仓库
2. 查询 GitHub Search API，查找过去 7 天内创建且有突然星标活动的仓库（更宽的时间窗口能捕捉到 24 小时扫描所遗漏的多日活动）
3. 从 Reddit r/osinttools 和 r/coolgithubprojects 板块最近 2 天的帖子中提取 GitHub 仓库链接，作为额外候选仓库
4. 通过 Events API 拉取每个仓库过去 24 小时内的近期互动事件（星标、fork）
5. 通过 GraphQL 获取每个互动账户的完整资料：账户创建日期、关注者/关注数、个人简介、仓库历史
6. 根据组合启发式模型给每个账户打分：账户年龄、资料完整度、仓库模式、活动历史
7. 使用时间戳聚类和并查集检测 协调性活动：在 3 小时窗口内互动的可疑账户集群
8. 在账本写入、仓库级比率、仪表盘和通知之前应用误报白名单，确保所有可见指标使用相同的人群
9. 将所有可疑账户追加到只追加的 JSONL 账本中并提交回此仓库
10. 发布每个仓库的情报提要，显示哪些仓库被攻击、通过哪些发现来源找到它们、以及 Events API 窗口是完整还是已达上限
11. 直接在目标仓库上提交 GitHub 问题，让维护者在其自己的问题追踪器中看到活动数据
12. 将格式化的扫描报告写入 GitHub Actions 作业摘要

无服务器。无数据库。无基础设施账单。

常见问题

它会通知目标仓库吗？

会。 当仓库的虚假率超过 40% 或检测到协调性活动时，phantomstars 会在该仓库上直接打开一个 issue。该 issue 包含完整的可疑账户表、活动成员身份、综合分数以及账户创建日期：维护者进行调查并向 GitHub 报告所需的一切信息。

如果目标仓库禁用了 issue，则通知会静默跳过，并记录在扫描日志中。

我可以请求检查一个特定的仓库吗？

可以。

• 对于普通的单次检查，以 owner/repo 格式提交仓库，并运行定向扫描。
• 对于全生命周期审计请求，使用单次全生命周期模式。它与每日扫描是分开的。

为什么要分开：

• 普通扫描模型专为近期的公开互动和低操作成本而设计。
• 全生命周期审计可能涉及较大仓库的数万个星标和数千个 fork。
• 这对于单次调查是可行的，但对于默认的每日路径来说太昂贵且太慢。
• 因此，全生命周期请求仅在带有保障措施的显式单次模式下运行。

我可以报告误报吗？

可以。如果你的账户出现在 data/suspects.jsonl 中，并且你认为分类有误，请使用提供的模板提交一个误报 issue。报告会在添加到白名单之前进行人工审查。白名单存储在 data/allowlist.txt 中；列在其中的账户将从所有未来的扫描和可疑账户账本中排除。

什么是活动 ID？

活动 ID（例如 c-a3f9b2e1）是一个 确定性 8 字符十六进制指纹，派生自该活动中成员登录名的排序集合的 SHA-256 哈希。同一组账户在不同的扫描运行中会产生相同的活动 ID，从而实现纵向追踪。它不是仓库名称、用户名或任何外部标识符。

稳定性： 只要活动的成员集合不变，该 ID 就是稳定的。如果在两次扫描之间添加或暂停了机器人，ID 就会改变，因为成员身份发生了变化。这是预期行为，反映了机器人农场组成的真实漂移。

它会检查账户创建日期吗？

会。 每个账户的创建日期都通过 GitHub GraphQL API（createdAt 字段）获取，并作为 account_created_at 存储在每条可疑记录中。它也是账户年龄评分的主要输入，是虚假账户最强的单一信号。在互动前 2 天内创建的账户仅凭年龄就获得 1.0 分。

它的置信度如何？

单个分数具有显著的误报率。一个资料稀疏的新开发者可能合理获得 0.75+ 分。该工具通过在提交 issue 之前要求活动级证据来解决这个问题；单个可疑账户是不够的。一个协调的集群，包含 40 多个账户，全部在同一周创建，全部得分 0.75+，全部在 90 分钟内互动，则是另一回事。这才是置信度变得可行的时候。

数据始终是概率性的。issue 正文明确说明了这一点。目标是给维护者提供信号和原始证据，让他们自己做出判断。

实时仪表盘

今日最受攻击的仓库

评分模型

每个账户会收到一个综合可疑分数（0.0 = 干净，1.0 = 可能虚假），来自四个信号：

分类阈值：

活动检测

一个活动是指一组 ≥ 4 个可疑账户，在同一仓库的 3 小时窗口内都进行了互动。该算法使用并查集构建连通分量；在窗口内共同互动的账户会被合并，任何超过最小大小的分量都会被标记为协调性活动。

活动 ID 是排序成员集合的稳定 SHA-256 指纹。在连续几天检测到的同一个活动，只要成员身份不变，就会有相同的 ID。

为什么活动才是真正的信号： 单个分数具有显著的误报率。一个新开发人员资料稀疏，单独可能获得 0.80 分。四十个账户全部得分 0.75+，同一周内创建，全部在 90 分钟内为同一个仓库加星标，这不是巧合。活动信号才是数据变得可行的地方：它区分了可疑数据点和协调性操作的证据。

数据格式

所有发现都提交到 data/suspects.jsonl 和 data/repos.jsonl，每行一个 JSON 记录，只追加。GitHub Actions 作业摘要（每次运行后在 Actions UI 中可见）提供格式化的每次扫描报告。

suspects.jsonl — 每次扫描每个被标记的账户一条记录：```json { "login": "user98432", "account_age_score": 0.9, "profile_score": 0.8, "repo_pattern_score": 0.8, "activity_score": 0.85, "composite": 0.842, "classification": "likely_fake", "campaign_id": "c-a3f9b2e1", "scan_date": "2026-05-17", "account_created_at": "2026-05-15", "target_repos": ["owner/repo-a", "owner/repo-b"] }

**repos.jsonl** — 每个扫描每个目标仓库一条记录：```json
{
  "full_name": "owner/suspicious-repo",
  "total_scanned": 87,
  "likely_fake": 62,
  "suspicious": 18,
  "known_likely_fake": 27,
  "known_likely_fake_ratio": 0.310,
  "repeat_offenders": 11,
  "allowlisted_excluded": 3,
  "fakeness_ratio": 0.713,
  "classification": "likely_fake",
  "campaign_count": 3,
  "discovery_sources": ["github_search_recent", "reddit_osinttools"],
  "event_sample_complete": false,
  "scan_date": "2026-05-17"
}

查询示例：```bash

All likely_fake accounts from today

jq 'select(.scan_date == "2026-05-17" and .classification == "likely_fake") | .login' data/suspects.jsonl

Accounts created in the last 3 days that were flagged

jq 'select(.account_created_at >= "2026-05-14") | [.login, .account_created_at, .classification] | @tsv' -r data/suspects.jsonl

Which repos were targeted today, sorted by fakeness ratio

jq 'select(.scan_date == "2026-05-17") | [.full_name, .fakeness_ratio, .likely_fake] | @tsv' -r data/repos.jsonl | sort -t$'''\t''' -k2 -rn

Repos with the highest recycled-bot share from previously seen likely_fake accounts

jq 'select(.scan_date == "2026-05-17") | [.full_name, .known_likely_fake_ratio, .repeat_offenders] | @tsv' -r data/repos.jsonl | sort -t$'''\t''' -k2 -rn

All members of a specific campaign

jq 'select(.campaign_id == "c-a3f9b2e1") | [.login, .account_created_at, .composite] | @tsv' -r data/suspects.jsonl

Repos a specific account targeted

jq 'select(.login == "user98432") | .target_repos[]' data/suspects.jsonl

High-confidence repos: fakeness ratio above 60%

jq 'select(.fakeness_ratio >= 0.6) | [.full_name, .fakeness_ratio, .campaign_count] | @tsv' -r data/repos.jsonl | sort -t$'\t' -k2 -rn

## 设置

### 1. Fork 本仓库

你的 Fork 拥有数据所有权。每次每日运行后，结果会提交到你的 Fork 上的 `data/suspects.jsonl` 和 `data/repos.jsonl`。

### 2. 添加 GitHub PAT 密钥

创建一个**经典**个人访问令牌，需包含以下作用域：
- `public_repo`：读取公共仓库事件和星标者，在公共仓库上创建 Issue
- `read:user`：通过 GraphQL 获取用户资料

**设置 → 密钥和变量 → 操作 → 新建仓库密钥** → 命名为 `GH_TOKEN`。

> 默认的 `GITHUB_TOKEN` 具有受限的速率限制，无法以全容量调用用户 GraphQL 端点。需要使用 PAT。

### 3. 启用 Actions

**操作 → 启用 GitHub Actions** 在你的 Fork 上。工作流使用 `Europe/London` 时钟，**英国时间每日 07:00** 运行：
- **英国夏令时期间为 06:00 UTC**
- **格林尼治标准时间期间为 07:00 UTC**

无需额外调度环境变量。GitHub Actions 的 Cron 仅支持 UTC，因此工作流在两个 UTC 小时都会触发，但仅在本地伦敦时间为 07:00 时才会继续执行。可通过 **操作 → Daily Phantom Stars Scan → 运行工作流** 进行手动触发。

每次运行后，格式化的扫描报告会在 **操作 → [运行] → 摘要** 中显示。

### 4. 本地运行```bash
git clone https://github.com/YOUR_USERNAME/phantomstars.git
cd phantomstars
python -m venv venv && source venv/bin/activate
pip install -e .
GH_TOKEN=ghp_your_token python -m phantomstars.main

对于安装后的临时本地运行：```bash GH_TOKEN=ghp_your_token python -m phantomstars.main

扫描一个仓库而非正常的发现集：```bash
PHANTOMSTARS_TARGET_REPO=owner/repo GH_TOKEN=ghp_your_token python -m phantomstars.main

一次性请求

用户可以通过两种方式请求一次性仓库检查：

1. 打开 Repo Check Request 问题模板，提供目标仓库及请求的深度。
2. 使用 Actions -> Daily Phantom Stars Scan -> Run workflow，并可选择设置：
   • target_repo: owner/repo
   • request_depth: recent 或 lifetime-request

当前行为：

• recent：立即运行针对性的近期互动扫描。
• lifetime-request：仅针对该仓库运行跨越历史星标和复刻的生存期扫描。
• 每日定时扫描保持不变，继续使用近期互动方法。

生存期模式的防护措施：

• 仅适用于明确的一次性定向请求
• 扫描开始前受配置的仓库大小限制上限约束
• 比每日扫描更慢且更消耗 API

项目结构```

phantomstars/ ├── .github/ │ ├── workflows/daily-scan.yml # Runs daily at 07:00 Europe/London │ └── ISSUE_TEMPLATE/false_positive.yml ├── src/phantomstars/ │ ├── config.py # All constants, no argparse, no env parsing │ ├── models.py # Frozen dataclasses │ ├── github_client.py # REST + GraphQL, tenacity retries, rate-limit aware │ ├── heuristics.py # Per-user composite scoring engine │ ├── campaigns.py # Timestamp clustering + union-find │ ├── storage.py # JSONL append + query helpers │ ├── reporter.py # README dashboard injector │ ├── notifier.py # GitHub Issues notifier (files on targeted repos) │ └── main.py # Orchestration entry point ├── tests/ │ ├── conftest.py │ ├── test_heuristics.py │ └── test_campaigns.py ├── data/ │ ├── suspects.jsonl # Append-only account findings ledger │ ├── repos.jsonl # Append-only per-repo intelligence │ └── allowlist.txt # Accounts excluded from future scans └── pyproject.toml

---

## 限制与已知故障模式

- **Events API上限：** 每个仓库最多300个近期事件。每天获得数千星标的仓库将只有部分覆盖。
- **覆盖标志：** 达到300事件上限的仓库在报告和仪表板中被标记为`capped`；这些仓库的比率是保守样本，而非全天计数。
- **搜索索引延迟：** GitHub的搜索索引是最终一致性的。在扫描边界前几秒创建的仓库可能会被遗漏。
- **启发式漂移：** 机器人运营商会适应。评分权重可能需要定期调整；在`config.py`中调整常量。
- **个体误报：** 一个新开发者如果资料稀疏，孤立评分可能达到0.75以上。活动成员身份是高置信度信号。
- **活动ID漂移：** 如果在两次扫描之间僵尸农场的成员发生变化（机器人被暂停、新机器人加入），活动ID会改变。这反映了实际的活动演变，而非缺陷。
- **速率限制：** 经过身份验证的PAT每小时5000次API请求。对于标准趋势页面大小来说完全在限制之内。
- **问题被禁用：** 一些目标仓库禁用了问题。这些仓库的通知会被静默跳过。

---

## 误报处理流程

如果你的账号出现在`data/suspects.jsonl`中并且你认为被错误分类：

1. 找到你的条目： `jq 'select(.login == "YOUR_LOGIN")' data/suspects.jsonl`
2. [提交误报问题](https://raw.githubusercontent.com/tg12/issues/new?template=false_positive.yml)，附上你的登录名、分类、扫描日期和解释
3. 报告会被人工审核。验证为误报的条目会被添加到`data/allowlist.txt`中，并从所有未来的扫描、仓库比率和问题通知中排除。

注意：提交问题不会修改或删除任何现有数据。嫌疑人账本只追加不删除。允许列表仅影响未来的扫描。

---

## 贡献```bash
pip install -e ".[dev]"
python -m black .
python -m ruff check .
python -m mypy src
python -m pytest

所有四项检查必须全部通过才能提交PR。

免责声明

本工具使用官方 GitHub API 对公共 GitHub 数据进行只读分析。如果在目标仓库中提交了问题，它们包含基于概率的发现，并明确标记为自动生成。发现结果是指标，而非指控。误报存在且属于预期情况。

本工具由 AI 作为编码伙伴构建，以应对部分由 AI 引起的生态系统问题。

许可证

Apache 2.0。详见 LICENSE

作者

由 tg12 构建 · GitHub

一个 JS Labs 项目 · AI 垃圾情报仪表板