AI PPT一改就崩盘？MemSlides登顶抱抱脸，让Agent记住你的改稿习惯

新智元报道 最尴尬的一刻，往往不是AI PPT生成失败。 而是它明明已经生成了一套还不错的slides，你只是说：「把第 8 页右下角那块改得更像流程图。」 下一秒，第8页可能确实改了，但第3页标题层级变了，第12页配色也漂了，前面反复调好的风格又被打散。 这才是真实PPT工作流里更常见的痛点。 第一版只是草稿，改稿才是主战场。 从「生成一套」到「生成得像这个用户」 过去几年，自动幻灯片生成进步很快。很多系统已经可以从论文、产品说明或一句主题出发，生成结构完整、视觉上也不算粗糙的初稿。 但在真实使用里，第一版slides的关键不只是「有没有生成出来」，而是它是不是已经贴近某个用户的表达习惯。 同一篇Transformer论文，可以被讲成基础教学课，也可以被组织成组会汇报、论文精读或技术培训。不同用户关心的页面角色、内容密度、证据边界和机制展开方式都不一样。有人希望先给结论和takeaways，有人更希望把定义、机制、边界条件拆清楚。 这正是用户画像记忆在round-0阶段的作用。 由北京邮电大学、清华大学、上海交通大学合作完成MemSlides 不是等到用户反复修改之后才开始「记住」，而是在首轮生成时就会根据当前任务意图检索用户画像，将兼容的长期偏好路由到当前工作记忆里，用来影响页面组织和表达方式。 论文链接: https://arxiv.org/abs/2606.17162 项目主页: https://memslides.github.io/ 演示链接: https://memslides.com/ 代码链接: https://github.com/huohua325/Memslides HF链接: https://huggingface.co/papers/2606.17162 该工作登顶Hugging Face Daily Papers #1 Paper of the Day，GitHub已获400+ stars；Demo website上线后也已吸引 100+ verified users试用。 图1展示的不是一个泛泛的「生成效果图」。它更像是在说明：系统如何把论文材料拆成定义、核心机制、实验依据、常见误区和边界条件等页面。这些选择背后，对应的就是用户画像中关于内容结构、信息密度和证据导向表达的偏好。 图1：首轮生成不仅体现完整性，也体现用户画像记忆对页面组织、内容密度和证据边界的影响。 项目也提供了在线Demo。用户可以上传材料、选择memory profile或模板，生成初稿后继续进入revision，并下载当前版本的PPTX、HTML或PDF。 也就是说，MemSlides面向的是从个性化初稿到后续持续修改的完整流程。 而一旦第一版已经开始贴近用户，后续问题就变得更尖锐：系统能否在多轮修改中继续保留这些偏好？当前会话里临时提出的要求，会不会过几轮就失效？用户只想改一个局部区域时，系统能不能避免把已经对齐的页面重新打散？ 让记忆分工 很多人一听到「Agent memory」，会自然想到：那就把历史对话放进更长的上下文里。 MemSlides 没这么做。 原因很简单：历史越长，里面的冲突也越多。今天用户说「这套报告用蓝色标题」，不代表他以后所有 PPT 都要蓝色标题；用户在某次编辑里遇到的工具错误，也不应该和「他喜欢什么风格」混在一起。 因此，MemSlides 把个性化幻灯片生成建模成一个有状态的 authoring process：系统先根据源材料、用户画像记忆和可选模板生成 round-0 初稿；之后每一轮反馈都会更新当前 session state，再围绕当前 deck 做局部编辑。 它的记忆组织有两个视角。 从生命周期看，有长期记忆和工作记忆。长期记忆保存跨任务稳定存在的信息，工作记忆保存当前 deck 中仍然有效的临时约束、修改目标和执行状态。 从功能角色看，有用户画像记忆和工具记忆。前者回答「这套 slides 应该体现什么偏好」，后者回答「Agent 应该怎么改得更稳」。 换句话说，MemSlides 不是让 Agent 记住更多废话，而是让它知道哪些信息该长期保留，哪些只在当前任务里生效，哪些属于用户偏好，哪些属于工具经验。 图2：MemSlides 将长期记忆、工作记忆、用户画像记忆和工具记忆组织到同一个多轮改稿流程中。 用户画像 真正的个性化，通常不是一句 role prompt 能解决的。 同样是学术汇报，有人喜欢每页只放一个核心结论，有人会保留公式和实验细节；同样是商业路演，有人偏好高密度表格，有人更依赖趋势图和对比图。 这些差异不是一次 prompt 里的标签，而是用户在长期写作和修改中慢慢暴露出来的习惯。 MemSlides 用用户画像记忆来保存这类跨任务偏好。它不是把 profile 整块贴到 prompt 前面，而是在任务开始时根据当前 intent 检索相关偏好，再与本轮请求做协调。 如果长期偏好和当前明确指令兼容，它们会一起进入工作记忆；如果发生冲突，当前这套 slides 的明确要求优先。 这一步很重要。否则，系统很容易把「这次临时想要蓝色标题」误当成「用户永远喜欢蓝色标题」。 任务结束后，MemSlides 也不会把每一句反馈都写回长期画像。它只沉淀稳定、可迁移的交互信号，让下一次生成更贴近用户，而不是更混乱。 图3：用户画像记忆会经历检索、路由、当前任务使用和任务结束后的稳定信号沉淀。 工作记忆 多轮改稿里，还有一类信息更微妙。 它不是长期偏好，却必须在当前 deck 里持续有效。 比如用户在第2轮说：「后面如果新增 summary/tip box，就用浅灰背景。」当时系统还没有新增这类元素，所以这条要求没有立刻执行对象。几轮之后，如果用户要求插入带 summary box 的页面，这条规则就应该被触发。 如果Agent只看当前轮输入，就很容易把这类延迟生效的约束忘掉。 MemSlides的工作记忆就是当前写作任务的状态板：active temporary preferences、carryover instructions、resolved targets、coverage status 都放在这里。Plan 阶段读取这些状态来确定修改范围，Act 阶段据此执行受限编辑，Guard 阶段再更新检查结果。 这让多轮修改不再是彼此孤立的一次次 prompt，而是围绕同一套 slides 持续推进的编辑过程。 图4：工作记忆让早先提出、后续才触发的临时样式偏好继续生效。 只改该改的地方 对人类编辑来说，「只改这一处」是一句很自然的话。 对生成式系统来说，这句话却很难。 因为很多系统在处理反馈时，会重新读取或重写大范围内容。结果就是目标区域改对了，但非目标页面也发生变化。用户看上去只提了一个小要求，系统却把整套 PPT 的状态重新打散。 MemSlides用scoped slide-local revision来约束这个问题。 每次反馈先被映射到最小有效修改区域，然后进入Plan-Act-Guard流程。 Plan阶段把自然语言请求转成execution contract，明确目标slide、作用范围、selector hints 和覆盖要