一只阿木木

Claude Code Skills 完全指南9:从个人工具到组织知识资产

团队级 Skill 系统:从个人工具到组织知识资产

这是「Claude Code Skills 完全指南」系列的第九篇。建议先阅读前八篇再继续。


写在前面

前八篇文章教你成为了一个优秀的个人 Skill 使用者。你知道怎么设计、构建、编排、管理 Skills——但所有这些能力都局限在你一个人身上。

然后你入职了新公司,或者换了一个团队。你精心构建的 Skills 散落在你个人的 ~/.claude/skills/ 目录里。新团队的同事还在每次会话手动告诉 Claude 公司的编码规范。你的另一个同事花了两周构建了一个和你几乎一模一样的代码审查 Skill——因为他不知道你已经做了一个。

这是 Skills 生态系统中最大的未解之谜:如果 Skill 是封装了人类专业知识的知识资产,为什么它只能帮助一个人?

如果一个过程依赖于部落知识,为什么不编码一次让每个人(人类和 AI)都受益?

这篇文章探讨的不是"如何写更好的 Skill"——你已经知道了。它探讨的是:如何将个人 Skills 变成团队知识资产,如何通过 Plugins 和 Marketplaces 跨项目分发,以及如何建立一个让整个组织都受益的 Skill 治理体系。


一、为什么 Skill 天然是组织级资产?

1.1 从个人提示到组织标准

管理员可以将 Skills 分配给群组,定义谁可以发布或修改它们,并保持部署可审计——这样工作流可以规模化而不会陷入混乱。这解决了一个常见的阻碍:碎片化的、逐人管理的提示。

这一句话点明了团队级 Skill 系统的核心价值。在没有 Skills 的世界里,每个团队成员都在各自维护自己的提示词——编码规范、审查清单、部署流程——每个人的版本略有不同,没有人知道谁的版本是最新的。

非技术领域的负责人可以写出包含示例和清单的优质 SKILL.md。工程师只在需要辅助脚本或工具粘合时才介入。认知转变是从"写代码"到"写规格"。

1.2 Skill 的三个位置层级

Claude Code 的 Skill 系统从一开始就设计了多层级架构:

text

层级 1:个人 Skills(~/.claude/skills/)
  ├── 只对你有效
  ├── 个人偏好、工作习惯
  └── 不会随 git 共享

层级 2:项目 Skills(.claude/skills/)
  ├── 提交到 git,团队共享
  ├── 项目特定的规范和工作流
  └── 新成员 clone 仓库即获得

层级 3:组织 Skills(通过 Plugins / Marketplace 分发)
  ├── 跨项目、跨团队复用
  ├── 管理员集中管理
  └── 版本控制和自动更新

组织可以建立共享的 CLAUDE.md 文件和自定义斜杠命令,编码公司特定的编码标准、架构模式和开发工作流,确保团队和项目之间的一致性。

大多数团队在层级 2 就停下来了。但真正的价值在层级 3——它需要 Plugin 系统和 Marketplace 的支持。


二、项目级共享:最快的起步方式

2.1 用 git 共享 Skill

最简单的团队共享方式不需要任何额外基础设施。

将 Skill 目录存储在 Git 中以获得历史追踪、通过 Pull Request 进行代码审查和回滚能力。每个 Skill 目录(包含 SKILL.md 和任何捆绑文件)自然映射到 Git 跟踪的文件夹。

text

your-project/
├── .claude/
│   ├── skills/
│   │   ├── code-review/
│   │   │   ├── SKILL.md
│   │   │   └── references/
│   │   │       └── security-checklist.md
│   │   ├── api-conventions/
│   │   │   ├── SKILL.md
│   │   │   └── references/
│   │   │       └── rest-standards.md
│   │   └── commit-format/
│   │       └── SKILL.md
│   ├── agents/
│   │   └── code-reviewer.md
│   └── settings.json          # Hooks 配置
├── CLAUDE.md
└── src/

