自从上周末体验了软著自动生成 Skill，我才第一次认识到 AI Skill 的重要性。这种交互方式大概会是未来软件的终极形态吧。这周完成了旧项目的账号权限迁移之后，马上就要开始功能的集中测试。而我感觉这些测试工作，相当一部分是重复劳动，是可以做成 SOP，形成 AI Skill 的。于是，我尝试了一下在 CodeBuddy 中写第一个 Skill。
新建 Skill 提示词
我想创建一个 codebuddy 的 skill，用于测试 MES 新系统的代码，跟旧系统的代码是否保持一致。两套系统的技术栈不同，但是功能是一样的。需要侧重的几个测试点：
1. 界面功能是否一致
2. 界面描述是否一致。例如，顶部的查询过滤项的描述是否一致，结果 table 的表头文字是否一致
3. 针对数据库的 SQL 是否一致。能否自动打开 vscode 的分屏功能，在左侧显示旧系统的 SQL 逻辑代码部分，右侧显示新系统的 SQL 逻辑代码部分
4. SQL 是否有优化的可能。
这个 skill 是否可以实现。
SKILL 内容，请使用中文。
使用了 CodeBuddy 中这两周限免的混元3模型，除了上下文 192K 比较小，没想到效果意外得好。
skill 骨架
结构如下：
.codebuddy/skills/mes-code-consistency-check/
├── SKILL.md # 主入口：4 测试点 SOP + 触发描述
├── references/
│ ├── reverse-lookup.md # 菜单名→旧JSP/BPO + 新Vue/Java 的反查链路
│ ├── comparison-checklist.md # 4 个测试点的逐项核对清单
│ └── oracle-optimization.md # Oracle SQL 优化红 flags 清单
└── scripts/
└── generate_html_diff.py # 旧左/新右 分屏 HTML 对比报告生成器
SQL 对比的体验优化
惊喜的是，AI 给了一个 SQL 对比的建议：
一个细节提醒：旧 SQL 在 BPO 的 .java 里（StringBuffer 拼接），新 SQL 在 Mapper .xml 里。直接 code –diff 整个文件会因格式不同很噪，所以 skill 要求先抽取纯 SQL 片段到临时 .sql 再对比，差异才清晰。
生成的临时 SQL 文件，放到了 skill 下的 .cache 目录，还挺贴心
> tree .\skills\
.CODEBUDDY\SKILLS
└─mes-code-consistency-check
├─.cache
├─references
└─scripts
> ls .cache\
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 2026/7/17 19:31 1978 new_xxx.sql
-a---- 2026/7/17 19:31 1413 old_xxx.sql
SQL 原文件的查看
我又提了一点建议：好兄弟，非常完美。有一点还能优化一下，在使用 code –diff 比对提取的 SQL 文件之后，请再调用 code 命令来打开对应的原始文件的具体代码行处，这样我就能更方便的查看原始代码文件。
然后，AI 大兄弟就在 code diff 后又加上了两行命令：
code -g "<旧 BPO/JSP 原始文件>:<SQL 起始行>"
code -g "<新 Mapper XML 原始文件>:<SQL 起始行>"
最后
我测试了一下，效果比预想的要好很多。节省了大量的人工操作。我的感触是，Skill 没必要自己手动敲，完全可以让 AI 去发挥。你在 AI 生成的 Skill 基础上去不断优化就好了。
关于作者 🌱
我是来自山东烟台的一名开发者，有感兴趣的话题，或者软件开发需求，欢迎加微信 zhongwei 聊聊，或者关注我的个人公众号“大象工具”， 查看更多联系方式