umarmsharif/strategy-deck-builder

strategy-deck-builder 是做什么的？

一项用于构建咨询级演示文稿的技能，基于 v5 亮白与松木设计系统 — 亮近白底色 (FCFCFA)、深松木强调色 (12564A)、浓缩咖啡黑 (1A1A1A) 文字、每份演示文稿一种显示字体（默认 Charter）搭配 Manrope 正文字体，通过细线和字重而非彩色条带传达强调，优先输出 pptx 格式。该系统的设计初衷是避免当前普遍被认为是 AI 设计痕迹的模式 — 暖色米白底色、单一字体、单侧强调条、徽章元素、超大章节编号。反“粗制滥造”的姿态深植于其设计基因中：参见 references/anti-slop.md（映射至演示文稿相关性的“粗制滥造”目录）以及 scripts/deck_qa.js 中的静态检查。

规范的参考实现位于 assets/reference-build.js — 一个完整、经过渲染测试的 pptxgenjs 示例。打开它以模式匹配幻灯片意图，然后复制代码块。完整的配方库、辅助函数以及常见问题表位于 references/build-helpers.md。

何时触发

主动使用此技能，适用于以下任何情况：

• 策略演示文稿、融资演示文稿、咨询交付物、案例研究回复
• 董事会汇报、领导层简报、路线图演示、转型计划
• 市场进入分析、诊断演示文稿、建议方案、高管摘要
• 用户提及“咨询风格”、“MBB 风格”、“麦肯锡风格”、“贝恩风格”、“BCG”或具体公司名称的任何内容
• 用户希望获得具有品牌水准且文案精炼的 polished 客户演示文稿

工作流程

按顺序执行以下步骤。前后强制性的反“粗制滥造”检查不可协商。

第 0 步 — 强制性反“粗制滥造”预检查

此技能产出的文案必须经得起持怀疑态度的读者审视。在起草任何幻灯片文案、演讲者备注、主题句、上下文行或简报文本之前，请阅读 references/anti-slop.md，以便校准语言，避免那些会暴露文稿为机器编写的 AI 痕迹。

阅读后，在起草文案时保持以下约束：

• 除非能证明其有特定作用（每页最多一个），否则不使用破折号
• 零填充废话词汇（深入、利用、稳健、无缝、变革性、范式、尖端、颠覆者，以及 anti-slop.md 目录中的其他词汇）
• 不使用负面平行结构（“不是 X，而是 Y”；“不仅是 A，而且是 B”）
• 句子不超过 30 个单词；具体名词和特定数字优于抽象概念
• 使用行动标题，而非主题标题（最重要的规则 — 参见 slide_patterns.md）

结构工艺可以完美，但一旦文案读起来像泛泛的咨询式 AI 输出，演示文稿仍会被折扣。此检查旨在阻止这种情况。

第 1 步 — 收集演示文稿简报

在编写任何一张幻灯片或一行 build.js 代码之前，使用 AskUserQuestion 进行两次连续的调用：

调用 1 — 演示文稿设置：

1. 受众 + 目标 — 谁在阅读这份演示文稿，你希望他们做出什么决定或采取什么行动？
2. 演示文稿原型 — 诊断型 / 建议型 / 路线图型 / 市场进入型 / 转型型 / 融资型 / SCQA / SCR / BLUF / 归纳型 / 问题树型 / 演绎型。演示文稿可以是简单型（全程一个原型）或分层型（一个主原型 + 章节级别的覆盖）。如果分层，决定哪个原型运行哪些幻灯片范围，并遵守该决定；不要将其折叠回单一形式。
3. 输出格式 — pptx / html / md / gamma / 简报（多选；默认：pptx）

调用 2 — 品牌 + 视觉简报：

1. 配色方案 — 根据意图询问（仅强调色；亮白底色 + 冷中性色固定）。提供：松木 12564A（默认；冷静、现代、成长）/ 石板蓝 1F3A5F（企业、金融、信任）/ 牛血红 6E1423（正式、权威）/ 客户十六进制色值（品牌锁定工作）。选择设置 ACCENT 并推导出 ACCENT_DK（约 70% 亮度）+ TINT（白底约 8%）+ TINT_BORDER。牛血红的色调略微偏粉 — 如果选择则需将其调暖。经过验证的配色方案值位于 design_system.md §1。
2. 标题字体 — 根据意图询问（正文保持 Manrope；仅改变标题字体）。提供：Charter（编辑衬线体，默认，渲染效果佳）/ Manrope Bold（现代、全无衬线体）/ Palatino（暖调衬线体）/ Baskerville（正式衬线体；在 PowerPoint/Google Slides 中表现最佳，在 LibreOffice 预览中较弱）。选择设置 DISPLAY，并且对于全无衬线体选项设置 DISPLAY_BOLD=true。只要不在过度使用列表中（Inter、Roboto、Fraunces、Geist、Plus Jakarta、Space Grotesk），任何已安装的字体都可以。选择全无衬线体即意味着有意识地接受单一字体族的建议 — 参见 references/anti-slop.md。
3. 品牌 + 内容简报 — 客户/公司名称、演示者、日期，以及粗略的幻灯片内容大纲（即使有项目符号笔记也可以；Claude 会进行结构化）。

