風格蒸餾 (Taste Distillation) 是做什麼的？
此獨立技能將其實現置於 scripts/ 中；後續的生成或本地剪輯編輯請使用 taste-application。請將每個命名類型保留在各自的包中。來自「Flash Ethereal」的測量結果不得被靜默地用於「Fluid Sketch」或「3D Cyber Glitch」。測量到的零值是有效數據；請將其與缺失欄位區分開來。
本地依賴項在 scripts/requirements.txt 中。另外授權的提供者工作還需要 scripts/requirements-live.txt、憑證以及明確的 TASTE_FORGE_ALLOW_LIVE=1 設置。--dry-run 模式不會讀取憑證或提交任務。切勿僅從本地端點名稱推斷工作流程已被儲存；請使用實際的提供者端工作流程或請求證據。
將參考影片轉換為風格包：一個包含測量數據和素材的資料夾，供後續階段確定性地使用。
啟用時機
- "捕捉這些片段的視覺風格" / "蒸餾出氛圍" / "使其可重複"
- 使用者有參考片段，並想要 LUT、調色或匹配的節奏
- 建立一個按類型劃分的風格庫
- 任何回答原本會是"用提示詞描述風格"的請求
核心發現
提示詞無法傳遞調色。測量可以。
在真實片段上測量：三次付費生成，隨著色彩方向升級，中間調 a* 從 +1.9 → +2.8 → +0.3，而目標是 +24.9；對比度從未離開約 19，目標是 34.7。將測量到的包套用至同一片段，在一次確定性傳遞中，色度 MAE 達到 1.88，對比度達到 33.7，而且免費。
因此，區分是：模型提供內容、動態和光影結構；包提供視覺風格。 生成提示詞中的色彩詞彙比無用更糟——它們耗費金錢，並將渲染推向 LUT 想要的基線之外。請在提示詞中明確說明："色彩：無。渲染為中性。調色在之後進行。"
包的內容
stylepacks/<類型>/
grade.json 測量的色彩統計量（見下文）
cadence.json 每個偵測到的鏡頭邊界及推導出的分佈
look.cube 33^3 LUT，直接拖入 Resolve 作為節點 LUT
spec.json 基於測量結果的 VLM 描述
grounding.txt 提供給 VLM 的測量事實
stills/ 最長鏡頭的全解析度幀（條件圖像）
plates/ 提取到黑色上的螢幕混合疊加元素
props/ 鑄造的 GLB 網格
pack.json 清單
執行方式
python mint.py --genre <名稱> --refs a.mov b.mov c.mov # 離線，無需 API 金鑰
python distill.py --genre <名稱> # 一次 VLM 呼叫
mint.py 是純數值分析——無網路、無金鑰、確定性——因此可重新生成包而非備份。
重要的測量方法
按亮度區域測量色度，而非全域
色彩特性通常存在於一個亮度區間。全域的 a*/b* 偏移在數學上無法代表分裂色調。請在區域內測量色度（L* 邊界 [0,15,35,55,75,100]）。
一個真實的簽名：在 L25 處為紫色（a +24.9, b* −17.5），兩端接近中性。只報告最暗和最亮區域會稱之為"均勻色偏"——永遠輸出整個曲線。
中位數 + MAD，而非平均值 + 標準差
真實參考集中的色度呈現強烈右偏。在一個測量片段中，中間調色度的平均值為 36.9，中位數僅為 17.5，因此基於平均值的 LUT 將色彩推到大約素材實際所需的 3 倍。
對比度應為 std(L*)，而非白減黑
白−黑範圍在幾乎所有真實片段上約為 100，無法區分任何內容。
背景佔比是頭等統計量
記錄低於 L*10 的像素比例。分佈的任何矩都無法觀察到它：一個片段可能擁有正確的平均值、標準差和色度，但其陰影已被提亮成灰色。這正是某次調色 MAE 為 1.88 / 對比度為 33.7，而實際幀卻是泥濘紫色混亂的原因。
測量前先遮蔽介面
螢幕錄製的參考帶有靜態家具——信箱黑邊、狀態欄、點讚圖示、字幕文字。所有這些都會像視覺風格一樣進入統計量：黑邊增加陰影權重，紅色心形將 a* 推向洋紅。時間變異性能乾淨地將它們分離——畫面會動，介面不會——因此無需手動裁剪。在真實素材上，這可保留約 65% 的像素。
節奏需要自適應門檻
適當的內容偵測器門檻值取決於素材：高對比度的動作參考在門檻值 30 時能清晰切割，而陰暗的參考則會將切割隱藏於門檻值之下。請遞減掃描門檻值，並取最高的、仍能找回最靈敏設定所找到的 ≥90% 鏡頭的門檻值——這樣會偏向真實切割而非雜訊。拒絕暗示荒謬切割率（>100/分鐘）的門檻值；連續的鏡頭移動會讓偵測器在每一幀都觸發。
在一次解碼傳遞中使用共享的 StatsManager 完成整個掃描。原始版本會為每個門檻值重新解碼，這在 60fps 的來源上意味著幾秒與幾分鐘的差異。
疊加圖層：素材，非螢幕截圖
靜幀是整個幀——合成一張圖只是把另一張圖片放在上面。疊加圖層是參考的圖形詞彙（光暈、條紋、故障碎片）被提取到黑色上，使其無需去背即可進行螢幕混合。
兩個陷阱，均在真實素材上遇到過：
- 絕對門檻值會失敗。 在明亮的參考中，
L>55 AND chroma>12的選取範圍約佔畫面的 90%，"疊加圖層"就變成了圖片——包括可辨識的臉。請按百分位數（約前 3%）選取，並拒絕任何覆蓋面積超過約 22% 畫面的疊加圖層。 - 按分離度排序，而非按亮度。 "明亮飽和像素的比例"會將褪色的畫面排在最前，而將帶有單一強烈光暈的黑色畫面——實際的簽名——排在倒數。請使用
p99.5(能量) / 中位數(能量)作為分數。
另外，在評分前要先遮蔽：嵌入的字體是明亮、飽和且高對比的，因此未遮蔽的執行會產生別人的標題卡的完美疊加圖層。
為 VLM 提供基礎事實
在要求描述之前，將測量結果餵入系統提示詞。未提供基礎事實時，VLM 會在具有 +24.9 a* 色偏的片段上報告"無明顯調色，中性"。提供基礎事實後，它會正確描述色偏，並獨立推斷次要強調色。
禁止使用模糊詞彙（varied, mixed, dynamic, some, often, neutral, or）——模型無法渲染"變化的光照"。在程式碼中強制執行禁令，而不僅僅在提示詞中： 在約三分之一的執行中禁令會被違反。請逐欄位重新提問，經過 N 次嘗試後保留最少模糊性的答案，而非判定失敗。
值得向使用者說明的事項：一旦規格書基於測量結果，它就不再是對測量結果的獨立檢查。
LUT 烘焙注意事項
- LUT 只能編碼逐像素的 RGB 函數。任何依賴分佈的（直方圖匹配、百分位錨點）必須在烘焙前簡化為常數，否則它會靜默地測量均勻的 LUT 網格而非片段。
cv2.cvtColor(LAB2RGB)內部會裁切，因此使用它的色域外測試會報告 0%。請手動將 Lab 轉換為線性 sRGB；一次真實測量顯示 83.3% 的點在色域外。- 使用偏移傳遞色度，而非仿射變換。仿射除以來源 σ 會過衝——在真實片段上，它將 b* 翻轉至 +11.6，而目標是 −17.5。偏移將 MAE 從 6.23 降至 2.13。
- 色域壓縮在相同 MAE 下需耗費 3.8 倍的執行時間。請設為選擇性啟用。
反模式
| 不要做的事項 | 原因 |
|---|---|
| 針對合成測試片段進行調整 | 在一個專案中導致了四種不同的錯誤結論；真實片段推翻了每一種 |
| 只相信 MAE | 1.88 的 MAE 在一個明顯錯誤的幀上看起來像成功 |
| 對色度使用平均值/標準差 | 右偏；力道約過大 3 倍 |
| 只比較端點區域 | 兩端本身構造就是接近中性的 |
| 只描述視覺風格就停止 | 規格書是針對內容和結構的；包才是針對色彩的 |
交接
包是介面。一旦它存在，請使用 taste-application 技能來針對它進行生成和組合，或將 look.cube 直接交給調色師。
附帶程式碼
此技能中的 scripts/ 是可用的實現，並非偽代碼。它沒有專案特定的假設：將其指向任何參考影片，它就會產生一個包。
pip install -r scripts/requirements.txt
export FAL_KEY=... # 僅在需要呼叫 fal 的階段需要
在 TASTE_FORGE_DRY_RUN=1 或 --dry-run 下，每個網路呼叫都會被存根，因此可以在不花費的情況下檢查計畫、提示詞、軌道佈局和清單。