我十年 Office 开发的终极大招：一个 Skill，让 AI 帮你做出最专业的 Excel 插件

不是写 VBA 宏，不是画 Ribbon 菜单。是一口气搞定：自定义函数、现代化功能区、WebView2 网页面板、媲美前端界面的 WPF 任务窗格——全程一行代码不用写。这就是我刚做完的 Excel-DNA 插件开发 Skill。

一、为什么我一直在做 Office 和浏览器周边的工具？

回看过去这一年，我一共做了八套 Skill：

你看出规律了吗？

全部围绕两个东西：Office 办公软件 和 浏览器。

这不是巧合。这是我作为一个在 Office 开发领域深耕了十年的老兵的判断——

面向零基础用户的 AI 开发，最有价值的方向不是做一个全新的 App，而是在他们天天用的工具上，长出他们刚好需要的新功能。

打开电脑，你最常用的软件是什么？Excel、WPS、浏览器。这三样东西，是你每天工作上"物理距离最近、打开频率最高、操作习惯最熟"的工具。

如果新功能直接嵌在这些你天天用的工具里，省掉的是"打开另一个软件 → 切换窗口 → 操作完 → 切回来"的全部摩擦。这就是我一直在说的"最短路径"——让功能长在离你最近的工具上。

但做到这一步，光靠 VBA 够吗？

不够。

二、从 VBA 到 Excel-DNA：一次本质性的技术升级

VBA 是我之前 Skill 体系里 Office 插件开发的唯一方案。它确实好用——原生嵌入、随文件分发、开发简单。

但做了这么多 VBA 项目，我太清楚它的天花板在哪：

而 Excel-DNA，几乎完美解决了以上所有问题。

三、什么是 Excel-DNA？为什么我在众多方案里选了它？

Excel 二次开发有很多技术路线：VSTO、COM Add-in、JavaScript API、VBA、Excel-DNA。

我最后选了 Excel-DNA，原因很简单——它是我能找到的唯一一个，同时在四个维度上都做到极致的选择：

维度一：.NET 语言全覆盖

VSTO 和 COM Add-in 的开发体验非常痛苦——你被锁死在 .NET Framework 4.6.2/4.8 这些老框架上，C# 写了一大堆，想用 record、Span<T>、System.Text.Json 这些新特性？不好意思，不支持。

Excel-DNA 完全不一样。 它支持 .NET 6、.NET 7、.NET 8，甚至最新的 .NET 11。你可以使用 .NET 生态里所有最新、最强大的能力——高性能 JSON 序列化、原生 DI 容器、System.CommandLine 命令行框架……一切 .NET 世界里最好的东西，你都能往 Excel 插件里塞。

这意味着什么？你的 Excel 插件，不再是一个"上世纪的遗产系统"，而是可以像做现代后端服务一样，用最前沿的技术栈去构建。

维度二：WebView2 前端集成

这是我最看重的能力之一。Excel-DNA 可以通过 CTP（Custom Task Pane，自定义任务窗格）在 Excel 侧边栏嵌入一个完整的 WebView2 窗口。

这是什么概念？你可以在 Excel 里跑一个完整的网页应用。

想用 Vue/React/Angular 写一个数据看板，嵌在 Excel 侧边栏？可以。想做一个可视化的图表配置器，拖拽选字段，自动生成 Excel 图表？可以。想连接你的内部系统 API，数据直接从线上拉到 Excel？可以。

VBA 做不到的、VSTO 做起来很吃力的，Excel-DNA 在一个窗格里全搞定了。

维度三：自动化能力无上限

因为跑的是完整 .NET，你可以做：

• 读取网页内容：HttpClient + HtmlAgilityPack，批量抓取、解析、入表
• 浏览器脚本自动化：通过 WebView2 的 DevTools Protocol，在你自己的插件里操控浏览器
• 调用任何 REST API：对接 AI 模型、企业内部系统、第三方平台
• 操作本地文件和数据库：读写本地文件、连接 SQLite/SQL Server，全本地跑

VBA 做这些事，要么干不了，要么代码写得极其痛苦。Excel-DNA 一行 await httpClient.GetAsync() 就解决了。

维度四：本地权限全覆盖

作为桌面插件，Excel-DNA 能调用 Windows 的全部能力：

• 文件系统读写、注册表操作
• Windows API 调用（P/Invoke）
• 进程管理、服务控制
• 剪贴板高级操作
• 多线程并行计算

