PPTX Deck 设计画像（Design Profile）实战指南：在 pptx-deck-creation 中锁定品牌与视觉风格

导读

本文围绕 pptx-deck-creation 插件中 pptx-deck-context 技能提供的设计画像（Design Profile）机制展开，讲解如何在编写可编辑 PPTX 幻灯片之前，用可复用的设计画像作为设计证据（design evidence），把调色板、排版、间距与签名元素（signature element）锁定进 summary.design_context，并最终翻译为坐标明确的 layout_tree 契约。读完本文，你将掌握三条内置画像（fluent-ui-design-tokens、primer-primitives、editorial-minimal）的适用场景与取舍标准、设计锁定的完整工作流，以及如何在不复制任何专有素材的前提下，把参考设计信号转化为可审计、可运行的版式契约。

一、设计画像在整个 Deck 工作流中的位置

在 pptx-deck-context 技能 的决策序列中，设计方向选择是第五步之前的关键动作：

1. 确认受众、决策、页数、语言、资料来源与品牌需求；
2. 选择叙事框架（mckinsey、scqa、pyramid、mece、action-title、assertion-evidence、exec-summary-first 或 custom），若用户未指定则显式提供选择，不得擅自替用户决定；
3. 为每个指标、引述、图表数值与事实性论断分配稳定 source ID，并规划 source_ref；
4. 选择有据可查的设计方向：优先用户品牌指南，其次只读参考 Deck 证据，最后才是 design-profiles.md 中的可复用画像；
5. 在开始撰写幻灯片前，把框架、假设、来源清单、调色板、排版、间距与签名元素全部记录进 summary。

也就是说，设计画像（Design Profile）是设计证据链中的第三优先级来源，其地位低于"用户显式品牌指南"与"只读参考 Deck 证据"，但它提供了一条标准化、可重复、无需外部素材的兜底路径，尤其适合没有品牌手册、也没有参考样片的场景。

设计画像的价值还在于它把"好看"这种主观判断，转译为可以写入 JSON 契约的客观参数。正如 pptx-slide-specification 技能 所强调的："最终的树是审计契约，而非渲染提示"——任何渲染器都不得在审计之后自行决定排版、缩放文字或推断布局，因此设计锁定必须发生在坐标编写之前，并且要以可验证的参数形式沉淀下来。

二、三条内置设计画像：适用场景与信号特征

design-profiles.md 以一张表格定义了三条画像，每条画像都给出了**适用场景（Best for）与信号特征（Signals）**两个维度，方便在不同演讲场景中快速取舍：

Profile	最佳适用场景	信号特征
fluent-ui-design-tokens	企业级与微软风格对齐的演示	克制的中性色、清晰的层级、基于 token 的间距、适度的圆角
primer-primitives	GitHub 与开发者向演示	清爽的表面、强文字对比、功能性强调色、紧凑标签
editorial-minimal	高管叙事与研究型演示	大量留白、高对比文字、有限调色板、单一视觉母题

这三条画像的设计语义如下：

• fluent-ui-design-tokens：适合汇报给企业客户、董事会或需要传递"严谨、规范"气质的场景。它的核心信号是"token 化"——间距、圆角、字号都应来自一致的 token 体系，中性色承担大面积表面，强调色只用于关键操作与层级提示。这与 Microsoft Fluent 设计语言的工程化思路一致，但本项目只借用其"设计信号"，不复制任何微软素材（详见后文规则）。
• primer-primitives：面向开发者社区、技术宣讲、开源项目发布等场景。其信号强调"清晰与功能"：表面干净利落、正文与背景对比强烈、强调色承担功能性语义（如状态、链接、代码高亮）、标签紧凑以节省横向空间。如果你要做一个面向工程师的架构分享或 API 发布会，这条画像比企业风更贴合受众预期。
• editorial-minimal：面向高管汇报、研究报告、白皮书式叙事。核心是"克制"：大量留白制造呼吸感，高对比度的字体承载阅读，调色板被刻意限制在两三种颜色以内，全篇只保留一个视觉母题（motif）来建立记忆点。适合信息密度高、需要读者专注逻辑主线的内容。

从仓库源码结构看，这三条画像并非绑定特定渲染实现的配置模板，而是文档化的设计契约：pptx-deck-creation 插件不内置渲染器（参见 README 边界说明），只在小任务范围内按需生成 python-pptx 构建脚本，因此画像的作用是"在坐标编写前统一视觉意图"，而非"自动套用皮肤"。

三、设计锁定的四条规则：从证据到契约

design-profiles.md 的第二部分给出了四条强制规则，它们是设计画像能够被安全使用的边界条件：

规则 1：证据优先级——品牌指南 > 参考 Deck 证据 > 文档化画像

