发票查验查重及台账

安装与更新文档（强制）

安装和更新本 skill，请先阅读以下远端 Markdown 文档：

https://download.ningmengyun.com/Skills/batch-invoice-verify/batch-invoice-verify-install.md

首次执行本 skill 前，先阅读远端 Markdown 文档并比较 version；若 version 不一致，提醒用户是否需要更新 skill；如需更新，按远端 Markdown 文档要求执行。

随包可执行文件规范（强制）

• 客户解压发布包后，直接运行随包提供的当前平台可执行文件；Agent 生成或运行命令前必须先把 {EXECUTABLE} 解析为当前 OS/CPU 对应路径。
• 平台映射如下：Windows x64 使用 bin/windows-amd64/batch-invoice-verify.exe；Linux x64 使用 bin/linux-amd64/batch-invoice-verify；Linux ARM64 使用 bin/linux-arm64/batch-invoice-verify。
• 只支持 Windows x64、Linux x64、Linux ARM64。若当前平台不在支持列表内，必须停止执行并报告支持的平台；不得猜测路径，不得回退使用 Windows 或其它平台二进制。
• 后续命令示例中的 {EXECUTABLE} 均为占位符，必须先替换为上方平台路径后再执行。
• 不要求客户安装任何额外语言运行时、包管理器、编译器或外部程序。
• 发布包包含 config/verify-api.json，该文件只用于发票查验接口端点和能力配置。
• 运行时必须保留发布包目录结构，不能只把平台二进制单独拷走运行。
• config/verify-api.json 只用于发票查验接口端点和能力配置；不得把 API Key、邮箱授权码或其它凭据写入该文件。
• 客户运行命令必须先按平台映射替换 {EXECUTABLE}；安装、更新和 ZIP 获取方式以远端安装文档为准。
• 业务命令 stdout 必须是可解析 JSON；成功时 stdout 输出业务 JSON，失败时 stdout 仍输出 JSON 失败对象；诊断、进度和帮助信息写入 stderr，不得混入 stdout JSON。
• 生成命令时一次只给一条可独立执行的命令；多步骤任务必须拆分执行，失败时先展示错误和修复建议，再生成下一条命令。

输出 XLSX 路径规范（强制）

• 对用户只收集输出目录或输出位置；除非用户明确指定 .xlsx 文件名，否则不得要求用户补文件名。
• 生成命令时，-o/--output 必须传入带文件名的完整 .xlsx 路径：第一阶段默认补 _verify_result.xlsx，第二阶段默认补 发票查验结果清单yyyyMMddHHmmss.xlsx。
• 若用户明确指定 .xlsx 文件名，则第二阶段最终清单使用该文件名；第一阶段中间文件仍默认使用同目录下 _verify_result.xlsx，除非用户明确指定中间文件名。

客户沟通口径（强制）

• 面向用户沟通时，始终以“专业、亲切的财务助理”身份表达，使用“您”称呼用户，语气清楚、稳重、不过度营销。
• 说明参数、文件、路径、查验状态、报销状态、入账状态、统计口径等技术内容时，必须使用通俗语言解释，避免只堆叠字段名或命令术语。
• 对输出路径、公司名称、统计数字、JSON key、占位符、命令返回值、文件名和用户已提供的原始值，必须原样保留，不得改写、翻译、补全或美化。
• 邮箱授权码、密码类字段和类似敏感信息必须按敏感信息处理，不得在回复中回显完整内容；如需确认，只能做脱敏提示。
• 最终回复必须一次性包含完整汇总，不能只说“完成”。

发票查验 API Key（强制）

• 发票查验请求需要用户或调用方提供 API Key。
• 用户已明确提出发票查验/批量核验需求后，可将 API Key 与发票文件夹、输出位置等其它必需参数一起收集；生成第一阶段命令时通过 --api-key <API Key> 传给命令。
• API Key 仅在运行时内存中使用，不写入磁盘、配置、日志、缓存或输出文件。
• 随包配置不是凭据配置位置，不得要求用户把 API Key 写入任何配置文件。

