美术规范

第一版参考图是一把机械键盘，我在它最下方那条植物装饰带上量了色板（旧图还留在 art/ref-source.jpg）。按那套做出来的东西，用户看到实物图之后的原话是： 「美术风格完全不对啊，你看看图片中的样式。」 —— 并对，因为第一版有两个硬伤：

结论：画风基准必须取自设计稿，不能取自实拍照片。 照片里的颜色是"被拍到的颜色"， 不是"被画出来的颜色"，中间隔着环境光、白平衡和相机。 这一条比任何具体色号都重要。

第一版错在取材，第二版错在判读。 第二版的失误在于： 我只量了参考图全图的主色（#8E9099，饱和 7.2%）， 却没量元素内部的色相分布。分区域一量就很清楚：

① 色值在容差 ±22 以内（水彩后期会把颜色挪 10~15 个数，容差太紧会误判）； ② 面积 < 3%。检查脚本两条都量，面积是独立量的。

极稀有植物不能做成"整朵金花"，暖金只能进花心。 实测极稀有那一种暖色面积 1.08%。

拿并排图给专业复核，原话是： 「右边和左边的核心差异：左边是手绘感、细线、柔和明暗、竖向兔子造型； 右边是粗描边、硬边、局部平涂、横向机器人造型。」 并给出「右边最该改的三点」，顺序是： ① 先改成竖直、完整、像兔子的身体轮廓；② 补出两只宽而尖的兔耳； ③ 减轻统一粗黑描边，把阴影从"零件灰块"改成连续的体积明暗。 注意：三点里没有一条是"换颜色"。

病根解释见 3.2。做法是 outline_pass()：

① 把主体所有部件画成一张**实心剪影**（只看 alpha，不看颜色）
② 剪影膨胀一圈、取差集 → 得到**一条连续外轮廓**
③ 轮廓柔化 0.6px（去硬锯齿），贴上去
④ 最后画内部细节（**细节不带外描边**）

这样头、颈、胸、腿之间不会出现闭合的深色圈线。 那只"像机械接口"的分件感，来源就是这些内部圈线。

[!warning] 线宽必须写明在多大画布上量 只写"3px"是没用的：同一条线在 540 宽的图上和 1080 宽的图上差一倍。 这份的规矩是：先在 1080×1920 上量，再整体缩到 540×960， 而且缩放只对最终合成帧做一次，不许每个零件各自缩放（接缝会各糊一圈）。

坑一：bleed 曾经是空转的。 老版膨胀的是 alpha 通道， 而底图 alpha 全是 255（画布不透明）——MaxFilter 对恒定值就是恒等。 所以"渗化"一次都没生效，写着 bleed=1.8 实际等于 0。 归因实测：色数 / 噪点 / 强边三项和"无任何后期"完全相同。 现在改成在 RGB 上做。

坑二：纸纹曾经是"电视雪花"。 老版是 px[x,y] += randint(-s, s) —— 逐像素白噪声。量出来它把噪点幅度从 1.26 冲到 3.42、色数 377 → 884， 而"水彩感"一点没涨：白噪声做出来的是雪花，不是纸。 视觉复核独立给出了同一个判断——把老版那一段评为 "最像电视雪花噪点：布满细密颗粒，边缘仍清楚，色块发灰、通透感弱"， 新版评为 "最像水彩画：纸张纹理与朦胧斑驳明显，边缘柔和，色块半透明、相互晕染"。 指标和眼睛对上了，才确认改的是真问题。

真正的纸有两点白噪声没有的东西：① 纤维（一个方向长、一个方向短） ② 尺度（纸纹比像素大得多，放大要能看见"纹路"不是"沙子"）。 现在用"低分辨率噪声放大 6 倍 + 很轻的细颗粒"，并且三通道同加同一个亮度值， 所以色相和饱和度完全不动。

