智能体技能是用什么语言写的？
论文信息
论文信息
摘要
2026 年第一季度，新编写的智能体技能中有 13.0% 使用的语言不是英语；一个季度之后，这个比例变成了 16.3%。也就是说，在三个月内，对 255,068 个技能样本而言，非英语占比提升了三个百分点，而且置信区间相距甚远，完全没有重叠。作为对比，GitHub 全站的非英语文档从 3.7% 涨到 13.0% 花了整整十年。因此，眼前这件事的推进速度完全是另一个量级。最合理的解释是：AI 开发的中心已经来到了旧金山以外的地方。
仔细看数据会发现，这个结论比表面上看起来更强，因为“用英语”并不等于“来自美国”。GitHub 上增长最快的开发者群体是印度，他们用英语写代码；尼日利亚和新加坡也是如此。因此，单靠语言统计根本看不见这些国家的身影。所以，非英语占比并不能衡量这个生态圈有多少位于美国之外。它只是一个下限，所有低于这个数字的估计都应该作此理解。
介绍一下背景：技能（skill）就是一个文件夹里的 SKILL.md 文件，里面用普通文字写明给 AI 智能体的操作说明。当智能体判断某个任务相关时，就会加载这个文件。Anthropic 在 2025 年 10 月发布了这个规范。它像菜谱一样传播：有人复制，就传开了。九个月后，公开仓库里已经有 380 万个这样的文件，分散在 282,200 个仓库中——这就是 GitSkills 数据集收集到的内容。
以传统软件（也就是我们通常说的软件）的标准看，技能非常奇怪，因为这正是 AI 颠覆的领域之一。技能用人类语言编写，运行环境是一个多语言模型，因此没有任何技术理由必须用英语写。深圳或圣保罗的开发者完全可以用自己的语言更精确地描述流程，智能体也会照做。至于智能体能不能同样好地执行，那才是更值得问的问题，比用爬虫扫文件能回答的任何问题都难得多。
分布情况
我们对每个去重后的技能，先剔除文件头元信息（front matter）和围栏代码块，再对正文部分做语言识别。
所以，14.3% 的技能不是用英文写的。按文字系统拆分的话，简体中文有 104,985 个，繁体中文有 9,112 个。上面这些行加起来并不完全等于这个总数，因为有 6,810 个技能的识别结果低于我们的置信度下限，两边都不算。更值得比较的对象是 GitHub 自己的文档，而不是它的 issue 或 pull request。2026 年 ICSE（国际软件工程会议）的一项研究把仓库文档中的非英文比例定为 13.0%，其中中文占仓库的 3.3%。总体来看，技能在这方面并不显眼：14.3% 对 13.0%，几乎持平。不过中文的比例明显更高：6.2% 对 3.3%。
为什么每个公开的数字都不一样
我们不是唯一公布数字的人，而这些公开数字彼此并不一致。
这些并不是矛盾，而是五个不同的统计人群：精选市场偏向英文，按领域切分的数据偏向该领域活跃的地区，而以英文查询为种子抓到的数据自然偏英文。第一个要排除的候选是我们自己，因为如果我们的识别器看到的英文比其他人的都少，那么整个比较就只是工具造成的错觉。于是我们在同一批文档上跑了两套工具：我们自己用的 py3langid，以及 92.6% 那项研究用的 fast-langdetect。两者在 97.6% 的文档上结果一致，英文占比只差了 1.2 个百分点，而我们要解释的差距大约有七个百分点。下一个候选是质量筛选，但它也解释不了什么：如果按“有效 front matter（文件开头的元数据区块）”过滤的语料库悄悄丢弃了非英文技能，那的确能解释一部分差距，但实际上非英文技能的 front matter 有效性反而略好，88.1% 对 86.6%，过滤后英文占比只从 85.6% 变成 85.4%。剩下的解释就是：你看的是什么地方。这一点完全可以推广到本数据集之外——所以，当有人告诉你“AI 生态系统”是什么样的，他抓取的仓库注册表可能比他说的话更能说明问题。
技能里的英文正在变少
技能自带提交历史，因此每个技能都有创建日期，这就可以把静态的饼图变成一条趋势线。
逐月看，上升并不平滑：2月回落到10.9%，3月又回升到14.2%。但窗口期内的方向没有疑问：1月为13.1%，6月为17.6%。这个速度大致符合一个诞生仅18个月的格式——在没有旧格式需要取代时，新类型产物获得自己用户群的速度本来就比成熟格式快得多。不过“非英语”并不是一个单一类别；拆开看，涨幅主要由四组里的两组带动，而不是全部。
我们把德语、法语、西班牙语、葡萄牙语、意大利语、俄语和荷兰语合为“欧洲语言”一组。这一组在整个窗口期内占比翻了一倍多；中文持续稳步上升；日语和韩语则不属于这两种情况：到2025年底，日语还是最常见的非英语语言，但2026年上半年随着其他语言相继进入，日语占比一路下滑；韩语则始终持平。被截断（censored，数据还未收满）的7月队列暗示日语正在回升，但我们不把它计入比较。由于最后一列是7月的采集月、数据不完整，所有变化都以两个完整季度为基准衡量，也就是2026年Q1和Q2；7月数据会出现在图中，但从不参与对比。
为什么我们相信这个趋势
这类趋势恰恰是最容易变成统计假象（artifact）的东西，所以我们在推翻它上面花的时间比发现它更长。全部技能里只有24%留有提交历史（commit history），而这个子样本偏向于被大量复制的那一批——这很关键，因为复制行为与语言之间的关联很强。换句话说，我们担心看到的是选择效应（selection effect），而不是人们实际书写内容的变化。在把复制次数固定为1后，涨幅比整体数字更大：14.7%到18.1%；在把每个仓库只计一次、避免任何批量上传者单方面拉动数据后，涨幅依然存在：14.5%到16.8%。
时钟
提交时间戳以UTC（协调世界时）存储，所以在我们看到文件之前，作者的本地时区已经丢失。但大多数人只在自己醒着的时候提交。如果某一组技能出自世界某个地区的人之手，那么在那一地区的夜间，这些提交记录应该会消失。
在那一时段，中文技能的提交量不到英文的一半，而英文本身在二十四小时里保持平稳，这正是全球分布人群的特征——没有统一的夜间。西班牙语和葡萄牙语则相反，在UTC 19:00达到峰值，对应巴西的下午和伊比利亚的傍晚，说明这些作者位于美洲。语言识别器并不知道文件提交的具体时间，所以这两个信号相互独立，却彼此吻合。
诚实的局限
这是一种人群层面的相位估计，误差至少两小时左右；它无法区分UTC+8与UTC+9，语言不等于国家，也不针对任何单个作者下结论。我们没有找到公开的、针对这种粒度的时刻推断验证，所以只应把它视为佐证，而非地理定位。原始git提交确实记录了作者的UTC偏移，而这个数据集将其归一化处理掉了——这是任何在此基础上构建的人需要修正的地方。
外部视角的同一故事
我们读到的只是单个平台上的单一工件类型，所以关键问题在于：用其他方式衡量的人是否看到同样的趋势？他们确实看到了，而且规模比我们能做到的大得多。
GitHub自己的Octoverse 2025报告称，印度一年内新增了520万名开发者，占全球新开设的3600万个账户的约14%，使其开发者总数达到2190万，位列全球第二。这是其2020年人数的4.9倍。同期巴西增长了4.1倍，印度尼西亚4.8倍，日本翻了三倍；目前亚太地区每分钟约有25个新注册，而欧洲只有12个。印度、巴西和印度尼西亚合计占所有新账户的一半左右。斯坦福大学2026年AI指数报告显示，生成式AI采用率在阿联酋为64%，新加坡为61%，而美国仅为28.3%，排在第24位。其政策章节记录到“世界其他地区在GitHub上的开源贡献现在已经超过欧洲，并接近美国”；教育章节则发现AI工程技能的增长速度在阿联酋、智利和南非最快。
这些指标和智能体技能本身毫无关系，但恰恰是这点让它们有价值：三项独立的测量都在追踪 AI 开发正在哪里发生，没有一项去看 SKILL.md 文件，却全指向同一个方向。我们的数字是同一个现象在一个十八个月前的语料库里的体现，而且这个数字还窥不见全貌。印度用英语写代码，所以 GitHub 增长的最大单一引擎在语言统计中是隐形的，尼日利亚和新加坡也一样。因此，14.3% 这个数应当被视为一个下限，真正位于美国之外的这个生态系统的占比只会比它更高。
复制，还是维护？
英语技能被复制得更多。一个技能被复用得越频繁，非英语技能的占比就越稳定地下降：从从未被复制过的技能中的 15.7%，一路降到被复制六次及以上的技能中的 5.8%。这个结论需要一点辩护，因为 GitHub 上很多看起来像复制的事情其实是在归档。十个仓库收容了这里所有技能文件的 14.5%，它们是注册表或镜像，而不是作者本人，所以 282,200 个仓库按集中度折算，行为上大约相当于 250 个左右。这些聚合仓库碰巧偏向非英语：非英语占比 20.5%，而其他地方只有 13.7%。所以无论它们对数字做了什么手脚，都是在抵消这个趋势，而不是制造它。把它们排除后，差距依然如故：从 15.1% 降到 5.3%。再按不同所有者来计数——也就是同一个贡献者把一个技能内置进自己的十个仓库只算一次——差距还会略微拉大，变成 15.1% 对 4.6%。
但非英语技能被修订得更多。这里需要做一次年龄校正，因为非英语技能平均更年轻，被改动的机会也更少。下面的比较把年龄固定住，问这样一个问题：在存在了至少 N 天的技能中，有多大比例是在它们诞生后的头 N 天里就被修订过的？
差距在第一个月内迅速拉开，之后一直保持稳定：一周时相差 1.3 个百分点，一个月时 5.2 个百分点，三个月时仍是 5.2 个百分点。这导致两类技能呈现出截然不同的生存方式：英语技能靠“传播”，写一次、被大范围复制，之后几乎不再改动；非英语技能则靠“照料”，被复制得少，却被反复修订。
复制占主导的那一半，原因很可能出在搜索上。技能的发现机制是词法层面的——也就是靠逐字文本匹配。一个用英语搜索的开发者，根本不会看到用中文写的技能，即使多语言模型完全有能力把它执行得很好。因此，一个深圳开发者写出的技能，和真正需要它的人之间，隔着的仅仅是一次文本匹配。如果这个判断正确，那么整个生态系统的全球化，会先发生在“写什么”上，之后才轮到“用什么”；而这中间的滞后，是一个某个工具厂商完全可以解决的工程问题。
到底是谁在写这些技能？
GitSkills 的作者们还追问了一个更值得回答的问题：有多少技能是智能体（agent，能自主执行任务的 AI 程序）自己写的？最直接的检验方法立刻就会失败，因为 GitHub 自带的机器人标记几乎什么都抓不到——智能体写的代码，是以人类账号的名义提交的。真正有效的信号是提交尾注（commit trailer，提交信息末尾的元数据块）：编码智能体会在它生成的提交末尾附上一行 Co-Authored-By（共同作者）署名。这是工具自己在声明作者身份，而不是我们根据行文风格去推测。
近三分之一的技能都带着智能体的指纹，而平台对此几乎毫无察觉。在这些署名中，Claude 占了压倒性多数，Cursor、Copilot 和 Codex 远远落在后面；署名行甚至会带上模型版本号。可以把这组数字当作一个下限来看——因为如果一个技能的作者亲手删掉了署名、在压缩提交时抹掉了它，或者所用的工具根本不生成署名，那么这个技能在这里就会被统计成“人类写的”。
这些数据没有展示什么
语言识别主要看书写体系和虚词，因此一篇满是英语技术词汇的德语技能，会被算法拉向英语一边——这也是为什么前面算出的非英语占比只是一个下限（lower bound，即真实比例只会更高，不会更低）。
日期信息只覆盖了语料库的一部分，而且只针对去重后的代表样本。所以这里的“创建时间”指的是某个提交第一次触及这个文件副本的时间，并不代表该内容第一次出现在任何地方。另外，爬虫只能看到存活至今的文件，任何在 2026 年 7 月之前被创建、后来又被删除的技能，对我们来说都是隐形的。这会让文中所有与维护相关的数字都被高估，而高估的幅度我们无法估算。
我们接下来想知道什么
这些数据无法回答的一个问题是：这种语言分布到底会不会造成实际代价。一个用中文写成、从未被复制的技能，可能质量更差，也可能只是没人发现的重复劳动——这两种世界在文件爬取里看起来一模一样，却指向完全相反的结论。要把它们区分开，需要执行轨迹（execution traces，即技能实际运行时留下的记录）这类数据；如果谁手里有，我们很愿意看看。
更大的问题在于，那个“下限”究竟靠什么支撑。目前 14.3% 的技能不是用英语写的，而且这个比例每个季度上升 3 个百分点；与此同时，平台上增长最快的开发者群体用的是英语，他们根本不会进入这个非英语统计。无论真实数字是多少，我们所有能测到的迹象都表明它正朝同一个方向移动，而且速度比以往任何可类比的对象都快。
第二篇（Article 02）将继续使用这个语料库，研究技能里涉及哪些编程语言。我们第一轮统计时，Shell/Bash 以 37.5% 的比例领跑所有语言，后来发现这是把粘贴进来的命令也算进去造成的统计假象（artifact，即测量方式带来的误导性结果）；改按技能实际交付的内容来衡量后，Python 以 7.6% 领跑，Shell 则降到 3.1%。
致谢
没有这份数据集，本文的一切都不存在。该数据集由他人构建并公开发布，收集、去重并整理这 380 万个技能文件的功劳，全部归于其作者：
Giuseppe Destefanis, Daniel Graziotin, Matteo Vaccargiu, and Marco Ortu. 2027. GitSkills: A Dataset of Agent Skills on GitHub. In Proceedings of the 24th International Conference on Mining Software Repositories (MSR '27).
GitSkills 是 MSR '27 挖掘挑战赛（Mining Challenge）使用的数据集。我们与该数据集的作者、MSR 或挑战赛主办方均无关联，因此本分析中的任何内容都不应被视为他们的立场：数据集归他们所有，而分析工作及其中的任何错误由我们负责。我们探讨的若干研究问题（例如这些技能是用哪些自然语言编写的）正是 GitSkills 作者提出但尚未回答的问题。
预印本：arXiv:2608.10906；存档：10.5281/zenodo.21875637；Parquet 镜像：mvaccargiu/gitskills；样本：giuseppedestefanis/gitskills-sample；许可协议：CC BY 4.0。
分析代码位于 github.com/plicara/articlesundergitskills-analysis/。其中的每张图表都由同一份机器可读的导出数据自动生成，没有任何手工绘制，因此整套分析可以随时重新生成、随时复核。
发现错误？我们由衷希望您能告诉我们。