dev-skill仓库全景：一套技能体系如何把AI Coding变成团队基础设施

如果说 Skill 是 AI Coding 的“能力单元”，那 dev-skill 更像一套把这些能力单元组织起来、分发出去、持续治理的基础设施。

它解决的不是“能不能写一个 skill”，而是更工程化的问题：

skill 写完以后，怎么统一安装到多个工具里
同一个能力在不同 IDE 里怎么保持一致
谁来维护 skill，谁来追踪使用情况
某个工作流跑顺了以后，怎么沉淀成团队资产

一句话概括：

dev-skill 不是技能合集，而是团队的 AI 能力操作系统。

一、它到底是什么

dev-skill 是一个团队内部统一的 AI 技能仓库，核心目标就两个：

把高频研发动作沉淀成 skills
支持一键分发到多个 AI 工具和工作流里

它现在覆盖的典型目标包括：

Cursor
Claude Code
Codex
OpenClaw 兼容层

这意味着你不用在每个工具里重复配一遍能力，而是可以在一个仓库里统一维护。

它在解决什么痛点

过去常见的问题是：

技能散落在各个项目里，维护很碎
三端重复配置，改一次要同步三次
新同学不知道该装哪些能力
排障、开发、CR、测试链路是断开的

dev-skill 想做的，就是把这些碎片收拢起来。

  flowchart TD
    classDef source fill:#DBEAFE,stroke:#2563EB,color:#111,stroke-width:2px;
    classDef sync fill:#DCFCE7,stroke:#16A34A,color:#111;
    classDef tool fill:#FDE68A,stroke:#D97706,color:#111;
    classDef gov fill:#FCE7F3,stroke:#DB2777,color:#111;

    A["dev-skill 仓库<br/>唯一事实来源"]:::source --> B["安装器 / 同步脚本"]:::sync
    B --> C["Cursor"]:::tool
    B --> D["Claude Code"]:::tool
    B --> E["Codex"]:::tool
    B --> F["OpenClaw"]:::tool
    A --> G["usage tracker / publish / distill"]:::gov

二、仓库结构长什么样

dev-skill 的结构不是“堆一堆 skill 文件”，而是按能力域分层。

1. 目录分层

skills/dev/：开发流程类
skills/cr/：代码审查与测试审查类
skills/writing/：文档写作与图表类
skills/zan/：Zan 工具链
skills/lark/：飞书协同能力
skills/helm/：技能治理类
skills/platform/：安装、统计、发布等平台能力

2. P0 默认安装

仓库里还专门定义了 backend-core 默认安装集，也就是团队最常用的一批技能。

这一步非常重要，因为它把“装什么”从个人偏好，变成了团队共识。

  flowchart LR
    classDef dev fill:#DBEAFE,stroke:#2563EB,color:#111;
    classDef cr fill:#FDE68A,stroke:#D97706,color:#111;
    classDef writing fill:#DCFCE7,stroke:#16A34A,color:#111;
    classDef zan fill:#E9D5FF,stroke:#7C3AED,color:#111;
    classDef lark fill:#CFFAFE,stroke:#0891B2,color:#111;
    classDef helm fill:#FCE7F3,stroke:#DB2777,color:#111;

    A["dev<br/>需求、开发、路由"]:::dev
    B["cr<br/>审查、测试、复盘"]:::cr
    C["writing<br/>方案、图表、文档"]:::writing
    D["zan<br/>日志、DB、缓存、接口"]:::zan
    E["lark<br/>飞书、文档、协作"]:::lark
    F["helm<br/>治理、发布、沉淀"]:::helm

    A --> B --> F
    C --> A
    D --> A
    E --> C
    F --> A

三、它为什么值得单独做成仓库

因为技能系统一旦做大，真正麻烦的不是“写”，而是“管”。

`dev-skill` 的核心价值

一键安装：按 profile 批量同步，不用手工拷贝
软链接管理：仓库更新即生效
技能组合：支持依赖补齐和工作流串联
可回收治理：误同步可以快速清理
跨工具统一：同一套能力在不同 AI IDE 保持一致

这就把 skill 从“散装提示词”变成了“可维护资产”。

  flowchart TD
    classDef pain fill:#FEE2E2,stroke:#DC2626,color:#111;
    classDef solve fill:#DCFCE7,stroke:#16A34A,color:#111;
    classDef result fill:#DBEAFE,stroke:#2563EB,color:#111;

    P1["痛点：分散、重复、难回收"]:::pain --> P2["统一仓库维护"]:::solve
    P2 --> P3["profile 安装"]:::solve
    P3 --> P4["软链接同步到多端"]:::result
    P4 --> P5["更新后即时生效"]:::result
    P5 --> P6["使用统计 + 发布治理"]:::result

四、安装和同步是怎么跑的

仓库的安装流程，本质上是一个“选择 -> 解析 -> 软链 -> 校验 -> 复用”的流水线。

典型命令

make install-backend-bundle
make install-backend-bundle-dry-run
make uninstall-backend-bundle
make stats

