优测测试场景构建专家 (Utest Plan Architect)

skill安装

1. 下载Skill，
2. 下载scripts文件https://docker-hub-1254257443.cos.ap-guangzhou.myqcloud.com/skill-cli/1.0.0/utest-generate-test-plan-scripts.zip
3. 将scripts文件解压到skill文件下
4. AI工具加载skill

拼装后目录结构如下

utest-generate-test-plan/
├── SKILL.md 
├── references/ (文档目录)
│   ├── account_prepare_trace.md 
│   ├── api_node.md (8.16 KB)
│   ├── apply_uin.md (6.39 KB)
└── scripts/ （文件解压位置）
    ├── Utest-Skills-Files.txt 
    ├── utest_darwin_amd64 
    ├── utest_darwin_arm64 
    ├── utest_linux_amd64 
    ├── utest_skills_install.ps1 
    ├── utest_skills_install.sh 
    └── utest_windows_amd64.exe 

核心定位

用于处理以下五类任务：

1. 从代码、协议或需求生成/修改优测测试场景。
2. 将本地测试场景保存/批量上传到优测平台。
3. 调试本地优测用例 JSON。
4. 同步/保存环境配置，或把已有数据集绑定到已有环境。
5. 申请UIN。

测试任务能力下线路由

若用户意图属于以下任一类型，本 Skill 不再处理：

• 执行/ 执行测试任务 / 接口测试任务
• 其他面向测试任务的管理诉求

命中以上诉求时，不再继续思考、不再继续分流、不再读取其他文档、不再尝试调试，也不再做任何额外判断。

此时必须直接返回固定提醒：当前 Skill 已不支持测试任务执行或接口测试任务。请前往 https://knot.woa.com/skills/detail/13713 下载优测最新出的任务管理 Skill。该 Skill 支持任务的增删改查和执行，功能更强大。当前 Skill 仍支持本地优测用例 JSON 调试。

总原则：让 SKILL.md 只负责“路由、边界、闭环”，具体结构细节放在 references/。

核心执行总规则

一、执行顺序

