写故障排查 Runbook，按材料选工具：仓库脚本偏 Codex，事故纪要偏 Claude，公开状态页和官方 𝕏 偏 Grok。没有永远更稳的一家。
要点
- 本稿比的是内部事故／排障手册：症状 → 诊断步骤 → 回滚／验证。它和一般技术说明、README 不是同一类活；后者见站内《写技术说明文档谁更稳》。
- 这里说的“稳”，指步骤里的命令和路径能指回你提供的材料，风险步骤带回滚，验证写的是观察结果，指不回的进“未知”节。口头“按常法重启一下”不算完成。依据是三家公开产品能力，不是自行跑分，也不做永远冠军。
- Codex 长处是对着本地仓库写：能读文件、改文档，并跑你机器上已有的命令，把 Makefile、健康检查和部署脚本里的真命令写进步骤。（Codex CLI）Best practices 把 log triage、telemetry or incident summaries 和 standard debugging flows 列为适合做成 skill 的重复劳动。（Best practices）Cookbook 也写明：恢复或排障步骤没真实跑过，就不能写成已经通过。（Iterating development workflows with Codex）
- Claude 长处是把你粘贴或上传的事故纪要、旧手册和值班约定放进 Project 知识库，用项目指令锁住“禁止编造命令”，再在 Artifacts／Docs 里反复改同一份手册。（How can I create and manage projects?；What are artifacts and how do I use them?）需要核对外公开状态页时，可开 Web search，回复带 citations；Team／Enterprise 须由 Owner 先打开组织能力。（Enable and use web search）
- Grok 长处是实时搜 Web 与 𝕏，适合补“供应商状态页／官方账号刚刚发了什么”。产品页写明 Search 给出 live citations，并接入实时 𝕏。（x.ai/grok）开发者文档另有
web_search／x_search说明，用来证明能力上有这两条通道，不等于 grok.com 的按钮就叫这个名字。（Web Search；X Search）它看不见你的私有集群，除非你把脱敏材料贴进去。 - 可混用：Codex 从仓库抽出命令事实表，Claude 排成可值班的手册，Grok 补一节对外状态与官方帖。人工终核抽几条只读命令实跑，风险步骤只允许人来执行。
正文
场景
夜里告警亮了：结账 5xx 持续偏高。你对模型说“写一份排障手册”。一份写得很完整，kubectl 参数在你们集群里根本不存在。另一份把上周值班群聊改写成步骤，回滚旗标却是编的。第三份检索了供应商博客，结论只剩“重启服务”，你们仓库里真正的回滚脚本一句都没出现。
一般技术说明要讲清楚“怎么跑起来”。故障排查 Runbook 要让人按症状往下走：先看什么，每步预期是什么，何时回滚，怎样算恢复。材料对不上，手册越漂亮越危险。
下面用同一份任务、同一套完成定义，对照三家。结论先说清：没有永远更稳的工具；按证据从哪来选型。相对判断来自产品能力和公开资料，不是自行测得的正确率数字。
可跟做步骤／可抄工作流
1. 统一任务与完成定义（三家共用）
开工具前先把合同贴在提示顶部。结构沿用常见排障写法，Google SRE 的排查方法也强调先形成假设，再用可区分的检查去验证，而不是一上来就改生产状态。（Effective Troubleshooting｜SRE Book）
【文档任务】给值班同事用的内部故障排查 Runbook（不是对外说明，也不是事故复盘长文）
【读者】本团队值班／支持，已有仓库或手册读权限
【必含节】
1. 触发与症状（告警名、用户可见现象、影响范围；只写材料里有的）
2. 先做的只读诊断（编号步骤；每步写命令或仪表盘入口、预期输出、失败时去哪一步）
3. 缓解与回滚（每个会改变状态的步骤标出风险，并写回滚办法和中止条件）
4. 恢复验证（要观察的信号、持续多久、谁来确认；未跑过的检查单独列出）
5. 升级路径（材料里有的联系人／角色；没有就进未知节）
6. 未知与待确认（单独一节，禁止删掉）
【禁止】
- 编造不存在的命令、旗标、集群名、仪表盘 URL、环境变量、回滚参数
- 把“建议重构”或根因猜想写成现行步骤
- 把计划中的验证写成已经通过
- 在手册里粘贴密钥、token、连接串；只写密钥位置或变量名
【完成定义】
- 每一处命令／路径／链接都能指回：仓库文件，或我粘贴的原文，或可打开的检索引用
- 指不回的必须进“未知与待确认”
- 风险步骤默认不要在生产执行；需要演练只读命令时，先说明环境并等待我确认
- 输出 Markdown；先给目录再给正文“未知节”删不得。删掉就等于鼓励它把猜想写成步骤。
2. 五轴对照（故障排查 Runbook 场景）
| 评价轴 | Grok | Claude | Codex／Cursor 改仓 |
|---|---|---|---|
| 1 证据锚点 | 强在公开状态页、官方公告、官方 𝕏；弱在进不了私有仓和内网仪表盘 | 强在你粘贴／上传的纪要、旧手册、值班约定；可要求先摘录再写 | 强在直接读仓库里的脚本、告警规则、已有 docs／runbooks |
| 2 步骤可执行 | 外链步骤容易写顺，内部命令常靠猜测，必须靠未知节拦住 | 结构稳定，适合把“每步预期／失败分支”写全；命令真实性取决于你给的材料 | 最容易写出仓库里真实存在的命令；也最容易把“计划中的新脚本”写进现行步骤 |
| 3 回滚与验证纪律 | 适合核对外公告是否仍在；不能替你证明集群已经恢复 | 项目指令可写死“未跑过的验证不许写成通过” | Cookbook 已有这句纪律；还可在本地跑只读命令，把观察输出贴回手册 |
| 4 对外时效 | 供应商故障先出现在状态页或官方 𝕏 时，这是它的主场 | 开 Web search 时可补公开页；默认仍偏你提供的材料 | 可用实时网页搜索核对公开文档；主场仍是本地仓，内网状态不在这里 |
| 5 活文档迭代 | Canvas／长对话可改，跨聊天的项目知识库要自备 | Project 知识库＋指令＋Artifacts／Docs，适合同一份手册多轮打磨 | 手册可以直接落在仓内走 PR，和告警规则、脚本一起审 |
读表时先问证据在哪。证据在当前 commit 的脚本和规则里，偏 Codex。证据在一叠值班纪要和旧手册里，偏 Claude Project。证据在供应商状态页或官方 𝕏，偏 Grok。
3. 三家怎么开跑（可跟做）
A. Codex／Cursor（贴仓库的排障步骤向）
- 在仓库根目录打开 Codex CLI 或 Cursor 里的 Codex。权限保持工作区内读写，危险命令仍要审批；不要为了“方便排障”解开沙箱。
- 先读再写。点名告警规则、现有
docs/runbooks或等价目录，以及部署和回滚脚本、健康检查入口。没读到的命令不许写进步骤。 - 提示可以接在完成定义后面：
先只读：列出与“结账 5xx 偏高”相关的告警规则、脚本、已有手册路径，以及每条命令所在的文件。
确认后：更新或新建 docs/runbooks/checkout-5xx.md，遵守上方完成定义。
只改这份文档，不要改业务代码，也不要在生产环境执行风险步骤。
若要演练只读命令，先列出命令和环境，等我确认再跑，并把观察输出贴回“恢复验证”。- 看 diff：路径是否真实，有没有把未完成的脚本写成现行步骤，风险步骤有没有回滚和中止条件。
- 公开上游文档可以用实时搜索核对版本；私有约定仍以仓内文件为准。
Best practices 把“标准排障流程、日志分诊和事故摘要”写成适合做成 skill 的重复劳动。真要沉淀，先把上面这份完成定义跑顺，再考虑收成 skill。第三方也有专门写 on-call runbook 的 skill，强调每步都是“动作＋预期＋分支”、风险步骤必须带回滚，并且默认不在生产执行改变状态的命令。（Runbook Writing Skill for Codex）那是公开第三方技能，不是 OpenAI 官方开关，结构可以借，安装与否由你决定。
B. Claude（纪要和旧手册打磨向）
- 建或打开一个 Project，把脱敏后的旧 Runbook、值班约定，以及最近一次事故时间线和已知仪表盘入口放进知识库。不要放密钥。
- 项目指令写入完成定义里的禁止项，尤其是“不许编造命令”和“未知节不得删除”。项目名和描述 Claude 读不到，别把关键纪律只写在名称里。
- 新开聊天，先让它摘录材料里的原句和路径，再写手册；要求输出到 Artifacts／Docs，方便按节改。
- 每轮只改一节，比如先只读诊断，再写回滚。改完仍要保留未知节。
- 需要核对外公开状态页时，在提示里写“使用 web search”，并要求每条对外断言带可点链接。Team／Enterprise 先确认组织已打开该能力。新版界面若不再显示开关，以现页为准。
C. Grok（对外状态和官方账号向）
- 打开 grok.com 或官方 App，选用当前界面的检索／Search（名称以界面为准）。
- 粘贴完成定义，并写明：内部步骤只依据我粘贴的原文；对外段落只依据可打开的状态页、官方公告和我指定的官方 𝕏 账号。
- 要求先列出实际打开或检索到的 URL，再写“对外依赖”这一节。打不开的删掉。网友截图和二手转述只能进旁证，不能单独作为“供应商已故障／已恢复”的依据。
- 内部集群命令如果材料不足，进未知节，不要用训练记忆补一条看起来很像那么回事的
kubectl。
消费端精确按钮文案、套餐是否包含搜索，以各产品现页为准。开发者文档里的 allowed_domains、按帖计费等是 API 细节，只用来说明能力边界，不写进你们值班手册的操作步骤。
4. 推荐混用，以及人必须留下的那几步
- Codex 先出“命令事实表”：路径｜命令｜摘录｜只读还是会改状态。
- Claude 按完成定义排成手册，未知节留空位。
- 手册里涉及供应商或公开状态时，Grok 补一节外链并核链。
- 你自己抽 2 到 3 条只读命令，在约定好的非生产环境跑一遍，或对照现有仪表盘。链接全部点开。
- 风险步骤只由人执行。模型可以起草回滚命令，不能代替你点下去。
- 定稿进仓库并走 PR，避免聊天里的“最新版”和仓内手册各写各的。
演示一次生成可以交差。能值班的手册还要有完成定义、事实表和未知节，以及至少一次对只读步骤的观察记录。
真实用户诀窍／反例
- 诀窍：先选证据源，再选模型。 工具之争，常常是材料没对齐。
- 诀窍：每步都写预期和失败分支。 第三方 runbook 实践把“调查一下”这种没有下一跳的句子当成典型缺陷，值班时最容易在这里开始即兴发挥。
- 诀窍：缓解可以先于深挖根因。 材料里如果已有回滚或开关，就把它放在长诊断前面，并写清中止条件。
- 诀窍：对外依赖和内部步骤拆开写。 时效策略不同，揉在同一段里很快过期。
- 反例：三家各出一版，挑最长的当胜者。 最长的往往掺了编造命令。
- 反例：对 Grok 说“根据我们的 Kubernetes 集群”。 它看不见，除非你粘贴脱敏后的命令和上下文。
- 反例：让 Codex 边写手册边在生产执行回滚。 完成定义应禁止未确认的风险步骤；沙箱和审批也不能为此解开。
- 反例：Claude 知识库塞进带密钥的值班附件。 手册只引用密钥位置。
- 反例：把一次生成当永久有效。 告警规则、脚本和状态页都会变，手册要随仓更新。
适用边界
- 本稿覆盖：内部故障排查／值班 Runbook 的工具选型与可抄完成定义。不是编程能力总榜，也不是事故指挥或事后复盘长文的写法评测。
- 不覆盖：合规审计正式文档、对外法律文本，以及需要在生产直接操作的自动修复。那些还要各自的审批和模板。
- 产品功能名和按钮文案，以及套餐是否包含搜索或 Projects，随版本变化，以各产品现页和你的界面为准。
- “更稳”指在对应证据源下更少无锚点编造、更少把计划写成已验证的工作流倾向，不是正确率百分比，也不是并行跑分。