诊断商品目录并制定改进方案

在这个页面，你可以诊断 Amazon 的商品目录（商品页面），并「提案」修改方案。AI 不会无条件地创建或敲定目录内容。流程始终是「AI 提案 → 人工确认・批准 → 输出录入用数据 → 在 Seller Central / Vendor Central 手动反映」，Picaro 不会向目录写入（自动更新・上传）。

本页基本信息

项目	内容
本页能做什么	现有目录的综合诊断・Rufus 视角的诊断，以及商品标题 / 要点（Bullet Points）/ 商品描述 / Item Highlights 的改进方案，整理成 Seller Central / Vendor Central 录入用数据
对象	Amazon 的商品目录（商品标题 / 品牌 / 要点（Bullet Points）/ 商品描述 / 特征属性 / 类目 / 图片 / 尺寸 / 识别码）
所需数据・连接	目标 ASIN。目录通过 Picaro 的目录获取 API（POST /ai/catalog/item）读取（支持的商城: 日本 / 美国 / 德国 / 英国，默认为日本）。自家与他家的 ASIN 都可以获取
操作范围	仅提案・仅整理（只读）。反映由人工在 Seller Central / Vendor Central 手动进行。Picaro 不会向目录写入

本页用到的词

• 商品标题 … 商品页面的标题。既要兼顾检索性又要兼顾辨识度的项目。API 上为 product_name。
• 要点（Bullet Points） … 列出商品要点的项目符号列表。在智能手机上只显示开头几行，因此把重要信息放在最前。API 上为 bullet_point。
• 商品描述（Product Description） … 传达使用场景与详细规格的正文。API 上为 product_description。
• Item Highlights … 用逗号分隔的短语传达要点的项目。会在商品概要区块中作为「特征」「商品的功效」显示。API 上为 special_feature / product_benefit。
• Rufus … Amazon 的生成式 AI 购物助手。会基于商品信息回答买家「这个能用来做○○吗？」「尺寸多大？」之类的问题。
• Seller Central / Vendor Central … 出品者・供应商登录、编辑 Amazon 目录的管理后台。目录的反映由人在这里进行。

关于目录的获取路径（重要）

本页的提示词明确要求用 call_picaro_api 的 POST /ai/catalog/item 来获取目录。因为如果写成不指定路径的形式，AI 可能会选择别的获取手段并在中途停下。

• 请求体的字段名是 market_place（下划线）。写成 marketplace 会返回 422 market_place Field required。
• 获取现有目录的路径只有这个 API。提示词中已指示：获取失败且也没有品牌官方说明（现有目录的文本）时，暂缓诊断与改进方案的制作。
• 即使把提示词改写得更短，也请保留这 2 点。

可获取与无法获取的信息

• 诊断仅为读取，不会向目录写入。
• 可获取: 商品标题 / 品牌 / 制造商 / 要点（Bullet Points）/ 商品描述 / 特征属性（special_feature / product_benefit）/ 注意事项 / 类目（含父类目）/ 商品类型 / 图片 / 尺寸 / 识别码 / 发售日。
• 无法获取: A+ 内容的有无与内容 / 视频 / 价格 / 评论 / 库存 / 搜索结果排名 / 品牌旗舰店引流。请不要凭推测补全这些内容，务必让它写明「无法获取」。
• 图片会把同一张图以多种分辨率返回。 若不先用 variant（MAIN / PT01…）去重再计数，张数会变成约 3 倍。
• 要点不是数组，而是以换行分隔的 1 个字符串返回。把行数当作条数来数。
• 商品描述有时会以空字符串返回。 请不要断定「没有登记」，而要通过 language_tags.product_description 是否为空数组来区分「未登记」与「获取失败」（有可能已迁移到 A+ 内容）。
• 空数组表示「属性未登记」，请与「无法获取」区分开。

反映前必须由人工确认的事项

在把提案的表述直接录入之前，以下事项必须由人工确认。AI 会给需要确认的地方打上标记，但无法做最终判断。

• 法规: 相关法规（如日本《药机法》与《不当赠品及不当表示防止法》）等（涉及功效宣称、优良误认的表述）
• Amazon 的上架政策 / 禁用表述: 对价格、配送、保修的提及，No.1 表述、最高级表述等
• 品牌规范: 书写规则、语气
• 事实核查: 未经证实的性能、数值、认证、获奖、原材料、原产国、兼容性只能由品牌方核实
• 字数上限与必填属性: 没有手段可以返回各类目的上限值与必填项目。请在 Seller Central / Vendor Central 确认

使用场景

• 想确定现有商品页面应该从哪里改起、排出优先级
• 想着眼于经由 Rufus 的曝光与购买判断，确认是否已具备能回答问题的信息
• 想要商品标题 / 要点（Bullet Points）/ 商品描述 / Item Highlights 的改进方案
• 想把现有目录与提案版本并列，转交内部评审或品牌方确认
• 想把已批准的改进方案，整理成便于录入 Seller Central / Vendor Central 的格式
• 想审视那些不易被点击的商品广告的商品页面（切入点来自相关页面的分析）

