本文给出DeepSeek接入Word的完整路径，覆盖账号准备、VBA宏、Office加载项、密钥安全与费用控制，适合个人与团队落地。 把DeepSeek接入Word，核心不是寻找唯一官方插件，而是根据使用场景选择扩展。个人快速验证可从VBA宏入手，团队协作更适合Office.js加载项，而真正决定能否长期运行的是密钥管理、费用边界和错误处理。下面按准备、实现、扩展、治理四个层面展开。
1. 接入前的账号、密钥与Word环境准备
在正式写宏或做加载项之前，需要先把DeepSeek侧和Word侧的变量固定下来。DeepSeek开放平台提供与OpenAI兼容的Chat Completions接口，基础地址通常写作，聊天补全路径为/chat/completions，也兼容/v1/chat/completions。到platform.deepseek.com注册并完成充值后，在API Keys页面创建密钥，密钥只显示一次，通常以sk-开头。模型名常用deepseek-chat和deepseek-reasoner，前者适合润色、翻译、摘要、续写，后者适合长链推理、合同条款对比和复杂审校。Word端建议使用Microsoft 365桌面版或Word 2019、2021，Windows环境对VBA和WinHTTP支持最完整；Mac Word的VBA对WinHTTP支持有限，通常需要改用Office.js或外部脚本。还要确认网络能访问api.deepseek.com，公司代理要放行443端口，否则会在发送请求阶段报错。
准备JSON解析库和测试素材同样重要。VBA原生不解析JSON，可引入VBA-JSON的JsonConverter.bas，并在VBA编辑器“工具-引用”中勾选Microsoft Scripting Runtime，32位和64位Office要注意声明语句兼容性。若不想引入库，也可以用Mid和InStr粗暴截取content，但遇到转义换行、Unicode和嵌套JSON时容易出错。准备一段200到500字的测试文本，包含中英文、标点和换行，用来验证请求转义、返回插入和错误提示。密钥不要直接写在宏里，可以先用Windows环境变量DEEPSEEK_API_KEY保存，VBA通过Environ读取；在共享文档中尤其要避免把密钥留在Normal.dotm或文档属性中。费用方面，DeepSeek按输入与输出token计费，缓存命中价格更低，测试时先用短文本和deepseek-chat，避免一上来就用reasoner消耗大量输出token。
2. 用VBA宏把DeepSeek嵌入Word正文操作
VBA宏是最轻量的接入，适合个人在Word里选中文字后直接调用DeepSeek。打开Word后按Alt+F11进入VBA编辑器，插入模块，创建一个Sub过程。核心逻辑是读取Selection.Text作为用户输入，用JsonConverter.ConvertToJson构造请求体，其中model设为deepseek-chat，messages数组包含system和user两条消息，system可写“你是Word文档助手，只返回处理后的正文”，user填入选中文本。随后用CreateObject创建WinHttp.WinHttpRequest.5.1对象，调用Open方法以POST请求，设置Content-Type为application/json，Authorization为Bearer加空格再加API密钥，最后Send发送JSON字符串。若返回状态码200，用JsonConverter.ParseJson解析responseText，取json(“choices”)(1)(“message”)(“content”)，再通过Selection.TypeText或Selection.Range.Text把结果写回文档。
为了让宏更实用，可以把提示词做成可切换模式。例如润色模式要求“不改变原意，直接返回润色后的文字”，翻译模式要求“译为英文并保留术语”，审校模式要求“列出事实错误和表达问题”。选中一段文字后按Alt+F8运行宏，结果可插入光标处，也可用Selection.Comments.Add为原文添加批注，这样法务或编辑能对照修改。还可以把宏添加到快速访问工具栏，形成近似按钮的体验。错误处理不能省略，On Error GoTo捕获异常后，根据Status区分401密钥错误、402余额不足、429请求过快和超时。WinHttpRequest支持SetTimeouts设置解析、连接、发送和接收超时，建议接收超时设为30000到60000毫秒。流式响应在VBA里处理复杂，日常使用保持stream为false更稳定。64位Office中若使用API声明，要加PtrSafe，避免编译报错。
3. 基于Office.js加载项构建任务窗格助手
当多人需要共用同一套Word助手时，Office.js加载项比VBA宏更适合分发。加载项本质是一个HTTPS网页，通过manifest.xml告诉Word在哪里加载任务窗格，以及需要哪些权限。开发时可用Yeoman的office-addin-taskpane模板生成项目，前端在Word.run中读取当前选区，例如context.document.getSelection.load(“text”)，同步后拿到文本，再调用后端接口。这里不建议前端直接请求DeepSeek，因为API密钥会暴露在浏览器或加载项代码中，而且跨域策略可能阻止请求。更稳妥的做法是搭一个Node.js、Express或Serverless函数作为代理，把DeepSeek密钥放在服务端环境变量或密钥管理服务里，前端只请求自己的后端路由。
任务窗格可以设计成“润色、翻译、摘要、审校、续写”几个按钮，也可以提供自定义指令输入框。用户点击后，前端把选区文本和指令发给代理，代理组装DeepSeek请求并返回内容，前端再用range.insertText或range.replace插入文档。manifest中的AppDomains要包含代理域名，Permissions至少设为ReadWriteDocument，SourceLocation必须是HTTPS地址。调试阶段可在Word的“插入-获取加载项-上传我的加载项”中侧载，企业则可通过Microsoft 365管理中心集中部署。一个实际案例是咨询团队把所有项目模板放入加载项，统一要求DeepSeek按公司术语表输出，减少每个人各自写提示词造成的风格漂移。加载项版本更新后，用户重新打开Word即可加载新资源，比逐个替换VBA宏更省事。
4. 密钥安全、费用控制与错误处理策略
密钥安全是DeepSeek接入Word后最容易出问题的环节。VBA宏中硬编码密钥，一旦文档或模板被同事复制，密钥就会泄露；Office加载项若把密钥写进前端JS，同样会被抓包看到。可行做法是VBA从Windows环境变量读取，例如Environ(“DEEPSEEK_API_KEY”)，加载项则通过后端代理调用，后端使用Azure Key Vault、AWS Secrets Manager或服务器环境变量保存密钥。日志只记录请求时间、模型名、token数量和状态码，不要记录文档正文，避免敏感合同、人事材料进入日志系统。企业还应确认DeepSeek API的数据处理条款，判断输入内容是否会被用于服务改进，必要时对敏感文档改用本地模型或私有化部署方案。
费用控制要在请求构造阶段完成。DeepSeek按输入和输出token计费，deepseek-chat适合大多数文档任务，deepseek-reasoner输出成本更高，应留给复杂推理。每次只发送选中的段落或章节，不要默认发送全文；设置max_tokens限制输出长度，temperature控制在0.3到0.7之间，减少无意义扩写。遇到429限流时采用指数退避，等待1秒、2秒、4秒再重试，连续失败则提示用户稍后再试。401通常说明密钥错误，402可能涉及余额，超时则检查代理和DNS。对高频使用的团队，应把提示词、模型名、超时和最大输出token固化到配置中，并在DeepSeek官方文档更新后先在小范围文档测试，再推送全员使用。