Prefer an explicit user brand guide. Otherwise use read-only reference-deck evidence, then a documented profile.

当用户能提供明确品牌指南时，必须以品牌指南为准；否则退回只读参考 Deck 证据（通过 pptx-reference-deck-analysis 技能 提取设计信号）；最后才使用文档化画像。这条优先级保证了：画像只是兜底方案，绝不凌驾于用户真实品牌资产之上。

规则 2：记录画像 ID、来源 URL（如适用）与许可证信息

Record profile ID, source URL when applicable, license information when known, and the resulting style lock.

使用画像不是"选个名字就行"，必须形成可追溯的记录：画像 ID、来源 URL（当适用时）、已知的许可证信息，以及最终形成的 style lock（风格锁定）。这保证了任何后续审计者都能从 summary.design_context 反查设计出处。这与 pptx-deck-creation-builder 智能体 的"不可协商规则"一致：不得编造缺失的品牌、来源、许可证或无障碍事实，要明确指出缺口并请求决策。

规则 3：公开设计信号仅用于灵感，绝不复制专有素材

Use public design signals for inspiration only. Do not copy proprietary images, logos, fonts, screenshots, or slide content.

这是版权合规的底线。画像与参考 Deck 只能贡献抽象的设计信号（色相倾向、层级关系、间距节奏、排版气质），任何专有图片、Logo、字体、截图或幻灯片内容都不得被复制进新 Deck。配套的 asset-guidance.md 提供了更细的资产溯源要求：放置外部资产前必须记录本地路径、来源 URL 或提供商、使用权与简洁 alt 文本，权利未知则一律不用。

规则 4：把锁定翻译成显式的 layout_tree 参数

Translate the lock into explicit layout_tree colors, fills, typography, rules, card shells, and bboxes.

设计锁定的最终归宿是 layout_tree——不是"让渲染器看着办"，而是把每个对象的位置、尺寸、颜色、填充、字号、规则线、卡片外壳与边界框（bbox）显式写出。这一点与 pptx-slide-specification 技能 的规则完全同构：使用稳定的可读 ID、绝对定位组与正英寸尺寸；普通内容必须落在安全边距内、页脚轨道之上，只有背景 layout_design 对象可以出血（full bleed）；正文不小于 9pt，优先通过删减文字、调整 bbox 或拆分密度来解决溢出，而非缩小字号。

四、把设计锁定翻译为 layout_tree：布局契约实例

设计画像要产生实际效果，必须落到 layout-contract.md 定义的 JSON 契约中。该契约规定生成的 Deck 使用包含 summary 与 slides 的 JSON 根结构，最终树是"审计契约，而非渲染提示"。一个最小契约示例：

{
  "summary": {
    "layout_policy": {
      "safe_margin": 0.5,
      "content_bottom": 6.7,
      "footer_top": 6.85,
      "minimum_gap": 0.12
    },
    "accessibility": {
      "language": "en-US",
      "presentation_title": "Quarterly operating review"
    }
  },
  "slides": [{
    "id": "s01_overview",
    "title": "Operating margin improves after the cost reset",
    "accessibility": { "reading_order": ["title"] },
    "layout_tree": {
      "slide_size": { "width": 13.333, "height": 7.5 },
      "root_group_id": "root",
      "groups": { "root": { "id": "root", "role": "slide", "layout_mode": "absolute", "object_ids": ["title"], "group_ids": [], "bbox": { "x": 0, "y": 0, "width": 13.333, "height": 7.5 } } },
      "objects": { "title": { "id": "title", "kind": "text", "role": "title", "classification": "content", "content": { "text": "Operating margin improves after the cost reset" }, "style": { "font_size": 30, "color": "#111827" }, "bbox": { "x": 0.75, "y": 0.55, "width": 10.8, "height": 0.65 }, "z_index": 2 } }
    }
  }]
}

对照这张契约，可以清楚地看到设计画像的落点：

• 调色板：落在每个对象的 style.color、填充与规则线设置中（示例中标题使用深色 #111827）；
• 排版：落在 style.font_size 以及字号分布策略中（正文不低于 9pt）；
• 间距：落在 layout_policy 的 safe_margin、content_bottom、footer_top、minimum_gap，以及每个对象的 bbox 坐标中；
• 签名元素：通过 classification、role 与 z_index 组织成有意识的视觉层级。

契约还定义了修复顺序（Repair order）：先移动/调整 bbox、改变 z 顺序或拆分密集页；其次缩短文案或扩大文字 bbox；最后才允许改字号（且正文永不小于 9pt）；重建后需将实际对象边界与契约比对。

五、构建端的验证闭环：设计审计如何兜底

设计画像并非写完即弃的装饰，而是贯穿到 pptx-quality-gates 审计清单 的强制检查项中。构建前审计直接包含两条与设计画像强相关的检查：

