告别重复劳动：一套插件让 AI 替你写代码、修Bug、做测试、上生产

Claude Code 团队 AI 插件实践：从新人上线到全栈自动化的渐进式指南

特别鸣谢：本文由 南京大翼航空 团队实践沉淀而成，感谢团队在 AI 辅助研发领域的持续探索与投入。

后续规划：本文为 dw 插件生态的总览。后续将为每个 skill 单独撰写详细教程文章，涵盖实战案例、配置细节和踩坑经验，敬请关注。

本文涉及的研发规范体系均基于 Claude Code 的插件机制实现。插件是 Claude Code 官方提供的扩展方式，支持自定义命令、Skill、Hook、Agent 等，是目前团队级 AI 研发规范的推荐落地形态。

开篇：我们为什么要做这套插件

在团队引入 Claude Code 做 AI 辅助开发后，我们很快遇到了几个共性问题：

1. 新人上手陡峭：不知道有哪些 skill、怎么装、怎么用
2. AI 改动污染主分支：直接在当前分支让 AI 改代码，心里不踏实
3. 重复踩坑无沉淀：同一个 Bug 换了个人又让 AI 从头排查
4. 全栈流程割裂：后端接口、前端页面、测试各跑各的，契约对不齐
5. 命令安全无保障：担心 AI 一个 rm -rf / 把环境搞崩

于是我们设计了一套团队级插件 dw，核心思路是 Skills + Agent Team：Skills 封装可复用的研发流程，Agent Team 负责多角色协作编排，配合 9 个渐进式 Skill 覆盖完整研发链路。

Skill 渐进关系：

1work ──→ depend ──→ frontend ──→ backend ──→ test ──→ feature ──→ devops ──→ fix ──→ wiki
2 │          │           │            │           │           │           │         │        │
3 环境隔离   依赖管理    前端开发     PRD→API    用例生成    全栈编排    云效运维   Bug修复   知识沉淀
4

从"把环境搭起来"到"把知识留下来"，形成完整闭环。下面我们按这个顺序逐一展开。

核心理念

dw 插件的设计围绕一个核心目标：让 AI 全自动化参与研发流程，同时保证安全、可追溯、可复用。

• Skills 封装流程：将研发活动（修 Bug、写功能、发版本）封装为可复用的 Skill，团队成员通过 /dw:<skill> 统一入口触发
• Agent Team 协作：复杂任务由多 Agent 协作完成，编排者分派、执行者落地、验证者把关
• Hooks 全生命周期守护：危险命令拦截、密钥扫描、MCP 预检、自动格式化——在工具调用层面前置防御，而非事后补救
• Wiki 知识沉淀：每次 Bug 修复、功能迭代的结果写入五层知识库，让 AI 的下一次修复能从历史中学习

典型流程

从收到需求到完成交付的完整链路：

1/dw:work              → 创建隔离的 AI 工作空间
2/dw:depend            → 装齐团队共享 skill
3/dw:feature           → 全栈功能（后端+前端+测试一步到位）
4  或 /dw:backend      → 纯后端（PRD → API + 测试 + 文档）
5  或 /dw:frontend     → 纯前端（设计稿 → 代码）
6  或 /dw:fix          → Bug 修复（多 Agent 协作 + 五级升级）
7/dw:test "..."        → 补充测试用例
8/dw:devops pipeline   → 触发流水线 / 部署
9/dw:wiki query "..."  → 检索/沉淀知识
10

项目目录结构

1dw/
2├── .claude-plugin/plugin.json   # 插件清单（name/version/commands/skills/hooks）
3├── agents/                      # Agent 定义（Teammate 角色配置）
4│   ├── pm.md
5│   ├── dev.md
6│   └── qa.md
7├── skills/                      # 核心能力（9 个 skill，每个含 SKILL.md + references/）
8│   ├── work/                    #   Git worktree 工作空间管理
9│   ├── depend/                  #   团队 skill 依赖管理
10│   ├── frontend/                #   设计稿 → 前端页面
11│   ├── backend/                 #   PRD → 后端 API
12│   ├── test/                    #   测试用例生成
13│   ├── feature/                 #   全栈迭代编排
14│   ├── devops/                  #   云效 DevOps 运维
15│   ├── fix/                     #   Bug 修复主流程
16│   └── wiki/                    #   五层知识库
17├── hooks/hooks.json             # 生命周期 Hooks（SessionStart / PreToolUse / PostToolUse / Stop）
18├── scripts/                     # Hook 引用的实际脚本（安全拦截 / 格式化 / 密钥扫描等）
19├── settings.json                # 插件配置（Agent Teams 开启 / 模型选择）
20├── CLAUDE_STANDARDS.md          # 团队规范（每次会话自动注入）
21└── team-skills.yaml             # 团队共享 skill 清单（depend skill 读取）
22

