用 Codex 製作風格一致的 AI 簡報：YAML Image Deck 實作教學

- 從教材、設計規格與黃金樣張，到可編輯 PPTX 的分階段製作流程。 -

不用先學 YAML，也不用自己寫生圖提示詞。你要準備的是簡報需求、可靠內容與視覺方向，再讓 Codex 分階段完成。

第一次建議拿一個小單元練習。本文以「8 頁、20 分鐘的小店社群行銷教學」示範，保留可直接貼進 Codex App 的各階段提示詞，文末附練習素材包。

本文依 2026 年 10 月 11 日可查到的 YAML Image Deck 原專案 與官方文件整理。工具能力與額度可能調整；需求表、案例、試批頁數與重試次數屬於本教學建議。

很多人第一次用 AI 做簡報，會直接下指令：

幫我把這份教材做成漂亮的簡報。

但這句話把好幾個不同的任務混在一起：整理內容、安排教學順序、設計版型、生成圖片、組裝簡報，以及檢查成品。

這篇教學把它拆開：

準備資料 → 確認大綱 → 建立規格 → 確認樣張 → 分批生成 → 組裝驗收 → 局部修改。

YAML Image Deck 的角色，是讓 Codex 把整份簡報的視覺規則、版型與逐頁內容寫成規格，再依規格生成。它不是一套安裝完就能獨立運作的簡報軟體，也不會光靠 YAML 就自動產生 PPTX。最後仍需要實際可用的生圖與簡報組裝工具。

一、先決定：你要「圖片式簡報」，還是「文字可修改的簡報」？

這會影響後面整個流程。

這篇教學選 plate。

例如投影片寫著「發布前，檢查三件事」，日後想改成「發布前，先核對這三點」，應該只需要修改文字，不必整張重新生圖。

但要注意：

plate 是「底圖仍是圖片，文字另外編輯」，不是把 AI 插畫自動變成可拆解的 PowerPoint 圖形。

原專案也要求，在精確性重要時，把公式、圖表、數字等內容保留為原生可編輯元素。參見 原專案 SKILL.md。

這篇範例的設定

我們要做的是：

給小店老闆的 AI 社群貼文入門
8 頁，20 分鐘，台灣繁體中文，16:9，文字可修改。

以下的店家與案例都是教學用的虛構資料，不代表任何真實商家的活動或成效。

二、階段 0：先讓 Codex 準備工作環境

你先做什麼？

在 Mac 建立一個獨立資料夾，例如：

1

yaml-image-deck-starter

再用 Codex App 開啟這個資料夾。

你也可以直接使用文末附的練習素材包，解壓縮後開啟，不用自己一個一個建立檔案。

先在獨立練習專案測試，不要一開始就要求 Codex 改動既有的正式教材專案。

Skill 安裝在哪裡才找得到？

作者 README 使用的是 .codex/skills 安裝方式；但目前 OpenAI 官方文件列出的本機 Skill 搜尋位置，包含專案內的 .agents/skills，以及使用者層級的 ~/.agents/skills。

這篇採用專案內安裝，比較容易知道這個 Skill 是為哪份教材服務。已經裝過的人，先檢查實際位置，不必再裝第二份。官方也說明，同名 Skill 不會自動合併；安裝後沒有出現時，可以重新啟動 Codex。 OpenAI Developers

貼給 Codex：環境準備提示詞

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50

請幫我準備 YAML Image Deck 的練習環境。
這一階段只檢查環境與安裝 Skill，不要開始生圖。

我的環境是 macOS，使用 Codex App。

請先回報目前工作區的絕對路徑。
所有專案檔案都放在目前工作區，不操作其他專案。

請依序處理：

1. 檢查是否已安裝 yaml-image-deck Skill。
   若已安裝，讀取並回報實際路徑與來源，不重複安裝或覆蓋。

2. 若未安裝，先檢視這個專案的 README、SKILL.md 與腳本：
   https://github.com/mathruffian-dot/yaml-image-deck

   先回報來源版本、預計安裝方式、讀寫路徑、網路目的地與憑證需求。
   需要 git clone 後執行腳本、npx skills add 或 sudo 時，
   先取得明確同意，再繼續安裝。

   審查與必要授權完成後，將其中的 skills/yaml-image-deck 安裝到：
   .agents/skills/yaml-image-deck/

   記錄安裝來源與版本資訊。

