对着验证码重试，等于告诉风控“我是脚本“——自动化里最贵的一行代码

先说结论：在自动化里，遇到验证码/二次验证/账号锁定就自动重试，是把"一次验证"升级成"账号被挂起"的最经典路径。
这不是道德问题，是概率问题。风控看的是行为模式：一个正常用户遇到验证码会停顿、会换网络、会手动输入；一个脚本遇到验证码会在 30 秒内重复请求三次，每次的间隔精确到毫秒。## 错误写法长什么样pythonfor attempt in range(3): page.goto(url) if page.locator("#captcha").count(): time.sleep(2) continue # ← 问题在这一行 break````continue` 看起来无害。但它表达的是"这是可重试的临时故障"，而验证码**不是**临时故障——它是一个**需要人介入的终止条件**。## 我的写法：把"需要人"建模成正常分支在状态枚举上直接给闸门一个判定：python@propertydef is_gate(self) -> bool: return self in (SessionState.NEEDS_2FA, SessionState.NEEDS_CAPTCHA, SessionState.BLOCKED)然后**重试动作单独做一个枚举，"交给人"是一等公民**：pythonclass RetryAction(str, Enum): NONE = “none” # 当前步原样重试 RELOGIN = “relogin” # 重新走登录 RESTART_ENV = “restart_env” # 关掉浏览器重开一套干净环境 ESCALATE_HUMAN = “escalate_human” # 交给人，停止自动操作关键在于 `ESCALATE_HUMAN` **和 `NONE` 一样是正常返回值**，而不是一个 throw 出去的异常。为什么这点重要？因为异常会被外层的兜底 `except` 吃掉——而兜底逻辑通常就是"重试"。**把"需要人"写成异常，等于把它交给了最不该处理它的那一层。**## 判定顺序也得配合闸门必须在登录标记**之前**判定。原因很反直觉：**验证码和 OTP 是以浮层形式出现在已经登录的页面之上的。**python # ---- 硬闸门（优先级最高） ---- if Marker.ACCOUNT_LOCKED in probe.markers: return Verdict(SessionState.BLOCKED, 0.95, …) if Marker.CAPTCHA in probe.markers: return Verdict(SessionState.NEEDS_CAPTCHA, 0.95, …) if Marker.OTP_INPUT in probe.markers: return Verdict(SessionState.NEEDS_2FA, 0.95, …) # ---- 登录态（排在闸门之后） ---- if probe.has(Marker.SELLER_NAV): return Verdict(SessionState.LOGGED_IN, …)顺序反过来会怎样？页面上的导航菜单还在（因为**底层确实还是已登录状态**），于是判成 `LOGGED_IN`，闸门被完全漏掉。脚本高高兴兴地继续采集，然后在一个永远不会前进的页面上超时。**这个 bug 在本地 mock 上是复现不出来的**，只有真实站点才会暴露。## 还有一个语义坑：HTTP 码别一律当"页面坏了"python# 这些 HTTP 码在亚马逊后台语境的含义是"对方暂时不想理你"，不是"页面坏了"。# 当成网络错误处理：退避重开环境，而不是硬刷。_TRANSIENT_HTTP = frozenset({0, 408, 429, 500, 502, 503, 504})429（限流）和 503 的正确反应是**退避 + 重开干净环境**，而不是"选择器变了，我去改代码"或者"再刷一次"。把限流误判成结构变化，会让你去修一个根本没坏的东西。## 判定结果要带上置信度和证据判定结果不是布尔值，而是带 **confidence** 和 **evidence** 的结构：python@dataclass(frozen=True, slots=True)class Verdict: state: SessionState confidence: float evidence: tuple[str, …] flags: frozenset[Flag] = frozenset()信息不足时退化到 URL 推断，并且**把置信度明确压低**：python # ---- 退化到 URL 推断（置信度明确压低，别假装确定） ---- path = probe.url.split(“?”, 1)[0] if “/ap/signin” in path: return Verdict(SessionState.LOGGED_OUT, 0.6, (“URL 落在 /ap/signin”,), …) flags.add(Flag.PARTIAL_RENDER) return Verdict(SessionState.UNKNOWN, 0.3, (“未命中任何标记”,), …)```一个能报出"我不确定（conf=0.30，原因是没命中任何标记）“的系统，比一个永远返回布尔值的系统好 debug一个数量级——因为前者把排查线索留下来了。## 交付物要能证明这件事这类设计最容易出现的退步是"代码里写了闸门，但没人测它”。我的做法是把闸门判成"转人工"这件事写成端到端用例：demo命令的最后一步就是验证验证码闸门被判成"转人工"。166 项测试里包含真开 Chromium 打本地 mock 后台的端到端——闸门行为有回归保护，不是靠注释承诺。## 完整代码项目开源在这里，测试可以自己跑：https://github.com/Amouren7/amz-harnessPython + Playwright，只做只读采集。README 开头写了 2026-03-04 起亚马逊新协议下哪些能做、哪些不能做——尤其是"多店铺代管"这类形态已经被明确盯上，做之前值得先看一眼。