企业官网建设流程全解析

让 AI 写一段重试逻辑并不难，难的是让它判断哪些请求不该重试。一个简单的 HTTP 状态码背后，可能藏着完全不同的业务状态：请求到底有没有到达服务器？服务器有没有已经处理过？重复发送会不会造成重复扣款？

有人做了个小实验，准备了 14 个 API 失败场景，包含请求方法、响应状态码、幂等键、限流头等额外信息，要求每个模型对每个场景返回一个决定：立即重试、延迟后重试，或者不重试，同时给出一句话解释。评分只看决定是否正确，解释不计分，但会被收集，用来观察模型是否真的理解了场景。

测试的模型有 8 个，包括常用的几个编码和文本模型。每个场景都有预期答案，最终成绩就是正确决定的百分比。

先说最扎眼的结果。一个支付请求返回了 429，并附带 Retry-After 头，看起来像是典型的限流，应该等一等再试。但这个请求没有幂等键，重复发送可能导致重复扣款。24 次尝试中，只有 6 次做出了正确判断，正确率 25%。而且六次失败在三个轮次里完全一致，不是随机波动，更像是模型系统性地掉进了同一个坑：看到 429 和 Retry-After，就条件反射地选择重试，忽略了支付场景缺少幂等保护这个关键上下文。

反过来，另一个支付场景附带了幂等键，重复请求不会造成重复扣款，模型们基本都能正确处理。这说明它们不是完全不懂幂等，而是在信号冲突时，容易被更显眼的 HTTP 状态码带偏。

除了这个支付陷阱，其他场景的表现分布也值得看。14 个场景里，有 7 个在全部 24 次尝试中都答对了。这些主要是直截了当的重试情况，比如服务不可用、限流且明确告知等待时间等。真正的差异出现在需要判断重试时机、多步状态流转或者上下文有矛盾的地方。

有意思的是，同一个模型三次运行的得分可能一样，但错的具体场景会变。比如有个场景叫过期过滤器工作流，四个模型在不同轮次给出了不同答案。有的模型从立即重试改成了延迟后重试，它仍然认为可以重试，只是对时机的判断变了。这让人开始怀疑，只按立即重试和延迟后重试严格区分对错是否合理，也许某些场景本来就允许多个合理答案。

再看稳定性。8 个模型乘以 14 个场景，一共 112 个组合，跑了三轮。其中 102 个组合在三轮里对错结果一致，稳定性大约 91%。也就是说，大部分情况下模型表现是稳定的，但同一得分背后，模型可能在不同场景上犯错，只是错误数量恰好相同。

效率方面，有的模型明显更省。有个模型在文本生成和样式任务上用得挺多，这次也保持了较低的成本，但它的成绩最差。另一个模型花费排在第二高，原因不完全是 token 定价，而是它没有遵守输出格式，本该只返回一个决定和一句话解释，却输出了几千个字符，把成本拉高了。

这个实验最直接的启示是，AI 辅助编码时，让模型生成重试策略容易，让它正确判断哪些请求该重试、什么时候重试，仍需要人把关。尤其是在支付、订单、库存这类涉及状态变更的场景，HTTP 状态码只是线索之一，方法是否幂等、有没有幂等键、请求是否可能已被处理，这些上下文同样关键。盲目照着模型的决定去重试，风险可能比不重试更大。

从方法上看，这个基准测试还能改进。比如允许某些场景有多个可接受的答案，而不是只认一种。或者把解释也纳入评分，观察模型是不是蒙对的。但即便在目前这种简单评分下，最强模型也没有全对，说明这个看似基础的问题，对 AI 来说远没有到轻松解决的程度。

对于日常开发，一个实用建议是：可以让 AI 帮你列出重试策略的候选方案，但最终判断哪些请求可以安全重试，应该由了解业务幂等性和状态流转的人来确认。如果模型给出的理由和你的业务上下文冲突，不要因为它的决定看起来符合 HTTP 惯例就忽略矛盾。