企业官网建设流程全解析

PPT Master 风格模板（Style）创建指南：Create Style 子工作流从输入解读到注册验证全解析

【免费下载链接】ppt-masterAI turns documents or topics into real, native PowerPoint decks—with native shapes, transitions and animations,>项目地址: https://gitcode.com/GitHub_Trending/ppt/ppt-master

本文基于仓库中的 Create Style Workflow 编写，结合 Create Template 的共享执行契约、真实注册的 Style 规格文件（如 mbb-consulting 风格规格）与底层工具脚本，系统讲解在 PPT Master 中如何创建一套「可复用的沟通方法与视觉默认值」风格模板。

在 PPT Master（项目路径GitHub_Trending/ppt/ppt-master）中，模板体系分为 Brand、Style、Layout、Deck 四种互相独立的种类（kind），每一种在仓库 templates/README.md 中都有明确的权责划分。其中 Style 的定位最为特殊：它不产出任何一页页面原型，也不绑定任何品牌身份或项目沟通契约，而是提炼一套「跨项目可复用的论证方式、证据表达规则与视觉默认值」，让同一套方法论可以在无数个项目中被反复套用。

本指南将完整解析 Create Style 子工作流：它的职责边界、输入如何被解读、规格（Design Spec）的完整字段与 YAML 骨架、物化与验证流程、以及它在库（library）与项目（project）两种作用域下的注册差异。读完本文，你将能看懂仓库中每一个templates/styles/<style_id>/templates/design_spec.md是如何被创作和校验的，并能独立依据该工作流起草一份完整、可注册的 Style 规格。

1. 定位：Style 只是 Create Template 的一个子工作流

Create Style 不是一个独立入口，它只在 Create Template 分发kind: style之后被激活。Create Template 作为固定入口，负责分发、作用域选择、用户确认门（confirmation gate）、冲突预检（collision preflight）、注册、完成与生成（Generate）交接；而 Create Style 只负责四件事：

1. 可复用的沟通方法（argument flow、页面信息纪律、论断与证据处理）；
2. 页面角色词汇表（Page Role Vocabulary）；
3. 证据纪律（evidence discipline）与视觉系统默认值；
4. 图片/图标方向与（仅在用户主动开启时的）审查焦点。

两种作用域的核心差异如下（见 create-template.md 的 Scope 表）：

工作流内的调用关系为：§1–2（输入解读与 Brief）喂给 Create Template 的 Step 2–3；Step 4 解析出<template_workspace>/<design_spec_path>后，§3 负责物化；§4 将验证证据返回给 Step 5、7、8。结构化预览（Step 6 的 review PPTX）对 Style 永远跳过。

三条硬规则

文档开篇用三条 hard rule 划死了 Style 的边界，理解它们是理解整个工作流的前提：

• 是子工作流而非顶层路由：只在 Create Template 的单一共享确认门之下执行，绝不作为竞争入口或二次确认存在。
• 只有方法与默认值：Style 拥有「可复用的论证方式、证据表达方式、非约束性设计默认值的协调方式」——它不拥有当前项目的沟通契约、品牌身份、页面几何、画布、SVG 原型、Master/Layout 图、占位符契约、应用契约、资产清单、载体资格或能力白名单。
• 没有页面原型：Style 只贡献一份 Design Spec——没有 SVG、没有 review PPTX、没有空的images//icons//exports/；其他种类在共享项目工作区中拥有的文件一律不触碰。

这也解释了为什么仓库中每个注册 Style 的目录结构都极其精简，例如 mbb-consulting 目录 下只有一个templates/design_spec.md。

2. 输入解读：五种证据来源各能「提供什么」、绝不能「变成什么」

Create Style 的 §1 给出了一张关键约束表，明确每种输入可以影响什么、禁止演变成什么：

系列感知的 PPTX 分析（强制项）

在从复合参考物推断跨页节奏之前，必须区分「连贯的成品套系」与「页面/版式库」：只有套系内部才能推断节奏，版式库的页面只能作为相互独立的构图证据。同时必须：

• 在 Style Overview 中保留来源（provenance）；
• 把用户自决的决策与 AI 默认值区分开；
• 拒绝组织机密的示例，绝不对专有框架做泛化。

参考而非约束

用户偏好的目录 mode、视觉风格、渲染方式、回退配色或字体栈，只作为 Stage-2 解决方案的种子，永远不是执行锁，也永远不能绕过确认门。这一点与 modes 目录索引 中「Reference — not a constraint」的表述完全一致。

