【科技资讯】我用 WorkBuddy 把 MBB 顶级咨询的 PPT 逻辑做成了 Skill

---

本文只讨论一件事：怎样把一页 PPT 背后的判断规则，做成可执行、可验证的 Skill。

此前，我尝试将MBB的咨询框架和方法如问题拆解、Storyline、单页论证和质量检查等咨询方法封装成 Agent和相关Skill，它已经能定义决策问题、组织 Storyline，并形成每一页的内容逻辑，详细内容见过往两篇相关公开文章。

一开始我在 Codex 中进行封装开发，逻辑执行都很顺利，但是在中文 PPT 制作环节中还是有很多小问题，如断行、行距、字号和工具链兼容性会反复影响页面稳定性。腾讯Workbuddy作为国内体验还不错的工作Agent，我就尝试把页面逻辑与 PPT 制作在 WorkBuddy上进行Skill封装，在既有咨询方法之上重做渲染、验证和迭代机制。

这个 Skill 接收结构化的页面内容和视觉配置，输出原生可编辑的 PowerPoint 单页。渲染开始前，它会先检查：这一页回答什么问题、论证是否成立、应该采用哪种展示结构。

一、PPT 生成不难，难的是让一页先在逻辑上成立

输入一段文字，自动生成几页 PPT，这类能力网上已经很多。大模型可以改写标题，绘图库可以放置文本和图形，模板系统也能快速统一配色。

但“生成一个 PPT 文件”与“形成一页有效的咨询型单页”是两回事。前者解决文件生产，后者必须先解决 Page Logic。

一页咨询型 PPT 至少要形成完整链路：

– 它服务于哪个决策问题？

– 行动标题给出了什么回答？

– 页面中的事实、计算或判断如何支撑这个回答？

– 读者应该得出什么含义？

– 管理层下一步要做什么？

如果这些问题没有答案，渲染得再快，也只是更快地产出一张逻辑不成立的页面。标题可能只是话题，图表与结论无关，信息很多，却无法推动讨论和决策。

这个 Skill 的核心不是 pptxgenjs，也不是多种布局，而是把“决策问题—行动标题—论证—含义—管理行动”变成一套可检查的页面契约。绘图只是最后一个阶段。

这里的“MBB 式”指顶级咨询公司的一套表达纪律：结论先行、证据支撑、结构清晰、视觉服务于决策，不涉及任何咨询公司的 Logo 或专有模板。

• 底层逻辑: 如果 Page Logic 没有被明确约束，增加绘图库和布局数量只能扩大输出规模，不能提高论证质量。页面渲染只是最后一步。

二、在 WorkBuddy 中把 Page Logic 做成工程系统

在多数的PPT生成中，会出现代码能跑，页面未必能用的情况。中文遮挡、层级失衡、图表崩溃和逻辑关系不清等问题，通常都要在成品预览中才能发现。

而WorkBuddy 可以在同一工作流中读取资料与脚本、修改代码、调用本地工具、生成 PPT，并根据预览结果继续调整。资料梳理、代码实现和测试也可以拆成并行任务。

工程工作仍然存在，但修改与验证之间的反馈周期明显缩短。我负责定义系统行为和质量标准，WorkBuddy 承担代码实现、批量修改与重复测试。

我先把生成过程拆成五个阶段，每个阶段只处理一类问题，并通过契约向下传递；条件不满足，管线立即停止，先约束内容与逻辑，再决定展示与渲染。

• 核心架构选择: 分开管理“说什么”与“怎么画”。前者由 Page Contract 约束，后者由 Exhibit Route 和 Visual Config 决定。

Skill 的脚本模块分为两个层级：核心引擎层（负责主题、文本、形状、桥梁等底层能力）与布局渲染层（负责将内容对象映射为具体的页面排版）。两层之间通过函数调用接口解耦。

