hashcat 实战：从密码恢复原理到弱口令审计排查

我第一次真正认真研究 hashcat，不是在网上看跑分，而是有一次公司内部做密码安全自查，需要快速验证一批内部服务账号是否存在弱口令。当时拿到的是系统导出的哈希列表，有 NTLM 格式的，也有 MD5 格式的，如果不借助工具，根本不知道哪些账号还在用"123456"这种密码。也就是那次，我认真把 hashcat 的运行逻辑、攻击模式、优化参数挨个过了一遍。用过之后最大的感受是：这工具真正难的地方，根本不在于命令记忆，而在于先想清楚"现在跑的是哪一类哈希、目标大概是什么结构、我手头有哪些词表资源"。

市面上讲 hashcat 的教程不少，但大多有个通病：上来就丢一条命令，比如 hashcat -m 0 -a 0 hash.txt rockyou.txt，然后说"等着出结果就行"。至于为什么选 -m 0、-a 0，为什么有些哈希跑一天都不出结果，为什么换个文件就报 Token length exception，很少有人讲清楚。这篇文章我想按自己的使用路径，把这套工具的底层逻辑、常用姿势和踩坑记录整理出来。无论你是刚开始接触密码恢复，还是在做合规审计时需要验证弱密码风险，应该都能从中找到可以直接落地的东西。

1. 先纠正一个认知：hashcat 不是"解密"，而是高速"猜密码"

很多人第一次用 hashcat，抱着"把密文放进去，明文吐出来"的期待，这其实是对它运行逻辑最大的误解。哈希函数是单向的，MD5、SHA256、NTLM 这类算法都不可逆，密文并不是密码经过"某种加密"后的结果，而是密码经过单向散列后的一串摘要。你不能从摘要里倒推出原始密码，只能把密码猜出来，再用相同的散列算法算一遍，对比摘要是否一致。一致，就说明猜中了。

1.1 四条核心链路：候选密码、散列、比对、命中

hashcat 的所有工作都可以压缩成四步：

1. 生成一个候选密码，比如 123456。
2. 用目标哈希对应的散列算法，把候选密码计算成摘要。
3. 把这个摘要和待破解的哈希进行比对。
4. 如果一致，这个候选密码就是明文；如果不一致，换下一个候选密码，循环往复。

所以 hashcat 实际上是一个"高速密码猜测引擎"，它的核心能力不是解密，而是极快地枚举候选密码。判断一个密码能不能被跑出来，取决于三件事：目标哈希使用了什么散列算法、候选密码的生成范围覆盖了没有真实密码、以及硬件每秒能完成多少次比对。

1.2 为什么单颗 GPU 能比 CPU 快这么多

这里要补一点硬件层面的理解。CPU 的设计目标是处理复杂、分支多的逻辑任务，核心数量通常只有几个到几十个。而 GPU 的设计目标是同时处理大量简单、重复的浮点运算，一颗中端显卡可能就有上千个流处理器。hashcat 恰恰把"猜密码"这件事拆成了大量互相独立的简单任务——每个候选密码都可以单独计算、单独比对，相互之间没有任何依赖。这种任务形态天然适合 GPU 并行处理。

你可以想象一个场景：CPU 是一个博士生，能解决的题目比较复杂，但一次只能算一道；GPU 是一屋子小学生，单个能力有限，但可以同时算一千道"两位数字乘法"。散列运算恰好是"两位数字乘法"级别的重复计算，所以 GPU 在密码恢复上能比 CPU 快成百上千倍。这也是 hashcat 官方一直推荐用显卡而不是 CPU 跑的原因。

1.3 "破解"和"恢复"的说法为什么都有

在安全圈里，大家普遍叫"密码恢复"或者"弱口令验证"，而不是叫"破解"。一字之差，意义完全不同。密码恢复隐含的前提是：哈希来自你自己管理的资产、来自授权的安全测试、来自 CTF 题目，或者来自已经泄露的数据集，你的目的是通过技术手段把弱密码暴露出来。把它当成"破解工具"去撞目标系统、破解别人账户，那是另外一回事，也不在这篇文章的使用建议范围内。我在后面讲预处理和边界时还会提到这一点。

2. hashcat 的核心运行逻辑：模式、攻击方式和状态流转

