DSH Office 插件：将 AI 能力嵌入 Excel、Word 与 PPT 的开源方案

/* MD / 富文本中的 .toc（含博客园搬家等嵌套结构）；.toc-box 在侧栏，不受影响 */
#content_views .toc,
/* 编辑器常在目录前后插入空 p（:empty 仍占 20px），一并去掉避免顶空隙 */
#content_views.markdown_views > p:empty:has(+ .toc),
#content_views.markdown_views > .toc + p:empty,
/* 富文本旧版目录标记 */
#content_views.htmledit_views #main-toc,
#content_views.htmledit_views #hr-toc,
#content_views.htmledit_views p[id*=\”-toc\”] {
display: none !important;
}
/* 目录去掉后，紧跟的首个标题不再多出一块上边距 */
#content_views.markdown_views > .toc + h1,
#content_views.markdown_views > .toc + h2,
#content_views.markdown_views > .toc + h3,
#content_views.markdown_views > .toc + h4,
#content_views.markdown_views > .toc + p:empty + h1,
#content_views.markdown_views > .toc + p:empty + h2,
#content_views.markdown_views > .toc + p:empty + h3,
#content_views.markdown_views > .toc + p:empty + h4 {
margin-top: 0 !important;
}

这次我们来看一个刚开源的 Office 插件项目：DSH。它瞄准的不是单个模型能力，而是把 AI 能力真正塞进电子表格、文档和演示文稿的操作流程里。过去用 AI 处理 Office 文件，典型路径是先导出文本、再粘贴到网页对话框、最后把结果复制回文档。DSH 这个插件要改变的正是这种来回切换的状态，让模型能力以侧边栏或功能区的形式直接出现在办公软件内部。

从社区热词和讨论氛围看，DSH 插件生态已经不是一个孤立的单点工具。 dsh plugin –profile web add dshmarket 这条命令说明它具备 CLI 管理机制，可以按 profile 添加外部插件市场； awesome dsh plugin 说明已经有人在维护插件资源列表； dsh 插件开发 相关搜索也说明它预留了二次开发入口。这些信号放在一起，可以判断 DSH 是一套可扩展的插件体系，而不是一次性交付的固定功能。同时， deepseek harness 与 DSH 在社区讨论中高频关联，DSH 在设计上更接近一个“模型能力桥接层”：后端对接模型推理服务，前端对接 Office 办公界面，中间由插件市场承担分发和扩展。

这篇文章会结合 DSH Office 插件的开源信息和 Office 加载项（Office Add-ins）的通用机制，把下面几件事讲清楚：这个插件到底解决什么问题、软件和硬件门槛是什么、怎么安装和启动、按电子表格/文档/演示文稿三类场景怎么验证效果、怎么通过接口做批量任务、运行时会占多少资源、遇到常见问题怎么排查。如果你正准备给自己或团队的工作流接入一个“文档里的 AI 侧边栏”，这篇文章可以直接当部署前参考。

先说一个很重要的前提：DSH 仓库的具体版本、命令参数和接口路径会随迭代变化，所以文中的命令和配置给的是通用可执行框架，实际执行时必须按官方仓库的 README 和 –help 输出为准。尤其是插件市场命令，从早期版本到正式版本，参数格式很可能调整，直接复制网上的旧命令到生产环境，大概率会踩坑。后面排查章节会专门讲这类问题。

1. DSH Office 插件核心能力速览

这张表里有一部分信息是确定的：开源、支持三种主要 Office 文件类型、带插件市场。另一部分是根据 Office Add-ins 通用机制推导的：侧边栏、manifest、sideload。为什么这么推导？因为目前微软 Office 扩展的主流方式就是加载项机制，而一个能同时工作在 Excel、Word、PowerPoint 里的插件，最自然的实现方式就是一个共用侧边栏页面，加上针对不同宿主的功能面板。DSH 大概率也是这个架构。

需要特别说明的是，表中没有写死显存占用和模型参数量，因为这部分完全取决于你给 DSH 后端接了什么模型。如果后端是远程 API，插件本体几乎不吃显存；如果后端是本地模型服务，显存占用由模型规模决定，这个不能一概而论，下面第 8 章会展开讲观察方法。

2. 适用场景与使用边界

DSH Office 插件适合谁，先看场景再下结论。

第一类是内容生产场景。运营人员写公众号大纲、产品经理写需求文档、售前写方案初稿，这类工作大量依赖“生成 + 改写 + 压缩”的循环。把 DSH 插件装进 Word 后，选中一段文字就能直接让模型改写，不用再复制到外部工具，整个工作流可以保持在文档上下文里。

第二类是数据处理场景。Excel 里做数据清洗、公式生成、分类打标，以前要手动写函数或者跑 Python 脚本。DSH 插件如果接上了模型服务，可以选中一个单元格区域，让模型按规则补全、改写、提取关键词。对非程序员用户来说，这比学 pandas 的曲线平滑很多。

第三类是演示文稿场景。PPT 制作中最耗时的是搭大纲、定标题、写演讲者备注。DSH 插件能在侧边栏里生成一页一页的提纲，甚至按当前页面内容生成下一帧建议，这比打开一个独立网页再切回来效率高。

但这些价值都有一个前提：后端模型服务是可用且稳定的。插件本身只是一个壳，真正决定输出质量的是模型，决定延迟的是模型服务和网络链路。所以如果期望“装完插件什么都不用配，立刻能用 AI”，那是误解。DSH 是一个工具链，需要你把后端接好，插件才有意义。

再看使用边界。

第一，开源不等于默认安全。DSH 插件代码公开，你可以审查它的数据流，但这不代表你随便从一个插件市场拉来的扩展就是安全的。尤其是涉及公司内部文档、客户数据、个人隐私时，必须先确认数据会发送到哪里，是内网模型服务还是外部 API。

第二，敏感数据外发风险。如果你把商业合同、源代码、医疗信息粘贴到插件侧边栏，而 DSH 后端配置的是公网大模型 API，这些数据就会离开你的网络边界。对于有合规要求的团队，正确做法是只在本地或私有化部署的推理服务上使用。

第三，肖像与版权合规。如果后续插件扩展支持了图像生成、声音合成或数字人相关能力，必须确认素材授权。包括人脸照片、他人声音、受版权保护的文本和图片，没有授权的情况下不能输入给模型做生成或克隆。

第四，自动化内容需要人工复核。AI 生成的公式可能算错，生成的合同条款可能有法律风险，生成的 PPT 配图可能不符合品牌规范。批量任务跑完之后，人工抽检和复核环节不能省。

3. DSH 本地部署环境准备

在开始装 DSH Office 插件之前，先把环境检查一遍。这套清单并不依赖某个特定版本，但每一项都值得先确认，避免装到一半卡住。

操作系统方面，Windows、macOS、Linux 通常都能跑出来，但 Office 加载项 sideload 在 Windows 和 macOS 上体验最顺，Linux 上通常搭配 Office 网页版使用。如果你的主力机器是 Linux，建议优先用浏览器测试网页版 Office，而不是跟桌面客户端较劲。

Node.js 是必装项。DSH 的 CLI 走 npm/pnpm 生态，所以本机需要 Node.js 环境。具体版本要求以仓库 package.json 的 engines 字段为准，一般在 Node 16 以上。安装后先确认版本：

node -v
npm -v
pnpm -v

如果 pnpm 没有装，可以顺手装上：