最近这两周，AI 逆向圈像是过年。
8 月 22 日，一个叫 x64dbg-MCP 的插件悄悄上线 GitHub，一周冲到了 1500+ 星、160 个 Fork。知乎它干的事很简单：把 x64dbg 这个 Windows 上最经典的调试器接到 AI 上——你在 Claude Code 里说一句「把程序加载进调试器，停在入口点」，AI 替你把鼠标键盘的活全干完，再顺手把寄存器值和内存内容整理好报给你。
而另一个叫 reverse-skill 的项目，8 月初空降 GitHub Trending 第一。知乎到 8 月中旬，它单日涨星一度超过 9000。知乎但它走的路完全不同：不接任何调试器，只给 AI 装一套「老工程师的脑子」。
两个项目都火了之后，评论区吵成了两派：一派说「逆向工程师要失业了」，另一派说「玩具，真干活还得靠人」。
其实两派都没说到点子上。这两个项目代表的是 AI 逆向的两大路线——一条是给 AI 接上手，一条是给 AI 装上经验。选错路线，不是多费点劲的问题，是根本跑不起来的问题。
今天把这事一次说清楚。
一、两大路线，到底各是什么
先看 x64dbg-MCP。
作者 Duty1g 有十多年安全经验，拿过 OSCE³ 认证，是 Synack 红队成员。知乎这个插件用 Zig 语言编写，零依赖，编译出来就是一个 .dp64 文件，扔进 x64dbg 的插件目录就能用——不用装 Python、.NET 或 Node.js，二进制只有几百 KB。
它提供 80 多个 MCP 工具，覆盖 x64dbg 几乎全部常用操作：加载、运行、暂停、断点（含硬件断点）、单步、读寄存器、读内存、反汇编——过去靠鼠标键盘做的操作，现在一句话就能表达。知乎而此前社区里流传的方案，要么需要 Node.js 做中转层，要么得跟着视频教程一步步配半天才能跑起来，门槛不低。哔哩哔哩
还有个细节值得一提：逆向环境常常是隔离沙箱或专网机器，少一个依赖就少一个出问题的环节，「零依赖」正是这个项目能圈粉的原因。
reverse-skill 则完全是另一种东西。
它自己不操作任何工具，只做「分诊」：任务进来，先用 41 条路由规则判断这是什么任务（APK？ELF 二进制？JS 混淆？固件？），再扫描本机装了什么工具，然后才决定用什么方法——APK 上 jadx 还是 apktool，ELF 开 Ghidra 还是 radare2，前端加密该抓包、hook 还是 AST。知乎老手靠直觉，它把直觉写成了机器可读、可验证的路由表。
这个项目有 42 个场景技能，甚至在 CI 里跑着 163 个回归测试用例——谁改了路由规则，只要一条用例不匹配，CI 立刻变红。它还有一道强制授权门：不填好 scope，AI 不会对任何目标动手。知乎
一句话总结：x64dbg-MCP 解决的是「AI 不会操作调试器」，reverse-skill 解决的是「AI 不知道该干什么」。
二、选哪条路线？先看你拆的目标「活多久」
这是本文最反直觉的结论，也是最重要的判断。
今年 3 月，看雪论坛上有一位叫「执着的猫」的作者，写文章记录了自己实测 unidbg 官方 MCP 之后放弃的过程：在 unidbg 官方加入 MCP 之前，他就已经尝试过给 unidbg 做 MCP 接入，结果发现问题比想象中多得多，最终放弃了这条路线。知乎
unidbg 官方投入不小：自研了一个约 2600 行代码的 HTTP+SSE 服务器，暴露出 50 多个调试工具，本质上是一个 AI 驱动的 GDB。但把它放到实际的 Android SO 逆向工作流里，踩了四道坎，道道都是结构性问题。
第一道坎，补环境。用 unidbg 跑 SO，最痛苦的不是分析，是 mock JNI 环境。补环境要改 Java 源码、触发编译、读报错输出——这些 MCP 全都干不了，它的工具箱里全是 read_memory、set_register 这类运行时操作，没有一个能「改代码」。
第二道坎，试错。逆向选错 hook 点是常态，但 unidbg 是模拟器，每次运行都从头开始，生命周期只有几秒，错过一个断点就得重来，而 MCP 没有「重启模拟器」的能力。写成代码的方式，改一行重跑 3 秒出结果。
第三道坎，算法验证。逆向的本质是「提出假设→验证→修正」，怀疑里面有一段魔改 AES，验证就要写 GF(2^8) 乘法、矩阵运算、S 盒查表这类纯算法代码，动辄几百行。MCP 能读数据，但不能算——AI 最后还是得说「我写个 Python 脚本验证吧」，绕回代码生成。知乎
第四道坎，输出爆炸。一次 trace 可能输出几十万条指令，拼成 JSON 约 30MB，AI 的上下文窗口装不下，内存先溢出了。
所以这位看雪作者得出的结论是：MCP 适合「长生命周期」的目标——真实的 Windows 进程、常驻服务，断点打错了能改，状态随时能查；x64dbg-MCP 恰好就是这个场景，所以它的路线是对的。知乎而 Skills（让 AI 写代码）适合「短生命周期、反复重跑」的目标——unidbg、APK 静态分析、算法还原，这类场景的循环天生就是「写代码→跑→看结果→改代码」。
这正是这两个同期爆火项目的本质区别，也是可以直接套用的选路线标准：
调试 Windows 软件、常驻进程 → x64dbg-MCP 这条线
Android SO、算法还原、JS 混淆，一切需要「反复重跑」的 → Skills 这条线
很多人的实际工作流是两个都用：MCP 负责交互式调试，Skills 负责方法论和脚本沉淀
用那篇看雪文章里的话说：把 AI 当作一个极其高效的代码生成器，远比把它当作一个远程调试操作员更有价值。知乎
三、上手之前，先看这份避坑清单
心动的话，先把别人踩过的雷看一遍：
reverse-skill 的第一个坑，是忘了跑 refresh-tool-index。这个脚本负责扫描本机工具、生成索引，不跑的话 AI 读规则时找不到工具清单，路由直接失效。知乎部署文档里白纸黑字写着，但多数新手会直接跳过。
依赖门槛不低。reverse-skill 需要 Java（给 jadx/apktool 用）、Node.js 22+、Python 3.x，再加一个 AI 客户端，光装依赖就够新手喝一壶。知乎而且它本质是「技能包」，不是「一键破解神器」：逆向基础为零的话，光靠它出不了活。它是给有基础的人加的智能助手，不是替你打基础。
x64dbg-MCP 还很早期。1500 星证明了需求存在，但每个工具在真实场景里的稳定性还需要更多实践验证。它是 MIT 协议开源，作者明确声明只用于合法的逆向工程和安全研究。
合规红线不是客套话。连 reverse-skill 自己都把「授权门控」做成了强制步骤——分析自己的软件、做授权内的测试、玩 CTF 都没问题，碰未授权的目标不是技术问题，是法律问题。知乎
第三方 Skills/MCP 自身也要做安全审查。你装的是一包提示词规则和工具调用脚本，等于把 AI 的行动权交给规则作者，装之前过一遍源码，尤其是路由规则和脚本部分。
四、不同段位，进不同的门
最后给分层建议：
入门好奇型：先别急着装。翻一遍 reverse-skill 的 RULES.md 和路由配置，看老手怎么拆解一个任务，比工具本身值钱。想动手感受，找一个自己写的小程序，用免费的 Ghidra 加通用大模型，先体验一次「AI 读反汇编」的循环。
进阶、做 Windows 软件或游戏安全方向：x64dbg-MCP 值得花 30 分钟试试，部署成本极低，一个 .dp64 文件的事。第一次测试建议别上真实任务，让它加载一个你熟悉的程序、停在入口点、解释当前函数——先确认「读和报」的链路顺了，再谈深活。
移动端、算法方向：认真考虑 Skills 路线。可以直接部署 reverse-skill（记得先跑工具索引），也可以参考它的结构，给自己的高频场景写一份 SKILL.md。逆向里真正值钱的资产是那些验证脚本，每沉淀一个到代码里都是赚的。
离线、涉密场景：本地模型已经值得考虑。8 月底有个测试引起不小讨论：本地跑 Qwen 3.8 27B，30 分钟逆向出一款商业软件的许可证验证，还原出二进制里被刻意混淆的 RSA 公钥，中途出错还会自我修正重试，最终生成了可用的绕过 PoC。整个过程离线完成，模型只需要 17GB 显存。知乎当然这只是单一案例，不代表任何目标都能拆，但对「二进制不能出隔离机」的场景，这是一个以前不存在的选项。
接下来值得盯的：MCP 生态会不会出现更多针对 IDA、Ghidra 这类重型工具的插件。今年的腾讯云黑客松智能渗透挑战赛上，已经有参赛队伍把逆向分析做成了专门的 Reverse Agent，用的正是 Ghidra MCP。知乎以及 Skills 类项目会不会出现面向垂直场景的轻量版。这两条路线不是谁替代谁，它们会长成 AI 逆向的两只手。
浪已经来了，但下水之前，先看清自己手里要拆的是什么。
