夜雨聆风这两天看到一篇新论文，我挺兴奋
arXiv 上线了一篇专门研究 AI Agent Skills 的实证论文，题目叫《From Registry to Repository: How AI Agent Skills Are Written, Adapted, and Maintained》
它最有意思的地方在于，终于有人把 Skills 放到软件工程视角里研究了
以前大家聊 Skills，更多是在聊"怎么让 Agent 更听话"
这篇论文换了个角度：Skills 已经是一种会被编写、复用、定制、维护的软件工件
这句话我太认了
因为我自己现在的工作区里，写文章、转视频、图床上传、质量检查、飞书白板配图，全都靠 Skills 串起来，它早就超出了"一段提示词"的范畴，更像一个小型软件包：有入口、有流程、有依赖、有脚本、有验收标准，也会随着工具链变化持续更新
论文到底研究了什么
这篇论文的样本量不小
作者团队挖了两类 Skills：
skills.sh 注册表里的 18,463 个 Skills GitHub 上 5,876 个仓库里的 23,199 个个人使用 Skills 通过名称和内容相似度，恢复出 3,709 条复用关系
论文的研究设计大概长这样：
它问了三个问题：
Skills 覆盖哪些软件工程知识领域 Skills 通常怎么写、怎么打包、里面到底装了什么 Skills 被复制到仓库后，开发者会怎么改、怎么维护
这个问题设计很有工程味
如果你把 Skills 当成软件资产，这三个问题就对应了软件资产的三个基本面：分类、结构、生命周期
第一件事：Skills 已经有明显的软件工程分布
作者用 SWEBOK，也就是软件工程知识体系，把这些 Skills 做了分类
结果挺符合直觉：Software Construction，也就是软件构建，占比最高
论文里给出的数据是：
skills.sh 注册表里的 Skills，Software Construction 占 28.3% GitHub 个人使用 Skills，Software Construction 占 22.1% 软件运维、测试、配置管理紧随其后 还有接近三成 Skills 没法归入传统软件工程分类，说明 Skills 已经溢出到语音、内容、办公等更宽场景
论文里的分布图很直观：
这里有个细节我很喜欢
注册表里的 Skills 更偏通用能力，比如代码生成、架构设计、安全检查
GitHub 个人仓库里的 Skills 更偏项目现场，比如配置管理、测试、质量、维护
这跟普通软件生态太像了
公共 npm 包提供通用能力，本地代码解决项目自己的脏活累活，Skills 也在走类似路径：公共注册表负责"大家都需要的能力"，个人仓库沉淀"我这个项目专属的经验"
第二件事：Skills 的结构开始像软件包
论文没有只看文本内容，还看了 Skills 的包装方式
一个典型 Skill 更像一个目录：
SKILL.md作为主入口YAML frontmatter 写 name 和 description Markdown 正文写工作流、边界、规则 可选的 scripts/、references/、assets/放脚本、参考材料、模板资源
作者统计后发现，注册表 Skills 普遍更长、更分层：
注册表 Skills 的 SKILL.md中位数是 1,678 tokens个人使用 Skills 的中位数是 1,114 tokens 注册表 Skills 的 Markdown 标题中位数是 19 个 个人使用 Skills 的中位数是 13 个
换句话说，被拿出来共享的 Skills 往往写得更像产品文档，结构更细，边界更清楚
但它也暴露出一个问题：可选元数据和资源目录还很稀疏
比如 license、compatibility、metadata、allowed-tools 这些字段出现率普遍只有个位数到十几个百分点，scripts/ 和 assets/ 的使用率也不高
这说明 Skills 生态还在很早期
大家已经意识到要把工作流打包，但还没形成稳定的软件包规范
第三件事：一个好 Skill 里通常装了六类东西
论文抽样分析了 180 个 SKILL.md，最后归纳出六类内容
我把它翻译成更接地气的说法：
这六类放一起看，已经非常像一个小型软件系统的说明书
它有接口，有运行时，有错误处理，有质量门禁，有领域数据，还有人机协作协议
我之前写 Skills 的时候，踩过很多坑
最初只写"请帮我把文章转成视频脚本"，效果很飘，后来慢慢加上输入格式、输出模板、分镜规则、镜头节奏、失败回退、最终保存路径，Agent 才开始稳定
这篇论文等于是用大样本证明了这个经验：真正好用的 Skills，核心价值在工程约束
最关键的发现：复用大多是一次性复制
这篇论文最扎心的数据来了
我把论文里的生命周期和风险点整理成一张图：
在软件工程相关的 2,462 条复用关系里，1,841 个 Skills 几乎原样被复制到个人仓库
更关键的是，复用后真正持续更新的比例并不高
论文统计，一年窗口内：
被复用的 Skills 里，只有 47.4% 在采用后发生过本地更新 也就是说，约 53% 被采用后再也没动过 在那些本地没更新的复用 Skills 里，40.2% 的上游源 Skill 后来发生过更新，但本地副本没有同步 在本地和上游都更新的场景里，62.3% 是各改各的，本地没有重新吸收上游变化
这就很像早期复制粘贴代码的老问题
你从网上抄了一个工具函数，放到项目里能跑，后面原作者修了 bug，你本地完全不知道
Skills 现在也出现了同样的问题
更麻烦的是，代码坏了通常会报错，Skill 坏了可能表现得很温柔：Agent 只是悄悄按旧流程做事，悄悄用过期路径，悄悄跳过新约束，最后你得到一个看起来合理、实际已经偏航的结果
Skills 的维护方式也很像文档
论文还发现，Skills 的维护有个明显倾向：加东西远多于删东西
排除修改项后，新增和删除的比例是 2.7:1
如果只看本地演化，新增和删除的比例更夸张，达到 6.1:1
这个现象太真实了
我们写 Skills 的时候，经常是 Agent 又犯了一个错，于是加一条规则
又遇到一个环境坑，于是加一段说明
又发现输出不稳定，于是加一个检查表
最后 Skill 越写越长，像一份不断膨胀的项目文档
这有好处，经验都沉淀下来了
也有坏处，没人定期清理的话，旧规则会和新规则打架，触发条件会越来越模糊，Agent 读完也容易懵
所以我现在越来越觉得，写 Skill 要有"维护者意识"
一个 Skill 至少要有：
版本记录：这次改动解决什么问题 适用范围：哪些项目能用，哪些场景要避开 验收样例：跑完后怎么判断结果合格 依赖清单：用了哪些 CLI、API、环境变量 上游来源：从哪个公共 Skill 改来的，后续怎么同步
这些听起来像软件工程老生常谈，但放到 Agent 时代，突然又变得新鲜了
最容易被忽视的地方：行为契约很少被改
论文里还有一个观察，我觉得特别值得警惕
开发者会频繁修改触发条件、工具路径、参考资料、输出格式
但有三类内容很少被改：
Agent 怎么和用户互动 Agent 怎么监控运行状态 Agent 失败时怎么恢复
论文把这些称为一种稳定的 behavioural contract，行为契约
这意味着什么
一个公共 Skill 被复制到你的仓库后，最容易原封带走的，往往就是这些看不见的行为规则
如果原 Skill 写得好，它会像安全带一样保护你
如果原 Skill 里面有偷懒的交互方式、危险的默认动作、糟糕的失败回退，它也会一起被继承
这也是我现在看 Skills 最关注的地方
我会先看它有没有写清楚这几件事：
遇到不确定信息要不要问用户 会不会在没有确认的情况下改文件、删文件、发消息 命令失败后是重试、回滚，还是把错误贴出来 最终交付前有没有验证动作 有没有明确禁止危险操作
模型越来越强后，真正决定安全边界的，很多时候就是这些小规则
Agent 的下一层竞争，模型之外还有 Skills
这篇论文对我最大的启发，是它把 Skills 从"个人效率小技巧"抬到了"软件资产管理"的位置
未来公司里可能会有三类仓库：
代码仓库：放产品代码 文档仓库：放人看的知识 Skills 仓库：放 Agent 执行工作的知识
第三类仓库会越来越重要
因为 Agent 真正落地时，模型只是发动机，Skills 决定它在你的组织里怎么跑
同一个模型，给它一套烂 Skill，它会像新员工一样到处乱撞
给它一套成熟 Skill，它就像被资深同事带过，知道你们的路径、规矩、工具、禁区、验收方式
我甚至觉得，未来很多团队的 AI 护城河，未必只在模型 API 调用量，而在这套内部 Skills 资产
谁的 Skills 覆盖更多业务流程，谁的验证规则更扎实，谁的失败恢复更可靠，谁就能更快把 Agent 放进真实生产环境
给写 Skills 的几个建议
结合这篇论文和我自己的使用经验，我建议大家以后写 Skills 按软件资产来写
第一，别只写愿望，要写流程
少写"请高质量完成"，多写"先收集输入，再判断边界，再生成草稿，再跑检查，再保存到指定路径"
Agent 需要可执行的路径，不需要空泛口号
第二，把触发词写具体
description 不要写成"帮助用户处理文档"，要写成"当用户要求 Markdown 转 Word、导出 docx、生成公众号排版文档时使用"
触发越具体，Agent 越不容易漏用
第三，脚本能解决的就交给脚本
自然语言适合表达判断，脚本适合做确定性动作
比如批量上传图片、合规扫描、格式转换，这种就该放到 scripts/ 里，让 Agent 调用工具，减少现场发挥
第四，必须有验证步骤
一个 Skill 如果没有验收标准，就像一段没有测试的代码
写文章要查句号、查外链、查事实来源
写代码要跑测试、看 diff、检查 lint
做数据分析要核对样本量、过滤条件、口径定义
第五，定期清理
Skill 很容易越写越厚
每隔一段时间要删掉过期规则，合并重复规则，检查外部链接和命令是否还有效
这件事以后可能会变成新岗位：Skill Maintainer
总结
这篇论文的价值，核心在于用实证数据提醒我们：Skills 已经进入软件工程问题域
它会被写出来，会被复制，会被改造，会过期，会漂移，也会沉淀组织经验
我一直说 Skills 重要，现在论文也来了
如果你还在把 Skills 当作"高级提示词收藏夹"，建议从今天开始换个视角：把它当成 Agent 时代的软件资产来设计、维护、测试和版本化