文件清单有重名怎么办：用相对路径核对交付文件

开始前先确认

交付核对最先要解决的是“这一行指向哪份文件”。为清单选定一个共同起点，再保留相对路径，通常就能区分只看名称无法分辨的附件。至于内容是否相同、哪个版本可交付，需要另行检查。

相对路径要有明确的起点

相对路径记录文件在某个根目录下的位置，不必带出本机用户名或盘符。但没有说明根目录，单独一段相对路径仍可能产生歧义。把清单标题写清“本清单相对于交付包根目录”，比只给一列路径更容易理解。

示例：假设交付包里有以下三个文件：

handoff/
  images/cover.png
  archive/cover.png
  notes/readme.txt

若只列文件名，得到的是两条cover.png和一条readme.txt；保留相对路径后，三条记录分别是images/cover.png、archive/cover.png和notes/readme.txt。这里有3条文件记录、2个不同的文件名，但不能据此说存在1个可删除的重复文件。

两个cover可能内容一样，也可能分别是新封面和旧封面。路径帮助定位，不能代替打开文件、查看版本记录或其他内容核验。

把“重名”拆成几种情况

如果同一批清单被复制粘贴两次，可以在清单副本中标记重复记录，核实后整理表格。删除清单里一条重复行与删除磁盘文件是两件事，本流程不要求删除、覆盖或重命名源文件。

即使两份文件大小相同，也不能单凭大小认定内容一致；修改时间较新，也不自动说明它是已批准版本。需要内容比较或校验时，应单独采用合适的方法，并明确结果能证明什么。

多个来源合并时，增加来源列

假设甲、乙两个交付包中都含images/cover.png。各自包内的相对路径相同，合并清单时就应增加“来源包”字段，例如“甲批次”和“乙批次”。以“来源包＋相对路径”作为这一轮核对依据，避免把两条记录混成一条。

不要为了让名称唯一，先把所有文件摊平复制到一个目录。这样可能遇到覆盖，也会丢失原来的组织关系。若业务确实要求改名，应另建交付副本并保存旧路径与新路径的对应关系，再核对引用是否仍然有效。

仅为盘点或确认附件是否齐全时，保留目录结构通常更容易追溯。不确定用途的归档文件也先保留，交付范围由实际要求确定，而不是由文件名决定。

生成清单后，先检查覆盖范围

网页工具只能处理当前获得的文件信息。选择了一个目录，不等于已经证明所有层级、所有隐藏项或所有设备文件都被列出。先检查实际列表里是否出现你已知的几个代表文件，包括根目录文件和需要交付的子目录文件。

若某个子目录内容缺失，先确认选取范围、浏览器提供的条目和工具实际行为，再补充处理。不要把未出现的条目直接判定为不存在，也不要宣称工具具备未经验证的完整递归扫描能力。

基本操作与字段选择可参考文件名清单指南。制作清单是记录已读到的信息，文件内容是否损坏、版本是否正确仍需另外验收。

核对交付，按路径回到实际文件

先在清单副本里增加“已找到”“待补充”“版本待确认”等人工状态。逐项到交付包对应路径找文件，打开必要内容，并将不确定项写清楚。这里的状态是你自行记录的核对结果，不是本站已提供的审核功能。

CSV适合筛选和标记，但导入后要看中文、分列和路径是否完整；TXT适合直接查看和复制。不要因为表格列宽太窄、路径显示不全就删掉前半段，调宽显示或查看完整单元格即可。

有多份清单时记录生成日期与范围，避免把旧列表当成当前目录快照。资料增删或目录调整后，应重新核对变化，而不是只更新清单标题里的日期。

最终交付让别人也能定位

交付包与清单使用同一个目录结构，说明根目录、是否包含归档内容以及尚未确认的条目。先在副本中检查路径，再让接收方按同一规则查看；不要要求对方猜“第二个cover是哪一张”。

验收至少包括记录数量、来源标识、相对路径、重名解释和待确认项。数量相等不代表内容一致，因此不要把“清单共多少行”写成“所有文件完整无误”。原始文件与原清单保留，整理过程不以删除源文件作为必要步骤。

需要生成初始清单时，可打开AI Lab文件名提取。公开说明支持读取主动选择的文件信息并导出TXT或CSV，9积分解锁后当前账号长期有效。本文没有核验哈希计算、内容比较、自动去重或批量重命名能力，不把这些任务归给它。