搞懂了"猜密码"这个本质，再看 hashcat 的参数就不会晕了。一条典型的命令由三块组成：目标哈希类型、攻击模式、密码候选来源。如果你不理解这三块各自负责什么，很容易出现"命令跑起来了，但方向完全错了"的情况。

2.1 -m 参数：告诉 hashcat 用哪一种散列算法

-m 全称是 hash type mode，它决定了 hashcat 用哪种散列函数去计算候选密码。选错了模式，后面的活儿全部白干。举例来说，同一个哈希字符串在其他上下文里可能代表完全不同的算法，只有模式匹配正确，比对才有意义。

下面是我日常用到频率最高的几个模式：

建议不要硬背，用的时候先确认哈希格式，再对照官方 example_hashes 文件确定模式。这个文件在 hashcat 开源仓库里维护得很好，列出了几百种哈希类型对应的典型样例，格式识别基本靠它。

2.2 -a 参数：决定候选密码从哪来

散列算法确定了，接下来要回答的问题是如何生成候选密码。hashcat 把常见的生成策略封装成几种攻击模式，平时我用得最多的是下面几种：

这里最容易混淆的是字典和掩码的关系。字典攻击是"我有一些可能密码的集合，挨个试"，掩码爆破是"我不知道具体内容，但知道大致的组成规则，穷举这个规则下的所有组合"。"知道大致组成规则"这句话比大家想象的更常见——比如很多系统强制要求密码不少于 8 位、至少包含大小写字母和数字，这个策略本身就缩小了掩码空间；又比如某个账号的默认密码是"公司名简称 + 工号"这种结构，把前缀确定下来以后，后面只需要爆破 4 到 6 位数字。

2.3 状态流转：从 Initializing 到 Cracked 的生命周期

hashcat 跑起来以后，输出界面上会有状态信息。新手看到满屏滚动的 hashcat 输出容易慌，其实需要关注的只有几个字段：

• Status：当前状态，常见的是 Running、Cracked、Exhausted。
• Speed：当前每秒尝试的候选密码数量，单位通常是 kH/s 或 MH/s。
• Time.Estimated：预计跑完当前模式需要的时间。
• Candidates：当前正在尝试的候选密码。
• Recovered：已经成功恢复的哈希数量。

Cracked 表示已经有一个或多个哈希被命中，此时按下回车或者等待结束，hashcat 会把结果写入 potfile。Exhausted 不一定是坏事，它表示当前候选集合已经全部跑完，只是没有命中而已。看到 Exhausted 后，正确的思路不是抱怨 hashcat 不行，而是回头检查：词表是否覆盖了真实密码的构成、规则用得够不够、掩码空间设置得对不对。

3. 环境准备阶段最容易踩的坑：别装"中文版"，先让设备被识别

网上的热搜词里有个很典型的说法叫"hashcat 中文版下载"。我的建议很直接：不要下载任何标着"hashcat 中文版"的第三方打包。原因很简单，hashcat 本身是开源项目，发布包里只有英文帮助信息，但它只是个命令行工具，需要的不是"汉化界面"，而是理解参数含义。所谓中文版下载站，很多是捆绑了广告、木马、甚至挖矿程序的非官方修改版本，用来跑密码恢复的工具如果本身不可信，后果不堪设想。

3.1 正确的安装方式

在 Kali Linux 里，hashcat 是预装工具。Debian/Ubuntu 系统可以执行：

bash复制sudo apt update && sudo apt install hashcat -y

macOS 可以用 Homebrew：

bash复制brew install hashcat

Windows 用户建议直接到 GitHub 官方仓库的 Releases 页面下载 7z 压缩包，解压后就能运行 hashcat.exe。注意 Windows 版依赖显卡驱动提供的 OpenCL 运行库，NVIDIA 用户一般要装最新的 NVIDIA 驱动，AMD 用户要装 Adrenalin 驱动，Intel 核显用户也得装对应的图形驱动。

安装完成后，先用一条命令验证环境：

bash复制hashcat -I

-I 会列出 hashcat 可以使用的 OpenCL 设备。如果你能看到类似 NVIDIA GeForce RTX 4060 这样的条目，说明环境正常。如果提示找不到平台或设备，检查驱动安装，再检查是否缺少 OpenCL 运行库。这个检测比直接跑命令重要得多，因为很多后续的诡异错误，根子都在设备没被识别上。

3.2 跑一次内置基准测试

