社媒运营调研报告（付费版）【零一数科·出品】 v0.7.0

采集抖音 / 微信视频号社媒素材，采集完成后与用户对齐「想分析什么、输出什么」，再交给服务端 一条龙生成 Markdown 调研报告。服务端内部自做「现造分析框架 → 生成报告」（用其自有 LLM key）， skill 侧只需 LY_API_KEY 一个 key，不调用任何外部 LLM 网关、不做报告结构确认。

版本：v0.6.0 · 作者：小风、Awen、CoderPig

执行流程

按以下顺序执行，每一步对应后面章节的细节：

1. 取 Key：读技能目录 config.json 的 LY_API_KEY（采集 + 报告生成共用）。缺失按「鉴权」引导。
2. 收集入参：与用户沟通收集品牌/卖点/背景（选填）+ 采集源（平台/账号/关键词/每源条数）+ 调研 目的（粗略即可，采集后还会细化）。按「入参收集」分两轮问，不全补全。缺失用「引导话术」追问。
3. 扣点确认：首次（新任务）create 前，向用户说明本次预计采集规模与扣点，征得同意再跑脚本； 用户未确认不跑。恢复超时任务不重复扣点，跳过此步。详见「扣点与确认」。
4. 创建采集任务（deferred）：把采集源组装成 --platforms-json，跑 create_task.py（不带 --user-prompt），得到 task_id，脚本内联轮询到 awaiting_prompt（采集完成）。
5. 采集后对齐分析方向：采集完成后告知用户规模；与用户探讨/润色本次要分析什么、输出什么， 把它写成一段清晰的「调研诉求」（即后续 resume 的 user_prompt）。详见「采集后对齐」。
6. 生成报告：跑 resume_task.py --user-prompt-file <诉求文件>，服务端一条龙生成报告， 脚本内联轮询到 completed，content 直返 Markdown。落地为 <主题>运营调研报告_<日期>.md 交付。

备选：若用户一开始就把调研诉求说得足够清楚、不想采集后再聊，可直接用 custom 一次性模式： create 带 --user-prompt-file，服务端采集→生成一把梭到 completed，跳过 awaiting_prompt/讨论。 但默认走 deferred（保留采集后细化诉求的灵活性）。

若是恢复已超时的任务（poll/resume 退出码 13），用对应脚本带 --task-id 续等即可，无需重新 创建与采集；已采集的任务仍在 awaiting_prompt，直接从第 5 步继续。

任一步异常按「退出码处理」表对号入座，不要自行判定失败。

进度同步：不要让用户觉得卡死（⚠️ 必读）

本任务是长耗时（通常半小时以上、甚至更久）的阻塞链路：找视频 → 读视频原始内容 → 整理 → 分析 → 生成报告。如果采集/生成期间一直不出声，用户会以为卡死了。全程必须主动、定期同步进度。

两条轮询路线，按场景选用

1. 阻塞轮询（默认）：直接跑 create_task.py / resume_task.py，它们内联轮询到分叉点/终态。

   • 进度走 stderr：stage 变化打一行；同一 stage 停留超过 30s 打心跳（⏳ 仍在 stage=X 已运行 N s）， 避免长阶段静默。stderr 内容要周期性转译给人话同步给用户。
   • 适合"一步到位、等它跑完"的场景。

2. 单次查询 poll_task.py --once（推荐用于主动同步）：只 GET 一次，把状态以机器可读 KV 吐到 stdout 后立即退出、不阻塞。输出形如：

   TASK_ID=<id>
   STAGE=<capturing|analyzing|awaiting_prompt|completed|failed|...>
   NEXT_ACTION=<poll|resume|retry|done|...>
   STATUS=<底层状态>
   WARNING=<非阻断警告，可能为空>
   ERROR=<失败原因，可能为空>
   CONTENT_EMPTY=<true|false>          # 仅 completed 时有意义
   POINTS_USED=<本次扣点，可能为空>
   === RESEARCH_REPORT_START === ... === RESEARCH_REPORT_END ===  # 仅 completed 且非空
   <task_id>
   

   • 适合"周期性主动查、在查询间隙给用户回话"。控制权在 skill 手里：查一次 → 翻译成进度回一句 → 等一会儿再查，而不是干等阻塞脚本跑完。

