团队使用 AI 编码工具时很多问题并不是模型不会写代码而是团队规则没有进入执行路径。比如不要运行危险删除命令、不要提交调试输出、不要编辑敏感文件、停止前必须跑测试。这些规则如果只靠口头提醒很容易在高频开发中失效。plugins/hookify给出的思路是把规则写成轻量 Markdown 文件由 Hook 在对应事件中执行。它降低了 Hook 的使用门槛让用户不需要直接维护复杂的hooks.json。Hookify 解决什么问题Hookify 的核心目标是快速创建自定义 Hook用来阻止或提醒不符合预期的行为。它支持两类入口用户直接描述规则例如/hookify Dont use console.log in TypeScript files。用户运行/hookify让工具分析近期对话中反复被纠正的问题并生成规则。生成的规则通常存放在.claude/hookify.*.local.md中。文件使用 YAML frontmatter 描述匹配条件正文则是触发后展示给 Claude 或用户的提示信息。一个规则由哪些字段组成最简单的规则包含名称、启用状态、事件、匹配模式和动作--- name: block-dangerous-rm enabled: true event: bash pattern: rm\s-rf action: block --- 检测到危险删除命令。请先确认路径、影响范围和备份情况。event决定规则在哪类事件上触发。Hookify 支持bash、file、stop、prompt和all。action决定触发后的行为warn表示提醒但允许继续block表示阻断执行。这种格式有两个好处。第一规则是文本容易审查和分享。第二规则内容和触发提示放在同一个文件中维护成本很低。从单条件到多条件单个正则适合处理明确模式例如rm\s-rf、console\.log\(、chmod\s777。但团队规则往往需要组合条件例如只在编辑.env文件且新增内容包含密钥关键词时提醒。Hookify 支持conditions可以同时检查文件路径、文本内容、会话记录等字段。所有条件都满足时规则才会触发。这比只靠一个大正则更容易维护也更能表达真实意图。warn 与 block 的取舍不是所有规则都应该阻断。对于调试语句、注释风格、测试提醒这类问题warn通常更合适因为它保留了开发者的判断空间。对于会造成数据丢失、泄露密钥或破坏仓库状态的操作block更合适。一个实用原则是不可逆或高代价操作用block可修正或依赖上下文判断的问题用warn。适合沉淀为 Hookify 规则的场景第一类是安全边界。比如禁止读取.env、credentials、secrets提醒不要硬编码 API Key阻止危险 shell 命令。第二类是工程规范。比如不允许在 TypeScript 中留下console.log要求 Python 变更后运行对应测试提醒生成代码时不要绕开项目既有抽象。第三类是团队偏好。比如提交信息格式、文档风格、生成文件目录、是否允许自动安装依赖等。只要规则有明确触发条件就可以逐步转成 Hookify 文件。Hookify 的真正价值Hookify 并不是要取代代码审查或 CI。它的价值在于把错误拦在更早的位置在命令执行前、文件写入时、会话结束前就给出反馈。这类反馈越靠近行为发生点修正成本越低。对于 AI 编码工具尤其如此因为一次会话可能连续执行多个步骤。如果规则只在最终 PR 审查时出现很多问题已经扩散到多个文件如果规则在工具调用前就触发模型可以立刻调整路径。对团队来说Hookify 最适合从小规则开始。先沉淀那些重复被提醒、判断标准明确、影响范围可控的问题再逐步扩大到更复杂的策略。这样既能避免规则系统过度设计也能让 Claude Code 的行为更贴近团队真实工作方式。