3. 檢查目前環境是否具備：
   - 可以實際呼叫的內建生圖工具。
   - Python 3。
   - PyYAML 與 Pillow。
   - 可以建立 PPTX 的工具。
   - 可以將 PPTX 渲染成圖片的工具。
   - Skill 指定的繁體中文圓體。

4. 缺少 Python 套件時，安裝於本專案的 .venv。
   缺少系統軟體或字型時，先回報。
   不要自行啟用 API 計費。

5. 建立下列資料夾，已有內容不要覆蓋：
   sources/
   prompt/
   slides/images/
   slides/previews/
   output/
   qa/

把檢查結果寫入 qa/environment.md。

請分清楚：
「工具存在」、「已執行測試」、「尚未測試」。
不要把尚未測試的能力直接寫成通過。

這一步要看什麼？

不是看到「安裝成功」就往下走，而是要看清楚這三件事：

有沒有讀到 Skill？能不能生圖？能不能組裝與檢查 PPTX？

原專案預設使用 Codex 內建生圖，並沒有要求使用者一開始就申請 API 金鑰。但這不等於無限免費；官方文件說明，內建生圖會計入 Codex 的使用額度。 ChatGPT Learn

三、階段 1：準備要交給 Codex 的三種資料

不用先寫好每一頁，但一定要說清楚：這份簡報要教誰、教會什麼，以及哪些資料可以使用。

我建議準備三種內容。

第一種：簡報需求表

這張表的作用，是避免 Codex 把「給新手的實作課」做成「給主管看的產業趨勢報告」。

第二種：真正要教的內容

你原本的 PPT、PDF、文章、筆記，都可以作為素材。

但我建議第一次只放跟這次主題直接相關的一小批資料，不要把整個歷年教材資料夾全部丟進去。

例如：

1
2
3
4

sources/
├── 社群行銷舊教材.pptx
├── 這次要講的重點.md
└── 店家案例資料.md

如果沒有舊教材，也可以先寫一段這樣的原始內容：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

本次要教的內容：

一、請 AI 寫貼文前，先提供四種資訊：
對象、目的、事實、格式。

二、建議流程：
提供資料 → 產生草稿 → 人工核對 → 調整發布。

三、虛構案例：
店名：晨光咖啡。
商品：新品燕麥拿鐵。
受眾：附近上班族。
目的：邀請讀者留言分享喜歡的咖啡口味。
語氣：親切自然。
格式：120–180 字，最後一句提問。

沒有提供價格、優惠、日期、產地或健康效果，
所以不能自行添加。

四、發布前檢查：
事實是否正確、語氣是否自然、行動是否清楚。

五、最後讓學員用自己的產品資料練習。

這樣就已經能開始規劃，不需要先寫成完整文章。

第三種：視覺方向

不用懂設計名詞，也能寫得很清楚：

奶油白底、深藍綠主色、橘色重點。
插畫乾淨、有一點紙感，適合成人上課，不要像幼兒教材。
文字要大、留白要夠，不要滿版小字，也不要大量霓虹科技元素。

有參考圖片時，再補一句：

只參考這張圖的配色與插畫感，不要複製裡面的品牌、人物或文字。

貼給 Codex：內容整理提示詞

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

這一階段只整理教學內容，不做設計、不生圖。

請先讀取：
- prompt/brief.md：簡報需求
- prompt/brand.md：視覺方向
- sources/：原始教材與案例

先列出實際存在的檔案。
不要假設不存在的附件已經提供。

請把資料整理成 prompt/content-notes.md，分成：

1. 本次一定要教的觀念。
2. 可直接使用的範例。
3. 適合放進練習的內容。
4. 與本次主題無關、可以略過的內容。
5. 資料不足、矛盾或需要查證的地方。

如果讀取 PPT 或 PDF：
- 保留來源檔名與頁碼。
- 不要只靠萃取文字猜測圖表。
- 無法讀取的頁面要明確列出。
- 不要修改原始檔案。

請區分：
「來源提供的事實」、「教學用虛構案例」與「你的建議」。

不要自行補出價格、優惠、日期、統計數字或成效。
完成後停在內容審查，不開始製作簡報。

這一步你要確認什麼？

最重要的是：

Codex 整理出來的內容，真的是你這次要教的東西嗎？

不要等到畫面很漂亮之後，才發現核心觀念講錯了。

四、階段 2：先確認逐頁大綱，不要急著生圖

這一步不是單純列八個標題，而是決定：

每一頁要讓學員理解什麼。

我們這份範例可以安排成：

