motion-video — 製作整支程式碼渲染影片

motion-video — 製作整支程式碼渲染影片 是做什麼的？

處理「影片層級」工作的路由技能。元素層級的動畫（持續時間、緩動、彈簧、單一元件內的顏色切換）則留在 motion-design 技能中；請參閱 ~/.claude/skills/motion-design/local/element-motion-params.md 以取得已測量的彈簧數值。證據存放於實驗室 <lab>（卡片 techniques/Tnn、文件、測量結果）；工具也保留在此處（使用者 2026-09-30），因此本技能僅引用其路徑，而非複製其內容。

參考資料中的每一條規則都帶有證據層級（references/evidence-and-instruments.md §層級）：使用者（使用者觀看影片後判定）、測量（經校準的儀器在原始影片上讀取）、驗證（經盲測 A/B 比較，範圍無重疊）、未驗證（在原始影片上測得，但未經模仿測試）。請勿將未經驗證的規則陳述為已驗證的規則。

路由表

如果任務是關於…	請閱讀
首先決定什麼；受眾、基調、底色、哪些資訊屬於哪個類別；裝置與基調的配對；素材與文字	references/whole-film-rules.md
哪種影片類型；段落骨架（片頭廣告、宣傳廣告、產品導覽、數據展示片、旁白解說動畫）；分鏡腳本 vs. 單一段落	references/film-types.md
段落變換在時間軸或旁白線上；節拍對齊；轉場（形狀到形狀、淡入淡出、擦除）；運鏡	references/rhythm-transitions-camera.md
建構頁面、時間驅動渲染、匯出為 MP4、產品忠實度（聲明檔案）、拍攝即時互動元件（§4 第 9 項）、封面、審閱循環、音樂來源與授權（§5）	references/build-and-export.md
證據層級；哪個實驗室儀器測量什麼；每個數字的來源	references/evidence-and-instruments.md
實拍片段或生成媒體（本地 ComfyUI 圖片、剪輯）、根據音樂節拍剪輯、可交換的 EDL — 編輯路線，非時間驅動頁面（使用者裁決 2026-10-18）；每個素材都必須附帶來源檔案，否則拒絕渲染	實驗室 tools/edit/README.md， 設計實驗室 docs/edit-route-design.md
連續的物理或演算法過程（如前端生長、領域擴散、波紋傳播） — 一個 manim 素材（PNG 序列 + 來源）合成到時間驅動頁面中，絕非完整的 manim 影片。整片製作與編輯合成（必須使用的素材）是分離的層級（使用者裁決 2026-10-20）；合成規則較簡潔，初步探索中	實驗室 experiments/probe-manim-insert-ow2010/README.md；提案 ~/.claude/outputs/manim-explainer-route-20261020/
單一元素的彈簧 / 顏色切換參數	motion-design/local/element-motion-params.md
在分鏡腳本之前，每部影片：共享的設計層（作為此影片的副本）— 其中的失敗清單具有約束力（作者已拒絕的作品；切勿重複）	<item>/inputs/design-axes.md，由 works_contract.py open（步驟 0）複製；實驗室分支從 run_arm.py 取得相同檔案
相同原則應用於貼文、簡報或網頁（跨媒介形式，軸線 A–I，生成軸線 J/K，命名學派）— 理論，選擇時請閱讀	~/.claude/references/design-axes/

工作順序（每一步驟在前一項之後）