它不像 Web Add-in 那样被浏览器沙箱限制，也不像 VBA 一样单线程跑。它就是一台装着 .NET 引擎的本地超级客户端，而 Office 只是它的宿主。

唯一不完美的地方：不能跨平台

是的，Excel-DNA 只能在 Windows 上跑。Mac 用户用不了。

但说实话——在 Windows 上的 Office 二次开发领域，我实在找不到比它更强的选择了。

四、如果你做过 VSTO，看完这节你会坐不住

前面说到 VBA 的天花板。但我知道，关注我这个号的读者里，有一部分人已经超越了 VBA——你们在用 VSTO 做 Excel 插件开发。

如果你是这个群体，这一节是专门写给你的。因为看完之后你会发现：VSTO 给你设了太多天花板，而 Excel-DNA 几乎全拆了。

VSTO 开发者最痛的五件事

做过 VSTO 的都懂，以下这些场景你一定经历过：

痛一：部署是噩梦。 你辛辛苦苦写了一个插件，要发给用户。然后你发现——用户电脑上必须先装 VSTO Runtime，Office 版本要匹配，还要用 ClickOnce 或者 MSI 安装包打个半天。用户双击你的安装包，Windows 弹出各种安全警告，装完之后还要去 COM 加载项里勾选启用。一个插件安装，能劝退一半用户。

痛二：你被锁在 .NET Framework 4.x 的监狱里。 VSTO 绑定 Office 自带的运行时，最高就到 .NET Framework 4.8。C# 都出到 13 了，你还在写 2019 年的语法。想用 record 类型？不支持。想用 Span<T> 高性能内存操作？不支持。想用 System.Text.Json 的高性能序列化？不支持。

痛三：自定义函数（UDF）是个伪命题。 VSTO 做插件本质上是一个 COM Add-in，它能操控 Excel 界面和对象模型，但它不支持自定义工作表函数。你想写一个 =MySuperFormula(A1:B10) 让用户在单元格里直接调用？VSTO 做不到。你得绕道用自动化插件（Automation Add-in），那是另外一套完全不同的技术栈，而且功能受限严重。

痛四：用户必须单独安装 VSTO Runtime。 插件本身不大，但它强依赖 VSTO Runtime。普通用户的机器上大概率没装这个东西，你得要么在安装包里附带 Runtime，要么让用户自己去微软官网下载安装。多一道门槛，就多一层劝退。

痛五：RTD 实时数据流完全没概念。 想在单元格里展示实时变动的数据（股价、传感器读数、消息推送）？VSTO 只能靠定时轮询来模拟，又慢又卡。原生的 RTD（Real-Time Data）机制，VSTO 根本不支持。

Excel-DNA 怎么一招一招破掉这些痛点

下面这张表，请做 VSTO 的朋友仔细看：

重点展开：三个 VSTO 开发者最会心动的能力

1. RTD 流式函数——VSTO 完全没有的东西

这是 Excel-DNA 相对 VSTO 最不讲武德的能力。RTD（Real-Time Data）允许你写一个函数，让数据自己往单元格里推。

什么意思？你写一个 =LIVE_STOCK("000001")，这个单元格就自动显示实时股价，每秒刷新。你写一个 =LIVE_CLOCK()，单元格里就是一个跳动的时钟。后台跑着的是一个 RTD 服务器，数据源可以是 WebSocket、MQTT 消息队列、串口传感器数据——任何实时流，都能推送到 Excel 单元格。

VSTO 做不到这个。 在 VSTO 里你要实现类似效果，要么用 Application.OnTime 定时轮询（又慢又卡），要么用 COM 事件监听（不稳定且复杂）。而 Excel-DNA 的 RTD 是 OS 级别的原生推送，不用轮询，不卡界面。

2. 异步 UDF——函数计算时，Excel 不再卡死

VBA 和 VSTO 都有的一个体验：如果你写了一个计算很重的自定义函数（比如调 AI 接口分析文本），Excel 整个界面就卡住了——鼠标转圈、无法操作、只能等。

Excel-DNA 的异步 UDF：函数在后台跑，Excel 照常用。函数计算期间，单元格显示"数据加载中……"（文案你可以自己定制），结果回来了自动填入。

