不是装得越多越好，是装得对且能退：xiaobai-skills 给 Codex 初学者的策展工具
不是每个用 Codex 的人都需要写 Skill。但几乎每个用 Codex 的人，都会在第三天上当。
不是每个用 Codex 的人都需要写 Skill。但几乎每个用 Codex 的人，都会在第三天上当。
装了二十个 Skill， prompt 一触发，三个 Skill 同时跳出来抢活。前端框架来了两个，测试规范来了三个，每个都说自己最懂。你删一个，过两天发现那个才是对的。你全留着，上下文预算被 Skill 描述占掉一半。
Tyuts 的 xiaobai-skills 就是来解决这个混乱的。它是个策展工具，不是 Skill 库。它的工作不是给你更多选择，而是帮你 做出选择并保留退路。
一、策展（Curation）而非收集
Skill 生态现在是什么状况？Vercel 的 skills.sh 支持 50 多种 Agent，从 Claude Code 到 Codex 到 Cursor，统统一套格式。Matt Pocock 的 skills 专注工程规范，Baoyu 的 skills 做前端视觉。每个库都是好库，但合在一起就是灾难。
xiaobai-skills 的核心设计是 "一个需求，一个默认，其余备份"。
它不像 npm 那样把所有依赖都装到 node_modules 里不管。它会：
- 审计你已经安装的 Skill
- 识别重叠（overlap）
- 让你选一个作为全局默认
- 把没选的移到备份文件夹，而不是删除
- 生成一份清单，解释为什么这样选
二、推荐套装的质量
xiaobai-skills 的推荐 starter set 覆盖八个领域：
| 领域 | 代表 Skill | 来源 |
|---|---|---|
| Skill 发现 | find-skills | OpenAI |
| Skill 创建 | skill-creator | OpenAI |
| 前端实现 | frontend-master | OpenAI |
| 图像生成 | imagegen | OpenAI |
| 内容工作流 | URL→Markdown, 翻译, 发布 | Baoyu 精选 |
| 工程规范 | TDD, 诊断, 审查 | Matt Pocock 精选 |
| 策展备份 | xiaobai-skills 自身 | Tyuts |
推荐清单里明确把 gstack、superpowers 和某些 Matt Pocock 子 Skill 列为"默认备份候选"——不是不好，是太宽，容易和其他 Skill 冲突。
三、冲突解决机制
这是策展工具真正的技术含量。
多个 Skill 的触发条件（trigger words）重叠时，Codex 会同时加载多个 SKILL.md 的完整内容。上下文预算被吃掉，Agent confusion 概率上升。
xiaobai-skills 的解法很粗暴但有效：
- 扫描所有已安装 Skill 的 name 和 description
- 根据关键词重合度计算"冲突分数"
- 把高冲突的 Skill 对列出来
- 用户选一个做主，另一个移走
备份目录的结构 ~/.codex/skills-backup/xiaobai-YYYY-MM-DD/ 加了一份 README.md 解释为什么每个 Skill 被移走。这个细节体现了一种产品设计思维：你今天的错误决定，应该能让明天的你轻易撤销。
四、与 skills.sh 的关系
Vercel 的 skills.sh 是生态的基础设施——统一安装、更新、移除。但它只管"有没有"，不管"合不合适"。
xiaobai-skills 是生态的治理层。它不替代 skills.sh，而是建立在它之上：
- 用 skills.sh 安装 Skill
- 用 xiaobai-skills 决定哪些全局激活、哪些备份
五、对 Agent 生态的预判
我觉得 Skill 生态正在重复 VS Code 插件的历史：
- 早期：没有插件，裸用
- 爆发期：插件数量爆炸，装 200 个的人比比皆是
- 整理期：出现 curated sets（如 VS Code 的 Extension Pack）
- 成熟期：精选套装成为默认，散装安装成为小众
但这个假设有个风险：真正的新手可能连"需要策展"这件事都意识不到。他们更可能的行为是：装一堆，出问题，然后怪 Agent 不好用。
所以 xiaobai-skills 如果能做到一件事，价值会翻倍：在冲突发生前预警。不是等装了二十个 Skill 才审计，而是在装第五个的时候就提醒"你的 TDD 相关 Skill 已经有三个了，建议选一个"。
这需要 hooks 或者对 Codex 安装行为的拦截。目前项目用 PowerShell 脚本，还做不到这个粒度。但这是值得做的方向。
六、局限
1. Windows 中心：PowerShell 脚本为主，macOS/Linux 安装器还在 TODO 里。但 Skill 生态的主力用户是开发者，macOS/Linux 占比不低。
2. 无自动更新：Skill 库在不断进化，Matt Pocock 上周刚加了 /prototype，Baoyu 每周更新。xiaobai-skills 的推荐 set 是静态的，需要手动同步。
3. 备份是冷备份：移走的 Skill 需要手动恢复，没有"试用三天自动回退"的优雅机制。
七、一句话判断
如果你用 Codex 已经超过一周，装了超过十个 Skill，经常感觉"Agent 怎么又理解偏了"——大概率不是 Agent 的问题，是你的 Skill 在打架。
xiaobai-skills 不解决 Agent 的智商，但它解决你的工具箱的混乱。在 Skill 生态从"野蛮生长"转向"精耕细作"的转折点，这类策展工具会越来越多。
不是装得越多越好，是装得对且能退。
项目信息
- GitHub: https://github.com/Tyuts/xiaobai-skills
- 定位: Codex 初学者 Skill 策展与备份工具
- 推荐套装: 前端/图像/内容/工程/策展 8 个领域
- 上游依赖: OpenAI 官方 Skill, Matt Pocock skills, Baoyu skills, skills.sh
- 安装: PowerShell 脚本 + 未来支持跨平台
- 许可证: MIT
讨论回复（1）
这篇从策展角度切入，比单纯介绍功能更有意思。
我补充一个观察：Codex Skill 的冲突不只是关键词重叠，还有层级冲突。比如 Matt Pocock 的 /tdd 强调 red-green-refactor，而某些大框架 Skill 可能直接把测试作为子步骤嵌入。两者不抢关键词，但工作流逻辑矛盾。策展工具如果只看 name/description 的重合度，会漏掉这种隐性冲突。
建议 Tyuts 考虑引入工作流签名检测：提取每个 Skill 的核心动作序列（如 [write-test → run-test → implement → run-test → refactor]），用序列相似度判断冲突。这比关键词覆盖更精准，但实现成本也高。
另一个方向：与 skills.sh 的 模式整合。用户在装新 Skill 之前，先跑一遍冲突预演，而不是装完再审计。策展前置化，体验会好很多。