Claude Code Mod 实测：给编程助手做一个自定义面板

Claude Code Mod 实测：给编程助手做一个自定义面板 — woshipm.com · 19 小时前 · 🛠 工具 / 开源

Claude Code 新上线的 Mod 功能把扩展能力从进程外搬进了进程内，文章要解决的问题是：怎样给终端里的编程助手做一套自定义界面，并在命令真正落地之前把它拦下来。作者用六个步骤搭出一个「雨姐」主题 Mod，全程可复现：核心只有三个文件，.claude-plugin/plugin.json 声明名称、版本与作者，hooks/hooks.json 用一行 modules 指向 register.tsx，register.tsx 导出 register 函数并在其中挂载钩子；把目录放进当前会话专属的 ~/.claude/dev-mods/，或在启动时用 claude --plugin-dir ./yujie 加载即可。Mod 通过订阅运行时事件工作，session.start 用来注册 yujie 命令、写状态栏并打开面板，ui.render 配合 AbovePrompt 组件在输入框上方渲染雨姐的台词，tool.call 则用于在命令执行前判断风险，像 rm -rf node_modules 这样的删除操作会被直接拦下，并让面板里「拦下」那一栏计数加一。作者的结论是，Mod 与 Skill、MCP、settings 里的 hooks 有本质区别：前三者都站在 Claude Code 外面，Mod 则是运行在 Claude Code 进程内的 JavaScript 或 TypeScript 代码，因此能直接绘制贴住对话的面板、输入框上方的提示条、底部状态栏，以及角落里几秒就消失的 toast。

核心信息

一个可用的 Mod 最小结构只有三样东西：.claude-plugin/plugin.json 负责声明名字、版本和作者，hooks/hooks.json 只写一行把 modules 指向 ./register.tsx，真正的逻辑全部落在 register.tsx 里。register.tsx 导出一个 register 函数，Claude Code 在加载这个 Mod 时调用它一次，雨姐的「工位」就在这次调用里搭好。目录可以直接放在当前会话专属的 ~/.claude/dev-mods/ 下，也可以自建文件夹后用 claude --plugin-dir ./yujie 在启动时加载；如果让 Claude 代写，它会调用自带的 plugin-authoring 技能，并在写入第一个文件时询问是否为该会话开启热重载。
Mod 之所以知道什么时候该画、什么时候该动，是因为 Claude Code 运行时持续产生事件：会话开始是 session.start，用户按下回车是 prompt.submit，Claude 准备跑命令或改文件是 tool.call，界面要渲染某一块是 ui.render，一轮回答结束是 turn.complete。Mod 的工作方式就是在这些事件上挂函数，也就是钩子。以雨姐为例，session.start 里一次完成三件事：注册名为 yujie 的命令、把底部状态栏写成「雨姐在岗 · 铁锅已热」、打开 id 为 yujie 的面板。
Mod 能直接操作界面，可用的绘制位置包括贴着对话的面板 Pane、输入框上方的提示条 AbovePrompt、底部状态栏，以及角落里几秒就消失的 toast。文章在 ui.render 事件上以 AbovePrompt 为组件挂了一个钩子，通过 $.ui.resolve 取出 Box 与 Text，把雨姐的台词渲染成粉色的一行，颜色值写作 #e0567a。正因为能改动这些位置，Mod 才和只输出文本的扩展方式拉开差距——界面元素由 Mod 自己画出来，而不是由宿主程序固定展示。
安全演示是这篇文章的重点之一：当 Claude 试图执行 rm -rf node_modules 时，雨姐会在命令真正落到终端之前把它拦下，并在面板的「拦下」一栏把计数加一。这个能力同样来自 tool.call 事件上的钩子，说明 Mod 不只是换一层皮，它处在命令执行链路的中间，具备判断与阻断的位置。文章给出的加载路径和事件清单都相当具体，读者照着三个文件和一次 register 调用就能复现一套自己的主题面板，也能把拦截规则换成自己真正关心的危险操作。

💡 为什么值得读: 想知道终端里的编程助手能被改造成什么样，这篇带完整文件结构、事件清单和启动参数的实测可以直接照着复现，还顺手演示了如何在命令执行前把它拦下来。

✍️ 小编看法: 小编看法：终端助手开始长出「界面」这件事，比多一个换肤玩法要重要得多。过去我们给编程助手加能力，路径无非是写说明文档、接外部工具、在固定时机跑脚本，它们都站在助手进程外面，只能影响它读什么、调什么，很难影响你在屏幕上看到什么、在按下回车之后发生什么。把扩展代码放进同一个进程，等于把最后这道缝也补上了：提示条可以变成团队规范的口播位，状态栏可以常驻当前分支和待办数量，面板可以做成审查清单，而 tool.call 上的拦截点则是最实在的一处——它让「先问一句再删」从口头约定变成了默认行为。但代价也在这里。跑在进程内的代码天然离敏感数据更近，能读会话内容、能改渲染、能阻断或放行命令，一旦装的是来源不明的 Mod，风险远高于装一个只读的工具连接器。更现实的问题是碎片化：每个团队各写一套面板，规范和拦截规则散落在各自仓库里，新人接手时未必知道哪条命令被谁悄悄放行。另外，界面定制一旦过度，终端那点宝贵的垂直空间很快会被台词和徽章吃掉，反而拖慢阅读。接下来值得盯的是三件事：Mod 的分发与签名机制会不会出现，权限声明能否细到「可拦截但不可读内容」，以及热重载下的调试体验能不能撑住真实项目。对普通用户来说，先拿它做拦截和状态提示，别急着把整个工作流搬进面板，是更稳的起步方式。

🏷️ Claude Code, mod, AI coding, safety