当新成员 git clone 你的仓库时,他们自动获得所有 Skills、Agents 和 Hooks 配置。不需要额外安装、不需要手动复制。

2.2 Skill 的 PR 审查流程

像对待代码一样对待 Skills。

要求 Skill 作者提交包含 3-5 个代表性查询的评测套件,涵盖 Skill 应该触发、不应该触发和模糊边界的情况。要求跨组织使用的模型(Haiku、Sonnet、Opus)进行测试,因为 Skill 效果因模型而异。

一个 Skill 的 PR 审查清单:

Markdown

## Skill PR 审查清单

### 基础检查
- [ ] SKILL.md 存在且 frontmatter 格式正确
- [ ] Description 使用指令式语态(ALWAYS invoke...)
- [ ] Description 包含负面边界(Do NOT use for...)
- [ ] SKILL.md 正文 < 500 行

### 测试
- [ ] 附带 3-5 个应触发的测试提示
- [ ] 附带 2-3 个不应触发的测试提示
- [ ] A/B 基线测试结果:Skill 版本胜率 ≥ 70%

### 安全
- [ ] 没有硬编码的凭证或 API 密钥
- [ ] 脚本没有执行危险操作(rm -rf、network calls)
- [ ] 没有将数据发送到外部 URL

在部署任何来自第三方或内部贡献者的 Skill 之前,完成以下步骤:阅读所有 Skill 目录内容。恶意 Skill 可以指示 Claude 执行任意代码、访问敏感文件或向外传输数据。对待 Skill 安装要像对待在生产系统上安装软件一样严格。

2.3 MCP 配置的团队共享

我们建议由一个中心团队配置 MCP 服务器,并将 .mcp.json 配置检入代码库,这样所有用户都能受益。

MCP 配置和 Skills 一样,应该提交到 git 并通过 PR 审查管理。一个团队统一的 .mcp.json 确保每个成员都有相同的外部工具访问权限。


三、Plugin 系统:跨项目分发

3.1 为什么需要 Plugin?

项目级共享有一个致命局限:Skills 被锁在单个仓库里。 如果你的团队有 10 个微服务仓库,同一个代码审查 Skill 需要在 10 个仓库里各复制一份。更新时需要同步 10 次。

一旦你构建了一套可靠的 Skills 或 Agents,将它们打包成 Plugin,这样你的团队可以跨不同仓库安装和使用,无需到处复制粘贴文件。

Skills 是斜杠命令。可复用的带工具访问的提示,运行在你的对话中。Plugins 将 Skills、Agents、Hooks 和 MCP 服务器打包在一起,配合一个 plugin.json。

Plugins 解决了分发问题:你安装一次,获得所有东西,并与团队共享。

3.2 Plugin 的完整结构

创建自定义 plugins 来扩展 Claude Code 的 skills、agents、hooks 和 MCP 服务器。Plugins 让你用可以在项目和团队之间共享的自定义功能来扩展 Claude Code。

一个 Plugin 的完整目录结构:

text

my-team-plugin/
├── .claude-plugin/
│   └── plugin.json            # 插件元数据(必需)
├── skills/
│   ├── code-review/
│   │   ├── SKILL.md
│   │   └── references/
│   │       └── security-checklist.md
│   ├── api-conventions/
│   │   └── SKILL.md
│   └── commit-format/
│       └── SKILL.md
├── agents/
│   └── code-reviewer.md
├── hooks/
│   └── hooks.json
└── README.md

常见错误:不要把 commands/、agents/、skills/ 或 hooks/ 放在 .claude-plugin/ 目录里面。只有 plugin.json 放在 .claude-plugin/ 里。所有其他目录必须在插件根级别。

3.3 从项目 Skills 迁移到 Plugin

从 .claude/ 中的独立配置开始用于个人使用和快速实验。当配置被证明有用并且你想分享时,转换为 Plugin。迁移很简单:将文件复制到 Plugin 目录并添加 plugin.json 清单。

迁移步骤:

Bash

# 1. 创建 Plugin 目录
mkdir -p my-team-plugin/.claude-plugin

