Mck-ppt-design-skill：它把 AI 做 PPT 从凭感觉拉回工程门禁

让 AI 做一套咨询风 PPT，最容易出问题的地方不是它不会写标题。它会写，也会排，看起来还挺像那么回事。真正麻烦的是，等你打开 PowerPoint，才发现图例挤出去了，标题像标签，某个连接线让文件弹修复提示，AI 还很自信地说“已经检查过”。

这类事故很烦，因为它不是一句提示词能彻底解决的。你可以提醒模型“注意留白”“不要溢出”“保持字体一致”，但模型下一次还是可能在另一张图里犯同样的错。PPT 的很多细节，本来就不该交给语言模型凭感觉算。

咨询风 PPT 更放大这个问题。它对版式、数字、图表、标题句、底栏、字体、颜色都很挑剔；一页看起来差一点，整套 deck 就会从“专业汇报”掉到“AI 拼出来的样子”。

Mck-ppt-design-skill 有意思的地方在于，它没有把希望继续压在提示词上，而是把 AI 做 PPT 拆成了引擎、版式能力、内容门禁和渲染后 QA。它真正想解决的不是“多给几个模板”，而是别让 AI 在没有证据的情况下宣布 PPT 已经完成。

这条路线很硬：AI 负责做判断，Python 负责落版，脚本负责判定能不能交付。对 PPT 这种格式来说，这比让模型继续堆坐标更靠谱。

它先把“一句话生成”拆成五段路

仓库里最新的 Harness Engineering 模式，把生成流程拆成 S1 到 S5：先写 brief.md，明确受众、目标、时长和关键信息；再写 outline.json，给每页选 layout 和洞见句；然后写 content.json，填文案、数据和来源；接着渲染 PPTX 并跑 QA；最后才交付。

这个顺序看着啰嗦，其实正好对准了 AI 做 PPT 的软肋。模型最擅长的是一口气往前冲，最不擅长的是在每个阶段停下来承认“这里还不能进入下一步”。MCK 的做法是给它装上刹车。

S3 的 gate_check_s3.py 会在渲染前检查内容格式，比如 four_column、executive_summary、meet_the_team 的元组格式，matrix_2x2 的四象限数量，process_chevron 的步骤数，donut 和 pie 的分段数。它不是让 AI “脑子里过一遍”，而是让 gate_s3.json 说了算。

S4 的 gate_check.py 则在 PPTX 出来后分类 QA 错误。能不能进入交付，不看 AI 的口头解释，而看 gate_result.json 里的 passed。这个小细节很关键：它把“我觉得没有问题”变成了一个可追责的布尔值。

67 个高层方法，是给模型少犯错的扶手

MckEngine 的价值不只是封装了 python-pptx。它把咨询风 PPT 常见页面拆成高层方法：cover、toc、table_insight、matrix_2x2、process_chevron、timeline、donut、dashboard_kpi、risk_matrix、stakeholder_map 等等。AI 不需要逐个算每个矩形的位置，只要选择合适的页面方法，再填入受控的数据结构。

这会改变输出方式。旧路子里，一个圆形图可能被模型用大量 add_rect 堆出来，坐标多、形状多、文件也容易膨胀。MCK 在 v2.0 后把圆形图表转向 BLOCK_ARC 原生形状，donut、pie、gauge 这类图表由引擎确定性生成，模型只负责给出比例、颜色和标签。

这里的判断并不抽象。README 里直接拿 v1.x 和 v2.0 对比：以前 chart-heavy deck 的输出 token 会很大，图表生成慢，文件也容易变重；引擎化之后，模型输出变成更短的函数调用，CPU 做确定性执行。PPT 生成从“写一堆形状”转向“调用稳定方法”。

版式矩阵让内容别再随便塞

很多 PPT 崩坏其实不是版式坏，而是内容超载。四栏页塞五栏，流程箭头放七步，环形图分八段，标题还写成一整句报告摘要，最后谁也救不了。

MCK 把这种经验写进 layout-matrix.yaml：cover 标题多少字，toc 最多几个 item，process_chevron 最多五步，donut 和 pie 最多六段，four_column 最多四列，two_column_text 全局最好只用一张。它不是在限制表达，而是在提醒 AI：PPT 不是 Word，版式有容量。

guard-rails.md 也很实在，讲的都是生产里会痛的细节：底栏和内容至少留间距，内容不能越过页面右边和底边，图例颜色必须用真实色块，内容页标题统一用 action title，水平排列必须动态算宽度，中文文本要设置东亚字体。读到这里能感觉到，这个项目不是只在做“好看”，它在防 PPT 文件和版面一起坏。

经验目录让下一次少踩同一个坑

它还有一个很像真实团队工作的设计：experiences 目录。overflow.md 记录文字溢出，chart-limits.md 记录图表限制，layout-pitfalls.md 记录版式陷阱，cjk-issues.md 记录中文渲染问题。每次修掉一种可复现的问题，就把规则沉淀到对应文件，下次 S3 阶段再读。

这比单次把 PPT 修好更有意义。很多 AI 工作流的问题是每次都像第一次做，同一个错误改了又犯。MCK 把修复经验留在仓库里，让下一次生成时先带着这些经验出发。它没有让记忆停在对话里，而是落成可读、可版本化的文件。

它更像一套严厉的 PPT 生产线

如果只是做一张简单封面，Mck-ppt-design-skill 会显得有点重。五阶段、gate、layout matrix、guard rails、QA 分类，这些东西都不是为了轻量试玩准备的。它面向的是另一种场景：董事会汇报、策略复盘、经营分析、数据图表很多、不能靠肉眼随便放行的 PPT。

它最值得借鉴的地方，是把 AI 从“最终裁判”降回“生产参与者”。AI 可以写 brief，可以选版式，可以填内容，可以调用引擎；但它不能跳过门禁，也不能在没有 gate_result.json 的时候说自己已经通过。对于需要交付给人的 PPT，这个姿态比多给几十个模板更重要。

所以看这个仓库，不要只看它像麦肯锡风格，也不要只数它有多少页面方法。更关键的是，它把 PPT 生成变成一条能被检查、能被回滚、能积累经验的生产线。AI 做 PPT 想走向真正可用，迟早都要经过这样的约束。