[建议] 仓库体积过大：将大尺寸 PNG 截图转换为 WebP

问题描述

仓库体积约 5.4G（本地工作目录），其中构建产物（docs/.vitepress/dist 1.2G + docs/.vitepress/dist-locales 2.9G）占 4.1G，但根源是文档中的高分辨率 PNG 截图。它们同时放大了 Git 体积、构建产物和页面加载体积。

事实数据

• 测试环境：本仓库通过 git clone --depth=1 https://github.com/GeoDaoyu/easy-vibe.git 拉取（浅克隆，仅下载最新提交），以下体积数据均在此环境下测得。
• Git 体积与历史无关：即便浅克隆只含最新提交快照，.git/ 依然有 465M，且这 465M 几乎全是当前版本的图片（pack 内含 HEAD 快照的全部对象）——说明体积问题纯粹来自当前图片太大，不是历史累积。源仓库完整克隆只会更大（历史中历次图片的旧版本 blob 仍在）。
• 源图片：docs/zh-cn/ 下共 1268 张图片、约 462M，其中 1063 张是 PNG（另 108 张 webp、82 张 jpg）。
• 最大单图：docs/zh-cn/stage-1/ai-capabilities-through-games/images/image27.png 12.8M（3787×5303 全分辨率截图），另有 5.8M（2048×2048）、5.3M、4.5M 等多张。
• 图片最集中的章节：
  • stage-1/ai-capabilities-through-games/ — 61M
  • stage-2/frontend/lovart-assets/ — 48M
  • vibe-stories/ — 39M
  • stage-1/integrating-ai-capabilities/ — 33M
  • stage-2/frontend/hogwarts-portraits/ — 32M
• 压缩实测：抽样 12.8M 的 image27.png，仅用 macOS sips 转 JPEG(85) 即压到 3.3M（-74%）；UI 截图转 WebP（质量 8085）通常可压 **8090%**。

为什么这是"体积乘数"

VitePress 多语言构建时，每个 locale 都会复制全站图片（dist-locales 中每个语言目录约 350M）。压图片一次，能同时瘦身：

1. Git 体积（浅克隆 465M → 预计 <150M；完整克隆收益更大）
2. 构建产物体积（磁盘占用）
3. 网站页面加载体积（对阅读体验和移动端友好）

建议方案

1. 优先处理 >1M 的 PNG 截图（约 92 张），批量转为 WebP（质量 80~85），保持文件名与引用路径不变。
2. 全量图片用 pngquant（有损）或 oxipng（无损）先做一轮压缩，预计 462M → 150~250M。
3. 后续新增图片约定：截图导出 WebP、控制分辨率（如 ≤1440px 宽）后再提交。
4. 可选：为仓库增加 scripts/optimize-images.cjs 脚本，方便以后批量执行。
5. 可选（后续再做）：若希望源仓库历史也瘦身，可在图片稳定后执行 git filter-repo 重写历史清除旧版大图（需 force push，注意影响）。

验收标准

• docs/zh-cn 图片总大小从 462M 降至 ≤200M（目标 ≤150M）
• 浅克隆 .git 体积从 465M 随压缩提交降至 <200M（无需重写历史即可生效）
• 所有引用图片的 markdown 无死链（npm run build 通过，页面图片正常显示）