项目记录：给退图原因做编码后，返工集中在哪两类
起因
配图返工一直不少，但每次复盘都说不清到底卡在哪儿：退回时写的都是「不太对」「再调调」，攒了一堆也没法统计。于是先做了一件不看图的事——给退图原因编一套固定码。
编码表只留六项
| 码 | 含义 | 判定依据 |
|---|---|---|
| 甲 | 需求没说清 | 原需求里找不到对应约束 |
| 乙 | 用途变了 | 放置位置或尺寸中途改动 |
| 丙 | 视角或光线漂移 | 与同组图不一致 |
| 丁 | 元素多余 | 出现要求里禁止的东西 |
| 戊 | 主体不对 | 表达的对象偏了 |
| 己 | 验收口径不同 | 两人判断不一致 |
要求每次退回只选一个码，选不准就标「待议」，不许写「综合原因」。这一条最费口舌，但也最值钱：多选等于没选，统计出来还是一团模糊。
分类思路借了 BackendWiki 里讲错误归类的做法：按「原因出在哪一层」分，而不是按「看起来像什么」分。层次清楚了，改哪一层就明确。
跑了一个月的统计
结果比预想集中：甲和乙两类合起来占了大半，真正属于生成质量的丙、丁、戊反而不到三成。也就是说，多数返工不发生在出图那一步，而发生在出图之前——需求里没写用途，或者用途中途改了。
据此做的两处改动
- 需求单里把「用途、位置、尺寸」设为必填，缺一项不进生成队列。
- 用途一旦变更，作废原单重开，不在原图上继续改。
第二条尤其有效。以前用途变了还接着调图，调到最后既不像新用途也不像旧用途，白费两轮。
一点保留
这份统计只反映自己这批任务的分布，换一类图未必成立。另外，编码不要再加项了，试过扩到十来项，填写的人很快开始随手选，数据反而失真。
小结
给模糊的「不太对」一个固定码，返工原因就从感觉变成了分布。看清大头在需求层，改进也就不用再盯着生成环节较劲。