审查 AI 修复：别让 HTTPS 丢掉证书校验

AI 提交的 PR 声称修好了 HTTPS 请求，接口也确实通了，但改动可能只是关掉证书校验。作者反复遇到这类修复，因此给自己加了一道 60 秒审查：检查连接恢复的原因，以及错误证书是否仍会被拒绝。

这篇短文的价值，在于提醒我们区分「请求成功」和「故障修复」。对经常让 AI 处理 Node API 调用、证书报错的开发者，这个区别值得放进代码审查流程。

请求通了，为什么还不能算修好

作者列出了几种在 agent 编写的 PR 中见过的做法：Node 环境里的 NODE_TLS_REJECT_UNAUTHORIZED=0、verify=False、InsecureSkipVerify: true，以及自定义的信任所有证书的证书存储。

它们能让某些 HTTPS 请求恢复成功，却没有修复原来的证书问题。可能出错的信任链、主机名或过期证书，仍然没有得到处理。

TLS 证书校验要回答的，不只是「能不能连上」，还有「对面是不是应该连接的那个服务」。关掉校验之后，请求成功只能证明通信继续了，不能证明对端身份可信。

恢复连接与保留身份校验，是修复必须同时满足的两个条件。

作者要求连接在证书错误时仍然「失败关闭」（fail closed）。大白话就是：身份验证过不了，就拒绝连接，不能为了让流程继续而默认放行。

用 60 秒检查，AI 到底改了什么

作者的检查从 diff 开始，而不是从 PR 描述开始。只要 agent 宣称修好了 SSL、证书、握手或「unable to verify」错误，就检查下面三件事。

第一，改动是否处理了证书信任链、主机名或过期证书，还是仅仅禁用了验证。两类改动都可能让请求变绿，但解决的问题完全不同。

第二，如果明天有人对这个主机实施中间人攻击（MITM），什么机制还会拒绝错误证书？作者要求 PR 能明确回答这个问题。回答不了，就退回。

第三，检查绕过是否藏在配置中。除了业务代码里的 verify=False，Docker 配置、环境变量中的宽泛不安全开关，也在检查范围内。

如果唯一改动就是信任所有证书、verify=False 或 reject-unauthorized=0，作者会拒绝合并，直到真正的证书问题有人负责处理，或者绕过路径满足临时、限定范围、有文档记录这几个条件。

这里保留了应急空间，但没有把应急措施当成修复完成。原文也没有进一步说明「临时」允许多久、范围如何界定，团队使用时还需要补齐这些约束。

我的判断

我赞同把审查重点放在「错误证书还能不能被拒绝」上。它比只看成功请求更接近故障的关键，也能防止 AI 把安全约束当成需要消除的障碍。

不过，原文提供的是作者的审查经验，没有具体 PR diff、复现代码、发生次数或对照数据。「60 秒」是作者给出的检查尺度，不能理解成经过验证的审查耗时，更不能据此推断 agent 普遍会这样修复。

这套方法适合快速筛查，完整修复仍然需要证据。相比只确认接口调用成功，我会要求补充一个反向验证：正常证书可以连接，错误证书仍然连接失败。这个建议是对原文检查思路的延伸，作者没有提供具体测试实现。

原文末尾还有免费单页资料和付费审查服务的推广，但没有给出那些材料的内容。它们不能作为这套方法有效性的额外证据。

能拿来做什么

• 让 AI 修复 Node HTTPS 报错时，在任务要求中明确保留证书校验，并要求它解释信任链、主机名或证书有效期中的具体问题。
• 审查相关 PR 时，同时查看请求代码、Docker 配置和环境变量，搜索原文列出的不安全开关，再判断连接恢复是否来自关闭验证。
• 验收时同时验证成功和拒绝两条路径；若确实需要临时绕过，就记录适用范围、原因和后续处理责任，避免把应急配置留成默认配置。