文章总结： 基于三篇论文的实验数据，总结出编写AI技能的五个关键规则：必须由人类专家编写而非依赖模型自生成；保持技能聚焦（2-3个文件）而非面面俱到；避免加载过多技能以防上下文泛滥；需针对每个运行框架单独测试和调整；瞄准模型预训练覆盖薄弱的领域以最大化收益。同时强调必须通过有技能vs无技能的对比测试来验证技能有效性，因为技能可能反而降低性能。 综合评分： 88 文章分类： AI安全,安全建设,技术标准,其他

如何写出一个好技能？现在终于有写作规则手册了

原创

Aparna Aparna

ThinkInAI社区

2026年7月8日 11:30 上海

在小说阅读器读本章

去阅读

⬆️关注 ThinkInAI 星科社区，最及时最干货的AI内容分享

上周在旧金山举行的 AI Engineer World’s Fair（https://www.ai.engineer/worldsfair/2026） 上，技能是最热门的主题之一。Latent Space 的 AINews 也这么说（https://www.latent.space/p/ainews-not-much-happened-today-07e），Paul Bakaus 举办了一场关于构建技能这门“黑魔法”的工作坊（https://www.latent.space/p/skill-engineering-design），从 Anthropic（https://github.com/anthropics/skills） 到 GitHub（https://www.a16z.news/p/impeccable-by-design），各家厂商如今也都开始把官方技能作为产品界面的一部分推出。但对大多数 AI 工程师来说，写出一个好技能一直更像是民间经验：听演讲、看推文、反复试错。

现在这种情况可以改变了。有三篇论文——一篇发表于 2 月，另外两篇发表于 6 月——用这个行业衡量一切的方式衡量了技能：运行任务、给结果打分、比较不同条件。结果是一套真正的技能写作规则手册，而且里面有不少反直觉的建议。

什么算是技能？

像往常一样，先确保我们讨论的是同一件事很有必要。就本文而言，技能是一个打包好的领域知识文件夹，智能体会按需加载它：其中包括指令、词汇，有时还有脚本和资源。它位于一系列越来越丰富的容器谱系上，从提示词到工具，再到一个新造的概念“配方”。最后这个说法来自 Introspection 的 Roland Gavrilescu（https://www.latent.space/p/autoresearch-introspection），他提出了这个新类别，位于技能之上一级：“我们从智能体工具走向了智能体技能。配方是一个更大的容器”，它会加入评测、裁判以及能够随着时间改进系统的反馈信号。

SkillsBench 论文（https://arxiv.org/abs/2602.12670）（arXiv:2602.12670，最早发表于 2026 年 2 月）给出了一个正式定义：技能是模块化、可复用的，携带流程性指导，并且可以跨模型移植（最后这一点后来被证明很棘手！）。系统提示词并不具备这些特征，RAG 检索或工具描述也不是技能。那篇论文的作者提出了一个类比：模型是 CPU，运行框架是操作系统，技能是应用程序。

那么，这三篇论文发现了什么？一个好技能应该包含什么？有五个关键点。

1. 不要让模型自己写自己的技能

让你的智能体帮你写技能，这件事非常诱人。SkillsBench 恰好测试了这一点：每个任务都在三种条件下运行——没有技能、专家策划的技能，以及模型为自己生成的技能。策划过的技能显著提高了通过率。自生成技能则完全没有带来收益，平均比无技能基线还低 1.3 个百分点。作者的结论是：模型无法可靠地编写自己在使用时会受益的流程性知识。

这些失败模式很有启发。模型要么写出含糊的流程（比如“使用 pandas 进行数据处理”，但没有任何实际 API 模式），要么一开始就没意识到这里需要专门知识。指望模型自己学习也行不通：技能演化论文 SkillComposer（https://arxiv.org/abs/2606.06079）（arXiv:2606.06079，2026 年 6 月）发现，从之前尝试解决同一问题的日志中不受控地抽取技能，会把编码表现拉低到无技能基线以下。

