1. 从会写提示词到造SkillAI编程走到分水岭了这两年我身边的开发者明显分成两种状态。一种还在对着对话框反复喂上下文把公司的代码规范复制进去把项目结构贴进去再叮嘱模型记得用error wrapping一轮对话下来光铺垫就花掉十分钟。另一种则开始用起了技能包——他们不再每次重复解释需求而是直接丢一句用xxx技能检查这段SQL模型自己就知道该套用哪套规范、走哪些检查步骤、按什么格式输出结果。后者用的就是现在AI编程圈里热度一路走高的Skills体系。所谓Skill可以通俗理解成给代码助手安装的岗位说明书把你希望模型稳定遵循的工作流程、专业知识、输出模板、边界约束打包成一个可命名的单元之后一次命名调用效果稳定发挥。而陌讯Skills正是这类生态里目前覆盖面最广、社区活跃度最高的一套实现。顶尖工程师为什么集体转向它我自己的体会是不是因为某单个技能写得多么惊艳而是这套生态第一次把AI编程技能做成了有版本、有规范、能共享、能拆装的标准件。在AI编程工具已经多得让人挑花眼的当下真正决定落地效果上限的恰恰是标准这件事。这篇文章我就围绕陌讯Skills这个生态把一个AI编程Skill从设计、编码、调试到上架分享的完整链路拆开讲透把我踩过的坑和沉淀下来的方法一并交代清楚。不管你现在是用AI辅助写业务代码还是在带团队推行AI编程规范这节内容都值得你花十分钟仔细看看。2. 为什么说标准化是AI编程Skill生态的生死线2.1 没有标准之前提示词是手工作坊先回到最原始的问题为什么非得有一个标准化的Skill生态因为过去靠提示词堆出来的AI编程能力本质上是手工作坊。我早先在一个跨平台项目里试着让AI帮我做代码审查。当时整理的审查提示词大概有八百字要求模型先读文件、再对照项目规范、然后列问题清单、最后给出修改建议。第一次用得不错第二次换了个文件咦输出格式变了第三次换个人来用效果又不一样。后来发现问题出在三个层面一是提示词分散在每个人的聊天记录和文档里没有统一载体二是一段提示词里混着应当做什么和不应当做什么模型经常抓不住优先级三是没有版本概念我改了一版之后上个月用的旧版是什么样完全无迹可寻。这听起来很像软件开发早期没有版本控制、没有测试用例的状态。一个人自娱自乐没问题一旦要团队协作立刻崩盘。2.2 标准件思维把AI能力变成可安装的插件陌讯Skills的做法是先把一个Skill定义成一个结构化的标准件。它明确划分了这个技能叫什么、用来干什么、在什么条件下触发、按什么步骤执行、输出什么格式、依赖哪些资源。这就像给模型一份工单而不是一句你看着办。标准化的第一个收益是可复用。团队里一个资深工程师把安全审计打包成Skill其他人直接拉下来就能用不必再读他大脑里那套经验。第二个收益是可组合。多个Skill像积木一样搭在一起先跑代码规范检查再跑安全审计最后跑生成变更总结就能组成一条自动化流水线。第三个收益是可传承。Skill本身是一个带版本号的文件项目里引入哪个版本一目了然新成员上手时看一遍Skill清单就能理解团队在哪些环节依赖AI。这个逻辑听起来不复杂但真正把它做成一套生态——有仓库、有索引、有拉取命令、有版本规则——就不是随便一个工具能做到的了。陌讯Skills的优势在于它把标准贯穿到了从创作到消费的每一个环节而不是只给一个schema字段表就撒手不管。3. 陌讯Skills的标准化内核一个Skill到底长什么样3.1 Skill包的物理结构目录即契约我第一次创建陌讯Skill的时候以为就是写个Markdown提示词丢进去。真正动手才发现一个合规的Skill包是一个有固定结构的目录。拿我维护最多的sql-review技能来举例它的目录长这样sql-review/ ├── skill.yaml # 元信息定义名称、版本、描述、触发关键词 ├── rules/ # 规则文件存放具体的检查规则 │ ├── index-usage.md │ ├── implicit-conversion.md │ └── limit-clause.md ├── prompts/ # 提示词模板按步骤拆分 │ ├── analyze.md │ └── report.md ├── scripts/ # 可选的执行脚本用于预处理/后处理 │ └── normalize_sql.py └── tests/ # 测试用例用真实SQL验证技能效果 ├── case1.sql ├── case1.expected.json └── case2.sql这个结构初看有点繁琐但用久了就明白它的好处。提示词模板被拆分成分析和报告两步模型不会再把逻辑混在一起规则文件独立成Markdown等于把团队知识库嵌进了技能包tests目录则让技能效果可以被持续验证。拿rules/index-usage.md来说它不是让模型留意索引而是给出了可执行的判断标准查询字段上是否有函数包裹、多列条件是否遵守最左匹配原则、模糊匹配是否使用了中缀通配符。这些规则写得越具体模型产出的审查结果就越稳定。3.2 skill.yaml把触发和上下文收集写清楚整个包的核心是skill.yaml。下面是一份精简但可跑通的示例name: sql-review version: 1.2.0 description: 对给定的MySQL查询语句执行索引失效风险、隐式类型转换和全表扫描风险检查 author: dev-skill-team license: MIT triggers: - 帮我检查SQL - review sql - 这条查询会有问题吗 context: require: - 待检查的SQL语句 optional: - 表结构DDL - 数据库版本 steps: - name: collect prompt: prompts/analyze.md - name: report prompt: prompts/report.md output: format: markdown sections: - 问题等级 - 风险描述 - 修改建议 - 示例改写你可能好奇context那一栏为什么重要。这是我从多次失败里学来的教训模型在缺少表结构信息时很大概率会根据字段名脑补类型导致索引判断完全跑偏。所以我在optional里放了表结构DDL并要求在收集阶段先判断上下文是否充足不足时明确向用户追问而不是硬着头皮分析。这一条规则直接让技能产出的准确率上了一个台阶。3.3 标准化的另一面输出的一致性怎么保证很多AI编程工具最大的问题不是不会答而是每次答得不一样。今天让它生成错误处理代码它给的是if err ! nil明天同样的需求它可能给你抛个panic后天心情好又开始自作主张上第三方库。陌讯Skills对输出的一致性做了两层约束。第一层是output.sections字段——它规定报告必须包含哪几个小节模型不能偷工减料。第二层是prompts里的强约束语句模板。比如sql-review的报告模板里规定所有修改建议必须给出改写后的完整SQL和对应的EXPLAIN预期结果。这样下游消费报告的人就不用费力二次解析。我举个直观对比。未封装成Skill之前我让模型检查一下SQL得到的是十几条笼统的建议可能未走索引建议添加LIMIT。封装成Skill之后同样一条SQL输出被规整成一张包括风险等级、影响行数预判、改写SQL、改写前后执行计划对比的结构化Markdown报告。团队拿着这个报告可以直接贴到工单评审环节。4. 实战从零封装一个可上架的Skill包4.1 选题什么样的任务才值得封装成Skill动手之前先想清楚不是所有AI需求都适合做成Skill。我自己定了一条判断线——要被封装的任务必须满足三个条件一是高频这个任务你一个月至少会用到几次二是稳定任务的目标、步骤、交付物是相对明确的三是可评审输出结果能否被验证和判错。拿sql-review来说SQL审查在开发流程里几乎天天出现审查步骤各团队都有固定套路而且查出来的问题是客观可验证的完全满足条件。相反像帮我头脑风暴一下产品名这种开放发散任务就不适合做成Skill——步骤和输出都不稳定硬包装只会让模型束手束脚。4.2 写schema把步骤拆到模型不会迷路的程度确定选题后最关键的一步是把任务拆解成步骤。很多第一次做Skill的人在这里翻车——他们倾向于写一个大而全的提示词试图让模型一步到位。结果就是模型要么丢失细节要么把规则相互混淆。我的拆法是把任务切成收集—分析—生成—自检四个阶段每个阶段一个prompt文件。以sql-review为例分析阶段prompt开头先设定角色然后要求逐条读取rules下的规则文件并把规则的核心要点列成清单。报告阶段prompt要求基于分析阶段的结论按固定字段组织输出并输出一条最佳改写方案。这里有个细节值得注意分析阶段的prompt不直接要求输出最终结论只要求给出证据链——比如该查询在order_id上使用了函数DATE()导致索引失效依据rules/index-usage.md第2条。有了证据链报告阶段就不会笔走龙蛇。下面是analysis prompt的骨架你是一名资深数据库性能工程师。请按照rules目录下的规则逐条分析用户提供的SQL。 约束 1. 必须标注每一条风险对应的规则出处。 2. 若表结构DDL缺失明确声明缺少DDL无法判断索引情况不得猜测。 3. 只输出风险点列表不要输出修改方案。 输出格式 | 风险点 | 涉及规则 | 严重程度 | 证据 |4.3 用陌讯CLI调试test命令是真正的救星写完Skill包接下来是调试验证。陌讯生态提供了一个命令行工具我把最常用的三条命令先亮出来# 在本地运行一次技能模拟线上完整流程 陌讯 skill run sql-review -i select * from orders where year(create_time)2024 # 跑测试集检查输出是否与预期结果一致 陌讯 skill test sql-review # 打包并预览即将发布的内容 陌讯 skill pack sql-review --checkskill test是我练习使用频率最高的命令。它做的事情很简单读取tests目录下的case文件依次执行Skill再和expected.json里的人工期望做对比。对比不是靠字符串匹配而是用语义相似度加字段级校验报告里是否出现了索引失效、是否给出了改写SQL、风险等级是否标对。只要有一个字段缺失测试就报红。我一开始写测试用例时潦草得很只塞了两条简单SQL。后来被一个线上事故教训了——一个性能很差的NOT LIKE查询我的Skill压根没检出来。补齐测试用例把它明确列为中缀通配符不得出现在LIKE模式开头的case再跑test技能效果立竿见影。现在我的规则是每个规则文件至少配两条正向用例和一条反向用例。4.4 上架与发布版本号、变更日志、许可证一个都不能少打包发布这件事听起来简单踩坑的地方其实不少。陌讯Skills的生态仓库对发布包的检查相当严格我第一次提交时就因为缺变更日志被拒了。发布前建议按这个清单自查版本号遵循语义化版本规则破坏兼容性的改动必须升大版本。CHANGELOG里写明本次变更点和受影响规则。license字段不能空缺团队内部使用也建议显式声明。注意涉及敏感业务内部信息的规则一定不要写进公开包。description字段写清楚这个Skill不能做什么减少误触发。例如sql-review的description里我特意加了一句不适用于PostgreSQL仅限MySQL。实测下来生态对description的要求比我想象的高。它不只是给人看的模型判断一个请求要不要激活某个Skill时description是重要依据。写得太宽泛模型会把不相关的请求也路由过来消耗上下文还容易误报。5. 团队落地与常见问题我替你们把坑踩平了5.1 团队引入Skill时最容易踩的五个坑陌讯Skills在个人开发者手里通常上手很快难的是团队落地。我把在几个项目里踩过的坑整理成了一张对照表目的不是吓唬人是帮你提前绕开坑点典型表现解决思路技能包粒度过大一个Skill里塞了几十条规则模型选择困难输出质量下降按单一职责拆包一个Skill只解决一类问题上下文注入顺序混乱规则、示例、当前代码混在一起模型顾此失彼严格按角色定义→规则→示例→当前任务排序依赖外部工具未经声明Skill在本地依赖脚本分享给别人后无法运行将脚本一并打包或在依赖字段中明确写法忽视版本锁pin团队仓库每次拉取到最新版Skill输出行为漂移在项目配置里锁定Skill版本号升级走审批未做效果回归改了一条规则导致另一个场景输出变差但没察觉建立测试集每次修改都跑一遍skill test回归其中版本锁pin这件事我特别多说两句。AI编程领域的Skill和普通依赖库一样升级可能是惊喜也可能是惊吓。我经历过一次把sql-review从1.1升到1.2新增了隐式类型转换检查规则结果之前一个正常通过的兼容性报告突然多了一堆红字警告。不是规则错了而是新规则覆盖了我没预料到的场景。如果没有锁版本团队其他成员拉取到新版本时就会看到不同的审查结果沟通成本一下子就上来了。5.2 效果不佳时先排查这五个环节Skill上线后表现不稳定别急着怪模型。九成问题出在包本身。我总结了一套排查顺序触发是否准确整句输入和短指令的触发率有明显差异检查description和triggers是否覆盖了团队习惯用语。上下文是否完整很多审查类Skill报告缺失关键信息是因为用户没有提供DDL或环境信息。步骤是否越级模型动不动就发挥直接给结论很可能是分析阶段和报告阶段的边界描述不够强硬。规则是否互相冲突两个规则文件可能同时对同一场景给出相反判断。示例是否带偏示例里的写法如果太标准会让模型忽略现实中的杂音。针对第4点我现在的做法是在rules目录里加一个conflicts.md专门记录规则之间的关系。比如索引失效规则和隐式类型转换规则经常出现在同一条SQL上我会在conflicts.md里写明判定优先级先报类型转换再报索引失效。不加这个说明模型给出的风险列表经常分不清主次。5.3 检查单一个干净Skill包的出厂标准结合上面所有经验我整理了一份自我检查单每次发布Skill前都会过一遍。这份清单对你也适用结构目录包含skill.yaml、prompts、rules、tests缺一不可。描述description字段讲清楚做什么和不做什么。规则每条规则有唯一编号、适用场景、判定条件和示例。提示词分步骤编写每个prompt文件有明确输入输出说明。测试每个规则至少配两条通过用例和一条失败用例。版本每次改动更新版本号和CHANGELOG。安全不包含内部路径、密钥、代码片段中的敏感信息。兼容声明适用的开发语言、数据库版本、模型上下文窗口要求。这份清单看起来严格但它恰恰是陌讯Skills这套生态能在团队中站住脚的根本原因。没有这份出厂标准一个Skill和一段随手写的提示词就没有本质区别。6. 实践以后的个人体会用陌讯Skills改造我们团队的AI编程流程已有大半年最大的感受是标准化带来的不只是效率更是安全感。以前AI辅助编码像抽奖同样的需求今天中奖明天翻车现在借助Skill体系至少团队内部的核心任务有了一条可控的、可追踪、可回滚的AI执行路径。我特别想分享一个也许有些反常识的经验Skill包的维护成本远高于创建成本。真正拉开差距的不是谁写出了惊艳的提示词而是谁在持续沉淀规则、更新测试用例、处理边界场景。我们团队每个Skill都有一位明确的owner负责收集中午走查时发现的新问题并把它固化成新规则。这个机制运行一个月后sql-review的准确率从最初的七成提升到了九成以上提升几乎全部来自持续的小版本迭代。所以如果你正准备进入AI编程Skill这个领域我的建议是不要一上来就追求做一个全能王技能而是从自己团队最高频、最痛的那个点切入把它做成标准件用测试锁住行为在真实项目里跑一个月再回头看收益。陌讯Skills现在生态里已经积累了覆盖代码生成、重构、审查、文档、测试等多种场景的技能包直接拿来用是入门最快的路径但真正让你团队受益的一定是把自己沉淀出的规范也做成Skill让AI真正理解你们的工作方式。