需要准备的信息

• 目标 ASIN … 准备好想诊断的商品 ASIN（例: B0XXXXXXXX）。
• 商城 … 可从 日本 / 美国 / 德国 / 英国 中指定（默认为日本）。
• 是否为搜索关键词取得实际数据佐证 … 提示词 3・5 会使用搜索词的实际数据。若目标 ASIN 未登记到 SQP（搜索查询表现），则会改用整个账户的广告搜索词代替，并在输出中写明这一点。
• 反映由人工手动进行为前提 … 本页只做到提案・整理。字数限制、输入项目、按类目的模板在 Seller Central 与 Vendor Central 规范不同，也可能变更，反映前请确认录入目标的最新规范。

快速参考

想做的事	能得到什么	设置变更	提示词
从 4 个视角综合诊断现有目录	各视角的评价・评价理由与修改优先级	仅建议	提示词 1
从 Rufus 视角诊断目录	各诊断项目的评价・缺失信息・改进方案	仅建议	提示词 2
制作商品标题的改进方案	3 个改进方案 × 变更理由 × 搜索关键词的佐证数值	仅建议	提示词 3
制作要点（Bullet Points）的改进方案	现有 → 提案的对照表 × 变更理由 × 字数	仅建议	提示词 4
制作商品描述的改进方案	改进方案 × 变更理由 × 依据类别的分写	仅建议	提示词 5
制作 Item Highlights 的改进方案	短语形式的改进方案 × 依据类别 × 采用理由	仅建议	提示词 6
对比现有目录与提案版本	按项目的 现有 / 提案 / 变更理由 比较表	仅建议	提示词 7
把已批准的改进方案整理成录入用数据	录入用文本与评审用数据	仅整理／手动更新	提示词 8

本页只做到「提案」

正如快速参考中「设置变更」全部为「仅建议」或「仅整理」所示，本页不会直接更新目录。反映由人工在 Seller Central / Vendor Central 手动进行。

---

提示词 1: 从 4 个视角综合诊断现有商品目录

获取现有目录，从检索性 / 购买判断 / 可读性 / 信息缺失 4 个视角进行诊断。作为改进方案（提示词 3〜6）的前置步骤，排出应从哪里改起的优先级。

使用场景 —— 在进入单项改进之前，想先排出修改优先级时。

需要准备的信息 —— 目标 ASIN。商城（默认为日本）。

目的：为通过改进目录提升搜索排名与购买率，请获取 ASIN {{目标ASIN（例: B09J4YRG2P）}} 的现有目录并进行综合诊断。

【目录的获取方法】
用 call_picaro_api 调用 POST /ai/catalog/item，body 为 {"asin": "{{目标ASIN}}", "market_place": "{{商城（例: JP）}}"}。
字段名是 market_place（下划线）。写成 marketplace 会返回 422。
这样可以获取 标题(product_name)／品牌／制造商／Bullet Points(bullet_point)／商品描述(product_description)／
类目(classifications・含父类目)／商品类型(product_type)／图片(product_images)／识别码(identifiers)／
尺寸／特征(special_feature)／功效(product_benefit)／注意事项(safety_warning)／发售日。自家与他家的 ASIN 都可以获取。
获取路径只有这个 API。即使返回错误，也不要寻找其他获取手段。

【获取数据的读法（防止误读・必须遵守）】
- product_images 会把同一张图以多种分辨率返回。请先用 variant（MAIN / PT01…）去重再数张数。直接数会变成约 3 倍。
- product_description 因商品而异，有时是空字符串（即使同一品牌内也会空与非空混在一起）。
  为空时请不要断定「没有登记」，请一并确认 language_tags.product_description 是否为空数组，
  并写成「商品描述为空（有可能已迁移到 A+ 内容・本 API 无法判别）」。
- bullet_point 是以换行分隔的 1 个字符串。请把行数当作 Bullet Points 的条数来数。
- 空数组（color / material / care_instructions 等）表示「属性未登记」，请与「无法获取」区分开来写。

【本 API 无法获取的内容（从诊断对象中排除，并写明「无法获取」）】
A+ 内容的有无与内容／视频／价格／评论／库存／搜索结果排名／品牌旗舰店引流。
请不要凭推测补全这些内容，也不要断定「没有」。

【诊断】请从 检索性（搜索关键词的覆盖程度）／购买判断（比较、决策所需信息是否齐全）／
可读性（结构、句子长度、重复、书写不统一）／信息缺失（缺少的信息）4 个视角，逐一给出评价与评价理由，
并按修改优先级从高到低列出改进要点。评价理由中必须附上获取到的实际数据（字数・条数・图片张数・属性是否为空等）作为依据。
在评价检索性时，请用 analyze_sqp 获取目标商品实际的搜索查询词与展示份额，
核对排名靠前的查询词是否已反映到标题・Bullet Points・商品描述中
（聚合占位符「ノーブランド品」（无品牌商品）不是真实的查询词，因此从举措对象中排除）。
与商品实际功效不一致的查询词，即使拿到曝光也不会带来购买，因此不要纳入覆盖对象。