这其实是 Bakaus 在 AIEWF 对 Latent Space 说过的一件事（https://www.latent.space/p/skill-engineering-design）的数据版。他的设计技能 Impeccable（https://impeccable.style/） 的工作方式，是把模型粗略理解的词语注入精确的专业含义。让一个没有辅助的模型把页面做得“更大胆”，你得到的往往是渐变和霓虹色。Impeccable 则通过层级、尺度和果断的字体排版来定义“大胆”。Bakaus 说：“一个背后没有任何东西支撑的形容词，只是一个漂亮的撇号。”“你真的必须告诉智能体你说的是什么意思。”专家词汇就是技能的价值所在，而现在数据表明，模型无法自己提供这些东西。Gavrilescu 也直白地指出了这个限制：“你不能简单地把所有这些知识都塞进一个 Markdown 文件”，除非先有人类把它提取出来。

所以你必须自己写。那么它应该写多大？

2. 写一个面面俱到的技能并不是正确方式

SkillsBench 发现，包含两到三个文件的聚焦型技能，表现优于更大的文件包和详尽文档。那些试图记录一切的综合型技能，实际上会把通过率拉低到无技能基线以下。每一次都是“详细但有边界”胜过“百科全书式”。

这也符合最优秀技能作者已有的工作方式。Bakaus 把设计问题描述为寻找“精确的控制层级”：不是所有东西都属于技能这个抽象层级；对于小调整，直接操作仍然更快；在探索阶段，开放式提示仍然有用。当技能编码的是模型反复判断错误的东西时，它才有用，而不是把手册照抄一遍。

追求详尽的本能是敌人。你添加的每一段都会和其他每一段争夺模型的注意力，而且超过一个低得出人意料的阈值后，新增内容就会开始造成损害。这也引出了一个问题：当你把这个问题从一个技能扩展到一个技能库时，会发生什么？

3. 加载更多技能会让智能体变差

如果一个技能有帮助，那加载整个技能库肯定更有帮助吧？生成式技能组合论文（https://arxiv.org/abs/2606.32025），令人困惑的是它也叫 SkillComposer（arXiv:2606.32025，2026 年 6 月 30 日），直接测试了这一点。把一个包含 196 个技能的完整技能库全部注入上下文，在编码任务上的得分比选择一个小而相关的子集低 16 分，同时还多消耗了 23% 的输入 token。上下文泛滥会同时在准确率和成本上失败。

有选择性要有效得多。那篇论文的方法把技能选择视为一个组合问题：哪些技能、多少个、按什么顺序。它们的 composer 是一个只有 390 万参数的小模型，唯一工作就是输出一个有序的技能 ID 列表；在 GPT-5.2-Codex 上，它让通过率比无技能基线提高了 23.1 分，并接近了“oracle”的水平：也就是某种总能选中完美技能的东西。Bakaus 从实践者角度得出了同样的架构，在 Impeccable 内部构建路由，把任务导向相关指令；他把这比作混合专家模型。一个团队用技能外部的专用模型来路由，另一个团队在技能内部路由，二者存在的原因相同：技能的效果取决于决定何时加载它们的机制。

好了，你要自己写，保持简短，不要写太多技能。现在你的技能仍然需要经受运行时环境的考验。

4. 在你声称支持的每个运行框架中测试

技能在格式上是可移植的（大家都接受 SKILL.md 文件），但事实证明，它们在行为上并不可移植。SkillsBench 在多个运行框架中评估了同一批技能，发现收益会因模型-运行框架配置不同而在 4.1 到 25.7 分之间变化。Claude Code 表现出最高的技能利用率。Codex CLI 则经常完全忽略技能：它会承认技能内容，然后还是按自己的方案实现。

这个发现对专家级技能作者来说并不意外。Bakaus 指出，Codex 和 Claude 处理子智能体或权限的方式并不相同，所以一个面向 Claude Code、Cursor、GitHub Copilot 和 Codex 的技能，不能假设它们拥有相同能力。Impeccable 的答案是，它会针对每个目标运行框架发布不同的编译版本（https://github.com/pbakaus/impeccable）。面向已知有坏习惯的模型的技能，会附带额外规则，禁止那些特定坏习惯。可移植性不是你在兼容性字段里声明出来的属性：它是你针对每个目标工程化产出的结果，而运行框架本身和技能文件一样，都是技能行为的一部分。