我通过六个版本的迭代最终完成了这个skill的调试，六个版本始终围绕三类问题推进：页面逻辑是否完整、渲染是否稳定、视觉是否准确表达内容关系。

• v1: 跑通基线，形成五阶段管线、pptxgenjs 移植、14 种布局、3 套视觉系统、3 种图表能力

• v2—v3.0: 补齐结构，增加架构原型和验证引擎，并重构为独立模块

• v3.1—v3.2: 提升稳定性，修复图表与中文排版，增加逻辑桥梁和方向判断

• v3.3: 扩展表达，扩展到 22 种布局、7 套视觉系统（未来可以扩展不同的风格）

迭代路径很直接，逻辑缺口进入验证规则，渲染问题进入回归测试，表达不足则回到真实页面寻找样例。

三、方法可以自动化，边界不能丢

1. 中文页面先解决容量边界

中文的字符宽度、断行和视觉密度都有自己的规律。系统会按文本长度调整字号；一旦内容超过页面容量，就返回 Logic Gate 精简文案。

• 工程补充: 行距从 1.02 调到 1.08，正文启用 shrinkText；autoFit 只负责兜底，不能替代内容删减。

2. 视觉元素必须承担逻辑功能

箭头说明证据如何推导出含义，配色区分事实、风险和管理选择，布局表达比较、流程或系统关系。七套视觉系统各自定义了层级、留白和面板语义。每套视觉系统是一组完整的设计标记（Design Tokens），包含画布底色、主/次文字色、accent 体系色、语义功能色（推荐/中性/决策/风险）和面板层深。页面渲染时根据 visualSystem 字段加载对应的完整主题。

设计原则：不同视觉系统不是同一模板的”换色”。它们拥有独立的层级结构、间距体系、面板语义和字体使用策略。例如 mck-light 以灰色大片留白为主基调，drk-dark 以青色活跃路径区分动态节点，architect-dark 使用代码风格标签（如 [LAYER-01]）来标注架构层级。

3. 验证规则必须外置，判断留给人

系统可以检查字段、结构、枚举和页面契约一致性，也能区分事实、计算、基准、推断、假设和管理选择六类证据。

但它不会自动把内容判定为“正确”。证据强度、架构安全性和管理后果仍需人工确认。生成速度越快，这层边界越重要。

为避免规则随对话上下文漂移，我把关键知识写进 Page Contract、参考文档、验证规则和版本记录。提示词负责触发流程，文件中的契约和规则决定系统如何执行。

四、产出与边界：从生成工具到领域 Skill

当前版本包含7套视觉系统、22种布局类型、5种架构原型、3种原生图表。共有 5 个脚本模块，共 2421 行；另有 10 篇参考文档，共 4913 词。它们共同管理页面契约、逻辑门、展示路由、视觉系统、布局图库、架构契约与质量检查。

在使用层面，输入主要被收敛为两份 JSON：Page Contract 负责内容与逻辑，Visual Config 负责视觉与几何。通过验证后，系统输出一张原生可编辑的 PPTX。

WorkBuddy 减少的是实现和验证成本，不是专业判断。我仍然需要定义页面契约、选择样例、判断证据是否充分，并对输出页面负责。

当前能力仍停留在单页。进入多页报告后，难点会转向 Storyline 连贯性、页面间一致性、数据刷新和团队版本管理；在这些问题解决之前，它还不能被称为完整的报告生成系统。

• 结语: 这次重构最值得复用的，不是 22 种布局，而是把“何时可以画、应该怎么画、何时必须停下”写成了系统规则。

• 互动问题: 多页报告的 Storyline 连贯性，能否也写成可检查的契约？你们团队做 PPT 时，最难标准化的是页面逻辑，还是排版与渲染？

文中“BCG”“McKinsey”“MBB”仅用于描述公开可观察的咨询表达思路与视觉风格。本 Skill 并非相关机构官方产品，也不包含其 Logo 或专有模板。

---