判断 Inkling 能不能接你手上这类截图任务，不要看公开演示，拿十几张自己业务里真实出现过的截图跑一遍更靠谱。原因是多模态模型的表现高度依赖输入分布：同一类报表，清晰扫描件和压缩过的手机截图结果可能差很远；同一张后台页面，问“有哪些按钮”和问“这笔订单当前处于什么状态”也是两种难度。建议先用 12 到 15 张截图把边界试出来，再决定哪些环节交给模型、哪些保留人工。

判断方向：用业务中高频出现的表格类、界面类、图表类、带手写或标注类截图各挑三张，覆盖清晰样本、低质量样本和边界样本，跑同一套固定提问并逐张记录成败。适用场景是接入前的可行性摸底，操作动作是先把成败标准写成可核对的形式再跑，验证方式是同图同问重复跑看结果是否一致。风险边界：小样本只能说明哪类任务需要人工复核，不能直接推导线上稳定性；涉及金额、状态判定和跨图汇总的任务，仍应保留人工环节。

挑出业务里最常出现的几类截图

挑图的原则是“来自真实任务”，不要用网上的示例图，也不要用自己精修过的漂亮截图。从最近一两周实际处理过的截图里取，按四个维度分类：表格类（对账单、订单明细、导出报表）、界面类（后台列表页、App 页面、报错弹窗）、图表类（折线图、柱状图、仪表盘）、带手写或标注类（审批签字、圈选批注、截图打标记）。

每类挑三张，理由要能说清楚：

• 第一张是这类里最常见、质量也最好的图，用来判断“能不能用”；
• 第二张是同类但质量差的图，例如缩放后模糊、只截了一半、带水印或压缩痕迹，用来判断“稳不稳”；
• 第三张是边界样本，例如同一张报表但行数很多、同一页面但元素密集，用来判断“什么时候不该用”。

四类各三张共 12 张，再补 2 到 3 张你凭经验判断模型大概率做不了的图作为对照。这一步不做任何调参，先原样跑。

给每类任务定一个能判定成败的标准

试用结论停在“感觉还行”就没法用来做接入决策。建议在跑之前把标准写成另一个人也能核对的形式，跑完不再改标准。

• 表格类：指定三列五行，逐格与人工读数比对，出现任意一格不一致、或输出多出/漏掉某一列，判为失败。
• 界面类：提问限定为“当前页面处于什么状态、有哪些可点击的操作”，人工对照截图核对；输出里出现截图不存在的按钮或状态，直接判失败，漏掉次要元素单独记为遗漏。
• 图表类：提问限定为“最大值出现在哪个类别、大致在什么数值区间、整体是升还是降”，趋势方向答反直接判失败，数值只要求落在可读刻度范围内。
• 带手写或标注类：标注文字逐字比对，同时要求说明标注指向哪个对象；文字错一个字或指向对象搞错，都判失败。

标准写细之后你会发现，很多失败其实是“提问没写清”，这正是下一步要区分的原因。

逐张跑同一套提问并记录结果

横向比较的前提是提问一致。每类任务准备一到两条固定的提问原文，所有同类图片都用同一句问，不要临场改词。记录表建议至少包含这些字段，存成 CSV 便于后面归类：

image_id,task_type,prompt,output_summary,verdict,fail_reason,run_no,stable
T-01,表格类,"读出这页的三列金额并逐行列出",输出了两列且第 4 行错位,fail,漏列+错位,1,
T-01,表格类,"读出这页的三列金额并逐行列出",输出两列并漏掉第 4 行,fail,漏列,2,no

同一张图重复跑时，用 run_no 区分次数，并额外记一列“是否与上一次一致”。建议每张图同问跑 2 到 3 次，因为多模态输出的稳定性本身就是要观察的项；两次结果不同，说明这类任务需要更强的校验，而不是模型一定不行。

接入时可以用一段最小请求骨架复现同样的条件，把 temperature 调低、固定 seed（如果你的接入端支持），把模型名、地址、图片传输方式换成自己环境里的实际值：

curl -s "$ENDPOINT" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"model":"<你的模型名>","temperature":0,"seed":42,
       "messages":[{"role":"user","content":[
         {"type":"text","text":"读出这页的三列金额并逐行列出，只输出结果"},
         {"type":"image_url","image_url":{"url":"<图片URL或base64>"}}]}]}'

具体字段名以你实际使用的接入方式为准，跑通一张后先确认返回里没有报错字段，再批量跑剩下的图。

把失败样本按原因归类

失败样本要先分类再下结论，否则容易把“图太模糊”记成“模型不会读表”。可按下面几类归档，每类给一个下一步动作：

归类之后回头看记录表：如果失败集中在某一类，结论就是“这类任务缩小范围后再接入”；如果同一张图不同 run 之间摇摆，优先考虑加校验和人工复核，而不是继续调提问。

据此划出接入范围和兜底方式

试用结论落到三档分工上比较好执行：

• 可以直接交给模型：单图、单字段、有明确核对方式的抽取，例如把清晰表格里的三列金额转成文本、把界面上的固定字段读出来。即使在这一档，也建议做格式校验（字段数、数值范围）后再写入。
• 模型出草稿，人工复核：界面状态判断、图表读数、带手写标注的审批意见。做法是模型输出带原文摘要，复核人只需扫一眼就能确认。
• 不接：跨多图汇总、需要外部系统知识才能判断的结论、签字真伪这类无法从截图本身确认的事项。

兜底流程要写清楚谁触发。常见做法是调用方服务在解析或校验失败时给这条记录打标记并推入人工队列，由当班复核人处理，超过约定时长未处理就升级给任务负责人。校验逻辑可以放在调用之后、写库之前，例如检查字段数量、必填项和数值区间：

required = ["金额", "日期", "单号"]
rows = parse_model_output(resp)
if not rows or any(k not in rows[0] for k in required):
    mark_for_review(record_id, reason="字段缺失")

这段只是通用骨架，字段名和解析方式要按你实际拿到的输出结构改写。核对完一轮之后，把记录表和归类结论一起存档，下次模型或提示词有变化时，用同一批截图复跑即可比较。