PPT Master 项目定位与能力边界：一套 AI 演示工作流如何定义“原生深度“的产品边界

• AI 技能
• 人工智能

本文以仓库中的定位章程 docs/zh/project-positioning.md 为主体，逐节解读 PPT Master 的长期产品定位、产品承诺、能力边界与能力准入判据，并把章程中的每一条立场映射回仓库中的真实证据——路线契约、SVG 编译管线、质量门脚本、模板工作区与 provider 接入层。读完本文，你既能回答"这个项目到底承诺什么、不做什么"，也能学会用它的七问判据去评估任何一项新能力是否应该进入这个工作流。

一、如何理解这份"章程"：产品政策，而不是功能清单

原文开宗明义：本文定义 PPT Master 的长期产品定位，以及新增、保留或削减能力时使用的判断标准。它是一份产品政策，不是功能清单或执行手册。

这一自我定位决定了两条使用规则：

1. 中文译本不形成第二套政策。docs/zh/project-positioning.md 是英文规范源的同步中文译本，定位变化必须在同一次修改中同步两种语言；如有歧义，以英文规范源为准。
2. 它不替代执行契约。当前具体如何选择路线，仍以 skills/ppt-master/workflows/routing.md 为准；定位文档回答的是更根本的问题——一个方向究竟是否应该属于 PPT Master。

这个分工在仓库里是可见的：SKILL.md只拥有全局执行纪律与路线选择的强制入口，workflows/routing.md 拥有确定性的顶层路线判定，workflows/index.md 则是仅供维护者使用的路线注册表（明确"运行时任务执行不消费本文件"）。政策文档、执行契约与维护注册表三层各司其职，正是章程所说"工程可靠性"在产品文档层面的一次落地。

二、项目定位：先把论证推理成形，再产出真正可编辑的 PowerPoint

章程给出的定位原文是：

PPT Master 是一套开源、对话驱动的工作流，让 AI 先把论证推理成形，再设计并产出真正可编辑的 PowerPoint——不是整页图片，也不是一层能改的表皮。它的核心轴线是原生深度：随着版本迭代，持续创作或保留更多 PowerPoint 自身的对象模型、演示行为和可复用结构。

围绕这一定位，文档展开了四个关键判断。

2.1 输入与路线：主管线生成新 deck，其余路线各有契约

输入可以是一个主题、源材料、数据、设计参考、品牌资产或已有.pptx。主管线负责生成新 deck；其他明确路线和 profile 可以提炼可复用的 Brand / Style / Layout / Deck 工作区，向现有 PowerPoint 填入新内容、重新设计它，或在保留各自契约所承诺内容的前提下追加原生演示行为。

这一点与仓库的路线体系一一对应。routing.md 的顶层路线矩阵只承认三条产物路线：Generate PPTX（创作/重建/视觉重做，含image-to-pptx、beautify-pptx、quick-generate等 profile）、Create Template（产出四类模板工作区）、Edit Native PPTX（保留来源的 round-trip 编辑与叠加增强）；每个请求必须且只能进入其中一条，支撑文档（profile、stage、governance）只细化所选路线，绝不与之竞争。章程中"其他明确路线和 profile"这句话，落到仓库里就是这张封闭的路线表。

2.2 原生深度是方向，不是清单

原生深度是一条持续推进的方向，不是一张固定功能清单。项目的北极星是不断向 PowerPoint 自身靠拢，缩小"AI 能生成的内容"与"熟练用户在 PowerPoint 中手工完成的内容"之间的差距。而 PowerPoint ↔ SVG 能力映射逐项、诚实地记录当前边界——对每项 PowerPoint 功能标注Native-stable/Native-normalized/Approximate/Bake-required/Sidecar/package/Direct preservation/Unsupported等状态，未列出的功能不默认为受支持。

roadmap.md 则把这条主轴展开成一张四层"能力覆盖地图"（可见对象 / 构图系统 / 行为系统 / 文档结构），并明确区分"有意边界"与"未完成"：那里的空白是决定，不是欠账。例如 SmartArt 被记录为"有意的不对称"——读取来源 diagram 的内容与结构、用普通形状管线重画，但从不编辑 DiagramML；原生 WordArt 与文字变形则明确"暂不考虑"。

