提示词技巧
我来给你做一个专门针对运维工程师的提示词优化指南，用可视化方式呈现会更直观。好，现在我来制作一个专为运维工程师设计的提示词优化指南，交互式、实用、带示例。
# 1、角色+上下文
技巧一：声明角色 + 补充环境上下文 明确告诉 Claude 你的环境和背景，它会给出更贴合实际的答案，避免过于通用的建议。 ❌ 模糊
帮我写个监控脚本
✅ 具体
你是一名 Linux 运维工程师。我们的生产环境是 CentOS 8，使用 Prometheus + Grafana 监控栈。帮我写一个 shell 脚本，每 60 秒采集一次磁盘 inode 使用率，超过 80% 时向 Alertmanager webhook 发送告警。
技巧二：说明技术栈版本
版本差异直接影响命令和配置语法，尤其是 Kubernetes、Nginx、Ansible 等工具。 ❌ 无版本
写一个 K8s 的 HPA 配置
✅ 带版本
写一个 Kubernetes 1.27 的 HPA 配置，基于自定义指标 http_requests_per_second，最小 2 副本，最大 10 副本，目标值 500 QPS。使用 autoscaling/v2 API。
# 2、指定输出格式
技巧三：明确要求输出格式 指定你需要的格式——runbook、YAML、脚本、只给命令不要解释——省去反复要求的时间。 ❌ 无格式要求
怎么排查 Pod 一直 CrashLoopBackOff？
✅ 指定格式
Pod 一直 CrashLoopBackOff，给我一份排查 runbook，格式要求： 1. 每步只给一条命令 2. 命令后跟一句话说明看什么 3. 最后列出最常见的 3 个根因和对应修复方法 不需要概念解释。
技巧四：要求只给命令，不要废话
❌ 会得到大段文字
如何查看哪个进程占用了 8080 端口？
✅ 直接拿命令
只给命令，不要解释：查看哪个进程占用了 8080 端口（Linux，需要同时显示 PID 和进程名）
# 3、约束+边界
技巧五：说明限制条件
生产环境有很多不可触碰的边界，提前声明可以避免收到危险建议。 ❌ 无约束
我的 MySQL 查询很慢，怎么优化？
✅ 带约束
MySQL 8.0，一张 2 亿行的订单表，查询响应 8 秒。约束条件： - 不能停机 - 不能修改表结构（有历史数据迁移风险） - 只能加索引或改查询语句 给出优化方案，按风险从低到高排序。
技巧六：指定安全级别
让 Claude 知道这是生产环境还是测试环境，会影响它建议操作的激进程度。
❌ 未说明环境
怎么清理磁盘空间？
✅ 明确生产限制
这是生产环境，不能删除任何业务数据。帮我列出安全的磁盘清理方法，每个方法注明：是否需要 root、是否有数据风险、预期能释放多少空间。
# 4、任务拆解
技巧七：复杂任务逐步拆解
对于复杂的运维任务，不要一次问完，先让 Claude 给出方案框架，确认后再深入每个步骤。 ❌ 一次问太多
帮我把单体应用迁移到 K8s，包括 CI/CD、监控、日志、网络策略全套
✅ 先要框架
我要把一个 Java Spring Boot 单体应用迁移到 K8s。 第一步：只给我迁移的整体阶段划分（不要细节），每个阶段一句话描述，我确认后再逐个展开。
技巧八：让 Claude 先列假设
在给出方案前，让 Claude 先说明它做了哪些假设，可以快速发现方向偏差。 ❌ 直接要方案
设计一套高可用的 Redis 方案
✅ 先列假设
设计高可用 Redis 方案前，先列出你做的所有假设（如数据量、QPS、是否需要持久化、预算限制等），我确认后再给出具体方案。
# 5、模版库
通用故障排查模板 环境：[操作系统] + [相关中间件及版本] 现象：[具体报错或异常行为，贴上错误日志] 已做过的操作：[列出已经尝试过的排查步骤] 约束：[不能重启服务 / 不能修改配置 / 仅有只读权限]
请给出排查步骤，每步一条命令 + 一句话说明目的，最后给出可能的根因列表。
自动化脚本模板 写一个 [bash/python] 脚本，功能：[具体描述] 运行环境：[OS] + [依赖工具版本] 要求：
- 有错误处理和日志输出（写入 /var/log/xxx.log）
- 关键操作前打印确认信息
- 支持 dry-run 模式（加 --dry-run 参数只打印不执行）
- 脚本末尾加使用说明注释
配置文件 Review 模板 下面是我的 [Nginx/K8s/Ansible] 配置文件，请从以下几个维度 review：
- 安全隐患（标注高/中/低风险）
- 性能问题
- 生产环境最佳实践缺失项
[粘贴配置内容]
输出格式：问题列表，每条包含：问题描述 → 建议修改 → 修改后的配置片段
变更方案模板 我需要在生产环境执行：[变更内容] 当前环境：[描述现有架构/配置] 变更窗口：[时间限制，如 2 小时内]
请给出变更方案，包含：
- 前置检查清单（变更前确认项）
- 变更步骤（逐步执行，每步加预期结果）
- 验证方法（如何确认变更成功）
- 回滚方案（如何快速还原）
以上是一个交互式指南，点击顶部标签切换不同技巧，模板库那一栏可以直接复制使用。
核心思路总结一下：
最重要的三件事，运维场景下能显著提升回答质量：
首先是声明上下文，把操作系统、版本、现有架构说清楚，Claude 不会给你一个"通用答案"而是贴合你实际环境的方案。
其次是加约束条件，不能停机、不能改表结构、只有只读权限……这些生产限制越早说越好，避免收到正确但不可执行的建议。
第三是指定输出格式，要 runbook 就说 runbook，要只给命令不要解释就说清楚，节省大量来回沟通成本。
如果遇到复杂任务（比如架构迁移），先让 Claude 给框架、列假设，你确认方向对了再深入，效率比一次问完高很多。
|