Optimism AI 工程化实践Graphite 驱动的 Solidity 代码审查规则体系【免费下载链接】optimismOptimism is Ethereum, scaled.项目地址: https://gitcode.com/GitHub_Trending/op/optimism本文基于 Optimism 单仓中 AI 工程工具集目录 展开介绍该团队如何把 AI 引入工程流程、其唯一在役项目 Graphite 代码审查系统的设计目标以及配套的 Diamond 审查规则文件 中针对 Solidity PR 的每一条具体审查规则——包括 OPCM 版本号升级告警、dev注释合规、vm.expectRevert低层调用语义、Foundry 版本升级管控、非幂等初始化器检测与存储布局变更Storage Layout Mutation识别等。读完本文你将掌握一套可直接复用的AI 代码审查规则编写方法论并能对照仓库源码验证每条规则的落地依据。一、AI 工程工具集定位与设计哲学ops/ai-eng 目录被定义为面向 Optimism 工程工作流的 AI 驱动自动化系统集合Collection of AI-driven automation systems for Optimism engineering workflows。目录内每个项目都遵循统一目标使用 AI 处理重复性任务、维持代码质量、提升开发者生产力。README 中给出了四条明确的设计哲学Philosophy这四点也是理解后续所有规则的前提Automate repetitive tasks自动化那些不需要人类创造力的重复任务Maintain quality standards在整个代码库中一致地保持质量标准Free up engineering time把工程时间释放给高价值工作Run primarily in CI工具主要在 CI 中运行本地执行仅用于测试验证。当前该目录下只有一个在役Active项目Graphite Code Review用途对 Pull Request 中的 Solidity 文件进行符合项目标准的自动化审查状态✅ Active技术栈Graphite Diamond规则引擎规则文件即 Diamond Code Review Rules文档ops/ai-eng/graphite/rules.md。新增 AI 工具的规范流程README 还规定了向该集合添加新工具的 5 步流程可作为仓库贡献约定直接引用创建新目录ai-eng/your-project/添加项目文档your-project/README.md更新 README 中的项目清单把相关命令加入根目录 justfile沿用现有模式接入 CI。整个工具集的维护方为 EVM Safety Team。二、审查范围Applicability严格圈定 AI 的管辖区规则文件 开篇第一条就是范围限定这是 AI 审查系统设计中非常关键的一环——先收敛再深化AI 只允许审查以下两类文件的变更Solidity 源码文件*.sol存储布局快照文件packages/contracts-bedrock/snapshots/storageLayout/*.json。对任何其他文件类型规则明确要求不留任何评论Do NOT leave comments on any other file types。这一约束避免了 AI 审查在无关文件上产生噪音评论也解释了为什么 Optimism 仓库中 storageLayout 快照目录 会单独列为审查对象——该目录存放了如AddressManager.json、CrossL2Inbox.json、DelayedWETH.json等核心合约的存储槽位快照是判断存储布局是否被破坏的唯一事实来源。三、规则详解Solidity 文件审查的七条主线以下小节完整继承 rules.md 中Rules for Reviewing Solidity Files的全部规则并结合仓库源码给出每条规则的现实对照。3.1dev注释合约内嵌的开发者契约规则要求审查者密切关注代码库中的devnatspec 注释这些注释经常包含重要的不变量invariants、前置条件或面向修改者的提醒。具体审查动作包括审查某函数变更时检查该函数或其所在合约的dev注释是否规定了修改时必须同步执行的操作例如注释声明更新此函数时同步更新 X发现违反dev注释指示的变更时必须标记Flag。这条规则的本质是把散落在 natspec 里的隐性开发约束提升为机器可执行的检查项——人可能忘记注释里写过的话AI 规则引擎不会。3.2 风格指南与版本选择明确不审什么规则中同样明确了两个负面清单风格遵循仓库根目录下的风格指南规则文件指明位于.cursor/rules/solidity-styles.mdc当前快照中该文件不存在以仓库实际 checkout 为准Versioning不要对某个 Solidity 文件的版本号递增选择发表意见Do NOT comment on the choice of version increment。什么该审、什么不该审的显式声明是这份规则文件最值得借鉴的结构化思路负面清单与正面规则同等重要它能防止 AI 在风格偏好或版本策略这类主观话题上浪费评审带宽。3.3 接口文件交给 CI不交给 AI对于接口文件规则划定了三条清晰的边界源码文件预期在interfaces/目录下有对应的接口文件——但缺失接口文件不审CI 会检查接口文件与源码文件的不一致不审CI 会检查接口文件不要求natspec 注释natspec 只要求出现在源码文件中。这体现了一条通用工程原则确定性规则用确定性工具CI lint/脚本执行AI 只处理需要语义理解的部分两者分工明确、互不越界。3.4vm.expectRevert与低层调用的布尔值陷阱这是规则文件中技术密度最高的一条。规则指出当vm.expectRevert与低层调用.call{}联用时Foundry 会反转返回布尔值的语义——该布尔值表示的是expectRevert 是否成功即调用是否按预期 revert而不是调用是否成功。因此如下捕获并断言该布尔值的代码是正确的审查时不应标记也不得建议移除返回值检查vm.expectRevert(ExpectedError.selector); (bool revertsAsExpected,) address(target).call(data); assertTrue(revertsAsExpected, expectRevert: call did not revert);审查动作的边界被精确限定为低层调用后未捕获也未断言返回值 → 必须标记已捕获并断言 → 正确代码不得标记。这类框架语义反转问题正是人工审查中最易误判的场景把它写成显式规则并附上正例代码能同时压制误报false positive与漏报false negative。3.5 Foundry 版本升级强制设计文档背书当 PR 修改了 Foundry 依赖版本即 mise.toml 中的forge、cast、anvil版本号当前快照中三者均为1.2.3时规则要求 PR 描述中必须引用一份已批准并合入的设计文档。若缺失AI 必须在 PR 上留下醒目评论模板如下⚠️Foundry Version Bump Without Design DocumentThis PR includes a change to the Foundry dependency versions, i.e theforge,cast, andanvilversions inmise.toml.Please include a reference to the approved and merged design document that approves these foundry versions for usage in the PR description. Otherwise, the PR will not be approved.规则文件同时指向仓库内的 Foundry 版本升级政策位于 contracts-bedrock 的 book 政策文档中供审查者与 PR 作者查阅升级流程细节。这构成了一条完整的治理闭环工具版本变更 → 设计文档背书 → AI 强制核验 → 政策文档兜底。3.6 OPCM 版本号升级三类 bump 的分级管控规则要求若 PR 修改了OPContractsManagerV2.sol并变更其version常量且属于 major 或 minor 版本升级必须在 PR 上留下醒目评论。仓库源码印证了这一规则的必要性——OPContractsManagerV2.sol 中version()函数的 natspec 注释本身就警告了 OPCM 的版本号规则与其他合约不同/// notice The version of the OPCM contract. /// WARNING: OPCM versioning rules differ from other contracts: /// - Major bump: New required sequential upgrade /// - Minor bump: Replacement OPCM for same upgrade /// - Patch bump: Development changes (expected for normal dev work) /// custom:semver 8.0.4 function version() public pure returns (string memory) { return 8.0.4; }AI 需要发出的标准告警评论模板为⚠️OPCM Version Bump DetectedThis PR includes a major or minor version bump toOPContractsManagerV2.sol.Reminder of OPCM versioning rules:Major bump: Only for a new required sequential upgrade (e.g., U16 → U17)Minor bump: Only for replacing an existing OPCM for the same upgrade (e.g., bug fixes, U16a)Patch bump: Expected for normal development workPlease confirm this version bump is intentional and follows the versioning policy.对照仓库事实可见其含义major bump 对应一次新的顺序性必选升级如 U16 → U17minor bump 仅用于同一升级内替换既有 OPCM如修 bug 的 U16apatch bump 才是日常开发的常态。由于 OPCM 是 Superchain 合约体系升级编排的核心入口把这类语义判断交给 AI 规则做二次确认能有效防止误升版本号。3.7 非幂等初始化器可升级合约的状态安全红线当审查对象是initialize()或reinitializer函数时规则要求判断其是否幂等——多次以相同参数调用应与调用一次产生相同的最终状态。理由在于代理proxy合约在升级过程中可能被重新初始化非幂等初始化器有损坏既有状态的风险。应当标记的情形When to flaginitialize()自增计数器、向数组追加元素或执行任何重复执行会改变结果的操作initialize()发起具有持久副作用的外部调用mint、转账、授权等而非简单覆写initialize()覆写了其他合约或链下系统可能已依赖的变量对已有initialize()的修改新引入了之前不存在的非幂等或不安全重入行为。处置要求非幂等或重入不安全的行为默认禁止除非函数上有显式notice注释说明其安全性。若检测到无notice背书的非幂等行为必须留下阻塞性blocking评论Non-Idempotent Initializer — Acknowledgment RequiredThisinitialize()function contains operations that are not idempotent (not safe to call multiple times with the same arguments). Since proxied contracts can be re-initialized during upgrades, this is disallowed unless explicitly acknowledged.Please either:Make the operation idempotent, orAdd anoticecomment on the function explaining why the non-idempotent behavior is safe given how callers use itSeedocs/ai/contract-dev.mdfor detailed guidance.该评论指向仓库中的 contract-dev.md这是 Optimism 面向 AI 辅助合约开发的成文指南两者互相引用形成审查规则 ↔ 开发规范的双向索引。3.8 存储布局变更警告包括改名伪装的隐蔽变更这是规则文件中最长、判定逻辑最复杂的一条。若 PR 修改了packages/contracts-bedrock/snapshots/storageLayout/下的任何文件AI 必须分析 diff判断存储槽位是否发生变更mutation区别于随合约整体新增或删除。构成变更mutation的情形已有字段的slot编号发生变化字段被挪到不同槽位已有字段的type发生变化已有字段的offset发生变化某存储槽位条目被整体删除字段从仍存在的合约中移除。不构成问题的情形在合约布局末尾纯新增存储槽位追加新字段为新合约新增存储布局文件因合约本身被删除而导致的布局文件删除。关键细节——通过改名/移动隐藏的变更规则专门警告若某个布局文件被删除、同时出现一个名字相近的新文件很可能是合约改名或移动。git 会把这种变更显示为删除 新增而非修改从而掩盖存储槽位变更。此时 AI必须把被删文件的布局与新文件布局逐字段比对以发现被隐藏的 mutation。规则给出的示例即FooV1.json被删除、FooV2.json被新增必须仔细比对二者的存储布局。检测到任何已有槽位变更含改名/移动所隐藏者时必须留下如下醒目评论⚠️Storage Layout Mutation DetectedThis PR modifies existing storage slots in the following file(s):[list the affected storage layout files]Changes detected:[describe the specific mutations: slot shifts, type changes, deletions, etc.]Mutating storage slots can bedangerousfor upgradeable contracts, as it may corrupt existing on-chain state.Required action:Please add an explicit comment in the PR description or in the code explaining why this storage layout change is safe. For example:This contract is not upgradeable and is always deployed freshThis is a new contract that has never been deployedStorage slots X-Y are intentionally being reorganized because [reason], and this is safe because [justification]The PR cannot be approved until this acknowledgment is provided.注意其中的处置策略AI 并不直接否决而是要求作者在 PR 描述或代码中给出显式安全论证例如该合约不可升级、始终全新部署在获得确认前 PR 不得被批准。这延续了整份规则的统一模式AI 负责发现与质询人类负责确认与担责。四、规则体系的设计模式可复用性分析把 README 的设计哲学与 rules.md 的具体条文合起来看这套系统呈现出一套可迁移的 AI 审查规则编写模式范围先行先声明只审什么其余文件一律沉默从制度上压低噪音正负清单并存正面规则dev合规、非幂等检查与负面清单不评版本选择、不查接口缺失同时显式化界定 AI 的权限边界确定性检查让渡给 CI接口存在性、接口一致性这类可脚本化的检查明确排除在 AI 职责之外规则即模板每类高危场景都附带可直接粘贴的标准化评论模板保证审查意见的一致性与可预期性规则与规范互相引用Foundry 升级规则指向 foundry-upgrades.md非幂等规则指向 contract-dev.md形成规则—政策—源码的三层证据链CI 优先、本地可选与 README 的Run primarily in CI哲学一致规则的执行主战场是 PR 流水线而非本地 IDE。对于其他维护着可升级合约代码库的团队这套范围限定 分级告警 模板化评论 政策文档背书的组合可以直接作为 AI 代码审查规则文件的写作范本先圈定文件类型再按风险等级信息提示 / 要求论证 / 阻塞合并分配每类检查的处置强度最后为每条规则在仓库内留存可验证的事实来源如 OPContractsManagerV2.sol 中的version()实现与 storageLayout 快照使 AI 审查的每一条结论都能回溯到仓库证据。【免费下载链接】optimismOptimism is Ethereum, scaled.项目地址: https://gitcode.com/GitHub_Trending/op/optimism创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/17 21:15:08 · 阅读 1.2k Optimism AI 工程化实践：Graphite 驱动的 Solidity 代码审查规则体系
Optimism AI 工程化实践Graphite 驱动的 Solidity 代码审查规则体系【免费下载链接】optimismOptimism is Ethereum, scaled.项目地址: https://gitcode.com/GitHub_Trending/op/optimism本文基于 Optimism 单仓中 AI 工程工具集目录 展开介绍该团队如何把 AI 引入工程流程、其唯一在役项目 Graphite 代码审查系统的设计目标以及配套的 Diamond 审查规则文件 中针对 Solidity PR 的每一条具体审查规则——包括 OPCM 版本号升级告警、dev注释合规、vm.expectRevert低层调用语义、Foundry 版本升级管控、非幂等初始化器检测与存储布局变更Storage Layout Mutation识别等。读完本文你将掌握一套可直接复用的AI 代码审查规则编写方法论并能对照仓库源码验证每条规则的落地依据。一、AI 工程工具集定位与设计哲学ops/ai-eng 目录被定义为面向 Optimism 工程工作流的 AI 驱动自动化系统集合Collection of AI-driven automation systems for Optimism engineering workflows。目录内每个项目都遵循统一目标使用 AI 处理重复性任务、维持代码质量、提升开发者生产力。README 中给出了四条明确的设计哲学Philosophy这四点也是理解后续所有规则的前提Automate repetitive tasks自动化那些不需要人类创造力的重复任务Maintain quality standards在整个代码库中一致地保持质量标准Free up engineering time把工程时间释放给高价值工作Run primarily in CI工具主要在 CI 中运行本地执行仅用于测试验证。当前该目录下只有一个在役Active项目Graphite Code Review用途对 Pull Request 中的 Solidity 文件进行符合项目标准的自动化审查状态✅ Active技术栈Graphite Diamond规则引擎规则文件即 Diamond Code Review Rules文档ops/ai-eng/graphite/rules.md。新增 AI 工具的规范流程README 还规定了向该集合添加新工具的 5 步流程可作为仓库贡献约定直接引用创建新目录ai-eng/your-project/添加项目文档your-project/README.md更新 README 中的项目清单把相关命令加入根目录 justfile沿用现有模式接入 CI。整个工具集的维护方为 EVM Safety Team。二、审查范围Applicability严格圈定 AI 的管辖区规则文件 开篇第一条就是范围限定这是 AI 审查系统设计中非常关键的一环——先收敛再深化AI 只允许审查以下两类文件的变更Solidity 源码文件*.sol存储布局快照文件packages/contracts-bedrock/snapshots/storageLayout/*.json。对任何其他文件类型规则明确要求不留任何评论Do NOT leave comments on any other file types。这一约束避免了 AI 审查在无关文件上产生噪音评论也解释了为什么 Optimism 仓库中 storageLayout 快照目录 会单独列为审查对象——该目录存放了如AddressManager.json、CrossL2Inbox.json、DelayedWETH.json等核心合约的存储槽位快照是判断存储布局是否被破坏的唯一事实来源。三、规则详解Solidity 文件审查的七条主线以下小节完整继承 rules.md 中Rules for Reviewing Solidity Files的全部规则并结合仓库源码给出每条规则的现实对照。3.1dev注释合约内嵌的开发者契约规则要求审查者密切关注代码库中的devnatspec 注释这些注释经常包含重要的不变量invariants、前置条件或面向修改者的提醒。具体审查动作包括审查某函数变更时检查该函数或其所在合约的dev注释是否规定了修改时必须同步执行的操作例如注释声明更新此函数时同步更新 X发现违反dev注释指示的变更时必须标记Flag。这条规则的本质是把散落在 natspec 里的隐性开发约束提升为机器可执行的检查项——人可能忘记注释里写过的话AI 规则引擎不会。3.2 风格指南与版本选择明确不审什么规则中同样明确了两个负面清单风格遵循仓库根目录下的风格指南规则文件指明位于.cursor/rules/solidity-styles.mdc当前快照中该文件不存在以仓库实际 checkout 为准Versioning不要对某个 Solidity 文件的版本号递增选择发表意见Do NOT comment on the choice of version increment。什么该审、什么不该审的显式声明是这份规则文件最值得借鉴的结构化思路负面清单与正面规则同等重要它能防止 AI 在风格偏好或版本策略这类主观话题上浪费评审带宽。3.3 接口文件交给 CI不交给 AI对于接口文件规则划定了三条清晰的边界源码文件预期在interfaces/目录下有对应的接口文件——但缺失接口文件不审CI 会检查接口文件与源码文件的不一致不审CI 会检查接口文件不要求natspec 注释natspec 只要求出现在源码文件中。这体现了一条通用工程原则确定性规则用确定性工具CI lint/脚本执行AI 只处理需要语义理解的部分两者分工明确、互不越界。3.4vm.expectRevert与低层调用的布尔值陷阱这是规则文件中技术密度最高的一条。规则指出当vm.expectRevert与低层调用.call{}联用时Foundry 会反转返回布尔值的语义——该布尔值表示的是expectRevert 是否成功即调用是否按预期 revert而不是调用是否成功。因此如下捕获并断言该布尔值的代码是正确的审查时不应标记也不得建议移除返回值检查vm.expectRevert(ExpectedError.selector); (bool revertsAsExpected,) address(target).call(data); assertTrue(revertsAsExpected, expectRevert: call did not revert);审查动作的边界被精确限定为低层调用后未捕获也未断言返回值 → 必须标记已捕获并断言 → 正确代码不得标记。这类框架语义反转问题正是人工审查中最易误判的场景把它写成显式规则并附上正例代码能同时压制误报false positive与漏报false negative。3.5 Foundry 版本升级强制设计文档背书当 PR 修改了 Foundry 依赖版本即 mise.toml 中的forge、cast、anvil版本号当前快照中三者均为1.2.3时规则要求 PR 描述中必须引用一份已批准并合入的设计文档。若缺失AI 必须在 PR 上留下醒目评论模板如下⚠️Foundry Version Bump Without Design DocumentThis PR includes a change to the Foundry dependency versions, i.e theforge,cast, andanvilversions inmise.toml.Please include a reference to the approved and merged design document that approves these foundry versions for usage in the PR description. Otherwise, the PR will not be approved.规则文件同时指向仓库内的 Foundry 版本升级政策位于 contracts-bedrock 的 book 政策文档中供审查者与 PR 作者查阅升级流程细节。这构成了一条完整的治理闭环工具版本变更 → 设计文档背书 → AI 强制核验 → 政策文档兜底。3.6 OPCM 版本号升级三类 bump 的分级管控规则要求若 PR 修改了OPContractsManagerV2.sol并变更其version常量且属于 major 或 minor 版本升级必须在 PR 上留下醒目评论。仓库源码印证了这一规则的必要性——OPContractsManagerV2.sol 中version()函数的 natspec 注释本身就警告了 OPCM 的版本号规则与其他合约不同/// notice The version of the OPCM contract. /// WARNING: OPCM versioning rules differ from other contracts: /// - Major bump: New required sequential upgrade /// - Minor bump: Replacement OPCM for same upgrade /// - Patch bump: Development changes (expected for normal dev work) /// custom:semver 8.0.4 function version() public pure returns (string memory) { return 8.0.4; }AI 需要发出的标准告警评论模板为⚠️OPCM Version Bump DetectedThis PR includes a major or minor version bump toOPContractsManagerV2.sol.Reminder of OPCM versioning rules:Major bump: Only for a new required sequential upgrade (e.g., U16 → U17)Minor bump: Only for replacing an existing OPCM for the same upgrade (e.g., bug fixes, U16a)Patch bump: Expected for normal development workPlease confirm this version bump is intentional and follows the versioning policy.对照仓库事实可见其含义major bump 对应一次新的顺序性必选升级如 U16 → U17minor bump 仅用于同一升级内替换既有 OPCM如修 bug 的 U16apatch bump 才是日常开发的常态。由于 OPCM 是 Superchain 合约体系升级编排的核心入口把这类语义判断交给 AI 规则做二次确认能有效防止误升版本号。3.7 非幂等初始化器可升级合约的状态安全红线当审查对象是initialize()或reinitializer函数时规则要求判断其是否幂等——多次以相同参数调用应与调用一次产生相同的最终状态。理由在于代理proxy合约在升级过程中可能被重新初始化非幂等初始化器有损坏既有状态的风险。应当标记的情形When to flaginitialize()自增计数器、向数组追加元素或执行任何重复执行会改变结果的操作initialize()发起具有持久副作用的外部调用mint、转账、授权等而非简单覆写initialize()覆写了其他合约或链下系统可能已依赖的变量对已有initialize()的修改新引入了之前不存在的非幂等或不安全重入行为。处置要求非幂等或重入不安全的行为默认禁止除非函数上有显式notice注释说明其安全性。若检测到无notice背书的非幂等行为必须留下阻塞性blocking评论Non-Idempotent Initializer — Acknowledgment RequiredThisinitialize()function contains operations that are not idempotent (not safe to call multiple times with the same arguments). Since proxied contracts can be re-initialized during upgrades, this is disallowed unless explicitly acknowledged.Please either:Make the operation idempotent, orAdd anoticecomment on the function explaining why the non-idempotent behavior is safe given how callers use itSeedocs/ai/contract-dev.mdfor detailed guidance.该评论指向仓库中的 contract-dev.md这是 Optimism 面向 AI 辅助合约开发的成文指南两者互相引用形成审查规则 ↔ 开发规范的双向索引。3.8 存储布局变更警告包括改名伪装的隐蔽变更这是规则文件中最长、判定逻辑最复杂的一条。若 PR 修改了packages/contracts-bedrock/snapshots/storageLayout/下的任何文件AI 必须分析 diff判断存储槽位是否发生变更mutation区别于随合约整体新增或删除。构成变更mutation的情形已有字段的slot编号发生变化字段被挪到不同槽位已有字段的type发生变化已有字段的offset发生变化某存储槽位条目被整体删除字段从仍存在的合约中移除。不构成问题的情形在合约布局末尾纯新增存储槽位追加新字段为新合约新增存储布局文件因合约本身被删除而导致的布局文件删除。关键细节——通过改名/移动隐藏的变更规则专门警告若某个布局文件被删除、同时出现一个名字相近的新文件很可能是合约改名或移动。git 会把这种变更显示为删除 新增而非修改从而掩盖存储槽位变更。此时 AI必须把被删文件的布局与新文件布局逐字段比对以发现被隐藏的 mutation。规则给出的示例即FooV1.json被删除、FooV2.json被新增必须仔细比对二者的存储布局。检测到任何已有槽位变更含改名/移动所隐藏者时必须留下如下醒目评论⚠️Storage Layout Mutation DetectedThis PR modifies existing storage slots in the following file(s):[list the affected storage layout files]Changes detected:[describe the specific mutations: slot shifts, type changes, deletions, etc.]Mutating storage slots can bedangerousfor upgradeable contracts, as it may corrupt existing on-chain state.Required action:Please add an explicit comment in the PR description or in the code explaining why this storage layout change is safe. For example:This contract is not upgradeable and is always deployed freshThis is a new contract that has never been deployedStorage slots X-Y are intentionally being reorganized because [reason], and this is safe because [justification]The PR cannot be approved until this acknowledgment is provided.注意其中的处置策略AI 并不直接否决而是要求作者在 PR 描述或代码中给出显式安全论证例如该合约不可升级、始终全新部署在获得确认前 PR 不得被批准。这延续了整份规则的统一模式AI 负责发现与质询人类负责确认与担责。四、规则体系的设计模式可复用性分析把 README 的设计哲学与 rules.md 的具体条文合起来看这套系统呈现出一套可迁移的 AI 审查规则编写模式范围先行先声明只审什么其余文件一律沉默从制度上压低噪音正负清单并存正面规则dev合规、非幂等检查与负面清单不评版本选择、不查接口缺失同时显式化界定 AI 的权限边界确定性检查让渡给 CI接口存在性、接口一致性这类可脚本化的检查明确排除在 AI 职责之外规则即模板每类高危场景都附带可直接粘贴的标准化评论模板保证审查意见的一致性与可预期性规则与规范互相引用Foundry 升级规则指向 foundry-upgrades.md非幂等规则指向 contract-dev.md形成规则—政策—源码的三层证据链CI 优先、本地可选与 README 的Run primarily in CI哲学一致规则的执行主战场是 PR 流水线而非本地 IDE。对于其他维护着可升级合约代码库的团队这套范围限定 分级告警 模板化评论 政策文档背书的组合可以直接作为 AI 代码审查规则文件的写作范本先圈定文件类型再按风险等级信息提示 / 要求论证 / 阻塞合并分配每类检查的处置强度最后为每条规则在仓库内留存可验证的事实来源如 OPContractsManagerV2.sol 中的version()实现与 storageLayout 快照使 AI 审查的每一条结论都能回溯到仓库证据。【免费下载链接】optimismOptimism is Ethereum, scaled.项目地址: https://gitcode.com/GitHub_Trending/op/optimism创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考