别再重复逆向：16,814 个"逆向出来"的工具，被一个人做成了 AI Agent 的检索表

一、一个让人后背发凉的场景

想象一下这个场景。你是嵌入式开发工程师，老板扔给你一个需求："把涂鸦（Tuya）智能插座在局域网内控制掉，不要走云端。"

你打开搜索引擎，输入"Tuya local protocol"，跳出来二十个 GitHub 仓库。你花两天读 Python SDK、踩了三个坑，最后发现三个月前隔壁组的老王已经把完整实现开源了，项目叫 tuya-local，Star 2600，License 是 MIT，甚至自带 Docker Compose。

类似的事情每天都在发生。你要读 .psd、要控制打印机、要拿某汽车品牌的车机数据、要接一款已经停产的智能家居设备的私有协议——这些产品都没有官方 API，或者官方 API 只覆盖了云端一半功能。全世界有成几万个开源项目是这么"逆向"出来的，但它们散落在 GitHub 搜索结果的第二页、第三页、以及某个俄罗斯开发者的私有 Gist 里。

alexgaoth/awesome-reverse-engineered 就是为解决这个问题而生的。

图为项目官方的可筛选检索站点，支持按分类、语言、健康度（活跃/放缓/休眠/归档）排序并生成分享链接。

二、背景：它到底在索引什么

这个仓库 2026 年 10 月 11 日创建，到今天（10 月 24 日）只有不到两周，已经收获 637 Star、123 Fork、3 个 open issue——在 GitHub 上这属于火箭速度。

它的自我定位是一句话："Don't reverse engineer it twice."（别把同一个东西逆向两遍。）

索引规模非常夸张：16,814 个开源项目，合计 1120 万 Star。分类覆盖 20 个大类：

分类	项目数	代表项目
游戏逆向与重实现	6,073	shadPS4、v86、RPCS3
设备/IoT/硬件	3,059	KOReader、LibrePods
RE 工具链	1,031	rea、Ghidra、jadx
非官方 Web/App API 客户端	908	yt-dlp、MediaCrawler
AI 工具与 LLM 客户端	740	claw-code、system_prompts_leaks
网络与线路协议	426	Sunshine、Impacket
文件格式	439	FFmpeg、ImHex、SheetJS
在线服务复活	639	NoLongerEvil Thermostat

它还特别维护了一份 "Resurrected（复活）" 名单，目前有 131 个被厂商亲手杀死的 products 被开源社区救活：AOL 的 ICQ（2024 年被 VK 关停）靠 Retro AIM Server 复活，Spotify Car Thing 被 Spotify 2024 年砍掉后有社区做了 DeskThing，亚马逊 2019 年停产的 Dash Button 至今还能被 node-dash-button 点亮，Google 2025 年关停的初代 Nest 温控器被 NoLongerEvil Thermostat 接管。每一项都注明了"谁杀的、哪一年、谁复活的"。

三、类比：它相当于逆向工程界的"搜索引擎 + 菜谱库"

打个比方。逆向工程以前像什么呢？像没有地图的荒野探险——每个逆向工程师都背着同样的设备、带着同样的笔记、重复发现同样的路口，走出同样的弯路。

这个项目做的是修路和立路牌。它不教你怎么逆向（那是 Ghidra、IDA 的活），它做的是把全世界已经逆向出来的东西汇总成一张带路况信息（Star 数、语言、License、最后 push 时间、是否归档）的地图，让你出发前先查图：

• 横向覆盖广：从 Tuya 插座协议到 PS4 模拟器，从 Nintendo DS 在线服务器到 Bambu 3D 打印机协议，跨度极大。
• 纵向有健康度标注：每个条目都记录"最后 push 时间"和"archived"标志。非官方 API 最怕的就是厂商改接口后客户端集体失效——这个索引直接把"1-2 年内有提交"作为筛选条件写进了 Agent Skill 的决策规则里。
• License 必填：Skill 里明确写着"空白 License 意味着保留所有权利，必须提醒用户"，避免 Agent 盲选一个法务上不能用的库。

四、核心功能：三套接入方式

4.1 Web 检索站点（GitHub Pages）

docs/index.html + docs/data.json（4.5 MB）构建的纯前端站点，部署在 GitHub Pages，无需服务器。23 个国家语言版本（英/简中/法/西/越/巴葡），可按分类、语言、健康度过滤，按 Star 或最近活跃度排序，每个搜索结果都有可分享的 URL。

4.2 Agent Skill（主力形态）

这是这个项目最核心的设计。仓库里带了一个标准 Claude Code Skill：plugin/skills/find-reverse-engineered/SKILL.md，一条命令安装：

npx skills add alexgaoth/awesome-reverse-engineered

Skill 内置了一套决策工作流：先用 1-4 个关键词搜索（支持 --category / --lang / --min-stars / --include-archived 过滤）→ 按"是否做对这件事、是否归档、两年内是否提交、语言包管理器是否匹配、License 是否兼容"五条规则依次筛选 → info 命令读取 README 摘要确认安装与鉴权步骤 → clone 或按 README 指示用 pip/npm/cargo/go 安装 → 最后必须告诉用户选了哪个项目、为什么、用了哪个版本、License 是什么。

