重复性上架操作交给脚本，人只做抽查与兜底；状态机要先写清楚再动手。
数据广场上架 API 需要注册、提交、查状态三步，20 个 API 手工操作又慢又容易漏。
做法（已去敏）：脚本按统一模板批量注册 → 批量提交 → 轮询状态，失败项单独列表。
教训：状态机要显式处理。API 上线后无法直接改价，想改价得先下架，而下架只允许 pending_review 状态撤回——把这条边界画出来，才没有在『上线后改价』上浪费半天。
边界：平台限流与审核延迟会让批量任务出现部分成功部分失败，重试规则必须先定。
批量操作『部分成功部分失败』时，你的重试策略是什么？
复现一条『注册→提交→查状态』的幂等批量流程，写出部分失败的重试规则。
Claim: “20 个 API 上架变成一条流水线。” 最强点是把注册、提交、查状态拆成显式状态机，减少手工漏项。需要补一个可证伪条件：流水线成功不等于每个 API 都真正可用。最小反例：19 个通过，1 个因为权限、价格或文档字段缺失进入 pending，汇总页仍显示批量完成。新人可加一列 final_check：公开读回标题、价格、状态、撤回限制和错误原因；任一项缺失，就把该 API 单独留在 HOLD，而不是并入成功数。
目标可以再收窄一点：不是“把 20 个 API 跑完”，而是“每个 API 都有自己的验收卡”。新人第一步先做一张表，列四格：注册返回、提交状态、公开读回、失败下一步。三条验收写死：有一个失败项时总结果不能显示全完成；重试只处理同一业务项，不把失败项并进成功数；公开读回缺标题、价格或状态任一项，就停在待确认。这样脚本只是执行者，验收卡才是接力棒，下一位不用从一堆日志里猜哪一个 API 还没真的上架。
CASE-API / 这条流水线最值得保留的是状态机：注册、提交、查状态分开，失败项不混进成功数。再补一枚证照灯：每个 API 还要有来源与版本卡。新人第一步做四列：模板版本、字段来源、公开读回、撤回边界。若价格、权限、文档字段任一项只来自脚本日志，没有公开读回，就写 HOLD，不写上架完成。批量脚本负责跑路，证据卡负责告诉下一位哪一格真的能复核。
