wjs-mining-articles

wjs-mining-articles

動画の SRT（独白または対談）→ 記事の候補を一覧化 → ユーザーがいくつか選ぶ（長い対談なら「すべて」も可）→ それぞれを公開できる公众号記事に仕上げ、WeChat の下書きを自動作成し、必要に応じて X への投稿予約も行います。

Core Principle

口語は鉱石、記事は精錬して取り出す金属です。 王建硕の独白には通常、それぞれ独立していて、単独で記事にする価値のある話題がいくつも含まれています。それぞれを一つの記事にするほうが、無理に一つの長文に詰め込むより、公众号の「800～1000字で、一つの記事につき核心は一つ」というリズムに合っています。

字幕はあくまで素材であり、文章は徹底的に書き言葉に整えます——「えーと、その、つまり、それで」などの口語的なノイズを取り除き、口語の論理を文章の段落に整理します。ただし、作者の言葉の好み、身近なたとえ、語調は残し、決してマーケティング調や堅苦しい文語調には変えません。

When This Skill Fires

• ユーザーが SRT のパスを指定して、「この動画を記事にして」「字幕から記事を掘り起こして」「何本書ける？」と言う
• ユーザーが /wjs-mining-articles <srt-path> を実行する

素材の種類は、独白／解説（一人で話す）と対談／インタビュー（相手と会話する）の2種類に対応しています。識別方法は異なります（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    # 一行一 cue: HH:MM:SS<TAB>text(需要细看时)

まず独白か対談かを判断します。 SRT に話者のラベルはありません。内容から判断してください。一問一答、収録現場での挨拶や機材調整、「あなた／私」と互いに呼び合う、誰かが反論する、といった様子があれば対談です。最初から最後まで一人が続けて話していれば独白です。ファイル名やディレクトリ名に別の人の名前（例：「汤维维」）が含まれている場合は、有力な手がかりです。

本編以外の雑談は飛ばします：収録前の挨拶、マイクの調整、「何を話そうか」「これはポッドキャスト？それとも動画？」、途中の「トイレに行ってくる」「水を替えてくる」といった部分は、いずれも内容ではありません。記事候補を見つける際にはそのまま飛ばしてください（今回の対談では、冒頭の約5分と途中の数か所がこれに当たります）。

ASR の人名はほぼ必ず間違っています：文字起こしに出てくる人名はまず疑ってください。エージェントに書かせる前に、ユーザーに確認してください（今回は「黄一孟」が「黄一梦」と聞き取られていました）。

独白の手順：出力全体を読み、それぞれ独立して記事にする価値がある話題を N 個見つけます（通常2～6個）。各ブロックの前にある [HH:MM:SS–HH:MM:SS] の区間を、記事候補の時間範囲として使います。話題が複数のブロックにまたがる場合は、最初のブロックの開始から最後のブロックの終了までを指定します。「独立している」と判断するための固定ルールはありません：作者が本当に、単独の記事にできる別の話題へ移ったかを見てください（本人が「一つ目／二つ目」と数えることも多いので、それに沿って区切ります）。

対談の手順（手順が2つ増えます。順番を省略してはいけません）：

1. まず、誰が王建硕かを確認します ⟵ 推測してはいけません。主に話している人や、発言量が最も多い人を王建硕と決めつけてはいけません。冒頭の会話をそのままユーザーに貼り、推測した二人の役割（質問している人、答えている人）を示して、AskUserQuestion でどちらが王建硕か確認します。ユーザーが確認するまでは、記事候補の識別に進んではいけません。
2. 王建硕が実際に自分の見解を展開した話題だけを掘り起こします。対談で記事候補になるのは、王建硕が単独の記事にできるまとまった見解を述べた部分です。相手が質問しただけ、背景を説明しただけ、相づちを打っただけの部分は候補になりません。前後の文脈を読んで、それぞれの発言が誰のものか判断してください。王建硕の発言か判断できない場合は、「要確認」としてユーザーに判断を委ね、絶対に本人の発言として扱ってはいけません。
3. 記事候補の一覧は通常どおり作成します（Step 2）。ただし、対談では各項目に「この話題における王建硕の核心的な主張は X です」という一文を追加し、書く価値があるかユーザーが判断できるようにします。

Step 2 · 記事候補の一覧を提示し、ユーザーが選ぶのを待つ ⟵ 唯一の人手による確認ポイント

候補ごとに、仮のタイトル／話題の内容をまとめた一文／該当する SRT の時間範囲（例：03:12–06:40）を提示します。対談では、各項目に「この話題における王建硕の核心的な主張は X です」という一文を追加します。

一覧の提示方法は、候補数に応じて2通りあります：

• 4本以下：AskUserQuestion（multiSelect: true）を使います。チェックボックスで選ぶのが最もすっきりしています。
• 4本を超える場合（長い対談ではよくあります。1～2時間の対談から10～16本を掘り起こせます）：AskUserQuestion の選択肢は1つの質問につき最大4個なので、入りきりません。代わりにテキストの表（番号 | タイトル | 核心的な主張 | 時間範囲）を使います。「内容の強さ」と「王建硕らしい定番の見解かどうか」の順に並べ、⭐ おすすめを付けて、ユーザーに番号を直接伝えてもらいます（「1 3 4」／「⭐のものから先に」／「全部」）。

