通用测试用例编写与转 xmind

概述

以资深软件测试工程师的角色，将任何业务需求转化为结构化测试用例（测试要点清单），并最终生成 xmind 脑图 / Markdown / HTML 右向逻辑图。

本 skill 是通用流程与规则，不绑定任何具体业务。需求可以是订单、用户、数据、报表、调度、巡检等任何领域——只需按同一套流程执行即可产出同样结构的内容。

四条核心能力（v2.3）：

支付宝 AI 按量付费改造（402 流程）

本 skill 已完成支付宝 AI 按量付费（HTTP 402）改造，付费能力落地在 Step 8，客户端为 scripts/aipay_gate.js（零依赖，Node 内置 fetch，不引入任何第三方支付 SDK），服务端接口契约见 references/aipay-integration.md。付费与业务无关，不影响 Step 0–7 的用例生成质量。

规范端点等价映射（不同接法名称不同，语义一致）：

付费状态判定：402 = 未支付（不得交付全文）；402 且 code 非 PAYMENT_REQUIRED = 凭证无效/金额不符，需重新取账单；200 + Payment-Validation = 已支付，可交付服务端返回的全文。

> 合规说明：付费链路完整可用，但上传属于显式触发动作——需用户主动要求解锁并同意上传清单后才发起（详见 Step 8 与 config/aipay.json）；用户拒绝时回落本地产物交付。

通用性铁律

• skill 中不得固化任何具体业务的字段/规则/术语（如某业务的专用字段、规则编号、脚本逻辑等）
• 本 skill 及 references 中的示例一律使用占位符或中性业务
• 具体业务的内容只出现在产出的 JSON / 脑图中
• 换任何需求，都按同一套流程（Step 0-6）与结构执行

产物清单（关键约束，永久生效）

每次执行本 skill 只产出以下 3 类文件（写入用户工作区）：

> 以上 3 类文件在 Step 6 生成后，必须经 Step 7 打磨工序：先打磨 .json，再由打磨后的 json 重新生成 .md / .html。交付的 md/html 必须是打磨后版本，不得交付打磨前产物。
>
> 默认交付路径：Step 7 通过后，直接把本机的三件套路径交付给用户即完成，全程不联网。
> 可选分支 Step 8（付费解锁）默认不启用：只有用户主动要求"发布/解锁完整版"、并看过上传清单明确同意后，才会把这三份产物上传到配置的服务地址。用户拒绝、地址未配置或任一环节失败，都回落到本地产物交付，不影响产物完整性。

明确不再产出：

• ❌ 不生成 .xmind（XMind 26 强制升级样式 / XMind 8 不兼容旧格式，体验差；用户已确认放弃此格式）
• ❌ 不生成 .opml（除非用户显式要求）
• ❌ 不生成 .xml8、.zen 等其他 x mind 内部格式

专属输出目录（强制，先生成目录再输出）：

• 每次执行生成前，先在输出根目录建立本 skill 专属输出目录 test-points/（输出根目录默认当前登录用户主目录，Windows 即 C:\Users\<用户名>\test-points；用户指定交付目录时用指定目录）。
• 目录不存在则先创建；已存在则沿用，并在写入前按下方强制清理纪律删除该需求上一批产物。
• 本 skill 的全部产物必须输出到该专属目录内，不得散落在工作区根目录或其他 skill 的目录下。
• 目录建立后向用户反馈该目录的完整绝对路径，便于查找最新产物。

强制清理纪律（先清理再生成）：

• 每次生成前，在专属输出目录 test-points/ 内先删除本次需求前缀的上一批全部产物：<prefix>-test-points.json、<prefix>-test-points.md、<prefix>-test-points.html，以及历史遗留的 .xmind / .opml，再重新生成；专属目录内只保留最新一套，避免文件堆积找不到新产物
• 禁止生成 -v2、-v3、-final 等递增命名文件；同一需求重复生成时始终覆盖同一套 <prefix>-test-points.*
• 删除范围只限专属目录内本次需求前缀的产物；不同需求/项目用不同前缀隔离（例如 V3.10.8 用 test-points.*、huiju 用 huiju-test-points.*），禁止互相覆盖、禁止误删其它项目或其它 skill 目录的文件；删除前先列出将删除的文件路径核对范围
• .html 与 .md 都基于 .json 生成，三者保持一致

产物命名约定（ASCII 命名，中文内容只在文件内）：

• 主项目（默认）：test-points/<prefix>-test-points.json / test-points/<prefix>-test-points.md / test-points/<prefix>-test-points.html
• <prefix>：项目/需求的英文/拼音缩写（如 V3.10.8 质控项目用 test，huiju 用 huiju）

核心纪律（铁律，贯穿全流程）

每个步骤末尾均附"检查清单"。清单未全部满足时，必须停下来向用户提问或请求截图，不得擅自往下编写。只有清单全部满足，方可进入下一步。此规则不可跳过、不可妥协。

尤其 Step 0：必须先让用户阐述测试方向、AI 主动思考提问并收集足够信息，禁止拿到需求就直接编写。

工作流总览

