你有没有用过 Claude 或者其他 AI 助手的"技能"（Skill）功能？就是那种打包好的说明文档加脚本，装上之后 AI 就能自动学会某项专门本领，比如做审计报告、生成有声书、分析股票数据。
这东西火得很快。论文里提到一个数字，半年时间，skills.sh 这个平台上就冒出来超过 20 万个技能包。听起来像是软件生态的又一次繁荣，但这里藏着一个几乎没人问过的问题：这些技能包，到底靠不靠谱？
先说个真实案例，来自论文的案例研究部分。有个叫 senior-security 的技能包，SKILL.md 文档里信誓旦旦写着"提供深度分析和优化建议"，结果打开它调用的 Python 脚本一看，那个 analyze 函数里根本没做任何分析，直接把状态标记成"success"，findings 列表留空，然后返回一份声称审计成功的报告。
这就像你雇了个保安公司来做安全巡检，合同上写着"每日全面巡查并出具详细报告"，结果保安每天到点就在报告上签个"一切正常"，压根没进过楼里。你不细看永远发现不了，因为报告格式完美、流程顺畅，甚至读起来还挺专业。
这就是这篇论文要解决的核心问题：如何自动揪出这些藏在 AI 技能包里的"说一套做一套"。
代码有 bug，一测就知道，可技能包的毛病完全不一样
传统软件出了错，通常很好抓。类型不对，编译器会报错，运行时崩溃，日志会告诉你在哪一行炸的。但 AI 技能包不是这么回事。
技能包里大部分是自然语言写的说明书，配上一些脚本和资源文件。它的"故障"往往不是程序崩溃，而是一种更隐蔽的东西，论文管这个叫"意图冲突"（intent conflict），说白了就是文档说的和代码做的对不上。
更麻烦的是，这种错误经常被悄悄"消化"掉。因为 AI 大模型本身很聪明，遇到技能包里模糊或者有缺陷的指令时，它会凭自己的常识"脑补"出合理行为，把这个坑给填上了。结果就是，表面上任务完成得好好的，实际上技能包内部藏着定时炸弹，只是这次没爆而已。
这也是为什么单纯看"任务最后有没有完成"是不够的，因为一个足够聪明的执行者，会把很多缺陷悄悄兜住。真正的问题被掩盖了，不代表它不存在。
研究团队做了个统计，把 skills.sh 上下载量超过 1000 次的 7577 个技能包扒下来分析了一遍。结果发现将近一半的技能包只有一个 SKILL.md 文件，行为完全靠自然语言指令和内嵌代码定义，这个文件的字符数中位数是 7352 字，大概就是一篇长文章的量。也就是说，绝大多数技能包，本质上就是一段说明书加几行代码片段，没有传统软件那种严谨的目录结构和测试用例。
这种"轻装上阵"的特性，一方面让技能包容易做，另一方面也让传统的代码检测工具完全用不上力，因为大部分内容根本不是代码，是文字。
把技能包当成一份"契约"来审
论文的核心思路挺巧妙的，他们没有把技能包简单当成一堆文本或者一堆代码，而是引入了一个经典的计算机科学概念：Hoare 逻辑。
Hoare 逻辑*：1969 年由计算机科学家 Tony Hoare 提出的程序正确性推理框架，用一个三元组 {前置条件} 程序 {后置条件} 来描述，意思是只要程序运行前满足某个前提，运行结束后就一定会达到某个结果。这是形式化验证领域的经典基石。
研究者的想法是，技能包里的每个操作单元，不管是一段说明文字还是一个函数，其实都隐含着一份契约：这个操作要求什么输入（前置条件），完成后应该产生什么结果（后置条件）。技能包的"正确性"，就是看这份隐含契约有没有被真正兑现。
论文由此定义了两种规格说明：
ExpectSpec（期望规格）*：根据技能包里声明的完整意图（比如周围的说明文字、上下文约束）推导出来的"应该做什么"。
FactSpec（事实规格）*：从实际的代码实现或指令中推断出来的"实际做了什么"，是在故意遮蔽部分上下文信息的情况下提取的。
两者一对比，如果对不上，就是潜在缺陷。
回到前面那个音频拼接的例子，论文图 3 里给出了一个很典型的场景：SKILL.md 说这个操作是"把音频片段拼接成一个文件，并报告是否成功"，代码看起来也确实在调用 ffmpeg 做拼接。但仔细读代码会发现，拼接完之后，所有输入的音频片段文件全都被删掉了。这是一个文档里完全没提到的副作用，直接违反了"期望"里没有明说但隐含的一条规矩：不该悄悄销毁用户的原始输入。
这就好比你把一沓重要合同原件交给打印店复印，取件的时候拿到了复印件，结果发现原件已经被当场销毁了，而你压根没同意过这件事。复印这个"核心功能"完成了，但一个没有被声明、也不该发生的破坏性动作，同时也发生了。
不过研究者也很谨慎地指出，光是发现"文档和代码对不上"并不等于就是真缺陷，这只是一个假设。自然语言描述本来就可能省略一些实现细节，某个局部的偏差也可能在流程别的地方被补偿掉了。真正确认一个缺陷，还需要回头看原始代码、判断这个问题是否真的会被用户触发、以及这种偏差会不会破坏技能包原本该有的通用性。
这也是为什么后面还要专门加一道"沙箱验证"的工序，光靠推理是不够的，还得真刀真枪跑一遍看看会不会出事。
四层"意图面纱"，让 AI 既不能看得太多，也不能看得太少
这篇论文最有意思的一个设计，是怎么解决"该给 AI 看多少上下文"这个两难问题。
听起来有点反直觉：为什么给 AI 看的信息越全越好，反而会出问题？
原因是这样的。如果在分析代码实现的时候，把技能包声明的完整意图全部摆在 AI 面前，AI 很容易"被带跑偏"。它会不自觉地按照文档说的去脑补代码应该是什么样，而不是老老实实看代码实际在做什么。这就跟你带着"我知道这个保安应该每天巡查"的预设去看巡查报告一样，你会更容易被表面的合规文字糊弄过去，而不是去深挖真实的执行记录。
但反过来，如果完全不给任何背景信息，只孤立地看一小段代码，AI 又可能得出一些不靠谱的判断，因为它根本不知道这段代码在整个流程里扮演什么角色，脱离上下文的解读很容易走偏。
论文管这个矛盾叫"意图披露粒度"问题（Intent Disclosure Granularity），解决方案是设计了一个叫"意图掩码"（intent mask）的机制，把上下文信息拆成四个可见层级：
整体层（Holistic）*：技能包的全局目标和总体约束。
血统层（Lineage）*：从当前节点一路追溯到根节点的上游依赖链。
邻居层（Neighbors）*：同一阶段里的平级操作，提供局部协作背景。
自身层（Self）*：当前正在分析的这个节点本身。
生成 ExpectSpec 的时候，用的是"完整视图"（FULL），也就是能看到除了目标节点本身之外的所有上下文，专门用来推导"这个节点应该做什么"。而生成 FactSpec 的时候，会构造好几个不同的"部分视图"，每个视图只暴露自身层加上另外三层中的某个子集，故意留一手，逼着 AI 只能基于有限信息去推断"这个节点实际在做什么"。
这套设计有点像医院会诊时的多学科讨论。一个疑难病例，你不会只让一个专科医生看着全部病历下判断，因为他可能会被某个和自己专业无关的诊断先入为主地带偏；但你也不会让医生完全不看任何背景信息就下结论，那样风险太大。更好的做法是让不同专科医生带着不同程度的背景信息分别给出意见，最后再综合起来看哪些结论是稳定一致的，哪些只是某个视角下的偏见。
论文的消融实验证实了这套多视角机制确实有效。单独用任何一个视角，缺陷确认率在 42.9% 到 45.8% 之间浮动，而把四个视角综合起来推理，确认率提升到了 48.2%，同时发现的缺陷数量也从单视角的 228 到 236 个提升到 261 个。更关键的是，把所有单视角发现的缺陷简单取并集，也只能覆盖多视角推理结果的 97.7%，说明这种综合推理确实能挖出单一视角发现不了的东西，不是简单的信息叠加。
把整个技能包变成一张图，代码和文档才能对得上话
要做到上面说的这套多视角推理，前提是得先把一个技能包里乱七八糟的东西，包括 Markdown 说明文档、Python 脚本、JavaScript 代码、配置文件，统一成一种可以互相比对的结构。
这篇论文做了两件事。第一件是把各种编程语言的脚本，通过 Tree-sitter 这个工具解析成语法树，再抽取成一种语言无关的中间表示，进而构建出函数之间的调用关系图。
Tree-sitter*：一个开源的增量式语法解析工具，能把不同编程语言的源代码统一解析成语法树结构，是很多代码分析工具的底层基础。
第二件事是用大模型把 SKILL.md 里松散的自然语言说明，重新组织成一张有向无环图（DAG），也就是"工作流图"。这张图区分了结构性节点（比如整体框架、阶段划分）和操作性节点（比如具体某一步该做什么、调用哪个脚本）。
这两张图построй好之后，还要把它们"缝合"起来。技能包里经常会写"第三步调用 xxx.py 脚本处理数据"这样的话，系统会尝试解析出这句话对应到代码图里的哪个具体函数入口，建立一个双向绑定关系。这样一来，从文档追到代码、或者反过来从代码定位到对应的文档描述，都变得可行了。
论文的图 2 展示了一个很直观的证据，他们用句子级别的语义相似度分析了官方的 skill-creator 技能包，发现文档里描述某个任务的句子和它实际调用的脚本代码，在语义相似度曲线上会同时出现峰值，而且峰值位置高度重合。这说明技能包的文字和代码之间确实存在着某种隐含的对齐关系，只是这种关系散落在文档各处，没有被显式标注出来，需要专门的方法把它挖掘出来。
沙箱里跑一遍，才算数
光靠大模型推理出"这里可能有问题"还不够，毕竟大模型自己也会犯错，也可能把无害的差异误判成缺陷。所以论文加了最后一道关卡：在隔离的沙箱环境里实际验证。
沙箱*：一种隔离的运行环境，代码或程序可以在里面执行而不会影响到真实系统，常用于安全测试和验证。
对于代码层面的候选缺陷，验证系统会构造最小化的测试用例，直接跑一遍原始代码逻辑，看看是不是真的会复现出问题。比如前面说的音频删除案例，就是通过实际跑一遍拼接流程，确认输入文件确实被删掉了。
对于工作流层面的候选缺陷，因为很多时候没有一个明确的"对错判定标准"，验证系统会构造一个更贴近真实用户使用场景的触发指令，模拟一个正常用户会怎么调用这个技能包，然后看看声称的缺陷行为是不是真的会被触发，以及相关指令是否真的能通过技能包的加载链被激活。
这套流程用了一个叫 OpenCode 的智能体框架配合容器管理，为了省资源，同一个技能包会复用一个"热容器"，但每次验证不同的候选缺陷时，会分配全新的工作空间，避免前一次验证的残留状态干扰这一次的判断。
结果发现了 763 个真实缺陷，命中率超过六成
研究团队把这套系统在 515 个真实技能包上跑了一遍，数据来源一部分是 SkillsBench 这个专门的基准测试集，另一部分是他们自己从 skills.sh 上按下载量筛出来的高人气技能包集合（论文里叫 SkillsTop）。
结果是，239 个技能包（占比 46.4%）被发现存在至少一个缺陷，累计找到 763 个经过人工确认的真实缺陷，整体的验证精确率是 61.2%。
代码类缺陷这边表现更稳定，精确率达到 67.1%，而工作流类缺陷只有 55.4%。这个差距其实挺好理解的：代码有明确的执行结果，跑一遍就知道对不对；但自然语言描述的工作流步骤，很多时候本身就存在解读空间，判断起来天然更模糊。
缺陷的分布也很有意思，呈现出明显的长尾效应，只有排名前 30 的技能包就占了全部缺陷的 41.7%。这说明大部分技能包质量还是过得去的，问题集中在少数几个"问题户"身上。
论文还做了个缺陷分类，从需求、约束、语义冲突和实现偏差四个维度去拆解。结果显示，工作流层面 74% 的缺陷出在"需求没写清楚"或者"约束条件在传递过程中丢了"，而代码层面 91.6% 的缺陷是"实现偏离了声明的意图"。这个对比其实揭示了一个挺深的道理：技能包的质量问题不是单点的，而是贯穿了从"想清楚要做什么"到"真正写代码实现"这整条链路的，任何一环松懈了都会留下坑。
不同模型测下来，结论基本一致
研究团队没有只用一个大模型跑实验，而是测试了包括 GPT 系列、DeepSeek 系列以及本地部署的 Qwen3.8-27B 在内的多个模型家族，想看看这套方法是不是只对某个特定模型管用。
结果显示，即便是参数规模小得多、本地部署的 Qwen3.8-27B，也能拿出不错的表现，验证通过率在 77.9% 左右，虽然发现的候选缺陷数量比顶级模型少一些，但胜在成本低很多。这说明这套方法不是靠着堆砌昂贵模型硬撑出来的效果，而是方法论本身站得住脚。
所有模型都表现出一个共同的规律：代码类候选缺陷的验证通过率普遍超过 79%，工作流类候选缺陷的通过率则在 29% 到 71% 之间大幅波动，而且都在纯文本、没有可执行脚本的技能包子集上表现最差。这再次印证了前面的判断，当前大模型处理结构化代码的能力，比处理开放式自然语言描述要更成熟、更可靠。
好用，但也有价钱和局限
跑一遍完整流程，平均每个技能包的成本是 2.585 美元，其中大头是"规格推理"这一步，占了 74.1% 的成本，因为这一步需要对图里的每个节点分别做推理，节点越多花费越大。相比之下，最后的沙箱验证只占了 10.3% 的成本。
研究团队也坦诚地讨论了这套方法目前解决不了的问题。有 197 个工作流层面的误报案例被拿出来单独分析，发现 68.5% 都是因为"过度推理"，也就是把文档里一些可选的建议、或者只是举例性质的说明，误当成了硬性规定去要求代码必须严格遵守。而在代码层面的 149 个误报里，有 49.7% 属于"触发不到"，也就是说那段代码在语法上确实可以被执行，但在正常的工作流约束或者智能体的路由逻辑下，实际上根本不会被走到那条路径上去。
还有一类挺有意思的误报，占工作流误报的 19.8%，叫"外部补偿"，说的是技能包文档里确实存在某个规格缺失或者表述模糊的问题，但执行任务的大模型凭借自己的常识推理，在运行时悄悄把这个坑给填平了，最终结果是对的，只是过程"看起来"有问题。这从另一个角度印证了论文开头提出的那个核心观察：智能体的聪明才智，恰恰是掩盖技能包缺陷的天然屏障。
写在后面
读完这篇论文，最让我意外的其实是那个统计数字：半数以上的真实技能包只有一个 SKILL.md 文件，中位数 7000 多字，没有测试、没有版本管理、没有任何传统软件工程该有的东西。这意味着现在整个 AI 技能生态,本质上是建立在"自然语言说明书 + 信任大模型能读懂"这个脆弱基础之上的。
论文里那个"外部补偿"现象也挺值得琢磨。技能包写错了，但聪明的大模型把错误悄悄修正了，最终用户看到的结果是对的。这听起来像是好事,但往深了想,这其实意味着技能包的质量问题会被系统性地隐藏起来,越是聪明的模型,越容易把这种隐藏做得天衣无缝,直到某天遇到一个稍弱一点的模型,或者一个恰好没法被常识修正的边缘场景,问题才会突然爆发。这种"温水煮青蛙"式的风险积累,可能比明显的报错更值得警惕。
另外一个让我停下来想了很久的地方是,这篇论文其实在用经典的、几十年前就有的程序验证理论(Hoare 逻辑),去审视一个 2026 年才刚刚兴起的全新软件形态。方法论没变,但审视的对象从确定性的代码,变成了充满模糊性的自然语言加代码的混合体。这种"老框架装新内容"的思路,某种程度上说明真正底层的工程原则是有穿透力的,不管技术形态怎么变,"声明的和实现的要对得上"这条铁律始终成立。
技能包生态还在疯狂扩张,20 万个只是半年的量。等它涨到 200 万个的时候,谁来审核这些说明书里到底写没写对?
Q&A
Q1：SkillSpec是什么？
A：SkillSpec是一个针对 AI 智能体技能包（Skill）正确性检测的框架，通过对比文档声明的意图和代码实际行为，找出两者不一致的缺陷，并在沙箱环境里进行实际验证确认。
Q2：SkillSpec是怎么发现技能包里的缺陷的？
A：它先把技能包里的文档和代码统一转换成图结构，然后为每个操作单元分别生成"期望规格"（文档说该做什么）和"事实规格"（代码实际做了什么），通过对比两者的差异找出潜在缺陷，最后放到隔离沙箱里跑一遍验证是否真实存在。
Q3：SkillSpec的检测效果怎么样？
A：在 515 个真实技能包上测试，发现 239 个技能包存在共计 763 个经人工确认的真实缺陷，整体精确率达到 61.2%，其中代码类缺陷的精确率更高，达到 67.1%。