1. 先热更新，再读任何 references/*.md。
2. 先判断边界，再判断阶段：先判断能不能做，再判断当前属于生成、上传、调试、环境同步，还是测试任务引导；其中“测试任务能力下线路由”优先级最高，一旦命中就立刻固定返回。
3. 默认不用 MCP：除非用户明确提到 MCP 或 utest-mcp。
4. 先本地落盘，再询问是否上传。
5. map init 默认延后：仅在生成用例 JSON 完成后且目标目录内不存在 .utest-map.yaml 时执行；上传、调试、环境相关阶段默认不要主动执行。

二、需要立即中断或先询问的情况

6. RPC和quic 缺少 app_server_name 时立即中断：唯一合法回复是 请提供协议文件的 app_server_name。
7. 协议不确定先问：用户未明确协议时，只有在基于已有信息或可搜索到的信息能够 100% 确认 协议类型时才可继续生成；只要仍有歧义或拿不准，就必须先询问用户要生成什么协议（如 HTTP/REST、RPC、QUIC、Dubbo、SSE），严禁默认按某种协议继续。
8. 实际请求参数不确定先问：生成请求时，不能只看 schema 的 required 字段。凡是会影响真实请求能否发出、路由、鉴权、资源定位、协议解析或业务成功的参数，不论它位于 path/query/header/body、顶层/链路级 args、协议头模板（如 header、quicHeader、authInfo）还是其他固定字符串模板中，只要其实际值无法从用户输入、代码常量、协议示例、example/default/enum、测试数据或已确认样例中 100% 确认，就必须先进入 ask 模式询问用户；严禁用 ""、0、false、[]、{} 等类型默认值、占位值或近似值继续生成可上传、可调试的最终用例。
9. ask 的目标是“让请求可跑通”，不是“只补齐必填项”：用户最终是否提供全部字段值由用户自己决定，但 Skill 必须把已识别到的、会影响实际请求通过的参数一次性纳入询问清单；不能只围绕 schema required 字段追问，也不能靠占位值、近似值或其他兜底写法绕过 ask 模式。如果当前协议请求已经能定位到明确的 message / struct / request body 结构（尤其是 RPC / QUIC 的 proto message），则 ask 前必须先完整盘点该结构中的全部字段，再把字段分成“已 100% 确认可直接填写”“需要用户确认后填写”“可选且由用户明确决定跳过”三类；禁止由 AI 先主观筛掉一部分字段，只挑自己认为关键的字段去问。即使某些字段是可选项，也必须让用户感知其存在并自行决定是否跳过。只要单个结构的字段数 超过 5 个，就必须用完整字段表格或等价清单一次性展示全部字段（至少包含字段路径、所在位置/层级、当前是否可确认、是否可选、说明或示例），不允许裁剪后分批零散追问。

三、结构生成

10. 断言绝不脑补：checkList 的字段名和枚举值必须严格使用 assert_obj 原始定义。
11. 生成 testcase / trace 结构 JSON 时，只保留有实际值的结构字段：凡可省略字段值为 null、""、[]、{}，一律不生成。
12. 这里的“空值字段删除”默认针对用例 JSON / trace 结构本身：适用于 testcase_obj、trace_obj、各类节点对象及其可省略结构字段，不默认作用于请求体、请求头等实际业务参数。
13. 实际业务参数按“值语义”处理：若用户显式指定为空，或通过协议定义、代码默认值、测试用例基线、已确认样例能交叉验证**该字段应为空，则按原样保留（null/""/[]/{}），禁止误删。。
14. testcase_obj 顶层字段只是高频示例，不是限制名单：像 header(这里的header指的是trace的顶层header，不是实际节点类型内的业务请求header)、dnshost、file、dataSetFile、dubbo、jdbc、protoFile、resourceFile、jarResourceFile 为空时当然也必须省略，但其他任意层级、任意结构字段同样适用。
15. 先按需挂载结构字段，再做后置裁剪：构造 JSON 时，不要先创建空数组/空对象占位再指望后面删除；只有字段已经拿到实际值时，才允许把该字段挂到对象上。
16. 输出前必须做全树后置过滤：在输出任何 JSON 代码块、落盘文件或展示最终结果前，必须把整个 testcase / trace 结构视为待剪枝的树，逐层做最后一次遍历删除空值结构字段。
17. 适用范围是整个 testcase / trace 结构树：该规则适用于任意层级、任意结构字段，不局限于 checkList 或某个具体字段名。
18. 凡是和“结构字段空值删除”冲突的内容，都以本规则为准：包括 required、default、参考 schema、示例 JSON、历史样例和通用补全习惯；但这条规则不覆盖“用户已明确指定为空”或“可 100% 确认应保留为空”的实际业务参数。

四、来源与变量边界

19. references/*.md 中的 schema、description、固定模板和示例只用于识别合法字段、枚举、类型和层级，不是逐字段照抄模板。
20. 分支文档、schema 描述和固定模板都不得覆盖 ask 总规则：只要涉及实际请求参数值——包括 path/query/header/body、顶层/链路级 args、domain/serviceName/funcName、协议头模板（如 header、quicHeader、authInfo）或其他固定模板中的业务值——仍必须按本文件“实际请求参数不确定先问”执行；出现“留空”“写空字符串”“补默认值”等说明时，仅可用于理解结构，不能据此跳过 ask。
21. 协议内容里出现的 ${a2} 是执行期自动填充的内置变量：严禁把 a2 加入 testcase 顶层 args、链路级 args、节点参数，或任何其他变量定义中。

说明：map init 的参数语义在各系统上一致，差别只在 shell 调用方式，不是 Go 二进制行为本身。

• 统一命令模板："" map init --path "" [--path "" ...]

• PowerShell 额外注意：执行可执行文件时需要在命令前加 &，即：& "" map init --path "" [--path "" ...]

无感知热更新（加载后第一步）

执行时机：加载本 Skill 后立即执行，且必须发生在读取任何 references/*.md 之前。

• Windows / PowerShell：
  • $out = & powershell -ExecutionPolicy Bypass -File "scriptsutest_skills_install.ps1" 2>&1; if ($LASTEXITCODE -ne 0) { $out | Out-String | Write-Host }
• Linux/macOS/Git-Bash：
  • cd "" && chmod +x "scripts/utest_skills_install.sh" && out="$(/usr/bin/env bash "scripts/utest_skills_install.sh" 2>&1)"; code=$?; if [ $code -ne 0 ]; then printf '%sn' "$out" | tail -n 80; fi; exit 0

失败处理：

• 更新成功：不向用户额外解释，直接继续。
• 更新失败：展示错误输出（至少最后 80 行），并仅提示一次：更新检查失败，将继续使用本地版本。

脚本会读取远端版本文件，并在本地写入 .utest-skill-version。

MCP 使用边界（唯一权威版本）

默认规则

默认禁止调用 utest-mcp / mcp_call_tool。

唯一允许例外

用户明确提到 MCP 或 utest-mcp；

替代路径

• 接口结构/字段：从用户提供的 proto、Go 结构体、代码逻辑中提取。
• 保存/上传：读取 references/save_test_plan.md，走本 Skill 自带 CLI。

该边界在生成、保存、调试链路内持续生效；若用户诉求是测试任务执行或接口测试任务，则直接按“测试任务能力下线路由”进行引导。

意图分流与最小化预读

第一步：先判断当前任务属于哪一类

先做排除：只要命中“测试任务能力下线路由”，就立刻返回固定提醒，不再继续做调试意图识别，也不再进入任何后续流程。

第二步：一个请求包含多个阶段时的处理方式

若用户说“生成并上传”或“生成后顺便调试”，按阶段串行处理：

1. 先完成生成阶段，只读生成相关文档。
2. 生成完成后，再读取下一阶段文档（如 save_test_plan.md 或 debug_case.md）。
3. 不要在一开始把所有文档一次性读入上下文。

生成/修改测试场景的闭环流程

阶段 1：识别协议与补充按需文档

在完成基础文档预读后，仅在需要时追加读取以下文档：

• RPC 通用入口：references/rpc_node.md
• QUIC 通用入口：references/quic_node.md
• Proto 关联：references/proto_obj.md
• HTTP/REST：references/api_node.md
• Dubbo：references/dubbo_node.md
• SSE：references/sse_node.md
• 逻辑控制：references/if_node.md、references/while_node.md、references/parallel_node.md
• 固定账号准备链路：用户明确要求“账号准备链路”“压测账号准备”“账号准备 setup 链路”时，读取 references/account_prepare_trace.md
• 协议扩展：
  • trpc_oidb / oidb → references/trpc_oidb.md
  • sso_* → references/sso_related.md
  • trpc-OVBU → references/ovbu.md

规则：只按当前节点/协议类型加载，不做全量扫读。

协议识别判定顺序

1. 用户已明确说明协议、nodeType，或直接给出足以唯一指向某协议的材料（如 swagger/openapi、HTTP 方法+URL、proto/JCE、dubbo 配置、quicHeader 等）时，按该协议继续。
2. 若用户没说协议，但基于当前已获得的信息或搜索到的代码、配置、文档，只能在能够 100% 确认协议类型时继续；“大概率”“像是”“通常如此”都不算确认。
3. 只要协议仍存在歧义，或在 HTTP/REST、RPC、QUIC、Dubbo、SSE 等之间拿不准，必须先停下来询问用户：要生成什么协议？
4. 在协议未确认前，禁止默认读取某个协议分支文档并直接生成节点；只能保留基础预读，等待用户确认或拿到足够证据。

阶段 2：协议文件前置校验（RPC / QUIC 强制中断机制）

满足以下任一条件，即视为需要协议文件的协议场景：

• 用户提供了 proto / JCE / TAF / tRPC / gRPC / QUIC 等协议内容；
• 准备生成的节点中出现 rpc_node 或 quic_node；
• 用户明确要求生成 nodeType=quic。

此时必须先读取 references/proto_obj.md，并执行以下校验：

• 若缺少 app_server_name：立即中断 生成与落盘；唯一合法回复为：请提供协议文件的 app_server_name。
• 若已提供 app_server_name：写入 protoFile，且 protoFile 对象里只能有 app_server_name，禁止捏造其他字段。
• 硬规则：app_server_name 只能出现在 protoFile[].app_server_name。
• 严禁把 app_server_name 复制、映射或回填到 domain、serviceName、funcName。
• 如果 domain、serviceName、funcName 无法从用户输入、代码、服务注册逻辑中确认：不要猜、不要拿 app_server_name 顶替，必须中断并要求用户补充。
• quic 是独立节点类型，必须使用 references/quic_node.md 中的 nodeType=quic、quicHeader、requestBodyType 等字段；禁止把 quic 塞进 rpc_node.protoType。
• 协议内容里出现的 ${a2} 是执行期自动填充的内置变量；严禁把 a2 加入 testcase 顶层 args、链路级 args、节点参数，或任何其他变量定义中。

阶段 3：本地构建规则

0. 内置账号准备链路

• 当用户明确要求加入“账号准备链路”“压测账号准备”或“账号准备 setup 链路”时，直接使用 references/account_prepare_trace.md 中的固定模板。
• 该模板是固定 setup trace；除删除空字符串、空数组、空对象与 null 字段外，不要改节点顺序或其他业务字段值。
• qqRedis.refreshUins(start, count) 默认使用 qqRedis.refreshUins(0, 500);；若用户明确要求修改，只允许调整第一个参数 start（uin 起始索引）和第二个参数 count（取数范围 / 导出账号数量）。
• 若 testcase 里已经存在前置链路，新增账号准备链路时不要删除、覆盖或改动原有前置链路配置；只把账号准备链路追加进去。

1. 场景拆分

• 按业务相关性拆分多个用例文件。
• 只有接口间存在明显串联/依赖关系时，才放进同一链路。
• 除非用户明确要求单文件，否则禁止把所有接口塞进一个用例或一个 JSON 文件。

2. 输出位置

• 优先遵循用户指定的输出目录/文件名。
• 若用户未指定，默认输出到项目根目录的 testcase/。

3. 服务与路由

• 服务寻址使用北极星方式，标准格式为 sys_polarisDiscover(namespace, serviceName[, env[, canaryLabel]])。
• 第 1 个参数 namespace 表示北极星命名空间；Production 表示正式，Development 表示测试，这两个属于 namespace 的示例值。建议优先使用全局变量，不写死。
• 第 2 个参数 serviceName 表示北极星服务名，只能来自用户明确提供的信息或代码中的服务注册逻辑；找不到或不确定时必须向用户询问，严禁猜测，也严禁用 app_server_name 顶替。
• 第 3 个参数 env 为可选项，表示北极星 env；由用户自己填写，只有在用户明确提供，或代码/配置中能够确认时才可填写；不确定时不要臆造。
• 第 4 个参数 canaryLabel 为可选项，表示金丝雀标签；只有在用户明确要求灰度流量，或代码/配置中能够确认时才可填写；默认不要猜测补齐。
• domain也就是服务url ，需要使用北极星寻址时，serviceName 必须先确认；env、canaryLabel 只有在可确认时才允许拼入表达式。
• 特例：若 protoType=sso_oidb 或 sso_pb，则 domain 固定使用全局变量 ${target}；同时在 testcase 顶层 args 中固定写入 target=${sys_polarisDiscover(Production,sso-internal)}。不是 env；不要改成其他服务名、其他 namespace 或其他 env，也不要把北极星表达式直接写进 domain。
• 用户提供 Go 代码时，优先参考 main.go 中服务注册逻辑确认服务名、方法名和路由映射。
• 北极星寻址示例：${sys_polarisDiscover(${namespace},a.b.c.d)}；若需要显式指定 namespace，可写 ${sys_polarisDiscover(Production,a.b.c.d)}；若需要显式指定 env，可写 ${sys_polarisDiscover(${namespace},a.b.c.d,user-env)}；若还需要指定金丝雀标签，可写 ${sys_polarisDiscover(${namespace},a.b.c.d,user-env,gray-tag)}。

4. 请求体与默认值

• 请求体结构必须严格匹配代码中的结构体/协议字段。
• 仅当满足 MCP 例外条件时，才可通过 MCP 查询最新流量样例值。
• 在生成最终请求前，必须先做一次实际可执行性参数盘点：不能只按 schema required 校验，要把会影响请求能否真正跑通的参数值，与字段名、类型、层级这类结构性信息严格区分。
• 下列内容都属于实际请求参数，只要值无法 100%确认，就必须先 ask，不得继续生成最终可上传用例：用户 ID、订单号、登录态、token、业务枚举值、关键路径参数、关键 query 参数、关键 header、请求体中影响路由/鉴权/查数/资源定位/业务分支的字段值，以及 domain/serviceName/funcName/env/canaryLabel、顶层/链路级 args、协议头模板（如 header、quicHeader、authInfo）里被请求实际引用的变量或命令字。
• 只有在参数值可以从以下来源之一100%确认时，才允许直接写入最终请求：用户明确输入、代码常量、代码里已写死的默认值、协议 example/default/enum、测试数据文件、已确认的历史样例。
• 如果只能确认字段结构，不能确认实际业务值，必须立即进入 ask 模式，一次性批量询问用户缺失的实际请求参数；在用户补齐前，禁止输出可上传、可调试的最终 testcase。
• ask 模式必须一次性列出全部缺失项，至少说明：字段路径、参数位置（如 path/query/header/body/args/domain/serviceName/funcName/headerTemplate/quicHeader/authInfo）、为什么必须提供、可接受的示例格式；不要逐字段零散追问。
• 对于已经拿到明确 message / struct / 请求体结构的请求，ask 前必须先完整盘点该结构中的全部字段，再分成“已确认可直接填写”“需要用户确认”“可选可跳过”三类；禁止只挑 AI 主观判断为关键的字段去问。
• 即使字段是可选项，只要它已经出现在明确的结构定义里，也必须展示给用户感知，并由用户明确决定是否跳过；AI 不能自行过滤掉 webhook、定时配置、通知配置、场景内容等扩展字段。
• 只要单个 message / struct / 请求体结构的字段数 超过 5 个，就必须使用完整字段表格或等价清单一次性展示全部字段，不允许裁剪后分批零散追问。
• 若协议分支存在固定模板或固定字符串结构（如 QUIC 的 authInfo、quicHeader，或 RPC/SSO 头模板），其中出现的 uid、token、cmd、module、命令字、路由值等仍属于实际请求参数；只要实际值无法 100%确认，就必须先 ask，不能因为模板已存在就直接输出最终用例。
• 查询不到样例值，或用户未允许 MCP 时，不能把未知的实际请求参数自动填成类型安全默认值。
• 只有明确属于技术占位、平台固定语义或代码里已写死默认值的字段，才允许保留默认值；未知业务值一律不适用该兜底规则。

5. 断言（checkList）

在生成或修改 checkList 前，必须先以 references/json_schemas.md 中的 assert_obj 为准。

这一段是重点中的重点：断言最容易出错的不是字段名，而是字段内的取值被模型“脑补”错。尤其是 position、operator、checkType 这三个枚举值，必须逐个按 Schema 精确填写，严禁使用同义词、自然语言或看起来差不多的值。

必须遵守：

1. 字段名白名单：assert_obj 中没定义的字段，一律禁止输出。尤其不要臆造 field、path、expected、actual、values、expect、assertKey 等字段名。

2. 枚举值白名单（重点）：

   • position 只能是：code、header、body、bodyJson、publicVariable、rpc_response_header、varJson
   • operator 只能是：eq、ne、gt、lt、ge、le、ctn、n_ctn、belong、n_belong、exist、n_exist、regex_match
   • checkType 只能是：content、len、list

3. 禁止同义词/近义词/自造值：严禁输出 contains、notcontain、not_contains、in、not_in、match、bodyjson、jsonBody、text、length 等任何不在枚举中的值。只要不是 Schema 原文，就视为错误。

4. 先按 Schema 后填值：先确认当前断言对象的字段名和枚举值都合法，再填写具体业务值；禁止边想边编。

5. 当 position="code" 或 position="body" 时，key 没有实际值，不要生成 key 字段；如果要校验 JSON 路径，必须使用 position="bodyJson"，不能写成 body。

6. 每个步骤都必须追加默认状态码断言：

   • position="code"
   • 不生成 key 字段
   • checkType="content"
   • operator="eq"
   • expectValue=["200"]

7. 校验响应 JSON 字段时：

   • position="bodyJson"
   • key 为响应 JSON 路径
   • expectValue 为字符串数组

8. 不确定时的降级策略：如果拿不准某个断言怎么写，先只保留默认状态码断言，或只生成自己能完全确认合法的断言；不要为了“看起来完整”去猜枚举值。

9. 生成后强制自检：逐条检查 checkList，确认每一项的字段名、position、operator、checkType 都能在 assert_obj 中找到原始定义；任何一个值不在枚举里，都必须立即重写。

6. CSV 数据驱动

当用户指定 CSV，或目标 JSON 同级目录存在 CSV 文件时启用：

• 变量占位符统一使用 ${列名}。
• 自动扫描请求体、请求头、URL 参数和断言期望值。
• 若字段名与 CSV 列名语义一致（忽略大小写和下划线），执行映射替换。
• 不额外生成 file 或 file_obj 字段。
• 生成后简要反馈已映射的变量清单。

阶段 4：落盘前兜底校验

对每个即将输出的 testcase_obj 执行以下检查：

• 若存在 rpc_node 或 quic_node，则 protoFile[0].app_server_name 不得为空。
• 若仍存在无法 100%确认 的实际请求参数值，则不得输出最终 JSON、不得落盘，也不得继续引导上传；必须先进入 ask 模式补齐缺失参数。
• 新建场景时，trace 下的 uuid 不得臆造；新建时留空或直接省略。
• 若用户未要求单文件，确认没有把所有接口合并进一个文件。
• 最后一步必须再次执行全树结构字段精简检查：遍历整个 JSON；对 testcase_obj、trace_obj、各类节点对象及其可省略结构字段，若值为 null、空字符串、空数组、空对象，就直接省略；这条检查默认不作用于请求体、请求头等实际业务参数。

阶段 5：落盘与映射初始化

• 使用 write_to_file 落盘。
• map init 的意义是生成 .utest-map.yaml 或做必要补全。默认情况下，它只在生成用例 JSON 完成后，且目标目录内不存在 .utest-map.yaml 时执行；如果 .utest-map.yaml 已存在，则直接跳过。上传、调试、环境相关阶段默认不要执行；但如果用户明确要求“执行 map init”，则允许直接执行。

规则：

• 先检查再执行：先判断目标目录内是否已存在 .utest-map.yaml；存在则不要执行 map init。
• map init来源：map init 不是 shell 内置命令，也不是外部需要现装的工具；它是 本 Skill 在 scripts 目录下预置的二进制执行包的子命令。
• 统一命令模板："" map init --path "" [--path "" ...]
• PowerShell 额外注意：执行可执行文件时需要在命令前加 &，即：& "" map init --path "" [--path "" ...]
• 执行路径规则：优先使用 Skill 文件夹内 scripts 下二进制的绝对路径，不要仅依赖相对路径，因为工作目录（CWD）可能随项目切换。
• 拒绝网络下载 / 拒绝自行安装：如果一时找不到 EXEC_PATH，只能继续核实本地 scripts 目录、修正路径或向用户说明；严禁因为“命令看起来不存在”就去联网下载、包管理安装或生成替代二进制。尤其禁止 curl / wget / Invoke-WebRequest 下载，禁止 npm / pnpm / yarn / pip / go install / brew / apt / choco / scoop 安装任何同名工具。
• 重要：防止工具失明：如果使用常规文件列表工具找不到执行文件，必须使用系统原生底层命令进行核实：
  • Windows: cmd /c "dir /a scripts"
  • Unix/macOS: ls -la /scripts
• --path 必须传绝对路径。
• 若用例分散在多个目录，只对缺少 .utest-map.yaml 的目录提供代表性 JSON 文件路径并执行初始化；已存在 .utest-map.yaml 的目录不要重复执行。

阶段 6：完成当前阶段后再引导下一步

生成阶段完成后，再提示用户是否需要上传，不要在生成前询问上传意愿。

推荐反馈方式：

✅ 测试场景已就绪：已按业务相关性生成本地优测用例 如需继续批量上传到优测平台，请直接说明。

保存/上传阶段规则

仅当用户明确要求上传、保存或同步到平台时触发。

• 读取 references/save_test_plan.md。
• 使用本 Skill 自带 scripts包内的文件 执行保存/批量上传。
• 若 case save 相关参数（尤其 --protocol-type、--sync-type、--git-url、--git-path、--git-branch）未由用户明确提供，则必须直接向用户索取；禁止通过当前仓库、git remote -v、代码搜索或历史信息自行推断。
• 禁止通过 utest-mcp / MCP 的 SaveTestPlan 保存或更新用例。

调试、环境与UIN申请阶段规则

• 先做测试任务排除：如果用户的核心诉求是执行测试任务、接口测试任务、按任务 UUID 执行、apitest、指定执行机执行等，则直接返回固定提醒和下载地址，不再进入调试阶段，也不再判断用户是不是想调试。
• 调试本地用例：只在用户明确表达调试本地优测用例 JSON、调试本地文件/目录、或明确要执行 case debug 时，才读取 references/debug_case.md，使用 case debug。
• 环境拉取：只读取 references/env_pull.md。
• 环境绑定数据集：只读取 references/env_bind_dataset.md。
• 环境保存、上传：只读取 references/env_save.md。
• 申请UIN：只在用户明确表达申请uin、申请uin账号、申请账号、申请拨测账号、申请拨测uin 或申请压测uin 时，读取 references/apply_uin.md，使用 case apply-uin。

这些阶段不要混入生成/上传规则，除非用户明确要求进入下一个阶段。

禁止模式（统一收口）

以下行为一律视为错误：

1. 在生成阶段提前读取上传、调试类无关文档。
2. 生成 JSON 前未读结构文档就臆造字段、枚举或断言操作符。
3. 生成 checkList 时猜字段名，或输出 assert_obj 未定义字段。
4. 生成 checkList 时猜枚举值，或输出 contains、notcontain、bodyjson 这类不在 Schema 中的值。
5. 在非生成阶段（上传、调试、环境同步）未得到用户明确要求却主动执行 map init。
6. 目标目录内已经存在 .utest-map.yaml，却仍重复执行 map init。
7. 生成完成前先问“要不要上传”。
8. 用 MCP 保存/更新用例。
9. 用 MCP 补接口 Schema、目录、鉴权或 app_server_name。
10. 把 app_server_name 回填、映射或复制到 domain、serviceName、funcName。
11. 在北极星寻址场景中，找不到或不确定 serviceName 时仍继续猜值或拿近似字段顶替。
12. 把所有接口都塞进一个 JSON 文件。
13. 为新建场景随意编造 uuid。
14. 用户明确是在做测试任务执行、接口测试任务、apitest、任务 UUID 执行或指定执行机执行，却仍继续使用本 Skill 处理，或误走到 case debug。
15. 用户未说明协议，且基于已有信息或搜索结果仍无法 100% 确认协议类型时，默认按 HTTP/RPC/QUIC/Dubbo/SSE 任一协议继续生成。
16. 只能确认结构字段（如 path/query/header/body、args、模板字段）的字段名、类型、层级，却无法 100% 确认实际请求参数值时，仍继续生成可上传、可调试的最终 testcase。
17. 在实际请求参数值不确定时，用 ""、0、false、[]、{} 等类型默认值、近似值或其他占位方式绕过 ask 模式。
18. 看见分支文档、schema 描述、固定模板或历史样例里带有空串/默认值说明，就把这些说明当成“已确认业务值”继续生成最终用例。
19. ask 模式下零散逐字段追问，或没有一次性列出全部缺失参数就继续生成最终用例。
20. ask 时只围绕 schema required 字段追问，遗漏其他会影响请求实际通过的参数。
21. 已经拿到明确的 message / struct / 请求体结构后，仍由 AI 自行裁剪字段，只挑部分字段 ask，没有把完整字段清单展示给用户。
22. 单个 message / struct / 请求体结构字段数超过 5 个时，未使用完整字段表格或等价清单一次性展示全部字段，而是分批、零散或按主观判断省略字段。