name: video-diary slug: video-diary displayName: 影片日記 Skill description: 程大明影片日記 Skill（寫稿 + 審稿 + 存稿 三合一）。當用戶說"寫影片日記""寫影片指令碼""幫我寫今天的影片文案""寫一篇日記"時走寫稿模式；說"審稿""審一下""幫我看看這篇稿""改改這稿"時走審稿模式；說"定稿""存檔""儲存"時走存稿模式（本地歸檔 + 飛書雙備份）。寫稿完成後預設自動內審，與審稿用同一把尺。 version: 4.3.0 agent_created: true visibility: private

影片日記 Skill（寫稿 + 審稿 + 存稿 三合一版 v4.3.0）

本 Skill 把影片日記的完整工作流收進一個檔案，三件事共用同一套標準，避免"寫/審/存"三處打架： - 寫稿模式：產出符合老闆風格的口播稿（原 video-diary v3.14） - 審稿模式：用同一把尺審文案質量、卡完播率（文案審稿原則） - 存稿模式：本地 video_diary_scripts/ 歸檔 + 飛書線上雙備份，徹底杜絕單點丟失

寫稿篇的原則 1–6 與審稿篇的原則 7，合起來構成「文案質量 7 原則」，寫審同源；存稿篇複用寫稿的鐵規則（大標題、分割線、靜默回覆）保證落庫一致。

〇、模式總覽（先判斷使用者意圖）

⚠️ 寫稿完成後預設自動內審：走「二、審稿」的清單逐條卡，不過關不輸出。使用者若明確要求"審稿"，則對已有文案做顯式二審。 ⚠️ 存稿只在使用者明確說"定稿/存檔/儲存"時觸發：本地寫 video_diary_scripts/Day[N]_[主題].md 且 同步飛書雙備份，二選一不可少；落庫後只回「已歸檔」，不 present_files、不羅列路徑。

一、寫稿流程（原 video-diary v3.14）

1. 工作流程

1. 讀取歸檔 → 讀最近的3篇歸檔文案（video_diary_scripts/目錄），摸清話題走向和節奏
2. 確認方向 → 向用戶確認本期話題方向（不給選擇題，直接問"今天聊什麼"）
3. 按格式寫稿 → 根據使用者提供的內容素材，選擇合適的結構型別，撰寫完整口播稿
4. 自檢 → 寫完後按「六、自檢清單」逐項檢查，修正問題後再輸出（同時走「二、審稿」清單）
5. 交付 → 在對話裡直接輸出完整文案文本（必須含大標題）
6. 迭代 → 使用者要求修改時，改完直接發完整文案全文（不發文件、不歸檔）
7. 歸檔 → 僅當用戶明確說"定稿""存檔""儲存"時，才按「三、存稿」執行本地歸檔 + 飛書雙備份，最後只回復"已歸檔"

2. 鐵規則（絕不可違反）

3. 1V1交流感規則

4. 結構型別（5種）

型別1：敘事體（最常用）

適用：有一天的經歷/見聞/對話可以展開

鉤子開頭（反常識/提問/場景，3秒抓住注意力）
  → 場景展開（具體發生了什麼，有細節有畫面）
    → 衝突/反常/觸動點
      → 理論/金句支撐（翻譯成人話）
        → 升維洞察（從"是什麼"到"意味著什麼"）
          → 金句/引用收尾
            → 固定收尾語

型別2：清單體

適用：密集資訊輸出（課程筆記、心得彙總）

鉤子開頭（交代素材來源+資訊量感）
  → 逐條列出（每條一句核心觀點 + 一句展開）
    → 預告或總結一句話
      → 固定收尾語

型別3：對話引出類

適用：別人說了一句話/打了個比方，深有感觸

鉤子開頭（交代場景和人物，用"我……"自然句式）
  → 引出原話/比喻（原汁原味保留）
    → 解釋為什麼有道理（用自己的理解展開）
      → 升維（從個人感觸到普遍規律）
        → 金句收尾
          → 固定收尾語

型別4：互動類

適用：想向觀眾徵集意見/號召參與

鉤子開頭（想法來源）
  → 具體計劃
    → 向觀眾提問（2-3個具體問題）
      → 表態（我是認真的）
        → 召喚行動
          → 固定收尾語

型別5：學習型（v3.0新增）

適用：AI工具上手、趨勢翻譯、資源推薦、學習過程記錄

