open-code-review 的 JSON 文件审查规则面向 JSON 键名拼写的精准静态检查【免费下载链接】open-code-reviewFast, efficient, battle-tested at Alibabas scale. Hybrid architecture code review tool: deterministic pipelines LLM Agent, precise line-level comments, built-in multi-language ruleset (NPE, thread-safety, XSS, SQL injection), OpenAI Anthropic compatible.项目地址: https://gitcode.com/GitHub_Trending/op/open-code-reviewJSON 是配置文件、接口协议、前端国际化资源与构建清单中最常见的载体但通用代码审查提示词往往把大量 token 浪费在键值本身的内容上。本篇文章聚焦 open-code-review下称 OCR内置规则集中针对 JSON 文件的专项规则 —— json.md —— 讲解它的核心语义、触发机制、源码实现、调试方法与自定义覆盖方式。读完你将掌握如何理解 OCR 对.json/.json5文件的默认审查行为如何用ocr rules check验证命中规则以及如何通过项目级规则文件让 JSON 键名的审查策略贴合自身业务。一条极其克制的规则只查键不查值OCR 内置的 JSON 审查规则全文只有一句话Check JSON files for spelling errors in json-keys; ignore the content of json-values. 检查 JSON 文件 json-key 中的拼写错误忽略 json-value 的内容。这句少即是多的规则背后是 OCR 审查哲学的直接体现。对比同目录下的 default.md覆盖正确性、安全性、性能、可维护性与测试覆盖五类通用问题和 go.md对 Go 代码的错误处理、并发、资源生命周期等展开详尽检查JSON 文件既不是可执行代码也不存在线程安全或内存泄漏问题真正值得被 LLM 关注的核心风险点是键名拼写错误maxRetryCount写成maxRetrayCount、backgroundColor写成backgroudColor这类错误不会触发编译失败或运行时异常却会导致配置静默失效、字段无法被消费方解析属于典型的难发现、代价高的缺陷键名不一致同一份 JSON 中相同语义的字段出现大小写、驼峰/下划线混用忽略值内容明确指示模型不要对 value 展开审查 —— 因为 value 可能是任意业务数据如 i18n 文案、数值参数、第三方数据对其进行语法正确性之外的审查既浪费 token 又容易产生误报。这也与 go.md 开头强调的 Favor precision over recall宁缺毋滥、优先精度原则一脉相承规则设计上主动收窄审查面把有限的模型注意力集中在 JSON 中最容易出错、且确定性工具难以覆盖的键名拼写上。规则如何被触发路径映射与 glob 展开JSON 规则并不对所有文件生效而是通过 system_rules.json 中的路径映射按需命中。该文件中的关键条目为{ default_rule: default.md, path_rule_map: { **/*.{json,json5}: json.md } }即任何路径匹配**/*.{json,json5}glob 的文件都会使用 json.md 作为审查规则。这个映射的解析逻辑位于 system_rules.go文件通过 Go 的embed机制//go:embed system_rules.json rule_docs/*见 system_rules.go直接编译进二进制因此系统内置规则层始终存在无需额外下载resolveDetail对每个路径执行first match wins首个匹配生效的顺序匹配system_rules.json 中靠前的模式优先带花括号的模式*.{json,json5}会被 expandBraces 展开为*.json与*.json5两个独立模式逐一匹配匹配基于bmatcuk/doublestar/v4库支持**跨目录递归匹配且大小写不敏感路径与模式都会先ToLower见 system_rules.go。值得注意的细节是path_rule_map中还有其他与 JSON 强相关的更早条目例如**/package.json→package_json.mdNPM 依赖与脚本审查、**/composer.json→composer_json.mdComposer 依赖审查。由于first match wins这些更具体的路径模式排在**/*.{json,json5}之前因此package.json会命中更专业的 package_json.md检查latest/*版本号、dependencies与devDependencies重复声明、scripts 中使用了未声明的工具依赖等而其他普通 JSON 文件才落到 json.md。这是理解 JSON 家族规则命中顺序的关键。ocr scan场景下supported_file_types.json 明确将.json5列入允许的文件类型与路径规则形成一致支持。规则解析的源码级原理系统规则的加载与解析全部封装在 system_rules.go 的LoadDefault()中L93-L115读取内嵌的system_rules.json用json.DecoderUseNumber以流式方式保留path_rule_map的键声明顺序自定义UnmarshalJSON见 L39-L87从而保证首个匹配生效的语义可复现将default_rule与每个路径规则对应的rule_docs/*.md文件内容读入内存作为该规则的最终规则文本。解析完成后Resolver接口的Resolve(path)对任意文件路径返回一条规则文本。这个规则文本随后被注入到 LLM 提示词模板的{{system_rule}}占位符中 —— 具体位于 plan_task_user.md 与 main_task_user.md。也就是说当审查到一个config.json时模型实际收到的系统规则指令就是那句检查键名拼写、忽略值内容。此外整个规则集还会通过CanonicalConfig()system_rules.go生成确定性的配置指纹参与运行清单manifest中rule_config_sha256的计算 —— 这意味着修改任何rule_docs/*.md文件都会改变审查会话的可复现标识。四层优先级系统规则只是兜底json.md 属于系统内置层优先级最低实际生效的规则由四层优先级链决定见 review-rules.md优先级来源位置1最高--rule命令行参数用户临时指定总是优先2项目级配置repo/.opencodereview/rule.json3全局配置~/.opencodereview/rule.json4最低系统内置编译进二进制的system_rules.json层级解析逻辑实现在 system_rules.go 的NewResolver与composedResolver.ResolveL447-L457中自定义 项目 全局依次尝试每层内部按声明顺序首个匹配生效前两层都没有命中时才回落到系统层。用户层命中后默认完全替换系统规则除非条目设置了merge_system_rule: true此时系统规则与用户规则会合并成一份带分节的组合提示见 mergeWithSystemRule。项目级 JSON 规则示例保存为repo/.opencodereview/rule.json并提交{ rules: [ { path: **/i18n/*.json, rule: Check JSON keys for spelling errors and naming consistency; ensure all keys use lowerCamelCase and that the same key set is used across locale files. Ignore json-value content. } ] }merge_system_rule用法{ rules: [ { path: **/*.json, rule: Additionally verify that no duplicate keys exist after JSON parsing., merge_system_rule: true } ] }验证与调试ocr rules check当不确定某个 JSON 文件到底命中哪条规则时使用 rules_cmd.go 提供的ocr rules check命令ocr rules check config/app.json输出示例File: config/app.json Source: System built-in Pattern: **/*.{json,json5} Rule: ──────────────────────────────────────── Check JSON files for spelling errors in json-keys; ignore the content of json-values. ────────────────────────────────────────该命令会显示命中的来源层Source、**匹配的 glob 模式Pattern**以及最终生效的规则文本若通过内容嗅探选定规则还会额外输出Note行。使用--rule指定自定义规则文件时同理ocr rules check --rule custom.json config/app.json对应源码中runRulesCheckrules_cmd.go调用ResolveDetail并输出明细是排查规则没按预期生效的首选工具。相关测试覆盖可参考 system_rules_test.go其中包含对entry/src/main/module.json5、entry/oh-package.json5等路径命中 json 规则的断言。相关内置规则一览围绕 JSON 生态OCR 在 system_rules.json 中提供了多条相互配合的规则理解它们的边界有助于准确预判审查行为路径模式规则文档审查重点**/*.{json,json5}json.md通用 JSON 键名拼写**/package.jsonpackage_json.md依赖版本、重复声明、scripts 工具依赖缺失**/composer.jsoncomposer_json.mdComposer 依赖、autoload、scripts、插件配置**/*.jsonnet/**/*.libsonnetjsonnet.mdJsonnet 配置模板**/*.{yaml,yml}yaml.mdYAML 配置文件优先级顺序以 system_rules.json 中的声明顺序为准package.json/composer.json等专有模式永远优先于通用 JSON 模式命中。小结OCR 对 JSON 文件的默认审查策略可以总结为三个要点范围聚焦只查 json-key 拼写、忽略 json-value、路径驱动**/*.{json,json5}映射 首匹配生效 大小写不敏感 glob、可观测可覆盖ocr rules check验证命中四层优先级链允许按项目覆盖。对于以 JSON 为核心资产国际化资源、配置清单、接口 schema的仓库建议结合merge_system_rule与项目级 rule.json在系统规则之上补充键名一致性、必填键校验等业务化约束从而把模型注意力精准投向 JSON 中最值得人工把关的部分。【免费下载链接】open-code-reviewFast, efficient, battle-tested at Alibabas scale. Hybrid architecture code review tool: deterministic pipelines LLM Agent, precise line-level comments, built-in multi-language ruleset (NPE, thread-safety, XSS, SQL injection), OpenAI Anthropic compatible.项目地址: https://gitcode.com/GitHub_Trending/op/open-code-review创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
open-code-review 的 JSON 文件审查规则：面向 JSON 键名拼写的精准静态检查
open-code-review 的 JSON 文件审查规则面向 JSON 键名拼写的精准静态检查【免费下载链接】open-code-reviewFast, efficient, battle-tested at Alibabas scale. Hybrid architecture code review tool: deterministic pipelines LLM Agent, precise line-level comments, built-in multi-language ruleset (NPE, thread-safety, XSS, SQL injection), OpenAI Anthropic compatible.项目地址: https://gitcode.com/GitHub_Trending/op/open-code-reviewJSON 是配置文件、接口协议、前端国际化资源与构建清单中最常见的载体但通用代码审查提示词往往把大量 token 浪费在键值本身的内容上。本篇文章聚焦 open-code-review下称 OCR内置规则集中针对 JSON 文件的专项规则 —— json.md —— 讲解它的核心语义、触发机制、源码实现、调试方法与自定义覆盖方式。读完你将掌握如何理解 OCR 对.json/.json5文件的默认审查行为如何用ocr rules check验证命中规则以及如何通过项目级规则文件让 JSON 键名的审查策略贴合自身业务。一条极其克制的规则只查键不查值OCR 内置的 JSON 审查规则全文只有一句话Check JSON files for spelling errors in json-keys; ignore the content of json-values. 检查 JSON 文件 json-key 中的拼写错误忽略 json-value 的内容。这句少即是多的规则背后是 OCR 审查哲学的直接体现。对比同目录下的 default.md覆盖正确性、安全性、性能、可维护性与测试覆盖五类通用问题和 go.md对 Go 代码的错误处理、并发、资源生命周期等展开详尽检查JSON 文件既不是可执行代码也不存在线程安全或内存泄漏问题真正值得被 LLM 关注的核心风险点是键名拼写错误maxRetryCount写成maxRetrayCount、backgroundColor写成backgroudColor这类错误不会触发编译失败或运行时异常却会导致配置静默失效、字段无法被消费方解析属于典型的难发现、代价高的缺陷键名不一致同一份 JSON 中相同语义的字段出现大小写、驼峰/下划线混用忽略值内容明确指示模型不要对 value 展开审查 —— 因为 value 可能是任意业务数据如 i18n 文案、数值参数、第三方数据对其进行语法正确性之外的审查既浪费 token 又容易产生误报。这也与 go.md 开头强调的 Favor precision over recall宁缺毋滥、优先精度原则一脉相承规则设计上主动收窄审查面把有限的模型注意力集中在 JSON 中最容易出错、且确定性工具难以覆盖的键名拼写上。规则如何被触发路径映射与 glob 展开JSON 规则并不对所有文件生效而是通过 system_rules.json 中的路径映射按需命中。该文件中的关键条目为{ default_rule: default.md, path_rule_map: { **/*.{json,json5}: json.md } }即任何路径匹配**/*.{json,json5}glob 的文件都会使用 json.md 作为审查规则。这个映射的解析逻辑位于 system_rules.go文件通过 Go 的embed机制//go:embed system_rules.json rule_docs/*见 system_rules.go直接编译进二进制因此系统内置规则层始终存在无需额外下载resolveDetail对每个路径执行first match wins首个匹配生效的顺序匹配system_rules.json 中靠前的模式优先带花括号的模式*.{json,json5}会被 expandBraces 展开为*.json与*.json5两个独立模式逐一匹配匹配基于bmatcuk/doublestar/v4库支持**跨目录递归匹配且大小写不敏感路径与模式都会先ToLower见 system_rules.go。值得注意的细节是path_rule_map中还有其他与 JSON 强相关的更早条目例如**/package.json→package_json.mdNPM 依赖与脚本审查、**/composer.json→composer_json.mdComposer 依赖审查。由于first match wins这些更具体的路径模式排在**/*.{json,json5}之前因此package.json会命中更专业的 package_json.md检查latest/*版本号、dependencies与devDependencies重复声明、scripts 中使用了未声明的工具依赖等而其他普通 JSON 文件才落到 json.md。这是理解 JSON 家族规则命中顺序的关键。ocr scan场景下supported_file_types.json 明确将.json5列入允许的文件类型与路径规则形成一致支持。规则解析的源码级原理系统规则的加载与解析全部封装在 system_rules.go 的LoadDefault()中L93-L115读取内嵌的system_rules.json用json.DecoderUseNumber以流式方式保留path_rule_map的键声明顺序自定义UnmarshalJSON见 L39-L87从而保证首个匹配生效的语义可复现将default_rule与每个路径规则对应的rule_docs/*.md文件内容读入内存作为该规则的最终规则文本。解析完成后Resolver接口的Resolve(path)对任意文件路径返回一条规则文本。这个规则文本随后被注入到 LLM 提示词模板的{{system_rule}}占位符中 —— 具体位于 plan_task_user.md 与 main_task_user.md。也就是说当审查到一个config.json时模型实际收到的系统规则指令就是那句检查键名拼写、忽略值内容。此外整个规则集还会通过CanonicalConfig()system_rules.go生成确定性的配置指纹参与运行清单manifest中rule_config_sha256的计算 —— 这意味着修改任何rule_docs/*.md文件都会改变审查会话的可复现标识。四层优先级系统规则只是兜底json.md 属于系统内置层优先级最低实际生效的规则由四层优先级链决定见 review-rules.md优先级来源位置1最高--rule命令行参数用户临时指定总是优先2项目级配置repo/.opencodereview/rule.json3全局配置~/.opencodereview/rule.json4最低系统内置编译进二进制的system_rules.json层级解析逻辑实现在 system_rules.go 的NewResolver与composedResolver.ResolveL447-L457中自定义 项目 全局依次尝试每层内部按声明顺序首个匹配生效前两层都没有命中时才回落到系统层。用户层命中后默认完全替换系统规则除非条目设置了merge_system_rule: true此时系统规则与用户规则会合并成一份带分节的组合提示见 mergeWithSystemRule。项目级 JSON 规则示例保存为repo/.opencodereview/rule.json并提交{ rules: [ { path: **/i18n/*.json, rule: Check JSON keys for spelling errors and naming consistency; ensure all keys use lowerCamelCase and that the same key set is used across locale files. Ignore json-value content. } ] }merge_system_rule用法{ rules: [ { path: **/*.json, rule: Additionally verify that no duplicate keys exist after JSON parsing., merge_system_rule: true } ] }验证与调试ocr rules check当不确定某个 JSON 文件到底命中哪条规则时使用 rules_cmd.go 提供的ocr rules check命令ocr rules check config/app.json输出示例File: config/app.json Source: System built-in Pattern: **/*.{json,json5} Rule: ──────────────────────────────────────── Check JSON files for spelling errors in json-keys; ignore the content of json-values. ────────────────────────────────────────该命令会显示命中的来源层Source、**匹配的 glob 模式Pattern**以及最终生效的规则文本若通过内容嗅探选定规则还会额外输出Note行。使用--rule指定自定义规则文件时同理ocr rules check --rule custom.json config/app.json对应源码中runRulesCheckrules_cmd.go调用ResolveDetail并输出明细是排查规则没按预期生效的首选工具。相关测试覆盖可参考 system_rules_test.go其中包含对entry/src/main/module.json5、entry/oh-package.json5等路径命中 json 规则的断言。相关内置规则一览围绕 JSON 生态OCR 在 system_rules.json 中提供了多条相互配合的规则理解它们的边界有助于准确预判审查行为路径模式规则文档审查重点**/*.{json,json5}json.md通用 JSON 键名拼写**/package.jsonpackage_json.md依赖版本、重复声明、scripts 工具依赖缺失**/composer.jsoncomposer_json.mdComposer 依赖、autoload、scripts、插件配置**/*.jsonnet/**/*.libsonnetjsonnet.mdJsonnet 配置模板**/*.{yaml,yml}yaml.mdYAML 配置文件优先级顺序以 system_rules.json 中的声明顺序为准package.json/composer.json等专有模式永远优先于通用 JSON 模式命中。小结OCR 对 JSON 文件的默认审查策略可以总结为三个要点范围聚焦只查 json-key 拼写、忽略 json-value、路径驱动**/*.{json,json5}映射 首匹配生效 大小写不敏感 glob、可观测可覆盖ocr rules check验证命中四层优先级链允许按项目覆盖。对于以 JSON 为核心资产国际化资源、配置清单、接口 schema的仓库建议结合merge_system_rule与项目级 rule.json在系统规则之上补充键名一致性、必填键校验等业务化约束从而把模型注意力精准投向 JSON 中最值得人工把关的部分。【免费下载链接】open-code-reviewFast, efficient, battle-tested at Alibabas scale. Hybrid architecture code review tool: deterministic pipelines LLM Agent, precise line-level comments, built-in multi-language ruleset (NPE, thread-safety, XSS, SQL injection), OpenAI Anthropic compatible.项目地址: https://gitcode.com/GitHub_Trending/op/open-code-review创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