50 个单元格同时调用？没问题。Skill 模板里内置了受控并发机制，用 SemaphoreSlim 限制同时请求数，不会把后端接口打爆。

3. QueueAsMacro——后台线程安全操作 Excel 的正确方式

在 VSTO 里，你想在后台线程中往单元格写数据，必须手动 Control.Invoke 切回 UI 线程。写错一步，要么报 COM 异常，要么静默失败。

Excel-DNA 的 QueueAsMacro：你把要做的 Excel 操作包成一个 Action，往队列里一扔，它自动排队到 Excel 主线程执行。线程安全、不会冲突、不会漏操作。一行代码，永久告别 COM 线程地狱。

一个灵魂拷问

你可能会问："VSTO 好歹是微软亲儿子，有官方支持，Excel-DNA 是开源项目，稳不稳？"

我的回答是：Excel-DNA 已经稳定运行了十几年，全球有数十万开发者在用。 全球最大的量化金融公司（Bloomberg、Goldman Sachs）都在用它做 Excel 金融插件。它不是"替代 VSTO 的新玩具"——它是"比 VSTO 更强大、更现代、但国内知道的人太少"的隐藏神器。

而且别忘了，我这套 Skill 里集成的不是普通 Excel-DNA，是我亲手编译、针对 WPS 个人版做了底层适配的增强版。你在别的地方拿不到这个。

又一个灵魂拷问：32 位还是 64 位？

做过 Excel-DNA 功课的人可能还有一个顾虑："VSTO 可以 Any CPU，一套就够了。Excel-DNA 要区分 32 位和 64 位的 xll。我怎么知道用户的 Office 是哪个位数？难道还要用户自己去查，然后再选一个版本下载？"

这个担心完全合理。传统的 Excel-DNA 部署确实有这个痛点——你得打包两份 xll（一个 32 位、一个 64 位），然后告诉用户"你先去文件→账户→关于 Excel 里看看你的 Office 是 32 位还是 64 位，再下载对应的安装包"。

光这一步，就能劝退 90% 的普通用户。

但我这套 Skill 已经把这个门槛打没了。

具体怎么做到的？Skill 生成的安装包只有一个 bat 文件，用户双击就行。bat 背后做的事情是：

1. 自动检测宿主 Office 的位数 — PowerShell 脚本直接读注册表，判断当前机器上的 Excel 或 WPS 是 32 位还是 64 位

2. 自动选择对应的 xll — 32 位就走 ExcelDna.xll，64 位就走 ExcelDna64.xll

3. 自动写入注册表加载项 — 一条命令完成插件注册，Office 启动自动加载

用户什么都不用管。双击 → 完成。

而且这里还有一个企业用户特别关心的细节：很多公司有 IT 管控，不允许员工安装 exe 文件。 VSTO 的安装包是 exe 或 MSI 格式，在这种环境里直接卡死。但我的方案是 bat 挂 PowerShell 脚本——纯脚本安装，没有任何 exe 安装包，完美绕过企业网络管控。

Excel-DNA 在部署上比 VSTO 多出来的那个"32/64 位选择"的复杂度，我在 Skill 里已经全部自动化消除了。你拿到手的就是"双击即装"，跟 Any CPU 没有区别。

不只是纸上谈兵——这套技术我亲手验证了五年

写到这，你可能觉得"说得挺好，但有人真正用这套东西做出过商业产品吗？"

我本人就是最好的案例。

我自己开发并运营了一款基于 Excel-DNA 的图表插件 EasyShu，已经稳定迭代了五年。它能把 Excel 原生图表的能力拉升到一个全新的高度——复杂组合图表、专业配色体系、一键出图模板——不管是功能深度还是交互体验，放在国内乃至国际范围内，都是顶流水平。

EasyShu 6.7 版本发布，有始有终，迭代不断，2025 年打造最强 AI+ 图表应用方案，圆满结束

这不是我吹牛。五年真实用户、持续付费、持续迭代——Excel-DNA 到底能干什么、上限在哪、坑在哪，没有人比我更清楚。

正因为我亲自踩过了这五年里所有的坑，所以现在这套 Skill 里的每一条规则、每一个脚本、每一段模板代码，都不是"理论上可以这样做"，而是"我就是这样做的，而且已经跑了五年没出过问题"。

Skill 帮 AI 写出来的插件，跟你自己花几万块定制的商业插件，是同一套骨架。

