为什么同一批条记录在几份交件里行数和顺序都对不上

同一批条记录在几份交件里行数与顺序不同，不是因为它们从不同项目取数，而是因为它们从同一份按创建时间取得的快照出发以后，各自采用了不同的排序键和展开粒度。表格式产物保留创建时间序，结构化清单重新按场、镜、条排序，可读日报又使用另一套镜头键；与此同时，前两者会按机位展开，而日报仍是一条 take 一行。

跨文件对表时，稳定的共同键是场、镜、条身份，不是“第几行”。

起点相同，后面的排序规则不同

快照最初按记录创建时间升序取得。表格式产物之后不再重排，所以它基本保留这个创建时间顺序。结构化清单会重新按场次、镜头编号与条号排序，其中场次和镜头使用自然序比较。于是数据来源相同，但行的位置已经和表格式产物分开。

可读日报还会再走一套排序：场次之后，它使用镜头的限定名作为第二把键，再按条号排列。这个限定名并不等于结构化清单使用的原始镜头编号，因此两份文件即使包含同一批 take，也没有“第二行就应该对第二行”的关系。

界面日志还有另一套顺序。它按镜头号字符串升序，再按条号升序。字符串排序下，10 会排在 2 前面。这是界面层自己的显示顺序，也不能拿来反推导出文件中的位置。

行数不同，核心在于是否按机位展开

结构化清单和表格式产物都按机位展开：一条 take 如果包含多个机位，会生成多行；没有机位时也会保留一行。可读日报不同，它按 take 数成行，因此一条多机位 take 仍然只占一行。

这也解释了为什么同一个现场记录集合会产生不同的总行数。一个多机位 take 在清单与表格里会被拆开，而在日报里仍是一个 take。日报那一列看起来像序号的 No. 还是整份文档的行号，不是 take 编号，所以更不能把它作为跨文件的对表键。

行数不同来自产物粒度不同；它不等于某一份文件“多了一条拍摄”或“少了一条拍摄”。

镜头标识在不同产物里也可能不是同一个字符串

可读日报会使用镜头限定名，而表格式产物的镜头列使用原始镜头编号。一个镜头在界面或某份文件中可能带着场次前缀或限定形态，在另一份文件里只保留较短的编号。接收方应把它们放回场、镜、条关系中理解，而不是仅凭某一列字符串全等来判断是否同一条。

这里描述的是我们产物侧的机制。当前证据不能继续断言某个下游软件会因此如何错配、漏配或拒绝导入。具体接收行为仍应由接收方按自己的导入模板逐列核对。

对表时应该用什么

跨文件核对时先锁定场次，再锁定镜头，再看条号；多机位记录还要继续看机位。这样做的目的，是把身份关系当作共同语言，而不是把某一份文件偶然出现的行位置当成主键。

如果两份文件的总行数不同，先问它们是不是采用了不同的展开粒度；如果顺序不同，再看它们是不是用了不同的镜头排序键。只有身份关系本身对不上时，才需要回到源记录检查，而不是先要求几份产物行行对齐。

这套差异是生成机制的结果，但“机制如此”也不等于可以忽略核对。每一份产物承担不同职责，接收方仍需确认自己使用的字段确实能回到同一条现场记录。

FAQ

为什么表格式产物和结构化清单顺序不同？

因为表格式产物保留创建时间序，而结构化清单会按场、镜、条重新排序。两者从同一批快照出发，但后续排序规则不同。

为什么多机位时几份文件的总行数不同？

结构化清单和表格式产物按机位展开，一条多机位 take 会占多行；可读日报按 take 成行，所以同一条 take 仍只占一行。

日报里的 No. 可以拿来和另一份文件的行号对吗？

不应该。日报的 No. 是整份文档的行号，与 take 编号不是同一个概念，不能作为跨文件身份键。

几份文件应该用什么共同键来核对？

优先使用场、镜、条身份，并在多机位记录上继续核对机位；不要把行号或某一份文件的排序位置当成共同键。

上海智独教育科技有限公司 — SlateX。以上数字截至 2026-09-24。