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

这次我们来看一个刚开源的 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 没有装，可以顺手装上：

npm install -g pnpm

Office 版本这里要说清楚。DSH 插件作为 Office Add-in，支持的宿主取决于微软加载项机制的能力边界。通常 Microsoft 365 订阅版和 Office 2021 之后的零售版对加载项支持比较好。Office 2016 或更老的版本，加载项机制支持有限，可能会出现安装了 manifest 但功能区不显示的情况。免费用户想测试，可以用 Office 网页版，打开后通过 sideload 上传 manifest，这是成本最低的验证路径。

后端模型服务是另一个关键前置条件。DSH 插件本身不带模型，它需要一个能响应请求的推理服务。这个服务有以下几种配置方式：

• 远程 API：在插件环境变量里配置 API 地址和 key，适合不想在本地装模型的场景。
• 本地推理服务：如果仓库兼容 OpenAI 风格的接口，可以用常见推理工具起一个本地服务，比如 Ollama、vLLM 或 llama.cpp 的 server 模式。这些工具是否兼容需要按 DSH 仓库的文档确认。
• 官方托管服务：如果 DSH 提供了官方后端，直接配置官方地址即可。

网络方面，安装阶段需要能访问 npm registry 和 DSH 插件市场源。如果你所在网络访问 npm 较慢，可以切换国内镜像源。

npm config set registry https://registry.npmmirror.com

如果你在代理环境或公司内网，需要提前确认 npm 和 Office 加载项请求都能通过内部代理。

磁盘空间方面，CLI 工具本身很小，几十 MB 级别。大头在模型文件，如果你选择本地部署模型，需要预留足够的空间。以常见的开源模型为例，参数规模从 7B 到 70B 不等，磁盘占用可能从几个 GB 到上百 GB。这个数字取决于你实际选的模型，不能一概而论。

端口占用同样要注意。DSH 后端服务和 Office 侧边栏页面之间需要本地通信，通常会监听某个本地端口。如果端口被占用，服务会起不来。检查端口可以用系统自带命令：

# Windows netstat -ano | findstr "端口号" # macOS / Linux lsof -i :端口号

如果端口冲突，优先修改 DSH 后端的监听端口，或者在环境变量里重新指定。

4. DSH 插件安装部署与启动方式

环境准备好之后，进入正式安装流程。下面这套流程结合了 CLI 管理和 Office Add-ins 的通用 sideload 逻辑，具体步骤名称以 DSH 仓库文档为准，但整体路径是通的。

4.1 安装 DSH CLI

先安装 DSH 的 CLI 工具。这里无法确定发布时用的确切包名，所以用dsh-cli作为占位符，实际执行前先查仓库里给出的 npm 包名。

npm install -g dsh-cli

安装完成后，先看帮助信息，确认当前版本支持哪些子命令：

dsh --help dsh plugin --help

从社区热词来看，插件管理是 CLI 的核心能力之一。常见操作包括查看已安装插件、搜索可用插件、添加插件市场、更新和卸载插件。

4.2 添加插件市场

社区热词里出现了一条关键命令：

dsh plugin --profile web add dshmarket

这条命令的作用是给当前 profile 添加一个名为 dshmarket 的插件源。执行后，CLI 会拉取插件市场的索引，之后就能通过插件市场安装 Office 插件。这里有几个注意点：

• --profile web指定的是配置环境，可能对应 web 端场景。如果你要配置本地桌面环境，可能需要换成其他 profile。
• dshmarket是插件市场名称，不同市场可以同时添加多个。
• 如果命令参数已经变化，先用dsh plugin add --help查看最新的参数格式。

添加成功后，可以用查询命令检查市场是否连通：

dsh plugin list dsh plugin search office

4.3 安装 Office 插件

CLI 将插件市场同步完成后，下一步是安装 DSH Office 插件本体。通常插件会以 manifest 文件的形式下发，manifest 中声明了插件名称、ID、支持的 Office 宿主类型、侧边栏页面 URL 等信息。