# 2. 从项目中复制 Skills
cp -r .claude/skills my-team-plugin/

# 3. 复制 Agents
cp -r .claude/agents my-team-plugin/

# 4. 创建 plugin.json
cat > my-team-plugin/.claude-plugin/plugin.json << 'EOF'
{
  "name": "my-team-tools",
  "description": "Standard tools for our engineering team",
  "version": "1.0.0",
  "author": {
    "name": "Engineering Team"
  }
}
EOF

# 5. 创建 hooks(从 settings.json 复制格式)
mkdir my-team-plugin/hooks
# 将 .claude/settings.json 中的 hooks 对象复制到 hooks/hooks.json

# 6. 测试
claude --plugin-dir ./my-team-plugin

在你修改 Plugin 时,运行 /reload-plugins 来接收更新而无需重启。

3.4 Skill vs Plugin:何时升级?

如果你刚开始,Skills 是更容易的入口。当你需要将多个组件打包在一起或随命令一起分发 Agents 时,就是使用 Plugin 的时候了。

text

使用独立 Skills:
  ✅ 个人工作流和快速实验
  ✅ 单个项目的特定需求
  ✅ 你在探索什么有效

升级到 Plugin:
  ✅ 需要跨多个仓库共享
  ✅ Skills + Agents + Hooks 需要一起工作
  ✅ 团队需要统一安装和更新
  ✅ 需要版本控制和发布管理


四、Marketplace:规模化分发

4.1 什么是 Plugin Marketplace?

Plugin Marketplace 是一个目录,让你向他人分发 Plugins。Marketplace 提供集中发现、版本追踪、自动更新,以及支持多种源类型(git 仓库、本地路径等)。本指南展示如何创建你自己的 Marketplace 来与团队或社区分享 Plugins。

4.2 团队内部 Marketplace

一个 GitHub 仓库,Claude Code 和 Cowork 都知道如何读取。

创建团队内部 Marketplace 的最小步骤:

Bash

# 1. 创建 Marketplace 仓库结构
mkdir -p my-team-marketplace/.claude-plugin
mkdir -p my-team-marketplace/plugins/code-standards/.claude-plugin
mkdir -p my-team-marketplace/plugins/code-standards/skills/code-review

# 2. 创建 Marketplace 清单
cat > my-team-marketplace/.claude-plugin/plugin.json << 'EOF'
{
  "name": "team-engineering-marketplace",
  "description": "Engineering team standard tools",
  "marketplace": true,
  "owner": {
    "name": "Engineering Team",
    "email": "[email protected]"
  },
  "plugins": [
    {
      "name": "code-standards",
      "source": "./plugins/code-standards",
      "description": "Company coding standards and review tools",
      "version": "1.0.0"
    }
  ]
}
EOF

# 3. 添加 Skills 到 Plugin 中
# ... 复制 SKILL.md 和相关文件

# 4. 推送到 GitHub(私有仓库)
git init && git add . && git commit -m "Initial marketplace"
git remote add origin [email protected]:your-org/claude-plugins.git
git push -u origin main

4.3 团队自动安装配置

通过在项目中添加 .claude/settings.json 来配置团队项目的自动 Marketplace 安装。当团队成员信任仓库文件夹时,Claude Code 自动安装 Marketplace。

JSON

{
  "extraKnownMarketplaces": {
    "team-engineering-marketplace": {
      "source": {
        "source": "github",
        "repo": "your-org/claude-plugins"
      }
    }
  },
  "enabledPlugins": {
    "code-standards@team-engineering-marketplace": true
  }
}

将这个文件检入到每个项目仓库的 .claude/settings.json 中。新成员 clone 仓库后,Claude Code 会自动提示安装团队的 Marketplace 和 Plugins。

跨团队共享 Skills 的能力——安装一次,通过 GitHub 随处更新。

4.4 企业级 Private Marketplace

