---

title: Skill 技能系统完全指南（五）实战 Skill：代码质量——Code Review、Lint 与测试覆盖率
date: 2026-07-10
category: AI 开发工具
tags: [Claude Code, Skill, 代码质量, Code Review, Lint, 测试覆盖率]

Skill 技能系统完全指南（五）：实战 Skill——代码质量

Code Review、Lint 检查、测试覆盖率分析——质量关卡一个都不能少。本篇教你编写代码质量 Skill，让 Claude 成为你的 7x24 在线 Code Reviewer。

前言

代码写完了，怎么确保质量？传统做法是：

自己看一遍 → 提交 PR → 同事 Review → 修问题 → 再 Review

这个过程慢且依赖人的状态。用 Skill 来标准化这个过程，每次提交都自动经过同一套质量关卡，不留死角。

一、Code Review Skill

1.1 设计思路

Code Review 不能只说"代码写得不错"或"这里有 bug"。一个专业的 Review Skill 应该有明确的审查维度和评分标准。

---
name: code-review-pro
description: 专业的代码审查 Skill，多维度审查代码质量、安全性、性能
trigger: 代码审查, code review, CR, 评审
tools: [Bash, Grep, Read, Agent]
---

# 专业代码审查 Skill

## 角色定义

你是一个严格的代码审查专家，拥有 10 年以上的企业级项目开发经验。
你审查代码的标准高于大多数公司的 Code Review 规范。

## 审查维度

### 维度 1：正确性（权重 40%）

- [ ] 逻辑是否正确？有无边界情况遗漏？
- [ ] 异常处理是否完善？
- [ ] 空值/Null 检查是否到位？
- [ ] 数据类型转换是否安全？
- [ ] 数据库查询是否正确（SQL 注入、N+1）？

### 维度 2：安全性（权重 25%）

- [ ] 有无硬编码的敏感信息（密码、密钥、Token）？
- [ ] 输入是否做了校验和过滤？
- [ ] SQL 是否使用了参数化查询？
- [ ] 前端有无 XSS 风险（v-html、innerHTML）？
- [ ] 接口是否有权限校验？
- [ ] 文件上传是否做了类型和大小限制？

### 维度 3：性能（权重 20%）

- [ ] 有无不必要的循环嵌套？
- [ ] 数据库查询是否可以优化（索引、JOIN）？
- [ ] 前端有无导致不必要重渲染的代码？
- [ ] 大对象是否做了浅拷贝/深拷贝的合理选择？
- [ ] 有无内存泄漏风险（未注销的事件监听、定时器）？

### 维度 4：可维护性（权重 15%）

- [ ] 命名是否清晰表达意图？
- [ ] 函数/方法是否过长（>50 行需拆分）？
- [ ] 是否有重复代码可以抽取？
- [ ] 注释是否充分但不冗余？
- [ ] 是否符合项目的 CLAUDE.md 规范？

## 评分标准

| 分数 | 等级 | 含义 |
|------|------|------|
| 90-100 | ✅ 优秀 | 可以直接合并 |
| 75-89 | ⚠️ 良好 | 有小问题，建议修改后合并 |
| 60-74 | 🔶 一般 | 有多个问题，需要修改后重新 Review |
| <60 | ❌ 不合格 | 存在严重问题，不建议合并 |

## 输出格式

📋 代码审查报告
━━━━━━━━━━━━━━━━━━━━━

文件：UserService.java
路径：src/main/java/…/service/UserService.java
评分：82/100 ⚠️ 良好

🔴 必须修复
L45: 未处理用户不存在的场景，直接抛 NullPointerException
→ 建议：添加 Optional 判断或 @Nullable 注解

🟡 建议修复
L78: 方法过长（86 行），建议拆分为 validateUser() 和 buildResponse()
L102: 硬编码的邮件模板路径，建议提取为常量

🟢 亮点
L23: 使用了 LambdaQueryWrapper 构建动态查询，代码简洁
L56: 事务注解 @Transactional 使用正确， rollbackFor 指定完整

━━━━━━━━━━━━━━━━━━━━━
总体评价：代码质量良好，修复 🔴 项后可合并

二、Lint 检查 Skill

2.1 设计思路

Lint 是代码风格的守门员。不同的语言和项目有不同的 Lint 规则。这个 Skill 的作用是自动生成和校验 Lint 配置。

---
name: lint-checker
description: 检查和生成 ESLint、Prettier、Checkstyle 等代码规范配置
trigger: lint, 代码规范, 格式化, prettier, eslint, checkstyle
---

# Lint 检查 Skill

## 角色定义

你是一个代码规范专家，熟悉各类语言的 Linter 配置。

## 前端 Lint 配置生成

根据项目需求生成 `.eslintrc.cjs`：

