管理库存与销售机会

在本页中，你可以确认 FBA 库存状况、整理出补货与清理的判断材料，也可以结合库存状况考虑广告的强弱调整。从识别断货风险、检测过剩库存，到创建补货下单简报，当你想高效处理与广告运维紧密相连的库存业务时使用。

本页基本信息

项目	内容
本页能做什么	FBA 库存一览与库存周数确认、断货风险诊断与补货下单简报的创建、过剩库存与滞销库存的检测、结合库存状况考虑广告调整、把握订购省缺货造成的机会损失
适用对象	FBA 库存（可售库存 / 入库处理中库存 / 周出货速度 / 库存周数），以及订购省（Subscribe & Save, SnS）的实绩数据
所需数据 / 连接	已连接账户的库存数据与订购省实绩数据（无需额外设置）
执行范围	多数为仅分析、建议（只读）。实际的下单、货件计划创建在 Seller Central 手动进行，Picaro 不会执行下单。仅结合库存的广告调整（提示词 4）会把建议交给相关页面（出价 / 预算）的审批流程去执行。各提示词会在「设置变更」中单独说明

needMoreStocks 不作为推荐补货数量・缺口数量使用。 它返回的值与当前库存数（sellableInventory）相同，无法作为补货量的依据。推荐补货数量请使用 reorderQuantitySuggested 等工具返回的值。
库存周数・库存天数（weeksOfCover / daysOfSupply）的「0」不一定代表「断货」。 周出货为 0 时即使有库存也会返回 0，因此务必区分「库存 0 的断货」「周出货 0 导致无法算出（滞销・休眠等）」「数据未取得」。
在结合库存状况的广告调整中，要把库存数据按 ASIN 单位合计之后再判定。 若保持 SKU 单位的行来判定，就会变成误将库存充裕的商品的广告收紧的建议（实测中已发生）。周出货为 0 的商品作为「无法判定」从收紧候选中剔除，不要把分母为 0 的情况当作「库存 0 天」。

什么时候用

想一目了然地把握 FBA 库存全貌（含库存周数）
想诊断断货风险，并整理出可直接用于下单检讨的补货下单简报
想找出过剩库存、滞销库存，作为去库存措施或精简在售商品的材料
想根据库存状况决定广告的强弱（收紧 / 维持 / 强化）
想把握订购省（SnS）因缺货造成的机会损失，反映到补货优先级中

执行前需确认

连接的账户 … 处理多个账户时，先确认目标账户是否正确。
交货周期、安全库存、下单周期 … 是断货风险诊断（提示词 2）的前提。请按自家采购、入仓的实际情况指定。
过剩库存的阈值 … 用于滞销库存判定（提示词 3）。默认为「超 180 天 = 过剩库存候选」「超 270 天 = 长期仓储费警告」，可按商品的周转特性调整。
下单不由 Picaro 执行 … 补货、下单的执行在 Seller Central 创建货件计划手动进行。

提示词速查表

想做什么	能得到什么 / 会生成什么	设置变更	提示词
确认 FBA 库存全貌（含库存周数）	附库存周数的库存一览	无变更	提示词 1
诊断断货风险并创建补货下单简报	紧急补货 / 下单候选 / 观察 / 无法判定的分档表，以及附过剩库存一览的下单简报	无变更（仅草稿）	提示词 2
找出过剩库存、滞销库存	过剩库存 / 长期仓储警告的一览	无变更	提示词 3
结合库存状况决定广告强弱	收紧 / 维持 / 强化的推荐一览	无变更（仅建议。执行经由出价・预算分类）	提示词 4
把握订购省因缺货造成的机会损失	断货未配送与恶化商品的一览	无变更	提示词 5

提示词 1: 确认 FBA 库存全貌（含库存周数）

以列表形式确认 FBA 库存。不仅是可售库存，还并列入库处理中库存、周出货速度、库存周数（按当前速度还能撑几周），把握全貌。

什么时候用 — 想一目了然地把握库存全貌（含库存周数）时。

执行前需要的信息 — 无（可直接使用）。想更改库存周数的阈值（默认 2 周）时请指定。

目的：为尽早发现断货风险，可视化 {{账户名（例：Torani）}} 的 FBA 库存全貌。

【获取】指定 account_id 调用 get_fba_inventory，取满 pagination.totalPages 的所有页。把返回行数与 pagination.totalRecords 相互核对，不一致时请写明（page_size 即使指定也可能被固定为 100）。务必在开头记载响应的 coveragePeriod 与 dataCreateDate（它是库存周数的分母——周出货的汇总期间，因此不要不写期间只给出库存周数）。

