---
name: helin-analyze-livestream-commerce
description: 河林直播电商拆解（河林方法论版）。分析中文直播带货回放转写稿，以河林“憋单-卡单-踢单-促单”循环为主框架，输出基于文稿证据的五模块报告：货盘与出场台账、排品动线与逼单循环、主推品话术整理、带合规提示的可复用话术框架、操盘点评；适配视频号、抖音、小红书三个平台，用户提供直播数据时可对照验证动作效果。用户提供直播文稿、逐字稿或回放转写，并说“拆解直播”“直播拆解”“复盘这场直播”“扒一下这个直播间”“拆个对标直播间”“这个主播怎么卖的”“看看人家怎么逼单的”“分析直播话术”“analyze this livestream transcript”时使用。要据此策划下一场直播时交给直播策划类技能；没有文稿且无法转写、只要投流或付费流量诊断、只拆短视频脚本时不要使用。
---

# 直播电商文稿拆解（河林方法论版）

## 目标

从直播回放转写稿还原货盘、排品动线、憋卡踢促循环和主推品话术，回答河林拆直播的三个问题：**做了什么动作、用户在问什么、哪些动作值得借鉴**。交付专业、直接、可复用、每个判断都能回到文稿证据的五模块报告。

方法论的核心立场：拆解是为了找到起效的动作，不是给文稿贴标签。没有数据时，“起效”只能写成推断；宁可写“文稿中未体现”，也不为了报告完整而补内容。

## 开始前

1. 完整阅读以下三个文件，再开始分析：
   - `references/helin-method.md`：河林方法论，含憋卡踢促循环、节奏参照、非商品段与用户问题、三平台适配、数据对照；
   - `references/analysis-rules.md`：证据等级、长文稿流程、角色判定、语速校准、合规标注；
   - `references/report-template.md`：五模块结构。写作前再看 `references/example-report.md` 对齐语气和证据密度。
2. 确认输入：
   - 有文本文稿（粘贴、md、txt、srt/vtt 字幕）→ 直接开始；
   - 只有 docx/pdf → 先用宿主可用的文档工具转成文本；
   - 只有视频文件或回放链接 → 探测宿主是否有转写类技能（如 `helin-douyin-transcript`）或转写工具，有则先转写；没有则停止，请用户上传文稿；
   - 什么都没有 → 停止分析，请用户上传或粘贴文稿。
3. 核对背景信息，缺失项合并成**一次**简短询问；能从文稿可靠判断的注明“根据文稿推断”后直接继续：
   - 平台（视频号/抖音/小红书），决定用哪把尺子；
   - 品类、账号名称（可选）；
   - 实际直播时长（文稿无时间戳时用于校准语速）；
   - 已知主推品（可选）；
   - 是否有直播数据：数据大屏截图、在线曲线、分钟级成交或商品热卖数（可选）。
4. 时长和数据缺失不阻塞分析；只有平台无法判断且文稿线索冲突时才需要等用户回答。

## 输出模式

- **完整拆解**（默认）：五个模块全部输出。
- **快拆**：用户只要某一部分（如“只看话术”“只拆排品”“看看怎么逼单的”）时，输出全文摘要和对应模块；证据规则和合规标注照常执行，不因为快拆而降低证据要求。

## 分析工作流

### 1. 检查文稿与判定平台

- 判断是完整场次、节选还是疑似截断稿；只分析可见范围。
- 记录说话人构成（主播、助播、运营、品牌方）和时间戳情况。
- 按 `helin-method.md`「三平台适配」一节判定平台。小红书场次改用“信任转化链”拆逼单，不把缺少憋卡踢判为缺陷。

### 2. 计量与定位

对文本文稿运行脚本（macOS/Linux 用 `python3`，Windows 用 `python`）：

```
python3 scripts/transcript_ledger.py outline 文稿.md
python3 scripts/transcript_ledger.py signals 文稿.md
```

