飞书幻灯片怎么改？41 万人装的 Skill，先把验收写进流程

同事在群里丢来一句：“这页标题换一下，末尾再补一张图。”

听起来像三分钟的活。真正麻烦的是，你不知道这次修改会不会把前一版的字体、页脚、图表或第七页的布局一起带偏。一次性把整份 PPT 交给 Agent 重做，确实省了点鼠标；但下一次返工时，原来能用的东西也要重新验一遍。

我这次翻到一个很适合这种场景的工具：Lark Suite 官方的 Lark Slides Skill。skills.sh 当前显示它有约 41.78 万次安装，对应仓库约 1.77 万 Star。它的卖点不是“一句话生成高级汇报”，而是把在线幻灯片当作一个可以读取、局部替换、回读和验证的内容系统。

安装命令只有一行：

npx skills add \
  https://github.com/larksuite/cli \
  --skill lark-slides

这篇不是线上实测报告。我没有为了写稿新建一份飞书幻灯片，也不会假装跑出了什么节省工时。下面只拆官方工作流里最值得借走的部分：当团队反复改汇报时，为什么“读—改—验”比“再生成一次”更像一条能交付的流程。

先别写 XML，先把每一页要解决什么写下来

官方规则要求新建或大幅改写一份演示文稿前，先落一个 slide_plan.json。里面不只是大纲，还要写清每页的核心结论、布局类型、视觉焦点、文字密度，以及素材缺失时的替代方案。

这一步很朴素，却正好卡住了 AI 做汇报最常见的毛病：把“项目复盘”平均切成六页，每页一个标题加三条 bullet，颜色和图标倒是很勤快，结论却没地方落脚。

有了页面计划，模型才知道这一页该用大数字、对比列、时间线还是图表；也知道主视觉是要解释数据，还是要给客户一个能看懂的产品画面。说得直白一点，先把每页的任务写出来，再谈“好看”才有落点。

官方还把图表、图片和文本的边界写得很细。图片必须先上传成飞书的 file_token，不能把外链直接塞进页面；原生图表该用图表元素，文本要显式给字号、自动换行和行距。它们听上去不浪漫，但都是为了避开一种最尴尬的交付：本地预览挺好，协作文档里却是破图、截断文字和空白页。

改一个标题，和重做一页，是两种不同的动作

这套 Skill 最有价值的地方，不在于“能改”，而在于它强迫你先选修改粒度。

如果同事只让换一个标题、调整一个文本块或插一张图，走 +replace-slide。它是块级替换，只动点名的元素，不改页面顺序，也不顺手清掉旁边的图表。对每周滚动修改的周报、客户方案和复盘材料，这才是默认动作。

如果要换整页背景、重排大半页内容或批量改版式，才用 +update-slide。这条命令的规则很硬：提交内容里没写进去的元素会被删除。它不是坑，反而是一张写在工具表面的风险提示——整页重写之前，得先把旧页面读回来，确认哪些对象必须保留。

再往前一步，新增页面用 +add-slide，删除页面需要先回读确认 slide_id。这些动作拆开以后，Agent 不再把“帮我改两页”理解成“请把 deck 重新想一遍”。对于协作型办公流，这个差别比会不会多画几个装饰图标重要得多。

交付前那三步，才是它真正想留下的东西

官方流程在提交前要求把待写入的 XML 保存到本地，先跑 xml_lint.py；检查结果有错误就不能写入。写完之后还要回读整份 XML，核对页数和关键元素，并用截图检查越界、重叠、空白页和内容过稀的风险。

这几步没法替你判断“这张图会不会让老板停三秒”，但它能解决更基础的问题：你改的是不是那一页，图是不是还在，文字有没有被挤出画布，协作端看到的是否和你以为的一样。

这也是我觉得它值得装的原因。生成内容很容易成为一次性表演，验证把它拉回可以复核的工作。尤其是你的汇报已经在线上持续迭代，有人改数字、有人改措辞、有人临时插一页方案时，能回读、能局部动、能截图验收，比再得到一份漂亮初稿更省心。

