拓冰网站定制 
open-code-review 内置 Rust 代码审查规则深度解读所有权、unsafe 边界与并发安全的 LLM 审查清单【免费下载链接】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本文围绕 open-code-review 内置的 Rust 语言审查规则文档internal/config/rules/rule_docs/rust.md展开系统梳理该规则在仓库中的定位、十类审查维度的完整条款并结合规则解析源码与ocr rules check调试命令说明如何让 LLM Agent 在 Code Review 中精准识别 Rust 代码的所有权、生命周期、unsafe、并发、宏元编程与安全缺陷。读完本文你将掌握这套内置 Rust 规则的完整内容以及它在四层规则解析链中如何被命中、定制与验证。一、Rust 规则在 open-code-review 规则体系中的位置open-code-review 采用确定性管线 LLM Agent的混合架构其中**规则Review Rules**决定了 LLM 在审查每个文件时重点关注什么。规则按四层优先级解析--rule命令行参数Custom 项目级.opencodereview/rule.jsonProject 全局~/.opencodereview/rule.jsonGlobal 内嵌系统默认规则System。系统层规则始终存在因为它随二进制编译打包//go:embed system_rules.json rule_docs/*见 internal/config/rules/system_rules.go。系统规则由两部分组成路径映射表 internal/config/rules/system_rules.json用 glob 模式把文件路径映射到对应的规则文档规则文档目录 internal/config/rules/rule_docs/每种语言/文件类型一份 Markdownrust.md就是其中之一。Rust 文件的命中规则非常直观**/*.rs: rust.md也就是说任何路径匹配**/*.rs的源文件在通过文件过滤binary / user_exclude / user_include / unsupported_ext / default_path 五道闸门详见 pages/src/content/docs/en/review-rules.md后其规则文本会被解析为rule_docs/rust.md的完整内容注入到 Agent 的 plan 与 main 任务提示词中替换{{system_rule}}占位符。值得注意的是系统规则层还内置了对.m文件的内容嗅探content sniffing.m同时被 MATLAB 与 Objective-C 使用当首行非空内容形如#import、implementation、//、/*时会改用objc.md实现见 internal/config/rules/sniffer.go。Rust 的.rs扩展名不存在歧义直接走路径映射即可无需内容嗅探。二、Rust 审查规则的顶层原则精度优先于召回rust.md开篇即给出一条核心基调只报告变更代码及其可达上下文中很可能真实存在的缺陷宁可漏报轻微问题也不误报——一次误报false positive会消耗审查者的信任。同时正确性与安全问题视为阻塞性blocking缺陷纯风格建议视为非阻塞。对于非局部结论规则要求 Agent 在报告前先调用file_read与code_search工具核实调用点、所有权关系、同步方式与输入边界不得仅凭函数名或包导入就推断并发调用、攻击者控制、资源所有权或错误契约。凡是cargo clippy、rustfmt、rustc编译器或确定性工具已经能可靠判定的问题除非 diff 展示了这些工具无法表达的、用户可见的具体后果否则不应重复报告。这一精度优先的设计哲学并非 Rust 独有对比 internal/config/rules/rule_docs/go.mdFavor precision over recall: report only defects that are likely real与 internal/config/rules/rule_docs/python.mdFavor precision over recall: only raise an issue when you are confident it is a real defect可见它是整个内置规则集的一贯策略——目的是让 LLM 的审查输出聚焦于确定性工具覆盖不到的、真正需要人类判断的缺陷。三、完整条款rust.md 的十类审查维度以下内容完整继承自 internal/config/rules/rule_docs/rust.md并结合 Rust 语言机制逐条给出实现层面的解读。3.1 明显拼写错误Obvious Typos or Spelling Errors类型名、函数名、变量名、枚举变体、trait 名或模块名在声明处的拼写错误不要在调用点报告拼写错误调用点的拼写由声明决定日志消息、panic 消息、错误消息或公开诊断信息中的字符串若含拼写错误且影响可读性。这类问题看似琐碎但公开 API 的拼写错误一旦发布就会成为长期兼容负担因此规则将范围限定在声明处。3.2 所有权与生命周期正确性Ownership and Lifetime Correctness错误的引用返回返回的引用不正确、借用的值逃逸了其有效作用域或生命周期关系使 API 变得不健全unsound或不可用过度 clone为满足借用而引入的多余clone()当借用、迭代器、Cow或所有权转移更清晰、更廉价时应优先使用后者内部可变性滥用用RefCell、Cell、Mutex绕过所有权问题而实际上并不存在真正的共享可变需求引用环RcRefCellT或ArcMutexT构成引用环时应改用Weak打破所有权环。这四条对应 Rust 最常见的所有权实践问题生命周期标注错误、不必要的克隆、为省事而引入的运行时借用检查、以及共享所有权造成的循环引用内存泄漏。3.3 错误处理与 panicError Handling and Panics生产/库代码路径中在失败可恢复或可用Result传播的情况下使用unwrap()、expect()、panic!、todo!、unimplemented!过早字符串化或丢弃错误错误被过早转成字符串或丢失上下文应保留原始错误并在边界处添加可操作上下文忽略返回值Result或Option被忽略、吞掉或映射成误导性的默认值公开 API panic公开 API 对普通非法输入直接 panic而非返回类型化错误除非 panic 有清晰的编程不变式文档。要点是区分程序不变式被破坏时的 panic可接受与可恢复失败被 panic 掩盖应返回Result。3.4 unsafe 代码边界Unsafe Code Boundariesunsafe块范围过大或隐藏了多个互不相关的不变式unsafe块、unsafe fn、unsafe impl Send、unsafe impl Sync缺少或存在过期的 safety 说明safety rationale裸指针解引用未明确有效性、对齐、初始化、别名和生命周期保证FFI 边界未校验空指针、缓冲区长度、所有权转移、字符串编码或分配器兼容性static mut、未检查的transmute、MaybeUninit、mem::zeroed或手动 drop 逻辑缺乏使操作健全的已文档化不变式。unsafe 是 Rust 中风险最集中的地带规则要求每一项 unsafe 操作都有明确的 safety 论证这是将unsafe 的正确性从口头约定变成审查清单。3.5 并发与共享状态Concurrency and Shared State锁粒度过大Mutex、RwLock、RefCell的 guard 持有时间过长尤其是跨用户代码调用或潜在阻塞操作持有async 中持锁在.await上持有同步锁或在 async 任务中直接使用阻塞 I/O、睡眠或 CPU 密集工作check-then-act 竞态共享状态、缓存初始化、文件创建或原子量周围的先检查后执行存在竞态原子序错误原子操作的内存序对受保护数据过弱或过强而掩盖了本应表达的同步契约不健全的 Send/Syncunsafe 实现Send或Sync但无法证明在文档化不变式下所有内部状态是线程安全的。这里特别值得注意在.await上持有同步锁与async 任务内做阻塞 I/O两条——它们是 async Rust 中死锁与事件循环卡死的经典来源也是普通静态检查难以覆盖的运行时语义问题。3.6 异步与取消安全Async and Cancellation Safety生成的JoinHandle被丢弃而失败、取消或关闭仍需要被观察取消不安全的 futurefuture 在部分写入、锁获取、事务或资源清理过程中不具备取消安全性阻塞 API 混用async 函数在请求/worker 路径中使用同步文件系统、网络或进程 API导致运行时被阻塞重试循环无退避、超时、取消传播或尝试次数上限。取消安全cancellation safety是 Rust async 生态特有的核心概念future 被 poll 后若未完成即被丢弃其内部状态可能停留在不一致的中间态规则要求审查者关注这类边界。3.7 集合、迭代器与性能Collections, Iterators, and Performance热路径非必要分配反复构造String、调用format!、collect()或to_vec()而借用或流式处理已足够迭代器适配器优先使用迭代器适配器和标准库集合 API 使所有权与复杂度更清晰避免过密的迭代器链掩盖错误处理或副作用预分配已知预期大小时为 hash map、vector 与 string 预分配容量避免增长开销O(n²) 查找嵌套循环中的 O(n²) 查找若HashMap、HashSet、排序或索引策略能明显降低复杂度则应报告。性能类问题规则强调了热路径前提避免审查者为了微优化而误报无关代码。3.8 类型与 API 设计Type and API Design建模领域状态用枚举、newtype 和类型化 ID 建模领域状态而非布尔值、字符串或原始整数——当非法状态本可以被表达时标准转换/借用 trait设计可复用 API 时优先使用From、TryFrom、AsRef、Borrow、IntoIterator等标准 trait公开项质量公开的 struct、enum、trait 与 error 应在 crate 边界内有合适的名称、可见性、trait derive 与文档抽象泄漏公开 API 中避免暴露具体集合或同步类型而应使用切片、迭代器、trait 或更窄的抽象以保留灵活性。用类型系统让非法状态不可表达make illegal states unrepresentable是 Rust API 设计的标志性理念这组条款正是它的审查落地。3.9 宏与元编程Macros and Metaprogramming宏类条款有明确触发前提只有当 diff 确实定义了macro_rules!或过程宏时才报告普通宏调用不在此列。表达式求值多次$x:expr片段在展开中被插入多次导致调用方表达式及其副作用被执行多次应在展开内先用let绑定一次缺少$crate::前缀导出的或被公开使用的宏引用了不带$crate::的项当宏从其他 crate 调用时名称解析会失败或绑定错误项token-tree 优先级$t:tt片段在未加括号的情况下重新发出运算符优先级可能悄悄改变意图此条仅适用于 token 级tt插值因为:expr片段和整个展开各自被解析为一个完整表达式过程宏错误处理过程宏对畸形输入使用unwrap()、expect()、panic!而不是发出带有效 span 的syn::Error/compile_error!宏卫生性假设生成的标识符依赖调用点作用域中的名称或宏在同一模块中被多次调用时出现项冲突。宏展开是编译期行为问题往往只在特定调用场景下才暴露这组规则为 LLM 提供了明确的检查边界。3.10 安全敏感代码Security-Sensitive Code输入验证路径、URL、命令、SQL 与序列化输入在使用前必须验证不要用未检查的字符串拼接构造 shell 命令或 SQL禁止日志泄密不要记录密钥、令牌、凭据、私钥或可识别个人身份的信息整数与边界检查整数转换、字节切片与长度运算是否存在溢出、截断和 UTF-8 边界错误密码学与鉴权加密、随机数、认证与授权代码必须使用经过充分审查的 crate 并显式处理错误标记临时拼凑的实现。四、源码级验证规则如何被加载与解析规则文本并非直接写死在审查逻辑中而是通过 internal/config/rules/system_rules.go 的嵌入式文件系统加载//go:embed system_rules.json rule_docs/* var rulesFS embed.FS func LoadDefault() (*SystemRule, error) { data, err : rulesFS.ReadFile(system_rules.json) // ... content, err : rulesFS.ReadFile(rule_docs/ rule.DefaultRule) // ... for i : range rule.PathRules { content, err : rulesFS.ReadFile(rule_docs/ rule.PathRules[i].Rule) // ... } }LoadDefault会读取system_rules.json解析出default_rule回退规则即 internal/config/rules/rule_docs/default.md与path_rule_map中按声明顺序排列的路径规则再把每个Rule字段替换成对应rule_docs/*.md的完整内容。路径匹配由resolveDetail完成internal/config/rules/system_rules.go匹配基于bmatcuk/doublestar/v4支持**递归目录匹配匹配前路径与模式均转小写大小写不敏感支持{a,b,c}花括号展开——expandBraces会把*.{go,py}展开为*.go、*.py分别匹配按声明顺序首个匹配优先first match wins全部未命中则回退到default_rule。因此对于src/parser/lexer.rs这样的路径**/*.rs是唯一命中的模式规则文本即为rust.md全文。若用户在项目级rule.json中配置了**/*.rs的定制规则则用户层优先于系统层若设置了merge_system_rule: true则系统规则会以## System-Specific Rules (Mandatory)与## User-Specific Rules (Mandatory)两个小节拼接保留见 internal/config/rules/system_rules.go。另一个值得注意的细节是CanonicalConfig()解析器会把所有层的规则文本、模式与merge标志序列化为确定性的字段列表用于生成运行 manifest 中的rule_config_sha256哈希。也就是说修改rust.md会使运行指纹变化规则变更可被审计与追踪。五、实战用ocr rules check验证 Rust 规则命中ocr rules check子命令用于检查某个文件路径最终命中哪条规则是排查规则行为最直接的调试工具实现见 cmd/opencodereview/rules_cmd.go。ocr rules check src/parser/lexer.rs输出会显示命中的层Source、匹配的 globPattern以及完整规则文本File: src/parser/lexer.rs Source: System built-in Pattern: **/*.rs Rule: ──────────────────────────────────────── …rust.md 全文… ────────────────────────────────────────其底层逻辑是runRulesCheck通过rules.NewResolver(repoDir, rulePath, ResolverOptions{})构建四层解析器断言其实现了DetailResolver接口再调用ResolveDetail(filePath)获取RuleDetail包含Rule、Source、Pattern字段见 internal/config/rules/system_rules.go。rules check对非 git 仓库目录会报错对应测试见 cmd/opencodereview/rules_check_test.go。若你为 Rust 项目配置了定制规则还可以叠加--rule参数调试ocr rules check --rule custom-rust.json src/parser/lexer.rs此时Source会显示Custom (--rule)Pattern为定制规则中命中的 glob——这一信息对确认为什么某条规则生效/不生效非常关键。六、为 Rust 项目定制与扩展规则内置rust.md面向通用 Rust 代码团队可按需覆盖或增强项目级规则在仓库根目录创建.opencodereview/rule.json并提交例如为内部 crate 增加专门的生命周期约定{ rules: [ { path: **/*.rs, rule: 内部 crate 的所有公开函数必须携带文档注释且不得在返回类型中暴露私有类型。 } ] }该层规则将替换系统规则若希望保留内置规则可设置merge_system_rule: true系统 Rust 规则会作为强制小节保留。单次 PR 覆盖ocr review --rule ./security-only.json可绕过项目与全局层适合安全专项审查。全局偏好写入~/.opencodereview/rule.json本机所有仓库生效。需要提醒的是默认路径过滤会排除测试文件**/*_test.rs在 internal/config/allowlist/default_exclude_patterns.json 中如需审查 Rust 测试代码需在include中显式声明如include: [**/*_test.rs]。七、结语从规则文本到可执行的审查契约rust.md不是一份泛泛的代码风格清单而是一份面向 LLM Agent 的、可执行的审查契约它把 Rust 语言最容易被误用、且确定性工具难以覆盖的领域——所有权与生命周期、unsafe 边界、异步取消安全、宏卫生性、并发内存序——逐条编码为精确的缺陷判定标准并以精度优先、证据驱动为总原则约束 Agent 的输出。结合四层规则解析链internal/config/rules/system_rules.go、ocr rules check调试工具与merge_system_rule合并机制团队既可以开箱即用地获得这套语言级审查能力也可以在不牺牲内置规则的前提下叠加自己的工程规范。如果你正在为 Rust 仓库接入 open-code-review建议按以下顺序落地先用ocr review --preview确认文件过滤结果 → 用ocr rules check file.rs验证规则命中 → 视团队规范在.opencodereview/rule.json中定制或合并规则 → 最后在 CI如 GitHub Actions见 examples/github_actions/ocr-review.yml中接入完整审查流程。【免费下载链接】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 内置 Rust 代码审查规则深度解读：所有权、unsafe 边界与并发安全的 LLM 审查清单
open-code-review 内置 Rust 代码审查规则深度解读所有权、unsafe 边界与并发安全的 LLM 审查清单【免费下载链接】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本文围绕 open-code-review 内置的 Rust 语言审查规则文档internal/config/rules/rule_docs/rust.md展开系统梳理该规则在仓库中的定位、十类审查维度的完整条款并结合规则解析源码与ocr rules check调试命令说明如何让 LLM Agent 在 Code Review 中精准识别 Rust 代码的所有权、生命周期、unsafe、并发、宏元编程与安全缺陷。读完本文你将掌握这套内置 Rust 规则的完整内容以及它在四层规则解析链中如何被命中、定制与验证。一、Rust 规则在 open-code-review 规则体系中的位置open-code-review 采用确定性管线 LLM Agent的混合架构其中**规则Review Rules**决定了 LLM 在审查每个文件时重点关注什么。规则按四层优先级解析--rule命令行参数Custom 项目级.opencodereview/rule.jsonProject 全局~/.opencodereview/rule.jsonGlobal 内嵌系统默认规则System。系统层规则始终存在因为它随二进制编译打包//go:embed system_rules.json rule_docs/*见 internal/config/rules/system_rules.go。系统规则由两部分组成路径映射表 internal/config/rules/system_rules.json用 glob 模式把文件路径映射到对应的规则文档规则文档目录 internal/config/rules/rule_docs/每种语言/文件类型一份 Markdownrust.md就是其中之一。Rust 文件的命中规则非常直观**/*.rs: rust.md也就是说任何路径匹配**/*.rs的源文件在通过文件过滤binary / user_exclude / user_include / unsupported_ext / default_path 五道闸门详见 pages/src/content/docs/en/review-rules.md后其规则文本会被解析为rule_docs/rust.md的完整内容注入到 Agent 的 plan 与 main 任务提示词中替换{{system_rule}}占位符。值得注意的是系统规则层还内置了对.m文件的内容嗅探content sniffing.m同时被 MATLAB 与 Objective-C 使用当首行非空内容形如#import、implementation、//、/*时会改用objc.md实现见 internal/config/rules/sniffer.go。Rust 的.rs扩展名不存在歧义直接走路径映射即可无需内容嗅探。二、Rust 审查规则的顶层原则精度优先于召回rust.md开篇即给出一条核心基调只报告变更代码及其可达上下文中很可能真实存在的缺陷宁可漏报轻微问题也不误报——一次误报false positive会消耗审查者的信任。同时正确性与安全问题视为阻塞性blocking缺陷纯风格建议视为非阻塞。对于非局部结论规则要求 Agent 在报告前先调用file_read与code_search工具核实调用点、所有权关系、同步方式与输入边界不得仅凭函数名或包导入就推断并发调用、攻击者控制、资源所有权或错误契约。凡是cargo clippy、rustfmt、rustc编译器或确定性工具已经能可靠判定的问题除非 diff 展示了这些工具无法表达的、用户可见的具体后果否则不应重复报告。这一精度优先的设计哲学并非 Rust 独有对比 internal/config/rules/rule_docs/go.mdFavor precision over recall: report only defects that are likely real与 internal/config/rules/rule_docs/python.mdFavor precision over recall: only raise an issue when you are confident it is a real defect可见它是整个内置规则集的一贯策略——目的是让 LLM 的审查输出聚焦于确定性工具覆盖不到的、真正需要人类判断的缺陷。三、完整条款rust.md 的十类审查维度以下内容完整继承自 internal/config/rules/rule_docs/rust.md并结合 Rust 语言机制逐条给出实现层面的解读。3.1 明显拼写错误Obvious Typos or Spelling Errors类型名、函数名、变量名、枚举变体、trait 名或模块名在声明处的拼写错误不要在调用点报告拼写错误调用点的拼写由声明决定日志消息、panic 消息、错误消息或公开诊断信息中的字符串若含拼写错误且影响可读性。这类问题看似琐碎但公开 API 的拼写错误一旦发布就会成为长期兼容负担因此规则将范围限定在声明处。3.2 所有权与生命周期正确性Ownership and Lifetime Correctness错误的引用返回返回的引用不正确、借用的值逃逸了其有效作用域或生命周期关系使 API 变得不健全unsound或不可用过度 clone为满足借用而引入的多余clone()当借用、迭代器、Cow或所有权转移更清晰、更廉价时应优先使用后者内部可变性滥用用RefCell、Cell、Mutex绕过所有权问题而实际上并不存在真正的共享可变需求引用环RcRefCellT或ArcMutexT构成引用环时应改用Weak打破所有权环。这四条对应 Rust 最常见的所有权实践问题生命周期标注错误、不必要的克隆、为省事而引入的运行时借用检查、以及共享所有权造成的循环引用内存泄漏。3.3 错误处理与 panicError Handling and Panics生产/库代码路径中在失败可恢复或可用Result传播的情况下使用unwrap()、expect()、panic!、todo!、unimplemented!过早字符串化或丢弃错误错误被过早转成字符串或丢失上下文应保留原始错误并在边界处添加可操作上下文忽略返回值Result或Option被忽略、吞掉或映射成误导性的默认值公开 API panic公开 API 对普通非法输入直接 panic而非返回类型化错误除非 panic 有清晰的编程不变式文档。要点是区分程序不变式被破坏时的 panic可接受与可恢复失败被 panic 掩盖应返回Result。3.4 unsafe 代码边界Unsafe Code Boundariesunsafe块范围过大或隐藏了多个互不相关的不变式unsafe块、unsafe fn、unsafe impl Send、unsafe impl Sync缺少或存在过期的 safety 说明safety rationale裸指针解引用未明确有效性、对齐、初始化、别名和生命周期保证FFI 边界未校验空指针、缓冲区长度、所有权转移、字符串编码或分配器兼容性static mut、未检查的transmute、MaybeUninit、mem::zeroed或手动 drop 逻辑缺乏使操作健全的已文档化不变式。unsafe 是 Rust 中风险最集中的地带规则要求每一项 unsafe 操作都有明确的 safety 论证这是将unsafe 的正确性从口头约定变成审查清单。3.5 并发与共享状态Concurrency and Shared State锁粒度过大Mutex、RwLock、RefCell的 guard 持有时间过长尤其是跨用户代码调用或潜在阻塞操作持有async 中持锁在.await上持有同步锁或在 async 任务中直接使用阻塞 I/O、睡眠或 CPU 密集工作check-then-act 竞态共享状态、缓存初始化、文件创建或原子量周围的先检查后执行存在竞态原子序错误原子操作的内存序对受保护数据过弱或过强而掩盖了本应表达的同步契约不健全的 Send/Syncunsafe 实现Send或Sync但无法证明在文档化不变式下所有内部状态是线程安全的。这里特别值得注意在.await上持有同步锁与async 任务内做阻塞 I/O两条——它们是 async Rust 中死锁与事件循环卡死的经典来源也是普通静态检查难以覆盖的运行时语义问题。3.6 异步与取消安全Async and Cancellation Safety生成的JoinHandle被丢弃而失败、取消或关闭仍需要被观察取消不安全的 futurefuture 在部分写入、锁获取、事务或资源清理过程中不具备取消安全性阻塞 API 混用async 函数在请求/worker 路径中使用同步文件系统、网络或进程 API导致运行时被阻塞重试循环无退避、超时、取消传播或尝试次数上限。取消安全cancellation safety是 Rust async 生态特有的核心概念future 被 poll 后若未完成即被丢弃其内部状态可能停留在不一致的中间态规则要求审查者关注这类边界。3.7 集合、迭代器与性能Collections, Iterators, and Performance热路径非必要分配反复构造String、调用format!、collect()或to_vec()而借用或流式处理已足够迭代器适配器优先使用迭代器适配器和标准库集合 API 使所有权与复杂度更清晰避免过密的迭代器链掩盖错误处理或副作用预分配已知预期大小时为 hash map、vector 与 string 预分配容量避免增长开销O(n²) 查找嵌套循环中的 O(n²) 查找若HashMap、HashSet、排序或索引策略能明显降低复杂度则应报告。性能类问题规则强调了热路径前提避免审查者为了微优化而误报无关代码。3.8 类型与 API 设计Type and API Design建模领域状态用枚举、newtype 和类型化 ID 建模领域状态而非布尔值、字符串或原始整数——当非法状态本可以被表达时标准转换/借用 trait设计可复用 API 时优先使用From、TryFrom、AsRef、Borrow、IntoIterator等标准 trait公开项质量公开的 struct、enum、trait 与 error 应在 crate 边界内有合适的名称、可见性、trait derive 与文档抽象泄漏公开 API 中避免暴露具体集合或同步类型而应使用切片、迭代器、trait 或更窄的抽象以保留灵活性。用类型系统让非法状态不可表达make illegal states unrepresentable是 Rust API 设计的标志性理念这组条款正是它的审查落地。3.9 宏与元编程Macros and Metaprogramming宏类条款有明确触发前提只有当 diff 确实定义了macro_rules!或过程宏时才报告普通宏调用不在此列。表达式求值多次$x:expr片段在展开中被插入多次导致调用方表达式及其副作用被执行多次应在展开内先用let绑定一次缺少$crate::前缀导出的或被公开使用的宏引用了不带$crate::的项当宏从其他 crate 调用时名称解析会失败或绑定错误项token-tree 优先级$t:tt片段在未加括号的情况下重新发出运算符优先级可能悄悄改变意图此条仅适用于 token 级tt插值因为:expr片段和整个展开各自被解析为一个完整表达式过程宏错误处理过程宏对畸形输入使用unwrap()、expect()、panic!而不是发出带有效 span 的syn::Error/compile_error!宏卫生性假设生成的标识符依赖调用点作用域中的名称或宏在同一模块中被多次调用时出现项冲突。宏展开是编译期行为问题往往只在特定调用场景下才暴露这组规则为 LLM 提供了明确的检查边界。3.10 安全敏感代码Security-Sensitive Code输入验证路径、URL、命令、SQL 与序列化输入在使用前必须验证不要用未检查的字符串拼接构造 shell 命令或 SQL禁止日志泄密不要记录密钥、令牌、凭据、私钥或可识别个人身份的信息整数与边界检查整数转换、字节切片与长度运算是否存在溢出、截断和 UTF-8 边界错误密码学与鉴权加密、随机数、认证与授权代码必须使用经过充分审查的 crate 并显式处理错误标记临时拼凑的实现。四、源码级验证规则如何被加载与解析规则文本并非直接写死在审查逻辑中而是通过 internal/config/rules/system_rules.go 的嵌入式文件系统加载//go:embed system_rules.json rule_docs/* var rulesFS embed.FS func LoadDefault() (*SystemRule, error) { data, err : rulesFS.ReadFile(system_rules.json) // ... content, err : rulesFS.ReadFile(rule_docs/ rule.DefaultRule) // ... for i : range rule.PathRules { content, err : rulesFS.ReadFile(rule_docs/ rule.PathRules[i].Rule) // ... } }LoadDefault会读取system_rules.json解析出default_rule回退规则即 internal/config/rules/rule_docs/default.md与path_rule_map中按声明顺序排列的路径规则再把每个Rule字段替换成对应rule_docs/*.md的完整内容。路径匹配由resolveDetail完成internal/config/rules/system_rules.go匹配基于bmatcuk/doublestar/v4支持**递归目录匹配匹配前路径与模式均转小写大小写不敏感支持{a,b,c}花括号展开——expandBraces会把*.{go,py}展开为*.go、*.py分别匹配按声明顺序首个匹配优先first match wins全部未命中则回退到default_rule。因此对于src/parser/lexer.rs这样的路径**/*.rs是唯一命中的模式规则文本即为rust.md全文。若用户在项目级rule.json中配置了**/*.rs的定制规则则用户层优先于系统层若设置了merge_system_rule: true则系统规则会以## System-Specific Rules (Mandatory)与## User-Specific Rules (Mandatory)两个小节拼接保留见 internal/config/rules/system_rules.go。另一个值得注意的细节是CanonicalConfig()解析器会把所有层的规则文本、模式与merge标志序列化为确定性的字段列表用于生成运行 manifest 中的rule_config_sha256哈希。也就是说修改rust.md会使运行指纹变化规则变更可被审计与追踪。五、实战用ocr rules check验证 Rust 规则命中ocr rules check子命令用于检查某个文件路径最终命中哪条规则是排查规则行为最直接的调试工具实现见 cmd/opencodereview/rules_cmd.go。ocr rules check src/parser/lexer.rs输出会显示命中的层Source、匹配的 globPattern以及完整规则文本File: src/parser/lexer.rs Source: System built-in Pattern: **/*.rs Rule: ──────────────────────────────────────── …rust.md 全文… ────────────────────────────────────────其底层逻辑是runRulesCheck通过rules.NewResolver(repoDir, rulePath, ResolverOptions{})构建四层解析器断言其实现了DetailResolver接口再调用ResolveDetail(filePath)获取RuleDetail包含Rule、Source、Pattern字段见 internal/config/rules/system_rules.go。rules check对非 git 仓库目录会报错对应测试见 cmd/opencodereview/rules_check_test.go。若你为 Rust 项目配置了定制规则还可以叠加--rule参数调试ocr rules check --rule custom-rust.json src/parser/lexer.rs此时Source会显示Custom (--rule)Pattern为定制规则中命中的 glob——这一信息对确认为什么某条规则生效/不生效非常关键。六、为 Rust 项目定制与扩展规则内置rust.md面向通用 Rust 代码团队可按需覆盖或增强项目级规则在仓库根目录创建.opencodereview/rule.json并提交例如为内部 crate 增加专门的生命周期约定{ rules: [ { path: **/*.rs, rule: 内部 crate 的所有公开函数必须携带文档注释且不得在返回类型中暴露私有类型。 } ] }该层规则将替换系统规则若希望保留内置规则可设置merge_system_rule: true系统 Rust 规则会作为强制小节保留。单次 PR 覆盖ocr review --rule ./security-only.json可绕过项目与全局层适合安全专项审查。全局偏好写入~/.opencodereview/rule.json本机所有仓库生效。需要提醒的是默认路径过滤会排除测试文件**/*_test.rs在 internal/config/allowlist/default_exclude_patterns.json 中如需审查 Rust 测试代码需在include中显式声明如include: [**/*_test.rs]。七、结语从规则文本到可执行的审查契约rust.md不是一份泛泛的代码风格清单而是一份面向 LLM Agent 的、可执行的审查契约它把 Rust 语言最容易被误用、且确定性工具难以覆盖的领域——所有权与生命周期、unsafe 边界、异步取消安全、宏卫生性、并发内存序——逐条编码为精确的缺陷判定标准并以精度优先、证据驱动为总原则约束 Agent 的输出。结合四层规则解析链internal/config/rules/system_rules.go、ocr rules check调试工具与merge_system_rule合并机制团队既可以开箱即用地获得这套语言级审查能力也可以在不牺牲内置规则的前提下叠加自己的工程规范。如果你正在为 Rust 仓库接入 open-code-review建议按以下顺序落地先用ocr review --preview确认文件过滤结果 → 用ocr rules check file.rs验证规则命中 → 视团队规范在.opencodereview/rule.json中定制或合并规则 → 最后在 CI如 GitHub Actions见 examples/github_actions/ocr-review.yml中接入完整审查流程。【免费下载链接】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），仅供参考