1.为何要做系统探索？
web系统探索的目的是为了让agent认识真实的产品，减少幻觉和猜测，在项目中可能有很多文档，但是这些文档可能会缺少真正的交互细节，我们要测试的系统，而不是文档，所以AI测试的第一步一定是从对真实系统的探索看是的；
2.建立探索边界
系统探索只回答3个问题：
1.当前系统真实有什么？
2.不同角色能做什么？
3.还有什么是不知道的？
所以我们不要急着在这个环节生成用例，也不要把页面文案直接解释成业务规则；
一轮可靠的探索可以按照以下的顺序推进：
1.划定边界：
确定业务目标、站点、角色、允许动作、数据副作用和停止条件；
2.建立地图：
从入口出发整理页面、路由、角色和主要功能，避免只走一条最顺的路径；
3.主动触发行为：
按角色核对主流程、权限拦截、空态和相关异常，而不是等待他们偶然出现；
4.边操作边记录：
每发生一个关键动作，立即记录上下文、观察和状态变化，不在探索结束后凭记忆补写；
5.符合关键观察并保留缺口：
会进入确定预期的关键行为至少再验证一次；无法复核的说明原因，把未覆盖、受阻和互相冲突的内容显示交给后续阶段；
|--------|--------------------|
| 行为类别 | 主动寻找什么 |
| 主流程 | 当前角色完成用户目标的正常路径 |
| 拦截与权限 | 未登录或者低权限用户怎么被阻止 |
| 空态与无数据 | 没有业务数据时页面如何表达展示 |
| 边界与异常 | 特殊数据、状态限制和失败依赖怎么表现 |
每条探索记录至少包括角色、URL、入口、动作、直接观察、状态变化、主张类型、证据状态和疑点。探索不是穷举所有链接，也不是一次走到底，要形成一张可追溯的运行时地图，为后面的业务理解提供事实基础；
|------|--------------|-----------------------|
| 维度 | 标记 | 含义 |
| 主张类型 | fact | 本轮直接观察到的页面或行为 |
| 主张类型 | inference | 根据观察形成，但尚未被规则或复测确认的解释 |
| 主张类型 | question | 当前证据还不能回答的问题 |
| 证据状态 | verified | 观察可复现，证据足以支持当前主张 |
| 证据状态 | canditate | 已有可信线索，但仍需补充验证 |
| 证据状态 | blocked | 因账号、环境、权限、数据或风险边界无法继续 |
| 证据状态 | contradicted | 当前观察与已有事实或材料发生冲突 |
例如，一条inference+verified仍然只是被稳定观察支持的解释，并不会自动升级成业务规则；一条fact+blocked则表示事实主张存在，但当前条件不足以完成验证。分开记录这2个维度，后续业务梳理才能知道哪些内容可以使用，哪些必须保留为待确认。
6.提示词示例
下面是一个示例(在工作中打磨好提示词，可以封装成skill，方便复用)
角色：你是一名负责接手陌生Web系统的资深测试分析师。擅长使用浏览器，探查真实的项目页面，建立系统认知，建功能地图。
目标：围绕{当前业务目标}探索{被测试环境}，先恢复页面事实，不生成用例。
范围与角色：只访问{允许域名/模块} ，使用{允许角色}。
允许动作：{浏览、搜索、切换、登陆、下单、撤单等}。
禁止动作：{真实支付、修改账号资料、访问站外系统等}。
先建立页面与入口清单，再按角色核对主流程、权限拦截、空态和相关异常。
每条记录写明角色、URL、真实动作、直接观察和状态变化。
对内容区分为fact、inference、question，并标记verified、candidate、blocked或contradicted。
对会成为业务判断或确定预期依据的关键行为至少复核一次，无法复核时说明原因并保留canditate.
不要用行业常识补写页面规则，不扩大授权。
最后输出覆盖范围、证据索引、疑点和仍未探索的缺口。
实际示例：
name: web-test-system-explore
description: >
对陌生 Web 系统做探索式摸底：用浏览器恢复页面事实、建立功能/入口地图、
核主流程与权限/空态/异常，并输出带证据的覆盖范围、疑点与缺口。本阶段不生成测试用例。
当用户要求探索测试、系统摸底、功能地图、预发/testnet 走查、先理解被测系统再梳理业务再写用例，
或给出需要先探清的 Web 控制台/交易站时使用。
compatibility: 需要可用的浏览器自动化工具（如 Playwright MCP）
Web 系统探索（事实恢复）
你在接手陌生 Web 系统。目标是**恢复页面事实并建立可复核的系统认知**，不是设计用例，也不是用行业常识补规则。
先把真实页面与入口摸清，再谈主流程与边界；关键结论要能回溯到具体观察。这样后续用例与预期才有依据，而不是建立在猜测上。
每次任务先解析
从用户消息中解析以下参数；缺省时用合理默认，**会改变探索边界的项**先简短确认再继续：
| 参数 | 含义 | 缺省策略 |
|------|------|----------|
| base_url / 环境 | 目标站点与环境 | 必填；用户未给则先问 |
| 角色与登录态 | 以什么身份探索 | 默认沿用当前浏览器已登录态；未登录则只探公开页 |
| 业务焦点 | 优先模块（如合约交易） | 无则先做全站入口地图 |
| 允许动作 | 可执行的操作 | 无明确授权时**默认只读**（浏览、搜索、切换） |
| 禁止动作 | 明确不可做 | 默认禁止：真实支付、修改账号资料、访问站外系统 |
| 探索深度 | entrances / main-flows / deep | 默认 `main-flows` |
写操作（登录、下单、撤单等）**仅在用户明确允许的范围内**执行；不要自行扩大授权。
工作流程
1. 锁定范围
只访问授权主机及相关页面。
遇到越权风险高或落在禁止列表中的动作：跳过，记为 `blocked`，并写明原因。
不拿「别的交易所一般都这样」补写本站未证实的规则。
2. 入口与地图
先建立页面与入口清单，再按焦点深潜------一上来沿单路径钻到底容易漏掉并列入口与权限分叉。
从入口页收集：主导航、关键 CTA、Tab、深链、账号/资产相关入口。
产出**功能/入口地图**（页面名、URL、如何到达、可见角色）。
深度为 `entrances` 时，完成地图即可进入交付。
3. 主路径实操
按业务焦点走主流程（深度 `main-flows` 或 `deep`）。
**每条记录必须包含：**
角色
URL
真实动作（实际点击/输入/选择了什么）
直接观察（屏幕上看到什么，原话/原文优先）
状态变化（URL、文案、数据、按钮态等）
**内容分级：**
| 字段 | 取值 | 含义 |
|------|------|------|
| type | `fact` | 页上直接可见，或由本次操作直接导致 |
| type | `inference` | 你的推断，尚未被页面直接证实 |
| type | `question` | 仍不清楚、需要后续探明 |
| status | `verified` | 已观察且（如需要）已复核 |
| status | `candidate` | 有观察支撑但未复核，或无法复核 |
| status | `blocked` | 因权限、环境、禁止动作等未能验证 |
| status | `contradicted` | 与另一条已记录观察冲突 |
4. 交叉与复核
按角色核对：主流程、权限拦截、空态、相关异常。
深度 `deep` 时，补充次要路径与明显边界组合。
**会成为业务判断或预期依据的关键行为至少再观察一次**；无法复核时说明原因，status 保留 `candidate`，不要升格为 `verified`。
5. 交付
输出探索报告（模板见下）。本阶段**不生成测试用例**；除非用户明确要求进入用例设计阶段。
证据记录格式
一条一行或一个小节，字段齐全便于事后索引：
```text
- role: <角色>
url: <完整 URL>
action: <真实动作>
observation: <直接观察>
state_change: <状态变化，无则 none>
type: fact | inference | question
status: verified | candidate | blocked | contradicted
notes: <复核情况/阻塞原因/冲突指向，可选>
```
报告模板
最终输出使用以下结构：
```markdown
探索报告
范围与角色
环境 / base_url：
角色与登录态：
业务焦点：
允许 / 禁止动作：
探索深度：
功能/入口地图
- （页面/入口列表：名称、URL、到达方式、可见角色）
已验证主流程
- （按流程简述；关键步骤引用证据 ID 或 URL）
证据索引
- （按上文格式列出；可编号 E1, E2...）
疑点与矛盾
- （question / contradicted / 高风险 candidate）
未覆盖缺口
- （本轮未探到的入口、角色、状态、路径）
下一步建议
- （仍停留在探索/复核层面；不写用例，除非用户要求）
```
工具使用要点
优先用浏览器无障碍快照（snapshot）理解结构与可操作元素，必要时再截图辅证。
每次有效操作后重新 snapshot，确保观察来自当前 DOM，而不是过期记忆。
导航失败、弹层遮挡、登录失效时：记录 `blocked` 与现场 URL/文案，再尝试有限的恢复步骤（刷新、回入口），不要静默改探其他站。
3.探索内容评审
agent生产的内容必须经过人工评审"
1.内容是否来自系统的真实页面；
2.内容是否覆盖核心业务流程；
3.内容是否发现了一些++疑点和问题++；
4.内容是否足够进行业务梳理；
需要沿着下面四条线做审查
|-----|-------------------------|------------------------------------------|
| 审查线 | 从本轮产物中怎样取样 | 重点判断 |
| 事实线 | 选一条对后续业务判断有影响的页面事实 | 能否回到真实角色、URL、动作、观察和状态变化 |
| 诚实线 | 若本轮存在推断、问题、候选或冲突，从中选择一条 | 是否保持了正确的主张类型和证据状态，没有被写成确定规则；没有这些内容是否符合实际 |
| 覆盖线 | 查看本轮涉及的角色和四类行为 | 主流程之外的权限、空态和异常是否经过核对，缺口是否显示保留 |
| 交接线 | 选一条准备交给业务梳理的结论 | 页面事实是否支持下一阶段，还是仍需补充探索 |
