企业官网建设流程全解析

简介：这是一份聚焦办公效率提升的PDF教程，适合经常使用Word或WPS处理文档、希望借助人工智能技术简化写作的职场人士。教程完整讲解了将两个办公软件接入DeepSeek R1服务的配置方法，先介绍在DeepSeek官网完成注册并进入API开放平台申请密钥的流程，同时提醒读者务必妥善保管密钥、避免泄露；随后针对Word和WPS分别说明接入步骤，尤其对WPS补充了启用VB开发环境、安装宏编辑器插件、安装后重启应用等细节。内容还包括实际操作中常见的插件安装失败、工具栏找不到入口等排错思路，帮助读者一步到位完成配置。整个资源是单个PDF文件，体积约976KB，结构紧凑，方便按章节查阅。目前已有1042人学习下载，适合追求高效文档处理的专业人士，也适合初次尝试AI辅助写作的个人用户。

1. 办公自动化中Word与WPS接入DeepSeek R1：把文档读写变成一次 HTTPS 调用

办公自动化中Word与WPS接入DeepSeek R1，就是两件事：把文档内容送到模型接口，把返回结果按原格式写回文档。做标书、审合同、改报告的人，天天和改措辞、摘要、比对条款这类重复劳动打交道，正则写不出，搜索换不来，正好是推理模型的地盘。

为什么把 Word 和 WPS 一起讲？办公电脑多数装 WPS，回家用 Word，两个软件对象模型并不互通。R1 的 API 调用不挑办公软件，真正的坑全在取文本、传 HTTP、写回格式这三步，两边做法有差异。

下面按选型、最小代码、WPS 双方案、踩坑记录、进阶批注五步来写，新手照着跑通第一条链路，熟手看参数边界和公式转换的退化方案。

2. 为什么用 DeepSeek R1 而不是本地脚本：接入方式与接口边界

2.1 R1 擅长的文档任务和接口调用边界

先想清楚一个前提：R1 不是用来做精确规则的。凡是能用正则、替换、pandoc 干净利落解决的——批量删空行、统一换行符、把 Word 表格导出成 CSV——都不值得走接口，本地脚本更快、更可预期。R1 的价值在需要理解语义的任务：长文摘要、术语统一、口语转书面、合同条款风险点提示、公式转 LaTeX，以及把模型输出整理成得体的 Word 内容。

R1 的调用边界其实很窄，就是一次标准的 HTTP POST。请求体是 messages 数组，模型名填 deepseek-reasoner；响应里除了 reasoning_content（思维链）还有 content（最终回答）。接入办公自动化时，回写文档的永远是 content。新手最容易踩的意外是拿到思维链写回正文，占篇幅还带推理口吻，看起来非常突兀。

接口的另一个边界是上下文长度和 max_tokens 的分配。R1 是推理模型，回答前要消耗一段思维链 token。这意味着 max_tokens 如果只给 512，润色一段两千字的稿子，很可能链还没走完就截断，返回的 content 是一段没写完的话。实际接入时我把 max_tokens 起步设到 2048，长文摘要给 4096。

还要提前接受一个现实：延迟。R1 是推理模型，短文本润色也要 5～10 秒起步，长篇摘要 30 秒以上很正常。宏界面在这段时间是卡住的，所以接入前要对齐预期，这不是本地替换那种毫秒级响应。批量场景优先走 Python 加重试，别硬塞进宏里循环。

2.2 Word 与 WPS 的自动化接口差异：VBA、JS宏和命令行三条路

接入 R1 之前，得先知道自己手里有几条路，每条路的地板在哪。

Word 这边走得最稳的是 VBA。对象模型全，Selection、Range、OMaths、Comments 都齐，MS 的官方文档也最厚。唯一麻烦是 64 位 Office 下个别 API 行为不同，但调 HTTP 这种活不受影响。