5種模板： | 子型別 | 一句話口訣 | 鉤子詞 | |--------|-----------|--------| | AI上手實錄 | 先踩坑再推薦 | "我花了X小時試了一遍" | | 趨勢翻譯官 | 翻譯資訊差 | "X%的人還不知道" | | 資源紅黑榜 | 幫你省時間 | "試了X個，只有Y個真管用" | | Learn in Public | 還沒搞明白 | "第X天，終於搞通了一個點" | | 見聞筆記 | 一句話值一年 | "他說了一個觀點把我震住了" |

學習型結構：

鉤子開頭（上述對應鉤子詞）
  → 背景/場景（為什麼做這件事）
    → 體驗/發現/進度（真實過程+吐槽）
      → 判斷/提煉（對電商老闆意味著什麼）
        → 收尾（"幹完再說，明天見"或固定收尾語）

關鍵：學習型的核心是展示"還在學/還沒搞明白"的狀態——活人感來源。評價標準永遠是多一層："這玩意省幾個人？能多賺多少錢？"

5. 輸出格式

每篇文案的完整結構：

Day[N]｜[核心主題]

[鉤子開頭，3秒抓住注意力]

[正文，按結構型別展開]

[金句/升維收尾]

好了，今天的影片日記就到這裡，我們明天再見，拜拜。

