技能介绍

生产故障里常见的那类困境

线上告警一来，往往同时堆着 Sentry 堆栈、分散的 结构化日志、用户复现步骤，以及「上周某次发布之后才开始」这类模糊线索。团队容易在改症状、猜根因、补测试之间来回切换，却缺少一条能串起 可观测性数据 → 代码变更 → 最小修复 → 回归验证 的固定路径。跨服务、跨数据库与发布窗口交织的问题，更需要有人专门做上下文传递，而不是每个角色各查各的。

技能如何组织这条流水线

本技能描述的是基于 多智能体编排 的智能化问题求解工作流，把调试与修复拆成四个阶段，并明确各阶段由哪类智能体承担：

问题分析：错误侦探与调试器智能体读取错误追踪、日志、复现步骤与可观测性数据，梳理故障上下文及上下游影响。
根因调查：调试器与代码审查智能体做深度代码分析，可配合 自动 git bisect 定位引入提交，并做依赖兼容性与状态检查，隔离具体失效机制。
修复实施：按栈调用领域智能体（如 python-pro、typescript-pro、rust-expert 等），实施 最小修复，并补齐单元、集成与边界用例，遵循生产安全实践。
验证：测试自动化与性能工程智能体跑回归套件、性能基准与安全扫描，确认未引入新问题。

复杂问题可在 database-optimizer → performance-engineer → devops-troubleshooter 等专家智能体之间编排，通过共享状态显式传递上下文。工作流强调理解根因而非治标，并可通过增强监控与告警把同类问题尽早暴露。

适用边界

适合：需要按阶段推进的 生产事故排查与修复、希望结合现代可观测性与 AI 代码助手（如 GitHub Copilot、Claude Code）与 OpenTelemetry / DataDog / Sentry 等数据的调试策略。
不适合：与多智能体事故响应无关的泛化开发任务，或必须依赖本技能未覆盖的外部工具链且无法映射到上述四阶段的情况。
执行前宜明确目标、约束与输入；细节模式与示例见技能包内 resources/implementation-playbook.md。