自定义规则每次都会发给llm吗？

[MaNongProgrammer]

我的自定义规则比较多，我想请问一下，ocr每次都会将rules发送给llm吗？这块的具体架构是怎样的，另外我想将soanr的规则应用到ocr中，大家是否有好的建议

[basil-k-aji-dev]

按代码捋了一遍，分三部分回答。

1. 不是「每次把所有 rules 都发给 LLM」——每个文件只会解析出一条规则正文

规则解析是 first-match-wins，四层链 --rule > 项目 .opencodereview/rule.json > 全局 ~/.opencodereview/rule.json > 内置 system_rules.json：

• composedResolver.Resolve（internal/config/rules/system_rules.go:447）按层遍历，第一个 glob 命中的 entry 直接 return，后面的层和后面的条目完全不参与。
• 系统层内部同样是 first-match-wins（resolveDetail，同文件 166-177 行），一条都没命中才落到 DefaultRule。

所以「自定义规则比较多」这件事本身不会让 prompt 变大。rules 数组里写了 50 条，某个 .java 文件最终注入的仍然只有命中的那 1 条的 rule 正文。真正影响 token 的是单条命中规则写得有多长，不是你写了多少条。

这里有个容易踩的坑：同一个 glob 下堆多条 entry 是没用的，命中第一条之后其余的不会被拼接。

2. 注入时机：按「分组」注入，不是全局一次

resolveGroupSystemRule（internal/agent/agent.go:1664）对组里每个文件调一次 Resolve，然后把规则正文相同的文件合并成一个块：只有一个块时裸输出；跨多个规则集时才用 <rules for="a.go, b.go"> 标出归属，避免模型拿到 Go 清单紧接着 XML 清单却不知道哪条管哪个文件。

它填的是 {{system_rule}} 占位符，位置在用户消息里（internal/config/template/prompts/plan_task_user.md:14 和 main_task_user.md:17），plan 阶段和 main 阶段各注入一次。

至于「每次都会发吗」——如果指的是同一个子任务内工具循环的每一轮：是的，会重发。规则在消息历史里，而 LLM API 是无状态的，每轮请求都要把完整消息数组再传一遍，这是协议决定的。缓解手段是 provider 的 prompt 前缀缓存，resolveGroupSystemRule 里专门把 diffs 按路径排序就是为了这个（agent.go:1669-1672 的注释：grouping LLM 返回的顺序每次都不一样，不排序会 churn "the prompt prefix that provider caches reuse"）。

粗略的成本模型：规则长度 × 分组数 × 每组轮数。

3. 关于把 Sonar 规则搬进来

可以搬，但有两点建议：

技术上——把同一类文件的多条 Sonar 规则折叠进一条 rule 正文，别指望用多条 entry 叠加（原因见上）。想保留内置的语言规则就在 entry 上加 merge_system_rule: true（system_rules.go:209、450），这样是系统规则 + 你的规则合并，而不是整个替换。写完用 ocr rules check <file-path> 逐个确认某个文件最终命中的是哪一层的哪条规则，避免写了没生效。

策略上——说句可能不太中听的：Sonar 里那些确定性的规则（空指针、资源未关闭、圈复杂度阈值、重复代码率……）建议继续留给 Sonar 跑。Sonar 是确定性的程序执行，LLM 是概率性的，把这类规则搬到 LLM 上是降级而不是升级。

真正值得搬进 OCR 的是 Sonar 查不了的那部分：跨文件的契约一致性、业务语义、「这个改动和同一次提交里的另一个文件对不上」这类需要理解意图的问题。

@lizhengfeng101 在 #243 里也提到过规则越精炼遵循率越好——几百条 Sonar 规则全量搬过来，反而会把真正想强调的维度稀释掉。两个工具并行跑、各管各擅长的部分，效果会比合并成一个好。

---

以上基于 3bce7ad。@lizhengfeng101 麻烦看下第 2 部分（注入时机和缓存那块）有没有说错的地方。