环境识别正常后，我建议立刻跑一遍基准测试，确认当前硬件的真实速度：

bash复制hashcat -b

-b 会对多种常见哈希算法执行基准测试，然后把每个算法的速度打印出来。这个速度数据能帮你判断某些任务是否现实：如果一个哈希算法在你这台机器上只有 10 kH/s，而候选空间超过 1 亿，那就该意识到这个任务可能需要几个星期，是否应该换思路而不是空等。

3.3 Windows 和 Linux 的路径问题

如果你用的是 Windows，注意 hashcat 对路径分隔符的处理。命令里的文件路径尽量用反斜杠时，最好用引号包起来；更省心的方式是直接切到 hashcat.exe 所在目录，把哈希文件和词表放到同目录，用相对路径运行，减少因为路径问题导致的"加载不了文件"或"文件名被 shell 转义"这类低级错误。

词表文件的编码也要注意。hashcat 默认按 UTF-8 读取字典，如果你在 Windows 上手动编辑了一个 UTF-16 编码的文本文件放进去，会报 Line-length exception。最简单的处理方式是用 VS Code 或 Notepad++ 把词表转成 UTF-8 编码，再跑任务。

4. 第一次实战：从生成测试哈希到看见 Cracked

很多教程直接拿传说中的 rockyou 词表和真实抓到的哈希来演示，但实际复现的时候容易因为哈希类型不一致、词表路径不存在导致失败。我第一次带新人入门时，都建议他们先从自己生成的哈希开始。好处是你能完全掌握真实密码，验证流程是否走通，再去处理真实数据。

4.1 先造一个测试目标

在 Linux 终端里执行：

bash复制echo -n "Sunshine1314" | md5sum | awk '{print $1}' > test.hash
cat test.hash

这里的 -n 表示不输出换行符，否则哈希计算会包含换行符，得到的结果和你预期的密码对不上。awk '{print $1}' 是把 md5sum 输出里的文件名部分去掉，只保留哈希值。执行完以后，test.hash 文件里就是 Sunshine1314 这个明文的 MD5 摘要。

如果你用的是 Windows，可以在 PowerShell 里这样生成：

powershell复制Write-Output -NoNewline "Sunshine1314" | Get-FileHash -Algorithm MD5 | Select-Object -ExpandProperty Hash -OutVariable h
$h.ToLower() | Out-File -Encoding ascii test.hash

4.2 识别哈希类型，别靠肉眼猜

能肉眼认出 MD5 是因为它固定 32 位的十六进制串，但现实中很多哈希长得并不标准。建议先用识别工具排查，比如 hashid 或者 hashcat 官方仓库的 example_hashes。Kali 里自带 hashid：

bash复制hashid test.hash

输出可能会提示 MD5 或 MD5 的几种变体。这时候还需要结合场景判断：你自己生成的是纯 MD5，所以模式选 -m 0 没问题；如果是从某个系统日志中拿到的哈希，最好先确认这个系统技术栈里最常用的散列算法，而不是只信自动识别结果。

4.3 用字典模式跑第一次

新建一个小字典文件：

bash复制echo -e "hello\nSunshine1314\nadmin" > small_dict.txt

然后用 hashcat 跑：

bash复制hashcat -m 0 -a 0 test.hash small_dict.txt

如果一切正常，几秒内输出会显示 Cracked。此时用下面的命令查看明文：

bash复制hashcat -m 0 -a 0 test.hash small_dict.txt --show

之所以要用 --show，是因为 hashcat 默认会把破解成功的哈希立即写入 potfile，但不会在结束后的屏幕输出里重复显示明文。--show 的作用是读取 potfile，把已经破解的哈希对应的明文展示出来。这是一个非常适合做自动化验证的接口，我后面会细说。

4.4 加规则扩展字典：没有词表里的词也能命中

实际场景里，纯字典攻击命中率往往不够。比如真实密码不是 Sunshine1314，而是 Sunshine1314!，如果词表里没有这个变体，字典模式就会 Exhausted。这时候规则的作用就体现出来了。

hashcat 的规则文件通常存放在安装目录下的 rules/ 子目录中，Kali 下一般是 /usr/share/hashcat/rules/。最常用的是 best64.rule，它包含 64 条经过实战验证的密码变形规则。命令是：

bash复制hashcat -m 0 -a 0 test.hash small_dict.txt -r best64.rule

