【比升级】同一单发版脚本，8 月用 TraeCode 做、这次用合并后的新版 TRAE 重做：6 处差异实录
脱敏说明：涉及的公司系统名称、服务器地址、密钥、业务数据均已隐去，脚本片段只保留结构，不含任何真实参数。
前情：这套发版脚本我 8 月发过一版（《我用 TraeCode 把 Go 微服务的"人肉上线"改造成一条命令全程可回滚的傻瓜式流程》）。这篇是同一单在新版 TRAE 上的重做复盘，只写差异和增量，不重复上一篇讲过的东西。
一、这单是什么
一套跑了两年的 Go 微服务，多台实例挂在负载均衡后面，发布长期靠一份"祖传"shell 脚本 + 人肉盯。
8 月那版改造做的事：一条命令走完"确认版本 → 自动备份 → 并行部署 → 健康检查 → 打印常用命令"，备份按时间 + 稳定版本双保留，回滚支持三种方式，告警加了失败阈值 + 冷却期。做完在真实服务器上跑了一次验证，之后团队的日常发版都在用它。
这次 TRAE 合并成一个入口之后，我把同一单又重做了一遍。下面是 6 处差异。
二、6 处差异实录
差异 1｜"通读旧脚本"这步，从我自己整理变成它先出清单
-
8 月：我先让它读部署文档和旧脚本、梳理现状痛点，然后由我判断先改哪几处。
-
这次：Agent 模式直接通读脚本 + 部署目录，先输出一份**"它没做什么"的清单**。三条是我自己 review 一定会漏的：缺回滚的触发条件、缺发版后健康检查、告警没有状态收敛。
-
差在哪：改动点排序从"我全判断"变成"它先给候选 + 我拍板"，我的注意力集中在取舍上。
差异 2｜失败处理：从"中止"变成"自动回滚"（这处最重要）
-
8 月：健康检查失败即中止部署，停在那儿等人工处理。
-
这次：失败不是停，而是自动切回上一版镜像和上一份配置，回滚后再探测一次确认真的恢复了。
-
差在哪：8 月那版是"防呆"，这次是"自愈"。回头看，8 月那版最大的缺口就在这——"能部署"和"能自己收场"是两件事。下面的配图②就是这个路径的实测输出。
差异 3｜备份：在双保留之上加了份数上限
-
8 月：按时间 + 稳定版本双保留，保证"回得去"。
-
这次：保留策略之上加了份数上限 + 自动清理——因为跑了一段时间发现，备份目录本身会把磁盘吃满，这算上一篇之后才暴露出来的问题。
差异 4｜告警：从"阈值 + 冷却期"简化成"状态跳变"
-
8 月：单条失败立即告警 + 失败阈值 + 冷却期 + 临时暂停，一整套参数。
-
这次：只在"成功 ↔ 失败"状态跳变时发通知，同一状态连续失败不重复刷屏。
-
差在哪：跑了半年发现，我们真正需要的判断只有"状态变了没有"。参数少了，行为反而更可预期。
差异 5｜补上了流量灰度
-
8 月：并行启动 + 逐台健康检查，但流量是一次性切过去的。
-
这次：先摘掉一台实例换新版 → 观察健康检查 → 通过后再逐步加回，任何一步异常立刻回滚上一版镜像。
-
差在哪：这是上一篇之后新加的一步，也是最接近"生产敢用"的一步。
差异 6｜验证方式：从"上真机跑一次"变成"dry-run + 故意注入故障"
-
8 月：改完在真实服务器上跑了一次验证。
-
这次：先用 dry-run 跑完整流程（备份 → 替换 → 健康检查 → 回滚），核对每一步的产物和退出码；再故意让健康检查失败，专门验证"自动回滚"这条路径真的能走通。
-
差在哪：教训是——别指望"成功路径跑通了"能证明回滚可用。正常发版和回滚自愈必须分别验证。
三、新版合并带来的三个变化（这才是重做的理由）
-
一个入口，切模式不用重贴上下文。 8 月是"IDE 模式 + 智能体"两套用法，中间找问题、改脚本是要换地方、重贴上下文的。这次在同一个任务里：Agent 模式读脚本出清单，IDE 模式逐段改写，来回切上下文不丢。发版脚本这种"先诊断后动手"的活，受益最明显。
-
Agent 能自己跑验证。 以前"起服务、跑一遍、核对输出"是我的活；这次它自己跑 dry-run、自己核对输出，我只看结论。
-
产物不再散落。 方案清单、脚本改动、两次 dry-run 的输出都在同一个任务里。8 月那篇的效率对比是靠回忆写的，这次可以直接翻记录。
四、顺带：另一单上踩到两个"报不了错"的坑
同期在另一个存量小项目上（一个本地跑、零依赖的群面练习小工具：7 个 AI 队友抢麦，最后给一张评分卡），踩到两个坑。共同点是——不报错、不崩溃，只是安静地毁掉体验：
Bug 1｜推理型大模型的"空气泡" 接口返回 200，HTTP 层完全正常，但正文内容是空的，界面上就冒出一个没有内容的空气泡。定位下来：推理型模型会先产出 reasoning_content，当推理把 max_tokens 预算吃光时，content 返回的就是空字符串。修复很小——检测到"content 为空但存在 reasoning_content"时，把 token 预算放大 4 倍重试一次，仍为空则回落到本地兜底文案。
Bug 2｜开局死锁：卡在"发言中"，界面一片空白 状态显示有人在发言，但一句话都不出。根因是调度器开局把发言权强制授予了某个角色，却没有触发对应的"开口"动作——令牌被持有、没人来消耗，状态机就锁死了。补上触发链路之后，30 秒内能稳定产出 11 条发言。
这两个坑后来被我总结成一句话：语法错误和崩溃会自己报警，状态机和模型返回不会。 后一类问题只能靠"盯着结果看"发现，而这一步恰好是 Agent 能替人做机械验证、但判断"结果对不对"必须由人来的地方。
五、真实评价
省下来的：读旧脚本、列缺失项、写重复度极高的备份/回滚样板代码，以及"跑一遍看结果"这种机械验证。
只能人工的：
-
危险动作的确认。清空、覆盖、切流量这几步，脚本再聪明也不该全自动碰线上，最后必须由人按；
-
健康检查的口径。探哪个接口、连续失败几次算失败，这是拿业务现状换来的，Agent 给不出；
-
灰度的步长。一次摘几台、观察多久，取决于流量规模，不敢交给模型拍。
还没解决的：多实例并行发版时的锁竞争还得靠人排顺序；回滚只保证回到上一版，做不到回到任意历史版本；健康检查目前只覆盖进程存活，业务指标还没接进去。
六、产物与截图
-
发版脚本：确认版本 → 备份（双保留 + 份数上限）→ 灰度替换 → 健康检查（失败自动回滚）→ 告警收敛，已脱敏，不含真实参数；
-
两次 dry-run 的终端输出（下方截图为本地模拟环境复现，实例名、版本号、应用名均为模拟值，不是生产环境截图）：
【配图①】正常发版 dry-run：备份 → 灰度摘一台 → 健康检查通过 → 逐台替换 → 告警被抑制
【配图②】注入故障：新版本健康检查连续 3 次返回 503 → 判定异常 → 自动回滚到上一版 → 回滚后探测通过 → 告警跳变（OK → FAILED）才发出
- 另一单的界面，作为"能跑 ≠ 能用"那段的对照：
【配图③】房间页：7 个 AI 队友 + 你的位置
【配图④】被抢话瞬间：话头被抢走，名单同步刷新
【配图⑤】评分卡：30 分制 6 维，每维都引用候选人原话
一句话总结：8 月那版证明了"发版可以一条命令"，这次重做证明了"发版失败可以自己收场"。 Agent 模式的价值在"把没写的东西找出来"，IDE 模式的价值在"把改对的东西写进去"。