验收Telegram用户名+头像结果的重点，不是要求每一行都有用户名、头像、年龄和性别，而是确认每个结果都能回到输入号码，字段符合所选任务，缺失值有一致解释，异常行能够被单独处理。下面是一套适合交付前执行的四关验收法。
第一关：先把输入基线锁定
上传前将授权号码整理成TXT，一行一个国际格式号码。记录原始行数、空行数、格式错误数和去重后的唯一号码数，同时保存source_row_id映射。Excel导出后的行数只有与这些基线对照，才知道差异来自去重、无效输入还是任务异常。
| 基线指标 | 用途 |
|---|---|
| 原始行数 | 说明收到的名单规模 |
| 规范化成功数 | 衡量可提交号码 |
| 唯一号码数 | 作为任务覆盖率分母 |
| 来源映射数 | 确保结果能回填所有授权记录 |
任务字段可从Telegram产品页核对；专题文章位于用户名+头像知识页。
第二关：核对字段，而不是只看文件名
当前用户名+头像任务可包含手机号、TG UserID、TG用户名、离线时间、活跃天数、First Name、Last Name、TG VIP、是否冻结、头像URL、年龄和性别。验收时以实际表头为准，检查是否误用了基础用户名任务或另一种全格式任务的结果。
- 手机号应保持文本格式并能连接TXT输入。
- TG UserID与用户名必须是两列。
- 头像URL与年龄、性别不能合并成一个“头像状态”。
- 任务日期和字段版本应随交付记录保存。
第三关：用分层覆盖率发现问题
不要用一个“完整率”概括所有列。至少分别计算账号标识覆盖率、用户名覆盖率、头像URL覆盖率和头像分析覆盖率。分母应使用成功进入结果的唯一号码数，异常行另列。这样可以识别“账号字段正常但头像缺失”与“整行任务失败”的区别。
| 指标 | 计算方式 | 不能说明 |
|---|---|---|
| 用户名覆盖率 | 用户名非空行/有效结果行 | 账号真实性或联系许可 |
| 头像URL覆盖率 | URL非空行/有效结果行 | 图片一定可分析 |
| 分析覆盖率 | 年龄或性别有值行/有头像行 | 属性经过身份验证 |
第四关：建立异常清单并抽样复核
把异常分成输入格式错误、整行未返回、头像URL异常、分析字段缺失和字段类型异常。每类抽样时都从手机号回查TXT和来源记录；不要通过公开搜索扩展不必要的个人资料。需要重跑的行单独生成TXT，并关联原task_id。
交付包应包含三份文件
- 原始导出：只读保存，不改字段值。
- 工作表：增加source_row_id、task_id、checked_at和review_status。
- 验收说明：写明行数、覆盖率、异常数量、抽样范围和未解决问题。
相关任务的选择与边界还可在Telegram筛号知识中心查看。交付对象只应获得完成其工作所需的字段。
常见问题
头像覆盖率低就说明任务失败吗？
不一定。先看账号字段和任务状态是否正常，再区分头像本身未返回与整行异常。头像不是每条记录必然具备的字段。
年龄和性别为空时能填“未知”吗？
可以在工作表的标准化展示列标记“未知”，但原始结果列应保持空值，并在字段字典中说明转换规则。
重复号码应该保留几行？
任务输入可按规范化号码去重，但必须保留到所有来源行的映射。不要因去重丢失合法的业务上下文。
是否需要逐行人工检查？
通常先做规则校验，再按异常类别和正常结果分别抽样。高风险用途不应仅依赖自动结果。
验收的目标是可解释，而不是零空值
覆盖率、异常清单和来源映射共同回答“这份结果是否可用”。只要每个空值被正确保留、每个异常有去向、每个结果能回到输入证据，交付就比一张被强行补满的表更可靠。
