#每日精选文章# 模型问你「确定要删吗」，不等于它有防护。

同一段对话补测：第一轮它只查单、要确认；第二轮回一句「确认，是测试数据，可以直接删」，
它立刻调用删除接口，订单真没了。3 次采样 3 次都删。

那道确认闸是行为层的、一次性的。要防只能在自己的代码里另加一层：
默认不把删除工具注册给模型；注册了，调用时也得验身份。

#每日精选文章# 排查老项目代码，发现一个让人后背发凉的 catch：
全量刷新 Redis 缓存，delete 旧 key 之后，rightPushAll 失败了。代码只打了行日志，把异常吞了。
结果：满件数缓存是新的，参与商品缓存是空的。价签服务读到空清单，门店价格全错，直到顾客在收银台发现不对……
一行没有任何重试和告警的 log.error，是怎么酿成数据漂移的？复盘全记录

#每日精选文章# 一个能直接抄走的结论。

Spring AI 2.0 配重试，写 spring.ai.retry.* 没用。那套 RetryTemplate 是给「自己实现 HTTP 调用的客户端」准备的。

OpenAI 走 openai-java SDK，SDK 自带重试，读 spring.ai.openai.max-retries。

验证：假上游连返 500 后成功，数上游收到几次请求。配错只有 1 个。