Step 7 为强制步骤：产物生成完毕后自动执行，不得跳过；其检查项清单与量化质量标准见该节正文。

Step 8 不是交付前提，默认不执行：本地产物在任何情况下都可直接交付。只有用户主动选择付费解锁、且明确同意上传时，才按该节流程执行；服务端返回内容须通过摘要/结构校验后才落盘。

每个步骤的完整提示词原文见 references/workflow-details.md，执行到对应步骤时加载。字段与模板规范见 references/case-schema.md（v2.2）。

Step 0：用户阐述测试方向 + AI 主动思考提问（核心硬纪律）

目标：在进入 Step 1 之前，先让用户主动阐述本期需求的主要测试方向与业务内容（测试人员视角），再让 AI 主动思考测试维度并向用户列出关键问题收集足够信息。只有"业务理解 + 测试方向 + 待澄清问题"都齐了，才开始用例梳理。

为什么必须有这一步：
- 同一份原型 / 需求文档，不同测试人员会拆出截然不同的用例（取决于各自对业务的理解深度）
- 仅基于原型文字会漏掉业务侧重点——真正的测试重点（核心计算/校验逻辑、数据处理规则、关键控制点等）往往不在原型里直接描述
- 新功能 vs 增量改动的测试策略完全不同（增量改要回归原逻辑；新功能要按功能测全）
- 重构类改动必须当新功能测，并额外验证迁移兼容性（老数据/老流程是否受影响）

AI 必须做的事（收到需求 + 原型后）：

提问方式（必须遵守）：

禁止用纯文字罗列问题让用户手写回答——用户回答成本高、体验差。必须使用选项式提问工具（ask_followup_question / AskUserQuestion）：

• 每个问题提供 2-4 个选项（选项即 AI 基于原型 + 用户阐述推测的最可能答案）
• 每个选项附简短说明，让用户一眼看懂选哪个
• 需要多选的场景（如"哪些数据源需要覆盖"）使用 multiSelect: true
• 若问题超过工具上限（单次最多 4 个问题），分批提问（先问最核心的 4 个，答完再问下一批）
• 选项必须覆盖"不确定 / 按惯例默认"这一项，避免用户卡住
• 若所有预设选项都不对，用户可在工具的输入框中补充自定义答案
• 每个问题必须标注所属模块：问题前面用 [模块A] / [模块A vs 模块B] 等前缀标注，便于用户区分相似功能在不同模块下的差异（例如"数据管理-日"和"数据管理-月"都有"日统计"或"表单编码查询"，必须标注是哪个模块）

提问示例（正确）：

问题：[数据管理-日] 「日统计」的"日"是按哪个日期聚合？
选项：
  A. 实际入库日期（数据进入系统的日期）—— 推荐
  B. 数据发生日期（业务发生的日期）
  C. 不确定，按惯例默认

提问示例（错误）：

1. [数据管理-日] 「日统计」的"日"是按哪个日期聚合？
2. [数据管理-月] 「月统计」的"日"是按哪个日期聚合？
   ↑ 看起来一样但其实是不同问题，必须标注模块让用户知道是问哪个模块

提问示例（错误）：

1. 「日统计」的"日"是按实际入库日期还是数据发生日期？
2. ...（纯文字罗列 8 个问题，用户需逐条手写）

禁止行为：
- ❌ 收到需求直接写用例（不经过 Step 0 提问）
- ❌ 仅基于原型文字闭门造车（必须基于用户阐述的业务理解）
- ❌ 跳过用户提到的业务关键信息（如"同类对象逻辑各不相同需逐个验证"、"存在正反例"、"需对比改动前后结果"等）
- ❌ 用 Step 1 的"被动澄清"代替 Step 0 的"主动思考提问"
- ❌ 把某个具体业务的规则/字段/术语写进 skill（skill 只保留通用流程与规则）

Step 1：需求收集与澄清

目标：在 Step 0 已完成业务理解和测试方向对齐的基础上，进一步逐项明确所有待确认信息（字段、规则、边界、回归影响），确保无歧义。

关键指令：
- 基于 Step 0 的用户阐述 + AI 提问回答，整理出结构化的需求澄清清单（信息项 | 当前状态 | 内容摘要 | 待澄清问题）。
- 仍允许补充提问（仅针对 Step 0 未问到的细节），不要重新做一次 Step 0。
- 一次提出所有问题，每个问题附最佳猜测供用户确认或纠正；界面/流程不清晰时明确请求截图。
- 信息严重不足时不要编造任何业务细节。

详细提示词：加载 references/workflow-details.md 的 Step 1。

检查清单（全部满足方可进入 Step 2）：
- 业务名称与目标、用户角色、核心模块、主要业务流程、关键字段校验规则均已明确
- 所有"待确认"项已得到用户回答，用户无补充信息

> 未满足则提问或请求截图，不得进入下一步。

Step 2：业务理解与测试范围识别

目标：基于已澄清需求，梳理业务流程，划分测试模块，界定测试边界。