数据在目标项目中的落盘位置：

1<项目根>/
2├── .dw/
3│   ├── task/                    # 任务清单（手动创建: backend-task.md / frontend-tasks.json 等）
4│   ├── memory/                  # 快照目录（自动维护，支持断点续跑）
5│   └── wiki/                    # 知识库（随 git 追踪，五层结构）
6├── .env.dw                      # 云效配置（不入 git!）
7└── .gitignore                   # 必须包含 .env.dw 和 .claude/worktrees/
8

一、work — AI 工作空间管理

基于 git worktree 创建隔离的 AI 工作分支（<branch>-ai），自动安装依赖，在新终端启动 Claude，AI 改动不污染主分支。

1flowchart TD
2    A["/dw:work [action]"] --> B{action 类型}
3    B -- create --> C[.gitignore 预检<br/>未忽略则自动追加]
4    C --> D[git pull origin branch]
5    D --> E[worktree add -b branch-ai<br/>已存在则追加时间戳]
6    E --> F[auto-setup<br/>pnpm/cargo/poetry/pip/go]
7    F --> G[新终端启动 Claude]
8    B -- sync --> H[git pull + rebase worktree]
9    B -- remove --> I[安全检查: 不在 worktree 内]
10    I --> J[worktree remove + branch -D]
11    B -- clear --> K[扫描 + 用户确认 yes]
12    K --> L[逐一 remove + branch -D + prune]
13

二、depend — 团队 Skill 依赖管理（三级体系）

管理团队共享 skill 依赖，从 YAML 清单读取配置，通过 npx skills 完成安装/更新。分为个人（~/.skills/）、项目（./.skills/）、团队（team-skills.yaml）三个级别。

1flowchart TD
2    A["/dw:depend [action]"] --> B{解析 action}
3    B -- "install / 空" --> M["读合并清单 plugin + project"]
4    B -- update --> M
5    M --> N{"scope 优先级: --scope 大于 项目 大于 插件 大于 global"}
6    N --> O{action}
7    O -- install --> P["对每条 skill: 已装跳过, 未装则 npx skills add"]
8    P --> Q["SUMMARY: installed / present / failed"]
9    O -- update --> R{"--no-pull?"}
10    R -- 否 --> S["git -C plugin-root pull --ff-only"]
11    S --> T["逐条 npx skills add -y"]
12    T --> U["npx skills update 兜底"]
13    U --> Q
14    Q --> V{"有新增或升级?"}
15    V -- 是 --> W["提醒 /exit 重启 Claude Code"]
16

三、frontend — 前端开发

dw:frontend 定位前端全流程开发，不仅限于设计稿转页面。覆盖三大场景：设计稿驱动（MasterGo → 代码）、接口联调（基于 backend 产出的 API 契约对接）、前端逻辑开发（状态管理、路由、交互逻辑等）。同时三平台并行支持 PC（Vue3+AntDV）、小程序（Taro+Taroify）、H5（Taro H5）。

清单格式（.dw/task/frontend-tasks.json）：

开发决策分支：

1flowchart TD
2    A[前端需求] --> B{是否有 MasterGo 设计稿?}
3    B -- 是 --> C{涉及后端接口?}
4    C -- 是 --> D["/dw:feature 全栈编排 + 契约交接"]
5    C -- 否 --> E["/dw:frontend 设计稿到代码"]
6    B -- 否 --> F{涉及后端接口?}
7    F -- 是 --> G["/dw:feature 或手动调 /dw:backend 后对接"]
8    F -- 否 --> H[纯前端逻辑: 状态/路由/交互]
9    H --> I{有现成设计规范?}
10    I -- 是 --> J["/dw:frontend task 中描述逻辑需求"]
11    I -- 否 --> K["对话模式直接开发, 手动编码 + /dw:test 补测试"]
12
13    subgraph 子 agent 内部流程
14      S1[DSL 解析] --> S2[布局树]
15      S2 --> S3[设计规范]
16      S3 --> S4[图片下载]
17      S4 --> S5[编码<br/>页面 + 逻辑 + 接口对接]
18      S5 --> S6[Lint 自检]
19    end
20

