【VS Code插件】Office加载项开发工具包

一、项目概况

Office Add-ins Development Kit 是由微软 OfficeDev 团队开发的 Visual Studio Code 扩展，托管于 GitHub（https://github.com/OfficeDev/OfficeAddinDevKit），旨在为 Office 加载项（Office Add-ins）开发者提供一站式的项目创建、调试和部署体验。该项目创建于 2024 年 7 月 17 日，以公共预览版形式于 2024 年 8 月 20 日发布（v0.5.0），2024 年 12 月 19 日正式发布 v1.0.0。关键数据如下：

二、Office 加载项平台背景

Office 加载项（Office Add-ins）是微软于 2013 年推出的扩展平台，允许开发者使用 HTML、CSS 和 JavaScript 等 Web 技术构建跨平台（Windows、macOS、Web、iPad）的 Office 扩展。与 VBA 宏不同，Office 加载项运行在嵌入于 Office 应用程序的 WebView 容器中，通过 Office JavaScript API（https://learn.microsoft.com/office/dev/add-ins/develop/office-javascript-api）与宿主应用交互，支持任务窗格（Task Pane）、内容加载项（Content Add-in）和自定义函数（Custom Functions）三种基本类型。

Office 加载项的技术架构决定了其具备 VBA 不具备的跨平台和沙箱安全优势，但同时也带来了开发体验上的挑战：开发者需要在 VS Code 中编写 Web 应用代码，同时在 Office 客户端中测试和调试加载项的运行效果，这种"双环境切换"的开发模式效率较低。Office Add-ins Development Kit 正是为了解决这一痛点而诞生的。

三、核心功能

3.1 项目创建脚手架

安装扩展后，用户在 VS Code 活动栏（Activity Bar）中点击 Office Add-ins Development Kit 图标，选择"Create a New Add-in"，即可通过交互式向导创建项目。向导引导用户依次选择：目标 Office 应用（Excel、Word、PowerPoint、Outlook）→ 加载项模板类型 → 编程语言（JavaScript 或 TypeScript）→ 工作区文件夹 → 项目名称。创建完成后，扩展自动生成包含 manifest.xml、HTML/CSS/JS 源文件和调试配置的完整项目结构，并在新窗口中打开。

这一脚手架功能的核心价值在于降低了 Office 加载项的入门门槛。在此之前，开发者需要手动配置 manifest.xml、搭建本地 Web 服务器、配置 Office 客户端的信任设置，流程繁琐且容易出错。

3.2 本地调试与预览

扩展提供一键启动调试功能（支持 F5 快捷键）。点击"Preview Your Office Add-in"后，扩展自动完成以下流程：检查开发环境前置条件（Node.js 版本、Office 连接状态）→ 启动本地 Web 服务器 → 在 Office 桌面应用中侧载（sideload）加载项 → 打开 Edge DevTools 调试窗口。调试结束后，"Stop Previewing"命令会关闭 Web 服务器并清理注册表和缓存中的加载项条目。

这一功能将原本需要多步骤手动操作的调试流程封装为单次点击，显著提升了开发效率。调试过程支持 Edge Chromium 的完整开发者工具链（DOM 检查、网络监控、控制台日志等），同时也支持在 Office on the Web 上进行远程调试。

3.3 清单验证与示例浏览

扩展内置 manifest.xml 验证功能，可在项目创建和修改时快速检测清单文件中的语法错误和配置问题。此外，"View Samples"命令提供了多个官方示例项目，覆盖常见开发场景（数据绑定、图表操作、邮件集成等），开发者可直接克隆示例作为项目起点。

3.4 CLI 支持

除图形界面外，扩展还支持命令行接口操作。用户可在 VS Code 集成终端中通过命令面板（Ctrl+Shift+P）搜索"Office"关键词发现所有可用命令，也可以直接在终端中执行 npm run start 等项目脚本，适合偏好键盘操作的开发者。

四、技术架构

Office Add-ins Development Kit 本身并非一个庞大的运行时框架，而更像是一个围绕 Office 加载项开发工作流的"胶水层"。其技术架构可归纳为以下几个层面：

项目模板层。 扩展内置了一套基于 Yeoman Generator（https://learn.microsoft.com/office/dev/add-ins/develop/yeoman-generator-overview）的项目模板，每种目标应用 × 模板类型 × 编程语言组合对应一个独立的项目骨架。模板中预配置了 webpack 构建脚本、Office JavaScript API 的 TypeScript 类型声明和调试启动配置。

调试桥接层。 调试功能的核心是打通 VS Code 的 Debug Adapter Protocol（DAP）与 Office 客户端的加载项运行时之间的连接。扩展在后台启动一个本地 HTTPS Web 服务器，将项目构建产物托管在该服务器上，然后通过 Office 的侧载机制将加载项 URL 注入到 Office 客户端。当用户在 Office 中操作加载项时，运行时错误和日志会通过 WebSocket 传递回 VS Code 的调试控制台。

