| 1 | # 项目定位与能力边界 |
| 2 | |
| 3 | [English](../project-positioning.md) | [中文](./project-positioning.md) |
| 4 | |
| 5 | --- |
| 6 | |
| 7 | 本文定义 PPT Master 的长期产品定位，以及新增、保留或削减能力时使用的判断标准。它是一份产品政策，不是功能清单或执行手册。 |
| 8 | |
| 9 | 本文是[英文规范源](../project-positioning.md)的同步中文译本，不形成第二套产品政策；定位变化必须在同一次修改中同步两种语言，如有歧义以英文规范源为准。 |
| 10 | |
| 11 | 当前具体如何选择路线，仍以 [`workflows/routing.md`](../../skills/ppt-master/workflows/routing.md) 为准。本文回答的是更根本的问题：一个方向究竟是否应该属于 PPT Master。 |
| 12 | |
| 13 | ## 一、项目定位 |
| 14 | |
| 15 | > **PPT Master 是一套开源、对话驱动的工作流，让 AI 先把论证推理成形，再设计并产出真正可编辑的 PowerPoint——不是整页图片，也不是一层能改的表皮。它的核心轴线是原生深度：随着版本迭代，持续创作或保留更多 PowerPoint 自身的对象模型、演示行为和可复用结构。** |
| 16 | |
| 17 | 输入可以是一个主题、源材料、数据、设计参考、品牌资产或已有 `.pptx`。主管线负责生成新 deck；其他明确路线和 profile 可以提炼可复用的 Brand / Style / Layout / Deck 工作区，向现有 PowerPoint 填入新内容、重新设计它，或在保留各自契约所承诺内容的前提下追加原生演示行为。 |
| 18 | |
| 19 | 原生深度是一条持续推进的方向，不是一张固定功能清单。PPT Master 的北极星是不断向 PowerPoint 自身靠拢，缩小 AI 能生成的内容与熟练用户可以在 PowerPoint 中手工完成的内容之间的差距。[PowerPoint ↔ SVG 能力映射](../powerpoint-svg-mapping.md)逐项、诚实地记录当前边界。 |
| 20 | |
| 21 | 从产品形态上看，PPT Master 是一套运行在任意支持 Agent 的 AI 工具中的工作流——也就是一个“skill”。它不是模型，不是托管式演示 SaaS，也不是 PowerPoint 的替代品。工作流负责演示文稿专用的推理、契约和质量门；确定性工具负责转换、校验、打包和可重复的文件操作；最终质量上限仍由所选模型决定。 |
| 22 | |
| 23 | 最主要的交付物是一份用户可以直接演示并继续精修的高质量 PowerPoint 草稿，而不是封闭的最终成品。可复用模板工作区、项目源材料、设计规范、预览和校验产物同样是一等支撑产物，因为它们让最终 deck 可控制、可重建、可复用。 |
| 24 | |
| 25 | ## 二、产品主张 |
| 26 | |
| 27 | 一份真正有用的 deck 有两层：让论证成立的推理层，以及让结果真正可用的 PowerPoint 构造层。PPT Master 同时负责这两层。 |
| 28 | |
| 29 | | 轴线 | 项目立场 | 产品结果 | |
| 30 | |---|---|---| |
| 31 | | 逻辑优先 | 绘制页面前先确定核心信息、叙事模式、提纲、层级和证据 | deck 的结构经过推理，而不是机械继承源材料顺序 | |
| 32 | | 原生深度 | 可编辑早已是及格线；真正的问题是可编辑到多深，也就是结果里究竟有多少 PowerPoint | 在所选路线支持的范围内，创作或保留真实 PowerPoint 形状、文字、图片、图表、表格、母版与版式、备注、转场、动画和 package 行为 | |
| 33 | | 诚实的可编辑性 | 输出是用户继续编辑的草稿，不是扁平图片，也不承诺一次生成完美终稿 | 视觉保真、数据驱动对象、跨软件渲染与保留程度之间的取舍必须显式说明 | |
| 34 | | 用户控制 | 工作流、项目状态和输出都归用户所有 | 成本透明；除用户选择的 provider 调用外，数据留在本地；不强制绑定编辑器、模型或平台 | |
| 35 | |
| 36 | 直接 OOXML 过于冗长和脆弱，不适合作为 AI 的通用视觉创作语言；整页图片又会丢掉原生对象模型。因此，PPT Master 把适合模型的视觉创作、确定性编译和直接 package 操作结合起来，并根据用户意图选择正确的修改契约。 |
| 37 | |
| 38 | 因此，项目的工作不只是写出一个 `.pptx`，而是让通用 AI Agent 具备可靠完成演示文稿工作的能力，同时保留用户检查、编辑和拥有结果的权利。 |
| 39 | |
| 40 | ## 三、目标用户与使用方式 |
| 41 | |
| 42 | PPT Master 主要服务于以下用户： |
| 43 | |
| 44 | - 手上有主题、文档、数据、视觉参考、品牌资产或已有 deck，需要把它们转化为演示文稿。 |
| 45 | - 关心 deck 的逻辑和 PowerPoint 可编辑性的深度，而不只是文件能否以 `.pptx` 打开。 |
| 46 | - 相比几秒钟出片，更重视整份 deck 的一致设计和可靠交付。 |
| 47 | - 需要本地持有项目、透明控制成本，并保留选择 AI Agent、模型和 provider 的自由。 |
| 48 | - 接受模型决定质量上限，并愿意确认关键方向，在必要时继续用 PowerPoint 完成最后一公里。 |
| 49 | - 能够使用对话式 AI 工具和本地 Python 环境，即使本人并不编写代码。 |
| 50 | |
| 51 | PPT Master 不以零配置浏览器出片、即时生成、实时团队共编，或完全不需要人类判断和修改的一次性完稿为主要目标。 |
| 52 | |
| 53 | ## 四、产品承诺 |
| 54 | |
| 55 | | 承诺 | 含义 | 边界 | |
| 56 | |---|---|---| |
| 57 | | 原生深度 | 在所选路线支持的范围内，创作或保留真实 PowerPoint 对象、可复用结构和演示行为 | 不把整页截图作为规范的 PPTX 生成结果；不支持的语义与有损取舍必须显式说明 | |
| 58 | | 逻辑先于排版 | 视觉创作前先推理核心信息、叙事、页面顺序和信息层级 | 如果某条路线承诺保留原文或结构，就必须遵守该承诺，不能静默重构 deck | |
| 59 | | 高质量、可继续编辑的草稿 | 消除从原材料到结构连贯、经过设计且仍可精修的 deck 之间的大部分工作 | 不承诺一次生成完美终稿；模型能力和用户判断仍决定上限 | |
| 60 | | 事实与意图保真 | 区分来源事实、用户决策、设计建议和派生产物 | 不编造依据，也不把保留型请求静默改成重新设计 | |
| 61 | | 成本透明且可预测 | PPT Master 保持免费开源；用户只为自己选择的 AI 模型和可选 provider 付费 | 不增加专有点数、按席位收费或额外的演示平台订阅层 | |
| 62 | | 数据留在本地 | 转换、创作、校验和导出都在用户机器上完成 | 用户选择调用的 AI 模型、搜索、生图和语音 provider 仍可能接收调用所需输入 | |
| 63 | | 无平台锁定 | 任何支持 Agent 的 AI 工具和兼容模型都可以驱动工作流，输出保持可迁移 | 不承诺不同模型产出质量完全一致，也不承诺不同演示软件渲染完全一致 | |
| 64 | | 工程可靠性 | 使用明确路线、保留契约、质量门、回读校验和可恢复项目状态 | 不用静默降级掩盖失败，也不发布未通过必需质量门的产物 | |
| 65 | | 质量优先 | 优先保证 deck 一致性、原生可编辑性和交付可靠性 | 可以在不损害质量时提效，但不默认采用低质量并行生成 | |
| 66 | |
| 67 | ## 五、产品能力模型 |
| 68 | |
| 69 | PPT Master 的能力范围比单一生成管线更宽，但有意窄于通用办公 Agent。 |
| 70 | |
| 71 | | 能力领域 | 项目责任 | |
| 72 | |---|---| |
| 73 | | 演示推理 | 把主题或材料包转化为面向受众的核心信息、叙事模式、提纲、页面规划和明确设计方向 | |
| 74 | | 原生演示创作 | 创作新的页面视觉，并编译为真正原生可编辑的 PowerPoint deck | |
| 75 | | 可复用演示设计 | 提炼、创建、组合、校验并应用 Brand、Style、Layout 和 Deck 工作区 | |
| 76 | | 已有 deck 改编 | 在不同保留契约下重做已有 deck、向原生页面壳填入新内容，或追加原生演示行为 | |
| 77 | | PowerPoint 表达 | 在沟通目标需要时使用图片、图示、图表、表格、公式、讲稿、旁白、转场和动画 | |
| 78 | | 审阅与交付 | 预览、检查、校验、修复、导出、回读，并保留足够的本地项目状态供后续精修或重新导出 | |
| 79 | |
| 80 | 这些是产品责任，不代表每项责任都必须暴露成顶层路线或单独的 workflow 文件。只有输入、修改规则、不变量或产物生命周期确实不同，才需要独立路线。 |
| 81 | |
| 82 | ## 六、项目拥有的责任与接入的能力 |
| 83 | |
| 84 | PPT Master 可以接入通用能力，但不因此成为这些通用能力的平台。 |
| 85 | |
| 86 | | 领域 | PPT Master 负责 | PPT Master 不负责 | |
| 87 | |---|---|---| |
| 88 | | 研究 | 判断 deck 需要什么证据、保存来源，并把研究结果转化为演示内容 | 与演示任务无关的通用网络研究引擎 | |
| 89 | | 图片 | 判断是否需要图片，并负责图片的角色、风格、来源、位置、出处和就绪状态 | 通用图片生成或图片管理平台 | |
| 90 | | 音频 | 负责演示语境中的讲稿、音色选择、逐页旁白、计时和 PowerPoint 嵌入 | 通用音频工作站、播客平台或语音供应商市场 | |
| 91 | | 数据可视化 | 选择表达形式、保留数据、校验几何，并显式呈现可编辑性与保真度之间的取舍 | 通用 BI 或电子表格产品 | |
| 92 | | 模板与品牌 | 定义可复用的演示身份、Master / Layout 结构、槽位、素材与组合契约 | 恢复来源文件中已经不存在的历史设计意图 | |
| 93 | | PowerPoint 编辑 | 负责演示专用的生成、填充、重做和有边界的原生增强 | 替代 PowerPoint 的完整编辑界面，或支持任意 OOXML 修改 | |
| 94 | |
| 95 | 仓库可以内置多个 provider，以保持开放性和实际可用性，但 provider 特有行为应当隔离在稳定的接入边界之后。演示工作流负责选择逻辑和输出语义，任何单一 provider 都不应重新定义产品边界。 |
| 96 | |
| 97 | ## 七、稳定的技术策略 |
| 98 | |
| 99 | 技术架构服务于定位，但技术架构本身不是项目定位。 |
| 100 | |
| 101 | - **受约束的 SVG → DrawingML** 是新设计页面的主要创作和编译路线：AI 使用适合模型的视觉语言工作，确定性工具再构建原生 PowerPoint 对象。 |
| 102 | - **直接 OOXML 操作**用于用户希望保留现有 PowerPoint package，而不是重新生成视觉设计的场景。 |
| 103 | - **模板工作区**在新页面创作前声明可复用的品牌身份，以及适用时的 Master / Layout、槽位和素材结构；这些结构不能在事后凭空猜测。 |
| 104 | - **sidecar 与 package 级阶段**负责演讲者备注、旁白、转场、动画，以及其他不属于静态页面 SVG 的演示行为。 |
| 105 | - **项目产物和质量门**让过程可检查、可续跑、可测试，并能安全地重新导出。 |
| 106 | |
| 107 | 具体实现可以演进，但以下不变量应保持稳定： |
| 108 | |
| 109 | 1. 不把作为规范交付物的 deck 扁平化成每页一张图片。 |
| 110 | 2. 完整的可见页面设计必须留在声明的创作源中；导出阶段不得凭空补造缺失视觉。 |
| 111 | 3. 明确说明原生可编辑性、视觉保真、数据驱动对象和保留程度之间的取舍。 |
| 112 | 4. 修改产物前先确定创作或修改契约。 |
| 113 | 5. 区分源材料、创作产物、派生产物和交付产物。 |
| 114 | 6. 必需语义无法安全表达时应当停止；不得声称不支持的保真度，也不得静默替换成另一种行为。 |
| 115 | |
| 116 | ## 八、明确不做 |
| 117 | |
| 118 | PPT Master 不以成为以下产品为目标： |
| 119 | |
| 120 | - 零配置、即时出片的浏览器演示 SaaS。 |
| 121 | - 完全替代人类演示判断，或承诺一次生成完美终稿的全自动系统。 |
| 122 | - 通用办公助手、研究平台、图片平台、音频平台或 provider 市场。 |
| 123 | - 完整的 PowerPoint 克隆、完整的浏览器自由画布或实时协作服务。 |
| 124 | - 任意 SVG 到 PPTX 或任意 OOXML 的转换服务。 |
| 125 | - 从完成态 PPTX 或 SVG 中恢复缺失的历史 Master / Layout 意图。 |
| 126 | - 把推断出的模板结构原地嫁接到已有文件上的升级器。 |
| 127 | - 以牺牲 deck 一致性、原生可编辑性或交付可靠性为代价的产品级默认速度优先生成器。 |
| 128 | |
| 129 | 这些非目标并不排斥在演示任务中使用研究、图片、音频、原生对象或已有 deck。它们防止支撑能力脱离演示语境，发展成承诺完全不同的独立产品。 |
| 130 | |
| 131 | ## 九、能力准入与削减判据 |
| 132 | |
| 133 | 评估任何新增能力时，按以下顺序回答： |
| 134 | |
| 135 | 1. **用户任务**：它完成了哪一个真实的演示文稿任务？ |
| 136 | 2. **核心贡献**：它是否提升了 PowerPoint 原生深度、改善了演示推理、增强了用户控制，或提高了交付可靠性？ |
| 137 | 3. **责任结果**：它创建或保护了什么演示产物、决策或质量属性？ |
| 138 | 4. **不变量**：什么必须保持不变，什么允许改变？ |
| 139 | 5. **产品层级**：它属于核心能力、演示专用扩展、可替换 provider adapter，还是仓库维护？ |
| 140 | 6. **可验证性**：能否明确检查成功与失败，而不是依赖模糊承诺？ |
| 141 | 7. **真实证据**：是否有真实用户需求、重复工作流或已经发生的失败，足以覆盖维护成本？ |
| 142 | |
| 143 | | 决策 | 适用条件 | |
| 144 | |---|---| |
| 145 | | 作为核心能力新增或保留 | 直接推进演示任务，或强化原生深度、推理、用户控制或可靠性，并需要演示专用契约或校验 | |
| 146 | | 作为集成扩展保留 | 能力本身可选，但它的规划和输出语义是演示专用的 | |
| 147 | | 放到稳定接入边界之后 | 底层服务具有通用性或供应商特异性，PPT Master 负责演示专用的选择逻辑和输出契约 | |
| 148 | | 移到仓库工具层 | 服务于仓库、示例、安装或贡献者流程，而不是生产演示文稿 | |
| 149 | | 退役 | 与另一权威重复、没有有效使用者、承诺无法验证，或维护成本高于演示价值 | |
| 150 | |
| 151 | 文件或 workflow 的数量本身，不是新增或删除能力的理由。真正的判断标准是责任是否清晰，以及它是否创造明确的产品价值。 |
| 152 | |
| 153 | ## 十、北极星结果 |
| 154 | |
| 155 | 一次成功的 PPT Master 使用过程应当是： |
| 156 | |
| 157 | > 用户把主题、源材料、设计参考、可复用模板或已有 PowerPoint 交给 AI Agent。AI 先把论证推理成形，再开始设计；用户确认真正重要的选择；工作流最终返回一份结构连贯、经过校验、具有深度原生能力且可继续编辑的 PowerPoint，以及足够的本地项目状态，用于演示、精修、复用或重新导出。 |
| 158 | |
| 159 | 未来工作应按以下顺序改善这一结果： |
| 160 | |
| 161 | 1. 原生深度、输出正确性和交付可靠性。 |
| 162 | 2. 内容推理、叙事质量和视觉一致性。 |
| 163 | 3. 品牌、风格、版式、Deck 和已有 PowerPoint 资产的复用。 |
| 164 | 4. 人工审阅、修正和可控迭代。 |
| 165 | 5. 能够强化前四项的额外格式、provider 和便利能力。 |
| 166 | |
| 167 | ## 十一、与其他文档的关系 |
| 168 | |
| 169 | | 文档 | 责任 | |
| 170 | |---|---| |
| 171 | | [`what-is-ppt.md`](./what-is-ppt.md) | 演示媒介、用户任务、生命周期、原生对象模型、模板与质量层次；本文定位判断的上游前提 | |
| 172 | | 本文 | 长期产品定位、产品承诺、能力边界和准入判据 | |
| 173 | | [`why-ppt-master.md`](./why-ppt-master.md) | 面向用户的差异化和选择理由 | |
| 174 | | [`technical-design.md`](./technical-design.md) | 当前技术架构和实现不变量 | |
| 175 | | [`workflows/routing.md`](../../skills/ppt-master/workflows/routing.md) | 当前可执行路线选择 | |
| 176 | | [`roadmap.md`](./roadmap.md) | 已交付能力、当前优先级和明确推迟的方向 | |
| 177 |