Pilot Review Report

案例：20260727-graphic-tee-couple（âme soeur 早餐狗狗短版 BOXY 短袖 tee，情侶穿搭 20 秒）

執行日：2026-07-27　15:30 至 20:35

這份是一次性的量測報告，不是規則正本。功能開發維持凍結，本報告不包含任何程式修改。

0. 一句話結論

這支片真的剪出來了，但不是靠這套流程剪出來的。

治理層（reels/，8,851 行）在 1 小時 47 分內產生了 13 筆 event、7 個 gate 判定、9 個 FAIL。 真正把畫面做出來的那 3 小時，它一筆紀錄都沒有，因為剪片層根本不會通知它。

而且治理層檢查的字幕是一份手維護的鏡像檔（9 條），實際出貨的草稿有 17 條。 有 8 條字幕從頭到尾沒有任何一關看過。

1. 每一步實際花費時間

時間來源：events.json 的 at 欄位、檔案 mtime。標「無 event」的是 timeline 撈不到、我手記的。

總計約 5 小時。 其中：

• 有 event 紀錄的區間：15:37 至 17:24，1 小時 47 分
• 沒有任何紀錄、但真正在產出畫面的區間：17:24 至 20:35，3 小時 11 分

預測錯在哪

我開拍前寫死的預測是「最大成本是手改 inventory.json（30 分以上）」。錯了，只花 4 分鐘。

真正的成本在三個地方，兩個我完全沒預測到：

1. 腳本 41 分鐘（預測 2 分）。因為第一版我沒看完 8 支素材就寫，顏色接不起來，Codex 來回 7 輪。
2. 草稿 metadata 汙染 40 分鐘（沒預測到）。shutil.copytree 把 BOXY 母版的 draft_id、封面、雲端同步欄位整包帶過來，CapCut 清單顯示成 BOXY 的縮圖、347.5M、00:22。
3. 預覽 render 60 分鐘（不在流程裡）。因為 CapCut 草稿不是可以直接看的東西，Kim 要看成品必須另外 render 一支 MP4，而整套流程沒有這一步。

2. 哪些步驟有產生真實價值

只列「這次真的擋到事情或改變了結果」的，其他一律不算。

共 5 項。注意其中 G1 的價值來自「人真的看了素材」，不是來自 inventory.json 有沒有填滿欄位。

3. 哪些步驟只是增加操作成本

4. 哪些 Gate 對這支影片不適用

這支片沒有口白（實測音軌 mean −37 至 −46 dB，Kim 確認「沒口白」）。

G3 為什麼是設計錯誤，不是這支片的問題

實測數字：

generatorPath   : ame-soeur-video/build_graphic_tee_couple.py
generatorSha256 : 0561362617ed2931...
registrySha256  : f38a271e7b9b9b8d...
hashMatches     : False

G3 的判準是「生成器的 sha256 要等於母版 registry 裡的 sha256」。

但每支新片本來就是一支新的 Python 檔，hash 永遠不可能對得上。 唯一能過的方式是「跑母版本人那支檔案」，那等於每支片都剪出一模一樣的內容。

這在開拍前的 PILOT.md §2 就預測到了，實測完全吻合。G3 用 hash 保護的是「檔案沒被改過」，但要保護的其實是「風格沒有每支重新發明」。這兩件事無關。

5. 哪些資料結構沒有被真正使用

5.1 空欄位普查（實測）

case.json 空的 21 欄：historicalAcceptance、deliverableUnderCurrentRules、blockedReason、media.archivedMedia、edit.voiceWavRef、musicRef.artist、G3/G4/G6/G7/G8 的 findingCount、G5 與 G9 的 ranAt/summary/findingCount、artifacts.playback、delivery.confirmedBy、delivery.confirmedAt、kimFeedback[]。

dialogueqa.json 整段全空的：semanticReview（4 欄）、humanConfirmation（4 欄）。

inventory.json 是唯一 0 空欄的檔案，也是唯一真的改變了結果的檔案（見第 2 節）。這個對比本身就是答案。

5.2 最嚴重的一個：字幕檢查的是鏡像檔，不是實體

captions.json（治理層讀的）    : 9 條
draft_content.json（真的出貨的）: 17 條

G4 和 G6 檢查的是我手維護的一份鏡像檔。實際草稿裡有 8 條字幕，從頭到尾沒有任何一關看過。

這代表：gate 可以判 PASS，而真正會播出去的東西是錯的。 這不是這支片的意外，是架構問題，因為治理層從設計上就不讀草稿本身，只讀人手填的 JSON。

同樣的問題也在 G3：generatorPath 只是一個字串欄位，填錯了工具不會知道。

5.3 G6 字寬公式：4 個 FAIL，4 個都是誤判

"情侶裝一定要"    px 1053.4 / 安全寬 864.0  size 19
"看兩套穿法"      px  876.1 / 安全寬 864.0  size 19
"也不用穿成同一套" px 1037.3 / 安全寬 864.0  size 14
"傳給想一起穿"    px  942.5 / 安全寬 864.0  size 17

這 4 條我在預覽影片裡都親眼確認過，畫面上完全在安全區內，一條都沒有超出。

根因：PX_PER_SIZE = 8.8 這個係數是拿 Staatliches（拉丁字型）量出來的，套到中文差了將近兩倍。 誤判率 4/4 = 100%。

