拆解 Manus 黑盒：用 Slidev 復刻生成PPT鏈路
整理版優先睇
作者揭開 Manus 生成 PPT 嘅黑盒機制，發現佢背後係一套 Web 化嘅 slide 工程，再用 Slidev 成功復刻出一條開放、可控、可驗證嘅 AI PPT 生成閉環。
呢篇文章出自一位技術作者，佢喺用 Manus 嗰陣遇到一個問題：切換賬號之後，新嘅 Manus 唔識得繼續編輯之前嘅 PPT，即使已經有曬完整嘅 HTML 同 JSON 檔案。Manus 回覆話只有透過 slide_initialize 喺當前任務沙箱創建嘅項目先可以預覽。呢個現象令作者開始拆解 Manus 嘅 slides 預覽機制。
作者發現 Manus 生成 PPT 嘅過程中，唔係直接操作二進制嘅 PPTX 檔案，而係先生成一組 Web 化嘅幻燈片工程：每個 slide 係一個獨立嘅 HTML 檔案，用 slide_state.json 嚟管理索引同狀態。只有透過 slide_initialize 註冊過嘅項目先可以被 slide_present 預覽，純粹複製檔案結構係冇用嘅。呢個設計對 AI Agent 嚟講好處係容易做增量修改同保留中間狀態。
基於呢個理解，作者決定用開放工具 Slidev 嚟復刻呢條鏈路。佢設計咗一個本地閉環：先用 outline.json 定義結構化輸入，再由 generate 腳本轉換成 Slidev 嘅 slides.md，然後進行 build、預覽、導出 PNG/PDF/PPTX，最後用 verify 腳本做機器校驗。呢套做法唔單止驗證咗 Manus 嘅原理，仲提供咗一條可觀察、可重複、可遷移嘅 AI PPT 生成路徑。
- Manus 生成 PPT 嘅核心唔係直接操作 PPTX，而係用 HTML+JSON 組成嘅 slide 工程，透過 slide_initialize 註冊項目狀態先可以預覽。
- 作者用 Slidev 做底座，補咗一層項目狀態同校驗機制，成功復刻出類似 Manus 嘅生成鏈路。
- 差異在於 Manus 係黑盒封閉平台，而 Slidev 方案完全開放，outline.json 做結構化輸入，slides.md 可直接編輯，導出格式包括 PNG、PDF、PPTX。
- 啟發係：要建立可靠嘅 AI PPT 系統，應該先將 PPT 拆成可管理嘅 slide 對象，再用工具承接，而唔係直接改二進制檔案。
- 可行動點：可以用作者公開嘅 GitHub 專案 slidev-agent-loop，按照 outline.json -> generate -> present -> export -> verify 嘅流程，本地搭建自己嘅 AI PPT 生成閉環。
slidev-agent-loop GitHub 專案
作者用嚟復刻 Manus 生成 PPT 鏈路嘅開放工具，包含 outline.json 結構、generate 腳本同 verify 腳本，可以喺本地直接運行。
Manus 嘅 slide 機制：唔係 PPTX，係 Web 工程
作者一開始遇到嘅問題係：切換賬號之後，新 Manus 認唔到之前嘅 PPT 項目，即使有曬 HTML 同 JSON 都唔得。Manus 解釋話只有透過 slide_initialize 喺當前任務沙箱建立嘅項目先可以用 slide_present 預覽。
為咗搞清楚背後嘅結構，作者叫 Manus 生成一個測試 PPT，發現目錄入面唔係 PPTX，而係一組檔案：slide_state.json、slide_1.html、slide_2.html... 同埋 assets 資料夾。slide_state.json 記錄咗項目標題、總頁數、每頁嘅 id 同狀態，每個 id 對應一個獨立 HTML 檔案。
作者仲做咗一個實驗：將完整嘅項目複製成另一個目錄，然後嘗試預覽，結果報錯話「Slide project not found」。呢個證明 Manus 唔係靠檔案結構，而係靠 slide_initialize 喺當前任務嘅上下文裏面註冊狀態。換賬號後，新任務自然認唔到舊項目，需要重新初始化。
用 Slidev 復刻開放鏈路：outline.json 做輸入，generate 做轉換
作者諗到：如果要自己做一套 AI PPT 生成系統，與其直接寫 PPTX，不如將 PPT 變成一組可管理嘅 slide 對象，然後用工具承接預覽同導出。佢揾到 Slidev 呢個開源工具，可以做到 slide -> 預覽 -> 導出，於是喺上面搭建一層 Agent 管理能力。
佢設計咗一個本地 demo，核心係用 outline.json 做結構化輸入。呢個 JSON 檔包含項目級資訊（project_id、title、subtitle、author、date、theme）同一個 slides 陣列，每個 slide 有 id、layout、title、summary、bullets 等欄位。作者認為咁樣 AI 只需要填內容，唔使直接寫 Slidev 嘅 slides.md。
{
"project_id": "docpilot-slidev-open-loop",
"title": "AI Slides Open Loop",
"subtitle": "用 Slidev 復刻開放、可控、可驗證的 AI PPT 生成閉環",
"author": "Dapeng Lab",
"date": "2026-05-09",
"theme": "default",
"slides": [
{
"id": "problem",
"layout": "bullets",
"title": "問題：AI PPT 不能只是一次性生成",
"summary": "真正可用的 AI PPT 系統需要可編輯、可預覽、可導出、可驗證。",
"bullets": [
"二進制 PPTX 難以被 Agent 精確 diff 和增量修復",
"純 HTML 託管缺少項目生命週期和導出閉環",
"黑盒平台能力強，但遷移和調試成本高"
]
}
]
}然後作者寫咗一個 generate 腳本，將 outline.json 轉換成 Slidev 識別嘅 slides.md。佢用 npm script 執行 `node scripts/open-slidev-loop.mjs generate`，腳本會逐頁渲染，用 `---` 分頁符號拼接。例如 bullets 類型會轉成標題 + 摘要 + 列表。
呢個做法嘅好處係：AI 生成容易改嘅 JSON，而唔係直接產生最終顯示格式，中間層由腳本負責翻譯。
本地閉環：預覽、導出、校驗，同埋上雲方向
- 1 第一步：用 `npm run generate` 將 outline.json 轉成 slides.md。
- 2 第二步：用 `npm run present` 執行 Slidev 嘅 build 同一個本地伺服器，得到預覽地址（例如 http://localhost:4185），功能上接近 Manus 嘅 slide_present。
- 3 第三步：用 `npm run export:png`、`npm run export:pdf`、`npm run export:pptx` 導出產物，結果會放喺 exports/ 目錄。
- 4 第四步：用 `npm run verify` 執行校驗腳本，檢查 slides.md 有冇生成、registry.json 有冇登記、dist/index.html 同導出檔案是否存在，最後生成 verify-report.json。
成個閉環係：outline.json -> generate -> slides.md -> registry.json -> build -> localhost 預覽 -> export PNG/PDF/PPTX -> verify-report.json。呢個設計重點唔係靚，而係驗證咗一條開放可控嘅 AI PPT 生成鏈路。
作者仲提出如果要上雲嘅話，沙箱嘅角色係俾每個 PPT 任務一個臨時隔離環境。本地嘅目錄同檔案會變成任務級沙箱、Preview Proxy、數據庫 Registry 同對象存儲。沙箱可以隔離文件、瀏覽器進程、導出進程，任務結束後保留輸入、產物同校驗報告。
1. 背景
上晝用 Manus 切換咗賬號之後，我想叫個新 Manus 繼續改上次份 PPT，但佢認唔到之前個 PPT 項目。
Manus 解釋話：
Manus 預覽嘅唔係 PPTX，而係佢自己初始化過嘅 slides 項目。只有經 slide_initialize 喺而家個任務沙箱入面創建出嚟嘅項目，先至可以繼續俾 slide_present 預覽。外部拎嚟嘅 HTML，就算內容齊全，都唔可以直接接上呢條鏈路。
呢度先大家確認一下呢篇文章入面 slide 嘅定義：佢唔係 Google Slides，亦唔係某個具體產品名。結合 Manus 暴露出來嘅項目結構，我將 slide 理解為一種由 JSON 描述同管理嘅「單頁幻燈片對象」。
一份 PPT 裏面有好多個 slide。每個 slide 有自己的 id、順序、狀態，同埋最終要渲染出嚟嘅頁面內容。
由呢個現象睇，Manus 嘅 slides 預覽至少涉及兩層嘢：
• 文件系統入面嘅幻燈片工程：HTML、資源文件、slide_state.json • 目前任務上下文入面嘅 slide 項目狀態：邊啲項目係由 slide_initialize 創建出嚟、可以俾 slide_present 繼續預覽
2. Manus Slides 項目
我叫 Manus 喺沙箱入面生成咗一個測試 PPT，項目目錄生成嘅唔係一個單獨嘅PPTX，而係一組檔案：
slide_state.json
slide_1.html
slide_2.html
...
assets/
slide_notes.json / slide_notes.md（有備註時才出現）slide_state.json 係 JSON 索引目錄檔案，記錄咗項目標題、總頁數、每頁 slide 嘅 id、狀態同頁碼。每個 id 又對應一個獨立嘅 HTML 檔案。
Manus 唔係一開始就直接操作複雜嘅二進制 PPTX 檔案，而係似生成一個 Web 化嘅PPT工程：每頁係一個 HTML 頁面，再透過平台工具將呢啲頁面組織、預覽同匯出。
呢樣對 AI Agent 好友好。相比直接修改 PPTX，編輯 HTML、CSS 同 JSON 呢啲文字檔案，更容易做增量修改、定位問題同保留中間狀態。
3. Manus Slides 項目狀態
為咗確認 Manus 預覽係只需要有同樣嘅目錄結構，定係存在類似註冊表嘅驗證。我做咗一個實驗：
1. 將一個已經生成嘅 Manus Slides 項目完整複製成 clone 目錄。 2. 用 diff / md5sum 確認兩個目錄內容完全一致。 3. 對 clone 目錄調用 slide_present。
結果出錯：
Slide project /home/ubuntu/.../project_clone not found,
use one of these available slide projects instead:
- /home/ubuntu/.../project呢個結果說明淨係相同結構唔夠，Manus slide 認得嘅唔係結構，而係目前任務入面已經透過 slide_initialize 建立過狀態嘅項目。
呢個都解釋咗上晝嘅異常：換咗賬號之後，就算 send 咗 HTML 同 JSON，新任務都唔可以當作 Manus Slides 項目繼續預覽，要重新 slide_initialize 喺目前任務上下文入面初始化/登記。
4. Manus Slides 理解
Manus 生成 PPT 嘅過程，唔係一開始就喺 PPT 上修改，而係有好多個 slide html，再用 json 記錄呢啲 slide 嘅狀態同順序，最後統一預覽，匯出多種格式。
咁如果自己整一套 PPT 生成嘅內容，要揾嘅唔一定係直接寫 ppt 嘅 skill，而係可以將 ppt 先變成一組可管理嘅 slide，然後再去做可以承接住 slide 嘅工具。
呢度調研到一個工具 Slidev，佢可以承接 slide -> 預覽 -> 匯出，咁我哋只需要喺佢上面搭建一組 Agent 管理能力就得。
5. 本地閉環點樣行
有咗上面嘅判斷，我做咗一個本地 demo。
呢個 demo 仲唔係完整嘅 Manus，亦冇接入雲端沙箱同調度。目的係先驗證一個閉環：如果將 Slidev 當成「幻燈片渲染同匯出」嘅底座，喺外面補一層可見嘅項目狀態同校驗 Agent 循環，可唔可以行出一條可觀察、可重複嘅 PPT 生成鏈路。
• 用 outline.json 承接 AI 可以生成嘅大綱同頁面結構。 • 用 registry.json 記錄項目身份、預覽地址同匯出產物。 • 用 verify-report.json 留低機器校驗結果，避免淨係靠肉眼判斷「好似成功咗」。
outline.json 唔係 Slidev 自帶嘅檔案，係我觀察 Manus 嘅輸出之後自定義嘅輸入結構。因為我唔希望 AI 一嚟就直接寫 PPTX，亦唔希望佢直接隨意拼 slides.md（Slidev 嘅入口）。
我更希望先將「呢份 PPT 有邊幾頁、每頁係咩類型、每頁有咩內容」固定成一個 JSON 結構。咁樣 AI 只需要按呢個結構填內容，後面嘅腳本負責將佢翻譯成 Slidev 可以運行嘅 slides.md。
所以呢度嘅分工係：
人 / 系統先定義 outline.json 的結構
-> AI 按這個結構填寫每頁內容
-> generate 腳本把 outline.json 轉成 slides.md
-> Slidev 讀取 slides.md 進行預覽和導出第一步係建立 outline.json，outline.json 嘅結構大概分兩層：
outline.json
├─ 項目級信息
│ ├─ project_id
│ ├─ title
│ ├─ subtitle
│ ├─ author
│ ├─ date
│ └─ theme
│
└─ slides[]
├─ slide 1
├─ slide 2
└─ ...例如 outline.json 入面會先記錄成個項目嘅資訊：
{
"project_id": "docpilot-slidev-open-loop",
"title": "AI Slides Open Loop",
"subtitle": "用 Slidev 復刻開放、可控、可驗證的 AI PPT 生成閉環",
"author": "Dapeng Lab",
"date": "2026-05-09",
"theme": "default"
}然後每頁 slide 都係一段結構化 JSON：
{
"id": "problem",
"layout": "bullets",
"title": "問題：AI PPT 不能只是一次性生成",
"summary": "真正可用的 AI PPT 系統需要可編輯、可預覽、可導出、可驗證。",
"bullets": [
"二進制 PPTX 難以被 Agent 精確 diff 和增量修復",
"純 HTML 託管缺少項目生命週期和導出閉環",
"黑盒平台能力強，但遷移和調試成本高"
]
}呢度嘅 layout 會話俾生成腳本知，呢一頁應該按邊種方式轉成 Slidev 頁面。
然後執行：
npm run generate呢度嘅 generate 唔係 Slidev 自帶命令，而係我喺 demo 入面自己寫嘅一層轉換腳本。package.json 入面將佢註冊成一個 npm script：
{
"scripts": {
"generate": "node scripts/open-slidev-loop.mjs generate"
}
}所以呢一步實際調用嘅係：
node scripts/open-slidev-loop.mjs generate腳本會讀取 outline.json，然後做一次好直接嘅轉換。例如 bullets 會轉成標題、摘要同列表；mermaid 會轉成 Mermaid 圖；table 會轉成 Markdown 表格。最後，腳本將所有 slide 逐頁渲染出來，並用 Slidev 嘅分頁符 --- 拼接成一個檔案：
const slideBodies = outline.slides.map((slide, index) =>
renderSlide(outline, slide, index)
);
const slides = `${renderFrontmatter(outline)}${slideBodies.join("\n\n---\n\n")}`;
生成結果就係 Slidev 可以運行嘅：slides.md。
對應上面嗰頁 slide，生成後嘅 slides.md 片段會變成：
---
theme: default
title: "AI Slides Open Loop"
info: |
用 Slidev 復刻開放、可控、可驗證的 AI PPT 生成閉環
drawings:
persist: false
transition: slide-left
mdc: true
---
# AI Slides Open Loop
<div class="open-loop-subtitle">用 Slidev 復刻開放、可控、可驗證的 AI PPT 生成閉環</div>
---
# 問題：AI PPT 不能只是一次性生成
<div class="open-loop-summary">真正可用的 AI PPT 系統需要可編輯、可預覽、可導出、可驗證。</div>
- 二進制 PPTX 難以被 Agent 精確 diff 和增量修復
- 純 HTML 託管缺少項目生命週期和導出閉環
- 黑盒平台能力強，但遷移和調試成本高
<!--
Slide 2: 真正可用的 AI PPT 系統需要可編輯、可預覽、可導出、可驗證。
-->即係話，outline.json 並唔係 Slidev 自帶格式，而係我自己加嘅一層結構化輸入。真正俾 Slidev 讀取嘅係 slides.md。中間呢段 generate 腳本，負責將 AI 更容易生成同修改嘅 JSON，翻譯成 Slidev 原生認識嘅 Markdown。
呢個代碼參考我放咗喺 github：https://github.com/ditingdapeng/slidev-agent-loop
第二步係構建同啟動預覽：
npm run present佢背後做咗兩件事：
slidev build --out dist
node scripts/open-slidev-loop.mjs present --serve --port 4185於是會得到一個本地預覽地址：
http://localhost:4185/
呢一步喺功能位置上接近 Manus 入面嘅 slide_present。分別係 Manus 返回嘅係 manus-slides://...，呢度返回嘅係普通嘅 localhost URL。
第三步係匯出產物：
npm run export:png
npm run export:pdf
npm run export:pptx匯出嘅結果會落到：
exports/png/
exports/deck.pdf
exports/deck.pptx最後執行機器校驗：
npm run verify呢個都唔係 Slidev 自帶命令，而係 demo 自己加嘅校驗腳本。package.json 入面對應嘅係
{
"scripts": {
"verify": "node scripts/open-slidev-loop.mjs verify"
}
}所以佢實際調用嘅係：node scripts/open-slidev-loop.mjs verify
佢會生成：exports/verify-report.json
校驗內容包括：slides.md 是否生成、registry.json 是否登記目前項目、dist/index.html 是否存在，同埋 PNG/PDF/PPTX 是否已經匯出。
所以呢個本地閉環行落嚟，其實係：
outline.json
-> generate
-> slides.md
-> registry.json
-> build
-> localhost 預覽
-> export PNG/PDF/PPTX
-> verify-report.json呢套 demo 嘅重點唔係視覺做得多精美，而係驗證我哋觀察到嘅嗰段 slide 工程鏈路，可唔可以用開放工具鏈行出來：AI 可控輸入係結構化嘅 outline.json，生成結果係可讀可改嘅 slides.md。預覽唔係截圖，而係真正嘅 Web 頁面。匯出結果包括 PNG、PDF、PPTX。機器校驗會檢查頁數、匯出物同構建結果。
呢個已經足夠回答開始用 Manus 嘅好奇，Manus 嘅 PPT 能力唔係直接喺二進制 PPTX 上硬改，而係似先將 PPT 拆成一套可管理、可渲染、可匯出嘅 Web PPT 工程。
6. 上雲
目前 demo 係本地運行，所以 localhost、本地目錄、檔案 registry.json 就夠。
如果要放上雲端生產環境，沙箱嘅角色就係：令每個 PPT 生成任務都喺一個臨時隔離環境入面執行。
大致鏈路係：
控制面 API
-> 創建 PPT 任務
-> 任務隊列
-> 創建任務級沙箱
-> 沙箱內生成 Slidev 工程
-> 運行 generate / build / present / export / verify
-> 產物寫入對象存儲
-> Preview Proxy 暴露預覽地址
-> 用戶確認或繼續修改本地嘅：
本地目錄
localhost
registry.json
exports/到雲端會變成：
任務級沙箱
Preview Proxy
數據庫 Registry
對象存儲沙箱嘅價值係隔離每次生成任務嘅檔案、瀏覽器進程、匯出進程同臨時依賴。任務結束後，保留結構化輸入、預覽產物、匯出檔案同校驗報告。
1. 背景
上午使用 Manus 切換賬號之後，我想讓新的 Manus 繼續接着上一次的 PPT 改，但它沒能識別之前的 PPT 項目。
Manus 給出的解釋是：
Manus 預覽的不是 PPTX，而是它自己初始化過的 slides 項目。只有通過 slide_initialize 在當前任務沙箱裏創建出來的項目，才能繼續被 slide_present 預覽。外部拿來的 HTML，即使內容完整，也不能直接接上這條鏈路。
這裏先共識一下本文裏 slide 的定義：它不是 Google Slides，也不是某個具體產品名。結合 Manus 暴露出來的項目結構，我把 slide 理解成一種由 JSON 描述和管理的“單頁幻燈片對象”。
一份 PPT 裏有很多個 slide。每個 slide 有自己的 id、順序、狀態，以及最終要渲染出來的頁面內容。
從這個現象看，Manus 的 slides 預覽至少涉及兩層東西：
• 文件系統裏的幻燈片工程：HTML、資源文件、slide_state.json • 當前任務上下文裏的 slide 項目狀態：哪些項目是由 slide_initialize 創建出來、可以被 slide_present 繼續預覽的
2. Manus Slides 項目
我讓 Manus 在沙箱裏生成了一個測試 PPT，項目目錄生成的不是一個單獨的PPTX，而是一組文件：
slide_state.json
slide_1.html
slide_2.html
...
assets/
slide_notes.json / slide_notes.md（有備註時才出現）slide_state.json 是JSON索引目錄文件，記錄了項目標題、總頁數、每一頁 slide 的 id、狀態和頁碼。每個 id又對應一個獨立的 HTML 文件。
Manus 並不是一開始就直接操作複雜的二進制 PPTX 文件，而更像是先生成一個 Web 化的PPT工程：每頁是一個 HTML 頁面，再通過平台工具把這些頁面組織、預覽和導出。
這對 AI Agent 很友好。相比直接修改 PPTX，編輯 HTML、CSS 和 JSON 這樣的文本文件，更容易做增量修改、定位問題和保留中間狀態。
3. Manus Slides 項目狀態
為了確認Manus 預覽是隻需要有同樣的目錄結構，還是存在類似註冊表的驗證。我做了一個實驗：
1. 把一個已生成的 Manus Slides 項目完整複製成 clone 目錄。 2. 用 diff / md5sum 確認兩個目錄內容完全一致。 3. 對 clone 目錄調用 slide_present。
結果報錯：
Slide project /home/ubuntu/.../project_clone not found,
use one of these available slide projects instead:
- /home/ubuntu/.../project這個結果說明只相同結構還不夠，Manus slide識別的不是結構，而是當前任務裏已通過slide_initialize建立過狀態的項目。
這也解釋了上午的異常：換賬號之後，即使發了HTML 和 JSON，新任務也不能當作 Manus Slides 項目繼續預覽，需要重新 slide_initialize 在當前任務上下文裏初始化/註冊。
4. Manus Slides 理解
Manus生成PPT的過程，不是一開始就在PPT上修改，而是有很多個slide html，再用json記錄這些slide的狀態和順序，最後統一預覽，導出多種格式。
那如果自己做一套PPT生成的內容，要找的不一定是直接寫ppt的skill，而是可以先把ppt變成一組可管理的slide，然後再去做能承接住slide的工具。
這裏調研到了一個工具Slidev，它可以承接slide->預覽->導出，那我們只需要在其上面，搭建一組Agent管理能力即可。
5. 本地閉環怎麼跑
有了上面的判斷，我做了一個本地demo。
這個demo還不是完整的Manus，也沒有接入雲端沙箱和調度。目的是先驗證一個閉環：如果把 Slidev 當成“幻燈片渲染和導出”的底座，在外面補一層可見的項目狀態和校驗Agent循環，能不能跑出一條可觀察、可重複的 PPT 生成鏈路。
• 用 outline.json 承接 AI 可以生成的大綱和頁面結構。 • 用 registry.json 記錄項目身份、預覽地址和導出產物。 • 用 verify-report.json 留下機器校驗結果，避免只靠肉眼判斷“好像成功了”。
outline.json 不是 Slidev 自帶的文件，是我觀察Manus的輸出自定義的輸入結構。因為我不希望 AI 一上來就直接寫 PPTX，也不希望它直接隨意拼 slides.md（Slidedev的入口）。
我更希望先把“這份 PPT 有哪些頁、每頁是什麼類型、每頁有哪些內容”固定成一個 JSON 結構。這樣 AI 只需要按這個結構填內容，後面的腳本負責把它翻譯成 Slidev 能運行的 slides.md。
所以這裏的分工是：
人 / 系統先定義 outline.json 的結構
-> AI 按這個結構填寫每頁內容
-> generate 腳本把 outline.json 轉成 slides.md
-> Slidev 讀取 slides.md 進行預覽和導出第一步是構建outline.json，outline.json 的結構大概分兩層：
outline.json
├─ 項目級信息
│ ├─ project_id
│ ├─ title
│ ├─ subtitle
│ ├─ author
│ ├─ date
│ └─ theme
│
└─ slides[]
├─ slide 1
├─ slide 2
└─ ...比如 outline.json 裏會先記錄整個項目的信息：
{
"project_id": "docpilot-slidev-open-loop",
"title": "AI Slides Open Loop",
"subtitle": "用 Slidev 復刻開放、可控、可驗證的 AI PPT 生成閉環",
"author": "Dapeng Lab",
"date": "2026-05-09",
"theme": "default"
}然後每一頁 slide 都是一段結構化 JSON：
{
"id": "problem",
"layout": "bullets",
"title": "問題：AI PPT 不能只是一次性生成",
"summary": "真正可用的 AI PPT 系統需要可編輯、可預覽、可導出、可驗證。",
"bullets": [
"二進制 PPTX 難以被 Agent 精確 diff 和增量修復",
"純 HTML 託管缺少項目生命週期和導出閉環",
"黑盒平台能力強，但遷移和調試成本高"
]
}這裏的 layout 會告訴生成腳本，這一頁應該按哪種方式轉成 Slidev 頁面。
然後執行：
npm run generate這裏的 generate 不是 Slidev 自帶命令，而是我在 demo 裏自己寫的一層轉換腳本。package.json 裏把它註冊成了一個 npm script：
{
"scripts": {
"generate": "node scripts/open-slidev-loop.mjs generate"
}
}所以這一步實際調用的是：
node scripts/open-slidev-loop.mjs generate腳本會讀取 outline.json，然後做一次很直接的轉換。比如 bullets 會轉成標題、摘要和列表；mermaid 會轉成 Mermaid 圖；table 會轉成 Markdown 表格。最後，腳本把所有 slide 逐頁渲染出來，並用 Slidev 的分頁符 --- 拼接成一個文件：
const slideBodies = outline.slides.map((slide, index) =>
renderSlide(outline, slide, index)
);
const slides = `${renderFrontmatter(outline)}${slideBodies.join("\n\n---\n\n")}`;
生成結果就是 Slidev 可運行的：slides.md。
對應上面那頁 slide，生成後的 slides.md 片段會變成：
---
theme: default
title: "AI Slides Open Loop"
info: |
用 Slidev 復刻開放、可控、可驗證的 AI PPT 生成閉環
drawings:
persist: false
transition: slide-left
mdc: true
---
# AI Slides Open Loop
<div class="open-loop-subtitle">用 Slidev 復刻開放、可控、可驗證的 AI PPT 生成閉環</div>
---
# 問題：AI PPT 不能只是一次性生成
<div class="open-loop-summary">真正可用的 AI PPT 系統需要可編輯、可預覽、可導出、可驗證。</div>
- 二進制 PPTX 難以被 Agent 精確 diff 和增量修復
- 純 HTML 託管缺少項目生命週期和導出閉環
- 黑盒平台能力強，但遷移和調試成本高
<!--
Slide 2: 真正可用的 AI PPT 系統需要可編輯、可預覽、可導出、可驗證。
-->也就是說，outline.json 並不是 Slidev 自帶格式，它是我自己加的一層結構化輸入。真正被 Slidev 讀取的是 slides.md。中間這段 generate 腳本，負責把 AI 更容易生成和修改的 JSON，翻譯成 Slidev 原生認識的 Markdown。
這個代碼參考我放在了github：https://github.com/ditingdapeng/slidev-agent-loop
第二步是構建並啓動預覽：
npm run present它背後做了兩件事：
slidev build --out dist
node scripts/open-slidev-loop.mjs present --serve --port 4185於是會得到一個本地預覽地址：
http://localhost:4185/這一步在功能位置上接近 Manus 裏的 slide_present。區別是 Manus 返回的是 manus-slides://...，這裏返回的是普通的 localhost URL。
第三步是導出產物：
npm run export:png
npm run export:pdf
npm run export:pptx導出的結果會落到：
exports/png/
exports/deck.pdf
exports/deck.pptx最後執行機器校驗：
npm run verify這也不是 Slidev 自帶命令，而是 demo 自己加的校驗腳本。package.json 裏對應的是
{
"scripts": {
"verify": "node scripts/open-slidev-loop.mjs verify"
}
}所以它實際調用的是：node scripts/open-slidev-loop.mjs verify
它會生成：exports/verify-report.json
校驗內容包括：slides.md 是否生成、registry.json 是否登記當前項目、dist/index.html 是否存在，以及 PNG/PDF/PPTX 是否已經導出。
所以這個本地閉環跑下來，其實是：
outline.json
-> generate
-> slides.md
-> registry.json
-> build
-> localhost 預覽
-> export PNG/PDF/PPTX
-> verify-report.json這套 demo 的重點不是視覺做得多精美，而是驗證我們觀察到的那段 slide 工程鏈路，能不能用開放工具鏈跑出來：AI 可控輸入是結構化的 outline.json，生成結果是可讀可改的 slides.md。預覽不是截圖，而是真正的 Web 頁面。導出結果包括 PNG、PDF、PPTX。機器校驗會檢查頁數、導出物和構建結果。
這已足夠回答開始用Manus的好奇，Manus 的 PPT 能力不是直接在二進制 PPTX 上硬改，而更像是先把 PPT 拆成一套可管理、可渲染、可導出的 Web PPT工程。
6. 上雲
當前 demo 是本地運行，所以 localhost、本地目錄、文件 registry.json 就夠了。
如果要放到雲上生產環境，沙箱的角色就是：讓每個 PPT 生成任務都在一個臨時隔離環境裏執行。
大致鏈路是：
控制面 API
-> 創建 PPT 任務
-> 任務隊列
-> 創建任務級沙箱
-> 沙箱內生成 Slidev 工程
-> 運行 generate / build / present / export / verify
-> 產物寫入對象存儲
-> Preview Proxy 暴露預覽地址
-> 用戶確認或繼續修改本地的：
本地目錄
localhost
registry.json
exports/到雲上會變成：
任務級沙箱
Preview Proxy
數據庫 Registry
對象存儲沙箱的價值是隔離每次生成任務的文件、瀏覽器進程、導出進程和臨時依賴。任務結束後，保留結構化輸入、預覽產物、導出文件和校驗報告。