拿一份周报试跑，别从最贵的 deck 开始

真要试，不需要一上来把季度汇报全交出去。找一份已经在线上协作、下周还会继续改的周报，故意只给 Agent 一个很窄的任务：替换第三页的标题，补一张已经获准使用的产品图，再新增一页待办。

流程可以压成下面五步：

1. 回读演示文稿，记住 presentation、slide 和 revision 标识
2. 先写页面计划；新增页才做大纲，局部修改不重排旧页
3. 把待提交的页面 XML 先存本地，跑版式检查
4. 按修改粒度写入：局部替换／整页更新／追加页面
5. 回读 XML，再看页面截图；发现问题只修对应块

这不是为了让过程变长。它是在把一次不可见的模型操作，拆成几次可确认的小提交。第三步能发现 XML 写错或元素越界；第五步能发现“命令成功”但图片没显示、文本看不清、内容意外变少。对需要留痕的办公室协作，这两个问题比生成速度更要命。

也别把验证理解成多跑一个脚本就万事大吉。XML 结构正确，不代表这页真的好读；截图看起来没溢出，也不代表那条结论是对的。前者是工具可以兜住的工程错误，后者仍然是作者和审稿人该做的判断。把责任分开，反而不容易对 Agent 抱错期待。

模板不是背景图，协作也不是把文件扔上云

很多团队的现状介于两头之间：老板给了一份多年攒下来的模板，里面有母版、页脚、客户 Logo 和一堆没人敢动的元素；内容又必须在飞书里一起改。最危险的做法，是把模板只当一张背景图，让 Agent 在上面盖新的文本框。短期看能交，后面每一次替换都更难维护。

官方流程单独给了模板导入与编辑路径，先把已有演示文稿读出来，再按页面和元素动刀。这个顺序值得保留：先知道原稿里有什么，再决定保留什么、换掉什么。自动化最适合处理重复且可验证的编辑，不适合替人猜测哪些历史元素只是装饰，哪些其实是品牌或审批要求。

对图片也一样。外部 URL 不能直接成为幻灯片里的图片地址，需要先变成受控的文件素材。看着像多一道手续，实际是在把“以后谁还能打开这页”的问题提前解决。协作资料的寿命往往比一次汇报长，能回读的素材和结构，才有机会真的被下一位同事继续使用。

哪些团队值得先用，哪些先别折腾

如果你的材料经常在飞书里协作、同一份 deck 会被反复修改，而且团队很在意“改一页不要伤到整份”，这条流程值得先拿一份周报或复盘做试点。别从老板最重要的路演稿开始，先挑一份改动频繁、可以回滚的日常材料。

如果只是临时做一份一次性的概念提案，或者团队的格式、审批和模板都锁在 PowerPoint／Keynote 里，先别为了装一个 Skill 强行迁移。它也不能代替内容判断：数字该不该上首页、结论是否站得住、素材是否能公开，还是得由真正对这件事负责的人决定。

还有一个现实边界：它依赖飞书身份授权和 Slides 的 XML 协议。需要协作权限、模板导入，或要处理外部图片时，先把权限、素材来源和上传路径理清。没有这几项，自动化只会把“手工时会提醒你的问题”更快地送到失败页。

试点一轮以后，也别只看它是否成功生成页面。回头问三件事：返工时有没有少改错一页，审核人能不能更快定位变化，下一位接手的人是否看得懂这次为什么这样改。三项里没有一项变好，就不该因为安装量高而继续往流程里加复杂度。

我会把它看成一条汇报协作的护栏，不是一个替代做汇报的人。页面计划让内容不散，局部修改让返工不伤，回读和截图让交付有证据。

你们团队改汇报时，最常见的事故是“改一页带坏整份”，还是“每一页都看着对，却没有一句话能讲清结论”？