我把 WPS 接入了大模型：一个软件工程师的 AI 办公自动化实验

0. 背景

作为软件工程师，我每天都在和文档、表格、演示文稿打交道。WPS 是国内使用率极高的办公套件，从 WPS官网 可以了解它的开放能力，完成 WPS下载 和安装后，就能用加载项、JS宏、开放平台 API 做二次开发。于是我做了一个实验：把 WPS 接入大模型，让办公软件具备理解和生成能力。

这个实验的目标不是做一个聊天窗口，而是把大模型变成 WPS 内部的推理引擎：读文档、理解表格、生成内容、执行格式化操作。整个过程涉及 WPS 加载项、本地网关、大模型 API、权限控制和工程化部署。

1. 为什么选择 WPS 作为 AI 办公入口

选择 WPS 有几个现实原因：

1. 覆盖面广：文字、表格、演示、PDF 都能处理。
2. 可编程能力强：WPS 提供 JS宏、WPS 加载项、开放平台 API。
3. 用户基数大：团队协作时不需要额外培训。
4. 本地文件友好：很多企业资料仍然以文档形式流转。

建议从 WPS官网 获取最新开发文档，并通过 WPS下载 安装正式版。版本过旧时，部分 JSAPI 和加载项能力可能不可用。

2. 总体架构

我的架构分为四层：

• WPS 客户端：运行加载项，展示任务窗格，读写文档。
• 本地网关：Node.js 或 Python 服务，负责 API Key、提示词模板、缓存、审计。
• 大模型服务：负责理解、生成、函数调用规划。
• 知识库：可选，用向量检索注入企业规范、模板和历史文档。

调用链如下：

用户操作 -> WPS 加载项 -> 本地网关 -> 大模型 -> 结构化结果 -> WPS 加载项写回文档。

核心原则是：大模型不直接碰文件，所有写操作都由 WPS 侧执行。这样安全边界清晰，也方便撤销和审计。

3. 接入方式选型

我评估了四种方式：

1. JS宏：适合原型，WPS 内置宏编辑器，但网络请求和 UI 能力有限。
2. WPS 加载项 wpsjs：用 HTML、CSS、JavaScript 开发任务窗格，体验接近现代 Web 应用，推荐。
3. COM 自动化：Windows 下用 Python 或 C# 控制 WPS，适合批处理，但跨平台弱。
4. 开放平台 API：适合云端文档处理，和本地客户端结合时需要额外同步。

最终我选择 wpsjs 加载项 + Python FastAPI 本地网关。开发前先到 WPS官网 查阅 JSAPI，再用 WPS下载 更新客户端。

4. 核心代码示例

4.1 WPS 加载项调用本地网关

async function askLLM(prompt) {
  const res = await fetch('http://127.0.0.1:8787/chat', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ prompt: prompt })
  });
  return await res.json();
}

async function polishSelection() {
  const app = wps.WpsApplication();
  const range = app.Selection.Range;
  const text = range.Text;
  const result = await askLLM('请润色以下文字：' + text);
  range.Text = result.content;
}

注意：不同 WPS 版本的 JSAPI 对象名可能略有差异，以 WPS官网 文档为准。

4.2 Python 网关

from fastapi import FastAPI
from pydantic import BaseModel
import openai

app = FastAPI()

class ChatRequest(BaseModel):
    prompt: str

@app.post('/chat')
def chat(req: ChatRequest):
    resp = openai.ChatCompletion.create(
        model='gpt-4o-mini',
        messages=[
            {'role': 'system', 'content': '你是办公写作助手'},
            {'role': 'user', 'content': req.prompt}
        ]
    )
    return {'content': resp.choices[0].message.content}

生产环境不要把 API Key 写进代码，应放在环境变量或密钥管理服务中。

5. 让大模型理解 WPS 文档上下文

只发送选中文本是不够的。要让模型理解文档，需要构造结构化上下文：

