简介：这是一款面向Windows 64位神奇宝贝玩家的RAID探测工具，基于Qt开发，用于实时扫描服务器中的RAID等级、种类、地点与开始时间，并按玩家偏好快速筛选事件，减少在游戏内反复寻找信息的时间。压缩包共11个文件，体积11.51MB，核心为RaidFinder.exe主程序，附带9个运行所需的DLL与1个raid_solver.py辅助脚本，可支持界面运行和特定RAID求解逻辑。界面简洁、上手门槛低，支持自定义筛选与提醒，能在符合条件的RAID出现时即时通知；2.2.2版本对检索速度和稳定性做了优化，并修复了已知问题。已有280人学习下载，适合想高效组队、捕捉稀有宝可梦或挑战高难度RAID的玩家直接取用。
1. RaidFinder-win64_2.2.2 的第一课：它不找闪，只解团战种子——这套流程值不值得你装
从 Switch 的极巨团战里刷一只闪光宝可梦，很多玩家刷的是券和运气；而 RaidFinder-win64_2.2.2 这个包刷的是确定性。它是运行在 Windows 64 位桌面环境下的团战种子搜索工具，配套《宝可梦 剑/盾》使用，通过 sys-botbase 从 Switch 内存里读回当前团战的种子，然后在 PC 上离线推演出未来数万帧里每一帧对应的宝可梦配置。第一次用的人最容易误解：它不会帮你闪，也不改任何内存数据，它只负责把“哪一帧会闪、是哪一种闪”算给你看，剩下的跳帧和进坑动作还是你自己来。这套逻辑适合两类人：一类是手里已经有一台能运行自制系统的 Switch，愿意折腾十分钟换后续几小时的稳定刷闪；另一类是想搞懂团战 RNG 到底怎么运作的人。先说结论：这个工具解决的核心问题，是把“不可控的团战刷新”变成“可预期的帧序列”。
2. 团战RNG与种子：先把“帧”这个概念立住，再看RaidFinder怎么工作
2.1 从时间戳到种子：团战为什么可预测
团战宝可梦的生成不是“进坑瞬间丢骰子”这么简单。游戏在生成一个极巨坑时，会先基于当前时间信息产生一个种子，之后每一次需要决定“宝可梦种类、性别、特性、个体值、是否闪光”的时候，都会从这个种子里按顺序取出随机数。只要种子相同、调用顺序相同，结果就完全相同。
RaidFinder 做的事情，是把这个种子从游戏内存里读出来，再用和游戏一致的随机数生成算法在 PC 上重放一遍。重放的最小单位就是“帧”。你可以把帧理解为一次完整的团战配置：第 0 帧是当前这颗种子下的第一次判定结果，第 1 帧是下一次，以此类推。实际游戏里，玩家进入坑、看对话、选动画、甚至改系统日期刷新坑，都会让团战推进到不同的帧。所以 RaidFinder 的界面里，最重要的列就是 Frame，它告诉你目标宝可梦出现在哪一帧。
这也是“确定性”的来源：只要种子没变，帧序列就是固定的，闪光、性格、个体值都在那条序列里排好了。没有玄学，只有偏移量。
2.2 为什么必须躺在“确认对话框”里：sys-botbase与内存读取
RaidFinder 不靠摄像头识别画面，也不抓取游戏网络包。它走的是内存读取通道，在 Switch 的自制系统环境下装一个叫 sys-botbase 的插件，让 Switch 在局域网里开一个 TCP 端口，通常是 6000。RaidFinder 作为客户端连接这个端口，发送读取内存的指令，拿到种子。
这里有一个很多人第一次上手时忽略的前提：内存里能读到种子的窗口非常窄。游戏只有在“玩家站在极巨坑前，对话框弹出‘是否挑战’这类确认界面”的时候，种子才驻留在可读取的内存区域。如果你还没点开坑、或者已经进了团战战斗，RaidFinder 读到的要么是残留数据，要么是无效地址。
所以操作顺序必须是：先把游戏停到坑口确认框，再切到电脑上点 Scan。这也解释了为什么 RaidFinder 的 win64 发布包需要配套 sys-botbase，而不是单独一个 exe 就能跑通全流程——桌面端只是算力侧，Switch 端才是数据源。
2.3 一张表看清RaidFinder主界面：七个控件、一个隐藏条件
不同版本的 RaidFinder 界面细节有差异，但核心控件基本一致。我一般按下面这张表对照着找：
| 控件/区域 | 作用 | 我的使用习惯 |
|---|---|---|
| Host/IP 输入框 | 填 Switch 的局域网 IP | 在 Switch 的系统设置里看，不要凭记忆填 |
| Port 输入框 | 默认 6000 | 除非你改过 sys-botbase 配置，否则不动 |
| Game Config | 选择《剑》还是《盾》 | 选错会直接导致种子解析不对 |
| Type | 普通坑 / 活动坑 | 活动期间如果全筛不出来，先回来改这里 |
| Scan 按钮 | 连接 Switch 并读取种子 | 游戏必须停在坑口确认框，否则白点 |
| Generate 按钮 | 从种子开始生成帧序列 | 生成前先设好 Max Frame，后面会讲 |
| Result 表格 | 展示每一帧的宝可梦配置 | 先点列头排序，比手动翻快得多 |
还有一个隐藏条件不在界面上：Switch 和 PC 必须在同一个局域网里，并且 sys-botbase 要在游戏运行中保持后台加载。如果你用的是自带网络转发或虚拟机的 PC，连接超时最常见的原因就是网段隔离，而不是插件没装好。
3. 跑通最小链路：从Switch的sys-botbase取种子，生成一万帧团战结果
3.1 部署sys-botbase：让Switch在局域网里开一个读内存服务
常见做法是把 sys-botbase 的文件夹放进switch/atmosphere/plugins目录，然后重启 Switch。这里不讨论自制系统的安装过程，只说部署完之后的验证方式：在电脑上打开命令行，敲一条Test-NetConnection 192.168.1.100 -Port 6000（Windows 的 PowerShell）或者nc -vz 192.168.1.100 6000，看到端口开放说明插件已经跑起来了。
我遇到过不少用户说“端口通了但 Scan 没反应”，问题往往不在插件，而在游戏状态。sys-botbase 提供的是内存读写能力，但游戏不在正确界面时，RaidFinder 读取的内存区域里没有有效种子。所以部署完插件之后，一定要把游戏推进到坑口确认框再回来测 Scan。
3.2 打开RaidFinder并Scan：网络连通不等于种子正确
启动 RaidFinder.exe 之后，先不要急着点 Scan。按下面顺序做：
- 在 Host 栏填 Switch 的 IP，Port 保持 6000。
- 在 Game Config 里选对是《剑》还是《盾》。
- 确认当前的坑是不是活动坑，不是就保持普通类型。
- 回 Switch，把游戏停在极巨坑前的确认对话框。
- 点击 Scan，观察结果区是否出现一串十六进制种子。
如果出现的是00000000或者提示 invalid seed，说明要么网络连接没建立起来，要么游戏状态不对。这里有个细节：Seed 的显示格式一般是 8 位十六进制，比如3A1B2C4D。看到这串值之后，先复制保存一下，后面跳帧验证要用。
网络连通不等于种子正确。我见过有人端口通了、种子也读出来了，但 Generate 出来的宝可梦列表全是普通怪，查了半天发现是 Game Config 选错版本。所以 Scan 成功之后，先随机看两帧，确认宝可梦种类合理再往下走。
3.3 Generate一万帧：先学会看Frame列，再谈过滤
种子读出来之后，Generate 之前先设置一个合理的帧范围。RaidFinder 一般会让你填 Maximum Frame 之类的参数，我通常填 50000。为什么不是越大越好？因为帧列表是按顺序生成的，几十万帧会让程序在筛选时变慢，而且真正追帧时你也不太会去追一个十万帧开外的目标——跳日期能推进的帧数有限，太远等于给自己挖坑。
点 Generate 之后，结果表会刷出一长串记录。每一行对应一帧，一般包含 Frame、宝可梦、性别、特性、性格、个体值、闪光类型这几项。第一次看这些数据会觉得很乱，但只要盯住 Frame 列就能理清逻辑：Frame 数字越小，代表你从当前种子出发越早能遇到这个配置；Frame 数字越大，就需要你通过改日期或参与其他团战把 RNG 往前推越多。
先别急着过滤，这一步的目标是确认生成链路本身通畅。随便找一行，看它的宝可梦种类和个体值，再回游戏对比当前坑口显示的宝可梦，如果对得上，说明这套链路的准确性没问题。
3.4 把结果导出成CSV：用Python按“至少要4V”做二次筛选
RaidFinder 的结果表可以复制出来存成文本或表格文件。我更习惯把结果导出成 CSV 后用脚本筛，因为界面里的筛选条件只能覆盖常用字段，我想同时卡“至少 4 项个体值是 31”和“只要闪光”这种组合条件时，脚本更顺手。
下面这段脚本按常见的导出列名读取，如果你导出的表头不是这套，先打印一行 header 改一下字段名再跑：
import csv def load_raid_results(path): rows = [] with open(path, newline="", encoding="utf-8-sig") as f: reader = csv.DictReader(f) for row in reader: rows.append(row) return rows def is_shiny(row): # 不同版本的闪光值可能写作 Square / Star / No return row.get("shiny", "").strip().lower() not in ("", "no", "none") def good_iv_count(row, keys=("hp", "atk", "def", "spa", "spd", "spe")): count = 0 for k in keys: try: if int(row[k]) == 31: count += 1 except ValueError: continue return count rows = load_raid_results("raid_results.csv") targets = [ r for r in rows if is_shiny(r) and good_iv_count(r) >= 4 ] targets.sort(key=lambda r: int(r["frame"])) for t in targets[:10]: print(t["frame"], t["species"], t["shiny"], t["nature"], t["ability"])这段代码做了三件事：读取结果为字典列表；过滤掉非闪光项；统计个体值为 31 的项数，只保留至少 4V 的目标。最后按帧排序，方便你决定选哪一个作为实际抓捕帧。
逻辑说明：字典读取方式能避免列顺序变化带来的错位，只要表头名字对上就能跑。参数说明：good_iv_count里的 keys 是六项个体值的简写，如果你的导出表里写成sp_atk或spatk，把元组里的spa替换掉即可。这个脚本的价值在于，RaidFinder 界面里的 IV 过滤通常是一个“所有个体值都不低于 X”的全局条件，但实战里你往往只在意攻击和速度是否 31，脚本的自由度更高。
4. 参数一改结果全变：Shiny Type、IV条数、Frame Range 和 Event 的取舍
4.1 Filter的两个入口：过滤列表不是重新搜索
RaidFinder 的 Filter 区域和 Search 功能经常被混淆。Search 是让工具去帧序列里找特定目标，Filter 是在已经生成的帧序列上做条件筛选。实际操作里，我一般先 Generate 一大批帧，再用 Filter 缩范围，因为重新 Search 往往要重新设置一堆条件，不如面对结果表逐层筛直观。
Filter 的本质是“谓词叠加”：每加一个条件，结果表里满足的行数就减少一层。最容易踩坑的地方是条件叠加的顺序。比如你先选了闪光类型再选性别，和先选性别再选闪光类型，最终结果一致，但中间观察到的行为会不同，容易让你误判是哪个条件导致结果为零。我的习惯是先把最硬的约束放上去，比如闪光类型或活动坑类型，再加软约束比如 IV 条数。
4.2 Shiny Type：星闪、方闪与Xor阈值——选错一帧都白跳
团战里的闪光并不是一个统一的“有闪/没闪”，而是分星闪和方闪两种。RaidFinder 的结果表里通常用 Star 和 Square 来标注。这背后是性格值异或机制，游戏里通过一个阈值判断是否闪光，再通过另一个阈值区分闪光类型。
参数层面你只需要记住：需要星闪就选 Star，需要方闪就选 Square，两者都接受就选 Any。这个参数直接决定后续跳帧的帧号，选错的结果就是你以为锁到了方闪帧，跳过去抓出来却是一只星闪。我早期就吃过这个亏，Filter 里选 Any，结果列表里星闪排在前面，配置完全符合目标，懒得往下翻方闪帧，进坑抓出来才发现闪的类型不对。
对比起来看：
| 参数值 | 匹配结果 | 适用场景 |
|---|---|---|
| Any | 星闪或方闪都保留 | 只求有闪，类型不挑 |
| Star | 只保留星闪 | 特定配队需要星闪特效 |
| Square | 只保留方闪 | 方闪更稀有，收藏向目标 |
还有一个细节：活动坑在此期间闪光概率会被抬高，但因为 Xor 阈值的分布变了，星闪和方闪的占比也会不一样。所以活动期间如果发现目标帧特别多，不要高兴太早，先确认 Type 选的是活动坑，再回来看 Shiny Type 参数是否被默认值覆盖了。
4.3 条数、性格与特性：怎样锁到“不只闪，还想要那只”
闪光只是第一步，多数人刷团战是为了特定宝可梦的高个体值。RaidFinder 的过滤条件里，个体值相关的通常以“至少几个 31”或者“某项必须为 31”的形式出现。
我个人的参数习惯是：如果目标是神兽或准神，我会至少卡攻击和速度两项为 31，第三项在看具体宝可梦。比如目标是多龙巴鲁托，速度 31 是必须的，攻击或特攻二选一也必须有 31；如果目标是热爱甜球，那 HP 和特攻更关键。这个没有通用最优解，但原理是一致的：先把输出向关键个体值卡住，再看性格和特性。
性格过滤器要注意同步特性。团战里宝可梦的性格由 RNG 生成，但你可以用带同步特性的宝可梦站在队首来提高命中率，所以性格过滤和同步特性是搭配使用的。特性方面则分清普通特性 1、普通特性 2 和隐藏特性，RaidFinder 一般用 Ability 1 / 2 / H 区分。如果你要的是隐藏特性，过滤时必须选 H，否则列表里排前面的很可能是普通特性个体。
4.4 Frame Range与帧预算：为什么我默认只生成50000帧
帧序列理论上可以一直往后模拟，但实际游戏里你能推进的帧数是有限制的。每跳一次系统日期，团战会重新生成一个种子，或者基于旧的帧位置推进一段固定步长。这个步长和游戏版本、当前区域、坑洞类型有关，不能一概而论。
所以我会用“帧预算”这个概念来约束 Generate 的帧上限：假设你测出来跳一天能推进 30 帧，你愿意花十分钟跳一周时间，那总预算就是 210 帧。这种情况下，Frame Range 设成 50000 是合理的，因为目标大概率落在零到几千帧之间。但如果目标帧排到了 80000 开外，你可能要跳几百天系统时间，出错概率大大增加，不如重新换一个坑。
实际操作时，我一般先把 Max Frame 设成 50000，Generate 后再打开 Filter 把闪光类型选上，看最靠前的闪光帧在什么位置。如果第一个闪光帧已经超过 30000，我就直接放弃这个种子，回游戏换一个坑再重新 Scan。换坑的成本远比跳几百天低。
4.5 Event参数：活动坑和普通坑的种子规则不一样
活动团战期间，地图上的普通坑会被替换成特殊活动坑，比如特定宝可梦的五星团战。这些坑洞的宝可梦池、闪光阈值和种子生成规则都和普通坑不同。RaidFinder 里的 Type 参数就是用来区分这个场景的。
如果不选 Event 而扫一个活动坑，通常会遇到两类情况：种子能读出来，但 Generate 的结果全是普通坑宝可梦，和当前坑口显示的完全对不上；或者种子根本解析不出来，Scan 提示异常。我判断是否选 Event 的办法很简单：看坑口发光的颜色和坑洞周围是否飘着特殊特效，活动坑通常有明显标记。
另外注意，活动坑的 Event 配置会随游戏版本更新变化，老版本 RaidFinder 可能不认识新活动。如果工具里 Event 下拉列表里找不到对应活动，先确认你的 RaidFinder 版本是否覆盖了这个时期的数据库，不要硬扫。
5. 常见问题与避坑：五次翻车记录，从“invalid seed”到“闪不出来”
5.1 现象：Scan提示invalid seed，或者读出来全是0
原因通常是游戏状态不对。我遇到过最典型的一次是：Switch 连上了、端口也通了，但我人站在坑边，没有把对话框点出来，种子地址读到的是全零。另一类是 Game Config 选错版本，剑和盾的种子地址不一样，读出来的数据无法解析成有效种子。
解决：先把游戏推到极巨坑前的确认对话框，再点 Scan。如果还是 invalid seed，把 Game Config 切到另一个版本重试。这个操作一分钟就能完成，但非常管用。
5.2 现象：改了系统日期，坑位没换，目标帧永远追不上
改了 Switch 系统设置里的日期，回到游戏发现坑口还是同一只宝可梦，种子也没变。原因基本是改日期后没有让游戏重新加载区域，或者站在坑洞里直接改的时间。
解决：改日期前先离开坑洞范围，最好回到附近再打开设置；改完日期后切换一下场景，比如进一次房子再出来，让地图重新加载，再去坑口查看。如果坑没变，就重复一次离开、改日期、加载的流程。记住，改完日期在同一个画面里原地等，是不会触发种子重算的。
5.3 现象：Generate到目标帧很远，跳了两百天也没到
这不是工具错了，而是帧预算没算好。目标帧在 80000 开外，说明这个种子本身离你想要的结果很远，硬跳只会积累更多变数。
解决：先测出当前版本的“跳一天推进多少帧”。方法是：扫描当前种子和当前帧，记下 Frame A；改日期加一天，回游戏重新扫描，得到 Frame B；B 减 A 就是一天的帧步长。有了这个步长，你就知道 80000 帧要跳多少天，如果超过心理预算，直接换坑重扫。
5.4 现象：过滤到星闪却一直不出，抓出来总是方闪或者反过来
原因几乎可以肯定是 Shiny Type 参数和实际预期搞反了，或者你选了 Any 之后没有细看列表里的闪光类型列。我翻车最狠的一次是刷一台特定活动坑，列表里前五个闪光帧全是星闪，但我要的是方闪，当时只看了 IV 和性格，没留意闪光列。
解决：Filter 里明确选 Square 或 Star，不要在“Any”状态下直接选第一目标。选中目标帧后，回表格里双击确认那一行的闪光类型列，再决定要不要跳。
5.5 现象：win64包双击没反应，或者被杀毒软件直接隔离
RaidFinder 这类工具用了内存读取和进程间通信接口，在 Windows Defender 眼里属于敏感行为，误报率不低。另外 win64 发布包依赖 VC++ 运行库，缺库的时候弹窗提示 VCRUNTIME140.dll 找不到或者程序直接闪退。
解决：先从压缩包重新解压一份，以免文件被隔离后残缺；再把整个文件夹加入杀毒软件排除目录。缺运行库就去装对应版本的 VC_redist.x64，装完重启再试。这个现象和工具本身无关，但会让新手误以为包损坏。
6. 验证与进阶：用“跳天-重扫”闭环把RaidFinder接进你的筛选管线
6.1 验证闭环：跳一天后的新种子和旧帧序列怎么对账
拿到一个种子并找到目标帧之后，不要直接埋头跳几百天。先做一个最小验证：记录当前种子的 Frame A，改一天日期，回游戏重新 Scan 得到一个新种子和新 Frame B。用 B 减 A 得到日步长，再用这个步长计算跳多少天能接近目标帧 T。
| 变量 | 含义 | 来源 |
|---|---|---|
| Frame A | 当前种子的当前位置 | Scan 后 Result 栏第一行或 Generate 结果 |
| Frame B | 跳一天后的位置 | 改日期后重新 Scan 并 Generate |
| Frame T | 目标帧 | Filter 后从结果表读 |
| Step | 一天推进的帧数 | B - A 的绝对值 |
| Days | 需要跳的天数 | (T - B) / Step，取整 |
这套对账不要省。如果 Step 算出来是负数或者超过预期范围，说明你之前 Scan 时游戏状态可能不对，或者 Type 选错了。宁可多花三分钟验证，也不要盲目跳一个月结果发现帧差越拉越大。
6.2 进阶用法：把“1万帧结果+目标筛选”做成半自动流程
如果你经常刷同一类宝可梦，可以把第 3.4 节的 Python 脚本扩展成一套固定流程：每次 Scan 后 Generate 一万帧，导出 CSV，脚本自动只输出闪光且满足个体值条件的前十个目标。我想强调的是，脚本不要试图去“自动化改 Switch 日期”或“自动按按键进坑”，这些操作一旦出错，你可能直接错过目标帧甚至把种子搞乱。半自动的意思是，PC 负责算，你负责执行游戏里的动作。
常见做法是将脚本输出结果直接当成“行动清单”，按帧排序后逐条执行；如果第一个目标帧太远，看第二个。这个习惯能让你从大量结果里快速定位可执行目标，而不是盯着界面翻几百行。
6.3 最后一点：保持版本意识，别让旧包拖累新游戏
RaidFinder-win64_2.2.2 这个版本号是一个固定快照，它对应某个时期的《剑/盾》游戏版本和活动配置。游戏更新之后，种子地址、活动坑参数、甚至 RNG 调用顺序都可能变化，旧包很可能读不出新种子。我现在的习惯是，每次游戏版本更新后先做一次扫描验证，确认种子和帧序列对得上，再批量刷。最后想告诉你的是，这套工具最大的价值不在“自动出闪”，而在于让每个操作都有可验证的结果：种子变了、帧差了、参数错了，每一步都有反馈。希望帮到你，也希望你刷到的每一只闪光都是自己想要的那一只。
本文还有配套的精品资源，点击获取
