name: sherlock-review description: “使用演绎推理进行证据基础的调查代码审查，以确定实际发生的情况与声称的情况之间的差异。用于验证实现声称、调查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'
});
相关技能
- brutal-honesty-review - 直接技术批评
- context-driven-testing - 适应上下文
- bug-reporting-excellence - 文档发现
记住
“在获得数据之前进行理论化是重大错误。” 只信任可复现的证据。不要信任提交消息、文档或"在我的机器上工作"的说法。
夏洛克标准： 每个声称必须经验性地验证。证据实际显示什么？