雪碧图与等分格子：工程要的是「每格像素一致、索引可预测」，视觉叙事让位于构建脚本与引擎采样
`sprite-grid-split` 面向 UI 草图条带、像素画格子与临时 atlas：程序读图时常假设 `frameWidth * col` 就能定位，若母图宽高不是单元格的整数倍或存在奇数宽，某些 GPU 纹理对齐会踩坑。抗锯齿会在格与格之间采到邻居颜色，看起来像「串色」。命名要稳定喂给 CI，例如 `ui_row03_col05.png`，并在 JSON 里写行列、padding、是否包含间隔线。改一帧就全量重导在大项目里成本高，因此目录版本化与增量哈希校验比「手工拖 nine patch」更靠谱。
`sprite-grid-split`：先写引擎读的 `cellW/cellH/rows/cols`，再让母图像素严格整除
- 与程序约定纹理格式：是否预乘 alpha、是否要求 2 的幂次、是否禁止奇数宽；把单元格宽高与 gutter 写进 `atlas.json`。母图总尺寸应为 `(cellW+gutter)*cols - gutter` 这类闭式表达式，避免口算误差。
- 源稿每个子图四周留 1px 透明隔离或实色 gutter，导出后在图像编辑器放大检查相邻格是否串色；对像素画关闭子像素抗锯齿并锁定整数网格。随机抽几格做哈希对比，确认与手工裁切一致。
- ZIP 与 JSON 同版本号提交；CI 里写脚本校验文件数等于 rows×cols 且尺寸全等。大 atlas 变更时生成 diff 蒙版报告，方便程序只更新变帧对应的 plist 或 sprite sheet 元数据。
等分格子问答：偶数对齐、抗锯齿串格、流水线命名与增量构建
程序里写死每格 64×64，切出来有的 63 有的 64，游戏引擎直接崩，这种偏差一般从哪里溜进来？
几乎总是母图总宽高不能被行列整除，或导出时带了非整数缩放。应用公式反推允许的画布尺寸，必要时在源图右侧或下侧补透明边到可整除；不要用「视觉差不多」的手动缩放。导出后用脚本批量 `identify` 宽高做断言。
UI 线框图切完后，细描边在格缝上出现隔壁格的灰边，是切片刀口问题还是混合模式问题？
多为双线性采样取到邻格：在美术源文件给每格加内缩或显式 gutter，并在引擎侧关闭重复边缘采样前的错误假设。若必须用无缝条带，考虑改用手工坐标裁切而非等分网格。
像素风项目切完出现模糊半像素，像被 Photoshop 悄悄平滑过，怎样从流程上禁止？
全程 nearest-neighbor，禁用非整数画布缩放；切片起点坐标强制整数；导出 PNG 前检查是否误开「连续色调」或「抗锯齿描边」。在 CI 加锐度检测或像素直方图对比，发现模糊即失败。
构建机要用稳定文件名生成枚举，行优先和列优先混用会怎样？
会导致资源 ID 与动画数据错位，表现为「播 A 帧却闪 B 图」。在 README 与 JSON 同时写明遍历顺序，并在代码里单测映射表；文件名用 `r02_c05` 这种自解释格式比纯数字更不易混。
雪碧图两百格，只改中间一帧却要等全量打包很慢，怎样结合切分工具输出做增量？
把每格单独文件纳入版本控制，全图 atlas 由脚本合成；CI 对比父提交哈希只重跑变更格。切分 ZIP 带版本目录名，旧包勿覆盖，方便回滚与对比二进制 diff。