先看证据
把内容判断和页面排版分开
IBM Research 在 Palette 文章中提出两个使用动机：前沿模型生成一份 deck 可以很好看，但连续要十份，成品就容易落回相似的默认审美；而作者希望模型能按用户自己的设计语言工作。敏感内容不一定能送到外部服务，也是文章提出的动机。作者将开放权重、在自有基础设施上运行的模型视为一种可能方向，但没有报告实际部署或数据安全验证。
小模型还有另一类麻烦：它们生成的是绘制幻灯片的代码，而不是直接在画布上排版。模型要预估文字和形状的位置、尺寸，代码渲染后才知道是否溢出或重叠。与此同时，它还得决定每页讲什么、用图表还是表格，以及哪些内容可以删减。Palette 的做法是把这两类工作拆开，而不是让模型在一次生成中同时完成。
先写简报，再逐页写代码
Palette 把一套 deck 的制作分成两个角色，由同一个 LoRA adapter 提供能力。Designer 阅读计划，先生成结构化 JSON brief，写明配色、字体系统、每页布局、确切内容和简短的设计理由。Coder 再根据 brief 中某一页的规格，写出绘制该页的 pptxgenjs JavaScript 代码，并在代码前给出推理。
中间的 brief 可读、可编辑；要改一页的布局，可以直接调整这页的规格，不必重新生成整套 deck。每页上下文也在写代码前就已确定，因此 Coder 可以逐页并行运行。作者称，这让代码生成阶段约快 6–7 倍；这个数字指代码生成阶段，并非整套 deck 的端到端耗时对比。训练时，Coder 样例平均约长 5 倍，团队因此把 Designer 样例过采样 5 倍，避免较短的 Designer 样例训练不足。
合成数据要教会模型为什么这样设计
作者称，公开资料里找不到同时包含演示文稿计划、设计决策和生成代码的语料，因此他们用大型开放教师模型合成了约 1,000 个 deck、约 10,000 张 slide。训练数据遵循 IBM Design Language。每个 deck 从一份配方开始，配方设定类型、长度、布局和用户指令；计划既有规整大纲，也有原始内容堆叠，让模型练习取舍和压缩信息。
样例还包括反事实式推理：不只记录最后选了什么，也说明考虑过什么替代方案、为什么没有采用。例如，若一页要表达四个季度的营收趋势，理由可以是柱状图比表格更容易让趋势一眼可见。Coder 的推理则处理几何问题，例如标题在某个字号下会不会换成三行并挤到图表。教师模型生成的数据并不自动可靠；作者发现，参考 deck 比单加规则更能约束教师模型的输出，模型会更多模仿给出的参考材料。
检查、修复，再由检查器把关
Palette 的检查机制既用于整理训练数据，也用于生成 deck 时的修复。合成的每个 deck 都会渲染，并检查元素重叠和内容溢出；发现问题后，团队修复页面，并把关于原布局哪里错、修复为什么有效的推理一并改写。作者将这些被检查器发现的错误转成更好的训练样例。
运行时，harness 先用简单规则处理已知问题，例如格式错误的颜色代码；随后逐页渲染并测量，几何检查器会标记文字重叠、被裁切或跑出幻灯片边界的情况。被标记的页面交给单独的编辑模型重写代码，但只有检查器确认页面有所改善，修改才会保留；否则沿用原页。用户还可以在计划中用双中括号写简短指令，例如要求把里程碑做成时间线。文章称训练配方覆盖 12 类指令，Designer 会把指令写进 brief，Coder 再据此绘制页面。
基准分数没有回答设计语言是否学会了
作者报告，Palette 在 PresentBench 的 Economics 和 Education 两个领域排第一，在 Talk 排第三；三域平均分为 59.7，低于 NotebookLM 的 60.8，差 1.1 分。作者还称，在 131 个 PresentBench deck 上启用检查修复 harness 后，平均提高 3.5 分。PresentBench 论文介绍的基准包含 238 个评测实例，平均每例有 54.1 个核查项。
这些结果衡量的是 deck 质量，不是 Palette 是否遵循 IBM Design Language，因此不能单独证明模型实现了文章所说的设计目标。现有材料也没有给出逐域具体分数、完整实验配置或统计显著性。另一个待核对之处是：PresentBench 网站当前显示 NotebookLM 总分 62.5，而文章比较的是三域均值 60.8；材料不足以确认两者差异是否完全来自统计范围。基础模型名称、权重是否公开发布，以及跨企业设计系统的测试结果，也都没有在公开资料中说明。