错误诊断智能调试

这类问题为什么难缠

线上报错往往只有一段堆栈、间歇复现步骤和模糊的「某服务变慢」——本地能跑通，生产却持续打点。更麻烦的是，Sentry、APM、分布式追踪和日志分散在不同系统里，团队容易在「加日志再发版」和「凭直觉改一行」之间来回折腾，缺少可证伪的假设和统一的验证口径。

技能如何组织调试流程

该技能把角色定位为 AI 辅助调试专家，输入侧要求你交代 $ARGUMENTS 范围内的：错误消息/堆栈、复现步骤、受影响组件、性能特征、环境（开发/预发布/生产）以及故障是否间歇。

核心工作流可以概括为：

• 初始分类：识别错误模式、解析堆栈与依赖，给出 3～5 个带优先级的假设，并推荐调试策略（交互式、Sentry/DataDog 驱动、时间旅行录制、混沌注入或统计对比等）。
• 可观测性采集：在生产/预发布场景下，按错误追踪、APM、追踪、日志与会话回放等渠道查频率、用户面、环境差异、关联告警与部署时间线。
• 假设与策略：每个假设带概率、证据、证伪标准与测试方法；常见类别包括逻辑/竞态、状态与缓存、集成超时与认证、资源耗尽、配置漂移、数据编码等。
• 智能埋点与生产安全：建议断点/日志点位置（入口、分支、状态变更、集成边界、错误路径）；并覆盖 OpenTelemetry、按用户/采样的条件日志、只读调试端点、金丝雀流量等低侵入手段。
• 根因、修复与闭环：重建执行路径与决策点变量状态，输出修复方案（变更范围、风险、测试与回滚），再跑测试、对比性能、观察错误率，并补充回归测试、监控与运行手册。

最终报告结构固定为：问题摘要、根本原因（含证据）、修复方案、验证计划、预防措施。

适用边界

任务与错误诊断、调试无关时不要启用；它不会替代你手头的领域工具，而是把现有可观测性与调试器用法串成 checklist。需要逐步示例时可参考 resources/implementation-playbook.md。