```javascript
module.exports = {
  root: true,
  env: {
    browser: true,
    es2021: true,
  },
  extends: [
    'eslint:recommended',
    'plugin:vue/vue3-recommended',
    '@vue/typescript/recommended',
  ],
  parserOptions: {
    ecmaVersion: 2021,
    parser: '@typescript-eslint/parser',
  },
  rules: {
    // 禁止使用 console
    'no-console': process.env.NODE_ENV === 'production' ? 'warn' : 'off',
    // 禁止使用 debugger
    'no-debugger': process.env.NODE_ENV === 'production' ? 'warn' : 'off',
    // 强制使用驼峰命名
    'camelcase': 'error',
    // 限制函数行数
    'max-lines-per-function': ['error', { max: 50 }],
    // Vue 组件名驼峰
    'vue/component-name-in-template-casing': ['error', 'PascalCase'],
  },
}

后端 Checkstyle 配置生成

生成 checkstyle.xml：

<module name="Checker">
  <module name="TreeWalker">
    <!-- 命名规范 -->
    <module name="MethodName"/>
    <module name="ParameterName"/>
    
    <!-- 代码长度 -->
    <module name="MethodLength">
      <property name="max" value="80"/>
    </module>
    <module name="LineLength">
      <property name="max" value="200"/>
    </module>
    
    <!-- 禁止语句 -->
    <module name="AvoidStarImport"/>
    <module name="IllegalImport"/>
  </module>
</module>

自动检查流程

执行 Lint 检查：

# 前端
cd frontend
pnpm exec eslint src/ --fix
pnpm exec prettier --check "src/**/*.{vue,ts,js}"

# 后端
cd asset-server
mvn checkstyle:check

报告不符合规范的代码文件和行号。

## 三、测试覆盖率 Skill

### 3.1 设计思路

没有测试覆盖的代码等于没有保障。这个 Skill 用来分析和提升测试覆盖率。

```markdown
---
name: test-coverage
description: 分析测试覆盖率报告，找出未覆盖的代码并提出补充测试建议
trigger: 测试覆盖率, coverage, 单元测试, 补充测试
---

# 测试覆盖率分析 Skill

## 角色定义

你是一个测试质量保证专家，擅长分析测试覆盖率和发现测试盲区。

## 执行流程

### 步骤 1: 运行测试并生成覆盖率报告

```bash
# 前端（Vitest）
cd frontend
pnpm test -- --coverage

# 后端（JaCoCo）
cd asset-server
mvn test jacoco:report

步骤 2: 分析覆盖率报告

读取覆盖率报告文件（frontend/coverage/index.html 或 asset-server/target/site/jacoco/index.html），提取以下指标：

指标	合格线	说明
行覆盖率	≥ 80%	代码行被执行的比例
分支覆盖率	≥ 70%	if/else 等分支被测试的比例
函数覆盖率	≥ 85%	函数被调用的比例

步骤 3: 识别未覆盖的代码

## 未覆盖代码分析

### 高优先级（核心业务逻辑）
| 文件 | 行号 | 未覆盖分支 | 建议测试用例 |
|------|------|-----------|-------------|
| UserService.java | 45-52 | 用户不存在分支 | 测试查询不存在的 userId |
| OrderController.java | 23 | 权限不足分支 | 测试无权限用户访问订单 |

### 中优先级（工具方法）
| 文件 | 行号 | 问题 | 建议 |
|------|------|------|------|
| DateUtil.java | 67 | 死代码 | 该方法未被任何地方调用 |

### 低优先级（边界情况）
- 空数组输入的处理
- 超大参数的处理

步骤 4: 生成测试代码建议

对于每个未覆盖的分支，生成对应的测试代码模板：

// 建议补充的测试用例
describe('UserService.getUserById', () => {
  it('should return null when user does not exist', () => {
    when(userMapper.selectById(9999)).thenReturn(null)
    expect(service.getUserById(9999)).toBeNull()
  })

  it('should throw when userId is negative', () => {
    expect(() => service.getUserById(-1)).toThrow()
  })
})

输出

生成完整的覆盖率分析报告，包含：

1. 总体覆盖率概览
2. 未覆盖的高优先级代码
3. 建议补充的测试用例代码
4. 覆盖率提升路线图

## 四、代码重复检测 Skill

### 4.1 设计思路

重复代码是维护的噩梦。这个 Skill 专门检测项目中的重复代码段。

```markdown
---
name: duplicate-detector
description: 检测项目中的重复代码段，包括方法体重复、SQL 重复、组件逻辑重复
trigger: 重复代码, 代码复用, DRY, 重构建议
---

# 重复代码检测 Skill

## 执行流程

### 步骤 1: 检测后端重复代码