dsh plugin install office --profile web

安装完成后，CLI 会提示 manifest 所在的本地路径，一般会放在 dsh 配置目录下。这个路径需要记下来，因为后面的 sideload 需要用到。

4.4 将插件加载到 Office

Office 加载项的加载方式取决于你用的是桌面版还是网页版。

桌面版 Excel / Word / PowerPoint 的 sideload 方式：

1. 打开一个空白文档。
2. 菜单栏选择“插入” -> “获取加载项” -> “管理我的加载项” -> “上传我的加载项”。
3. 选择 DSH CLI 输出的 manifest.xml 文件。
4. 等待加载完成后，功能区会出现 DSH 标签页或侧边栏按钮。

Office 网页版的 sideload 方式：

1. 打开 Office 网页版中的一个文档。
2. 进入“插入” -> “加载项” -> “上传我的加载项”。
3. 选择 manifest.xml，确认加载。
4. 刷新页面后，侧边栏按钮就会出现。

如果上面的入口路径和你当前的 Office 版本不一致，不要硬套。Office 的菜单命名在不同语言和版本下有差异，直接在设置或管理加载项里找“上传我的加载项”入口即可。

4.5 配置 DSH 后端地址

插件加载之后，还需要让侧边栏知道后端服务在哪。这个配置一般通过环境变量或 CLI 设置完成。通用的配置方式如下：

# 设置 DSH 后端服务地址 dsh config set backend.url http://127.0.0.1:8000 dsh config set backend.api_key your-key-here

如果 DSH 使用.env文件管理配置，可以手动创建并填写：

DSH_BACKEND_URL=http://127.0.0.1:8000 DSH_BACKEND_API_KEY=your-key-here

配置完成后，重启插件侧边栏，再检查日志确认后端连接是否成功。日志路径一般在 DSH 配置目录下的logs文件夹里，或者直接看 CLI 输出的日志流。

4.6 启动服务的顺序

一个容易踩坑的点是启动顺序。正确顺序应该是：先启动 DSH 后端模型服务，再启动 CLI 或 Office 宿主，最后打开插件侧边栏。如果先打开 Office 再启动后端，侧边栏第一次加载时可能拿到连接失败的错误，之后虽然你不处理也会恢复，但会多一次无效请求，而且用户容易误判为插件坏了。

5. DSH 插件功能测试与效果验证

装好之后，别急着直接用于生产。先按下面这一套验证流程跑一遍，确认插件、后端、模型三者的通路都没问题。测试时优先使用不含敏感信息的测试文本，不要一上来就丢公司文档进去。

5.1 基础连通性测试

在任意一个 Office 文档里打开 DSH 侧边栏，输入一段简单的测试提示词，例如：

用一句话解释什么是数据库索引。

预期结果是侧边栏返回一段可读的模型回答。如果返回错误，先检查后端服务是否启动、日志里有没有请求记录。这一步跑通，说明插件到后端的链路是通的，后续功能测试才有意义。

5.2 电子表格功能测试

电子表格里，DSH 插件最常见的价值点是公式生成、数据填充和内容分类。

测试目标：验证选中单元格区域后，模型能否按规则批量补全或改写内容。

操作步骤：

1. 在 Excel 中准备一列测试数据，例如 10 条订单备注。
2. 选中数据区域。
3. 打开 DSH 侧边栏，选择“填充/改写”功能。
4. 输入指令，例如“将每条备注改写为正式客服话术，并提取客户反馈关键词”。
5. 点击执行，等待结果返回。
6. 检查输出是否有遗漏行、格式是否一致。

预期结果：每个输入行都有对应输出，内容与指令匹配。

这一步最容易出现的问题是：选区过大，产生大量 prompt 请求，导致超时。第一次测试建议只选 3 到 5 行，确认流程稳定后再扩大范围。

