以前我在WPS里改方案，最烦的就是在浏览器和编辑器之间来回切。选中一段文字，复制到网页对话框，等AI结果，再复制回来，重新调格式……一天下来，这种机械操作能占掉大把时间。后来DeepSeek开放了API，我第一反应就是：能不能让WPS自己直接调用DeepSeek，把AI能力真正嵌进文字处理流程里？带着这个想法折腾了几天，方案跑通了，日常润色、翻译、摘要这些事现在都能在文档里原地完成。这篇文章就把我的接入过程和踩过的坑完整记录下来，给同样想在WPS里用上DeepSeek辅助功能的你一条可以直接照做的路线。
1. 为什么要把DeepSeek塞进WPS：先算清楚这笔账
1.1 每天重复“复制-粘贴-复制”的隐性成本
先说一个反直觉的结论：在浏览器和文档之间来回切换，看起来每次只花十几秒，实际上对思路的打断非常致命。我写材料时最怕的是刚有灵感，结果切到网页把需求打了一遍，切回文档发现自己忘了刚才想说啥，又得回头读上下文。这种“上下文切换”损耗，比单纯的手工编辑更费精力。
即使是简单的润色工作，网页版AI输出后你还得考虑格式问题：原文加粗的标题、段落的缩进、字体颜色，粘贴回来时大概率全丢。你以为是“复制粘贴一下”，实际是“重新排版一遍”。当这种操作一天重复几十次，时间账就很离谱了。把AI调用直接放到WPS里，等于把“复制到浏览器→等待→复制回来→排版”这四步压缩成“选中→点下宏→完成”。
1.2 三条路线对比：WPS AI、网页版、自己接API
我调研过三条路，各有利弊：
| 方案 | 优点 | 缺点 | 适合谁 |
|---|---|---|---|
| WPS自带AI | 开箱即用，不用写代码 | 功能相对封闭，提示词定制不灵活，部分权益需要额外开通 | 不太想折腾、只偶尔用一下的人 |
| 浏览器+DeepSeek网页版 | 零门槛，随时可用 | 文档和AI分离，长文本复制经常截断，格式来回调 | 偶尔处理一小段文本的人 |
| WPS接入DeepSeek API | 灵活可控，能批量处理，直接内嵌到文档流程 | 需要写一点宏代码，有学习门槛 | 经常处理文档、想真正提效的人 |
我的选择自然是第三种。原因很简单：只有API方案能把AI的能力“揉”进日常操作习惯里，而不是把AI当作另一个需要打开的工具。你真正留下的，不是一次次的“打开网页”，而是一套自己的AI辅助工作流。
1.3 谁适合折腾这件事
我总结了一下，下面这几类人从这篇接入方式里受益最大：
- 经常写标书、方案、公文的人。这类文档篇幅长、套话多，润色和统一的诉求非常强，AI直接内嵌能省掉大量来回修改。
- 做行政、综合岗位的人。一天到晚在WPS里处理通知、纪要、汇报，重复性文字工作占大头。
- 要翻译外文资料、做文献整理的人。选中原文直接翻译，还能自定义翻译风格，比来回切网页顺手得多。
- 以及纯粹对办公自动化感兴趣、想给WPS加点黑科技的人。这篇文章的做法本质上是把任意大模型能力“接进”Office/WPS体系，懂了这个思路，后面换别的模型也只是改几行代码的事。
2. 动手前先备好的几样东西
2.1 申请DeepSeek API Key
接入DeepSeek API的第一步是拿到密钥。流程很简单：
- 打开DeepSeek开放平台，注册账号并登录。
- 在控制台左侧找到“API Keys”，点“创建API Key”。
- 给这个Key起个名字，创建成功后把Key完整复制保存下来。注意，这个Key只在创建时完整显示一次，关掉页面后就只能删掉重建了。
申请好Key之后，一般需要充一点额度才能调用。DeepSeek的API价格不高，日常文字处理场景充个几十块能用挺久。这是公开的价格策略，你也可以在平台页面上实时看到计费明细。
有一点要特别提醒：API Key就是你的“钥匙”，把它硬编码在宏里没问题，但千万别把带Key的文档随便发给别人。我在踩坑部分还会再讲Key管理的细节。
2.2 检查WPS的“开发工具”和JS宏环境
接下来要确认WPS里能不能写宏。我推荐用WPS的JS宏（JSA）而不是老的VBA，原因后面详细讲——现在很多版本在“开发工具”选项卡里就能找到“JS宏”入口。打开WPS文字，依次点“文件→选项→自定义功能区”，在右侧勾选“开发工具”，确定后顶部就会出现开发工具选项卡。
在开发工具选项卡里点“JS宏”→“新建”，会打开一个代码编辑器。这个编辑器不用额外安装任何插件，是WPS自带的，基于JavaScript语法，学习成本比VBA低得多。
这里有点经验要分享：很多教程会让你去装VBA for WPS插件，但实际上WPS对JS宏的原生支持做得更好。尤其现在64位WPS很常见，要找对应版本的VBA插件反而麻烦，JS宏没有这个烦恼，64位、32位都能用。如果你过去在WPS里写过VBA，也不用担心，JS宏和VBA能共存，各有各的入口。
2.3 云端API还是本地部署：按场景选
DeepSeek接入WPS有两条路线：一条是直接调DeepSeek官方云端API，另一条是在自己电脑上用工具本地部署一个DeepSeek模型，然后让WPS访问本地接口。
这两条路怎么选？我建议按下面几个标准判断：
- 数据敏感度。如果是公司内部保密文档，不希望内容经过第三方服务器，那就必须走本地部署路线。官方API虽然不会把内容用于训练，但数据毕竟是经过云端流转的，对保密要求高的单位来说风险不可接受。
- 硬件条件。本地部署对电脑配置要求不低，尤其是内存和显卡。纯CPU跑起来慢得让人怀疑人生，想要流畅体验至少需要16GB以上内存，最好有一张支持CUDA的NVIDIA显卡。普通办公电脑还是老实走云端。
- 响应速度和稳定性。云端API的响应时间一般在1到3秒，本地部署则看显卡性能，性能不够时可能几十秒都回不来。就日常文档处理而言，云端API的延迟体验更接近“随叫随到”。
如果决定本地部署，我推荐用Ollama这类工具，后面会单独讲怎么和WPS联动。
3. 核心实现：用WPS的JS宏直连DeepSeek API
3.1 先看完整代码
直接上可用的代码。在WPS开发工具里新建一个JS宏，粘贴下面内容，把你的API_Key换成上一节申请的Key，保存即可：
// 配置区：改成你自己的API Key var DEEPSEEK_API_KEY = "你的API_Key"; var DEEPSEEK_API_URL = "https://api.deepseek.com/chat/completions"; // 核心函数：向DeepSeek发送请求并返回结果文本 function callDeepSeek(promptText) { var xhr = new XMLHttpRequest(); xhr.open("POST", DEEPSEEK_API_URL, false); // 同步请求，等待结果 xhr.setRequestHeader("Content-Type", "application/json"); xhr.setRequestHeader("Authorization", "Bearer " + DEEPSEEK_API_KEY); var payload = JSON.stringify({ model: "deepseek-chat", messages: [{ role: "user", content: promptText }], stream: false }); xhr.send(payload); if (xhr.status === 200) { var resp = JSON.parse(xhr.responseText); return resp.choices[0].message.content; } return "调用失败，HTTP " + xhr.status + "：" + xhr.responseText; } // 常用功能：润色当前选中文本 function DeepSeekPolishSelection() { var doc = Application.ActiveDocument; var sel = Application.Selection; var selectedText = sel.Text; if (!selectedText || selectedText.length === 0) { MsgBox("请先选中需要润色的文本。"); return; } var prompt = "请对下面的文本进行润色，要求保持原意，表达更书面、更流畅：\n" + selectedText; var result = callDeepSeek(prompt); sel.Text = result; }这段代码的意思是：把选中的文本拼进提示词，发给DeepSeek接口，拿到返回结果后，直接用结果替换掉文档里选中的内容。这是最基础的“选中即用”闭环。
3.2 代码拆解：从请求到替换文本
代码看起来不复杂，但里面有几个关键点我拆开讲。
首先是请求地址和鉴权。https://api.deepseek.com/chat/completions是官方兼容OpenAI格式的对话接口，支持deepseek-chat这个模型名。请求头里的Authorization字段必须写成Bearer 你的Key，少一个空格都会返回401鉴权失败。
其次是stream: false。这里我故意关掉了流式输出。流式输出在三方网页里体验很好，但在WPS宏环境里处理起来很麻烦，需要不断解析片段再拼接，对大多数场景来说没有必要。关闭流式后，接口一次性返回完整结果，解析简单，代码也更稳健。
然后是JSON解析。JavaScript里JSON.parse直接搞定，这也是我推荐JS宏而不是VBA的核心原因——VBA没有原生JSON对象，光是把响应里的content字段提取出来，就得写正则，还要考虑各种转义，极其折磨。JS宏就没有这个问题。
最后是用sel.Text = result替换选中文本。这是一个快速实现，实际使用中会带来格式丢失的问题，这部分我在踩坑章节详细说。
3.3 在WPS里运行宏的具体位置
写完宏之后怎么运行？回到WPS文字，开发工具选项卡→“JS宏”，在列表里选中刚才保存的宏（比如DeepSeekPolishSelection），点“运行”。更快的做法是在列表里点“选项”，给这个宏指定一个快捷键，我用的是Ctrl+Alt+P，顺手指位合理，调用很顺手。
如果是在WPS表格里用，对象模型略有差别，但核心的XMLHttpRequest请求逻辑是通用的。你可以把callDeepSeek这个函数原封不动放进表格的JS宏里，只是在获取单元格内容时改用Application.ActiveSheet.Range("A1").Text这类获取方式。
3.4 XMLHttpRequest不可用的兼容写法
我遇到过一些精简版WPS，JS宏环境里没有XMLHttpRequest对象，直接报“未定义”。这种时候不要慌，可以用WPS宏环境支持的ActiveXObject替代：
function callDeepSeek(promptText) { var xhr = new ActiveXObject("MSXML2.XMLHTTP"); xhr.open("POST", DEEPSEEK_API_URL, false); xhr.setRequestHeader("Content-Type", "application/json"); xhr.setRequestHeader("Authorization", "Bearer " + DEEPSEEK_API_KEY); // 后续逻辑完全一致 ... }如果ActiveXObject也被安全策略拦了，那就基本说明WPS运行在受限环境中，可能是公司内网安全软件做了隔离。这种情形下除了联系IT放行，还有一条路是把请求转发到本机部署一个代理服务，用Python写一个简单中转脚本，WPS只负责向http://localhost:8787发请求。不过这是少数情况，正常个人版WPS不需要这么折腾。
4. 从能调到好用：几个可以直接抄的场景宏
4.1 润色改写
润色是使用频率最高的场景，上面代码就是原样版本。不过实际用下来，我发现把提示词做得更具体，效果会更好。比如把Prompt改成“请以严谨但不生硬的书面语风格润色，保留核心信息，不添加原文没有的内容”，比单纯说“润色”靠谱得多。给AI明确约束，是减少结果返工的关键。
如果你经常碰到“AI把内容的原意改偏了”的情况，核心原因是提示词里没有要求保留原意。给DeepSeek补一句“不要改变原文的事实性内容”，基本就能避免。
4.2 批量翻译
翻译场景的宏可以做成循环处理：先把一篇文章拆成段落数组，再逐段调用API翻译，逐段写回文档。这种批量处理比手工复制到网页强在两点：一是能保持文档原有结构，二是可以统一术语。
function DeepSeekTranslateDoc() { var doc = Application.ActiveDocument; // 按段落拆分全文 var paragraphs = doc.Paragraphs; var sb = ""; for (var i = 1; i <= paragraphs.Count; i++) { var paraText = paragraphs.Item(i).Text; if (paraText.trim().length === 0) continue; var prompt = "把下面的内容翻译成英文，用词专业，不要漏译：\n" + paraText; var result = callDeepSeek(prompt); paragraphs.Item(i).Text = result + "\n"; // 加个保护：前一段请求完成后稍等一下 // 避免请求太密集被接口限流 Utilities.sleep(200); } MsgBox("翻译完成。"); }这段代码里我加了一句Utilities.sleep(200)，是因为太密集的连续请求有可能触发接口的频率限制。实际执行时我会把sleep时间设为300毫秒左右，翻译一篇几十段的英文文档，等待时间完全能接受。
4.3 摘要与要点提取
处理超长文档时，我会先让AI生成摘要和要点列表，再判断要不要深读。这个需求在WPS里的实现方式和润色几乎一样，只是提示词不同：
function DeepSeekSummarize() { var sel = Application.Selection; var selectedText = sel.Text; if (selectedText.length > 6000) { MsgBox("文本过长，建议先分段，一次提交6000字以内性能最好。"); return; } var prompt = "你是专业助理，请阅读下面的文字，输出：1. 核心摘要（200字内）；2. 分条要点。不要添加原文没有的信息：\n" + selectedText; var result = callDeepSeek(prompt); // 把摘要插到文档末尾，不覆盖原文 var endRange = Application.ActiveDocument.Content; endRange.InsertAfter("\n\n【AI摘要】\n" + result); }需要注意，这里的摘要是插到文档末尾，而不是替换掉选中内容，因为摘要场景里原文通常还需要保留。这提醒我：不同场景对结果的操作方式不一样，润色是替换、摘要是插入、翻译是逐段改写。写宏的时候先想清楚这个场景下的“读写关系”。
4.4 表格与公式辅助
在WPS表格里接DeepSeek，最常用的两个场景是：让AI解释复杂公式、让AI生成公式。比如我遇到一个棘手的Excel公式，选中单元格后调宏，让AI用通俗语言解释它的计算逻辑；或者我直接给AI描述需求，“统计B列大于100的单元格个数并按C列求和”，让它返回一个公式，我复制进单元格验证。
实现方式和文字处理一样，只改获取文本的对象。核心请求函数callDeepSeek不用动，在表格环境里直接复用。这里也体现出把“调用API”和“业务场景”分开写的好处：只要封装好callDeepSeek，在文字、表格、演示文稿里都能共用同一个请求函数。
5. 实测踩坑记录：从401到乱码，问题逐个拆
我在跑通过程中踩了不少坑，有些坑在官方文档里根本不会写。下面按我实际排查的顺序号列出，希望能帮你少走弯路。
5.1 401/403鉴权失败
现象：第一次调接口，返回401 Unauthorized或者403 Forbidden。
排查链路：
- 先检查API Key有没有复制完整，我第一回就把Key末尾的字母看漏了。
- 再检查请求头的格式。JSA里设置鉴权头的时候，一定要写成
Bearer加Key，注意Bearer后面有个空格。很多人在这里写错，把空格漏了或者大小写不对。 - 确认Key创建后是否已经充值。新账户如果余额为0，部分接口会拒绝调用，返回401。
这个坑是最常见的，90%的401都是这三点中某一点引起的。
5.2 400错误与“JSON转义地狱”
现象：返回400 Bad Request，报错信息类似invalid request format。
排查链路：
- 如果是JS宏，用
JSON.stringify构建请求体，一般不会出转义问题。反而是在手动拼接JSON字符串时最容易翻车。 - 如果是VBA方案，那堪称“转义地狱”。VBA字符串里表示引号要用两个连续双引号，一段简单的JSON在VBA里长这样：
"{""model"": ""deepseek-chat"", ""messages"": [{""role"": ""user"", ""content"": """ & userContent & """}]}"。一旦选中文本里本身带有英文双引号，拼出来的请求体就会支离破碎。 - 如果你还在VBA方案里挣扎，我的建议不是继续修复转义，而是直接跳到本文的JS宏方案。这是我踩完坑后的真实结论：与其和VBA的JSON转义缠斗，不如换个更合适的工具。
5.3 同步请求卡死与超时
现象：点击宏后WPS界面卡住，好几秒没反应，严重时弹出“未响应”。
原因：我在callDeepSeek里故意用了同步请求xhr.open("POST", url, false)，同步请求会阻塞WPS的主线程，等待期间界面就卡住了。如果DeepSeek接口响应时间较长，卡顿会非常明显。
我的解决办法：
- 设定
max_tokens值来控制单次输出长度，避免模型生成太长内容导致等待时间超标。 - 在宏入口加一个
MsgBox提示“已发送请求，请稍候”，虽然治标不治本，但至少让用户知道程序在工作。 - 如果追求体验，可以考虑改成异步请求，但异步模式下回调里操作文档对象要小心，WPS的JSA对象模型在回调中可能会失效。我实测下来，同步请求+合理限制输出长度，最稳。
5.4 中文乱码与编码不一致
现象：AI返回的结果插入文档后，中文变成乱码。
排查链路：
- 首先确认请求头里
Content-Type设的是application/json; charset=utf-8。虽然DeepSeek接口默认按UTF-8处理，但显式声明会更稳妥。 - 用
MsgBox打印一次callDeepSeek的返回值，确认接口本身返回的文本是否正常。如果返回正常但插入文档乱码，多半是WPS文档本身编码和结果不一致。 - 检查是否在宏里使用了
WScript.Shell之类的对象接收输出，这类对象在JS宏里往往默认按系统编码解释，会把UTF-8中文搞乱。直接使用XMLHttpRequest.responseText，通常不会乱码。
5.5 替换文本后格式丢失
现象：选中一段带加粗和颜色的文字，运行润色宏后，文字内容变了，但字体、颜色、大小全没了。
这是sel.Text = result这个操作的后遗症：它把整个选区的文本节点替换掉了，原来的字符格式也一并被冲掉。
我的解决思路有两个：
- 先记录选中范围的格式，再用新内容替换后重新设置格式。麻烦在于格式可能很复杂，涉及字体名、字号、加粗、斜体、颜色、高亮，全量恢复不现实。
- 更实用的做法是：把AI结果“插入”到选中文本后面，保留原文，让用户自己看过之后再删除旧文本。虽然多了个手动步骤，但至少不会破坏格式。
现在我的润色宏默认改成“插入结果到段落末尾，并标注【AI润色结果】”，用完确认无误再手工清理原文，稳当很多。
5.6 两个关联杂项：游客模式能用宏吗，MathType怎么不见了
有同学问WPS不登录能不能正常使用这些功能。我的实测结论是：基础的文字编辑、JS宏调用、本地保存都不受影响，不登录也能跑通DeepSeek接入方案。受影响的只是云文档同步、WPS AI这类在线能力。所以如果你因为各种原因不想登录WPS账号，这套DeepSeek方案反而是一条绕开官方AI限制、自己掌握主动权的路子。
另外，之前有人在装宏的时候发现“MathType不见了”。这个和接入DeepSeek没什么直接关系，但排查思路相似：在“开发工具→COM加载项”里看看MathType有没有被禁用；如果是64位WPS加载32位MathType插件，兼容性会有问题，需要装64位版本的MathType。顺带说一句，如果你折腾过“安装了某个插件后另一批插件不显示”，大概率都是加载项启用状态的问题，去COM加载项里重新勾选就能恢复。
6. 把宏升级成顺手好用的AI工具条
6.1 绑定快捷键与工具栏入口
宏写好之后，每次从“开发工具→JS宏”里找它运行，效率还是低。我会给每个高频宏绑定快捷键：在JS宏列表里选中宏，点右侧“选项”，输入快捷键组合。我的配置是：
Ctrl+Alt+P：润色选中文本Ctrl+Alt+T：翻译选中文本Ctrl+Alt+S：生成摘要
习惯了之后，整个操作流程就是一气呵成的：选中文字，按组合键，等待1秒，结果直接在文档里。
另一个办法是把宏添加到快速访问工具栏。在Word/WPS右上角快速访问工具栏的自定义区域，选择“更多命令”，找到“宏”分类，添加对应宏。这样在WPS界面就能点按钮调用，适合不太记快捷键的人。
6.2 请求参数调优与长文本分段策略
DeepSeek接口还支持一些参数，针对不同场景我会调整：
| 参数 | 润色 | 翻译 | 摘要 |
|---|---|---|---|
| temperature | 0.3 | 0.2 | 0.2 |
| max_tokens | 1024 | 2048 | 1024 |
| 单次输入上限 | 3000字 | 2000字 | 6000字 |
temperature控制输出随机性，润色和翻译要求语义精准，越低越好；创意写作才需要调高。max_tokens控制生成长度，太长会增加等待时间。
关于长文本，我不建议一次性让AI处理超过6000字。原因：一是接口对上下文的限制主要体现在总量上；二是单次输出太长时，模型后半段质量会下降。我的做法是写一个简单的分段函数，按段落数平均等分，每段不超过4000字，然后循环调用。
6.3 API Key管理与数据安全建议
API Key硬编码在宏里虽然方便，但有风险。我见过有人把带Key的WPS模板文件直接发给同事，Key秒泄露。几个实用的管理方式：
- 把Key放在系统环境变量里，宏代码里用
System.Environment.GetEnvironmentVariable("DEEPSEEK_API_KEY")读取。不过WPS JS宏对这个的支持不太稳定，我实测是在本机测试可行，但换机器可能读不到。 - 放在本地单独的配置文件里，宏里读取该文件内容。这样模板文件本身不包含Key，就算发出去也不会泄露。
- 公司内网强隔离环境，建议走本地部署方案。
数据安全上，再次强调：如果文档内容敏感，请使用本地部署DeepSeek；云端API虽然不会把数据用于训练，但数据经过第三方服务器是客观事实。我自己的原则是：一般工作文档走云端，涉及合同、人事、未公开数据走本地。
6.4 带重试与错误提示的最终版代码
综合前面的经验，我最终的宏模板长这样：
var DEEPSEEK_API_KEY = "你的API_Key"; function callDeepSeek(promptText, maxTokens) { var maxRetry = 3; for (var attempt = 1; attempt <= maxRetry; attempt++) { try { var xhr = new XMLHttpRequest(); xhr.open("POST", "https://api.deepseek.com/chat/completions", false); xhr.setRequestHeader("Content-Type", "application/json; charset=utf-8"); xhr.setRequestHeader("Authorization", "Bearer " + DEEPSEEK_API_KEY); var payload = JSON.stringify({ model: "deepseek-chat", messages: [{ role: "user", content: promptText }], max_tokens: maxTokens ? maxTokens : 1024, temperature: 0.3, stream: false }); xhr.send(payload); if (xhr.status === 200) { var resp = JSON.parse(xhr.responseText); return resp.choices[0].message.content; } else if (xhr.status >= 500) { // 服务端错误，稍后重试 Utilities.sleep(1000 * attempt); continue; } else { return "请求失败（HTTP " + xhr.status + "）：" + xhr.responseText; } } catch (e) { return "异常：" + e.message; } } return "重试多次仍失败，请检查网络或稍后再试。"; } function DeepSeekPolishSelection() { var sel = Application.Selection; var selectedText = sel.Text; if (!selectedText || selectedText.length === 0) { MsgBox("请先选中需要润色的文本。"); return; } var prompt = "请对下面的文本进行润色，保持原意，不改变事实，语言书面流畅：\n" + selectedText; var result = callDeepSeek(prompt, 1024); // 输出到新段落，避免破坏原格式 var insertRange = Application.ActiveDocument.Content; insertRange.InsertAfter("\n\n【AI润色】\n" + result); MsgBox("已完成，请手动核对并整理格式。"); }这个版本加了重试机制、错误提示，以及“插入而非覆盖”的格式保护策略，日常使用已经比较省心。
最后再分享一点个人体会：把DeepSeek接入WPS，本质上不是“给WPS加一个功能”，而是把AI变成文字工作流的一部分。最开始我总想着一步到位，写了很多自动批处理宏，结果发现维护成本比手工操作还高。后来收敛成几个最核心的场景宏，天天用，越用越顺手。建议你从润色这一个宏开始，用顺了再逐步加翻译、摘要、表格辅助。技术是为工作服务的，能用起来、能节省时间，才是这件事最大的价值。