3. Style Brief 与规格骨架：完整字段与可复制模板

3.1 需要向 Create Template Step 2 提供的字段（全部必填）

1. Style ID（文件系统安全的可移植 slug）与显示名；
2. Best Fit：可复用的决策/解释/表达场景（不绑定受众与结果）；
3. 可复用意图（Reusable Intent）；
4. 沟通方法：论证流程、页面信息纪律、论断/证据处理（preferred mode 可选）；
5. 页面角色词汇表：角色、职责、证据义务、构图倾向（不含顺序或包含策略）；
6. 证据与数据表达：图表、表格、来源、可编辑性指导（不含数字配额）；
7. 视觉系统默认值：构图、密度、装饰、色彩行为、原生文本气质（种子与字面回退可选；载体与构件的资格判断留给下游）；
8. 图片与图标方向：渲染方式、中心性、重现频率、处理默认值（不含来源限制、清单或页面映射）；
9. 审查焦点：仅当用户明确激活视觉审查时才应用的检查项。

3.2 完整规格模板（可直接复制）

原文档给出了完整的可复制骨架，以下为逐字继承的规范模板。注意 frontmatter 只允许四个字段：style_id、kind、summary、keywords（3–5 个发现标签）：

--- style_id: <confirmed slug> kind: style summary: <one-line reusable method and design-default fit> keywords: [<three-to-five discovery tags>] --- # <Style Name> — Style Specification > Method and design defaults only. No project communication contract, brand identity, page structure, or SVG prototypes. ## I. Style Overview | Property | Value | |---|---| | Style Name | <display name> | | Best Fit | <reusable selection context> | | Reusable Intent | <stable method/design outcome> | | Sources | <URLs, references, or user brief; date/version when known> | ## II. Communication Method - **Preferred Mode**: <catalog id or custom; omit when none> - **Mode References**: <catalog ids used by a custom seed; omit when none> - **Mode Behavior**: <required for custom; omit for a preset> - **Argument Flow** / **Page Message Discipline** / **Claim Discipline**: <prose> ## III. Page Role Vocabulary | Role | Communication Job | Evidence Obligation | Composition Tendency | |---|---|---|---| ## IV. Evidence & Data Expression - **Argument Trace** / **Charts** / **Tables** / **Sources** / **Native Editability**: <prose> ## V. Visual System Defaults - **Preferred Visual Style** / **Visual Style References** / **Visual Style Behavior**: <as for Mode> - **Composition** / **Density** / **Decoration** / **Color Behavior** / **Typography Character**: <prose; no identity claim> ### Fallback Color Scheme (conditional) | Role | HEX | Purpose | |---|---|---| ### Fallback Typography (conditional) | Role | Primary | Fallback Tail | Character | |---|---|---|---| ## VI. Image & Icon Direction - **Preferred Image Rendering** / **Image Rendering References** / **Image Rendering Behavior**: <as for Mode> - **Image Usage** / **Image Treatment** / **Icon Treatment**: <prose; library and inventory stay Stage-2 decisions> ## VII. Review Focus <!-- visual-review-trigger: explicit-user-only --> > Apply only after the user explicitly activates visual review. It never triggers that stage. - <style-specific check>

3.3 关键填充规则

• 回退小节按需省略：没有字面值时，整个 Fallback 小节（Color Scheme / Typography）直接省略；颜色一律用#RRGGBB精确值。
• 身份替换是一个整体决定：当提供了 Brand 或 Deck 身份时，它以一个决定替换重叠的回退颜色、字体、语气与图标身份，但不抹掉方法本身。
• 种子只是推荐：preset 必须是真实存在的目录 ID（如 mode 目录中的pyramid、narrative、briefing，见 modes/_index.md）；custom只能保留「确实被用到的真实引用」加上行为描述文字。
• 硬规则——Style 绝不变成能力策略：它可以微调处理方式、权重、密度、重现频率与连贯性，但永远不能禁止或强制某种载体、选择图片来源、或收窄基本图元（primitives）、预设、构图、布尔运算或自由形式。
• Page Role Vocabulary 是词汇表而非页单：不允许出现顺序、状态、数量、文件名、身份、插槽或内容策略。

4. 物化：Style 只写一份文件