公式生成测试也是 Excel 场景的核心。输入需求描述，让模型生成公式。例如：

在 C2:C100 统计 A 列每个分类对应的 B 列平均值

预期结果：返回一个可用的 Excel 公式，例如=IF(...)或=AVERAGEIF(...)。需要人工验证公式是否可以在 Excel 中正常运行，因为模型生成的公式在复杂嵌套时经常有括号不匹配的问题。

5.3 文档功能测试

Word 场景主要验证摘要、改写和续写。

测试目标：选中文档中的一段长文本，执行摘要操作，判断输出是否压缩了关键信息。

操作步骤：

1. 在 Word 中写一段 500 字左右的测试正文。
2. 选中这段文字。
3. 在 DSH 侧边栏选择“摘要”或者直接输入指令“总结这段内容，输出 3 个要点”。
4. 点击执行。
5. 对比输出要点和原文主题是否一致。

预期结果：输出包含 3 个要点，每个要点都能对应到原文的关键信息。

改写测试关注风格一致性。输入指令“将这段内容改写为更正式的语气”，观察模型是否改变了原文的客观事实。这里要特别注意：模型改写后可能存在事实漂移，不能只读一句觉得“通顺”就放心，要逐条核对数据、人名、日期是否保持一致。

文档场景的常见失败原因是上下文超长。如果整篇文档有上万字，插件把全文塞给模型，很可能请求被后端拒绝或截断。建议先测试长文档章节级的处理，把模型上下文限制在合理范围内。

5.4 演示文稿功能测试

PowerPoint 场景重点验证大纲生成、页面总结和演讲者备注生成。

测试目标：给一个空白 PPT 生成 5 页大纲，或基于现有页面生成演讲者备注。

操作步骤：

1. 打开一个新的 PowerPoint 文件。
2. 在 DSH 侧边栏输入主题，例如“生成一份关于市场部 Q3 复盘的大纲，包含 5 页”。
3. 点击执行，等待返回结构化大纲。
4. 将大纲内容复制到 PPT 页面中，或者如果插件支持直接写入，则检查写入后的排版。

预期结果：返回的大纲结构完整，包含标题和每页要点。

演示文稿场景的另一个验证点是批量生成演讲者备注。选中多张幻灯片，让插件逐页生成备注，检查每页备注是否和当前页内容相关。这一步能快速暴露批量任务的设计问题：是逐页串行请求，还是并行请求？如果串行，几十页 PPT 可能等很久；如果并行，后端可能扛不住。测试后心里要有数。

5.5 自定义参数与稳定性测试

功能跑通后，还要做一轮自定义参数测试。

• 温度参数：调节生成随机性，验证插件侧边栏是否能正确透传参数。
• 输出长度：设置最大 token 或最大输出字符数，验证长输出是否会被截断。
• 多轮对话：在侧边栏连续提多个问题，验证上下文是否按预期保留或重置。

稳定性测试的关键指标是：连续执行 20 次相同请求，是否出现偶发超时、连接重置、无响应。如果出现，优先检查后端日志和后端服务的并发配置。

6. DSH 接口 API 调用示例

DSH 插件侧边栏的本质是一个网页，它和后端之间的通信走 HTTP。如果你后续想把 DSH 的能力接到自己的脚本或内部系统里，可以直接调用后端接口，不一定非要操作 Office 界面。下面给出的是通用 API 调用模板，基于当前开源生态常见的 OpenAI 兼容风格来写。具体路径、鉴权方式和参数名，必须以 DSH 仓库的 API 文档为最终依据。

6.1 基础 curl 调用

curl http://127.0.0.1:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -H "Authorization: Bearer your-api-key" \ -d '{ "model": "your-model-name", "messages": [ {"role": "user", "content": "总结下面的会议纪要成三句话：..."} ], "temperature": 0.3 }'

