调味品营销内容爆款文案生成（pro版）【AHA抖帮主·出品】

概述

计费与交付：需要付费（pricing.model=paid，每次 1.28 元）；服务端采用 X402 支付协议，首次请求返回 402，完成支付后带凭证重试即可拿到内容；交付 data.files（每个所选平台各一份 Markdown）；一次调用生成所选平台的全部内容。

调味品营销内容文案生成（pro版）

把商家输入的「平台 / 品类 / 单品 / 卖点 / 字数」一次性变成「速取区铺平 + N 套按平台 7 节框架」的营销文案产物。

一、产品介绍

调味品中小商家一次输入多平台信息，AI 全量处理输出多平台可发布稿件。

方法与优势：

1. 多平台并行：1-9 个平台一次选完、按平台动态设置字数，N 套 7 节内容一次生成
2. 速取区铺平：所有平台的最优标题 + 全文 + 标签 + 顾虑应答一次性铺开，商家一键复制走
3. 逐平台 7 节框架：每个平台独立展示拍前速查 / 速取区 / A·B·C 三版标题 / 分段脚本 / 视觉节奏指令 / 发布标签 / 评论区顾虑应答，方便逐平台校对改稿
4. 调味品专属：6 大品类适配、B2B 餐饮采购话术自动切换、调味品功效声称专项过滤（古法/零添加/天然酿造等无认证词自动替换）
5. 双层合规 + 自然度自检：广告法极限词 / 平台违禁词 / 调味品 8 条品类红线 / 7 项自然度全部走完，产物末尾以人话告知

免责声明： AI 生成内容仅供参考，发布前请商家自行复核合规与产品真实性；本 Skill 不提供人工合规审查、品牌专属深度学习与多轮迭代优化（多轮能力由企业版 enterprise 提供）。

二、必填信息

三、收集规则

1. 必填齐全直接请求：7 个字段（含选填 brand）齐全时直接调用服务端生成，无需追问
2. 缺失一次性追问：任一字段缺失或模糊时，在同一轮中列出全部缺失项，一次性请用户补齐；最多追问 1 轮
3. 追问后仍不给按兜底继续生成：1 轮追问后用户仍未补齐，按兜底值继续生成，并在产物末尾以人话告知「本次跳过了 N 个字段，按兜底值生成 + 兜底明细」
4. 非法值立即报错不静默替换：枚举字段值不在可选值列表内，立即报错 invalid_<字段>:<值>，绝不静默替换为兜底

四、工作流

步骤 1 · 信息收集

按 §二 表格一次性收齐 7 个字段，特别注意 platform_list 为多选、word_count 为按平台动态。逐字段校验合法性与必填性。

步骤 2 · 自动推断

根据所选平台自动推断每个平台的内容形态（抖音 5 段式短视频、小红书短图文、公众号长图文、视频号短视频、电商平台导购文案、微博短帖、快手短视频、知乎长问答、朋友圈短文案），并按 word_count 套用对应的字数档位。

步骤 3 · 调用服务端生成

按 SKILL.md 的调用契约（见 §五）把字段提交给服务端，等待服务端并行返回 N 套 7 节内容。

步骤 4 · 形态输出

按 platform_list 顺序组装产物：

• §总览 速取区：按平台顺序铺平每个平台的「最优标题 + 内容全文」，末尾铺平各平台的发布标签 + 4 类顾虑应答
• §详细 逐平台框架：按平台顺序逐个展示完整 7 节框架（一个平台全部展示完再展示下一平台）

步骤 5 · 交付与自检

在产物末尾附加告知区（不暴露技术代号 / 条数）：

• 双层合规过滤告知（人话）
• 调味品品类专属红线告知（含天然酿造 / 古法 / 零添加等替换说明）
• B2B 餐饮采购话术切换告知（✅ 已切换 / ❌ 未触发）
• 发布前自检清单（按平台动态展示）
• 自然度检验告知（人话）
• pro 版边界提示（每次生成都展示，引导企业版做多轮迭代）
• 兜底告知（仅在走兜底 / 自定义字数修正时出现）

步骤 6 · 旁路上报

将本次请求的字段、is_fallback 状态、被兜底字段列表、platform_list（数组）、word_count_map（对象）、is_speed_mode 极速模式标记、buyer_user_split 购买者分离标记等 meta 信息按服务端约定旁路上报，用于后续统计与质量追踪。

五、调用服务端生成

接口

POST https://api.ahaai.net/api/skillpay/food-condiment--pro

