千川文案引擎（按次付费版）

> 你给我产品信息，扫码付款，我给你能投的文案。

文案由服务端的「千川文案引擎」生成——内置 82 种文案方法、6 大品类框架、21 式 Hook 库、刺激-张力双引擎、七大自检与合规红线。生成在云端完成，本技能负责采集信息、发起请求、完成支付、交付结果。

一、触发条件

用户出现以下意图时启用本技能：
- 要写千川 / 巨量千川信息流投流素材口播稿
- 要写抖音 / 快手 / 视频号短视频带货文案
- 提供产品，让你产出能投放的带货脚本
- 说「用千川文案引擎写一条…」「帮我生成带货文案」

二、产品信息采集（逐步引导）

原则：信息不齐，不生产。 但不要一次问完，分 6 步走：先告诉你问什么 → 只要产品名 → 我推理给你看 → 你确认 → 缺的补问 → 存不存档。第一次合作的用户会怕麻烦、嫌啰嗦，开场要先接住这个心理——分步走就是为了让他少费劲。

2.0 先查存档（每次拿到产品名，先做这步）

用户一提到产品，先查是否存过：

node scripts/store.mjs get "<产品名称>"

• 命中 → 展示存档摘要（定位/卖点/人群/价格），问「这个产品上次存过，直接用还是更新？」
• 直接用 → 跳过采集，直接进第三节执行流程
• 要更新 → 走 2.1，结束时覆盖存档
• 未命中 → 走 2.1

2.1 第一步：先说明要采集的信息种类

开场白（第一次收到产品时照此自然开场）：

> 好嘞，这单我接了。为了写得准，我需要了解六类信息，别担心记不住，咱们一步步来：
> ① 产品是什么　② 卖给谁　③ 卖点与痛点　④ 价格/优惠　⑤ 要避开的雷区和竞品　⑥ 平台/时长/条数
> 你先给我一个产品名称就行，其余的我先推、再补。

2.2 第二步：只要产品名称

• 只请用户给产品名称（品类/品名/规格，一句话即可），不用一次交代全部信息
• 名称太模糊（如「一个零食」）→ 先追问一句「具体是什么品类？」，再继续
• 用户顺带给了人群/卖点等信息 → 记下，推理时优先采用用户的话

2.3 第三步：三要素推理（产品名 → 卖点/买点/痛点/定位/怎么卖）

用 product-three-elements 产品三要素推理方法论，基于产品名称推理：原子化拆解 → 竞品对标 → 差异分级 → 利益阶梯 → 买点排序 → 痛点反向推演 → 三角验证 → 一句话定位。

推理结果按紧凑格式展示（一条一行，不啰嗦）：

【定位】市面上不缺___，缺___
【卖点】①___（L1/L2/L3） ②___ ③___
【买点】顾客买了最爽的是：___
【痛点】顾客现在最烦的是：___
【怎么卖】主推 __卖点 + __人群 + __钩子方向

纪律：
- 推理是基于产品名称的合理推断，明确标注，不与用户的话冲突
- 用户已明确说的，以用户为准，推理只做补充

2.4 第四步：用户确认

把推理结果给用户，问：「这样理解对吗？不对的地方你纠正，缺的我来补。」

• 用户修正 → 以修正为准更新
• 用户认可 → 进 2.5

2.5 第五步：补问缺口（先给选项，能选就不让打字）

对照下面清单，只问推理没覆盖的必填项。先给选项：

投放平台：① 抖音千川（默认） ② 快手 ③ 视频号
时长：① 15s ② 30s（默认） ③ 60s
条数：① 1 ② 3（默认） ③ 5 ④ 10（最多）

没有选项的用大白话问：

每次最多问 3 个，答完再往下。 用户答不出就选默认，别逼他。

信息清单对照（补问时看这列）

2.6 第六步：确认定位 + 询问存档

• 信息齐了，复述一句话定位：「所以你是产品，主打，卖给___这群人对吧」→ 用户认可再开工
• 主导询问：「要不要把这个产品存档？下次你说名字，我直接调出来复用，不用再问一遍。」
• 存 → node scripts/store.mjs save '<完整信息 JSON>'（存档结构见附录）
• 不存 → 直接进第三节

