面对一个需要将 Java Spring Boot 服务部署到 Ubuntu 裸机上的任务，许多人的第一反应是写一份“差不多能用”的脚本说明。问题是，当这份说明传到运维团队手里时，往往因为缺少具体路径、遗漏验证步骤，或者充斥着“建议配置环境变量”这类模糊措辞，导致执行中断甚至回滚。真正能够落地的部署脚本，必须让运维人员直接复制粘贴就能运行，每一步都有具体命令、明确路径、可验证的结果，以及失败时的兜底动作。
下面这套方法，围绕如何向 MarsCode 这类 AI 工具下达“硬指令”展开。你不需要自己手写所有细节，但必须学会用提示词把规则约束清楚——角色、版本、系统、路径、服务名、验证参数，一个都不能少。先看一个真实场景：你要为 Java Spring Boot 服务（v3.2.4）编写部署脚本，目标环境是 Ubuntu 22.04 + OpenJDK 17 + systemd，禁止使用 Docker 或 Kubernetes。所有路径以 /opt/app/ 为根目录，systemd 服务名格式为 app-【模块名】.service，每次 curl 验证必须带 --fail --max-time 5 参数。如果提示词里没有把这些写进去，AI 很可能混入容器化步骤，导致本地裸机直接翻车。
第一步：锁定部署目标与约束条件
提示词开篇必须把角色、版本、系统三要素一次性点明：你是一名 SRE，正在为 Java Spring Boot 服务（v3.2.4）编写可立即执行的部署脚本说明，目标环境是 Ubuntu 22.04 + OpenJDK 17 + systemd，禁止使用 Docker 或 Kubernetes。 这句话必须前置，因为 MarsCode 对角色+版本+系统三要素缺失的提示词，默认会混入容器化部署步骤，导致本地裸机执行失败。紧接着追加硬性约束：所有路径必须以 /opt/app/ 为根目录；所有 systemd 服务名格式为 app-【模块名】.service；所有 curl 验证必须带 --fail --max-time 5 参数。
第二步：强制输出纯命令流，禁用解释性文字
AI 很喜欢在命令中间穿插“请配置环境变量”这类话，对运维来说等于没有输出。解决方法是命令结构完全用分隔符锚定。在提示词末尾明确要求：“输出仅包含四列，用 | 分隔，首行为标题行：操作阶段|执行命令|预期输出|失败处理；后续每行一项，不加序号、不加空行、不加‘注意’‘说明’等前缀。” 同时用动词驱动粒度：每行必须以 chmod、cp、systemctl、curl、java -jar 这类动词开头，禁止出现“需要”“应当”“可以”；若某步无对应动词，则该步不输出。再嵌入校验锚点：每条命令后必须跟一句 curl 或 grep 验证，例如 “systemctl start app-api.service → curl --fail --max-time 5 http://localhost:8080/actuator/health | grep UP”。
第三步：注入真实文件与参数
光有框架还不够，得把你的实际信息填进去。第一，把 JAR 包名、配置文件名、服务名原样写进提示词。例如：“JAR 包名为 app-api-3.2.4.jar，配置文件为 /opt/app/conf/application-prod.yml，systemd 服务名为 app-api.service”。第二，粘贴一段真实配置片段作为上下文锚点：“application-prod.yml 中已定义 server.port: 8080，management.endpoints.web.exposure.include: health,info，logging.file.name: /var/log/app-api.log”。第三，指定失败兜底动作：“若 curl 返回非 200，执行 journalctl -u app-api.service -n 20 | grep -E 'Exception|ERROR' 并退出脚本”。
第四步：生成带执行路径的完整清单
经过前三步的约束，AI 输出会非常干净。下面是一个可以直接复制到终端执行的完整清单，每步都包含操作阶段、命令、预期输出和失败处理。注意，这些命令已经按照你的真实环境填充好了参数。
第一步：创建部署目录 → 执行 sudo mkdir -p /opt/app/{bin,conf,lib,logs} → 预期输出：无报错 → 失败处理：sudo chown -R deploy:deploy /opt/app
第二步：上传 JAR 包 → 执行 scp app-api-3.2.4.jar deploy@prod-server:/opt/app/lib/ → 预期输出：100% → 失败处理：检查 deploy 用户 SSH 密钥是否已部署到 prod-server
第三步：配置 systemd 服务 → 执行 sudo tee /etc/systemd/system/app-api.service << 'EOF'，然后粘贴以下内容：
[Unit]
Description=App API Service
After=network.target
[Service]
Type=jar
User=deploy
WorkingDirectory=/opt/app
ExecStart=/usr/bin/java -jar /opt/app/lib/app-api-3.2.4.jar --spring.config.location=file:/opt/app/conf/application-prod.yml
Restart=always
RestartSec=10
StandardOutput=journal
StandardError=journal
SyslogIdentifier=app-api
[Install]
WantedBy=multi-user.target
→ 预期输出：写入6行内容 → 失败处理：确认 EOF 前后无空格，且最后一行为空行
第四步：启动并验证 → 依次执行 sudo systemctl daemon-reload、sudo systemctl enable app-api.service、sudo systemctl start app-api.service → 预期输出：无 stderr → 失败处理：运行 sudo systemctl status app-api.service --no-pager -l 查看详细错误
第五步：健康检查 → 执行 curl --fail --max-time 5 http://localhost:8080/actuator/health | grep UP → 预期输出：{"status":"UP"} → 失败处理：tail -n 20 /var/log/app-api.log | grep -i exception
整个清单没有一句多余的说明，每一步都落地。如果你用的是其他 Spring Boot 版本、端口、日志路径，只需要在提示词里对应替换即可。记住，最核心的是让 AI 知道你是一个 SRE，而且你要的是“能直接执行”的命令，不是“你觉得应该怎么做”的建议。