fieldtest

Fieldtest

使用此技能评估应用作为已渲染软件的表现，而不只是检查代码。输出应以浏览器证据为依据：访问过的路由、视口尺寸、尝试过的交互、控制台／网络信号、可用时的截图，以及可复现的发现。

参考资料

进行完整的现场测试、确定开发 URL、选择角色视角，或校准报告语气与严重程度时，加载 references/browser-session.md。

评估返回的图像、搜索结果、生成内容或示例集合时，加载 references/output-quality.md。控件可正常工作，并不能证明其输出有用。

开始

调用时：

1. 声明正在使用 fieldtest 技能。
2. 确定模式：
   • 仅报告 QA
   • QA 并修复
   • 针对某个路由、功能或回归问题进行检查
   • 响应式／移动端审查
   • 角色浏览
3. 如果用户未指定 URL，则从代码库中检测开发服务器。
4. 如果应用尚未运行，且能明确确定正确的开发命令，则仅在确认其为本地、不会修改数据，且不是宽泛的 dev:all 或连接生产环境的命令后启动。如果有多个应用或命令都可能符合条件，则提出一个简短问题。
5. 选择最适合宿主环境的浏览器工具；如果有一流的本地浏览器可用，不要默认使用较弱的浏览器方案。

在执行会写入数据或触发外部影响的操作前，根据应用配置和运行时环境确定实际使用的数据库、存储、账户及操作目标。localhost 指向前端，不代表其后端服务。仅检查必要的设置，并隐去凭据；如有可用的一次性目标，则使用该目标。目标位置未知时，应视为尚未验证；获准浏览并不代表获准写入种子数据或远程数据。针对实际目标，遵守宿主环境的审批规则。

默认仅生成报告，除非用户明确要求修复问题。

浏览器工具选择

使用可用的最强浏览器；必要时可平稳降级到 Playwright，并明确标注任何仅基于静态检查的结果属于未完成的现场测试。完整的备用方案顺序见 references/browser-session.md。

对于本地 Web 应用，如果有支持浏览器的工具可用，不要仅通过 Shell 检查来完成现场测试。此技能的重点是已渲染的行为。

上下文扫描

阅读足够的代码库上下文以理解其意图，无需审查整个仓库：

