Surge 规则写到后期，难点通常不在“能不能匹配”，而在“还能不能维护”。一份规则如果长期叠加例外、临时补丁和重复域名，最后很容易变成只敢追加、不敢整理的配置。

我的目标是把规则维护当成一个小型工程来处理。

规则先分层

规则不应该只按来源堆在一起，而应该按职责分层：

• 基础直连：局域网、国内常见服务、运营商相关域名
• 代理分流：需要稳定走代理的服务、区域限定服务
• 广告与追踪：需要拦截或单独处理的域名
• 临时例外：带有过期时间或复查说明的规则

分层的好处是定位问题更快。一次命中异常时，可以先判断它属于哪一层，而不是从几千行规则里盲找。

命名要能说明意图

规则文件、策略组和注释都应该说明维护意图。例如 streaming-global 比 proxy2 更容易让半年后的自己看懂；temp-direct-for-bank-app-2026-05 比 fix 更适合作为临时例外。

命名不是装饰，它是维护成本的一部分。

每次变更都要可回退

规则维护最怕“改完好像能用”。更稳的方式是把每次调整拆成小变更，并记录：

• 为什么新增或删除这条规则
• 影响的 App、域名或策略组
• 是否需要同步到 Quantumult X
• 是否需要一周后复查

Git 对配置文件非常友好。只要规则是文本文件，就可以通过 diff 看见每次变更的真实范围。

后续计划

后面我会把 Surge 和 Quantumult X 的规则维护拆成更多具体文章，包括命名约定、规则转换、策略组拆分、测试方式和常见误判排查。