自定义的rules 规则 可以合并么？

[Susanping]

{
"rules": [
{
"path": "AA.js",
"rule": "AA.md"
},
{
"path": "AA.js",
"rule": "BB.md"
}
]
}
可以针对同一个文件合并 分别定义的规则AA.md + BB.md 么？ 想把规则文件分开写，感觉文件分开写 比较清晰。 不想把适用于AA.js 的规则 都写入在一个文件里，感觉很庞大。目前好像是相同文件匹配到多条规则时，只取第一条

[hwbest]

我们遇到了同样的需求，而且是更极端的情况，想补充一下实际场景。

我们的使用场景（Android 代码评审）, review 规则通常分为三层：

1. 通用规则：空指针检查、空安全、命名规范、日志规范等，跨语言适用
2. 语言规则：Kotlin/Java 特有的规范，如协程使用、Android 生命周期管理、Java 互操作等
3. 领域规则：业务层约束，如 Repository 层架构规范、API 调用约定、数据层设计模式等

一个典型的 Android 文件（如 UserRepository.kt）需要同时满足这三层规则。

---

现有设计根本做不到

当前 ocr 的 first-match-wins 机制决定了一个文件只能命中一条规则。这意味着：

{
"rules": [
{ "path": "/*.kt", "rule": "kotlin.md" },
{ "path": "/repository/**", "rule": "domain.md" }
]
}

当 UserRepository.kt 参与评审时：

• 若 *.kt 排在前面 → 只命中 Kotlin 语言规则，领域规则被丢弃
• 若 /repository/ 排在前面 → 只命中领域规则，语言规则被丢弃

任意两层规则都无法同时生效，更别说三层了。
所以不只是"通用规则没有地方合并"——语言规则和领域规则也只能揉进同一个 .md 文件。规则稍有变动就要改 N 份文件，维护成本非常高。

---

建议方案：rule 字段支持引用多个文件

把 rule 从单文件路径扩展为文件列表，按顺序拼接内容：

{
"rules": [
{
"path": "**/*.kt",
"rule": [
"rules/common.md",
"rules/kotlin.md",
"rules/android_domain.md"
]
}
]
}

为什么这个方案好

1. 兼容现有设计：单字符串配置完全不变；遇到数组则按顺序读取并拼接，中间插入分隔线
2. 改动面极小：只需要在 resolveRuleEntries 里扩展 rule 字段的解析逻辑
3. 解决多层规则叠加：不只是通用规则，语言和领域规则也可以独立维护、自由组合

---

希望维护者可以考虑这个需求，这应该是一个很轻量但收益很高的改动。感谢！

[lizhengfeng101]

@Susanping @hwbest 感谢反馈，这个建议很好，下周我们优先支持

[hwbest]

补充建议哈:
如果支持多个md合并, 关联的地方可能也要修改, 比如:
ocr rules check

[hwbest]

@lizhengfeng101

请问这个需求支持的计划是什么?

谢谢

[lizhengfeng101]

@lizhengfeng101

请问这个需求支持的计划是什么?

谢谢

抱歉，目前团队在解决一些内部事情，这个需求还没有开始做，欢迎你提个 issue 或者 pr

[nofacer]

我们也挺需要这个feature的，提了个issue #1132

[hwbest]

我看了一下你的票号, 你的需求和当前票的需求不完全一样.

另外, 我本地AI Coding已经完成这个功能了, 目前还在做一些测试和回归, 如果官方到时候依然没有支持的话, 可能会提PR上来申请Review

[hwbest]

Created issue and PR, see below:
Issue: #1177
PR: #1178

Thanks

[hwbest]

更新一下这个讨论的最终结果,方便关注此需求的同学有个交代。

我按本讨论里的方案实现了 rule: string | []string(数组按序合并多份用户 md),提了 issue #1177 和 PR #1178。维护者 @lizhengfeng101 已回复:实现本身(代码、测试、双语文档、单值字节兼容)被肯定,但因产品方向决定不予内置,PR 未合并、issue 已关闭(not_planned)。完整理由见 #1177。

维护者 @lizhengfeng101 给出的核心理由:

1. 配置层做选择,不做构造。rule.json 映射 path → rule 是选择;把多个用户文件拼成一个规则体属于构造,应归到生成规则的那个流程,而不是解析层。
2. 高 fan-in、无可归因、无回归基线。一旦 common.md 被多个 entry 引用,改一行会静默、全局、概率性地影响所有消费方的实际 prompt——既无可读的 diff,也无回归测试(模型输出不确定)。在没有 comment→规则归因之前,重复(duplication)反而是限制爆炸半径的东西。
3. 外部构建期生成严格更优。在 Makefile / pre-commit / CI 里加一步把分层源文件拼成一个已提交的"有效规则文件",能做数组能做的一切,外加去重、按分支/环境条件包含、模板变量等;且输出是已提交产物,改动以 diff 形式在 code review 里可读,可观测性比数组严格更高。

维护者 @lizhengfeng101 同时给了两条出路:

• 非内置路径:愿意接受把这套作为文档化模式放进 examples/rule_composition/(合成脚本 + 布局约定 + ocr rules check 验证说明 + 失败模式提示),但需先在讨论里对齐放置与范围,再动手。
• 何时会重新考虑内置:等 OCR 具备 comment → rule 归因(每条 review comment 携带触发它的规则段落),不可观测性问题基本消失后,内置构造才更站得住脚——这也是他们认为无论如何都更值得建的前置能力。

所以短期内 rule.json 不会支持数组形态。有同样需求的同学,目前可行的替代是上面第 3 点的构建期生成一个已提交的有效规则 md(单值 rule 指向它),用 ocr rules check 验证最终正文——这项能力现在就有,只是文档不足。

---

补充:在另一个相关讨论 #999 里,维护者 @lizhengfeng101 此前给过几个当前版本下立即可用的 workaround,一并贴出来供大家参考(完整版见 #999):

1. 合并 rule 文本,按 path 归类 —— 把适用同一 path 的规则合并进一个 entry 的 rule 字段(或引用一个较长的 .md 文件,上限 512KB),用 markdown 章节组织安全/性能/规范等类别。维护者提醒:规则条数越多越会稀释模型对每条规则的关注,经验上单个文件 10–15 条以内较稳,超出的可拆给方案 2 分轮。
2. 多轮审查 + --rule 覆盖 —— 对同一组变更执行多次 ocr review,每次用 --rule 指定不同规则文件(--rule 是 layer 1,完全覆盖 project/global/system);每轮只关注一个维度,可在 CI 里并行。
3. Delegation Mode —— 用 ocr delegate preview 取文件列表、ocr delegate rule 取规则分组,在 host agent 侧自行组合多维度规则并审查,组合逻辑不受 first-match-wins 约束。

另外 @lizhengfeng101 强调:first-match-wins 并非技术限制,而是设计倡导——鼓励按作用域拆分规则,让每个文件只命中真正相关的规则集,以控制单次审查的规则条数、避免模型注意力稀释。上百条规则通常不必全部作用于每个文件(安全规则偏 API/网络层、性能规则偏数据处理层、规范规则可按语言拆),合理用 path glob 做作用域划分,自然能把单文件命中条数控制在有效范围内。

我会持续关注 examples/ 方案和 comment→rule 归因的进展。