CI 流水线把 PR diff 和源文件发给 Claude 要测试建议。8 个建议中 5 个已经在测试套件中存在了。流水线没有把已有测试文件包含在上下文中。
看不到什么已经被测试了，Claude 只基于源代码生成测试。最显而易见的测试场景——任何称职的开发者首先会写的——恰恰是现有套件已经覆盖的。
修复：把已有测试作为上下文提供
| 方法 | 重复率 | 新颖边缘情况 | 每建议审查时间 |
|---|---|---|---|
| 无已有测试在上下文中 | 60% | 15% | 3 分钟 |
| 已有测试在上下文中 | 8% | 65% | 1 分钟 |
上下文成本：每 PR 约 500 额外 token。回报：重复减少 87%，新颖边缘情况增加 4 倍，审查速度提升 67%。
当 Claude 能看到什么已经被测试了，它跳过已覆盖场景聚焦于真正的缺口——未覆盖的边缘情况、错误路径、边界条件。这不是去重引擎。Claude 只是读已有测试然后自然避免重复它们。
大型测试套件
500+ 测试跨 40 个文件的代码库不可能全部加载到上下文。方案：只提供和正在测试的模块相关的测试文件。
给 auth/permissions.ts 生成测试？包含 auth/permissions.test.ts 和任何共享测试工具。不要 API 测试、不要数据库测试、不要 UI 测试。定向上下文既充分又高效。
从代码库各处随机抽取的测试文件没有帮助——可能根本不包含 auth 测试。基于被测模块的定向选择才是正确策略。
工作流
- 提供已有测试 — 在上下文中包含模块的测试文件
- 提供源代码 — 包含被测函数或模块
- 请求缺口分析 — “为未覆盖的代码路径生成测试，避免已有测试中已覆盖的场景”
已有测试有双重用途：它们展示什么已被覆盖（避免重复），也展示团队的测试模式（保持测试风格、工具和规范的一致性）。
CI 流水线集成
每个 PR 的自动化测试缺口分析：
流水线步骤：
1. 识别变更的源文件
2. 找到对应的测试文件
3. 两者作为上下文传给 Claude
4. 请求未覆盖场景的测试建议CLAUDE.md 可以描述测试规范和理念，但它不能防止重复测试内容。上下文中的实际测试文件才提供重复避免。
不存在的东西
--no-duplicates标志 — 不是 Claude Code 特性。改在上下文中提供已有测试。- 内部去重引擎 — Claude 没有检测重复测试的特殊机制。它自然地使用上下文。
- 自动检测已有测试 — 流水线必须显式包含测试文件。Claude 不会自动发现或读取它们除非它们在上下文中。
一句话总结： 请求新测试时在上下文中包含已有测试文件——重复从 60% 降到 8%，Claude 把精力重定向到 65% 真正新颖的边缘情况建议上。