规则的本质是告诉 hashcat："每读到一个字典里的基础词，不要只试它本身，还要按规则生成一系列变体。"比如基础词 password，配合常见规则可能生成 password1、Password、P@ssword、password!、1password 等。可以先用 --stdout 参数预览规则生成的结果，避免规则不符合预期：

bash复制hashcat --stdout -a 0 -r best64.rule small_dict.txt | head -20

这不会去破解任何哈希，只负责把候选密码打印出来，是调试规则和词表的利器。

4.5 用掩码处理有结构的密码

如果已知目标密码是"一个手机号"，也就是 11 位数字，那么字典和规则可能都不如掩码高效。执行：

bash复制hashcat -m 0 -a 3 test.hash '?d?d?d?d?d?d?d?d?d?d?d'

?d 代表数字 0-9。这条命令会穷举所有 11 位数字组合，共 100 亿种可能。在 GPU 上跑 MD5 的话，速度动辄每秒几亿次，理论上并不算费力；但如果你的真实密码是 "手机号 + 两位字母"，掩码就要相应调整。常用的内置字符集如下：

还可以自定义字符集，比如 -1 ?d?l 表示字符集 1 为数字加小写字母，然后掩码里写 ?1?1?1?1?1?1，就表示穷举 6 位数字或小写字母构成的所有组合。这种写法在爆破四位和六位 PIN 码时非常有效。

5. 跑不动或跑太慢时，我会这样优化和断点续跑

hashcat 跑不起来的情况其实很少，更多是"跑得太慢"或者"跑到一半中断了"。中断这件事在真实场景里几乎必然发生，因为 GPU 长时间满载会带来散热和功耗问题，或者你临时需要把显卡让给其他任务。所以任务管理能力比单纯的命令记忆重要得多。

5.1 指定 Session，中断后能一键恢复

默认状态下，hashcat 会在中断时把进度写入恢复文件，但如果你同时跑好几个任务，不指定会话名称，恢复时很容易混淆。我建议每次大规模任务都显式指定 session：

bash复制hashcat -m 1000 -a 0 ntlm.hash rockyou.txt --session=ntlm_audit

跑到一半想暂停，直接按 Ctrl+C，hashcat 会提示恢复文件的保存位置。需要继续时，执行：

bash复制hashcat --session=ntlm_audit --restore

--restore 会从上次中断的位置继续，而不是从头开始。这个机制在大候选集合下非常重要，否则每次中断都重跑，时间成本完全不可接受。

5.2 potfile 是破解结果的"账本"

hashcat 会把所有已破解哈希对应的明文记录在 potfile 中，默认位置是用户目录下的 ~/.hashcat/hashcat.potfile。每次启动任务时，hashcat 会先读取 potfile，如果发现某个哈希已经在里面，就不会再耗费算力去重复测试。所以你可以做这样的事：第一次用字典跑了一批哈希，跑完查看哪些没破解，然后换个规则或者词表再跑一次，已经破解的那些会自动跳过，运行效率高得多。

如果自动化脚本需要读取结果，也走 potfile：

bash复制cat ~/.hashcat/hashcat.potfile

每条记录的一般格式是 哈希值:明文。注意，如果哈希本身含有冒号字段（比如 salt:hash 格式），输出格式会相应变化，脚本解析时要结合具体模式处理，不要天真的用第一个冒号做分割。

5.3 优化参数：-O、-w、-n 怎么配合用

hashcat 提供了一些通用优化参数，但它们不是无脑加上就更快：

• -O：启用内核优化，尝试用更大的循环和更少的寄存器去换取更高吞吐。大多数情况能用，但对某些算法可能不稳定，甚至导致 CL_OUT_OF_RESOURCES。
• -w：工作负载模式，取值 1 到 4。-w 3 是普适的选择，能让电脑以较高负载运行但不会完全卡死；-w 4 会有更激进的资源占用，可能让系统"假死"，建议只在专用跑哈希的机器上用。
• -n：设置每个设备的并行规则数，调大有时能提升速度，但调太大可能触发驱动超时。

我自己常用的组合是 -O -w 3。如果跑高负载任务时显卡驱动报 Reset device，通常是因为内核执行时间超过操作系统限制，这时可以尝试调低 -w，或者给 GPU 降频降温，而不是一味加负载。

