簡報工具越來越快，內容責任反而更容易被藏進精緻畫面。本課先把工作拆成兩段：06 只確認受眾、主張、證據、頁面角色與人工決定；07 才處理色彩、字型、布局與檔案渲染。兩段之間要留下 CONTENT_LOCK。少了這個閘門，格式調整常會順手改掉結論，最後大家只記得投影片很好看，卻說不清楚哪一句話何時被換掉了。
簡報分成內容與呈現兩條產線
- 四份輸入
已確認會議成果、受眾與決策情境、可用證據、不可說內容。 - Presentation Brief
說清楚簡報要讓誰理解、決定或採取什麼行動。 - Deck Content
逐頁寫出角色、主張、證據、未確定事項與人工核決。 - 人工審查
確認一頁一任務、主張有依據、試行沒有被寫成制度。 - CONTENT_LOCK
記錄版本、核准日期與課堂識別碼，才交給 07。
本頁停止條件：受眾、目的、決策權、證據或期望行動缺漏時，先列出缺口。不得用常識、想像或漂亮文字補齊。
四份輸入與開工閘門
| 輸入 | 這次使用 | 不足時怎麼辦 |
|---|---|---|
| 已確認的會議主管版 | 只取可回查的決定、風險與待核決事項 | 原文無直接支持時保持待確認 |
| 已確認的會議追蹤版 | 確認工作、角色、期限與狀態 | 責任或期限未確認時不得補寫 |
| 受眾與決策情境 | 實際受眾、使用情境與時點尚未提供（OPN-04） | 受眾或決策權不清時停止排頁 |
| 可用證據與不可說內容 | deck-input-facts-v09.md | 來源表以外內容不當作已確認事實 |
這組教材只使用虛構資料。若在自己的工作情境練習，仍要先確認資料是否可進入工具、誰有權查核，以及成果能存放在哪裡。
先完成 Presentation Brief
Brief 是內容產線的開工說明。至少回答八件事：目的、受眾與已知程度、決策權、一句核心主張、最可能出現的問題、已確認證據、目前不能下的結論、期望行動與人工核決。頁數、時間與使用情境也要寫清楚。
可接受的核心主張
先用兩週測試一套可查核的會議追蹤方式，再由人決定是否值得繼續。
應退回的寫法
安禾分行將導入 AI 會議追蹤制度，並提升工作效率。
來源沒有正式導入或效率成效，不能這樣寫。
七頁敘事與 Deck Content Schema
七頁是本課的比較框架，不是所有簡報的固定答案。每一頁都要留下 slide_id，並記錄角色、標題、主要訊息、支持要點、證據、視覺意圖、未確定事項、講者備註與人工決定。
| slide_id | 頁面任務 | 內容驗收重點 |
|---|---|---|
| S01 | 目的與一句主張 | 清楚說明兩週試行與人工核決 |
| S02 | 固定欄位 | 只描述 FIC-03 的四類欄位 |
| S03 | 已確認範圍 | 不預先宣稱成效 |
| S04 | 欄位與人工查核 | 待確認標示、主持人逐項查核 |
| S05 | 未確認內容 | 責任或時間未確認時保留待確認 |
| S06 | 兩週後決定 | 由人決定繼續、修改或停止 |
| S07 | 啟動前待確認 | 日期、實際主持人與操作安排待人決定 |
內容 JSON 是格式產線唯一可引用的內容來源。若想修改主張或證據，必須回到本頁，解除鎖定、重做審查，再建立新版本。
逐頁內容審查
- 一頁只有一項主要任務。
key_message有可回查的evidence_refs。- 試行沒有被寫成正式制度。
- 未確認事項仍在
uncertainty。 speaker_note沒有藏入畫面上不能支持的說法。human_decision清楚指出由誰做成最後判斷。
人工審查通過後才進入鎖定。模型自稱「已完成查核」只能當作輸出文字，不能取代人工核准。
建立 CONTENT_LOCK
下方工作區會對正規化後的 JSON 計算 FNV-1a-32 識別碼，並產生 P06_CONTENT_LOCK.md。這個識別碼用於課堂版本辨認，不具資安簽章、作者認證或時間證明效力。
鎖定後，07 可以更換字型、色彩、留白、圖像策略、頁面布局與標示；核心主張、證據、頁面角色、結論、待確認事項、停止條件與人工核決都不能改。
內容階段 Prompt
怎麼用這段 Prompt
- 先看輸入：確認本段要求的檔案或前一階段成果已準備好。
- 再複製：如果本頁要求全新對話，務必另開視窗；否則沿用本段指定的對話。
- 送出前：確認內容是虛構或已去識別，也沒有超出公司允許的資料邊界。
- 回覆後：先查來源、停止條件與人工檢查點，通過後才保存或交給下一步。
可直接複製
先查缺口，再產生內容 JSON
你只負責簡報內容與敘事，不處理字型、色彩、版型、圖示、動畫或 PPTX。
請依序讀取：
1. 已確認的會議主管版。
2. 已確認的會議追蹤版。
3. presentation-brief.md。
4. 可用證據與不可說內容。
第一步，檢查 brief 是否缺少受眾、目的、決策權、核心主張、證據、不可說內容、期望行動、頁數或使用情境。若有缺口，只列出缺口並停止，不得補寫。
第二步，只提出七頁敘事順序。每頁列出 slide_id、role、title、key_message、evidence_refs、uncertainty 與 human_decision。不要提供視覺風格或版型。
第三步，等待人工核准頁面角色、主張與證據。未收到核准，不得繼續。
第四步，依 deck-content-schema-v09.json 產生 P06_DECK_CONTENT.json。所有重要主張必須有 evidence_refs；未確認內容保留在 uncertainty；speaker_note 不得藏入來源無法支持的內容。
第五步，依 P06_CONTENT_REVIEW.md 逐頁自查，列出退回項目。不要自行把退回項目改成通過。
禁止事項：
- 不做 PPTX。
- 不指定字型、色票、圖示或版型。
- 不增加來源未提供的數字、因果、責任、期限、規定或核准狀態。
- 不把試行寫成正式制度。
額度不足時，保存到哪裡再交接
- Brief 完成後先下載
P06_PRESENTATION_BRIEF.md。 - 七頁順序核准後保存內容 JSON，不必等待完整簡報。
- Luna 無法繼續時，把 brief、JSON、內容審查表與 handoff note 交給 Copilot。
- 兩個工具都無法使用時，以靜態 Markdown／JSON 範本完成最低成果。
切換工具時不從頭重做，也不把上一階段的待確認內容當成已核准事實。