AI 技能文件怎么管？别被模型吞了
Ask HN: How do you manage skills files?
我想知道大家如何高效管理、整理并验证 Skills 文件的有效性，以及如何持续优化它们。虽然我认为通用技能终将被模型能力取代，但在过渡期，我急需找到更好的管理方案，特别是针对那些网上随处可见的通用型技能。
模型永远无法填补自定义技能能解决的未知空白。虽然模型足够聪明，能自行查找 SSH 密钥或过往连接记录，但技能文件能直接给出'用密钥 Z 和用户 X 连接 Bob'的明确指令。这种信息密度高的技能能省去无谓的推理，大幅节省 Token 消耗，直接跳过繁琐的调研阶段。
我的观点是，通用型编码 Agent 会变得越来越强，让技能文件逐渐失去价值，其进化速度远超人们定制技能的速度。不过，对于像撰写独特营销文案这类任务，情况可能不同。目前我保持技能极简，只保留像'移除文档中的所有 Slam Poetry'这样的高频单句提示，并将所有技能放入团队共享的 Repo 中，鼓励大家自由使用和发挥。
我在项目中维护一个 docs/目录，存放所有应用所需的技能和文档。我把这些内容视为 ADRs（架构决策记录），这样能帮助 AI 更好地理解它所操作系统的各个组成部分。
HN 评论区
280- skeledrew
我主要靠自己提示词来构建技能，并给那些我认为能受益的技能加上自我改进指令。通常如果一个技能效果不好（或完全没用），会出现额外的工具调用。事实上，这往往就是最初创建技能的触发点：当需要多次工具调用来完成重复任务，而这些调用本可以精简时。但从大多数 AI 相关帖子的评论来看，人们几乎从不阅读智能体（agent）的转录记录（而且自我改进指令也不总是被触发），所以他们的技能永远无法提升。
- avaer
技能大多是骗人的把戏，尤其是人们使用它们的方式（指望像下载功夫秘籍一样从名人那里下载技能）。
也许去年那会儿还有点用，但现在有了好的代码仓库和好的提示词，今天的智能体完全能找到它们所需的一切，根本不需要技能。
作为开发者宏（developer macros）的“技能”或许有点用，但顶多也就是团队内部在仓库里共享的东西，而不是从网上下载来的。如果你拥有多到需要专门管理的技能，那这就是个代码异味（code smell）。
- gregwebs
把它们纳入版本控制。
我有一个专门存放软件开发技能的 git 仓库 [1]。里面有个安装脚本，通过符号链接指向这些技能。在机器上更新技能，只需推进 git 仓库即可。其中一个技能附带了一些 bash 脚本，其余的本质上就是提示词。
把特定于项目的技能放在项目里效果很好。
我通过理解每一个技能、审查拉取请求（pull requests）以及测试最终产品来确保它们有效。结果很少是完美的，所以我一直在微调技能以及我使用 AI 的方式。
- alexhans
- 我不找技能，我创造技能
- 把它们组织在软件仓库中，用符号链接安装到你所有的代码框架中。基于 frontmatter 的渐进式披露（progressive disclosure）会处理其余部分。
- 我通过 AI 评估（evals）确保它们有效。把它们当作集成测试，用来证明行为。它们对优化你的工作流很有用。我尽量让我的技能主要充当自然语言与良好、小型、快速工具之间的翻译器。
- 只有当新问题出现时，我才会修改它们，而不是无缘无故地改。
如果技能代表的是我团队或我个人独有的工作流，模型能力就吞不掉它们。
我之前写过一篇关于良好心智模型的文章：
https://alexhans.github.io/posts/series/evals/building-agent...
- sformisano
SkillCatalog (https://skillcatalog.dev/) - 存储在 git 中，通过桌面应用（macos）和 CLI 进行管理
完全披露：我是作者
- WatchDog
我不用任何技能，大家觉得哪种技能最有用？
对于通用任务，模型似乎完全有能力自己搞定；对于特定于项目或环境的任务，我就把相关信息放在 readme 或 agents.md 文件里。
- FailMore
惊讶居然没人提到，但我认为依赖 https://github.com/vercel-labs/skills 是个靠谱的选择。它处理了各种代码智能体的全局安装。如果我要开发一个仅限内部使用的技能，我可能还是会基于同样的基础。
- invaliduser
我基本上是在受够了总是写同样的提示词时，才去创建一个技能，然后随着时间推移不断调整它。
我大概有 3 个技能，目前为止效果不错。最近的大部分改动都是要求 Claude 别再使用那些让文档难以阅读和理解的比喻和修辞手法（也许这只是对非母语者来说很烦人，我不确定）。