页面生成流程：

1flowchart TD
2    A[读 frontend-tasks.json] --> B[校验 platform + tasks 字段]
3    B --> C[扫描快照 过滤已 done]
4    C --> D["并发数小于 3 且有待办?"]
5    D -- 是 --> E[派子 agent 写快照 running]
6    E --> D
7    D -- 否 --> F[等待子 agent 回执]
8    F --> G[落快照 done/failed]
9    G --> H{还有待办?}
10    H -- 是 --> D
11    H -- 否 --> I[汇总表格 + 询问失败项重试]
12

四、backend — 需求驱动的后端全流程

从 PRD 一键落地为「数据库 schema + 三层代码 + 测试 + OpenAPI 文档」，7 步顺序执行，快照断点续跑。支持 4 种技术栈。

frontmatter 必填字段：

1flowchart TD
2    A[入参] --> B[Step 0 前置检查<br/>platform/module/outputDir + 快照扫描]
3    B --> C["Step 1 需求解析 -> 结构化 JSON"]
4    C --> D["Step 2 Schema 设计 -> migration + entity"]
5    D --> E["Step 3 API 契约 -> 接口清单表格"]
6    E --> F["Step 4 编码实现 -> Controller/Service/DTO"]
7    F --> G["Step 5 测试生成 -> 单测 + 集成"]
8    G --> H[Step 6 OpenAPI 文档]
9    H --> I["Step 7 Lint 自检 -> 两轮自动修复"]
10    I --> J[快照 status=done]
11

五、test — 测试用例生成与验证

基于 wiki 历史 + git 近期改动，生成双层测试用例（Layer A 基本执行 / Layer B 复杂组合）。支持等价类、边界值、Pairwise、状态机等多种方法论。8 个降级场景确保外部依赖缺失时不中断流程。

1flowchart TD
2    A["ARGUMENTS"] --> B{ID 数量}
3    B -- "0" --> C[描述模式 target_intent=原文]
4    B -- "1" --> D[单 ID: 拉详情]
5    B -- ">=2" --> E[批量: 循环 single-mode]
6    C --> F[Step 1 收集上下文<br/>wiki + git commits]
7    D --> F
8    E --> F
9    F --> G[Step 2 生成双层用例<br/>Layer A 必跑 / Layer B 按需]
10    G --> H[Step 2.5 覆盖率自检<br/>最多 1 轮补全]
11    H --> I{检测到 test runner?}
12    I -- 是 --> J[Step 3 运行测试<br/>失败按维度聚类]
13    I -- 否 --> K[静态验证模式<br/>类型 + lint + 桌面演算]
14    J --> L[报告 + 可信度标签]
15    K --> L
16

六、feature — 全栈迭代编排

同时涉及后端 + 前端 + 测试时，由 feature 统一调度三个下游 skill。主会话只做编排不做编码，检索 wiki → 建 Agent Team → 派活 → 契约交接 → 收束汇总。

frontmatter 必填字段（.dw/task/feature-task.md）：

1flowchart TD
2    A[入参] --> B[Step 0 解析 + 快照扫描]
3    B --> C{快照状态}
4    C -- done --> D[询问重跑/跳过/续跑]
5    C -- 无/failed --> E[Step 1 wiki 检索历史]
6    D -- 续跑 --> E
7    E --> F{Agent Teams 可用?}
8    F -- 否 --> G[降级: 主会话串行调下游 skill]
9    F -- 是 --> H[Step 2 创建 Agent Team]
10    H --> I[Step 3 派发 teammate]
11    I --> J1["backend -> dw:backend"]
12    I --> J2["frontend -> dw:frontend"]
13    I --> J3["test -> dw:test"]
14    J1 --> K["Step 4 API 契约交接, backend -> frontend"]
15    K --> L[Step 5 等待收束 & 快照]
16    J2 --> L
17    J3 --> L
18    L --> M[Step 6 汇总输出<br/>+ 自判是否回写 wiki]
19    G --> M
20

七、devops — 云效 DevOps 全流程编排

将云效 DevOps 操作从"手工点页面"提升为"一句话驱动"。HITL 守卫所有写操作，长时操作 5 分钟超时支持用户决策，快照支持断点续接。