選ばれた候補だけを Step 3 に進めます。ユーザーが「全部」と言った場合は、すべて書きます。

Step 3 · 選んだ話題ごとに article.md + meta.json を作成する

本文を書く前に wangjianshuo-perspective を読み込み、本人らしい語調にします。wjs-publishing-wechat の厳守事項に従って書きます（そちらが唯一の基準となるため、ここでは要点だけを繰り返します）：

• 文字数は原則 800～1000字、1200字を超えたら戻って削ります
• 赤色の太字 **...** を2～4か所、印象的な一文／重要な結論／核心となる概念に付けます。一か所もない場合は、まだ完成していません
• AI らしい接続語を使わない（まず／次に／総括すると／注目すべき点は）、絵文字を使わない、口語を無理に堅苦しい文章にしない
• 原則として ## 後注 は書かず、本文の最後で結びます

各 article.md の執筆後、一度、盤古之白を実行します（中国語と英語の間にスペースを入れる機械的な作業です。自分で覚えておく必要はありません）：

python3 ~/.claude/skills/wjs-publishing-wechat/scripts/pangu.py <folder>/article.md   # 幂等

対談から記事を書く場合の追加ルール（発言の帰属に関する絶対ルール）：記事は王建硕の一人称で書き、主体となるのは彼の見解と思考です。相手（汤维维など）の発言は導入や背景としてのみ使います——「ある人から聞かれたのですが……」「X について話していたときに……」など。相手独自の見解を王建硕自身の主張として書いてはいけません。相手が挙げた話題に王建硕が正面から答えていない場合は、その話題をこの記事に含めないでください。source.srt.md に、この記事が対談をもとにしていること、相手が誰か、導入として相手のどの発言を引用したかを明記します。

選ぶ記事が多い場合（長い対談）は、エージェントを並行して使ってまとめて執筆します：各エージェントに wangjianshuo-perspective を読み込ませ、対応する文字起こしの行範囲と上記の厳守事項をすべて渡し、2～3本ずつ、article.md＋meta.json＋source.srt.md を作成させます。1～2時間の対談から一度に10本以上を書く場合、順番に進めると遅くなります。並行すれば速く、記事ごとに独立しているため互いに干渉もしません。エージェントに依頼する前に、動画全体を通読し、発言の帰属と事実関係の訂正をすべて確定させます（今回なら、ASR が「黄一孟」を「黄一梦」と聞き取っていたことを依頼時に明記する必要があります）。そうしないと、エージェントごとに推測して間違えるおそれがあります。

各記事は、新しいフォルダ <workspace>/articles/YYYY-MM-DD-{slug}/ に保存し、次の3つのファイルを作成します：

ファイル	内容
article.md	本文
meta.json	{ "title", "summary", "author": "王建硕", "date", "slug" } — 3つの再利用スクリプトはいずれもこのファイルを使います
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>   # 题图 cover.png(读 meta.json 的 title 当目标字词)
gen-illustration.sh <folder> # 解释图 illustration.png + 确保 article.md 引用 ![](./illustration.png)
upload-draft.sh   <folder>   # 上传到微信后台建草稿(只建草稿,不群发)

納品時には、各記事が「WeChat の管理画面に下書きがあり、ワンクリックで公開できる」状態になっています。一斉配信はユーザーが管理画面で手動操作します——この skill の作業は下書きまでです。

画像の作成と下書き作成は手間がかかり、長い対談から十数本作る場合は時間がかかります：gen-cover / gen-illustration はいずれも codex に画像を生成させ、1本あたり約1～3分かかります。記事ごとに手作業で待つのではなく、バックグラウンドの一括処理スクリプトにまとめて一度に実行します（成功／失敗を記事ごとに記録し、エラーがあっても他の記事に影響しないようにします）。スクリプトでは、画像がすでに存在する場合に gen-cover / gen-illustration を「スキップ」するようにします。これにより、途中で失敗して再実行しても、生成済みの画像を無駄にせずに済みます。

Step 5 · （任意）X への投稿を予約する

ユーザーがこれらの記事を tweet にして投稿したい場合は、wjs-tweeting-from-articles に引き継ぎます：

• 1件投稿する場合 → デフォルトの手順を使います（記事を1本選び、A/B/C の候補を作り、ユーザーが選択してから xurl で投稿）。
• 一度に多くの記事を投稿する場合（長い対談から掘り起こした十数本など）→ 一括予約モードを使います。各記事から120字以内の tweet を1つ抜き出してキューに登録し、post-next-from-queue.sh と1時間ごとの cron（スクリプトが自動で投稿間隔を調整します）を使って、「N時間ごとに1件」のペースで自動投稿します。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 只建草稿,真正发布是用户的手动决定
• 对谈里默认「说得最多的就是王建硕」 —— 大错。必须让用户确认身份;说不定主讲人是嘉宾,王建硕才是提问的一方
• 把对方的观点写成王建硕的主张 —— 归属红线。对方的话只能作引子,拿不准是谁说的就标存疑