手上列了五六个场景，先别按业务价值排序。PixelUMM 这类多模态模型在不同输出形态上的稳定性差距，往往比场景之间的业务价值差距更大：同样一张图片，判断“画面里有没有某个物体”和“把图里的文字转成结构化字段”，后者的返工点会多出整理和校对两层。先用输出稳定性和人工返工这两个维度过一遍，能筛掉大部分“看着能做、实际要人兜底”的场景。

适用场景：已有 3–6 个候选场景、手上有真实样本可抽。操作动作：每个场景抽一批业务真实输入，按“可直接用 / 小改可用 / 不可用”记结果，并把返工归到识别、整理、校对三类。验证方式：固定同一批样本隔开时间复跑一次，看输出是否漂移。风险边界：这些记录只代表自己的样本，不承诺业务收益，也不能替代线上观察；正式上线前仍需小流量验证。

把候选场景按输入形态和输出要求列出来

把候选场景写成同一张表，场景之间才可比，而不是凭印象排序。输入类型不要只写“图片”，要写到“手机拍摄的单张票据、扫描件、带表格的截图、多图对比”，因为输入形态直接决定识别难度。输出用途要区分“写进数据库”“给人看”“触发自动化动作”，三种用途对格式的要求完全不同。

下游有没有人复核，比模型准不准更能决定先做哪个。无人复核的场景，要么输出能被程序校验（字段齐全、枚举合法、数值在范围内），要么就先别做；有人复核的场景，返工成本是可计量的，用小样本就能估出来。

每个场景挑一批真实样本记录输出能不能直接用

样本从真实业务里抽，不要用演示图或修过图的样例。每个场景先抽 20–50 条，覆盖常见形态和几类边缘情况：模糊、倾斜、多栏、手写、反光、截图缩放。原始文件留好，复跑要用同一批，否则前后不可比。

• 可直接用：不改一个字就能进下游，写入、发布或触发动作。
• 小改可用：改一个字段、一句话、一个数字。
• 不可用：结构错、漏关键项、和图对不上，整条要重做。

不可用时的人工动作也要记，只记“不可用”不记动作，后面统计返工点会缺信息。动作通常分四类：补字段、改文字、重跑一次、退回人工处理。

scene,sample_id,input_type,verdict,rework_step,action,rerun_same
invoice_fields,s001,phone_photo,usable,,,yes
invoice_fields,s002,phone_photo,partial,organize,fix_amount,no
ui_locate,s031,screenshot,unusable,recognize,manual_mark,no

verdict 用 usable、partial、unusable 三档；rework_step 记 recognize、organize、proofread；rerun_same 记录同一输入隔开时间跑两次结果是否一致。这张表自己用就够，不必先上系统。

统计每个场景的人工返工点落在哪一步

返工点分三类，每条样本只打一个主标签，避免重复计数：

• 识别：没认出来、认错对象、漏掉关键区域。
• 整理：认出来了，但字段顺序、单位、合并拆分、格式不对。
• 校对：输出看着对，但要人逐条核对数字、编号、金额才敢用。

频次按条数记，不按“感觉多不多”。识别类返工占大头，说明输入形态还没收敛，换提示词或加约束收效有限；整理类为主，通常加一层输出结构校验能拦下一部分；校对类为主，说明场景本身离不开人，先别指望省人力。

scene=invoice_fields samples=40
recognize=8  organize=11  proofread=5  usable=16

数字只写自己样本里的条数，不必急着换算成比例。条数比比例更不容易误导自己的判断。

按稳定性给场景排序并标出返工集中处

排序不要用单一分数，按这个顺序看：先看不可用条数，再看可直接用条数，然后看复跑一致率，最后看下游有没有复核兜底。不可用条数多的排后面，哪怕该场景业务价值高，因为不可用意味着每条都要人重做。

并列时的取舍规则：输出字段更少、格式更固定、输入更单一的先做；需要长文本生成、多图推理、输出口径依赖主观判断的往后放。两条并列时，下游有人复核的优先，因为返工有落点。

还有几类场景不参与排序，要写清原因：拿不到真实样本的，只有演示图；输出“可用”标准说不清的，比如“生成一段有感染力的文案”；输入质量完全不可控的，用户随手拍、无约束上传。这几类先补样本或补校验，再进排序。

定下先做的场景和暂缓条件

走完上面几步，通常能落到一个场景上：单图输入、字段数少、输出结构固定、下游有人复核。先做这个场景，验证目标放在“返工是否集中在能被校验拦住的那一步”，而不是笼统的准不准。在模型输出之后、写库之前加一层结构检查，把不通过的条目直接落到人工队列并标记原因。

{
  "scene": "invoice_fields",
  "required": ["invoice_no", "amount", "date"],
  "rules": {
    "amount": "number, > 0",
    "date": "YYYY-MM-DD",
    "invoice_no": "length 8-20"
  }
}

字段名和规则按自己的场景替换。用同一批固定样本跑，记录被拦下多少条、拦住的是否真是坏结果，这比只看模型原始输出有用。

暂缓的场景要写重评信号，不要只写“以后再排”：样本补到能覆盖主要输入形态、输入质量有了约束（例如只接受扫描件）、下游加了复核环节、或者输出改成固定字段。复评时间点建议放在一个迭代之后，仍用同一批固定样本复跑对比；换样本会让前后结果不可比。