Skills / Workflow
Skills Registry
100+ 个可复用的 AI 工作流，覆盖前端工程、自动化、音乐、写作、求职和 Agent 开发。按任务场景检索，直接拿到能用的指令。
- 角色
- Owner / Product Engineer：把分散在本地目录、仓库和工作流里的 skills 产品化成一个可公开访问的入口，并明确它的内容边界与使用方式。
- 时间
- 持续迭代 · 2026-05-20
- 平台
- Web
100+ AI 技能 · 按任务查找 · 开箱即用
01 / Background
为什么做
过去一年，我在日常工作中积累了 100 多个可复用的 AI 技能。部署前端项目、发音乐专辑、投简历、管域名、做竞品分析——每件事都沉淀成了一套经过验证的协作指令。这个站点把它们变成了可检索、可分享的公开目录，而不是继续埋在本地文件夹和聊天记录里。
Skills Registry 当前公开展示界面。
02 / Scenario
应用场景
- 要部署一个 Next.js 项目到 Vercel——不用从头配 CI/CD，vercel-deploy skill 一条命令搞定。
- 要在网易云和 DistroKid 同时发一张专辑——不用手动填几十个字段，music-board 系列 skill 跑完整条链路。
- 要同步更新 BOSS 直聘、猎聘、智联招聘上的在线简历——不用逐个平台登录修改，resume-online 系列 skill 一次完成。
项目当前最重要的交付与判断。
界面截图 01。
03 / Delivery
实现了什么
- 100+ skill 覆盖 8 个领域：前端工程、自动化运维、音乐发布、内容写作、求职工具、Agent 开发、视频图像和数据分析。
- 每个 skill 标注了适用场景和前置条件。从「我要做什么」反向找到工具，不需要先记住名字。
- 站点负责发现和筛选，完整文档、更新记录和源码留在 GitHub。两边各司其职，互不拖累。
从输入到结果的核心使用路径。
界面截图 02。
04 / Design
设计过程与取舍
- Skills 不只是“一个目录网站”。它是我整个 AI 协作实践的沉淀——每个 skill 都代表一个经过真实任务验证的工作模式。设计上没有追求“功能丰富”，而是在做减法：一个页面解决一个任务，一个场景聚合一组能力。
- 视觉上不走 SaaS 后台路线。暖纸色背景、衬线体和细线分割，让它更像一本可以翻阅、可以打印的参考手册。这种克制是有意为之：技能本身已经足够复杂，界面不能再增加认知负担。
- 站点和 GitHub 有明确的分工：站点负责“发现”——你在这里找到需要的 skill 并理解它能干什么；GitHub 负责“深度”——完整文档、更新记录和源码都在那里。更新一个 skill 文件，站点自动同步，不需要手动维护两份内容。
界面截图 04。
05 / Tech
技术实现
- 静态站点发布，重点在内容编排和入口治理，不引入重型应用框架。
- 站点展示和导航，GitHub 承载完整文档和版本演进。内容即代码，更新 skill 等于更新站点。
- 首页直接显示公开 skill 数量、脱敏数量和已上线场景——能力目录本身也是交付物，不只是链接集合。
产品流程图。
06 / Access
当前访问方式
- 线上地址：skills.zondev.top。
- 页面内可直接跳转 GitHub 仓库、技能目录和最近更新，方便继续深挖。
体验深描
痛点、用户故事与交互设计
这一段不讲技术栈，只讲「人在什么处境下用它、哪里卡住、我做了什么回应」。
我的痛点
这些项目都从我自己被卡住的地方开始。
- P01
一年攒了 100+ 个可复用的 AI 工作流，全散在本地文件夹和聊天记录里。
- P02
真正的阻碍不是「有没有能力」，而是「知道要做什么，却不知道该先看哪个 skill」。
- P03
按 skill 名字浏览没用——名字是我自己起的，过两个月我也记不住。
- P04
想分享出去，但不少 skill 里有私密路径和未脱敏内容，不能直接公开。
- P05
如果把所有说明都堆进网站，目录会迅速变重变乱，还要维护两份内容。
用户故事
写成「作为…我想…以便…」，每条对应一个可验证的产品动作。
- US01
作为有明确任务的人，我想先按「我要做什么」缩小范围，再进入具体 skill，以便不用先记住名字。
- US02
作为想快速上手的人，我想每个 skill 都标注适用场景和前置条件，以便判断它能不能直接用。
- US03
作为需要深挖的人，我想从站点一键跳到 GitHub 的完整文档与源码，以便深度内容不被网站阉割。
- US04
作为维护者，我想更新一个 skill 文件就等于更新站点，以便不需要维护两份内容。
- US05
作为要公开展示的人，我想站点只呈现脱敏后的部分，以便公开不等于泄漏。
用户体验旅程
按真实使用顺序展开：此刻在做什么 / 哪里有摩擦 / 产品怎么回应。
阶段此刻在做什么摩擦点产品回应
01说出要做的事
带着一个具体任务进来，比如「把项目部署到 Vercel」。
目录型网站默认你先知道工具名字，这个前提本身就不成立。
入口语义从「按 skill 名浏览」改成「先找到要做的事」，动词而不是名词作为入口。
02缩小范围
在 8 个领域与若干场景里定位到一小组能力。
100+ 条平铺会直接淹没人。
一个页面解决一个任务，一个场景聚合一组能力，先收敛再展开。
03判断能不能用
打开某个 skill，想知道要不要装什么、有没有前置条件。
缺少前置说明时，试错成本比自己写还高。
每个 skill 标注适用场景与前置条件，判断在进入执行前完成。
04深挖与复用
确认可用后，需要完整 spec、更新记录与源码。
网站放不下完整文档，硬放会让目录失焦。
站点负责发现与筛选，GitHub 承接完整文档与版本演进，两边各司其职。
交互细节
决定「用起来顺不顺」的微观判断。
- 目录本身就是交付物
- 首页直接显示公开 skill 数量、脱敏数量与已上线场景，而不是只给一堆链接。
- 从任务反查工具
- 导航以任务动词组织，用户不需要先记住任何 skill 名称。
- 站内不复制文档正文
- 站点只做发现与导流，避免同一份内容出现两个版本。
- 内容即代码
- 更新 skill 文件即更新站点，不存在「文档已改、网站还旧」的状态。
设计细节
视觉系统、状态语言与节奏上的取舍。
- 参考手册而非 SaaS 后台
- 暖纸色背景、衬线体与细线分割，让它更像一本可翻阅、可打印的手册。
- 做减法
- 技能本身已经足够复杂，界面不能再增加认知负担，因此不追求功能丰富。
- 分层公开
- 能公开的放站点，完整 spec 留 GitHub，边界写在明处而不是靠模糊处理。