1flowchart LR
2    A[用户输入] --> B[Phase 0 上下文初始化<br/>读 .env.dw 创建快照]
3    B --> C[Phase 1 域识别<br/>工作项/代码/流水线/部署/...]
4    C --> D[Phase 2 HITL 确认<br/>写操作默认需确认]
5    D --> E[Phase 3 执行 + 流式回报<br/>长任务轮询 5min 超时]
6    E --> F[Phase 4 汇总 + 知识沉淀<br/>可选 wiki 回写]
7

八、fix — Bug 修复

Bug 修复是最高频的研发活动。dw:fix 将 Bug 单或自然语言描述转化为可合并的修复 MR，完整流程覆盖：wiki 记忆预检 → 探索定位根因 → 任务拆分 → 编码 → 自测 → QA 对抗测试 → 知识沉淀。内置五级升级策略，修复失败时逐级降级，不陷入无限循环。

五级升级策略：

1flowchart TD
2    A[用户输入] --> B{匹配 ID 数量}
3    B -- 0 --> C[描述模式]
4    B -- 1 --> D[单 ID 模式<br/>拉取工作项详情]
5    B -- ">=2" --> E[批量模式<br/>循环 single-mode]
6    C --> F[wiki 记忆预检]
7    D --> F
8    E --> F
9    F --> G[探索定位根因]
10    G --> H[任务拆分]
11    H --> I[Dev 编码]
12    I --> J[Dev 自测]
13    J --> K{自测通过?}
14    K -- 否 --> I
15    K -- 是 --> L[QA 对抗测试]
16    L --> M{QA 通过?}
17    M -- 否 --> N{"轮次小于 3?"}
18    N -- 是 --> I
19    N -- 否 --> O[五级升级策略]
20    M -- 是 --> P[知识沉淀<br/>写入 .dw/wiki/bugs/]
21    P --> Q[创建 MR 到远程分支]
22

九、wiki — 五层知识库

受 Karpathy LLM Wiki 启发的轻量级知识库，记录 bug 修复和 feature 迭代全过程。其他 skill 程序化消费：fix 修复后自动录入，feature 可选回写，test/fix 执行前检索历史。

五层结构：

1flowchart LR
2    A[原始输入] --> B[raw/ 存证]
3    B --> C["清洗 -> features"]
4    C --> D[提取 hub title]
5    D --> E{编辑距离匹配<br/>已有 hub?}
6    E -->|命中| F[合并 hub body]
7    E -->|未命中| G[创建新 hub]
8    F --> H[提取/更新 concepts]
9    G --> H
10    H --> I[重建缓存]
11

十、Hooks 系统 — 全生命周期安全网

上面 9 个 skill 是"主动能力"，hooks 则是"被动保障"。它们在 Claude Code 会话的各个生命周期节点自动触发，前置拦截风险。

Hook 矩阵

各脚本详解

SessionStart — 规范注入

会话一启动就把 CLAUDE_STANDARDS.md 注入到 Claude 的上下文中。内容包括：核心工作原则、代码规范（单次 ≤ 200 行）、Bug 修复规范、Feature 开发规范、重构规范、Agent 协作协议、知识持久化规范。

UserPromptSubmit — 上下文注入

每次你按下回车，脚本自动在 prompt 前面追加一段 git 状态信息：

1[git-context]
2branch: feat/login (ahead 2 / behind 0 vs origin/feat/login)
3worktree: /Users/xxx/git/myapp
4dirty: 5 files (1 added / 3 modified / 1 deleted)
5

Claude 不用再主动跑 git status 就能感知仓库状态。

PreToolUse(Bash) — 危险命令拦截

这是最重要的一道安全防线，拦截清单包括：

• rm -rf / 或 rm -rf ~（含 sudo 变体）
• git push --force 到 main / master / prod / production / release
• git reset --hard 到远端主干
• git clean -fdx / git checkout -- .
• mkfs.* / dd if=... of=/dev/...
• fork bomb :(){ :|:& };:
• chmod -R 777 /

命中后 exit 2，Claude 会看到拦截原因并自行改写为更安全的命令。

PostToolUse — 密钥扫描

代码写入后自动扫描，命中以下任一正则即阻断：

