给铭文交易做体检报告：解码输出里那几个布尔字段

铭文出了问题，多数人的第一动作是去市场页面刷新、去钱包看余额、去客服提问。但 ord 生态里其实有一台本地听诊器：解码接口。对一笔交易运行解码（命令行或 API 的解码端点均可，手册注明该接口与命令行解码结果一致），返回的 JSON 会把交易内每个铭文信封逐字段拆开。今天只讲这份“体检报告”里最有用的一组内容：几个布尔标记。

先看信封的基本结构。铭文的刻写脚本本质上是一条“边界内的数据串”：开始标记之后，依次放入若干字段，以内容分隔标记划分出头与正文。字段的编号有奇偶之分，规则在编号机制篇讲过，这里只取结论：正文之后再出现某些不符合规范的字段，会触发单列计数。解码输出正是按这套解析逻辑生成的，所以它的标记就是索引器眼中的“格式判决”。

逐项读这份报告。duplicate_field：同一个字段在头里出现了两次。规范期望每个字段各司一次，重复即异常，标记为真。incomplete_field：字段声明了却没有完整的值——比如声称有内容类型却没给出类型串。半截字段比没有字段更糟，因为它可能让整条铭文落入异常类。unrecognized_even_field：正文之后出现了未识别的偶数标签字段——这一项是“诅咒化”的经典扳机之一，命中它的铭文往往拿不到正向编号。pushnum 与 stutter 之类标记则针对脚本写法的低级形态：把数字直接压进字段、同一值连压两次。这些标记全部为假，才是一封格式干净的信。

报告里另外两个字段值得单列：pointer 与 delegate。指针记录内容归属输出位置的指定值，填错会导致铭文“没有落在预期输出上”；委托记录目标铭文的序列化编号，非空说明这件藏品是引用件。把它们和布尔标记连起来看，很多悬案立刻有了物证：钱包说“我没刻上”的铭文，解码后可能显示 pointer 指向了一个不合适的输出；显示 delegate 非空的藏品，画面空白该去查目标件而不是骂市场。解码输出里还顺带给出正文的字节数组——PNG 文件的开头字节直接肉眼可辨，连“内容装错了袋子”这种事故都能当场识破。

自查的推荐顺序：拿到自己那笔交易哈希，先跑解码看布尔标记——任何一项为真，问题出在刻写工具生成的脚本上，重刻往往是唯一干净解；全假，再看指针与输出结构，确认铭文当前挂在哪个输出上；再全正常而展示端仍异常，责任面基本收敛到索引器或渲染端，换入口交叉验证即可。三个步骤各对应一类根因（配置、事实、软件），顺序颠倒就会把配置问题当故障修，甚至无谓地重建数据库。

读这份报告时还值得注意两个坐标字段：input 与 offset。它们记录信封所在的输入序号与脚本内位置——一枚铭文从哪笔输入、脚本的第几段被解析出来，都在这两个数里。这两个数与 satpoint 联动，能把“铭文现在住在哪个输出”讲清楚：解析记录给出出生坐标，持仓坐标由索引持续追踪。工具界面从不会把这些摆在你面前，但排障时它们是分辨“刻写时的异常”与“转手后的漂移”的分水岭——出生坐标异常是脚本问题，出生正常而 satpoint 频繁变动是记账结构问题（找零与合并的正常产物），两者的处置方式完全不同。把解码报告当病历本，先分清病灶在哪一层，再决定找谁修。

最后一个心态提醒：这些字段标记反映的是索引实现按规范执行的机械结果，没有商量的余地，也没有情绪。与其在社群里晒截图问“为什么我的编号是负的”，不如学会读这几行布尔值——五分钟能自答的问题，不值得等二十四小时。本文为机制说明，不构成任何投资建议。