DeepSeek写运维脚本的提示词

写 DeepSeek 运维提示词的底层逻辑：先把“上下文”焊死

一个常见的悲剧是：运维同学满怀期待地扔给 DeepSeek 一句“帮我写个清理日志的脚本”，结果模型输出了一个用 shutil.rmtree 直接删目录、连 try-except 都不带的“冲击波”。然后脚本一运行，/var/log 下文件全没了，生产环境直接报错。

其实问题根本不在模型，而在提示词——没有提前把角色、环境、安全边界交代清楚。从行业经验来看，真正能直接拿到生产环境跑的脚本提示词，必须像一份操作手册那样层层锁死。

明确角色与约束条件

第一步：在提示词开头用一句话锁定模型的身份和隐性知识库。比如“你是一位有 5 年 Linux 系统运维经验的 Python 自动化工程师”。这句话看似简单，但它能激活模型对 sudo 权限、systemd 服务生命周期、/var/log 目录结构这些隐性规则的调用。如果只写“请帮我写脚本”，模型会默认用最通用的写法——未必适应生产环境。

第二步：强制声明运行环境的硬约束。必须包含类似“目标系统为 CentOS 7.9，Python 版本固定为 3.6.8，禁止使用 asyncio、pathlib（因旧环境未升级）”的语句。不写清楚这点会怎样？模型大概率会输出 f-string 或 shutil.move() 这类在 3.6.8 中受限的语法，运行到一半直接报错。

第三步：用“必须”“严禁”“仅限”这类强动词锁定边界。例如：“必须检查 /etc/hosts 是否存在备份副本，严禁覆盖原始文件；日志仅写入 /var/log/myscript/，严禁写入 /tmp。”这些词语不是摆样子——它们能促使模型在生成代码时主动加入权限校验和路径守卫。

描述任务要带真实上下文

不要写“写一个清理日志的脚本”，而是写：“上周 nginx_access.log 占满 /root 分区导致 API 超时，现需脚本每天凌晨 2 点执行：①保留最近 7 天压缩包；②删除超过 30 天的原始日志；③执行前校验磁盘剩余空间是否＞5GB，否则中止并邮件告警。”这种写法把事故场景、触发条件、异常处理全部裹进需求，模型输出的代码自然不会遗漏检查点。

直接粘贴 shell 命令失败截图中的关键行——比如“df -h | grep '/root' 显示 100%；journalctl -u nginx.service --since '2 hours ago' 输出大量 'connect() to unix:/var/run/php-fpm.sock failed'”。模型能据此识别出根因是 PHP-FPM 套接字失效而非磁盘问题，生成的修复脚本就能跳过无意义的日志清理，直接走服务重启+套接字检查的逻辑链条。

要求输出格式与安全机制

在提示词末尾必须明确指定代码结构和安全阀门。比如：“输出仅含 Python 源码，开头加 #!/usr/bin/env python3，结尾加 if __name__ == '__main__': main()；函数内每处 open() 操作必须配 with 语句；所有 subprocess 调用必须捕获 CalledProcessError 并记录 stderr 到 logger.error()。”

【关键前提】必须在提示词中要求“第一行注释注明该脚本已在 CentOS 7.9 + Python 3.6.8 环境实测通过”，否则模型可能生成未经验证的假设性代码。这行注释既是给后续维护者看的，也是给模型自己加的一层“实测约束”。

补充安全指令：所有涉及 rm、chmod、systemctl restart 的操作，必须前置 dry_run 参数开关，默认 True；当 dry_run=False 时，需二次确认输入 'y' 才执行。这个设计在模版脚本中几乎成了标配——干运行模式下只打印不执行，把误操作的成本降到零。