自己写、保持简短、不要写太多、针对每个运行框架发布一个版本。但技能到底应该写什么？

5. 把技能瞄准模型最薄弱的地方

SkillsBench 按领域衡量了技能收益，结果从软件工程领域的 4.5 分，到医疗健康领域的 51.9 分不等，制造业紧随其后。技能在软件领域帮助最小，因为模型已经被预训练数据充分覆盖；而在覆盖较薄的领域，帮助最大。

SkillsBench 的作者还爬取了公开技能生态，发现所有技能中有 38% 是软件开发技能。社区主要在技能帮助最小的地方构建技能。如果你在决定把写技能的精力投向哪里，套利空间在那些模型本来就不了解的领域：你公司的内部惯例、受监管行业、专业化工作流，以及任何模型预训练覆盖很浅的地方。通用编码工作流技能是一笔拥挤交易，优势很小。编码你们合规团队如何审查供应商合同的技能，则不是。

这五个发现都有一个共同依赖：它们每一个都是通过细致测量发现的，这意味着你不能盲目套用。

不测试，你就无法知道你的技能是否有效

上面每个结果都来自同一种方法，而且这是你自己也可以运行的方法（https://github.com/benchflow-ai/skillsbench）。拿一组任务。运行两遍，一次加载技能，一次不加载技能，其他所有条件保持不变。用同样方式给两次运行打分，然后看差异。就这么简单。这些论文中的评分使用了自动化检查：一个脚本验证输出，并在没有人工判断介入的情况下返回通过或失败，这正是比较值得信赖且可重复的原因。

这之所以重要，是因为技能可能有害。在 SkillsBench 中，84 个任务里有 16 个在加载技能后得分反而低于不加载技能。你无法通过肉眼查看输出来发现这一点，因为加载技能后的输出通常看起来更专业，即使它通过率更低。只有“有技能 vs 无技能”的比较才能抓住它。

技能演化论文把同样的思路又向前推进一步，并把它作为质量门槛：只有当对技能的修改能让任务套件通过率显著提升时，才接受这个修改。保留那些可测量地有帮助的内容，丢掉没帮助的内容。这把技能维护从凭感觉变成了一个循环，也正是 Gavrilescu 的配方概念所描述的循环：把评测和反馈信号作为制品的一等组成部分包裹在技能周围。这类评测正是 Arize AX（https://arize.com/ax?utm_source=lvoss&utm_medium=linkedin&utm_campaign=devrel&utm_content=How%20do%20you%20write%20a%20good%20skill%3F%20There%27s%20actual%20data%20now.） 可以帮助你构建的东西。

这仍然留下了一些空白。对于不存在自动化检查的领域该如何评分？比如“设计是否更大胆了”并没有通过/失败的标准。又该如何衡量 Bakaus 在 AIEWF 提到的失败模式（https://www.latent.space/p/skill-engineering-design）：当“如果每个人都用同一个技能来做前端设计工作，一切最终都会看起来一样”？一个让所有用户输出多样性塌缩的技能，即使每个单独输出得分都不错，也是在失败。这两者都需要这个领域尚未标准化的评估方法。

民间经验时代结束了

五个月前，写出一个好技能意味着你要向散落各处的工作坊演讲拜师学艺。现在，我们有了一份由数万次实验支持的清单：自己写，保持小巧，不要写太多，按运行框架测试，瞄准模型薄弱领域，并用评测验证每一次修改。

做这些测量的人已经完成了最难的部分。现在你有了数据；去把它做好吧。

加入ThinkInAI社区

#

如果你也对AI充满兴趣，欢迎加入我们的ThinkInAI社区，在这里，你可以：

• 获取最新AI工具资讯
• 参与实战经验分享
• 结识志同道合的伙伴
• 共同探讨AI应用方向

扫描文末二维码，加入ThinkInAI社区，一起拥抱AI新时代！

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：ThinkInAI社区 Aparna Aparna《如何写出一个好技能？现在终于有写作规则手册了》