尧图网页设计 
简介面向需要提升办公效率的职场人士及希望尝试AI辅助写作的个人用户这份PDF教程系统讲解了在Word和WPS中接入DeepSeek R1的完整过程。资源为单文件PDF压缩包大小约976KB内容紧凑精炼整体结构完整适合下载后随时查阅。教程首先介绍DeepSeek官网注册、进入API开放平台、创建并命名API密钥的详细流程同时强调保存好密钥、避免泄露等重要安全细节随后分别演示Word接入的配置步骤以及WPS中启用开发工具、切换到VB环境、安装插件、重启应用、打开宏编辑器等完整操作并针对插件安装提示、重启生效等常见问题给出对应解决办法。目前已有1042人学习下载适合刚接触AI办公集成、希望快速完成DeepSeek服务配置并在文档创作中调用智能编辑功能的读者对照操作。整个过程无需编程基础按步骤即可完成接入。1. 办公自动化里接 DeepSeek R1先让 Word 和 WPS 变成 AI 的“编辑器”我见过太多人为了“办公自动化”去买各种 AI 插件结果插件升级一次公司几百份模板全变乱码售后只会让你“重装试试”。这两年我一直在用一条更干净的路不装任何插件在 Word 和 WPS 里直接用宏调用 DeepSeek R1 的 API让选中文字、表格数据甚至公式图片都能当场交给模型处理再把结果写回文档。这个方案解决的是办公自动化里最扎手的“最后一公里”——AI 能生成内容但生成的东西进不了 .docx、对不上表格格式、公式还带一堆 LaTeX 符号。适合谁IT 支持、财务、行政、还有天天做标书和制度文档的人。反直觉的是绕开插件直接调 API反而更省心、更可控、更持久。2. 选型与接入管线为什么用“宏 DeepSeek R1 API”以及 3 个先定好的参数2.1 为什么是宏 API而不是现成的 AI 插件办公自动化接入 AI 常见有三条路装现成插件、用独立客户端、自己写宏调 API。我为什么坚持第三条插件是个黑匣子它适配了哪些模型、模型版本什么时候换、你的文档内容会被送到哪里去你都看不见。大模型 API 的每一次请求都能留下日志审计时拿得出记录插件只能给你一句“该问题已反馈”。另一个问题是格式兼容。Word 和 WPS 的文档结构差别很微妙插件通常只针对其中一个优化另一个就成了后妈养的。宏 API 的好处是只要你会写几行 VBA 或者 WPS 的 JS 宏就能让模型能力长在你的业务流里。比如公司有标准的合同模板你可以在宏里把模板段落拼进 Prompt让 DeepSeek R1 生成的摘要直接带着公司条款编号这在插件里要折腾好久。DeepSeek R1 的定位是推理增强模型它会先输出一段“思考过程”再给结论所以它特别适合写公式、做逻辑推导、清洗结构化文本这类需要动脑子的任务反过来如果你只是让 AI 随便聊聊天、写个朋友圈文案R1 的思考过程反而拖慢响应。接入前先想清楚文档自动化里的哪一环是真正需要“推理”的哪一环只是模板填空后者用轻量模型更划算别让 R1 干它不适合的活。2.2 接入前先把 3 个参数想清楚模型、temperature、max_tokens我一般会把下面这张表贴在项目文档第一页每次调试出问题先回来看它。参数建议取值说明modeldeepseek-reasoner 这类推理模型名以官方控制台列出的模型名为准不同时期模型标识会调整temperature公式、代码、合同条款类写 0.1~0.3润色文案、翻译写 0.7 左右R1 本身定位是推理模型温度调太高容易在一本正经的推导里掺幻觉max_tokens直接给 8192R1 的“思考链”会先吃掉大量 token默认值偏小长文档必被截断base_url 以官方开发者文档为准常见的入口是https://api.deepseek.com/v1/chat/completions鉴权方式用Authorization: Bearer 你的key。key 千万别直接写在代码里尤其是 Word 宏要分发给同事时key 写死在 .bas 文件里等于公开。我建议把 key 放到配置文件里宏启动时用Environ(DEEPSEEK_API_KEY)读环境变量或者做成用户窗体的输入框只在当前会话里保存。另外要留意正文里热词常提到的场景——Word 公式转 LaTeX、公式图片转 Word——这类需求对温度非常敏感公式不是创作是解码温度一旦高了括号匹配就出幻觉。2.3 通用接入管线从选中一段文字到拿到 model 的回答接入管线其实只有四步取文档内容、拼 Prompt、发 HTTP 请求、解析 JSON 回填文档。VBA 里没有内置的 JSON 库这是大部分人在第一步就翻车的地方。下面这段代码是我常用的最小骨架VBA 里负责三件事转义 Prompt、发请求、从响应里取出content字段。Function JsonEscape(s As String) As String JsonEscape Replace(s, \, \\) JsonEscape Replace(JsonEscape, , \) JsonEscape Replace(JsonEscape, vbCrLf, \n) JsonEscape Replace(JsonEscape, vbLf, \n) End Function Function DeepSeekChat(prompt As String, apiKey As String) As String Dim http As Object Dim body As String Set http CreateObject(MSXML2.XMLHTTP) body {model:deepseek-reasoner, _ messages:[{role:user,content: _ JsonEscape(prompt) }], _ temperature:0.3, _ max_tokens:8192} 官方兼容 OpenAI 的 chat/completions 格式 http.Open POST, https://api.deepseek.com/v1/chat/completions, False http.SetRequestHeader Content-Type, application/json; charsetutf-8 http.SetRequestHeader Authorization, Bearer apiKey http.Send body If http.Status 200 Then DeepSeekChat [HTTP http.Status ] http.responseText Exit Function End If DeepSeekChat ExtractContent(http.responseText) End Function代码的逻辑很简单先把用户传进来的文本转义成 JSON 字符串避免换行和引号破坏请求体然后用MSXML2.XMLHTTP发起同步 POST请求体里指定模型、消息列表和两个关键参数。注意这里选MSXML2.XMLHTTP而不是WinHttp.WinHttpRequest.5.1是因为后者的响应文本默认按 ASCII 解码中文响应大概率乱码这点在第 5 章还会细说。ExtractContent函数负责从响应里抠出真正的回答。R1 的响应里同时有reasoning_content和content前者是思维链不应该直接展示给最终用户而message结构里content是最后的字段所以用InStrRev从后往前找最保险。Function ExtractContent(resp As String) As String Dim cP As Long, sP As Long, eP As Long, t As String R1 返回里最后出现的 content 就是模型正式回答 cP InStrRev(resp, content, -1, vbBinaryCompare) If cP 0 Then Exit Function content 值前有一个引号向后找值结束的引号 sP InStr(cP Len(content), resp, , vbBinaryCompare) eP InStr(sP 1, resp, , vbBinaryCompare) If sP 0 Or eP 0 Then Exit Function t Mid(resp, sP 1, eP - sP - 1) t Replace(Replace(t, \\n, vbLf), \\r\\n, vbCrLf) t Replace(t, \, ) t Replace(t, \\, \) ExtractContent t End Function这段代码的思路是InStrRev找到最后一个content键的位置再从这个位置向后找第一个引号作为内容起点再找下一个引号作为终点。因为 JSON 里的换行已经是\n转义形式所以文本里不会出现裸引号截取是可靠的。眼神尖的读者会发现Replace的顺序有讲究先把\\换回去否则会把本来应该保留的反斜杠也吞掉。我在实际项目里见过不少人栽在这里——把\\n直接替换成换行后LaTeX 里的\frac全变成了裸frac。3. 在 Word 里落地选中文字生成正文、清洗粘贴文本和公式图片转 LaTeX3.1 最常用的“选中即处理”润色、翻译、摘要一气呵成用户对办公自动化最大的诉求不是“帮我写整篇”而是“我选中这一段你帮我改”。Word 宏里这个操作对应Selection.Range。下面这个宏会把选中的文字发给 DeepSeek R1然后把结果直接插入到光标位置原文保留在下方作为对照。Sub DeepSeekR1_Selection() Dim apiKey As String, prompt As String Dim selectedText As String, result As String apiKey Environ(DEEPSEEK_API_KEY) If apiKey Then MsgBox 先设置环境变量 DEEPSEEK_API_KEY, vbExclamation Exit Sub End If If Selection.Type wdSelectionNormal Then selectedText Selection.Range.Text Else selectedText ActiveDocument.Content.Text End If prompt 请对下面这段文本做技术文档风格的润色 _ 保留原有术语不要改变事实信息。 vbCrLf vbCrLf selectedText 请求可能较慢先给用户一个状态提示 StatusBar.Text DeepSeek R1 处理中…… DoEvents result DeepSeekChat(prompt, apiKey) StatusBar.Text 插入到当前光标位置原文自动下移成对照 Selection.TypeParagraph Selection.TypeText result End Sub这个宏的设计有几个细节。第一Selection.Type判定了当前是不是选中了正常文本如果什么都没选就退回处理整篇文档防止用户误操作后没有任何反馈。第二发送前先把状态栏提示刷出来DoEvents让界面先响应否则用户看到 Word 卡死会直接强杀进程。第三结果插入用的是Selection.TypeText它会跟随当前段落样式而不是凭空创建一堆自动格式。如果你希望结果保留原文格式可以用Selection.Range.FormattedText ...的方式回填但我个人习惯让 AI 输出保持正文格式后续再统一排。3.2 把 AI 返回的 Markdown 转成 Word 原生正文而不是一堆 # 号很多人的实际痛点不是“调不通 API”而是“AI 输出的 Markdown 没法直接用”。DeepSeek R1 很喜欢用 Markdown 组织回答标题用##列表用-。直接粘贴进 Word 就是灾难。热词里就有人搜“markdown 转 word 工作流 coze”想用 no-code 工作流绕一圈。其实这步在 Word 宏里几行代码就能搞定按行读取识别前缀落到 Word 内置样式。Sub PasteAsMarkdownText(txt As String) Dim lines As Variant, line As Variant Dim level As Integer, clean As String lines Split(txt, vbLf) For Each line In lines If Left(Trim(line), 1) # Then 连续 # 的数量就是标题层级 level 0 Do While Mid(line, level 1, 1) # And level 4 level level 1 Loop clean Trim(Mid(line, level 1)) Selection.Style ActiveDocument.Styles(标题 level) Selection.TypeText clean ElseIf Left(Trim(line), 1) - Then 无序列表统一落到列出段落样式 clean Trim(Mid(line, 2)) Selection.Style ActiveDocument.Styles(列出段落) Selection.TypeText clean ElseIf Trim(line) Then Selection.TypeParagraph Else Selection.Style ActiveDocument.Styles(正文) Selection.TypeText Trim(line) End If Selection.TypeParagraph Next line 表格行以 | 开头建议单独交给 Word 表格生成逻辑见 6.2 End Sub这里的核心是不自己画格式而是映射到 Word 的“样式”体系。用ActiveDocument.Styles(标题 1)而不是手动改字号加粗好处是后续生成目录、调整公司模板字体只要改样式全文自动跟着变。这个习惯是多年的血泪经验——我在早期会让代码直接设置Selection.Font.Size等模板调整时整篇文档格式全乱。列表部分也是同理用“列出段落”而不是手动加项目符号避免缩进层级错乱。如果你处理的 AI 输出里还有 Markdown 表格那就不能用行处理了得单独做表格切分这部分在最后一章讲。3.3 公式图片转 WordR1 在公式 LaTeX 上的正确打开方式热词里“公式图片转 word”和“word 公式转 latex”出现频率相当高翻译一下就是PDF 或网页里的公式是图片想让它们变成 Word 里可编辑的公式。DeepSeek R1 本身是文本模型不能直接看图。我常用的落地路径是先用 OCR 工具把公式图片识别成 LaTeX再把 LaTeX 交给 R1 做“清洗”——因为 OCR 出来的 LaTeX 经常有括号不匹配、把\alpha识别成a的问题R1 很擅长把这段乱糟糟的 LaTeX 修正成规范形式。Function CleanLatex(rawLatex As String, apiKey As String) As String Dim prompt As String prompt 你是一名 LaTeX 校对专家。下面这段 OCR 识别出的 LaTeX _ 可能有括号不匹配、命令拼写错误。请只输出修正后的 LaTeX _ 不要加任何解释不要加 Markdown 代码块。公式如下 _ vbCrLf vbCrLf rawLatex CleanLatex DeepSeekChat(prompt, apiKey) End Function注意 Prompt 里专门强调了“不要加任何解释不要加 Markdown 代码块”。R1 的推理模型特性决定了它很喜欢先“演算”一番再给结论但在公式清洗这个场景你需要的是纯结果。加了这句之后输出里就不会出现latex的围栏省掉一层后处理。清洗完的 LaTeX 可以直接存到 Word 里的文本框里也可以在第 6 章的方法中进一步转成 Word 原生公式 OMML。如果电脑里装了 MathType 或者其它公式工具R1 返回的 LaTeX 也能直接被它们识别粘贴但我不建议把业务依赖绑死在公式编辑器上因为同事电脑上不一定装了对应的软件。4. WPS 里接入VBA 组件与 JS 宏的差异以及表格批量清洗写法4.1 先分清WPS 的 VBA 组件和内置 JS 宏怎么选WPS 接入 DeepSeek R1 比 Word 多一个前置决策用 VBA 还是用 JS 宏。WPS 个人版默认不带 VBA 组件需要单独安装这也是“wps vba 组件”和“vba 插件 7.1 支持 wps”这类热词存在的背景。如果你的公司电脑不允许安装第三方组件或者装了之后被安全策略拦下那就走 WPS 内置的 JS 宏——在“开发工具”里切换到 JS 环境不需要额外装任何东西。我的选择逻辑是这样的如果团队里已经有一批跑在 Word 上的 VBA 宏且能装 WPS 的 VBA 组件那迁移成本最低因为大部分对象模型通用如果是从零开始、或者要发给外部单位用坚决选 JS 宏少一个安装依赖就少一次“到现场发现装不上”的售后。WPS 的 JS 宏语法是标准 JavaScript 风格调用方式和浏览器里的 XHR 几乎一样。这里最大的坑是WPS 对 VBA 的兼容不是 100%某些 Word 宏里的ActiveDocument.Styles在 WPS 里拿不到同名枚举需要先跑一段探测代码看看对象模型支持到哪一层。4.2 WPS 文字调 DeepSeek 的 JS 宏样板取全文、发请求、写回WPS 的 JS 宏接入 API 的骨架比 VBA 更简洁因为 JavaScript 天生就有JSON对象不用手写解析。下面这段是 WPS 文字里用的最小样板。function DeepSeekR1_Insert() { var apiKey WPS.Env.GetEnvironmentVariable ? WPS.Env.GetEnvironmentVariable(DEEPSEEK_API_KEY) : ; // 取当前文档内容想只处理选中区改成 Selection 相关接口 var docText ActiveDocument.Content.Text; if (docText.length 6000) { docText docText.substring(0, 6000); } var body { model: deepseek-reasoner, messages: [{ role: user, content: 请把下面内容改成中文公告风格\n docText }], temperature: 0.3, max_tokens: 8192 }; var xhr new XMLHttpRequest(); xhr.open(POST, https://api.deepseek.com/v1/chat/completions, false); xhr.setRequestHeader(Content-Type, application/json; charsetutf-8); xhr.setRequestHeader(Authorization, Bearer apiKey); xhr.send(JSON.stringify(body)); var resp JSON.parse(xhr.responseText); var result resp.choices[0].message.content; // 在文档末尾插入后面补两个空行隔开原文 ActiveDocument.Content.InsertAfter(\n\n result); }这段代码里有几个值得注意的取舍。第一我加了 6000 字符的截断保护因为长文档直接进 Prompt 会放大 token 消耗R1 的思维链还会再吃一部分全文动不动几万字很危险实际接业务时我都是先做段落切分再逐段调用。第二XMLHttpRequest在 WPS 的 JS 宏环境里能用但不同版本行为有差异遇到没有此对象的环境就退回 WPS 提供的网络接口。第三代码里用了WPS.Env.GetEnvironmentVariable如果当前环境不支持就改成弹窗输入 key。WPS 的对象模型在不同大版本之间差异明显写宏时先console.log(typeof ActiveDocument)探一下能省下大量排查时间。4.3 WPS 表格批量清洗把一列数据交给 R1结果回填邻列办公自动化里最高频的场景其实是表格拿到一列客户地址、一列错误格式的手机号、一列横跨三行的公司名想标准化但又不敢用正则硬写。WPS 表格的 JS 宏很适合做这个。下面这个例子读取 A1:A50拼成一个请求发给 DeepSeek R1要求它按行返回标准化结果再写到 B 列。function CleanRows() { var sheet ActiveSheet; var rows 50; var inputLines []; for (var i 1; i rows; i) { var cellValue sheet.Range(A i).Value2; if (cellValue ! cellValue ! null) { inputLines.push(i : cellValue); } } var prompt 下面每一行是序号: 原值请你对每个原值做标准化统一全半角、修正明显错别字保持序号不变。只输出序号: 结果每行一条不要解释\n inputLines.join(\n); var body { model: deepseek-reasoner, messages: [{ role: user, content: prompt }], temperature: 0.1, max_tokens: 8192 }; var xhr new XMLHttpRequest(); xhr.open(POST, https://api.deepseek.com/v1/chat/completions, false); xhr.setRequestHeader(Content-Type, application/json; charsetutf-8); xhr.setRequestHeader(Authorization, Bearer WPS.Env.GetEnvironmentVariable(DEEPSEEK_API_KEY)); xhr.send(JSON.stringify(body)); var resp JSON.parse(xhr.responseText); var outputLines resp.choices[0].message.content.split(\n); for (var j 0; j outputLines.length; j) { var parts outputLines[j].split(:); if (parts.length 2) { var rowIdx parseInt(parts[0], 10); var cleanVal parts.slice(1).join(:).trim(); sheet.Range(B rowIdx).Value2 cleanVal; } } }合批请求是这里的核心思路。把 50 行数据拼到一个请求里远比循环 50 次调用 API 省钱省时间而且 R1 能看到上下文能根据同一列的其它行推断你想要的统一格式。但这带来一个新问题R1 输出偶尔会比输入少几行或者某行结果里带了冒号导致切分错位。所以我让每行输入都带“序号”输出也要求带“序号”回填时按序号定位而不是按顺序硬填。如果你只是拿split(:)取第一段遇到公司名“XX:上海事业部”这种带冒号的字段就会翻车代码里用parts.slice(1).join(:)把剩余部分拼回去就是专门应对这个的。5. 接入 DeepSeek R1 的 5 个常见坑乱码、截断、JSON 解析失败和假死5.1 现象返回的中文全乱码或者干脆是空字符串用WinHttp.WinHttpRequest.5.1发请求时最容易出现这种问题。原因很简单这个对象把响应体按单字节字符集解码中文 UTF-8 的字节被拆成一个一个拉丁字符自然全是乱码。解决方法是换用MSXML2.XMLHTTP如果必须保留 WinHttp就手动用 ADODB.Stream 把responseBody按 UTF-8 解码。Dim stream As Object Set stream CreateObject(ADODB.Stream) stream.Type 1 二进制 stream.Open stream.Write http.responseBody stream.Position 0 stream.Type 2 文本 stream.Charset utf-8 resp stream.ReadText stream.Close这段代码在 VBA 里是通用的“强制按 UTF-8 解码”办法。注意stream.Type先设 1 再设 2顺序不能反先以二进制拿到原始字节再切到文本模式并按指定字符集解码。如果你发现 MSXML2 在某个老系统上也不能用检查一下系统是否缺少对应的 MSXML 运行库补装后重启 Office 即可这属于玄学之外的确定性故障。5.2 现象R1 答到一半就断长文总是结尾丢失R1 的响应里带reasoning_content模型要先“思考”一大段才输出正式内容。如果你没设max_tokens默认值往往不够思考链加正文一起用于是响应被截断正文刚开头就戛然而止。另一个表现是短问题正常长文档处理必定丢尾巴。解决方法是把max_tokens显式调到 8192同时检查 API 控制台里的“上下文长度”配额别让累计 tokens 超限。如果任务真的很长——比如要处理整本合同——就不要一个 Prompt 硬撑先切成段落逐个请求最后拼装。我的习惯是段落长度控制在 2000 字以内这样 R1 的推理深度和响应速度都处于甜点区。5.3 现象JSON 解析总失败浏览器里复制却正常VBA 里最常见的翻车现场同一个响应放到 Postman 或浏览器控制台里JSON.parse正常VBA 里一解析就报错。原因有两个方向。第一R1 的content里可能带了 Markdown 代码围栏即使你只在 JSON 层面看是合法的某些手写解析器会把它当成异常结构。第二VBA 的ScriptControl组件在 64 位 Office 里根本加载不了很多人以为代码写错了其实是组件缺失。我的做法是响应文本先做一次清理把json和尾部的删掉再用InStrRev截取最后出现的content字段而不是引入第三方 JSON 库。R1 响应里content字段一定在reasoning_content之后取最后一个content是可靠的。如果是 JS 宏环境直接用JSON.parse就行但同样要先做代码围栏清理。5.4 现象一运行宏 Word/WPS 就“未响应”这是因为 VBA 里的XMLHTTP同步请求会卡死 UI 线程R1 推理速度又比普通模型慢一个请求动辄十几秒期间用户不能做任何操作Windows 就会弹“未响应”。解决思路有两层。第一层是在宏里加过程反馈请求前设置StatusBar.Text调用DoEvents刷新界面让用户知道程序还活着。第二层是拆任务如果是批量处理一次少发几行数据如果公司上了 R1 的异步 API就把请求放到后台用回调机制回填文档。WPS JS 宏里如果环境支持把xhr.open的第三个参数改成true用onreadystatechange回调界面就不会假死VBA 里没有原生异步换一种做法——弹一个无模式窗体显示“处理中”不要让宏一口气跑到底。5.5 现象这台电脑能跑换一台就报 400 或“ActiveX 部件不能创建”宏分发到别的电脑上时最常见的三个原因第一目标机器没装 WPS 的 VBA 组件或 Office 是 64 位而代码里用了ScriptControl第二API key 还嵌在旧代码里换机后环境变量不存在第三Word 的宏安全性设置把宏给禁了调用时直接静默失败。解决方法是宏启动时先做环境探测——CreateObject包一层错误处理失败就弹窗提示具体缺什么key 改由环境变量或用户窗体输入不要写死在代码里不要在宏代码里写“禁用宏安全检查”之类的绕过逻辑正确做法是让 IT 在组策略里对已签名的宏放行。我曾经因为图省事在公共模板里硬编码了一个测试 key结果换了两台电脑全部报 401排查了半天才发现是 key 的问题从那以后我再也不把 key 写进宏文件。6. 进阶让 R1 的输出真正“长在” Word/WPS 里并做一次自检6.1 把 LaTeX 公式转成 Word 原生公式OMML而不是文本第 3.3 节里清洗好的 LaTeX如果只作为字符串粘贴等于让公式失去了可编辑性。Word 的原生公式格式是 OMML想让 LaTeX 变成 OMML常见做法是借道 pandoc把 R1 返回的 LaTeX 包进一个最小 Markdown 文件执行pandoc in.md -o out.docx --mathml再用 Word 打开或把生成的段落复制过来。宏里可以用Shell调用这条命令。pandoc tmp.md -o output.docx --mathml注意--mathml参数才会让公式以 Word 可识别的 OMML 落盘。这个方案的优势是不依赖 MathType也不用装公式编辑插件只要一台机器有 pandoc公式就是原生可编辑的。在 VBA 里调用时先ChDir到工作目录处理完再用Documents.Open打开生成的文件。批量的公式图片转 Word 场景我会让 R1 一次性输出多条 LaTeX每条前面加$$公式编号$$标记pandoc 会依次转成 Word 公式块的序列效率比一条条处理高很多。6.2 让 R1 按你的模板输出结构化 Prompt 与后处理脚本如果你希望 R1 每次返回的内容都能直接入档最好的办法不是靠运气而是在 Prompt 里约会法。我常用的模板是明确输出格式、明确分隔符、明确“不要输出任何额外解释”。比如做合同摘要时我会要求 R1 只返回下面这种结构【甲方】xxx 【乙方】xxx 【金额】xxx 【付款节点】1. 2. 3.后处理脚本再按“【标题】”正则切分填入 Word 表格或书签位置。这个做法把“模型输出”和“版面呈现”彻底解耦模型只负责产出结构化文本排版交给 Word 宏。比起让 R1 直接生成一份不靠谱的 Word 文档这种拆法让每一步都可测、可修、可审计。6.3 用 R1 自己的“慢思考”给结果加一道自检最后分享一个验证技巧对重要内容把 R1 的输出丢回给它做二次校验。不是简单问“对不对”而是让它再推导一遍“这份摘要里的金额和付款节点是否与原文一致如有不一致列出差异。”R1 的推理链会在这时真正起作用。如果两次结果矛盾我会人工介入。这套做法救过我一次有个周报自动汇总功能R1 第一次生成时把“下周一”理解成了“下周日”自检环节发现了日期偏移从那以后凡是带时间、金额、编号的输出我都会加一道自检。你不需要让它“反思”只要换一个角度描述同一个任务就能暴露大部分幻觉。接入 DeepSeek R1 到办公自动化的核心不是把 API 调通而是把模型输出驯化成文档体系里可用的内容。我这几年最大的教训是永远不要相信一次输出凡是进入正式文档的 AI 内容都要保留人工复核位。希望帮到你。本文还有配套的精品资源点击获取 用宏在Word和WPS中接入DeepSeek R1，打造可控的办公自动化流程
简介面向需要提升办公效率的职场人士及希望尝试AI辅助写作的个人用户这份PDF教程系统讲解了在Word和WPS中接入DeepSeek R1的完整过程。资源为单文件PDF压缩包大小约976KB内容紧凑精炼整体结构完整适合下载后随时查阅。教程首先介绍DeepSeek官网注册、进入API开放平台、创建并命名API密钥的详细流程同时强调保存好密钥、避免泄露等重要安全细节随后分别演示Word接入的配置步骤以及WPS中启用开发工具、切换到VB环境、安装插件、重启应用、打开宏编辑器等完整操作并针对插件安装提示、重启生效等常见问题给出对应解决办法。目前已有1042人学习下载适合刚接触AI办公集成、希望快速完成DeepSeek服务配置并在文档创作中调用智能编辑功能的读者对照操作。整个过程无需编程基础按步骤即可完成接入。1. 办公自动化里接 DeepSeek R1先让 Word 和 WPS 变成 AI 的“编辑器”我见过太多人为了“办公自动化”去买各种 AI 插件结果插件升级一次公司几百份模板全变乱码售后只会让你“重装试试”。这两年我一直在用一条更干净的路不装任何插件在 Word 和 WPS 里直接用宏调用 DeepSeek R1 的 API让选中文字、表格数据甚至公式图片都能当场交给模型处理再把结果写回文档。这个方案解决的是办公自动化里最扎手的“最后一公里”——AI 能生成内容但生成的东西进不了 .docx、对不上表格格式、公式还带一堆 LaTeX 符号。适合谁IT 支持、财务、行政、还有天天做标书和制度文档的人。反直觉的是绕开插件直接调 API反而更省心、更可控、更持久。2. 选型与接入管线为什么用“宏 DeepSeek R1 API”以及 3 个先定好的参数2.1 为什么是宏 API而不是现成的 AI 插件办公自动化接入 AI 常见有三条路装现成插件、用独立客户端、自己写宏调 API。我为什么坚持第三条插件是个黑匣子它适配了哪些模型、模型版本什么时候换、你的文档内容会被送到哪里去你都看不见。大模型 API 的每一次请求都能留下日志审计时拿得出记录插件只能给你一句“该问题已反馈”。另一个问题是格式兼容。Word 和 WPS 的文档结构差别很微妙插件通常只针对其中一个优化另一个就成了后妈养的。宏 API 的好处是只要你会写几行 VBA 或者 WPS 的 JS 宏就能让模型能力长在你的业务流里。比如公司有标准的合同模板你可以在宏里把模板段落拼进 Prompt让 DeepSeek R1 生成的摘要直接带着公司条款编号这在插件里要折腾好久。DeepSeek R1 的定位是推理增强模型它会先输出一段“思考过程”再给结论所以它特别适合写公式、做逻辑推导、清洗结构化文本这类需要动脑子的任务反过来如果你只是让 AI 随便聊聊天、写个朋友圈文案R1 的思考过程反而拖慢响应。接入前先想清楚文档自动化里的哪一环是真正需要“推理”的哪一环只是模板填空后者用轻量模型更划算别让 R1 干它不适合的活。2.2 接入前先把 3 个参数想清楚模型、temperature、max_tokens我一般会把下面这张表贴在项目文档第一页每次调试出问题先回来看它。参数建议取值说明modeldeepseek-reasoner 这类推理模型名以官方控制台列出的模型名为准不同时期模型标识会调整temperature公式、代码、合同条款类写 0.1~0.3润色文案、翻译写 0.7 左右R1 本身定位是推理模型温度调太高容易在一本正经的推导里掺幻觉max_tokens直接给 8192R1 的“思考链”会先吃掉大量 token默认值偏小长文档必被截断base_url 以官方开发者文档为准常见的入口是https://api.deepseek.com/v1/chat/completions鉴权方式用Authorization: Bearer 你的key。key 千万别直接写在代码里尤其是 Word 宏要分发给同事时key 写死在 .bas 文件里等于公开。我建议把 key 放到配置文件里宏启动时用Environ(DEEPSEEK_API_KEY)读环境变量或者做成用户窗体的输入框只在当前会话里保存。另外要留意正文里热词常提到的场景——Word 公式转 LaTeX、公式图片转 Word——这类需求对温度非常敏感公式不是创作是解码温度一旦高了括号匹配就出幻觉。2.3 通用接入管线从选中一段文字到拿到 model 的回答接入管线其实只有四步取文档内容、拼 Prompt、发 HTTP 请求、解析 JSON 回填文档。VBA 里没有内置的 JSON 库这是大部分人在第一步就翻车的地方。下面这段代码是我常用的最小骨架VBA 里负责三件事转义 Prompt、发请求、从响应里取出content字段。Function JsonEscape(s As String) As String JsonEscape Replace(s, \, \\) JsonEscape Replace(JsonEscape, , \) JsonEscape Replace(JsonEscape, vbCrLf, \n) JsonEscape Replace(JsonEscape, vbLf, \n) End Function Function DeepSeekChat(prompt As String, apiKey As String) As String Dim http As Object Dim body As String Set http CreateObject(MSXML2.XMLHTTP) body {model:deepseek-reasoner, _ messages:[{role:user,content: _ JsonEscape(prompt) }], _ temperature:0.3, _ max_tokens:8192} 官方兼容 OpenAI 的 chat/completions 格式 http.Open POST, https://api.deepseek.com/v1/chat/completions, False http.SetRequestHeader Content-Type, application/json; charsetutf-8 http.SetRequestHeader Authorization, Bearer apiKey http.Send body If http.Status 200 Then DeepSeekChat [HTTP http.Status ] http.responseText Exit Function End If DeepSeekChat ExtractContent(http.responseText) End Function代码的逻辑很简单先把用户传进来的文本转义成 JSON 字符串避免换行和引号破坏请求体然后用MSXML2.XMLHTTP发起同步 POST请求体里指定模型、消息列表和两个关键参数。注意这里选MSXML2.XMLHTTP而不是WinHttp.WinHttpRequest.5.1是因为后者的响应文本默认按 ASCII 解码中文响应大概率乱码这点在第 5 章还会细说。ExtractContent函数负责从响应里抠出真正的回答。R1 的响应里同时有reasoning_content和content前者是思维链不应该直接展示给最终用户而message结构里content是最后的字段所以用InStrRev从后往前找最保险。Function ExtractContent(resp As String) As String Dim cP As Long, sP As Long, eP As Long, t As String R1 返回里最后出现的 content 就是模型正式回答 cP InStrRev(resp, content, -1, vbBinaryCompare) If cP 0 Then Exit Function content 值前有一个引号向后找值结束的引号 sP InStr(cP Len(content), resp, , vbBinaryCompare) eP InStr(sP 1, resp, , vbBinaryCompare) If sP 0 Or eP 0 Then Exit Function t Mid(resp, sP 1, eP - sP - 1) t Replace(Replace(t, \\n, vbLf), \\r\\n, vbCrLf) t Replace(t, \, ) t Replace(t, \\, \) ExtractContent t End Function这段代码的思路是InStrRev找到最后一个content键的位置再从这个位置向后找第一个引号作为内容起点再找下一个引号作为终点。因为 JSON 里的换行已经是\n转义形式所以文本里不会出现裸引号截取是可靠的。眼神尖的读者会发现Replace的顺序有讲究先把\\换回去否则会把本来应该保留的反斜杠也吞掉。我在实际项目里见过不少人栽在这里——把\\n直接替换成换行后LaTeX 里的\frac全变成了裸frac。3. 在 Word 里落地选中文字生成正文、清洗粘贴文本和公式图片转 LaTeX3.1 最常用的“选中即处理”润色、翻译、摘要一气呵成用户对办公自动化最大的诉求不是“帮我写整篇”而是“我选中这一段你帮我改”。Word 宏里这个操作对应Selection.Range。下面这个宏会把选中的文字发给 DeepSeek R1然后把结果直接插入到光标位置原文保留在下方作为对照。Sub DeepSeekR1_Selection() Dim apiKey As String, prompt As String Dim selectedText As String, result As String apiKey Environ(DEEPSEEK_API_KEY) If apiKey Then MsgBox 先设置环境变量 DEEPSEEK_API_KEY, vbExclamation Exit Sub End If If Selection.Type wdSelectionNormal Then selectedText Selection.Range.Text Else selectedText ActiveDocument.Content.Text End If prompt 请对下面这段文本做技术文档风格的润色 _ 保留原有术语不要改变事实信息。 vbCrLf vbCrLf selectedText 请求可能较慢先给用户一个状态提示 StatusBar.Text DeepSeek R1 处理中…… DoEvents result DeepSeekChat(prompt, apiKey) StatusBar.Text 插入到当前光标位置原文自动下移成对照 Selection.TypeParagraph Selection.TypeText result End Sub这个宏的设计有几个细节。第一Selection.Type判定了当前是不是选中了正常文本如果什么都没选就退回处理整篇文档防止用户误操作后没有任何反馈。第二发送前先把状态栏提示刷出来DoEvents让界面先响应否则用户看到 Word 卡死会直接强杀进程。第三结果插入用的是Selection.TypeText它会跟随当前段落样式而不是凭空创建一堆自动格式。如果你希望结果保留原文格式可以用Selection.Range.FormattedText ...的方式回填但我个人习惯让 AI 输出保持正文格式后续再统一排。3.2 把 AI 返回的 Markdown 转成 Word 原生正文而不是一堆 # 号很多人的实际痛点不是“调不通 API”而是“AI 输出的 Markdown 没法直接用”。DeepSeek R1 很喜欢用 Markdown 组织回答标题用##列表用-。直接粘贴进 Word 就是灾难。热词里就有人搜“markdown 转 word 工作流 coze”想用 no-code 工作流绕一圈。其实这步在 Word 宏里几行代码就能搞定按行读取识别前缀落到 Word 内置样式。Sub PasteAsMarkdownText(txt As String) Dim lines As Variant, line As Variant Dim level As Integer, clean As String lines Split(txt, vbLf) For Each line In lines If Left(Trim(line), 1) # Then 连续 # 的数量就是标题层级 level 0 Do While Mid(line, level 1, 1) # And level 4 level level 1 Loop clean Trim(Mid(line, level 1)) Selection.Style ActiveDocument.Styles(标题 level) Selection.TypeText clean ElseIf Left(Trim(line), 1) - Then 无序列表统一落到列出段落样式 clean Trim(Mid(line, 2)) Selection.Style ActiveDocument.Styles(列出段落) Selection.TypeText clean ElseIf Trim(line) Then Selection.TypeParagraph Else Selection.Style ActiveDocument.Styles(正文) Selection.TypeText Trim(line) End If Selection.TypeParagraph Next line 表格行以 | 开头建议单独交给 Word 表格生成逻辑见 6.2 End Sub这里的核心是不自己画格式而是映射到 Word 的“样式”体系。用ActiveDocument.Styles(标题 1)而不是手动改字号加粗好处是后续生成目录、调整公司模板字体只要改样式全文自动跟着变。这个习惯是多年的血泪经验——我在早期会让代码直接设置Selection.Font.Size等模板调整时整篇文档格式全乱。列表部分也是同理用“列出段落”而不是手动加项目符号避免缩进层级错乱。如果你处理的 AI 输出里还有 Markdown 表格那就不能用行处理了得单独做表格切分这部分在最后一章讲。3.3 公式图片转 WordR1 在公式 LaTeX 上的正确打开方式热词里“公式图片转 word”和“word 公式转 latex”出现频率相当高翻译一下就是PDF 或网页里的公式是图片想让它们变成 Word 里可编辑的公式。DeepSeek R1 本身是文本模型不能直接看图。我常用的落地路径是先用 OCR 工具把公式图片识别成 LaTeX再把 LaTeX 交给 R1 做“清洗”——因为 OCR 出来的 LaTeX 经常有括号不匹配、把\alpha识别成a的问题R1 很擅长把这段乱糟糟的 LaTeX 修正成规范形式。Function CleanLatex(rawLatex As String, apiKey As String) As String Dim prompt As String prompt 你是一名 LaTeX 校对专家。下面这段 OCR 识别出的 LaTeX _ 可能有括号不匹配、命令拼写错误。请只输出修正后的 LaTeX _ 不要加任何解释不要加 Markdown 代码块。公式如下 _ vbCrLf vbCrLf rawLatex CleanLatex DeepSeekChat(prompt, apiKey) End Function注意 Prompt 里专门强调了“不要加任何解释不要加 Markdown 代码块”。R1 的推理模型特性决定了它很喜欢先“演算”一番再给结论但在公式清洗这个场景你需要的是纯结果。加了这句之后输出里就不会出现latex的围栏省掉一层后处理。清洗完的 LaTeX 可以直接存到 Word 里的文本框里也可以在第 6 章的方法中进一步转成 Word 原生公式 OMML。如果电脑里装了 MathType 或者其它公式工具R1 返回的 LaTeX 也能直接被它们识别粘贴但我不建议把业务依赖绑死在公式编辑器上因为同事电脑上不一定装了对应的软件。4. WPS 里接入VBA 组件与 JS 宏的差异以及表格批量清洗写法4.1 先分清WPS 的 VBA 组件和内置 JS 宏怎么选WPS 接入 DeepSeek R1 比 Word 多一个前置决策用 VBA 还是用 JS 宏。WPS 个人版默认不带 VBA 组件需要单独安装这也是“wps vba 组件”和“vba 插件 7.1 支持 wps”这类热词存在的背景。如果你的公司电脑不允许安装第三方组件或者装了之后被安全策略拦下那就走 WPS 内置的 JS 宏——在“开发工具”里切换到 JS 环境不需要额外装任何东西。我的选择逻辑是这样的如果团队里已经有一批跑在 Word 上的 VBA 宏且能装 WPS 的 VBA 组件那迁移成本最低因为大部分对象模型通用如果是从零开始、或者要发给外部单位用坚决选 JS 宏少一个安装依赖就少一次“到现场发现装不上”的售后。WPS 的 JS 宏语法是标准 JavaScript 风格调用方式和浏览器里的 XHR 几乎一样。这里最大的坑是WPS 对 VBA 的兼容不是 100%某些 Word 宏里的ActiveDocument.Styles在 WPS 里拿不到同名枚举需要先跑一段探测代码看看对象模型支持到哪一层。4.2 WPS 文字调 DeepSeek 的 JS 宏样板取全文、发请求、写回WPS 的 JS 宏接入 API 的骨架比 VBA 更简洁因为 JavaScript 天生就有JSON对象不用手写解析。下面这段是 WPS 文字里用的最小样板。function DeepSeekR1_Insert() { var apiKey WPS.Env.GetEnvironmentVariable ? WPS.Env.GetEnvironmentVariable(DEEPSEEK_API_KEY) : ; // 取当前文档内容想只处理选中区改成 Selection 相关接口 var docText ActiveDocument.Content.Text; if (docText.length 6000) { docText docText.substring(0, 6000); } var body { model: deepseek-reasoner, messages: [{ role: user, content: 请把下面内容改成中文公告风格\n docText }], temperature: 0.3, max_tokens: 8192 }; var xhr new XMLHttpRequest(); xhr.open(POST, https://api.deepseek.com/v1/chat/completions, false); xhr.setRequestHeader(Content-Type, application/json; charsetutf-8); xhr.setRequestHeader(Authorization, Bearer apiKey); xhr.send(JSON.stringify(body)); var resp JSON.parse(xhr.responseText); var result resp.choices[0].message.content; // 在文档末尾插入后面补两个空行隔开原文 ActiveDocument.Content.InsertAfter(\n\n result); }这段代码里有几个值得注意的取舍。第一我加了 6000 字符的截断保护因为长文档直接进 Prompt 会放大 token 消耗R1 的思维链还会再吃一部分全文动不动几万字很危险实际接业务时我都是先做段落切分再逐段调用。第二XMLHttpRequest在 WPS 的 JS 宏环境里能用但不同版本行为有差异遇到没有此对象的环境就退回 WPS 提供的网络接口。第三代码里用了WPS.Env.GetEnvironmentVariable如果当前环境不支持就改成弹窗输入 key。WPS 的对象模型在不同大版本之间差异明显写宏时先console.log(typeof ActiveDocument)探一下能省下大量排查时间。4.3 WPS 表格批量清洗把一列数据交给 R1结果回填邻列办公自动化里最高频的场景其实是表格拿到一列客户地址、一列错误格式的手机号、一列横跨三行的公司名想标准化但又不敢用正则硬写。WPS 表格的 JS 宏很适合做这个。下面这个例子读取 A1:A50拼成一个请求发给 DeepSeek R1要求它按行返回标准化结果再写到 B 列。function CleanRows() { var sheet ActiveSheet; var rows 50; var inputLines []; for (var i 1; i rows; i) { var cellValue sheet.Range(A i).Value2; if (cellValue ! cellValue ! null) { inputLines.push(i : cellValue); } } var prompt 下面每一行是序号: 原值请你对每个原值做标准化统一全半角、修正明显错别字保持序号不变。只输出序号: 结果每行一条不要解释\n inputLines.join(\n); var body { model: deepseek-reasoner, messages: [{ role: user, content: prompt }], temperature: 0.1, max_tokens: 8192 }; var xhr new XMLHttpRequest(); xhr.open(POST, https://api.deepseek.com/v1/chat/completions, false); xhr.setRequestHeader(Content-Type, application/json; charsetutf-8); xhr.setRequestHeader(Authorization, Bearer WPS.Env.GetEnvironmentVariable(DEEPSEEK_API_KEY)); xhr.send(JSON.stringify(body)); var resp JSON.parse(xhr.responseText); var outputLines resp.choices[0].message.content.split(\n); for (var j 0; j outputLines.length; j) { var parts outputLines[j].split(:); if (parts.length 2) { var rowIdx parseInt(parts[0], 10); var cleanVal parts.slice(1).join(:).trim(); sheet.Range(B rowIdx).Value2 cleanVal; } } }合批请求是这里的核心思路。把 50 行数据拼到一个请求里远比循环 50 次调用 API 省钱省时间而且 R1 能看到上下文能根据同一列的其它行推断你想要的统一格式。但这带来一个新问题R1 输出偶尔会比输入少几行或者某行结果里带了冒号导致切分错位。所以我让每行输入都带“序号”输出也要求带“序号”回填时按序号定位而不是按顺序硬填。如果你只是拿split(:)取第一段遇到公司名“XX:上海事业部”这种带冒号的字段就会翻车代码里用parts.slice(1).join(:)把剩余部分拼回去就是专门应对这个的。5. 接入 DeepSeek R1 的 5 个常见坑乱码、截断、JSON 解析失败和假死5.1 现象返回的中文全乱码或者干脆是空字符串用WinHttp.WinHttpRequest.5.1发请求时最容易出现这种问题。原因很简单这个对象把响应体按单字节字符集解码中文 UTF-8 的字节被拆成一个一个拉丁字符自然全是乱码。解决方法是换用MSXML2.XMLHTTP如果必须保留 WinHttp就手动用 ADODB.Stream 把responseBody按 UTF-8 解码。Dim stream As Object Set stream CreateObject(ADODB.Stream) stream.Type 1 二进制 stream.Open stream.Write http.responseBody stream.Position 0 stream.Type 2 文本 stream.Charset utf-8 resp stream.ReadText stream.Close这段代码在 VBA 里是通用的“强制按 UTF-8 解码”办法。注意stream.Type先设 1 再设 2顺序不能反先以二进制拿到原始字节再切到文本模式并按指定字符集解码。如果你发现 MSXML2 在某个老系统上也不能用检查一下系统是否缺少对应的 MSXML 运行库补装后重启 Office 即可这属于玄学之外的确定性故障。5.2 现象R1 答到一半就断长文总是结尾丢失R1 的响应里带reasoning_content模型要先“思考”一大段才输出正式内容。如果你没设max_tokens默认值往往不够思考链加正文一起用于是响应被截断正文刚开头就戛然而止。另一个表现是短问题正常长文档处理必定丢尾巴。解决方法是把max_tokens显式调到 8192同时检查 API 控制台里的“上下文长度”配额别让累计 tokens 超限。如果任务真的很长——比如要处理整本合同——就不要一个 Prompt 硬撑先切成段落逐个请求最后拼装。我的习惯是段落长度控制在 2000 字以内这样 R1 的推理深度和响应速度都处于甜点区。5.3 现象JSON 解析总失败浏览器里复制却正常VBA 里最常见的翻车现场同一个响应放到 Postman 或浏览器控制台里JSON.parse正常VBA 里一解析就报错。原因有两个方向。第一R1 的content里可能带了 Markdown 代码围栏即使你只在 JSON 层面看是合法的某些手写解析器会把它当成异常结构。第二VBA 的ScriptControl组件在 64 位 Office 里根本加载不了很多人以为代码写错了其实是组件缺失。我的做法是响应文本先做一次清理把json和尾部的删掉再用InStrRev截取最后出现的content字段而不是引入第三方 JSON 库。R1 响应里content字段一定在reasoning_content之后取最后一个content是可靠的。如果是 JS 宏环境直接用JSON.parse就行但同样要先做代码围栏清理。5.4 现象一运行宏 Word/WPS 就“未响应”这是因为 VBA 里的XMLHTTP同步请求会卡死 UI 线程R1 推理速度又比普通模型慢一个请求动辄十几秒期间用户不能做任何操作Windows 就会弹“未响应”。解决思路有两层。第一层是在宏里加过程反馈请求前设置StatusBar.Text调用DoEvents刷新界面让用户知道程序还活着。第二层是拆任务如果是批量处理一次少发几行数据如果公司上了 R1 的异步 API就把请求放到后台用回调机制回填文档。WPS JS 宏里如果环境支持把xhr.open的第三个参数改成true用onreadystatechange回调界面就不会假死VBA 里没有原生异步换一种做法——弹一个无模式窗体显示“处理中”不要让宏一口气跑到底。5.5 现象这台电脑能跑换一台就报 400 或“ActiveX 部件不能创建”宏分发到别的电脑上时最常见的三个原因第一目标机器没装 WPS 的 VBA 组件或 Office 是 64 位而代码里用了ScriptControl第二API key 还嵌在旧代码里换机后环境变量不存在第三Word 的宏安全性设置把宏给禁了调用时直接静默失败。解决方法是宏启动时先做环境探测——CreateObject包一层错误处理失败就弹窗提示具体缺什么key 改由环境变量或用户窗体输入不要写死在代码里不要在宏代码里写“禁用宏安全检查”之类的绕过逻辑正确做法是让 IT 在组策略里对已签名的宏放行。我曾经因为图省事在公共模板里硬编码了一个测试 key结果换了两台电脑全部报 401排查了半天才发现是 key 的问题从那以后我再也不把 key 写进宏文件。6. 进阶让 R1 的输出真正“长在” Word/WPS 里并做一次自检6.1 把 LaTeX 公式转成 Word 原生公式OMML而不是文本第 3.3 节里清洗好的 LaTeX如果只作为字符串粘贴等于让公式失去了可编辑性。Word 的原生公式格式是 OMML想让 LaTeX 变成 OMML常见做法是借道 pandoc把 R1 返回的 LaTeX 包进一个最小 Markdown 文件执行pandoc in.md -o out.docx --mathml再用 Word 打开或把生成的段落复制过来。宏里可以用Shell调用这条命令。pandoc tmp.md -o output.docx --mathml注意--mathml参数才会让公式以 Word 可识别的 OMML 落盘。这个方案的优势是不依赖 MathType也不用装公式编辑插件只要一台机器有 pandoc公式就是原生可编辑的。在 VBA 里调用时先ChDir到工作目录处理完再用Documents.Open打开生成的文件。批量的公式图片转 Word 场景我会让 R1 一次性输出多条 LaTeX每条前面加$$公式编号$$标记pandoc 会依次转成 Word 公式块的序列效率比一条条处理高很多。6.2 让 R1 按你的模板输出结构化 Prompt 与后处理脚本如果你希望 R1 每次返回的内容都能直接入档最好的办法不是靠运气而是在 Prompt 里约会法。我常用的模板是明确输出格式、明确分隔符、明确“不要输出任何额外解释”。比如做合同摘要时我会要求 R1 只返回下面这种结构【甲方】xxx 【乙方】xxx 【金额】xxx 【付款节点】1. 2. 3.后处理脚本再按“【标题】”正则切分填入 Word 表格或书签位置。这个做法把“模型输出”和“版面呈现”彻底解耦模型只负责产出结构化文本排版交给 Word 宏。比起让 R1 直接生成一份不靠谱的 Word 文档这种拆法让每一步都可测、可修、可审计。6.3 用 R1 自己的“慢思考”给结果加一道自检最后分享一个验证技巧对重要内容把 R1 的输出丢回给它做二次校验。不是简单问“对不对”而是让它再推导一遍“这份摘要里的金额和付款节点是否与原文一致如有不一致列出差异。”R1 的推理链会在这时真正起作用。如果两次结果矛盾我会人工介入。这套做法救过我一次有个周报自动汇总功能R1 第一次生成时把“下周一”理解成了“下周日”自检环节发现了日期偏移从那以后凡是带时间、金额、编号的输出我都会加一道自检。你不需要让它“反思”只要换一个角度描述同一个任务就能暴露大部分幻觉。接入 DeepSeek R1 到办公自动化的核心不是把 API 调通而是把模型输出驯化成文档体系里可用的内容。我这几年最大的教训是永远不要相信一次输出凡是进入正式文档的 AI 内容都要保留人工复核位。希望帮到你。本文还有配套的精品资源点击获取