同名名单怎么合并？按编号关联、保留缺失项，再逐条核对

先确定“同一个人”的证据来自哪里

编辑建议是先写清主键的含义：员工编号是否在两个系统中代表同一身份，是否可能重用，前导零是否有意义。只有名字相同、部门相近或列表位置相同，都不足以替代这个确认。允许的标准化也要单独写明，不让 AI 自行删字符或补编号。

RFC 8259区分 JSON 字符串与数字，并建议对象成员名称唯一。这是数据表示规则，不是身份核实方法。姓名直接当对象键，会难以保留同名记录；使用记录数组并把编号保留为字符串，可以表达多条同名输入。转换时可参考CSV 与 JSON 的编号检查。

四条输入，三种不同的处理决定

以下名册、编号和培训信息均为本站虚构示例，不含真人资料。假设两个系统的 staff_id 已被业务负责人确认使用同一个编号体系；本例不允许从姓名推断缺失编号。R01 与 R02 名字相同，编号不同；T01 的名字是缩写，编号与 R01 一致。

期望决策是 T01 与 R01 匹配、R02 暂无对应培训记录、T02 待确认。它不证明培训缺席，也不能推出 T02 属于哪一个林晨。

先准备两份原表，不把它们纵向堆到一起

练习包提供directory.zh.csv、training.zh.csv及英文对应文件，另有expected-links.csv与review-ledger.csv。每次只导入一种语言的两份原表。答案账本用于对照，不作为第三张输入表；这些是编辑设计材料，不是模型实测。

保留source_row作为来源证据。两份原表虽然共享一些列名，记录对象不同。不要点击“纵向合并全部表”：它只是追加记录，不会建立名册与培训的关系。

source_row,staff_id,name,department
R01,E007,林晨,Design
R02,E021,林晨,Operations

source_row,staff_id,name,course
T01,E007,L. Chen,Intro
T02,,林晨,Intro

让 AI 返回决策，而不是只给一份缩短名单

可以把下方规则与四条记录一起提交给获得授权的 AI 服务。用虚构数据试验，真实名单遵守组织的数据处理规则。提示词提供的是工作约束，不能保证模型执行无误；仍需逐行检查输出。

1. 1
   先保存四条原始输入，给每行稳定的来源编号，保留空值与原样姓名。
2. 2
   人工确认两份资料的编号体系，写明可允许的标准化。本例只做完全一致的编号匹配。
3. 3
   让 AI 返回每条来源的决策与理由，把缺失或冲突单独列为待确认。
4. 4
   逐条对照：T01 的理由必须是 E007，而不是名字相似；T02 不能被悄悄分配。

Treat each source row as evidence. Match records only by the supplied staff_id, whose shared meaning has been confirmed. Keep IDs as strings. Do not match by name, row order or department.
Return: source row IDs, decision, matched row IDs, reason, unresolved question.
Allowed decisions: matched, unmatched, unresolved.
Missing or conflicting IDs must remain unresolved. Keep every source row traceable.
For R01/R02/T01/T02, explain which rows can be linked and which require confirmation.

在工具中做完整外关联，并核对左右来源列

打开数据清洗与分析。关联读取所选两份原始表，不读取已确认的清洗结果。当前关联会去掉键首尾空白；本例编号没有这些空白。若业务规则要求首尾空白也必须区分，应使用符合该规则的匹配方式。

1. 1
   同时导入directory.zh.csv与training.zh.csv，展开“关联与差异（原始表）”；左表选名册，右表选培训。按文件名核对，不盲信导入顺序。
2. 2
   关联键选staff_id，关联方式选完整外关联，再点“按键关联”。保留左右两边source_row、staff_id及原样姓名。
3. 3
   结果应为三行：R01–T01、R02–空白、空白–T02。若选左关联，右侧未匹配T02不会进入结果，必须另留待确认账本。
4. 4
   下载CSV并重新打开，先看来源侧列名，再按来源配对与expected-links.csv核对，不依赖结果行顺序。

工具完成的是键匹配，不核实两套编号体系，不判断出勤，也不会自动生成这些业务审核决定。

用来源覆盖检查代替“人数差不多”

同样是三行，为什么仍可能完全错配

在新一轮练习中，故意把关联键改成name，仍做完整外关联。R01、R02都会因同名而联系到T02，L. Chen的T01反而落成未匹配。结果仍是三行。这是故障教学副本，不是某个模型的错误率测试。

核对来源对：正确结果有一次R01–T01，错误结果把T02用在两条关系中。退回姓名结果，把键恢复为staff_id，重跑并重新下载。不要靠删除一条同名结果“修复”，否则会丢掉独立员工编号。

缺失、别名和冲突要走不同的处理路线

缺失 ID 时向有权确认的人或源系统核对；不要让模型依据常识猜测。编号相同但部门等字段冲突时，保留两边值和版本，不能假设较长文本就是较新资料。若编号体系不同，需要经过确认的映射表，再做跨系统匹配。

空字段也不能改成 0 或“无”。可以按AI 提取表格的缺失与零值区分记录未提供、待确认和明确不存在。姓名可以帮助人工检索候选，但不自动成为合并证据。

交付一份能回到原始输入的匹配结果

保留原始资料、匹配规则、输出和人工确认记录。若需要汇总统计，先定义统计的是人员、来源记录还是已确认匹配；本例的四条输入不等于四个人，也不能由待确认条目推导完整人数。小样例通过后仍需检查真实资料的编号重复与覆盖范围。