架构模板位于 assets/inputs.example.json。幻灯片数量不是必填输入 — 让它根据内容会谈和原型自然确定。高管演示文稿默认 8-12 页，深度分析 15-18 页，综合主演示文稿 26 页以上。

在触及任何构建脚本之前，根据回答编写 inputs.json。将输入与构建脚本分离意味着同一个脚本可以处理未来所有的演示文稿。

第 1.5 步 — 强制性骨架草稿（在任何内容起草之前）

在填写幻灯片正文、面板、数据点、甘特图行或任何文案之前：生成一个 inputs.json 的骨架草稿版本，仅包含：

• title_slide 已填写
• slides[i].breadcrumb、slides[i].title、slides[i].context 已填写（标题必须是行动标题 — 参见 slide_patterns.md 中的通用约定）
• slides[i].layout 已选择（Claude 从按原型筛选的池子中果断选择）
• 所有 slides[i].content 块留空 {} 或仅包含占位字段名称

以表格形式呈现骨架草稿，包含列：# | 章节 / 原型 | 面包屑导航 | 行动标题 | 布局 | 上下文行（一句话） | 主要视觉 / 数据（5 秒测试）。

章节 / 原型 列可使分层结构一目了然。对于简单型演示文稿（全程一个原型），每一行都携带相同的值（例如 — / diagnostic）。对于分层型演示文稿，该列命名幻灯片所属的章节以及该章节运行的原始 — 例如 构建案例 / inductive、序列操作 / roadmap、结尾请求 / bluf。章节边界变得直观可见（相邻行共享一个章节标签；变化标志着打断）。

然后使用 AskUserQuestion 询问以下问题：

1. 叙事弧线在章节之间是否成立？（全部批准 / 修改特定幻灯片 / 重大重组）
2. 是否有任何标题没有陈述“所以呢？”（列出需要修复的幻灯片编号，或“全部没问题”）
3. 是否有任何布局选择对其幻灯片的职能来说感觉不合适 — 包括幻灯片布局与其章节原型冲突？（列出幻灯片编号，或“全部没问题”）
4. 是否有任何上下文行或视觉描述缺少关键细节？（列出幻灯片编号，或“全部没问题”）

在起草任何正文内容之前，等待明确的确认。如果用户要求更改，请更新骨架草稿表格并重新询问 — 在用户表示“全部没问题”或类似话语之前，不要进入第 1.6 步。

为什么存在此步骤：抛弃 10 个幻灯片标题比抛弃 10 张完成的幻灯片快得多。金字塔原理 / SCQA 结构化讨论在廉价版本上进行。跳过此步骤是导致完成的演示文稿必须重建的最常见原因，也是稀疏的英雄幻灯片溜进来取代密集工作模式的地方。

骨架草稿内的模式选择： Claude 从按原型筛选的池子中果断选择布局。仅当两个模式在内容匹配上真正旗鼓相当时，或者用户之前表达了品味偏好时，才使用 AskUserQuestion 来呈现选择。每张幻灯片逐个选择会产生每次演示文稿 10–12 次强制询问，且质量收益不成比例；应避免。

单调性防护（可选选择器）： 当你填写 布局 列时，扫描是否有两张或更多相邻幻灯片会共享相同的视觉习语 — 最常见的是水平条（参见 references/slide_patterns.md → “在相邻幻灯片之间变化条形习语”）。当发现连续重复时，要么自行变化处理方式，要么为重复的幻灯片引发预览选择器：一个 AskUserQuestion，首先显示推荐布局（标记为 (Recommended)），然后提供 2 个渲染安全的替代方案，每个在选项的 preview 字段中携带一个简短的 ASCII 小型布局模拟图，这样用户就能根据图片而不是模式名称进行选择。这仍然是可选的 — 它会在检测到重复、真正平局或用户询问“我有什么选择”时触发，而不是在每张幻灯片上。它是第 4.5 步变化模式的廉价对应实现：在用户做出选择之前，不构建任何内容。

仅当用户已经提供了完整的 inputs.json 或明确写了“跳过骨架草稿”时，才可跳过第 1.5 步。否则不可协商。

第 1.6 步 — 每张幻灯片的创建纪律（5 步骤）

对于每张幻灯片，按此顺序填写架构。不要跳步。

