最近后台不少朋友问同一个问题怎么才能让AI在项目里不只“聊得明白”还能“干得利索”我自己的答案是——技能Skill而圈子里讨论最多的正是“陌讯Skills”。按我过去几个月的使用体验它不只是又一个提示词仓库更像是一整套把AI编程能力“标准化”的基础设施。很多顶尖工程师对它感兴趣原因也集中在“标准化”这三个字上技能可以被描述、被安装、被复用也能被测试、被追溯。这篇文章就围绕陌讯Skills说清楚它到底是什么、为什么值得用以及如何把一个真实技能从零写完并发布。1. 标准化是“AI编程技能”真正能复用的前提1.1 散装提示词为什么撑不起团队协作我早期做AI编程提效时最头疼的其实是“提示词管理”。不同成员手上都有自己的一套Prompt放在聊天记录、本地TXT、共享文档里命名千奇百怪。有的人写“帮我查Python代码问题”有的人写“你是资深后端请严格检查这段代码的潜在缺陷”。看起来都是代码审查但触达效果完全不一样换个模型换个上下文窗口结果就飘了。这个问题本质上是“散装提示词”的结构性缺陷。提示词本身没有固定元数据机器无法判断它该何时生效、该被什么参数驱动更别谈权限边界和版本升级。大家一起用的时候会出现“这个提示词只在某人电脑上有效别人复制过去就失灵”的尴尬。这种模式下单个开发者的局部效率可能很高但团队层面的资产沉淀几乎为零。把散装提示词比作自己家的随手菜谱只有自己能看懂“少许盐”是多少换个人完全无法复现。而“技能”更像标准化的料理包包装上写清了原料、做法、保质期任何人拿过来按流程操作都能得到一致的结果。1.2 陌讯Skills给出了一套统一契约陌讯Skills的关键不是提供一个存放提示词的地方而是定义了一套“技能契约”。每个技能必须包含明确的能力描述、触发条件、输入输出参数、权限声明以及可执行的实现逻辑。有了这套契约AI Agent才能在合适的场景里自动发现并调用它而不是靠用户在对话框里反复粘贴提示词。这套契约给我的感觉就像接口文档对于后端服务的意义。过去我们要求前端工程师按接口文档对接后端现在陌讯Skills要求提示词的制造者按统一规范描述能力边界。没有规范的提示词是“不可调用的”只有符合规范的技能才具备被复用的资格。对于工程师来说这意味着可以把AI编程相关的最佳实践封装成独立模块。比如“Python单元测试生成”“前端可访问性检查”“数据库索引优化建议”每一条都像工具库里的函数一样有清晰的入参、出参和副作用描述。使用方根本不用关心内部Prompt怎么写的只需要按接口调用。1.3 解决的不只是个人效率更是团队资产沉淀在真实项目里沉淀知识比写代码更难。一个团队磨合出的Code Review清单、上线前的安全扫描规则、日志分析套路如果只存在某几个老手脑子里新人永远接不上。而把这类经验写成技能放进陌讯Skills生态团队里任何人拉起Agent都能使用同一套判断标准。我参与的一个后端项目就把“慢SQL排查”做成技能。这个技能里封装了我们对慢查询的常规分析流程先看执行计划再检查索引使用然后结合表数据量判断是否需要分页优化。过去老员工要花半小时讲一遍流程现在新人只要在Agent里唤起对应技能它会自动按步骤分析并输出结论。这就是标准化带来的团队级收益知识从个人经验变成了可调用的组织资产。2. 陌讯Skills的标准化协议到底规范了什么2.1 一个技能包长什么样陌讯Skills对技能包的目录结构有明确约定。一个最小技能通常包含技能描述文件、实现脚本、输入输出Schema、依赖声明和测试用例。我自己常用的目录大概是my-skill/ ├── SKILL.md ├── main.py ├── schema.json ├── requirements.txt ├── tests/ │ ├── cases.json │ └── run_test.sh └── README.md其中SKILL.md是核心很多新人不重视它其实它承担了技能被“发现”和“触发”的重任。下面是一个我写过的代码审查技能的简化版name: code-review-python description: | 对一段Python代码进行基础质量检查重点关注未使用变量、重复定义的函数、 明显的空异常处理。适合在提交Pull Request之前运行。 version: 1.2.0 author: skill-community-contributor trigger: keywords: - python code review - python 代码检查 - check python context: - code_block: python arguments: code: type: string required: true description: 待检查的Python源码 rules: type: array required: false description: 需要启用的检查规则ID列表 permissions: network: false filesystem: read-only output: type: json fields: - severity - line - message - rule_id每一个字段背后都有用意。name和description用于索引模型可以据此判断“这个技能适不适用于当前任务”。trigger描述匹配规则当用户请求中出现相关关键词Agent自动决定是否加载。arguments定义了结构化参数比从提示词里猜测可靠得多。permissions限制了技能能访问什么资源这直接关系到在企业内部落地的安全性。2.2 执行逻辑与工具调用规范光有描述还不够技能还要有真正可运行的实现。在陌讯Skills里实现逻辑通常是一段独立脚本或HTTP服务。以我们常用的Python技能为例脚本从标准输入读取JSON请求经过处理后再从标准输出返回JSON结果。这种“统一管道”的设计让任何大模型都能以相同方式调用任意技能不绑定特定厂商的私有协议。我写的一个简化版本会长这样#!/usr/bin/env python3 import ast import sys import json def check_unused_imports(tree): ... return issues def check_redefined_functions(tree): ... return issues def main(): raw sys.stdin.read() payload json.loads(raw) code payload[code] tree ast.parse(code) issues check_unused_imports(tree) issues check_redefined_functions(tree) print(json.dumps({issues: issues}, ensure_asciiFalse)) if __name__ __main__: main()脚本只做一件事接收统一JSON输入产出统一JSON输出。Agent不需要知道内部怎么用AST只需要把源码字段填进去等等结果。这种“标准接口”让技能像Unix工具一样可以被组合也可以被其他技能调用。2.3 版本、依赖与兼容性管理标准化革命里最被低估的一块是版本管理。过去一个提示词改来改去根本说不清现在线上跑的是哪个版本。陌讯Skills引入了类似npm的版本语义每个技能有版本号、变更记录、兼容性声明。技能之间也可以互相依赖比如代码检查技能可以依赖一个公共的“规则库技能”规则库升级时引用它的技能可以选择跟随主版本。我把这种设计理解为“把工程化常识搬进AI技能世界”。前端有package.jsonPython有requirements.txt为什么AI技能不能有依赖锁和版本回滚陌讯Skills正是把这一点做到了生态层面。你在项目里锁定某个技能版本后即使上游发布新版本也不会影响当前项目稳定性直到你主动升级。3. 顶尖工程师为什么选它我在真实场景里看到的三个理由3.1 场景一从单模型到多模型技能无缝迁移今年我们团队项目里换过一次底层模型。按照以前的玩法针对旧模型调优的那么多提示词基本等于作废得逐条重新调。但用了陌讯Skills后情况完全不同技能是独立于模型运行的Agent只是通过标准协议调用它模型本身的差异被屏蔽掉了。比如同一个“Python代码审查”技能在模型A下可以使用迁移到模型B之后依然可以调用。因为技能的执行逻辑跑在沙箱里模型只负责理解请求、填充参数、解析输出。我不需要因为换模型就去重写技能内部逻辑。这对工程师来说是实打实降低技术栈锁定风险。3.2 场景二团队代码规范与安全检查自动化日常Code Review中最耗精力的其实是批量化的“规则检查”。比如导入排序、未使用变量、缺少异常上下文、硬编码密钥等。这些事情完全适合交给技能自动化。我们在团队内把一套基于陌讯Skills的“安全扫描技能”接入Pre-commit流程每次提交代码前自动跑一遍。技能的输入是本次改动的Diff输出是风险级别列表。它会指出疑似密钥泄漏的位置、未处理的异常分支、过于宽泛的except语句。常规错误在进入人工Review之前就被挡掉Review效率提升非常明显。这个技能并不追求替代人而是把机械的工作从人身上卸下来。3.3 场景三告别“提示词膨胀”维护成本直线下降你肯定体会过“提示词膨胀”为了让模型按预期输出不断往上堆例子和约束最后一段提示词几千字稍微改一点就会连锁失效。技能化之后这些内容被拆分到独立的规则文件和测试用例里不再是“一坨”不可维护的文本。一次我们修改了输出格式要求从旧的“自然语言结论”改成“JSON结构化报告”。过去要挨个改所有聊天模板现在只需要改技能的schema定义和解析逻辑然后跑一遍测试用例确认输出兼容。这种可测试性是散装提示词完全给不了的。3.4 “国内最全”生态不只是一句宣传语我看过不少技能平台多半停留在示例Demo层面。陌讯Skills让我觉得不一样的是生态厚度技能分类覆盖从后端开发到数据分析从运维脚本到前端组件检查甚至还有针对具体行业场景的模板。很多技能不是官方随手写的而是社区开发者在真实项目中打磨出来的附带了测试数据和版本记录。最直接的感觉是我在里面搜一个“PostgreSQL慢查询分析”技能能找到多个版本各自有优缺点说明、评价、尝鲜数量。这就像一个成熟包管理器该有的样子。缺的不是“能跑的示例”而是“可比较、可信任、可迭代”的选项。4. 实操从零创建一个陌讯Skill并发布4.1 环境准备与脚手架在电脑上安装陌讯Skills的命令行工具后初始化技能非常快。我习惯用官方脚手架curl -sSL https://example.com/install | sh mx skill init code-review-for-python执行后会生成一个标准目录剩下的事情就是往里面填内容。这个初始化动作的价值在于它替你把契约和目录结构定好了你不需要一开始就记住所有规范。安装完成之后最好先跑一下自带示例mx skill test my-skill确保本地的技能运行环境能正常工作。这个环节很基础但能避免后续因为环境缺失浪费大量时间。4.2 填写SKILL.md和实现逻辑初始化生成的是模板要替换成自己的描述和实现。我建议先写SKILL.md因为它迫使你思考“什么时候触发”“需要什么参数”“输出什么格式”想清楚再写代码比先写代码再补描述顺畅很多。接着在main.py里写核心逻辑。下面是我在做“未使用变量检查”时的一段实现import ast import sys import json def detect_unused_vars(source: str): tree ast.parse(source) defined {} for node in ast.walk(tree): if isinstance(node, ast.Name) and isinstance(node.ctx, ast.Store): defined[node.id] node.lineno used set() for node in ast.walk(tree): if isinstance(node, ast.Name) and isinstance(node.ctx, ast.Load): used.add(node.id) unused {name: line for name, line in defined.items() if name not in used} return [{line: line, name: name} for name, line in unused.items()] def main(): payload json.loads(sys.stdin.read()) source payload.get(code, ) try: issues detect_unused_vars(source) print(json.dumps({status: ok, issues: issues}, ensure_asciiFalse)) except SyntaxError as e: print(json.dumps({status: error, message: str(e)}, ensure_asciiFalse)) if __name__ __main__: main()需要注意技能脚本的输入输出必须是严格的JSON。我踩过几次坑当时在print里混入了日志信息Agent解析时直接失败。所以上了生产后所有额外的日志都要打到stderrstdout只留给JSON结果。4.3 本地测试与调试写好脚本后用测试用例手动模拟Agent调用echo {code: def f():\n x 1\n return 2} | mx skill run ./my-skill如果返回的结果包含未使用变量x说明逻辑正确。陌讯Skills还支持在schema.json里声明多组测试用例方便后续回归{ cases: [ { input: {code: def f():\n x 1\n return 2}, expected: {status: ok, issues: [{line: 2, name: x}]} } ] }有了测试用例技能后续修改才敢放开手脚。我通常会在本地跑三组用例正常代码、带语法错误的代码、空代码。保证边界情况不会让技能崩溃。4.4 发布到陌讯生态本地跑通后发布操作也走命令行mx skill publish ./my-skill发布前会自动做一轮检查包括SKILL.md字段是否完整、脚本是否有语法错误、声明的权限和实际行为是否一致。通过后会生成一个唯一技能标识类似包管理器里的包名。这一步我建议把README写详细一些说明使用场景、参数含义、常见问题。社区里的工程师判断一个技能是否可用很大程度看说明文档是否清晰。一个没有文档的技能即使功能很强也容易被埋没。4.5 在Agent项目里接入发布之后使用方只需要在项目配置里声明引入skills: - name: code-review-for-python version: 1.2.0 source: mx-community/xxx代码里调用时可以走官方SDKfrom mxskills import load_skill skill load_skill(code-review-for-python, version1.2.0) result skill.run({code: source_code})接入之后Agent会在用户请求匹配到触发条件时自动加载技能并按规范填充参数。这句体验让我感觉AI应用开发真的进入了“依赖管理”时代而不是每次都要手动拼提示词。5. 常见问题与避坑指南5.1 技能没有被触发先查触发条件我见过最多的问题是技能发布后发现Agent一直不调用。排查的时候不要先怀疑Agent先看SKILL.md里的trigger。很多技能的trigger写得太死比如只监听“code review”用户说“帮我审查这段代码”时反而匹配不到。排查项检查点关键词描述是否覆盖了用户常见的自然表达方式上下文条件是否设置了过严的上下文限制比如代码语言类型不匹配版本缓存是否Agent还缓存着旧版本的技能描述建议在description里多写几个同义词和典型场景而不是只写一个正式名词。触发规则本质上是在帮技能做召回召回范围太小能力再强也用不上。5.2 版本升级后行为不对回滚旧版本技能升级后可能出现“工作方式变了但团队还适应不了”的情况。比如新版本把输出结构改了下游解析逻辑跟不上。这时候正确做法不是立刻让所有人改代码而是回滚技能版本。在配置里把version改回原版本重新启动Agent任务即可。这也是我在前面强调锁版本的原因。如果你不锁版本技能发布方一旦升级你的项目将被动变动。这种不确定性在协作环境中非常致命。5.3 沙箱内网络受限技能需要外部信息怎么办陌讯Skills的默认沙箱不允许技能随便访问公网这是为了安全。但有些技能确实需要网络比如查询远程API或下载依赖包。解决办法是在SKILL.md里显式声明网络权限并在运行时配置里开通白名单域名。注意权限声明是双向的你声明之后技能运行时会获得更大的自由度但审计时也会更醒目。我的习惯是能不开网络就不开尽量把外部依赖预先放在技能包里。5.4 不同模型对技能参数的理解差异尽管陌讯Skills在协议层已经标准化但底层模型对“如何填充参数”仍然有差异。同一个技能在某个模型下调用时参数特别标准换一个模型后它可能把整个代码块塞进description字段里。我的应对方法是在主逻辑里做参数归一化如果检测到payload里某些关键字段为空尝试从附加文本里再解析一次。换句话说不要假设上游模型一定会严格遵循schema技能自身要具备一定的容错能力。这属于工程经验测试用例里应该覆盖到异常场景。最后说一点个人体会。我自己做下来的感觉是不要一开始就急着写复杂的技能先拿一个经常重复做的任务比如“代码审查”或“日志分析”把以前的提示词改造成完整技能体会一遍“定义输入、声明权限、处理输出、跑测试用例”的流程。这个过程会让你理解标准化带来的确定感比多写几个花哨提示词值钱得多。还有一个小经验调试技能时把每一步的输入输出沉淀成结构化日志不要只靠一句“它没反应”来判断。回头看日志往往一眼就能看出是参数没传对还是触发条件没命中。这里的确定性正是顶尖工程师愿意围绕陌讯Skills构建工作流的核心原因。 
长河君 · 2026/10/22 15:03:54 · 阅读 1.2k AI编程技能标准化：陌讯Skills从提示词到工程化实践
最近后台不少朋友问同一个问题怎么才能让AI在项目里不只“聊得明白”还能“干得利索”我自己的答案是——技能Skill而圈子里讨论最多的正是“陌讯Skills”。按我过去几个月的使用体验它不只是又一个提示词仓库更像是一整套把AI编程能力“标准化”的基础设施。很多顶尖工程师对它感兴趣原因也集中在“标准化”这三个字上技能可以被描述、被安装、被复用也能被测试、被追溯。这篇文章就围绕陌讯Skills说清楚它到底是什么、为什么值得用以及如何把一个真实技能从零写完并发布。1. 标准化是“AI编程技能”真正能复用的前提1.1 散装提示词为什么撑不起团队协作我早期做AI编程提效时最头疼的其实是“提示词管理”。不同成员手上都有自己的一套Prompt放在聊天记录、本地TXT、共享文档里命名千奇百怪。有的人写“帮我查Python代码问题”有的人写“你是资深后端请严格检查这段代码的潜在缺陷”。看起来都是代码审查但触达效果完全不一样换个模型换个上下文窗口结果就飘了。这个问题本质上是“散装提示词”的结构性缺陷。提示词本身没有固定元数据机器无法判断它该何时生效、该被什么参数驱动更别谈权限边界和版本升级。大家一起用的时候会出现“这个提示词只在某人电脑上有效别人复制过去就失灵”的尴尬。这种模式下单个开发者的局部效率可能很高但团队层面的资产沉淀几乎为零。把散装提示词比作自己家的随手菜谱只有自己能看懂“少许盐”是多少换个人完全无法复现。而“技能”更像标准化的料理包包装上写清了原料、做法、保质期任何人拿过来按流程操作都能得到一致的结果。1.2 陌讯Skills给出了一套统一契约陌讯Skills的关键不是提供一个存放提示词的地方而是定义了一套“技能契约”。每个技能必须包含明确的能力描述、触发条件、输入输出参数、权限声明以及可执行的实现逻辑。有了这套契约AI Agent才能在合适的场景里自动发现并调用它而不是靠用户在对话框里反复粘贴提示词。这套契约给我的感觉就像接口文档对于后端服务的意义。过去我们要求前端工程师按接口文档对接后端现在陌讯Skills要求提示词的制造者按统一规范描述能力边界。没有规范的提示词是“不可调用的”只有符合规范的技能才具备被复用的资格。对于工程师来说这意味着可以把AI编程相关的最佳实践封装成独立模块。比如“Python单元测试生成”“前端可访问性检查”“数据库索引优化建议”每一条都像工具库里的函数一样有清晰的入参、出参和副作用描述。使用方根本不用关心内部Prompt怎么写的只需要按接口调用。1.3 解决的不只是个人效率更是团队资产沉淀在真实项目里沉淀知识比写代码更难。一个团队磨合出的Code Review清单、上线前的安全扫描规则、日志分析套路如果只存在某几个老手脑子里新人永远接不上。而把这类经验写成技能放进陌讯Skills生态团队里任何人拉起Agent都能使用同一套判断标准。我参与的一个后端项目就把“慢SQL排查”做成技能。这个技能里封装了我们对慢查询的常规分析流程先看执行计划再检查索引使用然后结合表数据量判断是否需要分页优化。过去老员工要花半小时讲一遍流程现在新人只要在Agent里唤起对应技能它会自动按步骤分析并输出结论。这就是标准化带来的团队级收益知识从个人经验变成了可调用的组织资产。2. 陌讯Skills的标准化协议到底规范了什么2.1 一个技能包长什么样陌讯Skills对技能包的目录结构有明确约定。一个最小技能通常包含技能描述文件、实现脚本、输入输出Schema、依赖声明和测试用例。我自己常用的目录大概是my-skill/ ├── SKILL.md ├── main.py ├── schema.json ├── requirements.txt ├── tests/ │ ├── cases.json │ └── run_test.sh └── README.md其中SKILL.md是核心很多新人不重视它其实它承担了技能被“发现”和“触发”的重任。下面是一个我写过的代码审查技能的简化版name: code-review-python description: | 对一段Python代码进行基础质量检查重点关注未使用变量、重复定义的函数、 明显的空异常处理。适合在提交Pull Request之前运行。 version: 1.2.0 author: skill-community-contributor trigger: keywords: - python code review - python 代码检查 - check python context: - code_block: python arguments: code: type: string required: true description: 待检查的Python源码 rules: type: array required: false description: 需要启用的检查规则ID列表 permissions: network: false filesystem: read-only output: type: json fields: - severity - line - message - rule_id每一个字段背后都有用意。name和description用于索引模型可以据此判断“这个技能适不适用于当前任务”。trigger描述匹配规则当用户请求中出现相关关键词Agent自动决定是否加载。arguments定义了结构化参数比从提示词里猜测可靠得多。permissions限制了技能能访问什么资源这直接关系到在企业内部落地的安全性。2.2 执行逻辑与工具调用规范光有描述还不够技能还要有真正可运行的实现。在陌讯Skills里实现逻辑通常是一段独立脚本或HTTP服务。以我们常用的Python技能为例脚本从标准输入读取JSON请求经过处理后再从标准输出返回JSON结果。这种“统一管道”的设计让任何大模型都能以相同方式调用任意技能不绑定特定厂商的私有协议。我写的一个简化版本会长这样#!/usr/bin/env python3 import ast import sys import json def check_unused_imports(tree): ... return issues def check_redefined_functions(tree): ... return issues def main(): raw sys.stdin.read() payload json.loads(raw) code payload[code] tree ast.parse(code) issues check_unused_imports(tree) issues check_redefined_functions(tree) print(json.dumps({issues: issues}, ensure_asciiFalse)) if __name__ __main__: main()脚本只做一件事接收统一JSON输入产出统一JSON输出。Agent不需要知道内部怎么用AST只需要把源码字段填进去等等结果。这种“标准接口”让技能像Unix工具一样可以被组合也可以被其他技能调用。2.3 版本、依赖与兼容性管理标准化革命里最被低估的一块是版本管理。过去一个提示词改来改去根本说不清现在线上跑的是哪个版本。陌讯Skills引入了类似npm的版本语义每个技能有版本号、变更记录、兼容性声明。技能之间也可以互相依赖比如代码检查技能可以依赖一个公共的“规则库技能”规则库升级时引用它的技能可以选择跟随主版本。我把这种设计理解为“把工程化常识搬进AI技能世界”。前端有package.jsonPython有requirements.txt为什么AI技能不能有依赖锁和版本回滚陌讯Skills正是把这一点做到了生态层面。你在项目里锁定某个技能版本后即使上游发布新版本也不会影响当前项目稳定性直到你主动升级。3. 顶尖工程师为什么选它我在真实场景里看到的三个理由3.1 场景一从单模型到多模型技能无缝迁移今年我们团队项目里换过一次底层模型。按照以前的玩法针对旧模型调优的那么多提示词基本等于作废得逐条重新调。但用了陌讯Skills后情况完全不同技能是独立于模型运行的Agent只是通过标准协议调用它模型本身的差异被屏蔽掉了。比如同一个“Python代码审查”技能在模型A下可以使用迁移到模型B之后依然可以调用。因为技能的执行逻辑跑在沙箱里模型只负责理解请求、填充参数、解析输出。我不需要因为换模型就去重写技能内部逻辑。这对工程师来说是实打实降低技术栈锁定风险。3.2 场景二团队代码规范与安全检查自动化日常Code Review中最耗精力的其实是批量化的“规则检查”。比如导入排序、未使用变量、缺少异常上下文、硬编码密钥等。这些事情完全适合交给技能自动化。我们在团队内把一套基于陌讯Skills的“安全扫描技能”接入Pre-commit流程每次提交代码前自动跑一遍。技能的输入是本次改动的Diff输出是风险级别列表。它会指出疑似密钥泄漏的位置、未处理的异常分支、过于宽泛的except语句。常规错误在进入人工Review之前就被挡掉Review效率提升非常明显。这个技能并不追求替代人而是把机械的工作从人身上卸下来。3.3 场景三告别“提示词膨胀”维护成本直线下降你肯定体会过“提示词膨胀”为了让模型按预期输出不断往上堆例子和约束最后一段提示词几千字稍微改一点就会连锁失效。技能化之后这些内容被拆分到独立的规则文件和测试用例里不再是“一坨”不可维护的文本。一次我们修改了输出格式要求从旧的“自然语言结论”改成“JSON结构化报告”。过去要挨个改所有聊天模板现在只需要改技能的schema定义和解析逻辑然后跑一遍测试用例确认输出兼容。这种可测试性是散装提示词完全给不了的。3.4 “国内最全”生态不只是一句宣传语我看过不少技能平台多半停留在示例Demo层面。陌讯Skills让我觉得不一样的是生态厚度技能分类覆盖从后端开发到数据分析从运维脚本到前端组件检查甚至还有针对具体行业场景的模板。很多技能不是官方随手写的而是社区开发者在真实项目中打磨出来的附带了测试数据和版本记录。最直接的感觉是我在里面搜一个“PostgreSQL慢查询分析”技能能找到多个版本各自有优缺点说明、评价、尝鲜数量。这就像一个成熟包管理器该有的样子。缺的不是“能跑的示例”而是“可比较、可信任、可迭代”的选项。4. 实操从零创建一个陌讯Skill并发布4.1 环境准备与脚手架在电脑上安装陌讯Skills的命令行工具后初始化技能非常快。我习惯用官方脚手架curl -sSL https://example.com/install | sh mx skill init code-review-for-python执行后会生成一个标准目录剩下的事情就是往里面填内容。这个初始化动作的价值在于它替你把契约和目录结构定好了你不需要一开始就记住所有规范。安装完成之后最好先跑一下自带示例mx skill test my-skill确保本地的技能运行环境能正常工作。这个环节很基础但能避免后续因为环境缺失浪费大量时间。4.2 填写SKILL.md和实现逻辑初始化生成的是模板要替换成自己的描述和实现。我建议先写SKILL.md因为它迫使你思考“什么时候触发”“需要什么参数”“输出什么格式”想清楚再写代码比先写代码再补描述顺畅很多。接着在main.py里写核心逻辑。下面是我在做“未使用变量检查”时的一段实现import ast import sys import json def detect_unused_vars(source: str): tree ast.parse(source) defined {} for node in ast.walk(tree): if isinstance(node, ast.Name) and isinstance(node.ctx, ast.Store): defined[node.id] node.lineno used set() for node in ast.walk(tree): if isinstance(node, ast.Name) and isinstance(node.ctx, ast.Load): used.add(node.id) unused {name: line for name, line in defined.items() if name not in used} return [{line: line, name: name} for name, line in unused.items()] def main(): payload json.loads(sys.stdin.read()) source payload.get(code, ) try: issues detect_unused_vars(source) print(json.dumps({status: ok, issues: issues}, ensure_asciiFalse)) except SyntaxError as e: print(json.dumps({status: error, message: str(e)}, ensure_asciiFalse)) if __name__ __main__: main()需要注意技能脚本的输入输出必须是严格的JSON。我踩过几次坑当时在print里混入了日志信息Agent解析时直接失败。所以上了生产后所有额外的日志都要打到stderrstdout只留给JSON结果。4.3 本地测试与调试写好脚本后用测试用例手动模拟Agent调用echo {code: def f():\n x 1\n return 2} | mx skill run ./my-skill如果返回的结果包含未使用变量x说明逻辑正确。陌讯Skills还支持在schema.json里声明多组测试用例方便后续回归{ cases: [ { input: {code: def f():\n x 1\n return 2}, expected: {status: ok, issues: [{line: 2, name: x}]} } ] }有了测试用例技能后续修改才敢放开手脚。我通常会在本地跑三组用例正常代码、带语法错误的代码、空代码。保证边界情况不会让技能崩溃。4.4 发布到陌讯生态本地跑通后发布操作也走命令行mx skill publish ./my-skill发布前会自动做一轮检查包括SKILL.md字段是否完整、脚本是否有语法错误、声明的权限和实际行为是否一致。通过后会生成一个唯一技能标识类似包管理器里的包名。这一步我建议把README写详细一些说明使用场景、参数含义、常见问题。社区里的工程师判断一个技能是否可用很大程度看说明文档是否清晰。一个没有文档的技能即使功能很强也容易被埋没。4.5 在Agent项目里接入发布之后使用方只需要在项目配置里声明引入skills: - name: code-review-for-python version: 1.2.0 source: mx-community/xxx代码里调用时可以走官方SDKfrom mxskills import load_skill skill load_skill(code-review-for-python, version1.2.0) result skill.run({code: source_code})接入之后Agent会在用户请求匹配到触发条件时自动加载技能并按规范填充参数。这句体验让我感觉AI应用开发真的进入了“依赖管理”时代而不是每次都要手动拼提示词。5. 常见问题与避坑指南5.1 技能没有被触发先查触发条件我见过最多的问题是技能发布后发现Agent一直不调用。排查的时候不要先怀疑Agent先看SKILL.md里的trigger。很多技能的trigger写得太死比如只监听“code review”用户说“帮我审查这段代码”时反而匹配不到。排查项检查点关键词描述是否覆盖了用户常见的自然表达方式上下文条件是否设置了过严的上下文限制比如代码语言类型不匹配版本缓存是否Agent还缓存着旧版本的技能描述建议在description里多写几个同义词和典型场景而不是只写一个正式名词。触发规则本质上是在帮技能做召回召回范围太小能力再强也用不上。5.2 版本升级后行为不对回滚旧版本技能升级后可能出现“工作方式变了但团队还适应不了”的情况。比如新版本把输出结构改了下游解析逻辑跟不上。这时候正确做法不是立刻让所有人改代码而是回滚技能版本。在配置里把version改回原版本重新启动Agent任务即可。这也是我在前面强调锁版本的原因。如果你不锁版本技能发布方一旦升级你的项目将被动变动。这种不确定性在协作环境中非常致命。5.3 沙箱内网络受限技能需要外部信息怎么办陌讯Skills的默认沙箱不允许技能随便访问公网这是为了安全。但有些技能确实需要网络比如查询远程API或下载依赖包。解决办法是在SKILL.md里显式声明网络权限并在运行时配置里开通白名单域名。注意权限声明是双向的你声明之后技能运行时会获得更大的自由度但审计时也会更醒目。我的习惯是能不开网络就不开尽量把外部依赖预先放在技能包里。5.4 不同模型对技能参数的理解差异尽管陌讯Skills在协议层已经标准化但底层模型对“如何填充参数”仍然有差异。同一个技能在某个模型下调用时参数特别标准换一个模型后它可能把整个代码块塞进description字段里。我的应对方法是在主逻辑里做参数归一化如果检测到payload里某些关键字段为空尝试从附加文本里再解析一次。换句话说不要假设上游模型一定会严格遵循schema技能自身要具备一定的容错能力。这属于工程经验测试用例里应该覆盖到异常场景。最后说一点个人体会。我自己做下来的感觉是不要一开始就急着写复杂的技能先拿一个经常重复做的任务比如“代码审查”或“日志分析”把以前的提示词改造成完整技能体会一遍“定义输入、声明权限、处理输出、跑测试用例”的流程。这个过程会让你理解标准化带来的确定感比多写几个花哨提示词值钱得多。还有一个小经验调试技能时把每一步的输入输出沉淀成结构化日志不要只靠一句“它没反应”来判断。回头看日志往往一眼就能看出是参数没传对还是触发条件没命中。这里的确定性正是顶尖工程师愿意围绕陌讯Skills构建工作流的核心原因。