这套系统要解决的不是“写得更快”
摘要
亚马逊运营最容易出问题的地方，是把商品事实、经验推断和广告数据混在一份文档里。这套 Skill 把工作拆成六步：每一步都有明确的输入、产出和未知项。目标不是让 Agent 直接接管账户，而是先生成一套品牌方可以逐项审核的运营记录，再决定是否发布 Listing、上传批量文件或执行优化。
1. 六个 Skill，一条证据链
总入口会先判断当前缺少哪一份上游产物，而不是一上来就写 Listing 或建广告。后一个 Skill 可以使用前一个 Skill 的结果，但不能悄悄改写原始依据。
01 · amazon-listing-collector
收集商品依据
把现有 Listing 资料、商品参数、对比输入和待确认信息整理成可追溯的来源包。
02 · amazon-review-analysis
提取用户的真实表达
从评论证据中整理重复出现的需求、顾虑、使用场景和用词，并保留它们来自哪组材料。
03 · amazon-keyword-library-builder
建立可管理的关键词库
把商品词、场景词和用户表达分配到合适位置，不把所有发现的词都当成可直接发布的关键词。
04 · amazon-listing-generator
生成可审核的 Listing 草案
只使用已确认的商品事实和关键词依据来组织文案，对宣称与缺失证明保持可见，交由人审核。
05 · amazon-fad-initialization
生成默认暂停的广告草案
生成启动结构、预算分配和批量文件草案。所有批量行默认保持暂停，必须先审核。
06 · amazon-ad-report-analyzer
把单份报表转成待审核动作表
每次分析一份支持的广告报表，输出判断依据、待选动作和运行清单，不直接回写账户。
2. 阶段之间的交接规则，比一条“完美提示词”更重要
每一个阶段都应保留三层内容：看到的证据、对证据的明确解读，以及建议动作。这样审核者可以否定一个解读，却不会丢掉原始依据。
owned / permitted source material
-> evidence pack
-> review findings
-> governed keyword library
-> Listing draft + gate
-> paused advertising draft
-> one-report analysis + review queue判断规则：如果必需的上游材料缺失，系统应停在当前阶段，或明确标注假设；不得自行编造商品事实、搜索量或真实投放表现。
3. 食品收纳容器案例：这是规划草案，不是成绩单
套件中的食品收纳容器案例，用来展示文件如何从一个 Skill 交接到下一个 Skill。其中数字只表示草案的准备度和预算分配，不代表销售额、点击率、转化率、ACOS、ROAS 或客户数。
生成的所有批量行都保持暂停。上传或启用之前，必须由人逐项确认商品 ID、活动结构、竞价、预算、否定词候选项和对应站点的要求。
4. 实际执行边界
- 不回写亚马逊账户。公开方法和打包 Skill 只生成待审文件；不发布 Listing、不上传批量文件、不修改竞价，也不启用广告。
- 不编造商业结果。规划评分或预算草案，不能当作收入、转化或广告效率的证明。
- 否定词在审核前只是候选项。否定操作会影响后续流量，因此必须保留依据和审核责任人。
- 每次只分析一份广告报表。这样才能说清字段含义、判断阈值和结果来源。
5. 方法公开，实现文件加密
当前页是对外公开的完整方法说明。文件目录、验证记录和套件下载放在需密码访问的代码页；GitHub 仓库为私有。
同步发布：DEV Community · Medium。两个镜像版本都指回当前规范页。