Quarterly Impact · 2026.04.12—2026.07.15
Sherlock：复杂研发工作，
已经可以交给它
设立 Sherlock 时，我们希望它不只回答问题，而是能处理信息不完整、系统边界复杂、需要工程判断的研发工作。这个季度，它已经多次在 Slack 中与同事一起把调查推进到实现、验证和 PR。
至少 61 位报告期内的真实用户数
51 位单月最高活跃用户数（6月）
4月 21 · 5月 26 · 6月 51
32.5 / 天最近 28 天，真实用户主动 @Sherlock
327.8 h4,004 次有 duration 的运行实测累计值
它最有价值的地方： 把原本散落在代码、日志、数据、工单和历史决策中的路径接起来，让同事更快拿到可以继续行动的结论。
在任意 Slack 频道 @Sherlock，或直接私聊它。先说明现象和期望交付，再选择你希望它推进到哪一步。
01只调查给出可复核的证据链、根因、影响范围，以及当前仍不能证明的部分。
02给修复方案回读历史契约和调用链，给出兼容方案、回归点与发布风险。
03推进到 PR明确授权后进入独立 worktree，实现、测试、跑 hooks、提交 PR 并回读 CI。
可直接复制的任务模板@Sherlock
现象：发生了什么，期望行为是什么
范围：商家 / 用户 / 时间 / requestId / 相关链接
期望交付：根因与证据链 / 修复方案 / 推进到 PR
只读调查Jira、日志、Trace、数据和代码查证可自主执行。
代码交付独立 worktree、测试与 hooks；commit / push / PR 需要明确授权。
高风险操作生产写入、数据修复、权限变更仍由人确认。
Sherlock 能把工作推进到结果，不只因为模型更强，而是本季度把入口、证据、交付和可观测性做成了稳定能力。
01 · ENTRY从人类提问扩展到事件驱动频道 @ 与 DM 之外，CS、Datadog、Sentry listener 可以自动触发调查。
02 · EVIDENCE跨系统建立证据网络联合 Jira、日志、Trace、Redshift、GrowthBook、代码和历史 PR。
03 · DELIVERY安全地推进到工程交付独立 worktree、测试、hooks、授权边界，以及 PR 与 CI 验证结果。
04 · TELEMETRY让运行与质量可以复盘Transcript、会话、运行时长、工具、模型与用量统一归档，可以复算。
开发者真正构建的价值： 把一次性的排查经验，变成可以持续触发、联合查证、安全交付并被量化改进的系统能力。
比运行量更重要的是主动使用者。频道里统计真实用户发送的 @Sherlock 消息；私聊从本地任务 session 识别用户；两种入口按 Slack ID 去重。
至少 61报告期内总用户数
54在频道里 @Sherlock 的用户
37私聊用户 · 231 个任务
增长之外，更重要的是复用： 报告期内 48 / 61 位用户至少在两个不同日期使用；5 月的 26 位用户在 6 月全部再次使用。
用户数按可映射的 Slack ID 统计；有 1 个历史 DM channel 无法映射到对端用户，因此报告期内至少有 61 位真实用户，各月实际活跃用户也可能更多。
这里同时展示每周运行次数与每周活跃会话。前者代表工作强度，后者代表正在协作的真实任务面。
591最近四个完整周 · 平均每周运行
250最近四个完整周 · 平均活跃会话
785 / 29706/22 当周运行 / 活跃会话
统计窗口统一为东八区周一 00:00 到下周一 00:00。旧 runtime 清理后，现有运行记录从 04/15 开始，04/13 当周数据不完整，因此不进入工作量比较；最近四周均值只使用完整可观测周。
327.8 h4,004 次有 duration 的运行累计值
4小时19分05/01—07/15 · 76 个自然日的日均实测运行量
| 统计对象 | 数量 | 总值 | 平均 | 中位 | P90 |
|---|
| 有 duration 的运行 | 4,004 | 327.8 h | 4分55秒 | 3分02秒 | 11分02秒 |
| 至少一条有 duration 的会话 | 1,509 | 327.8 h | 13分02秒 | 7分52秒 | 28分31秒 |
同一个 session 中有多次 run 时，只累加其中有 duration 的记录。缺失 duration 的 run 不进入总值、平均值、中位数或 P90；因此这里只展示已记录到的 327.8 小时，实际运行时间可能更多。
76 天05/01—07/15 的自然日跨度
684个会话包含多个有时长 run
1,509个会话至少有一条时长记录
日均值 = 327.7976 小时 ÷ 76 个自然日；没有用覆盖率对总时长做放大估算。
代表性工程交付不以“开了 PR”为终点。生产证据、正确实现、回归验证、评审反馈和最终合并，缺一项都不能写成已交付。
01根因到合并修复2026-06-01—2026-06-10
问题背景一位新访客完成线上预约并预付后，预约和客户档案里的姓名却都是空白。支持人员无法在页面上复现，因为表单明明要求必须填写姓名；商家因此担心异常预约甚至欺诈。
Sherlock 做了什么把 Jira 截图、生产数据、Datadog 请求与 Customer merge 代码串成一条证据链，证明空姓名来自 existing-client profile merge；随后修改 blank-name 保护逻辑并补回归测试。
推进结果问题从“前端必填失效”被改写为准确的后端覆盖缺陷；修复通过测试、3 位工程师批准，并于 06/10 合并。
替同事省下的路径跨 Jira、数仓、日志、Online Booking 与 Customer 服务对齐同一预约，再完成实现、测试和评审跟进。
Session 实测运行1 小时 07 分
替代的人工串联跨系统对齐 + 修复交付
02根因到安全交付2026-07-02
问题背景支持人员在 Lead 档案里修改“首选门店”后，界面看似提交成功，刷新后却仍是旧值。这个字段决定 Lead 归属，修复时还必须防止把 Lead 指向不属于当前公司的门店。
Sherlock 做了什么从 CS 现象追到 BFF 更新接口：字段已被接收却没有写入。实现持久化后，又根据 review 补上 company ownership 校验与合法、非法 business 的回归测试。
推进结果灰度环境由同事验证恢复；最终改动保留持久化和跨租户保护，人工批准、CI 通过并于 07/02 合并。
替同事省下的路径对齐接口 schema、服务写路径与租户边界，在修复主缺陷后继续收敛 review 暴露的安全风险。
Session 实测运行35 分 46 秒
替代的人工串联写路径追踪 + 权限边界补全
代表性案例可以是已合并交付，也可以是复杂分析闭环；凡展示 PR，均已确认合并且关键改动保留。点击标题可回到原 Slack 对话。
复杂链路里，问题常常不在单个接口，而在初始化顺序、共享包和宿主应用之间的契约。Sherlock 把这些分散边界推进成可验证、可回退的工程交付。
03跨端控制面2026-06-23—2026-06-26
问题背景一位移动美容商家在信号较弱的拖车里无法加载首页、日程和客户信息，短信和其他应用却能正常使用；问题持续数月，已经影响联系客户和日常经营。团队需要能够灰度切换并安全回退的移动 API 入口。
Sherlock 做了什么跨仓回读已有 gateway 方案与 Mobile 初始化顺序，接入 GrowthBook feature、默认回退和测试，并把能力边界收敛为 App 重启或重新初始化后生效。
推进结果核心提交完整保留，51 个 test suites / 211 个 tests 与 CI 通过，人工批准后于 06/26 合并；报告不把它描述成运行中实时切流。
替同事省下的路径同时梳理配置控制面、客户端初始化时序、历史 gateway 约定与降级路径，再验证产品边界。
Session 实测运行36 分 43 秒
替代的人工串联跨仓方案复用 + 初始化契约验证
04跨层根因到双仓交付2026-06-02—2026-06-10
问题背景一个员工同时服务多个 franchise 时，浏览器明明停在 company A，收到的来电却可能属于 company B；切换 company 后表现又会变化。问题间歇发生，最初很容易被归因于 Twilio、浏览器缓存或用户操作。
Sherlock 做了什么先还原 Twilio Device 与 token refresh；工程师反驳第一版共享 identity 假设后，继续用 Datadog 证明页面仍在 A、token identity 已变成 B，并追到共享 call-center 包自己创建 HttpClient、绕过宿主 tab-local context。两版局部方案被否定后，最终收敛为共享包注入并复用宿主网络栈。
推进结果Sherlock 推进调查与双仓实现，Xiaoyang 校准抽象并参与 Boarding 端提交；两个 PR 均获人工批准并于 06/10 合并，QA 复现旧问题后验证修复。
替同事省下的路径跨页面状态、共享包、HTTP client、company context、Twilio token 与双仓实现反复对齐，再完成 QA 验证。
Session 实测运行1 小时 02 分 37 秒
替代的人工串联跨层取证 + 架构纠错 + 双仓交付
隐藏按钮不等于服务端拒绝写入，地址文本正确也不等于 placeId 可以跨国家复用。Sherlock 把隐含约束落实为服务端防线和兼容性修复。
05服务端授权闭环2026-05-21
问题背景受限员工在界面上看不到“新增客户”按钮，却仍能直接调用 BFF 写接口创建或修改客户资料。界面权限看似生效，服务端实际上没有阻止写入。
Sherlock 做了什么区分 authentication、UI capability 与 server-side authorization，定位 createClient 缺少 addNewClient 权限校验并完成首修。Lishen 在人工 Review 中发现相邻两个写接口仍有同类缺口，Sherlock 采纳意见，补齐实现和回归测试。
推进结果首个端点由 Sherlock 定位并修复，相邻 attack surface 由 Lishen 扩展；最终 PR 获人工批准、于 05/21 合并并发布。
替同事省下的路径从 UI 绕过复现走到服务端鉴权，再把人工 Review 转化为相邻写接口的完整防线。
Session 实测运行旧记录未保留
替代的人工串联鉴权分层 + 首修实现 + Review 补全
06业务边界到合并修复2026-06-26
问题背景多名移动美容员工从 MoeGo 点击 Google Maps 导航时，被带到错误地址；同一批客户使用 Apple Maps 却正常。错误地址会直接造成迟到或上门失败。
Sherlock 做了什么从线上地址漂移追到共享导航层的 placeId 选择逻辑；review 指出历史 UK 数据可能缺 country 后，又补上严格的地址文本 fallback。
推进结果单一 Sherlock commit 完整保留，CI 通过、两位工程师批准并于 06/26 合并。
替同事省下的路径复盘多地图 provider 的参数语义、历史地址兼容性和 fallback，再把修复限制在正确国家范围。
Session 实测运行34 分 38 秒
替代的人工串联Provider 语义对齐 + 历史数据兼容
room 遍历顺序会改变容量结果，loading 也可能在没有请求时出现。Sherlock 用最小反例、Network 证据和状态机建模，把误导性的表面现象还原成真实执行路径。
07复杂业务规则反证2026-06-29
问题背景商家的 Daycare 明明还有容量，两只宠物分别预约都能看到可用服务，但一起选择就显示“No availability”。客户只能拆成两笔订单，或让员工手动代订。
Sherlock 做了什么把两层 capacity gate 按真实测试数据逐步演算；同事继续提供测试结果后，Sherlock 证明修复第二层仍会在第一层提前失败，并区分历史引入 commit 与近期暴露条件。
推进结果团队拿到可复现 corner case、准确历史和修复方向；人类在 thread 中确认“原来还和 room 顺序有关”，关联 CS 与工程单均已关闭。
替同事省下的路径重建容量公式、制作最小数据、逐分支执行并回溯 git 历史，才能从配置猜测走到可复现结论。
Session 实测运行11 分 37 秒
替代的人工串联公式演算 + 历史回溯 + 反例验证
08前端状态机到合并修复2026-07-14
问题背景在 Boarding 的 Split Lodging 页面新增第二段住宿后，房间下拉一直显示 Loading。界面看起来像请求卡住，但日期范围尚未完整时，当前分段其实根本不会发起房间列表请求。
Sherlock 做了什么从截图、Network、SelectRoom、公共 useQuery 和版本历史逐层反证，证明 query condition 为 false 时请求未发送，但 hook 初始 loading=true 被组件直接透传。随后用 canFetchLodgings 约束 loading 语义，并补日期不完整、日期完整两条组件回归用例。
推进结果Sherlock 完成调查、实现、测试、commit、push 和 PR；业务代码只改 9 行并新增 2 个组件测试，相关 29 个测试、类型、lint、hooks 与 CI 通过，PR 获人工批准并于 07/14 合并。
替同事省下的路径先证明请求没有发生，再区分“未启用”与“正在加载”，用局部状态门控避免改变全局 hook 语义。
Session 实测运行34 分 41 秒
替代的人工串联状态机取证 + 最小修复 + 完整验证
物理重建会抹去历史，旧请求也可能污染当前界面。Sherlock 一边守住无法追溯的证据边界，一边把搜索重构为由 query identity 隔离状态的协作实现。
09历史状态与审计边界2026-07-07
问题背景商家在 7 月 2 日调价后发现，多只宠物原本自定义的服务时长从预约和客户档案中消失，影响美容师排期。团队需要判断数据能否恢复，并追查是什么操作造成了变化。
Sherlock 做了什么同事用 2/17 与 5/8 的 90 分钟记录否定了最初的 snapshot 解释；Sherlock 随即重查写路径，发现 saveCustomerService 会物理删除再插入，当前行没有可追溯 ID，且时间模式符合批量重建。
推进结果机制层根因与审计盲区被证明：历史 duration 可能在重建时丢失，但现有数据不能可靠归因到具体操作者，因此没有制造确定性结论。
替同事省下的路径把跨月份反例、数据库当前行和服务写入语义对齐，同时区分“机制已证实”与“具体 actor 不可证”。
Session 实测运行11 分 32 秒
替代的人工串联历史数据比对 + 写路径溯源 + 结论校准
10并发模型到协作实现2026-07-13—2026-07-15
问题背景Mobile Overview 的搜索、分页、刷新和连续输入共用手写状态。旧请求还在运行时输入新关键词，latest request 会被 busy 直接丢掉；旧关键词的下一页也可能追加到当前结果。
Sherlock 做了什么两轮 Review 逐步找到结果未重置与 latest-keyword 竞态；工程师追问项目已有能力后，方案从手写 latest-wins 收敛到 TanStack Query，以 keyword、business、日期、状态和 service type 定义 query identity。获得授权后，Sherlock 完成核心重构并自审修正刷新、回第一页和重复分页。
推进结果Sherlock 贡献关键竞态发现和核心重构 commit，不是整份 feature 的作者；Jim Ye 随后继续提交 3 个交互与分页修正。最终 PR 获多人批准并于 07/15 合并。
替同事省下的路径从交互时序建模、项目内基础设施搜索到核心重构，再由原作者和 reviewer 继续完善并合并。
Session 实测运行45 分 48 秒
替代的人工串联竞态建模 + 核心重构 + 人类继续完善
CS 有稳定入口、明确时间戳和可追踪结果，所以适合作为趋势样本；它只是 Sherlock 工作的一部分。Jira 数据更新至 2026-07-17 10:58 SGT。
1,174报告期内创建的 Bug Report
913已有 resolutiondate
916StatusCategory = Done
怎么理解这张图： 较早的两个四周窗口中，同一周创建且已经关闭的工单，平均用时从 8.63 天降至 6.41 天（-25.8%）。最近几周的工单还会继续关闭，不同优先级、问题类型和团队也会影响用时，所以这里只展示同步变化，不把它写成 Sherlock 单独造成的结果。
用户、复用与任务输入
- 频道：通过 Slack 全局只读搜索，统计真实用户发送的 @Sherlock 消息。
- 私聊消息：统计 transcript 与历史消息库中的用户消息；不以运行次数代替。
- 复用按用户在不同自然日再次活跃统计；月留存按 Slack ID 跨月回访统计。
- 自动 CS 统计 Bug Report Bot 的顶层根消息，并要求至少存在一个 CS key。现有记录合计至少 4,450 次；旧 runtime 清理前的部分 DM 消息已经无法恢复，实际总数可能更多。
运行、会话与时长
- 来源：Sherlock 的会话与运行记录，统一汇总统计。现有记录至少包含 4,584 次运行和 1,820 个会话；旧 runtime 清理前的部分记录已经无法恢复，实际总数可能更多。
- 周窗口：东八区周一 00:00 到下周一 00:00；04/13 周只有 04/15 之后的部分记录，因此不进入趋势比较。
- 只统计有时长记录的运行；总值、平均、中位与 P90 都不补全缺失值。
- 05/01—07/15 日均按 76 个自然日计算。
案例与证据台账
- 来源：当前可恢复的 transcript、Slack 协作现场、运行记录与 GitHub 合并状态交叉核验。
- 标题直接链接原 Slack 对话；展示的 PR 均已合并，并确认关键改动仍然保留。
- 案例运行时长为同一 Slack 对话中所有已记录时长的合计；旧 runtime 已清理的记录不补算。
- 详细证据状态、运行时间和链接见 case-evidence-ledger.json。
Jira / CS
- 来源：通过 Jira 只读查询获取。
- 范围：04/12—07/15 创建的 CS Bug Report。
- 关闭用时：解决时间减去创建时间。
- 按工单创建所在自然周统计，只包含已有解决时间的工单。
Jira 基线： project = CS · issuetype = Bug Report · created ≥ 2026-04-12 · created < 2026-07-16。所有 Jira 数据为只读拉取，未修改工单。
完整统计口径、复用与留存明细、结论被采用情况和满意度测量说明见 docs/指标口径.md。案例证据与链接见 data/cases/case-evidence-ledger.json。报告由本目录中的数据与脚本生成。
