要不要把一类任务交给 GPT-6 Luna，通常不看模型整体强不强，而看这类任务的输出形态、可用线和稳定性要求能不能对上。翻译、摘要、结构化抽取表面都是把一段文字变成另一段文字，验收方式却差得很远：摘要读得下去就算过关，结构化抽取必须能被下游程序直接解析。建议按分类、对照、稳定性、边界、回看五步走，先小范围试，再决定迁移范围。

适合交给 GPT-6 Luna 的，多是输出短、格式边界清楚、错了能重试或人工补一笔的任务；长上下文依赖、字段强约束、错一次就要回滚的任务，先留在原方案。判断路径是：按输出形态分类，三类任务各做一次人工对照，按稳定性决定放主链路还是旁路，不合适的明确保留，到点回看调用记录与抽检结果。

把手头任务按输出形态分类

分类维度建议只用三个：输出长度、输出是否有结构、谁来验收。输入长度作为辅助维度，因为输入长度直接影响上下文压力和成本，也影响能在提示词里塞进多少规则。以自家客服和订单业务为例，先把任务落到下面几类里。

• 短文本生成：客服一句话回复草稿、工单分类标签、商品标题改写。输入通常 20–300 字，输出 5–80 字。验收靠人工一眼看，或关键词命中。
• 长文改写：把一周工单整理成周报、把会议记录压成要点。输入通常 800–5000 字，输出 200–800 字。验收靠人工通读，速度是瓶颈。
• 结构化抽取：从订单备注抽收货信息、从聊天记录抽意图和商品编号。输入通常 100–1500 字，输出是固定字段。验收靠程序解析加必填校验，不靠人读。
• 混合型：先抽取再生成说明文案。这类任务失败点最多，建议拆成两步分别判断。

分类不是为了写文档，而是为了决定后面对照时看什么。输出越短、结构越固定，人工对照和程序校验都越便宜，迁移的试错成本也越低。

挑三类任务各做一次人工对照

从上面几类里各挑一个真实任务，每个任务先取 10–20 条自家历史样本，覆盖正常样本和边界样本，例如空备注、错别字、超长工单。同一批输入分别跑现方案和 GPT-6 Luna，输出放到同一张表里对照。评分维度只保留三个：准确性、格式符合、可读性，每项用达标或不达标两档，避免打分尺度漂移。

记录表字段建议固定成下面这些，后续回看时字段不要改，否则前后没法比：

• task_id：样本编号，能和原始工单对上
• task_type：短文本生成、长文改写或结构化抽取
• input_chars：输入字符数，用来确认落在哪个区间
• output_raw：模型原始输出，不做人工润色
• accuracy_ok：事实或字段值是否准确（0/1）
• format_ok：格式是否符合约定（0/1）
• readable_ok：可读性是否达标（0/1）
• need_fix：是否需要返工，以及返工属于哪一类原因
• fix_minutes：返工大致耗时，用于和原方案对比
• review_note：对照时记下的疑问，留给回看节点

判断某个任务是否值得迁移，建议只看三条依据：第一，对照后多数样本达到可用线，返工只是少量字面修正，而不是重写；第二，输出可以被程序校验或被人一眼校对，例如固定字段能解析、短文本能扫读；第三，出错时有流程接得住，重试或人工补一笔的成本低于继续用原方案。三条里有任何一条明显不成立，就先不迁移，把它记进暂不迁移清单。

结构化抽取可以在对照阶段就加一道校验，减少人工判断量。下面是一段通用校验骨架，函数名和字段名按自家任务替换，执行位置放在拿到模型输出之后、写入业务库之前：

import json

def check_extract(raw: str, required: list[str]) -> tuple[bool, dict]:
    try:
        data = json.loads(raw)
    except json.JSONDecodeError:
        return False, {}
    if not isinstance(data, dict):
        return False, {}
    missing = [k for k in required if not data.get(k)]
    return (len(missing) == 0), data

# 调用示例：先调模型拿 raw，再校验
ok, data = check_extract(raw_output, ["order_id", "intent"])
if not ok:
    raw_output = call_again(prompt, text)   # 只重试一次，仍失败就转人工

这段代码只做格式和必填判断，不判语义。语义仍然要靠人工抽检，别把校验通过等同于结果正确。

看任务对稳定性的要求

同一类任务，放进主链路还是放在旁边，取决于错了之后能不能补。这里把场景分成两类。

可重试补正的场景：批量生成报表草稿、客服回复候选、工单分类建议、知识库问答的参考片段。这类任务的特点是输出先给人看或先入库草稿，错了有人能改。合适的位置是异步队列或旁路服务，配上失败重试和降级到原方案的分支。验证方式是看调用记录里的重试次数和人工修改比例，边界是重试仍失败时必须能退回原流程，不能卡住主流程。

必须一次正确的场景：金额折算、订单状态变更、对外发送的正式通知、写进审计或结算记录的字段。这类任务错了要回滚，甚至对外可见。处理方式通常是不直接进主链路，要么让模型只产出建议值、由规则或人工确认后再落库，要么继续用原来的确定性程序。验证方式是确认下游有没有硬校验拦得住，边界是拦不住就别接。

判断标准可以很朴素：问一句这条输出错了，谁在什么时候会发现。回答里如果出现没人会发现，该任务就不适合交给轻量档位直接输出。

把不合适的任务留在原方案

迁移边界要在动手前写清楚，避免试完一个点就顺势全量替换。下面几条判据，命中任意一条，建议暂不迁移，或只迁移其中的一个子步骤。

• 长上下文依赖：需要跨多份文档、跨长时间窗口比对才能判断，输入本身超出可稳定处理的范围。
• 字段强约束：金额、日期、证件号、内部编码必须逐字符正确，且没有二次校验机会。
• 人工复核成本高：复核一遍的时间接近甚至超过原来自己做一遍的时间，迁移就没有意义。
• 责任与留痕要求：输出需要明确责任主体或可解释依据，模型给出的依据链不足。
• 原方案稳定且不贵：现有规则程序跑得稳、维护成本低，迁移只是换一种写法，收益有限。

更稳的做法是部分迁移：例如从工单里抽字段这一步可以试，后面的生成对外回复仍然留在原方案。迁移范围写在一份清单里，注明每个任务当前状态：已迁移、旁路试运行、暂不迁移。

定一个回看节点

取舍不是一次定终身。建议在首次切换后一周左右做第一次回看，之后按累计调用量设置第二次，例如每个任务累计到一定调用规模、或隔一个月再看一次。回看不看感觉，看两样东西：调用记录和人工抽检结果。

调用记录最少留下面这些字段，能写日志就写日志，不能写日志就落一张表：

ts,task_id,task_type,input_chars,model_tier,retry_count,
format_ok,human_edit,fallback_used,review_flag

复查项建议固定：格式校验失败有没有集中在某类输入；重试次数是否集中在少数样本；人工修改的原因主要是措辞还是事实错误；有没有出现对照阶段没覆盖到的新输入形态；降级到原方案的次数是否在增加。人工抽检从每个任务里随机取一小批，用对照阶段同一套标准打分，和首次对照的记录比趋势，不追求单次漂亮数字。

回看的产出是三个决定之一：扩大迁移范围、维持现状、回退到原方案。只要调用记录里出现新的集中失败模式，就先暂停扩量，把这类输入补进对照样本再判断。