關鍵：把「投影片文字」與「講者要說的話」分開

例如第 5 頁：

畫面上：

先填這四格
對象｜目的｜事實｜格式

講者備註裡：

對象是希望誰看到；目的不是一定要成交，也可以是讓讀者留言；事實只能放已確認的商品資訊；格式包含語氣、字數與結尾行動。

這樣才不會變成把講義全文塞進投影片。

貼給 Codex：大綱規劃提示詞

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

請依照 prompt/brief.md 與已核對的內容，
規劃 8 頁、20 分鐘的教學簡報。

每一頁都要列出：
- 頁碼與用途。
- 唯一的核心訊息。
- 精確的上版文字。
- 圖像應該表達什麼。
- 資料來源。
- 講者備註。
- 建議講解或練習時間。

本次內容密度建議：
- 標題盡量控制在 16 個中文字內。
- 一般內容頁以 3 個重點為原則。
- 四格分類與四步流程，可以依實際結構呈現。
- 完整解釋與長篇提示詞放在講者備註或練習講義。

不要為了湊頁數重複內容。
不要自行補出來源沒有提供的事實。

輸出：
prompt/outline.md
prompt/speaker-notes.md

現在不要生圖。
先讓我確認教學順序與每頁文字。

這裡的字數與頁數，是這份練習的建議，不是 Skill 的硬性限制。

大綱看完沒有問題後，你再回覆：

大綱與文字確認，請以這個版本進入設計規格階段，先不要生圖。

五、階段 3：讓 Codex 把白話需求轉成 YAML

YAML 到底是什麼？

在這個工作流程裡，你可以把它理解為：

一份有固定欄位的簡報製作規格。

它會記錄受眾、頁數、配色、字體方向、版型，以及每一頁要出現的內容。

但原作者特別強調，YAML 是設計契約，不是精確到每個像素的渲染程式碼。因此，寫好規格之後仍然要生成、檢查與調整。欄位定義可對照 原專案 schema。

你只需要看懂幾個欄位

原專案的版型選擇是依「資訊關係」分派，例如比較、流程、分類、案例、總結，而不是每頁隨機換裝飾。

例如第 3 頁的規格片段可能長這樣：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

# 這是單頁示意片段，不是完整可執行的 spec.yaml。

page: 3
role: "comparison"
core_point: "提供清楚資訊，讓草稿有明確方向"
semantic_structure: "contrast"

layout:
  id: "comparison_split"
  variant: "left_right"

visible_text:
  title: "同樣請 AI，差在資訊"
  labels:
    - "模糊：幫我寫貼文"
    - "清楚：對象＋目的＋事實＋格式"

visual: "左右比較，左側凌亂紙片，右側整理好的資料卡。"
output: "slides/images/page_03.png"

你不需要自己寫這段。讓 Codex 依原專案模板產生即可。

plate 還需要多一份「文字放哪裡」的規格

例如標題放在上方、比較文字放左右兩欄，這些都需要有明確位置。

原專案提到 overlay_blocks，但沒有提供一套完整、通用的文字疊加渲染器。實務上要讓 Codex 配合你當前使用的簡報工具，補上文字方塊的位置、大小、字級與對齊。

貼給 Codex：設計規格提示詞

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

使用 $yaml-image-deck。
這一階段只建立設計規格，不生圖。

請讀取：
- 已核准的 prompt/outline.md
- prompt/brand.md
- 這個 Skill 的 spec-template.yaml
- references/schema.md
- references/layout-library.md
- references/prompting.md

請建立 prompt/spec.yaml，設定：
- output_mode: plate
- planning_mode: yaml_spec
- generation_strategy: sequential
- style_lock: golden_sample
- 16:9
- 台灣繁體中文

每頁要依資訊關係選擇原專案支援的 layout.id。
相同版型不要連續使用超過兩頁。

沒有真正生成並核准樣張之前，
design_system.style_reference 保持空白，
不要假造一個已存在的參考圖片路徑。

plate 模式的 visible_text 是後續要疊加的文字，
不能要求生圖工具把這些字畫進底圖。

另建立 prompt/overlay-plan.yaml：
定義每頁文字內容、位置、尺寸、座標單位、
字型、字級、顏色與對齊方式。

這份 overlay-plan 是本專案的組裝規格。
請說明實際簡報工具如何讀取，
不要假稱原專案已經內建完整的文字疊加功能。

檢查 Skill 指定的圓體是否已安裝；
缺少時先回報，不要偷偷換成其他字型。