Create Style §3 的规则极其简单而严格：只写templates/design_spec.md（项目作用域下为design_spec.style.<style_id>.md）。不创建、不采用任何图片、图标、SVG、payload 或导出物——所有参考都只以文本形式留在 Sources 栏里作为溯源（provenance）。

对比同类子工作流可以更清晰地看到边界：Create Brand 可以额外采用images/（Logo/照片）与icons/（品牌化图标覆盖），而 Style 什么都没有——这正是「无页面原型」硬规则的直接体现。

5. 验证清单：什么必须存在、什么必须不存在

Create Style §4 的验证结果返回给 Create Template 的 Step 5、7、8，逐项要求如下：

必须满足：

• frontmatter 非空：style_id、kind: style、summary、3–5 个keywords，且没有其他任何 frontmatter 字段；
• style_id与库工作区 ID 一致；
• 章节 I–VII 全部存在；preset 种子解析到真实 ID，custom 种子携带行为描述文字；
• 没有任何*.svg、资产目录、导出物或 payload；
• Review Focus 恰好携带一个<!-- visual-review-trigger: explicit-user-only -->标记，且该节不能激活视觉审查阶段（对比 visual-review 阶段，Style 的 Review Focus 是纯建议性的）。

必须不存在：

• primary_color、画布、页数/页型、复制策略、结构、Master/Layout、占位符、Page Roster、Signature Design Elements；
• 当前项目的受众、目标、交付背景、后续生命周期（afterlife）、大纲、页面指派、图标清单或图片映射；
• 仅 Brand 有、仅 Deck 有的章节；回退小节必须保留其精确名称（不能改名）。

5.1 两种作用域的校验与注册命令

两种作用域都要先跑模板模式质量检查器：

python3 skills/ppt-master/scripts/svg_quality_checker.py "<template_workspace>/templates" --template-mode --canonical-authoring

该检查器在模板模式下（见 template-tools.md）会检测 kind 并校验「无页单契约」：对kind: style校验 frontmatter、章节/字段形态、条件性的 custom 与回退值、可移植 ID，以及「单文件、无页单」的边界。

库作用域在此基础上增加注册预演（dry-run），确认门通过后由 Create Template Step 7 正式注册：

python3 skills/ppt-master/scripts/register_template.py <style_id> --kind style --dry-run python3 skills/ppt-master/scripts/register_template.py <style_id> --kind style

项目作用域两条命令都跳过，并报告Not registered (project workspace)。register_template.py从templates/design_spec.md的 frontmatter（优先）或正文推导索引条目，并更新templates/styles/styles_index.json——该 JSON 是默认 Stage-1 模板控件与聊天列表的唯一发现来源（不扫描目录）。下游消费必须经由 Generate Step 3 的显式工作区根路径；裸的 Style 名称或风格描述永远不会激活它（见 routing.md 的模板选择边界）。

6. 源码级实例：mbb-consulting 风格规格逐节解析

仓库 styles 索引 当前注册了 13 个风格：academic-research、consulting-decision、creative-pitch、incident-postmortem、investor-pitch、mbb-consulting、narrative-keynote、operating-review、product-launch、science-explainer、solution-proposal、technical-deepdive、workshop-teaching。每个目录都只含templates/design_spec.md，与 §4 的「单文件」规则完全吻合。

以 mbb-consulting/templates/design_spec.md 为最完整的真实范本，可以看到规范骨架是如何被实例化的：

Frontmatter 与 Overview。frontmatter 恰好四个字段：style_id: mbb-consulting、kind: style、一行 summary、5 个 keywords（consulting, strategy-document, MBB-style, document-density, exhibits）。Overview 中的 Best Fit 描述为「桌边阅读距离下的战略文档」场景，Sources 明确记录了方法来源（继承自consulting-decision，以及 2026-09-05 从 EV 市场优先级 deck 确认的文档密度页面约定）——这正是 §1「保留来源」要求的落地。

II. Communication Method。Preferred Mode: pyramid（结论先行的论证骨架，对应 modes 目录 中的真实目录 ID）；Argument Flow 定义了overall answer → key support → page message → evidence的可追溯链；Page Message Discipline 要求每页一个问题 + 断言式标题 + 可见证明；Claim Discipline 要求事实、假设、含义、建议语义分离。