0. 在一切之前確認（whole-film-rules.md §0）：目的 / 影片類型（片頭廣告、宣傳廣告、產品導覽、解說動畫、簡介影片）、影片將在哪裡展示、觀看者看完後應採取什麼行動、受眾、唯一需要記住的事、能量（平靜 / 生動 / 宣傳；需詢問，不能僅從產品推斷）與底色、素材與限制、內容語氣（行銷 vs. 輕度技術）以及呈現形式（分頁 vs. 連續舞台）。使用者在此 → 詢問這些並等待。無人看管 → 將每個開放問題寫入 build/questions.md，並以最字面的解釋處理請求，記錄在 build/plan.md。「產品介紹片」不足以決定是廣告還是導覽（使用者 r14）；「廣告」不足以決定是片頭還是宣傳（使用者 r15）。請示中的類型或形式名稱（MAD、PV、showreel…）既是影片類型，也是該影片所服務的產品名稱主題：請在 film-types.md §命名中解析，並在使用者確認該定義之前，不得進行分鏡腳本；無對應項目的名稱需詢問，不得推斷 — 未經確認的名稱會導致目標錯誤 / 期望不足的失敗（使用者 2026-10-19：一個僅一行敘述的 MAD 請求，第一輪回傳的結果是純程式碼 MV）。 正式項目或實驗室輪次？（正式 = 作者將送出或交給他人的事物；唯一定義存在於 <works>/README.md）。正式 → 任務的首次寫入為 python -X utf8 ~/.claude/tools/design-axes-mount/works_contract.py open <works>/films/<film_id> --medium video --actor main-loop [--toolbox PATH:ROLE:FACET ...]，無論請求來自哪個資料夾；將其列印出的「創作輸入」行貼入邊界合約，並在該項目內建構。來自另一個交付物的生成器、元件或頁面（如同書籍的插圖腳本、之前的影片）是一個工具箱條目，包含其角色與面向，而非預設（一個 2026-10-11 的書籍專案：該書籍的線稿生成器縮放至 1080p 被拒絕，現為負面參考）。實驗室輪次 → run_arm.py 掛載相同的層。
1. 先決定整部影片（whole-film-rules.md §1）：命名唯一的受眾、該受眾需要知道什麼、基調（在步驟 0 中命名的能量；僅當無能量時，從產品 + 受眾推斷），以及唯一底色（宣傳廣告可放寬此規則，whole-film-rules.md §6）。這四項在選擇任何裝置之前必須固定。如果產品的文件未說明某個功能解決什麼問題，請詢問擁有者（build-and-export.md §4 第 7 項）；無人看管時，請寫入 build/questions.md，而非虛構一個痛點。
2. 影片類型（film-types.md）：片頭廣告、宣傳廣告、產品導覽、數據展示片、旁白解說動畫或簡介影片 — 根據步驟 0 的目的，而非哪個骨架最接近手邊。選擇骨架；決定分鏡腳本（固定內容）vs. 單一段落（多次執行產生）。
3. 節奏來源（rhythm-transitions-camera.md §1）：僅音樂 → 段落變換在小節線處；存在旁白或歌詞 → 段落變換在行首處，且音樂不強制鎖定。影片是否有旁白，根據影片類型和基調（步驟 1-2）決定；安靜的影片仍可能使用帶有慢段的音樂。
4. 在編寫程式碼之前先建立分鏡腳本表：首先閱讀 inputs/design-axes.md（路由表，「在分鏡腳本之前」行）。每個段落 t：標題、視覺、數據、佈局、入轉場/出轉場、運鏡目標、動畫意圖（每個移動元素和每個疊加效果層一行：動畫要表達的意義；無對應行的元素保持靜止或消失，whole-film-rules.md §2a；命名效果將該行作為描述，因為僅有名稱而其目錄與業界含義衝突時，需按業界含義建構 — 實驗室 r28，3/3 輪次，盲測讀者；實驗室 docs/text-motion-vocabulary.md §3/§5），關鍵影格（時間軸 keys[]：每個段落至少一個 role: key — 觀看者必須閱讀或清晰看到的時刻，可選 hold；role: breakdown 用於段落內部決定運動傳遞方式的姿勢；段落之間的接縫是推導得出的，無需撰寫；實驗室 docs/agent-review-kbt-design.md §3），以及參考角色 K／工具箱（預設為 none；重複使用的生成器或元件需命名其角色 K 和所借用的面向，且必須與 open 的 --toolbox 條目匹配）。當使用者存在時，向其展示並等待確認。記錄每個您自己做出的設計決策，使用 python ~/.claude/tools/process-ledger/ledger.py add 即時記錄。該表的載體已由規則決定（使用者 2026-10-08，實驗室 docs/production-order.md 最後一節）：一個 JSON film.timeline.json 加上一個生成的唯讀時間軸頁面；批准時需要：film_type、audience、energy、rhythm_source 以及每個段落的 at、dur、freedom（locked / guided / free）、motion_intent；運鏡目標 / 方法採用固定的 D1 / D2 詞彙。該工具（tools/timeline/，實驗室 docs/timeline-layer-design.md）在其 TL-1 里程碑之前不應建構 — 在此之前請保持使用 Markdown 表格，並使用這些欄位名稱（已更改的鏡頭記錄名稱對應於該設計的 §6.1 表格）。
5. 裝置：每個裝置有其自己的基調；與步驟 1 的基調衝突的裝置將被捨棄，絕不改變基調以適應裝置（使用者 2026-09-30）。僅當有動畫意圖將其與內容連結時（§2a），才使用庫存裝置（粒子爆發、隧道、浮動卡片堆疊、故障效果、大字體設計、偽 HUD 數字）。
6. 建構（build-and-export.md §1）：一個 HTML 頁面，其每一幀都是時間的純函數（window.__setTime(t)）；無計時器、無 CSS 過渡。
7. 匯出（build-and-export.md §2）：使用 filmkit 匯出，即實驗室的 tools/filmkit/render.py（設定檔 lab-round），絕不手寫捕捉腳本。它逐幀捕捉、編碼、驗證，然後才發布輸出名稱；其 check.py 決定檔案是否可交付。正式影片需使用 @font-face 捆綁字型（一個開放授權的無襯線字體家族，涵蓋中日韓和拉丁語系，例如 Noto Sans TC；絕不依賴匯出或檢視機器上安裝的字型，實驗室 D26）。正式影片需使用 --profile delivery-web 匯出（格式欄位，加上當影片不是透過 open 開啟的工作項目或其掛載過期時的 FK-R-18 / FK-R-19 阻斷）。響度和真峰值由 check.py 作為事實報告（FK-R-17，資訊）。要根據平台對其進行判斷，請傳遞 --rules <rules file> --target <name>；目標是規則檔案中的一個聲明，包含其來源和 review_when，絕不由技能假設。
8. 審閱（build-and-export.md §3）：先看整部影片的 1 fps 靜態關鍵幀圖，然後看細節；回饋格式為「秒數 / 位置 / 變更」；一次只改一個；最多 3 輪。然後，正式影片需並排審閱：works_contract.py review <item> 將候選影片的靜態關鍵幀圖與一個由標籤選擇的、相同類型的已批准影片並排放置（或寫入 reference: none），且審閱者不是建構者（§3 第 9 項）— 在單次工作階段的乾淨上下文子代理讀取 deliver/_review/side-by-side.png，判決的第一行是 reviewer: subagent-clean-context。works_contract.py deliver <item> 會拒絕，直到 deliver/_review/verdict.md 比候選影片更新。 代理審閱路徑（使用者 2026-10-19，實驗室 docs/agent-review-kbt-design.md；使用者只提供方向和設計內容）：一個製作者子代理建構，調度的主循環工作階段進行審閱且絕不編輯影片；它們透過檔案（tools/review/review.py）溝通，閘門為 G0 分鏡腳本（製作者審閱導演）→ G1 關鍵靜態幀（僅限困難項目）→ G2 K/T 視窗（感受 = 精緻）→ G3 整部影片，每個閘門最多 3 輪；僅失敗清單、filmtoolkit 阻斷行、產品忠實度和一次見過的缺陷可能阻止；在第三輪之後，最佳版本將隨列出開放項目一起發佈，判決會說明 reviewer: dispatcher-main-loop，user_watched: no（build-and-export.md §3 第 10 項）。
9. 交付，採用以下接受的形狀。目的地：一個工作項目（<works>/films/<film_id>\\，謂詞在 <works>/README.md 中）；使用者命名的專案保留一個指標（_MOVED_<date>.txt）或僅保留其自己的書籍 / 數據。在其自己的專案中建構並被採用（生成器外部）的影片，在每一輪接受後重新進入，使用 works_contract.py adopt <same root> --id <id> --revise。每個項目的狀態：<works>/STATUS.md（首先閱讀）。實驗室輪次則前往 <lab>\experiments\<round>\。

