| name | wjs-mining-articles |
| description | Use when the user has a video's SRT subtitle file — a 王建硕 monologue / 讲解, OR a 对谈 / 访谈 where 王建硕 is one of the speakers — and wants to mine it into multiple standalone 微信公众号 articles, one article per distinct topic. Triggers — "把这个视频写成文章", "从字幕里挖文章", "这个 SRT 能写几篇", "把对谈写成文章", "/wjs-mining-articles <srt>". |
wjs-mining-articles
一个视频的 SRT(独白或对谈)→ 一桌选题 → 用户勾几个(长对谈可「全要」)→ 每个长成一篇可发布的公众号文章,自动建好微信草稿,可选再排期发到 X。
Core Principle
口语是矿,文章是提炼出来的金属。 一段王建硕的独白里通常讲了好几个各自独立、各自值得成文的点;每个点单独成一篇,比硬塞成一篇长文更符合公众号「800–1000 字、一篇一个核心」的节奏。
字幕只是原料,成文要彻底书面化——去掉「呃、那个、就是说、然后」这类口头碎屑,把口语逻辑理成书面段落;但保留作者的用词偏好、家常比喻和语气,绝不改成营销腔或书面八股。
When This Skill Fires
- 用户给一个 SRT 路径,说「把这个视频写成文章」/「从字幕里挖文章」/「能写几篇」
- 用户跑
/wjs-mining-articles <srt-path>
支持两种源:独白/讲解(你一个人说)和对谈/访谈(你和别人对话)。两种走不同的识别路径(见 Step 1),但成文标准一致。
When NOT to use
- 没有 SRT,只有视频/音频——先用
wjs-transcribing-audio 出 SRT,再回来
- 对谈里王建硕根本没怎么说话(纯主持、对方独角戏)——挖不出他第一人称的文章,别硬写
- 已有一篇成稿要发——直接用
wjs-publishing-wechat
Workflow
Step 1 · 读 SRT,判断源类型,识别选题
脚本在本 skill 目录下,从 skill 根目录跑(或写全 ~/.claude/skills/wjs-mining-articles/scripts/parse-srt.sh):
scripts/parse-srt.sh <srt-path>
scripts/parse-srt.sh <srt-path> --raw
先判断这是独白还是对谈。 SRT 没有说话人标记,从内容判断:有一问一答、现场寒暄/调设备、「你/我」互相称呼、有人反驳——就是对谈;从头到尾一个人连续讲就是独白。文件名/目录名带别人名字(如「汤维维」)是强信号。
跳过非正片的口水段:录制前的寒暄、调麦克风、「咱们聊啥」「这是播客还是视频」,以及中途「我去个洗手间」「换点水」这类——都不是内容,识别选题时直接略过(这次那条对谈开头约 5 分钟、中间几处都是这种)。
ASR 人名几乎一定有错:逐字稿里的人名先存疑,派 agent 写之前跟用户核对(这次「黄一孟」被听成「黄一梦」)。
独白路径:读输出全文,识别出 N 个独立的、各自值得成文的话题(典型 2–6 个)。每块前的 [HH:MM:SS–HH:MM:SS] 区间拿来标选题时间段——话题跨多块时取第一块起到最后一块止。没有「几个才算独立」的死规则:看作者是否真的换了一个能独立成文的点(他常自己数「第一个/第二个」,顺着切)。
对谈路径(多两步,顺序不能省):
- 先确认谁是王建硕 ⟵ 不许猜,也不许默认主讲人/说得最多的人就是王建硕。把开头一段对话原样贴给用户,标出你推断的两个角色(谁在问、谁在答),用
AskUserQuestion 让用户确认哪一方是王建硕。用户没确认前,不进入识别选题。
- 只挖王建硕真正展开了观点的话题。对谈里的选题 = 王建硕给出了成段的、能独立成文的看法之处;对方纯提问、纯背景、纯附和的地方不算选题。读上下文判断每个点是谁说的——拿不准某句是不是王建硕说的,就标「存疑」交给用户判,绝不替他认领。
- 选题清单照常出(Step 2),但每条额外标一句「这个点里王建硕的核心主张是 X」,方便用户判断值不值得写。
Step 2 · 出选题清单,等用户勾选 ⟵ 唯一的人工闸
每个候选给三样:拟定标题 / 一句话梳理这个话题在讲什么 / 对应 SRT 时间段(如 03:12–06:40)。对谈每条再加一句「这个点里王建硕的核心主张是 X」。
清单怎么呈现,按候选数分两种:
- ≤4 篇:用
AskUserQuestion(multiSelect: true),勾选框最干净。
- >4 篇(长对谈常见,一场 1–2 小时能挖 10–16 篇):
AskUserQuestion 一题最多 4 个选项,塞不下。改用文字表格(序号 | 标题 | 核心主张 | 时间段),按「多强 + 多像王建硕招牌观点」排序、标出 ⭐ 推荐,让用户直接报序号(「1 3 4」/「先写 ⭐ 那几篇」/「全要」)。
只有选中的进入 Step 3。用户说「全要」就全写。
Step 3 · 每个选中话题写成 article.md + meta.json
写正文前载入 wangjianshuo-perspective 保证语气是本人。按 wjs-publishing-wechat 的硬约束写(那是单一事实源,这里只复述要点):
- 默认 800–1000 字,超 1200 回去再砍
- 红色加粗
**...** 2–4 处,打在点睛句/关键结论/核心概念词。一处都没有 = 没写完
- 不加 AI 连接词(首先/其次/综上所述/值得注意的是)、不加 emoji、不把口语强行八股化
- 默认不写
## 后注,正文最后落点收束
写完每篇 article.md 后,跑一遍盘古之白(中英文之间补空格,机械活、不靠自己记):
python3 ~/.claude/skills/wjs-publishing-wechat/scripts/pangu.py <folder>/article.md
对谈成文额外规则(归属红线):文章是王建硕第一人称,主体是他的观点和思考。对方(如汤维维)的话只作引子/背景——「有人问我…」「聊到 X 的时候」——绝不把对方的独到观点写成王建硕自己的主张。对方提了一个王建硕没正面回应的点,就别写进这篇。source.srt.md 里要注明本篇基于对谈、对方是谁、引用了对方哪几句作引子。
选中很多篇时(长对谈)用并行 agent 批量写:每个 agent 载入 wangjianshuo-perspective、拿到对应的逐字稿行区间和上面全部硬约束,各写 2–3 篇,落 article.md+meta.json+source.srt.md。一条 1–2 小时的对谈一次写 10+ 篇,串行太慢,并行又快又互不干扰(每篇独立)。派 agent 前先把全片通读一遍、把归属和事实更正都定下来(比如这次「黄一孟」被 ASR 听成「黄一梦」,得在派单时就写明),否则每个 agent 各猜一遍容易出错。
每篇落到一个新文件夹 <workspace>/articles/YYYY-MM-DD-{slug}/,写两个文件:
| 文件 | 内容 |
|---|
article.md | 正文 |
meta.json | { "title", "summary", "author": "王建硕", "date", "slug" } — 三个复用脚本都靠它 |
source.srt.md | 原料备份:SRT 来源路径 + 本篇对应时间段 + 抽出的原始口语片段(可追溯) |
<workspace> 默认 ~/Library/Mobile Documents/com~apple~CloudDocs/my/我的项目/我的创作/wechat-publish/,与 publishing 一致。
Step 4 · 直接建草稿(全自动)
对每个选中文件夹依次调 publishing 的现成脚本(不重写),路径 ~/.claude/skills/wjs-publishing-wechat/scripts/:
gen-cover-ai.sh <folder>
gen-illustration.sh <folder>
upload-draft.sh <folder>
交付:每篇都是「微信后台已有草稿、可一键发布」状态。群发由用户在后台手动点——本 skill 到草稿为止。
配图/建草稿是重活,长对谈十几篇要跑很久:gen-cover / gen-illustration 都走 codex 出图,每篇约 1–3 分钟。串成一个后台批处理脚本一次跑完(逐篇记成功/失败、出错不影响其他篇),别一篇篇手动等。脚本里给 gen-cover / gen-illustration 加「图已存在就跳过」,这样中途失败重跑不浪费已生成的图。
Step 5 · (可选)排期发到 X
用户要把这些文章也发成 tweet 时,交给 wjs-tweeting-from-articles:
- 发 1 条 → 它的默认流程(挑一篇、起 A/B/C 候选、用户选、
xurl 发)。
- 一次要发很多篇(长对谈挖出的十几篇)→ 它的批量排期模式:每篇抠一条 ≤120 字的 tweet 排进队列,
post-next-from-queue.sh + 每小时 cron(脚本自己节流)按「每 N 小时一条」自动发,避免一次连发被 X 判刷屏。详见该 skill。
复用边界
| 复用 | 用法 |
|---|
wjs-publishing-wechat 三个脚本 | 题图/解释图/建草稿,直接调,不重写 |
wjs-publishing-wechat 字数/加粗/无 AI 味规则 | 单一事实源,本 skill 不另立标准 |
wjs-publishing-wechat/scripts/pangu.py | 盘古之白,每篇 article.md 写完跑一遍 |
wangjianshuo-perspective | 写正文时载入,保语气 |
wjs-tweeting-from-articles | (可选)Step 5 把文章排期发到 X |
本 skill 唯一新增代码:scripts/parse-srt.sh。
Common Mistakes
- 把多个话题硬塞成一篇长文 —— 违背「一篇一个核心」。识别出几个独立话题就出几个候选,让用户挑
- 照搬口语,留着「呃/然后/就是说」 —— 字幕是原料不是成稿,必须彻底书面化
- 忘了写
meta.json —— 三个复用脚本全靠它,缺了题图和草稿都建不出来
- 忘了红色加粗 —— 一处都没有就是没写完
- 自动跑去群发 —— 本 skill 只建草稿,真正发布是用户的手动决定
- 对谈里默认「说得最多的就是王建硕」 —— 大错。必须让用户确认身份;说不定主讲人是嘉宾,王建硕才是提问的一方
- 把对方的观点写成王建硕的主张 —— 归属红线。对方的话只能作引子,拿不准是谁说的就标存疑
