Palette：教小模型用你的设计语言制作演示文稿

这两种方案都指向一个由你掌控的模型：开放权重，运行在你自己的基础设施上，并用你自己的设计语言训练。问题在于，那些真正适合自行托管的小型开放模型并不擅长这类任务。它们生成的幻灯片往往一塌糊涂：标题融进背景里，文字溢出幻灯片，图形彼此层层叠压。Both of those point to a model you own: open weights, running on your own infrastructure, trained on your own design language. The catch is that small open models, the kind you'd actually self-host, are bad at this. Their decks come out broken: titles that vanish into the background, text running off the slide, shapes stacked on top of each other.

Palette 押注的是：一个小型开放权重模型，只要使用符合你的设计语言的合成数据进行训练，并通过测试框架检验，就能与前沿系统一较高下，同时让你保有成果的所有权。我们微调了一个 20B 模型，让它像人们实际制作演示文稿那样工作：由设计师规划整套演示文稿，再由程序员绘制每张幻灯片。它的训练数据遵循 IBM 设计语言；在 PresentBench 上，它在我们评测的三个领域中有两个排名第一。这篇文章将介绍我们如何合成数据、训练模型，以及围绕模型搭建测试框架。Palette tests one bet: that a small open-weight model, trained on synthetic data in your design language and checked by a harness, can compete with frontier systems while you keep ownership of the result. We fine-tuned a 20B model to build decks the way people do: a designer plans the deck and a coder draws each slide. Its training data follows the IBM Design Language, and on PresentBench it ranks first on two of the three domains we measured. This post covers how we synthesized the data, trained the model and built a harness around it.

为什么小模型难以处理演示文稿 Why decks are hard for small models

幻灯片看起来很简单，但制作幻灯片需要模型完成三件小模型不擅长的事。A slide deck looks simple, but making one asks a model to do three things small models are bad at.

它在看不到幻灯片的情况下进行排版。模型不会直接绘制幻灯片，而是编写代码，将每个元素放置在指定的 x、y 坐标上，并设置宽度和字号。一个 75 个字符的标题能否以 56pt 字号排成两行，全靠模型在脑中计算；只有代码渲染后，它才会发现自己算错了。小模型经常会算错，这就是形状重叠、文本溢出幻灯片的原因。It lays out the slide without seeing it. The model doesn't draw slides; it writes code that places every element at an x, y, width and font size. Whether a 75-character title fits on two lines at 56pt is arithmetic the model does in its head, and it only finds out it was wrong after the code renders. Small models get this wrong often, which is where overlapping shapes and text running off the slide come from.

它需要同时做出两类决策：确定每张幻灯片要讲什么，以及如何呈现（用图表还是表格？删掉哪些内容？），这属于编辑判断；而精准地安排内容位置，则属于几何问题。它必须在一次处理中完成这两项工作，覆盖 10–20 张幻灯片，同时保持配色、字体和布局的一致性。It makes two kinds of decisions at once. Deciding what each slide says and how to show it (a chart or a table? what to cut?) is editorial judgment. Placing it precisely is geometry. A single pass has to do both across 10–20 slides, while keeping the palette, type and layout consistent.

没有数据展示演示文稿是如何制作出来的。虽然现成的演示文稿很多，但缺少设计决策背后的理由，以及生成它们的代码。There's no data showing how decks get made. Plenty of finished decks exist, but not the rationale behind the design choices or the code that produced them.

像人一样构建：既是设计师，也是编码者 Build it like a human: a designer and a coder

没人会一口气做完整套演示文稿。你会先确定叙事结构（要做多少张幻灯片、每张讲什么、哪些用图表、哪些用表格），然后才开始制作每一张幻灯片。Palette 也以同样的方式拆分工作，分为两种角色，并由同一个 LoRA 适配器来承担：Nobody makes a deck in one pass. You decide the story first (how many slides, what each one says, which gets a chart and which gets a table) and only then build each slide. Palette splits the work the same way, into two roles served by a single LoRA adapter:

• 设计师阅读计划后，撰写一份结构化的 JSON 设计简报，内容包括配色方案、字体系统，以及每张幻灯片的布局、具体内容和简短的设计说明。
  The designer reads the plan and writes a structured JSON brief: the palette, the type system, and for each slide its layout, its exact content and a short design rationale.
• 编码人员根据简报中某一页幻灯片的规格，编写用于绘制该幻灯片的 pptxgenjs JavaScript 代码，并在代码前说明推理过程。
  The coder takes one slide's spec from the brief and writes the pptxgenjs JavaScript that draws it, preceded by its reasoning.