• AKIA[0-9A-Z]{16} — AWS Access Key
• sk-(ant-)?[A-Za-z0-9_\-]{32,} — OpenAI / Anthropic API Key
• gh[pousr]_[A-Za-z0-9]{36,} — GitHub PAT
• xox[baprs]-[A-Za-z0-9-]{10,} — Slack Token
• -----BEGIN (RSA |EC |OPENSSH |DSA |PGP )?PRIVATE KEY----- — PEM 私钥
• AIza[0-9A-Za-z_\-]{35} — Google API Key

对 .env 文件中的密钥只警告不阻断（.env 本来就是放密钥的地方），但会提醒你确认 .gitignore。

PostToolUse — 自动格式化

文件写入后按扩展名分派格式化工具：

工具不在 PATH 就静默跳过，不影响主流程。

Stop — 桌面通知

任务完成时发送桌面通知。Windows → BurntToast（未装降级 msg.exe），macOS → osascript，Linux → notify-send。都失败也 exit 0。

十一、总结与最佳实践

10.1 前后端合并一个项目时的注意事项

如果你的项目是前后端合一（比如同一个 git 仓库下既有 src/modules/ 又有 src/views/），feature skill 原生支持这种场景：

1. 契约交接机制保证接口对齐：backend 产出 API 契约 → frontend 按契约对接，不会有字段名对不上的问题
2. backend 产出 OpenAPI 文档：可直接作为 frontend 的接口参考
3. 模块目录独立：backend 产出在 src/modules/<module>/，frontend 产出在 src/views/<page>/，互不冲突
4. feature-task.md 同时声明两端配置：一次编排，两端并行产出

10.2 新人上手路径速查

1第一步: /dw:depend               # 装齐团队 skill
2第二步: /dw:work                  # 创建 AI 工作空间
3第三步: 开始编码                   # 使用 backend / frontend / fix 等
4第四步: /dw:test "..."            # 生成测试
5第五步: /dw:wiki query "..."      # 沉淀和查询知识
6

场景速查：

10.3 慎用部分 MCP 说明

dw 插件依赖三个 MCP 服务，它们在使用前会自动预检（PreToolUse hook），但理解它们的权限边界很重要：

核心原则：

• MCP 调用前自动预检，缺配置不是静默失败，而是明确告诉你缺什么、怎么补
• .env.dw 绝不进 git，Hook 的 secret-scan 也会拦截 .env 外的密钥
• Cookie 过期时 skill 自动降级（fix 单 ID → 描述模式），不会卡死

10.4 安全红线速查

所有以下行为被 Hooks 自动拦截（exit 2），无需担心 AI 越界：

附录：关键目录速查

1项目根/
2├── .dw/
3│   ├── task/                    # 任务清单（手动创建）
4│   │   ├── backend-task.md
5│   │   ├── frontend-tasks.json
6│   │   ├── feature-task.md
7│   │   └── devops-task.md
8│   ├── memory/                  # 快照（自动维护，支持断点续跑）
9│   │   ├── backend/<platform>/<module>.md
10│   │   ├── frontend/<platform>/<id>.md
11│   │   ├── feature/<name>.md
12│   │   └── devops/<slug>.md
13│   └── wiki/                    # 知识库（随 git 追踪）
14│       ├── raw/
15│       ├── features/
16│       ├── hubs/
17│       ├── concepts/
18│       └── bugs/
19├── .env.dw                      # 云效配置（不入 git!）
20└── .gitignore                   # 必须包含 .env.dw 和 .claude/worktrees/
21

本文基于 dw 插件 v1.0.0，持续迭代中。如果你对某个 skill 的设计细节感兴趣，每个 skill 目录下都有完整的 README.md 和 references/ 参考文档。

下一步

本文为 dw 插件生态的总览。读完本文，你应该能判断遇到什么问题该用什么 skill。

后续计划：

• 9 篇 skill 详情教程：每个 skill 单独成文，涵盖实战案例、配置细节、参数详解和踩坑经验
• 开源仓库 + Demo 项目：代码和最小可运行示例将在详情文章中同步披露

如果你对某个 skill 特别感兴趣，欢迎在评论区留言，我们会优先输出。

觉得有用？点个赞收藏，更新不迷路。告别重复劳动：一套插件让 AI 替你写代码、修 │ 痛点切入，动词驱动 │

│ │ Bug、做测试、上生产

《告别重复劳动：一套插件让 AI 替你写代码、修Bug、做测试、上生产》 是转载文章，点击查看原文。