2.3 产品形态：一个运行在任意 Agent 工具中的"skill"

从产品形态上看，PPT Master 是一套运行在任意支持 Agent 的 AI 工具中的工作流——也就是一个"skill"。它不是模型，不是托管式演示 SaaS，也不是 PowerPoint 的替代品。

职责分工同样写得很清楚：工作流负责演示文稿专用的推理、契约和质量门；确定性工具负责转换、校验、打包和可重复的文件操作；最终质量上限仍由所选模型决定。仓库的 SKILL.md 就是这套形态的执行入口：它声明了强制加载顺序（读本文件 → 运行完整性闸门attribution_guard.py→ 读取routing.md→ 选定唯一路线 → 只加载该路线的运行时权威），并给出全局执行纪律（串行执行、阻塞即停、不跨阶段打包、确定性路由、在所有权层修复）。

2.4 交付物：一份可继续精修的草稿

最主要的交付物是一份用户可以直接演示并继续精修的高质量 PowerPoint 草稿，而不是封闭的最终成品。可复用模板工作区、项目源材料、设计规范、预览和校验产物同样是一等支撑产物，因为它们让最终 deck 可控制、可重建、可复用。这一立场在 technical-design.md 的项目结构中得到具象化：sources/（来源契约）、design_spec.md+spec_lock.md（设计规范与执行契约）、svg_output/（唯一手写源）、svg_final/（派生预览）、exports/（带时间戳交付物）、validation/（质量报告与审计日志）、backup/<timestamp>/svg_output/（冻结作者源，支持不重跑模型即可重建 PPTX）。

三、产品主张：两层价值与四条轴线

一份真正有用的 deck 有两层：让论证成立的推理层，以及让结果真正可用的PowerPoint 构造层。PPT Master 同时负责这两层，其立场浓缩为四条轴线：

为什么是"受约束的 SVG"而不是直接 OOXML 或整页图片，定位文档给出了关键论证：直接 OOXML 过于冗长和脆弱，不适合作为 AI 的通用视觉创作语言；整页图片又会丢掉原生对象模型。因此 PPT Master 把适合模型的视觉创作、确定性编译和直接 package 操作结合起来，并根据用户意图选择正确的修改契约。

这条路线的技术展开见 technical-design.md：svg_output/使用的是项目规范化 SVG 中间语言——借用 SVG 的 XML 语法与二维图形模型，但允许的元素、属性、单位与 DrawingML 映射由项目规范封闭定义，"SVG 适应 PPT Master，而不是 PPT Master 追随整个 SVG 标准扩张"。SVG 与 DrawingML 共享同一套绝对坐标二维矢量世界观（<rect rx>→prstGeom roundRect、transform→a:xfrm、linearGradient→a:gradFill），所以转换是"方言翻译"而非格式代沟。转换也不是格式猜测，而是有注册表、有保真度说明、可测试的编译：skills/ppt-master/scripts/svg_to_pptx.py 下的svg_to_pptx/drawingml/编译器逐元素派发翻译，每个形状都有自己窄的、可单独调试的翻译器。

因此，项目的工作不只是写出一个.pptx，而是让通用 AI Agent 具备可靠完成演示文稿工作的能力，同时保留用户检查、编辑和拥有结果的权利。

四、目标用户与使用方式

PPT Master 主要服务于以下用户：

• 手上有主题、文档、数据、视觉参考、品牌资产或已有 deck，需要把它们转化为演示文稿；
• 关心 deck 的逻辑和 PowerPoint 可编辑性的深度，而不只是文件能否以.pptx打开；
• 相比几秒钟出片，更重视整份 deck 的一致设计和可靠交付；
• 需要本地持有项目、透明控制成本，并保留选择 AI Agent、模型和 provider 的自由；
• 接受模型决定质量上限，并愿意确认关键方向，在必要时继续用 PowerPoint 完成最后一公里；
• 能够使用对话式 AI 工具和本地 Python 环境，即使本人并不编写代码。