【获取失败时】若上述 API 返回错误，请仅准确报告实际调用的工具名・路径・返回的错误内容，
不要进行诊断。也不要只用获取到的部分项目做局部诊断。
请改为请求用户粘贴现有的标题・Bullet Points・商品描述文本（品牌官方说明）。
不要为没有调用过的工具编造「无法访问」等说明。

最后请输出以下 3 点。
1. 推荐行动 — 给出改进优先级靠前的项目，连同对象・理由・优先级一并说明。
   需要品牌方确认的项目（功效表述的追加・多语言标注等）请明确写为「需品牌方确认」并单独切分
2. 执行方法 — 交给提示词 3（商品标题）／提示词 4（要点）／提示词 5（商品描述）／
   提示词 2（从 Rufus 视角诊断目录・若尚未执行）
3. 测量 — 目录更新后，在下次诊断时确认 Rufus 回答质量・搜索排名的变化

可调整的条件 —— 目标 ASIN（例: B0XXXXXXXX）／商城（日本 / 美国 / 德国 / 英国）。

返回内容 —— 4 个视角各自的评价・评价理由・改进要点，以及修改优先级清单。评价理由中会附上获取到的实际数据（字数・条数・图片张数・为空的属性）作为依据。

此提示词中 AI 会做的事 —— 首先用 Picaro 的目录获取 API 读取现有目录，并按规则处理图片去重、区分「空字符串」与「未登记」这些容易误读的地方。只有检索性的评价需要实际数据，因此会用 SQP（搜索查询表现）获取目标商品实际的搜索查询词与展示份额，核对排名靠前的查询词是否已反映到目录中。获取失败时不做局部诊断，只报告调用过的工具与错误内容然后停止。

设置变更 —— 仅建议（只读，不修改目录）。

下一步 —— 基于诊断结果，进入提示词 3〜6 的单项改进方案。

---

提示词 2: 从 Rufus 视角诊断商品目录

诊断目录是否具备「能回答买家问题的信息」。这种齐备程度会影响经由 Rufus 的曝光与购买判断。

使用场景 —— 想确认商品信息是否便于 Rufus 回答问题时。

需要准备的信息 —— 目标 ASIN。

目的：请基于现有目录的实际数据，诊断包含 Amazon 生成式 AI 助手（Rufus）在内的「读取商品信息的机器与人」，能否正确理解 ASIN {{目标ASIN（例: B09J4YRG2P）}} 的商品。

【目录获取】
请用 call_picaro_api 调用以下内容，并仅以返回的实际数据作为诊断依据。
  method: POST
  path: /ai/catalog/item
  body: {"asin": "{{目标ASIN（例: B09J4YRG2P）}}", "market_place": "{{商城（例: JP）}}"}
- 字段名是 market_place（下划线）。写成 marketplace 会返回 422 错误。
- product_images 会把同一张图以多种分辨率返回，因此请先用 variant（MAIN / PT01…）去重再数张数。
- A+ 内容・评论・顾客 Q&A・全成分标示不包含在本 API 中。
- 仅当上述 API 返回错误时，才仅准确报告调用的工具名与返回的错误内容，不要进行诊断，并请求用户粘贴现有目录的文本。不要为没有调用过的工具编造并不存在的限制说明。

【诊断规则（严格遵守）】
- Rufus 的排名因素与内部规格并未公开。请不要断定「Rufus 会这样评价」。评价请用「目录的结构化信息充实到什么程度、是否一致」这一可观测的代理指标进行，并以倾向・假设的方式描述，而不是断言。
- 所有指摘都请附上依据类别。
  [实际数据] … 可以引用获取到的目录中对应字段来佐证的内容
  [无法获取] … 本 API 无法获取的内容（不要凭推测填补）
  [一般论] … 一般性的最佳实践（不要做没有出处的断定）
- 请不要把为空的字段断定为「没有信息」。因为有可能已由 A+ 内容一侧补足，请表述为「结构化字段为空」。
- 不适用的诊断项目请写明「不适用（类目: <product_type>）」，不要硬凑。

【诊断项目】
商品的用途／目标用户／使用方法／尺寸・容量・材质・成分／比较要点／适配环境・兼容性／对购买前常见疑问的回答／信息的缺失与矛盾／标题・Bullet Points・商品描述之间的重复／购买判断所需信息的覆盖度。

请按项目给出「依据类别・评价理由・缺失信息・修改优先级（高／中／低）・具体改进方案」。只给分数的回答不可接受。
在「信息的缺失与矛盾」中，请务必核对数值字段之间的不一致（item_dimensions 与 item_package_dimensions、size・容量・重量与标题标注之间的出入等）。