模型（使用者 2026-10-10，實驗室 CLAUDE.md 裁決；原因 experiments/r22-haiku/REPORT.md）：Haiku 絕不製作影片，無論是作為指揮者還是上述任何步驟的工作者；元件的固定內容視為生產（實驗室 D-T12）。

此技能可能給出的判決，以及每項判決的驗證方式

-「段落變換位於小節線 / 旁白行處」→ tools/measure_product.py 或 tools/narrlock.py 作用於渲染後的 MP4（實驗室路徑）。 -「動畫在旁白下連續」→ tools/density.py 移動份額和靜止執行次數。 -「每個數字 / 功能都是真實的」→ tools/fidelity.py + build/claims.json（T05）。 -「有運鏡」→ tools/camflow.py；at_boundary 執行需要檢視影格。 -「檔案可交付」（可讀取、預期長度、大小和編解碼器、預期時有聲音、由 filmkit 根據現存於磁碟上的輸入寫入）→ tools/filmkit/check.py（render.py 自己執行）。返回碼 0 表示無阻塞行，與畫面品質無關。 -「看起來不錯 / 符合參考」→ 永遠不根據數字。需由模型讀取的靜態關鍵幀圖以及使用者親自觀看（實驗室 INV-6）。數字證明資料路徑，而非畫面品質。在代理審閱路徑上，此判決永不出現：影片為「在代理審閱下交付，未經使用者觀看」（判決 user_watched: no）。 -「響度達到目標」→ check.py --rules F --target NAME；對於沒有容差的目標，UNDET 結果是規則檔案的差距，而非通過。

交付形狀（人類必須觀看影片）

逐字貼上 check.md 的第 1-4 節（阻塞 / 確認 / 需要檢查 / 未確定）（第 5 節，作者的聲明豁免，保留在檔案中）— 對於來自 --profile delivery-web 檢查的正式影片，因此 FK-R-18（設計軸線掛載）和 FK-R-19（工作項目戳記）行也在其中，加上 deliver/_review/report.md 的 reference: 行，包括 rerun 行，放在核對清單之前；工作階段自身的問題隨後單獨列出，切勿混入貼上的章節中。在正式影片上進行的任何 transform.py 操作（normalize 自 filmkit M3 起存在：transform.py normalize <in> --out <new> --target-lufs X --true-peak Y 或 --rules F --target NAME；duck 和 convert 尚未建構）都必須先詢問，指定其將會寫入的新檔案名稱（寫入位置見下文）。