关键指令：
- 用文字描述核心业务主路径：起点、关键环节与状态流转、终点、异常分支与回退路径。
- 将业务拆分为可独立测试的模块（模块名 + 职责 + 关键数据实体）。
- 明确测试范围：覆盖模块清单、排除项及原因、环境与数据准备要求。
- 所有内容必须基于 Step 1 已澄清需求，不得编造未确认信息。

详细提示词：加载 references/workflow-details.md 的 Step 2。

检查清单（全部满足方可进入 Step 3）：
- 主流程完整、异常分支与回退路径已识别
- 模块已拆分且职责明确，测试范围已界定
- 用户已确认流程梳理和模块划分无异议

> 流程存在断点或模块边界不清时，向用户提问确认，不得进入下一步。

Step 3：双维度用例设计 + 流程性判定

目标：基于需求分析结果（Step 1/2），完成两件事——
① 从功能层面与数据层面两个维度设计用例，确保核心业务逻辑与边界数据场景全覆盖；
② 判定是否存在流程性用例，据此决定各子模块的输出形式（流程形式 / 标准模板）。

3.1 功能层面（对应"功能正例 + 功能反例"）

3.2 数据层面（对应"场景"）

3.3 覆盖三类场景（强制）

每个功能的设计结果必须覆盖：正常场景（正例） + 异常场景（反例） + 边界条件（场景）。
三类均无内容的功能不允许输出；确实不适用的必须写明原因并标 [待确认]。

3.4 流程性判定（决定输出形式，强制先判定）

判定标准（满足任一即判定为"流程性用例"）：
1. 存在明确的操作步骤序列（开始 → 节点1 → 节点2）
2. 存在状态流转或条件分支（是/否、成功/失败、通过/驳回）
3. 存在回退 / 退回 / 循环 / 重试路径
4. 存在跨角色、跨系统、跨岗位的流转

> 流程形式只用于需求中确实存在流程性用例的子模块/功能分组：先逐条对照上面 4 条标准，四条都不命中的（纯表单字段校验、列表查询筛选、静态说明页、字段边界）一律用标准模板，禁止把"打开 → 输入 → 保存"这类表单操作包装成假流程节点，也不允许为了"有流程"而给没有流程的模块硬造流程。

输出形式决策：

必须输出流程性判定表：

> 不确定是否属于流程性时，向用户提问确认，不得凭感觉硬套流程形式。

详细提示词：加载 references/workflow-details.md 的 Step 3。

检查清单（全部满足方可进入 Step 4）：
- 每个模块都完成了功能层面（正例/反例）与数据层面（场景）两个维度的用例设计
- 每个功能都覆盖了正常 / 异常 / 边界三类场景（不适用者已写明原因）
- 边界值已具体到数值，异常场景已具体到触发条件
- 已输出流程性判定表，每个子模块的输出形式已确定
- 用户已确认用例设计与流程性判定无遗漏

> 字段校验规则、异常处理或流程分支未明确时，向用户提问，不得进入下一步。

需求内容与测试推导分层规则（强制）

测试要点不是 PRD 原文，生成时必须明确区分以下三类内容：

• [PRD明确]：需求文档中直接写明的功能、字段、规则、流程、状态、校验或验收要求；必须能够回溯到 PRD 原文或来源定位。
• [测试推导]：根据 [PRD明确] 需求设计出的正向、反向、边界、兼容、异常、联动或回归测试关注点；可以输出，但不得伪装成需求原文，也不得写成“需求要求”。
• [待确认]：PRD 未说明、存在歧义或无法判断的内容；只能作为测试澄清项保留，不得自行补成确定规则。

标注要求：

1. 测试要点字符串必须以 [PRD明确]、[测试推导] 或 [待确认] 开头；嵌套测试点同样必须标注。
2. [PRD明确] 后保留需求事实；[测试推导] 后描述测试动作或验证关注点；[待确认] 后写明缺失信息和需要确认的问题。
3. 不得把“合法路径”“非法操作不可执行”“缓存更新”“权限控制”“数据隔离”等未在 PRD 中明确写出的内容，直接写成 [PRD明确] 或需求结论；这类内容只能写成 [测试推导] 或 [待确认]。
4. “按 PRD 全量覆盖”表示完整覆盖 PRD 明确内容，不表示可以把测试推导冒充为 PRD 内容；交付前必须同时输出三类内容的数量统计。
5. 后续用例 Skill 消费时，必须优先使用 [PRD明确] 作为需求依据；[测试推导]作为测试设计；[待确认]作为需求澄清或风险项。

输出模板规范（强制，Step 4 编写时逐节点对照）

用例按 主模块 → 子模块 → 功能分组 → 功能 → 分支 → 测试要点 归纳整理，保证导入 XMind 后结构清晰、层级分明。
功能较多时必须在子模块与功能之间加“功能分组”层（feature_groups，按业务语义归类，如“配置”“辅助说明页面”“原逻辑回归”），把同一模块下的功能一层一层下钻，禁止把所有功能平铺在子模块下。
每个子模块先按 Step 3.4 的判定结果选择模板：有流程 → 流程形式；无流程 → 标准模板。

模板 A：标准模板（无流程的用例）