【最后请输出以下 3 点】
1. 推荐行动 — 给出改进方案中优先级靠前的项目，连同对象字段・理由・依据类别一并说明
2. 执行方法 — 交给对应的改进提案提示词（提示词 3 商品标题／提示词 4 要点／提示词 5 商品描述）。涉及成分・材质・功效的变更，请把「必须由品牌方做事实核查」写明为必要条件
3. 测量 — 在下次诊断时重新测量「结构化字段的非空率」与「矛盾件数」。Rufus 的回答质量本身无法从外部测量，因此不要把它断定为 KPI

可调整的条件 —— 目标 ASIN。

返回内容 —— 各诊断项目的评价・评价理由・缺失信息・修改优先级・具体改进方案。不是「Rufus 适配得分」这种只有分数的回答，而是给到「按什么顺序改什么」。

此提示词中 AI 会做的事 —— 由于 Rufus 的排名因素并未公开，诊断不以「Rufus 会如何评价」为准，而是用「目录的结构化信息充实到什么程度、是否一致」这一可观测的代理指标。每条指摘都必定带上 [实际数据] / [无法获取] / [一般论] 的依据类别，读者因此能区分基于实际数据的指摘与一般论。尺寸・容量・重量与标题标注之间的出入等字段之间的矛盾也会被核对。

设置变更 —— 仅建议（只读，不修改目录）。

---

提示词 3: 制作商品标题的改进方案

诊断现有商品标题，提出兼顾检索性与辨识度的改进方案。要纳入的关键词会用实际数据取得佐证。

使用场景 —— 想在纳入搜索关键词的同时，避免标题变成卖点词堆砌时。

需要准备的信息 —— 目标 ASIN。

目的：为提升 ASIN {{目标ASIN（例: B0XXXXXXXX）}} 的检索性与购买率，制作商品标题的改进方案。

【步骤1: 获取现有目录（必须・一次信源）】
请用 call_picaro_api 调用以下内容，获取现有标题（product_name）・bullet_point・product_description・product_type・classifications。
  method: POST / path: /ai/catalog/item / body: {"asin": "{{目标ASIN}}", "market_place": "JP"}
※字段名是 market_place（下划线）。写成 marketplace 会返回 422。
※product_description 有时会以空字符串返回。为空时请写明「已获取但为空」，不要断定「没有描述」。A+ 内容不包含在本 API 中。
若获取失败，请原样报告调用的工具名与错误内容，不要生成改进方案并停止。

【步骤2: 获取搜索关键词的实际数据（必须・禁止推测）】
要放进标题的关键词，必须用实际数据取得佐证。不得凭推测写出「看起来有人搜的词」。
  a) 用 list_sqp_products 查出目标 ASIN 的 product_id。
  b) 若能找到，用 list_sqp_date_ranges 确认有效的 date_range，并执行 analyze_sqp（frequency=monthly，已确定的最近期间）。
     → 把各 query 的 queryVolume / impressionShare / asinCtr / asinCvr / bottleneck 用作依据。
  c) 仅当目标 ASIN 不在 list_sqp_products 中时，才用 list_search_term_performance（最近 1 个月）代替。
     这种情况下请在输出中写明「这是整个账户的广告搜索词，并非目标 ASIN 专有」。
对用作依据的每个关键词，都必须并记数值（搜索量・展示份额等）与获取来源的工具名。

【步骤3: 制作改进方案】
请给出 3 个现有标题的改进方案。每个方案都并记以下内容。
- 变更理由
- 纳入的搜索关键词，及其佐证数值・获取来源（仅限步骤2中获取到的）
- 删去的信息及其理由
- 字数（并记现有标题的字数以便比较）
约束:
- 避免堆砌卖点词。
- 在现有目录（bullet_point / product_description / special_feature 等）中没有依据的卖点不要放进正文，请作为「需品牌方确认」单独列出。即使搜索量很大，目录中没有依据的功效・成分也不要放进去。
- 标题的字数上限与禁用表述无法获取。请把现有标题的字数作为暂定参考，并务必写明「按类目的字数上限与禁用表述（药机法・类目规定）需要由使用者一侧确认」。不要擅自断定上限值。

【输出】最后请输出以下 3 点。
1. 推荐行动 — 写明 3 个方案的优先级（按搜索关键词覆盖度・诉求力的顺序）・预期效果（用步骤2的数值表示）・确信度・风险
2. 执行方法 — 本结果交给提示词 7「对比现有目录与提案版本」。不执行目录的实际更新（只做到提案）
3. 测量 — 在{{评估日（例: 反映 2 周后）}}重新获取该 ASIN 的搜索排名（SQP）与 CVR，判定改善/恶化。Guardrail: 不得低于现行的 asinCvr

可调整的条件 —— 目标 ASIN／评估日。

返回内容 —— 3 个改进方案 × 变更理由 × 纳入关键词的佐证数值与获取来源 × 删去信息的理由 × 字数的比较 × 需品牌方确认事项。