现在每个角色只负责一种决策：设计师负责编辑判断，编码人员负责几何布局。双方之间的设计说明清晰易读、便于编辑，因此无论是人还是智能体，都可以更改单张幻灯片的布局，而不必重新生成整套演示文稿。由于每张幻灯片的上下文都在编写代码前确定，编码任务可以并行运行，每张幻灯片各执行一次，因此编码阶段的速度提升了约 6–7 倍。Each role now makes one kind of decision: the designer handles the editorial judgment, and the coder handles the geometry. The brief between them is readable and editable, so a person or an agent can change one slide's layout without regenerating the deck. And because every slide's context is fixed before any code is written, the coder calls run in parallel, one per slide, which makes the coding stage about 6–7× faster.

我们使用 LoRA 而非全量微调来训练适配器：它能在强大的基础模型之上教会模型一种格式和一项技能，同时不影响基础模型已有的知识，而且让每次实验的成本都很低。一个经验是：编码器示例的长度约为设计师示例的 5 倍，因此简单混合会导致设计师示例训练不足，直到我们将其过采样 5 倍。We trained the adapter with LoRA rather than full fine-tuning: it teaches a format and a skill on top of a capable base without disturbing what the base already knows, and it made each experiment cheap. One lesson: coder examples are about 5× longer than designer examples, so a naive mix undertrained the designer until we oversampled its examples 5×.

生成牌组及其推理过程 Synthesizing decks and their reasoning

目前没有公开的计划、设计决策和幻灯片代码语料库，因此我们用一个大型开源教师模型生成了一个。每套幻灯片都从一份设定其类型、长度、版式和任何用户指令的配方开始，因此我们可以控制数据覆盖的内容。计划从整齐的大纲到原始内容堆砌不等，让模型学会删减和精简。我们生成了约 1000 套幻灯片，涵盖大约 10,000 张幻灯片。There's no public corpus of plans, design decisions and slide code, so we generated one with a large open teacher. Each deck starts from a recipe that sets its genre, length, layouts and any user directives, so we control what the data covers. Plans range from tidy outlines to raw content dumps, so the model learns to cut and condense. We generated around 1000 decks covering roughly 10,000 slides.

每个示例还包含其背后的推理，并以反事实的形式呈现：推理过程会权衡另一种选择，并说明为何将其排除，从而让模型学会选择背后的规则，而不只是学会这个选择。设计者会同时考虑内容和形式。例如：Every example also carries the reasoning behind it, written as a counterfactual: the trace weighs an alternative and says why it was rejected, so the model learns the rule behind a choice, not just the choice. The designer reasons about content and form. For example:

连续四个季度的收入呈现出明显的上升趋势。我考虑过用表格，但这张幻灯片的重点是趋势，而非具体数字，因此柱状图能让人一眼看出这一点。

"Revenue for four quarters, with one clear upward trend. I considered a table, but the point of this slide is the trend, not the exact figures, so a bar chart makes it visible at a glance."

编码器会推理几何问题：The coder reasons about geometry:

标题共 62 个字符。使用 44 磅字号时会换成三行，并与下方图表挤在一起，因此我将字号设为 36 磅，这样可以排成两行，并在图表上方留出空间。

"The title is 62 characters. At 44pt it would wrap to three lines and run into the chart below, so I set it at 36pt, which fits on two lines and leaves room above the chart."

仅靠教师模型并不能保证数据质量，真正起作用的是围绕它构建的闭环。每份合成演示文稿都会经过渲染，并由与测试框架在推理阶段使用的同一检查器检查是否存在重叠和溢出。出错的幻灯片会得到修复，其推理过程也会改写成同类反事实说明，涵盖原始布局哪里出了问题，以及修复为何有效。检查器发现的每个错误，都会成为更好的训练样例。The teacher alone doesn't make the data good; the loop around it does. Every synthesized deck is rendered and checked for overlaps and overflow by the same checker the harness uses at inference. Broken slides are repaired, and their reasoning is rewritten as the same kind of counterfactual, covering what the original layout got wrong and why the fix works. Each mistake the checker catches becomes a better training example.

最难解决的问题是忠实度。最糟糕的失败，是幻灯片上出现了输入中没有的事实；我们发现，提示词规则无法阻止这种情况。如果简报要求制作一个六行五列的表格，却只提供了三个要点，编写者就不得不编造其余内容。The hardest problem was faithfulness. The worst failure is a slide with facts that weren't in the input, and we found that a prompt rule can't prevent it. If a brief asks for a six-by-five table but carries only three bullets, the coder has to invent the rest.