如果 DSH 后端不是这套接口格式，那么这个请求会返回 404 或 400。这时候去后端日志看实际注册的路由，一般日志里会打印所有已挂载的 endpoints。

6.2 Python 调用示例

import requests url = "http://127.0.0.1:8000/v1/chat/completions" headers = { "Authorization": "Bearer your-api-key", "Content-Type": "application/json" } payload = { "model": "your-model-name", "messages": [ {"role": "system", "content": "你是一个数据清洗助手。"}, {"role": "user", "content": "提取以下文本中的日期和人名：..."} ], "temperature": 0.0 } response = requests.post(url, json=payload, timeout=60) print(response.status_code) print(response.json()["choices"][0]["message"]["content"])

这里有一个实用的调试技巧：调接口时先不拼业务逻辑，先用固定文本测试，确认返回结构和字段名，再套到自己的循环里。否则一旦字段名写错，批量任务会成片报 KeyError。

6.3 接口鉴权与超时策略

接口鉴权字段通常通过环境变量注入，不建议硬编码在脚本里。请求超时要设置合理值：文本生成类接口通常耗时 30 到 120 秒，时间设太短会导致正常请求被误判为失败；设太长又会让任务队列堆积。建议第一次用小文本测试，测出该模型在后端上的平均耗时和 p95 耗时，再决定超时上限。

脚本里还要处理重试。网络抖动、后端临时负载高、连接池耗尽都会导致偶发失败。一个简单的重试策略：最多重试 3 次，每次等待时间递增，例如 1 秒、3 秒、8 秒。

7. DSH 批量任务与自动化处理

Office 插件的交互式操作适合小规模验证，真正要提升生产力，批量任务才是关键。DSH 的批量场景通常分为三类：Excel 选区逐行处理、Word 章节批量总结、PPT 多页生成备注。

7.1 批量任务的设计方式

批量任务不宜直接在插件侧边栏里一页一页点击执行，效率低且难以追踪。推荐的做法是在插件侧边栏里选中任务范围后，一次性提交给后端，由后端按队列串行或并行处理。

如果 DSH 插件内部没有任务队列，可以考虑外部脚本兜底。下面是一个 Python 批处理示例，逻辑是读取一个 CSV 文件，逐行调用 DSH 接口，把输出写回新文件。这个示例是通用模板，需要按实际接口字段和业务逻辑调整。

import csv import time import requests from requests.adapters import HTTPAdapter API_URL = "http://127.0.0.1:8000/v1/chat/completions" API_KEY = "your-api-key" INPUT_FILE = "./input.csv" OUTPUT_FILE = "./output.csv" MAX_RETRY = 3 session = requests.Session() session.mount("http://", HTTPAdapter(max_retries=MAX_RETRY)) def process_line(row): prompt = f"将以下内容归类并提取关键词：{row['raw_text']}" payload = { "model": "your-model-name", "messages": [{"role": "user", "content": prompt}], "temperature": 0.0 } for attempt in range(MAX_RETRY): try: resp = session.post(API_URL, json=payload, timeout=90) resp.raise_for_status() return resp.json()["choices"][0]["message"]["content"] except Exception: time.sleep(2 ** attempt) return "ERROR" with open(INPUT_FILE, "r", encoding="utf-8") as f_in, \ open(OUTPUT_FILE, "w", encoding="utf-8", newline="") as f_out: reader = csv.DictReader(f_in) writer = csv.writer(f_out) writer.writerow(["input", "output"]) for row in reader: result = process_line(row) writer.writerow([row["raw_text"], result]) print(f"processed: {result[:30]}...")

这个脚本的核心思路是：每条输入独立请求，请求失败后指数退避重试，最终失败则写入 ERROR 标记，方便事后复查。

7.2 批量任务并发与限流

批量任务要考虑并发控制。如果一口气开几百个并发请求，后端推理服务可能直接崩溃，或者排队时间猛增。推荐先做小规模压测：从 1 并发开始逐步增加，观察后端响应延迟和显存占用，找到安全并发上限。