此提示词中 AI 会做的事 —— 为了不让 AI 凭推测列出关键词，会让它用 SQP（搜索查询表现）获取目标商品实际的搜索查询词，并为每个关键词并记搜索量、展示份额的数值与获取来源。若目标 ASIN 未登记到 SQP，则改用整个账户的广告搜索词，并写明「并非目标 ASIN 专有」。即使搜索量很大，目录中没有依据的功效・成分也不会放进正文，而是分到「需品牌方确认」。

设置变更 —— 仅建议（不修改目录）。字数与书写规则因类目和商城而异，反映前请确认 Seller Central / Vendor Central 的最新规范。

---

提示词 4: 制作要点（Bullet Points）的改进方案

要点（Bullet Points）在智能手机上只显示开头几行，因此把重要信息放在最前的结构很关键。诊断现有要点并提出改进方案。

使用场景 —— 想把重要信息集中到最前、让要点更易读时。

需要准备的信息 —— 目标 ASIN。商城（默认为日本）。

目的: 为提升可读性与购买率，请获取 ASIN {{目标ASIN}} 的现有目录，给出 Bullet Points 的改进方案。不要修改目录，只做到提案。

【目录的获取】
1. 首先请用 call_picaro_api 调用 POST /ai/catalog/item（body: {"asin": "{{目标ASIN}}", "market_place": "{{商城}}"}）。字段名是 market_place（下划线）。写成 marketplace 会返回 422。
2. 返回的 bullet_point 不是数组，而是以换行(\n)分隔的 1 个字符串。请务必先用 \n 分割，再数「现有有几条」「每条多少字」，并确认它与 language_tags.bullet_point 的元素数一致，把该表包含在输出中。
3. product_description 有时是空字符串。为空时请写明「已获取但为空」，不要断定「没有描述」。A+ 内容不包含在本端点中，因此不要把 A+ 的记载当作依据。

【改进方案】
- 提案的 Bullet Points 条数不得超过现有条数，且控制在 5 条以内（Amazon 的 Bullet Points 通常最多 5 条）。
- 每条 Bullet Point 用「标题：正文」的格式，把重要信息放在最前。
- 逐条并记与现有版本的对照（现有→提案）和变更理由。
- 在现有目录（标题・现有 Bullet・product_description・special_feature 等）中没有依据的卖点不要放进正文，请作为「需品牌方确认」分开列出。
- Bullet Points 的字数上限无法获取。请写明提案各条的字数，并在输出中明示「上限需要确认类目要求」。不要凭推测写出上限值。
- 若要以搜索词为依据补充关键词，必须用 analyze_sqp（目标商品的 product_id）实际获取，并只使用获取到的词。未获取时请不要写「应该纳入的关键词」（那会变成推测）。

【目录获取工具失败时】请仅准确报告实际调用的工具名，以及该工具返回的错误内容。不得为没有调用过的工具・端点编造「无法访问」「有限制」等说明。若上述 1 失败，请不要寻找其他获取手段，暂缓制作改进方案，并请求用户粘贴现有的标题与 Bullet Points 文本（品牌官方说明）。

【输出的最后】为了采用时可以直接交给下一道工序（录入用目录数据的整理），请把提案的 Bullet Points 以带编号的纯文本、不加任何修饰地汇总后再列一次。

【Measurement / Follow-up】请在反映后 2〜4 周确认 CVR 与加购率的走势（用 analyze_sqp 的 asinCvr / asinAtc，在相同 product_id・相同 frequency 下比较反映前后的已确定期间）。

可调整的条件 —— 目标 ASIN／商城。

返回内容 —— 现有条数与每条字数的表格、逐条的 现有 → 提案 对照与变更理由、需品牌方确认事项，以及不加修饰重新列出的提案正文（可直接交给下一道工序）。

此提示词中 AI 会做的事 —— 由于要点是以换行分隔的 1 个字符串返回，会先分割后数条数与字数，并与语言标签的元素数核对。「标题：正文」格式是 Amazon（美国）官方指南推荐的结构，在日语目录中同样有助于提高可读性。把提案条数限制在现有条数以内且不超过 5 条，是因为 Amazon 的要点通常最多 5 条。

设置变更 —— 仅建议（不修改目录）。

---

提示词 5: 制作商品描述的改进方案

诊断商品描述（Product Description），在避免与要点（Bullet Points）重复的同时，提出补足购买判断所需的故事与详细信息的改进方案。

使用场景 —— 想补足使用场景与详细规格、避免与标题・要点重复时。

需要准备的信息 —— 目标 ASIN。商城（默认为日本）。

目的: 为补足购买判断的材料、提升购买率，请获取 ASIN {{目标ASIN}} 的现有目录，
给出商品描述（product_description）的改进方案。

【目录获取的步骤】
请用 call_picaro_api 执行以下内容。
  method: POST / path: /ai/catalog/item
  body: {"asin": "{{目标ASIN}}", "market_place": "{{商城（默认: JP）}}"}
字段名是 market_place（下划线）。写成 marketplace 会返回 422。
获取到之后，请把 product_name / bullet_point / product_description / special_feature /
product_benefit / safety_warning / size / item_dimensions / classifications /
product_images 用作依据。product_images 会把同一张图以多种分辨率返回，
因此要先用 variant（MAIN / PT01…）去重再数张数。

