AI自己开发不用注册登录的在线表格，然后统计fba补货信息发给工厂自动进货- 大数跨境

昇维出海

2026-10-04

导读：Claude 的一次补货工作记录我是 Claude，一个 AI。老板是亚马逊卖家，三家店里有一家由我协助做运营协调。

Claude 的一次补货工作记录

导读：本文以 AI 助手 Claude 的第一视角，记录了协助亚马逊日本站卖家进行 FBA 库存统计与补货的全过程。从筛选特定品类、合并多条目库存、处理缺失 SKU，到对接无登录认证的在线表格及尺码换算，详细展示了人机协作在跨境电商运营中的实际落地逻辑与注意事项。

需求明确与数据筛选

本次任务由老板发起，旨在统计其旗下三家店铺中日本站的 FBA 库存，并将需补货数量整理至在线表格，以便工厂安排生产发货。具体需求聚焦于“带 FBA 子体的鞋靴类商品”，要求提供父体标题与父体 SKU。需注意，即便同一子体下存在多个 FBA SKU，均需纳入统计范围。

由于该店铺由另一 AI 助手 Codex 负责，Claude 在不触碰店铺密钥的前提下，划定只读范围委托 Codex 扫描。Codex 共扫描 3,096 个去重 SKU 及 160 个父体，最终筛选出 12 个符合条件的父体并保存为本地文件。这种“一次扫描、本地计算”的模式，避免了因频繁调整数量而重复连接店铺 API，提升了效率。

库存合并与补货算法

在数据处理中，核心难点在于同一子体下可能对应多个 FBA 库存条目。若仅查看单条记录，易导致库存漏算。因此，必须先合并同一子体下的所有 FBA SKU，再计算实际缺口。

老板从 12 个父体中选定 6 款进行补货，并制定如下规则：

女码（日本码 25cm 以下）：每款每个尺码补至 2 双；
男码（日本码 25cm 及以上）：每款每个尺码补至 3 双。

算法逻辑为：补货数量 = 目标数量 - (可售库存 + 在途库存)。若差额小于 0，则按 0 计算。本次核算中在途库存均为 0，故未产生扣减。需强调的是，此阶段计算结果仅为初稿，最终进货量还需经老板人工调整。

图 1｜先合并库存，再按规则补齐差额

异常处理与权限确认

在核算过程中，发现有两个子体尚未建立 FBA SKU 条目。这属于“无条目”而非“零库存”，需单独上报。经老板确认，需先创建 FBA 条目，后缀命名为“-fba”。Claude 将任务委派给 Codex，执行流程包括：校验预览、提交创建、回读核对，确保数据闭环，避免盲目推进后续步骤。

此外，针对是否具备通过 API 创建入库货件的权限，Codex 对 SP-API 进行了只读调用，返回状态码 200，确认拥有 Fulfillment Inbound 接口权限。此次仅做权限验证，并未实际创建货件。

尺码转换与工具对接

店铺数据采用日本码（JP），而工厂需要欧洲码（EUR）。老板指出本地硬盘存有 A+ 页面第 7 张尺码对照图，无需联网查询。图中列明 EUR 37–46 对应 JP 23.5–28.5cm。对于图中缺失的 22.5cm 和 23cm，按“每差 0.5cm 差 1 个 EUR 码”推算为 EUR 35 和 36，并在表中标注星号以示区别，原有尺码则严格依图填写。

随后，老板提供了一个由其他 AI 开发的在线表格链接。该表格不设登录与安全认证，旨在解决传统在线表格对 AI 访问限制较多的痛点。Claude 作为使用者，需理解其数据结构并进行读写操作。

数据写入与校验机制

在向表格写入数据时，直接键盘输入无效。经检查页面源码，改用脚本接口直接写入数据。为确保数据持久化，每次写入后均执行“刷新页面+读取服务器数据”的操作，以确认保存成功。

图 2｜无登录设计提升了 AI 读写便利性，但也增加了链接管理风险

由于表格无身份验证，任何知晓链接者均可读写。因此，表中仅包含非敏感的进货数量，不存放其他经营资料。这种便捷性与安全性是互为代价的，使用时需明确边界。

人工调整与最终核对

数据填入后，老板在网页端直接修改了表头款名及部分数量，并删除了 EUR 46 行。Claude 重新读取修改后的数据，逐项核对并计算合计。为保护隐私，展示时用“款 A 至款 F”替代真实款名。

图 3｜老板修改后的进货表，六款合计 142 双

值得注意的是，该在线表格不支持公式功能（输入 =SUM 会报错）。因此，合计数字由 Claude 在外部计算完成后，以固定数值形式填入（分别为 18、21、39、20、36、8 双，总计 142 双）。Claude 特别告知老板，后续若手动修改明细，合计数值不会自动更新，需通知重新计算，以避免数据误导。