WPS 这边有两条路。第一条是装 VBA 组件后跑 VBA，兼容 Word 的大部分对象，但别指望 100%。实操中最典型的坑是 Range.XML 和 OMaths 在 WPS 里不完整，公式相关功能直接退化。第二条是 WPS 2019 之后自带的 JS 宏（JSA），用 JavaScript 写，处理 JSON 比 VBA 舒服得多，但它没有 Word 那么全的对象模型，很多属性名要现查。

第三条路不经过宏：用 Python 写独立脚本，python-docx 读写 docx，requests 调接口。这条路适合批处理和复杂逻辑，缺点是要跑在装了 Python 的机器上，不能像宏一样按 F5 就在文档里干活。我一般把交互型操作放宏里，批处理型任务放 Python 里，两不耽误。

三条路的取舍一句话能说清：单人、即时、贴合文档操作的选 VBA 或 JS 宏；多文件、定时跑、要接数据库的选 Python。

2.3 整体链路：选中文本→调 API→回写，数据走在哪

链路拆开只有四步：取文本、发请求、解析响应、写回。但每一步都有选择。

取文本要注意 Selection.Text 末尾常带段落标记回车，发出去之前要清掉。发请求，VBA 推荐 WinHttp.WinHttpRequest.5.1 同步方式，界面会卡但代码最短；WPS JS 宏里有的版本能用 XMLHttpRequest，没有就用宿主提供的 Http 对象。解析响应，JS 宏直接 JSON.parse，VBA 没有原生解析库，要么引 VBA-JSON，要么字符串截取——截取在短任务里够用，一旦 content 里带引号就翻车。写回，直接给 Selection.Text 赋值会丢字体样式，要记住修改前的 Font 属性再恢复。

一个容易忽略的点：数据全程在内存里走，不要为了中转写临时文件。写临时文件会引入编码问题，还会撞上 WPS 对宏读写文件系统的权限限制（5.1 详述）。除非输出大得离谱，内存方案足够。

还有一条属于工程纪律：R1 接口是云端服务，文档内容会离开本机。涉及商业秘密、个人信息的内容，上线前要过合规评估。我的做法是敏感字段先脱敏，或者这类任务留在本地规则工具上，而不是硬塞给接口。

链路里还要考虑失败兜底：接口超时、返回空 content、网络波动。宏不是生产系统，但最少做一件事——回写前把选中文本备份到变量，出问题能一键还原。这是吃过亏之后养成的习惯。

3. Word 里跑通 DeepSeek R1：VBA 最小调用代码与参数设置

3.1 准备工作：密钥、宏安全设置和 WPS VBA 组件

动手前先备齐三样东西。

第一，API 密钥，形如 sk- 开头。密钥在宏里建议放模块顶部常量，方便替换；不要把密钥硬编码进随文档分发的模板里，文档发出去，宏里的密钥也跟着走了。我的习惯是宏读环境变量或外部配置文件，拿不到就弹提示，而不是写死在 docm 里。

第二，宏的运行环境与安全设置。Word 按 Alt+F11 进 VBA 编辑器，工具 → 引用里勾选 Microsoft WinHTTP Services 5.1。不勾引用也能用 CreateObject 直接创建，少一步配置。随后到信任中心把当前工作目录设为受信任位置，否则宏被禁用，按 F5 没反应。不要为了省事永久关闭宏安全，也不要去找来路不明的 WPS 破解版或第三方 VBA 组件包。WPS 需要 VBA 能力时，装官方 VBA 组件（7.1 版本常见）就够了，干净且兼容性好。

3.2 最小 VBA 代码：WinHttp 同步请求与 UTF-8 响应解码

下面这段是 Word 里直接可跑的最小实现，模块里放两个过程：一个发请求，一个处理选中区。