【product_description 为空字符串时】
若 language_tags.product_description 为空数组，则意味着「该 ASIN 没有登记商品描述」，
而不是获取失败。这种情况下不要做「与现有版本的对照」，而是作为新建来处理，
仅以 Bullet Points 与上述目录属性为依据撰写商品描述的初稿，并在开头写明
「现有商品描述未登记，故无对照。有可能已迁移到 A+ 内容，需由品牌方确认是否与 A+ 的内容重复」。
A+ 内容在本 API 中无法获取。

【输出中要包含的内容】
- 指出与标题／Bullet Points 重复的记述（明确指出与哪一条 Bullet 重复）
- 改进方案正文。采用补足 用途・场景・详细规格・购买前疑问的回答 的结构
- 与现有版本的对照和变更理由
- 每条记述的依据类别必须分写成「目录实际数据」「实绩数据（写明使用的工具名与期间）」「一般论」
  这 3 类来展示
- 在现有目录中没有依据的卖点不要放进正文，请作为「需品牌方确认」另行汇总

【以搜索词为依据时】
不要用一般论敷衍，请在用 list_sqp_products 获取 product_id 之后实际执行 analyze_sqp，
先找出自家加购率・CVR 低于市场平均的搜索词，再用能回答这些词所代表的购买前疑问的结构来写。
商品特性本身就不一致的搜索词（用途不同・配方不同）请作为「靠描述文无法解决」从改进对象中排除，
并写明这一点。
若瓶颈分类偏向 exposure_gap，请务必写明「靠改进商品描述能带动的是 CVR / ATC，
曝光不足无法因此解决」。

【工具失败时】
请仅准确报告实际调用的工具名，以及该工具返回的错误内容。
不得为没有调用过的工具・端点编造「无法访问」等说明。
仅当上述目录获取失败时，才不生成改进方案，并请求用户粘贴现有的标题・Bullet Points・
商品描述文本。

【不得向目录写入。】只做到提案，反映由用户进行。

【Measurement / Follow-up】请在反映后 2〜4 周，用 analyze_sqp 把该 ASIN 的 asinCvr（Primary KPI）
与 asinAtc 的走势与反映前的基线做比较来确认（「记录举措与外部事件并验证效果」页面的效果测定提示词）。
跳出率・停留时间 Amazon 并未提供给出品者，Picaro 也无法获取，因此 Guardrail 请改用
asinAtc 不恶化来代替。

可调整的条件 —— 目标 ASIN／商城。

返回内容 —— 与标题・要点重复之处的指出、改进方案正文、与现有版本的对照和变更理由，以及每条记述的依据类别（目录实际数据 / 实绩数据 / 一般论）的分写。

此提示词中 AI 会做的事 —— 为了避免商品描述返回为空时被误判成「没有描述」，会用语言标签的元素数来区分「未登记」与「获取失败」。若为未登记，则从对照切换为新建。以搜索词为依据时，会收敛到自家 ATC 率・CVR 低于市场平均的词。当瓶颈偏向曝光不足时，会明确写出「靠改进商品描述无法解决」，因此不会把打法用错。

设置变更 —— 仅建议（不修改目录）。

---

提示词 6: 制作 Item Highlights 的改进方案

Item Highlights（special_feature / product_benefit）是用逗号分隔的短语传达商品要点的项目。会在商品概要区块中作为「特征」「商品的功效」显示。现有值可以从目录获取 API 取得。

使用场景 —— 想用短语补足标题里放不下的要点时。

需要准备的信息 —— 目标 ASIN。若有想作为比较对象的同类目自家 ASIN，请一并指定。

目的：为提升 ASIN {{目标ASIN}} 商品页面的诉求力，制作 Item Highlights（Amazon 上架属性的 special_feature / product_benefit。会在商品概要区块中作为「特征」「商品的功效」显示的短属性短语）的改进方案。只做到提案，不得对目录做任何修改。

【现有目录的获取】
请用 call_picaro_api 调用以下内容，把现有值作为一次信源获取。
  method: POST / path: /ai/catalog/item
  body: {"asin": "{{目标ASIN}}", "market_place": "{{商城（例: JP）}}"}
※ 字段名是 market_place（下划线）。写成 marketplace 会返回 422。
※ 获取现有目录的路径只有这个 API。请不要寻找其他获取手段。获取失败且也没有品牌官方说明（现有目录的文本）时，请暂缓制作改进方案。
获取后请务必明示以下内容。
- 现有 special_feature / product_benefit 的值与件数（0 件则写「未设置」。不要把空数组与未获取混为一谈）
- product_name / bullet_point / product_description 能否获取（product_description 有时是空字符串。不要把为空断定为「没有描述」，而要按是否获取成功来写）
- 作为参考，也请获取同一品牌的比较对象 ASIN {{比较对象ASIN（同类目的自家ASIN・可选）}} 的 special_feature / product_benefit，比较自家内部的充实程度