推荐节奏（采集 + 生成全程）

• 任务已 create/resume、进入阻塞等待后：每隔约 60–90s，用 poll_task.py --once --task-id <id> 查 一次当前 STAGE，并把 stage 翻译成人话同步给用户： | STAGE | 对用户说 | |---|---| | capturing | "正在各平台抓视频 + 读取视频原始内容，这步最久，已采集一段时间，继续中…" | | analyzing | "素材已采集完，服务端正在分析 + 生成报告，通常几分钟…" | | awaiting_prompt | "采集完成，等你定一下分析方向，定了我就让服务端出报告。" | | completed | "报告生成完成，正在保存…" | | failed | "任务失败了，我来帮你看看能不能继续…"（按「异常→继续决策」处理）|
• 查询间隙也别让用户干等：把"预计还要多久""你可以先忙别的"这类话带上。
• 出现 WARNING 字段非空时，主动转告（非阻断，但要透明）；出现 ERROR 非空按异常决策处理。
• 绝对不要长时间不出声：哪怕 stage 没变，也要定期说一句"还在 X 阶段、正常运行中"。

不阻塞场景（更稳的驾驶方式）

如果你的运行环境不方便干等阻塞脚本，可全程改用 --once：

1. 先 create_task.py --no-poll（只创建、不内联轮询）拿 task_id；
2. 之后全程用 poll_task.py --once 周期性查状态，按 NEXT_ACTION 决定下一步： poll→继续等 / resume→进入「采集后对齐」给诉求 / retry→询问是否重试 / done→取 content 交付。 这样全程都是非阻塞、可主动同步进度，用户感受最好。

鉴权

只需一个 key，放技能目录（SKILL.md 所在目录）config.json：

{
  "LY_API_KEY": ""   // 01Claw 鉴权：采集 + 报告生成共用；服务端内部用它调自有 LLM 出报告
}

⚠️ 分发包里 config.json 的 LY_API_KEY 必须留空（切勿硬编码任何 key）；用户首次使用时自行填入， 或通过环境变量 LY_API_KEY / OPENCLAW_RELAY_API_KEY 注入。脚本读取顺序：config.json → 环境变量。 通信全程走 HTTPS 默认证书校验（脚本不关 SSL）。

- **LY_API_KEY**：01Claw 账号鉴权 key，采集与报告生成共用。从
  <https://claw.lingyishuke.com/webapps/01claw-auth/index.html?source=workbuddy> 登录/注册 01Claw
  账号获取。请求头 `Authorization: <api_key>`（兼容 Bearer 前缀）。脚本回退环境变量
  `OPENCLAW_RELAY_API_KEY` / `LY_API_KEY`。
- ⚠️ skill **不调用任何外部 LLM 网关**（曾误用 zeroone01/OpenRouter 网关，那是独立鉴权体系、
  不认 LY_API_KEY，已移除）。所有 LLM 工作都在服务端完成。

**任何时候都不要编造或猜测 key。** 取 key 流程：

1. 检查 `config.json` 的 `LY_API_KEY` 是否非空；缺则提示用户补，并列出获取方式。
2. 用户给 key 后写入 `config.json`（保留其他字段），再继续。
3. 鉴权失败（401）说明 key 失效/过期，引导用户重新获取并覆盖。

### 缺少 API Key 的话术

> 做这次报告要调用 01Claw 服务（采集 + 生成报告都走它，服务端自带大模型）。
> 👉 打开 <https://claw.lingyishuke.com/webapps/01claw-auth/index.html?source=workbuddy>
> 登录/注册 01Claw 账号获取 key，发给我（一串字符即可），我帮你存好。服务按次计费，
> 余额不足我会提醒你充值。