本期需求名称            ← project_name
└── 主模块               ← groups[].name
    └── 该模块下的子模块  ← groups[].modules[].name
        ├── 功能分组1     ← modules[].feature_groups[].name（可选；功能较多时按业务语义归纳）
        │   ├── 模块包括的功能1   ← feature_groups[].features[].name
        │   │   ├── 功能正例      ← dimensions.positive（功能层面·正常场景）
        │   │   │   ├── 1功能测试点1
        │   │   │   ├── 2功能测试点2
        │   │   │   └── 3功能测试点3
        │   │   ├── 功能反例      ← dimensions.negative（功能层面·异常场景）
        │   │   │   ├── 1功能反例测试点1
        │   │   │   ├── 2功能反例测试点2
        │   │   │   └── 3功能反例测试点3
        │   │   └── 场景          ← dimensions.data（数据层面·边界条件）
        │   │       ├── 1
        │   │       ├── 2
        │   │       └── 3
        │   └── 模块包括的功能2
        └── 该模块下的子模块2
    └── 主模块2

模板 B：流程形式（有流程的用例）

该模块下的子模块2        ← groups[].modules[].name（type="flow"）
└── 该模块流程           ← modules[].flow.name
    ├── 开始             ← flow.start
    ├── 流程节点1        ← flow.nodes[0]
    │   └── 该节点的测试要点 ← flow.nodes[].points
    ├── 流程节点2        ← flow.nodes[1]
    │   ├── 是           ← branches[0].condition（向后流转 type=forward）
    │   │   ├── 继续节点3  ← branches[0].next
    │   │   └── 结束      ← branches[0].next / flow.end
    │   └── 否           ← branches[1].condition（回退 type=back）
    │       └── 返回流程2 ← branches[1].target

流程形式编写要求：
- 节点按实际执行顺序排列；节点内可挂该节点的测试要点。
- 每个判定节点必须穷尽"是/否"（或通过/驳回）两条分支，分支内可挂该分支的测试要点。
- 存在回退/循环时用 "type": "back" + "target": "<历史节点名>"，渲染为 否 — 返回流程节点2。
- 仅在确实存在流程性用例时使用；不存在流程时禁止生成空的"该模块流程"节点。

Step 4：用例编写与模块化归纳（按模板输出）

目标：基于 Step 3 的用例设计与输出形式决策，编写测试用例并做模块化归纳，输出结构化用例集。

关键指令：
- 严格遵循 references/case-schema.md（v2.2）：不再写完整用例（不需要 case_id / 步骤 / 预期结果字段）。
- 模块化归纳：按 主模块 → 子模块 → 功能 → 分支 → 测试要点 + 概要 组织，保证 XMind 中层级分明、同一分支不重复堆叠。
- 按判定结果选模板：流程性子模块用 type:"flow" + flow；其余子模块用 dimensions（positive/negative/data）标准模板。
- 双维度不得缺失：每个功能的 positive / negative / data 三个分支都要有内容。
- 核心业务逻辑逐条列：每条规则在 positive 中单独立一条，不合并。
- 边界具体到数值：data 中写清最小值/最大值/临界越界值与具体长度、枚举、字符集。
- 概要（shared）：跨功能共用的要点集中到 shared，避免在每个功能重复列举。
- 每个子模块必须明确列出本期新增/变更的功能，不能笼统堆在一处。
- 用例描述必须贴合具体业务，写清"什么对象/字段/场景下，触发什么校验或行为"，禁止"测试正常/测试异常"等空话。
- 用例中的需求事实必须标 [PRD明确]；测试人员扩展的场景标 [测试推导]；需求未说明的标 [待确认]。

层级与命名规范（强制）

• 先按“主模块 → 子模块 → 功能分组 → 功能 → 测试分支 → 细分要点”建立树；同一子模块下的功能必须按业务语义归入功能分组，不将多个子模块、多个功能或多个规则平铺在同一节点；功能多到看不清归属时必须继续下钻。
• 子模块/功能名称使用业务动作或对象命名，例如“日期范围校验”“统计口径”“空数据展示”，避免使用“功能测试”“其他”等空泛标题。
• 一个测试分支只表达一个可独立验证的对象；按“字段/条件 → 场景 → 预期关注点”拆分，避免一条要点同时包含多个无关校验。
• 对可枚举内容逐项展开：每个状态、每个数据来源、每个边界值、每种组合条件分别列出；使用 1.、2.、3. 编号保持短句化。
• 每条要点控制在一至两行，优先使用“对象 + 条件 + 行为/结果”句式；详细解释放入嵌套 points，不在父节点堆长段落。
• 输出中明确区分 [PRD明确]、[测试推导]、[待确认]；截图只引用实际存在且与当前节点对应的原型证据，不用父节点截图冒充不存在的子页面截图。
• 可用 screenshot_paths 在子模块或功能节点绑定截图；Markdown 在节点下直接插入图片，HTML 在节点旁提供缩略图/可点击预览。
• 用户提供经过人工优化的 XMind、Markdown 或 HTML 时，将其视为风格基准样例：优先学习其层级深度、节点命名、场景拆分、概要聚合、编号方式和截图挂载方式，不得退回到“子模块下直接平铺测试内容”的旧风格。
• 生成前先检查每个子模块是否都有独立功能、每个功能是否都有独立测试分支、每个测试分支是否还能继续拆出条件/数据/结果；能拆分时必须继续下钻。
• 对“正例/反例”“有值/无值”“单选/多选”“全部/指定”“按日/按周/按月”“已启用/未启用/已发布/未发布”等成对或多状态场景，默认拆为并列节点，不合并成一句概括性描述。
• 需求中出现“测试场景”“注意点”“需要验证”等内容时，将其转换为具体的场景节点和细分验证点；不得原样保留为无法执行的空泛标题。

