今天早上 6 点我收到一封邮件。标题是SkillForge 每日同步完成内容很简单新增 1 个 Skill质检全部通过0 个需要人工处理。我看了一眼就关了。这封邮件我每天都会收到有时候新增十几个有时候一个没有偶尔会有几个质检不通过需要我看看。但大部分时候我什么都不用做。这个网站已经自己跑了半个月了。8 万个 Skill找不到我想要的skills.sh 是目前最大的 Claude Code Skill 目录上面有好几万个 Skill。东西是真的多但你打开试试就知道了——大多是都是英文没有分类搜索只能靠关键词硬匹配。你想找一个帮产品经理写 PRD 的 Skill搜 PRD 出来相关的搜 product manager 出来几十个长得差不多的得一个个点进去看 README 然后再翻译才知道干什么的。很难从里面找到真正适合自己的。使用 find-skills 也不够直观质量参差不齐。群里也经常有人问有没有好用的前端 Skill推荐一个写文章的 Skill每次都得靠人肉推荐。所以想法很简单做一个中文的 Skill 导航站按职业领域、技能分类。你是产品经理就看产品经理的你想用什么技能就去看对应领域的 Skill。三天后上线了。但上线只是开始。把活交给 AI然后翻车了最初的方案很朴素写个脚本每天自动抓 skills.sh 的新 Skill把 README 丢给大模型让它输出分类、中文描述、标签直接存数据库。听起来没毛病。跑了两天我就知道不行了。有个做 Kubernetes 部署自动化的 Skill模型把它分到了营销领域。我去看了下它的 README里面有一句automate your deployment pipeline模型大概把 pipeline 跟营销漏斗搞混了。我给每个 Skill 设计了一组使用前 vs 使用后的效果对比依照Skill.md\Reademe.md。这个设计到现在我还觉得是对的——用户不关心你怎么实现的只关心装上之后有什么不同。但 AI 生成的对比有些是这样的使用前类似手动分析数据 使用后类似自动分析数据还有更离谱的。一个代码审查 SkillAI 给的对比是使用前代码有 bug使用后代码没有 bug。这些问题让我意识到一件事AI 能理解内容但它的输出不可控。你不能像调函数一样用它——给输入就一定得到正确输出。所以第一版方案推翻了。不信任 AI但让 AI 互相盯着到底该怎么处理AI 不靠谱这个问题。全部手动显然不现实几千个 Skill靠人工分类写描述写到什么时候但全交给 AI 又会出上面那些问题。后来想通了一个原则代码做确定的AI 做不确定的。什么意思呢整个流程可以想象成一条流水线代码和 AI 轮流上场。先是代码干活去 skills.sh 把所有 Skill 的列表抓回来跟数据库比一下哪些是新的再把新 Skill 的说明文档下载下来。这些事情不需要动脑子规则明确代码做又快又准。然后 AI 上场拿到一个 Skill 的说明文档AI 来判断它属于 29 个领域中的哪一个写一段中文描述生成一组使用前 vs 使用后的效果对比再打几个标签。这些事情没有标准答案需要读懂内容才能做只能交给 AI。接着代码再检查一遍 AI 的输出分类结果是不是 29 个领域里的描述是不是中文效果对比的格式能不能正常显示检查通过才存进数据库不通过就打回。到这里还没完。存进去之后另一个 AI 再来审一遍。这是我踩完坑之后加的一步。一开始我让生成内容的 AI 自己检查自己的输出结果它觉得自己写的每条都挺好的。你让一个人自己改自己的作业他当然觉得没问题。所以我把生成和质检拆成了两个独立的 AI。负责生成的那个用能力更强的模型专注把描述和对比写好。负责质检的用另一个模型拿着一套检查标准逐条审核——描述跟原文档对不对得上效果对比有没有具体场景还是像手动做→自动做那种敷衍的质检不通过的第三个 AI 自动修复。但修复 AI 也有限制——它只能改描述和标签不能动效果对比。因为效果对比的质量要求高越自动改越容易跑偏不如留给我手动处理。修了之后质检 AI 再审一遍还是不行的就标记待处理等我来看。相当于一个小团队有人写、有人审、有人改、改完再审。只不过团队成员都是 AI而且互相不知道对方是谁。这套机制跑起来之后数据质量跟第一版比完全是两个东西。上线半个月我基本没管过它现在每天早上 6 点整个流程自动跑一遍。抓新数据、AI 分类和生成描述、代码校验入库、AI 质检、有问题自动修复、发邮件通知我。我定了一条铁律任何失败都必须发邮件通知不允许静默出错。 自动化最怕的不是出错是悄悄出错你不知道。跑了半个月确实没有出过坏了但我不知道的情况。除了每天的同步每周还有一轮存量质检对数据库里已有的 Skill 重新检查一遍。相当于持续保养。另外还做了一个 AI 搜索。普通搜索只能匹配关键词但用户经常用自然语言描述需求比如帮我找一个能自动写单元测试的工具。关键词匹配对这种查询束手无策。AI 搜索的思路是让模型帮用户理解需求然后挑选。但 5000 多个 Skill 的信息量太大不可能一次性全丢给模型让它挑。所以拆成了三步——先缩小范围再粗选最后精挑。第一步AI 判断用户的需求跟哪几个领域相关。写单元测试大概率跟测试和后端有关那就只看这两个领域的 Skill其他领域直接跳过。第二步从这两个领域里快速扫一遍所有 Skill 的名字挑出 30 个最可能相关的。这一步只看名字不看详细描述目的是快速缩小到一个可处理的范围。第三步把这 30 个的名字和描述都给 AI 仔细看最终精选 5-8 个推荐给用户每个都附上推荐理由。从 5000 多个到 30 个到 5 个三步漏斗每一步的工作量都是可控的。整个搜索过程几秒钟完成一个月的 API 成本大概十几块钱。上线之后有个意外收获搜索日志里能看到哪些查询返回了 0 结果。这些空搜索就是用户有需求但我数据库里没有的东西。后来做了个自动补充系统——收集这些搜索词自动去 GitHub 搜对应的项目AI 判断是不是 Skill是的话直接入库。用户的搜索需求反过来驱动数据补充又是一个自己跑的循环。它不只是在跑它在自己进化SkillForge 到现在有 5200 多个 Skill29 个领域支持中英日三语。但让我最意外的不是这些数字本身而是这些数字是怎么来的。上线的时候大概 4000 个 Skill。后面新增的这 1200 多个绝大部分不是我手动加的是系统自己找到的。不只是数据在涨用户也在涨。偶尔在推特上看到有人找 Skill顺手分享一下链接再加上群里口碑传播半个月下来 4000 多个访客1.7 万浏览量。每天的自动同步会从 skills.sh 抓新数据这是基本的。但真正有意思的是另一条线用户搜了什么、搜不到什么系统自己会去补。有人搜金融分析没有结果系统自动去 GitHub 找相关的项目AI 判断是不是 Skill是的话自动入库。下次再有人搜同样的词就能搜到了。每周的存量质检也是类似的逻辑。不是我告诉它这条描述写得不好你去改而是质检 AI 自己扫描、自己发现问题、自己修复修完再自己审一遍。回头看这些功能我发现它已经不只是自动跑了。它在自己进化。数据在变多质量在变好覆盖的需求在变广——这些都不是我在推动的是系统自己在做的。我只是偶尔看看邮件处理一下 AI 修不好的边角问题。甚至最近很火的人物蒸馏skill也是他自己找的在搜索日志中。它发现有一个关键词被反复搜索”同事”于是就回落到候选名单自己去搜一搜就搜到了然后自动走一遍流程后入库。目前人物蒸馏相关的 skill 已经 50 多个了。产品不再是你做完交付的东西而是你搭好骨架之后它自己生长的东西。传统的产品运营是这样的人工采集、人工分类、人工审核、人工发布你停下来网站就停了。你的时间被绑死在上面。但如果产品能自己跑、自己学、自己变好你的角色就变了——不是每天喂数据的运营而是搭骨架、定规则的架构师。做完一个腾出手做下一个。我在公司做的审核 Agent 也是这个思路。以后做个人项目我都会优先想一个问题这个东西做完之后能不能自己跑能不能自己变好如果不能先想想怎么让它能。依照这个思路你也能做一个能自己跑、自己进化的产品。网站地址skills.yangsir.net 往期推荐claude code skillsAI时代的产品经理AI编程效率提升Claude code全系列从小白到专家技术趋势与行业观察AI大模型热点追踪clawdbot实战与玩法飞书社群开源知识库https://my.feishu.cn/wiki/PFJswU0arip563kZbpNccWkIn0f?fromScenespaceOverview今天的文章就到这里啦如果觉得不错可以点个赞、在看、转发三连支持我扫描下方图片中我的微信二维码备注进群拉你进社群一起交流学习