Claude 通过对话式问答流程引导管理员定义 Plugin 应该具备的 Skills、应该响应的斜杠命令和需要的连接器。生成的 Plugin 是组织完全拥有的可移植文件系统。管理员还可以从私有 GitHub 仓库获取 Plugins。这意味着公司的内部开发团队可以在私有仓库中编写和版本化 Plugins,并发布到内部 Marketplace,而无需通过 Anthropic 的基础设施路由代码。这一区别对 IP 敏感的组织和受监管行业中有数据驻留和代码治理合规要求的组织非常重要。

一旦 Plugins 在 Marketplace 中,管理员可以使用按用户配置来控制哪些员工有访问权限,通过自动安装将 Plugins 自动推送给特定团队,并限制可见性,让每个团队只看到与其职能相关的 Plugins。


五、组织治理:安全、审计、合规

5.1 安全审查框架

本指南适用于需要在组织中治理 Agent Skills 的企业管理员和架构师。它涵盖如何审查、评估、部署和大规模管理 Skills。

Skills 如果触发错误、与其他 Skills 冲突或提供低质量指令,可能会降低 Agent 性能。在任何生产部署前都需要评估。

Anthropic 官方的企业 Skill 审查清单涵盖四个维度:

维度 1:安全

完整性验证:计算审查过的 Skills 的校验和,并在部署时验证。在 Skill 仓库中使用签名提交以确保来源可信。

维度 2:质量

生产环境:将 Skills 固定到特定版本。在提升新版本之前运行完整评测套件。将每次更新视为需要完整安全审查的新部署。

维度 3:分发

为每个 Skill 维护一个内部注册表,包含每个基于角色的捆绑包只应包含与该角色日常工作流相关的 Skills。

维度 4:跨平台

自定义 Skills 不会在不同界面之间同步。通过 API 上传的 Skills 在 claude.ai 或 Claude Code 中不可用,反之亦然。每个界面需要单独上传和管理。将 Git 中的 Skill 源文件维护为单一事实来源。如果你的组织跨多个界面部署 Skills,需要实现自己的同步流程以保持一致。

5.2 治理工作流

安全/政策制定者:定义代码运行 Skills 的审批路径、数据类别约束、Skill 加载/执行的审计跟踪,以及提示注入检查清单。

一个完整的治理工作流:

text

Skill 作者提交 PR
       ↓
技术审查(代码质量 + Skill 设计原则)
       ↓
安全审查(无恶意代码 + 无数据外泄 + 无硬编码凭证)
       ↓
评测验证(触发率 ≥ 90% + A/B 胜率 ≥ 70%)
       ↓
跨模型测试(Haiku / Sonnet / Opus)
       ↓
审批 + 版本标记
       ↓
部署到 Marketplace
       ↓
自动分发到团队

定义治理:选择环境(Team/Enterprise)、发布权限和审查门控。

5.3 角色分工

工程师:发布仓库模板、CI linter 和小型辅助库。做管家——不是瓶颈。领导者:资助 Skill 目录/UX 和启用计划("SOP → Skill" 研讨会)。将 Skills 作为评审中的一等产物。

角色
职责
产出
Skill 作者
领域专家,编写 SKILL.md
新 Skill + 评测套件
Skill 审查者
资深工程师,审查设计和安全
审查意见 + 批准/拒绝
平台管理员
DevOps/平台工程,管理 Marketplace
Marketplace 配置 + 分发策略
部门负责人
识别高价值工作流
Skill 需求清单 + ROI 评估

六、开放标准:跨平台可移植性

6.1 Agent Skills 开放标准

将 Skills 作为开放标准发布是一个经过计算的战略选择。通过让 Skills 跨 AI 平台可移植,Anthropic 押注生态系统增长将比专有锁定带来更多收益。这一策略看起来正在奏效。OpenAI 已悄然在 ChatGPT 和 Codex CLI 中采用了结构相同的架构。开发者 Elias Judin 在本月早些时候发现了这一实现——目录中包含的 Skill 文件完全复刻了 Anthropic 的规范——相同的文件命名约定、相同的元数据格式、相同的目录组织。

