Claude Code 能改自己的界面，我先不让它改决定

Hello，我是飞飞。

你有没有想过，让 Claude Code 在输入框上面，直接显示当前上下文还剩多少？或者让它把这次改过的文件，放在对话旁边，随时翻给你看。

Claude Code 的 Mods 就是冲着这类事来的。它可以加界面，也可以介入工具调用。你安装的那段代码，进的是同一个会话。

所以我会先试着看清它做了什么，再考虑让它替我做决定。

我还没有装过或实测这次的 Mod。这篇先核官方文档和公开源码，再拿自己的写作流程对照。这里提到的新用法，是我准备怎样选，不是已经跑过的结果。

一段代码能做什么

Anthropic 的介绍把 Mod 放在插件里。你可以自己写，也可以安装别人打包好的插件。它里面的 JavaScript 或 TypeScript 函数，会在 Claude Code 的会话事件发生时被调用。

比如 Claude 准备调用工具、用户发来一条消息、界面准备画出某一行，这些都可能成为扩展点。

官方概览把处理事件的动作分成三类：观察、改写、接管。观察之后让原来的流程继续；改写事件再交给后续环节；也可以自己给出结果，原本的处理就不必再跑。

这三种动作听起来只差几个词，影响却不一样。

只记录“这轮改了哪些文件”，属于观察。改掉准备执行的工具参数，已经介入了行为。直接返回一个结果，则更进一步：用户在会话里看到结果时，得知道到底是哪段代码产生的。

界面也是如此。官方示例有一个显示上下文占用的状态条。它把每轮的变化摆在输入框旁边，不用你反复找。另一个内置例子是 /diff，把会话里未提交的文件改动列在对话旁边。

这个界面能帮你看改了什么，但不能替你判断改得对不对。一个文件旁边有漂亮的变更视图，也还得看内容、跑检查。

跟原来的 Hook 差在哪

我以前写过一篇 Claude Code Hooks 入门。那时我在项目规则里要求每次修改代码后跑类型检查，长会话压缩后有一次被跳过。错误跟着代码提交，第二天上线出了问题。

这件事让我想把重要检查从一句提醒，变成更明确的流程。可回看旧文，我当时把 Hook 的效果说得太满了。

设置里的 Hook 可以在某些事件发生时运行命令，也可以处理提示或其他支持的动作。当前官方参考说明，PreToolUse 这样的工具调用前事件，可以阻止调用，也可以提出修改后的参数。不能说原来的 Hook 只能看、完全不能改。

而 PostToolUse 是工具完成之后发生的事。它能报告问题、让后续流程看到错误，但已经完成的文件写入，并不会因为它后来报错就自动消失。检查失败后怎么处理，还得看具体配置和调用方。

旧文记下了那次漏检，但我手上没有当时完整的 Hook 配置与执行记录。不能把它写成“加了某个 Hook，就证明以后永远不会漏”。要判断某一关是否有效，得看它有没有启用、匹配什么事件、失败后谁接住结果。

Mods 的不同，是处理函数在 Claude Code 内部参与事件链。它能在一次会话里共享状态，画自己的面板，还能接管部分事件的结果。一个已有脚本能解决的格式检查，我没理由仅为了换个名字就重写一遍。

反过来，如果想在会话旁边实时显示每一步的状态，或者需要围绕一次调用记录前后变化，Mod 才有更具体的用途。先看要做的事，再决定用哪一种扩展。

我会先显示哪件事

我的写作流水线里，选题、资料、文章、润色、评阅和分发有各自的规则。文章还要过字数、摘要、平台元数据等检查。它们各做一段工作，不代表每一步天然有一个实时仪表盘。

最近一次写作流程里，助手运行脚本核对了正文与 Obsidian 副本是否一致。正文改过，副本没跟上，下一次再引用时就可能读到旧稿。这个检查项目里已经有脚本，运行后能报告一致、漂移或拒绝回写。

假如以后在 Claude Code 做一个只读面板，我想先让它显示这三个结果：文章契约有没有通过、副本是否一致、各平台文件有没有生成。点开某一步，能看到脚本给出的状态和输出位置。

这里要强调，面板只是我想做的方案。我还没写这个 Mod，也没证明它能在每种会话界面显示。官方说终端和桌面有界面支持，但具体组件、版本与运行入口还得按实际环境确认。

面板本身不会让检查自动变真。脚本没跑，就写“未检查”；脚本失败，就显示失败。不能因为绿色面板能画出来，就把没有执行过的验收写成通过。

至于“检查失败时自动改稿”“替我批准下一步”，我暂时不想一起交出去。前者可能动到刚被人工确认的内容，后者会把一次需要判断的动作变成默认决定。有没有必要，需要先看那份只读状态是否真的帮我减少遗漏。

安装前看什么

这次助手在本机终端查到 Claude Code 是 2.1.312。官方文档称，终端版从 2.1.287 起默认支持已安装的 Mods。版本够新，说明可以继续检查，不代表我这次已经加载了某个 Mod。桌面应用有自己的版本，我也没有在这次核对它。

看来源时，先分清内置和外来的。Anthropic 在 Claude Code 仓库公开了部分内置 Mod 的源码和测试；社区作者也能把自己的 Mod 装进插件发布。两者都叫 Mod，作者和维护责任却不一样。

官方文档说得很直接：Mod 使用当前用户的权限，能读写用户可访问的文件、发起网络请求，也可能接触会话内容和环境变量。它的代码结构有限制，不等于它被关在一个无法碰到本机的安全盒里。

安装前，我会打开源码，先看它订阅了哪些事件，是否读文件、启动进程或访问网络。选定候选插件目录后，可以按官方文档运行 claude plugin validate <插件目录>，列出它处理的事件和调用；这能帮助审查，但列表本身不是安全保证。读完再决定是否信任作者和来源。

权限也不能一概而论。官方说明，组织托管设置或 Team、Enterprise 登录下，默认的 sec-default 会限制用户安装的 Mod 绕过部分既有审批规则。个人使用和有托管策略的环境不能直接画等号。我这次没有核查自己的组织策略，也不假定它已经替我挡住所有动作。

有个关停细节同样容易漏：官方说，安全模式等方式可以停掉用户安装的 Mod，但内置 Mod 有自己的行为和设置。想知道当前会话加载了什么，可以在对应会话里打开 /plugin 查看；光看某个配置文件，不能证明全部插件都没运行。

先把检查结果摆出来

回到写作这件事，我最想要的其实不是一个会代替我点头的扩展。我想看见：文章刚改过，副本还没同步；分发已经生成，摘要检查却还没跑。

这些状态都得来自真实检查。显示和实际执行分开记，失败和未执行也分开写。这样我才知道手里还有哪一步没做，而不是被一个看上去很完整的界面安慰。

Mods 把 Claude Code 的会话打开了一个更灵活的扩展入口。它的吸引力很具体：有些以前要切窗口、翻日志才能找到的信息，可以放到做事的地方。

我会先从只读状态开始。等我有机会真写一个、加载一个，再回来告诉你它漏过什么、帮上了什么。现在，我手里有的是官方资料和旧流程，还没有这次的使用数据。

如果你也用 Claude Code，你最想把哪一条信息放在会话旁边：上下文占用、文件改动，还是某个检查是否通过？