Rule-identifier ：把团队编码规范写成 Hookify 规则

你让 Claude 帮你写了一下午代码，临近提交时例行扫了一眼 diff，差点心梗。三个 console.log 裸奔在页面脚本里，硬编码的 API 密钥藏在环境变量文件里，还有一个 rm -rf 连着绝对路径虎视眈眈。这已经不是 Claude 不行的问题了，它写完代码就下班了，但审查是你的事。

AI agent 干活的场景越来越密，但”守规矩”这件事对模型来说是个盲区。它不知道你们团队禁 eval()，不知道 .env 不能提交，不知道跑 chmod 777 意味着运维半夜找你。这些约束靠人肉 code review 来兜底，要么漏，要么慢，要么在凌晨三点打过来。

Anthropic 团队显然意识到了这个缺口。他们在 Smithery 上发布的 rule-identifier，本质不是给用户用的工具，是教你给 Claude 写”家规”的指导手册。这个 Skill 本身不执行任何规则，它负责告诉你 Hookify 规则的语法、触发点、匹配逻辑和最佳实践。有点像交警培训手册，不是红绿灯本身，但没有它你就不知道该把灯立在哪。

这篇文章会从零走完 rule-identifier 的启动流程：理解它的设计逻辑，写出第一条规则，验证它真的能拦住 AI 的危险操作，然后思考这套机制在整个 AI agent 开发流程里的位置和边界。

环境准备

前置条件不重。你需要一个已经跑起来的 Claude Code 或支持 Hookify 的 AI agent 环境，项目根目录下有一个 .claude/ 文件夹。rule-identifier 本身不需要安装任何依赖，它是一个纯文本的元技能，你甚至不需要从 Smithery 拉取它，记住规则格式就能直接手写。

在 Smithery 上安装的话，点一下 Install 按钮就行，之后 rule-identifier 会作为一个可调用的 Skill 出现在你的 Claude 环境中。调用它的时候，它会根据你的需求输出一条完整的 Hookify 规则文件。手动模式更直接：在项目根目录下创建一个 .claude/hookify.{规则名}.local.md 文件，把 YAML frontmatter 和提示消息填进去，保存即生效。

命名有讲究。hookify.{描述性名称}.local.md 这个格式不是 Anthropic 拍脑袋定的。hookify. 前缀让文件管理器一眼能认出这是什么，.local.md 后缀则意味着它是本地专属且应该被 .gitignore 拦截。推荐在 .gitignore 中加一行 *.local.md，规则里可能包含团队内部敏感信息，不该推上公开仓库。

验证环节来条最小规则试试水。创建一个 hookify.dangerous-rm.local.md，在 pattern 里填 rm\s+-rf，event 设 bash，消息里写一句红色警告。保存后在 Claude 里输入 rm -rf /tmp/test，如果弹出了你写的那条警告，说明整个链路通了。如果没弹，检查一下 YAML 引号有没有写反，这是最容易踩的坑。

操作流程

第一步是找对你要盯的行为。不是所有代码问题都适合用 Hookify 规则来拦截。适合用规则管的事有三个特征：可被正则匹配、后果严重、人肉审查容易漏。落到具体类别上，最常见的是这三类：

• 危险 shell 命令：rm -rf、sudo、chmod 777
• 安全敏感代码：eval()、innerHTML、dangerouslySetInnerHTML
• 不该被修改的文件：.env、证书文件、node_modules/

第二步是选事件类型。rule-identifier 支五种 hook 触发点：bash 监听命令行输入，file 监听文件编辑操作，stop 在 agent 准备结束时触发，prompt 在用户提交提示词时触发，all 覆盖全部四种。大部分实操场景用 bash 和 file 就够了，stop 适合加完成检查清单，prompt 适合对特定类型的请求做预拦截。选错了事件类型，规则写得再好也不会触发。

第三步写正则或条件组。最简单的格式是在 pattern 字段直接写一条正则，比如 rm\s+-rf，适合单条件场景。需要同时检查多个条件时切到 conditions 数组格式，比如”编辑的文件是 .tsx 且新内容包含 console.log“，这意味着只有 TypeScript 文件中的 console.log 才会触发，不影响 .js 或测试文件里的调试输出。条件之间是 AND 关系，全满足才触发。

第四步写触发后的提示消息。这部分直接决定 Claude 看到规则触发后会怎么反应。一条好的提示消息有三个层次：先告诉它检测到了什么，再解释为什么这是个问题，最后给出替代方案。比如检测到 console.log，消息里可以说”生产代码里留 console.log 会污染控制台且暴露内部状态，换成 logging 库或条件编译的 debug 输出”。消息写得越具体，Claude 的行为调整越精准。

第五步是关键。保存 .local.md 文件后规则立即生效，不需要重启或重载。触发一次你要打开的文件看看能不能匹配，再调整下模式或者补充下消息。Hookify 规则的迭代成本很低，改一下 pattern 再跑一下就行。如果误报多了就把正则收紧一点，如果漏了就把匹配范围拓宽。这个过程很像给 ESLint 写自定义规则，只是一条规则写完就能生效，没有 CI 之类的环节。

关键设计

rule-identifier 的设计里有个让我反复琢磨的选择：它不是一个”规则执行器”，而是一个”规则编写指导”。它的 SKILL.md 全文都在教语法、讲范例、列踩坑，但自己不跑任何匹配逻辑。这种”元技能”的定位在整个 Smithery 生态里都不多见，但它触及了一个更根本的问题：AI agent 的约束机制，到底是靠工具还是靠知识？

YAML frontmatter 做配置层是 Hookify 规则系统最聪明的决策。四个必填字段加上两个可选扩展，把一条规则的元数据和提示内容做了物理切割：

