企业官网建设流程全解析

image-to-editable-ppt-skill工作原理揭秘：输入归一化到最终组装校验的4阶段流水线

【免费下载链接】image-to-editable-ppt-skillCodex skill for converting slide images, PDFs, and image-based PPTX files into editable PowerPoint decks.项目地址: https://gitcode.com/gh_mirrors/im/image-to-editable-ppt-skill

image-to-editable-ppt-skill是一个把幻灯片图片、PDF、图片版 PPT转换成可编辑 PowerPoint（.pptx）的 Codex skill。它的价值在于：可读文字尽量恢复成可双击编辑的原生文本框，简单几何恢复成 PowerPoint 形状，复杂视觉元素则保留为带来源记录的独立图片资产。本文将用小白也能看懂的方式，拆解它从「输入归一化」到「最终组装校验」的4 阶段转换流水线，帮你看懂 AI 在背后到底做了什么。

一、整体流程：一条四阶段的转换流水线 💡

无论输入是一张截图还是一整份 PDF，最终都会流经过同样四个阶段：

理解这条流水线，你就抓住了这个 skill 的骨架：它不靠「一次生成」，而是逐页拆任务 → 并行重建 → 严格验收 → 汇总交付。

二、阶段一：输入归一化，把"乱"的输入变成整齐的页面

这是最容易被人忽略、却最关键的阶段。所谓「归一化」，就是把五花八门的输入，统一成流水线能吃的标准页面图片。

支持哪些输入？

• 单张图片 / 多张图片：直接转存为source.png；
• 多页 PDF：按指定 DPI 把每一页渲染成图片；
• 图片版 PPT / PPTX：只接受"整页就是一张图"的幻灯片，逐页抽出那张满版图；
• 传统.ppt会先借助本机 Office 转换器转成 PDF 再逐页拆图。

归一化这一步真正做了三件事

1. 建独立任务目录：每次转换都有一个专属目录，原始输入被复制进input/，中间产物和最终结果都落在其中，互不干扰；
2. 逐页拆图：PDF 每页、PPTX 每页、每张图片，都变成一个pages/page_NNN/source.png；
3. 登记清单 + 配置图片后端：写出整册的页面清单deck_manifest.json和每页作业表page_jobs.json，并记录本次使用的图片生成 backend（内置image_gen优先，不可用时降级到 CLI）。

这一步的核心逻辑写在_input_normalization.py，由prepare_deck_run.py统一调度。归一化完成后，整册的「页面数量、输出配置、并发上限」都已确定，后面每一步都有据可依。

三、阶段二：页面分派与并行重建

页面准备好后，进入最"重"的重建环节。

单页本地做，多页并行做

• 只有 1 页：主 agent 用--local认领页面，本地按同一套流程重建；
• 多页：按并发上限max_concurrent_pages（默认 6 个槽位）分批分派给多个 page worker 并行处理，谁有空槽谁就干活。

这个"看还有几个空位、把待办页面派给谁"的调度逻辑，集中在deck_run_state.py，它维护着每一页的状态：pending → dispatched → recorded → accepted。

重建时靠"测量"而非"目测"

重建者会参考页面请求page_request.json，并依据OCR 文字标注（精确的框坐标、实测字号、字号分组）来还原文字——也就是说，文字的大小和位置是量出来的，不是猜出来的，同级文字字号也会自动保持一致。

每页最终产出一份manifest（清单文件），描述这页里有哪些文本框、哪些形状、哪些独立图片资产，以及各自的坐标与层级。这份 manifest 就是后续组装的"权威输入"。页面重建者遵循的提示词模板见page-worker.md。

四、阶段三：结果记录与哈希校验

页面重建完不等于能交付。这一步由record_page_result.py把守，像一道质检关卡：

• 核对必交产物：manifest、单页page.pptx、预览图、校验报告等缺一不可；
• 契约校验：再次运行校验，确认页面validation.json里passed: true，否则拒绝记录；
• 打哈希指纹：对所有产物计算 SHA256，存进作业表。

打哈希的目的在于：万一某个文件后来被悄悄改动，组装阶段会立刻发现"指纹对不上"，从而阻止交付一份被污染的结果。通过这关，页面状态才从dispatched变为recorded。

五、阶段四：最终组装与整册校验

所有页面都被recorded后，最后一步由finalize_deck_run.py一键收尾：

1. 复核所有页面：逐一核对状态、校验结果与哈希，任何一页不达标都会明确报出问题；
2. 按页顺序组装：读取各页已记录的manifest.json，重建出最终的{origin}_edited.pptx；
3. 整册校验：对整份 PPT 再跑一次 deck 级验证，并生成validation.json；
4. 落摘要：写出run_summary.json，把所有页面标记为accepted，任务状态置为complete。

如果输入是.pptx，这一步还会把原页面的备注按页原样复制进输出，不翻译、不改写。到这里，一份真正可编辑的 PPT 才算正式交付。

六、关键文件速查（附相对路径）

想深入看代码，可以按这条主线去读：

• 入口与规则：SKILL.md
• 输入归一化：_input_normalization.py、prepare_deck_run.py
• 状态与并发调度：deck_run_state.py
• 页面记录与哈希：record_page_result.py
• 最终组装校验：finalize_deck_run.py
• 页面重建提示词：page-worker.md
• 清单结构说明：manifest-schema.md
• 标准工作流文档：workflow.md

七、小结

image-to-editable-ppt-skill把「图片转可编辑 PPT」这件看似模糊的事，拆成了输入归一化 → 并行重建 → 记录校验 → 组装交付四个确定性的阶段。它的聪明之处不在某一步多惊艳，而在于每一步都有据可查、有指纹可验、有状态可追踪——所以最终得到的不只是"看起来像"的 PPT，而是一份真正能逐字逐块编辑的成果。理解了这条流水线，你再去看它的运行日志，就会知道 AI 此刻正停在哪一站。

【免费下载链接】image-to-editable-ppt-skillCodex skill for converting slide images, PDFs, and image-based PPTX files into editable PowerPoint decks.项目地址: https://gitcode.com/gh_mirrors/im/image-to-editable-ppt-skill