可观测性与浏览器验证

要解决什么问题

Agent 改完代码后，常见做法是读 diff、跑单元测试，然后给出「应该没问题」的结论。UI 是否真的渲染正确、异常是否在日志里出现、P99 是否仍在预算内——这些运行时事实往往被静态推断替代。结果是：bug 复现不了、性能回归发现晚、PR 里只有文字声称「已修复」却没有截图或查询结果。

技能如何工作

本技能把浏览器快照、结构化日志、指标与链路当作一等反馈传感器，要求结论必须附带可核对的证据。

核心原则：

• 用真实信号替代推断：以页面实际渲染、真实错误日志、监控系统测得的延迟为准。
• 验收标准可机器校验：例如 P99 < 2s、某 DOM 元素存在，拒绝「看起来不错」类主观表述。

典型执行流程（QA Verifier 只读、不改业务代码）：

1. 预检验收标准是否可量化。
2. 区分目标：UI、性能/可靠性，或两者兼有；检测环境中是否有浏览器自动化工具。
3. UI 验证：驱动应用，采集 before/after 截图或 DOM，观察控制台与网络请求。
4. 性能/可靠性验证：将约束写成可查询断言，对日志或指标执行查询。
5. 以「预期 vs 实际 / 修复前 vs 修复后」成对输出，结论格式为 是/否 + 证据 + 时间戳。

与 harness-verification-loop 衔接触发运行时验证；证据可下游交给 harness-commit-gate 作为质量门禁依据。

适用边界与注意点

• 适合：复现 UI bug、确认 P99 等 SLO、截图验证用户旅程、核对性能预算。
• 跳过：纯文档/配置、仅靠静态分析即可证实的改动、仅后端 API 且无用户可见 UI（可只做可观测性侧验证）。
• 能力缺口：环境无浏览器自动化且任务依赖 UI 信号时，应报告缺口，不要退回读代码猜行为。
• 常见坑：自由文本日志难以聚合；历史指标/日志污染当前验证，需时间范围过滤或清理；截图文件名建议带用例标识与时间戳便于归档。