树结构示例（通用占位，实际内容按具体业务填充）：

主模块（一级大类）
├── 子模块A1
│   ├── 功能A1-1
│   │   ├── 功能正例
│   │   │   ├── 1. 测试要点1
│   │   │   └── 2. 测试要点2
│   │   ├── 功能反例
│   │   │   └── 1. 测试要点3
│   │   └── 场景
│   │       ├── 1. 边界场景1
│   │       └── 2. 边界场景2
│   └── 功能A1-2
│       └── ...
└── 子模块A2（流程形式）
    └── 该模块流程
        ├── 开始
        ├── 流程节点1
        ├── 流程节点2
        │   ├── 是
        │   │   ├── 继续节点3
        │   │   └── 结束
        │   └── 否 — 返回流程节点2
        └── ...

> 注意：skill 中不得固化任何具体业务的字段/规则/术语（如某业务的专用字段、规则编号、脚本逻辑等）。示例一律使用占位符或中性业务，确保换任何需求都能复用同一套流程与结构。

测试要点深度展开模式（标注说明）：

仅列"测试正常/异常"是不够的，测试要点应按以下通用模式深度展开，把每一条都拆成可独立验证的颗粒：

> 关键原则：每一条测试要点必须可独立执行 + 可独立验证。若一个要点无法独立验证（依赖其他操作 / 结果含糊），说明拆分不够细，继续按上述模式展开。

详细提示词：加载 references/workflow-details.md 的 Step 4。

检查清单（全部满足方可进入 Step 5）：
- 每个子模块都列出了本期新增/变更的功能
- 每个功能都写入了 dimensions.positive / negative / data 三个分支，且都有内容
- 核心业务逻辑在 positive 中逐条列出（未合并为"功能正常"）
- 数据层面的边界值已具体到数值
- 流程性子模块已按流程形式输出（节点顺序正确、是/否分支穷尽、回退路径用 type:"back"）
- 不存在流程性用例时，未生成任何空的"该模块流程"节点
- 跨功能的共性要点已用概要（shared）节点集中
- 用例描述贴合业务、具体、无空话/占位符
- 每条用例已标记为 [PRD明确]、[测试推导] 或 [待确认]
- [PRD明确] 内容均可回溯到 PRD 原文或来源定位
- [测试推导] 未被表述为需求事实，[待确认] 未被擅自补全
- 用户已确认用例集覆盖度满足要求

> 用例缺少必要数据（如具体边界值未定义）时，向用户提问，不得用假设值替代。

Step 5：用例结构化与覆盖自检

目标：整理为标准 JSON 文件，进行完整性、冗余、覆盖度自检。

关键指令：
- 整理为符合 references/case-schema.md（v2.2）的完整 JSON（顶层含 project_name / version / created_date / dimension_labels / groups）。
- 完整性校验：必填字段齐全；每个子模块、功能和测试要点均已覆盖；每条字符串、对象 name 和嵌套要点均带 [PRD明确]、[测试推导] 或 [待确认] 标记。
- 来源校验：[PRD明确] 必须有 PRD 原文或来源定位；[测试推导] 不得冒充需求事实；[待确认] 不得被擅自补全。
- 冗余检查：合并重复用例时保留来源标记，不得因合并丢失 PRD 明确内容；共性内容上提到 shared。
- 覆盖度自检（双维度 + 三类场景）：对照 Step 3 用例设计表逐项核对，并输出覆盖统计表：

• 任一功能三类场景中有 0 条时必须说明原因，不允许静默缺项。
• 模板一致性自检：有流程性子模块用 type:"flow"、其余用标准模板；无流程性用例时全量标准模板。
• 输出 test-points.json 全文 + 自检报告（含三类来源标记数量 + 双维度覆盖统计）。

详细提示词：加载 references/workflow-details.md 的 Step 5。

检查清单（全部满足方可进入 Step 6）：
- JSON 合法且符合 v2.2 规范，必填字段齐全
- 每个功能均覆盖正常 / 异常 / 边界三类场景（缺项已写明原因）
- Step 3 用例设计表中的每个测试点均已落为具体用例，未覆盖项为空（或已说明原因）
- 输出形式与流程性判定结果一致，无多余空流程节点
- 用户已确认最终用例集

> 自检未通过则修正后重新自检；覆盖不足源于需求缺失时，向用户提问，不得进入下一步。

Step 6：转换为 xmind

目标：将 test-points.json 转换为思维导图文件。

运行时选择（按序尝试，第一个可用即可）：