• 文字文档：段落样式、标题层级、选区文本、前后文。
• 表格：工作表名、表头、行数据、公式、选区范围。
• 演示文稿：幻灯片标题、正文、备注、版式。
• 用户意图：润色、总结、翻译、生成周报、审查合同等。

可以用 YAML 或 JSON 描述上下文：

app: wps
doc_type: writer
selection: 这里是选中的文字
outline:
  - 一级标题
  - 二级标题
tables:
  - name: Sheet1
    headers:
      - 日期
      - 销售额
    rows:
      - [2024-01-01, 1000]
user_intent: 生成周报

然后通过 Function Calling 暴露工具：

• read_document：读取文档结构。
• write_selection：写入选区。
• insert_table：插入表格。
• replace_text：替换文本。
• create_slide：创建幻灯片。

模型返回工具调用请求，本地网关校验参数后交给 WPS 执行。这样大模型负责推理，WPS 负责文档操作。

6. 典型实验场景

6.1 周报生成

从 WPS 表格读取本周数据，让模型总结关键指标，再写入 WPS 文字模板。整个过程可以一键完成。

6.2 合同审查

把合同条款分段发送给模型，让模型识别风险点，并在 WPS 中添加批注。注意敏感信息要脱敏，或者改用本地模型。

6.3 Excel 公式解释

选中公式后，让模型解释含义，并生成替代公式。对复杂嵌套公式特别有用。

6.4 PPT 大纲生成

读取文字文档的标题和段落，生成幻灯片大纲，再调用 WPS 接口创建页面。

6.5 公文润色

保持正式语气，统一术语，检查错别字。大模型可以给出 diff，WPS 侧做高亮和接受/拒绝。

7. 工程化问题

把 Demo 变成可用工具，需要解决很多工程问题：

• 上下文窗口：只发送必要内容，长文档先分段摘要。
• 流式输出：用 SSE 或 WebSocket，让 WPS 任务窗格逐步显示结果。
• 错误处理：超时、限流、重试、降级到小模型。
• 缓存：对相同 prompt 和文档哈希做缓存，降低成本。
• 权限：本地网关做鉴权，WPS 加载项只访问必要接口。
• 审计：记录谁在什么文档上执行了什么操作，支持撤销。
• 成本：分类和路由用小模型，复杂生成用大模型。
• 隐私：敏感文档本地处理，或者只发送脱敏片段。

这些设计比模型本身更重要。

8. 部署与分发

开发完成后，把加载项打包，通过企业内部分发。团队成员需要 WPS下载 并安装客户端，推荐从 WPS官网 获取正式版本，避免兼容性问题。

本地网关可以用 Docker 部署：

FROM python:3.11-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .
CMD uvicorn main:app --host 0.0.0.0 --port 8787

如果企业有多人使用，网关需要加认证、限流和日志。API Key 放在服务端，不能下发到客户端。

9. 效果与反思

实验上线后，最明显的收益是：

• 周报从 30 分钟缩短到 5 分钟。
• 表格分析可以在 WPS 内直接完成。
• PPT 初稿效率提升明显。
• 合同审查更规范，风险条款不容易遗漏。

但也有反思：

1. 大模型不是替代人，而是办公自动化中的推理组件。
2. WPS 的价值在于文档对象模型和生态，AI 需要和它深度结合。
3. 安全、权限、审计必须在第一版就考虑。
4. 提示词要模板化，输出要结构化，否则很难工程化。

未来我计划接入 RAG 企业知识库、多模态图片表格识别和本地小模型，让 WPS 成为真正的 AI 办公入口。

10. 结论

把 WPS 接入大模型，是一个可行且高价值的实验。你可以从 WPS官网 获取开发文档，完成 WPS下载 和安装，先用 JS宏 或 wpsjs 做原型，再逐步工程化。核心原则是：大模型负责推理，WPS 负责文档，本地网关负责安全与编排。

对于软件工程师来说，这不只是效率工具，更是一次把日常办公变成可编程工作流的机会。当 WPS 和大模型结合，文档不再只是静态文件，而是可以理解、生成和执行任务的智能界面。