/debug

如果您看到不熟悉的占位符或需要检查哪些工具已连接,请参阅 CONNECTORS.md

运行结构化调试会话,系统性地查找和修复问题。

用法

/debug $ARGUMENTS

工作原理

┌─────────────────────────────────────────────────────────────────┐
│                       调试                                         │
├─────────────────────────────────────────────────────────────────┤
│  第 1 步:复现                                                      │
│  ✓ 理解预期行为 vs 实际行为                                         │
│  ✓ 确定精确的复现步骤                                               │
│  ✓ 确定范围(何时开始?影响谁?)                                    │
│                                                                     │
│  第 2 步:隔离                                                      │
│  ✓ 缩小到具体组件、服务或代码路径                                    │
│  ✓ 检查最近的变更(部署、配置更改、依赖)                             │
│  ✓ 审查日志和错误消息                                                │
│                                                                     │
│  第 3 步:诊断                                                      │
│  ✓ 形成假设并验证                                                   │
│  ✓ 追踪代码路径                                                     │
│  ✓ 识别根本原因(不仅仅是症状)                                      │
│                                                                     │
│  第 4 步:修复                                                      │
│  ✓ 提出带解释的修复方案                                             │
│  ✓ 考虑副作用和边界情况                                             │
│  ✓ 建议防止回归的测试                                               │
└─────────────────────────────────────────────────────────────────┘

我需要您提供什么

告诉我问题。以下任何信息都有帮助:

输出

## 调试报告:[问题摘要]

### 复现
- **预期**:[应该发生什么]
- **实际**:[实际发生了什么]
- **步骤**:[如何复现]

### 根本原因
[解释为什么会发生这个 bug]

### 修复
[需要的代码更改或配置修复]

### 预防措施
- [需要添加的测试]
- [需要部署的防护措施]

如果连接器可用

如果 ~~monitoring 已连接:

如果 ~~source control 已连接:

如果 ~~project tracker 已连接:

提示

  1. 准确分享错误消息——不要转述,确切的文本很重要。
  2. 提及变更了什么——近期的部署、依赖更新和配置变更是首要嫌疑对象。
  3. 包含上下文——"这在 staging 正常但生产环境不行"或"只影响大负载"能快速缩小范围。