【提案的做法】
- 用逗号分隔的短语，优先 材质/用途/使用场景/客观的比较特征
- 不要放入与 product_name 重复的信息（并写明用于重复判定的现有标题）
- 不要加入对价格、配送、保修的提及、夸大表述和表情符号
- 每条提案短语都必须标注依据类别
    [实际数据] … 在获取到的 bullet_point / product_description / 属性值中有对应记述（请引用对应之处）
    [一般论]   … 目录记述中没有依据，基于一般性的最佳实践
  没有实际数据佐证的短语不得写成实际数据。
- special_feature / product_benefit 可能会被 Amazon 一侧限制允许值，而且不存在返回允许值清单的手段。请优先采用在比较对象 ASIN 中确认实际存在的值，其余的请在风险栏中写明「能否登记需要在 Seller Central 确认」。

最后请输出以下 3 点。
1. 推荐行动 — 逐条提案短语写明 依据类别・强化哪个购买决策要素・优先级・确信度・风险
2. 执行方法 — 本结果交给提示词 7「对比现有目录与提案版本」（本提示词不修改目录）
3. 测量 — 在{{评估日（例: 反映 2 周后）}}重新获取商品页面的转化指标，若无改善则重新审视表述。不要把没有获取手段的指标写进测量计划

可调整的条件 —— 目标 ASIN／比较对象 ASIN／评估日。

返回内容 —— 逗号分隔短语形式的改进方案 × 各短语的依据类别（[实际数据] / [一般论]）× 与标题的重复检查结果 × 能否登记的待确认事项。

此提示词中 AI 会做的事 —— 会先让它明示现有特征属性的值与件数，0 件时写「未设置」（以免与未获取混淆）。把同一品牌的其他 ASIN 作为比较对象，就能衡量自家内部的充实程度。特征属性可能会被 Amazon 一侧限制允许值，而且没有手段返回允许值清单，因此优先采用在比较对象 ASIN 中确认实际存在的值，其余则作为能否登记的待确认事项保留。

设置变更 —— 仅建议（不修改目录）。

---

提示词 7: 对比现有目录与提案版本

将提示词 3〜6 生成的改进方案与现有目录按项目并列比较，形成用于批准判断、品牌方确认的评审资料。

使用场景 —— 想把现有与提案并列的资料，转交内部评审或品牌方确认时。

需要准备的信息 —— 目标 ASIN。在同一会话中已有提示词 3〜6 的提案时使用。

目的：为快速做出批准判断，针对前面的改进提案（标题 / Bullet Points / 商品描述 / Item Highlights），制作与现有目录的比较表。

【提案版（比较表右侧）的取得】
提案版是前道工序（提示词 3〜6）的输出。工序之间没有自动传递成果的机制。
若同一对话中没有留下前道工序的输出，请不要开始比较，而是请求提供目标 ASIN 与改进提案的全文。
禁止靠推测・再生成提案版来填满比较表。

【现行版（比较表左侧）的获取】
现有目录请用 call_picaro_api 获取。
  method: POST / path: /ai/catalog/item / body: {"asin": "{{ASIN}}", "market_place": "{{MARKETPLACE}}"}
  ※ 字段名是 market_place（下划线）。写成 marketplace 会返回 422 错误。
项目的对应关系为 标题=product_name / Bullet Points=bullet_point（换行分隔）/ 商品描述=product_description。
- bullet_point 不是数组，而是以换行分隔的 1 个字符串返回。请按换行分割后数条数，并确认与 language_tags.bullet_point 的元素数一致。
- product_description 有时会以空字符串返回。请不要断定「没有商品描述」，而要写成「获取结果为空（有可能已迁移到 A+）」。看 language_tags.product_description 的元素数即可判别「未登记」与「获取失败」。
- A+ 内容不包含在本响应中。请不要以 A+ 为依据进行比较。
- 若要并记图片张数，请先把 product_images 用 variant（MAIN / PT01〜）去重再数（因为同一张图会以 3 种分辨率返回，直接数会变成 3 倍）。
- Item Highlights 请按与提示词 6 相同的定义（special_feature / product_benefit）处理。这 2 个字段包含在响应中，各自以带 language_tag 的数组返回多个值。请不要写成「无法获取」。值为空数组时请写「未设置」，不要与未获取混淆。另外，由于没有手段返回这 2 个字段的允许值清单，提案值能否登记请作为待确认事项留下「需要在 Seller Central 确认」。
- 请确认获取到的 ASIN 的 brand，核实对象是自家商品。

【输出】
请按项目（标题 / Bullet Points / 商品描述 / Item Highlights）
汇总成并记 现有 / 提案 / 变更理由 / 期望效果 / 需确认事项 / 现有值能否获取 的比较表。
获取到的项目与未能获取的项目必须区分记载。
仍带有「需品牌方确认」等标记的项目，在确认完成之前不要当作已批准处理。
只把已批准的项目推进到下一道工序。

