Trae写发布步骤文档提示词怎么减少机械感

写发布步骤时，核心要点其实就几个：明确执行人、环境约束和失败应对路径；删掉所有无主语动词短语；全文“请”字不超过1个；以真实告警为起点，嵌入失败场景，并补充预发验证、灰度开关、报错速查三类上下文。

写发布步骤文档时，最怕的就是那种机械感。运维同学在深夜紧急上线前，反复读三遍还抓不住重点——“执行部署脚本”“检查服务状态”“验证核心接口”这类指令，没有角色、没有上下文、没有失败反馈，既不能防错，也无法快速定位卡点。说到底，这问题出在动词短语上，它们像无头苍蝇，没人知道该往哪飞。

删掉所有无动作主体的动词短语

打开你正在写的发布步骤文档，逐行检查：凡是没有明确执行人、没有具体环境约束、没有失败应对路径的动词短语，全部删掉。比如“启动服务”——删；“校验配置”——删；“确认无误后发布”——删。它没说谁确认、在哪确认、用什么判断“无误”。

这一步要是没做，后面加再多截图和命令行都救不回来——因为没人知道该在哪个终端敲哪条命令、出错时看哪行日志、卡住时联系谁。

用真实发布现场重写每一步

方法一：以真实告警为起点。比如，值班同学凌晨2:17收到钉钉告警，然后打开 Jenkins job “deploy-order-api-prod”，查看构建参数 env=prod, region=shanghai, commit=3a8f2c1，点击“Build with Parameters”。而不是写“准备发布包”这种没头没脑的指令。

方法二：把失败场景直接嵌入步骤中。比如，执行 db-migrate --env=prod --step=20240712_add_index_user_id，若报错 ERROR: duplicate key value violates unique constraint，则跳过该 step，手动执行 ALTER INDEX IF NOT EXISTS idx_user_id ON users RENAME TO idx_user_id_v2。

补全三类不可跳过的上下文信息

① 本地预发验证路径：前端同学拉完 release/v2.4 分支后，执行 npm run build:preview，将静态资源上传至 http://preview.trae.cn/order/，然后用 curl -I https://preview.trae.cn/order/api/v1/status 确认返回 200 OK 且 X-Env: preview。

② 灰度切流开关方式：登录 traefik dashboard，进入 namespace=prod，编辑 ingressroute order-api，将 match 字段从 Host(`api.trae.cn`) 改为 Host(`api.trae.cn`) && Headers(`X-Canary`, `true`)。

③ 关键报错速查表：遇到“context deadline exceeded”报错，检查 istio-proxy 是否卡在 Envoy xDS 同步；遇到“no healthy upstream”，执行 kubectl get endpoints order-api -n prod，确认 SUBSETS.ADDRESSES 非空；遇到“permission denied on directory '/data/log'”，登录目标节点，运行 sudo chown -R 1001:1001 /data/log。