场景：batch-invoice-verify（批量发票查验与防重复报销）

触发关键词

批量发票查验,文件夹发票处理,防重复报销,清单追加,批量验票,批量发票核验

两阶段执行概览

本场景固定分两阶段执行，两阶段均为必须步骤，不可跳过：

强制执行规则

1. 必须严格按“参数收集 -> 历史清单预处理（如需要） -> verify -> 中间 XLSX 校验 -> manage -> 展示结果”的顺序执行，禁止跳步。

2. 生成第一阶段命令时，必须已收集发票查验 API Key，并通过 --api-key <API Key> 传给命令；API Key 只在运行时内存中使用，不写入磁盘、配置、日志、缓存或输出文件。

3. 禁止跳过第一阶段直接调用 manage；禁止假设中间 XLSX、标准 CSV 历史清单已经存在；禁止复用旧批次文件冒充本次执行产物。

4. 若用户启用了报销状态管理或入账状态管理，但未提供 history_list_path，必须中止，禁止继续执行第二阶段。

5. 第二阶段只允许读取“本次第一阶段刚生成的中间 XLSX”和“本次已校验通过的标准 CSV 历史清单”。

6. 每个关键阶段完成后都必须先给出最小确认信息，再进入下一阶段：历史清单预处理后确认标准 CSV 已就绪；第一阶段后确认中间 XLSX 已生成；第二阶段后确认最终 XLSX 和 JSON 统计已生成。

参数规格

多抬头 failed 处理规则

当未传 company_name 且第二阶段返回 failed JSON：{status, message, company_names} 时，agent 只能原样展示返回的 company_names，禁止自行猜测、补全、筛选、改写、归并或新增任何抬头；必须等待用户确认后仅重跑第二阶段。

执行流程

1. 收集参数与发票文件：收集必要参数，帮助用户将发票文件收集到同一文件夹；确认或推断输出目录。

2. 历史清单预处理（条件执行）：若用户提供了非标准格式的历史清单，必须先转换成脚本可直接读取的标准 CSV；本命令不做自动字段映射转换。若转换失败、字段映射不明确或数据验证不通过，则必须中止。

3. 第一阶段：verify：执行 {EXECUTABLE} verify -i <folder-or-xlsx-or-csv> [-o <xlsx-or-dir>] --api-key <api_key>。

4. 第一阶段产物校验（必须执行）：确认本次刚生成并在 JSON intermediate_excel_path 返回的中间 XLSX 已存在、文件非空、可正常读取，且能作为第二阶段输入。

5. 第二阶段：manage（必须执行）：执行 {EXECUTABLE} manage -i <xlsx> [-o <xlsx-or-dir>] [--check-duplicate] [--history <csv>] [--check-reimburse] [--check-account] [-c <company>]；重复风险提醒默认开启，--check-duplicate 仅为兼容旧命令保留，不需要额外传入。

6. 展示结果：根据 JSON 结果按下方“输出模板”输出统计信息，最终交付文件以第二阶段处理后的 XLSX 为准。

输出模板

企业名称：XXXXXX有限公司

【处理统计】
- 待处理文件总数：XX个
- 有效发票文件：XX个
- 查验成功：XX张
- 查验失败：XX张
- 重复风险发票：XX张
- 新增清单记录：XX张

【输出文件】
- 发票处理清单：{excel_file_path}（不输出发票明细）

【异常提示】
- XX个非发票文件已过滤
- XX个发票查验接口超时，建议稍后重试

字段映射说明（JSON -> 输出）

• 待处理文件总数 = total_file_count
• 有效发票文件 = valid_invoice_count
• 查验成功 = verify_success_count
• 查验失败 = verify_failed_count
• 重复风险发票 = duplicate_risk_count
• 新增清单记录 = new_list_count
• 异常提示 = 根据 error_alerts 分类展示（非查验成功的状态）；error_alerts 是“状态 -> 文件名列表”，展示时可汇总数量并列出或概括对应文件名。
• 企业名称 = company_name