video-creator
目的
為產品展示和行銷影片進行內容規劃。撰寫附有時間標記的旁白腳本，建立逐場景分鏡表，定義拍攝清單，並列出所需素材。將完整的製作計畫儲存為檔案。此技能建立的是影片製作的「計畫」，而非實際的影片檔案。
被誰呼叫（入站）
marketing(L2)：展示/解說影片腳本launch(L1)：產品展示影片
呼叫什麼（出站）
無 — 純 L3 工具。
可執行指令
步驟 1：接收簡報
從呼叫技能接受輸入：
topic— 影片主題（例如「Rune 外掛展示」、「功能 X 導覽」）audience— 觀眾類型（例如「開發者」、「非技術背景創辦人」、「現有用戶」）duration— 目標長度（秒），例如 60、120、300platform— 發布平台：youtube|twitter|tiktok|loom|internaloutput_path— 計畫儲存路徑（預設：marketing/video-plan.md）
根據平台推斷限制：
- YouTube：無嚴格長度限制，超過 3 分鐘建議加入章節
- Twitter/X：最長 140 秒，前 3 秒必須有鉤子
- TikTok：最長 60 秒，節奏快、剪接快速，需上字幕
- Loom：非同步友善，以螢幕錄製為主，不需要音樂
步驟 2：腳本
撰寫附有時間標記的旁白腳本。在撰寫任何一行之前，請先應用下方的敘事工藝原則 — 觀眾「聽到」的腳本成敗取決於開場與流暢度，而非拍攝清單。
結構：
- 鉤子（0–5 秒）：開場白，抓住注意力 — 陳述問題或報酬
- 鋪陳（5–15 秒）：背景 — 本內容適合誰，他們會學到什麼
- 展示/主體（15 秒–[duration-15 秒]）：主要內容，按場景拆解
- CTA（最後 10 秒）：行動呼籲 — 下一步該做什麼（給 repo 加星、註冊、分享）
每個區段格式：
[00:00] 鉤子
旁白：「...」
畫面：[觀眾看到的內容]
[00:05] 鋪陳
旁白：「...」
畫面：[觀眾看到的內容]
步驟 3：分鏡表
建立逐場景拆解：
每個場景包含：
- 場景編號與名稱
- 持續時間（秒）
- 視覺描述（畫面上出現的內容）
- 旁白文字（來自步驟 2）
- 轉場類型：cut | fade | zoom | slide
範例：
場景 3：即時展示 — 安裝指令
持續時間：12 秒
視覺：終端機視窗，輸入指令「npm install -g @rune/cli」，輸出訊息滾動
旁白：「只需一個指令即可快速安裝。」
轉場：cut
步驟 4：拍攝清單
明確定義需要錄製或顯示的內容：
依類型分類：
- 螢幕錄製：列出每個要捕捉的螢幕狀態（URL、應用程式狀態、操作動作）
- 程式碼片段：列出每個要顯示的程式碼區塊（檔案路徑 + 行數範圍，或內聯）
- 圖表/投影片：列出每個所需的靜態視覺（標題、重點）
- 終端機：列出每個要記錄的指令序列
格式：
鏡頭 1 — 螢幕錄製
URL：https://myapp.com/dashboard
動作：點擊「新專案」→ 填寫表單 → 點擊「建立」
持續時間：~8 秒
鏡頭 2 — 終端機
指令：npm install -g @rune/cli && rune init my-project
預期輸出：[請描述應出現的內容]
持續時間：~10 秒
步驟 5：所需素材
列出開始錄製前需要的所有素材：
- 螢幕截圖（哪些頁面/狀態）
- 程式碼片段（哪些檔案、哪些區段）
- 圖表（主題、風格：流程圖 | 架構圖 | 比較表格）
- 投影片背景或標題卡
- 縮圖（尺寸依平台而定：YouTube 1280x720、Twitter 1200x628）
步驟 6：報告
使用 Write 將完整的影片計畫儲存至 marketing/video-plan.md（或指定的 output_path）：
# 影片計畫：[主題]
- **平台**：[平台]
- **目標長度**：[duration] 秒
- **觀眾**：[audience]
- **建立日期**：[date]
## 腳本
[步驟 2 的完整時間戳腳本]
## 分鏡表
[步驟 3 的逐場景拆解]
## 拍攝清單
[步驟 4 的所有鏡頭]
## 所需素材
[步驟 5 的檢查清單]
## 平台注意事項
[目標平台的限制與提示]
然後向呼叫技能輸出摘要：
## 影片計畫已建立
- 檔案：[output_path]
- 場景數：[count]
- 鏡頭數：[count]
- 預估錄製時間：[n] 分鐘
- 需準備素材：[count] 項
### 後續步驟
1. 準備計畫中列出的素材
2. 依照拍攝清單順序錄製鏡頭
3. 以分鏡表為參考進行剪輯
敘事工藝（決定腳本是否引人入勝或枯燥乏味）
展示腳本是「聽」的，不是「讀」的。以下原則能區分引人入勝的腳本與普通的旁白 — 請在步驟 2 中、撰寫任何一行之前套用。
九項原則：
- 痛苦優先開場。 以觀眾最大的痛點或已發生的數據開場（「如果你常常必須...」、「這個 repo 已經有 9k 顆星...」）。絕對不要用平淡的目錄式開場（「今天我們將探討...」、「這是一個可以...的工具」）— 這種開場沒有點出任何問題，完全沒有理由讓人繼續看下去。
- 對比結構。 「不只是 X，更是 Y」、「不是 X，而是 Y」、「像 X 但具有 Y」。對比能吸引注意力。
- 第二人稱。 「你馬上會看到」、「如果你在 M 系列 Mac 上開發...」。讓觀眾身歷其境。
- 即時示範性。 「就在這裡」、「這個」、「現在的時間軸上」。具體且當下。
- 具體真實名稱，保留術語。 說出實際的檔案、指令、競爭對手名稱（「Final Cut」、「Cursor」、「ffmpeg」）。禁止使用泛稱（「一個 AI 工具」、「那個框架」）。不要把術語硬翻譯成彆腳的詞。
- 量化社會證明 — 一次就夠。 「超過 9k 顆星」。絕對不要連續以獨立片段的方式列出星數、叉數、問題數。
- 簡短子句，逗號串聯。 「你可以修剪、取代或重新生成它。」一次呼吸的長度，不要用條列式碎片。
- 將限制轉為特色。 說出一個誠實的限制或「誰不應該使用這個」。這是影片中最能建立信任的一句話 — 它是留存率的保證，不是填充內容。
- 使用場景落地。 以「特定」的觀眾情境作結，而不是「去看看吧」。
有名稱與編號的「武器」。 為每個差異化點賦予標題和編號（「武器 01/02」）。挖掘 2-3 個「非顯而易見」的細節（一個正規表示式、一個守衛條件、一個演算法、一個備援機制）— 一個精確且令人驚喜的機制勝過一串泛泛的能力清單。
場景間的連接詞。 第一個場景之後的每個場景開頭都應使用語言上的連接詞回頭參照（「核心在於...」、「具體來說...」、「但請注意...」），如此整部影片才會像「一篇獨白」，而不是 N 個被逐一朗讀的簡短說明。將完整腳本按照順序大聲朗讀一遍 — 如果聽起來像不連貫的片段，請重寫。
自動失敗模式 — 如果出現以下情況，拒絕該腳本：
- ❌ 鉤子/問題/解決方案/CTA 被當作孤立的填空片段處理
- ❌ 側邊欄數據（星數/叉數/問題數）作為獨立的一行場景
- ❌ 每個句子都像獨立的條列式重頭開始（「X 執行一條流程。Y 負責寫入。Z 負責旁白。」）
- ❌ 泛泛的能力宣稱（「功能完整」、「非常強大」、「社群中很受歡迎」）
- ❌ 描述的是 README/repo 而非產品本身
- ❌ 以「去看看吧」、「感謝觀看」作結
旁白：TTS 安全敘事（當旁白由機器合成時）
當旁白將由 TTS 引擎合成（AI 語音，而非真人朗讀）時，聽到的「旁白」與看到的「螢幕文字」是「兩個獨立通道」— 一個用聽的，一個用讀的。請獨立優化兩者；絕對不要把原始片段、數字或符號直接餵給 TTS，然後期望語音能正確解讀。（下方以越南文為例說明模式；請根據目標 TTS 引擎的語言，套用相同的注音與數字轉文字原則。）
數字 → 口語文字（許多神經 TTS 引擎會誤讀純數字 — 越文範例）：
| 形式 | TTS 可能誤讀 | 請寫成 |
|---|---|---|
| 版本小數點 | GPT 5.5 → "năm rưỡi" | GPT năm chấm năm |
| 統計小數點 | 82.7% | tám mươi hai phẩy bảy phần trăm |
| 規格 | 200MP | hai trăm megapixel |
| 價格 | $5 / 21 triệu | năm đô / hai mươi mốt triệu đồng |
| 倍數 / 百分比 | 2x / 30% | gấp đôi / ba mươi phần trăm |
英文/品牌名稱 → 旁白用注音，螢幕顯示用原文：
| 術語 | 旁白（聽到） | 顯示（看到） |
|---|---|---|
| README | ruýt my | README |
| ffmpeg | ép ép em peg | ffmpeg |
| GitHub / repo | git hâb / rề pô | GitHub / repo |
| API / GPT | ây pi ai / gí pi tí | API / GPT |
從旁白中移除： emoji、URL（改成說「github 點 com 斜線...」）、符號（→ & % $ # / @）、斜線指令（改成說「外掛安裝指令」）、句中出現的副檔名（改成說「那個 YAML 檔案」）、駝峰式命名識別碼、省略號 … 與破折號 —（TTS 會誤讀 — 請拆成兩個短句）。每一個句子都要以 . 或 ? 結尾，以產生自然的停頓。
保留術語，使用自然的口語風格。 用一個內行朋友說話的方式來寫 — 但要保留標準的技術術語（「commit」、「endpoint」、「prompt」保留原形；硬翻譯聽起來怪異且會失去原意）。只有在當地語言確實使用該詞時才進行翻譯。
口白影片的製作注意事項（如果真的會製作，而不只是規劃）：
- 全片使用同一種聲音、同一個供應商 — 中途更換聲音或供應商會讓人感到突兀。
- 先測量 TTS 長度，再決定每個場景的視覺長度 — 先估計長度再渲染會導致影音不同步。
- 卡拉 OK 式字幕是短影音（TikTok/Reels/Shorts）的最高專業信號：置中底部字幕，逐字與語音同步，關鍵字加上重音。這是在靜音自動播放時確保理解度的要件，也是最強烈的「專業」暗示 — 請為它保留底部字幕區。
備註
此技能建立的是影片製作的「計畫」。實際的錄製與剪輯必須由人類或專用的螢幕錄製工具執行。
輸出格式
影片計畫儲存至 marketing/video-plan.md，內容包含腳本、分鏡表、拍攝清單、素材檢查表及平台注意事項。摘要報告包含場景數、鏡頭數及預估錄製時間。完整範本請參閱上方步驟 6 報告。
限制
- 在產生內容前必須確認影片參數（長度、解析度、格式）
- 不得在未經用戶確認的情況下超出合理的檔案大小
- 必須儲存至專案素材目錄
銳利邊角
此技能已知的失敗模式。在宣告完成前請檢查這些項目。
| 失敗模式 | 嚴重性 | 緩解措施 |
|---|---|---|
| 未套用平台限制（例如超過 Twitter 最長 140 秒） | 高 | 步驟 1：立即從平台推斷限制 — 它們會限制後續所有內容 |
| 腳本缺少 CTA 區段 | 中 | 每個腳本都必須包含 CTA（最後 10 秒）— 無論影片長度為何，沒有例外 |
| 未儲存為檔案（僅有口頭輸出） | 高 | 限制 3 + 步驟 6：必須寫入 output_path — 僅有口頭輸出代表沒有持久化 |
| 承諾會產出實際的影片檔案 | 中 | 明確備註：此技能建立的是「計畫」— 實際錄製由人類執行 |
| 使用平淡的目錄式開場（「今天我們將探討...」）而非痛苦優先鉤子 | 高 | 敘事工藝 #1：以觀眾最大的痛點開場 — 沒有點出任何問題的開場會在 2 秒內流失觀眾 |
| 在 TTS 旁白中保留原始片段/數字/符號（「README」、「82.7%」、「5.5」） | 高 | 旁白章節：將旁白改寫為注音 + 數字轉文字形式；僅在顯示通道保留原文拼寫 |
| 腳本像 N 段不連貫的片段 | 中 | 敘事工藝連接詞：第一個場景之後的每個場景開頭都回頭參照 — 在宣告完成前請朗讀完整腳本 |
完成條件
- 已識別平台限制並套用至長度/格式
- 已套用敘事工藝 — 痛苦優先開場、跨場景連接詞、至少一個限制轉特色、無自動失敗模式
- 若旁白由 TTS 合成：在聽覺通道使用數字轉文字 + 注音品牌名稱，顯示通道保留原文拼寫
- 腳本已撰寫並包含時間標記（鉤子、鋪陳、展示/主體、CTA）
- 已建立逐場景分鏡表並包含轉場
- 拍攝清單已依類型分類（螢幕錄製、終端機、程式碼、圖表）
- 已產生所需素材檢查清單
- 已使用執行階段的檔案編輯能力將
video-plan.md寫入至output_path - 已輸出「影片計畫已建立」報告，包含場景數、鏡頭數與素材數
成本概況
輸入約 500-1500 個 token，輸出約 500-1000 個 token。建議使用 Sonnet 以確保腳本品質。