5.4 用 --stdout 先演练，别浪费 GPU 时间

在正式开跑大任务之前，我会先用 --stdout 检查候选密码的生成范围。比如用了某个规则和词表，先用命令统计一下候选数量级：

bash复制hashcat --stdout -a 0 -r rules/best64.rule small_dict.txt | wc -l

这样能在一分钟内知道规则会把词表扩展成多少行。如果扩展后的候选数量是天文数字，而目标哈希算法速度又不快，就应该提前判断任务是否需要调整方向，而不是让机器空转到天荒地老。

6. 报错排查清单：那些让我卡壳一下午的问题

hashcat 的报错信息整体上是清晰的，但新手很容易在文件格式阶段就出错。下面这几个问题是我见过最多、自己也踩过的，整理成清单供排查。

6.1 Hashfile 解析类报错

最常见的一类报错集中在"hashcat 读不懂你的哈希文件"。

Separator unmatched 表示哈希文件里的一行没有按照预期格式用冒号分割。比如你跑的是带 salt 的算法，模式预期每一行是 哈希:salt，但你给的哈希不含冒号，就会报这个错。解决办法是核对模式，把文件改成它期望的格式。

Token length exception 表示某个字段的长度和模式不匹配。比如模式 0 需要 32 位 MD5，但你文件里有一行是因为复制粘贴漏了字符，长度变成 31 位，就会触发这个异常。排查方法：

bash复制cat -A hashfile

cat -A 能看到行尾字符和不可见字符。我碰到过很多次，问题是出在 Windows 记事本保存的 \r\n 换行符上，把这些转换掉就正常了。

No hashes loaded 表示没有任何哈希能被识别。最常见的原因是你把包含系统用户名的 /etc/passwd 或密码策略说明文件直接丢给了 hashcat。hashcat 只能处理"纯哈希列表"，不能帮你从乱七八糟的文本里自动提取。你需要先用工具把感兴趣的哈希字段提取出来，整理成一行一个的格式。另外，哈希文件里的 # 开头的行是注释，写完注释后注意别加在哈希行中间。

6.2 设备相关报错

No devices found 或 CL_PLATFORM_NOT_FOUND_KHR 表示 hashcat 找不到可用的 OpenCL 设备。这种事情在 Windows 上特别常见，重装系统后没有驱动或者驱动版本过老都可能导致。首先执行 hashcat -I，确认列表里是否有 GPU 设备。如果列表是空的，去厂商官网装最新驱动，不要只依赖 Windows 自动更新。

CL_OUT_OF_RESOURCES 一般是显存不足或内核资源分配失败。出现后可以先加 -O 让 hashcat 使用优化内核，如果还是不行，检查显存占用，关闭其他占显存的应用，或者调低 -w。

6.3 任务"跑完"但没有结果

这个问题不报错，但比报错更让人抓狂。眼看着状态变成 Exhausted，却一条都没有 Cracked，你可能会怀疑 hashcat 是不是有问题。大多数时候，hashcat 没有问题，问题出在候选密码根本没覆盖真实密码。

我的排查顺序是：

1. 用 --show 看 potfile，确认之前是不是已经破解过这个哈希，只是没注意。
2. 检查哈希模式是不是选错了。模式选错时，所有候选密码算出来的摘要都和实际不同，永远不可能匹配。
3. 检查词表和规则是否命中目标密码的构造方式。如果目标是 P@ssw0rd2024，你却只跑一个小写纯字母词典，那耗尽是正常的。
4. 用时间预估反推。如果候选空间有 100 亿，而当前速度每秒只有 1000，说明这个任务需要 11 天才能跑完，此时状态虽然是 Running，但基本等于跑不出来。换规则、换掩码、缩小范围才是出路。

6.4 小心忽略 potfile 带来的"重复劳动"

默认 potfile 是全局的，如果你在测试时破解了一个测试哈希，之后再跑一个包含相同哈希的任务，hashcat 会直接认为它已破解而不重复计算。这在正式任务中是好事，但如果你想做算法对比或复现某个命令，记得用独立的 potfile，避免结果被全局 potfile 污染：

bash复制hashcat -m 0 -a 0 test.hash small_dict.txt --potfile-path ./my.potfile

顺便说一句，--remove 参数可以在哈希破解后立刻从输入文件中删除该行。如果你后续想要保留原始哈希文件，不建议加这个参数，因为不可逆。