五、WPS 适配：从众筹项目到一人独行，我把最难啃的骨头啃下来了

聊完 Excel-DNA 本身，我必须讲一个背景故事。因为这关乎这套 Skill 里最硬核的部分——WPS 适配。

四年前的众筹：三十多人合力，让旧版 Excel-DNA 跑在 WPS 上

2022 年，我在国内 Office 开发圈发起了一个众筹项目：把 Excel-DNA 适配到 WPS 个人版。

为什么要做这件事？因为 WPS 个人版有一个"白名单机制"——加载 COM 插件时，必须提前在注册表里写入插件的 CLSID。而原版 Excel-DNA 用的是动态 CLSID 注册，每次加载生成的 CLSID 都不一样，WPS 个人版根本不认。

不解决这个问题，你用 Excel-DNA 开发的所有插件，在 WPS 个人版上全部歇菜。而国内用 WPS 个人版的用户，数以亿计。

那次众筹三十多人参与，众筹金额 5000 元，我是发起人，也是最大出资方。我找了社区一位技术领袖，用两周时间修改了 Excel-DNA 底层代码，把动态 CLSID 改成固定注册机制。最终项目开源在了 Gitee 上——excel-dna-for-wpspersonal。

但那毕竟是旧版本。 当时的 Excel-DNA 跑在 .NET Framework 4.x 上，是上一个时代的产物。

这一次，没有外援，全程自己搞

四年后，当我决定把最新版 Excel-DNA 做成 Skill 时，摆在面前的第一道坎就是：新版 Excel-DNA 已经全面转向 .NET Core（.NET 6/8），底层架构跟四年前那个老版本完全不同，WPS 适配要从头再来。

而且这一次，没有众筹团队，没有外援。全程一个人。

我亲手编译了 Excel-DNA 的底层——XLL 和 DLL 全部自建

让最新版 Excel-DNA 完美适配 WPS 个人版，不是改几行配置就完事的。我来告诉你我都做了什么：

第一步：编译 Excel-DNA 的 C++ 底层宿主——xll 文件。

Excel-DNA 的核心是一个叫 ExcelDna.Host 的 C++ 原生工程。这个工程编译出来就是 .xll 文件——Excel 加载插件的入口。没有它，一切免谈。

C++ 编译有多难？光是把 Visual Studio 的 PlatformToolset 从仓库默认的 v143 对到我本机的 v145，就花了半天。x64 编译时 ml64.exe 卡住，还得手工用 MASM 汇编器单独编 exports64.obj。最坑的是——整个 C++ 工程不能放在中文路径下，否则 unity 编译阶段直接乱码，链接失败。我不得不把工程拷到一个全 ASCII 路径（D:\AI_skill_ascii）下才能编译通过。

第二步：编译 Excel-DNA 的 .NET 托管层——ManagedHost、Loader、Integration DLL。

这一层是 Excel-DNA 的"大脑"，负责加载你写的 .NET 插件代码。我必须确保它编译成 net6 版本，因为 .xll 内嵌的运行时宿主只会加载对应版本的托管 DLL。一旦 TargetFramework 混搭了 net6 和 net8，Excel 打开直接卡后台或闪退——没有任何错误提示，就是崩。

就这个问题，我排查了整整两天。

建立官方 NuGet 最小工程做对照、逐步排除 IntelliSense 浮动版本干扰、对比 xll 内嵌资源和外置 DLL 的加载优先级……反复试错，最终才定位到：自编的 .xll 里内嵌的 ManagedHost 是 net8 的，但 .dna 配置文件引用了 net6 的运行时路径。加载链路断裂，宿主进程直接退出。

修好之后，我又手工把 Excel-DNA 仓库从多目标框架收缩到只保留 net6，统一版本号为 1.9.1，确保 C++ 宿主和 .NET 托管层的运行时版本完全一致。

这一步意味着什么？

在国内 Office 二次开发领域，能做到这一步的人，屈指可数。

不是因为技术高不可攀——而是这条路太窄、太偏、太苦。你需要同时懂 C++ 编译和 .NET Core 运行时机制，需要熟悉 Excel 的 xll 加载协议和 WPS 的白名单注册表机制，还需要有耐心在中文路径编码、PowerShell 5.1 BOM 标记、C++ unity build 乱码这些非技术性的烂坑里反复扒。

但我做完了。