[!warning] 渗化不能整幅混，只能限定在轮廓附近 试错两次，都记下来： ① 逐像素按局部差异混 → 色数 377 → 2277（平涂区被轻微混合，干净色块碎成渐变） ② Image.blend(im, blurred, 0.30) 整幅恒定 alpha → 色数 377 → 1786 （恒定 alpha 仍然是"每个像素都变"，平涂区也变了）

正确做法是先做一张 mask：只在有轮廓的地方允许混，平涂区 mask=0 → 像素值原样保留。"平"和"水彩"不冲突，冲突的是"整幅一起动"。

兔子跳起来的时候，没有地面投影就看不出脚有没有离地。

主体锚是实测加上的：整套色板都是浅色、又禁止加黑描边， 结果兔子（米白）压在天空/远山（也是浅色）上时会糊掉。 两轮视觉复核都指出"兔子和背景融色"。 解决办法不是加黑线（违反规范），而是在兔子正后方压一圈 16% 的暗角—— 它把主体"顶"出来，又在色板之内。

① foot_lift 对脚底不是恒等映射，所以不能"量出偏移就直接补"。 髋、膝、脚三处耦合，膝盖还有个夹取值会跟着变 —— 实测给 foot_lift 加 −3， 脚只动了 1px。调这个参数调了 7 轮都没调对，因为偏移根本不是它造成的。

② 更关键的一条：hipy 漏了 foot_lift。 原来写的是 hipy = GY - 30 * squash + body_y，少了 foot_lift： 身体升上去、髋部留在原地 → 腿被拉长去够地面 → 脚永远踩在地上，腾空帧也踩着。 这一个漏项同时造成了三个假象：hop 只离地 8px、leap 完全不离地、land 脚陷地下 7px。 修掉之后 hop 立刻变成 40px。 "腿改了、髋没改"是这类骨架代码最典型的漏改，靠肉眼看帧根本发现不了。

③ 最后靠"扫描 + 自动标定"收口。 calibrate() 会扫描补偿量， 取"触地帧最大偏移最小"的那个，不依赖任何关于"谁在动"的假设。 迭代逼近和手推公式都试过，前者会过冲（+7 → +10），后者符号还容易搞反。

[!danger] 关于影子，这里有两个都踩过的坑 ① 腾空时影子不许消失。 原来 alpha = 74 × shadow，而 shadow 在最高点掉到 0.12， 算出来 alpha ≈ 9、半径又只有 1.8px —— 影子的 alpha 直接变成 0，整块没了。 表现是"跳起来的时候脚下什么都没有"，反而更看不出离地。现在 alpha 有地板值（≥30）， 半径也有下限（≥0.5）：离地靠"影子变小变淡"表达，不是靠"影子没了"。

② 校验脚本曾经量的是影子，不是脚。 影子画在最下面，所以"最下面一个不透明像素" 永远是影子的底边，不是脚。于是 --probe 一直在量影子，报出来的"漂移 2px" 其实是影子的漂移，跟脚一点关系都没有——脚本在量错的东西，却一直是绿的。 现在 foot_y() 会按颜色先把影子剔除再扫。

第一版把它用在了所有帧上——包括腾空帧。结果视觉复核的结论是 "双脚仍像着地，跳跃感不足"：兔子身体明明抬到 66px 高了， 脚却还钉在地面上，看起来像被拉长而不是跳起来。

正确做法是给绘制函数加一个 foot_lift 参数： 触地帧传 0（脚钉在地面线），腾空帧传正数（脚跟着身体抬起来）。 实测小跳取 抬升 × 0.62、大跳取 × 0.80（大跳抬得更多、更快， 最高点的剪影是"腿悬在身下"）。

一句话：踩在地上的时候不许漂，飞在天上的时候必须离地。

还有一个连带的坑：--probe 自己一开始是错的。 它对所有帧都要求"脚底 = 地面线"，所以腾空帧一改对就报"漂移 51px"—— 把正确的行为当成了错误。现在它按组分开报（触地帧报漂移、腾空帧报离地量）。 校验脚本写错比不写更危险：它会让你把对的改回错的。

