Amazon 补货审批工作流

一张审批表背后，其实有六段工作

补货看上去像填表，实际要先从运营系统取得建议数据，再整理库存来源、确认本批范围、填写两套模板，最后逐项核对。任何一个环节靠临时记忆完成，都会让后面的结果变得难以解释。

因此，这个项目没有从“自动填 Excel”开始，而是先画出数据从哪里来、谁做决定、什么条件会阻断，以及哪两份结果必须一起交付。

拆分阶段时，我要求每一步只回答一个问题：Export 负责取得可信快照，Normalize 负责建立统一数据形状，Preview 负责把判断材料呈现给人，Confirm 负责冻结业务范围，Generate 负责把确认结果投射到模板，Validate 负责从最终文件反向证明交付完整。这样出现异常时，可以定位是取数、解释、决策、写入还是校验出了问题。

1. 01

   Export

   复用本地授权状态进入约定页面，确认站点与筛选条件后取得时间戳明确的数据快照；登录失效、权限变化或导出超时时停止，不沿用旧文件冒充本次结果。

2. 02

   Normalize

   在不改动源文件的前提下寻找最新有效工作簿，统一字段别名、日期、数量和不可见字符，并保留原始行号以便错误能够回指来源。

3. 03

   Preview

   只展示目标站点的候选 SPU、库存与异常摘要，把系统知道什么和不知道什么呈现出来；此时不写正式模板，也不产生可流转文件。

4. 04

   Confirm

   由运营明确勾选本批范围并生成确认快照。程序不会根据名称相似度扩大范围，确认后的集合成为后续两个输出共享的唯一输入。

5. 05

   Generate

   根据两份独立 YAML 映射写入临时工作簿，复制必要格式与公式但不覆盖已有正式文件；模板结构变化被限制在映射层处理。

6. 06

   Validate

   重新打开最终工作簿，核对工作表、行数、SKU 集合、必填字段、数量和两表一致性；通过后才把临时文件共同提升为正式交付物。

最重要的设计，不是自动，而是中途停一下

候选范围生成后，流程故意暂停。补哪些商品仍然是运营判断，自动化只能把库存、建议量和异常整理清楚，不能替人决定本次业务范围。

这个暂停点让程序承担重复劳动，也让责任边界保持清晰：输入由工具整理，范围由人确认，输出再由工具执行和验证。

暂停发生在正式文件写入之前，而不是生成后再让人删除错误行。前者让人的决定成为明确输入，后者则会让审批表和发货表在人工修改过程中产生不同版本。确认快照还会记录本批范围与时间，使后续结果能够说明自己基于哪次决定生成。

• 没有匹配到目标站点时直接停止，不回退到其他市场。
• SKU 缺失或重复时阻断，不用模糊匹配猜测。
• 数量只接受正整数，异常文本不会静默转成 0。
• 候选预览不产生可提交文件，确认后才进入写入阶段。
• 确认前可以重新导出或调整筛选；确认后若范围改变，必须开启新批次而不是在结果文件里手改。

失败本身也要是一份结果

网页变化、字段缺失、文件损坏或其中一份模板写入失败，都不应该只留下一个模糊报错。流程会标明失败阶段、缺失项和本次输出状态，并清理尚未通过校验的半成品。

运行报告聚焦失败阶段、输入范围和输出状态，让后续排查可以从明确的节点开始。对业务工具而言，可恢复和可解释与成功运行同样重要。

错误信息按照“发生在哪一阶段、涉及哪些输入、是否产生临时文件、能否安全重试”组织。这样操作者不需要阅读代码堆栈，也能判断应该重新登录、修复源数据、更新映射，还是重新确认业务范围。

先定义数据契约，再写任何自动化代码

上游导出、库存文件和目标模板来自不同系统，它们对同一概念可能使用不同列名、格式和空值表达。如果直接在脚本中边读边猜，代码会把偶然出现的表格样式误当成业务规则。

因此每个阶段都先定义最小输入契约：哪些字段必须存在、什么值可以为空、SKU 如何唯一、站点如何识别、数量允许什么类型。字段别名可以通过映射兼容，但核心字段缺失必须中止。

标准化结果不会只保留清洗后的值，还保留来源文件、工作表、原始行号和原始文本。后续如果某个数量被拒绝，报告可以指出它来自哪一格，而不是只告诉使用者“转换失败”。这条追溯链也是人工复核能够信任自动化的基础。

两份 Excel 不是两个结果，而是一个事务

审批表和发货表会进入同一条业务链，所以不能允许一份成功、一份失败。流程先分别写入临时文件，随后统一回读并核对 SKU 范围、行数和数量；只有两份都通过，才把它们作为本次正式结果交付。

这种处理借用了事务思维：生成只是中间状态，校验通过才算提交。任何一边失败，另一边也不会被当作可用结果留下，从源头避免版本错配和单边流转。

文件名也在提交阶段统一确定，并避免覆盖已经进入人工审批的版本。重跑同一批次时，系统优先识别已有成功结果或明确创建新版本，而不是悄悄覆盖，从而保留业务流程需要的版本边界。

把会变化的模板，与不能变化的业务规则分开

这里最核心的方法不是“自动化更多”，而是识别变化频率：界面和模板会变，业务不变量相对稳定。将两者分层，才让这条流程可以持续维护，而不是一次性脚本。

每次变化都先判断属于哪一层：如果只是模板换列，应修改映射并重新运行写入测试；如果业务含义改变，例如数量允许规则变化，则需要修改校验器并重新确认影响范围。通过这种分类，维护动作不会因为一个 Excel 改版而扩散到整条链路。

• 列名、工作表名称和写入位置放入 YAML 映射，模板更新时只调整配置。
• SKU 唯一性、站点隔离、数量类型和双表一致性保留在校验逻辑中。
• 网页选择器与导出步骤独立封装，上游界面变化不会直接污染 Excel 规则。
• 每个阶段留下输入摘要与结果状态，便于判断问题来自网页、数据、映射还是校验。

如何判断这条工作流真的可靠，而不只是能跑通一次

验证被分成阶段级和交付级两层。阶段级验证证明每个转换没有丢失关键字段，交付级验证证明两份最终文件共同满足业务约束。测试样本既包含正常批次，也包含站点混入、重复 SKU、缺失数量、模板缺列和单边写入失败。

我关注的不是只得到绿色成功，而是每个失败样本是否在正确阶段停止、是否没有留下误导性的正式文件、报告是否足以指导下一步。可靠性来自可预测的失败行为，而不是假设所有输入都干净。

Lab 如何呈现这条工作流

Lab 里预设三份示例工作簿，用较慢的动画依次展示最新文件定位、字段统一、人工确认与成对校验，最后提供一份可下载的 Excel 结果。

演示保留了这条工作流最关键的停顿、判断与回读检查，让整套处理方式可以被完整理解。

公开演示不会连接真实运营系统，也不会处理访客文件。它用合成数据重现相同的阶段边界、阻断条件和双表一致性检查，展示的是方法与控制点，而不是伪装成真实生产执行。