厂商视角这是官方教程,口吻偏推广:强调「fun」「nothing new to learn」,鼓励发 X/LinkedIn,并引导用户把 mod 提交到 claude.ai/directory。「Claude Code 自身功能也用 mod 写」这一说法既是能力背书,也是营销。
自己验证到 anthropics/claude-code 公开仓库的 mods/ 目录,读 AGENTS.md 支持和 /diff pane 的源码与测试,核对它们用的是否就是文中公开的 $ API,有没有私有接口。
数字口径Token Weather 里的百分比是「上一次回答所基于的输入」除以窗口(¶29),不包含本轮将产生的输出,也不是 auto-compact 的实际触发点。「Compact soon」的阈值 90% 是作者自己设的,测试里的 200k 窗口也是 stub 值。「about 80 lines」是粗略的说法。
自己验证在同一个会话里对比 mod 显示的 percent 和状态栏、/usage 的读数,再观察自动压缩实际发生时的百分比,看和 90% 的阈值有多大偏差。
可复现性validate 和 test 的输出、热重载行为、$.state 撑过重载、pane 在窄终端退化成 band,都可以在本机复现。前提是 CLI 版本达到 2.1.287,而本机 claude update 会被 SNI 阻断。
自己验证挂代理升级后 claude --version,照着 ¶20–¶45 从空目录搭 token-weather,执行 claude plugin validate ./token-weather 和 claude plugin test ./token-weather,比对输出和 ¶42、¶43 是否一致。另外故意用模块变量存状态,保存一次,确认历史会清零。
遗漏文章没有讲 headless 或无人值守场景:不带 UI 时 ui.render 钩子怎么处理,hold 型钩子(只要 next.signal 不中止就无限等待)会不会让 claude -p 卡住。
自己验证写一个最小 mod:turn.complete 时把一行写进日志,另加一个 tool.call 永远等待的分支。
遗漏安全模型只有一句「像装包一样谨慎」:没说签名或完整性校验,没说 directory 的审核标准,也没说 push 更新后已安装的用户会不会自动拉取新代码。沙箱只说了没有 DOM 和 Node,没说 $.process.run、$.fs、$.http 的权限边界。
自己验证查官方 plugin 和 marketplace 文档,确认有没有签名、版本锁定和自动更新策略。实测一个 mod 能否用 $.process.run 读 ~/.claude.json(里面存着 qcc 的 API key),以此评估凭据暴露面。
遗漏文章没讨论 mod 对成本和缓存的影响:prompt.submit 改写每条提示、注册模型可调用的工具、热重载期间工具集合变化,都可能改动提示前缀,从而影响缓存命中(推断)。
自己验证在同一任务上分别开、关一个会 prompt.submit 注入文本的 mod,对比 /usage 里的缓存占比;再在会话中途用热重载新增一个 tool,观察缓存读数的变化。