6. 四套工具目前的輸入、輸出與斷點

三個真正的斷點

斷點 A：治理層 ↔ 草稿（最嚴重） 治理層看的是鏡像檔，不是實體。字幕 9 對 17。generatorPath 是字串。 後果：gate 判 PASS 不代表出貨的東西是對的。

斷點 B：剪片層 ↔ 治理層 build_graphic_tee_couple.py 跑完產出草稿，不寫任何 event。 後果：timeline 對「真正在剪片的那 3 小時」完全是盲的，記錄的全是治理動作本身。

斷點 C：人 ↔ 人 Codex 跟我用同一批素材、同一個 Drive 資料夾，彼此看不見對方在做什麼。 後果：同一支片被剪了兩次，直到你貼出 CapCut 截圖才發現。 這是這次最貴的一筆浪費，而整套流程沒有任何一關會問「這支片是不是已經有人剪過了」。

7. 保留／簡化／封存／刪除清單

這份清單是提案，等你核准後才動手。封存一律用 git mv 移到 _archive/，不刪檔。

保留（不改）

簡化

封存（移到 _archive/，不刪）

刪除

預估規模變化：

8. 一條新的最小主流程設計

方向照你定的：

素材 → edit.json → 通用 build.py → CapCut 草稿 → 三項必要機械檢查 → 人工實播 → 可交付

8.1 edit.json（每支片唯一的一份檔案）

取代現在的：一支 Python driver ＋ case.json ＋ inventory.json ＋ captions.json。

{
  "id": "20260727-graphic-tee-couple",
  "title": "âme soeur｜圖T情侶穿搭｜兩套版",
  "author": "claude",              // 只允許一個剪輯作者，開檔即登記
  "hasVoiceover": false,           // false 時口白相關檢查一律 NOT_APPLICABLE
  "preset": "layered-shirt-v2",    // 風格母版，指向 presets/*.json
  "music": "haul-upbeat.mp3",
  "sources": [                     // G1：每支素材必須有 reviewed 與 verdict
    {"file": "1781668634150.MP4", "reviewed": true, "verdict": "adopt", "note": "深灰＋深藍 BREAKFAST tee"}
  ],
  "timeline": [                    // 每段用哪支、切哪一段、放多久
    {"src": "1781668634150.MP4", "in": 1.2, "dur": 1.5}
  ],
  "captions": [                    // 唯一一份字幕來源，build 與檢查都讀這份
    {"text": "情侶裝一定要", "at": 0.0, "dur": 0.75, "size": 19, "y": 0.72}
  ]
}

關鍵差別：captions 只有這一份。 build.py 拿它產草稿，檢查也拿它跟草稿實體對照。不會再有 9 對 17。

8.2 build.py（一支，取代 34 支 driver）

python reels/build.py cases/<id>/edit.json

• 讀 preset 決定字型／顏色／字級級距／安全區
• 產 CapCut 草稿
• 產完自己補上乾淨的草稿身分：新 draft_id、正確 tm_duration、重算 size、清空雲端欄位、用自己的畫面產封面（這次踩到的坑直接內建成步驟，不是靠人記得）
• 產完自己寫一行 timeline（補上斷點 B）
• 同時 render 一支預覽 MP4（補上「Kim 看不到成品」這個缺口）

8.3 三項必要機械檢查（全部直接讀 draft_content.json，不讀鏡像）

沒口白的片，口白相關檢查一律回 NOT_APPLICABLE，不是 FAIL、不是 NOT_RUN。

8.4 人工實播

python reels/build.py playback <id> --by Kim --result ok --note "整支看過，字幕都在安全區"

寫下四件事：誰、何時、看的是哪一版（草稿 draft_content.json 的 sha256）、結果。 草稿變了就自動失效，但不需要 session binding 那一整套四種 hash。

8.5 交付

三項機械檢查全過 ＋ 有一筆對得上目前版本的實播紀錄 ＝ 可交付。

9. 這次沒有回答的問題

誠實列出來，不假裝報告是完整的：

1. autocut.py 那套（481 行、4 個 .bat）這次完全沒碰，不知道它現在還能不能跑、值不值得留。要另外測。它是唯一「丟檔案進去就有東西出來」的介面，可能反而是新流程該學的對象。
2. Codex 的剪片路徑我沒看過（那支草稿在保護清單上，我沒有讀它的授權）。所以「一個作者」這條規則實際上要怎麼落地，還沒跟 Codex 那邊對過。
3. G9 的價值沒有被驗證，因為這次沒有人真的做完實播。我跳過它、而且因此報錯了，這反過來證明它有價值，但這是反證不是正證。
4. 新流程的實際耗時沒有估。要等真的做出來跑一支才知道有沒有比 5 小時快。

10. 待你裁決

• 這份報告 ＋ 第 7 節的清單，核准哪些、退回哪些
• 封存動作要不要現在做（git mv 到 _archive/，可完全回復）
• 新主流程要不要照第 8 節做，還是先只做其中一段

在你回覆之前，我不動任何程式。

量測人：Claude｜2026-07-27｜資料來源：cases/20260727-graphic-tee-couple/events.json、preflight.json、檔案 mtime、CapCut 草稿實體