【按 ASIN 单位归并】同一 ASIN 可能返回多行（虽是 SKU 单位的行，但响应中没有 SKU 列，因此无法把行与 SKU 对应起来）。务必先归并到 ASIN 单位再判定。
- 可售库存・入库处理中库存在 ASIN 内合计
- 周出货（weeklyShipmentUnits）是同一 ASIN 各行填入相同值的 ASIN 单位值，因此不要合计，取 1 个代表值
- 归并后的库存周数 =（ASIN 合计的可售库存）÷（周出货）重新计算，MCP 按行返回的 weeksOfCover 作为参考值并列写出
※ 不归并而按行判定时，会只看库存为 0 的 SKU 行就误判为「断货」（实际上 ASIN 合计可能有充足库存）。

【库存周数 0 的处理 — 必须】weeksOfCover=0 中混有含义不同的情况。不可一律把 0 当作「临近断货」。务必分成下列 3 档输出。
A. 需要处理（断货风险）… 周出货 > 0 且 归并后库存周数 < {{阈值（例：2 周）}}。若 ASIN 合计库存为 0，请写明「完全断货」
B. 无法算出（分母为 0）… 周出货 = 0。库存周数写「无法算出」，不要写 0。并进一步分为
   B-1 有库存・出货 0 → 滞销（属于过剩库存一侧的议题。转到提示词 3〈识别过剩库存与滞销库存〉）
   B-2 库存 0・出货 0 → 休眠 / 停产 / 未上架的候选
C. 健全 … 归并后库存周数 >= {{阈值（例：2 周）}}
务必区分「库存 0（断货）」「销售实绩 0」「库存数据未取得」，不要混淆。

【输出】以 A 档在最前，按归并后库存周数从小到大，用表格并列 ASIN・商品名・可售库存・入库处理中库存・周出货速度・归并后库存周数・档位。B 档・C 档给出件数与代表示例。
注意：可售库存（sellableInventory）是包含入库处理中库存的合计值，因此请写明库存周数是已计入在途入库的值。
注意：get_fba_inventory 的响应中没有 SKU 列。仅在需要 SKU 时用 lookup_sku_for_asin 补全，无法补全的 ASIN 注明「SKU 未登记」；由于行与 SKU 无法对应，注明「SKU 不显示（API 规格）」。
注意：不要把 needMoreStocks 当作推荐补货数量使用（它返回与库存数相同的值，无法作为补货量的依据）。

最后请输出以下 3 点。
1. 推荐行动 — 写明 A 档的优先级・理由・预想风险（断货・机会损失）。优先级以库存周数从少到多为基本，但周出货速度小的 ASIN 即使断货影响也小，因此要用库存周数与出货速度两者加权
2. 执行方法 — A 档的 ASIN 交给提示词 2（FBA 库存风险诊断）确认补货数量。B-1 档转到提示词 3（识别过剩库存与滞销库存）
3. 测定 — 在 {{评估日（例：7 天后）}} 重新获取库存周数，确认 A 档件数的增减

A 档为 0 件时也要写明「无对应项」；在断定实绩为 0 之前，请确认 B 档的件数与数据取得状况（totalRecords・coveragePeriod）。

可修改的条件 — 库存周数的阈值（例：2 周）／再确认的评估日（例：7 天后）。

返回内容 — 按需要处理 → 无法算出 → 健全的顺序排列的 ASIN × 商品名 × 可售库存 × 入库处理中库存 × 周出货速度 × 归并后库存周数的表。库存周数是「可售库存 ÷ 周出货速度」的推算值，是已计入在途入库的值。周出货为 0 的 ASIN 会作为「无法算出」区分开，不会把库存周数显示为 0。SKU 默认不显示，仅在需要时单独补全。

设置变更 — 无变更（只读）。

接下来做什么 — 需要处理档的 ASIN，用提示词 2 诊断断货风险。有库存但出货已停止（B-1 档）的，用提示词 3 作为过剩库存・滞销库存来确认。

提示词 2: FBA 库存风险诊断（断货风险、推荐补货数量）

一次性诊断各 ASIN 的断货风险、推荐补货数量与过剩库存，并生成可直接用于下单判断的补货下单简报。用于同时防止断货造成的销售机会损失与过量下单造成的成本。

什么时候用 — 想诊断断货风险，并整理出可直接用于下单检讨的补货下单简报时。

执行前需要的信息 — 交货周期（从下单到可售的天数，示例为 14 天）、安全库存天数（应对需求波动、入库延迟的缓冲，示例为 7 天）、下单周期天数（示例为 14 天）。若一并给出过剩库存阈值与最小下单批量（例：100 个），判定与是否可下单的精度会更高。

目的：为同时防止断货造成的销售机会损失与过量下单成本，请从 {{账户名（例：Torani）}} 的 FBA 库存出发，一次性诊断各 ASIN 的断货风险、推荐补货数量与过剩库存，并生成可直接用于下单判断的补货下单简报。