这意味着你构建的 Skills 不只是 Claude 的资产——它们是跨平台的资产。

截至 2026 年 3 月,Claude Code Skill 生态系统包括 Anthropic 官方 Skills、经过验证的第三方 Skills,以及与通用 SKILL.md 格式兼容的数千个社区贡献 Skills。相同的 Skill 文件可在 Claude Code、Cursor、Gemini CLI、Codex CLI 和 Antigravity IDE 上运行。

6.2 对团队的意义

Anthropic 的 Agent/Skills 规范实现了跨平台 Skills,可以在 Claude 之外工作。共享的文件夹/规范格式意味着你可以构建一次 Skill,在采用该标准的任何地方运行——减少供应商锁定并加速治理审查。

这意味着你的团队 Skill 投资有三重保障:

  1. 即使换工具也不浪费——同样的 SKILL.md 在 Claude Code、Cursor、Gemini CLI 中都能用
  2. 治理只做一次——安全审查、合规检查对所有平台通用
  3. 生态系统效应——你构建的 Skills 可以贡献到开源社区,也可以从社区获取

6.3 跨平台分发

一个仓库,十一个平台。原生支持 Claude Code Plugins、Codex Agent Skills、Gemini CLI Skills,并通过 scripts/convert.sh 转换为 8 个以上工具。

如果你的团队同时使用多个 AI 编码工具,你的 Skill 仓库可以一次构建、多平台部署。


七、从零建立团队 Skill 系统的四阶段路线图

阶段 1:盘点与试点(第 1-2 周)

目标:识别高价值 Skill 候选,完成第一个团队 Skill。

为每个新团队:进行简短的需求评估以识别高价值工作流。配置席位并交付定制的入职培训。指定一位本地倡导者来推动采用并在组织内分享早期成果。

具体行动:

text

第 1 周:
  □ 调研团队中每个人私下使用的 AI 提示和工作流
  □ 识别 Top 3 重复性最高的工作流
  □ 选择 1 个最高价值的,构建第一个团队 Skill
  □ 在团队内部做 A/B 测试

第 2 周:
  □ 将 Skill 提交到项目的 .claude/skills/
  □ 建立 Skill PR 审查流程
  □ 指定一位 Skill 倡导者

阶段 2:标准化(第 3-4 周)

目标:建立 Skill 开发标准,创建 Plugin。

在你的组织中使用一致的命名约定。

text

第 3 周:
  □ 建立 Skill 命名约定(如 team-name:skill-purpose)
  □ 创建 SKILL.md 模板,包含必填字段
  □ 创建 Skill PR 审查清单
  □ 构建 3-5 个核心 Skill

第 4 周:
  □ 将所有项目级 Skills 迁移到 Plugin
  □ 创建团队 GitHub 仓库
  □ 配置 .claude/settings.json 自动安装
  □ 团队演示和培训

阶段 3:分发与治理(第 5-8 周)

目标:建立 Marketplace,实施治理流程。

text

第 5-6 周:
  □ 创建内部 Plugin Marketplace
  □ 按角色创建 Skill 捆绑包
  □ 实施安全审查流程
  □ 建立版本管理策略

第 7-8 周:
  □ 跨团队推广
  □ 收集使用反馈
  □ 迭代改进
  □ 度量采用率和效果

阶段 4:持续演进

目标:建立持续改进机制。

构建一个自定义 Skill:使用发布的规范(agentskills.io)捕获你组织的风格指南或审批清单。度量采用情况:追踪节省的任务时间、错误率和审查通过率。规模化和标准化:模板化高价值 Skills;使用基于角色的访问和版本控制来管理变更。


八、真实案例:一个工程团队的 Skill 系统

8.1 系统全貌

一位生产力倡导者描述了他的完整工具集如何协同工作:

工程总监的水平取决于他们招聘的团队。这七个 Plugins、Skills 和 MCP 服务器就是那个团队。每一个处理一项特定工作——从功能架构到实时文档查询——它们一起将单个 Claude Code 会话变成了感觉像整个工程组织的东西。

