📍 文 / 老Z
今天 HuggingFace rank 2 这篇，来自北邮、清华和上交的合作，14 upvotes。我是因为题目点进来的：personalized slide generation with multi-turn local revision。第一反应是：这不是所有 AI 工具都应该做的事吗？结果发现，大家真的没做。
问题是什么
用 AI 生成 PPT，你可能用过 Gamma 或者 DeepPresenter 之类的工具。体验上有个共同的问题：你告诉它"学术风格，深蓝配色，每页图多文少"，它做出来第一次还行。下次你开一个新的任务，它又忘了。你得重新说一遍。
这不是小毛病。每次都要从零建立偏好描述，说完还不一定对——你说"学术风"，它理解的可能跟你想要的差一截。而且，在一次编辑过程中，你对第3页说了"把这个列表改成表格"，让它去改第5页的时候，它把第3页又改回去了。
更根本的问题是：现有的 PPT 生成系统，改一个地方常常要重新生成整个 deck。改个颜色，全页重排。这一方面慢，另一方面把你之前调好的内容又打乱了。
MemSlides 想解决的就是这些。
之前的方法为什么不行
DeepPresenter 和 SlideTailor 这些系统，在 PPT 生成质量上已经做得不错，但个性化基本上是靠当下的 prompt 条件控制的——你在本次任务里说了什么，它就用什么。任务之间没有记忆，本次任务的多轮修改之间也没有稳定的状态。
有人会说，把偏好写进系统 prompt 不就行了？问题是静态系统 prompt 无法动态更新：你在第3次修改里说了"以后这类幻灯片不要用表格"，这条约束得在第4次、第5次修改里还活着，而且要能跟新的指令协调而不是覆盖一切。
Agent 记忆的相关工作很多，但大多关注的是检索、反思、长期知识积累，没有认真处理这种场景——用户对同一任务的偏好要跨会话传递，同时本次会话内的临时约束不能混进长期偏好。
这两种信息的生命周期完全不同，混在一个池子里管理是很容易出问题的。
这篇论文做了什么
MemSlides 的核心设计是三种记忆的分工。
图：MemSlides 框架总览。左侧是长期记忆（用户画像记忆 + 工具记忆），右侧是 Agent 循环（Plan-Act-Guard），中间是工作记忆，负责在任务内的多轮修改中传递状态。
用户画像记忆（User Profile Memory） — 跨任务的稳定偏好。
这层记忆按 intent（学术、商务、创意等）分桶，每个桶里存用户在主题、内容、视觉风格、布局、模板等维度上的偏好。每次任务开始时，系统根据当前 intent 取出对应的画像子集，跟本次的请求进行协调——显式冲突的偏好被覆盖，兼容的偏好作为激活状态注入工作记忆。
任务结束时，系统做一次巩固（consolidation）：只有在多轮交互中反复出现的、稳定的偏好信号才会被写回长期记忆。一次性的"今天我想换个风格"不会污染画像。这个设计解决了我之前见过很多记忆系统都没处理好的问题：临时请求和长期偏好混在一起，会把画像越积越乱。
图：用户画像记忆的生命周期。任务开始时，intent-matched 的偏好被路由进工作记忆；任务结束时，稳定的交互信号被巩固回长期记忆。一次性的请求不会被写回。
工作记忆（Working Memory） — 会话内的临时状态。
工作记忆存的是这次任务里的活跃约束：你在第2轮说的"不要超过5行"，你在第4轮说的"这页不动"，以及当前编辑状态的快照信息。工作记忆让后续的每次修改都能感知到之前几轮留下的约束，而不是每轮都重新从零开始。
工具记忆（Tool Memory） — 可复用的执行经验。
这层记忆解决"如何做"的问题，存的是 agent 在执行编辑操作时积累的经验：哪些 tool call 序列有效、哪些模式容易出错、每个操作场景下好的执行路径是什么。任务内的经验在任务结束时被提炼进长期工具记忆，下次遇到类似的编辑请求时检索出来用。
三层记忆对应三种不同的信息生命周期：跨任务 / 会话内 / 操作级，分开管理，互不污染。
局部编辑执行（Localized Modify Execution）：
除了记忆设计，MemSlides 还做了另一件事：把"改一点"真的变成"只改那一点"。
图：MemSlides 的 Plan-Act-Guard 局部编辑流程。Plan 生成执行合约（scope、target、coverage requirement），Act 执行最小有效编辑，Guard 验证覆盖范围后才允许本轮结束。
系统把每次修改请求转化成一个"执行合约"：scope 是 local 还是 global，target 是哪几页哪些元素，coverage requirement 是什么。执行器根据合约选择编辑工具：批量 CSS 更新、语义批次样式修改、快照式局部 patch 或页面插入/删除。Guard 环节在修改完成后验证覆盖是否达标，覆盖不足就重试，而不是让 agent 自行决定是否完成。
整个流程的出发点是：系统不应该因为"改第3页的标题颜色"而动到第4页。大部分现有工具都没有这个约束，结果是小改动带来意外改动，用户得花时间检查其他地方有没有被搞坏。
有趣的实验
MemSlides 的评估分两块：个性化对齐（personalization alignment）和局部编辑可靠性。
个性化对齐用的是一个多画像、多 intent 的 profile bank，每个画像有明确的内容偏好和风格要求，用 LLM-as-judge 在四个维度（内容、结构、视觉、特异性）评分。
表：在三种模型（GPT-5、GLM-5、Gemini 3.1 Pro）上，MemSlides vs DeepPresenter vs SlideTailor 的个性化对齐分数（0-10）。MemSlides 在 GLM-5 和 Gemini 上全维度领先，GPT-5 上也在 Content 和 Specificity 胜出。
MemSlides 在 GLM-5 和 Gemini 3.1 Pro 上实现了全维度领先；GPT-5 上也在内容和特异性上高出竞争对手。值得注意的是 Specificity（特异性）这一维，这个维度专门用 distractor persona 设计来检验模型有没有真正区分不同用户——如果只是模板选得好而没有真正记住用户画像，Specificity 不会高。
工具记忆的消融实验更直接：
表：有/无工具记忆时的局部编辑指标对比。工具记忆让 Closed-Loop Completion 从 0.815 提升到 0.963，首次正确编辑时间从 609.5 秒降到 242.5 秒，Core Tool Time Ratio 降到 0.327x。
有工具记忆时，Closed-Loop Completion（闭环完成率）从 0.815 提升到 0.963，Strict Verify（严格验证通过率）从 0.310 到 0.534，首次正确编辑的时间从 609.5 秒压到 242.5 秒。这几个数字在说同一件事：记住之前用过什么工具、怎么用的，后续执行效率明显更高，出错更少。
我觉得最有意思的是局部编辑的质性对比（Figure 5）：同样一个"改第5页底部文字"的请求，DeepPresenter 完成了修改，但同时动了公式块和布局；MemSlides 只动了目标元素。前者从结果上看"改了"，从过程上看是一次全页重写。
我的看法
MemSlides 解决的问题是个基础设施问题——在 PPT 生成场景里做好记忆分层——而不是模型能力的突破。三种记忆分别对应三种不同生命周期的信息，这个设计逻辑清晰，落地的方式也相对直接。
工具记忆这一块，我觉得还有很多可以挖的地方。现在的实验规模（9个诊断对）相对受控，在更复杂的 deck 编辑场景里——比如跨 deck 复用工具链经验——效果还是个问题。另外，profile consolidation 的策略目前比较保守（只有稳定信号才写回），在偏好本身会随时间演变的情况下，怎么 handle 旧偏好过时是个没处理的问题。
但这篇的价值在于把"个性化"从 prompt 工程的范畴里拆出来，当成一个需要专门设计的系统问题来处理。这个思路比单纯改 prompt 格式更有意思。
• 论文：https://arxiv.org/abs/2606.17162
• 代码：https://github.com/huohua325/Memslides
• 项目主页：https://memslides.github.io/
✍️ 老Z ·
欢迎转发，谢绝洗稿