你可以在这里补截图

  flowchart TD
    classDef start fill:#1F2937,stroke:#111827,color:#fff;
    classDef step fill:#93C5FD,stroke:#2563EB,color:#111;
    classDef check fill:#FDBA74,stroke:#EA580C,color:#111;
    classDef done fill:#86EFAC,stroke:#16A34A,color:#111;

    A["开始"]:::start --> B["选择 profile"]:::step
    B --> C["解析 skill / 依赖"]:::step
    C --> D{"冲突?"}:::check
    D -->|否| E["建立软链接"]:::step
    D -->|是| F["覆盖 / 跳过 / 重命名"]:::check
    F --> E
    E --> G["写入目标目录"]:::step
    G --> H["校验安装结果"]:::done
    H --> I["查看 stats / dashboard"]:::done

五、技能怎么分层，怎么理解

仓库里的 skill 不是平铺的，而是按职责划分成几层。

1. 开发层

比如：

brainstorming
sdd-intelligent-router
sdd-dev-workflow
dev-lifecycle
app-scanner

这层负责把“需求怎么变成代码”这件事跑顺。

2. 质量层

比如：

author-final-review
code-review
full-review
integration-test

这层负责把“代码写完以后怎么保证质量”跑顺。

3. 工具层

比如：

zan-log-query
zan-rds-ops
zan-redis-query
zan-hbase-query
zan-apollo-query
zan-dubbo-invoke

这层负责把排障、查询、联调这些底层动作接起来。

4. 治理层

比如：

skill-creator
skill-publish
knowledge-distiller
auto-installer
skill-usage-tracker

这层负责把技能系统本身变成可持续演进的资产。

  flowchart LR
    classDef dev fill:#DBEAFE,stroke:#2563EB,color:#111;
    classDef quality fill:#FDE68A,stroke:#D97706,color:#111;
    classDef tool fill:#E9D5FF,stroke:#7C3AED,color:#111;
    classDef gov fill:#FCE7F3,stroke:#DB2777,color:#111;

    A["开发层"]:::dev --> B["质量层"]:::quality --> C["工具层"]:::tool --> D["治理层"]:::gov
    D --> A

六、最适合新手的使用路径

如果第一次接触这套仓库，我建议按这个顺序看：

先看 README.md，理解仓库定位
再看 skills/_README.md，理解分类
然后看 docs/tutorials/all-skills-usage-manual.md，理解每个 skill 怎么触发
最后再看某个具体 skill 的 SKILL.md

这个顺序的好处是：

先有总图
再看分层
再看使用
最后看细节

一个很实用的联动方式

flowchart TD
    classDef entry fill:#DBEAFE,stroke:#2563EB,color:#111;
    classDef next fill:#DCFCE7,stroke:#16A34A,color:#111;
    classDef final fill:#FDE68A,stroke:#D97706,color:#111;

    A["README 总览"]:::entry --> B["skills/_README 分类"]:::next
    B --> C["all-skills 使用手册"]:::next
    C --> D["具体 skill 的 SKILL.md"]:::final
    D --> E["真实任务里试一次"]:::final
{% endmermaid %}

---

## 七、它和你现在这批 AI 文章是怎么串起来的

如果放到你现有的知识图谱里，`dev-skill` 其实是一个很自然的“中心枢纽”。

- `Skill扫盲` 讲的是概念
- `Superpowers` 讲的是一个具体方法论
- `Agent Team` 讲的是多角色协作
- `dev-skill` 讲的是如何把这些能力工程化、仓库化、治理化

所以这篇文章最适合放在“AI / Agent / Skill”这一条知识链的中间。

{% mermaid %}
flowchart TD
    classDef concept fill:#DBEAFE,stroke:#2563EB,color:#111;
    classDef method fill:#FCE7F3,stroke:#DB2777,color:#111;
    classDef infra fill:#DCFCE7,stroke:#16A34A,color:#111;

    A["Skill扫盲"]:::concept --> B["Superpowers"]:::method --> C["Agent Team"]:::method --> D["dev-skill"]:::infra
    A --> D
    B --> D
    C --> D
{% endmermaid %}

---

## 八、你后面最适合补的图片位

如果你想把这篇文章做得更像“完整产品介绍”，我建议你后面补 4 张图：

1. 仓库首页截图
2. skills 分类树截图
3. 安装命令执行截图
4. 统计看板截图

<!-- 图位 4：统计看板截图 -->
<!-- 这里建议放 skill usage dashboard、排行榜、最近使用场景等截图 -->

---

## 九、最后一句话

`dev-skill` 最厉害的地方，不是它装了多少 skill，而是它把“经验”变成了“制度”，再把“制度”变成了“可以分发的能力”。

这就是为什么我会把它看成一套基础设施，而不是一个普通仓库。

## 延伸阅读

- 如果你想先看 `Skill` 本身是怎么从提示词补丁升级成工作流的，可以读 [Skill扫盲：从提示词补丁到AI工作流，我如何用dev-skill把经验沉淀成能力系统](/posts/skill-literacy-dev-skill-workflow.html)。
- 如果你想看 `Superpowers` 的实际使用方式，可以读 [Superpowers使用指南：把Claude Code和Codex变成真正会按流程工作的开发Agent](/posts/superpowers-guide-coding-agent-workflow.html)。
- 如果你想看多 Agent 怎么串成协作流水线，可以读 [Agent Team使用教程：用Tmux分屏把多个AI串成自动协作流水线](/posts/agent-team-tutorial-tmux-workflow.html)。