作为国内 Office 开发圈的意见领袖，我亲手把最新版 Excel-DNA（.NET Core）完美适配了 WPS 个人版。

这不是花钱外包能做到的事，也不是找个人随便搞搞能搞定的事。这是实打实的底层编译，是对 Excel-DNA 和 WPS 两个体系的深度理解。

而现在，我把这一切全部封装进了 Skill 里。 你不需要知道什么是 xll、什么是 C++ 编译、什么是托管宿主版本对齐——AI 读 Skill 后，自动生成的项目天然就能同时在 Excel 和 WPS 个人版上完美运行。

六、十年经验全塞进一个 Skill：完整的自动化工程体系

说了这么多 Excel-DNA 的能力，但这一切和 Skill 有什么关系？

关系大了。

Excel-DNA 强，不代表它好上手。 恰恰相反，Excel-DNA 的开发体验对新手极其不友好：

• 要同时理解 .NET 项目结构、xll 配置、dna 文件、Ribbon XML
• CTP 定制任务窗格的 API 分散在多个命名空间，文档匮乏
• WPS 兼容需要额外处理——ProgId、Guid、白名单、图标透明度，每个都是坑
• .NET 版本选择和 RollForward 策略选错了，插件直接起不来
• 打包部署没有标准工具链，全靠自己摸索

这些坑，我这十年几乎全踩过。

我以前做 VBA 插件、做 COM Add-in、做 Excel-DNA 项目，每一次都重新踩一遍。现在我做这套 Skill，就是把我踩过的每一个坑、总结的每一条经验，全部固化下来。

这套 Skill 不是一个"告诉你 Google 该怎么搜"的指引。它是一个完整的自动化工程体系：

四大核心脚本

两套项目蓝图

11 篇参考文档

从需求澄清、项目结构决策、HandyControl 控件集成、构建验证、安装验收——每一步 AI 需要知道的知识，都有对应的专项文档。

全套 HandyControl 官方文档镜像

87 个扩展控件 + 36 个原生控件的完整文档，AI 直接查阅，生成的界面控件不会用错。

这就是 Skill 和"一段提示词"的区别：前者是铺好路的自动化工程，后者是让 AI 摸着石头过河。

七、连界面都帮你做好了——HandyControl + WPF

说到 Excel 插件的界面，这也是我一直想突破的一个大痛点。

做 Office 二次开发的人都知道，内置的 UserForm 有多丑——方方正正的灰色窗口、锯齿感明显的控件、缩放一下就变形。你用 VBA 写的功能再强，用户打开那个窗体的第一眼就在心里扣分了。

而我这套 Skill 里，界面用的是 WPF + HandyControl。

HandyControl 是什么？它是国内最流行的 WPF 开源控件库之一，Star 数过万，内置：

• 36 种原生控件的增强版（Button、TextBox、ComboBox、TabControl……全部现代化重绘）
• 87 个扩展控件（Growl 全局通知、StepBar 步骤条、Tag 标签、PropertyGrid 属性面板……）
• 多套主题皮肤：深色/浅色一键切换
• 7 色内置 Accent 预设：红/橙/金/绿/蓝/紫/默认，下拉就能换

而且这不是简单的"模板里有几个按钮示范"。我这套 Skill 做的是：

• 全局主题统一注入：不是每个控件自己手动设颜色，而是通过 Application.Resources 全局统一下发
• 设计期智能提示：加了 DesignTimeResources.xaml，你在 VS 设计器里也能看到 HandyControl 的样式预览
• 7 色 Accent 预设下拉：在任务窗格里直接切换，不用看代码，实时预览
• Growl 全局通知封装：一条调用，右下角弹出精美通知

这些看起来像是"IDE 插件才该做的事"，但我全部做进了 Skill 的模板里。你不需要知道什么是 Application.Resources、什么是 ResourceDictionary.MergedDictionaries——AI 读完模板，自动按这套模式生成。

做出来的界面长什么样？ 圆角按钮、毛玻璃导航栏、渐变进度条、流畅窗口缩放、全局主题一键切换——拿出去给别人看，完全不会觉得是"Excel 插件"，更像是花好几万外包开发的前端系统。

八、13 轮迭代：从图标透明到 xll 崩溃，我把所有坑填平了

写到这里，我想让大家看到我对这套 Skill 的用心程度。

