为什么我坚决不让 AI 碰框架？——Python 与 Excel VBA 两大 Skill 大更新

这一轮，我更新了两套 Skill：Python 和 Excel VBA。一个从"帮你做工具"升级成了"帮你搭系统"，一个把最容易翻车的一环彻底改造成了脚本驱动。它们背后的逻辑是同一个——永远不让 AI 去做更多不确定的事情。 而这套逻辑，恰恰是我这 17 套 Skill 敢说"非同小可"的底气。

一、Python：从"帮你做个工具"到"帮你搭一套系统"

先说 Python。

以前 python-dev 这套 Skill 能干什么？一句话：给零基础的人做 Python 工具。 脚本、桌面小工具、Excel 批处理、网页爬虫，最后打包成 exe 双击就能用。

这些能力当然很有用，但它有个边界：是"工具级"的——你用的时候打开，用完关掉，数据都在你自己电脑上。

这一轮我把它升级了。python-dev 现在能做"系统级"的东西了：

网页 / 在线系统 / 管理后台：Python 做后端（FastAPI），Web 做前端，多人同时访问，手机也能开；

数据库：SQLite 起步，要上规模再换 PostgreSQL，AI 帮你判断；

认证权限：JWT 登录、密码哈希、密钥走 .env，不用你自己碰安全；

部署上线：把系统放到一台一直开机的机器上，24 小时运行，开机自启、崩溃自动重启、日志能查。

你可能注意到了——这些能力，正是"业务系统开发"那套 Skill 的能力。 我这次特意把它们对齐了：把业务系统开发那套里已经验证过的"全栈 + 部署"经验，原样移植进 python-dev。

为什么这么做？

因为很多人只有一个 Python 的需求，但需求说着说着就长成了"系统"：一开始只是"帮我抓点数据"，后来变成"帮我在内网搭一个查询系统，大家都能访问"。以前这两件事得在两个 Skill 之间来回切，现在一个 python-dev 就能从"工具"一路做到"系统"，全程不换场。

这套 Skill 里我还内置了一个已经跑通的完整样例——web-app 蓝图：FastAPI + SQLAlchemy + SQLite 后端 + React 前端的一套订单管理系统，自带 14 个测试，还配齐了 Windows / Linux / Docker 三套部署脚本。AI 拿到它，只需要把里面的业务换成你的业务。

关键是把"部署"这件事也做成了脚本。 以前让 AI 教人部署服务器，十有八九给你一句"在终端里跑 uvicorn"——用户一关窗口，服务就没了。现在铁律摆在那：

服务类交付必须做到开机自启、崩溃自愈、日志落盘，禁止拿"双击 bat 挂个黑窗口"当部署。

三套部署脚本全是编号好的 .bat / .sh，零基础用户照着点就行。这一套下来，E2E 我全部实测通过——不是理论可行，是我自己跑通、你直接抄作业。

二、VBA：把"靠提示词教"改成"靠脚本驱动"

再说 VBA。这次改动的，是整套 Skill 里最容易翻车的一个场景：在用户现有的 Excel 文件上写 / 改宏。

之前：只有参考文档级别的指引

以前用户拿一个做好的 .xlsx / .xlsm 过来，说"帮我在里面加个宏"，我的 Skill 给 AI 的是参考文档——告诉它"你应该怎么做"。

听着合理，对吧？但我自己拿来开发测试的时候发现：AI 的不确定性太强了。 就算有文档指引，它依然可能——

自作聪明地去读工作簿的 VBA 工程，写一坨 COM 代码，读出来还不对；

改的时候没保留用户原来的数据、格式、隐藏表；

干脆新建一个空工作簿，把内容"搬"过去，结果啥都丢了；

改完一保存，把用户的原文件给污染了。

文档是写了，但 AI 该自由发挥的地方还是在自由发挥。问题不在 AI 笨，在于我让它自由发挥的空间太大了。

现在：铁律——"现有文件流程必须走脚本，禁止 AI 自由发挥"

所以这一轮，我把这条链路整个推倒，重做成模板化 + 脚本化：

 

import_existing_workbook.ps1（只读分析）
        │  源文件只读，产出 baseline/ 副本 + 组件清单
        ▼
AI 只编辑 src/ 里的 .vba 纯文本（增 / 删 / 改）
        │  不碰 Excel，不写任何 COM 代码
        ▼
apply_vba_to_workbook.ps1（回写交付）
        │  在内存完成全部改动，一次性另存为产物
        ▼
dist/<原名>.xlsm

 

三个角色分得清清楚楚：

