把选品、Listing 和广告的 Skill 串成一条工作流
串联的价值不在省时间，在保证上下游用的是同一份判断——选品时认定的差异点，会一路传到 Listing 的卖点和广告的核心词上。做法是让每个 Skill 输出结构化的中间文件，下一个 Skill 读它而不是重新推导。但串联会放大错误：上游一个错误结论会污染下游全部产出，所以关键节点必须保留人工确认，出问题时也要能单步重跑。
串联的价值不在省时间，在保证上下游用的是同一份判断——选品时认定的差异点，会一路传到 Listing 的卖点和广告的核心词上。做法是让每个 Skill 输出结构化的中间文件，下一个 Skill 读它而不是重新推导。但串联会放大错误：上游一个错误结论会污染下游全部产出，所以关键节点必须保留人工确认，出问题时也要能单步重跑。
到这里，前面几篇的 Skill 都是各跑各的：调研出一份报告，写 Listing 时你把报告里的结论手动誊过去，投广告时再把关键词手动整理一遍。
串起来能省掉这些搬运动作，但省时间不是重点。
重点是上下游用的是同一份判断。
你在选品阶段认定这个产品的差异点是「防缠绕刷头解决了宠物毛问题」，这个结论应该一路传下去：Listing 的第四点卖点要写它，广告的核心词组要围绕它，客服的常见问题要覆盖它。
人工搬运的时候，这条链很容易断。调研报告写完放进文件夹，两周后写 Listing 的可能是另一个同事，他重新看了一遍竞品，得出了一个稍微不同的结论。于是产品页强调的和广告投的对不上，数据也就没法归因。
串联解决的是这个问题。
要串起来，每个 Skill 的输出就不能只是给人看的 Markdown 报告，还要有一份给下一环读的结构化文件。
设计一份贯穿全流程的产品档案，比如 product/<sku>/profile.json：
{
"sku": "VC-2000",
"category": "宠物吸尘器",
"stage": "listing_ready",
"facts": [
{ "key": "续航", "value": "45 分钟", "source": "specs.md" },
{ "key": "噪音", "value": "62 分贝", "source": "specs.md" }
],
"differentiators": [
{
"point": "防缠绕宠物毛刷头",
"evidence": "竞品差评中 34% 提到毛发缠绕",
"confirmed_by": "human",
"confirmed_at": "2026-09-20"
}
],
"core_keywords": ["pet hair vacuum", "anti tangle brush"],
"warnings": ["成本表缺少 2026 年 9 月后的报价"]
}
几个字段值得单独说：
source：每条事实都要能追到出处。下游生成 Listing 时，只允许使用有 source 的事实confirmed_by：这条结论是人确认过的，还是 AI 推出来的。下游对两者的处理方式应该不同stage：走到哪一步了。防止跳步，比如没确认差异点就去生成 Listingwarnings：上游发现的数据问题，要一路带下去，不能在中途消失最后一条最容易被忽略。上游写了「成本数据缺失」，如果这个警告在传递中丢了，下游算毛利时就会拿着不完整的数据得出确定的结论。
串联的风险是错误会顺着流水线传下去，而且越传越难发现。所以要在几个关键节点卡人工确认。
建议卡三处：
调研出来的「空位假设」是假设，不是结论。这一步必须人确认：这个差异点你的供应链做不做得到、成本能不能接受。
确认之后写进 confirmed_by，下游才允许把它当卖点用。
没有这一道，你可能会围绕一个根本做不出来的差异点，做完整套 Listing 和广告。
前面讲过，合规责任落在账号上。这一道不能省。
预算和竞价的初始设置要人定。跑起来之后的日常诊断可以自动，但第一次开投是人的决定。
这三处之外的环节都可以自动流转。
用一个主 Skill 把子流程编排起来：
---
name: product-pipeline
description: 把一个新产品从调研推进到可投放：调研、差异点确认、Listing 生成、广告词准备，按阶段执行并在关键节点停下来等人确认。当用户要推进一个新品、走完整上架流程时使用。
argument-hint: [sku]
allowed-tools: Read Write Bash(python3 *)
---
## 状态
读取 `product/$0/profile.json`，按 `stage` 决定从哪一步开始。
文件不存在时，从头创建，`stage` 设为 `research`。
## 阶段
### research
执行品类调研和抱怨分析，把结果写进 profile：候选差异点、核心关键词、竞品价格带。
完成后 `stage` 改为 `awaiting_diff_confirm`，停下来，输出待确认的差异点清单。
### awaiting_diff_confirm
不自动推进。等人在 profile 里把某个差异点标为 `confirmed_by: human` 之后，才能进入下一步。
### listing_draft
只使用 profile 里带 source 的事实，和已确认的差异点，生成 Listing 草稿。
未确认的差异点不得写进卖点。
完成后 `stage` 改为 `awaiting_listing_review`。
### awaiting_listing_review
不自动推进。等人确认 Listing 已上架。
### ads_prep
基于已确认的差异点和核心关键词，生成初始广告结构建议：广告活动分组、核心词、否定词初始清单。
不设置预算和竞价，这两项留空由人填。
完成后 `stage` 改为 `awaiting_ads_launch`。
## 通用规则
- 每个阶段结束时，把本阶段的产出和 `warnings` 写回 profile
- 上游的 warnings 必须原样带到下游，不得删除
- 任何一步的数据不足以继续时，停下来说明缺什么，不要跳过
## 禁止动作
- 不跳过任何 `awaiting_*` 状态
- 不修改人已经确认过的字段
- 不调用任何平台接口
流水线最麻烦的地方是出了问题不知道在哪一环。三条实践：
**每一步都留产出文件。**不要只保留最终结果。每个阶段的中间产物都写进磁盘，出问题时能一步步回看。
**支持单步重跑。**因为有 stage 字段，你可以把它改回上一个阶段重跑那一步，而不用从头来一遍。
**profile 用 Git 管起来。**每个阶段结束提交一次。这样任何一条结论是什么时候进来的、被谁改过，看提交历史就清楚。
这三条加起来，排错成本会低很多。
也有不该串的时候：
判断标准和前面所有场景一致：**重复频率高、流程能标准化、结果能验证。**串联本身也要过这三关。
回头看整条路径：先搞清楚它能干什么、把它装上、接好自己的 API，再写第一个 Skill，然后按场景一个个展开，最后串成流水线。
真正的规律只有一条：每一步的价值都不来自 AI 更聪明，而来自你把规则写清楚了。
调研的质量取决于你定的字段，广告诊断的质量取决于你定的阈值，Listing 的质量取决于你整理的事实表，客服的质量取决于你的知识库。Claude Code 是那个不知疲倦、每次都严格照做的执行者，但照什么做，仍然是你的活。
所以真正的建议是：先挑一件每周都要重复、规则说得清、结果能验证的工作，把它写下来。写下来的那一刻，收益就已经产生了一半——哪怕你最后没用任何 AI 工具。
有具体场景想聊的，联系方式在关于页面。
大部分团队用 AI 还停在翻译、写文案和生成图，AI 只参与了工作中间一小段。Claude Code 的区别在于它能读本地文件、通过 MCP 接外部数据、把流程写成 Skill 反复执行，也就是能自己动手而不只是给建议。但对外发送、改价、改库存这类动作必须留人工确认；能批量生成不等于该批量生成。建议先挑一个每周都要重复、规则写得出来、结果能验证的动作跑通，再往外扩。
监控的难点不是抓数据，是决定什么值得打断你。价格波动几毛钱、短暂缺货、临时活动价，这些每天都在发生，全推给你等于没有监控。做法是设置幅度阈值和持续时间双重过滤，再按影响程度分成立刻通知、汇总日报、只记录三档。跟价一律不自动执行，因为自动跟价的对手方也是程序，很容易被拖进对谁都没好处的价格战。
客服邮件自动化里，分类比写回复值钱得多——把几十封邮件按类型和紧急度分好流，人处理起来的顺序就完全不同了。回复草稿要分级：政策类问题照资料答，订单类问题带上具体信息，涉及退款、赔付、责任认定和法律的一律只标记不起草。发送权不给它，理由不是技术不行，是对外承诺的责任落在账号上。用改稿率和转人工比例衡量效果，改稿率长期高说明规则没写清楚。
作者
大阪烧鸟
大阪烧鸟，关注 AI 在跨境电商运营中的实际应用、Shopify 独立站与日本商业观察，偏爱把复杂问题拆成可执行的方法。
如果这篇内容对你有帮助，可以继续浏览 zens.osaka 的文章列表，按主题顺着看相关问题。
转载或引用请保留 zens.osaka 的原文链接与标题。