## 入参收集

分两轮问，话术亲和，不抛技术字段名（brand/platforms/deferred 等不出现）。详见 references/usage-notes.md。

> 🚫 **采集硬门槛（缺了绝不开跑）**：要发起任务，**至少给一个平台**（抖音 / 视频号），且**该平台至少提供
> 账号 或 关键词之一**（账号→抓该账号下的视频；关键词→抓与热门关键词相关的视频）。这是采集能跑起来的
> 前提，缺则**不发 create、不扣点，必须先补全**。脚本侧 `normalize_platforms` 会拦截并退出码 3；
> 服务端即使收到也会返 `400 At least one account or keyword is required`。**别让用户以为能跳过。**

### 第一轮：业务信息 + 调研目的（粗略）

> 帮你做社媒运营调研报告。先对齐几样：
> 1. **品牌/产品名**是？（含规格更好，如 `<品牌名> <规格>`）
> 2. **这次调研想搞清楚什么**？比如"行业怎么卖""竞品怎么打""某卖点怎么合规表达"——目的越准报告越贴业务。
> 卖点、公司背景、目标人群有就给，没有我也能做，但给了更准。采集完我们还会再对齐一次分析方向。

### 第二轮：采集源

> 接下来定采集范围：
> 1. **采哪个平台**？抖音 / 视频号（可都采）。
> 2. **对标账号或搜索关键词**给一些，至少一个平台给一个。关键词可分平台配，避免通用短词两边都抓
>    （噪音大、重复扣点）。
> 3. 每个账号/关键词采几条？默认 5 条，想深采样可调高（1–20），越多越慢越耗点。

整合成用户入参 JSON（结构见 references/usage-notes.md），写到工作目录 `social-research-input.json`；
同时把采集源组装成 `--platforms-json`（对象形态，分平台配额）。

## 扣点与确认（⚠️ 高成本任务，必须前置确认）

本技能是**高成本任务**——它不是简单调一次接口，而是要「去各社媒平台找视频 → 读取每条视频原始内容 → 整理视频素材 → 分析视频素材 → 生成报告」一整条重链路。**视频数量越多，点数消耗越大。** 一个完整任务（采集 + 分析 + 生成报告）**通常要 1000 点甚至更多**，视需查看的视频数量而定。

因此**开跑前必须让用户明确知情并确认**，绝不默认开始。

### 开始采集任务前（create 前）·必确认

跑 `create_task.py` 前，先向用户说明**成本量级 + 耗时**并征得同意：

> ⚠️ 提醒，开跑前两个事情请先知晓：
>
> 1. **耗时长**：整个任务要"找视频 → 读取每条视频原始内容 → 整理 → 分析 → 生成报告"一条龙，
>    **整个过程通常要半小时以上**（视频越多越久，可能更久）。期间我会同步进度，你可以先忙别的。
> 2. **耗点多**：这是个**高成本任务，1000 点起步、甚至更多**；耗点多少取决于要查看的视频数量，
>    **要看越多、耗点越多**。
>
> 本次计划采集 douyin / wx_video 共 N 个账号 + M 个关键词 × 每源 X 条 ≈ 总探看 Y 条视频。
> 看得越多报告越全、但耗点也越多、时间也越久。**确认要开始吗？**（确认后我开始采集；想缩小范围先告诉我）

- 用户明确说"开始/确认/可以"才跑 create；**未确认不跑**。
- 用户嫌贵/要缩范围 → 帮他**减少关键词数或每源条数**后重新估，再次确认。
- 给一个"省钱档"建议：若用户预算敏感，提示"每源 1–2 条、关键词精简到核心 5–8 个，能把成本压到最低"。

### 生成报告前（resume 前）·轻提示

resume 阶段采集已扣点，生成报告是同一任务延续，**不再重复要确认**，但要一句话告知：

