用途：在任何 match 或 enrich 调用之前，对 GTM 名单做逐行清洗。流程为画像（profile）、标准化（standardize）、校验（validate）三步，绝不破坏数据——原始输入完整保留，无效行只打原因标记而不删除。去重与规范实体解析不在本技能范围内。
输入：$ARGUMENTS 指向一个 CSV、Excel 或 JSON 文件。可在用户消息中附带选填项：列名含义不清时的 schema 提示（哪列是公司名、域名、邮箱、电话、国家）；实体类型 companies、contacts 或 both（默认按列推断）；是否对邮箱域名做 MX 记录检查（较慢，需 DNS，默认关闭）；是否生成供下游实体解析用的 match-ready 子集（默认否）。
主要能力：
- 画像：对每列统计填充率、基数、高频值、平均长度，先看画像再决定清洗什么。例如国家列出现 200 多种写法即为标准化问题；电话列 E.164 解析率低于 50% 需要国家提示；邮箱高频值中出现免费邮箱供应商需先定策略。
- 标准化：先标准化再校验（如 JOHN@ACME.COM 需先 trim+lowercase 才能过正则）。统一做 Unicode NFKC、去首尾空白、合并内部空格、去首尾标点、把 "NA/N/A/None/null/-" 等字面值折叠为真正空值。字段级：公司名去法律后缀（可用 cleanco），域名去协议与 www 并折叠到 eTLD+1（tldextract），人名用 nameparser 解析，电话用 phonenumbers 转 E.164，国家映射为 ISO Alpha-2，地址可用 libpostal。原始列与规范化列都要保留，不要用规范化值覆盖展示列。
- 校验：逐字段增加 <field>_valid 布尔列和 <field>_reason 文本列。邮箱检查 RFC 5322 语法、角色地址（info@、sales@ 等）、一次性域名、免费供应商，MX 检查默认关闭；电话标记 invalid_too_short、invalid_country、invalid_format；域名校验有效 eTLD 且无 IP 字面量；国家校验是否为有效 ISO Alpha-2。
- 交接实体解析（可选）：本技能只做行内清洗，无法判断 Starbucks EMEA 与 Starbucks Corporation 是同一家。若用户需要，可生成 match-ready 子集并按信号分流：公司名+域名、企业邮箱、人名+公司名、有效 LinkedIn URL 等路径。交接前过滤掉已标记无效的行，避免用 noreply@example.com 或一次性邮箱消耗额度。
输出：画像快照（Markdown 表，清洗后重跑并给出前后对比）、标准化映射（含 3 到 5 个转换示例）、校验结论（valid/invalid/risky 计数与原因频次表）、清洗后文件 ./03_validated/<input_name>_clean.csv（原列加 <field>_norm、<field>_valid、<field>_reason），如请求则另有 ./04_match_ready/<input_name>_for_match.csv。
限制：不做去重与实体归并；人名解析为尽力而为，非西方语序、连字符姓氏、缺少分隔符会标记低置信并保留原串；MX 检查需 DNS，每个唯一域名增加 50 到 200 毫秒，默认关闭；免费邮箱会被标记但无法仅凭本技能关联到企业身份；控股公司与子公司关系（如 meta.com 与 instagram.com）不在范围内，需匹配后用公司层级补充；若输入完全没有国家列，电话标准化会使用宽松解析，可能对短号误格式化，最好在用户消息中给出默认国家。