1. 读——import_existing_workbook.ps1 把用户现有的工作簿，只读地解析成标准 VBA 项目结构：标准模块、类模块、窗体、文档模块、Ribbon，全部提取出来，附带一份清单；

2. 改——AI 只干一件事：改 src/ 里的 .vba 文本。 增删改都是纯文本编辑，不碰 Excel，一行 COM 代码都不用它写；

3. 写——apply_vba_to_workbook.ps1 负责把改动回写进工作簿：先在内存里把所有 VBA 增删改做完，再一次 SaveAs 落盘，你的原文件从头到尾零污染。

AI 从"要懂怎么操作 Excel"降级成了"只需要写业务逻辑"。 它要写的，就是 src/ 里那个宏里面真正的业务代码——别的，它想碰都碰不着。

改完之后的准确率，是肉眼可见的提升。我拿真实场景跑了好几轮验证：xlsx 转 xlsm 加宏加 Ribbon、在现有 xlsm 上迭代修改、删除旧模块、基线文件纯度——五种场景全部通过。 之前靠文档指引时的"碰运气"，变成了现在的"稳定交付"。

三、这背后，是我做整套 Skill 最核心的信条

Python 和 VBA 这两个更新，表面看是两件事，背后其实是同一个原则：

永远不让 AI 去做更多不确定的事情。

我把这套原则拆成两句，可能是你看完这篇文章最该带走的东西：

第一句：底层框架，永远由专家落地成脚本，绝不让 AI 自由发挥。

Web 怎么分层、部署怎么做到开机自启、VBA 怎么读旧文件、怎么回写不污染原文件、中文编码有什么坑、PowerShell 5.1 有什么红线……这些"框架性"的东西，是我这个有十三年 Office 开发经验的人，一个一个踩过坑、验证过、固化好的。

它们不该指望 AI 现场发挥，因为现场发挥 = 不确定性。 我把它们写成脚本、模板、蓝图，AI 直接调用就行。它不需要懂，也最好别碰。

第二句：业务逻辑，才是 AI 该专注的地方。

AI 真正擅长、也唯一适合做的，是"把用户的一句大白话，翻译成一段简单的业务代码"——算个金额、查个表、存个数据。这些是它的主场，它做得很稳。

所以我这套 Skill 的分工就一句话：

框架我兜底，业务交 AI。

AI 被安排得明明白白，自然就不会再给你搞出什么"惊喜"。

四、为什么我敢说：这 17 套 Skill，和普通提示词不是一回事

做完了这次验证，我心里更踏实了。

市面上大多数"AI 技能包"是什么？本质还是一段提示词——把一堆规则写成文本告诉 AI："你应该这样做、那样做。"

然后呢？结果全看 AI 的自由发挥。模型强一点，结果就好一点；模型差一点，就靠运气。这也是为什么很多人觉得"AI 编程不靠谱"——不是 AI 不行，是你在让它干它最不擅长的事。

而我的 Skill 不一样。我的每一套 Skill，都不是"告诉 AI 怎么做"，而是**"把怎么做写死成脚本，让 AI 照着执行"**：

环境是脚本装的，不用 AI 猜；

骨架是蓝图生成的，不用 AI 造；

框架是脚本驱动的，不用 AI 编；

坑是提前踩平的，不用 AI 踩。

AI 在里面唯一要动的，是它最擅长的业务逻辑。所以——

哪怕你用的只是普通水平的 AI 模型，哪怕你完全没有编程基础，也能稳稳地做出能用的成品。

这次 Python 和 VBA 的更新，恰好就是这套价值的两面证明：Python 那边证明"一个 Skill 也能撑起系统级交付"，VBA 这边证明"把不确定性交给脚本，准确率立竿见影"。 两者指向同一个结论——零基础用户 + 普通 AI + 我的 Skill = 稳定出成品。

这就是我这 17 套 Skill 敢说"非同小可"的底气。不是自夸，是这套方法论，真的和普通提示词不在一个维度上。

最后

这轮更新，想体验的话：

想要 Python 全栈 + 服务器部署 的能力，拿 python-dev 这套；

手里有现成的 Excel 文件想加宏、改宏的，拿 Excel VBA 这套，体验一下"脚本驱动"有多稳。

还是老规矩，首次申领零门槛。加我好友，进免费社群，亲手玩一把——用大白话说出你的需求，剩下的，交给 Skill 和 AI。

如果觉得这些折腾值得认可，欢迎随喜打赏。不设固定金额，你觉得值多少就打赏多少。

以上就是“为什么我坚决不让 AI 碰框架？——Python 与 Excel VBA 两大 Skill 大更新”的详细内容，想要了解更多Python教程欢迎持续关注编程学习网。