遇到的问题
skill 越装越多,特别是全局安装的 Skill ,元信息占用了过多的上下文空间。为了解决这个问题,我的第一反应是全局只装必要的 Skill ,其他的就具体的项目里安装。 但是这样我就逃避了一个问题:怎么样才能集中管理Skill? 前段时间看到宝玉老师通过 Symlink 去管理 Skill:通过 Symlink 直接链接到原始 Skills 的 Repo。我觉得这是个管理 Skill 的好办法,再结合我现在使用 Skill 的经验:
- 别人的 Skill clone 下来需要根据不同的Agent架构与电脑环境进行适配才好用。更新的时候适配还需要重新做一遍。
- Skill 太多,对于 Skill 的触发方式、功能、完成度、来源(主要用于更新)两眼一抹黑,需要 Skill 总览和 Skill 搜索,提高 Skill 的使用效率。
找AI聊需求

发现自己遗漏了一些细节。
之前的设计我只是通过安装方式对 Skills 进行了分类,并没有管理 Skill 的状态,所以让AI补全了相关的设计。
before:
- custom 目前表示"自己写的、完成后进入 skills"。
- remote 表示"远程拉取的、待适配"。
- skills 表示"最终可用"。
after:
sh
./
├── registry/ # 核心索引层,不是给人手工翻目录用的
│ ├── skills.json # 所有 skill 的注册表
│ ├── sources.json # 来源仓库、版本、同步信息
│ └── projects.json # 各项目启用关系
├── warehouse/
│ ├── remote/ # 原始拉取内容,只保留上游原貌
│ ├── adapted/ # 适配后的可分发版本
│ └── local/ # 本地原创 skill
├── runtime/
│ ├── global/ # 当前全局启用集合
│ └── projects/ # 每个项目的启用清单或 symlink 目标
├── manifests/
│ └── <skill-name>.yaml # 每个 skill 的声明文件
└── bin/
└── hk-skill # 管理命令入口
和AI探讨了之后,让他重新出了一版设计文档。
项目已开源,设计文档放在里面了,如果不忙会把方案单独抽出来做成工具。
产品效果
sh
./bin/hk-skill install {repo}
# 执行流程:fetch → vet → adapt → register
# 拉取远程项目并进行安全审查,成功就注册,失败就清除文件
./bin/hk-skill enable {skill-name} --global
# 全局启用,建议工具类方法
./bin/hk-skill enable {skill-name} --project {project-path}
# 项目内启用,project-path为绝对地址
经验教训
因为刚开始只是当作小工具在开发,所以出了设计文档就开始 vibe coding,正是因为没有技术方案,也没有写 spec、rules 和 agents.md 这些文档才导致了后面 token 飙增的情况出现。
有了设计文档一定要有配套的技术方案和规范文档!这里不能省,省了后面更亏。
设计就像十月怀胎,写代码就像一朝分娩,设计就是写代码。情况不明决心大,心中无数点子多。
期间我尝试了多种模型配合开发的场景,最后感知到的体验是:
- OpenCode + oh-my-openagent 效果比单一类型的模型效果更好。但是偶尔会出现卡死的情况,虽然有指定Agent-Atlas作为上下文维持,但是还是没法及时中断并重启项目,写之前需要单独声明:做不来的工作别勉强,及时中断或者换个工作。
- GPT5.4 计划/审核/测试 + kimi2.5 执行,效果最好。(期间还用了 glm5.1/gemini3/minimax2.5)