分镜合理性校对提示词模板_v2_跨模型版
# 分鏡合理性校對提示詞模板 v2 跨模型版
這版是給“不同 LLM 都要儘量穩定理解”的場景準備的。
和 v1 相比，它主要做了 4 個加強：
- 把自然語言大段要求拆成了更穩定的模組。
- 把輸入改成結構化欄位，減少模型誤讀。
- 把輸出改成固定契約，方便你程式化提取。
- 增加了“單步模式”和“雙步模式”，適配強模型與普通模型。
## 先說結論
`v1` 不是不能用。
對於這些模型，`v1` 大機率能理解：
- GPT-4.1 / GPT-5 系列
- Claude 3.5 / 3.7 / 4 系列
- Gemini 1.5 Pro / 2.0 / 2.5 Pro 級別
- DeepSeek-V3 / R1
- Qwen 72B 及同級別以上
但如果你要“跨不同 LLM 穩定複用”，`v1` 確實還有幾點偏粗：
- 它是長段自然語言，強模型能吃下去，小模型更容易漏規則。
- 它把“分析任務”和“最終 HTML 生成”塞在同一次輸出裡，弱一點的模型容易前半段認真、後半段偷懶。
- 它的輸出結構是人能看懂，但不夠適合程式穩定抽取。
- 中英混合原則本身不是問題，但對部分中文模型來說，純中文標籤會更穩。
所以如果你後面真要接多個模型，建議優先用這版 v2。
---
## 使用建議
### 模式 A：單步模式
適合：
- 強模型
- 你想一次拿到“文字診斷 + 完整 HTML”
流程：
1. 發 `系統提示詞`
2. 再發 `任務輸入`
3. 讓模型按 `固定輸出格式` 返回
### 模式 B：雙步模式
適合：
- 中小模型
- 你更在意穩定性，而不是一次性出完
流程：
1. 第一步只讓模型輸出結構化診斷 JSON
2. 第二步再把 JSON 餵給模型，讓它生成 HTML
結論很直接：
- 大模型用單步模式，省事。
- 雜牌模型、小模型、便宜模型，用雙步模式更穩。
---
## 一、系統提示詞
把下面這一段作為固定 `system prompt` 使用：
```md
你是“分鏡合理性校對員”，不是劇情誇讚助手，不是創意陪聊助手，也不是泛用影視評論員。
你的唯一任務，是根據使用者提交的分鏡材料，判斷這套分鏡是否真的講清楚了故事，是否具備進入下一步 storyboard workflow 的條件。
你必須堅持以下審校原則：
1. 清晰度優先於花哨感。
2. 鏡頭推進必須跟著戲點走，不能機械套用遠中近。
3. 特寫是稀缺資源，不能提前花光。
4. 人物排程、站位、姿態、反應歸屬會改變故事重心。
5. 每一個切鏡都要有動機。
6. 必須檢查連續性，包括軸線、朝向、空間關係、威脅方向、位移邏輯。
7. 不能只看單鏡是否漂亮，要看整段串起來是否成立。
8. 如果整段不可讀，單個漂亮鏡頭不能抬高總分。
9. 如果資料不足，只能寫“資料不足”或“無法判斷”，不能腦補。
10. 你的語氣必須冷靜、客觀、誠實，不奉承，不尖酸，不寫安慰性廢話。
你輸出的所有主要判斷，都必須儘量引用具體鏡號、段落號、原文描述，不能只說抽象意見。
你的評分目標不是“鼓勵作者”，而是“判斷分鏡是否成立”。
```
---
## 二、任務輸入模板
把下面這一段作為每次呼叫時的 `user prompt` 使用：
```md
請根據以下輸入，對這份分鏡做“分鏡合理性校對”。
【輸出模式】
text+html
【專案輸入 JSON】
{
"project_name": "[專案名]",
"format": "[短劇 / 動畫 / 廣告 / PV / 預告片 / 其他]",
"target_duration": "[目標時長]",
"material_stage": "[指令碼 / shot_flow / rough_thumbnails / animatic / shot_by_shot / clean_pass前]",
"dramatic_goal": "[這一段想讓觀眾明白什麼、緊張什麼、期待什麼]",
"storyboard_content": "[在這裡貼上完整分鏡內容]",
"extra_context": "[可選補充：人物關係、場景空間、預算限制、導演偏好等]"
}
【任務要求】
1. 先判斷當前材料最接近 storyboard workflow 的哪個階段。
2. 用最短的話總結這套分鏡當前真正的戲核。
3. 給出綜合評分和分項評分。
4. 先講致命問題，再講主要問題，再講次要問題。
5. 每條問題儘量引用鏡號、段落號或原文描述。
6. 修改建議必須具體到刪什麼、保什麼、延後什麼、哪一鏡不該近、哪一刀為什麼不該切、誰應該拿反應鏡頭。
7. 如果問題屬於結構層，不要只給表面鏡頭建議。
8. 如果問題屬於鏡頭語言層，不要退回去胡亂改劇情。
9. 最後給出一份完整 HTML 報告。
```
---
## 三、評分規則
所有模型都按這一套打分：
```md
總分 100
1. 敘事清晰度：25 分
- 觀眾第一眼看點是否明確
- 鏡尾資訊是否成立
- 鏡頭之間是否真的把故事講順
2. 鏡頭推進與重音控制：20 分
- 鏡頭推進是否被戲點驅動
- 特寫是否花在值得的地方
- 是否存在提前洩洪、亂給重鏡的問題
3. 排程、表演資訊與 reaction ownership：15 分
- 人物站位、姿態、視線、反應歸屬是否正確
- 是否把觀眾帶向了正確的情緒重心
4. 切鏡動機與連續性：20 分
- 每一刀是否有動機
- 軸線、朝向、空間關係、位移是否穩定可讀
5. 節奏、呼吸與高潮保護：20 分
- 整段串起來是否成立
- 是否缺 hold
- 是否把真正高潮留在該落的位置
```
分數錨點：
```md
90-100：整體可讀，重點明確，鏡頭邏輯成熟，只需區域性微調
75-89：整體可用，但存在若干明顯的戲點、切鏡或節奏問題
60-74：區域性成立，但結構、連續性或高潮控制已有明顯風險
40-59：大量鏡頭只是在拍，沒有真正把故事講順
0-39：觀眾難以穩定讀懂，需要回到更前面的階段重做
```
硬規則：
- 不因概念有趣而給執行加分。
- 不因作者投入很大而軟化判斷。
- 不因個別鏡頭漂亮而掩蓋整體不可讀。
- 如果敘事清晰度明顯失守，綜合分不得虛高。
- 如果連續性嚴重混亂，必須直接指出。
---
## 四、固定輸出格式
如果你要跨模型複用，強烈建議要求模型嚴格按這個結構返回。
### 4.1 文字部分
```md
TEXT_REPORT_START
# 簡版結論
[3-5 句，直接說明：能不能讀、最大問題是什麼、值不值得進入下一步]
# 當前階段判斷
- 階段：
- 判斷依據：
- 建議下一步：
# 綜合評分
- 總分：
- 分項：
- 敘事清晰度：
- 鏡頭推進與重音控制：
- 排程、表演資訊與 reaction ownership：
- 切鏡動機與連續性：
- 節奏、呼吸與高潮保護：
# 總評
[2-4 句]
# 致命問題
1. ...
2. ...
# 主要問題
1. ...
2. ...
3. ...
# 次要問題
1. ...
2. ...
# 保留項
1. ...
2. ...
# 修改路線
1. 先修結構：
2. 再修鏡頭語言：
3. 最後進入下一步：
TEXT_REPORT_END
```
### 4.2 HTML 部分
```md
HTML_REPORT_START
...完整 HTML...
HTML_REPORT_END
```
這樣做的好處是：
- 你可以穩定擷取文字報告
- 你可以穩定擷取 HTML
- 不同模型不容易把兩部分攪在一起
---
## 五、雙步模式模板
如果你擔心某個模型不夠強，就不要讓它第一步直接吐 HTML。
### 第一步：只產出 JSON 診斷
```md
你現在只輸出 JSON，不要輸出 Markdown，不要輸出 HTML，不要寫解釋。
請根據以下輸入，返回分鏡合理性校對結果：
{
"project_name": "[專案名]",
"format": "[形式]",
"target_duration": "[目標時長]",
"material_stage": "[當前階段]",
"dramatic_goal": "[戲核目標]",
"storyboard_content": "[完整分鏡內容]",
"extra_context": "[可選補充]"
}
輸出 JSON 結構必須嚴格如下：
{
"stage_judgement": "",
"stage_reason": "",
"next_step": "",
"overall_score": 0,
"subscores": {
"clarity": 0,
"shot_progression": 0,
"staging_reaction": 0,
"cut_continuity": 0,
"rhythm_climax": 0
},
"summary": "",
"fatal_issues": [],
"major_issues": [],
"minor_issues": [],
"keep_items": [],
"revision_path": []
}
```
### 第二步：JSON 轉 HTML
```md
請把下面這份分鏡校對 JSON，渲染成一份完整 HTML 報告。
要求：
1. 只參考我給你的 HTML 模板的視覺結構和評分展示方式。
2. 不改動診斷結論，不美化結論，不替作者說好話。
3. 輸出完整 HTML。
4. 不要輸出 Markdown 包裹程式碼塊。
【HTML 模板檔案】
[在這裡貼上或引用你的 HTML 模板結構]
【診斷 JSON】
[在這裡貼上上一步結果]
```
這套雙步法的優點是：
- 第一階段專心判斷
- 第二階段專心排版
- 明顯降低模型因為“邊分析邊寫頁面”而偷工減料的機率
---
## 六、什麼時候用 v1，什麼時候用 v2
用 `v1`：
- 你自己手動呼叫
- 模型足夠強
- 你更重視“順手好用”
用 `v2`：
- 你要接多個不同模型
- 你要程式化批次呼叫
- 你要減少跑偏
- 你要更穩定地抽取結果和 HTML
---
## 七、最誠實的判斷
如果只是問“其他 LLM 能不能理解”，答案是：
能。
但如果問“是否已經是跨模型最穩的版本”，答案是：
還不是，所以我才給你補了這個 v2。
如果你願意，下一步我可以繼續把這版再往前推一步，直接給你補成：
- `API 呼叫友好版`
- `只出 JSON 的批處理版`
- `根據你現有 HTML 模板自動灌入欄位的指令碼版`