卖安全边际更值钱。调用API写个Agent谁都会，但敢签SLA、敢承担决策失误赔偿的没几家。能力会越来越便宜，责任和信任才是护城河。客户买的不是「能做什么」，是「出事谁兜底」。

结论：AI 生成的测试用例不能直接当质量门，但可以作为“候选用例”经过准入审查后，分层进入门禁。门禁要求结果确定、可复现、可归因，未经审查的生成用例做不到这三点。 一、为什么不能直接当质量门 1. 断言可能是“复述实现”：模型常根据现有代码反推期望值，代码有 bug 时用例照样通过，等于给缺陷盖章。 2. 覆盖率虚高：行覆盖上去了，但边界值、异常路径、数据约束（空值、超长、并发、幂等、时区）经常缺失。 3. 不稳定：Mock 与真实依赖行为不一致、依赖执行顺序或时间，会产生 flaky，门禁一旦误报，团队很快会绕过它。 4. 不可追溯：用例与需求条目没有映射，失败后无法判断是需求变了、代码错了还是用例错了。 二、准入审查（进门禁前） 1. 需求对照：每条用例标注对应的需求点或验收标准，没有对应项的只能留在探索性集合。 2. 边界与异常：人工按清单补齐——边界值、非法输入、依赖超时与失败、权限、数据约束、重复提交。 3. 断言审查：期望值必须来自需求或契约（接口文档、数据库约束），不能来自被测代码的当前输出。 4. 变异验证：对关键模块做变异测试（故意改坏逻辑），用例抓不住变异体，说明断言太弱，不予放行。 5. 稳定性验证：同一用例在干净环境连续跑 20～50 次，全部通过才允许进入阻断型门禁。 三、分层使用 - 阻断型门禁：只放经审查、稳定、与需求强关联的用例，覆盖核心链路和已出过线上事故的场景。 - 告警型（不阻断）：新生成、未验证稳定性的用例先在这一层观察，连续稳定一段时间后再晋升。 - 探索性参考：用于启发测试思路、发现遗漏场景，不计入通过率和覆盖率指标。 - 晋升与淘汰要有规则：flaky 用例自动降级并记录，不允许靠重试掩盖。 四、流水线落地要点 1. 用例以代码形式入库、走评审，与普通代码同样 Review，生成来源在提交信息中注明。 2. 在 CI/CD 流水线（如 CODING DevOps 或自建 Jenkins/GitLab CI）里拆成多个阶段：单元、接口、端到端分别设门禁阈值，失败时输出可定位的日志与复现命令。 3. 测试数据与环境隔离：每次运行使用独立数据和容器化环境，避免用例相互污染。 4. 指标上看“缺陷逃逸率、变异得分、flaky 率”，不要只看生成数量和覆盖率。 五、小结 AI 负责提高用例产出速度，人负责判断“测什么才算对”。先审查再分层放行，门禁的可信度才不会被生成用例拖垮。

正：Computer Use 的价值在兜底。当目标系统既没有 API、也没有 MCP，浏览器自动化又难以覆盖时，它靠截图识别与坐标点击把最后一公里跑通，让存量系统不改造也能被自动化接管。因此工具选型应逐级降级：API/MCP 优先，浏览器自动化其次，桌面操作垫底，把不确定性压缩在最小范围。 反：但能让机器点鼠标，不等于有业务授权，更不等于动作已成功。界面漂移、权限弹窗、异步状态会让同一步骤在不同会话里产生不同结果；缺少独立身份、租户作用域、白名单与沙箱约束时，一次越权点击就可能放大为真实的资金或数据损失。转账、退款、删除这类不可逆动作，绝不能只凭屏幕视觉判定成败，否则回滚成本远高于省下的接入成本。 定：用反演思维先假设误操作与越权已经发生，再倒推防线，并以安全边际为不可逆动作留出权限、审批与恢复余量。技术上按上述层级设防，产品上强制人工审批、留存操作截图与完整审计链，写操作统一加幂等键、状态回读、超时隔离与补偿机制；验收只看误操作率、任务完成率、人工接管率与回滚成功率，商业上才能把赔付与合规风险算清。