【本次诊断的定位】
- Business Objective … 同时防止断货造成的销售机会损失与过量下单成本，进行合理的补货下单。
- User Decision … 决定本次下单周期中「对哪些 ASIN、下单多少个」（不下单、暂缓的 ASIN 也要附理由明示）。
- Expected Outcome … 下单对象 ASIN 与推荐补货数量的清单、暂缓下单的 ASIN 及其理由、过剩库存侧需注意的 ASIN，一次性齐备、无需追加提问的状态。
- Guardrail KPI … 过剩库存成本／下单批量效率。仓储费与长期仓储费的金额无法从 Picaro MCP 取得，因此改用库存天数、超阈值天数、ltsfRisk（warning/watch）做替代监控，不做金额换算。

【获取】按下列 2 个工具，指定 account_id 调用。
1. detect_restock_needs（lead_time_days={{交货周期天数（例：14）}}／safety_stock_days={{安全库存天数（例：7）}}／reorder_cycle_days={{下单周期天数（例：14）}}／max_pages=10／include_low_confidence=true）
2. detect_overstock（同一 account_id／max_pages=10。阈值保持默认，或指定 {{过剩库存阈值天数（例：180）}}）
请不要使用 generate_restock_brief。它在 critical / reorder / monitor 上返回与 detect_restock_needs 相同的数据、在 overstock 上返回与 detect_overstock 相同的数据，但不返回总件数字段（相当于 totalSkusEvaluated）与 idle 的明细数组（idleItems），会使下述件数验算与休眠 SKU 的分离无法进行。
include_low_confidence=true 是必需的。设为 false 时 idle 会从 summary 中一并消失，各分档件数之和与 totalSkusEvaluated 不再一致，也不会给出被排除的件数。
请确认响应中的 thresholds 与指定值一致，并把两个工具的 totalSkusEvaluated 与 get_fba_inventory 的 pagination.totalRecords 对照，在开头写明是否已对全部数据完成评估。salesDateRange（周出货的统计期间）与 inventoryCreatedAt（库存快照日期）也请写在开头。