• 必填：name、enabled、event、pattern
• 可选：action（控制 warn 还是 block）、conditions（多条件复合匹配）

配置在前端信息区，提示内容在 Markdown 正文里，读规则文件的时候不需要翻来翻去找逻辑，也没有 JSON 配置那些引号地狱。enabled 字段的存在意味着你可以暂时关掉某条规则但不删除，这在调试规则组合的时候极其实用。

两种匹配格式的共存也是刻意为之。pattern 单条件格式覆盖 80% 的日常场景，写起来像记一行正则笔记。conditions 数组格式解决需要跨字段组合判断的复杂需求，它引入了两个核心维度：

• field：指定检查对象（命令文本、文件路径、新旧内容）
• operator：指定匹配方式（正则匹配、包含、等值、前缀、后缀）

两条条件之间是 AND 关系，全满足才触发。这种设计在易用性和灵活性之间找到了一个舒服的点，简单场景不强迫你写条件数组，复杂场景不会被单行正则卡死。

warn vs block 的默认策略也值得说一句。默认是 warn，展示消息但不阻断操作。这个默认值选得很聪明，一条首次部署的规则总会有预期之外的匹配，如果上来就 block，等于把自己锁在了代码外面。先用 warn 跑几天，观察误报率，确认模式没问题再切 block。这个操作逻辑很像运维里的灰度发布，只不过发行内容从代码换成了规则。

使用场景

第一个日常用法就是拦截危险命令。假设你们团队有个不成文的规矩，禁止在服务器上直接跑 rm -rf，但新来的 Claude 显然不知道。用 event: bash 加 pattern: rm\s+-rf 配上 action: block，一条规则就完成了从”口头约定”到”机器强制”的转化。更精细的做法是把 sudo、chmod 777、mkfs 这些高危操作也挂上规则，每个危险命令各写一条，这样触发消息可以给出更具体的替代建议。

第二个典型场景是管代码质量。console.log、debugger、print() 这些调试语句从研发阶段溜进生产分支的概率远超你的想象。用 event: file 加 conditions 格式精确锁定目标文件类型和代码模式，比在 ESLint 配置里加规则快得多。而且 Hookify 规则会直接在对话窗口里拦住 Claude，而不是等到你提交代码后才在 CI 管道里报错。这个时间差的缩短，实际效果远超你第一时间的想象。

第三个场景比较巧妙：用 stop 事件加完成检查清单。Claude 准备结束一个任务时，你可以塞一条规则提醒它检查测试是否跑通、文档是否更新、.local.md 文件有没有被意外提交。这种”出发前检查单”式的用法虽然简单，但在多任务并行的工作流里避免了大量的遗漏和返工。把团队共识从”应该”变成”必须”，靠的就是这条小小的 stop 规则。

还有一种组合用法很少被提及，但实际威力很大。你可以针对项目写一套基础规则（拦截危险命令 + 代码规范），再为每个特定模块写补充规则（数据库操作检查、API 端点约束），最后用 enabled: true/false 按不同的开发阶段切换规则组。这种模块化程度已经接近于 lint 配置的灵活性了，只是 Hookify 的规则生效在对话层而非 CI 层。

洞察与反思

写了几条规则之后我才意识到，rule-identifier 真正的价值不是帮你写出一两条规则，而是让你习惯用一种”规则思维”来审视 AI agent 的行为边界。你开始下意识地问自己：Claude 做的这件事，如果出错会造成什么后果？能不能用一条正则把它框住？这种从”事后审查”到”事前约束”的思路转变，比任何一条具体规则都重要。

但正则匹配的灰度问题绕不开。rm\s+-rf 能拦截 rm -rf /，但拦不住 rm -rf / 里两个空格变三个空格的情况。你当然可以通过正则把空白符匹配范围放宽，但放宽意味着误报率上升。hook-identifier 对此的回应很诚实：它没给什么银弹解法，建议就是测试、调整、再测试。这种不假装问题不存在的态度，反而让我更信任这套机制。

边界也很清楚。Hookify 规则只能拦截工具调用层的操作，它管不到 Claude 在你代码里把变量名从 userId 改成 user_id 这个级别的行为。它不是类型检查器，不是文档生成器，不是性能分析器。它能做的事是”禁止 X”和”警告 Y”，不能做的事是”推导 Z”。把这个边界搞清楚了，就不会对它产生不切实际的期望。

如果你已经在用 ESLint、Prettier、Husky 这些前端工程化工具，Hookify 规则是在对话层面补上了最后一环。传统工具拦截在 CI 或 commit hook，Hookify 拦截在写代码的那一刻。这种”越早拦截”的逻辑，做过程序质量管控的人都懂它的价值。不是替代现有工具链，而是往更上游走一步。

资源地址

总结

从识别一个危险操作，到选出合适的事件类型，到写出可用的正则，再到测试迭代，rule-identifier 把”写 AI 规则”这件事的成本压到了相当低的水平。它不需要配置服务器，不要求安装运行环境，存一条 YAML 就生效。这种轻量感在 AI 工具链里不算稀有，但结合上 Anthropic 对 Hookify 系统的整体设计，规则的即时性和可组合性才是真正的杀伤力。

下一步的延展方向有两个。向内走，把项目里所有”口头约定”和”code review 常见评论”都转化成 Hookify 规则，建一套属于你们团队的本地规则库。向外走，把那些验证过的高频规则（比如禁止提交密钥、检查测试覆盖率）开源成共享模板，让规则从个人习惯变成社区共识。

说真的，一个连删除命令都要让你手动审查的 AI agent，不配叫”靠谱”。rule-identifier 给了你工具去教会它什么叫规矩，剩下的就看你了。