```bash
# 使用 PMD CPD 检测
cd asset-server
mvn pmd:cpd-check

步骤 2: 检测前端重复代码

# 使用 eslint-plugin-unicorn 的 no-unused-vars 和 sort-imports
# 以及手动检测相似的 Vue 组件
cd frontend
pnpm exec eslint src/ --rule 'unicorn/filename-case: error'

步骤 3: 检测 SQL 重复

# 查找相同的 SQL 片段
grep -rn "SELECT.*FROM jt_" src/main/resources/mapper/ | \
  awk '{print $3}' | sort | uniq -d

步骤 4: 输出报告

📋 重复代码检测报告
━━━━━━━━━━━━━━━━━━━━━

🔴 高度重复（>80% 相似）
  UserService.java:L34-52 与  AdminService.java:L28-46
    相似度：92%
    建议：提取为公共的 BaseUserService

🟡 中度重复（50-80% 相似）
  DayReportMapper.xml 中有 3 个查询使用了相同的 WHERE 条件
  建议：抽取为 <sql id="commonFilters"> 片段

🟢 轻度重复（<50% 相似）
  多个组件中都写了类似的 el-dialog 关闭逻辑
  建议：封装为 useDialog composable

━━━━━━━━━━━━━━━━━━━━━
总计：高度重复 1 处 | 中度重复 1 处 | 轻度重复 1 处

## 五、综合质量检查编排

将以上所有 Skill 编排成一个综合质量关卡：

```markdown
---
name: quality-gate
description: 综合质量检查：Code Review + Lint + 测试覆盖率 + 重复代码检测
trigger: 质量检查, quality gate, 合并前检查, merge check
---

# 综合质量检查 Skill

## 角色定义

你是发布质量的最后一道关卡。在代码合并之前，你必须确保所有质量指标达标。

## 检查清单

按顺序执行以下检查，全部通过才能放行：

| # | 检查项 | 通过标准 | 权重 |
|---|--------|---------|------|
| 1 | Lint 检查 | 0 error, ≤3 warning | 必须 |
| 2 | 单元测试 | 100% 通过 | 必须 |
| 3 | 测试覆盖率 | 行覆盖率 ≥ 80% | 必须 |
| 4 | Code Review | 评分 ≥ 75 | 必须 |
| 5 | 重复代码 | 无高度重复 | 建议 |
| 6 | 安全扫描 | 无高危漏洞 | 必须 |

## 放行标准

- 全部"必须"项通过 → ✅ 放行
- 任一"必须"项不通过 → ❌ 拦截，列出问题
- 所有"必须"通过但有"建议"项不通过 → ⚠️ 放行但注明

## 输出格式

🛡️ 质量检查报告
━━━━━━━━━━━━━━━━━━━━━

[1/6] Lint 检查 ✅ 0 error, 2 warning
[2/6] 单元测试 ✅ 42/42 passed
[3/6] 测试覆盖率 ✅ 行覆盖率 85.3%
[4/6] Code Review ✅ 评分 88/100
[5/6] 重复代码检测 ⚠️ 发现 1 处中度重复（建议优化）
[6/6] 安全扫描 ✅ 无高危漏洞

━━━━━━━━━━━━━━━━━━━━━
结论：✅ 放行 — 可以合并到主分支
备注：建议后续优化重复代码（见 [5/6]）

六、这一章的核心心得

1. Code Review Skill 的核心是多维度——正确性、安全性、性能、可维护性缺一不可
2. Lint 检查是基础——自动化代码规范检查，减少人工争论
3. 测试覆盖率要有底线——80% 行覆盖率是一个合理的最低标准
4. 重复代码检测能省很多事——DRY 原则不是口号，是实实在在的可维护性提升
5. 综合质量关卡最有价值——把多个检查 Skill 编排在一起，成为代码合并的"守门员"
6. 评分标准要量化——90 分以上放行，75-89 建议修改，低于 75 打回重改

七、下一步

代码质量有保障了，接下来还有一个高频需求——文档。

代码写好了要写 API 文档，功能做完了要写用户手册，版本发布了要写 Changelog。这些 repetitive 的文字工作，同样可以用 Skill 来自动化。

下一篇我们将编写文档生成 Skill。

---

系列目录：

1. 初识 Skill 系统——什么是 Skill？为什么需要 Skill？
2. 自定义 Skill 开发——从 0 到 1 编写自己的 Skill
3. Skill 编排与组合——多个 Skill 串联工作，打造自动化流程
4. 实战 Skill：DevOps 部署——编写 Docker/Nginx/CI-CD 相关的部署 Skill
5. 实战 Skill：代码质量——编写 Code Review / Lint / 测试覆盖率 Skill ← 本篇
6. 实战 Skill：文档生成——编写 API 文档 / 技术手册 / Changelog 生成 Skill（待写）
7. Skill 分享与复用——团队共享 Skill 库、开源 Skill 生态、版本管理（待写）
8. Skill 进阶技巧——条件触发、多语言支持、与 Agent/Workflow 的配合（待写）