当 AI 更快地报告漏洞、提出补丁，团队最直观的选择是加速审查。但审查队列只呈现了困难的一部分：有人需要把相似报告归为同一根因，有人需要比较兼容性与安全取舍，有人需要把修复送到下游并恢复服务。PHP 的公开复盘让这条链条变得具体——风险迹象很早已经出现，真正卡住的是几种修复方案各有代价，而熟悉引擎且能够作决定的人手有限。[1]
此前本刊沿着代码审查讨论过：少一轮审查，可能减少返工，也可能把工作留给以后；因此不能只看评论量或轮数。这次新增的认识是，即使问题已经被认定为真实，团队仍可能因为无法选定可接受的修复而停滞。PHP 后来的进展既来自研究者给出明确利用路径，也来自专职人员投入、优先级提升和决策机制调整。把延误简单归为“模型还不够强”或“人类总是瓶颈”，都会漏掉可以改变的条件。[1]
Trail of Bits 提供了对其中一段工作的具体改进。它让修复证据经过旧版失败、新版成功和撤销后再次失败，再用真实入口检查旧行为是否被破坏。重要的不只是多了一位检查者，而是后一个步骤可以重新运行前一个步骤的主张。版本与证据的交接有机会减少重新理解问题的成本；同时，严格举证留下的边界案例也必须交给人，不能当成问题已经消失。[2]
Dan McAteer 的监督界面从人的一端补充了这个判断。提醒曾帮助他发现未提交工作，也因为几乎每轮触发而开始被略读。增加检查次数不自动增加注意力；如果输出无法区分必须处理的缺口与普通建议，人就又要承担一轮解释。这里可以借用补丁流程的做法：重要提醒直接指向证据和可执行的下一步，而不是只生成一个完成标签。[3]
外部站点的经历则提醒我们把交付终点放远一点。Weird Gloop 预防性停机期间用缓存保住大部分访问，但动态服务仍有中断；维护者担心人员很少的公共网站承受不了持续的紧急应对。这一经历不能代表所有网站，却表明发现方节省的时间与运营方付出的工作可能发生在不同组织，不能只在单个团队的账上评价整条流程。[4]
我的判断是，值得扩大的能力包括发现新问题，也包括把证据、决定与修复交给下一位参与者。下一次比较不妨追踪同一批报告从成立、选定方案、发布到恢复服务的等待和返工，再看哪些自动化真正缩短了交付。这个建议尚未验证；本期材料已经足以说明，报告数、补丁数与误报下降都只是其中一段，不能各自替代最终结果。