上次发过的 AI 排障项目，这次整理成了可直接跑的 v0.1.0 MVP

[bimeixishuai]

上个月我在 V2EX 发过一个更早期版本，当时更多是在讲思路。
这次把项目整理到了一个能直接跑的 v0.1.0 MVP，所以补发一次更新版：

debug-runbook
https://github.com/UnCooe/debug-runbook

如果你上次看过，这次值得重新看一眼的点主要有 3 个：

1. 现在可以直接 pnpm demo，0 配置先跑起来
2. 项目边界收紧了，不再把它写成“完整生产系统开源版”
3. custom runbook 、README 、发布面都补到了一个更像 v0.1.0 的状态

这个项目核心还是那个判断：

很多线上故障不是没有规律，而是排查流程本身高度套路化。

比如某个结果不对，正常排查顺序往往就是：

1. 先对齐期望结果和实际结果
2. 再看缓存
3. 再看 DB
4. 再看 trace / 调用链
5. 最后判断到底是缓存陈旧、预期副作用没发生，还是状态本身异常

我后来越来越觉得，AI 排障里最值钱的不是“给模型更多工具”，而是把这套顺序和证据边界写清楚。
不然就很容易变成：

• 工具很多，但调查路径不稳定
• trace / SQL / 日志一长就开始跑偏
• 结论看着像那么回事，但 audit 不动

所以这个项目做的事情，不是再封装一堆调试工具，而是把排障经验写成可执行 Runbook ，让 Agent：

• 先选对剧本
• 再按顺序取证
• 最后按 evidence rules 下结论

现在仓库里开源的是这层可复用骨架：

• Runbook selector
• ordered executor
• evidence normalization
• decision engine
• MCP server 入口

边界也先说清楚：

• 当前是早期开源 MVP
• 不是原内部系统的完整开源镜像
• 不包含私有 DAG 、权限系统和自动修复链路

现在已经能 0 配置直接跑 demo 了：

pnpm install
pnpm demo
pnpm benchmark
pnpm check

快来试试，把你们团队祖传的排错绝招写成剧本提个 PR ！

[gyl1989113]

收藏了。。这个项目运维开发能用吗

[bimeixishuai]

@gyl1989113
可以借鉴，运维排错本身或者说只要可以抽象的排错逻辑就很适合这套思路。

很多运维问题其实也有固定排查顺序，适合把这些经验抽成 runbook ，让 AI 按顺序取证，而不是自由乱查。

不过当前这个仓库内置的能力更偏后端业务链路排障，不是开箱即用的运维平台。
如果要用在运维场景，一般需要自己补对应的 tool adapter 和 runbook/skill ，比如接 K8s 、Prometheus 、日志系统之类，再把平时的排错逻辑沉淀进去。

[bimeixishuai]

@gyl1989113 可以直接让 cc 帮你介入你想要暴露的一些内容，你把经验告诉他抽象为 skill 就可以快速体验效果