' 模块级常量：密钥 Private Const API_KEY As String = "sk-你的密钥" ' 核心函数：把 prompt 发给 DeepSeek R1，返回 content 字段 Public Function CallDeepSeekR1(ByVal prompt As String, ByVal apiKey As String) As String Dim http As Object Dim reqBody As String Dim respBody() As Byte Dim stream As Object Dim content As String ' 1. 构造 JSON 请求体；VBA 里双引号要写成两个连续的双引号 reqBody = "{""model"": ""deepseek-reasoner""," & _ """messages"": [{""role"": ""user"", ""content"": """ & _ prompt & """}], ""temperature"": 0.6, ""max_tokens"": 4096}" ' 2. 用 WinHttp 同步 POST；False 表示同步等待 Set http = CreateObject("WinHttp.WinHttpRequest.5.1") http.SetTimeouts 60000, 60000, 60000, 60000 http.Open "POST", "https://api.deepseek.com/chat/completions", False http.SetRequestHeader "Content-Type", "application/json; charset=utf-8" http.SetRequestHeader "Authorization", "Bearer " & apiKey http.Send reqBody ' 3. 按字节取响应，再用 ADODB.Stream 按 UTF-8 解码，避免中文变问号 respBody = http.ResponseBody Set stream = CreateObject("ADODB.Stream") stream.Type = 1 ' adTypeBinary stream.Open stream.Write respBody stream.Position = 0 stream.Type = 2 ' adTypeText stream.Charset = "utf-8" content = stream.ReadText stream.Close ' 4. 截取 content 的字符串值；短任务够用，复杂场景换成 VBA-JSON 库 Dim marker As String Dim startPos As Long Dim endPos As Long marker = """content"":""" startPos = InStr(content, marker) + Len(marker) endPos = InStr(startPos, content, """", vbBinaryCompare) CallDeepSeekR1 = Mid(content, startPos, endPos - startPos) End Function

逻辑说明：第 1 步是坑位最多的地方——VBA 字符串里的双引号必须写成两个连续引号，否则 JSON 结构直接坏。第 2 步 SetTimeouts 四个参数分别是解析、连接、发送、接收超时，R1 推理慢，默认 30 秒经常不够，统一给到 60 秒。第 3 步如果不走 ResponseBody 而直接读 responseText，中文 Windows 上会被按 ANSI 解码，中文全变问号，这是接入排错里出现频率最高的问题。第 4 步的字符串截取在答案里没有英文引号时能工作，一旦有引号就断，生产环境建议直接引 VBA-JSON 的 ParseJson。

然后是"选中文本→回写"的调用过程：

' 宏入口：选中一段文字，运行后替换成 R1 的润色结果 Sub ReplaceSelectionWithR1() Dim selectedText As String Dim result As String ' 1. 校验：光标必须选中正文 If Selection.Type <> wdSelectionNormal Then MsgBox "请先选中一段正文再运行" Exit Sub End If ' 2. 取文本并清理换行与制表符，防止打断 JSON 字符串 selectedText = Selection.Text selectedText = Replace(selectedText, vbCr, " ") selectedText = Replace(selectedText, vbLf, " ") selectedText = Replace(selectedText, vbTab, " ") selectedText = Trim(selectedText) If Len(selectedText) < 2 Then MsgBox "选中内容太短" Exit Sub End If ' 3. 记住原字体，回写后恢复，避免丢格式 Dim origFontName As String Dim origFontSize As Single origFontName = Selection.Font.Name origFontSize = Selection.Font.Size ' 4. 调用接口；提示词要求只输出结果，不输出解释 result = CallDeepSeekR1("请润色下面这段文字，保留原意，不要解释，直接输出润色结果：" & selectedText, API_KEY) ' 5. 回写并恢复字体 Selection.Text = result Selection.Font.Name = origFontName Selection.Font.Size = origFontSize End Sub

这里有两个容易被忽略的行为：一是 Selection.Text 自带末尾段落标记，不清理就混进 JSON；二是直接 Selection.Text = result 会丢掉选中区的字体、字号、加粗等格式，所以先存 Font 属性。跑通这段后，把任务换成翻译、摘要、条款风险提示，只需要改提示词前缀，代码结构不动。

3.3 必调的三个参数：模型名、temperature 和 max_tokens

接入后真正决定输出质量的是请求体里的三个参数，不是代码。

模型名 model 决定走哪个能力。R1 推理模型在 API 里对应 deepseek-reasoner。如果后续平台把模型收敛成一个统一入口，以你拿到的接口文档为准。模型名写错的常见现象是 HTTP 400 或 404，排查接口问题先看这一项。

temperature 控制随机性。R1 这类推理模型在 0.6 附近是安全区间：太低答得干瘪，太高会在一遍遍重跑时结果不一致。做审校、摘要这类求稳任务我放 0.3；做创意改写、文案扩写放 0.7 以上。需要反复重跑验证一致性的批量文档，配合低温更合适。

max_tokens 要按 R1 的思维链特性调。推理模型的 token 分两块：先思考后作答，max_tokens 是两块的上限之和。短任务 2048 够，长文摘要和翻译至少 4096，不然内容会在说到一半处被掐断，现象就是 content 末尾是个半截句子。

3.4 把选中文本规范化发送：控制符、长度和提示词模板

文本规范化是让链路可靠的最后一道工序，也最容易翻车。除了上节清理 vbCr 和 vbLf，还要处理两个问题。

第一个是长度。R1 的上下文长度有限，一个宏直接把三万字标书塞进去，请求体会超限。常见做法是按自然段切分，每段单独请求再拼接结果；单段超过 2000 字的，先截成小块分批发。批处理时注意控制频率，别在几十毫秒内连发一堆请求。

第二个是提示词模板的一致性。同样一段文字，"润色一下"和"你是资深编辑，请润色下面这段文字，保持正式语气，不要解释，直接输出"得到的结果差异巨大。我习惯把提示词固定成模板常量，只拼接业务部分。模板里有三要素：角色、任务、输出约束。输出约束最重要——不加约束，R1 会在答案前后加"以下是润色结果"之类的废话，回写进文档就乱了。

把这三要素写进 3.2 的代码，只需要改第 4 步的字符串拼接。模板统一后，所有宏共用一套规范，出问题只改一处。

4. WPS 接入的两条路：JS 宏直接调 API，和 Markdown 转 Word 工作流

4.1 WPS JS 宏：从选中文本到 JSON.parse 的最短路径

WPS 2019 之后的版本自带 JS 宏。打开方式是：开发工具 → JS 宏 → 新建模块，写完后直接运行。JS 宏最大的优势是 JavaScript 原生处理 JSON，不需要像 VBA 那样做字符串截取，响应解析稳得多。

// 在 WPS 的 JS 宏编辑器里新建模块，粘贴这段代码 var API_KEY = "sk-你的密钥"; function DeepSeekR1Replace() { var sel = ActiveDocument.Selection; var text = sel.Text; if (text == null || text.length == 0) { alert("请先选中一段正文"); return; } // 清理换行和多余空白 var prompt = text.replace(/[\r\n\t]+/g, " ").trim(); // 用 XMLHttpRequest 同步调用；若当前版本没有该对象， // 在宏编辑器对象列表里搜 Http 相关对象，按同样三步改写 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 " + API_KEY); var body = { model: "deepseek-reasoner", messages: [{ role: "user", content: prompt }], temperature: 0.3, max_tokens: 4096 }; xhr.send(JSON.stringify(body)); var resp = JSON.parse(xhr.responseText); var content = resp.choices[0].message.content; // 回写选中区 sel.Text = content; }

逻辑说明：JS 宏里 ActiveDocument.Selection 和 VBA 同名，但宿主环境不同，部分属性名有差异。JSON.stringify 负责序列化，天然规避 VBA 双引号转义的坑；JSON.parse 解析响应，比字符串截取可靠。请求体里我把 temperature 放到 0.3，因为 WPS 里做审校类任务居多，温度低输出更一致。

注意，不同 WPS 版本对 JS 宏宿主暴露的 HTTP 对象名不一样。有的版本有 XMLHttpRequest，有的需要用 Http.post 这类封装。没有 XMLHttpRequest 时，在左侧对象面板搜 Http，照着设置请求头、发送、读取响应三步改写即可。接口地址、模型名、密钥占位符都要替换成实际的。

4.2 公式转 LaTeX：用 Range.XML 把公式喂给 R1

把 Word 公式转成 LaTeX，是接入 R1 后效果最实用的场景之一。原理：Word 内置公式以 OMML 存储，Range.XML 能拿到包含 OMML 的 XML。把 XML 发给 R1，让它输出对应 LaTeX，比传统公式转换工具灵活。

' Word 场景：选中公式区域，提取 OMML 交给 R1 转 LaTeX Sub FormulaToLatex() Dim mathXml As String Dim latex As String ' 1. 校验当前是否选中了公式对象 If Selection.OMaths.Count = 0 Then MsgBox "请先选中文档里的公式" Exit Sub End If ' 2. 取第一个公式的 XML（含 OMML） mathXml = Selection.OMaths(1).Range.XML ' 3. 把 XML 发给 R1，提示词要求只输出 LaTeX latex = CallDeepSeekR1("请把下面的 OMML 数学标记转换为 LaTeX 公式，只输出 LaTeX 代码，不要解释：" & mathXml, API_KEY) ' 4. 把结果插入到当前段落后面，自行复制使用 Selection.InsertAfter vbCrLf & latex End Sub

逻辑说明：Selection.OMaths.Count 判断选中区是否包含公式，避免对纯文本调用导致崩溃。Range.XML 返回带命名空间的 XML 字符串，直接发给 R1，不需要自己解析 OMML 结构。第 4 步没有替换原公式，因为 LaTeX 回填到 Word 有专门通道：Word 2019 后的等式编辑器支持直接输入 LaTeX，按 Alt+= 进入公式编辑后粘贴即可；如果公式来自 MathType，也可以复制时选 LaTeX 格式，直接进 R1 处理。

这个方案有一个边界要提前讲：WPS 对 OMaths 和 Range.XML 支持不完整，代码大概率只能在 Word 里跑。WPS 里的退化方案见 5.5。

4.3 DeepSeek 输出的 Markdown 怎么导出为 Word：pandoc 工作流

接入 R1 后另一个高频诉求，是把模型输出的 Markdown 文档转成正式 Word。R1 的回复天然是 Markdown 风格，直接在 Word 里贴会留下井号、星号、横线这些标记。常见做法是走 pandoc 工作流：

# 1. 把 R1 返回的内容存成 ai_output.md # 2. 用 pandoc 转 Word，默认模板即可 pandoc ai_output.md -o 输出文档.docx # 3. 如果要匹配公司模板，先生成 reference.docx 再覆盖样式 pandoc --print-default-data-file reference.docx > ref.docx pandoc ai_output.md -o 输出文档.docx --reference-doc=ref.docx

逻辑说明：pandoc 把 Markdown 的标题层级映射成 Word 标题样式，代码块映射成等宽字体段落，表格映射成 Word 表格。第一次转换后观察样式偏差，用生成的 ref.docx 调一次模板，之后所有文档复用同一套样式。

这个工作流与办公软件版本无关，也不依赖特定插件。配合 R1 的 API，整条链路就是：文档 → R1 → Markdown → pandoc → 规范 Word。比在宏里逐段转换省事，也规避了 VBA 回写格式的老大难问题。要注意 R1 输出的列表符号统一成横线和有序数字，pandoc 对表格支持良好，但个别扩展语法不一定认，转出来先预览一遍。

4.4 批量处理：Python 脚本扫目录 vs 宏循环

待处理文档超过 10 个时，宏循环就不合适了：VBA 同步请求卡界面，一个文件跑半分钟，人只能干等。批量场景我一般配一个 Python 脚本，用 python-docx 读段落、requests 调接口、再写回。

import time import requests from docx import Document API_URL = "https://api.deepseek.com/chat/completions" API_KEY = "sk-你的密钥" def ask_r1(text: str) -> str: payload = { "model": "deepseek-reasoner", "messages": [{"role": "user", "content": text}], "temperature": 0.3, "max_tokens": 4096, } resp = requests.post( API_URL, headers={"Authorization": f"Bearer {API_KEY}"}, json=payload, timeout=120, ) resp.raise_for_status() return resp.json()["choices"][0]["message"]["content"] doc = Document("待审稿件.docx") for i, para in enumerate(doc.paragraphs[:20]): # 先跑前20段试水 if len(para.text.strip()) < 5: continue para.text = ask_r1("润色并保持原意：" + para.text) time.sleep(1) # 限速，避免短时间高频请求 doc.save("审稿结果.docx")

逻辑说明：doc.paragraphs 遍历所有段落，len 过滤掉空段和短段，para.text 直接赋值实现替换。time.sleep(1) 是批量场景的关键——模型接口对突发请求会限流，不加 sleep 跑几十条就开始报错。试水时先用前 20 段切片，确认输出质量再放开全量。Python 方案和宏方案的本质区别：宏处理正在编辑的这一个文档，脚本处理一批文档，前者交互性强，后者可控性强。

5. 接入避坑：WPS报错75、中文乱码、接口超时和 JSON 解析的 5 个现场

5.1 WPS 宏里报错 75：临时文件路径与权限

现象：VBA 在 WPS 里跑，动不动弹"错误 75：路径/文件访问错误"，尤其加了写临时文件的功能后几乎必现。

原因：WPS 对宏的文件系统访问比 Word 保守，宏默认没有写盘权限；其次是路径带中文或写在系统盘根目录也容易触发。很多老教程让宏把临时文件写到 C 盘根目录，在新版 WPS 里基本都踩中。

解决：临时文件一律写到用户临时目录，用 Environ("TEMP") 动态获取，别硬编码：

Dim tmpPath As String tmpPath = Environ("TEMP") & "\r1_output.txt" Open tmpPath For Output As #1 Print #1, result Close #1

再到 WPS 信任中心把当前工作目录设为受信任位置，宏才有读写权限。如果不想碰文件权限，绕开文件系统，直接走内存传递，3.2 的做法就没这个问题。

5.2 中文全变问号：响应解码的编码问题

现象：接口调用成功，英文正常，中文在立即窗口里显示成问号，写回文档也是一排问号。

原因：这是接入 DeepSeek R1 出现频率最高的问题，根源是字符集错配。WinHttpRequest 的 responseText 在中文 Windows 上默认按 ANSI 解码，而 API 返回 UTF-8，两边对不上。直接读 responseText 拿回来的中文字符串已经是乱码，后面再处理也救不回来。

解决：必须走字节级读取，也就是第 3 章代码里的 ResponseBody 加 ADODB.Stream 加 Charset=utf-8 三步。字节数组不经过 ANSI 解码，再用 Stream 按 UTF-8 显式转文本，中文才能完整回来。凡是中文乱码的报障，第一反查就是这三步有没有写全。

5.3 长文本请求超时：SetTimeouts 与分段策略

现象：发一段 2000 字的请求，十几秒后宏报超时或连接中断，有时干脆卡死没反应。

原因：WinHttpRequest 默认超时约 30 秒。R1 是推理模型，长文本的思维链可能超过 30 秒才走到第一个响应字节；加上同步请求阻塞界面，超时前用户容易误判成程序卡死。

解决：请求前显式设置超时，四个参数统一给到 60 秒以上：

http.SetTimeouts 60000, 60000, 60000, 60000

确实超时的长文档不要无限加超时时间，而是分段处理：把全文切成 500～800 字的小段，逐段请求再拼接。这样单次请求耗时可控，失败重试代价也小。UAT 时把超时和"模型答到一半截断"分开看——前者靠 SetTimeouts，后者靠调大 max_tokens，方向别搞反。

5.4 JSON 截取取错字段：VBA 解析 content 的正确姿势

现象：明明调用成功，回写进文档的内容却是半句，或者一段推理过程，有时候还带着转义符。

原因：VBA 没有原生 JSON 解析，很多人用 InStr 找 "content":" 然后截到下一个引号。但 R1 返回里有两个相关字段：reasoning_content 在前，content 在后，截取没对准就拿到推理链；内容里一旦包含英文引号，截取终点直接错位。这是字符串截取的天花板。

解决：有条件就引 VBA-JSON 库，把整个响应解析成字典对象，再取 choices[0].message.content。不想引库的退路是改提示词约束输出格式，比如让 R1 用固定标签包住答案，宏里直接找标签对，绕开 JSON 解析。JS 宏没有这个问题，JSON.parse 一行解决。我的建议：代码要长期维护的，别省引库这一步，字符串截取只适合临时调试。

5.5 WPS 里公式对象模型缺失：Range.XML 不可用的退化方案

现象：在 WPS 里打开含公式的文档，跑 4.2 的 Selection.OMaths(1).Range.XML 报"对象不支持此属性或方法"。

原因：WPS 的公式对象模型和 Word 不是同一套，对 OMaths 支持不全，Range.XML 也没有实现。4.2 的方案被迫退化。

解决：两条路。第一条，公式转换类任务只在 Word 环境里跑，把 WPS 里的文档另存为 docx 再在 Word 中处理；第二条，WPS 里改用截图方案，公式区域截图后用带视觉能力的模型把图转成 LaTeX，再回填。回填时 Word 2019 以上可以直接用 LaTeX 输入公式，WPS 需要先转成 OMML 再插入。公式转换是接入 R1 后收益最高的功能之一，但也是最依赖办公软件版本的，跑不通先查版本支持，别急着怀疑模型。

6. 进阶：让 R1 自动写审校批注，并在十篇文档上做回归验证

6.1 自动批注宏：把审校建议写进 Word 批注

最后一层进阶，是把 R1 从"替换文本"升级成"审校批注"。做法：选中一段，R1 返回审校意见，用 Comments.Add 把意见挂到该段落的批注里，正文不动。这样既保留人审流程，又借了模型的眼。

Sub AddAIRemark() Dim sel As Range Set sel = Selection.Range If sel.Text = "" Then Exit Sub Dim text As String text = Replace(sel.Text, vbCr, " ") Dim result As String result = CallDeepSeekR1("审校下面这段文字，指出事实错误、逻辑问题和表达问题，每条建议不超过100字：" & text, API_KEY) sel.Comments.Add Range:=sel, Text:=result End Sub

这个模式的价值在于批注非破坏性，R1 判断失误时删批注即可，不影响正文。审校任务把 temperature 降到 0.3，追求结果一致；每条建议限字数，避免批注长到盖过正文。

6.2 验证方法和一个备份习惯

接手这类接入，我验证可靠性的习惯是固定十篇样本：两篇合同、两篇技术方案、两篇公告、两篇论文摘要、一篇会议纪要、一篇产品介绍。每篇跑三遍，记录三个指标：输出是否被截断、返回格式是否一致、回写后样式是否保留。

三遍跑下来能看出两件事。一是温度对输出一致性的影响：同一段文字三遍结果差异太大，说明 temperature 偏高，往下调。二是提示词模板的问题：某个任务每次都在答案开头加"以下为审校结果"，说明输出约束没写清，模板里要补上"不要解释，直接输出"。

最后说一个自己的血泪习惯：不管代码多简单，核心文档先另存副本再跑宏，验证无误再全量执行。R1 能力越强，越容易让人放松对写回操作的警惕，而格式化回写恰恰容易出现静默问题——看起来正常，字体、缩进、批注挂错位置都不是一眼能看出来的。先备份这个动作花不了十秒，但能省掉后面一整天的手工修复。希望帮到你。

本文还有配套的精品资源，点击获取