无时间戳且用户给了实际时长时，在子命令前加 `--duration-min 实际分钟数`。`outline` 给出分段目录和实测语速；`signals` 给出憋/卡/踢/促/上链等关键词命中，只作为找位置的线索。

### 3. 分块通读，建立出场台账

- 按 `analysis-rules.md` 第 3 节分块读完全文，不跳读中段。
- 识别商品（P 编号）和非商品段（N 编号）的边界与返场，写成边界文件后运行：

```
python3 scripts/transcript_ledger.py ledger 文稿.md 边界.tsv
```

- 处理台账中的“未归属段”和“重叠段”。报告中的字数、时长、出场次数和占比一律取自台账。
- 边界文件放在临时目录，不留在用户的工作区。

### 4. 判定货盘角色

按 `analysis-rules.md` 第 5 节的 A–F 六项信号做综合判断，写明理由；时长接近、首讲不可见、自定性冲突三种情况按该节处理。主推品最多两个；信号不足时标“暂定”。角色是分析判断，不要写成主播或品牌方的官方定义。

### 5. 还原排品动线与憋卡踢促循环

- 动线包含非商品段；作用一律写“推断承担……作用”，有数据对照时例外。
- 每个主推品以上链接/放单为锚点切轮次，逐轮记录憋、卡、踢、促和口播放单量，计算单轮时长，对照 5–15 分钟基准和平台推流节奏做判断。
- 只记录真实出现的环节，缺失环节写“文稿中未体现”并分析可能用意。

### 6. 整理用户问题

收集主播复述或回答过的观众问题，按主题归并，记录频次、对应商品，以及回应后是否接回逼单。观众昵称等个人信息不写入报告。

### 7. 整理话术、抽象框架、标注合规

- 模块三按真实顺序整理主推品话术，保留原意，不扩写成文稿中不存在的卖点。
- 模块四从已出现的话术结构中抽象框架，区分固定步骤和替换变量。
- 按 `analysis-rules.md` 第 10 节识别极限词、无依据比价、虚构稀缺、功效宣称等风险：模块三照实记录并标 ⚠；模块四不得沉淀这类句式，并给出合规替换写法。

### 8. 数据对照（仅在有数据时）

用户提供数据，或宿主有可用的电商数据工具且用户同意调用时，把关键动作的时间点和数据变化对齐，输出 2.5 节。只陈述时间上的相关性，并提示投流、平台推荐等其他因素。数据工具调用失败最多重试一次，仍失败就按无数据处理并在报告中说明。

### 9. 输出报告

严格按 `report-template.md` 的模块顺序输出。未知或估算的信息就地标注。

- 用户以文件形式提供文稿且宿主可写文件时：优先写入用户指定目录；未指定时，若文稿所在目录的父目录下有名称含“拆解”的子目录（如 `文稿原文/` 旁边的 `直播拆解/`），就写入那个子目录，否则写入文稿所在目录。文件名为 `{日期}_{账号}_直播拆解.md`；同名文件存在时加版本后缀，不覆盖。对话中只给全文摘要、三条最关键发现和文件路径。
- 其他情况：直接在对话中输出完整报告。

## 交付前检查

- 每个价格、机制、主推品定位和策略判断，能否回到文稿证据（引用格式统一）？
- 字数、时长、出场次数是否取自台账，语速口径是否写明？
- 是否把估算时间、推断作用、数据对照和文稿事实明确区分？
- 是否误把 ASR 纠错写成已确认事实？
- 是否覆盖全部可识别商品、返场和主要非商品段？
- 憋卡踢促循环是否只记录了真实出现的环节？小红书场次是否换用了信任转化链？
- 模块四是否已剔除或替换全部 ⚠ 句式？
- 是否只整理了最多两个主推品，是否完全排除了投流分析？
- 点评是否具体到动作、话术或排品；没有明显问题时，是否避免了硬挑毛病？

任一检查不通过时，先修正报告再交付。

版本 v2.1.0 ｜ 2026-10 ｜ 开源版（MIT）：憋卡踢促主框架、三平台适配、台账脚本、合规标注