同时，文档也明确划出反面：PPT Master 不以零配置浏览器出片、即时生成、实时团队共编，或完全不需要人类判断和修改的一次性完稿为主要目标。why-ppt-master.md 把这一面翻译成用户可感知的短板表——需要配置（安装 Python、克隆仓库、配置 AI 编辑器）、生成较慢（逐页串行保证跨页一致性）、无协作功能、浏览器预览不是完整自由画布——并直接给出结论：如果你要零配置、浏览器里秒出幻灯片，托管式 SaaS 更适合你。定位文档与面向用户的选型文档由此形成互补：一个说"我们不是什么"，一个说"什么情况下别选我们"。

五、产品承诺及其边界

这是章程中最具约束力的一张表——每项承诺都同时写明含义与边界：

这些承诺在仓库里都能找到执行机构，而非停留在纸面：

• 工程可靠性对应 svg_quality_checker.py 的两段式质量门（early gate 把前五页当作方法样本校准方法，final gate 对完整作者源做发布前检查；error 阻塞、warning 非阻塞、有意不做 auto-fix），以及svg_to_pptx.py在创建 PPTX 前对 final 质量报告的独立发布门——缺失、非 final、含阻塞项或指纹不匹配的报告会被拒绝；structured 输出还要在发布前重新打开临时 PPTX 做 package 级回读校验。
• 事实与意图保真对应 docs/zh/technical-design.md 中的产物所有权切分：sources/是内容契约、analysis/只存机器事实、svg_output/是唯一手写源、svg_final/与exports/是派生物；"修改产物前先确定创作或修改契约"是执行纪律的一部分。
• 数据留在本地对应 getting-started.md 描述的运行方式：源文档本地转换、SVG 本地生成、PPTX 本地导出，唯一外部通信是用户自己选择的模型与 provider 调用。

六、产品能力模型：比单一生成管线宽，比通用办公 Agent 窄

这些是产品责任，不代表每项责任都必须暴露成顶层路线或单独的 workflow 文件。只有输入、修改规则、不变量或产物生命周期确实不同，才需要独立路线。这条原则解释了仓库的组织形态：顶层路线只有三条，而 workflows/index.md 注册的支撑文档则按 profile（image-to-pptx、beautify-pptx、quick-generate）、模板子工作流（create-brand/style/layout/deck）、生成阶段（topic-research、verify-charts、visual-review、live-preview、customize-animations等）和治理（failure-recovery）分类挂载在所选路线之下。

能力模型的宽度也可以从模板资产中读出：skills/ppt-master/templates/ 下维护着 21 个品牌预设、14 个风格、7 个版式与 2 个 Deck 工作区（均有*_index.json索引），另有 33 个图表模板、6 个表格模板、5 个内置图标库、18 种视觉风格与 5 种叙事 mode 的参考目录——它们分别对应"可复用演示设计"与"PowerPoint 表达"两个能力领域，而"演示推理"则由 Strategist 阶段与modes/目录承载。

七、项目拥有的责任与接入的能力

PPT Master 可以接入通用能力，但不因此成为这些通用能力的平台：

provider 隔离是这张表最重要的工程注脚：仓库可以内置多个 provider 以保持开放性和实际可用性，但 provider 特有行为应当隔离在稳定的接入边界之后。这一点在源码目录结构中直接可见——skills/ppt-master/scripts/image_backends/ 内置了 15 个图像生成 backend（OpenAI、Gemini、MiniMax、Qwen、Kimi 系的 modelscope、智谱、Stability、fal、Replicate 等），skills/ppt-master/scripts/tts_backends/ 内置了 5 个 TTS backend（CosyVoice、Edge、ElevenLabs、MiniMax、Qwen），全部经由backend_common.py定义的统一接口接入。演示工作流负责选择逻辑和输出语义，任何单一 provider 都不重新定义产品边界；technical-design.md 还为此规定了具体的隔离纪律，例如图像生成使用 provider 专属 config key 而非通用IMAGE_API_KEY，让"当前用的是哪个 backend"从推理变成可读配置。

八、稳定的技术策略：架构服务于定位

技术架构服务于定位，但技术架构本身不是项目定位。章程列出五条稳定策略，每条都能在仓库中找到对应物：

