文章 / AI编程与办公自动化
从“给一段VBA代码”到“交付一个可安装的插件”
为什么想做这件事？ 做过Excel VBA插件交付的朋友都懂这种 “最后一公里”的折磨 ： 你费了很大劲把代码写对、测通，然后开始发愁： 要做功能区（Ribbon）吧，得找个第三方工具，还要学它的语法； 要打图标包吧，得学怎么把图片资源塞到Office Open XML的包里，还要改各种关系文件；
传统模式的痛点
传统开发模式里，这些环节往往分散在好几个工具里，中间要手工切好几次。
就算你有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 之后，现在的体验大概是这样：
- 用户简短提个需求；
- AI 先当你的**“产品经理助理”**：帮你把需求聊清楚，帮你确认是当前文件用还是通用插件、要什么入口、给谁用、用几次；
- AI 再当你的**“开发工程师”**：在这套模板基础上小改，生成完整的 PowerShell 构建脚本；
- AI 最后当你的**“测试工程师”**：自己用 COM 打开 Excel，写模拟数据，跑一遍核心功能，还会检查一下结果对不对。
全程不需要你做什么？
全程不需要你：
- 打开 VBA 编辑器；
- 复制粘贴代码；
- 用第三方工具画 Ribbon；
- 手工写注册表脚本；
- 甚至不需要亲手做测试。
相当于把零散的步骤串成了一条完整的交付链路。
适用范围和一点思考
当然，目前这套玩法主要适用于 Windows + Excel 环境，面向的是有真实 VBA 需求、但不想自己钻太深技术栈的朋友。
做这套东西的过程中，我最大的感受不是技术有多复杂，而是思维方式的变化： 原来总觉得“AI 越自由越好”，现在发现“给 AI 足够的约束，反而能让它更稳定地交付可用的东西”。
最后
如果你对这套玩法有兴趣，想了解更多细节，可以找我聊聊。