一个结构良好的 CLAUDE.md 是让所有这些工具有效运作的基础。

8.2 Partner Skills 生态

Anthropic 与十家合作伙伴一起发布 Skills,这些合作伙伴阵容读起来就像现代企业软件的名人录。Atlassian(制造 Jira 和 Confluence)、设计工具 Figma 和 Canva、支付基础设施公司 Stripe、以及自动化平台 Zapier 的存在,表明 Anthropic 将 Skills 定位为 Claude 与企业已在使用的应用之间的连接组织。

从目录开始:安装一小组 Skills(如用于 PRD 的 Notion、用于品牌资产的 Canva)并将它们映射到现有工作流。

8.3 关键洞察:Plugin 是可移植的

Plugins 是简单的、可移植的文件系统,你完全拥有。它们跨 Cowork 和基于 Claude Agent SDK 构建的任何东西工作,使得创建跨团队和与行业专家共享的私有 Plugin Marketplace 变得容易。


九、度量:如何证明 Skill 系统的价值

9.1 关键指标

Anthropic 自己的内部研究表明,其工程师在 60% 的工作中使用 Claude,实现了 50% 的自我报告生产力提升——比上一年提高了两到三倍。值得注意的是,27% 的 Claude 辅助工作由原本不会完成的任务组成,包括构建内部工具、创建文档和解决员工所说的"纸屑"问题——小的生活质量改进,一直被无限期推迟。

你的团队可以追踪的指标:

指标
怎么测量
目标
Skill 采用率
团队中使用 Skills 的成员百分比
> 80%
触发率
Skill 在应该触发时实际触发的频率
> 90%
手动纠正率
团队成员需要纠正 Claude 的频率变化
减少 40%+
任务完成时间
标准工作流(如代码审查)的时间对比
减少 30%+
Skill 库增长率
每月新增的 Skills 数量
稳定增长
知识复用率
新 Skill 引用已有 Skills 的频率
递增

9.2 OpenTelemetry 集成

此外,我们还添加了 OpenTelemetry 支持,让管理员追踪团队的使用量、成本和工具活动。

将实时 Claude Code 指标导出到你的可观测性堆栈中。追踪会话活动、token 使用和成本,无需构建自定义集成。


十、常见误区

误区 1:「每个人都应该自己写 Skill」

不。Skill 应该由最了解该工作流的领域专家编写,然后通过 Plugin 分发给所有人。就像你不会让每个开发者自己写 CI/CD 配置一样。

误区 2:「把所有 Skill 放到一个大 Plugin 里」

每个基于角色的捆绑包只应包含与该角色日常工作流相关的 Skills。

前端开发者不需要数据库迁移 Skill,后端开发者不需要 Figma 设计 Skill。按角色分包,而不是一个包含所有东西的巨型 Plugin。

误区 3:「Marketplace 搭好就不用管了」

一次失败的 GitHub 同步可能会临时从你的 Marketplace 中移除 Plugins。

Marketplace 需要持续维护:版本更新、安全审查、过时 Skill 退役、新需求响应。指定专人负责。

误区 4:「安全审查太重了,我们是小团队」

恶意 Skill 可以指示 Claude 执行任意代码、访问敏感文件或向外传输数据。

即使是小团队,最基础的安全检查(阅读 SKILL.md 全文 + 检查脚本)也是必须的。这不是官僚主义,这是防御恶意 Skill 注入的底线。


十一、你今天就应该做的 3 件事

✅ 行动 1:把你最好的 Skill 提交到项目 git

打开你的 ~/.claude/skills/ 目录,选出你使用频率最高、效果最好的 1-2 个 Skill。将它们复制到当前项目的 .claude/skills/ 目录中,提交一个 PR。

✅ 行动 2:和团队做一次 Skill 盘点

