ECC 规则体系中的 Rust Hooks 实战用 cargo fmt / clippy / check 搭建 Claude Code 自动化质量门禁【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC在 Claude Code 的日常协作中Rust 开发者最常遇到的问题是Agent 每次编辑完.rs文件后缩进、lint 警告和编译错误常常被留到下一次手动检查。本文以 ECCEverything Claude Code开源仓库中的 Rust Hooks 规则 为核心系统讲解如何利用 PostToolUse 钩子在编辑器保存.rs文件后自动执行cargo fmt、cargo clippy与cargo check并结合仓库内真实的 hooks 配置与源码实现帮助你搭建一套编辑即校验、写错即反馈的 Rust 自动化质量门禁。读完本文你将掌握 Hook 的匹配器机制、配置语法、运行时控制方式以及如何将这些钩子与 ECC 的 hooks 运行时、规则分层体系无缝集成。一、规则文件的定位Rust 专用扩展层在 ECC 仓库中规则按语言分目录组织rules/rust/下包含 hooks.md、coding-style.md、patterns.md、security.md、testing.md 五个维度。日语本地化版本位于 docs/ja-JP/rules/rust/其中 hooks.md 的开头就声明了它的定位このファイルは common/hooks.md を Rust 固有のコンテンツで拡張します。本文件以 Rust 特有内容扩展 common/hooks.md也就是说ECC 采用通用基座 语言扩展的分层规则设计通用层rules/common/hooks.md 定义所有语言共用的 Hook 类型、权限策略与 TodoWrite 最佳实践语言层rules/rust/hooks.md 只补充 Rust 特有的 Hook 建议本地化层docs/ja-JP/rules/common/hooks.md 与 docs/ja-JP/rules/rust/hooks.md 提供日语翻译方便非英语开发者引用。这种分层意味着阅读 Rust Hooks 规则时必须同时理解通用 Hooks 系统的行为约定否则容易把该在哪一层配置搞混。规则文件顶部的 frontmatter 也值得注意--- paths: - **/*.rs - **/Cargo.toml ---paths声明了该规则的作用域——只对.rs源文件与Cargo.toml清单文件生效。这与 Hook 配置中的matcher参数相辅相成规则文件划定管哪些文件Hook 的matcher划定在哪些工具事件上触发。二、Hooks 系统基础理解 PreToolUse / PostToolUse / Stop在进入 Rust 配置之前先掌握 ECC 通用 Hooks 规则中的三类核心事件见 rules/common/hooks.mdHook 类型触发时机能力边界PreToolUse工具执行前可校验、可修改参数stderr 输出警告退出码 2 可阻断工具调用PostToolUse工具执行后可自动格式化、运行检查、分析输出不能阻断只能反馈Stop每轮 Agent 响应结束时最终校验如全量格式化、类型检查、会话状态持久化ECC 仓库的 hooks/hooks.json 是这套机制的完整生产级示例它把 Hook 事件扩展到了 7 类PreToolUse、PreCompact、SessionStart、PostToolUse、PostToolUseFailure、Stop、SessionEnd。其中PreToolUse注册了 Bash 前置分发器pre:bash:dispatcher、文档文件警告pre:write:doc-file-warning、配置保护pre:config-protection、MCP 健康检查pre:mcp-health-check等钩子Stop阶段则批量执行格式化与类型检查stop:format-typecheck、会话成本统计stop:cost-tracker、桌面通知stop:desktop-notify等。这套真实配置印证了一个重要设计思路轻量检查放在 PostToolUse 逐次执行重量级全量校验放在 Stop 批次执行——与 Rust 规则中编辑后跑cargo check、提交前跑完整构建的分层策略完全一致。三、核心配置Rust 的 PostToolUse 三件套Rust Hooks 规则docs/ja-JP/rules/rust/hooks.md给出的核心建议是在~/.claude/settings.json中配置三个 PostToolUse 钩子cargo fmt— 编辑.rs文件后自动格式化cargo clippy— 编辑 Rust 文件后执行 lint 检查cargo check— 变更后验证编译比cargo build更快。其背后是 Rust 官方工具链的标准分工rustfmt负责风格统一clippy负责代码质量 lintcargo check只做元数据解析与类型检查、不生成完整二进制因此能以远低于cargo build的成本提前暴露编译错误。ECC 的 rules/rust/coding-style.md 进一步强化了这一分工格式强制使用cargo fmtlint 使用cargo clippy -- -D warnings把警告升级为错误最大行宽 100 字符。将这三个工具落成可直接复制到~/.claude/settings.json的配置{ hooks: { PostToolUse: [ { matcher: Edit|Write, hooks: [ { type: command, command: cargo fmt --all, description: Auto-format Rust files with rustfmt after edits, timeout: 30 } ] }, { matcher: Edit|Write, hooks: [ { type: command, command: cargo clippy --all-targets --all-features -- -D warnings, description: Run clippy lints with warnings-as-errors after editing Rust files, timeout: 120 } ] }, { matcher: Edit|Write, hooks: [ { type: command, command: cargo check --all-targets, description: Verify compilation after changes (faster than cargo build), timeout: 120 } ] } ] } }配置要点逐条拆解matcher 选型Edit|Write覆盖了修改已有.rs文件和新建.rs文件两个场景。若只想在修改时触发可收窄为Edit若想连MultiEdit批量编辑也纳入则写Edit|Write|MultiEditECC 自身的 hooks/hooks.json 中大量使用matcher: Edit|Write|MultiEdit组合。命令选择cargo fmt --all会格式化当前工作区所有包保证多 crate 工作区风格一致cargo check --all-targets覆盖 lib、bin、test、example 等全部目标比裸cargo check更彻底。timeout 兜底PostToolUse 钩子理论上不阻断流程但卡死的命令仍会拖慢 Agent 响应务必给出合理超时。ECC 的钩子中 PostToolUse 分发器的超时被设为 30 秒同步与 45 秒异步见 hooks/hooks.json 的post:dispatcher:sync/post:dispatcher:async可作为参考基线。四、把配置放进真实环境ECC 的 Hook 运行时机制上面是裸配置写法。在 ECC 生态中Hook 并不是简单粘贴到 settings.json 就完事——hooks/README.md 明确警告不要直接把仓库里的hooks.json原样粘贴到~/.claude/settings.json或复制到~/.claude/hooks/hooks.json因为仓库内文件面向插件/仓库安装命令路径需要按你的实际 Claude 根目录重写。正确做法是使用 ECC 安装器bash ./install.sh --target claude --modules hooks-runtime --enable-hookspwsh -File .\install.ps1 --target claude --modules hooks-runtime --enable-hooks安装后 hooks 会解析到~/.claude/hooks/hooks.jsonWindows 上为%USERPROFILE%\.claude。理解这一层后Rust 三件套可以有两种落地方案方案 A独立配置把第三节的 JSON 合并进~/.claude/settings.json的hooks.PostToolUse数组——适合只想给 Rust 项目加门禁、不引入完整 ECC 运行时的用户方案 B融入 ECC通过 ECC 运行时环境变量控制钩子行为与仓库内置钩子共存。运行时控制参见 hooks/README.md 的 Runtime Hook Controls 一节# 主开关显式环境变量覆盖插件偏好 export ECC_HOOKS_ENABLEDtrue # 钩子配置档位minimal | standard | strict默认 standard export ECC_HOOK_PROFILEstandard # 按 ID 禁用特定钩子逗号分隔 export ECC_DISABLED_HOOKSpre:bash:tmux-reminder,post:edit:typecheck # 只关闭 GateGuard如安装或恢复期间 export ECC_GATEGUARDoffminimal只保留必要的生命周期与安全钩子standard是均衡档strict会开启更多提醒与更严格的护栏。Rust 三件套属于质量检查型钩子按档位语义建议放在standard及以上。五、编写自己的 Rust Hook协议与退出码如果默认配置满足不了需求例如希望新写测试文件才允许创建源文件、超过 N 行就阻断可以按 ECC 的 Hook 协议自研。根据 hooks/README.md 的定义Hook 本质是从 stdin 读取 JSON、向 stdout 输出 JSON 的 shell 命令// my-rust-hook.js let data ; process.stdin.on(data, chunk data chunk); process.stdin.on(end, () { const input JSON.parse(data); const toolName input.tool_name; // Edit, Write, Bash ... const toolInput input.tool_input; // { file_path, old_string, new_string, ... } // 非阻断警告写 stderr console.error([Hook] Rust file edited — run cargo fmt before commit); // 阻断仅 PreToolUse 有效退出码 2 // process.exit(2); // 必须把原始数据回写到 stdout console.log(data); });退出码语义0表示成功继续2表示阻断工具调用仅 PreToolUse 生效其他非零值视为错误但只记录、不阻断。Hook 输入结构tool_name/tool_input.file_path/tool_input.new_string/ PostToolUse 独有的tool_output在 hooks/README.md 的 Hook Input Schema 一节有 TypeScript 接口定义。结合 Rust 场景一个实用的自定义钩子示例——编辑.rs文件后自动运行 rustfmt 并提醒 clippy{ matcher: Edit|Write, hooks: [ { type: command, command: node -e \let d;process.stdin.on(data,cdc);process.stdin.on(end,(){const iJSON.parse(d);const pi.tool_input?.file_path||;if(/\\.rs$/.test(p)){const{execFileSync}require(child_process);try{execFileSync(cargo,[fmt,--all],{stdio:pipe})}catch(e){console.error([Hook] cargo fmt failed: e.message)}console.log(d)})\, description: Auto-format .rs files with rustfmt after edits, timeout: 30 } ] }对长耗时检查例如大型 crate 的cargo check还可以声明为异步钩子避免拖慢主流程{ type: command, command: node my-slow-rust-check.js, async: true, timeout: 300 }异步钩子在后台运行不能阻断工具执行——适合通知类检查不适合必须通过才能继续的门禁。六、与测试、风格规则配合形成完整 Rust 工作流Rust Hooks 不是孤立存在的。ECC 的 Rust 规则体系把格式化 / lint / 编译 / 测试 / 提交串成了完整闭环编辑后PostToolUse 三件套兜底fmt→clippy→check提交前完整跑一遍 rules/rust/testing.md 定义的测试命令矩阵cargo test # 运行全部测试 cargo test -- --nocapture # 显示 println 输出 cargo test test_name # 按名称模式运行 cargo test --lib # 仅单元测试 cargo test --test api_test # 指定集成测试tests/api_test.rs cargo test --doc # 仅文档测试覆盖率门禁cargo llvm-cov --fail-under-lines 80强制行覆盖率不低于 80%rules/rust/testing.md 明确目标为 80%风格门禁cargo clippy -- -D warnings把警告当错误处理rules/rust/coding-style.md。ECC 自身也遵守同样的心智模型——它在 scripts/hooks/pre-bash-tmux-reminder.js 的正则中把cargo build列为典型的长时运行命令建议放进 tmux 以便查看日志而cargo check作为轻量验证则适合放在每次编辑后的 PostToolUse 里。这种长时命令进 tmux、轻量检查进钩子的取舍正是 Rust 三件套设计中用 check 代替 build的原因所在。七、注意事项与故障排查不要在非 Rust 项目里保留三件套cargo命令在无 Cargo.toml 的目录会立即失败。配合规则 frontmatter 的**/*.rs/**/Cargo.toml作用域理解建议用 matcher 精确限定或只在 Rust 仓库中启用对应配置。性能开销意识每次Edit|Write都跑cargo check在大型 crate 上会显著拖慢 Agent。可以降级为只跑cargo check -q静默模式、提高 timeout、或把 clippy 移到 Stop 阶段批处理ECC 的stop:format-typecheck正是每次编辑不跑、每轮响应末统一跑的代表。权限与自动接受通用规则rules/common/hooks.md提醒自动接受权限只在可信、定义明确的计划下开启探索性工作应关闭且永远不要使用dangerously-skip-permissions标志改用~/.claude.json中的allowedTools精确授权。Rust 钩子会触发 cargo 子进程务必确保这些命令在授权范围内。钩子被 ECC 覆盖若通过 ECC 插件安装且发现自定义钩子不生效检查 hooks/README.md 的禁用/覆盖方法——在~/.claude/settings.json中对同名 matcher 声明空数组hooks: []即可屏蔽插件钩子或用ECC_DISABLED_HOOKS按 ID 关闭。八、小结Rust Hooks 规则docs/ja-JP/rules/rust/hooks.md虽然只有短短几行却精准点出了 Claude Code Rust 协作中最有价值的三道自动化关卡cargo fmt统一风格、cargo clippy拦截坏味道、cargo check快速验证编译。结合 ECC 仓库 hooks/hooks.json 的生产级配置、hooks/README.md 的协议定义与运行时控制以及 rules/rust/coding-style.md、rules/rust/testing.md 的配套规范你可以把这三道关卡嵌入 Agent 的每一次文件编辑让写完即校验、问题即反馈成为 Rust 开发的默认体验——这正是 Agent 辅助编程时代规则驱动开发最务实的落地方式。【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 ECC 规则体系中的 Rust Hooks 实战：用 cargo fmt / clippy / check 搭建 Claude Code 自动化质量门禁
ECC 规则体系中的 Rust Hooks 实战用 cargo fmt / clippy / check 搭建 Claude Code 自动化质量门禁【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC在 Claude Code 的日常协作中Rust 开发者最常遇到的问题是Agent 每次编辑完.rs文件后缩进、lint 警告和编译错误常常被留到下一次手动检查。本文以 ECCEverything Claude Code开源仓库中的 Rust Hooks 规则 为核心系统讲解如何利用 PostToolUse 钩子在编辑器保存.rs文件后自动执行cargo fmt、cargo clippy与cargo check并结合仓库内真实的 hooks 配置与源码实现帮助你搭建一套编辑即校验、写错即反馈的 Rust 自动化质量门禁。读完本文你将掌握 Hook 的匹配器机制、配置语法、运行时控制方式以及如何将这些钩子与 ECC 的 hooks 运行时、规则分层体系无缝集成。一、规则文件的定位Rust 专用扩展层在 ECC 仓库中规则按语言分目录组织rules/rust/下包含 hooks.md、coding-style.md、patterns.md、security.md、testing.md 五个维度。日语本地化版本位于 docs/ja-JP/rules/rust/其中 hooks.md 的开头就声明了它的定位このファイルは common/hooks.md を Rust 固有のコンテンツで拡張します。本文件以 Rust 特有内容扩展 common/hooks.md也就是说ECC 采用通用基座 语言扩展的分层规则设计通用层rules/common/hooks.md 定义所有语言共用的 Hook 类型、权限策略与 TodoWrite 最佳实践语言层rules/rust/hooks.md 只补充 Rust 特有的 Hook 建议本地化层docs/ja-JP/rules/common/hooks.md 与 docs/ja-JP/rules/rust/hooks.md 提供日语翻译方便非英语开发者引用。这种分层意味着阅读 Rust Hooks 规则时必须同时理解通用 Hooks 系统的行为约定否则容易把该在哪一层配置搞混。规则文件顶部的 frontmatter 也值得注意--- paths: - **/*.rs - **/Cargo.toml ---paths声明了该规则的作用域——只对.rs源文件与Cargo.toml清单文件生效。这与 Hook 配置中的matcher参数相辅相成规则文件划定管哪些文件Hook 的matcher划定在哪些工具事件上触发。二、Hooks 系统基础理解 PreToolUse / PostToolUse / Stop在进入 Rust 配置之前先掌握 ECC 通用 Hooks 规则中的三类核心事件见 rules/common/hooks.mdHook 类型触发时机能力边界PreToolUse工具执行前可校验、可修改参数stderr 输出警告退出码 2 可阻断工具调用PostToolUse工具执行后可自动格式化、运行检查、分析输出不能阻断只能反馈Stop每轮 Agent 响应结束时最终校验如全量格式化、类型检查、会话状态持久化ECC 仓库的 hooks/hooks.json 是这套机制的完整生产级示例它把 Hook 事件扩展到了 7 类PreToolUse、PreCompact、SessionStart、PostToolUse、PostToolUseFailure、Stop、SessionEnd。其中PreToolUse注册了 Bash 前置分发器pre:bash:dispatcher、文档文件警告pre:write:doc-file-warning、配置保护pre:config-protection、MCP 健康检查pre:mcp-health-check等钩子Stop阶段则批量执行格式化与类型检查stop:format-typecheck、会话成本统计stop:cost-tracker、桌面通知stop:desktop-notify等。这套真实配置印证了一个重要设计思路轻量检查放在 PostToolUse 逐次执行重量级全量校验放在 Stop 批次执行——与 Rust 规则中编辑后跑cargo check、提交前跑完整构建的分层策略完全一致。三、核心配置Rust 的 PostToolUse 三件套Rust Hooks 规则docs/ja-JP/rules/rust/hooks.md给出的核心建议是在~/.claude/settings.json中配置三个 PostToolUse 钩子cargo fmt— 编辑.rs文件后自动格式化cargo clippy— 编辑 Rust 文件后执行 lint 检查cargo check— 变更后验证编译比cargo build更快。其背后是 Rust 官方工具链的标准分工rustfmt负责风格统一clippy负责代码质量 lintcargo check只做元数据解析与类型检查、不生成完整二进制因此能以远低于cargo build的成本提前暴露编译错误。ECC 的 rules/rust/coding-style.md 进一步强化了这一分工格式强制使用cargo fmtlint 使用cargo clippy -- -D warnings把警告升级为错误最大行宽 100 字符。将这三个工具落成可直接复制到~/.claude/settings.json的配置{ hooks: { PostToolUse: [ { matcher: Edit|Write, hooks: [ { type: command, command: cargo fmt --all, description: Auto-format Rust files with rustfmt after edits, timeout: 30 } ] }, { matcher: Edit|Write, hooks: [ { type: command, command: cargo clippy --all-targets --all-features -- -D warnings, description: Run clippy lints with warnings-as-errors after editing Rust files, timeout: 120 } ] }, { matcher: Edit|Write, hooks: [ { type: command, command: cargo check --all-targets, description: Verify compilation after changes (faster than cargo build), timeout: 120 } ] } ] } }配置要点逐条拆解matcher 选型Edit|Write覆盖了修改已有.rs文件和新建.rs文件两个场景。若只想在修改时触发可收窄为Edit若想连MultiEdit批量编辑也纳入则写Edit|Write|MultiEditECC 自身的 hooks/hooks.json 中大量使用matcher: Edit|Write|MultiEdit组合。命令选择cargo fmt --all会格式化当前工作区所有包保证多 crate 工作区风格一致cargo check --all-targets覆盖 lib、bin、test、example 等全部目标比裸cargo check更彻底。timeout 兜底PostToolUse 钩子理论上不阻断流程但卡死的命令仍会拖慢 Agent 响应务必给出合理超时。ECC 的钩子中 PostToolUse 分发器的超时被设为 30 秒同步与 45 秒异步见 hooks/hooks.json 的post:dispatcher:sync/post:dispatcher:async可作为参考基线。四、把配置放进真实环境ECC 的 Hook 运行时机制上面是裸配置写法。在 ECC 生态中Hook 并不是简单粘贴到 settings.json 就完事——hooks/README.md 明确警告不要直接把仓库里的hooks.json原样粘贴到~/.claude/settings.json或复制到~/.claude/hooks/hooks.json因为仓库内文件面向插件/仓库安装命令路径需要按你的实际 Claude 根目录重写。正确做法是使用 ECC 安装器bash ./install.sh --target claude --modules hooks-runtime --enable-hookspwsh -File .\install.ps1 --target claude --modules hooks-runtime --enable-hooks安装后 hooks 会解析到~/.claude/hooks/hooks.jsonWindows 上为%USERPROFILE%\.claude。理解这一层后Rust 三件套可以有两种落地方案方案 A独立配置把第三节的 JSON 合并进~/.claude/settings.json的hooks.PostToolUse数组——适合只想给 Rust 项目加门禁、不引入完整 ECC 运行时的用户方案 B融入 ECC通过 ECC 运行时环境变量控制钩子行为与仓库内置钩子共存。运行时控制参见 hooks/README.md 的 Runtime Hook Controls 一节# 主开关显式环境变量覆盖插件偏好 export ECC_HOOKS_ENABLEDtrue # 钩子配置档位minimal | standard | strict默认 standard export ECC_HOOK_PROFILEstandard # 按 ID 禁用特定钩子逗号分隔 export ECC_DISABLED_HOOKSpre:bash:tmux-reminder,post:edit:typecheck # 只关闭 GateGuard如安装或恢复期间 export ECC_GATEGUARDoffminimal只保留必要的生命周期与安全钩子standard是均衡档strict会开启更多提醒与更严格的护栏。Rust 三件套属于质量检查型钩子按档位语义建议放在standard及以上。五、编写自己的 Rust Hook协议与退出码如果默认配置满足不了需求例如希望新写测试文件才允许创建源文件、超过 N 行就阻断可以按 ECC 的 Hook 协议自研。根据 hooks/README.md 的定义Hook 本质是从 stdin 读取 JSON、向 stdout 输出 JSON 的 shell 命令// my-rust-hook.js let data ; process.stdin.on(data, chunk data chunk); process.stdin.on(end, () { const input JSON.parse(data); const toolName input.tool_name; // Edit, Write, Bash ... const toolInput input.tool_input; // { file_path, old_string, new_string, ... } // 非阻断警告写 stderr console.error([Hook] Rust file edited — run cargo fmt before commit); // 阻断仅 PreToolUse 有效退出码 2 // process.exit(2); // 必须把原始数据回写到 stdout console.log(data); });退出码语义0表示成功继续2表示阻断工具调用仅 PreToolUse 生效其他非零值视为错误但只记录、不阻断。Hook 输入结构tool_name/tool_input.file_path/tool_input.new_string/ PostToolUse 独有的tool_output在 hooks/README.md 的 Hook Input Schema 一节有 TypeScript 接口定义。结合 Rust 场景一个实用的自定义钩子示例——编辑.rs文件后自动运行 rustfmt 并提醒 clippy{ matcher: Edit|Write, hooks: [ { type: command, command: node -e \let d;process.stdin.on(data,cdc);process.stdin.on(end,(){const iJSON.parse(d);const pi.tool_input?.file_path||;if(/\\.rs$/.test(p)){const{execFileSync}require(child_process);try{execFileSync(cargo,[fmt,--all],{stdio:pipe})}catch(e){console.error([Hook] cargo fmt failed: e.message)}console.log(d)})\, description: Auto-format .rs files with rustfmt after edits, timeout: 30 } ] }对长耗时检查例如大型 crate 的cargo check还可以声明为异步钩子避免拖慢主流程{ type: command, command: node my-slow-rust-check.js, async: true, timeout: 300 }异步钩子在后台运行不能阻断工具执行——适合通知类检查不适合必须通过才能继续的门禁。六、与测试、风格规则配合形成完整 Rust 工作流Rust Hooks 不是孤立存在的。ECC 的 Rust 规则体系把格式化 / lint / 编译 / 测试 / 提交串成了完整闭环编辑后PostToolUse 三件套兜底fmt→clippy→check提交前完整跑一遍 rules/rust/testing.md 定义的测试命令矩阵cargo test # 运行全部测试 cargo test -- --nocapture # 显示 println 输出 cargo test test_name # 按名称模式运行 cargo test --lib # 仅单元测试 cargo test --test api_test # 指定集成测试tests/api_test.rs cargo test --doc # 仅文档测试覆盖率门禁cargo llvm-cov --fail-under-lines 80强制行覆盖率不低于 80%rules/rust/testing.md 明确目标为 80%风格门禁cargo clippy -- -D warnings把警告当错误处理rules/rust/coding-style.md。ECC 自身也遵守同样的心智模型——它在 scripts/hooks/pre-bash-tmux-reminder.js 的正则中把cargo build列为典型的长时运行命令建议放进 tmux 以便查看日志而cargo check作为轻量验证则适合放在每次编辑后的 PostToolUse 里。这种长时命令进 tmux、轻量检查进钩子的取舍正是 Rust 三件套设计中用 check 代替 build的原因所在。七、注意事项与故障排查不要在非 Rust 项目里保留三件套cargo命令在无 Cargo.toml 的目录会立即失败。配合规则 frontmatter 的**/*.rs/**/Cargo.toml作用域理解建议用 matcher 精确限定或只在 Rust 仓库中启用对应配置。性能开销意识每次Edit|Write都跑cargo check在大型 crate 上会显著拖慢 Agent。可以降级为只跑cargo check -q静默模式、提高 timeout、或把 clippy 移到 Stop 阶段批处理ECC 的stop:format-typecheck正是每次编辑不跑、每轮响应末统一跑的代表。权限与自动接受通用规则rules/common/hooks.md提醒自动接受权限只在可信、定义明确的计划下开启探索性工作应关闭且永远不要使用dangerously-skip-permissions标志改用~/.claude.json中的allowedTools精确授权。Rust 钩子会触发 cargo 子进程务必确保这些命令在授权范围内。钩子被 ECC 覆盖若通过 ECC 插件安装且发现自定义钩子不生效检查 hooks/README.md 的禁用/覆盖方法——在~/.claude/settings.json中对同名 matcher 声明空数组hooks: []即可屏蔽插件钩子或用ECC_DISABLED_HOOKS按 ID 关闭。八、小结Rust Hooks 规则docs/ja-JP/rules/rust/hooks.md虽然只有短短几行却精准点出了 Claude Code Rust 协作中最有价值的三道自动化关卡cargo fmt统一风格、cargo clippy拦截坏味道、cargo check快速验证编译。结合 ECC 仓库 hooks/hooks.json 的生产级配置、hooks/README.md 的协议定义与运行时控制以及 rules/rust/coding-style.md、rules/rust/testing.md 的配套规范你可以把这三道关卡嵌入 Agent 的每一次文件编辑让写完即校验、问题即反馈成为 Rust 开发的默认体验——这正是 Agent 辅助编程时代规则驱动开发最务实的落地方式。【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考