☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
你是一名sre，正在为java spring boot服务（v3.2.4）编写可立即执行的部署脚本说明，目标环境是ubuntu 22.04 + openjdk 17 + systemd，禁止使用docker或k8s。所有路径必须以/opt/app/为根目录；所有systemd服务名格式为app-【模块名】.service；所有curl验证必须带--fail --max-time 5参数。操作阶段|执行命令|预期输出|失败处理 创建部署目录|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
你需要让marscode生成的脚本部署说明能被运维同学直接复制粘贴执行，而不是看到“请配置环境变量”“建议检查权限”这类无法落地的模糊指令——每一步都必须含具体命令、明确路径、可验证结果和失败兜底动作。
第一步：锁定部署目标与约束条件
在提示词开头直接写明：“你是一名SRE，正在为Java Spring Boot服务（v3.2.4）编写可立即执行的部署脚本说明，目标环境是Ubuntu 22.04 + OpenJDK 17 + systemd，禁止使用Docker或K8s。”
这句必须前置，【MarsCode对角色+版本+系统三要素缺失的提示词，默认会混入容器化部署步骤，导致本地裸机执行失败】。
紧接着追加硬性约束：“所有路径必须以/opt/app/为根目录；所有systemd服务名格式为app-【模块名】.service；所有curl验证必须带--fail --max-time 5参数。”
第二步：强制输出纯命令流，禁用解释性文字
方法一：用分隔符锚定结构
在提示词末尾明确要求：“输出仅包含四列，用|分隔，首行为标题行：操作阶段|执行命令|预期输出|失败处理；后续每行一项，不加序号、不加空行、不加‘注意’‘说明’等前缀。”
方法二：用动词驱动粒度
写死指令：“每行必须以动词开头：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’并退出脚本”。
第四步：生成带执行路径的完整清单
第一步：创建部署目录 → 执行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
第四步：启动并验证 → 执行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
