现象
生成结果里角色的头被裁到画面外。
两个独立原因
一、只有 attack 与 jump 补了顶部空间
ai_engine/master_prep.py 的 prepare_master：
if action in ("jump", "attack"):
return add_headroom(master, ratio=0.62 if action == "jump" else 0.70)
return master
其余动作（含 custom）一点余量都没有。而自定义动作恰恰是最不可预测的一类——用户可能描述抬手过头、跳起、后仰，这些都会顶出母版上沿。
补边的原始依据是 attack 实测 15/72 帧触顶。这个依据对，但它只覆盖了当时测过的两个动作，没有覆盖后来加进来的 custom。
二、定标时"溢出被裁"没有区分裁的是什么
postprocess/pack.py 的取舍是刻意的：
整帧装不下时不为它压缩角色，让延展物溢出被裁
理由成立——为保尺寸一致，宁可裁掉翅尖、尾尖、披风角。压缩的后果不对称：同一角色在两个动作里能差到四成。
但这条规则没有区分「裁的是延展物」还是「裁的是头」。 头是主体的一部分，不是延展物。当前实现只看整帧宽是否超出画布，不看被裁掉的是哪个部位。
影响
头被裁的产出是不可用的，而不是"差一点"。角色身份主要由头部承载，裁掉之后这一帧对使用者没有价值。而当前它会作为正常帧交付。
建议方向（待评估）
- 补边覆盖到 custom：自定义动作不可预测，应给默认余量。ratio 取多少需要实测，不要直接抄 attack 的 0.70。
- 区分裁切部位：溢出裁切前先判断被裁区域是否落在主体上部。裁延展物照旧，裁到头部应当报出来——这条可以先只记录不拦截，攒数据再定阈值。
- 判据要能自动判定，否则只能靠人看图。
slicing/quality 已有逐帧主体分析的基础设施，可在其上加一个"主体是否触及画布上沿"的读数。
备注
补边与裁切是一对：补得多则角色在画面里更小（浪费分辨率），补得少则容易触顶。这个取舍需要数据支撑，不能拍脑袋定——建议先加读数（第 3 条），有分布之后再调参数。
现象
生成结果里角色的头被裁到画面外。
两个独立原因
一、只有 attack 与 jump 补了顶部空间
ai_engine/master_prep.py的prepare_master：其余动作（含 custom）一点余量都没有。而自定义动作恰恰是最不可预测的一类——用户可能描述抬手过头、跳起、后仰，这些都会顶出母版上沿。
补边的原始依据是 attack 实测 15/72 帧触顶。这个依据对，但它只覆盖了当时测过的两个动作，没有覆盖后来加进来的 custom。
二、定标时"溢出被裁"没有区分裁的是什么
postprocess/pack.py的取舍是刻意的：理由成立——为保尺寸一致，宁可裁掉翅尖、尾尖、披风角。压缩的后果不对称：同一角色在两个动作里能差到四成。
但这条规则没有区分「裁的是延展物」还是「裁的是头」。 头是主体的一部分，不是延展物。当前实现只看整帧宽是否超出画布，不看被裁掉的是哪个部位。
影响
头被裁的产出是不可用的，而不是"差一点"。角色身份主要由头部承载，裁掉之后这一帧对使用者没有价值。而当前它会作为正常帧交付。
建议方向（待评估）
slicing/quality已有逐帧主体分析的基础设施，可在其上加一个"主体是否触及画布上沿"的读数。备注
补边与裁切是一对：补得多则角色在画面里更小（浪费分辨率），补得少则容易触顶。这个取舍需要数据支撑，不能拍脑袋定——建议先加读数（第 3 条），有分布之后再调参数。