本 Skill 是按次付费的。服务端采用 X402 支付协议：首次请求返回 402 并给出支付凭证，完成支付后带凭证重试即可拿到内容。

必做前置检查：看你的宿主环境是否支持微信支付工程化支付（表现为工具列表中存在 mcp__weixinpay__* 系列工具）。只以你的工具列表为证据。不支持 → 终止流程且不要发起下单，提示用户升级智能体或安装微信支付 AI 支付插件后重试。

请求头：Content-Type: application/json

请求体字段

调用流程（四步，必须按此顺序；3b 是可选分支，正常支付不涉及）

第 1 步 · 首请求 —— 拿到支付凭证（期望 HTTP 402）

curl -sS -i -X POST "https://api.ahaai.net/api/skillpay/food-condiment--pro" 
  -H "Content-Type: application/json" 
  -d '{"platform_list": ["抖音", "视频号"], "category": "酱油", "product": "", "purpose": "带货", "selling_point": "", "word_count": {"抖音": "300", "视频号": "600"}, "brand": "无"}'

响应 HTTP 402，关键信息在响应头：

WeixinPay-Required: <payment_code>     # 支付凭证码（一次性）
X-Out-Trade-No: <out_trade_no>         # 商户订单号（幂等键）

双投递：这两个值除了响应头，响应体顶层也各有一份 —— 服务端对 402 头/体同时投递，因为部分智能体的工具链只读响应体、会丢弃响应头。优先用响应头；读不到时从响应体顶层取，两者逐字节一致。

响应体：

{
  "msg": "PAYMENT_REQUIRED",
  "code": 402,
  "WeixinPay-Required": "<payment_code>",
  "X-Out-Trade-No": "<out_trade_no>",
  "data": {
    "content": null,
    "meta": { "amount": "1.28", "currency": "CNY", "detail": "请完成微信支付后重试" }
  }
}

data.meta 里另有 out_trade_no / code_url（原生收款码串）。

payment_code 已编码全部所需信息，正常流程用不到它们。

第 2 步 · 保存这两个值（payment_code 与 out_trade_no）——第 4 步要用。同一笔订单全程复用同一对值；重新发起第 1 步就是新订单，会重复扣费。

第 3 步 · 发起支付 —— 调用微信 AI 支付工具

把第 2 步保存的 WeixinPay-Required 值作为 paymentCode 参数，调用你的微信支付工具（工具名以你的工具列表为准，如 weixinpay_pay）：

// 工具调用示意（具体参数以工具定义为准；paymentCode 内已编码全部信息，通常无需手填其它参数）
{
  "tool": "weixinpay_pay",
  "args": { "paymentCode": "<第 2 步拿到的 WeixinPay-Required 值>" }
}

支付工具返回成功 → 进入第 4 步；返回失败 → 如实告知用户「支付未完成」并停止（不要伪造内容、不要用旧 Header 重试）。

第 4 步 · 支付成功后重试 —— 带上两个 Header 原样重发

curl -sS -X POST "https://api.ahaai.net/api/skillpay/food-condiment--pro" 
  -H "Content-Type: application/json" 
  -H "X-Out-Trade-No: <第 1 步拿到的 out_trade_no>" 
  -H "WeixinPay-Required: <第 1 步拿到的 payment_code>" 
  -d '{"platform_list": ["抖音", "视频号"], "category": "酱油", "product": "", "purpose": "带货", "selling_point": "", "word_count": {"抖音": "300", "视频号": "600"}, "brand": "无"}'

服务端会向微信查单验真（不是相信客户端已付款），确认成功后返回 HTTP 200：

{
  "msg": "ok",
  "code": 200,
  "data": {
    "content": "…多平台总览索引（**不是**产物本体）…",
    "files": [
      {"platform": "抖音", "filename": "单品-抖音.md", "content": "…该平台完整 Markdown…"},
      {"platform": "小红书", "filename": "单品-小红书.md", "content": "…"}
    ],
    "platforms": ["抖音", "小红书"]
  },
  "meta": {
    "out_trade_no": "…", "idempotent": false, "server_elapsed_ms": 1234,
    "platform_count": 2, "is_partial": false
  }
}

多平台产物（本 Skill 特有）

platform 是多选字段，服务端会为每个平台各生成一份独立的 Markdown：

交付方式（必须照做）：

1. 把 data.files 里每一项的 content 分别写入一个 .md 文件，

文件名用该项的 filename；不要把多个平台拼成一份大文件。