1. 受约束的 SVG → DrawingML是新设计页面的主要创作和编译路线：AI 使用适合模型的视觉语言工作，确定性工具再构建原生 PowerPoint 对象。证据：svg_to_pptx.py 与svg_to_pptx/drawingml/编译器、svg_quality/契约校验包。
2. 直接 OOXML 操作用于用户希望保留现有 PowerPoint package 而不是重新生成视觉设计的场景。证据：Edit Native PPTX 路线用pptx_to_svg.py --roundtrip导入、svg_to_pptx.py --roundtrip导出，未改页面逐字节恢复，编辑页只重建被编辑的对象。
3. 模板工作区在新页面创作前声明可复用的品牌身份，以及适用时的 Master / Layout、槽位和素材结构；这些结构不能在事后凭空猜测。证据：四类模板工作区（brand / style / layout / deck）与create-template路线；带旧结构语义的模板包不能原地升级，必须新建工作区。
4. sidecar 与 package 级阶段负责演讲者备注、旁白、转场、动画，以及其他不属于静态页面 SVG 的演示行为。证据：animations.jsonsidecar 按 slide stem 与顶层 group id 关联对象级动画；notes/目录承载逐页讲稿；pptx_animations.py、pptx_transitions.py、notes_to_audio.py、powerpoint_video.py等脚本负责对应的 package 级导出。
5. 项目产物和质量门让过程可检查、可续跑、可测试，并能安全地重新导出。证据：前文质量门、validation/workflow.log冷审计日志、backup/冻结作者源，以及 governance/failure-recovery.md 定义的全路由停止/继续规则。

具体实现可以演进，但以下不变量应保持稳定：

1. 不把作为规范交付物的 deck 扁平化成每页一张图片。
2. 完整的可见页面设计必须留在声明的创作源中；导出阶段不得凭空补造缺失视觉。
3. 明确说明原生可编辑性、视觉保真、数据驱动对象和保留程度之间的取舍。
4. 修改产物前先确定创作或修改契约。
5. 区分源材料、创作产物、派生产物和交付产物。
6. 必需语义无法安全表达时应当停止；不得声称不支持的保真度，也不得静默替换成另一种行为。

前两条是"不产整页图片"承诺的架构化表达（对应svg_final/只是派生预览、native 导出唯一读取svg_output/的切分）；最后一条 fail-closed 原则则贯穿质量门实现——svg_to_pptx.py在正式发布前对不合格的质量报告直接拒绝，而不是降级放行。

九、明确不做：把非目标写进政策

PPT Master 不以成为以下产品为目标：

• 零配置、即时出片的浏览器演示 SaaS；
• 完全替代人类演示判断，或承诺一次生成完美终稿的全自动系统；
• 通用办公助手、研究平台、图片平台、音频平台或 provider 市场；
• 完整的 PowerPoint 克隆、完整的浏览器自由画布或实时协作服务；
• 任意 SVG 到 PPTX 或任意 OOXML 的转换服务；
• 从完成态 PPTX 或 SVG 中恢复缺失的历史 Master / Layout 意图；
• 把推断出的模板结构原地嫁接到已有文件上的升级器；
• 以牺牲 deck 一致性、原生可编辑性或交付可靠性为代价的产品级默认速度优先生成器。

这些非目标并不排斥在演示任务中使用研究、图片、音频、原生对象或已有 deck。它们防止支撑能力脱离演示语境，发展成承诺完全不同的独立产品。

roadmap.md 的"明确不做"一节是这份非目标清单的逐案展开，每个条目都附了被评估过的诉求与理由：

• 对任意 PPTX placeholder 系统做无契约盲填——Generate 路线围绕完全可控的新形状创作；"固定位置替换数据"级别的诉求直接写几行python-pptx脚本更划算。
• 把原生 PowerPoint 图表设为默认路线——跨 PowerPoint / Keynote / LibreOffice / WPS 四渲染器的位置保真是主轴，原生图表默认会破坏像素一致性；--native-charts-and-tables是用户显式选择跨端保真换取数据工作簿的窄例外。
• uv 作为默认/必需依赖——pip + requirements.txt是唯一官方安装路径（仓库根目录 requirements.txt 直接-r指向 skill 内的依赖清单）。
• 纯速度优化——成本/速度/质量三角下选择质量优先；quick-generate是用户主动选择的短路，而不是默认档。
• 独立 CLI / 托管 SaaS / 桌面 App 形态——chat 是交互核心，不是包装层。

