自动化代码质量：使用 Claude Skills 编写、修复和审查测试

手动代码质量工作的隐性成本

每个工程团队都在每个迭代中花费大量时间在感觉必要但永远做不完的工作上：为新代码编写测试、修复重构后中断的测试以及在合并前审查 Pull Request。这些不是可选活动——它们是团队维护对代码库信任的方式。但手动完成时，它们既慢又不一致，而且是截止日期紧迫时第一个被削减的事情。

Claude Skills 直接解决了这个问题。一小组专用 skills——write-tests、fix-tests、review-pr 和 review-local-changes——构成了一个完整的代码质量自动化层，在您的本地机器上通过 Claude Code 运行。它们共同处理质量循环中最耗时的部分，让您的团队专注于真正需要人类判断的决策。

本指南将介绍每个 skill 的工作方式、它们如何配合，以及如何将它们集成到能更快交付更高质量代码的开发工作流中。

---

write-tests：规模化自动测试生成

write-tests skill 解决了任何代码库中最常见的差距：代码在没有足够测试覆盖的情况下发布，因为编写测试几乎和编写功能本身一样耗时。

当您运行 /write-tests 时，该 skill 首先发现您的测试基础设施。它读取您现有的测试配置文件（jest.config.js、pytest.ini、go.mod 或等效文件），识别已经使用的测试模式，并映射您想要覆盖的文件。这个发现阶段意味着生成的测试与您的团队已经建立的约定匹配——相同的文件命名、相同的断言风格、相同的 mock 模式。

发现后，write-tests 派遣并行子智能体为范围内的每个模块或函数编写测试。因为智能体并行运行，覆盖 10 个文件的模块所需的时钟时间大致与覆盖一个文件相同。每个智能体接收被测函数的完整上下文、作为风格参考的现有测试，以及明确的指令来测试边界情况、错误路径和边界条件——而不仅仅是正常路径。

输出是一组您可以审查、运行和提交的测试文件。该 skill 不会发明行为；它从代码中的实际函数签名和文档字符串推导测试。如果某个函数在边界处的行为不明确，生成的测试会暴露这种模糊性，这本身就是有用的信息。

# 示例：对特定模块运行 write-tests
# 在 Claude Code 中，安装 skill 后：
/write-tests src/payments/processor.ts

# 该 skill 将：
# 1. 从项目配置中自动检测 Jest + TypeScript
# 2. 分析 processor.ts：函数、类型、错误处理
# 3. 派遣并行智能体进行单元 + 集成测试
# 4. 编写 src/payments/processor.test.ts
# 5. 运行测试套件验证所有新测试通过

对于拥有遗留代码库的团队，write-tests 在覆盖率改善冲刺期间特别有用，可以指向特定目录。与其手动为数百个函数编写测试，您将 skill 指向一个目录，审查输出，然后迭代。

---

fix-tests：系统性修复失败的测试套件

重构会破坏测试。依赖升级会破坏测试。即使是简单的重命名也可能级联导致十几个失败的规范。fix-tests skill 正是为这种情况而存在的。

该 skill 从自动发现开始：它运行您的测试套件，收集所有失败的测试，并按失败类型分组——断言不匹配、缺少 mock、类型错误、更改的 API 签名。分组很重要，因为大多数损坏的测试套件只有少数根本原因；修复一种类型的故障通常会解决一组测试。

分组后，fix-tests 派遣并行智能体修复每个故障类。每个智能体接收失败的测试、测试输出和相关的源代码。智能体的目标是修复测试而不更改生产代码——这个约束迫使修复反映系统的实际新行为，而不是通过削弱断言来让测试通过。

智能体完成修复后，该 skill 再次运行完整套件进行验证。如果出现新的故障（修复的罕见但可能的副作用），它会运行另一个修复周期。结果是一个干净的测试套件，准确反映代码的当前状态。

# 示例：修复重构后所有失败的测试
/fix-tests

# 输出摘要（示例）：
# 在 8 个文件中发现 23 个失败的测试
# 分组为 3 种故障类型：
#   - API 签名更改（14 个测试）
#   - 缺少 mock 设置（6 个测试）
#   - 类型断言错误（3 个测试）
# 派遣 3 个并行修复智能体...
# 重新运行套件：0 个失败
# 所有测试通过。提交前请审查更改。

一个关键的设计选择：fix-tests 拒绝删除测试或削弱断言来让套件通过。如果一个测试确实无法在不更改断言的情况下修复，该 skill 会将其标记为需要人工审查，而不是默默降低覆盖率。这使得该 skill 可以安全地在 CI 中作为一个提出修复建议供人工批准的步骤运行。

---

