1这个流程做什么
输入一个工单文件，输出一张分类明细表 + 一句话统计。
①
进来
上传本批工单文件（xlsx / docx / pdf / txt / md）
上传本批工单文件（xlsx / docx / pdf / txt / md）
②
处理
切成小块 → 每块独立调用模型判断分类 → 合并所有块
切成小块 → 每块独立调用模型判断分类 → 合并所有块
③
出去
9 列明细 CSV（含状态标记）+ 一句话统计
9 列明细 CSV（含状态标记）+ 一句话统计
判定"不确定"的口径：只有回单为空、完全无意义、或无法归入任何一级分类时才标
待确认，
并给出候选分类（下拉选项）。是否不确定由代码裁决，不看模型自由发挥——所以同一份数据跑两次，结论一致。
2整体流程（6 段主干）
从上传文件到导出 CSV，主干是一条直线；「逐块分类」内部是一个循环。
1 · 输入
开始
上传本批工单文件
→
2 · 取文本
文档提取器
把文件内容转成文本
→
3 · 预处理
切成若干块
每块 10 条，整理成
row_id / 工单编号 / 回单内容→
4 · 核心判定
逐块分类
循环容器：每块独立判定 → 解析
→
5 · 汇总
汇总输出
合并所有块，统一连续编号，打状态标
→
6 · 交付
导出 CSV + 输出
9 列明细表 + 一句话统计
第 4 段「逐块分类」内部循环（迭代容器）
循环入口
循环开始
取出一块文本
→
LLM
块内分类
一次只看 10 条，输出 JSON
→
CODE
解析块结果
容错解析 + 回填原文与编号
每一块独立跑一遍这两步，块与块互不影响。108 条 → 11 块 → 模型只调用 11 次。
3每个环节具体在做什么
| 环节 | 节点 | 做什么 | 关键设置 |
|---|---|---|---|
| 输入 | 开始 | 接收本批工单文件 | 文件类型：document |
| 取文本 | 文档提取器 | 把上传文件转成可处理的文本（Markdown 表格 / JSON 都能吃） | — |
| 预处理 | 切成若干块（代码） | 按 10 条一块切分，每行整理成 row_id | 工单编号 | 回单内容 |
CHUNK_SIZE = 10 |
| 核心判定 | 块内分类（LLM） | 对一块里的工单逐条分类，输出 JSON 数组（一级分类 / 二级原因 / 判定依据 / 回复建议） | 通义 qwen3.7-maxtemperature=0、max_tokens=4096 |
| 解析块结果（代码） | 容错解析模型输出；按位置回填原文与工单编号；标注本块是否完整 | 接受数组 / 单个对象 / 思考前缀 / 代码块包裹 | |
| 汇总 | 汇总输出（代码） | 合并所有块结果 → 按块号与块内位置排序 → 从 1 连续编号 → 标 已确定 / 待确认 → 生成 9 列表格与一句话统计 | 同时统计成功 / 失败 / 截断的块数 |
| 交付 | 导出 CSV + 输出 | 用 Markdown 转 CSV 插件生成文件；输出节点只暴露 2 个变量 | 文件名：工单分类结果_含待确认标记.csv |
4最终交付物
输出变量 1
outputCSV 文件：工单分类结果_含待确认标记.csv，9 列明细
输出变量 2
report_md一句话统计：本次共处理 108 条工单：已确定 97 条，不确定 11 条。（共 11 块：成功 11 块）
CSV 的 9 列
| 序号 | 工单编号 | 回单内容 | 一级分类 | 二级原因 | 判定依据 | 回复建议 | 状态 | 候选分类（下拉选项） |
|---|---|---|---|---|---|---|---|---|
| 1 | GD001 | 用户皮线损坏，熔接后恢复 | 网络质量 | 线路故障 | 皮线损坏、熔接后恢复 | 按已恢复归档 | 已确定 | |
| 2 | GD002 | 用户来电说了些听不懂的话 | 其他 | 待核实 | 未说明具体问题 | 补充问题后派单 | 待确认 | A. 其他 / B. 服务渠道 / C. 前台服务 |
序号是整批连续编号（1..N），跨块不重复；
状态为「待确认」的行，其「候选分类」就是给人工或下游系统的下拉选项（A 为 AI 首选）。
5为什么这样设计（三个关键决定）
分块
一次判 100+ 条时，模型在超长推理里前面影响后面，同一份数据两次跑出 74/34 和 97/11。
压到每块 10 条后，块内不需要长推理，结论就稳了。
独立
用循环容器让每一块单独调用，块与块互不影响；
temperature=0 保证同一输入得到同一结论。
代码裁决
模型只负责分类；是否算"不确定"由代码按分类文字判定，不采信模型自报的标记，
所以状态列稳定可复现。
6稳定性与可观测性
解析器能接受这些输出形态
| 模型输出 | 是否接受 |
|---|---|
JSON 数组 [{...},{...}] | 接受 |
单个 JSON 对象 {...} | 接受 |
带 <think> 思考前缀 | 自动剥离 |
```json 代码块包裹 | 接受 |
输出被截断（结尾没有 ]） | 保住已解析记录 |
| 空 / 纯文字无 JSON | 该块记失败并提示 |
报告会主动告诉你哪里出问题
本次共处理 108 条工单：已确定 97 条，不确定 11 条。 （共 11 块：成功 11 块） — 若某块失败 — 本次共处理 89 条工单：已确定 89 条，不确定 0 条。 （共 11 块：成功 10 块，失败 1 块，其中 1 块被截断） ⚠️ 有 1 块的模型输出无法解析，这部分工单未计入，请重跑 ⚠️ 另有 9 条因输出被截断未返回，请重跑这批
丢了多少条、是哪一环丢的，报告里直接写出来——不会静默少数据。
7怎么用 / 注意事项
使用步骤
- 导入工作流 → 打开「开始」节点，上传本批工单文件
- 运行；查看输出
report_md（一句话统计） - 下载
output里的 CSV，按「状态」筛选待确认行
注意事项
- 模型需选非思考的
qwen3.7-max；开启思考会占满输出额度导致 JSON 出不来 - 若报告出现 ⚠️ 失败/截断：重跑该批，或把
CHUNK_SIZE从 10 调到 5 - 换模型或换分类体系不需要改代码：改模型下拉、改提示词清单即可
8一句话总结
把"一批工单"切成每块 10 条，逐块独立判定，再由代码统一编号与打标 ——
既拿到大模型的分类能力，又保证了结论可复现、异常看得见。
人只需要看「待确认」的那几条。