1. 信息 — 首先编写 slides[i].title。它必须是行动标题（“所以呢”）。如果你无法写出标题，说明你还不清楚幻灯片的目的。
2. 结构 — 从支持标题的目录中选择 slides[i].layout。默认使用密集工作模式（diagnostic-three-panel、prioritisation-matrix、phased-roadmap-gantt、three-col-comparison、waterfall-baseline-to-target）。稀疏的调味模式（stat-row、big-numeral-findings）仅用作章节桥梁，切勿作为演示文稿的主体。
3. 图表 / 主要视觉 — 填写 slides[i].content。视觉应在 5 秒内可读。对于矩阵：数据点位于何处？对于甘特图：哪些工作流重叠？对于瀑布图：哪个项目占主导？
4. 支撑 — 填写 slides[i].context（数据处理前的一句话框架）和 slides[i].footer_note（来源 + 注意事项）。两者在数据幻灯片上都不可协商。
5. 打磨 — 由 scripts/check_titles.js + 第 7 步反“粗制滥制”后续检查 + 第 8 步飞行检查交付门处理。在交付前运行。

在信息之前选择布局是导致稀疏英雄幻灯片溜进来的原因。在布局之前选择视觉是导致图表最终不支持其标题的原因。在内容之前进行打磨是浪费的工作。顺序至关重要。

完整参考：references/methodology/slide_creation_process.md。

第 2 步 — 阅读设计系统 + 模式

始终阅读（每次构建），按此顺序：

1. references/design_system.md — 固定的调色板/排版/结构。未经充分理由不得偏离。
2. references/slide_patterns.md — 主模式目录 + 通用约定（行动标题、选择性色彩、图表真实性、条形/列排序、标签直接标注、区域比例圆圈、页脚纪律、瀑布图特定规则）。
3. references/build-helpers.md — 调色板常量、header()/title()/footer() 辅助函数、每个模式配方（§2.x）以及常见问题表。每次构建的实现参考。assets/reference-build.js 是使用了这些的工作示例。
4. references/methodology/content-interview.md — 内容访谈框架（情况 → 问题 → 假设 → 证据 → 论证 → 答案）。在触及任何构建脚本之前运行阶段 1。

按需阅读（仅在触发条件适用时）：

• references/chart-selection-guide.md + references/chart-library/ — 当幻灯片需要图表时。由第 2.5 步驱动；不要预加载。
• references/slide-job-to-layout.md — 在第 1.5 步和第 4.5 步选择布局时使用，以使模式选择可追溯而非直觉化。
• references/raci-guidance.md — 当构建 RACI 或任何职责分配幻灯片时使用。

如果用户提供参考演示文稿或幻灯片进行匹配，挖掘其缩略图以了解布局，挖掘其文本以了解章节结构。将任何外部参考仅视为结构参考：研究其构建方式，切勿复制其文字、数字或图像。

第 2.5 步 — 图表幻灯片：查阅图表库 + 图表选择指南

当幻灯片需要图表时（柱状图、折线图、堆叠图、双面板、组合柱状图/线图、小多组图、瀑布图、梅基图），不要即兴发挥。按顺序参考两个文档：

首先，references/chart-selection-guide.md — 顶部的快速选择表将幻灯片的预期信息映射到图表类型。原则：图表类型适合信息，而非数据形状。应用图表特定的提示（无 3D、直接标注线、条形逻辑顺序等）。

然后，references/chart-library/ 获取渲染后的配方（6 个精炼模式之一）：

1. 每个会话阅读一次 references/chart-library/patterns/00-shared-design-rules.md。

2. 选择最接近的模式：

   数据形状	模式文件
   5–12 个类别按一个指标排名	01-horizontal-bar-with-delta.md
   相同类别显示绝对值和百分比	02-dual-panel-bar.md
   按类别或随时间变化的构成/混合	03-stacked-bar.md
   具有 1–4 条线的连续时间序列	04-line-with-annotations.md
   不同尺度的两个相关指标	05-combined-bar-and-line.md
   3–6 个类别中的相同图表结构	06-small-multiples.md
   基准 → 机制 → 目标	references/build-helpers.md → waterfall-baseline-to-target

3. 在为幻灯片起草 inputs.json 之前，阅读该模式的完整结构。每个文件都包含结构图、设计规则、标题模板和“何时不使用”的护栏。

4. 通过 brand.primary_hex 应用品牌调色板。

5. 来源行不可协商。 每张图表幻灯片必须设置 slides[i].footer_note 并提供真实来源。

版权：图表库目录仅包含模式与约定（参见 chart-library/SOURCES.md）。所有图表均使用用户自己的数据构建；切勿嵌入第三方的图表图像、标题或数字。

第 3 步 — 选择原型骨架

从高效构建的路径开始，遵循原型所规定的叙事结构。编写 scripts/build.js 脚本，该脚本将 inputs.json 作为输入并生成 build/out.pptx。

E

…

[截断以供翻译]