Sherlock · Quarterly Impact
Quarterly Impact · 2026.04.12—2026.07.12
设立 Sherlock 时，我们希望它不只回答问题，而是能处理信息不完整、系统边界复杂、需要工程判断的研发工作。这个季度，它已经多次在 Slack 中与同事一起把调查推进到实现、验证和 PR。
在任意 Slack 频道 @Sherlock，或直接私聊它。先说明现象和期望交付，再选择你希望它推进到哪一步。
给出可复核的证据链、根因、影响范围，以及当前仍不能证明的部分。
回读历史契约和调用链，给出兼容方案、回归点与发布风险。
明确授权后进入独立 worktree，实现、测试、跑 hooks、提交 PR 并回读 CI。
@Sherlock 现象：发生了什么，期望行为是什么 范围：商家 / 用户 / 时间 / requestId / 相关链接 期望交付：根因与证据链 / 修复方案 / 推进到 PR
Sherlock 能把工作推进到结果，不只因为模型更强，而是本季度把入口、证据、交付和可观测性做成了稳定能力。
频道 @ 与 DM 之外，CS、Datadog、Sentry listener 可以自动触发调查。
联合 Jira、日志、Trace、Redshift、GrowthBook、代码和历史 PR。
独立 worktree、测试、hooks、授权边界，以及 PR 与 CI 验证结果。
Transcript、会话、运行时长、工具、模型与用量统一归档，可以复算。
比运行量更重要的是主动使用者。频道里统计真实用户发送的 @Sherlock 消息；私聊从本地任务 session 识别用户；两种入口按 Slack ID 去重。
用户数按可映射的 Slack ID 统计；有 1 个历史 DM channel 无法映射到对端用户，因此报告期内至少有 58 位真实用户，各月实际活跃用户也可能更多。07/12 为刷新时点内的部分日。
这里同时展示每周运行次数与每周活跃会话。前者代表工作强度，后者代表正在协作的真实任务面。
统计窗口统一为东八区周一 00:00 到下周一 00:00。旧 runtime 清理后最早可恢复运行在 04/15，因此 04/13 当周不进入工作量比较；最近四周均值只使用完整可观测周。
| 统计对象 | 数量 | 总值 | 平均 | 中位 | P90 |
|---|---|---|---|---|---|
| 有 duration 的运行 | 3,631 | 275.1 h | 4分33秒 | 2分58秒 | 10分09秒 |
| 至少一条有 duration 的会话 | 1,370 | 275.1 h | 12分03秒 | 7分30秒 | 26分55秒 |
同一个 session 中有多次 run 时，只累加其中有 duration 的记录。缺失 duration 的 run 不进入总值、平均值、中位数或 P90；因此这里只展示已记录到的 275.1 小时，实际运行时间可能更多。
日均值 = 275.0990 小时 ÷ 73 个自然日；没有用覆盖率对总时长做放大估算。
代表性工程交付不以“开了 PR”为终点。生产证据、正确实现、回归验证、评审反馈和最终合并，缺一项都不能写成已交付。
把 Jira 截图、生产数据、Datadog 请求与 Customer merge 代码串成一条证据链，证明空姓名来自 existing-client profile merge；随后修改 blank-name 保护逻辑并补回归测试。
问题从“前端必填失效”被改写为准确的后端覆盖缺陷；修复通过测试、3 位工程师批准，并于 06/10 合并。
从 CS 现象追到 BFF 更新接口：字段已被接收却没有写入。实现持久化后，又根据 review 补上 company ownership 校验与合法、非法 business 的回归测试。
灰度环境由同事验证恢复；最终改动保留持久化和跨租户保护，人工批准、CI 通过并于 07/02 合并。
代表性案例可以是已合并交付，也可以是复杂分析闭环；凡展示 PR，均已确认合并且关键改动保留。点击标题可回到原 Slack 对话。
复杂链路里，第一次判断不一定正确。Sherlock 的价值也体现在吸收领域专家纠正、重查事实，并把共识推进为可验证的双端交付。
跨仓回读已有 gateway 方案与 Mobile 初始化顺序，接入 GrowthBook feature、默认回退和测试，并把能力边界收敛为 App 重启或重新初始化后生效。
核心提交完整保留，51 个 test suites / 211 个 tests 与 CI 通过，人工批准后于 06/26 合并；报告不把它描述成运行中实时切流。
最初选错生产分支和 tier 数据源；同事指出领域事实后，Sherlock 重新核对 feature-caliber、新 DWS tier 表、重复 company 风险和 SQL 行扩张，再同步修正 profile 服务与数仓任务。
两个 PR 均获人工批准并合并；最终验证 31,595 行对应 31,595 个 distinct business，重复、非法 tier 与 tag/column mismatch 都为 0。
当错误只在少数用户、少数时序出现时，单看一段代码很容易误判。这里的关键是把状态变化、身份迁移和人类反例放到同一条时间线上。
沿 selected payment method、Form state 与默认选卡逻辑定位竞态；再根据同事反馈多轮缩小 diff、验证 Stripe/feature flag 边界，并补观测日志。
最终幂等 resync 逻辑与映射测试保留，CI 通过、人工批准并于 06/29 合并。
在长对话里逐步排除前端 saveCard 和宽泛 webhook 写回；同事提供 customerId 反例后，Sherlock 把日志与代码对齐到 lead→customer merge：订单已指向 canonical customer，但 pay 请求仍携带旧 source ID。
根因与安全修复边界被收敛到 Online Booking 支付入口使用 order customerId；没有把仍未合并的后续 PR 写成已交付成果。
国家范围、room 遍历顺序这类局部条件，足以让表面合理的逻辑产生错误结果。Sherlock 用 fallback、最小反例和历史回溯把边界显式化。
从线上地址漂移追到共享导航层的 placeId 选择逻辑；review 指出历史 UK 数据可能缺 country 后，又补上严格的地址文本 fallback。
单一 Sherlock commit 完整保留，CI 通过、两位工程师批准并于 06/26 合并。
把两层 capacity gate 按真实测试数据逐步演算；同事继续提供测试结果后，Sherlock 证明修复第二层仍会在第一层提前失败，并区分历史引入 commit 与近期暴露条件。
团队拿到可复现 corner case、准确历史和修复方向；人类在 thread 中确认“原来还和 room 顺序有关”，关联 CS 与工程单均已关闭。
物理重建、配置删除和事后修改会抹去现场。Sherlock 把时间线、写路径和历史状态重新拼回去，同时清楚标出哪些事实已经证明、哪些无法追溯。
同事用 2/17 与 5/8 的 90 分钟记录否定了最初的 snapshot 解释；Sherlock 随即重查写路径，发现 saveCustomerService 会物理删除再插入，当前行没有可追溯 ID，且时间模式符合批量重建。
机制层根因与审计盲区被证明：历史 duration 可能在重建时丢失，但现有数据不能可靠归因到具体操作者，因此没有制造确定性结论。
从 Sentry stack 与 source map 定位 Pet Code option renderer，再回看 workflow 历史：步骤保存了 Pet Code ID，两分钟后该 Pet Code 不再可用，随后触发悬空引用崩溃。
一次运行内完成事件、源码与历史状态闭环，并明确区分事故发生时的配置与后来已经变化的 workflow 当前状态。
CS 有稳定入口、明确时间戳和可追踪结果，所以适合作为趋势样本；它只是 Sherlock 工作的一部分。Jira 数据更新至 2026-07-12 21:03 SGT。
完整统计口径、复用与留存明细、结论被采用情况和满意度测量说明见 docs/指标口径.md。案例证据与链接见 data/cases/case-evidence-ledger.json。报告由本目录中的数据与脚本生成。