触地帧的 foot_lift 还不许为负：leap 的最后一帧身体下压（抬升 −3px）， 负的 foot_lift 会让脚沉到地面线以下，实测漂移 4px（穿模）。加 max(0, ...) 修掉。

第一版（表里原来那些 #E8E3D5 / #A88763 / #7E9B93）是从小农场那套清新风 直接搬过来的 —— 暖米白天空 + 土黄土壤 + 小清新绿，和灰蓝水彩毫无关系。 它甚至不在第二节的色板里，那句"不许新调色"当时就是一句空话。

第二版我按"色相要区分"改了，但只看色板值、没看屏幕值： 按色板算"天空与远山差 0.19"，渲染出来只有 0.043 —— 因为天空有渐变、远山被混色、地面被提亮。整整一轮调色都没生效， 而我还以为"改了颜色数值却完全不动"是缓存问题。

现在这张表是按渲染后的实测值反推出来的，并且每一带都过了 check_tone.py --scene（见 8.5.1）。

[!important] 为什么五带的色号看起来"差不多" 这是同一个世界的一条跑道，不是五个关卡。五带的明度、饱和、色度都压在同一档 （实测明度 0.6030.626、饱和 14.617.5%、色度 19~22）， 靠色相的小偏移（砾石滩略偏紫灰、溪谷偏冷）和中景剪影的疏密来区分。

不要为了"换带要明显"去拉大色差。拉大之后五带会变成五个游戏， 而且必然有一带因为掉出色度区间而不达标（砾石滩第一版就是这样： 饱和 8.2%、色度 7，其余四带 1618% / 1722，一眼就是"这关没做完"）。

[!tip] 换带的时候只动环境，不动角色 过渡靠天空带整体渐变（6 秒），兔子和花的颜色不变。 "换了个地方"的感觉靠环境给，不靠给角色换皮 —— 省素材，也更像真的走到了另一个地方。

同理，纵向分四层，相邻层明度差要 >0.05： 天空 0.67 / 远山 0.55 / 中景树 0.47 / 地面 0.59 / 土壤 0.36。 远山必须比中景树亮（空气透视）—— 这一条我两个方向都错过： 先是画得比树还暗（深度反了），改完又和树撞在一起（0.43 vs 0.47，分不开）。

旧版的做法是 tools/art/notes_art.py 用 PIL 画椭圆和矩形拼出兔子和植物。 那是根本性的路线错误 —— 用户看到成品后的原话是 「你是在逗我吗 你生图使用的是生图工具吗 风格完全不对 完全不是一样的东西」。

现在全部改成生图（gpt-image-2，图生图），做法与来源见 参考图元素拆离 与 素材总表。

否则你看到的"差异"全是缩放比造出来的。 这和之前"量兔子要量内部像素""量接缝要量画布不要量截图"是同一条： 先确认你量的/看的对象，是不是你要评价的那个东西。

旧版八条全部通过，但用户看到实物图的原话是「美术风格完全不对啊」。 原因很直接：旧八条里一条都没量"明暗关系" —— 它只量了"线够不够细""有没有纯黑" "有没有高饱和"，而翻车翻在"整幅亮了一档、暗部为零"。 标准漏了维度，全过也没有意义。

新加的 1~3 条就是补这个维度。补完之后又发现第二个问题： 单件素材和整幅场景不能共用一个口径。

第一轮：拿"全图暗部 ≥5%"当判据 → 全部场景不达标。 查下来它量的是构图密度：参考图是一条花纹边框，元素填满 67.5% 画幅； 我的场景只有 18.4% 是元素，其余是天空 —— 全图暗部永远到不了 5%。 而按元素口径看，我的画法比参考图还暗一档（13.8% vs 10.5%）。 拿一个量构图的指标去判画法，会得出"画法不合格"这个完全错误的结论。