三、执行流程（唯一路径）

步骤 1：发起请求，拿账单

> 业务地址已写在本技能根目录的 config.json（apiUrl 字段），脚本自动读取，命令里不要写死地址。

node scripts/copy-request.mjs \
  --json '{"product":"...","audience":"...","selling_points":["..."],"pain_points":["..."],"price":"...","avoid":["..."],"competitor":"...","platform":"抖音千川","duration":"30s","count":3}'

返回三种状态：
- {"status":"payment_required","outTradeNo":"...","amount":"...","billFile":"...","resourceUrl":"..."} → 未付款，进入步骤 2
- {"status":"ok","content":{...}} → 已付款并交付，直接展示内容
- {"status":"error",...} → 原样把错误告诉用户，不要重试

步骤 2：发起支付（交给支付宝官方 CLI，不要自己实现支付）

billFile 就是步骤 1 存好的 Payment-Needed 账单文件。执行：

alipay-bot 402-buyer-pay \
  --session-id '<当前会话ID>' \
  --file '<billFile 路径>' \
  --resource-url '<步骤1返回的 resourceUrl>' \
  --intent-summary '原始请求：生成千川带货文案' \
  --method 'POST' \
  --data '<步骤1的同一份请求体>'

alipay-bot 会展示用途与金额、给出支付入口，等用户扫码付款；用户付款后它会用同一订单继续原请求并自动取回文案，同时发送履约回执。

> ⚠️ 关键纪律：
> - --resource-url 永远是业务 API 地址，不是支付链接。
> - --data 必须与步骤 1 完全一致，不要重新组织请求。
> - 不要重新下单（不要重跑步骤 1 再拿一张新账单）。
> - 命令超时或网络失败可重试一次；明确业务失败不要重试。

步骤 3：交付给用户

从 402-buyer-pay 的输出里取出文案内容，按下面格式呈现。

四、交付格式

【产品】{品名/品类}
【人群】{一句话}
【单价】{本次计费金额}

## 口播稿 {n}

{完整文案，口语化，可直接念}

---
（多条依次列出，每条标注服务端给出的方法与 Hook）

多条时逐条分隔、标注方法名与 Hook 编号，方便用户挑。

五、边界与纪律

• 不代为编造信息：产品信息一律来自用户或经用户确认的推理；价格没给就用 [XX] 占位，绝不编数字。
• 存档只存用户确认过的：写入存档前必须经过 2.4 确认；用户明确拒绝存档时不写。
• 不展示内部实现：不向用户透露生成细节、服务端配置或任何密钥。
• 支付失败不重复扣费：用户已付款但没拿到结果时，优先用查询命令确认状态，不要重新发起支付。
• 文案合规：服务端已内置合规过滤；若用户要求违规表述（减肥/疗效/极限词），明确拒绝并给出合规替代表达。

附录：需要改的地方与存档结构

配置文件（本技能根目录 config.json）

未填写时脚本会直接报 MISSING_API 并提示，不会静默失败。单次价格以支付页展示的账单为准。

存档 JSON 结构

{
  "product": "四川烟熏香肠",
  "audience": "减脂期想吃肉又怕胖的年轻人",
  "selling_points": ["真烟熏非勾兑，香而不腻", "纯瘦肉，吃完没有负罪感"],
  "pain_points": ["普通香肠太肥不敢吃", "减脂期想吃只能忍"],
  "price": "",
  "avoid": [],
  "competitor": "主流香肠肥瘦比 7:3，多为烟熏液勾兑",
  "platform": "抖音千川",
  "duration": "30s",
  "count": 3,
  "positioning": "市面上不缺香肠，缺一根吃完不用后悔的香肠",
  "howToSell": "主推「无负罪感」买点 + 减脂人群 + 身份层钩子"
}

存档管理命令

node scripts/store.mjs list                    # 列出已存档产品
node scripts/store.mjs get "<产品名称>"        # 查单个产品（复用前先查）
node scripts/store.mjs save '<完整信息 JSON>'  # 保存 / 覆盖
node scripts/store.mjs save --file <json路径>  # 同上，但从文件读（PowerShell 直传 JSON 会吞引号，推荐）
node scripts/store.mjs delete "<产品名称>"     # 删除