IBM Palette 带来的产品问题：AI 销售演示稿何时才能发给客户？
Palette 让品牌化演示稿生成值得关注。小团队应如何核验事实、品牌适配、自动修复，以及客户真正打开的文件？
一份 AI 生成的销售演示稿可以很漂亮，却向客户承诺了错误的产品。试点变成正式上线日期，空白数据变成亮眼成绩，一次排版修复又把原本重要的限制藏了起来。
11 月 3 日，IBM Research 公开介绍了 Palette：一种面向特定设计语言的演示稿生成方法。对正在开发 AI 文档功能的创业者来说，这件事提出了一个很现实的问题：从生成文件到允许用户发给客户，中间还缺哪些判断？
值得围绕它定义的产品边界，是可交付给客户的文件。事实、品牌选择、可读性、交付格式，都属于这份承诺。生成成功只是其中一个条件。本文会用一个虚构销售场景、一张可复用检查表，以及与现有流程对照的方法，帮助非技术创始人和小型产品团队评估演示稿功能，不讨论如何训练模型。
我们没有运行 Palette、复现其评测，也没有测试客户部署。下文涉及的研究结果均归属于原作者；案例和检查建议是本文提出的评估方法，不能据此认为某个具体系统已经通过验证。
1. Palette 带来了什么，哪些问题还没被证明
根据 IBM 11 月 3 日的介绍，Palette 使用经过适配的 20B 模型来生成符合 IBM 设计语言的演示稿。规划角色先给出结构化方案，编码角色再逐页制作。外围检查系统负责渲染、发现版面问题，并有条件地保留修复结果。
IBM 报告的 PresentBench 三领域平均分为 59.7，低于 NotebookLM 的 60.8。原文同时承认，这个基准没有评估对特定设计语言的遵从程度；通过一两份客户文件适配现有模板，仍属于后续探索。这些是发布方的研究结果，不能证明另一家创业公司的模板已经可用。
因此，创始人今天可以调整向原型提出的要求：除了成品，还要看中间的内容与设计方案，以及它和交付文件之间的对应关系。单张惊艳样例无法说明系统是否保留了产品限制，也无法说明它是否适应客户模板。
先把几个术语说清楚。本文所说的 brief，是绘制幻灯片前确定的内容和视觉方案；harness，是负责运行检查、管理修订的外围软件。品牌一致性指符合事先约定的设计规范，而不是主观觉得“挺专业”；内容忠实度指保留来源的含义与限定条件。这两项可以各自失败，不能混为一个分数。
拥有模型也意味着承担运维。把模型所有权当作采购优势之前，要问清楚谁维护部署、谁处理导出失败、谁批准数据处理方式，以及谁更新检查流程。本文不保证 Palette 的实际获取方式、许可证、硬件需求或总成本；这些都需要在试点前另行确认。现有材料足以支持调查这条工作流，却不足以让团队直接承诺无人值守地制作客户演示稿。
2. 从基准中提取问题，不要直接提取采购结论
PresentBench 论文提交于 2026 年 3 月，介绍了 238 个评估任务，每项任务平均配有 54.1 个由人工设计、以是非问题表达的检查项。它的启发在于：演示稿质量可以拆成与具体任务有关的问题，而不是用一个通用的“美观分”概括。做产品评估时，也应先写任务要求，再比较输出。续约演示稿要有正确的合同周期和清楚的续约请求；产品演示要区分已经上线的功能与概念；入门培训要让新用户照着步骤操作。一个笼统的“好不好看”，回答不了这些问题。
官方评测代码库以 PDF 形式接收生成的幻灯片，并围绕来源材料和任务指令组织评估。针对 PDF 的评测本身，不能证明可编辑的 PowerPoint 在客户环境中保留了文字、形状或预期行为。基准成绩可以帮助挑选值得进一步检查的任务，最终仍要测试你实际出售的交付物。也不要把平均分理解成客户验收概率。评分规则上的得分，并不等于你的客户群体中有多大比例会接受成品。少数领域的结果和真实业务的全部输入也不是一回事。记录哪些任务与公开评测接近，哪些没有被覆盖。
采购时可以提出一个具体问题：“我们有哪些必需检查，是这项评测可能漏掉的？”请供应方展示一次失败、系统如何发现，以及用户最终看到什么。导出失败后明确停留在待处理状态，通常比一个干净预览引导用户发送错误材料更容易处理。你选择的是一套包含失败处理方式的流程，不能只看榜单数字。
3. 把品牌要求改写成能核验的选择
“按我们的品牌来做”并不清楚。它可能指封面相似、使用指定字体、遵守网格，也可能指叙述语气。如果创始人和设计师对要求都没有共识，模型无法替他们可靠地解决分歧。
IBM 自己的设计文档展示了设计语言可以具体到什么程度：色彩规范说明配色与视觉层级的关系，2x Grid说明如何组织空间，字体规范则规定系统中的字体选择。这里借鉴的是“把选择写清楚”的做法，并不是建议把 IBM 的品牌视觉搬进自己的产品。
试点时，请设计师准备一个已经认可的小型参考包：封面、信息密集页、图表页，以及结尾提出请求的页面。同时写清哪些地方允许变化。强调色也许可以换，但路线图上的状态标签必须保留；版式可以紧凑一些，来源署名却不能消失。
审查时分别标记可接受变化、品牌不符和内容错误。不同间距可能可以接受，未经许可的合作伙伴 Logo 涉及品牌与使用权限，没有来源的客户成绩则是内容问题。不能用视觉一致性的高分去抵消事实错误。
中文或其他目标语言的演示稿，还需要单独说明例外。英文样张用过某种字体，不代表中文就能正确渲染。要确定可接受的备用字体，并在交付环境里看实际换行。不要为了塞进原版式不断缩小字号。如果内容确实需要多一页，就把它视为一次编辑决定，重新检查顺序和上下文。
比较不同输出期间，应固定参考包。否则品牌要求一边变，结果一边变，团队很难判断差异究竟来自生成系统，还是来自被改过的任务。
4. 一个虚构案例：看似完成的销售稿，实际承诺错了
假设有一家虚构创业公司 Harbor，正在为服务业开发 AI 咨询受理助手。团队想给潜在客户做一份简短演示。输入说明写得很清楚：助手准备回复草稿，员工审核后才能使用，日历连接属于计划功能。客户则问，它能不能自动修改预约。
材料里没有经过验证的响应时间成绩，没有客户 Logo 的使用许可，也没有日历功能确定的交付日期。这些空缺本身就是任务的一部分。好的演示稿可以解释当前流程、列出待确认问题，不必把空缺补成看似可信的成果。
设想第一版输出的标题是“自动处理每一次预约”，路线图把日历连接安排在本季度，另有一页画出了没有来源的改善曲线。文字都放得下，配色也统一。几何检查器完全可能找不到重叠，却漏掉了核心问题：Harbor 正在承诺另一种产品。
审查者应当对照输入核验主张，而不是判断它们听起来像不像真的。把标题改成“准备回复草稿并交由员工审核”的准确描述；把日历连接放进明确标注的计划讨论中，不补上不存在的日期；删除效果图表，改用不包含未测成绩的流程示意。
再设想第二版。主张已经准确，但一次修复把“需要员工审核”移到了很小的页脚。字还在，客户只看标题和主要流程图，却仍可能误会由谁执行操作。检查必须覆盖上下文中的含义，包括限制是否醒目，而不只是搜索某几个词有没有保留。
第三版保留了重要限制，也没有突破来源边界。它可以进入交付审查，但还不能证明客户理解了。请一位不熟悉 Harbor 的人复述：产品现在能做什么、哪些操作需要审核、哪些还在计划中。先记录答案，再解释。这里给出的是一种测试建议，并不是我们已经做过用户研究。
5. 用一张检查表，把证据和责任人对齐
可以直接把下面的表格复制到产品评审中。每行都需要指定责任人，并保留与本次文件版本对应的证据。“尚未检查”仍然属于未解决事项。如果某项确实不适用，应注明它为什么不在产品承诺范围内，而不是默认为通过。
| 审查问题 | 需要保留的证据 | 谁负责解决 |
|---|---|---|
| 希望客户作出什么决定？ | 已批准的演示目的与结尾请求 | 创始人或销售负责人 |
| 每项产品主张都有来源吗？ | 主张、来源及限定条件的对应记录 | 产品负责人 |
| 未知项是否仍明确显示为未知？ | 缺失数据与计划功能审查记录 | 产品负责人 |
| 图表是否忠实于所提供的数据？ | 数值、单位、标签与来源版本 | 数据负责人 |
| 是否符合约定的品牌规范？ | 参考包及标注过的差异 | 设计师 |
| 重要限制是否容易被读者看到？ | 按实际显示尺寸检查标题与图示 | 内容审查者 |
| 目标接收者能阅读并浏览内容吗？ | 无障碍检查及尚未解决的问题 | 无障碍审查者 |
| 下载文件是否与预览一致？ | 在目标软件中打开导出文件的检查记录 | 交付检查者 |
| 修复是否改动了主张或限定条件？ | 修改前后的内容与渲染对照 | 产品负责人 |
| 谁批准把这个版本发出去？ | 最终文件、发送对象与批准记录 | 客户负责人 |
这是一张本文提出的工作表，不是经过验证的评分系统，也不是对 Palette 现有控制能力的描述。小团队可以由同一个人兼任多个角色，但不能让一个自动排版分数代替这个人对事实的确认。
对 Harbor 来说，没有来源的效果图表应当阻断交付，即使其余各项都通过。一个尚未统一的间距偏好，可能只需要轻微修订，不涉及重新判断产品主张。分开处理这些问题，可以避免团队花一个小时挑封面，却漏掉错误承诺。
检查范围也应与功能承诺相称。内部提纲工具不必保证成品能直接发给客户。但如果界面里有“发送给客户”按钮，最终授权就已经成为你出售的流程的一部分。按钮应对应到一个具体、已批准的文件。之后只要文件或已批准的来源材料发生变化，就应重新审查；仅仅把批准记录挂在一段对话上，很容易误用。
6. 自动修复之前，先定义什么才算变好
修复系统首先需要回答：“按照哪项检查，结果变好了？”版面指标改善时，含义、可读性或可编辑性可能反而变差。因此，产品只能把重叠减少视为排版方面的证据，其他检查仍应各自生效。
假设 Harbor 的功能对比页文字重叠。把“仅生成草稿，须经员工审核”缩写成“自动回复”，可以消除重叠；把所有标签缩得难以阅读，也可以消除重叠。但这两种修复都不符合任务要求。增加空间并保留限定条件是第三种选择，仍需在导出的文件中查看效果。
列出修复过程不能静默更改的内容：产品状态、日期、价格、数量、单位、引用、限制，以及希望客户采取的行动。请实施方解释，一旦这些字段被改动，如何提示人工批准。这是产品需求，不是在宣称逐字比较就能证明语义没有变化。
还要看跨页矛盾。一页准确写着员工审核草稿，最后一页却承诺无人值守运行。单独检查每一页，无法判断整份稿件到底向客户承诺了什么。内容负责人需要按演示顺序阅读，并结合最后提出的请求来审查。
修复次数也要有边界。达到允许的尝试次数后，用户应得到带有明确问题提示的可用草稿、手动修改入口，或者清楚的失败状态。这个边界应根据延迟预算和支持能力确定，本文没有证据支持某个通用次数。保留原始版本，避免一次被拒绝的修改破坏原本有用的工作。
评估时，应保留修改前后对照，包括没有被采用的修复。只展示成功案例的图库，无法告诉团队回归问题出现得多频繁、后果多严重。可以按后果分类：外观不便、信息难以阅读、错误主张、交付失败。这样创始人才能决定哪些问题可暂留在有限试点中，哪些必须停止对外使用。
7. 检查客户真正会打开的那份文件
预览只是某一种渲染路径的结果。客户可能下载 PowerPoint，用另一款软件打开，改一个数字，再转发 PDF。产品应先确定支持哪些路径，再逐一检查。
PptxGenJS 的保存文档介绍了文件生成及多种输出方式。相关操作完成，意味着文件已经生成，不能据此判断接收者能否按预期使用。原型里应把“导出完成”和“交付检查通过”分成两个状态。对 Harbor，交付检查者需要在双方约定的软件里打开导出文件，重新确认预览中审过的限制、路线图标签和图表来源。再做一次普通编辑，例如更换客户名称，查看页面是否仍表达相同承诺。如果只支持 PDF，就直接说明，不要暗示文件具备完整可编辑能力。
无障碍也属于交付检查。微软的 PowerPoint 指南涉及阅读顺序、替代文本、对比度、清楚的链接说明，以及不只依赖颜色传达含义。一张渲染图片不能证明底层对象的阅读顺序合理。需要使用相应软件的检查工具，并根据目标用户的需求查看结果；自动检查通过也不等于获得全面的无障碍认证。
小团队应记录实际测试的软件环境和支持格式。没有测过的环境仍是未知。如果模板所需字体不可用，记录替代字体，查看换行是否变化、限定条件是否被挤掉。如果稿件中有链接，应在交付文件里确认目标地址，而不是假设导出后仍然正确。
保留经过审查的文件本身。之后重新生成“同一份”演示稿，得到的可能已经是另一个文件。批准一张截图，不能授权同一提示词未来生成的所有导出结果。
8. 比较整条流程的审查成本
商业上真正要回答的是：这个功能是否减少了为客户做出可接受演示稿的工作？计时应从输入批准后开始，到交付物批准时结束。只算生成时间，会漏掉资料整理、事实纠错、导出失败和被放弃的尝试。
选择一小组有代表性的任务，并在改进流程时留出部分任务，不用于调整。可以包括普通业务更新、刻意保留未知项的稀疏输入、信息密集的图表页，以及目标语言任务。这些是建议的覆盖类别，并不代表样本量足以支持统计结论。使用有权使用的真实材料，或者明确标注的合成材料。
用同一份已批准来源，对照团队原有的模板流程。分别记录准备材料、等待生成、核对事实、修改设计、检查交付和返工所花的时间。尝试生成的演示稿数与最终批准数要分开。如果系统很快生成大量不合格文件，却只对成功导出的文件计算平均时间，就会把失败成本藏起来。
两个实用指标是：总人工投入分钟数除以批准交付物数量，以及总流程支出除以批准交付物数量。要写清支出包含什么。自主管理的系统应计入实际发生的运维，不能把一次模型调用当作整项服务。总交付耗时也要单独记录：一个流程可能省人力，却仍赶不上客户会议。
报告平均值时，同时展示失败类别。根据用途，一次没有依据的主张，可能比多次排版修改更重要。不要把它们合成一个令人放心的数字后就丢掉原始案例。说明每次批准之前需要多少人工介入。
条件允许时，让审查者先看文件，再讨论是哪套系统生成的。对某个模型的熟悉或期待，可能影响观感。之后再收集流程反馈：能否找到主张来源，能否只改一页而保留其余内容，导出失败后能否恢复？这些观察，才把模型演示连接到团队真正能支持的产品。
9. 先上线一项有证据支撑的承诺
第一版有用的功能，可能只是生成可审阅方案与可编辑候选页面的起草助手。即使暂时不能无人值守交付，它也能服务小团队。界面应明确显示状态，并让负责客户关系的人参与批准。
只有证据覆盖新增承诺时，才扩大范围。支持另一个品牌，需要新的参考包和审查；支持另一种语言，需要实际内容与渲染检查；提供自动发送，需要可靠地把批准版本对应到交付文件。这些能力都不会因为一个基准分数而自动成立。
也有不适合这条工作流的场景。一次性的主题演讲可能高度依赖叙事判断，维护自动化流水线未必划算。来源材料还没批准的团队，应先统一自己的产品主张。包含敏感客户材料的演示稿，需要覆盖预览、导出、存储和支持环节的数据处理安排；仅知道模型运行在哪里，回答不了整个服务的数据问题。
做第一次产品决策时，请团队带来三份具体材料：已批准的输入与品牌参考包、附有完整审查记录的候选演示稿，以及最终会到达接收者手里的文件。先讨论尚未解决的检查项，再决定添加什么生成功能。如果团队拿不出文件，或者解释不清某项限定条件，就先把范围收回到内部起草。
Palette 引出的机会值得研究，因为演示稿是有实际业务用途、结构也可检查的产物。创始人的任务，是把这个机会变成能够兑现的客户承诺。Harbor 可以先帮助团队准备准确、可审阅的客户沟通材料，再考虑进一步自动化沟通流程。