先说结论这个标题不是噱头是我自己搭了快八个月才敢写出来的总结。去年我还是典型的一个人扛全流程的自由开发者接单、写方案、改代码、做内容、回客户消息所有事情都压在一个人身上。直到我把自己的经验沉淀成了一个 skill 仓库用统一的编码和部署脚本把 243 种技能管理起来整个人的工作方式才真正变了。这篇就把仓库结构、SKILL.md 规范、3 分钟部署链路、分类体系以及一路踩过的坑全部拆开讲适合所有想用 AI 提升单人产出效率、把经验资产化的人参考。1. 为什么我要把243种skill塞进同一个仓库1.1 先搞清楚skill到底是个什么东西很多人第一次听到 skill 这个说法会误以为它是一个插件或者一个 API。实际上一个 skill 的本质是一份“给 AI 代理的可执行手册”通常由一个 SKILL.md 主文件加上若干辅助文件组成。SKILL.md 里面用 YAML 格式写明元信息比如名字、描述、输入、输出、依赖正文部分则是逐步执行的指令。AI 代理读到这份文件就知道自己该按什么流程干活了。我用一个生活化的例子解释老师傅带徒弟不会把自己脑子里的经验直接传过去他得把流程写成一二三步徒弟照着做才不会跑偏。skill 就是给 AI 用的这份“带徒手册”。以前我给客户交付方案交付完知识就留在对方那里了现在我把每次交付都拆成 skill经验留在自己的仓库里下次还能复用。这个认知转变是我从“接一单做一单”走向“越做越轻松”的关键。另外要注意skill 和普通提示词的区别是结构化的。提示词是一段话skill 是一个完整的小工程它带输入输出约定、带校验规则、带参考脚本。主流 agent 框架里已经有很多类似机制但核心思路都一致只是在不同平台上叫法略有差异。理解了这一点后面所有内容都好谈。1.2 一个人干五个岗位的日子我受够了我去年最崩溃的一段时间一周要同时跟进三个项目白天写代码晚上写文案凌晨还要回客户消息。那时候我的做法是在对话记录里反复翻找以前写过的提示词改几个字段再发给 AI 用。效率极低因为每次找提示词要五分钟改完还不一定好用模型一更新旧提示词的效果又飘了。我试着把所有提示词存进文件夹结果发现根本没法维护。问题不是文件多而是没有结构。没有索引没有版本没有输入输出约定过上两个月我自己都忘了某个文件名对应的是什么能力。更别提把几个提示词组合成一个复杂工作流那基本靠手动拼拼完还得担心前后逻辑是否一致。后来我才意识到我缺的不是更多时间而是把“自己会做的事情”沉淀成可复用资产的能力。一个人的公司最大的浪费就是经验流失。接过的每一单、调过的每一个接口、写过的每一类文案如果不能沉淀下来变成下次直接可调用的资产那每次都是从零开始。于是我开始规划这个仓库目标很明确所有我知道怎么做的任务都要变成仓库里一份可检索、可调用、可组合的 skill。1.3 仓库模式赢在哪里有人会问为什么不直接在某个 AI agent 平台的技能市场里下载别人做好的 skill 来用我确实试过。通用 skill 放到具体业务里总是差点意思你还是得自己改。更关键的是你真正值钱的是自己业务流程里的判断比如你客户的文案风格、你习惯的数据指标口径、你对交付质量的验收标准——这些经验很难从同一套模板里得到。自己的仓库意味着你对自己所有技能有完全控制权。想改就改想组合就组合还能通过 git 看到每个 skill 的改动历史。仓库模式的另一个好处是可测试。我给每个 skill 都设计了自检入口执行前先用一个固定样例跑一遍看输出是否符合预期没问题再放进生产环境。这种“可回滚、可测试、可版本化”的能力是散落提示词永远给不了你的。2. 仓库结构与skill编码规范2.1 目录就这样排仓库顶层结构非常朴素但每一层都有约定。第一次打开这个仓库的人三十秒内能找到任何一个 skill。我见过很多个人项目目录建得比微服务还复杂最后维护的人自己都不想打开。记住一人公司的仓库应该追求“打开就知道放哪”而不是“架构漂亮”。skill-hub/ ├── deploy/ │ ├── docker-compose.yml │ ├── .env.example │ └── deploy.sh ├── docs/ │ ├── SKILL_TEMPLATE.md │ └── CODING_GUIDE.md ├── scripts/ │ ├── build_index.py │ ├── self_test.py │ └── lint_skill.py └── skills/ ├── SK-001-article-writing/ │ ├── SKILL.md │ ├── requirements.txt │ └── templates/ └── SK-012-social-copywriting/ ├── SKILL.md ├── scripts/ └── assets/重点说一下 skills 目录的约定。每个 skill 独占一个子目录目录名格式是“编码-短横线描述”。SK-012-social-copywriting 这个目录里SKILL.md 是主文件requirements.txt 是 Python 依赖如果有templates 目录放输出模板assets 目录放参考样例。所有 skill 的目录结构保持一致这样脚本处理起来非常省事不用为每个 skill 写特例。2.2 SKILL.md的frontmatter和正文怎么写SKILL.md 是整个系统的核心。我用 YAML frontmatter 结构来定义元信息正文部分写具体的执行步骤。这里直接放一个我实际使用的模板--- name: SK-012-social-copywriting description: 生成适合小红书发布的中文种草笔记包含标题、正文和话题标签要求口语化、有真实体验感、避免机器腔。 version: 2.3.0 tags: [内容创作, 小红书, 文案] input: product_name: string, 产品名称 selling_points: list, 核心卖点 output: markdown文件包含标题建议、正文、话题标签 dependencies: [pandoc] --- # 任务目标 基于产品信息和卖点生成3版不同角度的种草笔记。 # 执行步骤 1. 提取产品名称和核心卖点。 2. 为每个卖点找一个具体的使用场景。 3. 按模板要求写正文加入真实体验细节。 4. 生成3个候选标题每个不超过20字。 5. 结尾附上话题标签。 # 输出模板 ## 标题 标题内容 ## 正文 正文内容 ## 话题标签 #标签1 #标签2 #标签3 # 质量校验点 - 正文是否包含具体场景细节 - 是否有至少一个情绪起伏 - 标题是否超过20字 - 是否出现“众所周知”“值得注意的是”等机器腔词汇为什么 frontmatter 这么重要因为检索和调度全靠它。AI 代理在接收到任务时会读取所有 SKILL.md 的 description 字段跟当前任务做匹配。description 写得越具体匹配越准。我曾经有一个 skill 的 description 只写了“写文案”结果任何文案类任务它都能被匹配上看起来没问题实际上因为太宽泛经常被匹配到不合适的场景。正文部分同样有讲究。我坚持包含“任务目标、执行步骤、输出模板、质量校验点”四块。任务目标解决“做这件事要在什么语境下”执行步骤解决“按什么顺序做”输出模板解决“做成什么样”质量校验点解决“如何防止 AI 发挥忽好忽坏”。这四个部分缺一不可尤其是质量校验点这是我后来才补上的效果立竿见影。2.3 从SK-001到SK-243数字不是瞎定的243 这个数字看起来吓人实际上每个 skill 都分配了固定编码段管理起来非常清晰。我把 8 大类常用工作流各分配了 30 个编码位最后额外留了 3 个总控类 skill。这样的设计便于快速判断一个技能属于哪一类也方便在 agent 调度时按编码段做权限控制和任务分流。类别编码段典型skill示例应用场景内容创作SK-001 ~ SK-030SK-012 小红书种草文案公众号、小红书、短视频脚本编程开发SK-031 ~ SK-060SK-042 API接口生成快速生成后端接口、修复bug数据分析SK-061 ~ SK-090SK-068 销售日报生成从数据源提取指标并生成报表营销增长SK-091 ~ SK-120SK-105 投放落地页结构广告文案、渠道分析、转化思路运营管理SK-121 ~ SK-150SK-132 项目进度同步周报、排期、任务拆解客户服务SK-151 ~ SK-180SK-165 售后话术生成客服应对、邮件回复办公效率SK-181 ~ SK-210SK-198 PPT大纲生成会议纪要、文档整理知识管理SK-211 ~ SK-240SK-225 读书笔记结构化阅读总结、方法论沉淀总控编排SK-241 ~ SK-243SK-242 任务分发多skill协作调度每个 category 也就 30 个空位但一个类别只放 10 到 20 个留一些余量给未来新增的 skill。我觉得分类数量不重要重要的是“3 个总控技能”虽然数量最少价值却最高它们负责把其他 240 个技能编排起来完成真正复杂的工作流。2.4 依赖、版本和自动校验每个 skill 的依赖我写死在 SKILL.md 里如果依赖是 Python 包目录下放 requirements.txt如果是系统级工具比如 pandoc、ffmpeg就统一在部署脚本里安装。为什么不在所有 skill 之间共享一个大环境因为隔离能避免依赖冲突。比如某个排版类 skill 需要老版本 markdown 库另一个技能需要新版本独立 requirements.txt 是为了减少相互干扰。版本管理我直接复用 git。整个仓库一个 repo每个 skill 的改动都走 commit。发布新版本时打 tag比如 v2.3.0而不是给每个 skill 单独维护版本号。SKILL.md 里的 version 字段只是给人看的git tag 才是系统实际依赖的版本标记。3 个总控 skill 会引用其他 skill 的版本号配合 tag 回滚非常方便。还有一件值得做的事我给 repository 写了一个 lint 脚本在 pre-commit hook 里自动执行。这个脚本会检查每个 SKILL.md 是否有合法 frontmatter、description 是否少于 50 字、编码是否重复、依赖是否声明。规则很简单但它救了我不止一次。一旦某个 skill 格式坏了agent 在运行时根本不会触发它而你往往要过很久才能发现。有自动校验坏文件根本进不了仓库。3. 3分钟部署从克隆到可调用3.1 部署前需要准备什么先说清楚3 分钟是指在你本机已经装好 Docker 和 Git 的前提下从克隆仓库到 API 自检完成的时间。如果你要现装 Docker那肯定不止 3 分钟这是合理的前提。整体只需要一台 2 核 4G 的 Linux 机器不需要 GPU。很多同学一听 AI 就觉得要显卡其实这套仓库里跑的检索和调度逻辑CPU 完全够用。为什么不需要 GPU因为所有 skill 的检索用的是本地小向量模型比如 nomic-embed-text384 维CPU 推理很快。而真正调用大模型生成内容的部分是通过 API 完成的不在部署范围内。所以一台云主机每个月的成本可以控制在很低这符合一人公司“低成本起步”的需求。部署前你要准备好三个信息本机 IP 或域名、要开放的 API 端口默认 8000、以及如果你要跑大模型 API 服务的 key只需要在 .env 里配置不配置也能先跑索引和检索。没有 GPU、没有高配服务器、没有复杂的依赖环境这是我能做到 3 分钟部署的前提。3.2 一键部署脚本到底做了什么部署脚本名字就叫 deploy.sh全流程分五步执行。每步都有明确输出中途出现任何问题立即停止并提示不会让你蒙在鼓里。这是我写的简化版本#!/bin/bash set -euo pipefail echo [1/5] 检查环境... docker --version /dev/null 21 || { echo 缺少 Docker; exit 1; } git --version /dev/null 21 || { echo 缺少 Git; exit 1; } echo [2/5] 生成环境变量... cp .env.example .env sed -i s|SKILL_REPO_DIR|$PWD/skills| .env sed -i s|API_PORT|8000| .env echo [3/5] 启动基础服务... docker compose up -d echo [4/5] 构建skill索引... docker compose exec api python scripts/build_index.py echo [5/5] 运行自检... docker compose exec api python scripts/self_test.py echo 部署完成。API地址: http://localhost:8000第 1 步检查环境很好理解。第 2 步生成 env 文件时脚本会把当前目录的绝对路径写进 SKILL_REPO_DIR这保证迁移仓库位置时不用手动改配置。第 3 步用 docker compose 一次性拉起所有服务包括 FastAPI 网关、向量检索服务和 Redis 队列。第 4 步是构建 skill 索引这一步会把 skills 目录下所有 SKILL.md 的元信息尤其是编码、description、tags读出来写入 sqlite 数据库并对 description 做向量化。为什么要向量化因为用户自然语言提问和 skill 描述不一定是字面上的匹配向量检索能解决“同义词”和“意图理解”问题。第 5 步自检脚本会检查所有 243 个 skill 是否都能被检索到同时用一个固定测试任务跑一次完整链路。3.3 关键参数与选型解析部署过程中有几个参数我一开始也是摸着石头过河后来固定成了推荐值大家可以直接抄配置项推荐值说明embedding模型nomic-embed-text本地推理、384维、CPU可跑索引存储sqlite3数据量极小不需要Elasticsearch检索top_k5召回5个候选再由排序规则精排API端口8000FastAPI网关默认监听队列并发4控制对大模型API的并发请求内存占用约3GBollama约2G网关Redis约1G先说索引存储。243 条 skill 的 description 文本加起来连 100KB 都不到这个量级用 sqlite 绰绰有余。很多人一上来就想上向量数据库完全没必要。检索质量的关键从来不是存储引擎而是你 description 写得清不清楚。我花了大量时间打磨 description让每个 skill 的描述都包含“能做什么”“在什么场景用”“输入什么”三个要素这样即使用传统关键词检索也能找到。再说并发控制。这套系统是我一个人用的并发本来不高但我仍然在网关层把并发限制到 4。为什么因为如果不限制某个调度任务可能会循环调用几十次大模型 API一次性把额度打爆。限制并发后哪怕出现循环 bug损失也可控。这个习惯让我避免过一次比较大的费用事故当时一个测试任务在循环里调了 300 多次 API如果不是队列限制那个月账单会很难看。3.4 部署完怎么验证部署完不能直接开跑先做一轮验证。我习惯用两条 curl 命令快速确认系统状态。第一条测搜索第二条测执行curl http://localhost:8000/skills/search -X POST \ -d {query:写一篇小红书种草文案,top_k:3} curl http://localhost:8000/skills/run -X POST \ -d {skill_id:SK-012,input:{product_name:便携榨汁杯,selling_points:[无线,30秒榨汁,USB充电]}}第一条命令应该返回 3 个匹配的 skill其中 SK-012 的相似度和排序应当排在第一。如果 SK-012 没出现在结果里说明 description 写得太宽泛或者索引没重建。第二条命令会实际执行文案生成正常情况会返回标题、正文和话题标签。这一步验证的是“从搜索到调度到执行”的完整链路。我建议第一次部署时跑两遍测试第一遍用 curl第二遍用仓库自带的 client.py 脚本因为脚本会打印更详细的日志方便排查问题。跑通之后就安心了这套系统可以稳定地作为你日常工作的基础设施。4. 243种skill如何组成一套赚钱系统4.1 八大类别的拆分逻辑243 个 skill 不是拍脑袋凑出来的是按一人公司最常干的活拆的。我在第 2 章的表格里列出了八大类别这里重点讲“为什么这样拆”。一个人经营业务绕不开四件事做东西、卖东西、服务客户、管流程。内容创作和编程开发属于“做东西”营销增长属于“卖东西”客户服务和运营管理属于“服务客户与管流程”数据分析和知识管理则是给前三者做支撑和反馈。这个分类逻辑的价值在于遇到一个具体需求时我能很快定位“这件事该找哪个类别的 skill”。比如客户问我能不能做一份投放数据复盘我第一反应是打开数据分析类找到报表生成和指标解读两个 skill而不是在整个仓库里翻。如果你也打算建自己的仓库我建议先按自己的业务画一张“工作地图”把常做的任务分类再按类别建 skill而不是想到哪写到哪。每个类别里面skill 的粒度也有讲究。我坚持一个 skill 只做一件具体的事。比如“写小红书文案”是一个 skill“写公众号长文”是另一个 skill而不是一个“写文案” skill 包打天下。粒度越小复用越灵活调度的匹配精度也越高。缺点是需要维护的条目变多但有编码体系兜底多不是问题。4.2 一个真实skill的完整解剖拿 SK-012 小红书种草文案来举例这个 skill 的完整结构是这样的。SKILL.md 文件我已经在第 2 章展示过了这里说几个实际使用中的关键经验。首先是 description 字段。我一开始写的描述是“生成小红书文案”后来发现检索经常匹配到其他记账类、节日祝福类任务。改成“生成适合小红书发布的中文种草笔记包含标题、正文和话题标签要求口语化、有真实体验感、避免机器腔”之后匹配准确率明显提升。这说明描述越具体越能表达“这个 skill 的边界在哪里”。其次是输出模板。以前我让 skill 自由发挥它有时给 Markdown 表格有时给纯段落格式不稳定。后来我在 SKILL.md 里固定了输出模板要求标题、正文、话题标签分块输出并且要求每个部分有明确标记。坏处是不够灵活好处是后续如果要接排版或发布流程数据格式统一处理脚本不用写一堆规则。对一人公司来说格式统一省下的时间非常可观。最后是质量校验点。这是我最晚加入的部分却是我最推荐你复制的地方。AI 生成内容最大的问题是“同质化”和“正确的废话”。我把“是否有具体场景细节”“是否有情绪起伏”“是否出现机器腔词汇”写进校验清单让 agent 在执行完任务后自己对照检查一遍不合格就重写直到通过为止。实测下来输出内容的质量稳定度提升了一大截。4.3 三个总控skill的调度实战三个总控 skill 分别是 SK-241 客户需求拆解、SK-242 任务分发、SK-243 质量汇总。它们是整个仓库的“导演”。拿我最近接的一个需求举例客户要“给便携榨汁杯写 3 篇小红书笔记配 3 张场景图出一份一周发布排期”。以前这个需求我要自己做三件事至少花一天。现在流程是这样的先把需求丢给 SK-241它会拆解出“文案 3 篇、场景构图 3 套、发布时间表 1 份”三个子任务。然后 SK-242 根据任务类型自动分派文案任务发给 SK-012构图任务发到 SK-036 配图生成排期任务发到 SK-128 排期表生成。最后 SK-243 汇总三个子任务的输出检查文案与配图是否一致、排期是否合理输出一份整体交付文档。这里有个细节中间的“编导”环节我会在关键节点做一次人工确认。比如 SK-241 拆完子任务后我会扫一眼拆得对不对确认后再让下游执行。这一步看似多余实际上是整个链路的安全阀。因为一旦拆解错了后面的执行全都白费还不如在最早环节掐掉错误。自动化不是完全放手而是把有限的精力放在最重要的判断节点。4.4 赚钱模式的边界在哪里必须说点实在话skill 仓库本身不赚钱赚钱的是它让你“一个人干五个人的活”。我用这套系统接内容代运营、做技术咨询 demo、给客户交付流程方案。比如以前接一个数据日报需求要从零写脚本一边查文档一边写交付三到五天现在调用 SK-061 到 SK-080 里对应的数据处理 skill脚本结构已经有了我只需要改参数和核对结果半天就能交付。同样的报价我的成本降了利润自然上来。但别被“终极赚钱模式”这种词冲昏头。skill 仓库替代的是执行层判断层、决策层、客户关系永远是人的活。客户要的是你帮他做判断而不是你丢给他一个仓库。我见过有人把 skill 仓库当成发财捷径以为买了模板就能日进斗金实际上一周就放弃了。这套系统真正的作用是放大你的能力不是凭空生钱。用之前先想清楚你的业务里哪些是反复做的执行工作哪些是真正需要你的判断的工作把执行交给 skill把自己留给判断。5. 常见问题与排查技巧实录5.1 部署阶段最容易翻车的三个点部署阶段我见过最多的有三个问题。第一个是端口占用。8000 端口往往被其他项目占着解决方案很简单改 .env 里的 API_PORT或者先用docker compose ps看看哪些服务在跑。第二个是 Docker 版本太低docker compose 的某些语法在老版本上不兼容升级到 Docker 20.10 以上的版本基本能解决。第三个是模型权重下载慢第一次启动 ollama 时需要拉取 nomic-embed-text 模型网络状况不好时会很慢。建议提前手动执行ollama pull nomic-embed-text把这个下载放到部署脚本之前。我踩过一次最典型的坑deploy.sh 执行完显示部署成功API 也能调通但搜索总是返回空结果。查了半天发现是索引脚本在 build_index 时报错但因为脚本没有加set -e错误被忽略了流程继续往下走最后 API 起来了但索引是空的。后来我在所有关键脚本里都加上set -euo pipefail并让自检脚本检查索引条数是否为 243如果不是就报警。这样任何一步出错都不会被掩盖。5.2 skill搜不到优先查这三处skill 搜不到我总结下来 90% 是三个原因。第一改了 SKILL.md 之后没有重建索引。description 和 tags 是搜索的依据但索引是在部署时构建的改完文件必须重新跑 build_index.py否则系统用的还是旧数据。第二description 写得太泛。我之前说过“写文案”这种描述几乎匹配不到任何任务。第三搜索词和描述用词不一致。比如描述里写的是“种草笔记”搜索时输入“推广文案”即使语义相近也可能匹配不上所以我会在描述里尽量把同义词也加上或者把检索 top_k 调大一点。遇到搜不到的问题我的排查路径是固定的先看索引有没有重建然后看 SKILL.md 的 description 是否具体再看搜索词和描述之间是否有词汇鸿沟。如果都排除再查向量模型是否正常加载。这四步排查法基本解决了我遇到的九成问题。5.3 生成质量不稳定怎么办大模型输出不稳定是很正常的所以我给每个 skill 都写了质量校验点在 SKILL.md 里明确要求 agent 输出前自检。还有一个很有效的参数调整把大模型 API 调用时的 temperature 压到 0.3 以内。这个参数控制输出的随机性越低越稳定。创作类任务稍微调高到 0.5 左右保留一点灵活性但纯分析、代码、报表类任务一律用低温度。我还会定期抽检生成结果。跑完一个任务后把结果里不合格的部分记录下来整理成 bad case 清单每个月回头更新一次 SKILL.md。比如某段时间发现文案总是出现同一个套话就在质量校验点里加一条“是否出现已经被列为套话的词汇”。skill 是会腐烂的模型升级后旧写法的效果会漂移所以维护不是锦上添花而是必需品。5.4 仓库是养出来的不是攒出来的最后聊一点维护心得。建这个仓库初期我疯狂追求数量一周能写 20 个 skill觉得数量越多越有成就感。后来发现很多 skill 写完就用了一次甚至一次都没用白白占着编码位还拖慢了检索质量。后来我改成“以用定建”一个 skill 如果连续三个月没被调用就进入待合并名单要么合并到相关 skill 里要么直接删除。真正让这个仓库活下来的是每周一次的小维护。周五下午我会看一遍执行日志统计哪些 skill 调用频率高哪些调用频次低。高频的 skill 重点打磨低频的果断合并。这个过程听起来无聊但坚持下来之后仓库的整体质量一直在往上走。这里还要强调一个容易被忽略的机制每个新 skill 发布前我都用固定测试输入跑一遍自检确认输出合格才会上线。自检样例必须是稳定的、预期的输出是明确的否则没法判断 skill 到底行不行。这套“新建-自检-上线-监控-迭代”的循环比任何花哨的技术架构都重要。把这个仓库做到第 100 个 skill 时我才意识到真正难的不是“怎么建”而是“怎么让它持续被用起来”。如果你也打算搭一套我的建议很朴素先挑自己业务里反复做的那三四件事把它们的流程写成 SKILL.md格式照着模板来放进一个 git 仓库跑通一条搜索到执行的 API 链路。别一上来就追求 243 个3 个能跑通的 skill 就足够改变你的工作方式了。243 是一个自然生长的结果不是一个必须达到的目标。