更值得注意的是 Skill 里的一条"Rules"约束：先用官方 API/SDK，只有在官方方案不存在或不够用时才动用逆向工具，且只用于用户自己的账号、设备和数据。这让 Agent 不会动不动就跑去逆向。

4.3 MCP Server

mcp/ 子目录是一个纯标准库实现的 stdio MCP Server，暴露三个工具：

工具	作用
search_reverse_engineered	按产品/厂商/协议/任务排序搜索，可按分类、语言、最小 Star、归档状态过滤
get_reverse_engineered_project	返回单条索引（Star、License、最后 push、归档状态）加 README 开头
list_reverse_engineered_categories	列出全部分类与子分类及计数

安装同样是 uvx 一行：

claude mcp add reverse-engineered -- uvx --from "git+https://github.com/alexgaoth/awesome-reverse-engineered#subdirectory=mcp" reverse-engineered-mcp

数据层是 data/entries.json（7.5 MB，CC0 授权），首次运行下载并缓存 24 小时到 ~/.cache/awesome-reverse-engineered/，也支持用 RE_INDEX_DATA 指定本地副本。读 README 时走 GitHub API，设 GITHUB_TOKEN 可提高限额。

4.4 自动化运维

数据不是手工维护的。.github/workflows/refresh.yml 每天夜间自动刷新索引，提交历史清晰可见："Nightly refresh 2026-10-23"、"Update index: round 15"、"Add an MCP server for the index"。data/stats.json 记录了脚本的运行规模：3,099 次搜索、348 个数据源、173 个被剔除的越界条目。SOURCES.md 有 158 KB，记录了每一条目的来源出处。

五、上手门槛：三种方式，三种代价

• 只想看看：直接开 https://alexgaoth.github.io/awesome-reverse-engineered/，零门槛。
• 给 Agent 用：npx skills add，一分钟内完成，之后 Skill 就在你的 Claude Code / Cursor 里生效。
• 要 MCP：uvx --from git+... 一行，或者从 mcp/ 目录拉下 reverse_engineered_mcp.py + re_index.py 放同一目录 python3 reverse_engineered_mcp.py 运行——零第三方依赖，只用 Python 标准库。

容器化方面：mcp/Dockerfile 是单阶段 python:3.12-slim，复制两个 py 文件直接启动，没有多阶段构建、没有 docker-compose、没有 K8s manifest。整体硬件需求极低：无需 GPU，256MB 内存起步，50MB 磁盘足够索引本身（完整 entries.json 约 7.5 MB）。

六、争议与局限

必须说清楚几件事：

1. "逆向"存在法律与伦理边界。 仓库本身提供的是索引，不是工具本体，实际使用哪个项目、怎么用，责任在用户。但索引天然会吸引盗版固件破解、解锁限制功能等用途，使用者需要自行判断合法性边界。
2. 仓库极度年轻。 创建不足两周，作者一人维护（Alex Gao），数据管道、分类标准、增量更新逻辑都在快速演进，长期稳定性尚未验证。
3. 数据质量依赖上游。 Star 数、License、归档状态都靠 GitHub API 抓取，"最后 push 时间"这类健康度指标对于 fork 密集或 monorepo 项目并不完全准确。索引本身的准确性也依赖 SOURCES.md 的维护纪律。
4. 7.5 MB JSON 全量下载对每次 MCP 冷启动不算轻量，缓存 24 小时的策略在高频调用场景下才划算。
5. 内容多 ≠ 都能用。 16,814 个项目里包含大量个人实验、Toy 项目和早已 fork 停滞的代码，Skill 里的五步筛选规则（尤其是"两年内有提交"）是必须遵守的，否则会踩坑。

七、行业意义：从"个人英雄项目"到"基础设施"

这个项目折射出的趋势比它本身更有意思：逆向工程正在从个人手艺变成 Agent 可调用的基础设施。

过去的路径是"高手写脚本 → 发博客 → 别人抄"，信息衰减极其严重。这个项目把它变成了"结构化索引 → 机器可读 → Agent 自动检索 → 自动读取 README → 给出选型建议"。中间商被去掉了。

它同时也是 Awesome List 形态的一次升级。传统 awesome-list 是 Markdown 表格，人读；这个项目是 Markdown + 结构化 JSON + MCP 三位一体，既保住了人读（categories/*.md 21 个大文件），又给了机器读（data/entries.json），还给了一条自动化生产流水线（scripts/refresh.py + render.py + GitHub Actions）。这种"给人看、给 Agent 看、给 CI 看"的三层设计，正在成为开源项目索引类仓库的新范式。

作者在 README 里写的那句"Found it? Use it, fix it, and report breakage upstream. One maintained client beats ten private scripts."，本质上是一份社区倡议：与其重复造轮子，不如维护那个已经跑通的上游客户端。在闭源产品不断加固、接口不断变更的现实里，一个被上千人盯着的社区客户端，确实比十个躺在某人电脑里的私有脚本更耐用。

从 637 Star 和 12 天的新鲜度来看，这个项目很可能正在成为 AI Agent 工具链的一个标准件。