title: Skill 技能系统完全指南五实战 Skill代码质量——Code Review、Lint 与测试覆盖率date: 2026-07-10category: AI 开发工具tags: [Claude Code, Skill, 代码质量, Code Review, Lint, 测试覆盖率]Skill 技能系统完全指南五实战 Skill——代码质量Code Review、Lint 检查、测试覆盖率分析——质量关卡一个都不能少。本篇教你编写代码质量 Skill让 Claude 成为你的 7x24 在线 Code Reviewer。前言代码写完了怎么确保质量传统做法是自己看一遍 → 提交 PR → 同事 Review → 修问题 → 再 Review这个过程慢且依赖人的状态。用 Skill 来标准化这个过程每次提交都自动经过同一套质量关卡不留死角。一、Code Review Skill1.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 注入、N1 ### 维度 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 检查 Skill2.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.xmlmodulenameCheckermodulenameTreeWalker!-- 命名规范 --modulenameMethodName/modulenameParameterName/!-- 代码长度 --modulenameMethodLengthpropertynamemaxvalue80//modulemodulenameLineLengthpropertynamemaxvalue200//module!-- 禁止语句 --modulenameAvoidStarImport/modulenameIllegalImport//module/module自动检查流程执行 Lint 检查# 前端cdfrontendpnpmexeceslint src/--fixpnpmexecprettier--checksrc/**/*.{vue,ts,js}# 后端cdasset-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()})})输出生成完整的覆盖率分析报告包含总体覆盖率概览未覆盖的高优先级代码建议补充的测试用例代码覆盖率提升路线图## 四、代码重复检测 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 组件cdfrontendpnpmexeceslint src/--ruleunicorn/filename-case: error步骤 3: 检测 SQL 重复# 查找相同的 SQL 片段grep-rnSELECT.*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 idcommonFilters 片段 轻度重复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]六、这一章的核心心得Code Review Skill 的核心是多维度——正确性、安全性、性能、可维护性缺一不可Lint 检查是基础——自动化代码规范检查减少人工争论测试覆盖率要有底线——80% 行覆盖率是一个合理的最低标准重复代码检测能省很多事——DRY 原则不是口号是实实在在的可维护性提升综合质量关卡最有价值——把多个检查 Skill 编排在一起成为代码合并的守门员评分标准要量化——90 分以上放行75-89 建议修改低于 75 打回重改七、下一步代码质量有保障了接下来还有一个高频需求——文档。代码写好了要写 API 文档功能做完了要写用户手册版本发布了要写 Changelog。这些 repetitive 的文字工作同样可以用 Skill 来自动化。下一篇我们将编写文档生成 Skill。系列目录初识 Skill 系统——什么是 Skill为什么需要 Skill自定义 Skill 开发——从 0 到 1 编写自己的 SkillSkill 编排与组合——多个 Skill 串联工作打造自动化流程实战 SkillDevOps 部署——编写 Docker/Nginx/CI-CD 相关的部署 Skill实战 Skill代码质量——编写 Code Review / Lint / 测试覆盖率 Skill← 本篇实战 Skill文档生成——编写 API 文档 / 技术手册 / Changelog 生成 Skill待写Skill 分享与复用——团队共享 Skill 库、开源 Skill 生态、版本管理待写Skill 进阶技巧——条件触发、多语言支持、与 Agent/Workflow 的配合待写
Skill 技能系统完全指南（五）：实战 Skill——代码质量
title: Skill 技能系统完全指南五实战 Skill代码质量——Code Review、Lint 与测试覆盖率date: 2026-07-10category: AI 开发工具tags: [Claude Code, Skill, 代码质量, Code Review, Lint, 测试覆盖率]Skill 技能系统完全指南五实战 Skill——代码质量Code Review、Lint 检查、测试覆盖率分析——质量关卡一个都不能少。本篇教你编写代码质量 Skill让 Claude 成为你的 7x24 在线 Code Reviewer。前言代码写完了怎么确保质量传统做法是自己看一遍 → 提交 PR → 同事 Review → 修问题 → 再 Review这个过程慢且依赖人的状态。用 Skill 来标准化这个过程每次提交都自动经过同一套质量关卡不留死角。一、Code Review Skill1.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 注入、N1 ### 维度 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 检查 Skill2.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.xmlmodulenameCheckermodulenameTreeWalker!-- 命名规范 --modulenameMethodName/modulenameParameterName/!-- 代码长度 --modulenameMethodLengthpropertynamemaxvalue80//modulemodulenameLineLengthpropertynamemaxvalue200//module!-- 禁止语句 --modulenameAvoidStarImport/modulenameIllegalImport//module/module自动检查流程执行 Lint 检查# 前端cdfrontendpnpmexeceslint src/--fixpnpmexecprettier--checksrc/**/*.{vue,ts,js}# 后端cdasset-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()})})输出生成完整的覆盖率分析报告包含总体覆盖率概览未覆盖的高优先级代码建议补充的测试用例代码覆盖率提升路线图## 四、代码重复检测 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 组件cdfrontendpnpmexeceslint src/--ruleunicorn/filename-case: error步骤 3: 检测 SQL 重复# 查找相同的 SQL 片段grep-rnSELECT.*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 idcommonFilters 片段 轻度重复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]六、这一章的核心心得Code Review Skill 的核心是多维度——正确性、安全性、性能、可维护性缺一不可Lint 检查是基础——自动化代码规范检查减少人工争论测试覆盖率要有底线——80% 行覆盖率是一个合理的最低标准重复代码检测能省很多事——DRY 原则不是口号是实实在在的可维护性提升综合质量关卡最有价值——把多个检查 Skill 编排在一起成为代码合并的守门员评分标准要量化——90 分以上放行75-89 建议修改低于 75 打回重改七、下一步代码质量有保障了接下来还有一个高频需求——文档。代码写好了要写 API 文档功能做完了要写用户手册版本发布了要写 Changelog。这些 repetitive 的文字工作同样可以用 Skill 来自动化。下一篇我们将编写文档生成 Skill。系列目录初识 Skill 系统——什么是 Skill为什么需要 Skill自定义 Skill 开发——从 0 到 1 编写自己的 SkillSkill 编排与组合——多个 Skill 串联工作打造自动化流程实战 SkillDevOps 部署——编写 Docker/Nginx/CI-CD 相关的部署 Skill实战 Skill代码质量——编写 Code Review / Lint / 测试覆盖率 Skill← 本篇实战 Skill文档生成——编写 API 文档 / 技术手册 / Changelog 生成 Skill待写Skill 分享与复用——团队共享 Skill 库、开源 Skill 生态、版本管理待写Skill 进阶技巧——条件触发、多语言支持、与 Agent/Workflow 的配合待写