1. 每个文件写完后用 present_files 展示给用户（或按用户要求的目录落盘）。
2. 若 meta.is_partial=true：如实告知哪些平台没生成成功，并说明

「可用同一组支付 Header 原样重试补齐，不会重复扣费」。

agent 必须遵守

1. 必须把 402 响应头里的两个值原样带回重试：

X-Out-Trade-No（商户订单号，同时是幂等键）+ WeixinPay-Required（支付凭证码）。同一次调用必须复用同一个 out_trade_no —— 换了就是新订单、会重复扣费。

1. 只有收到 402 时才能引导用户支付；HTTP 200 表示已履约，直接交付产物。
2. data.files 是最终产物（每平台一份 Markdown）：逐个写入文件并交付给用户，不要把多个平台拼成一份大文件；data.content 只是总览索引。
3. 若重试仍返回 402，说明尚未支付成功：如实告知用户「支付未完成」，

不要编造内容、不要改 Header 重试。

1. 入参合法性只在"支付之后"才校验：首请求不会因为入参非法返回 400 ——

它一律先建单并返回 402。400（msg 形如 invalid_platform:B站）只会出现在重试阶段，那时已经扣款，且服务端不会自动退款（订单保持已支付）。⇒ 如实告知用户「本次已扣款、入参不合法」，并用同一组 Header 修正入参后重试（同一 out_trade_no 会继续履约，不会重复扣费；不要重新下单）。用户确实要用服务端不支持的取值时，只能人工退款 —— 告知用户联系客服。

1. meta.idempotent=true 表示这是重放（服务端返回了已履约的缓存），不重复收费，

可正常交付。注意 meta 在响应体顶层，不在 data 里面。

1. 支付环节的任何异常都要如实告知用户，不要把失败描述成成功。
2. 支付按第 3 步走：把 WeixinPay-Required 作为 paymentCode 调用你的微信支付工具

（工具名以你的工具列表为准）；不要在正常支付路径调用 weixinpay_retry_pay—— 它只用于「用户取消后重付同一笔订单」，且必须先问用户确认。特别地：不要向用户展示 WeixinPay-Required 的原始值、不要轮询或臆测支付状态。⚠️ 更重要的是：任何情况下都不要重新执行第 1 步 —— 它每次都会新建一张订单，与本单无关，会重复扣费并让订单表堆满未支付的 INIT 记录（线上真实发生过一次会话堆数十条）。

异常分支（涉及钱，不要弄错）

六、通用原则

1. 多平台产物结构：服务端必须为 platform_list 每个平台并行生成 7 节内容；客户端按「速取区铺平 + 逐平台框架」结构输出，一个平台所有内容展示完再展示下一平台
2. AI 选用 A/B/C 标题：从 A 场景需求触发型 / B 感官反常识型 / C 痛点场景型 3 个候选中选最适合「当前平台 + 创作目的 + 字数」的 1 个放入速取区，3 个完整版本在第 3 节公开给商家做 A/B 测试
3. 抖音 5 段式情绪曲线：开头抓人（0-5s）→ 讲场景（5-15s）→ 说产品（15-50s）→ 让人想吃（50-65s）→ 引导下单（65-75s），前 3 秒必带动作钩子
4. B2B 餐饮采购自动切换：当 purpose = B2B 餐饮采购 时自动切换专业术语（出餐率 / 风味稳定性 / SKU 适配），并在产物末尾以 ✅ / ❌ 告知商家
5. 调味品 8 条品类红线：天然酿造 / 古法 / 零添加 / 增强食欲等无认证依据词自动替换为「传统工艺 / 精选原料 / 提鲜增香」等可证实表述，发布前请商家自行确认是否有认证依据
6. 不暴露技术代号与条数：自检项以人话告知商家「已过滤 / 已校准」，不出现 Kernel 48 条 / 行业 8 条 / 自然度 7 项等具体数字
7. 单品闭环：商家填的 product 单品名必须在标题 / 开头 / 感官段至少出现 2 次，保单品保真度

七、参考文档索引

八、免责说明

本 Skill 由 pro 版（v1.0）提供，一次性输出多平台内容，如需在本文基础上微调（如换更软的、加个卖点），请重新开一轮修改字段；如需 AI 基于上稿逐句优化（多轮迭代 / 反常识库 / 数据复盘 / 团队协作）请使用企业版 enterprise。AI 生成内容仅供参考，发布前请商家自行复核合规、广告法极限词、平台违禁词、产品真实性与认证依据；本 Skill 不提供人工合规审查、品牌专属深度学习与功效化深度审核。