名称

sherlock-review

描述

“使用演绎推理进行证据基础的调查代码审查，以确定实际发生的情况与声称的情况之间的差异。用于验证实现声称、调查bug、确认修复或进行根本原因分析。通过系统观察找到真理的基本方法。” category: quality-review priority: high tokenEstimate: 1100 agents: [qe-code-reviewer, qe-security-auditor, qe-performance-validator] implementation_status: optimized optimization_version: 1.0 last_optimized: 2025-12-03 dependencies: [] quick_reference_card: true tags: [investigation, evidence-based, code-review, root-cause, deduction]

夏洛克审查

<default_to_action> 在调查代码声称时：

观察：收集所有证据（代码、测试、历史、行为）
推理：证据实际显示什么 vs 声称是什么？
排除：排除不可能的情况
结论：证据是否支持声称？
文档：记录发现，基于证明而非假设

三步调查法：

# 1. 观察：收集证据
git diff <commit>
npm test -- --coverage

# 2. 推理：比较声称与现实
# 代码是否匹配描述？
# 测试是否证明修复/功能？

# 3. 结论：基于证据的判决
# 支持 / 部分支持 / 不支持

夏洛克原则：

“数据！数据！数据！” - 收集数据后再做结论
“排除不可能” - 什么是不能为真的？
“你看，但不观察” - 运行代码，而不只是阅读
只信任可复现的证据 </default_to_action>

快速参考卡

证据收集清单

类别	检查什么	如何检查
声称	PR描述、提交消息	仔细阅读
代码	实际文件变更	`git diff`
测试	覆盖率、断言	独立运行
行为	运行时输出	本地执行
时间线	事件发生时间	`git log`, `git blame`

判决级别

判决	含义
✓ 真	证据完全支持声称
⚠ 部分真	声称准确但不完整
✗ 假	证据与声称矛盾
? 无意义	声称不适用于上下文

调查模板

## 夏洛克调查：[声称]

### 声称
"[PR/提交声称要做什么]"

### 证据检查
- 代码变更：[文件、行数]
- 添加的测试：[数量、覆盖率]
- 观察的行为：[实际发生的情况]

### 推理分析

**声称**：[具体断言]
**证据**：[你发现的内容]
**推理**：[逻辑结论]
**判决**：✓/⚠/✗

### 发现
- 有效的内容：[附带证据]
- 无效的内容：[附带证据]
- 缺失的内容：[实现/测试中的空白]

### 建议
1. [基于发现的行动]

调查场景

场景1：“这修复了Bug”

步骤：

在修复前的提交上重现bug
在修复后的提交上验证bug是否消失
检查修复是否解决根本原因或症状
测试不在原始报告中的边缘案例

红旗警告：

只是移除错误日志的修复
仅适用于特定测试案例
绕过而非根本原因修复
未添加回归测试

场景2：“性能提升50%”

步骤：

在基准提交上运行基准测试
在优化后的提交上运行相同基准测试
在相同条件下比较
验证测量方法

红旗警告：

只在玩具数据上测试
不同的比较条件
未提及权衡

场景3：“处理所有边缘案例”

步骤：

列出代码路径中的所有边缘案例
检查每个案例的测试覆盖率
测试边界条件
验证错误处理路径

红旗警告：

catch {} 隐藏错误
通用错误消息
未记录关键错误

示例调查

## 案例：PR #123 "修复异步处理程序中的竞态条件"

### 检查的声称：
1. "消除竞态条件"
2. "添加互斥锁"
3. "100%线程安全"

### 证据：
- 文件：src/handlers/async-handler.js
- 变更：添加`async/await`，移除回调
- 测试：2个新测试用于异步流程
- 覆盖率：85%（原为75%）

### 分析：

**声称1："消除竞态条件"**
证据：添加`await`到顺序操作。无实际互斥锁。
推理：通过移除并发避免竞态，而非同步。
判决：⚠ 部分真（解决方式与声称不同）

**声称2："添加互斥锁"**
证据：无互斥库、无锁变量、无同步原语。
判决：✗ 假

**声称3："100%线程安全"**
证据：JavaScript是单线程。未使用工作线程。
判决：? 无意义（在此上下文中无意义）

### 结论：
修复有效但原因与声称不同。通过使操作顺序进行来避免竞态条件，而非添加同步。

### 建议：
1. 更新PR描述以准确反映解决方案
2. 添加并发请求处理测试
3. 移除错误的技术声称

代理集成

// 证据基础的代码审查
await Task("夏洛克审查", {
  prNumber: 123,
  claims: [
    "修复内存泄漏",
    "提升性能30%"
  ],
  verifyReproduction: true,
  testEdgeCases: true
}, "qe-code-reviewer");

// Bug修复验证
await Task("验证修复", {
  bugCommit: 'abc123',
  fixCommit: 'def456',
  reproductionSteps: steps,
  testBoundaryConditions: true
}, "qe-code-reviewer");

代理协调提示

内存命名空间

aqe/sherlock/
├── investigations/*   - 调查报告
├── evidence/*         - 收集的证据
├── verdicts/*         - 声称判决
└── patterns/*         - 常见欺骗模式

舰队协调

const investigationFleet = await FleetManager.coordinate({
  strategy: 'evidence-investigation',
  agents: [
    'qe-code-reviewer',        // 代码分析
    'qe-security-auditor',     // 安全声称验证
    'qe-performance-validator' // 性能声称验证
  ],
  topology: 'parallel'
});

记住

“在获得数据之前进行理论化是重大错误。” 只信任可复现的证据。不要信任提交消息、文档或"在我的机器上工作"的说法。

夏洛克标准： 每个声称必须经验性地验证。证据实际显示什么？

夏洛克审查Skill sherlock-review

夏洛克审查

快速参考卡

证据收集清单

判决级别

调查模板

调查场景

场景1：“这修复了Bug”

场景2：“性能提升50%”

场景3：“处理所有边缘案例”

示例调查

代理集成

代理协调提示

内存命名空间

舰队协调

相关技能

记住