arcdodo Rename Order Invoice Pairs
整理订单截图和对应发票，让同一笔交易或同一组合发票的文件使用相同基础命名，只保留扩展名和类型序号差异。
示例：
runninghub_2026-05-18_199.00_order.png
runninghub_2026-05-18_199.00_invoice.pdf
平台标准名
| 原始名称可能出现 | 标准名 |
|---|---|
| 海马云, RunningHub, runninghub, running hub | runninghub |
| MiniMax, minimax, 海螺, Hailuo, hailuo | hailuo |
| 快手, 可灵, Kling, kling, kwai | kling |
工作流
Phase 1: 盘点文件
用户给文件夹路径或一批文件后：
- 列出所有图片、PDF、发票和订单相关文件。
- 分成两类：订单截图/付款截图、发票。
- 识别平台、日期、金额、订单号、发票号、文件类型。
- 如果文件名信息不足，查看图片/PDF 内容；仍不足时，生成需要人工确认的候选表。
优先使用文件名和可读文本。不要仅凭文件顺序直接重命名。
Phase 2: 配对
按可靠性从高到低配对：
- 同一订单号、发票备注或交易号。
- 同一平台 + 同一金额 + 同一日期或相近日期。
- 同一平台 + 唯一金额，可写入候选计划，但日期缺失时必须人工确认。
- 一张发票金额等于多张订单截图金额之和时，只能列为组合候选，人工确认后执行。
- 人工确认。
自动执行最低门槛：订单号/交易号一致，或同一平台 + 同一金额且候选唯一。仅平台相同、仅日期相同、缺少真实交易日期、组合发票或同一发票被多笔订单使用时，必须列入待确认清单。
如果同一张订单截图可能对应多张发票，不要自动执行，必须列为冲突。一张发票可以对应多张订单截图，但必须先人工确认组合关系。
Phase 3: 生成统一命名
默认命名格式：
<platform>_<YYYY-MM-DD>_<amount>_<kind>.<ext>
其中：
<platform>使用标准名：runninghub、hailuo、kling<amount>保留两位小数，例如99.00<kind>订单截图用order，发票用invoice- 一张发票对应多张订单截图时，截图命名为
_order_1、_order_2，发票仍为_invoice
如果用户要求“完全相同命名”，则使用：
<platform>_<YYYY-MM-DD>_<amount>.<ext>
但当订单截图和发票扩展名相同，会导致重名冲突；此时必须保留 _order / _invoice。
Phase 4: 先计划后执行
必须先生成改名计划，包含：
- 原文件名
- 新文件名
- 识别出的平台/日期/金额
- 配对依据
- 是否有冲突
只有在计划无冲突，或用户明确确认后，才执行重命名。
可使用脚本：
python scripts/rename_order_invoice_pairs.py <folder> --dry-run
python scripts/rename_order_invoice_pairs.py <folder> --apply --confirmed
--confirmed 只表示改名计划已经过用户确认或严格人工复核；不要在未展示并检查计划时自动添加。
脚本详情见 references/RENAMING-RULES.md。
质量门槛
执行前检查：
- 每个订单截图最多对应一张发票。
- 一张发票可以对应多张订单截图。
- 平台名必须标准化。
- 日期和金额不能凭空编造。
- 文件创建时间或修改时间不能作为交易日期。
- 自动配对必须达到最低门槛，弱匹配只能进入待确认清单。
- 组合发票必须确认多笔订单金额之和与发票金额一致。
- 有冲突时不能自动执行。
- 执行前必须保留改名计划。
执行后汇报：
- 成功改名数量。
- 跳过数量和原因。
- 冲突文件清单。
- 改名计划保存位置。
处理不确定情况
如果无法确定配对，不要猜。输出“待确认清单”，让用户确认哪张订单截图对应哪张发票。