内容来源：Bits, Bugs, and Opinions。https://tomakl.dev/posts/claude-code-devops-commands/
原题：The devops commands that replaced my runbooks
原发布时间：2026-03-04
用于部署、诊断和系统健康检查的 11 条斜杠命令，以及它们与被取代的运维手册文档有何不同。
归档关系：这是作者承诺在为 Claude Code 编写自定义命令之后推出的 DevOps 续篇。上一篇文章介绍命令文件、
$ARGUMENTS、Frontmatter 与命名空间；本文则把这些模式应用到部署、诊断和健康检查中。
来源修复说明：Cloudflare 邮箱保护错误地把部署命令中的
trigger.dev@4.4.1当成了邮箱地址。下文已还原解码后的软件包与版本标记；其他源代码和正文均按原样保留。
兼容性与安全说明（核对日期：2026-07-21）：归档保留了仍受支持的旧版
.claude/commands/路径，不过当前 Claude Code 推荐使用 Skills；生产部署 Skill 应设置disable-model-invocation: true。标为 Bash 的代码块混合了真实 Shell 命令与mcp__trigger__...工具调用，因此不能把整个代码块当成 Bash 执行。allowed-tools只表示预先授权访问；涉及 SSH、Docker 和通配符权限时，必须认真测试 PreToolUse 门禁。Skills 仍是由模型执行的提示词，并非确定性运维手册；如果Agent工具可用，当前子智能体可以创建嵌套智能体。原文还分别使用了 11 条和 12 条命令两个数量，并把相关文章中的/devops:deploy简写为/deploy；下文保留这些不一致之处。
在上一篇文章中，我介绍了自定义斜杠命令的工作方式：Markdown 文件、$ARGUMENTS、Frontmatter 和命名空间。我承诺会写一篇 DevOps 类别的续文，这就是它。
DevOps 目录有 12 条命令。这里主要介绍那些真正取代了我过去维护的文档的命令。
运维手册的问题
我曾经维护过运维手册：一些 Confluence 页面，说明如何部署、如何检查部署是否出错，以及怎样诊断每个应用中的错误。其中有些写得不错，但大多数已经落后几个月，我只能一边照做，一边在脑子里修补变更差异。
在我加入可以从 CLI 完成检查的 MCP 集成后，部署手册仍然有很长一段时间写着“打开 Trigger 控制面板，检查部署状态”。我总是忘记更新文档，而文档也一直在对我撒谎。
命令没有这个问题。如果更换某项检查所使用的工具，我会更新命令文件，而命令文件本身就是实际执行的内容。文档与行为之间不存在落差。
/deploy
这是我使用最多的命令。在它出现之前，部署 Trigger.dev 任务需要依次完成五件彼此独立的事，其中一半只存在于我的脑子里。
命令首先并行运行部署前检查：
git status # 工作树是否干净？
git log --oneline -5 # 即将部署哪些内容？
docker ps | grep trigger # 容器是否正在运行？
mcp__trigger__list_deploys # 当前部署的版本
mcp__trigger__list_runs # 最近的运行状态
它展示所有结果，然后停止并请求我确认。权限 Hooks会自动强制执行这个门禁，因此，即使我忘记添加确认步骤，破坏性命令仍会遭到阻止。只有在我同意后，它才会通过 SSH 登录 ARM 开发板并运行真正的部署：
ssh user@server "cd ~/trigger-deploy && git pull && \
npx trigger.dev@4.4.1 deploy --env prod"
然后，它等待 30 秒，再运行部署后检查：新版本是否出现、Worker 是否注册了全部任务、容器是否仍然健康。
旧运维手册是一个截图早已失真的 Confluence 页面；新方案是一个 42 行的 Markdown 文件，每次都会做正确的事。
/diagnose
这条命令更有野心，是一条调试应用错误的多智能体流水线。
运行 /diagnose myapp /var/log/myapp/error.log 后，它会：
1、从日志中提取错误关键词
2、在 Confluence 中搜索已有解决方案（使用 confluence-searcher 子智能体）
3、如果没有结果，并行启动三个智能体：网络调研、库文档查询、代码库搜索
4、把全部信息交给 enterprise-app-specialist 智能体分析根本原因
5、提议根据发现创建一份 Confluence 运维手册或本地 Markdown 文件
6、起草工单摘要，以及一小段给问题报告者的说明
最后一项最节省我的时间。每周写五次“我们确认根本原因是 X，应用了修复 Y，服务已恢复正常”，正是适合模板化的任务。智能体负责写，我负责阅读和发送。
命令文件本身大约 150 行，与其说是命令，不如说是编排脚本。但归根结底，它仍然只是一个包含编号步骤和工具引用的 Markdown 文件。
/trigger-status
一项简单的状态检查，分三步：
docker ps | grep trigger # 容器健康状况
mcp__trigger__list_runs # 最近 10 次运行，成功或失败
mcp__trigger__get_current_worker # 已注册任务
输出是一张简短表格：容器是否健康、运行成功率，以及当前活跃任务列表。
每当感觉哪里不对，或者想确认新部署是否正确完成注册时，我都会运行这条命令。它大约需要 15 秒。旧方法则要打开 Trigger Web 界面，在三个不同页面中点来点去，再手动对比预期状态。
/sys-health
并行执行六项检查：
df -h / # 磁盘
free -h # 内存
uptime # 平均负载
docker ps | grep trigger # 容器
docker ps --filter "health=unhealthy" # 是否有故障
ss -tlnp | grep -E ':(80|443|3000|5432|8080)' # 关键端口
输出是一张紧凑表格。磁盘使用率超过 90%，或者存在任何不健康容器，都会被标出。
这是命令所能达到的最简单形式，连标题和用法一共只有 20 行。出现问题时，我会把它作为其他一切操作之前的第一步。
/app-status
这条命令按应用工作。我支持的每个应用都有一份 Profile，包括名称、技术栈、日志路径、GitHub 标签和 Confluence 空间。命令会根据我传入的参数加载相应应用 Profile，并显示：
• 带该应用标签的开放 GitHub Issue
• 该应用 Confluence 空间中的最近页面（通过 MCP）
• 本地索引中最近诊断的五个问题
• 应用 Profile 摘要
这能让我在开始调试会话之前迅速掌握情况。不必分别打开 GitHub、Confluence 并查阅笔记，只需运行 /app-status myapp，所有信息就会集中在一个地方。
客户专用命令
三条命令分别处理特定客户或环境：一条用于某个 AWS 账户，一条用于带 Kubernetes 和 MongoDB 的 Azure 环境，另一条用于 AWS 上运行的生产系统。
这些命令遵循同一种模式，只不过内置了环境专用上下文。Azure 命令知道具体的虚拟机名称、需要检查的防火墙规则和 Replica Set 配置。我不必记住这些内容，命令会自行携带。
每条命令都会引用客户专用规则文件，其中包含“接触 iptables 之前始终验证 UFW 状态”或“重启任何成员之前检查 MongoDB Replica Set 健康状态”等要求。这些上下文过去只存在于我的脑子里，偶尔会被遗忘。
它们取代了什么
• 一个带过时截图的 Confluence 部署手册：/deploy
• 一份“如何检查哪里出了问题”的脑内清单：/sys-health 和 /trigger-status
• 一个早已停止维护的“谁负责哪个应用”Wiki 页面：/app-status
• 三份客户运维手册，每份两三页：三条客户命令
• 每次都从头编写事件摘要的习惯：/diagnose 第六步
12 个文件共约 400 行 Markdown。它们取代的 Confluence 页面合计大概有 600 行，一次写好后便逐渐与现实脱节。
真正的区别不在行数，而在于命令会运行，Confluence 页面只会静静躺在那里。
一个失败的模式
我曾尝试创建一条 /infra 命令，让它检测上下文并判断当前正在处理哪个环境：“如果存在 Kubernetes 配置，就假定是 Kubernetes 环境，否则检查 Docker。”
这个思路很聪明，却并不可靠。检测逻辑猜错的次数多到我有一半时间都要手动覆盖。最后，我把它拆成三条明确的客户命令。文件更多了，困惑却更少。
教训平淡无奇：明确优于聪明。知道自身上下文的命令，比试图推断上下文的命令更好用。