III. Page Role Vocabulary。给出了 11 行角色表（Executive synthesis、Recommendation、Situation/complication/resolution、Driver decomposition、Current-state diagnosis、Comparison/benchmark、Process/operating model、Roadmap、Risk/mitigation、Decision request、Appendix/evidence），每行包含 Communication Job、Evidence Obligation、Composition Tendency——没有顺序、数量或文件名，印证了「词汇表而非页单」的硬规则。

IV. Evidence & Data Expression。详细规定了 Argument Trace（每页信息必须向上追溯到总答案的一个关键支撑、向下指向可见证明）、Charts（展品 A/B/C 编号徽章、直接标注数值、去网格线、强调决策相关变化）、Tables（列与行组从比较/决策逻辑派生）、Sources（左下角编号脚注 + 来源行，估计值/代理值/情景值必须标注）、Native Editability（优先可编辑的原生图表/表格/业务形状）。

V. Visual System Defaults。Preferred Visual Style: custom+Visual Style References: swiss-minimal——custom 种子真实引用了一个目录条目并附带了详细的行为散文。Composition/Density/Decoration/Color Behavior/Typography Character 五个维度全部填满，其中 Density 给出了 1280px 画布上的具体字号阶梯（标题 24px、正文 14px、脚注 10px 等），是「非约束性默认值」的典型写法。Fallback Color Scheme提供了 10 行精确 HEX 表（Dominant#051C2C、Accent#2251FF等），Fallback Typography给出了 Microsoft YaHei / Arial 的字体栈——两节均使用精确名称且格式合法。

VI. Image & Icon Direction。Preferred Image Rendering: minimalist-swiss解析到真实渲染目录条目；Image Usage 强调「图片只在提供证据、必要上下文或因果解释时使用」，Icon Treatment 要求单一连贯图标族。

VII. Review Focus。恰好一个<!-- visual-review-trigger: explicit-user-only -->标记，附 8 条风格专属检查项（答案在渲染尺寸下可快速识别、论断与证据空间相连、密度页有清晰扫描路径等），全部以「仅当用户明确激活视觉审查时应用」为前提。

这份真实文件完整对应了工作流的每一处要求，可以作为创作任何新 Style 规格时的对照基准。

7. 在完整生命周期中的位置：从分发到下游消费

把 Create Style 放回完整链路（见 create-template.md 的 Process Overview）：

Reference Bundle Intake & Analysis → Fact-Based Brief Proposal → User Confirmation Gate → Preflight + Invoke Selected Child → Validate Child Output → [Review PPTX: 仅 Layout/Deck] → [Register Library Index] → Output

要点：

• 确认门（Step 3）之前禁止写入：任何最终模板目录、模板 SVG 或 Design Spec 都不得在[TEMPLATE_BRIEF_CONFIRMED]发出前落盘；Style 分支在 Step 4 后直接进入本子工作流 §3，不经过 Template_Designer、不写 SVG、不建结构。
• Step 5 分流：Brand/Style 分支跑本子工作流 §4 清单 + 模板模式检查器；库作用域加--dry-run，随后跳过 Step 6（review PPTX 与多 Master 门对 Brand/Style 永远不触发）。
• Step 7 注册：库作用域正式register_template.py <style_id> --kind style；项目作用域报告未注册。
• Step 8 输出：完成报告只列出 spec 一份文件，Brand/Style 均标注SVG roster: N/A与Native structure: N/A，Style 额外标注Visual review trigger: N/A (advisory focus only)。
• Handoff：<template_workspace>/作为精确候选交给 Generate Step 3（见 generate-pptx.md）；应用阶段通过 apply-template-workspace 阶段 安装，且只消费显式根路径。

8. 工具链速查

结语

Create Style 是整个 PPT Master 模板体系中「方法论资产化」的关键环节：它用一份文件承载跨项目可复用的论证方式、证据纪律与视觉默认值，同时用三条硬规则把自己的边界锁死在「方法与默认值」之内——不碰品牌身份、不碰结构、不碰任何当前项目的事实。仓库中 13 个已注册 Style 与完整的 mbb-consulting 范本，为遵循该工作流创作新风格提供了可对照的真实基线。当你需要让「如何论证、如何呈现证据、如何排版」这套经验脱离具体项目被反复复用，而不是复用某一页设计时，Create Style 就是正确的入口。

【免费下载链接】ppt-masterAI turns documents or topics into real, native PowerPoint decks—with native shapes, transitions and animations,>项目地址: https://gitcode.com/GitHub_Trending/ppt/ppt-master