# 1) 首选 Node：零依赖，Windows 上可用性最高
node <skill目录>/scripts/gen_xmind.js test-points.json test-points.xmind

# 2) 备选 Python：Windows 下 python 命令常不可用，必须用 py -3
py -3 <skill目录>/scripts/gen_xmind.py test-points.json test-points.xmind

> 不要假设 python 命令存在。若 node 与 py -3 均失败，再尝试 python3 / python。

输出格式说明（固定约定）：
- 主产物输出 XMind Zen / 2020+ 高版本格式（--format=zen，zip 内含 content.json + metadata.json + manifest.json，layoutEngineVersion: "3"）。
- 不使用 XMind 8 兼容格式（content.xml）：XMind 2024/2026 已不兼容旧格式，直接打不开。
- 画布布局固定为 右向层级树：--layout=logic → 在 rootTopic.structureClass 写入 org.xmind.ui.map.tree.right（注意：XMind Zen 从 rootTopic 读取该字段，写 sheet 无效）。根在最左，模块→测试类型→用例→详情逐级向右展开。
- XMind 2024/2026 打开时的样式弹窗处理：新版 XMind 打开 zen 高版本文件可能提示"导图样式已更新为当前 XMind 版本资料库中最新样式"。引导用户点击"取消 / 否" 保留原布局；若用户点了确定被升级成思维导图，需在 XMind 画布手动切换结构（右键 → 结构 → 选择"逻辑图/右向"）并另存，再交付该文件。
- 备选格式：--format=xml8（老 XMind 8）、--format=opml、--format=md。
- 脚本内置结构类 ID：logic/tree = org.xmind.ui.map.tree.right；mindmap = 不设置（默认放射状）；orgchart = org.xmind.ui.map.orgchart.down。

生成纪律（先删再生成）：
- 每次生成前，先删除本次需求前缀的上一批产物（<prefix>-test-points.json、<prefix>-test-points.md、<prefix>-test-points.html，以及历史遗留的 .xmind / .opml / .xmind8.xmind），再运行生成命令；json 由 Step 5 重新生成覆盖，避免新旧文件混淆。
- 若用户只是要求把已确认的最新 json 重新转换为格式（未改需求内容），可保留该 json 并重新生成 md/html；除此之外不得保留上一批 json。
- Windows 下删除中文路径文件时用文件工具/脚本（终端传中文路径会乱码），不要用终端 del 命令操作中文路径。

默认产物（关键约束）：

• 本 skill 不再生成 .xmind 格式——直接交给 XMind 用户体验差（XMind 26 强制升级样式 / 8 兼容版不兼容），用户明确要求去掉
• 默认只生成 2 种产物：
• *.md：Markdown 大纲（标题层级 #/##/###/#### + - 列表项），用户可在 XMind 中「文件 → 导入 → Markdown」获得右向逻辑图
• *.html：纯静态 HTML（CSS 实现根在左、向右延展的逻辑图），零依赖、双击即看、可打印为 PDF
• 源数据 <prefix>-test-points.json 在每次完整生成时由 Step 5 重新覆盖，不额外保留旧版 json
• 其他格式（zen/xml8/opml）脚本仍保留支持（若用户显式需要可手动指定），但默认不输出 .xmind

可选格式（脚本支持但默认不用）：

• 画布布局（--layout=logic|tree|mindmap|orgchart，默认 logic）：仅用于 .xmind / .opml 格式
• 其他可用参数：--sheet-title=XXX（画布名称）

验证与交付：
- 确认产物文件存在且大小 > 0；层级为 根(本期需求名称) → 主模块 → 子模块 → 功能 → 分支(功能正例/功能反例/场景) 或 该模块流程(开始 → 流程节点 → 是/否分支)。
- 输出交付总结：文件清单（路径 + 大小）、用例统计（主模块数 / 子模块数 / 功能数 / 用例总数 / 功能正例(正常) / 功能反例(异常) / 场景(边界) / 流程形式处数）、脑图结构概览。
- JSON 解析失败则回到 Step 5 修正 test-points.json 后重试。

Windows 环境注意事项：
- 终端对中文参数的编码不稳定，中文路径/文件名可能被写成乱码目录或乱码文件名。产物文件名一律用 ASCII（如 test-points.md、order-test-points.html），中文只出现在文件内容中。
- 不要先 cd 进含中文的目录；脚本用绝对路径调用。
- 脚本已强制 UTF-8 输出，文件内中文内容不会乱码；终端回显出现乱码属正常现象，以实际文件为准。

详细提示词：加载 references/workflow-details.md 的 Step 6。

检查清单：
- 文件已生成且大小 > 0，脑图层级正确（标准模板与流程形式均正确渲染）
- 用例统计已输出（含正例/反例/场景三类数量），用户已确认可正常打开

Step 7：打磨工序（最终质量关卡，生成完毕后自动执行）

7.0 触发时机（强制）

Step 6 产物生成完毕后立即自动执行，无需用户触发、不得跳过。 这是交付前的最后一道工序，位置固定在「生成产物」之后、「交付总结」之前。

Step 5 结构化 → Step 6 生成产物 → Step 7 打磨工序 → 交付总结
                                    ↑ 本步骤，自动触发