真正起作用的是参考演示文稿，而不是规则：修正一份参考演示文稿，就能可靠地改变教师的输出；添加一条规则却很少奏效。教师会在提示中看到几份参考演示文稿，而且它更倾向于照搬它们，而不是遵循指令。What fixed it was reference decks, not the rules: fixing a reference reliably changed the teacher's output, while adding a rule rarely did. The teacher sees a few reference decks in its prompt and copies them far more than it follows instructions.

用通俗英语引导一副牌 Steering a deck in plain English

用户通常希望对特定设计选择进行更精细的控制：用图表代替表格、指定某种颜色，或采用更深色的封面。Palette 支持他们通过指令来提出这些要求。指令是直接写在计划中的简短说明，并用 [[ ]] 括起来：Users often want finer-grained control over specific design choices: a chart instead of a table, a particular color, a darker cover. Palette lets them ask for these with directives, short instructions written directly in the plan and wrapped in [[ ]]:

## Rollout plan
- March: pilot with two teams
- May: security review complete
- July: rollout to all of engineering
- September: company-wide launch
- November: first adoption review
[[make this a timeline]]

设计师将每条指令都写入设计简报，编码者绘制幻灯片时会遵循这些指令。没有这条指令，模型很可能会用表格展示这些里程碑；有了它，模型则会改用时间线。The designer builds each directive into the brief, and the coder follows it when drawing the slide. Without the directive, the model would reasonably show these milestones as a table; with it, the model draws a timeline instead.

模型会遵循指令，因为它经过了相关训练。数据配方中包含来自 12 个类别的指令，下面展示了其中几个类别的指令，每条指令都采用了几种不同的表述方式，让模型学会理解其意图，而不是记住某个固定说法。The model follows directives because it was trained to. The data recipes include directives from 12 categories, a few of which are shown below, each phrased several different ways, so the model learns the intent rather than a fixed phrase.

Figure 1. An illustration of the same plan without (left) and with (right) the [[make this a timeline]] directive.

构建检查与修复框架 Building a check-and-repair harness

即使是经过充分训练的模型，有时也会生成有问题的幻灯片：标题和背景颜色相同，或者两个文本框叠在一起。因此，Palette 不会直接返回模型的输出；每套幻灯片都要先经过一个测试框架。Even a well-trained model sometimes produces a broken slide: a title in the same color as the background, or two boxes stacked on top of each other. So Palette doesn't return the model's output directly; every deck goes through a harness first.

Figure 2. The designer drafts the brief, the coder writes each slide's code in parallel, and the harness checks and repairs every slide before the deck is returned.

首先，简单的规则会修正已知错误，例如格式错误的颜色代码，否则它会让所有幻灯片都变成黑色。然后，系统会渲染并测量每张幻灯片：几何检查器会标记文本重叠、被裁切或超出幻灯片边界的情况。被标记的幻灯片会交由单独的编辑模型，由它重写该幻灯片的代码。First, simple rules fix known mistakes, such as a malformed color code that would otherwise turn every slide black. Then each slide is rendered and measured: a geometry checker flags text that overlaps, gets clipped or runs off the slide. Flagged slides go to a separate editor model, which rewrites that slide's code.

关键规则是，只有检查器确认幻灯片有所改进时，才会保留改写；否则就保留原稿。因此，这套测试框架可以安全地用于每一套幻灯片。它可以修复幻灯片，但不会让幻灯片变得更糟。The key rule is that a rewrite is kept only if the checker confirms the slide improved; otherwise the original stays. That makes the harness safe to run on every deck. It can fix a slide, but it can't make one worse.

Figure 3. An illustration of a repair. As generated (left), each card's title is stacked on top of its description; the harness detects the overlaps and reflows the cards into a 2×2 grid (right).

为了衡量其效果，我们将每套 PresentBench 演示文稿各生成一次，并分别在使用和不使用测试框架的情况下进行评分。在 131 套演示文稿中，测试框架平均提升了 3.5 分。To measure its effect, we generated each PresentBench deck once and scored it with and without the harness. Across 131 decks, the harness adds 3.5 points on average.

评估 Evaluation

