要判断 Macaron-V1 的后训练边界，起点不该是它的能力介绍，而是你这周真要交付的那几件事。能力描述回答的是“它被训练去做什么”，但不回答“你手上这条任务是否落在里面”。建议的顺序是：先把任务写成清单，再拿清单逐条去对描述，把对不上的位置标成空白区，并为每块空白预先写下一条能执行的退路。这样做，是把“临时才发现没有退路”挪到动手之前。

判断 Macaron-V1 是否够用，建议以任务清单为主、能力描述为辅：先写下每条任务的输入来源、输出形态和失败是否可接受，再逐条在能力描述里找对应原文，找不到的直接记为空白区，不用“应该也能做”补上。空白区按影响排序，区分整条任务缺失还是某个环节缺失。每条空白至少备一种降级做法：拆成多步、转人工接管或改输出形态，并写清触发条件。边界是否成立，要靠跑通降级分支、看日志确认，不靠描述推断。

把本周真实要做的事写成任务清单

从能力列表出发很容易跑偏：你会顺着它能做什么去想用途，而不是从已经压在排期上的活出发。建议直接打开本周的待办，把需要模型参与的任务挑出来，一条一条按下面三个字段写死，写成能保存、能复制的结构，不要只写在脑子里。

tasks:
  - id: T1
    name: 把客服工单摘要成三类优先级
    input: 工单正文（工单系统导出，单条约 300~800 字，纯文本）
    output: 三行结构化标签 + 一句话结论
    fail_ok: 不能错分高优先级；其余错分可人工复核
  - id: T2
    name: 从合同文本里抽字段
    input: PDF 转出的纯文本，含表格，页数不定
    output: JSON 字段，键名固定
    fail_ok: 可以失败，失败后转人工处理

三个字段各有用途。输入来源要写到能指到具体位置，比如哪张表、哪个目录、导出格式是什么，否则后面无法判断“描述里说的输入”和你真实的输入是不是一回事；输出形态要写结构，写“一段文字”等于没写，后面没法校验；失败能不能接受决定了降级是硬停还是软降，这条不写清，出事时只能临时拍板。

验证方式很朴素：清单里每一条的输入，本地都要有一份对应样本。跑之前先用样本对一遍格式，格式对不上，后面的对照就没有意义。

拿清单逐条去对能力描述

对照的动作要具体，不要通读一遍凭印象打勾。打开能力描述，按任务里的关键词逐条搜索，命中的句子整句复制进表里，不要改写、不要概括。改写过的句子会让人误以为已经覆盖。

表里的“是”可以继续往下走；“否”和“部分”都要归到空白区。“部分”不要当覆盖处理，因为描述里没写清的条件——输入长度、输出结构、是否保留原文片段——恰恰是最容易在现场出问题的地方。表格留空的那一格本身就是结论：描述里没有这条，别自己补。

标出描述没覆盖的空白区

空白区要排序再动手，排序依据建议用两个维度相乘：这条任务在本周交付里是否关键，以及失败是否可以接受。关键且不能失败的任务排最前，关键但可人工兜底的排其次，不关键的直接往后放甚至这周不做。

每条空白还要标清楚是整条任务缺失还是某个环节缺失。这两类处理方式不同：整条缺失通常只能换路径，环节缺失往往能靠拆步或改输出形态补上。

• T2 合同字段抽取：整条任务缺失。描述里没有字段抽取相关说明，输入还包含表格，属于连入口都没写。
• T1 工单摘要：环节缺失。分类有说明，但“输出必须是固定三行标签”这个约束没写，属于输出形态环节缺失。
• T4 多轮追问：环节缺失。描述提到对话，但没说明是否保留上一轮上下文，属于输入延续环节缺失。

这一步不做验证，只做标注，但要保证每一条空白都能指回具体的任务编号和描述里缺失的位置，方便后面复查时不用重新推一遍。

给空白区定降级方案

降级不是把模型换成更强的配置，而是在覆盖不到的地方让流程仍然能交付。每条空白先选一种做法：拆成多步、转人工接管、改输出形态。选完必须写触发条件，而且触发条件要是可观测的，比如字段缺失、返回为空、格式不符、超时；不要写“模型没把握”这类无法在代码或日志里判断的表述。

fallback:
  T2:
    trigger: "返回 JSON 解析失败 或 必需键缺失"
    action: split_then_handoff
    steps:
      - 先只抽条款标题，输出纯列表
      - 再由人按标题逐条补字段
  T1:
    trigger: "输出行数不足三行 或 标签不在枚举内"
    action: change_output
    to: "候选标签 + 原文片段，由人挑一个"
  T4:
    trigger: "用户第二轮提问仍需上一轮信息"
    action: manual_takeover
    to: "转人工会话，保留前面原文"

拆成多步适合输入太长或结构太复杂的任务，把一次抽取拆成“先定位、再取值”，每一步的输出都能单独校验；转人工接管适合失败不可接受但量不大的环节，需要提前估算人时，降级本身不减少工作量，只是把不可控变成可控；改输出形态要把结果改成人能快速核对的形式，比如短列表、固定键名的 JSON、带原文片段的行，不要改成更长的自然语言，那只会让人更难校对。

验证方式：在降级分支里打一条可搜索的日志标记（例如 fallback_hit=T2），用样本跑一轮，看哪些分支真的被触发、触发时输出长什么样。日志里没有标记，就说明这条降级写在文档里但没接进流程。风险边界也要写下来：降级分支能保证流程不中断，但不保证质量达到正常路径，是否可接受仍需要结合具体交付要求确认。