執行原專案的 validate_spec.py，
保存執行結果。

完成後顯示設計摘要與待確認事項，不開始生圖。

這一步你要看什麼？

不必逐行閱讀 YAML。請 Codex 用白話回報：

這份簡報用什麼配色？字體是否可用？
每一頁為什麼用這個版型？
哪些內容是圖片，哪些內容可以編輯？

這幾件事講得清楚，就比較容易發現方向是否跑掉。

六、階段 4：只生成一張黃金樣張

先不要做整份簡報。

這裡的「黃金樣張」，就是你核准的視覺基準。後面各頁參考它的配色、插畫材質與視覺語言，而不是重新猜一次。

原專案要求先生成一張代表性的內容頁，確認後再存入風格參考路徑。

為什麼這次選第 3 頁，不選封面？

這是我的實作建議：第 3 頁同時有標題、比較文字、插畫與留白，比只有大標題的封面更能測試整套規則。

封面好看，不代表一般內容頁也放得下。

貼給 Codex：黃金樣張提示詞

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

使用 $yaml-image-deck。

這次只製作第 3 頁作為黃金樣張，
不要生成其他頁。

請讀取：
prompt/spec.yaml
prompt/overlay-plan.yaml
以及相關 Skill 規則。

先編譯這一頁的生圖提示詞，儲存為：
prompt/image-prompts/page_03_v01.md

提示詞必須包含：
- 完整 16:9 投影片底圖，不是螢幕或投影幕示意。
- 左右各 6%、上下各 10% 的重要內容安全邊界。
- 左右比較的構圖與閱讀順序。
- 左側是凌亂紙片，右側是整理好的資料卡。
- 為標題與兩側文字保留安靜、清楚的區域。
- 沿用已確認的配色與插畫風格。
- 不生成文字、偽文字、Logo、頁碼或浮水印。

使用目前實際可用的內建生圖工具，
產生無字底圖並保存到：
slides/images/page_03_v01.png

接著依規格疊加原生可編輯文字，
輸出：
output/golden-sample_v01.pptx

再從該 PPTX 渲染完整預覽：
slides/previews/page_03_v01.png

請讓我同時檢視：
1. 無字底圖。
2. 疊上文字後的完整投影片。

若無法生圖或渲染 PPTX，明確回報未完成項目。
不要以其他結果冒充。

完成後停下，等我核准。

你怎麼知道樣張可以通過？

不要只看「圖片漂亮不漂亮」，而要看完整頁面：

標題好不好讀？文字區夠不夠？圖像有沒有幫助理解？是不是你想要的成人教學風格？

plate 模式尤其要看含字預覽。光核准一張漂亮底圖，還不知道文字疊上去會不會擠。

不滿意時，這樣改

不要只說：

再漂亮一點。

改成：

1
2
3
4
5
6
7
8
9
10

請只修改第 3 頁樣張：

保留目前配色、左右比較結構與標題文字。

右側插畫縮小一些，增加文字留白。
移除右下角與教學內容無關的裝飾。
標題提高可讀性，但不要超過安全邊界。
整體更像成人工作坊教材，不要增加可愛玩偶。

請輸出 v02，保留 v01，不要改其他頁。

真正看過、同意之後，再鎖定樣張

1
2
3
4
5
6
7
8
9
10
11
12
13

我已檢視並核准第 3 頁這個版本的底圖與完整版面。

請先確認實際檔案存在。
保留原始版本，將核准底圖另存為：
slides/images/page_03.png

將 design_system.style_reference
指向這張真實存在的無字底圖。

把這次核准與檔案路徑記錄到 qa/approval-log.md。

後續頁面參考配色、材質與插畫語言，
但不要全部複製第 3 頁的左右比較版型。

這段核准提示詞，要在你真的看過圖片之後才貼。

七、階段 5：分批生成，不要一次賭完整份

樣張通過後，我建議先做第 4、5 頁。

因為這兩頁分別是「流程」與「四格分類」，剛好能測試：

同一套風格，換成其他版型之後是否仍然成立？

原專案預設循序生成；只有使用者明確要求，而且環境允許時，才使用多代理平行生圖。第一次練習不需要先開平行模式。

貼給 Codex：試批生成提示詞

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

使用 $yaml-image-deck。

沿用已核准的：
prompt/spec.yaml
prompt/overlay-plan.yaml
第 3 頁黃金樣張底圖。