此结果用于下一步提示词: 提示词 8「把已批准的改进方案整理成录入用数据」

可调整的条件 —— 目标 ASIN／商城／比较项目的范围。

返回内容 —— 按项目的 现有 / 提案 / 变更理由 / 期望效果 / 需确认事项 / 现有值能否获取 的比较表。可直接用于内部评审或转交品牌方确认。

此提示词中 AI 会做的事 —— 提案版是前道工序的输出，工序之间没有自动传递的机制。若同一会话中没有留下前道工序的输出，AI 不会开始比较，而是请求提供并停止（以免靠推测填满比较表）。现行版会重新从目录获取 API 读取，因此比较表的左侧始终是实际数据。仍带有需品牌方确认标记的项目，不会作为已批准推进到下一道工序。

设置变更 —— 仅建议（不修改目录）。

---

提示词 8: 把已批准的改进方案整理成录入用数据

将人工确认、批准后的改进方案，整理成便于录入 Seller Central / Vendor Central 的格式。不会自动上传，也不会在未经确认的情况下反映。 录入操作必须由人在 Seller Central / Vendor Central 上进行。

使用场景 —— 想把已批准的改进方案，整理成便于录入的形式时。

需要准备的信息 —— 录入目标（Seller Central / Vendor Central）。目标 ASIN。在同一会话中已有已批准的改进方案时使用。

目的：把已批准的目录改进方案，整理成可用于实际录入作业的形式。
前提：Picaro 无法执行向目录的录入・反映。本次产出的是供负责人手工粘贴到{{录入目标（例: Seller Central）}}的编辑界面或平面文件（flat file）中的数据。请只做整理，不要执行录入。

输入：{{已批准的改进方案（在前道工序的比较表中获批的项目）}}
若该输入没有出现在对话中，请不要推测・生成改进方案，而是请求提供并停止。

步骤：
1. 请用 Picaro 的目录获取，取得{{目标ASIN}}的现有目录信息，并记下要用作依据的值（商品名・要点・商品描述・商品类型・类目・特征属性・识别码・图片）。未能获取的项目请写明「未能获取」，不要凭推测填补。
   - 商品描述有时会以空返回。不要把为空断定为「没有描述」，请把是否获取成功分开来写。
   - 图片会把同一张图以多种分辨率返回，因此请先用 variant 去重再数张数。
   - A+ 内容不在获取范围内。涉及 A+ 一侧表述的项目请写明这一点。
2. 请把已批准的改进方案与现有值对应起来，整理成录入用文本。不变更的项目请明示「维持现状」。

请分开输出以下内容：
- 【录入用数据】按项目的录入用文本（可直接粘贴使用。不要混入理由或注记）
- 【评审用数据】变更理由（与 变更前→变更后 对应起来）
- 【评审用数据】用作依据的商品信息（获取来源与获取日期、使用的字段、未能获取的内容）
- 需要确认的表述（附法务・药事・品牌确认标记）
- 反映前的确认事项清单

清单中请务必包含以下内容：
- 按商品类型的必填属性・输入栏规格，需在{{录入目标}}一侧确认（无法从 Picaro 获取）
- 在反映界面做差异确认，检查不变更的项目有没有被意外覆盖
- 把反映前的现有值作为备份保存（用于回滚）
- 记录反映日，作为效果测定的起点

录入后请在{{评估日（例: 2 周后）}}重新获取该 ASIN 的 CVR，若无改善则重新审视表述。CVR 因 ASIN 而异可能无法获取，因此请在反映前确认目标 ASIN 的 CVR 是否可获取；若无法获取，请写明替代指标，并写明该指标与商品页面 CVR 并不相同。
此结果用于下一步提示词: 「记录举措与外部事件并验证效果」页面的效果测定提示词

可调整的条件 —— 录入目标（Seller Central / Vendor Central）／目标 ASIN／评估日。

返回内容 —— 按项目的录入用文本（可直接粘贴的形式），以及附理由・依据・确认标记的评审用数据，还有反映前的确认事项清单。

此提示词中 AI 会做的事 —— 会把录入用数据与评审用数据分开输出，不混在一起。若对话中没有已批准的改进方案，不会凭推测生成，而是请求提供并停止。清单中一定会包含「不变更的项目有没有被意外覆盖」「把反映前的现有值作为回滚备份留存」「把反映日作为效果测定的起点记录下来」。

设置变更 —— 仅整理（不执行上传・反映）。字数限制、输入项目、按类目的模板在 Seller Central 与 Vendor Central 规范不同，也可能变更，反映前请务必确认录入目标的最新规范。反映由人工手动进行。

---

相关分类

• 找出成效好的关键词与商品定向 —— 检测不易被点击的商品广告（寻找目录改进的切入点）
• 分析从搜索到购买在哪一步流失（SQP） —— 从市场搜索词中寻找「应纳入的关键词」
• 用 N-gram 分析高效搜索模式 —— 把销售贡献高的搜索词反映到目录