⚠️ 輸出鐵律：直接在對話中發純文本，絕不用 ``` 程式碼塊包裹文案內容。 歸檔檔名：Day[N]_[核心主題].md，存入 video_diary_scripts/ 目錄（落庫規則見「三、存稿」）

6. 自檢清單（寫稿）

寫完稿後逐項檢查，全部通過才輸出（同時過「二、審稿」清單）：

• [ ] ⚠️ 大標題「Day[N]｜[核心主題]」是否完整存在？（絕不能丟！）
• [ ] ⚠️ 開頭是否為「結果前置的爆款開頭」——第一句是最炸的結果/事實/資料，無日期開頭？
• [ ] 若無驚人結果可用，開頭鉤子是否用了「四大公式」之一（痛點前置/身份反差/利益承諾/反常識）？
• [ ] 每兩句之間邏輯連貫，無跳躍？
• [ ] 資訊密度檢查：每句話是否是「痛點/反轉/乾貨/結論」四種之一？有無廢話（"然後呢""就是說"）？
• [ ] 視角檢查：有沒有從「我想說」出發的段落？改寫為「觀眾想聽」視角？
• [ ] 互動雙條件檢查：正文裡有沒有讓觀眾覺得「這說的不就是我」的點？有沒有情緒起伏（不全是平鋪直敘）？
• [ ] 理論部分是否用具體場景/類比"翻譯成人話"了？
• [ ] 金句/引用前有沒有過渡鋪墊？
• [ ] 是否有升維——從具體到抽象、從"是什麼"到"意味著什麼"？
• [ ] 個人經歷是否自然滲透（用「我…」自然句式），而非單獨開段自我介紹？
• [ ] 結尾固定收尾語是否一字不改？
• [ ] 整篇口語化，能脫稿講出來？
• [ ] 是否有1V1交流感（疑問句/反問/拋觀點勾互動，且未出現"你想啊"，且未出現"對吧？""你知道吧"等虛弱確認語氣詞）？
• [ ] 是否避免了說教感？
• [ ] ⚠️ 是否避免了「我拍大腿」等誇張浮誇表達（老闆明確停用，保持克制真實風格）？
• [ ] ⚠️ 中段防流失：正文是否每 2–3 句一個資訊鉤子、無連續 4 句以上純平鋪？中段是否埋了"我馬上演示一個絕招"這類勾回觀眾的鉤子？
• [ ] ⚠️ 時長與可讀性：單句是否≤28字、段落是否≤4行？錄屏類總時長是否壓在 2–3 分鐘（超長拆系列）？
• [ ] 開頭承諾對齊：前 10 秒是否讓觀眾見到了標題/開頭承諾的內容或價值？
• [ ] 結尾利落：除固定收尾語外，收尾是否乾淨、不拖泥帶水？
• [ ] ⚠️ 事實核查（鐵規則#21）：文中所有事實、數字、第三方評論/誇讚，是否都能追溯到使用者真實素材（影片日記 MD、已發內容、使用者口述）？凡無法溯源的他人之言、虛構資料，一律刪除，不靠"別人誇我"造鉤子？
• [ ] 情緒曲線（第8.3節）：通篇是否有起伏（鉤→沉→轉→燃→收），而非一個調門平鋪到底？平鋪處是否在"轉/燃"補了鉤/金句？

  發現更多技能外掛，請訪問7w4.net。

• [ ] 封面標題三選一（第8.2節）：寫稿末尾是否附了 3 個封面標題備選供挑（不進歸檔/飛書，只在對話給）？

7. 文案質量核心原則（原則1–6；原則7見「二、3」）

以下原則提煉自前字節跳動創作者收入部門員工「茜茜」的實戰方法論（40天萬粉、第三個月收入追平大廠工資）。核心邏輯：從「等流量」到「設計資料」。

原則1：視角轉換 — 從「我想說」到「你想聽」

原則2：開頭3秒定生死 — 四大黃金公式

原則3：資訊密度 — 每句話必須是這四種之一

• 痛點（戳中觀眾的真實困擾） / 反轉（打破預期） / 乾貨（具體可操作） / 結論（收束成一句話） 反例：「哈嘍大家好，我是大明，今天想跟大家聊…」「然後呢，接下來，就是說」→ 直接刪，或換疑問句/反問勾。 正例：14字含3資訊量 → 「三十歲大廠離職，開啟一人公司模式」。

原則4：驅動互動的雙條件

觀眾願意點贊/轉發/關注，必須同時滿足：1. 相關性：「這事跟我有關係」；2. 情緒波動：有衝突/反差/金句。寫完標出哪裡讓觀眾覺得「這說的不就是我嗎」，沒有就補。

原則5：個人經歷自然滲透，不單獨開段

觀眾關注你，是因為對「這個人」有期待。把個人經歷（電商老兵、幫幫堂、Codex實戰）用「我…」自然句式帶出來，別專門開一段自我介紹。

原則6：選題從觀眾需求倒推

寫之前先想：1. 觀眾普遍有什麼痛點/困惑？2. 我這期哪句話能讓他們覺得「這說的不就是我」？3. 看完能得到什麼？想不清楚就別寫。

8. 爆款彈藥庫（v4.3.0 新增）

前面 21 條鐵規則解決"不能怎麼寫"，本節解決"具體怎麼開口"——給寫稿一套可直接套用的開頭句式、封面標題公式、情緒曲線，把「結果前置爆款開頭」（鐵規則#2）從口號變成彈藥。⚠️ 所有 [...] 佔位一律填真實素材（守鐵規則#21，不許為套公式編資料）。

8.1 開頭鉤子彈藥庫（5類 × 可套句式）

選用邏輯：先看本期有沒有"最炸的數字/結果"——有就優先 資料炸場；沒有再從其餘四類挑最貼題的一個，不疊加。[] 內一律填真實素材。

8.2 封面標題公式（區別于歸檔大標題）

歸檔大標題永遠是 Day[N]｜核心主題（鐵規則#1 不變）。但影片封面/釋出標題是 CTR 命門，另按公式產出——每篇寫稿末尾附「封面標題三選一」，只在對話裡給老闆挑，不進歸檔正文、不進飛書。

8.3 情緒曲線（一稿的起伏設計）

一條口播稿走這條線，避免全程一個調門：

鉤(炸/懸念) → 沉(鋪場景/痛點) → 轉(反常識/反轉) → 燃(金句/絕招演示) → 收(升維 + 固定收尾語)

自查：通篇是否只有一個情緒檔位？平鋪無起伏＝在"轉/燃"處補鉤、補金句（掛接完播率原則7-#2、#5）。

二、審稿流程（與寫稿用同一把尺）

本模式用寫稿篇的鐵規則 #1–#20 反向卡稿，併疊加原則7「完播率最佳化」。寫稿完成後預設自動內審，使用者明確要求"審稿"時走顯式二審。

1. 審稿定位

• 審稿 = 用寫稿標準反推：寫稿篇的每一條鐵規則、自檢清單，都是審稿的"扣分項清單"。稿子裡出現鐵規則禁止的內容（虛弱詞、浮誇表達、連續平鋪…）即判為不過關。
• 雙維度：① 文案質量（鐵規則 #1–#20 / 原則1–6）② 完播率（原則7 / 鐵規則 #17–#18）。

2. 審稿清單（逐條反向卡稿）

3. 原則7：完播率最佳化（6條寫作方法論）

完播率 = 觀眾看到結尾的比例，是演算法推流的命門。每條完播率低，根因幾乎都能歸到下面 6 條寫作動作。審稿時逐條反推（與寫稿篇原則1–6 共同構成「文案質量 7 原則」）：

反推閉環：審出某條完播率隱患 → 對照上表 6 條定位根因 → 給"這稿怎麼改"的具體動作，而非只列數字。

4. 審稿輸出格式

審稿結論必須給"改哪裡"的具體動作，不只列問題：

📋 審稿結論 · Day[N]｜[主題]

❌ 不過關項（必改）：
  - [鐵規則#19] 第X段出現"對吧？" → 刪，改疑問句勾
  - [原則7-#2] 中段連續5句平鋪 → 第Y句後加"我馬上演示一個絕招"勾回

⚠️ 建議最佳化（可選）：
  - [原則7-#5] 金句壓在結尾，建議前移到第2段

✅ 已過：大標題/開頭爆點/收尾語/英文大寫/時長

三、存稿流程（本地歸檔 + 飛書雙備份）

定位：寫稿產出的稿子，最終要"落袋"。存稿 = 本地 video_diary_scripts/ 檔案歸檔 + 飛書線上文件雙備份，二者缺一不可（老闆 2026-07-16 明確要求，徹底杜絕單點丟失）。 觸發：僅當用戶明確說"定稿""存檔""儲存"。 鐵律：落庫後只回「已歸檔」，不 present_files、不羅列路徑、不彙報細節（鐵規則#15）。

1. 本地歸檔

• 目錄：video_diary_scripts/（在 .workbuddy/ 下；Mac/PC 通用，路徑由指令碼按本機自動定位，不寫死磁碟機代號）
• 檔名：Day[N]_[核心主題].md
• 首行（不變）：Day[N]｜核心主題（不帶日期，遵守鐵規則#1）

2. 飛書雙備份（線上文件）

• 文件 token（doc_id）：AmekdtcBJo53IwxVrJ0cx9N0nQb（程大明持有，2026-07-16 建立）
• 文件 URL：https://taiyi2023.feishu.cn/docx/AmekdtcBJo53IwxVrJ0cx9N0nQb
• 錨點塊 block_id（引言段，永遠插在它後面=內容最頂）：doxcncj77qTBiiutKmAAqbMC8hg
• 排序：日期越近越靠上（最新在最上）。block_insert_after --block-id <錨點> 的語義是"最後同步的壓最頂"，因此逐篇按時間順序存檔時越新越靠上；一次性補檔多篇時務必按日期從早到晚依次同步，最晚那篇會落最頂。錨點 id 穩定不變、可永久複用。
• ⚠️ 補檔"比已存日記更舊"的一篇時（例如先存了 Day125、Day122，事後才補 Day124）：不能用錨點（會跑到最頂、順序反）。須從 docs +fetch --detail with-ids 找到該舊日理應落在的前一篇的末尾 <hr id="..."/>（例：Day124 應落在 Day125 之後 → 取 Day125 分割線塊 id），用 feishu_sync.py --after <該hr塊id> 插入到正確位置。

每篇格式

• 標題 → <h1>Day[N]｜核心主題（YYYY.MM.DD）</h1>（本地 .md 首行仍是 Day[N]｜核心主題，飛書 H1 在末尾追加 （YYYY.MM.DD），日期由 --date 傳入）
• 正文 → 按空行分段，每段一個 <p>...</p>
• 分割線 → 每篇正文末尾追加一條 <hr/>，使相鄰兩篇之間用分割線隔開（見鐵規則#16）
• 文本內若出現 < > & 須轉義為 < > &（標籤本身不轉義）

純標題記錄（老闆 2026-07-16 明確：之後還會發這類"只有標題"的日記記錄）

• 現象：使用者只給一行標題（如「Day124｜Obsidian搞定了我15680條筆記」），不帶正文——通常是錄了某段影片素材、還沒寫稿，先佔個位。
• 處理：本地 .md 首行只寫該標題（無正文），飛書同步生成 <h1>Day[N]｜主題（YYYY.MM.DD）</h1><hr/>（無 <p> 段落，僅標題 + 分割線）即可，不要因為沒正文就跳過或追問使用者。
• 排序：純標題記錄多為事後補檔的舊日，同樣按"補更舊日記"規則用 --after 落到正確位置。
• 使用者後續會把這類純標題記錄陸續發來，收到即按上述歸檔，無需等正文。

日期怎麼來：存檔時若該篇日記的日期由使用者給出，直接用；否則用該篇日記所寫當天的日期（通常為當天）。歸檔本地 .md 時首行仍寫 Day[N]｜核心主題（不帶日期，遵守鐵規則#1）；飛書 H1 才追加 （YYYY.MM.DD）。

3. 同步命令（跨平臺：Mac / PC 通用）

配套指令碼已做 OS 自適應，無需改任何路徑。執行環境為 WorkBuddy 內建 Python（python3，Mac/PC 通用）。

# 用 WorkBuddy 內建 python 執行配套轉換器，把某篇 .md 變成飛書 XML 並同步到最頂
#   --date 傳該篇日記對應的日曆日期，如 2026.07.12（不傳則 H1 不帶日期）
#   --noop 只打印 XML 不落庫（驗證用）
python3 "<技能目錄>/feishu_sync.py" "<源md路徑>" --date 2026.07.12

# 補更舊的一篇（落到正確位置）：
python3 "<技能目錄>/feishu_sync.py" "<源md路徑>" --date 2026.07.14 --after <hr塊id>

跨平臺說明（重要）： - lark-cli 路徑：指令碼按 sys.platform 自動探測——Windows 用 ~/.workbuddy/binaries/node/cli-connector-packages/lark-cli，macOS 用 ~/Library/Application Support/WorkBuddy/... 或 ~/.workbuddy/...，找不到時回退 /usr/local/bin/lark-cli。若你的環境特殊，設環境變數 LARK_CLI=/絕對路徑/lark-cli 即可覆蓋。 - 飛書文件歸屬：doc_id / 錨點 預設是程大明的本機值。換人/換文件時，設環境變數 FEISHU_DOC_ID、FEISHU_ANCHOR（或改指令碼頂部預設值），無需動邏輯。 - 日期推算（批次用）：feishu_bulk_sync.py 以 Day122 = 2026-07-12 為錨點推算日期；換錨點設 FEISHU_ANCHOR_DAY / FEISHU_ANCHOR_DATE。 - 源目錄：批次指令碼預設讀 <.workbuddy>/video_diary_scripts/；換位置設 VIDEO_DIARY_SCRIPTS_DIR。 - 臨時檔案：統一用 tempfile，不寫死磁碟機代號，Mac/PC 都不會越界。

4. 批次重灌（一次性把 video_diary_scripts/ 全部重同步飛書）

• 指令碼：skills/video-diary/feishu_bulk_sync.py（全自動：去重→清空文件→分塊灌入；H1 帶日期、按 Day 升序塊 / 塊內降序，保證最新在最頂）。
• 用法：python3 "<技能目錄>/feishu_bulk_sync.py"（無引數；配置同上環境變數）。
• 去重：同 Day 多稿時取正文行數最多的一篇作代表（其餘不丟，列在 stdout 供補錄）。
• ⚠️ 已固化的三個坑：① 飛書 +fetch --detail with-ids 的 block id 是 id="..."（不是 block_id="..."），清空時按 id= 提取；② 清空階段 --block-id 一次性塞幾百個 id 會超 Windows 命令列 8191 字元上限（WinError 206），須分批（每批 20）；③ 源 .md 首行可能帶 # Markdown 字首，H1 標題須規範成 Day0NN｜主題 再追加 （日期）。

5. 靜默原則

鐵規則#15：飛書同步是靜默動作，落庫後不向用戶彙報細節、不 present_files、不羅列路徑；統一隻回「已歸檔」。

附：資料復盤不在本 Skill 範圍

本 Skill 只負責「寫稿」「審稿」「存稿」。小紅書/抖音的資料採集與資料分析（採集指令碼、SQLite、指標復盤報告等）不納入本 Skill，暫不提供。如後續要做資料復盤，單獨成 Skill，不與寫稿/審稿/存稿混在一起。

四、更新日誌

質量較好。優點是功能全面、規則清晰、示例豐富，跨平臺適配做得不錯，使用體驗流暢。不足是部分配置針對特定使用者，不夠通用；錯誤提示和異常處理還可以更完善；內容模板種類偏少，選擇有限。整體而言，這是一個成熟可用的 Skill，但還有提升空間。