从开始做到现在，这套 Skill 经历了 13 轮深度迭代，从 0.1.0 一路干到 0.2.8。不是那种"改个文案、加个功能就发版本"的迭代——每一次都是真实的踩坑、排障、验证，然后把经验固化进 Skill 的规则和脚本里：

最难的一次，是排查 xll 编译导致的 Excel 闪退。 过程漫长到我自己回头看都觉得变态——先是怀疑 TargetFramework 配错、然后怀疑 IntelliSense 浮动版本导致运行时混搭、再怀疑 LoadFromBytes 模式、又怀疑外置 DLL 劫持了加载路径……一步步排除，最后才定位到：

PowerShell 5.1，UTF-8 without BOM 的.dna 文件被当作 ASCII 读，嵌套了乱码的引用路径，导致 IntegratedAssemblyLoad 阶段直接抛异常，整个宿主进程退出。

我把整个过程——包括建立官方 NuGet 最小工程做对照验证、用 OFFICIAL_HELLO 项目跑可行性确认、最终收敛到"只留两个 xll 文件 + 编译期走 NuGet 流程"——全部写成了 CHANGELOG.md 和对应的 references 文档。

这些坑，以后用这套 Skill 的人一个也不用踩。 因为它们已经被我变成了一套又一套的"自动化规则"——AI 读完之后，自动避开。

九、除了不能跨平台，几乎没有任何缺点

让我把所有能力重新梳理一遍。用这套 Skill 做出来的 Excel 插件，具备的能力是：

💻 核心能力

🔌 可嫁接的能力

🎨 界面能力

除了不能跨平台（Mac 不支持），这个方案的缺点我实在想不出来了。

而且这个"不能跨平台"也不是 Excel-DNA 的问题——它受限于 xll 基于 Win32 C++ 宿主的底层架构。但反过来想，对 Windows + Office 用户来说，这正是"性能最强、权限最全"的底层保证。

十、和 VBA Skill 的关系：不是替代，是组合拳

有人可能会问："你之前做了 VBA Skill，现在又做 Excel-DNA Skill，到底用哪个？"

我的回答很简单：看场景。

VBA 和 Excel-DNA，不是谁替代谁的关系。 VBA 负责"轻量、快速、随文件走"，Excel-DNA 负责"高性能、高界面、高权限"。两套 Skill 组合起来，就是 Office 开发的完整武器库。

十一、免费，欢迎打赏

这是我的铁原则，从第一套 VBA Skill 到现在第七套，一个字没变过：

高质量的东西不一定要收费。

从 VBA 到 Python 到 .NET 到飞书多维表格到 WPS 多维表格到浏览器插件到图标到 Excel-DNA——八套 Skill，全部免费开放。

不收割韭菜，不贩卖焦虑，不搞知识付费墙。

遇到我就是缘分。你觉得这些分享对你有帮助，随喜打赏——没有固定金额，不设付费墙。 打赏是一种认可，不是入场券。

也欢迎加入免费社群。 在群里你可以分享使用 Skill 的经验心得，提出你想做的插件创意，看到其他群友的实战案例相互启发。

写在最后

十年前，我第一次给 Excel 写 VBA 宏的时候，一个简单的自定义函数就兴奋了半天。

后来做 COM Add-in，被注册表、GUID、安装器折腾得掉头发。再后来接触 Excel-DNA，惊叹于它的能力——但也被它的学习曲线劝退了好几次。

十年过去了，我终于把这十年里所有踩过的坑、学到的经验、磨出来的最佳实践，全部变成了一套 AI 可读、可执行、可验证的 Skill。

现在，你不需要知道什么是 xll，不需要知道 CTP 怎么配，不需要纠结 .NET 6 还是 .NET 8，不需要研究 HandyControl 的 Theme 怎么注入——你只需要告诉 AI 你想做什么，剩下的全部自动完成。

而且做出来的东西，无论是功能还是界面，都是专业级的。

我的目标很简单：让每一个用 Office 的人，都能在自己的 Excel 和 WPS 上，长出自己想要的任何功能。而且长得比那些花几万块定制的商业插件还漂亮。

从 VBA 到 Excel-DNA，从轻量到重度，从"能做"到"做得好"——这段路我帮你铺完了。

可以开始玩了。

想体验 Excel-DNA 插件开发 Skill？欢迎进入免费社群，亲手体验：一句需求 → 完整插件项目 → 双击安装进 Excel/WPS。