问 HN：你们如何管理 skills 文件？
AI 用户对“skills”——供 LLM agents 复用的 prompt 和工作流文件——是否属于必要基础设施，还是随着模型进步而变成不必要复杂性，意见分歧。许多人认为它们作为缓存的工作流和项目特定 runbook 很有价值，可以编码工具约定、减少 token 消耗，并让 agents 更可靠，尤其是在专有或复杂环境中。另一些人则认为通用的、从网上下载的 skills 往往是伪科学，建议只保留少量、精选、受版本控制的集合（通常通过 Git、符号链接或自定义 CLI 管理），其余一律依赖确定性脚本或良好的 AGENTS.md/文档。
“skills” 是什么，以及它们在哪些地方有帮助
- 许多人将 skills 描述为小型、可复用的 prompt 文件或 runbook，用来告诉 agents 如何 执行可重复任务，通常把确定性脚本与更高层级的指导结合起来。
- 常见用途：
- 用于高频提示的宏 / 快捷方式（例如，rebase、测试运行、Jira 工作流）。
- 项目或组织特定约定：代码风格、提交信息、分支、部署步骤。
- 面向小众工具/CLI 或模型训练数据覆盖不足的专有系统的接口。
- “工作流缓存”，避免反复重新摸索多步骤流程该怎么做。
怀疑态度与“skills 已经过时”的观点
- 一些人认为，现代模型可以从仓库和文档中推断出大多数“通用”行为（设计评审、基础代码审查），因此通用的市场型 skills 没必要，甚至有害。
- 有些人把大型 skills 集合看作一种代码异味、额外的技术债，以及影响者营销的产物。
- 还有人更愿意把几乎所有内容都放进 AGENTS.md/README，让模型直接读取代码和文档。
- 也有人担心过度信任 LLM 的判断，并围绕 skills 构建脆弱、透明度不足的系统。
何时 skills 被视为必需
- 许多人在以下方面报告了很大收益：
- 专有、复杂或跨系统的工作流（部署、CI、安全检查、合规）。
- 在使用自定义工具时减少 token 消耗和反复试错（例如晦涩的 CLI、DSL）。
- 捕捉来之不易的调试流程或“在这里该怎么做”，避免 agents 重新学习。
- skills 被视为上下文指导和流程编码，而不是“额外智能”。
组织、共享与工具链
- 常见模式：
- 将 skills 放在版本控制之下（通常在 dotfiles 或专用仓库中），再通过符号链接接入 agent 的 skills 目录。
- 使用类似包管理器的 CLI 或“marketplace”（内部或公开）来安装、更新和固定版本。
- 将全局 skills 与项目特定 skills 分开；有些人会按任务域使用 profile 或“skillsets”。
- 通过脚本、Nix/Home Manager 或自建注册表，在机器和 agents 之间同步 skills。
设计、维护与评估实践
- 常被建议的原则：从零 skills 开始；只有在看到重复摩擦或 token 浪费时才添加；保持数量少、规模小、任务特定；定期清理。
- 有些人把 skills 当作代码：运行 eval 或行为测试，使用类似集成测试的检查，并在 agents 发生困难时更新 skills。
- 第三方 skills 的安全性与权限被标为关注点；许多人更倾向于只使用自建或经过内部审查的 skills。