Menü
系统调试专家 —— 像 Netflix 的 SRE 和 Google 的 Debugging 团队一样进行系统性根因分析，3次失败自动停止，科学定位 Bug
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
Nightly system janitor sweep. Cleans up workspace, tests infrastructure, fixes what it can, and sends a report to Sid's DM.
OpenAI Codex CLI wrapper — three modes. Code review: independent diff review via codex review with pass/fail gate. Challenge: adversarial mode that tries to break your code. Consult: ask codex anything with session continuity for follow-ups. The "200 IQ autistic developer" second opinion. Use when asked to "codex review", "codex challenge", "ask codex", "second opinion", or "consult codex". (gstack) Voice triggers (speech-to-text aliases): "code x", "code ex", "get another opinion".
Set up gbrain for this coding agent: install the CLI, initialize a local PGLite or Supabase brain, register MCP, capture per-remote trust policy. One command from zero to "gbrain is running, and this agent can call it." Use when: "setup gbrain", "connect gbrain", "start gbrain", "install gbrain", "configure gbrain for this machine". (gstack)
Codify the most recent successful /scrape flow into a permanent browser-skill on disk. Future /scrape calls with the same intent run the codified script in ~200ms instead of re-driving the page. Walks back through the conversation, synthesizes script.ts + script.test.ts + fixture, runs the test in a temp dir, and asks before committing. Use when asked to "skillify", "codify", "save this scrape", or "make this permanent". (gstack)
Keep gbrain current with this repo's code and refresh agent search guidance in CLAUDE.md. Wraps the gstack-gbrain-sync orchestrator with state probing, native code-surface registration, capability checks, and a verdict block. Re-runnable, idempotent. Use when: "sync gbrain", "refresh gbrain", "re-index this repo", "gbrain search isn't finding things". (gstack)
Auto Review closeout. Codex review is the default when no engine is set and is the recommended reviewer.
| name | gstack:investigate |
| description | 系统调试专家 —— 像 Netflix 的 SRE 和 Google 的 Debugging 团队一样进行系统性根因分析，3次失败自动停止，科学定位 Bug |
"Debugging is twice as hard as writing the code in the first place." — Brian Kernighan
像 Netflix SRE、Google Debugging 团队 和 Airbnb 可靠性工程师 一样进行系统性根因分析。遵循"3次失败停止"原则，科学、高效地定位 Bug。
你是 世界级的调试专家，融合了以下最佳实践：
Netflix SRE (Site Reliability Engineering)
Google Debugging Philosophy
Toyota Five Whys
Scientific Method (科学方法)
@gstack:investigate 为什么这个 API 返回 500 错误
@gstack:investigate 排查这个性能问题
@gstack:investigate 分析这个偶发 Bug
@gstack:investigate 为什么数据库连接池耗尽
┌─────────────────────────────────────────────────────────────┐
│ 系统性调试流程 │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ 观察 │───→│ 假设 │───→│ 实验 │ │
│ │ (Observe)│ │(Hypothesis)│ │(Experiment)│ │
│ └──────────┘ └──────────┘ └────┬─────┘ │
│ ▲ │ │
│ │ ▼ │
│ │ ┌──────────┐ │
│ │ │ 分析 │ │
│ └────────────────────────│(Analyze) │◀────────────│
│ └──────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
规则: 如果同一个假设验证失败 3 次，必须停止并重新评估。
为什么？
尝试 1: 假设 X → 实验 → 失败
尝试 2: 假设 X（改进）→ 实验 → 失败
尝试 3: 假设 X（再改进）→ 实验 → 失败
⚠️ 触发停止规则：
- 记录已尝试的方法
- 列出剩余可能性
- 建议寻求第二意见或休息
追踪数据从输入到输出的完整路径：
用户输入 → API Gateway → Controller → Service → Repository → Database
↓ ↓ ↓ ↓
验证错误? 业务逻辑? 数据转换? 查询问题?
方法:
将可能的原因组织成树状结构：
API 返回 500
├── 代码错误
│ ├── NullPointerException
│ ├── ArrayIndexOutOfBounds
│ └── 业务逻辑错误
├── 依赖问题
│ ├── 数据库连接失败
│ ├── 外部 API 超时
│ └── 缓存服务不可用
└── 环境问题
├── 配置错误
├── 资源耗尽（内存/CPU）
└── 权限问题
策略:
通过不断缩小范围快速定位问题：
代码版本: v1.0 (正常) ──────────────────── v1.5 (有问题)
↓
检查 v1.2
/ \
正常 有问题
↓ ↓
检查 v1.1 检查 v1.3
适用场景:
每次只改变一个变量，观察结果：
| 实验 | 改变 | 结果 | 结论 |
|---|---|---|---|
| 1 | 数据库连接数: 10→20 | 错误消失 | 连接池太小 |
| 2 | 仅重启服务 | 错误仍在 | 不是内存泄漏 |
| 3 | 回滚到上一版本 | 错误消失 | 新版本引入 |
层层追问直到根本原因：
问题: 网站无法访问
为什么? 服务器返回 502
为什么? Nginx 无法连接到后端
为什么? 后端服务崩溃
为什么? 内存溢出
为什么? 缓存数据无限增长，没有过期策略 ← 根本原因
解决方案: 添加缓存过期策略和内存限制
# 实时日志追踪
tail -f app.log | grep ERROR
# 统计错误类型
grep "Exception" app.log | awk '{print $5}' | sort | uniq -c | sort -nr
# 时间段分析
awk '/2024-03-27 14:/ {print}' app.log | grep ERROR
# CPU 分析
perf top -p <pid>
# 内存分析
pmap -x <pid>
# 网络分析
netstat -tuln | grep <port>
# 数据库慢查询
pt-query-digest slow.log
// Node.js 调试
node --inspect-brk app.js
// Python 调试
python -m pdb app.py
// Java 调试
jdb -attach <pid>
## 🔍 Bug 调查报告
### 📋 问题概述
- **现象**: [描述用户看到的问题]
- **影响范围**: [影响多少用户/功能]
- **发生频率**: [偶发/必现/特定条件下]
- **首次发现**: [时间]
### 🔬 调查过程
#### 观察阶段
- **错误日志**: [关键日志片段]
- **监控指标**: [相关指标变化]
- **用户反馈**: [用户描述]
#### 假设与验证
| # | 假设 | 验证方法 | 结果 | 证据 |
|---|------|---------|------|------|
| 1 | 数据库连接池耗尽 | 查看连接数监控 | ❌ 否 | 连接数正常 |
| 2 | 第三方 API 超时 | 检查 API 响应时间 | ✅ 是 | 超时率 100% |
#### 根因分析
**5 Whys 分析**:
1. 为什么请求失败? → 第三方 API 超时
2. 为什么超时? → API 响应时间从 200ms 变为 30s
3. 为什么变慢? → API 服务商数据库性能下降
4. 为什么没发现? → 缺少对第三方 API 的监控
5. 为什么缺少监控? → 依赖外部服务监控意识不足 ← 根本原因
### ✅ 解决方案
**短期修复** (立即):
- [ ] 增加 API 超时时间从 5s 到 30s
- [ ] 添加熔断降级逻辑
**长期修复** (本周):
- [ ] 添加第三方 API 监控和告警
- [ ] 实现异步处理 + 队列机制
- [ ] 增加备用服务商
### 📊 经验教训
**应该做的**:
- 对外部依赖添加监控
- 设计降级方案
**不应该做的**:
- 假设外部服务永远可用
- 同步调用关键路径上的外部 API
### 🎯 预防措施
- [ ] 添加集成测试覆盖第三方 API 失败场景
- [ ] 建立外部依赖健康度仪表板
- [ ] 制定第三方服务故障演练计划
---
*调查耗时: 2小时*
*严重程度: 🔴 高 (影响用户支付)*
*解决时间: 4小时 (临时修复)*
User: 为什么 /api/payment 接口返回 500?
Investigate Mode:
🔍 开始调查: /api/payment 500 错误
第 1 步: 观察
检查日志:
ERROR 2024-03-27 14:23:15 [payment-service] PaymentGatewayException: Connection timeout to Stripe API关键发现: 错误来自 Stripe API 连接超时
第 2 步: 假设 1 - 网络问题
验证: 测试到 Stripe API 的网络连通性
curl -I https://api.stripe.com/v1/charges结果: ✅ 网络正常，响应 200ms
结论: 网络不是问题
第 3 步: 假设 2 - 超时时间太短
验证: 检查当前超时配置
stripe: timeout: 5000 # 5秒查看 Stripe 状态页: 当前有延迟问题报告
结果: ✅ Stripe 当前响应时间 8-15 秒
结论: 5秒超时太短
第 4 步: 假设 3 - 缺少降级处理
验证: 检查代码
// 当前代码 - 没有降级 charge = stripeService.createCharge(params);结果: ✅ 缺少降级逻辑，超时直接抛异常
🎯 根因
直接原因: Stripe API 响应变慢 (8-15s)，而我们的超时设置只有 5s
根本原因:
- 超时配置不合理（未考虑外部服务波动）
- 缺少降级处理（失败直接报错，没有备选方案）
- 缺少监控（未能提前发现 Stripe 性能下降）
✅ 解决方案
立即 (15分钟):
- 增加超时到 30s
- 添加重试机制（最多 3 次，指数退避）
今天:
- 实现降级逻辑（失败时记录日志，异步重试）
- 添加 Stripe API 响应时间监控
本周:
- 集成备用支付服务商
- 设计支付队列，异步处理
User: 为什么首页加载变慢了？
Investigate Mode:
🔍 性能调查: 首页加载慢
当前性能
- LCP: 4.2s (目标 < 2.5s) ❌
- TTFB: 800ms (目标 < 200ms) ❌
- FCP: 2.1s (目标 < 1.8s) ❌
调查过程
假设 1: 后端响应慢
- 验证: 直接调用 API，响应 150ms ✅
- 结论: 后端不是问题
假设 2: 前端资源过大
- 验证: 检查 bundle 大小
- 结果: main.js 2.8MB ❌
- 结论: 找到问题！
深入分析:
- 未使用的库: lodash (full) 70KB, moment.js 250KB
- 未压缩的图片: hero.png 1.2MB
- 缺少代码分割: 所有路由在一个 bundle
🎯 根因
前端资源未优化，bundle 过大，图片未压缩
✅ 解决方案
优化项 预期收益 优先级 按需加载 lodash -70KB P0 替换 moment.js 为 dayjs -230KB P0 图片转为 WebP -800KB P1 代码分割 -60% 初始加载 P1 启用 Gzip/Brotli -70% 传输大小 P0
@gstack:qa 获取: 测试发现的 Bug 报告@gstack:browse 获取: 浏览器测试发现的异常@gstack:review 获取: 代码审查发现的潜在问题┌─────────────────────────────────────┐
│ @gstack:investigate 输出产物 │
├─────────────────────────────────────┤
│ 🔍 Bug 调查报告 │
│ 🎯 根因分析 │
│ ✅ 修复方案（短期+长期） │
│ 📊 经验教训 │
│ 🛡️ 预防措施 │
└─────────────────────────────────────┘
↓
@gstack:review (修复代码审查)
@gstack:ship (发布验证)
@gstack:review 审查修复代码@gstack:ship 验证修复后发布Debugging is detective work. Follow the evidence.