打磨只改表达，不改语义：修正措辞、清理冗余与空白、核对功能与需求一致性；不得新增、删除或改写任何测试要点的事实内容（要改内容必须回 Step 4/5）。

7.1 打磨对象

铁律：只改 json 后重新生成 md/html；禁止直接手改 md/html（三者为生成关系，手改会在下次生成时丢失）。

7.2 检查项清单（五项，逐项过）

① 措辞打磨

> 常见拗口词与推荐替换表见 references/polish-rules.md，优先查表；表中没有的按上表规则判断。

② 冗余清理

• 同一功能下完全同义的要点 → 合并为一条（保留信息更全的表述）
• 跨功能重复且无差异的要点 → 上提到该子模块的 shared 概要
• 「测试正常」「测试异常」「功能可用」等无信息量的占位语句 → 删除或改写成具体对象+条件+预期
• 同一节点下 positive 与 negative 内容完全相同 → 至少一方改写为真正的反向场景

③ 空白内容清理

④ 功能与需求一致性核对

• 正向核对：需求文档中每一条明确需求，至少有一条用例覆盖（标注来源为需求原文）；
• 反向核对：每条用例都能回溯到需求原文或明确的测试推导理由，不得出现需求中不存在的功能点；
• 排除项核对：需求方声明「不在范围内」的内容（如需求素材、其他版本模块），用例中不得作为需求出现；如作为背景说明必须显式标注；
• 默认值核对：需求中给出的默认值，用例中必须原样出现且不被改写（如统一值、默认分类名）；
• 口径核对：同一规则在不同模块的描述必须一致（如唯一键规则、排序规则、校验提示）。

⑤ 可读性提升

• 同一层级的句式统一（建议「对象 + 条件 + 预期」）；
• 可枚举项用 1. 2. 3. 编号，不塞进一句；
• 成对/多状态场景（单选/多选、为空/非空、成功/失败）拆为并列要点，不用一句概括；
• 每条要点可独立执行、可独立验证；依赖其他操作才能验证的继续下钻拆分。

7.3 质量标准（量化门槛，全部满足才放行）

7.4 执行方式

建议脚本化自动检查 + AI 判断修正，流程：

1. 自动扫描：对 json 跑结构化检查（空节点、占位符、标注残留、长度、同义重复、术语不一致），输出问题清单；
2. 人工/AI 判断：对清单逐条判定「改表述 / 合并 / 删除 / 保留并说明原因」；
3. 应用修正：只改 json；
4. 重新生成：重跑 Step 6 生成 md/html；
5. 复扫确认：再跑一次自动扫描，确认 Q1–Q10 全部达标。

防误报铁律（扫描规则本身也要打磨）：宁可漏报，不可误报。 漏报只是没优化到，误报会把正确内容改错，且带着「自动检查」的可信度外衣更容易被直接采纳。

• 新增或修改扫描模式前，必须先在小样本上试跑，逐条人工判读命中项是否真为问题；存在任一条误报就收紧模式或弃用该模式；
• 中文的「的」字结构、量词结构（如 0 条历史）、被动句极易误报，这类模式默认按误报处理，必须人工确认；
• 扫描结果一律标注「待人工确认」，不得作为「已发现问题」直接修改；每条命中必须带原文摘录与路径，没有摘录的命中项不允许进入修改环节。

> 典型案例：用正则 的历史 扫「助词错位」，命中 6 处 的历史记录、的历史档案——均为正确语法。若不判读直接替换，会改坏 6 条正确表述。

7.5 不过关时的处理

检查清单（全部满足方可交付）：
- Q1–Q10 全部达标，自动扫描结果干净
- md / html 已由打磨后的 json 重新生成（非打磨前版本）
- 打磨只改表达、未改动任何要点的事实内容
- 已执行防误报自检：本次使用的扫描/替换规则无误报（有误报的已收紧或弃用，并记入打磨报告）
- 已向用户说明本次打磨改了什么（改了哪些类、多少处）
- 用户已确认可正常打开最终产物

Step 8：可选的付费解锁（默认关闭，需用户显式同意上传）

本节默认不执行：Step 7 通过后，把本机三件套的路径直接交付给用户即完成全流程，不联网、不上传。仅当用户主动要求"发布预览 / 解锁完整版"时才进入本节。

详细契约：references/aipay-integration.md（接口字段、状态码、告知清单与校验纪律）。服务地址只从 config/aipay.json 的 api 字段读取，环境变量 AIPAY_SKILL_API 优先；未配置即视为不启用，直接跳过本节。

8.1 前置条件（全部满足才可继续）

• Step 7 已通过 Q1–Q10，<prefix>-test-points.json/.md/.html 均为打磨后版本
• 服务地址已配置（config/aipay.json 或 AIPAY_SKILL_API），且为 HTTPS
• 用户主动要求付费解锁（不得由 skill 自行发起）
• 已向用户展示 8.2 的告知清单，且用户明确表示同意上传

8.2 上传前告知清单（必须逐项展示，缺一不可）

先执行只读命令拿到真实清单（不联网）：