第二轮：阈值定 8% → 参考图自己只有 7.8%，基准图被判不合格。 阈值必须低于基准图的实测值，否则就是自相矛盾。改成 6%。

现场回放：用户说「灰度过重、对比不足」，而我跑完 check_tone 得到的是一排 ✓。 为什么？因为当时只有饱和度的上限（10%），没有下限 —— 而上限拦的是"太艳"，根本拦不住"太灰"。 我的场景当时 P90 只有 3.9%（基准 15.2%），色度只有 6（基准 12）， 一路绿灯。

判据有效性的验法（这条以后照做）：拿三个已知样本跑一遍， 旧版必须被拦下、新版必须通过、基准在中间 ——

三个样本一眼可分，判据才算立住。只能"全过"的判据等于没有判据。

[!warning] 反过来也要防：主观评价不构成判据，除非它对基准图有区分度 这一轮修完之后，我把图送去视觉复核，回答仍然是「整体明显发灰发闷」。 看起来像是"改了个寂寞"，但同一套提问拿去问基准图，回答是「这张图整体偏灰」—— 参考图自己也是灰的。

所以"发灰"这个评价对基准图同样成立，它不区分"做对了"和"做过灰了"。 这种评价不能当判据用，只能用来看"有没有硬伤"（错位、糊成一团、元素丢失）。

能不能当判据，验法是一样的：拿基准图跑一遍。 基准图也会被判"不合格"的判据，一律不能用 —— 无论它是脚本还是人。 （这和"阈值必须低于基准值"是同一条规矩的两个面： 一个是数值面，一个是主观面。）

[!note] 为什么是「元素内」而不是「全图」 elem_mask() 用局部对比（与高斯模糊的差 >0.05）把元素圈出来 —— 平滑的天空和地面底色不会被算进去。这样量出来的才是画法， 不受"这一关天空留了多少"影响。

1. 口径混用：按场景口径量 bush-0.webp 得出"暗部 0.0%、轮廓没画出来"， 按单件口径真值是 10.8%、完全正常。一个口径错误可以凭空造出问题。
2. 判据量错了对象：全图暗部量的是构图，不是画法。见上面第一轮。
3. 阈值高于基准值：定 8%，基准图 7.8% —— 自相矛盾。
4. 暗部占比偏向线条多的素材：石头 2.2% 被判"没描边"。
5. 过期截图：shot-band2.png 是 12:15 的旧文件（生成它的逻辑早删了）， 带着旧色板混进验收，伪造出两张"不达标"。验收前先确认截图是本轮生成的。
6. UI 面板按场景判：线索卡截图被判"太亮"，而面板本来就该亮。
7. 判据的方向搞反了：饱和度上限拦的是"太艳"，拦不住"太灰"。 我拿一个上限去对付"灰度过重"，于是用户看得见的问题在验收里是隐形的。 "太灰"和"太艳"是两个方向，各要一条判据。
8. 阈值比基准还严：色板色号饱和定 ≤20%，而 HSV 饱和在暗色上会自动虚高 （#292D35 明度 0.18 → HSV 饱和 24.5%，色度却只有 12、和基准一致）。 差点为了迁就一条错判据，把本来就对的暗色改坏。对暗色用色度，不用 HSV 饱和。
9. 色板值 ≠ 屏幕值：我按色板算"天空与远山差 0.19"，实测屏幕上只有 0.043 —— 因为天空有渐变、远山被混色、地面被提亮。 同时树带画在 y 47%~69%（SKY_H+4 起、高 160），我却一直量 43%~51% —— 那段全是天空。量之前先确认元素到底在哪个区段。

第九节那十二条判据是对的。这一节记的是"我拿着对的判据，还是把同一件事做错四次"。

前面三轮我一直在优化画布，但报出问题的那个数是截图量出来的。 中间一度把已经改对的东西又改坏（为了压这一条，把纸纹颗粒从 0.010 加到 0.018）。 任何一个量出来的异常，先确认量的对象是不是用户真正看到的那个。