請先確認參考圖片實際存在並讀取。
需要把它提供給生圖工具作為參考時，請實際提供；
不能只在文字裡寫路徑，就宣稱已參考圖片。

這次只生成第 4、5 頁，一頁一次呼叫。

要求：
- 維持共同配色、材質與插畫語言。
- 第 4 頁採流程版型，第 5 頁採四格分類。
- 不要把每一頁都做成左右比較。
- 底圖不生成任何文字。
- 不修改已核准的上版文字。

每頁都要保存：
- 實際使用的生圖提示詞。
- 原始底圖。
- 用於組裝的最終底圖。
- 疊上原生文字後的完整頁面預覽。

記錄實際圖片尺寸。
若不是 16:9，只能在不損失重要內容的前提下裁切或補邊；
不要硬拉伸。

檢查物件數量、留白、風格與文字區。
失敗時只重做有問題的頁面。
本次每頁最多重試 2 次，仍不合格就回報問題。

完成兩頁後停下，先讓我檢查。

「每頁最多重試兩次」是這篇教學的成本控制建議，不是原專案的限制。

第 4、5 頁也通過後，再貼：

試批通過。請沿用相同規格完成第 1、2、6、7、8 頁，不重做已核准的第 3、4、5 頁。

額度不足怎麼辦？

保存已完成頁面、規格與待辦即可，不要為了湊完頁數，偷偷改成另一種製作方式。

例如可以要求：

生圖額度不足時，請保留成果並列出缺頁。不要自行改用付費 API，也不要把程式畫出的替代插畫宣稱成原定的 AI 生圖成果。

八、階段 6：組裝 PPTX，並檢查「真正交付的檔案」

這個階段最容易出現一種誤會：

原始圖片看起來正常，所以 PPTX 一定正常。

但你最後拿去上課的是 PPTX，因此要檢查的是匯出後的 PPTX 渲染結果。

原專案的驗收流程包含：檢查圖片、組裝 PPTX、重新渲染，再檢查整份總覽與溢出問題。

先看懂兩個檢查腳本的能力範圍

所以，**VALID 不等於「可以直接交付」**。這是根據 validate_spec.py 與 verify_images.py 的檢查範圍所做的區分。

貼給 Codex：組裝與驗收提示詞

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

請進行 PPTX 組裝與驗收。

先確認 8 頁素材與上版文字都齊全，
不要把缺頁或未核准頁當成完成。

請執行：
- validate_spec.py
- verify_images.py

把實際命令、輸出與退出碼保存到 qa/。

使用目前環境實際可用的簡報製作工具，
輸出：
output/ai-social-post_v01.pptx

本次是 plate 模式：
- 每頁放入 AI 生成的無字底圖。
- 標題、標籤、重點與頁碼使用原生可編輯文字。
- 精確流程箭頭需要時使用原生物件。
- 不准把整張含字預覽貼進 PPTX 冒充文字可編輯。

文字依核准大綱，不自行改寫。
加入講者備註與來源。
保留可重新執行的組裝程式碼或指令。

完成後，重新渲染這份匯出的 PPTX。
逐頁檢查：
- 頁數與順序。
- 缺字與異常換行。
- 文字遮擋與超出邊界。
- 圖片是否被拉伸。
- 文字區是否清楚。
- 整份風格是否一致。

建立完整總覽圖：
slides/previews/contact-sheet_v01.png

建立：
qa/QA_REPORT.md

報告分開記錄：
1. 腳本檢查結果。
2. 匯出 PPTX 的渲染檢查。
3. 尚待人工確認的項目。

沒有執行的檢查寫「未驗證」，不要寫 PASS。
不要自行提交或推送 Git。

你最後要親手做的一個測試

用你上課實際使用的軟體開啟 PPTX，點選一段文字，試著修改。

這能直接確認：你拿到的到底是原生文字方塊，還是一張把文字畫死的圖片。

同時切到播放模式，看一下標題、字型、換行與順序。若只在 Keynote 檢查過，就記錄為 Keynote 檢查，不要把它當成已完成 PowerPoint 原生驗收。

九、階段 7：修改時，先判斷「要不要重新生圖」

這是選擇 plate 的主要好處。

貼給 Codex：只改文字的提示詞

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

以 output/ai-social-post_v01.pptx 為基準，
建立 v02，保留 v01。

只把第 3 頁標題改成：
「先給資訊，再請 AI 寫」

其他文字、所有底圖與頁面順序都保持不變。
這次不呼叫生圖工具。