【按 ASIN 汇总 —— 必需】detect_restock_needs 返回的是 SKU 单位的行，但响应中没有 SKU 列，同一 ASIN 会同时出现在多行、多个分档中（库存为 0 的行进入 critical，有库存的行进入 monitor）。判定前请务必先按 ASIN 汇总。
- sellableInventory、inboundWorkingQuantity 在 ASIN 内合计
- weeklyShipmentUnits、reorderPointUnits、targetStockUnits 是 ASIN 单位的值，同一 ASIN 的各行填入相同数值，因此不要合计，取 1 个代表值
- 汇总后的推荐补货数量 = max(0, targetStockUnits −（ASIN 合计 sellableInventory ＋ ASIN 合计 inboundWorkingQuantity））重新计算
- 汇总后的距断货天数 =（ASIN 合计 sellableInventory ÷ weeklyShipmentUnits）× 7 重新计算，行单位的 daysUntilStockout 作为参考值并列
- 汇总后不再属于紧急补货、下单候选的 ASIN，作为「同一 ASIN 的其他行有库存、无需下单」排除，并务必写明排除的件数与数量
※不汇总而按行处理时，会只看库存为 0 的 SKU 行就误判为「紧急补货」，对实际库存充足的 ASIN 过量下单（验证时的实测中，紧急补货 5 件里有 2 件是误检，相当于约 14,000 个的过量下单）。

【区分 0 与 null —— 必需】weeksOfCover / daysOfSupply 在周出货为 0 时即使有库存也返回 0，因此请务必把「0」拆解为下列 3 种。
- 分档 A 库存为 0 的断货 … sellableInventory = 0。实际的断货。属于紧急补货对象
- 分档 B 周出货为 0、无法计算 … weeklyShipmentUnits = 0（daysUntilStockout 返回 null）。即使有库存也只是返回 0，并不是断货。作为滞销、休眠、停售放入 Idle，不要写成「距断货 0 天」
- 分档 C 健全 … 库存与出货均存在，库存天数可以计算
请不要单独用 weeksOfCover / daysOfSupply 作为断货的依据。
请不要使用 needMoreStocks（在验证过的全部 SKU 上它与 sellableInventory 同值，并非推荐补货数量）。推荐补货数量请使用 reorderQuantitySuggested（按 ASIN 汇总时使用上述公式重新计算的值）。
请务必区分「库存 0（完全断货）」「销售实绩 0（无法计算）」「数据未取得」。

【分档】以 detect_restock_needs 的 classification 作为一次分档，按 ASIN 汇总后不再满足 Critical 条件的 ASIN 降级到 Monitor。不要只用天数重新分类（Reorder 包含「库存天数尚有剩余，但可售库存＋入库处理中库存低于目标库存」的情况，用天数阈值切分会漏掉下单候选）。
- 🔴 紧急补货（critical）… 可售库存低于下单点且没有入库处理中库存／库存天数不超过交货周期
- 🟡 下单候选（reorder）… 可售库存＋入库处理中库存低于目标库存
- 🟢 观察（monitor）… 已满足目标库存
- ⚪ 无法判定、休眠（idle）… 近期没有出货、无法判定（confidence=low、上述分档 B）
过剩库存（detect_overstock）与补货分类是正交的另一个轴。不要与上述 4 个分档合计，请用单独的表格呈现，并注明各分档件数的简单相加含有重复。

【SKU 的确定】对 🔴 与 🟡 的各 ASIN，用 lookup_sku_for_asin 查出 SKU 并在 SKU 列并列。
当 1 个 ASIN 返回**多个不同的** SKU 时，各 SKU 的 sellableInventory 填入的是 ASIN 合计、无法按 SKU 分离，因此请写明「SKU 无法确定、需在库存管理界面确认」，不要确定该 SKU 的下单数量。若只是同一 SKU 名因 parentAsin 不同而重复返回（去重后只剩 1 条）则不属于「无法确定」。请先去重再判定。

【输出】先按分档用表格呈现补货侧，再用单独的表格呈现过剩库存。
- 补货侧的列 … 商品名、ASIN、SKU（仅在能确定时）、汇总后的距断货天数、可售库存、入库处理中库存、周出货数、推荐补货数量、confidence、判定理由
- 过剩库存侧的列 … 商品名、ASIN、库存天数、超阈值天数、可售库存、ltsfRisk（warning/watch）
因按 ASIN 汇总而分档发生变化的，请注明「汇总前 Critical → 汇总后 Monitor（SKU 行拆分导致的误检）」。

【下单简报】在上述表格之后，按下列 5 段总结。
1. What happened — 紧急补货、下单候选、过剩库存的各自件数与规模。同时给出按 ASIN 汇总后的值与汇总前的原始件数
2. Why — 断货／过剩的成因。但销售数据只有最近 1 周的快照、没有时间序列，因此无法判定出货速度变化与季节性。请写明无法判定，不要凭推测下结论
3. So what — 放任不管时的断货风险与过剩库存风险。不做金额换算，只给出库存天数、超阈值天数、ltsfRisk
4. What was done — 上次简报之后已执行的下单。由于不存在返回下单履历的 MCP 工具，若使用者未提供，请写明「等待使用者输入」（不要断定为「没有」）
5. What should we do next — 本次应下单的 ASIN 及其优先级

【数据质量】请务必遵守下列各项，并把验算结果作为必须输出项。
- 验算各分档件数之和（critical＋reorder＋monitor＋idle）是否与 totalSkusEvaluated 一致，不一致时写明差异件数与原因（周出货低于 min_weekly_units 的 SKU 默认被排除／include_low_confidence 的指定等）
- 当 totalSkusEvaluated 与 get_fba_inventory 的 totalRecords 不一致，或被 max_pages 截断时，请写明总件数、已确认件数、未确认件数（若出现 [N of M rows omitted]，请在开头写明「⚠️全 X 件中仅取得 Y 件」）
- 未取得的 SKU 不要放入表中，另行注明「剩余 N 件未取得」，不要做出「同样紧急」之类的推测性断定（未取得就写「未取得、情况不明」）
- 禁止从合计值（totals over N rows）反推、捏造单个 ASIN、单个 SKU 的数值。只记载已取得的行

请在回答末尾写明所使用的前提条件（交货周期、安全库存、下单周期、过剩库存阈值，以及库存快照日期与销售实绩期间），并说明 Picaro 的数据与 FBA 库存管理界面的显示值不会完全一致、最终确认请在该界面进行。

最后请输出下列 3 点。
1. 推荐操作 — 在紧急补货、下单候选中，把推荐补货数量达到 {{最小下单批量（例：100 个。下单批量、MOQ、每箱入数在 Picaro MCP 的任何响应中都不存在，需由使用者指定）}} 以上的，作为「本次下单周期应下单的 ASIN」，按距断货天数升序、推荐补货数量降序呈现。未指定最小下单批量时，请写明「因未指定，不判定是否可下单」，不做向下单单位的取整（写明「下单单位需使用者确认」），只给出推荐补货数量的清单。无法唯一确定 SKU 的 ASIN 作为「需确认 SKU」另行列出，不确定其下单数量
2. 执行方法 — 把清单直接作为下单依据交出（Picaro 内没有下单执行入口，需手动下单）
3. 测量 — 在 {{评估日（例：7 天后）}} 用相同的前提条件重新取得 detect_restock_needs，确认判定为紧急补货的 ASIN 是否已脱离 critical（是否出现新的断货）。不要用 weeksOfCover / daysOfSupply 做恢复判定（周出货落到 0 时也会返回 0，会被误认为恢复）。若未恢复，请怀疑下单延迟并展开调查

可修改的条件 — 交货周期（例：14 天）／安全库存天数（例：7 天）／下单周期天数（例：14 天）／过剩库存阈值／最小下单批量。请按自家采购、入仓的实际情况调整。

返回内容 — 分档（🔴紧急补货 / 🟡下单候选 / 🟢观察 / ⚪无法判定、休眠）× ASIN × SKU（仅在能确定时）× 距断货天数 × 可售库存 × 入库处理中库存 × 周出货数 × 推荐补货数量的表、单独表格的过剩库存一览，以及 What happened / Why / So what / What was done / What should we do next 五段构成的补货下单简报。仅生成草稿，不会执行实际下单或向外部发送。

设置变更 — 仅分析、建议（仅生成草稿）。不会执行下单。

接下来做什么 — 下单的执行请在 Seller Central 创建货件计划完成。想进一步深挖过剩库存侧时，使用提示词 3（识别过剩库存与滞销库存）。

提示词 3: 识别过剩库存与滞销库存

检测推算库存天数超过阈值的 SKU 作为过剩库存候选。滞留时间长的库存会增加仓储费负担，可作为降价、广告强化、精简在售商品等判断的材料。

什么时候用 — 想找出滞留的库存，作为去库存措施或精简在售商品的材料时。

执行前需要的信息 — 无（可直接使用）。默认阈值为「超 180 天 = 过剩库存候选」「超 270 天 = 长期仓储费警告」。

目的：为防止产生长期仓储费与库存成本的浪费，请从 {{账户名（例：Torani）}} 的 FBA 库存中分别识别「过剩库存」与「滞销库存」。这两者是不同的概念（过剩库存＝数量过多／滞销库存＝没有动销）。

【获取】
1. 指定 account_id 调用 detect_overstock（overstock_threshold_days={{过剩库存阈值天数（例：180）}}／ltsf_warning_days={{长期仓储费警告天数（例：270）}}／max_pages=10）。
2. 用同一 account_id 指定 page_size=500 调用 get_fba_inventory，查看响应的 pagination.totalPages 取全部页。page_size 会被服务端压低（可能按 100 返回），指定值未必会被原样采用，因此件数的判定始终用 pagination.totalRecords 与 totalPages 来做。
确认响应的 thresholds 是否与指定值一致，并把 detect_overstock 的 totalSkusEvaluated 与 get_fba_inventory 的 pagination.totalRecords 相互核对，在开头写明是否做到了全量评估。

【观测期间的写明 — 必须】务必在开头写出 salesDateRange（周出货的汇总期间）与 inventoryCreatedAt。salesDateRange 目前只返回 7 天，且不存在指定期间的参数。请写明对有季节性的 SKU，从单周的出货实绩外推会失真。同时用 get_data_ingestion_status 确认 salesDateRange 各天的入库状况。但不要用按天的 rollup_status 做确定判定。只要有 1 个未投放的广告类型，即使其他所有报表都 completed，那一整天也会落为 no_data。请按报表单位展开 reports[]，用与库存・销售相关的报表是否 completed 来判定，若包含未确定日请写明。

【过剩库存的判定】使用 detect_overstock 的输出。
- 长期仓储费风险 … ltsfRisk="warning"（推算库存天数超过 {{长期仓储费警告天数}}）
- 持续观察 … ltsfRisk="watch"（{{过剩库存阈值天数}} 〜 {{长期仓储费警告天数}}）

【滞销库存的判定 — 必须・detect_overstock 无法取得】
detect_overstock 对周出货为 0 的 SKU 在 daysOfSupply 返回 0 而非 null，因此必定低于阈值，结构上一件零动销 SKU 都不会返回。即使指定 min_weekly_units=0 结果也不变。因此滞销库存请自己从 get_fba_inventory 的全部行中提取。
- 滞销库存 … weeklyShipmentUnits=0 且 warehouseQuantity>0（抱着库存没有动销）
- 相当于停售 … weeklyShipmentUnits=0 且 warehouseQuantity=0（不计入滞销库存）

【0 与 null 的区分 — 必须】
- daysOfSupply / weeksOfCover 的 0，在「库存 0 的断货」与「周出货 0 导致无法算出（＝滞销）」两种情况下都会返回。务必并读 warehouseQuantity 来拆解，明示属于哪一种。不要写「库存天数 0 天」。
- needMoreStocks 返回与 sellableInventory 相同的值，因此不要作为推荐补货数量・缺口数量使用。
- 务必区分书写「无对应项」「不在评估范围（无出货实绩，无法算出）」「数据未取得」。不在评估范围的 SKU 数 detect_overstock 不返回，请从 get_fba_inventory 数出并写明。

【ASIN 重复的处理 — 必须】get_fba_inventory 返回的是 SKU 单位的行，但响应中没有 SKU 列，同一 ASIN 会出现在多行。报告件数时请区分书写行数（SKU 数）与 ASIN 数。需要 SKU 名称时可尝试用 lookup_sku_for_asin 反查，但对 Picaro 的 SKU 主数据中没有登记的 ASIN 会报错。无法反查的 ASIN 作为「SKU 不明」处理，不要凭推测填写 SKU 名称。另外返回的 sellableInventory 在各 SKU 中填入的是 ASIN 合计值，跨 SKU 合计会重复计算。不要合计。

【指标的局限 — 必须】推算库存天数（daysOfSupply）是用当前的销售速度消化当前库存所需的前瞻性天数，并不是长期仓储费计费依据的库存存放日龄。MCP 中不存在返回库存日龄・aged 库存分档・长期仓储费实际金额的字段。请在回答末尾写明本结果是代理指标，实际金额请在 Seller Central 的库存健康度仪表盘确认。

【输出】请把过剩库存（长期仓储费风险／持续观察）与滞销库存分成不同的表格，写明商品名・ASIN・推算库存天数・周出货数・可售库存・入库处理中库存・判定理由。

最后请输出以下 3 点。
1. 推荐行动 — 超过 {{长期仓储费警告天数}} 的 SKU 作为「通过促销・降价或强化广告去库存」，{{过剩库存阈值天数}}〜{{长期仓储费警告天数}} 作为「持续观察」，滞销库存作为「检讨退运・弃置或降价处理」，按持有数量从多到少给出带优先级的排序
2. 执行方法 — 需要强化广告的 SKU，先用「原因诊断」确认 ROAS，再生成出价调整的建议，由用户确认・批准后再反映。降价・退运・弃置在 Picaro 内没有执行入口，请写明为手动实施
3. 测定 — 在 {{评估日（例：30 天后）}} 用相同参数重新检测，确认 ltsfRisk="warning" 的 SKU 数、以及周出货 0 且有库存的 ASIN 数是否减少。同时用 detect_restock_needs 的 classificationSummary.critical 件数确认去库存措施有没有造成断货（断货率本身无法从 Picaro MCP 获取，请在 Seller Central 确认。请写明 critical 件数是断货率的代理指标）

可修改的条件 — 过剩库存、长期仓储警告的阈值（例：180 天 / 270 天）／再检测的评估日（例：30 天后）。可按商品的周转特性调整。

返回内容 — 过剩库存（长期仓储费风险 / 持续观察）的表，与滞销库存（出货已停止但库存仍留存的商品）的表，分别附上商品名・ASIN・推算库存天数・周出货数・可售库存・入库处理中库存・判定理由。过剩库存（数量过多）与滞销库存（没有动销）会作为不同概念来处理。

设置变更 — 仅分析、建议（只读）。

接下来做什么 — 要检讨通过广告去库存（广告强化、降价）时，配合调整竞价使用。

提示词 4: 结合库存状况考虑广告调整

对有断货风险的 ASIN 持续投入广告费，会在断货的同时导致广告效率恶化；反之库存充裕的 ASIN 则有强化广告的空间。把库存与广告业绩对照起来，提出调整候选。

什么时候用 — 想根据库存状况决定广告的强弱（收紧 / 维持 / 强化）时。

执行前需要的信息 — 无（可直接使用）。想更改库存风险判定的交货周期・安全库存天数，或强化检讨的 ROAS 下限时请指定。

目的：为防止断货期间浪费广告费，同时最大化库存充裕商品的销售机会，
请识别 {{账户名（例：Torani）}} 的断货风险 ASIN，并把该 ASIN 的广告实绩并列出来。

【库存侧的获取 — 必须归并到 ASIN 单位】
1. 用 detect_restock_needs（lead_time_days={{交货周期天数（例：14）}}／
   safety_stock_days={{安全库存天数（例：7）}}／max_pages=10／include_low_confidence=true）获取库存风险。
   在开头写明总件数（totalSkusEvaluated）・各档件数・库存快照日・周出货的汇总期间。
2. 本工具返回 SKU 单位的行，同一 ASIN 会同时出现在多行・多个档位（库存为 0 的行进入紧急补货，
   有库存的行进入观察）。判定前务必归并到 ASIN 单位。
   - sellableInventory ・ inboundWorkingQuantity 在 ASIN 内合计
   - 归并后不再满足紧急补货条件的 ASIN 降级为观察，并写明剔除的件数
   - 不归并而按行处理时，会只看库存为 0 的 SKU 行就误判为「紧急补货」，
     变成把实际上库存充足的主力商品的广告收紧的反向建议。这在实测中已经发生
3. weeklyShipmentUnits = 0 的行作为「无法判定（滞销・休眠・停售）」从收紧候选中剔除，另行列出。
   weeksOfCover / daysOfSupply 在周出货为 0 时即使有库存也返回 0，
   请不要单独用它作为断货的依据。务必区分「库存 0 的断货」「周出货 0 导致无法算出」
   「数据未取得」。
4. 请不要使用 needMoreStocks（它与 sellableInventory 同值，并非推荐补货数量）。

【广告侧的获取 — 按 ASIN 轴获取】
5. 请按对象 ASIN，逐个以 ASIN 轴获取归属于该 ASIN 的广告实绩。
   用 call_picaro_api 调用 POST /product-analysis/product-detail/ad
   （body: amazon_account_id, from_date, to_date, code=对象ASIN, type="asin"），
   会返回该 ASIN 的广告费・广告销售额・ROAS・ACoS・CVR・CPC，含按广告活动的明细与合计。
   - 把 total 区块的 ads_spend / ads_sales / roas / acos 作为 ASIN 单位的值使用
   - 用 items[] 的 campaign_id / campaign_name / campaign_type 确定投放该 ASIN 的广告活动
   - 区分呈现 ads_sales_same_sku（同一 SKU 产生的销售额）与 ads_sales（含光环效应）
   - 核对 pagination.total_count 与 items 件数，写明是否取得了全部
   - 期间截至用 get_data_ingestion_status 确认的已确定日，不包含当天
6. 未产生广告费的 ASIN 写「无广告实绩」，请区分 0 与无法取得。
7. ROAS・ACoS 直接使用上述返回值，不要自行重新计算。
   请验算按广告活动的明细合计是否与 total 一致，不一致时写明差分。

【Guardrails】请写明库存数据与广告数据的获取方法，中途切换时请公开说明。
请完全不要调用写入类工具（出价・预算变更）。

最后请输出以下 3 点。
1. 推荐行动 — 把按 ASIN 归并后属于紧急补货・下单候选、且产生了广告费的 ASIN
   作为「收紧检讨」，按距离断货的天数从少到多给出。用金额表示断货期间所使用的广告费，
   并一并写出按日折算为月额的浪费规模。
   把属于观察档且 ROAS 在 {{强化ROAS下限（例：2.0）}} 以上的 ASIN 作为「强化检讨」给出。
   若无对应项请写明「无对应项」。无法判定（周出货 0）的 ASIN 不要放入收紧候选，另行列出
2. 执行方法 — 收紧・强化的对象广告活动可以用步骤 5 的 items[] 的 campaign_id 确定。
   把对象 ASIN 与对象广告活动一并写出，建议内容由用户确认・批准后再调整出价。
   但若 1 个广告活动投放了多个 ASIN，收紧该广告活动会影响其他 ASIN，
   因此请写明影响范围并交由人来判断。若想以定向单位而非广告活动单位来压制，
   请在交接中写明
3. 测定 — 库存恢复后 {{评估日（例：7 天后）}} 用相同前提条件重新获取 detect_restock_needs，
   确认收紧对象 ASIN 是否已脱离紧急补货。同时重新获取同一 ASIN 轴的广告实绩，
   用 ROAS 与广告销售额确认强化建议是否有效。不要用 weeksOfCover / daysOfSupply 做恢复判定

可修改的条件 — 交货周期天数（例：14 天）／安全库存天数（例：7 天）／强化检讨的 ROAS 下限（例：2.0）／再确认的评估日（例：7 天后）。

返回内容 — 分开列出的「收紧检讨 ASIN」（按距离断货的天数从少到多，附断货期间所使用的广告费与折算为月额的浪费规模）与「强化检讨 ASIN」（属于观察档且 ROAS 在下限以上）一览、对象广告活动（campaign_id），以及无法判定（周出货 0）的另列清单。由于没有断货时自动停止广告的机制，临近断货的 ASIN 的广告务必由人来判断和调整。

设置变更 — 本页仅分析、建议（不修改广告设置）。实际的调整通过调整竞价 / 调整预算的审批流程（分析 → 审批 → 执行）进行。

接下来做什么 — 要执行收紧、强化时，使用调整竞价 / 调整预算的审批流程。

提示词 5: 把握订购省（SnS）缺货造成的机会损失

订购省（Subscribe & Save, SnS）一旦断货，已登记的定期配送会变成未配送，直接造成销售机会损失。按商品确认「因断货导致的未配送」，作为补货优先级的判断材料。

什么时候用 — 想把握订购省因缺货造成的机会损失，反映到补货优先级中时。

执行前需要的信息 — 无（可直接使用）。与最近期间对比的上一期间，请明确指定为不重叠且长度相同的期间（省略时会自动导出与主期间重叠的范围）。

目的：为尽早把握订购省（SnS）因缺货造成的销售机会损失，并用于库存补货的优先级排序，请获取 {{账户名}} 的订购省商品级实绩与库存状况。

【指标的定义 — 请先确认】
list_sns_products 返回的 not_delivered_due_to_oos 不是「件数」而是「率（%）」（例："0.0%" / "88.9%" / "--"）。
相当于未配送件数・缺货天数・预想需求的字段，在 SnS 类・库存类的任何工具中都不存在。
因此不可把机会损失换算成金额或件数。请用率来排序，规模用出货数与销售额并列表示。
率的分母在规格中没有记载，因此不要反推件数来呈现。

【获取步骤】
1. 只用最近的已完成周指定 {{最近期间}}，以
   sort_key=not_delivered_due_to_oos / sort_order=desc / frequency=weekly 获取 list_sns_products。
   ※ frequency=monthly 会因当月尚未入库而以 0 返回，不要使用。
2. 明确指定长度相同且不重叠的 {{上一期间}}，用相同条件再获取一次。
   not_delivered_due_to_oos 没有 *_compare 字段，因此 1 次调用无法做期间对比。
   另外省略对比期间时会自动导出与主期间重叠的范围，因此务必明确指定。
3. 同一 ASIN 可能以多个 SKU 行重复返回，因此请按 ASIN 归并后再汇总・排序。
4. 对排名靠前的候选调用 get_fba_inventory，并列写出 sellableInventory / weeklyShipmentUnits /
   weeksOfCover。

【值的解释规则 — 必须遵守】
・not_delivered_due_to_oos 为 "0.0%" 表示「无缺货导致的未配送」，"--" 表示「无法算出（该期间出货为 0，
  或 SnS 优惠为 INELIGIBLE / SUSPENDED）」。请不要把 "--" 等同于 0。
・"--" 的商品出货减少，很可能是因为优惠结束，请不要断定为缺货。
・get_fba_inventory 的 weeksOfCover / daysOfSupply，在 weeklyShipmentUnits 为 0 时
  即使还有库存也返回 0。weeklyShipmentUnits=0 的行请把 weeksOfCover 当作「无法算出」，
  不要用作缺货信号。
・请务必区分标注 null / 未取得 / 0。

【数据质量的披露规则 — 最重要】
① 在开头写明取得件数与 product_count，若存在省略标记，请给出总件数・已确认件数・未确认件数。
② 表中记载的行只限工具结果中实际存在的行，不要凭推测・想象编造省略行的 ASIN・商品名・数值
   （哪怕编造 1 行也视为数据的不当使用）。
③ 已确认件数少于全部时，请写明排名仅在已确认范围内成立。
④ 因果关系（例：因缺货导致出货减少）只在 not_delivered_due_to_oos 为正值时主张。
   为 0.0% 或 "--" 时不要断定因果。

【输出】
・最近期间 / 上一期间各自的、率为非零的商品按降序排列的表（ASIN・商品名・缺货率・出货数・SnS 销售额・
  SnS 单价・库存周数）。两个期间都存在的商品附上率的差分（百分点）。
・即使率高，出货数不足 {{最低出货数阈值（例：50）}} 的商品请注明「规模小，补货优先级低」。
・非零为 0 件时请写明「最近期间未检测到缺货导致的未配送」，不要勉强做排名表。
・用 1 行附上未把机会损失换算成金额的理由（未配送件数・缺货期间・预想需求无法从 MCP 获取）。

【判断】请把缺货率较上一期间上升、且出货规模较大的商品，作为库存补货的检讨对象提高优先级来说明。
【Measurement / Follow-up】补货处理后 30 天重新执行相同的 2 期间对比，确认 not_delivered_due_to_oos 的率是否下降（请用率而非件数来对比）。

可修改的条件 — 最近期间／上一期间／作为规模参考的最低出货数（例：50）。

返回内容 — 最近期间・上一期间各自的、按断货导致的未配送率（not_delivered_due_to_oos。不是件数而是 %）从高到低排列的表（ASIN・商品名・缺货率・出货数・SnS 销售额・SnS 单价・库存周数），以及两个期间的差分（百分点）。仅限已有订购省登记的商品（基于 SnS 实绩，与广告归因销售额是不同的数据）。「0.0%」表示无未配送，「—」表示无法算出（无出货实绩，或优惠结束等），两者都不等同于「0」。