ChatGPT写脚本部署说明提示词常见问法完整列表

# 脚本部署说明 在实际工作中，我经常遇到一个有意思的现象：让ChatGPT生成一份能直接交给运维同事执行的脚本部署说明，结果总是差那么一点——要么缺关键路径，要么漏了权限检查，再不然就是跳过回滚步骤。说实话，这事儿真不赖模型——问题出在提示词上。只要你没有把“谁在什么环境里部署什么、失败后怎么退、成功后怎么验”这三件事钉死，模型就会自由发挥，然后你就得反复修改。 那么，到底该怎么写？我们从一个真实的例子拆开来看。 ## 1. 环境要求 执行主体是【运维工程师】，部署环境为阿里云ACK集群（v1.26.11），节点OS是CentOS 7.9，内核版本3.10.0-1160.118.1.el7.x86_64，已预装kubectl 1.26.0及helm 3.12.3。部署脚本由Python 3.9编写，打包为tar.gz压缩包，解压后路径结构明确：`/opt/app/deploy/`。 ## 2. 部署步骤 按时间流拆解，每个阶段都必须包含验证动作，不能跳过。 ① **准备阶段**：检查目标主机是否满足Python 3.9+、pip≥22.0、空闲内存≥2GB。任一条件不满足，直接exit 1并输出具体缺失项。 ② **部署阶段**：解压tar.gz包 → 安装依赖（`pip install -r /opt/app/deploy/requirements.txt --no-cache-dir`） → 校验config.yaml语法（`python -m yaml syntax /opt/app/deploy/conf/config.yaml`） → 执行`deploy.py --dry-run`确认无报错 → 最后才执行真实部署。 ③ **验证阶段**：用`curl -sf http://localhost:8080/health | jq '.status'`检查，必须返回"ok"；同时确认进程数（`ps aux | grep deploy.py`）为1；日志目录权限（`ls -l /var/log/deploy/`）必须是755且属主为deploy_user。 ④ **回滚阶段**：提供一条可直接复制的命令——`tar -xzf deploy-backup-$(date -d 'yesterday' +%Y%m%d).tar.gz -C /opt/app/`。注意，这个备份是由部署脚本在第②步开始时自动触发的。 ## 3. 验证清单 除了上述验证阶段的操作，还需要用字段标签硬性区分必填参数与可选配置。所有参数必须归类，标签不可省略，且仅允许使用【必填】和【可选】。 【必填】APP_ENV：运行环境标识，取值为prod/staging，影响数据库连接池大小与日志级别。 【必填】DEPLOY_USER：部署操作所属系统账号，用于chown与systemd service文件中User字段。 【可选】BACKUP_RETENTION_DAYS：本地备份保留天数，默认7，超过此值的旧备份将被rm -f删除。 【可选】SSL_CERT_PATH：HTTPS证书路径，仅当APP_ENV=prod且ENABLE_HTTPS=true时生效。 ## 4. 回滚方案 回滚步骤很简单，但必须写清楚触发条件：当部署脚本在第②步发现任何异常时，自动触发回滚。回滚命令为上面已经提到的： `tar -xzf deploy-backup-$(date -d 'yesterday' +%Y%m%d).tar.gz -C /opt/app/` ## 5. 常见故障与修复 以下是三个高频故障点，每个包含【现象】【定位命令】【修复操作】，中间用空行分隔。 **场景1** 【现象】执行deploy.py后进程立即退出，stdout为空，journalctl -u myapp.service显示“Failed at step EXEC spawning /opt/app/bin/deploy.py: Permission denied” 【定位命令】`ls -l /opt/app/bin/deploy.py` 查看权限，`id deploy_user` 确认用户是否存在 【修复操作】`chmod +x /opt/app/bin/deploy.py`，同时检查文件属主：`chown deploy_user:deploy_group /opt/app/bin/deploy.py` **场景2** 【现象】health接口返回503，但进程存活，netstat -tlnp | grep :8080显示端口未监听 【定位命令】`netstat -tlnp | grep :8080` 确认端口状态，`cat /opt/app/conf/config.yaml | grep bind_addr` 检查配置 【修复操作】可能原因有三种：1. 配置中bind_addr未设置正确（验证命令：`grep bind_addr /opt/app/conf/config.yaml`）；2. 防火墙规则拦截（验证命令：`iptables -L -n | grep 8080`）；3. 应用启动参数中端口被覆盖（验证命令：`ps aux | grep deploy.py | grep -oE ':[0-9]+'`） **场景3** 【现象】首次部署成功，二次部署时报错“Migration already applied”，而实际数据库表结构未更新 【定位命令】`grep -r "already applied" /var/log/deploy/deploy.log` 查看具体上下文 【修复操作】（仅限测试环境）临时方案：`MIGRATE_SKIP=1 /opt/app/bin/deploy.py`；永久修复：检查数据库迁移脚本中是否存在重复的迁移ID，使用`python manage.py migrate --fake`命令安全恢复。