node <skill目录>/scripts/aipay_gate.js manifest --dir <专属输出目录> --prefix <prefix>

把 stdout 原样呈现给用户，必须包含以下各项：

在用户明确同意之前，不得执行 8.3。

8.3 上传并展示节选（必须带 --consent）

node <skill目录>/scripts/aipay_gate.js publish --dir <专属输出目录> --prefix <prefix> --consent

• 缺 --consent 时脚本立即以退出码 5 中止，不发起任何网络请求
• 拿到 draft_id 后，把 stdout 的「节选预览」原样呈现，并说明结构统计（主模块 / 子模块 / 功能 / 用例要点）、预览比例、价格与下一步命令
• 上传失败（退出码 4）时按 8.6 回落到本地交付，不反复重试

8.4 触发支付

node <skill目录>/scripts/aipay_gate.js unlock --draft <draft_id>

• 退出码 2 表示需要支付：把返回的 金额、支付截止时间、amtPaymentLink、Payment-Needed 原样呈现
• 宿主具备 AI 付支付能力时，把 Payment-Needed 交给支付能力完成付款；否则请用户用支付宝端支付后把 Payment-Proof 提供回来

8.5 解锁、校验与落盘

node <skill目录>/scripts/aipay_gate.js unlock --draft <draft_id> --proof <Payment-Proof> --prefix <prefix>

输出目录默认是当前登录用户主目录下的 test-points/（Windows 即 C:\Users\<用户名>\test-points），与执行命令时的 cwd 无关，无需传 --out；确需指定时才用 --out <目录>。

服务端返回的三件套通过校验后写入 <prefix>-test-points.json/.md/.html。落盘前脚本强制做以下校验，任一不通过即以退出码 6 中止且不写任何文件：

支付由买方客户端完成时（收银台/AI 付客户端代为请求资源并拿到 200），把该 200 响应体原样存成文件后落盘：

node <skill目录>/scripts/aipay_gate.js save --body <支付端返回的响应体.json> --prefix <prefix>

同样经过上述校验后写入 <prefix>-test-points.json/.md/.html，并回显 draft_id / 订单号 / 履约确认状态。禁止手抄或改写响应体内容。

8.6 降级与失败处理（一律以本地产物兜底）

8.7 检查清单（执行过本节时逐项确认）

• 用户已看到 8.2 的完整告知清单，并在对话中明确同意上传
• 上传时带了 --consent，且未在用户同意前发起任何网络请求
• unlock 返回 200，且已附带 Payment-Validation 回执
• 回传内容通过摘要或结构校验（退出码 0），落盘文件大小 > 0
• 覆盖前已生成 <文件名>.bak 备份（可直接回滚）；已向用户输出 draft_id、out_trade_no、trade_no、最终文件路径与大小
• 未执行本节或发生降级时，交付说明明确标注"本地直出，未上传"

> 付费解锁是可选服务，不是交付门槛。任何环节失败都回落到本地产物，不重复扣款、不重复上传、不编造凭证、不把未校验的回传内容写盘。

需求澄清提问模板

任一步骤检查清单未满足时，按以下模板提问：

我在【Step X：步骤名称】中发现以下信息尚不明确，需要您确认后再继续：

1. [问题1描述]
   - 当前理解：[最佳猜测]
   - 需要确认：[具体问题]

2. [问题2描述]
   - 当前理解：[最佳猜测]
   - 需要确认：[具体问题]

如涉及界面或流程不清晰，请提供截图，我将根据截图理解后再继续。

资源

• scripts/gen_xmind.js — 首选。Node 零依赖转换脚本，输出 MD / HTML / OPML / Zen / XML8 格式，支持 dimensions 双维度分支与 flow 流程链（Step 6 时运行，无需加载进上下文）。
• scripts/gen_xmind.py — Python 标准库版本的等价脚本（默认 md），供 Node 不可用时使用（py -3 调用）。
• references/workflow-details.md — 各步骤的完整提示词原文（Prompt），执行到对应步骤时按需加载。
• references/case-schema.md — v2.2 用例字段与模板规范：双维度（dimensions）、流程形式（flow）、输出形式决策规则（Step 3/4/5 时按需加载）。
• references/polish-rules.md — Step 7 打磨工序配套细则：拗口词替换表、冗余与空白识别规则、需求一致性四向核对、自动扫描脚本要点、Q1–Q10 门槛速查（Step 7 时按需加载）。
• scripts/aipay_gate.js — Step 8 可选付费解锁客户端（零依赖）：manifest 只读展示上传清单（不联网）、publish 需 --consent 才上传暂存、unlock/save 校验后落盘、status 查询（Step 8 时运行，无需加载进上下文）。
• config/aipay.json — 服务地址与告知文案配置：api 留空即禁用付费流程；可被环境变量 AIPAY_SKILL_API 覆盖，scope/purpose/retention 用于上传前告知。
• references/aipay-integration.md — Step 8 接入契约：服务端接口、402/410/502 处理、上传告知清单、回传校验与路径防护、Payment-Proof 来源（Step 8 时加载）。
• assets/example-cases.json — 结构示例（中性业务），同时演示标准模板与流程形式两种写法。