说实话写这篇博客的时候我心情挺复杂的。一个月前我刚到实习岗位满腔热血觉得自己学了一年Java终于能大展拳脚了。结果第一周下来我发现自己每天干的最多的事情是——帮团队里各种人处理一些小事格式化日志、检查SQL有没有带敏感字段、按固定模板写周报日报、把一堆散乱的设备上报数据整理成结构化文档……每件事都不难但每件都要重复做。最离谱的是有一天我上午花了两小时帮三个同事分别处理了三份格式不同但内容差不多的数据报告。下午我坐在工位上发呆脑子里就一个念头我是在用大学学的数据库知识干活吗我明明是个复读机啊。然后带我的老周化名别问了看我状态不对走过来问了一句“你天天在忙啥”我把那一堆杂活一说他笑了“这些事儿你干嘛不让AI帮你干”我说“让AI干我连prompt都写不利索每次出来的东西还得大改。”他说“那你有没有想过不是每次重新教AI而是写一份说明书让它自己学会”这就是我第一次听说Skill这个东西。一、Skill到底是个啥别被概念唬住我当时反应跟你现在可能一样——Skill听起来很高大上是不是要写什么复杂的插件要不要学新框架老周当时的原话我记到现在他说“你就把它理解成你给实习生写的工作手册。”你想啊假设你带了个新来的实习生你得告诉他遇到A类数据怎么处理遇到B类报告用什么模板SQL里哪些字段不能碰周报要按什么格式写……你把这些写成一个文档他照着做就行了对吧Skill就是这个文档。只不过你的实习生变成了AI助手。技术上说Skill就是一个叫SKILL.md的Markdown文件放在一个固定目录里。AI助手启动的时候会读这些文件遇到对应的场景就自动按你写的规则来执行。就这么简单。没有SDK没有编译没有依赖管理。一个Markdown文件就是你的全部武器。二、我的第一个Skill从翻车到能跑我第一个Skill的需求特别朴素——我每天要检查一批SQL语句看它们有没有带上权限过滤条件。这事儿我手动做了两周眼睛都快瞎了。我兴冲冲地跑去问老周“我是不是直接写个Markdown告诉AI’帮我检查SQL’就行了”他说“你写写看。”我第一版大概是这么写的--- name: sql-checker description: 帮助检查SQL语句 --- # SQL检查器 请帮我检查SQL语句是否合规。跑了一下AI回了我一句您的SQL语句看起来没问题。我拿着这个结果去找老周他看了一眼就乐了“你这说明书也太敷衍了吧你要是给实习生写’帮我检查SQL’他也不知道你所谓的’合规’是啥意思啊。”我愣住了。他说“你想想你手动检查的时候脑子里在过哪些规则把它们一条一条写下来。”于是我回去把脑子里的规则全倒了出来写了第二版--- name: sql-checker description: 检查SQL语句是否包含必要的权限过滤条件 适用于日常SQL审查、代码Review、数据查询校验等场景。 当用户提到SQL审查、权限过滤、数据权限检查时使用此技能。 --- # SQL权限过滤检查 ## 检查规则 1. 所有涉及用户数据的查询必须包含 zone_id 过滤条件 2. 涉及设备数据的查询必须关联用户设备类型权限表 3. SELECT * 语句需要标记为警告建议显式列出字段 4. 检查是否存在未加权限过滤的JOIN操作 ## 输出格式 对每条SQL输出 - 是否通过✅ / ❌ - 命中的规则编号 - 如果不通过给出修改建议 ## 示例 输入 sql SELECT * FROM device_data WHERE create_time 2026-01-01输出❌ 不通过 - 命中规则#1 缺少 zone_id 过滤 - 命中规则#3 使用了 SELECT * - 建议添加 WHERE zone_id ? AND ... 并显式列出需要的字段这次跑出来的结果说实话把我惊到了——跟我手动检查的结论几乎一模一样而且速度是我的一百倍。 老周看了一眼说这还差不多。但你注意到没有你第二版比第一版多了什么 我想了想**规则具体了输出格式固定了还给了例子。** 他说对这就是写Skill的三个核心——**告诉它做什么、怎么做、做完了长什么样**。 --- ### 三、踩过的坑替你提前排掉 接下来两周我陆续写了四五个Skill有做得好的也有翻车的。把教训整理一下省得你们再踩 **坑1description写得太笼统** 我有个Skill一开始description写的是帮助处理数据报告。结果呢我让它干啥它都觉得跟数据报告有关连我让它写个Hello World它都要扯到数据报告上去。 后来我改成了将设备上报的JSON原始数据整理为结构化Markdown报告适用于日报生成、数据归档、异常数据标注等场景这下它只在真正需要的时候才触发。 description这个字段是AI判断我该不该用这个Skill的唯一依据。你写得越具体它越聪明写得越模糊它越抽风。 **坑2SKILL.md写成了教科书** 我有个Skill写了快800行把各种背景知识、原理说明全塞进去了。结果AI执行的时候经常跑偏——因为它在上下文里要处理的信息太多了反而抓不住重点。 老周跟我说了一句话我印象很深**AI已经很聪明了你只需要写它不知道的东西。** 后来我把那个800行的文件砍到了200行把详细的参考资料拆到了另一个文件里叫reference.md只在主文件里留了一句详细参考见reference.md。效果反而好了。 这就好比你给实习生写手册核心操作写在第一页背景资料附在后面他想看自己翻。别把第一页就搞得像论文一样。 **坑3没有给示例** 这个坑我踩了两次。有一次写了一个代码审查的Skill规则写得很详细但没给例子。结果AI输出的审查报告格式每次都不一样有时候用表格有时候用列表有时候还给我来个诗歌体夸张了但真的很难统一。 加了两三个示例之后输出格式就稳定了。**示例是最好的老师对AI也一样。** --- ### 四、我现在的工作流一套Skill组合拳 到现在为止我给自己写了这些Skill举几个例子你们可以举一反三 | Skill名称 | 干什么的 | 触发场景 | |-----------|---------|---------| | sql-review | 检查SQL权限过滤 | 提到SQL审查/权限检查时 | | daily-log-format | 按固定格式整理工作日志 | 提到日报/工作日志时 | | api-doc-gen | 根据Controller代码生成接口文档 | 提到接口文档/API文档时 | |>六、几个写Skill的潜规则这些是我翻过文档、踩过坑之后总结出来的文档里不一定有但很实用name字段别乱起。只能用小写字母、数字和短横线最长64个字符。别用中文别用大写别用下划线。sql-review可以SQL_Review不行。description要写什么时候触发。很多人只写了这个Skill干什么忘了写什么时候该用它。AI是靠description来决定要不要加载你的Skill的你不写触发条件它就只能靠猜。主文件控制在500行以内。超过的话把详细内容拆到单独的文件里。AI的上下文窗口是有限的你的Skill只是它加载的众多信息之一别抢别人的空间。术语要统一。别一会儿说接口一会儿说API一会儿又说端点AI会懵。选定一个词全文统一。别写时效性内容。比如2026年7月之前用旧版API这种过期了就出问题。如果有新旧版本用当前方案和历史方案已废弃这种结构来组织。七、从能用到好用我的一些进阶心得写了几周Skill之后我发现有一些模式特别好用分享给你们检查清单模式。如果你的Skill是做审查/检查类的给AI一个checklist格式让它逐项打勾。输出特别清晰也不会漏项。如果-那么分支模式。如果你的任务有好几种情况要分别处理别把所有规则混在一起写。用情况A→走这条路、情况B→走那条路的方式组织AI理解起来更准确。先做再验模式。对于特别重要的操作比如批量修改数据你可以让AI先执行再自己验证一遍结果验证不通过就回滚。相当于给AI加了一道保险。还有一个心得好的Skill不是写出来的是改出来的。别指望第一版就完美。你用的过程中发现AI哪里做得不对就去改规则。这其实就是一个训练的过程只不过你训练的不是模型本身而是给模型的说明书。写在最后回头看这一个月写Skill这件事给我最大的收获不是省了多少时间——虽然确实省了很多。真正的收获是我开始用能不能自动化的视角去审视自己的工作了。以前遇到重复劳动我的反应是忍着做完。现在我的反应是这个能不能写个Skill让AI帮我干。这个思维转变比任何技术都值钱。说实话实习生的工作大多确实琐碎。但你可以在琐碎中找到杠杆用一个下午的时间写出一个Skill然后接下来每天省下两个小时。这两个小时拿来学源码、看论文、写博客、准备面试哪样不比当复读机强最后送一句老周跟我说的话也是我现在的工作信条“重复的事情做两遍就该想想有没有第三遍的必要。”共勉。