另一个容易被忽略的点是输入内容长度。同一个 prompt 模板里，如果输入字段长度差异很大，单条请求的 token 消耗差异也会很大，导致整个批量任务的总时间不可预测。批量执行前，先统计输入文本长度的分布，把超长文本单独切分或单独走长文本处理逻辑。

7.3 批量任务日志与断点续跑

批量任务最好支持断点续跑。最简单的做法是每处理完一条就落盘一条，不要等全部完成后再统一写文件。这样即使中间进程崩溃，已处理的结果也不会丢。上面的代码用了逐行写文件的方式，就是这个原因。

更完整的方案是维护一个任务状态表，包含每条输入的 id、状态、重试次数、失败原因和输出。这样后续可以只重跑失败的任务，不用整批再来一遍。

8. 资源占用与性能观察

DSH 插件的资源占用要从两层看：前端插件本体和后端模型服务。

插件本体非常轻。它本质上是一个 Office 宿主里的 WebView 页面，加载后主要消耗的是内存和少量 CPU，内存占用通常在几十 MB 到几百 MB 之间，取决于侧边栏页面复杂度。如果只是简单对话，不会对 Office 造成明显性能影响。

资源大头在后端模型服务。如果在本地部署模型，显存和内存占用由模型参数规模、量化方式和并发数决定。一个 7B 模型用 4-bit 量化，大约需要 6 到 8 GB 显存；13B 模型 4-bit 量化大约需要 10 到 12 GB；70B 模型的量化版本则远超消费级显卡容量。这些是通用参考区间，不是 DSH 官方数据，具体占用需要以你选用的模型和推理框架实际运行为准。

要观察资源占用，分平台操作：

• Windows：打开任务管理器，转到“性能”面板，观察 CPU 和内存占用率。如果用的是 NVIDIA GPU，任务管理器的“GPU”面板会显示显存占用。
• Linux：顶部用htop或free -h看内存，用nvidia-smi看显存。
• macOS：用“活动监视器”查看内存压力和 GPU 用量。

# 查看 GPU 显存占用 nvidia-smi # 每 2 秒刷新一次 watch -n 2 nvidia-smi

如果用的是远程 API，本机资源占用很小，主要关注网络延迟和 API 的并发限制。

性能优化方向上，降低显存占用的常见手段是加量化参数、减小上下文长度、降低 batch size。如果后端使用 vLLM 这类推理框架，还可以配置更小的 max-model-len 来节省显存。如果插件侧边栏响应很慢，优先检查是网络耗时还是生成耗时，可以在浏览器开发者工具里看 Network 面板，确认请求的耗时分布。

批量任务期间，显存占用会波动。小批次串行时，显存占用平缓；并行批次上来后，显存峰值会明显上升。建议在批量跑之前先记一个基线显存，跑的过程中持续用 nvidia-smi 观察，如果接近显存上限就要降低并发。

9. 常见问题与排查方法

DSH 插件部署和运行中，有几类问题出现频率最高。下面按现象、可能原因、排查方式和解决方案整理成表，方便对照处理。

在这些问题里，最容易在部署初期绊倒人的不是 Office 配置，而是 pnpm 安装卡住。社区热词里专门有一条 “deepseek harness 卡在 pnpm dsh web”，说明这不是个例。遇到这种情况先别急着重装系统，按顺序处理：检查 Node 版本是否满足要求、升级 pnpm 到最新版、清掉 pnpm 的缓存和 node_modules、换更稳的 registry 源、最后再重新跑安装命令。

10. DSH 插件最佳实践与使用建议

把 DSH Office 插件接入日常工作流之后，下面这些工程化习惯可以让整体体验稳定很多。