7. 不是所有密文都能直接丢给 hashcat：预处理链路与使用边界

hashcat 之所以强大，是因为它支持几百种哈希类型，但这并不意味着你可以把一个 Wireshark 抓包文件、一个加密的 zip、一份 PDF 直接丢给它。hashcat 只能处理"已经被提取成规范哈希行"的数据。各种文件格式到哈希行之间的转换，通常需要另一套工具链完成。

7.1 典型场景的预处理链路

以常见的文档加密为例，你拿到的是一个加密的 Office 文档或者 PDF，hashcat 本身并不直接解析这些文件格式。一般会用 John the Ripper 工具链中的脚本先把文件转换成 hashcat 能识别的哈希行，比如 office2john.py、pdf2john.pl。生成的哈希以 $office$ 或 $pdf$ 开头，这种格式 hashcat 才能识别并指定对应的模式。

Linux 系统的 /etc/shadow 文件也是类似。文件里的密码字段直接就是哈希串，但格式可能是 $6$salt$hash，此时需要把整段（包括 $6$salt$hash）作为一行提取出来，然后用 -m 1800 跑。如果你只把最后的哈希部分拎出来，忽略了 salt，就会因为字段缺失而报解析错误。

Windows 域环境里的哈希格式同样特殊，NTLM 哈希相对简单，提取后配合 -m 1000 即可；但如果涉及 Kerberos 票据，就需要先从抓包或内存中提取对应格式的 ticket，再匹配具体模式。这一步通常不只是在 hashcat 命令层面能解决的。

我这里不展开具体攻击链细节，核心想表达的是：一定要先搞清楚你手里的数据是"原始文件"还是"标准哈希"。如果是原始文件，先去查对应的转换方式；如果已经是标准哈希，再去确定模式。跳步是新手常见误区。

7.2 授权边界：什么场景才适合开跑

讲使用边界时，我把话说得直白一些。hashcat 是密码安全审计和密码恢复的常备工具，适合的使用场景包括：

• 你自己创建的账户密码的恢复验证；
• 公司明确授权的内部密码安全自查，目标是发现弱口令并推动整改；
• CTF 比赛、漏洞靶场等实验室环境中给出的挑战哈希；
• 对已公开泄露的数据集做密码习惯分析，帮助安全团队了解员工或用户的弱密码模式。

如果你手里的是别人系统的哈希，没有获得授权，那不管技术上多简单，都不应该运行。原因不只是法律风险，更是安全从业者的基本底线。我见过有人拿 hashcat 跑邻居家 WiFi 抓包，或者拿同事的域账号哈希做测试，这种行为一旦被溯源，后果往往远超想象。

7.3 从审计视角看 hashcat 的价值

最后分享一个在真实安全项目里的视角。做弱密码审计时，目标不是跑出所有哈希的明文，而是找出最脆弱的那一批账号。通常流程是：先跑一遍常见的 1000 万到 1400 万词的经典词表，再叠加几套高频规则，看看哪些账号使用了极简密码。命中那些账号后，报告里最优先说明的应该是"弱密码风险面"和"整改建议"，而不是把每个明文都展示出来。

从防御角度看，跑 hashcat 的意义其实不是"秀破解能力"，而是验证组织的密码策略是否真的阻挡了弱口令。如果 30% 的账号能在几分钟内被词表命中，那说明即使系统强制了 12 位密码，用户仍然会用 Admin@123456 这类变体，策略形同虚设。基于这个结论去推动密码策略调整、多因素认证和账号风险监测，比单纯晒破解结果有价值得多。

我在实际项目里还有个惯例，所有跑出来的弱密码明文，只进入安全整改工单，不会随意拍照、截图或者转发到非保密的协作群。明文口令本身就是敏感信息，哪怕它来自测试环境，处理不当也可能引发后续问题。如果你把这个工具用在合规安全项目里，建议从一开始就定好明文数据的存储和知悉范围。

hashcat 学习曲线的终点不是记住更多参数，而是能准确判断一个密码恢复任务是否可行、资源投入是否合理、流程是否合法合规。我的经验是，不要一上来就追最新的 GPU 跑分，先用一个小型项目把字典、规则、掩码、potfile、session 这些概念闭环走一遍，等到真实任务来临，你才不会慌。