1. 设计上下文检查（第 4 项）：summary.design_context 必须指明一个风格锁定或已批准来源；除非用户显式要求，否则拒绝默认主题、纯标题加要点的输出。这从机制上保证了"每套 Deck 都有明确的视觉依据"。
2. 布局策略检查（第 5 项）：内容必须保持在安全边距内、页脚轨道之上，只有 layout_design 对象允许出血。

此外还有内容碰撞（bbox 不得重叠）、文字容量（CJK/全角文本每行字符数估计减半）、类型尺度（正文至少 9pt）、包含关系（子对象适配父组、形状内文字尊重内边距）、表格、原生可编辑性、来源溯源性（可解析的 source ID、定位器、声明类型与验证状态）以及正向几何（每个对象正尺寸、构建前归一化线端点）等十余项检查。构建后还需重开包比对实际页数、边界、隐藏页状态与请求几何，校验无障碍标题、语言、阅读顺序、有意义的图片 alt 文本与表格表头，并运行 OOXML 包校验器修复畸形 XML、断裂关系、内容类型缺口与重复布局链接。交付前提是所有检查通过，或每个例外均注明幻灯片 ID、对象 ID、原因、负责人与审查日期。

这套闭环意味着：fluent-ui-design-tokens 之类的画像选择，最终会以"设计上下文已锁定 + 布局参数合规"的形式被审计清单量化验证，而不是停留在口头风格描述。

六、从哪里提取画像之外的设计信号：参考 Deck 的只读分析

当用户提供参考 Deck 时，pptx-reference-deck-analysis 技能 提供了提取设计信号的只读路径，这比直接套用画像更贴近用户预期。其提供的分析配方包括：

• Prompt context：返回 slide_count、slide_size、风格与品牌信号、模板/版式证据，以及带形状计数的简短标题/文本摘要；
• Full extraction：返回只读 summary、逐页 layout_tree 证据与审计所需的 OOXML 标记；未经明确批准，资产引用与专有内容不得进入新 Deck；
• Style master：汇总调色板、强调色、排版、字号分布、母版/版式使用与主导流程模式；
• Derived reference-template catalog：按零基索引列出每个源幻灯片，记录版式角色、视觉描述、可用区域、占位符角色、视觉结构与内容适配约束。目录是"对分析结果的视图，而非复制计划"，仅供灵感参考，目标页必须独立编写坐标。

配套的 reference-deck-analysis-patterns.md 给出了临时分析脚本的参考模式（仅作文档用途，不打包为可导入的分析库）：以 EMU_PER_INCH = 914400 为换算基准把 EMU 转为英寸，递归遍历形状（含嵌套 shape.shapes），并在遍历时统计颜色与字体；对填充、线条、颜色、图片数据、表格与图表等可选属性要包裹异常处理，因为参考 Deck 中这些属性可能缺失或不被支持。

参考 Deck 分析产出的"风格主数据"（palette、typography、font-size 分布、母版/版式使用、主导流程）恰好可以作为"信号"对照三条画像：如果参考 Deck 的中性色克制、层级清晰、间距呈 token 式节奏，那么 fluent-ui-design-tokens 就是合适的画像抽象；如果表面清爽、强调色功能性、标签紧凑，则更接近 primer-primitives。画像在这里起到的是"把零散参考信号归一化为一套可命名、可记录、可复用的设计语言"的作用。

七、实操要点速查

综合 design-profiles.md、SKILL.md 与配套技能，一次规范的设计画像落地流程可概括为：

1. 选画像：企业/微软风格 → fluent-ui-design-tokens；开发者/GitHub 风格 → primer-primitives；高管叙事/研究报告 → editorial-minimal；有品牌手册或参考 Deck 则按证据优先级先取用它们。
2. 记证据：记录画像 ID、来源 URL（如适用）、许可证信息（如已知），以及最终 style lock，全部落入 summary.design_context。
3. 守边界：画像与参考 Deck 只提供灵感信号；不复制专有图片、Logo、字体、截图或幻灯片内容；资产权利未知则不用。
4. 翻契约：把调色板写进 style.color/填充/规则线，排版写进 font_size（正文 ≥ 9pt），间距写进 layout_policy 与各对象 bbox，签名元素通过 classification/role/z_index 组织。
5. 过审计：确保 summary.design_context 指明风格锁定或已批准来源，内容落在安全边距与页脚轨道内，其余审计项全部通过或逐项记录例外。

这条链路把"选一个设计方向"从主观审美问题，变成了"证据可追溯、参数可审计、输出可重建"的工程问题——这正是 pptx-deck-creation 插件"创建可编辑、生产就绪 PPTX 演示"的核心方法论：叙事、来源与设计上下文先行，坐标契约随后，构建与审计收尾。