一条名叫「Ask HN: How do you manage skills files?」的提问帖，发布5小时后拿到了50赞、39条评论——在Hacker News不算爆款，但足够说明一件事：AI编程代理的“技能文件”（skills）已经从个人收藏变成了一个需要被管理的工程对象，而开发者们还没找到舒服的答案。
发帖人自己先抛出一个判断：skills迟早会被模型能力吃掉，但在那之前，得先找个更好的管理方式。这句话看似悲观，评论区却给出了相反的行动——不是等模型变强，而是现在就开始给skills上git、上版本、上自动检测。
大家真正在攒的不是技能库，是团队私有流程
评论区里出现频率最高的一句话是：不要教模型它已经会的东西。git怎么用、python语法这类通用知识，模型自己清楚，做成skill纯属浪费。有开发者说得更直接——他攒的skills都是“这家公司/这个项目里我们喜欢怎么做事”：查测试数据库的方式、分支命名规范、commit message风格、云上日志怎么排查。这些东西通用文档里找不到，只能靠团队自己写。
也有人反过来做减法：只留9个skills，理由是市面上很多marketplace装了几百个技能包，用起来反而更乱。少而专，比装满一个技能货架更有用。
Git只是起点，真正麻烦的是漂移和同步
有开发者提到自己维护skills的方式：把它们放进repo，做成Claude插件，还跑一个每两周执行一次的agentic workflow，专门检查skill内容有没有和文档「漂移」，一旦发现就自动开PR。另一个开发者做了个叫Capshelf的小工具，靠内容哈希锁定skill版本，防止团队协作时被人无意改坏；OpenSpec则提供了init命令和更新路径，专门解决“装上之后怎么持续更新”的问题。
这些做法有个共同前提：git能存文件，但不能告诉你哪个skill过时了、哪个和团队实际流程已经脱节。内容哈希能防住“意外改动”，防不住“这个技能本来就写错了”或者“早就不适用了”。
技能攒起来容易，攒对、攒新才是真门槛
- 风险.内容哈希只锁版本一致，不代表skill内容本身正确或仍然有效，团队仍需人工审查。
Skills和README的边界在哪
讨论里也有人质疑skills是不是被过度发明了——某些项目专属约定，写进README或AGENTS.md链接过去就够了，不必单独做成一个可调用的skill文件。区别其实在于用途：AGENTS.md适合放静态的项目约定，谁看都行；skill更适合封装一段可反复执行的重复流程，比如“怎么发日志”“怎么做代码审查”，模型能直接调用执行，而不只是读一遍参考。
- 结论.skill该不该存在，先问一句“这是不是我每周都要重复讲一次的操作”，答案是否则大概率不需要。
对使用Claude Code、Cursor这类工具的个人开发者，问题是控制数量、别贪多；对工程团队来说，问题变成了要不要为共享、审查、自动检测漂移这套机制投入维护预算——这笔账，目前还没人算得很清楚。