我们在 PresentBench 上进行评估，该基准从五个方面为生成的演示文稿评分：基础要素、视觉设计、完整性、正确性和忠实度。PresentBench 提供的是源文档，而非计划，因此在这些测试中，我们使用一个独立的前沿模型，根据每份文档起草计划，再由 Palette 根据计划制作演示文稿。我们报告了三个领域的结果；基线数据来自 PresentBench 论文。We evaluate on PresentBench, which scores generated decks on five criteria: fundamentals, visual design, completeness, correctness and fidelity. PresentBench provides a source document rather than a plan, so for these runs a separate frontier model drafted each plan from its document, and Palette built the deck from that plan. We report three domains; baseline numbers are from the PresentBench paper.

Figure 4. PresentBench scores by domain. Palette (blue) against NotebookLM, Manus 1.6 and five other systems (gray). Palette ranks first on Economics and Education, third on Talk, and second on the three-domain mean.

Palette 在结构化内容和数值准确性决定得分的领域表现最佳，在 Economics 和 Education 上均排名第一。在 Talk 领域，演示文稿更偏叙事、以演讲为主，两款闭源系统得分更高，Palette 排名第三。在这三个领域的综合表现中，Palette 排名第二，落后 NotebookLM 1.1 分（59.7 对 60.8），领先于其他所有系统；而 Palette 仅是一个 20B 开放权重模型。Palette does best where structured content and numeric accuracy decide the score, ranking first on Economics and Education. On Talk, where decks are narrative and speech-driven, two closed systems score higher and Palette places third. Across the three domains it places second, 1.1 points behind NotebookLM (59.7 vs 60.8) and ahead of the rest of the field, as a single 20B open-weight model.

PresentBench 衡量的是一套演示文稿是否出色，而不是它是否遵循某种特定的设计语言。据我们所知，目前还没有这样的基准测试，这是我们希望弥补的空白。PresentBench measures whether a deck is good, but not whether it follows a specific design language. We're not aware of a benchmark that does, and it's a gap we hope to help close.

接下来是什么 What's next

测试框架已经能计算一些成本低且可验证的信号：幻灯片能否正常渲染、是否存在重叠或溢出，以及每条事实能否追溯到项目简报。如今，我们用这些信号在生成后修复输出。接下来，我们希望将同样的检查用作强化学习的奖励，让模型从一开始就不再犯这些错误。由于代码生成器一次处理一张幻灯片，每张幻灯片都是一次简短且可独立检查的 rollout，非常适合采用 GRPO 风格的训练。The harness already computes cheap, verifiable signals: does the slide render, does anything overlap or overflow, does every fact trace back to the brief. Today we use them to repair output after generation. Next, we want to use the same checks as rewards for reinforcement learning, so the model stops making these mistakes in the first place. Because the coder works one slide at a time, each slide is a short, independently checkable rollout, a natural fit for GRPO-style training.

我们还希望通过从源文档中提取图表（例如使用 Docling），并借助 harness 将其放置到演示文稿中，来弥补我们在图表密集型演示文稿方面的不足。此外，我们正在探索一种更轻量的方式，让你使用自己的模板：无需重新训练，只需对一个或两个现有的 .pptx 文件进行重新换肤。We also want to close the gap on figure-heavy decks by extracting figures from source documents (e.g. with Docling) and placing them with the harness. And we're exploring a lighter way to bring your own templates: re-skinning output from one or two of your existing .pptx files, without retraining.

我们的收获 What we learned

Building Palette 让我们学到了一些有效的方法，这些方法也能自然地应用于其他输出结构可用代码检查的任务，从图表和示意图到 UI 布局：Building Palette taught us a few effective methods that extend naturally to other tasks whose output has a structure you can check in code, from charts and diagrams to UI layouts:

1. 将推理过程融入数据。训练模型理解做出某个选择的原因，包括哪些选项被舍弃，能教会它比单纯提供选择更多的东西。
   Put the reasoning in the data. Training on why a choice was made, including what was rejected, teaches more than the choice alone.
2. 先修正示例，再添加规则。教师出错时，我们的第一反应是往它的提示词里加一条规则，但这很少奏效。相比遵循指令，它更倾向于照搬参考牌组，所以真正能改变它输出的，是修正参考内容。
   Fix the examples before adding a rule. When the teacher got something wrong, our first instinct was to add a rule to its prompt, and that rarely helped. The teacher copied its reference decks far more than it followed instructions, so fixing the reference was what actually changed its output.
3. 默认情况下确保修复安全。只有在确实带来可衡量的改善时才保留的修复，可以应用于每项输出。
   Make repairs safe by default. A fix that's kept only when it measurably helps can run on every output.
4. 先构建检查器。它能确保数据可信，让输出可以安全交付。
   Build the checker first. It's what makes the data trustworthy and the outputs safe to ship.