本文内容，已经兼容WPS表格，安装过VBA模板在WPS表格上也可使用

为什么想做这件事？

做过Excel VBA插件交付的朋友都懂这种“最后一公里”的折磨：

你费了很大劲把代码写对、测通，然后开始发愁：

要做功能区（Ribbon）吧，得找个第三方工具，还要学它的语法；

要打图标包吧，得学怎么把图片资源塞到Office Open XML的包里，还要改各种关系文件；

要打包成 xlam 吧，还得操心怎么把文件给出去，怎么让别人安装不报错；

最后还要写安装卸载脚本，还要在不同版本的Windows和Excel上都试一圈才敢交差。

传统模式的痛点

传统开发模式里，这些环节往往分散在好几个工具里，中间要手工切好几次。

就算你有AI帮忙写VBA代码，后面几步还是要你自己动手填坑：

要么你得教AI用一堆第三方工具，要么你得自己当那个“最后的执行人”。

折腾一圈下来，本来想靠AI提效，结果发现真正累人的不是写代码，而是那些杂七杂八的“交付流程”。

我的不一样的尝试

我最近做了一套不一样的尝试。

不是简单给AI一段长长的提示词，而是写了一套完整的 Skill。

这套 Skill 不只是“一份文档指引”，而是一套可复用的脚本骨架 + 完整的交付规则库：

• 给AI一个现成的、已经跑通的模板

• 后续AI只需要写业务逻辑，框架不用大动刀

• 甚至可以只小改文案、图标，就能快速生成一个新插件

• 普通AI只要会写简单VBA，就能在这个基础上干活

为什么选 PowerShell 而不是 Python？

这里还有一个我觉得很有启发的技术选型：

我没有选很多人一上来就想到的 Python，而是选了 PowerShell。

为什么选PowerShell？

对于“桌面工具 + Office 插件 + 脚本交付”这个场景，PowerShell 是真的省心：

• 不需要安装环境，Windows 自带；

• 不用管各种依赖包的版本冲突，不用怕 pip install 半天装不完；

• 天然能和 Excel COM 无缝配合；

• 写注册表、写安装卸载脚本、操作 ZIP 包，这些交付环节的脏活累活，PowerShell 都能很顺手地搞定。

一个关键思路：用“约束”来让AI不出错

更重要的是，我在这套 Skill 里加了一个关键思路：用“约束”来让AI不出错。

不是让AI自由发挥，而是给它一套明确的“什么可以做、什么不能做、怎么做更稳”的规则：

• 什么时候应该做成 xlsm，什么时候应该做成 xlam；

• 什么时候用 Ribbon，什么时候用工作表里的形状按钮；

• 中文文件和脚本应该用什么编码；

• 做完之后应该怎么自己测一遍，再交给用户。

这些规则不是凭空想的，是踩过很多坑之后总结出来的。

现在的体验是什么样的？

把这些规则写进 Skill 之后，现在的体验大概是这样：

1. 用户简短提个需求；

2. AI 先当你的**“产品经理助理”**：帮你把需求聊清楚，帮你确认是当前文件用还是通用插件、要什么入口、给谁用、用几次；

3. AI 再当你的**“开发工程师”**：在这套模板基础上小改，生成完整的 PowerShell 构建脚本；

4. AI 最后当你的**“测试工程师”**：自己用 COM 打开 Excel，写模拟数据，跑一遍核心功能，还会检查一下结果对不对。

全程不需要你做什么？

全程不需要你：

• 打开 VBA 编辑器；

• 复制粘贴代码；

• 用第三方工具画 Ribbon；

• 手工写注册表脚本；

• 甚至不需要亲手做测试。

相当于把零散的步骤串成了一条完整的交付链路。

适用范围和一点思考

当然，目前这套玩法主要适用于 Windows + Excel 环境，面向的是有真实 VBA 需求、但不想自己钻太深技术栈的朋友。

做这套东西的过程中，我最大的感受不是技术有多复杂，而是思维方式的变化：

原来总觉得“AI 越自由越好”，现在发现“给 AI 足够的约束，反而能让它更稳定地交付可用的东西”。

最后

如果你对这套玩法有兴趣，想了解更多细节，可以找我聊聊。