Claude Code 实践(4) - 2轮修正，15分钟完成 OS 源码级问题根因排查

代码库：HyperOS 源码（MiuiTelecomm、MiuiTelephony、frameworks/opt/telephony）

结论

用 Claude Code 对一个陌生的 MIUI Telephony 代码库做根因排查。第一轮分析结论被领域专家否定，补充数据约束后第二轮找到了正确答案，并给出了被专家认可的代码修改建议。

💡

AI 做源码分析速度很快（几分钟读完三个 repo 数万行代码），但容易”局部正确、全局遗漏”。

领域专家用真实数据做约束、用工程常识做校验，是保证分析质量的关键。两者结合，能把原本可能需要几个小时的排查压缩到十几分钟。

同事反馈：CALL_TIME_OUT 打点每天约 2 亿次，成本很高。需要搞清触发逻辑，判断是否合理。涉及三个 repo 的 MIUI Telephony 定制代码，我之前没接触过这块。

第一轮：AI 分析，结论错误

让 Claude Code 全局搜索三个 repo，梳理 CALL_TIME_OUT 广播的发送方和接收方。几分钟后给出结论：“只在底层 modem 超时未响应时触发，正常通话不会触发。“分析逻辑自洽，代码引用准确，我发到了飞书。

同事看完直接否了：

“这个结论不对，我分析看看。如果当前数据量没有问题，那分析结论是不准确的。之前统计过，每天数据量在 2 亿左右，如果按这个数据，一半都是有问题的。”

2 亿次/天，和用户通话次数对齐，不可能是”异常路径”的量级。数据和结论矛盾，一定漏掉了什么。

第二轮：加数据约束，找到根因

带着”必须解释 2 亿次/天”的约束重新排查。这次让 Claude Code 从打点 key 反向追踪所有写入方，而不是从广播名正向追踪。

关键发现：代码里有两套并行的监控系统，第一轮只看到了 V2（通过广播触发，仅异常路径），漏掉了 V3（HangUpOptimize 3.0，直接写入相同打点 key，每次通话挂断都触发）。V3 把”正常完成的状态报告”和”真正的超时告警”混在一起打点，导致日均 2 亿次。

修改建议也很简单：把正常完成的分支单独拆出来，不打点。改 5 行代码，打点量预计降 95%+。

同事反馈：“基本正确，至少会起到很大效果。“但也指出了局限：“这个只是辅助，能一次性正确吗？相对非专业，需要多次问。”

同事的后续反馈

当同事得知第二轮分析的改进来自上下文提示词技巧（给 AI 加数据约束、切换搜索方向）后，反应很积极：

“你这个是自动生成的吗？有了这个就方便多了。最好还能给出优化建议。”

“我觉得这个你可以作为一个案例了。修改也是我看代码排查出来的，基本正确。”

“具体都是怎么印证的？prompt 能更新到文档吗？我学习学习，看是怎么一个流程，内部我们也学习下。“

AI 源码分析的能力边界

AI 容易陷入”局部正确、全局遗漏”。第一轮每一步都对——搜索准确、引用准确、推演自洽——但它顺着一条链路走到底就认为搞清楚了，没有反向验证”还有没有其他路径写入同一个终点”。这和人类工程师的常见错误一样，只是 AI 更依赖明确指令，不会自己切换策略。

AI + 领域专家的协作模式

这次的有效协作链路是：AI 做初步分析 → 专家用数据否定 → AI 在新约束下重新分析 → 专家确认。

AI 的优势是速度和覆盖面：几分钟内读完数万行代码，给出结构化的链路分析。专家的优势是直觉校验：看到”只在异常路径触发”就能立刻反问”那每天能触发几次？“——这种基于工程常识的量级判断，AI 不会主动做。