检查 Clash（mihomo）中的 DOMAIN-KEYWORD 之前，需要先准备正反两组样例。正样例用来回答哪些域名应当被关键字命中，反样例用来回答哪些域名即使含有相近字符也不能被命中。文档把 DOMAIN 定义为匹配完整域名，把 DOMAIN-SUFFIX 定义为匹配域名后缀，并把 DOMAIN-KEYWORD 定义为域名关键字匹配。规则按从上到下的顺序匹配，顶部优先。样例必须能对照这些定义，而不能只罗列一批看起来相似的名字。
正反样例分别承担的作用
正样例应满足：域名中出现你准备写入的关键字，并且业务上允许这条规则的动作生效。文档在后缀规则中给出的 www.google.com、mail.google.com 和 google.com，都含有 google 这一材料，因此在关键字同为 google 时，它们可以作为正样例的起点。正样例的作用是防止规则写完后完全没有命中，也防止把完整域名需求误写成关键字却未察觉。
反样例应满足：业务上不允许命中，即便字符串看起来接近。文档明确指出，后缀 google.com 不匹配 content-google.com。这个名字对后缀是反例，对关键字却是关键试金石：它含有 google，若你的关键字规则也会收下它，就说明范围已经越过后缀边界。反样例的作用是把关键字可能更宽从抽象变成可核对的一条名字。没有反样例，就无法发现误伤。GEOSITE、逻辑规则或 MATCH 也可能截走或放行走样例，准备时应记下它们在列表中的位置。
准备样例的步骤
第一步，写出拟使用的关键字，形态与文档示例一致，例如 DOMAIN-KEYWORD,google,auto。不要把星号、问号写进关键字。那些通配符属于 DOMAIN-WILDCARD，仅支持星号匹配零个或多个字符、问号匹配一个字符，并与配置文件其他地方的 Clash 格式通配符不相同。正则应使用 DOMAIN-REGEX。类型不确定时，先不要制作样例。
第二步，从将会出现的域名中挑出正样例。每条正样例都要用一句话说明它为何含有该关键字。若某条其实要求整段相等，应改标为 DOMAIN 的样例，而不是关键字正样例。若某条其实要求后缀边界，应改标为 DOMAIN-SUFFIX 的样例。
第三步，构造反样例。至少包含一类含有同一关键字、但不是后缀关系的名字，文档中的 content-google.com 就是现成模板。再补一类完全不含关键字的名字，用来确认规则不是无条件命中。若业务还不能接受某些子串偶然相同的域名，把它们全部列入反样例。不要用动作字段代替反例：REJECT 或 DIRECT 只说明命中后做什么。
第四步，把正反样例放到整份 rules 的顺序中阅读。顶部规则优先，因此某条正样例可能先被更上方的 DOMAIN、DOMAIN-SUFFIX、GEOSITE 或 AND、OR、NOT 组合拿走；某条反样例也可能先被其他规则命中，从而表现为关键字没有误伤，其实只是还没轮到。MATCH 匹配所有请求、无需条件，不能当作反样例的安全网。逻辑规则要注意括号。目标 IP 类规则及 no-resolve 与域名样例不是同一套检查。
对照文档判断以及失败后的下一步
判断样例是否合格，依据是文档定义而不是数量多少。正样例必须能用域名关键字匹配解释；反样例必须能指出它为何不该落入该关键字，尤其要能对照后缀例子中的排除项。若正样例需要完整一致，依据指向 DOMAIN；若反样例的核心是后缀边界，依据指向 DOMAIN-SUFFIX。样例与类型对不上，就不应进入写入 rules 的环节。
正样例无一命中时，下一步核对关键字拼写、类型是否误写、是否被上方规则截走。反样例被命中时，下一步缩小为 DOMAIN-SUFFIX 或 DOMAIN，或把精确规则前移，对可列举误伤使用 NOT。正反样例互相矛盾时，说明关键字这个类型选错了，应停止增加样例，先改类型。逻辑组合结果与样例不符时检查括号。对象实际是 IP、端口或进程时，改用 IP-CIDR、DST-PORT、PROCESS-NAME 等，不要继续堆域名样例。仍无法收敛则回到是否使用 DOMAIN-KEYWORD。
本文只说明怎样准备正反样例检查关键词规则。语义以路由规则手册为准。