夜雨聆风搞了 5 篇 AI化日记，我们从 CLI 化一路干到 Skill 化，把系统拆成了 8 个技能包，效果不错——AI 能自己查数据库、能自己跑报表、能自己排查调度延迟。
然后一个很朴素的问题摆在我面前：这些 Skill，怎么分给同事？
三条路，三条死胡同
方案一：发 zip 到群里。
第一天："这是数据查询的 Skill，用这个。"同事下载了 data-query-v1.zip。
第三天：修复了个 bug，又发 data-query-v1.1.zip。
第五天：加了新功能，发了 data-query-v2-final.zip。
一周后，同事问我："你那个数据查询的 Skill 有没有支持分页的版本？我不知道我电脑上的是哪个……"
这条路，走到第三天就知道不行。
方案二：发到公网的 Skill 注册中心。
ClawHub、skills.sh 这些公开市场确实方便，一行命令就能装。但问题是——我们这些 Skill 里装着公司内部系统的连接方式、数据库表结构、业务逻辑。把这些丢到公网上？安全部门第一个跳出来砍死我。
这条路，路标上写着"此路不通"。
方案三：放到公司 GitLab 上。
"这个是 Git 仓库，你 clone 下来，放到 ~/.claude/skills/ 目录就行。"
同事："Git 是什么？"
我："……"
不是同事的问题。公司里不是每个人都是程序员——运营同事要用数据查询 Skill，财务同事要用报表生成 Skill，你让他们装 Git、学 clone、理解 working directory？这条路技术上走得通，实际上走不通。
三条路都堵死了。然后，SkillHub 出现了。
讯飞在 GitHub 上开源了一个项目叫 SkillHub，一句话描述：企业私有的 AI Agent 技能包注册中心。 自托管，放在公司内网，Docker Compose 一行命令部署。
GitHub：https://github.com/iflytek/skillhub
也就是说——我们现在有了第四条路：
同事不需要知道 Git。不需要理解命令行。打开网页，搜索"数据查询"，点一下下载，Skill 就到本地了。
它的发布流程，和我们需要的完全吻合
准备阶段： 把 SKILL.md 和脚本打成一个 zip。这个我们已经有了——之前拆出来的 8 个 Skill，每个都是标准结构。
发布阶段： 三条路任选——CLI 一把梭（npx clawhub publish）、Web UI 拖拽、REST API 接 CI/CD。我们选 CLI 就行，发布脚本写进行 CI，代码合并即发布。
安全扫描： 发布后内置的 Skill Scanner 自动跑，检查有没有误夹带了密钥、Token。这不需要你手动触发，异步跑完，结果直接显示在后台。
审核机制： 命名空间可以开审核。普通同学提交 Skill，管理员看过 SKILL.md 内容、检查过扫描报告，点通过。不想开审核也行，Owner 自己发布直接上线。
版本管理： 语义化版本（1.0.0、1.1.0），latest/beta/stable 标签，多版本共存，版本不可变。这比"群里那个最终版一定是最终版吧？"可靠一百万倍。
还有两个让我觉得"就应该是这样的"的设计
兼容 ClawHub CLI 协议。 我们用的是 OpenClaw，配置一下注册中心地址，clawhub install 直接拉。一次发布到 SkillHub，所有 Agent 端（Claude Code、Loomy 等）都能装。不需要在每个平台维护一份。
权限粒度对路。 命名空间隔离，Owner/Admin/Member 三级权限，可见性分 PUBLIC / NAMESPACE_ONLY / PRIVATE。后端组和前端的 Skill 各放各的命名空间，互不干扰。需要跨组共享的，设成 PUBLIC 就行——都在内网，安全可控。
那块拼图
回头看我们这 6 篇日记的路线——系统 CLI 化、流程 Skill 化、Agent 同事化——其实一直缺一块拼图。
Skill 开发好了，能干活了，但如果分发靠 zip、靠 Git 教学、靠"你自己去那个目录找一下"，那 Skill 的价值就卡在了开发者自己的电脑上。
SkillHub 补上了这一块。它是 Skill 从"个人工具"到"团队基础设施"的那道桥。
Apache 2.0 开源协议，Docker Compose 一行命令部署到内网，兼容 ClawHub CLI。如果你也在走 CLI + Skill 这条路，Skill 做到第三四个的时候，你一定会需要它。
不写代码的程序员。