清单管理层。 manifest.xml 是 Office 加载项的核心配置文件，定义了加载项的显示名称、权限范围、默认页面 URL 和支持的宿主应用等信息。扩展提供的验证功能基于 XML Schema 校验，确保清单文件符合 Office 平台的格式要求。

五、退役原因分析

2026 年 5 月 20 日，微软正式宣布该工具退役。

退役原因可能有以下两点：

微软平台战略转向。 微软正在推进"统一清单"（Unified Manifest for Microsoft 365）标准，试图将 Office 加载项、Copilot 插件和 Teams 扩展统一到同一套清单格式下。为此，微软推出了 Microsoft 365 Agents Toolkit作为新一代开发工具，取代原有的加载项专用工具链。Office Add-ins Development Kit 作为"旧清单"时代的产物，其退役是平台战略演进的必然结果。

GitHub Stars 仅 8 颗。 作为一个由微软官方背书的 VS Code 扩展，8 颗 Star 的社区参与度远低于预期。这说明 Office 加载项的开发者群体规模有限，且该群体的开发工具选择更多依赖微软官方文档中的推荐流程（如直接使用 Yeoman Generator），而非通过 VS Code 扩展发现。

微软在 README 中推荐用户转向两个替代方案：针对使用统一清单（Unified Manifest for Microsoft 365）的加载项，推荐使用 Microsoft 365 Agents Toolkit；针对使用传统加载项清单的加载项，推荐使用 Yeoman Generator for Office Add-ins。

传统加载项清单（Only Add-in Manifest）是 Office 加载项平台自 2013 年推出以来使用的清单格式，文件名为 manifest.xml，采用 XML 格式。每个 Office 加载项都必须有一个清单文件来描述自身特征：

• 加载项的 ID、版本、显示名称、描述

• 加载项与 Office 的集成方式（自定义功能区、任务窗格等）

• 所需的权限和要求集（Requirements Sets）

• 图标、图像等品牌资源

传统清单总计有 7 个 XML Schema 版本，随着 Office JavaScript API 的演进不断更新。它仅适用于 Excel、OneNote、Outlook、PowerPoint、Project 和 Word 六种 Office 应用，不能与其他 Microsoft 365 扩展类型（如 Teams 应用、Copilot 插件）组合使用。

开发工具链：Yeoman Generator for Office Add-ins (Yo Office) + 传统 manifest.xml。

统一清单（Unified Manifest for Microsoft 365）是微软正在推进的新一代清单标准，采用 JSON 格式。它的核心目标是打破扩展类型的壁垒：

• 一个 JSON 清单文件，可以同时描述 Office 加载项、Teams 应用、Copilot 插件、Message Extensions 等多种 Microsoft 365 扩展

• 这些扩展可以作为一个单元打包、安装和管理

• 统一清单只有 1 个 Schema（而非传统清单的 7 个）

开发工具链：Microsoft 365 Agents Toolkit（前身为 Teams Toolkit），基于该工具创建的项目默认使用统一清单。

选择传统清单的场景

• 项目需要尽快上线到生产环境，传统清单在所有 Office 客户端和平台上均已获得完整支持，不存在兼容性风险

• 仅开发纯 Office 加载项，不需要 Teams 集成、Copilot 插件等扩展类型

• 对微软平台变动敏感，统一清单仍在演进中，Schema 和工具链可能还会调整

• 已有 XML 清单项目需要维护，迁移成本高且收益有限时

选择统一清单的场景

• 项目面向 Microsoft 365 全生态，需要同时覆盖 Office 加载项、Teams 选项卡、Copilot 插件等

• 新项目从零开始，直接采用统一清单可以面向未来

• 需要单一打包单元，希望将多种扩展能力作为一个应用发布到 Microsoft AppSource

• 愿意接受预览状态的部分不确定性

六、对 WPS 的启示

避免依赖单一平台标准。 微软频繁调整加载项平台标准（从传统 manifest 到统一清单），导致开发工具链不断重构。WPS 插件应基于自身稳定的 JS 插件 API 构建，不跟随微软的清单格式变更而调整。

重视开发工具链的价值。尽管该扩展退役，但在 VS Code 中开发 Office 扩展仍然具有极大价值。WPS 官方插件应当包含 JS 插件开发脚手架、调试通道和发布向导，并建立在更稳定的 WPS JS 插件 API 之上。

工具链 + 文档预览的双层覆盖。 WPS 官方插件应当将开发工具链与文档预览能力统一在同一个扩展中，功能覆盖上更全面。

七、延伸阅读

• Office Add-ins 官方文档：https://learn.microsoft.com/office/dev/add-ins/overview/office-add-ins

• Microsoft 365 Agents Toolkit：https://learn.microsoft.com/office/dev/add-ins/develop/agents-toolkit-overview

• Yeoman Generator for Office Add-ins：https://learn.microsoft.com/office/dev/add-ins/develop/yeoman-generator-overview