夜雨聆风你更新了 Codex 或 Claude Code，终端能打开，账号没掉，随手让它改一段代码，测试也过了。
看起来一切正常。
可下一次让它审查 PR，它少问了一次确认，换了调用工具的顺序，或者给出了和昨天不同的风险结论。没有报错，也没有红屏，但你原来熟悉的那套行为已经变了。
这类变化，比工具直接崩掉更麻烦。崩了你会停，顺畅地跑偏却很容易被当成升级成功。
我的判断是：AI 编程工具升级后，先回放旧任务；会运行不等于行为没变。
今天这两个更新，提醒了什么？
OpenAI 7 月 13 日发布 Codex 0.144.2。官方 Release 只有一项修复：回滚一次提示词回归，恢复 Guardian 自动审查此前的策略、请求格式和工具行为。
这里最值得留意的词，不是某个版本号，而是三个行为面：策略、请求格式、工具行为。
也就是说，一个提示词层面的改动，可能不会让程序启动失败，却会改变它怎么理解审查任务、怎么组织请求、什么时候调用工具。官方没有披露影响人数和具体错误结果，所以不该把它写成大面积事故；但这次回滚已经足够说明，提示词也属于需要做回归验收的产品代码。
两天前，Claude Code 2.1.207 的官方 Release 也列出了一组相似信号。
它调整了 Bedrock、Vertex AI、Foundry 上的 Auto mode 开启方式；修复了非交互运行把远程托管设置记成“已同意”、却没有展示安全同意框的问题；还修复了正常系统消息触发提示词注入误报，以及一处配置值进入 shell 命令的注入风险。
这些问题看着不在一条线上，落到使用者身上却都在问同一件事：工具到底按什么规则行动，它在什么时候问你，又相信哪一层配置。
为什么“测试过了”还不够？
传统软件更新，我们习惯看几个结果：能不能启动，接口通不通，单元测试过没过。
AI 编程工具多了一层不稳定面。相同输入未必逐字得到相同输出，这很正常；麻烦在于，升级还可能改变系统提示词、模型、工具选择、权限策略、上下文压缩和告警逻辑。
所以验收目标也要换一下。
你不需要追求每句话一模一样，要检查的是那份“行为合同”有没有被悄悄改掉：
它会不会在相同位置请求确认； 它读了哪些文件、调用了哪些工具； 它有没有跳过原本要求的测试或审查； 它把哪些内容标成风险，又漏掉了什么； 它最后改动的范围，是否仍和任务边界一致。
一份代码能跑，只能证明结果暂时可用。它不能证明过程仍可控。
更新后，先做这四步
第一步，留一组固定的旧任务
别等更新完成后再临时想怎么测。
平时就保留三类短任务：一个只读分析任务，一个小范围改代码并跑测试的任务，一个代码审查任务。每个任务都写清允许读取的目录、能否改文件、必须运行的检查和预期停下来的位置。
验收标准也别写成“回答不错”。要写成可以对照的动作，比如“只改这两个文件”“修改前先展示计划”“发现高风险项时给出证据行号”“执行外部命令前需要确认”。
第二步，看过程，不只看成品
同一个旧任务，在更新前后各跑一次。
对比四样东西：计划、文件改动、工具调用、权限提示。文字风格变了问题不大；该问的时候没问、该测的时候没测、读取范围突然扩大，才值得停下来。
如果工具支持日志或会话记录，把它留到验收结束。没有记录，就至少保存最终 diff、运行过的命令和关键确认截图。
第三步，重新看一遍设置从哪来
AI 编程工具的设置可能来自用户目录、项目仓库、启动参数和企业托管策略。一次更新后，默认值和优先级都可能变化。
重点检查自动模式、允许的命令、可读写目录、MCP 或插件、网络访问、托管设置。尤其要分清：这是我个人同意的，项目仓库声明的，还是管理员下发的。
如果你说不清一个开关由哪层控制，就先别在重要仓库里放开它。
第四步，先小范围升级
个人使用，可以先挑一个可撤回的小项目；团队使用，先让少量成员或一条非关键流程升级。
同时记下旧版本号、当前配置和回退方法。观察一两轮真实任务，再决定是否全面更新。
这一步看着慢，实际是在省返工。等到所有人都更新、配置也被同步后才发现行为变了，定位成本会高很多。
这对用 AI 干活的人意味着什么？
以后评价一个 AI 工具是否稳定，不能只看模型名字和跑分。
对个人来说，更有用的能力是保留几条可回放任务，知道更新前后的差异该看哪里。你会少一次“怎么今天突然不听话”的盲查。
对团队来说，需要把 AI 工具版本和配置纳入普通工程变更：谁先升级，测哪些任务，什么情况暂停，怎样回退。提示词、权限和工具策略都该进变更记录，不能只记安装包版本。
AI 工具越来越像工作环境的一部分。工作环境一变，验收也得跟上。
下次看到“更新成功”，先别急着开大活。
拿昨天做过的任务再跑一遍。能重新打开工具，只是安装成功；旧的行为合同还在，才算升级完成。