花 30 分钟组织一次团队会议。每个人分享:

  • 你在和 Claude 对话时重复最多的 3 件事是什么?
  • 你有没有私下构建的提示或 Skill?
  • 你觉得什么工作流最适合 Skill 化?

这个会议的产出就是你的团队 Skill 路线图。

✅ 行动 3:创建第一个 Plugin

选择团队盘点中最高共识的 1 个工作流,把它构建成 Plugin。推送到团队的 GitHub 仓库。配置 .claude/settings.json 让团队成员自动安装。

如果你刚开始,Skills 是更容易的入口。当你需要将多个组件打包在一起或分发 Agents 配合命令时,就是使用 Plugin 的时候了。


本文的知识框架总结

text

团队级 Skill 系统
│
├── 三个层级
│   ├── 个人 Skills(~/.claude/skills/)
│   ├── 项目 Skills(.claude/skills/ → git 共享)
│   └── 组织 Skills(Plugins + Marketplace)
│
├── 分发机制
│   ├── Git 共享(最简单,单仓库内)
│   ├── Plugin(跨仓库,打包分发)
│   └── Marketplace(规模化,集中管理)
│
├── 治理体系
│   ├── PR 审查流程(安全 + 质量 + 评测)
│   ├── 版本管理(固定版本 + 升级审查)
│   ├── 角色分工(作者 / 审查者 / 管理员 / 负责人)
│   └── 度量体系(采用率 + 触发率 + 任务时间)
│
├── 开放标准
│   ├── SKILL.md 格式跨 5+ 平台通用
│   ├── OpenAI 已采用相同架构
│   └── 构建一次,到处运行
│
├── 四阶段路线图
│   ├── 1. 盘点与试点(1-2 周)
│   ├── 2. 标准化(3-4 周)
│   ├── 3. 分发与治理(5-8 周)
│   └── 4. 持续演进
│
└── 核心原则
    ├── 编码一次,让所有人受益
    ├── 像管理代码一样管理 Skills
    ├── 按角色分包,不是一个大 Plugin
    └── 安全审查是底线,不是可选项

下一篇预告

九篇文章走下来,你已经掌握了从个人 Skill 设计到团队级系统建设的完整知识体系。

最后一篇将回到最高处——把所有碎片拼在一起。

第 10 篇是整个系列的终章和全景图:2026 年 AI Agent 工具链的终极指南。它将统一前九篇的所有概念,给出一个完整的心智地图,并回答一个根本性问题:在 AI Agent 快速演进的 2026 年,什么才是真正持久的知识?


本文是「Claude Code Skills 完全指南」系列的第 9 篇,共 10 篇。全系列目录:

#
标题
核心问题
1
Skill 的本质
一个 Markdown 文件如何改变 AI 行为?
2
Description 设计的科学
为什么你的 Skill 永远不触发?
3
从零构建一个生产级 Skill
三种设计模式怎么选?
4
五种架构模式
Skill 的内容应该怎么组织?
5
Context Engineering
如何管理 Claude 最稀缺的资源?
6
编排模式完全指南
多 Skill 如何协同工作?
7
知识管理系统
如何构建可复利增长的项目上下文?
8
Workflow vs Agent vs Skill
什么时候该用什么?
→ 9团队级 Skill 系统从个人工具到组织知识资产
10
全景图
2026 年 AI Agent 工具链的终极指南

📞 AI+obsidian 读书与知识管理星球

请点击了解详情 →

Image
Obsidian+AI第二大脑(付费)
Obsidian+AI第二大脑
Obsidian+AI工作流
Obsidian+AI工作流
Obsidian+AI 读书卡片合集系列
读书卡片合集
   Obsidian+AI 知识管理合集系列
Obsidian+AI知识管理
   Obsidian 数字人生
Obsidian数字人生
 AI + Obsidian 效率革命
AI + Obsidian 效率革命
AI 重建知识系统
Obsidian × AI 重建知识系统
Claude Code Skills 完全指南
Claude Code Skills 完全指南

 AII

Image

松花酿酒,春水煎茶。

眉上风止,见字如晤。

一只阿木木