这一轮的时候, 我更新了两套 Skill, 一套是和 Excel VBA。其中一套从原来那个“帮你做工具”, 升级成为了“帮你搭系统”。另一套, 把最容易出现问题的一环, 完全改造成了脚本驱动的那种形式。它们背后所蕴含的逻辑, 是同一个, 就是永远都不让 AI 去做更多那些具有不确定性的事情。而这一套套逻辑, 恰恰就是 我这 17 套 Skill 敢说“非同小可”的那种底气所在喇。一、从帮你做个工具到帮你搭一套系统先说 。先前, -dev这一套Skill究竟能够起到怎样的作用呢? 一句话来表述: 针对那些毫无基础的人员制作工具。诸如脚本, 桌面小工具, Excel批处理, 网页爬虫, 最终再打包成为exe格式, 通过双击即可使用。这些能力无疑很具实用性, 然而它存在一个界限, 此界限为“工具级”的, 即当你使用时将其开启, 使用完毕后把它关闭, 相应数据均处于你自身的电脑之上。这一轮我把它升级了。-dev现在能做系统级的东西了你或许留意到了, 这些能力, 恰恰是“业务系统开发”那套Skill所具备的能力。此次我特地将它们进行了对齐, 把业务系统开发那套里面已经经过验证的“全栈 部署”经验, 原封不动地移植到了-dev。为什么这么做因为许多人仅有着单一的需求, 然而需求阐述着阐述着便演变成了“系统”, 起初仅仅是“帮我抓取一些数据”, 嗣后却变为“帮我在内部网络搭建一个可供众人访问的查询系统”。以往这两件事情需要在两个技能之间来回切换, 如今单个-dev 就能从“工具”一直做到“系统”, 整个过程无需更换场地。在这套 Skill当中, 我内置了一个已然跑通的完整范例, 也就是 web - app 蓝图, 有涉及后端与 React 前端的一套订单管理系统, 它还自带 14 个测试, 并且已然配齐 / Linux / 三套部署脚本。倘若 AI 获取到这一单, 仅须将当中展现的业务转化成你的业务即可。重点在于将“部署”这一事项同样制作成了脚本, 以往让AI指导人们去做服务器部署时, 十有八九会给到你这样一句话“在终端里运行”, 然而当用户关闭窗口后, 服务也就随之消失了, 如今明确的规则就摆在那里:进行服务类交付时, 务必要达成开机能够自动启动, 出现崩溃状况时会自我恢复, 日志能落到硬盘, 禁止把“双击一下 bat 文件挂着黑漆漆的窗口”视作部署。那三套被部署的脚本, 全都是编好了号码, 以.bat或者.sh作为后缀名的, 对于没有基础的用户而言, 照着上面的指示操作就完全可以了。就这一整套流程下来, 关于E2E我全部都经过现场实际检测并且通过核对了——不是那种在理论层面上具备可行性, 而是我自己亲自运行成功, 你直接照着这个去操作就可以了。二、VBA把靠提示词教改成靠脚本驱动再来讲讲VBA。这次所进行改动的, 乃是整套Skill之中, 最为容易出现翻车的一个场景, 即在用户现有的Excel文件之上写或者改宏。之前只有参考文档级别的指引就在以前, 有用户拿着已然做好的那种文件名后缀为.xlsx或者.xlsm的文件过来, 然后说道“帮我在这边面加个宏”, 而我所给予AI的Skill呢, 那是一份用作参考的文档, 此文档会告知它“你应该怎样去做”。按照常理来听, 是比较合理的, 对不对? 然而当我自已将其取来做开发测试时却发现, 该AI的不确定性实在是太强啦。虽说即便拥有文档进行指引, 它仍然存在着有可能性或者——。那文档是写好了, 然而, 用于 AI 的那些该自由发挥的部分依旧是处于自由发挥的状态。问题并非出在 AI 不那么聪明伶俐这块, 而是关键在于, 是我给予它用来自由发挥的空间实在是太大了。如今, 存在这样一条铁定的规定, 即现有的文件流程需要按照脚本来进行, 不允许人工智能自由地展现其能力, 去做发挥性的操作。于是, 在这一轮操作过程中, 我将这一条链路, 从整体上进行了推倒处理, 随后重新构建成为模板化加上脚本化的形式。book.ps1只读分析│ 源文件只读产出 / 副本 组件清单AI进行编辑操作, 仅针对src/里的.vba纯文本, 存在增加、删除或者修改这三种情形。│ 不碰 Excel不写任何 COM 代码k.ps1回写交付│ 在内存完成全部改动一次性另存为产物dist/原名.xlsm三个角色分得清清楚楚1. 读——book.ps1将使用者当下已有的工作簿, 以只读的方式解析为标准VBA项目结构, 即标准模块、类模块、窗体、文档模块, 把这些全部提取出来, 还要附带一份清单。2. AI 仅仅做一件事情, 这件事情就是修改 src/ 里面的 .vba 文本, 增加、删除以及修改全部都是纯粹的文本编辑操作, 不会去触碰 Excel, 就连一行 COM 代码都不会用它去编写。3. 制作脚本——k.ps1, 其职责在于将修改内容重新写回到工作簿当中, 具体先后顺序为——首先在内存里完成针对所有 VBA 的增加、删除以及修改操作, 随后进行一次性的落盘处理, 如此保证你的原文件自始至终不会被污染、保持常态, 最后才完成整个操作流程。人工智能从“得晓得怎样去操作电子表格软件”降低级别转变为了“仅仅只需要去编写业务方面的逻辑”, 它所要编写的, 正是在根源文件里那个宏文档之中实实在在的业务代码, 除此之外的其他内容, 它就算想要去触碰都根本没有办法碰到。修改之后的精确程度, 呈现出肉眼能够明显看到的提高。我运用真实的情形进行了好几轮的验证: xlsx 转化为 xlsm 并增添宏, 在已有的 xlsm 基础上进行迭代更改, 将旧的模块予以删除, 基线文件的纯净度——这五种情形全部都顺利通过。先前依靠文档指示时那种“碰运气”的状况, 成了如今“稳定提交”的局面。三、这背后是我做整套 Skill 最核心的信条跟VBA这两项更新, 从表面上去看, 是两件不同的事情, 然而在背后实际上是同一个原则:永远不让 AI 去做更多不确定的事情。我把这套原则拆成两句可能是你看完这篇文章最该带走的东西第一句是, 底层的框架, 始终是由专家将其落地成为脚本, 绝对不会让AI进行自由发挥。Web如何进行分层, 部署怎样达成开机自启, VBA如何读取旧文件, 怎样进行回写且不污染原文件, 中文编码存有哪些坑, 5.1有什么红线, 这些“框架性”的内容, 是身为有着十三年开发经验的我, 逐一踩过坑, 验证过, 并且固化好的。不要寄希望于让它们依靠AI在现场进行发挥, 毕竟现场发挥那就意味着存在不确定性 , 我将它们撰写成脚本 , 再制作成模板 , 最后绘制成蓝图 , AI直接调用便可以了 , 它不需要去理解 , 理应最好与之保持距离。第二句业务逻辑才是 AI 该专注的地方。AI真正拿手、且唯独适配去做的, 是将用户的一句通俗易懂的话语, 转译为一段简易的业务代码, 比如算个金额, 查个表, 存个数据, 这些属于它的优势领域, 它做得极为稳健。所以我这套 Skill 的分工就一句话框架我兜底业务交 AI。AI 被安排得明明白白自然就不会再给你搞出什么惊喜。四、何故我能讲, 这十七套技能, 跟平常的提示语可不是同一回事呢?做完了这次验证我心里更踏实了。市面上占据多数的“AI 技能包”究竟是什么, 其本质实际上是一段提示词, 这段提示词干嘛, 是把一堆规则给写成文本而告知 AI 说, “你应当如此去做、那般去行动。”。而后呢? 最终的结果完全取决于AI的自行发挥。要是模型更为强大一些, 那么最后的结果就会更好一些要是模型稍差一些, 那就只能凭借运气了。这同样是众多人认为“AI编程不靠谱”的根由所在——并非是AI真的不行, 而是你在驱使它去做它最为不擅长的事情。然而, 我的Skill并非如此。我的每一套Skill, 并非是“告知AI如何去做”, 实则是**“将怎么做具体固定成脚本, 令AI依照其执行”**:AI 在里面唯一要动的是它最擅长的业务逻辑。所以——即便你所运用的不过是处于普通水准的AI模型, 即便你全然欠缺编程方面的基础, 也能够稳稳当当地打造出可投入使用的成品。这一回, 与VBA的更新, 恰恰正是这套价值的两面例证, 那一边例证“一个Skill也能够支撑起系统级交付”, VBA这一边例证“将不确定性交付给脚本, 准确率即刻显现”, 二者均朝着同一个结论指示, 即零基础用户加上普通AI以及我的Skill必然稳固地产出成品。这便是我这十七套 Skill 表明“非同小可”的那个底气的所在之处。并非自我吹嘘, 而是这一套方法论实实在在地和普通的提示词处在并非同一维度之上。最后这轮更新想体验的话仍然是老的一种规则, 第一次进行申领是没有门槛限制的。添加我的好友, 进入免费能够加入的社群, 亲自去玩一回——使用通俗易懂的大白话讲出你的需求, 其余的部分, 一并交付给Skill以及AI。若认为这般折腾是值得予以认可的, 欢然欢迎随喜进行打赏, 并非设置固定金额, 而是你觉着值多少便去打赏多少。