我给自己造了个 70 人 AI 团队
从第一个 Skill 到全链路系统，一个人的五个月
两天，15 个视频，全部剪完。就我一个人。
准确说，是一个人加一个 AI 团队。
不是粗剪。字幕校对、错误修正、章节切分、配图生成、标题优化，每个环节都过了一遍。
这是上个月的真实数据。那段时间我在密集产出一批教学视频，内容本身花了很长时间打磨，每个知识点都经过实际验证，有些用法连官方文档都没写过，我自己测通了才敢教。内容急不来。
但剪辑可以快。这个 AI 团队里跑着 70 多个 Skill。这篇文章讲的就是它们。
Claude Skills 是用英语写的程序
这不是比喻。一个 Skill 就是一份纯文本文件，里面写着你希望 AI 怎么工作、遵守什么规则、产出什么结果。不需要 Python，不需要 IDE，不需要任何编程经验。你只需要会描述自己的工作方式。
2025 年 10 月 Claude 正式推出 Skills 功能。我在第一周就写了第一个 Skill，用来校对视频字幕。五个月后，70 多个 Skill 分布在六条链路上：
从选题到发布的完整链条，覆盖视频、Newsletter、推文、字幕、后期
配图、图表、B-roll 动画、品牌视觉，所有视觉产出都走这条线
信息采集、结构化、推送到笔记系统的自动闭环
产品定位、商业决策、社群运营
Skill 的创建、测试、同步、协作，都有专门的 Skill 在管
翻译、语音合成、文档处理
但数字不是重点。重点是这 70 多个 Skill 之间的关系。
它们不是一夜之间冒出来的，也不是为了凑数。刚开始用 Skills 的时候，每个 Skill 都是独立的。写一个解决一个问题，跟其他 Skill 没有任何关系。后来 Skill 多了，它们开始共享状态，一个 Skill 的输出变成另一个的输入。再后来，Skill 开始调度 Skill，系统自己决定该调用谁、按什么顺序执行。
这三个阶段，就是从"写脚本"到"建系统"的过程。下面用三个案例来说明。
一个 Skill 解决一个问题
录完一条视频，最烦的不是剪辑，是字幕校对。
AI 转录出来的字幕错误率不低。专业术语基本全错，人名、产品名经常变成同音字，断句位置也不一定对。每条视频手动校对一两个小时，枯燥、重复，还容易漏。
我的第一个 Skill 就是解决这件事。把校对规则写成一份文本文件，告诉 AI 怎么对照参考文档修正术语、统一人名、调整断句。一次校对从一两个小时变成几分钟审阅。
没什么花哨的。一个输入，一个输出，解决一个具体问题。但它让我意识到一件事：任何你每周重复做的工作，只要你能把规则写清楚，就可以变成 Skill。
字幕解决了。然后是字幕转文章。然后是标题优化、描述生成、封面配图。单个 Skill 越积越多，问题也随之而来：它们之间完全独立，没有任何协作。
多个 Skill 共享状态
用 AI 写内容的人都有一个共同体验：生成的文字读起来"正确但没有灵魂"。
更麻烦的是"不统一"。我的系统里有 9 个创作类 Skill，分别负责 Newsletter、视频脚本、推文、文章评审等不同场景。我在 Newsletter Skill 里调了一下午的语气，改到满意了。结果切到推文 Skill，又是一股标准 AI 味。每个 Skill 各写各的，风格参差不齐。
后来我换了个思路，建了一个独立的风格学习 Skill。它只做一件事：从我的手动修改中提取偏好，持续更新一份共享的风格档案。这份档案覆盖思维方式、句式偏好、表达红线，所有创作类 Skill 读同一份。
每次我在任何一个 Skill 的输出上改一句话，风格学习 Skill 就从修改中提取信号，更新档案。下一次，9 个 Skill 的输出风格都会更接近。不是"变好了"，是终于统一了。
Skill 不再各自为政，它们有了共享记忆。
风格统一了，但每次还得手动一个一个触发。Skill 多了之后，光是记住该用哪个、按什么顺序跑，本身就成了体力活。
Skill 调度 Skill
回到开头那个数字。两天剪完 15 个视频，背后跑的不是一个 Skill，是一条流水线。
字幕 Skill 先自动校对转录错误。HighlightCut 根据字幕内容识别章节边界，辅助粗剪。后期 Skill 串联五个环节，一条命令完成从字幕校对到封面生成的全部后期工作。配图 Skill 为每个视频生成课程 PPT 和缩略图。
每个 Skill 各管一个环节，但它们之间有明确的上下游关系：上一个的输出是下一个的输入。我要做的只有两件事：在关键节点审阅质量，和做最终的发布决策。
这就是为什么内容可以花很长时间打磨，而剪辑可以两天搞定。人负责判断，系统负责执行。
这套系统有一个总入口。你告诉它要做什么，它自己判断该调哪些 Skill、按什么顺序跑。一个人运营 YouTube 频道、Newsletter、X、课程、精英圈社群，同时还在写一本书。如果按传统方式，编辑、设计、剪辑、运营、社交媒体，每条线至少一个人，加起来就是 5 到 8 人的团队。
我没有团队。但我有 70 多个各司其职的 Skill。它们共享记忆，互相协作，有调度中心，有质量控制。
我把自己的判断力复制了 70 份，每份专精一件事。
但这还只是同一个 AI 的编排。如果不同的 AI 可以互相补位呢？
延伸：AI 调度 AI
如果说系统总入口是 Skill 调度 Skill，那 ai-pair 就是 AI 调度 AI。
ai-pair 是我的结对协作 Skill。它能组建一个异构 AI 团队：Claude 负责创作，OpenAI Codex 负责审查逻辑和事实，Google Gemini 负责审查可读性和风格。三个不同公司的 AI 模型，在同一个工作流里各司其职，互相审阅对方的输出。
你现在看到的这篇文章，就是用这种多 AI 协作模式完成初稿审阅的。
前段时间独立开发者 Peter Steinberger 发布了 OpenClaw，一个 7x24 小时常驻运行的开源个人 AI Agent，GitHub 星数突破 22 万。不少人觉得惊艳。说实话，我的感受不太一样。不是因为它不好，而是因为我已经在用 Claude Code 编排多个 AI 协作了。真正让我兴奋的从来不是某个模型有多强，而是不同模型之间可以互相补位，形成比单一模型更可靠的系统。
这套系统中有不少组件已经开源。下面是部分已开源工具的实际使用反馈：
踩坑与失败
不是每个 Skill 都活了下来
70 多个 Skill 是现在的数字。真实的数字比这更大，因为有些 Skill 已经被淘汰了。
坑 1：两个 Skill 做同一件事
早期我做了一个专门生成 Newsletter B 版的 Skill，和一个主 Newsletter Skill 并行跑。两个 Skill 各管一种格式，听起来分工明确。但实际维护时发现，改一个就得同步改另一个，改着改着两边就不一致了。最终合并成一个 Skill 加模式切换，维护成本直接减半。
坑 2：一个 Skill 想管太多事
我在只有三四个视觉类 Skill 的时候就做了一个"品牌视觉统一生成器"，想一步到位管所有视觉产出。结果每次新增一个视觉 Skill，这个生成器就得跟着改，改到后来它自己变成了最大的维护负担。砍掉之后，让每个视觉 Skill 各自引用一份共享色板，反而更稳定。
系统的清晰度比 Skill 的数量重要。
你不需要 70 个 Skill
你不需要 70 个。甚至不需要 10 个。
我的第一个 Skill 是 2025 年 10 月写的，20 分钟。如果你现在开始，三个月后可能有 5 到 10 个，覆盖你最常重复的工作。这就够了。70 是五个月积累的结果，不是起步门槛。
你的第一个 Skill 该做什么？
找一件你每周至少做一次、每次花超过 30 分钟、而且你已经形成了固定套路的工作。把你的套路写成一份纯文本文件，告诉 AI 该怎么做。这就是你的第一个 Skill。
如果你不确定从哪开始，免费入门课里有具体的上手指引。
从 1 到 N 的真正难点
第一个 Skill 可能 20 分钟就写完了。但从第 1 个到第 70 个，中间差的不是时间，是一套设计系统的方法。哪些能力该独立成 Skill，哪些该合并？Skill 之间怎么传递信息？风格怎么统一？质量怎么控制？
这些问题背后是一个更大的命题：不是"怎么写 Skill"，而是"怎么设计一个 AI 协作系统"。
MAPS 框架如何指导 Skill 设计
这套体系的设计方法论是 MAPS 四维罗盘：Mindset（心智）决定你怎么看待人机分工，Architecture（架构）决定 Skill 之间怎么协作，Prompt（提示词）决定单个 Skill 的输出质量，Systems（系统）让整套体系可监控、可回顾、可扩展。
不是教你用某个工具，而是教你怎么设计自己的系统。
下一步
第一个 Skill 可能只要 20 分钟。但第 70 个背后那套设计体系，才是真正的竞争力。
常见问题
Claude Skills 是什么？和 ChatGPT 的 GPTs 有什么区别？
Claude Skills 是 Anthropic 在 2025 年 10 月为 Claude 推出的能力扩展机制。一个 Skill 是一份纯文本文件（SKILL.md），用自然语言定义 AI 的工作方式、规则和输出标准。不需要编程，用英语（或中文）描述即可。
Claude Skills 和 Prompt 有什么区别？为什么不直接用 Prompt？
Prompt 是一次性的对话指令。Skill 是持久化的能力定义，可以被反复调用，可以引用外部文件，可以和其他 Skill 协作。类比的话，Prompt 是口头吩咐，Skill 是写成文档的标准作业流程。
Claude Skills 和 MCP 有什么关系？需要同时用吗？
Skills 定义的是 AI "怎么工作"，MCP（Model Context Protocol）解决的是 AI "能连接什么"。一个 Skill 可能会调用 MCP 来读写 Notion、操作 GitHub、查询数据库，但 Skill 本身是工作流程的定义，MCP 是外部工具的连接协议。两者互补，不是替代关系。
不会编程也能用 Claude Skills 吗？
可以。Skill 的本体是纯文本，用自然语言写。但如果你有编程基础，可以让 Skill 调用脚本、操作文件系统、连接外部 API，能力上限会高很多。
Claude Skills 免费吗？需要订阅 Claude Pro 吗？
Skills 功能包含在 Claude Pro（$20/月）和 Team/Enterprise 订阅中。免费版 Claude 不支持自定义 Skills。写 Skill 本身不额外收费，但运行 Skill 会消耗你的对话额度。
70+ Skills 是怎么积累起来的？需要多长时间？
不是一口气写完的。每解决一个真实的工作痛点，就自然产生一个新 Skill。而且 Skill 之间可以复用组件，比如风格档案被 9 个 Skill 共享，字幕处理模块被多个后期 Skill 调用。系统越成熟，新 Skill 的创建速度越快。从第一个到 70+，我用了五个月。
哪些 Skill 是开源的？在哪里可以下载？
目前已开源的包括 Obsidian 绘图三件套、Smart Illustrator（智能配图）、AI 圆桌（多 AI 协作）、Verbatim Flow（语音输入法）等。开源项目发布在 GitHub 上。
免责声明