> 采集已完成，现在开始生成报告（服务端会基于已采集素材 + 你的调研诉求一条龙出报告，通常几分钟）。这一步用的是已采集的数据，不再额外大规模探看视频。

> 恢复已有任务（带 `--task-id` 续等）只续轮询，不重复扣点、不需再次确认。

## 采集后对齐

采集完成（`awaiting_prompt`）后，服务端**不会**自动出报告，它在等你给出"分析什么/输出什么"的
调研诉求（即 resume 的 `user_prompt`）。这一步是你的核心增值——把用户模糊的需求转成清晰、可执行的诉求：

1. **转告采集概况**："采集完成，douyin/wx_video 共抓到约 N 条内容。"
2. **对齐分析方向**：复述用户第一轮说的调研目的，问要不要补充/细化。给选择而非开放式反问：
   - 重点放哪：选题机会 / 竞品对标 / 账号诊断 / 合规话术 / 人群脚手架
   - 输出什么：调研报告 / 话术库 / 对照表 / 行动建议
   - 给谁看、参考用还是决策用
3. **写成调研诉求**：把对齐结果写成一段清晰的中文诉求，作为 resume 的 user_prompt。要点：
   - 一句话说清调研真问题 + 交付物与受众
   - 点明重点方向与约束（如合规红线）
   - 要求中文 Markdown、可执行建议、基于真实素材不编造
4. **保存诉求文件**：写到 `<工作目录>/research-goal-<task_id>.md`，供 resume 用 `--user-prompt-file`。

> 诉求示例（占位，按实际替换 `<...>`）：
> "基于本次采集的 `<平台>` `<行业/品类>` 素材，调研：① `<调研问题1，如行业怎么卖/竞品怎么打>`；
> ② `<调研问题2，如某卖点怎么合规表达/某场景怎么落地>`。输出中文 Markdown 调研报告：
> 含调研数据基础、`<按需的章节方向>`、可执行运营建议。只引用采集到的真实素材，不得编造；
> 素材不足处标注覆盖度。不要输出 [[media:...]] 占位符与数据库内部 ID。"

> 这是"探讨诉求"而非"确认报告章节结构"——服务端会基于这段诉求 + 素材自己现造分析框架并出报告，
> skill 不做结构确认。诉求写得越清晰，报告越准。

## 运行方式

在 skill 目录下运行。脚本纯标准库，无需装依赖。

### 阶段1：创建采集任务（deferred，默认）

