一个人加 70 个 Claude Skill：AI 团队两天剪完 15 个视频的完整体系

一句话结论

五个月、70+ Claude Skills、六条链路。从第一个字幕校对 Skill（20 分钟搭建，校对时间从 1 小时降到几分钟），到 9 个创作 Skill 共享风格档案实现输出统一，再到 Skill 调度 Skill 的全自动流水线（两天剪完 15 个视频）。核心方法论：不是”怎么写 Skill”，而是”怎么设计一个 AI 协作系统”。

两天，15 个视频，全部剪完

就一个人。准确说，是一个人加一个 AI 团队。

不是粗剪。字幕校对、错误修正、章节切分、配图生成、标题优化，每个环节都过了一遍。

这是真实数据。那段时间作者在密集产出一批教学视频，内容本身花了很长时间打磨，每个知识点都经过实际验证，有些用法连官方文档都没写过，自己测通了才敢教。内容急不来，但剪辑可以快。这个 AI 团队里跑着 70 多个 Skill。

Claude Skills 是用英语写的程序

这不是比喻。一个 Skill 就是一份纯文本文件，写着你希望 AI 怎么工作、遵守什么规则、产出什么结果。不需要 Python，不需要 IDE，不需要任何编程经验，只需要会描述自己的工作方式。

2025 年 10 月 Claude 正式推出 Skills 功能。作者在第一周就写了第一个 Skill，用来校对视频字幕。五个月后，70 多个 Skill 分布在六条链路上：内容创作（28 个）、视觉与设计（14 个）、知识管理（7 个）、商业运营（6 个）、开发者基建（13 个）、工具类（6 个）。

但数字不是重点。重点是这 70 多个 Skill 之间的关系：从独立的单点工具，到共享状态、互相协作，再到系统自己决定调用顺序——这是从”写脚本”到”建系统”的过程。

阶段一：单点突破

录完一条视频，最烦的不是剪辑，是字幕校对。

AI 转录出来的字幕错误率不低：专业术语基本全错，人名、产品名经常变成同音字，断句位置也不一定对。每条视频手动校对一两个小时，枯燥、重复、还容易漏。

第一个 Skill 就是解决这件事：把校对规则写成一份文本文件，告诉 AI 怎么对照参考文档修正术语、统一人名、调整断句。一次校对从一两个小时变成几分钟审阅。

没什么花哨的。一个输入，一个输出，解决一个具体问题。但它带来一个关键认知：任何你每周重复做的工作，只要你能把规则写清楚，就可以变成 Skill。

字幕解决了，然后是字幕转文章、标题优化、描述生成、封面配图。单个 Skill 越积越多，问题随之而来：它们之间完全独立，没有任何协作。

阶段二：共享记忆

用 AI 写内容的人都有一个共同体验：生成的文字读起来”正确但没有灵魂”。更麻烦的是”不统一”。系统里有 9 个创作类 Skill，分别负责 Newsletter、视频脚本、推文、文章评审等不同场景。在 Newsletter Skill 里调了一下午的语气，改到满意了，切到推文 Skill，又是一股标准 AI 味。

后来换了个思路：建一个独立的风格学习 Skill。它只做一件事：从手动修改中提取偏好，持续更新一份共享的风格档案。每次在任何一个 Skill 的输出上改一句话，风格学习 Skill 就从修改中提取信号更新档案。下一次，9 个 Skill 的输出风格都会更接近。不是”变好了”，是终于统一了。

Skill 不再各自为政，它们有了共享记忆。

风格统一了，但每次还得手动一个一个触发。Skill 多了之后，光是记住该用哪个、按什么顺序跑，本身就成了体力活。

阶段三：系统自运转

回到开头那个数字。两天剪完 15 个视频，背后跑的不是一个 Skill，是一条流水线。

字幕 Skill 先自动校对转录错误。HighlightCut 根据字幕内容识别章节边界，辅助粗剪。后期 Skill 串联五个环节，一条命令完成从字幕校对到封面生成的全部后期工作。配图 Skill 为每个视频生成课程 PPT 和缩略图。

每个 Skill 各管一个环节，但它们之间有明确的上下游关系：上一个的输出是下一个的输入。人要做的只有两件事：在关键节点审阅质量，和做最终的发布决策。

这就是为什么内容可以花很长时间打磨，而剪辑可以两天搞定。人负责判断，系统负责执行。

这套系统有一个总入口。告诉它要做什么，它自己判断该调哪些 Skill、按什么顺序跑。一个人运营 YouTube 频道、Newsletter、X、课程、精英圈社群，同时还在写一本书。如果按传统方式，编辑、设计、剪辑、运营、社交媒体，每条线至少一个人，加起来是 5 到 8 人的团队。而现在：没有团队，但有 70 多个各司其职的 Skill——共享记忆、互相协作、有调度中心、有质量控制。作者把自己的判断力复制了 70 份，每份专精一件事。

延伸：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 已经被淘汰。

举两个例子：

重复建设：早期做了一个专门生成 Newsletter B 版的 Skill，和主 Newsletter Skill 并行跑。两个 Skill 各管一种格式，听起来分工明确。但实际维护时发现，改一个就得同步改另一个，改着改着两边就不一致了。最终合并成一个 Skill 加模式切换，维护成本直接减半。

过早抽象：在只有三四个视觉类 Skill 的时候就做了「品牌视觉统一生成器」，想一步到位管所有视觉产出。结果每次新增一个技能都要跟着改生成器，改到后来它自己变成了最大的维护负担。砍掉之后，让每个视觉 Skill 各自引用一份共享色板，反而更稳定。

一个是「两个 Skill 做同一件事」，一个是「一个 Skill 泆管太多事」。踩坑的共同教训：系统的清晰度比 Skill 的数量重要。

你的第一个 Skill 该做什么

你不需要 70 个 Skill，甚至不需要 10 个。第一个 Skill 是 2025 年 10 月写的，20 分钟。如果现在开始，三个月后可能有 5 到 10 个，覆盖最常重复的工作，这就够了。70 是五个月积累的结果，不是起步门槛。

找一件每周至少做一次、每次花超过 30 分钟、而且已经形成了固定套路的工作。把套路写成一份纯文本文件，告诉 AI 该怎么做。这就是你的第一个 Skill。

从第 1 个到第 70 个，中间差的不是时间，是一套设计系统的方法：哪些能力该独立成 Skill，哪些该合并？Skill 之间怎么传递信息？风格怎么统一？质量怎么控制？

这些问题背后是一个更大的命题：不是”怎么写 Skill”，而是”怎么设计一个 AI 协作系统”。这套体系可以用 MAPS 四维罗盘概括：Mindset（心智）决定你怎么看待人机分工，Architecture（架构）决定 Skill 之间怎么协作，Prompt（提示词）决定单个 Skill 的输出质量，Systems（系统）让整套体系可监控、可回顾、可扩展。

第一个 Skill 可能只要 20 分钟。但第 70 个背后那套设计体系，才是真正的竞争力。

原文信息

作者：Axton Liu（@AxtonLiu），AI 实践者

原文地址：