請同步更新：
- prompt/outline.md
- prompt/spec.yaml
- prompt/overlay-plan.yaml

重建 PPTX 後，重新渲染第 3 頁，
檢查換行、字級與重疊。

確認其他頁面沒有非預期差異，
將修改內容與驗證結果記錄到 qa/。

還有一個很容易忽略的問題

假設你後來自己在 PowerPoint 改了標題，但沒有更新 YAML，下次 Codex 重新組裝，就可能使用舊文字。

因此，重建之前最好加一句：

我可能在 PowerPoint 手動修改過內容。請先比對 PPTX 與 YAML，列出差異，不要直接用舊規格覆蓋我的修改。

重點不是所有修改都要經過 AI，而是最後要留下能夠重做同一份成果的規格。

十、常見卡關，直接這樣處理

十一、你已經有 Codex 簡報流程，應該怎麼接進去？

不必把原本的流程全部丟掉。

我建議把 YAML Image Deck 加在「需要 AI 視覺的部分」。

例如，你原本已經有內容大綱、講者備註、精確流程圖，以及可編輯的表格，就保留這些成果。先選封面、觀念比較頁、案例情境頁來測試這個 Skill。

當視覺流程穩定後，再逐步擴大範圍。

對長期備課來說，我更建議分清楚兩類檔案：

可以重用的：配色、字體方向、版型規則、已核准的風格樣張。

每次課程要換的：受眾、教學目標、案例、逐頁內容、講者備註。

這樣你下一次不是從零開始，而是：

沿用同一套視覺規則，換成適合新受眾的教學內容。

練習素材包

我把這次範例整理成可以直接放進 Codex 專案的檔案：

下載 YAML Image Deck｜Codex 練習素材包（ZIP）

包含需求表、視覺方向、虛構教材、8 頁大綱草稿、完整範例 YAML，以及各階段提示詞。

依素材包所附 qa/EXAMPLE_VALIDATION.md 的紀錄，8 頁 YAML 曾通過原專案 validate_spec.py 的結構檢查（紀錄日期：2026-10-11）；這是素材提供時的驗證紀錄，不代表圖片與 PPTX 已經完成，也不代表讀者目前環境已通過驗證。素材包沒有代你安裝 Skill，也沒有預先生成圖片或簡報。

開始時只做一件事：解壓縮，用 Codex App 開啟資料夾，貼上「階段 0」提示詞。

整個流程最重要的不是一次講出完美提示詞，而是：

內容先確認，樣張先確認，再讓 Codex 批次製作；修改時只動需要變更的部分。

延伸閱讀

• Claude Skill 可以用在 Codex 嗎？Agent Skills 遷移指南：理解哪些工作方法可以共用、哪些平台設定需要調整。
• Codex Skills 與 Plugins 的使用觀念：釐清專案技能與插件的分工。

常見問答 (FAQ)

Q1：不會 YAML，也能用 Codex 製作這份簡報嗎？

可以。先提供簡報需求、可靠內容與視覺方向，再讓 Codex 整理大綱與 YAML 規格。你主要確認教學順序、上版文字與含字樣張，不必從零手寫 YAML。

Q2：baked 和 plate 模式差在哪裡？

baked 把文字與圖像一起生成在圖片中；plate 先生成無字底圖，再由簡報工具疊上原生文字。需要經常修改的教材適合 plate，但底圖中的插畫仍是圖片，不能因此當成可拆解的 PowerPoint 圖形。

Q3：安裝 YAML Image Deck 後，就能直接輸出 PPTX 嗎？

不能只靠安裝 Skill 或寫好 YAML 就保證輸出。還需要實際可呼叫的生圖工具、PPTX 組裝工具、字型與渲染工具；plate 模式另外需要文字位置與字級的組裝規格。開始前應確認各工具是否可用。

Q4：為什麼要先核准黃金樣張，再生成其他頁？

黃金樣張用來確認配色、插畫材質與文字留白。先檢視無字底圖和疊上文字的完整投影片，通過後再測試其他版型，有助於提早發現風格或內容密度問題，避免整份重做。

Q5：素材包通過 VALID，是否代表簡報已經完成？

不是。素材包所附紀錄只表示範例 YAML 曾通過結構檢查；沒有附上已生成圖片或完成的 PPTX。實際製作仍需檢查圖片、組裝 PPTX、重新渲染，並在上課使用的軟體中確認文字可編輯、字型與換行正常。