```bash
python3 scripts/create_task.py \
  --brand "<品牌名>" \
  --selling-points "<产品卖点…>" \
  --background-context "<公司/项目背景 + 目标人群…>" \
  --platforms-json '{"douyin":{"keywords":["<关键词1>","<关键词2>"],"keywords_content_limit":5},
                     "wx_video":{"keywords":["<关键词3>","<关键词4>"]}}'

• 不带 --user-prompt 即 deferred：采集完成后停在 awaiting_prompt，stdout 最后一行是 task_id。
• --platforms-json 必须是 JSON 对象（嵌套形态），key ∈ {douyin, wx_video}，每平台支持 accounts / keywords / accounts_content_limit / keywords_content_limit。
• ⚠️ 不要用扁平 accounts/keywords 数组，也不要显式传 prompt_mode，服务端会 422 拒。

阶段2：采集后对齐 → 写诉求文件

见「采集后对齐」。产物：research-goal-<task_id>.md。

阶段3：生成报告

python3 scripts/resume_task.py \
  --task-id <task_id> \
  --user-prompt-file research-goal-<task_id>.md

• 推诉求给服务端，内联轮询 capturing→analyzing→completed，content 直返 Markdown （用 === RESEARCH_REPORT_START/END === 包裹）。
• 想单独续等用 poll_task.py --task-id <id>；失败重试用 retry_task.py --task-id <id>。

输出交付（成功后：告知扣点 + 报告查看方式，且必须真的落地 md）

resume_task.py（deferred 路径）或 create_task.py --user-prompt*（custom 路径）成功完成时， stdout 会给出 content（报告正文）。交付时务必确认拿到的是真实 Markdown，而不是空壳。

① 取报告正文：必须非空才算完成

脚本完成时 stdout 形如（poll/resume/custom 均同）：

POINTS_USED=<本次实际扣点，可能为空>
=== RESEARCH_REPORT_START ===
<完整 Markdown 报告>
=== RESEARCH_REPORT_END ===
<task_id>

从两分隔符之间截取 Markdown。先判空——

• content 非空（≥800 字、以 # 开头的 Markdown 标题结构）→ 真·完成，进入 ②落地 + ③告知。
• content 为空 / 极短 / 不是 Markdown（如纯 JSON、纯报错、占位符） → 这叫"没真正生成"， 绝不能假装交付。处理见下方「未真正渲染为 md 的处置」。

② 真正落地为 md 文件（杜绝"没渲染为 md"）

报告必须写入磁盘为 .md 文件：

• 路径：<工作目录>/<主题>运营调研报告_<YYYYMMDD>.md（主题用 brand 提炼，去特殊字符）。
• 写盘后立即回读校验：Read 一次刚才写入的文件，确认行数/首行标题正常。若写盘失败或回读异常， 重写一次；仍失败则把报告正文直接渲染在对话里、并明示"文件写盘失败，报告内容见本条对话"。
• 文件名纯中文/符号可能因 shell 转义出问题：写入时用 Python/Write 工具直接写文件，不要用 shell echo > 拼接长 markdown（这是"没渲染成 md"的常见根因——shell 转义把内容截断或转义坏了）。

③ 告知用户：实际扣点 + 报告查看方式

报告落地后，向用户明确两件事：

✅ 报告已生成！

本次扣点：这是一个高成本任务（找视频→读视频原始内容→整理→分析→生成报告），整条链路约消耗 {点数} 点（≈本次探看 {N} 条视频所致；视频越多耗点越多）。具体可在 01Claw 账户后台点数明细查看。

查看报告：① 报告已保存为 Markdown 文件 → <绝对路径>，可直接打开；② 内容也已渲染在上方对话中。

• {点数}：脚本 stdout 会先打一行 POINTS_USED=<值>（服务端若返回扣点字段即真实值）。
  • POINTS_USED 非空 → 直接用这个真实值告知："本次实际扣除 {值} 点"。
  • POINTS_USED 为空 → 服务端没回扣点字段，按本次规模如实估算并表述为"约" （本次采集源数 × 每源条数 × 单条视频探看成本 + 生成成本；单条探看成本随视频时长/内容量浮动， 整体量级 1000 点起的任务），措辞用"约消耗 X 点"，不编造精确数字，让用户去 01Claw 账户后台核对。
• 高成本任务务必让用户能去账户后台点数明细核对实际消费。
• 同时把报告开篇的执行摘要/数据基础章转述一句，让用户快速判断价值。

④ 交付后引导

问是否就某章节深挖、调整采集范围重跑、或换调研诉求再生成（可复用同一 task 的采集， 重新 resume 不同诉求即可出新报告，无需重采、不重复扣采集的点）。

未真正渲染为 md 的处置（兜底，务必执行）

当 ① 判出 content 为空/非 md 时，不要硬凑交付，按序处理：

1. 先看 stage：若 stage≠completed（任务其实没成功完成），按「退出码处理」走失败路径，不交付。
2. 若 stage=completed 但 content 为空（报告落库延迟，偶发）：告知用户"报告已生成但正文拉取有延迟"， 用 poll_task.py --task-id <id> 再轮询 1–2 次取 content；取到非空 md 后再走 ②③。
3. 若反复轮询仍为空（几分钟内）：如实告知"这次报告正文没拉取成功，可能是服务端落库异常或素材过少 导致服务端未产出正文"，给出 task_id 便于排查，问用户是否重试。绝不把空内容/JSON/报错 塞进一个 .md 文件假装交付。

退出码处理

四个脚本（create/poll/resume/retry）共用同一套退出码：

| 码 | 含义 | 处理 | | --- | --- | --- | | 0 | 成功/到分叉点 | create 到 awaiting_prompt / resume 到 completed 按「输出交付」处理 | | 2 | 缺 key | 引导去 auth 链接取 key、写入 config.json 的 LY_API_KEY | | 3 | 参数非法（含 400/422） | 多为必填没补全、超限，或 platforms 用了扁平 schema / 误带 prompt_mode。讲清原因补完再采。任务未发起，不扣点 | | 4 | 余额不足（402） | 引导充值，任务未提交、不扣点 | | 8 | 鉴权失败（401） | key 失效，换新 key | | 10 | 其他 4xx | 透出服务端 message；404=任务找不着，409=状态不对（流程走岔，先 poll 看现状） | | 11 | 5xx/网络 | 服务端抖动或网络问题；告知"因网络原因任务执行失败，已扣点数已返还"，稍后可重试 | | 12 | 任务失败 | 采集或生成报告失败；告知用户"因网络原因本次任务执行失败，相应点数已返还"，问要不要 retry | | 13 | 轮询超时 | 非失败；告知"还在跑"，用对应脚本带 --task-id 续等；若用户放弃，告知"已发起的任务如未完成会返还点数" |

一句话（失败必告知点数返还）：凡任务已发起但未成功出报告（退出码 11/12，以及放弃等待的 13）， 统一告知用户「因网络原因本次任务执行失败，相应点数已返还」，并询问是否重试；任务根本没发起 的（2/3/4/8）不涉及点数、无需说返还。⚠️ 这是高成本任务，失败时点数返还的话术一定要讲， 让用户安心 + 可去账户后台核对点数明细。

未知状态不要自行判定失败；脚本会原样透出 error_message/progress_message，按脚本退出码处理。

异常→继续决策：很多异常任务没死，引导用户往下走

遇到非 0 退出码或异常状态，先 poll_task.py --once --task-id <id> 查真实 stage/next_action， 再按下表决策——很多情况下任务还活着，API 提供了明确的"继续"路径，不必让用户从头重来。

| 状况 | 真实状态判断 | 能否继续 / 怎么继续 | 对用户怎么说 + 引导 | |---|---|---|---| | 轮询超时（退出码 13） | 多为 next_action=poll（任务仍跑） | ✅ 能：再轮询一次即可 | "任务还在跑、没失败。要继续等（我再查）/ 你先忙、回来用 task_id 续 / 放弃都说一声。" 别让人以为失败 | | 任务 failed（退出码 12） | next_action=retry | ✅ 能：retry_task.py --task-id <id> 复用已采集数据、只重跑分析，不重新抓视频、不重复扣采集点 | "失败了但点数已返还。要 retry 重试吗？（复用已采集、更省）/ 或换个分析方向 resume 重生成 / 或放弃。" | | awaiting_prompt 卡住 | next_action=resume | ✅ 能：给调研诉求 → resume_task.py | "采集已完成，不是卡死——就等你定分析方向。告诉我你想分析什么，我直接出报告。" | | completed 但 content 空 | STAGE=completed 且 CONTENT_EMPTY=true | ✅ 能：报告落库延迟，再 --once 取 1–2 次 | "报告已生成、正文落库有延迟，我再查一次拿正文。"（别当失败） | | 409 状态不符 | 先 --once 看真实 stage | ✅ 能：按 next_action 选对的接口（resume 还是 retry） | "流程顺序走岔了，我先看下任务真实状态，再用对应的方式继续（不必重采）。" | | 5xx / 网络异常（退出码 11） | 先 --once 查任务是否存活 | 看情况：存活就续等、死了才重试 | "刚网络抖了一下，我查下任务还在不在——还在就接着等，不在再帮你重发。" | | 401 鉴权失败（退出码 8） | key 失效 | ⚠️ 需换 key | "鉴权 key 失效了，重新取一个发我，我存好就能继续（任务不会丢）。" | | 402 余额不足（退出码 4） | 未扣费、任务未发 | ⚠️ 需充值 | "点数不够，先充值；充完我重发即可，之前没扣点。" | | 404 任务不存在（退出码 10） | task_id 失效 | ❌ 无法继续 | "这个任务找不到了（可能已清理或 task_id 不对），需要重新创建一个。" |

三条恢复路径（API 明确支持，优先用，别让用户白重来）：

1. poll（超时/等待）→ 继续轮询，任务没死。
2. retry（failed）→ 复用已采集数据重跑分析，不重新抓视频、不重复扣采集点。
3. resume（awaiting_prompt）→ 补调研诉求即出报告，采集成果不丢。

一句话原则：异常先 --once 查真实状态，按 next_action 找继续路径；只有任务真死了或 key/余额问题才 需要重来。 采集是一次性成本大头，能复用就别重采。

引导话术

未提供输入

报告技能已就绪 ✅ 我能帮你采集抖音/视频号社媒素材，对齐你想分析的方向后，让服务端生成一份调研报告。

随时可以开始，把下面几样发给我即可：

1. 品牌/产品名（含规格更好）
2. 调研目的——想搞清楚什么（行业怎么卖 / 竞品怎么打 / 怎么合规表达…）
3. 采哪个平台、对标账号或关键词——抖音 / 视频号，至少一个平台给一个来源

卖点、背景、目标人群有就给，没有我也能采，给了报告更准。

缺采集源（平台/账号/关键词）必填追问

用户没给平台、或给了平台但账号和关键词都空时，必须追问，不能跳过：

还缺采集源，没它我没法开跑喔——

1. 采哪个平台？抖音 / 视频号（至少一个，可都采）；
2. 对标账号 或 搜索关键词，至少给一个：
   • 想看某个具体账号的发的内容 → 给账号名（如"XX 官方旗舰店"）；
   • 想看跟某个热门词相关的视频 → 给关键词（如"通勤好物""抗老精华"）。 给到这两样我就能开采集了。

补一轮还不给 → 明确告知"平台和采集源是必填项，缺了无法发起任务（也不扣点）"，终止，不硬凑空源发请求。

采集进行中

已开始采集 ⏳ 服务端正在抖音/视频号找视频 → 读取每条视频原始内容，视频多所以比较慢—— 整个任务（采集+对齐+生成报告）通常要半小时以上，你可以先忙别的，进度有变化我会同步你。 期间也会持续消耗点数（视频越多耗点越多）。

⚠️ 失败兜底（采集/生成中途异常时用）：若任务途中因网络等原因失败，我会告诉你 「因网络原因本次任务执行失败，相应点数已返还」，不会让点数白扣，可放心。

采集完成 + 对齐方向

采集完成 ✅ 共抓到约 N 条内容。服务端不会自动出报告，它在等你说"想分析什么、输出什么"。 你之前提到想搞清楚「<复述用户第一轮给的调研目的>」。要不要补点或调整重点？ 比如偏选题机会、偏竞品对标、偏合规话术、偏人群/场景？对齐后我直接让服务端生成报告。

关键文件

• scripts/create_task.py — 创建采集任务（默认 deferred，支持 --user-prompt 走 custom）+ 轮询
• scripts/poll_task.py — 单独轮询（续等 / 拉报告）
• scripts/resume_task.py — 推调研诉求（user_prompt）生成报告 + 轮询到 completed
• scripts/retry_task.py — 重试失败任务
• references/api.md — 服务端 API 契约（状态机/字段/真实行为校正）
• references/skeleton-prompt.md — 服务端内部现造分析时遵循的骨架（仅背景参考，skill 不调用）
• references/usage-notes.md — 入参收集/校验/节奏/错误码引导