十、能力准入与削减判据：七问与五种决策

这是章程最具操作性的部分——评估任何新增能力时，按以下顺序回答：

1. 用户任务：它完成了哪一个真实的演示文稿任务？
2. 核心贡献：它是否提升了 PowerPoint 原生深度、改善了演示推理、增强了用户控制，或提高了交付可靠性？
3. 责任结果：它创建或保护了什么演示产物、决策或质量属性？
4. 不变量：什么必须保持不变，什么允许改变？
5. 产品层级：它属于核心能力、演示专用扩展、可替换 provider adapter，还是仓库维护？
6. 可验证性：能否明确检查成功与失败，而不是依赖模糊承诺？
7. 真实证据：是否有真实用户需求、重复工作流或已经发生的失败，足以覆盖维护成本？

用仓库中的真实决策对照这张判据表，可以看得很直观：新增一个图像生成 provider → 第 5 问判为"可替换 provider adapter"，落到image_backends/的稳定边界之后，不进入顶层路线；原生公式（LaTeX → OMML）→ 第 2 问直接强化"原生深度"，成为核心能力并配有封闭的档位表与 fail-closed 校验；"从任意 PPTX 恢复历史 Master/Layout 意图" → 第 6 问无法可验证、第 1 问没有对应的演示任务，于是写入非目标与明确不做；而 update_repo.py 这类服务于仓库自身指纹维护的脚本 → 第 5 问判为仓库工具层，与生产演示文稿的能力完全分列。

最后一条原则值得单独强调：文件或 workflow 的数量本身，不是新增或删除能力的理由。真正的判断标准是责任是否清晰，以及它是否创造明确的产品价值。

十一、北极星结果与改善优先级

一次成功的 PPT Master 使用过程应当是：

用户把主题、源材料、设计参考、可复用模板或已有 PowerPoint 交给 AI Agent。AI 先把论证推理成形，再开始设计；用户确认真正重要的选择；工作流最终返回一份结构连贯、经过校验、具有深度原生能力且可继续编辑的 PowerPoint，以及足够的本地项目状态，用于演示、精修、复用或重新导出。

未来工作应按以下顺序改善这一结果：

1. 原生深度、输出正确性和交付可靠性；
2. 内容推理、叙事质量和视觉一致性；
3. 品牌、风格、版式、Deck 和已有 PowerPoint 资产的复用；
4. 人工审阅、修正和可控迭代；
5. 能够强化前四项的额外格式、provider 和便利能力。

这个优先级顺序与 roadmap.md 的"方向"一节完全一致——主轴是原生深度，按优先级而非固定时间表推进，且明确不承诺交付时间窗口。

十二、与其他文档的关系

这套文档分工本身就是一个可借鉴的治理样本：上游定义"演示媒介是什么、好 deck 的质量层次"（what-is-ppt），中游定义"项目承诺什么、不做什么"（本文），下游分别回答"为什么选它"（why）、"现在怎么实现"（technical-design）、"请求怎么路由"（routing）、"做到哪了、下一步做什么"（roadmap）、"每项能力的当前边界"（powerpoint-svg-mapping）。任何一层发生变化时，歧义仲裁规则都很明确：可执行路线以 routing.md 为准，定位歧义以英文规范源为准。

小结

PPT Master 的定位章程本质上回答了一个问题：当"可编辑"已经只是及格线之后，一个 AI 演示工作流应该把力气花在哪里。它的答案是原生深度这条持续推进的轴线，以及围绕它建立的一整套可执行约束——四条产品轴线、九项带边界的承诺、六条能力责任、一张所有权/不所有权对照表、六条架构不变量、八项非目标和一套七问准入判据。对使用者而言，这份章程是理解每一项承诺（本地数据、成本透明、可继续编辑的草稿）为什么成立、边界在哪里的依据；对维护者而言，它是新增、保留或退役任何能力之前必须过的第一道审查。

• AI 技能
• 人工智能