2026年，全世界的程序员每天往GitHub上传的代码已经堆积成山。有意思的是，这些代码里藏着一个几乎没人正经挖过的宝藏：无数被调试过、被验证过、被反复打磨过的解决问题的经验。
蚂蚁国际的一支研究团队盯上了这件事。他们想问一个问题：能不能让AI从这堆代码里，自动学会怎么解决问题，而不是让AI从零摸索，或者干等着人类写教程？
这个问题听起来简单，做起来却踩了不少坑。我们一步步拆开看。
**当AI智能体遇到真实世界的复杂任务**
先说说背景。现在的AI智能体已经不满足于简单的问答了，它们要处理软件工程、数学推理、系统操作这类需要多步骤、长时间规划的复杂任务。这类任务光靠模型参数里存的知识是不够的，智能体还得会调用工具、能从失败中学习、能跟别的智能体协作。
支撑这一切运转的，是一种叫"技能"的东西。
**技能（Skill）**：指的是可复用的操作性知识，加上使用这些知识的适用条件。简单说，就是"什么情况下该怎么做"的打包方案，智能体在执行任务时可以随时调取。
技能这东西好处很明显，可以独立更新、独立部署，不用重新训练整个模型就能给AI"打补丁"。但问题是，技能从哪来？
目前主要有两条路。第一条路是从**智能体的执行轨迹（trajectory）**里提炼，也就是让AI自己去跑任务，把成功的、失败的经验整理成技能。这条路的毛病是，技能质量完全取决于生成它的那个智能体本身有多强，模型一换、任务一变，之前攒的经验可能就不好使了。
第二条路是从文档里提炼，比如说明书、教程之类的文本资料。这条路避开了对AI自身经验的依赖，但有个致命缺陷：这些技能缺乏可执行的证据来验证它们到底对不对。
研究团队意识到，这两条路都绕开了一个天然存在的资源：源代码。
代码这东西的好处是，它天生支持执行、评估、验证。一段代码到底能不能用，直接跑一下就知道了，不需要靠猜。而且GitHub上那些活跃维护、被反复打磨的项目，本身就是经过千锤百炼的操作经验的结晶。
**从代码里挖技能，到底难在哪**
如果这事真这么简单，早就有人做了。实际操作起来，难点在于代码里混杂着太多东西。
真实世界的代码里，可复用的通用逻辑和项目专属的胶水代码、局部变量命名、隐藏依赖、未处理的边界情况全都搅在一起。一个好的技能记录，不能只是说"这段代码做了什么"，还得说清楚这个操作在什么条件下适用、哪些步骤是必须的、哪些约束必须遵守、失败了会怎样、以及这个操作的边界在哪里不能瞎套用。
这就好比你去请教一位老木匠怎么做榫卯结构。如果他只是把手上正在做的这一件家具的每个动作原样描述一遍，你学到的只是"怎么做这一件家具"，换个尺寸、换个木料你就傻眼了。真正有用的传授，是老木匠告诉你榫卯的受力原理是什么、什么情况下该用燕尾榫什么情况下该用直榫、木料含水率多少会影响咬合。如果没有这层抽象，你学到的只是复制粘贴，遇到新情况立刻抓瞎。
这正是这项研究要解决的核心矛盾：既要跳出具体某一份实现的局限去做抽象总结，又不能抽象过头脱离了原始代码的支撑，变成一句正确的废话。
**Code2Skill：一条从代码到技能的自动化流水线**
研究团队给这套系统起名叫Code2Skill，一个全自动化的流水线。它的整体思路可以概括成四步：挑代码、抽技能、验证技能、建索引。
**筛选：不是所有代码都值得学**
Code2Skill先扫描了GitHub上截至2026年4月14日、star数超过500的仓库，一共筛出19,769个仓库作为源池。这些仓库星标中位数达到3,133，78.3%的仓库star数超过1000，66%在过去一年内还有推送更新，说明这些都是活跃维护、有真实使用者的项目，不是那种写完就扔在角落吃灰的玩具代码。
拿到仓库之后，系统会用抽象语法树解析出函数、方法、命令行入口、文件级组件这些"代码单元"，然后用一个大语言模型当"标签员"，对每个单元打分，判断它是否具备可复用的操作意图、有序的执行步骤、清晰的边界条件。这一步会过滤掉那些平平无奇的getter/setter、简单的配置声明这类没什么营养的代码。
这就像招聘时先筛简历。你不可能把每份简历都拿去做深度背景调查，得先用一轮初筛把明显不合适的人挡在外面，剩下的才值得投入更多精力细看。
**抽取：把代码翻译成结构化的技能卡片**
通过初筛的代码单元，接下来要被"翻译"成正式的技能记录。这里Code2Skill设计了三种粒度：**原子技能（atomic skill）**捕捉单个函数或方法里定义明确的单一操作；**复合技能（composite skill）**捕捉多个操作按顺序协调完成的工作流；**模式技能（recurring-pattern skill）**捕捉超出单个函数范围、更高层次的实现模式。
为什么要分三档，而不是一刀切？因为如果只用一种粒度，要么会把一个多步骤的流程拆得七零八落，要么会把局部的具体行为过度泛化成空洞的大道理。论文里举了个例子很直观：一个DNS-over-QUIC连接故障恢复的技能记录，被提取成一个复合技能，里面写清楚了什么时候该重试、重试前要不要关闭旧连接、什么条件下要清空令牌缓存，还专门列出了"绝对不能做的事"，比如不能无限重试、不能全局重置解析器。这种细节的颗粒度，只有复合技能这个层级才装得下。
每一份技能记录里，除了操作步骤，还必须留下**溯源信息（provenance）**：指这份技能是从哪个仓库、哪个文件、哪个版本提取出来的，方便后续检查和更新。
这一环节让技能记录不再是孤立的一段文字，它始终能追溯回原始代码。
**验证：让技能"闭卷考试"
这是整套流程里最巧妙的一步，研究团队称之为**源码盲重构（source-body-blind reconstruction）**：把提取出来的技能描述交给另一个AI，故意不让它看原始代码，只让它根据技能描述重新写一遍代码。
这一步的逻辑其实很朴素。如果一份技能描述真的把关键信息都说清楚了，那么另一个AI应该能凭这份描述重新写出功能等价的代码。如果重构出来的代码和原始代码对不上，说明技能描述本身有遗漏，要么漏掉了关键约束，要么加入了原代码里没有的臆想内容。
这就像考试时的"闭卷复现"。你如果真的理解了一道数学题的解法，应该能在不看答案的情况下，凭着自己整理的笔记把解题过程重新推一遍。如果凭笔记推不出来，说明这份笔记要么记漏了关键步骤，要么记错了。如果不做这一步验证，技能库里很可能混入大量看起来煞有介事、实际上根本用不了的描述，那样的技能库不但没用，反而会把AI带偏。
重构完成后，一个**源码感知的评判模型（source-aware judge）**会拿重构出的代码和原始代码做比对，直接判定一致就通过，判定不一致就转给**裁决器（adjudicator）**进一步判断，到底是技能描述本身有问题，还是重构过程本身出了岔子。这一整套流程走完，技能记录才算真正被"接受"进入技能库。
人工评估的结果显示，最终进入技能库的记录里，92%的技能描述被人工判定为准确，80%被判定为值得保留，直接通过等价性判定的记录里84%支持正确重构。作为对照，被拒绝的那批记录只有32%的描述准确率，28%的保留价值，且没有一份能支持正确重构。这组数字的差距相当悬殊，说明这套验证机制确实起到了过滤作用，不是走个形式。
**索引：让技能库变得好查**
技能记录通过验证之后，还有最后一步，就是建立检索用的索引。系统会给每份记录打上**特征标签（feature tagging）**，标注这个技能属于哪种问题类型（比如状态更新、数据转换、输入校验）、用到了什么复用机制（比如参数化、状态机控制、API调用）。同时还会做**目的索引（purpose indexing）**，把功能相近的技能聚成一类，从中选出一个代表性记录，减少检索时的冗余候选。
最终，Code2Skill在这19,769个仓库上跑完全流程，产出了名为**CodeSkillBank**的技能库，一共包含1,006,822条被接受的技能记录。
**这些技能到底管不管用**
光有技能库还不够，得看它能不能真正提升AI干活的水平。研究团队设计了一系列实验来回答这个问题。
**基础测试：加了技能之后AI表现怎样**
团队在DS4-Flash、Qwen3.5、Qwen3.6、Gemini 2.5 Pro、GPT 5.2这五个模型家族上，覆盖BigCodeBench、SWE-bench Verified、TerminalBench、LongCLI-Bench、AgentBench-OS、AIME 2026、HMMT 2025、GPQA这八个基准，一共做了72组"协议匹配"对比实验。
**协议匹配（protocol-matched）**：指的是除了是否提供检索到的技能之外，其余所有实验条件（模型、推理模式、任务集合、评估方式）都保持完全一致，这样才能确认性能差异确实是技能带来的，而不是别的变量在捣乱。
结果显示，72组对比中有57组用上技能之后表现更好。八个基准的平均分从42.90提升到47.90，相对提升了11.7%。尤其在SWE-bench Verified这个软件工程基准上，九组对比全部实现了提升，没有一个例外。
值得一提的是，AIME、HMMT、GPQA这三个数学和科学推理基准也有明显收益，说明从代码里学到的结构化检查思路，居然能迁移到和代码八竿子打不着的数学证明和科学问答里去。这倒是有点意外，毕竟代码里学到的更多是"怎么写程序"，但从更抽象的层面看，检查边界条件、验证前提假设这类思维习惯，本身就是跨领域通用的。
**和其他技能库掰手腕**
光是"有技能比没技能强"还不够有说服力，研究团队接着把CodeSkillBank拿去跟三个基于执行轨迹提炼技能的对照方案比较：Trace2Skill、ExpeL，以及一个改造版的SkillRL-Bank。
在同一套智能体流程下，七个共享基准上，CodeSkillBank在全部七个基准上都排名第一，平均得分49.5。作为对照，即便挑出Trace2Skill、ExpeL、SkillRL-Bank三者里每个基准上表现最好的那个分数拼凑出一个"理想化最优组合"，平均分也只有40.1，比CodeSkillBank低了9.5分。在单个基准上，CodeSkillBank领先最强对照方法6.6到13.3分不等。
这个结果说明一件事：不是随便找个共享的执行流程套上就能有好效果，技能库本身的质量才是关键变量。代码驱动的技能库确实提供了比执行轨迹更扎实的procedural knowledge。
**技能该插在流程的哪个环节**
技能能不能用好，还取决于把它塞进AI工作流的哪个位置。研究团队比较了三种插入方式：**生成时提示（generation-time prompting）**，就是一上来就把技能塞进第一版生成的提示词里；**规划阶段引导（planning-time guidance）**，让AI在做任务规划的时候看到技能；**生成后审查（post-generation critique）**，等AI先写出一版草稿，再拿技能去审查、修正这份草稿。
实验发现，规划阶段引导的效果最稳定，DS4-Flash和Qwen3.5在四个基准上全部有提升。生成时提示对DS4-Flash帮助明显，但对Qwen3.5效果参差不齐。而更广泛的生成后审查评估里，72组里有57组都有提升，是三种方式里表现最稳的。
这背后的道理其实好理解。就好比你请一个建筑顾问，如果在你还没画图纸之前就把一堆规范条文甩给你，你得先消化这些条文、再动手画图，两件事叠在一起容易顾此失彼。但如果你先画出一版草图，再拿着规范去对照检查，顾问的意见就能直接落地成具体的修改建议，效率明显更高。技能在"审查一份已有草稿"时更容易发挥作用，因为它这时候的任务是具体的对照检查，而不是抽象地指导从零开始的创作。
**技能记录能不能瘦身**
技能库虽然有一百多万条记录，但检索出来的内容塞进AI的上下文窗口是要占地方的。研究团队测试了几种"瘦身"方案：控制检索深度（一次给1条、3条还是10条技能）、用完整版记录还是压缩过的摘要版、检索原始记录还是去重后的代表性记录。
结果挺有意思。检索深度从1提到10，平均展示的上下文从2.1千字符暴涨到1.78万字符，但收益却很有限，Qwen只涨了1.4分，DS4-Flash甚至还略有下降。
摘要版的表现明显更划算。在检索深度为3的情况下，用摘要替代完整记录，平均上下文减少了88.9%，从6,352字符压缩到707字符，但Qwen的分数几乎没掉，DS4-Flash反而从28.40涨到31.80。
这个结果告诉我们一件挺反常识的事：**塞给AI更多的技能文本，不代表AI能学到更多东西**
这有点像给学生发复习资料。如果你把一整本参考书原封不动地甩给学生，学生要花大量精力去筛选哪些是重点，反而可能因为信息过载错过真正有用的部分。但如果你提前把核心考点浓缩成一页纸的提纲，学生反而能更快抓住重点、答对更多题。技能记录里那些具体的实现细节，对AI来说更像是"参考书里的旁枝末节"，真正管用的是那份浓缩过的操作要点。
**技能对强化学习训练有没有帮助**
前面说的都是推理阶段直接用技能，那如果是在训练一个强化学习模型的过程中引入技能，效果又如何？
研究团队在Qwen3-32B的SWE-World代码修复训练流程上做了测试，比较了四种技能接入方式：完整记录直接喂给策略模型、摘要版喂给策略模型、只让负责打分的验证器看到技能（对策略模型隐藏）、以及在生成结果后进行结构化审查。
结果显示，在训练到第150步这个检查点上，四种方式全部比不用技能的基线要好。策略侧和验证侧的接入能把任务解决率提升7到8个百分点，而生成后审查这条路径带来了14个百分点的提升，是四种方式里最猛的。
这个结果和推理阶段的发现遥相呼应：技能拿来"审查已有答案"，比技能拿来"指导从零生成"更容易发挥价值。原因大概在于，审查环节可以把抽象的技能转化成针对具体候选答案的检查清单，这个转化过程比"凭空运用一条通用规则从头生成一份完整答案"要容易得多。
**AI写的代码，能不能也拿来炼技能**
最后一个实验挺有意思，也挺有前瞻性。研究团队想知道，随着AI生成代码越来越普遍，Code2Skill这套流程是不是也能从AI写的代码里提炼出有用的技能，而不只是局限于人类写的代码。
他们随机挑了25份经过测试验证的人类代码实现，然后用GPT-5.1驱动的Codex，针对同样的接口需求生成对应的AI实现，两边都必须通过相同的公开测试和隐藏测试。之后从每份实现里各抽取一条"怎么实现"和一条"怎么验证"的技能记录，人类代码和AI代码各形成一个50条技能的小型库，拿去在400道LiveCodeBench题目上做对照测试。
结果是，人类代码库的通过率为93.00%，AI代码库的通过率为93.50%，两者的总体差距只有0.5个百分点。虽然总分接近，但两个技能库在16道题目上给出了不同的答案，人类代码库独有7道题能解出来，AI代码库独有9道题能解出来，说明这两个来源提供的指导并不完全相同，但整体质量是可比的。
这个发现的意义不在于AI代码比人类代码更强或更弱，而在于它证明了一件事：只要代码经过了测试验证，不管这段代码是人写的还是AI写的，Code2Skill这套流程都能从里面挖出有价值的技能。这意味着随着AI生成代码越来越多，这套技能提炼流程理论上有能力持续吃进新的养料，技能库可以像滚雪球一样越滚越大，而不用担心"人类代码写得越来越少"会让这条路走到尽头。
**写在后面**
读完这篇论文，最触动我的其实是一个挺朴素的观察角度的转变。
过去大家讨论AI智能体怎么变强，视角要么是"让模型自己在环境里试错攒经验"，要么是"喂给它更多人类写的教程文档"。这篇论文提醒我们，其实还有第三条路一直被忽视了：那些已经跑在生产环境里、被无数开发者反复调试打磨过的代码本身，就是一座尚未开采的经验矿山。这些代码不需要AI亲自去经历失败才能学会，因为失败早就被写代码的人经历过、修复过了。
另一个让我觉得设计得巧妙的地方，是那个"闭卷重构"的验证机制。它没有依赖人工审核这种昂贵又慢的方式，而是巧妙地用了一个AI互相制衡的思路：一个AI负责总结，另一个AI在看不到原文的情况下负责复现，复现不出来就说明总结有问题。这个思路其实挺有普适性，不只是适用于代码技能提炼，任何需要判断"一份摘要是否真的抓住了原文核心信息"的场景，都可以套用这个"能不能凭摘要复原原文"的检验方式。
至于这篇论文还没解决的问题，我觉得挺明显的一点是，技能库目前的更新机制还相对被动，它记录了溯源信息方便后续核查和刷新，但当一个仓库的代码发生重大重构之后，原来提取的技能记录到底该不该失效、该怎么自动检测失效，论文里没有给出很成熟的答案。这个问题留给未来的研究者，应该会是个挺有意思的方向。
Q&A
Q1：Code2Skill是什么？
A：Code2Skill是蚂蚁国际团队提出的一套全自动流水线，能从GitHub代码仓库中自动提取可复用的操作技能，并通过源码盲重构验证技能是否真实可靠。
Q2：CodeSkillBank技能库的效果如何？
A：在九个模型设置、八个基准的72组对比实验中，加入CodeSkillBank检索到的技能后，57组实验表现提升，平均分从42.90提升到47.90，相对提升11.7%。
Q3：AI生成的代码也能用来提炼技能吗？
A：可以。实验显示，经过测试验证的AI生成代码提炼出的技能库，在LiveCodeBench上的通过率为93.50%，和人类代码提炼的93.00%相当，说明这条流水线能持续吸纳AI代码作为新养料。
