AI 写代码越来越快之后，交付链路里最容易被低估的环节变成了验收。
一个 issue 修完，只有 diff 和测试日志还不够。许多问题只在已登录页面、灰度账号、生产数据和真实权限组合下出现。如果最后仍由人工打开页面逐项确认，自动化闭环就停在最后一公里。
我的实践是：用 whistle 将本地改动接入真实业务页面，用 CDP 驱动浏览器完成操作和回读。
真实环境是验收起点
单测可以验证函数，接口测试可以验证返回值，E2E 可以验证测试环境的主流程。这些测试必要，但不足以覆盖真实业务现场。
真实缺陷常常依赖多项条件：用户已登录、账号命中灰度、页面读取生产数据、前端资源处在特定版本、后端接口还带权限判断。mock 环境通过，只能说明 mock 里的路径成立。
因此，我给 AI 的验收标准会直接写到业务路径：访问哪个页面，重放哪个动作，观察哪个接口，页面上应出现哪个状态，console 中不能出现哪类错误。
最终验收材料必须包括 URL、关键 DOM、Network、Console、截图，以及原失败条件的消失证据。
whistle：未发布代码的真实演练
代码尚未发布，却需要进入真实页面验证。whistle 解决的是这个环境缝隙。
页面域名仍然使用线上域名，SSO、Cookie、权限和生产数据保持不变；只有本次修改相关的前端资源，或少量接口，被转发到本地 dev server。
这相当于一次小范围演练：业务现场保持真实，局部代码来自本地版本。
这一步的价值在于让本地 patch 接触真实业务条件。没有它，验收很容易退回本地环境；有了它，AI 才能在接近用户现场的页面里检查修复效果。
CDP：浏览器会话的操作层
CDP 是 Chrome 的调试与控制协议。它可以点击页面，也可以读取 DOM、执行 JavaScript、监听 Network、捕获 console、截图，并连接到已登录浏览器上下文。
完整浏览器会话在很多系统中比 Cookie 更重要。我遇到过复制 Cookie 给普通 HTTP 客户端仍然返回 401 的情况，因为站点认可的是当前浏览器里的完整登录上下文。通过 CDP 在页面上下文中请求，才真正复用了这份身份。
所以在自动化验收里，CDP 承担两件事：执行动作，回读结果。执行后必须观察页面、接口和错误日志，不能把“点击完成”当成“业务完成”。
失败归因规则
一个 issue 修完后，我通常让 AI 按这条链路执行：
改代码 → 启本地服务 → 开 whistle 规则 → 打开真实页面 → CDP 重放路径 → 回读证据 → 失败则归因重修。
以“列表筛选数量不对”为例，验收不能只保留截图。请求参数、接口返回、页面渲染数量需要同时确认。
如果请求参数错误，优先回到前端逻辑；如果接口返回异常，检查数据或后端条件；如果页面跳转到登录页，先处理权限或会话；如果接口正确但页面未更新，排查前端状态和渲染链路。
这套规则的目标，是让失败结果重新落回可处理的工程对象，而不是停留在“环境问题”这样的模糊判断上。
权限边界与使用纪律
CDP 操作的是已登录浏览器。浏览器中具备什么身份，自动化脚本就可能具备相同的行动能力。
因此，我把 CDP 放在正式 API 之后：API 能完成的验收优先使用 API；只有需要验证真实页面交互时，才使用 CDP。浏览器使用专用 profile，调试端口只保留在本机，写操作先 dry-run，结束后再从业务页面回读结果。
AI 降低了编码成本，但验收不能继续依赖人工补位。可回读的 CDP + whistle 链路，把“改完代码”推进到“证明修复有效”。这才是自动化交付真正需要补上的一环。