• package.json 和委派的工作区 package.json 文件
• 框架配置，例如 next.config.*、vite.config.*、astro.config.* 或 playwright.config.*
• 路由文件，例如 app/**/page.*、pages/**、src/routes/** 或同等文件
• 最近的更改：git log --oneline -10 和 git status --short
• 存在时的设计、产品或品牌文档
• 应用专属说明，例如 AGENTS.md

为检测端口而读取 .env* 时，仅检查解析本地 URL 所需的键，例如 PORT、HOST 或框架专用的开发服务器变量。不要在报告中引用或概述机密信息。

将以上内容整理成简短的固定上下文：

• 意图
• 可能的主要流程
• 技术栈
• 开发 URL
• 后端目标，以及测试操作获准产生的影响
• 测试范围内的路由
• 角色或测试视角

浏览时使用此摘要；不要在脑中长时间保留未经整理的文件原始内容。

浏览器会话

基于证据开展工作：

1. 打开目标 URL，确认页面确实已加载。
2. 检查控制台错误和明显的网络故障。
3. 交互前记录第一印象。
4. 测试主要流程。
5. 在安全的情况下，触发至少一种空、无效、加载中或错误状态。
6. 浏览相邻或重要的次要路由。
7. 当任务范围较广或涉及视觉时，检查移动端和桌面端宽度下的响应式表现。
8. 检查主要控件的键盘操作和可访问名称基础项。

对于异步流程，尝试在 A 完成前执行 B；观察加载、失败和最终状态。较晚返回的响应不得替换 B，无关更新不得重放 A 或清除当前错误。如果应用嵌入在其他产品中，请在实际宿主环境中验证内容的呈现和交互；独立浏览器演示只能覆盖该演示本身。

对于破坏性操作、付款、邮件、订单、发布或生产环境变更，只有在用户明确授权后才能继续；如缺少必要授权，请先询问。

录制

进行完整的实地测试时，如果浏览器工具支持录制，请录制一段主要流程的短片（约 30 秒）。为文件取一个有意义的名称。读者应能仅凭短片验证发现的问题，只有在短片显示异常时才需要查看代码。录制是可选的；如果工具不支持录制，请跳过。

测量规范

这里的每条规则都来自一次曾得出错误但看似确定的数字的测量。

• 每次测量前都要确认视口和 URL。 重新读取 innerWidth+"x"+innerHeight 和 location.href；如果其中任一项与要求不符，请重置并重试；如果页面尺寸或页面不对，就拒绝报告测得的数字。错误的测量结果看起来也像证据。
• 让检测工具自行发现缺陷，而不是告诉它去哪里找。 如果检查目标是你已认定答案所在的位置，就无法证伪自己的判断。优先选择可能带来意外发现的测量，并提前说明什么结果会推翻你的判断。
• 判断之前，先证明捕获结果有机会呈现缺陷。 如果截图中要比较的两个区域恰好色调相近，它就无法证明两者的边界。先检查前置条件（对比度、状态、数据存在），不满足时就拒绝使用该截图。
• 只检查页面声明内容是否正确，会漏掉什么都没声明的页面。 每项“已声明内容正确”的检查，都要配套一项“没有内容被遗漏声明”的检查。
• 等待最终状态，而不是首次出现。 元素一出现就结束的轮询，测量的是内容开始呈现的时刻；固定时长的等待，只能测量届时已呈现的内容。应等待代表流程完成的条件。
• 程序化点击不等同于手指点击。 程序化点击会绕过命中检测、指针事件和遮罩层，可能让手指无法触及的控件通过测试，也可能让手指可以触及的控件测试失败。使用工具的真实点击操作，并断言交互预期产生的变化。
• 你读取的数值可以被你找理由解释；你拒绝接受的数值才值得信任。 在驱动脚本中设置阈值，而不是只放在脑中。

用户视角

如果用户提供了用户视角，就使用它；否则选择最相关的视角：

• 首次使用者：清晰度、方向指引、标签、下一步、错误恢复。
• 设计师：层级、间距、字体、独特性、交互质量。
• 操作人员：重复工作流、信息密度、表格、筛选器、批量操作、状态清晰度。
• 演示者：叙事、可靠性、亮点、演示过程中的风险。
• 响应式审查员：移动端适配、溢出、目标尺寸、视口特定布局。

不要把用户视角浏览变成空泛的审美评论。问题发现仍须有证据和影响说明。

发现

仅报告有浏览器证据支持的问题。与其罗列许多细枝末节，不如优先报告少而重要的问题。

每项发现应包含：

• 严重程度或优先级
• 路由／屏幕
• 发生了什么
• 影响
• 复现步骤
• 证据，例如截图路径、录制文件路径、控制台消息、网络状态或可见状态
• 在代码检查有依据时，说明可能原因
• 建议的修复方案

如果没有明显问题，请明确说明，并提及已测试的内容。

修复模式

用户要求修复时：

1. 在浏览器中复现问题。
2. 检查范围最小的相关代码路径。
3. 进行范围明确的修改。
4. 运行相关检查。
5. 在浏览器中重新测试相关路由或流程。

如果工具支持录制，请录制受影响流程的修复前和修复后片段，并在报告中附上两个路径。

除非用户明确要求同时进行代码审计，否则不要修复未经复现的推测性问题。

输出

完整报告请使用：

## Fieldtest Report

Target: [URL]
Mode: [report-only QA | QA plus fixes | focused route/feature/regression | responsive/mobile audit | persona browsing]
Lens: [persona/lens]
Browser: [tool used | static inspection only, not browser-verified]
Viewports: [sizes tested]
Recordings: [clip paths, or none]

## Findings

### High

### Medium

### Low

## What Was Tested

## Residual Risk

针对性检查可缩短输出，但仍须包含目标、步骤和结果。

完成检查

完成前，请确认：

• 应用确实已在浏览器中加载
• 已注明测试的 URL 和视口尺寸
• 在工具支持的情况下，已检查控制台和网络问题
• 发现包含复现步骤或具体证据
• 覆盖范围列明了检查过的案例和未检查的内容；已加载或录制的案例不计为已进行视觉检查
• 未经确认未执行破坏性流程
• 如有修复，已在浏览器中重新测试
• 工具支持录制时已录制；否则已说明未录制