业务语意的审查

[MENGMUZI]

想跟大佬探讨一下AICR中关于业务语意部分的审查，目前OCR的设计思路是啥，目前看着更多的代码规范类的审查

[lizhengfeng101]

感谢关注和提问！这是一个很好的问题，分享一下 OCR 当前在这方面的设计思路。

OCR 的定位和设计哲学

OCR 目前的核心定位是通用的代码审查工具，而非特定业务领域的审查工具。在设计上，我们有意将「代码层面的通用审查能力」和「业务语意的领域审查能力」做了分层解耦：

1. 内置规则（System Rules）

OCR 内置了一套通用审查规则，覆盖正确性（逻辑错误、边界条件）、安全性（SQL 注入、XSS）、性能（N+1 查询）、可维护性、线程安全等维度。这些是代码层面的通用问题，不依赖业务上下文。

2. 需求背景注入（--background / -b）

OCR 支持通过 --background 参数传入业务需求描述，这段文本会作为 Requirement Background 注入到审查 prompt 中，帮助 LLM 理解代码变更的业务意图。例如：

ocr review -b "本次变更是为了支持用户批量导出订单，需要注意分页查询的性能和数据一致性"

当指定 --commit 时，如果未提供 --background，OCR 会自动使用 commit message 作为需求背景。

3. 自定义规则（--rule / .opencodereview/rule.json）

这是 OCR 为业务语意审查提供的核心扩展机制。团队可以在项目根目录创建 .opencodereview/rule.json，按文件路径模式配置自定义审查规则，也支持通过 merge_system_rule 将自定义规则与系统规则合并。规则内容可以是内联文本，也可以引用 .md 文件。例如：

{
  "rules": [
    {
      "path": "**/service/**/*.java",
      "rule": "检查所有数据库操作是否在事务中执行；检查金额计算是否使用 BigDecimal",
      "merge_system_rule": true
    }
  ]
}

这样就可以将业务领域的审查要求（如金融场景的金额精度、电商场景的库存一致性等）注入到审查流程中。

为什么不直接内置「业务语意审查」

纯粹的业务语意审查本质上需要理解业务上下文——需求文档、产品设计、领域模型等，这些信息因团队和项目而异，无法用通用规则覆盖。OCR 选择的方案是提供机制而非策略：通过 --background、--rule 和 .opencodereview/rule.json 将业务上下文的注入权交给用户和团队，而不是试图内置某种业务理解能力。

后续方向

我们也在持续思考如何更好地支持业务语意审查，比如和需求管理系统（Jira、Linear 等）的集成，自动拉取关联需求的描述作为审查背景。如果你有具体的场景或想法，欢迎继续讨论！