第一，先小参数测试，再全量运行。无论是 Excel 批量处理还是 PPT 批量生成备注，第一次跑一定要缩小范围。先用 3 条数据测试 prompt 效果，确认输出格式符合预期后，再扩大到全量。直接全量跑，等于用生产数据调 prompt，既浪费 token 又浪费时间。

第二，保存一套最小可运行配置。把你验证通过的 DSH CLI 版本、插件版本、后端模型名、量化方式、prompt 模板、关键环境变量整理成一份文档。以后重新部署或者同事加入时，照着这份文档就能复现环境，不用重新踩一遍坑。

第三，模型来源和授权要明确。如果 DSH 后端用的是开源模型，注意记录模型许可证和模型卡信息。如果模型的许可证对商用有限制，而你的业务属于商业用途，需要提前规避风险。

第四，输入、输出、中间文件分目录管理。批量任务的文件建议按以下结构组织：

dsh-tasks/ ├── inputs/ # 原始输入 ├── outputs/ # 最终结果 ├── logs/ # 任务日志 └── checkpoints/ # 断点状态

这样即使某个任务失败，也可以根据日志和 checkpoint 快速定位问题，而不是在一堆混杂的文件里找。

第五，接口服务要限制访问范围。如果 DSH 后端服务监听在 0.0.0.0 而不是 127.0.0.1，意味着同一网络内的其他机器也可能访问到接口。如果你没有鉴权配置，这相当于把模型推理能力开放给了整个内网。生产环境至少加上 API key 鉴权，或者限制监听地址到本机。

第六，对外发布或商用前，一定做内容复核。模型生成的财务分析可能算错比率，生成的营销文案可能有事实错误，生成的合同条款可能漏掉关键信息。DSH 插件提高的是生成效率，不是内容正确率。任何外部可见的内容，都要过一遍人工审核。

第七，关注 DSH 上游更新。插件市场的好处是扩展可以持续更新，但要警惕两个方向：一个是上游更新带来的接口不兼容，另一个是第三方插件市场里的来源不可控。优先使用官方插件市场和官方发布的扩展，第三方插件尽量做代码审查后再安装。

第八，隐私与合规优先。涉及人脸、声音、版权素材、个人敏感信息、商业机密的场景，先确认授权和数据流向。如果敏感，就使用本地部署方案，保证数据不出内网。

11. 总结与下一步

DSH Office 插件最值得尝试的点，是把 AI 从独立对话窗口搬到了真正的办公工具内部。电子表格、文档、演示文稿三类场景都有明确的实用价值，尤其适合内容运营、数据分析和知识管理相关工作流。插件的开源属性让它具备了二次开发和私有化部署的潜力，插件市场机制则保证了生态扩展的可能性。

如果只有一个功能需要最先验证，我建议先测电子表格场景里的批量填充。因为这是最直接、最容易量化效果的场景：输入一列数据，输出一列结果，效率提升肉眼可见。同时它也最容易暴露后端并发、超时设置和 prompt 设计这三方面的问题，一次测试就能看出整个链路的水位。

最容易踩的坑集中在三个方面：一是 pnpm 安装 DSH 依赖时卡住，需要在环境准备阶段就处理 Node 和 registry 问题；二是 Office 加载项 sideload 后功能区不显示，通常是 manifest 加载或缓存问题，而不是插件坏了；三是批量任务跑了一半失败后没有断点续跑机制，导致整体重跑，浪费大量时间和算力。

后续可以继续扩展的方向：一是尝试 DSH 插件体系里更多类型的插件，比如社区维护的其他数据处理工具；二是研究怎么把 DSH 后端替换成更适合自己业务的推理框架和模型；三是基于文档、表格、PPT 三类宿主，设计一套自己的 AI 办公自动化流程；四是如果团队有研发能力，可以直接 fork 这个插件，针对内部业务流程和交互习惯做定制。

建议先跑通最小闭环，再逐步扩大规模。顺手把部署过程中验证过的版本和命令记下来，后面会省很多事。