在业务上，铭牌建档是一个动作：设备到货，现场人员对着铭牌拍一张照片，资产卡片的字段随之生成。 在实现上，这个动作包含两个性质不同的子问题。
两项要求并列时，彼此并不冲突；但若交由同一次模型调用完成，会带来一个具体困难：输出的错误无法归因。 同一个填错的字段，可能源于视觉模型读错了字符，也可能源于模型对台账字段的推测。 两类偏差的修复方式完全不同——读取偏差要调整图像条件与提示词，归位偏差要调整字段映射规则。 缺少这一段区分，修正工作只能靠试错推进。
管线的第一项设计决定，就是把这两件事分开：识别交给模型，归位交给规则。
第一阶段（Stage 1）的输入是一张铭牌照片，输出是一组键值对（RawField[]）。
视觉模型采用 Qwen3-VL-32B-Instruct，配以工业铭牌 OCR 专用提示词，要求输出标准 JSON。
这一阶段的关键约定是：Stage 1 不接触台账 Schema。 模型不知道资产卡片上定义了哪些字段，也不知道资产分类编码的层级结构，只被要求把照片上出现的键值对如实读出。
| 项 | 内容 |
|---|---|
| 输入 | 铭牌照片一张（现场拍摄，光线与角度不受控） |
| 输出 | RawField[] 键值对，保留牌面原文 |
| 模型与提示词 | Qwen3-VL-32B-Instruct；工业铭牌 OCR 专用提示词，要求输出标准 JSON |
| 不涉及 | 台账字段定义、资产分类编码、动态表单结构 |
| 后续接口 | 有效性检查未通过的图片不进入下一阶段（见 06 节） |
口径：模型标识与提示词要求取自内部实现记录；「不涉及」一栏为该阶段在代码层面的调用边界。
这一约定带来两项结果。其一，提示词与台账字段解耦：台账新增字段时，识别侧的提示词不必改写。
其二，识别结果可被多个消费端复用：同一份 RawField[] 既可用于构造资产卡片，也可用于与合同、发票等来源做交叉比对。
第二阶段（Stage 2）的输入是 RawField[]，处理方式是查表，其中不含模型调用。
映射规则集中在一份静态表 FIELD_MAP 中，共 60 条，按精确匹配、模糊匹配、未命中三级顺序执行。
| 顺序 | 匹配方式 | 命中结果 | 未命中时的去向 |
|---|---|---|---|
| 1 | 精确匹配 | 归入对应的台账字段 | 进入下一级 |
| 2 | 模糊匹配 | 归入最接近的台账字段 | 进入下一级 |
| 3 | 未命中 | 不归入台账字段 | 写入 technicalSpecs（技术参数 JSONB） |
口径：60 条规则与三级顺序取自内部实现记录；单次匹配耗时低于 0.5 毫秒，该阶段无网络 IO。
查表方式带来三项可预期的性质。
RawField[] 重复执行，归位结果一致。FIELD_MAP 追加一条入口即可，提示词与模型均不调整。两阶段切分的实质是把可确定的部分从模型里移出来。 识别环节保留模型的判断能力，归位环节改为规则执行。 由此，字段归类的正确率不再随模型版本波动，新增字段的成本也不再体现为一次提示词改写。
归位的结果按值的来源分为三类。这一分类与字段的重要性无关，只说明该值是如何得到的， 以及界面应当以何种方式呈现。
| 类别 | 值的来源 | 界面呈现 | 写入位置 |
|---|---|---|---|
| A 类 | 铭牌上直接读出，FIELD_MAP 精确命中 | 绿色，直接带出 | 资产台账字段 |
| B 类 | 由已有信息推断得到 | 黄色，待人工确认 | 资产台账字段 |
| C 类 | 未命中映射规则的技术参数 | 归入技术参数区 | technicalSpecs（JSONB） |
口径：A / B / C 三类划分与着色方式取自内部实现记录；着色规则的完整说明见技术系列《动态表单与置信度着色》。
A 类字段的可信度直接来自视觉模型的提取质量，因此识别环节的处理条件（拍摄光线、铭牌反光、字迹磨损） 会直接反映在这一类字段上。C 类的写入位置与台账字段分离，未命中映射规则的参数不会因此丢失， 也不会被强行塞进某一字段。
三类字段组装为动态表单卡片，由 prepare_equipment_form 完成。
该环节属于消费端：它决定字段以何种顺序、何种分组呈现给现场人员，其输入是前两阶段的输出。
管线本身到此为止，第三段不计入两阶段管线的定义。
分段之后，耗时可以逐段归属，性能问题因此具备定位路径。
| 环节 | 主要成本 | 计量方式 |
|---|---|---|
| Stage 1 | 网络往返与视觉模型推理 | 单张照片的端到端耗时 |
| Stage 2 | 规则匹配，低于 0.5 毫秒 | 进程内计时，无网络 IO |
| 表单组装 | 卡片构造 | 进程内计时 |
这一计量方式给出过一次明确的判定：早期单张照片的端到端耗时约 130 秒，
而 Stage 2 与表单组装合计不足 1 毫秒，全部耗时集中在 Stage 1。
定位到该段之后，原因落在视觉模型的思维链开关上——思维链开启时推理过程被完整展开，
关闭该开关（enable_thinking=false）之后降至 3 至 8 秒。
与耗时定位相关的一项实现记录是客户端的选择。管线采用 OpenAI 原生客户端：
在此之前使用 Vercel AI SDK 时，enable_thinking 参数没有被正确转发至上游，
模型始终以默认状态运行，导致该项设置在一段时间内实际未生效。
本节所述的内容仅为耗时归属的判定路径。 130 秒到 3 至 8 秒的完整调优过程、测试条件与实测口径，属于落地篇的范围， 见技术系列《基于 Qwen-VL 的铭牌识别与设备台账自动建立》。 本文不重复列出该篇的测试数据。
识别类内容容易被写成超出事实的表述。以下四项为本文所述管线不作出的承诺。
| 事项 | 本文的表述 |
|---|---|
| 识别准确率 | 不承诺 100%。未能识别的字段回到待填状态，系统不按经验值假定填充 |
| 无效图片 | 有效性检查未通过时不展开空白表单，改走 LLM 降级路径，由对话方式补齐信息 |
| 多源冲突 | 铭牌、合同与发票可并行提取；同一字段出现多个值时取置信度较高者，冲突本身留痕供复核 |
| 完全无人值守 | 不承诺。B 类字段与低置信度的 A 类字段需要人工确认之后方可入账 |
口径：本表为本文的表述范围说明；四项内容与内部实现记录中的失败处理路径一一对应。
技术系列各篇说明的是同一套系统的不同侧面。与本文直接相邻的有三篇，分工如下。
| 篇目 | 回答的问题 |
|---|---|
| 本文 · 铭牌 OCR 的两阶段管线 | 管线为什么切成两段，切口落在哪个位置，这一处理的代价是什么 |
| 技术系列 03 · AI Pipeline 编排器 | 意图明确时的快速通道如何并入整体编排 |
| 技术系列 05 · 基于 Qwen-VL 的铭牌识别与设备台账自动建立 | 从铭牌照片到设备台账的完整落地过程与实测口径 |
| 技术系列 07 · 动态表单与置信度着色 | 识别结果的可信度如何呈现在表单上 |
读取环节的能力上限由视觉模型决定，归位环节的能力上限由映射规则覆盖的字段范围决定。 将两者分列，是为了在讨论识别效果时明确所指的环节：模型升级影响的是前者， 台账字段调整影响的是后者，两者的评估方式与投入方式并不相同。
FIELD_MAP 的规则条数与匹配顺序、三类字段的划分方式；enable_thinking 参数的转发问题与客户端调整记录两阶段的调用边界、60 条映射规则、三类字段的来源划分、130 秒与 3 至 8 秒的耗时归属—— 上述各项均标注了判断口径。贵方可在演示环境上核对与资产建档、卡片字段相关的动作数量。