适用条件：样例必须能打在官方 payload 上
为逻辑规则准备匹配与不匹配样例，是为了在写入 rules 之前分清：哪些请求应由这一条命中并采用行末出站，哪些应跳过并交给后续规则。适用条件是：规则已写成 LOGIC_TYPE,((payload1),(payload2)),Proxy；每个 payload 都能对应手册中的类型与载荷；优先使用该页已经出现的例子作为种子，例如域名 baidu.com、网络 UDP 或 tcp。样例只服务语法与真值判断。手册未定义的字段不要编进样例。整份列表仍按从上到下匹配，因此还要预留“会被上方规则先截获”的对照，而不能假定逻辑条一定会被执行到。
具体操作：按三种逻辑分别准备正反例
对 AND,((DOMAIN,baidu.com),(NETWORK,UDP)),DIRECT，匹配样例必须同时满足完整域名等于 baidu.com 且网络为 udp。不匹配样例至少准备两类：域名正确但网络为 tcp；网络为 udp 但完整域名不同。不要只用“两个条件都错”一种反例，否则看不出是哪一个原子失败。若把域名原子改成 DOMAIN-SUFFIX，正反例要改用手册对后缀的说明：以 google.com 为例，www.google.com、mail.google.com 和 google.com 属于匹配侧，content-google.com 属于不匹配侧。
对 OR,((NETWORK,UDP),(DOMAIN,baidu.com)),REJECT，匹配样例应覆盖三种：仅 UDP、仅该完整域名、两者同时成立。不匹配样例必须让两个原子都为假，例如 tcp 且域名不是 baidu.com。如果只准备“两者都成立”的匹配样例，无法发现误把 OR 写成 AND。
对 NOT,((DOMAIN,baidu.com)),PROXY，匹配样例是完整域名不是 baidu.com 的请求；不匹配样例是完整域名恰好为 baidu.com。不匹配表示本条不采用 PROXY，请求继续向下，可能被其他规则或最后的 MATCH 处理。MATCH 无需条件、匹配所有剩余请求，不要为它准备不匹配样例。
SUB-RULE,(NETWORK,tcp),sub-rule 的匹配样例是 tcp，不匹配是 udp。若 payload 是 IP-CIDR 且带 no-resolve，除地址是否落在网段内，还要区分两种背景：尚未因本条触发 DNS 解析；以及更早规则已经解析。手册指出，后一种情况下带 no-resolve 的目标 IP 规则依旧可能被匹配到。通配类简单规则则按 * 匹配零个或多个字符、? 匹配一个字符来构造，并记住其与配置其他处 Clash 格式通配符不相同。
判断样例是否充分以及失败时下一步
判断依据：每条逻辑规则都有匹配组与不匹配组；AND 的不匹配能单独打破其中一个条件；OR 的不匹配能同时打破全部条件；NOT 的不匹配正好落在被否定的条件上；样例字段均可在手册类型中找到。
失败时下一步：真实请求与样例结论冲突时，先把它当作优先级对照，检查上方是否已有 DOMAIN、GEOSITE、RULE-SET 等先命中。UDP 匹配样例未停在本行出站时，核对手册关于节点无 UDP 支持会继续向下匹配的说明，而不是增加无依据的字段。样例无法代入规则时，通常是括号或类型名偏离示例，应先改回 AND/OR/NOT 的官方写法，再重新生成正反例。RULE-SET 作为 payload 时，样例不能替代是否已配置 rule-providers 这一前提。