使用 playwright-skill 进行浏览器测试

对于构建 Web 应用的团队，测试覆盖必须扩展到单元测试之外，覆盖实际的浏览器行为。playwright-skill 将浏览器自动化直接添加到 Claude Code 工作流中。

Playwright Skill 自动检测正在运行的开发服务器，消除了 E2E 测试设置中最令人沮丧的部分。您描述用户流程——登录、导航到设置、更新偏好、确认更改持久化——该 skill 会生成一个结构良好的 Playwright 测试，具有正确的选择器、断言和重试逻辑。它在每个步骤都截图，使故障易于诊断。

playwright-skill 的亮点在于覆盖难以单元测试的交互：表单验证流程、乐观 UI 更新、会话过期处理和响应式布局转换。这些场景需要真实的浏览器，该 skill 处理管道工作，让您专注于要断言什么。

---

review-local-changes 和 review-pr：多智能体代码审查

编写和维护测试只是质量故事的一半。另一半是确保到达生产环境的代码经过彻底审查。手动代码审查很有价值，但随着团队规模增长扩展性很差；审查者会产生盲点，同样类别的错误年复一年出现在事后分析中。

review-local-changes 和 review-pr 将结构化的多智能体代码审查引入 Claude Code。

两个 skills 通过并行派遣六个专业审查智能体来运作，每个智能体聚焦于不同的质量维度：

• 安全审查者：检查 OWASP Top 10 漏洞、代码中的密钥、注入风险
• 缺陷审查者：识别逻辑错误、差一错误、空引用
• 质量审查者：评估命名、结构、DRY 合规性、复杂度
• 契约审查者：验证 API 契约是否与文档和调用者匹配
• 测试审查者：识别覆盖差距和因错误原因通过的测试
• 历史审查者：根据先前修复的问题检查回归

并行执行意味着完整审查在顺序审查所需时间的一小部分内完成。所有六个智能体的发现被合并到单个报告中，去重并按严重性排序。

# 示例：review-pr 输出结构
review:
  pr_number: 142
  summary: "支付处理器重构 — 3 个严重、7 个中等、12 个低发现"
  findings:
    - severity: critical
      agent: security
      file: src/payments/processor.ts
      line: 87
      message: "用户控制的输入直接用于 SQL 查询 — 需要参数化。"
    - severity: moderate
      agent: testing
      file: src/payments/processor.test.ts
      line: 34
      message: "测试断言状态码但未断言响应体 — 部分覆盖。"
    - severity: low
      agent: quality
      file: src/payments/utils.ts
      line: 12
      message: "函数 `buildPayload` 与第 45 行的 `formatRequest` 逻辑重复。"

review-local-changes 设计用于提交前使用——您对未提交的 diff 运行它，在问题到达 PR 之前捕获它们。review-pr 与 GitHub CLI 集成，直接在 Pull Request 上发布行内评论，使发现对整个团队在他们已经审查代码的地方可见。

---

构建完整的质量工作流

这四个 skills 作为流水线一起使用时最有效：

1. 编写新代码后，运行 /write-tests 生成初始覆盖。
2. 任何重构后，运行 /fix-tests 修复任何损坏的规范。
3. 提交前，运行 /review-local-changes 及早发现问题。
4. 合并前，运行 /review-pr 发布结构化的行内评论。

这个流水线不需要外部 CI 配置，不需要额外服务，也不需要从编辑器切换上下文。每个步骤都在 Claude Code 中运行，每个步骤都产生您可以立即行动的输出。

始终采用此工作流的团队报告了两项改进：生产审查中发现的缺陷更少，每个 PR 花在重复反馈上的时间更少。重复反馈——"为错误路径添加测试"、"这个变量名不清楚"、"参数化那个查询"——转移到自动化层，让审查者专注于架构决策和业务逻辑。

对于已经使用 CI 的团队，这些 skills 是现有流水线的补充而非替代。在本地运行它们获取快速反馈，保留您的 CI 作为最终门控。

---

开始使用

从 Claude Skills Hub 下载 .md 文件并将其放在项目的 .claude/skills/ 目录（或您的全局 ~/.claude/skills/ 目录以在所有项目中使用）中来安装任何这些 skills。大多数项目不需要额外配置——这些 skills 会自动发现您的测试框架和代码结构。

如果您的覆盖率低，从 write-tests 开始；如果您有大量失败测试的积压，选择 fix-tests；如果您想要零摩擦的即时价值，选择 review-local-changes。所有四个现在都可在 Claude Skills Hub 目录 中获取。

代码质量不是开发结束时的检查点——它是工作的持续属性。这些 skills 使维护这个属性变得更容易。