1实现原理 · 为什么它能做到
它是分阶段流水线:分析 → 强制确认 → 大纲 → 提示词 → 出图 → 合并 PPTX/PDF,每阶段产物落盘,可按 --outline-only / --prompts-only / --images-only 断点续跑。
- [ ] Step 7: Generate images
出图后端不在本仓实现,而是按优先级解析:当前请求指定 > EXTEND.md 偏好 > 运行时原生工具(Codex imagegen / Cursor GenerateImage / Hermes image_generate)> 唯一已装的非原生后端(baoyu-image-gen)> 问用户。
If a skill named `imagegen` is listed, you are running inside Codex and MUST use it
走 codex-imagegen 分支时优先经由同仓 baoyu-image-gen 技能脚本,而不是直接调包装器。
route through `baoyu-image-gen --provider codex-cli` (preferred)
提示词文件是硬性可复现记录:调用任何后端之前,每张图的完整最终 prompt 必须先落成 prompts/NN-slide-[slug].md。
**Prompt file requirement (hard)**: write each image's full, final prompt to a standalone file under `prompts/`
合并是本仓唯一的可执行代码,且纯本地:merge-to-pdf.ts 用 pdf-lib 逐页嵌图,merge-to-pptx.ts 用 pptxgenjs 出 16:9 并把 base-prompt + 每页 prompt 写进备注。
pptx.layout = "LAYOUT_16x9";
确认是硬门禁:Step 2 未完成不得进入 Step 3 及之后,除非用户本轮显式说『直接生成/不用确认』。
Do **not** start Step 3 or later until the user completes Step 2.
风格系统 = 17 个预设 × 4 个维度(texture/mood/typography/density)自由组合;内容信号命中关键词表就自动选型,否则回退 blueprint。
17 presets covering technical / educational / lifestyle / editorial use cases.
批量出图有明确优先序:后端原生 batch > 运行时并行工具调用(默认 4,可 --batch-size 覆盖)> 串行;且『所有 prompt 文件先落盘』才允许开第一批。
- Never start the first batch until all selected slide prompt files exist on disk.
2核心能力
3外部依赖
| Kind | Dependency / Endpoint |
|---|---|
| api | 运行时图像生成后端(Codex imagegen Skill / Cursor GenerateImage / Hermes image_generate)——用户内容与提示词由此出网 |
| cli | codex CLI(无原生 imagegen 时的 codex exec 后端,需 codex login) |
| cli | baoyu-image-gen 技能脚本(--provider codex-cli,首选路径) |
| cli | bun / npx -y bun(跑合并脚本与包装器) |
| package | pdf-lib ^1.17.1(PDF 合并) |
| package | pptxgenjs ^4.0.1(PPTX 合并,声明于仓库根 package.json) |
| package | sharp ^0.34.5(根依赖,两个合并脚本均未 import) |
| network | homepage 元数据 URL(静态 frontmatter,任何步骤都不抓取) |
4管控建议与判定依据
- scripts/: 执行本地脚本或命令: ${BUN_X} {baseDir}/scripts/merge-to-pptx.ts <slide-deck-dir>(bun 或 npx -y b
- 网络端点: 声明外部网络访问: skill 自身脚本零网络调用(两个合并脚本只 import fs/path + pdf-lib / pptxgenjs)
- 本地工作目录: 文件读写与工件输出: slide-deck/{topic-slug}/source-*.{ext} 与 analysis.md
5第二遍独立确认
- [ok] 两个合并脚本无网络、无 env、无 spawn — merge-to-pdf.ts 只 import fs/path + pdf-lib,merge-to-pptx.ts 只 import fs/path + pptxgenjs;全目录 grep process.env/fetch/http/child_process 零命中。
- [ok] 出图后端解析阶梯与 SKILL.md 一致 — 阶梯为 当前请求 > EXTEND.md preferred_image_backend > 运行时原生(imagegen/GenerateImage/image_generate)> 唯一非原生后端 > 问用户;codex-imagegen 分支的调用契约在 references/codex-imagegen.md。
- [ok] 不读 API key(认证走用户订阅) — codex-imagegen.md 明写 'no `OPENAI_API_KEY` is read or sent';脚本零 env 读取,唯一的 env 覆盖是 $BAOYU_CODEX_IMAGEGEN_BIN(后端可执行文件路径)。
- [ok] prompt 文件先行是硬要求 — SKILL.md 标注 (hard),且合并脚本把 base-prompt + 每页 prompt 写进 PPTX 备注,形成可复现双通道。
- [ok] 依赖与声明一致性 — pdf-lib/pptxgenjs 由仓库根 package.json 提供(skill 内无 package.json);根依赖 sharp 未被这两个脚本 import(属未使用依赖)。
- [ok] EXTEND.md 路径文档不一致(轻微) — SKILL.md 列三条路径(含 XDG),references/config/preferences-schema.md 只列项目与家目录两条;另 slide-deck 的首次设置明确不阻塞(与 translate/xhs-images 相反),已在正文引用中如实标注。
- [ok] base-prompt.md 的模型定向指令 — 文件结尾确有 'Please use nano banana pro to generate the slide image based on the content provided above.' 与 'DO NOT refuse to generate' 类措辞;因它把用户文本与模型指令混在同一通道,已写入 injection_surface 与 risks。
- [ok] 档位复核(批4 终裁) — 按 Main『生成後端類先例=orange』与点名后端+素材出网的判法落 orange;自身脚本仅有本地 pdf/pptx 合并与写盘,不升红。
6结论
9867805610b81b26…